[PATCH u-boot-marvell 00/29] kwboot higher baudrate

[Chris Packham]

On Fri, 27 Aug 2021, 8:32 PM Pali Rohár, <pali at 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.behun at nic.cz> wrote:
> > >
> > > On Fri, 27 Aug 2021 13:16:25 +1200
> > > Chris Packham <judge.packham at gmail.com> wrote:
> > >
> > > > On Thu, Aug 26, 2021 at 1:46 AM Marek Behún <marek.behun at 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.glpk@gmx.de/
> > >
> https://patchwork.ozlabs.org/project/uboot/patch/20210817051158.13283-1-xypron.glpk@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

>