from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:

Mauro Condarelli mc5686 at mclink.it
Mon Aug 31 23:53:55 CEST 2020


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

> 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?

Do You have any hint why "u-boot-with-spl.bin" is substantially
larger than "u-boot-mtmips.bin" with essentially the same defconfig?

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

Many Thanks in Advance
Mauro

P.S.: "daniel666" on IRC is You?
Regards
Mauro



More information about the U-Boot mailing list