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

[Pali Rohár]

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.

For other cases it is a good idea to use kermit protocol instead of
xmodem.

> But:
> I see this on my PC on the first use of a baudrate change:
> $ stty -F /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> 921600
> stty: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0: unable
> to perform all requested operations
> 
> The 2nd call succeeds. Not sure what this means. Perhaps this has
> something to do with the speed problem, I'm seeing here on my AXP
> target with the FTDI USB-UART controller.

Maybe this could indicate bugs in kernel driver.

> Thanks,
> Stefan