[U-Boot] [PATCH] tools: kwboot: Make kwboot more robust on a38x

[Chris Packham]

On Fri, Aug 17, 2018 at 11:06 AM Chris Packham <judge.packham at gmail.com> wrote:
>
> On Fri, Aug 17, 2018 at 11:01 AM Chris Packham <judge.packham at gmail.com> wrote:
> >
> > On Thu, Aug 16, 2018 at 8:38 PM Baruch Siach <baruch at tkos.co.il> wrote:
> > >
> > > Hi Chris,
> > >
> > > Chris Packham writes:
> > > > On Tue, Aug 14, 2018 at 3:25 AM Baruch Siach <baruch at tkos.co.il> wrote:
> > > >> From: Jon Nettleton <jon at solid-run.com>
> > > >>
> > > >> This patch accomplishes 2 things to make the kwboot procedure
> > > >> on the a38x more reliable.
> > > >>
> > > >> 1)  We fill the tty with 1K of the magic bootparam.  This helps
> > > >> with the timing of where the microcode picks up in the read of
> > > >> the line to ensure we actually catch the break to go into recovery
> > > >> mode
> > > >>
> > > >> 2)  Before starting the xmodem transfer we sleep for 2 seconds
> > > >> and then flush the line.  This allows all the magic bootparam
> > > >> to be flushed from the line and makes the xmodem transfer reliable
> > > >> and removes the Bad message failures.
> > > >>
> > > >> Signed-off-by: Jon Nettleton <jon at solid-run.com>
> > > >> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> > > >> ---
> > > >
> > > > Reviewed-by: Chris Packham <judge.packham at gmail.com>
> > >
> > > Thanks.
> > >
> > > > Lately I haven't had much luck with using kwboot on a38x. I seem to be
> > > > able to get the spl to boot from uart (even better now thanks to this
> > > > patch) but the next stage still loads from SPI. I haven't been brave
> > > > enough to blank a board to see if that changes behaviour. Are your
> > > > experiences any different? I'm wondering if there is something we need
> > > > to do in the SPL to figure out that we need to load the next stage via
> > > > xmodem.
> > >
> > > It works for me here on the Clearfog.
> > >
> > > The code that determines the seconds stage load device is in
> > > arch/arm/mach-mvebu/spl.c:get_boot_device(). Does the code there get it
> > > right? What do you read from CONFIG_BOOTROM_ERR_REG?
> > >
> >
> > I get the following from enabling the debug
> >
> > BOOTROM_REG=0x63001000 boot_device=0x0
> > SAR_REG=0xcb20b342 boot_device=0x34
> > BOOTROM_REG=0x63001000 boot_device=0x0
> > SAR_REG=0xcb20b342 boot_device=0x34
> >
> > The strapping is for SPI so the second part isn't surprising.
>
> (sorry hit send too soon)
>
> If I hard code get_boot_device() to return BOOT_DEVICE_UART then
> kwboot works for me.

And if I revert commit e83e2b390038 ("arm: mvebu: fix boot from UART
when in fallback mode") it works properly.