[PATCH u-boot-marvell 00/13] Yet another kwboot improvements

[Stefan Roese]

On 26.10.21 17:34, Marek Behún wrote:
> On Tue, 26 Oct 2021 17:25:10 +0200
> Stefan Roese <sr at denx.de> wrote:
> 
>> On 26.10.21 17:20, Marek Behún wrote:
>>> On Tue, 26 Oct 2021 17:13:05 +0200
>>> Stefan Roese <sr at denx.de> wrote:
>>>    
>>>> Here is now just hangs forever. No output from main U-Boot proper at
>>>> all. This happed every time, when the baudrate is changed, meaning a
>>>> non 115200 -B is passed to kwboot. I checked with 115201 and here no
>>>> U-Boot proper output is printed as well.
>>>>   
>>>>> If there are timeout errors related to "Waiting 1s for baudrate change
>>>>> magic" then increasing 1s (1000 ms value) to e.g. 10s could help.
>>>>
>>>> I changed the timeout to 10s without any change. It did not help.
>>>
>>> At what address is the image being sent to? Please send dumpimage
>>> output for the kwb image.
>>
>> [stefan at ryzen u-boot-marvell (kwboot-test1)]$ ./tools/dumpimage -l
>> u-boot-spl.kwb
>> Image Type:   MVEBU Boot from spi Image
>> Image version:1
>> BIN Hdr Size: 89196 Bytes = 87.11 KiB = 0.09 MiB
>> Data Size:    548604 Bytes = 535.75 KiB = 0.52 MiB
>> Load Address: 00800000
>> Entry Point:  00800000
> 
> I think the baudrate changing code is not the problem, because it
> executes correctly in the binhdr when increasing the baudrate.
> Otherwise
>    Changing baudrate to 230400 Bd
> wouldn't be printed.

Okay. Still it's unclear, why I don't see any speedup in the download
time here.

> Stefan, did it previously work on this board?

No...

> I mean at the time the
> patches were first merged into u-boot-marvell Did the problem start
> occuring only now, when the code is merged in u-boot master?

... Meaning, it still works when the baudrate is not changed at all.
I never tried with a baudrate != 115200 until your work in this area
here.

>>> Is it possible to connect JTAG to the board?
>>
>> It is. But this would be a bit difficult for me, to dig all these old
>> tools out and find the correct configuration of the BDI.
> 
> Yes, lets keep that as last resort.

Agreed.

Thanks,
Stefan