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