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

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

[Baruch Siach]

From: Jon Nettleton <jon@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@solid-run.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 tools/kwboot.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 50ae2b4b77b1..4be094c9c8d8 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -286,6 +286,7 @@ kwboot_bootmsg(int tty, void *msg)
 {
 	int rc;
 	char c;
+	int count;
 
 	if (msg == NULL)
 		kwboot_printv("Please reboot the target into UART boot mode...");
@@ -297,10 +298,12 @@ kwboot_bootmsg(int tty, void *msg)
 		if (rc)
 			break;
 
-		rc = kwboot_tty_send(tty, msg, 8);
-		if (rc) {
-			usleep(msg_req_delay * 1000);
-			continue;
+		for (count = 0; count < 128; count++) {
+			rc = kwboot_tty_send(tty, msg, 8);
+			if (rc) {
+				usleep(msg_req_delay * 1000);
+				continue;
+			}
 		}
 
 		rc = kwboot_tty_recv(tty, &c, 1, msg_rsp_timeo);
@@ -426,6 +429,9 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
 
 	kwboot_printv("Sending boot image...\n");
 
+	sleep(2); /* flush isn't effective without it */
+	tcflush(tty, TCIOFLUSH);
+
 	do {
 		struct kwboot_block block;
 		int n;
-- 
2.18.0

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

[Chris Packham]

Hi Baruch, Jon,

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.
>
> 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@solid-run.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---

Reviewed-by: Chris Packham <judge.packham@gmail.com>

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.

>  tools/kwboot.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index 50ae2b4b77b1..4be094c9c8d8 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -286,6 +286,7 @@ kwboot_bootmsg(int tty, void *msg)
>  {
>         int rc;
>         char c;
> +       int count;
>
>         if (msg == NULL)
>                 kwboot_printv("Please reboot the target into UART boot mode...");
> @@ -297,10 +298,12 @@ kwboot_bootmsg(int tty, void *msg)
>                 if (rc)
>                         break;
>
> -               rc = kwboot_tty_send(tty, msg, 8);
> -               if (rc) {
> -                       usleep(msg_req_delay * 1000);
> -                       continue;
> +               for (count = 0; count < 128; count++) {
> +                       rc = kwboot_tty_send(tty, msg, 8);
> +                       if (rc) {
> +                               usleep(msg_req_delay * 1000);
> +                               continue;
> +                       }
>                 }
>
>                 rc = kwboot_tty_recv(tty, &c, 1, msg_rsp_timeo);
> @@ -426,6 +429,9 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
>
>         kwboot_printv("Sending boot image...\n");
>
> +       sleep(2); /* flush isn't effective without it */
> +       tcflush(tty, TCIOFLUSH);
> +
>         do {
>                 struct kwboot_block block;
>                 int n;
> --


> 2.18.0
>

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

[Baruch Siach]

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.
>>
>> 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@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?

baruch

>>  tools/kwboot.c | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/kwboot.c b/tools/kwboot.c
>> index 50ae2b4b77b1..4be094c9c8d8 100644
>> --- a/tools/kwboot.c
>> +++ b/tools/kwboot.c
>> @@ -286,6 +286,7 @@ kwboot_bootmsg(int tty, void *msg)
>>  {
>>         int rc;
>>         char c;
>> +       int count;
>>
>>         if (msg == NULL)
>>                 kwboot_printv("Please reboot the target into UART boot mode...");
>> @@ -297,10 +298,12 @@ kwboot_bootmsg(int tty, void *msg)
>>                 if (rc)
>>                         break;
>>
>> -               rc = kwboot_tty_send(tty, msg, 8);
>> -               if (rc) {
>> -                       usleep(msg_req_delay * 1000);
>> -                       continue;
>> +               for (count = 0; count < 128; count++) {
>> +                       rc = kwboot_tty_send(tty, msg, 8);
>> +                       if (rc) {
>> +                               usleep(msg_req_delay * 1000);
>> +                               continue;
>> +                       }
>>                 }
>>
>>                 rc = kwboot_tty_recv(tty, &c, 1, msg_rsp_timeo);
>> @@ -426,6 +429,9 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
>>
>>         kwboot_printv("Sending boot image...\n");
>>
>> +       sleep(2); /* flush isn't effective without it */
>> +       tcflush(tty, TCIOFLUSH);
>> +
>>         do {
>>                 struct kwboot_block block;
>>                 int n;

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

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

[Chris Packham]

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.
> >>
> >> 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@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.

[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@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.
> > >>
> > >> 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@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.

[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@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.
> > > >>
> > > >> 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@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.

[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@gmail.com> wrote:
>
> 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.
> > > > >>
> > > > >> 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@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.

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.

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

[Chris Packham]

On Fri, Aug 17, 2018 at 8:11 PM Jon Nettleton <jon@solid-run.com> wrote:
>
> On Fri, Aug 17, 2018 at 1:22 AM Chris Packham <judge.packham@gmail.com> wrote:
> >
> > 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.
> > > > > >>
> > > > > >> 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@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.
>
> 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.

That's certainly what Marvell's USP does. But I find it a pain because
you have to remember to load the right image and you waste so much
time sending an image configured for spi over xmodem only to realise
you copied the wrong one. Or you brick a board by writing the UART
version into flash.I like the kwboot method of patching the image on
the fly.

I think the real issue I was experiencing is that there are 2
different behaviours depending on whether your intercepting a normal
boot. Or bringing up a blank board. I've just sent a series to deal
with this http://patchwork.ozlabs.org/patch/958704/ (I got your main
just after sending it, I'll include you in the Cc if there is a
re-roll).

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

[Jon Nettleton]

Took a look Chris, and looks fine.

I would like to note we will have a patchset coming to mainline that
adds bubt support to the a38x series.  You can get an overview of the
initial changes here.
https://github.com/SolidRun/u-boot/commits/v2018.01-solidrun-a38x/cmd/mvebu

Some of them are specific to other patches in our tree that we aren't
sure about mainlining such as naming the final image after the
intended boot target it is built for.

Specifically I have added boot mode selection verification of the
image to be written in this commit.
https://github.com/SolidRun/u-boot/commit/6278dfa518ab4591494e17c5d4d1d9477c22e39f#diff-c63156ce279617bc2b2c5fe8cd299c43
In this case when using bubt to flash an image it is impossible to
brick a machine by writing the incorrect image to the incorrect boot
medium.
On Fri, Aug 17, 2018 at 10:58 AM Chris Packham <judge.packham@gmail.com> wrote:
>
> On Fri, Aug 17, 2018 at 8:11 PM Jon Nettleton <jon@solid-run.com> wrote:
> >
> > On Fri, Aug 17, 2018 at 1:22 AM Chris Packham <judge.packham@gmail.com> wrote:
> > >
> > > 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.
> > > > > > >>
> > > > > > >> 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@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.
> >
> > 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.
>
> That's certainly what Marvell's USP does. But I find it a pain because
> you have to remember to load the right image and you waste so much
> time sending an image configured for spi over xmodem only to realise
> you copied the wrong one. Or you brick a board by writing the UART
> version into flash.I like the kwboot method of patching the image on
> the fly.
>
> I think the real issue I was experiencing is that there are 2
> different behaviours depending on whether your intercepting a normal
> boot. Or bringing up a blank board. I've just sent a series to deal
> with this http://patchwork.ozlabs.org/patch/958704/ (I got your main
> just after sending it, I'll include you in the Cc if there is a
> re-roll).

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

[Willy Tarreau]

Hi,

On Thu, Aug 16, 2018 at 07:59:58PM +1200, Chris Packham wrote:
> 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.

FWIW, I managed to install my clearfog-base using it, though I don't
remember any particularly bad corner case. I remember about the usual
issue with the SPL being a bit too verbose and breaking the upload but
that's something that already affected prior versions. I think the
current u-boot version had a pause at this moment but I could be wrong,
anyway it used to work for me.

Just my two cents,
Willy

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

[Stefan Roese]

On 13.08.2018 17:24, Baruch Siach wrote:
> From: Jon Nettleton <jon@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@solid-run.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
>   tools/kwboot.c | 14 ++++++++++----
>   1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index 50ae2b4b77b1..4be094c9c8d8 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -286,6 +286,7 @@ kwboot_bootmsg(int tty, void *msg)
>   {
>   	int rc;
>   	char c;
> +	int count;
>   
>   	if (msg == NULL)
>   		kwboot_printv("Please reboot the target into UART boot mode...");
> @@ -297,10 +298,12 @@ kwboot_bootmsg(int tty, void *msg)
>   		if (rc)
>   			break;
>   
> -		rc = kwboot_tty_send(tty, msg, 8);
> -		if (rc) {
> -			usleep(msg_req_delay * 1000);
> -			continue;
> +		for (count = 0; count < 128; count++) {
> +			rc = kwboot_tty_send(tty, msg, 8);
> +			if (rc) {
> +				usleep(msg_req_delay * 1000);
> +				continue;
> +			}
>   		}
>   
>   		rc = kwboot_tty_recv(tty, &c, 1, msg_rsp_timeo);
> @@ -426,6 +429,9 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
>   
>   	kwboot_printv("Sending boot image...\n");
>   
> +	sleep(2); /* flush isn't effective without it */
> +	tcflush(tty, TCIOFLUSH);
> +
>   	do {
>   		struct kwboot_block block;
>   		int n;
> 

Applied to u-boot-marvell/master

Thanks,
Stefan