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

[Jon Nettleton]

On Fri, Aug 17, 2018 at 1:22 AM Chris Packham <judge.packham at gmail.com> wrote:
>
> 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.

Chris,

I see the issue.  Mainline is still missing another patch from our
local tree.  I don't think Baruch has broken it out and submitted it
to mainline yet.  Look at this #ifndef here.

https://github.com/SolidRun/u-boot/blob/v2018.01-solidrun-a38x/arch/arm/mach-mvebu/spl.c#L35

Basically this allows you to specifically build u-boot for UART
recovery and short circuits the detected boot device if it is already
configured.  Please try adding that in and verify that it works for
you.

This also requires u-boot with commit
72c4e67d08fe2389754b4ce874d76b1bbd9fef24 and
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART set in your  .config

Thanks,
Jon

This does bring up the question as to whether Boot Method should be
individual choices and then we build multiple images named for each
boot type rather than requiring an individual build for each boot
type.