On Fri, Aug 17, 2018 at 11:06 AM Chris Packham judge.packham@gmail.com wrote:
On Fri, Aug 17, 2018 at 11:01 AM Chris Packham judge.packham@gmail.com wrote:
On Thu, Aug 16, 2018 at 8:38 PM Baruch Siach baruch@tkos.co.il wrote:
Hi Chris,
Chris Packham writes:
On Tue, Aug 14, 2018 at 3:25 AM Baruch Siach baruch@tkos.co.il wrote:
From: Jon Nettleton jon@solid-run.com
This patch accomplishes 2 things to make the kwboot procedure on the a38x more reliable.
- 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
- 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@solid-run.com Signed-off-by: Baruch Siach baruch@tkos.co.il
Reviewed-by: Chris Packham judge.packham@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.