Am Dienstag, den 01.09.2020, 15:09 +0200 schrieb Mauro Condarelli:
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@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@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - b6:bf:30:14:ba:25 eth0: eth@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@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@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 36:f2:c3:0a:27:a4 eth0: eth@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@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@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 1e:a9:c5:a8:35:82 eth0: eth@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.
I think you need to increase CONFIG_SPL_SYS_MALLOC_F_LEN. The error is due to decompressing u-boot-lzma.img. I guess your raw u-boot.bin is bigger than Gardena, thus you need more buffer space. Maybe try with +512k or +1024k.
Increasing CONFIG_SYS_MALLOC_LEN also makes sense but is only relevant for the final u-boot.bin when using UBI or LZMA compressed Linux images.
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@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@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 8a:c1:c1:2a:28:91 eth0: eth@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@10130000: 0 Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 7e:fc:d1:78:a2:4e eth0: eth@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 ***