from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:
Daniel Schwierzeck
daniel.schwierzeck at gmail.com
Tue Sep 1 01:41:12 CEST 2020
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
>
> 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
But it's missing in include/configs/vocore2.h. Could you send a patch
to add this?
>
> 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
>
--
- Daniel
More information about the U-Boot
mailing list