from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:
Mauro Condarelli
mc5686 at mclink.it
Tue Sep 1 15:09:35 CEST 2020
Hi Daniel,
Hi Stefan,
comments inline below.
Many Thanks
Mauro
On 9/1/20 1:41 AM, Daniel Schwierzeck wrote:
> Am Montag, den 31.08.2020, 23:53 +0200 schrieb Mauro Condarelli:
>> Thanks Daniel.
>>
>> On 8/31/20 10:36 PM, Daniel Schwierzeck wrote:
>>> Hi Mauro,
>>>
>>> Am Montag, den 31.08.2020, 21:57 +0200 schrieb Mauro Condarelli:
>>>> Sorry to disturb :(
>>>>
>>>> I am trying to switch from https://gitlab.denx.de/u-boot/custodians/u-boot-mips commit f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master.
>>>> In both case I'm using plain "vocore2_defconfig".
>>>>
>>>> Actually I'm using:
>>>> make ARCH=mips CROSS_COMPILE=~/vocore/__V2__/Buildroot-2/mipsel-buildroot-linux-uclibc_sdk-buildroot/bin/mipsel-linux- all
>>>> for master and Buildroot compilation environment for `u-boot-mips`, but I don't think that's the problem (compiler is the same, if needed I'll recompile manually "old" also).
>>>>
>>>> Of course the two versions have tons of differences, but .config is essentially the same (some reordering and a few apparently harmless new CONFIG_s; iff deemed useful I can post both, but, as said, I'm using in-tree vocore2_defconfig in both cases).
>>>>
>>>> First thing is something changed in compilation and the old "u-boot-mtmips.bin" si nowhere to be found, apparently replaced by "u-boot-with-spl.bin".
>>>>
>>>> Second data point is new u-boot is substantially larger:
>>>>
>>>> -rwxr-xr-x 1 root root 244580 Aug 31 20:06 u-boot-mtmips.bin
>>>> -rwxr-xr-x 1 root root 275005 Aug 31 20:00 u-boot-with-spl.bin
>>>>
>>>> Third and most important new version does not work:
>>>>
>>>> ===============================================
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU: MediaTek MT7628A ver:1 eco:2
>>>> Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>> DRAM: 128 MiB
>>>> WDT: Started with servicing (60s timeout)
>>>> MMC: mmc at 10130000: 0
>>>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
>>>> OK
>>>> In: uart2 at e00
>>>> Out: uart2 at e00
>>>> Err: uart2 at e00
>>>> Model: VoCore2
>>>> Net:
>>>> Warning: eth at 10110000 (eth0) using random MAC address - b6:bf:30:14:ba:25
>>>> eth0: eth at 10110000
>>>> Hit any key to stop autoboot: 0
>>>> => load mmc 0:1 80010000 u-boot-mtmips.bin && go ${fileaddr}
>>>> 244580 bytes read in 17 ms (13.7 MiB/s)
>>>> ## Starting application at 0x80010000 ...
>>>>
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU: MediaTek MT7628A ver:1 eco:2
>>>> Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>> DRAM: 128 MiB
>>>> WDT: Started with servicing (60s timeout)
>>>> MMC: mmc at 10130000: 0
>>>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
>>>> OK
>>>> In: uart2 at e00
>>>> Out: uart2 at e00
>>>> Err: uart2 at e00
>>>> Model: VoCore2
>>>> Net:
>>>> Warning: eth at 10110000 (eth0) using random MAC address - 36:f2:c3:0a:27:a4
>>>> eth0: eth at 10110000
>>>> Hit any key to stop autoboot: 0
>>>> =>
>>>> ===============================================
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU: MediaTek MT7628A ver:1 eco:2
>>>> Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>> DRAM: 128 MiB
>>>> WDT: Started with servicing (60s timeout)
>>>> MMC: mmc at 10130000: 0
>>>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
>>>> OK
>>>> In: uart2 at e00
>>>> Out: uart2 at e00
>>>> Err: uart2 at e00
>>>> Model: VoCore2
>>>> Net:
>>>> Warning: eth at 10110000 (eth0) using random MAC address - 1e:a9:c5:a8:35:82
>>>> eth0: eth at 10110000
>>>> Hit any key to stop autoboot: 0
>>>> => load mmc 0:1 80010000 u-boot-with-spl.bin && go ${fileaddr}
>>>> 275005 bytes read in 20 ms (13.1 MiB/s)
>>>> ## Starting application at 0x80010000 ...
>>>> <<dead>>
>>>> ===============================================
>>>>
>>>> What am I doing so wrong?
>>>>
>>>> I'm available to all possible tests, but I'm, most likely, just missing something obvious.
>>>> I'm also available on IRC as "mcon".
>>>>
>>> we have removed the custom target "u-boot-mtmips.bin" during review
>>> because there already is a generic variant with CONFIG_BUILD_TARGET to
>>> build extra images. Have a look at arch/mips/mach-mtmips/Kconfig:
>>>
>>> config SYS_TEXT_BASE
>>> default 0x9c000000 if !SPL
>>> default 0x80200000 if SPL
>>>
>>> config SPL_TEXT_BASE
>>> default 0x9c000000
>>>
>>> config SPL_PAYLOAD
>>> default "u-boot-lzma.img" if SPL_LZMA
>>>
>>> config BUILD_TARGET
>>> default "u-boot-with-spl.bin" if SPL
>> I am somewhat aware of that... and that's the reason to use
>>
>> "u-boot-with-spl.bin"
>>
>> for testing.
>>> Also your test is looking strange. You can't load the full SPL image to
>>> RAM to a random address. You would have to load the SPL to the correct
>>> link address at 0x9c000000 but I guess that's not possible because this
>>> memory region is some read-only XiP area mapped to SPI flash. What
>>> should work is loading the raw u-boot.bin payload to 0x80200000 and
>>> start it from there.
>> I seemed to recall SPL code was Position Independent, but
>> apparently I'm wrong.
> SPL is always position dependent for smallest possible binary size.
> Only the proper U-Boot binary is position independent (actually it's
> also compiled as position dependent but uses the same hack/technique as
> MIPS Linux to emit and store relocation information).
>
>> What is the correct way to test in RAM before flashing?
>> Problem being a wrong flashing bricks target (I do have means
>> to recover bricked targets, but not here).
> you can only reliably test the U-Boot payload by loading u-boot.bin to
> CONFIG_SYS_TEST_BASE. Testing the SPL binary only makes sense with a
> EJTAG debugger.
>
>>> Have you actually tried to write u-boot-with-spl.bin to SPI flash? The
>> Yes I did and it didn't work :(
>> That's why I'm trying to chain load in RAM as I do NOT have a
>> JTAG debugger, unfortunately.
>>
>>> only result I can see from your test is that U-Boot crashed after the
>>> go command and the CPU simply booted again from the currently flashed
>>> 2020.04-rc1 image. Only the last test resulted in a permanent hang.
>> No, I was not clear.
>> First test was fully functional.
>> I willingly rebooted from SPI NOR in order to do the second test
>> in the same condition.
>> Second test crashed immediately.
>>
>>> The final version mtmips SPL series (which got merged) was also tested
>>> by Stefan Roese so it should simply work on your VoCore2 board.
>>>
>>> You could also switch to tag 2020.07 and test that. It could also be
>>> possible that something else got broken since 2020.07.
>> I will do that test ASAP.
>> I assume You mean I should Flash "u-boot-with-spl.bin" to SPI NOR,
>> right?
> yes
Since Stefan confirmed "master" has no problems with GARDENA
I went ahead and reflashed with current master.
>> Do You have any hint why "u-boot-with-spl.bin" is substantially
>> larger than "u-boot-mtmips.bin" with essentially the same defconfig?
> u-boot-with-spl.bin applies some padding between SPL and payload:
>
> lzma -c -z -k -9 u-boot.bin > u-boot.bin.lzma
> ./tools/mkimage -A mips -T standalone -C lzma -O u-boot -a 0x80200000
> -e 0x80200000 -n "U-Boot 2020.10-rc3""-00012-g9f04a634ef for vocore2
> board" -d u-boot.bin.lzma u-boot-lzma.img >/dev/null && cat /dev/null
> /opt/gcc-9.2.0-nolibc/mips-linux/bin/mips-linux-objcopy --gap-
> fill=0xff -O elf32-tradlittlemips -j .data.reloc -j .dtb.init.rodata
> -j .text -j .rodata -j .data -j .u_boot_list -I binary -O binary --pad-
> to=0x10000 spl/u-boot-spl.bin u-boot-with-spl.bin && cat u-boot-
> lzma.img >> u-boot-with-spl.bin || rm -f u-boot-with-spl.bin
>
>
> The padding can be controlled with CONFIG_SPL_PAD_TO. IIRC the first
> patch series also had padding, but v2 or v3 not anymore. Looking
> at arch/mips/mach-mtmips/spl.c:spl_nor_get_uboot_base(), the u-boot-
> lzma.img must be cat'ed directly after u-boot-spl.bin. So you need to
> set CONFIG_SPL_PAD_TO to 0. This is done for the other MTMIPS boards:
>
> include/configs/gardena-smart-gateway-mt7688.h:28:#define
> CONFIG_SPL_PAD_TO 0
>
> include/configs/linkit-smart-7688.h:28:#define
> CONFIG_SPL_PAD_TO 0
I added this to my include/configs/vocore2.hand mow difference
is MUCH smaller:
-rwxr-xr-x 1 root root 244580 Aug 31 20:06 u-boot-mtmips.bin
-rwxr-xr-x 1 root root 247721 Sep 1 13:19 u-boot-with-spl.bin
... possibly compatible with all other changes between the two versions.
> But it's missing in include/configs/vocore2.h. Could you send a patch
> to add this?
I surely will, as soon as I'm certain this actually works ;)
>> I am switching also because I need SquashFS support; do You
>> have any idea how stable is that? (I need it to load Linux Kernel).
> it's a read-only FS, so there shouldn't be any stability issues. The
> worst case would be that the Linux image has bit errors after reading
> to RAM. But bootm should catch this during the image checksum check.
>
>> Many Thanks in Advance
>> Mauro
>>
>> P.S.: "daniel666" on IRC is You?
> yes
>
>> Regards
>> Mauro
>>
Now problem is "Unable to allocate 209398 bytes for LZMA"
Full trace below.
I assume I should enlarge
#define CONFIG_SYS_MALLOC_LEN (1024 * 1024)
since GARDENA has:
#define CONFIG_SYS_MALLOC_LEN (16 * 1024 * 1024)
but I would like a confirmation, if possible.
TiA!
full trace: =============================
U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
Trying to boot from NOR
U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
CPU: MediaTek MT7628A ver:1 eco:2
Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc at 10130000: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In: uart2 at e00
Out: uart2 at e00
Err: uart2 at e00
Model: VoCore2
Net:
Warning: eth at 10110000 (eth0) using random MAC address - 8a:c1:c1:2a:28:91
eth0: eth at 10110000
Hit any key to stop autoboot: 0 <--- booting ok with "mtmips"
=> ls mmc 0:1
179840 uboot-ram_20170210.bin
179840 uboot-ram.bin
183272 uboot-rom_20170213.bin
183272 uboot-rom_20170423.bin
1819846 uImage.initram
1473392 initram.cpio.xz
1819846 uImage
534530 u-boot.bin
12713984 recov.squashfs
52983808 okcash.swu
698880 persist_data.tar
97 net.cfg
2360074 recov.uImage-old
247721 u-boot-with-spl.bin
244580 u-boot-mtmips.bin
15 file(s), 0 dir(s)
=> load mmc 0:1 80200000 u-boot.bin
534530 bytes read in 35 ms (14.6 MiB/s)
=> go ${fileaddr} <--- test of raw image (OK)
## Starting application at 0x80200000 ...
U-Boot 2020.10-rc3-00012-g9f04a634ef-dirty (Sep 01 2020 - 09:40:13 +0200)
CPU: MediaTek MT7628A ver:1 eco:2
Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc at 10130000: 0
Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In: uart2 at e00
Out: uart2 at e00
Err: uart2 at e00
Model: VoCore2
Net:
Warning: eth at 10110000 (eth0) using random MAC address - 7e:fc:d1:78:a2:4e
eth0: eth at 10110000
Hit any key to stop autoboot: 0
=> sf probe
=> load mmc 0:1 85000000 u-boot-with-spl.bin <--- use raw image to reflash
247721 bytes read in 18 ms (13.1 MiB/s)
=> sf update ${fileaddr} 0 ${filesize}
device 0 offset 0x0, size 0x3c7a9
247721 bytes written, 0 bytes skipped in 2.269s, speed 111648 B/s <--- apparently OK
=> reset
resetting ...
U-Boot SPL 2020.10-rc3-00012-g9f04a634ef-dirty (Sep 01 2020 - 09:40:13 +0200)
Trying to boot from NOR
alloc space exhausted
Unable to allocate 209398 bytes for LZMA
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
*** DTR: up ***
<--- this is effectively a power-cycle
*** DTR: down ***
U-Boot SPL 2020.10-rc3-00012-g9f04a634ef-dirty (Sep 01 2020 - 09:40:13 +0200)
Trying to boot from NOR
alloc space exhausted
Unable to allocate 209398 bytes for LZMA <--- same error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
*** DTR: up ***
More information about the U-Boot
mailing list