On Fri, Aug 17, 2018 at 11:01 AM Chris Packham <[email protected]> wrote: > > On Thu, Aug 16, 2018 at 8:38 PM Baruch Siach <[email protected]> wrote: > > > > Hi Chris, > > > > Chris Packham writes: > > > On Tue, Aug 14, 2018 at 3:25 AM Baruch Siach <[email protected]> wrote: > > >> From: Jon Nettleton <[email protected]> > > >> > > >> 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 <[email protected]> > > >> Signed-off-by: Baruch Siach <[email protected]> > > >> --- > > > > > > Reviewed-by: Chris Packham <[email protected]> > > > > 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. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
