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

[Stefan Roese]

On 28.10.21 19:00, Pali Rohár wrote:
> On Thursday 28 October 2021 16:20:11 Stefan Roese wrote:
>> On 28.10.21 13:04, Pali Rohár wrote:
>>> On Thursday 28 October 2021 08:16:24 Stefan Roese wrote:
>>>> On 27.10.21 23:03, Pali Rohár wrote:
>>>>> On Wednesday 27 October 2021 17:27:41 Stefan Roese wrote:
>>>>>> Still I see no speed change. But this is a different story...
>>>>>
>>>>> Could you try to upload some file in u-boot via xmodem at different
>>>>> speeds? E.g. via loadx command:
>>>>>
>>>>> loadx <addr> 921600
>>>>>
>>>>> and
>>>>>
>>>>> loadx <addr> 115200
>>>>
>>>> loadx & loady are producing nearly the same numbers on my Armada XP
>>>> target for download (slow of cause). This is really strange.
>>>
>>> Ok. So it means that the issue should not be in kwboot, if also U-Boot
>>> xmodem implementation is affected.
>>
>> Agreed.
>>
>>>> I also tested with "normal" console actions (logging) with higher
>>>> baudrates. Here these numbers:
>>>>
>>>> time md 2000000 10000:
>>>>
>>>> 115200 baud:
>>>> time: 1 minutes, 32.694 seconds
>>>>
>>>> 921600 baud:
>>>> time: 11.587 seconds
>>>>
>>>> 92.7s vs 11.6s -> factor ~8. Which is exactly the baudrate difference.
>>>> So at least here I see a speed difference, which means that the USB
>>>> UART converter must be working in general. I really have no idea right
>>>> now to explain, why this does not any speed differences while
>>>> downloading.
>>>
>>> So this means that USB-UART converter must work also on higher speeds.
>>>
>>> My idea is that there is some significant overhead on USB-UART when
>>> accessing either RX or TX queue. xmodem protocol is: send 132 bytes,
>>> wait for 1 byte reply, send another 132 bytes, wait again for 1 byte
>>> reply, ... So if USB-UART has internal overhead which cause that every
>>> byte is postponed by some delay then it would mean that xmodem is most
>>> time just waiting, meaning overhead is applied for every one 132-byte
>>> long packet. Test with md cause continuous stream of data, therefore
>>> such overhead is applied only at beginning of the md transfer.
>>>
>>> Similar issues with can observed also on high speed networks were is
>>> very big latency when using protocols where each small packet has to be
>>> acknowledged. TCP is using windowing to prevent such kind of issues.
>>>
>>> And kermit protocol too via its streaming mode. So kermit transfer could
>>> prove if this is really that issue.
>>>
>>> Anyway, I have looked at your strace output again and I saw that there
>>> is a long gap after tcdrain() and end of the read(). So if kernel
>>> implements tcdrain() for your USB-UART hw it means that it take too much
>>> time to receive reply byte from USB-UART hw to the kernel. So it could
>>> be another indication of that overhead.
>>
>> Thanks for the input here.
>>
>>>>> And compare if xmodem transfer is in U-Boot faster or not. Ideally also
>>>>> try via kermit protocol at different speeds as kernel supports
>>>>> streaming.
>>>>
>>>> I'm currently struggling to get gkermit working on my Ubuntu machine -
>>>> so no numbers here yet, sorry.
>>>
>>> In U-Boot console call:
>>>
>>>     loadb _addr_
>>>
>>> And then quit terminal emulator used for U-Boot /dev/ttyUSBX device.
>>> Then run gkermit with following arguments:
>>>
>>>     gkermit -i -X -s _file_to_send_ < /dev/ttyUSBX > /dev/ttyUSBX
>>>
>>> (redirecting both stdin and stdout is required)
>>>
>>> After successful transfer gkermit exit. BEWARE that gkermit does not
>>> print any progress information and neither any error. So do not kill
>>> gkermit via CTRL+C prematurely. You can use "time gkermit ..." for
>>> measuring total transfer time.
>>>
>>> If you are going to use different speed than 115200 in u-boot run:
>>>
>>>     loadb _addr_ _speed_
>>>
>>> And then on host start gkermit with more commands around:
>>>
>>>     stty -F /dev/ttyUSBX _speed_
>>>     printf '\015' > /dev/ttyUSBX
>>>     gkermit -i -X -s _file_to_send < /dev/ttyUSBX > /dev/ttyUSBX
>>>     sleep 0.5
>>>     stty -F /dev/ttyUSBX 115200
>>>     printf '\033' > /dev/ttyUSBX
>>>
>>> Due to absence of progress bar and error information I'm using ckermit
>>> application for kermit file transfers. But for testing purposes is
>>> gkermit application here also fine.
>>
>> Ah, perfect. Here my number now using these steps and gkermit, with
>> a file size of 549373 bytes:
>>
>> 115200 baud: ~72 sec
>> 921600 baud: ~11 sec
> 
> So I think it is clear now. Either USB-UART HW or kernel driver for it
> has some big overhead for any protocol which needs acknowledgement of
> received data. So xmodem protocol is not suitable for it.
> 
> It would require to debug kernel driver and ideally monitor traffic on
> oscilloscope to see where exactly is the issue.
> 
> And because bootrom supports only xmodem protocol we cannot do more in
> kwboot.

Agreed. Let's close this issue here. Important is, that kwboot still
works on all supported SoC's - even if the speedup improvements may
not be available for all boards.

Thanks for all your work here,
Stefan