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

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

[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".

Thanks in advance.
Mauro Condarelli

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

[Daniel Schwierzeck]

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

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. 

Have you actually tried to write u-boot-with-spl.bin to SPI flash? The
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. 

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.

-- 
- Daniel

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

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

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

[Daniel Schwierzeck]

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

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

[Stefan Roese]

Hi Daniel,
Hi Mauro,

On 31.08.20 22:36, Daniel Schwierzeck wrote:

<snip>

> Have you actually tried to write u-boot-with-spl.bin to SPI flash? The
> 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.
> 
> 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.

Just a quick note. I tested mainline (master) just right now and it
works without any issues (AFAICT) on the GARDENA 7688 board:

U-Boot SPL 2020.10-rc3-00033-g23e333a5c0 (Sep 01 2020 - 06:49:58 +0200)
Trying to boot from NOR


U-Boot 2020.10-rc3-00033-g23e333a5c0 (Sep 01 2020 - 06:49:58 +0200)

CPU:   MediaTek MT7688A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: GARDENA smart Gateway (MT7688)
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
Loading Environment from SPIFlash... SF: Detected XM25QH64A with page 
size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
F-Data:factory-data version 1 detected
Net:   eth0: eth at 10110000
Hit any key to stop autoboot:  0

HTH.

Thanks,
Stefan

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

[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 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
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 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 - 8a:c1:c1:2a:28:91
eth0: eth at 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 at 10130000: 0
Loading Environment from SPIFlash... 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 - 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 ***

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

[Stefan Roese]

Hi Mauro,

On 01.09.20 15:09, Mauro Condarelli wrote:

<snip>

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

Its the SPL malloc area, so you need to change a different value:

Please try to increase this value via Kconfig:

CONFIG_SPL_SYS_MALLOC_F_LEN

On GARNEDA its currently this:
CONFIG_SPL_SYS_MALLOC_F_LEN=0x40000

HTH,
Stefan

> 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 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 - 8a:c1:c1:2a:28:91
> eth0: eth at 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 at 10130000: 0
> Loading Environment from SPIFlash... 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 - 7e:fc:d1:78:a2:4e
> eth0: eth at 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 ***
> 
> 
> 


Viele Gr??e,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

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

[Daniel Schwierzeck]

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 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
> 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 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 - 8a:c1:c1:2a:28:91
> eth0: eth at 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 at 10130000: 0
> Loading Environment from SPIFlash... 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 - 7e:fc:d1:78:a2:4e
> eth0: eth at 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