On Fri, 27 Aug 2021, 8:32 PM Pali Rohár, <p...@kernel.org> wrote: > On Friday 27 August 2021 14:45:07 Chris Packham wrote: > > On Fri, Aug 27, 2021 at 1:39 PM Marek Behún <marek.be...@nic.cz> wrote: > > > > > > On Fri, 27 Aug 2021 13:16:25 +1200 > > > Chris Packham <judge.pack...@gmail.com> wrote: > > > > > > > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún <marek.be...@nic.cz> > wrote: > > > > > > > > > > Hello Stefan and others, > > > > > > > > > > this series adds support for booting Marvell platforms via UART > (those > > > > > bootable with kwboot) at higher baudrates. > > > > > > > > > > Tested on Turris Omnia up to 5.15 MBd, which is 44x faster than > > > > > 115200 Bd. > > > > > > > > > > The user can direct kwboot to use higher baudrate via the -B > option. > > > > > (BTW this option was there before but did not work with the -b > option.) > > > > > > > > > > Only the payload part of the KWB image is uploaded at this higher > > > > > baudrate. The header part is still uploaded at 115200 Bd, since > the code > > > > > that changes baudrate is injected into header as a binary > extension. > > > > > (The payload part makes up majority of the binary, though. On > Turris > > > > > Omnia the payload currently makes ~87%.) > > > > > > > > > > The series also contains various other fixes, refactors and > improvements > > > > > of the code, upon which the main change is done. > > > > > > > > > > Marek & Pali > > > > > > > > What tree/sha is this series based on. I've tried to apply them out > of > > > > patchwork and it fails at "tools: kwbimage: Simplify iteration over > > > > version 1 optional headers" > > > > > > Applies to master and to u-boot-marvell, but you need the 6 > > > additional patches for kwbimage/kwboot that are on patchwork > > > but not yet applied to u-boot-marvell: > > > https://patchwork.ozlabs.org/project/uboot/list/?series=257577 > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817050320.11983-1-xypron.g...@gmx.de/ > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210817051158.13283-1-xypron.g...@gmx.de/ > > > > > > Also some more fixes were yet needed, which I will sent in v2. > > > > > > To make it simpler for you I pushed v2 into > > > https://gitlab.nic.cz/turris/turris-omnia-uboot > > > branch > > > kwboot-baudrate-improvements > > > > > > > Thanks. I took it for a spin on the x530. In terms of regression > > testing the default behaviour is good. > > > > The higher speed settings weren't so good. I started with 3125000 and > > that doesn't get onto the 2nd part of the download, same for 1152000 > > and 4000000 (I stopped trying higher speeds at that point). Using > > 230400 and 460800 it does make it through the 2nd part of the download > > but when I go back on to the console it appears to be unresponsive. > > > > All of this could be down to the serial hardware in my system (the > > x530 uses a real RS232 interface not a TTL) and I have had problems > > with the MosChip USB-Serial adapter in my test PC in the past. I > > wouldn't reject this series based on me not being able to get it > > working, the important thing for me is the default behaviour at the > > standard baudrate which is good. > > You need to choose speed which is supported by both armada board and > your computer. Armada boards support speeds calculated by formula: > speed = TCLK / ( 16 * d ) > where d is 16-bit integer number. So for A385 board with 250 MHz TCLK > you can set speeds from above formula +/- 30%. Tested were: > 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, > 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, > 2000000, 2500000, 3125000, 4000000, 5150000. > If you have a board with different TCLK you obviously need to use > different baudrates. > > But it is possible that your computer does not support these speeds. > E.g. more chinese USB TTL adapters have base clock 3 MHz and so they > could not support 3150000 or 2500000 speeds. > > > One usability thing I'd like to see is retaining support for -t (I use > > that quite a lot when recovering a system). Ideally we'd still be able > > to drop into the console at 115200 once the download is complete. > > -t is fully supported, I'm using -t with -B 5150000 and it is working > fine. After successful download, speed on both A38x and host computer is > changed back to the value 115200. >
Ah I misread the man page update >