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

[Chris Packham]

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.