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. 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 ***
