[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Craig McQueen]

This is to avoid the boot sequence halting due to initial "junk"
received on serial input.

Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
---
I have found that on the BeagleBone Black, U-Boot occasionally halts at 
the U-Boot prompt at boot-up, whether power-up, warm external 
reset or software reset. I have seen other people report the same issue.

This seems to be due to U-Boot receiving "junk" data on the serial 
console. The BeagleBone Black has a pull-down resistor which was 
apparently added to try to mitigate this issue, but it doesn't entirely 
fix it.

 common/autoboot.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index c11fb31..3ab51d9 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -230,19 +230,29 @@ static int abortboot_normal(int bootdelay)
 		printf("Hit any key to stop autoboot: %2d ", bootdelay);
 #endif
 
-#if defined CONFIG_ZERO_BOOTDELAY_CHECK
 	/*
-	 * Check if key already pressed
-	 * Don't check if bootdelay < 0
+	 * Flush any pending input key presses.
+	 * On some systems, there might be some junk input.
+	 * No need if bootdelay < 0.
 	 */
 	if (bootdelay >= 0) {
-		if (tstc()) {	/* we got a key press	*/
+		ts = get_timer(0);
+		while (tstc()) {	/* we got a key press	*/
 			(void) getc();  /* consume input	*/
+#if defined CONFIG_ZERO_BOOTDELAY_CHECK
 			puts("\b\b\b 0");
 			abort = 1;	/* don't auto boot	*/
+			break;
+#else
+			/*
+			 * Sanity check just to avoid infinite loop. It should
+			 * never happen if hardware is working as expected.
+			 */
+			if (get_timer(ts) >= 1000)
+				break;
+#endif
 		}
 	}
-#endif
 
 	while ((bootdelay > 0) && (!abort)) {
 		--bootdelay;
-- 
2.1.4

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Simon Glass]

Hi Craig,

On 20 December 2015 at 19:07, Craig McQueen
<craig.mcqueen@innerrange.com> wrote:
> This is to avoid the boot sequence halting due to initial "junk"
> received on serial input.
>
> Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> ---
> I have found that on the BeagleBone Black, U-Boot occasionally halts at
> the U-Boot prompt at boot-up, whether power-up, warm external
> reset or software reset. I have seen other people report the same issue.
>
> This seems to be due to U-Boot receiving "junk" data on the serial
> console. The BeagleBone Black has a pull-down resistor which was
> apparently added to try to mitigate this issue, but it doesn't entirely
> fix it.

I wonder if this can be fixed for that board only?

One option might be to clear out the UART input buffer when the driver
is probed. You could copy the TI maintainer also, for comments.

At present I can press a key before U-Boot comes up and it will be
picked up. I suspect that this patch would break that, although I have
not tested it.

>
>  common/autoboot.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/common/autoboot.c b/common/autoboot.c
> index c11fb31..3ab51d9 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -230,19 +230,29 @@ static int abortboot_normal(int bootdelay)
>                 printf("Hit any key to stop autoboot: %2d ", bootdelay);
>  #endif
>
> -#if defined CONFIG_ZERO_BOOTDELAY_CHECK
>         /*
> -        * Check if key already pressed
> -        * Don't check if bootdelay < 0
> +        * Flush any pending input key presses.
> +        * On some systems, there might be some junk input.
> +        * No need if bootdelay < 0.
>          */
>         if (bootdelay >= 0) {
> -               if (tstc()) {   /* we got a key press   */
> +               ts = get_timer(0);
> +               while (tstc()) {        /* we got a key press   */
>                         (void) getc();  /* consume input        */
> +#if defined CONFIG_ZERO_BOOTDELAY_CHECK
>                         puts("\b\b\b 0");
>                         abort = 1;      /* don't auto boot      */
> +                       break;
> +#else
> +                       /*
> +                        * Sanity check just to avoid infinite loop. It should
> +                        * never happen if hardware is working as expected.
> +                        */
> +                       if (get_timer(ts) >= 1000)
> +                               break;
> +#endif
>                 }
>         }
> -#endif
>
>         while ((bootdelay > 0) && (!abort)) {
>                 --bootdelay;
> --
> 2.1.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Regards,
Simon

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Tom Rini]

On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> Hi Craig,
> 
> On 20 December 2015 at 19:07, Craig McQueen
> <craig.mcqueen@innerrange.com> wrote:
> > This is to avoid the boot sequence halting due to initial "junk"
> > received on serial input.
> >
> > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > ---
> > I have found that on the BeagleBone Black, U-Boot occasionally halts at
> > the U-Boot prompt at boot-up, whether power-up, warm external
> > reset or software reset. I have seen other people report the same issue.
> >
> > This seems to be due to U-Boot receiving "junk" data on the serial
> > console. The BeagleBone Black has a pull-down resistor which was
> > apparently added to try to mitigate this issue, but it doesn't entirely
> > fix it.
> 
> I wonder if this can be fixed for that board only?

No, and it's not -exactly- a that board only problem.  It's a HW design
issue that can show up elsewhere too.  I _think_ however in this case
the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as
that's one of the reason various other boards use that set of options.

I would suggest bringing this up on the beaglebone list to see what the
various people that ship and support these boards think, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160114/180927de/attachment.sig>

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Robert Nelson]

On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <trini@konsulko.com> wrote:

> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> > Hi Craig,
> >
> > On 20 December 2015 at 19:07, Craig McQueen
> > <craig.mcqueen@innerrange.com> wrote:
> > > This is to avoid the boot sequence halting due to initial "junk"
> > > received on serial input.
> > >
> > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > > ---
> > > I have found that on the BeagleBone Black, U-Boot occasionally halts at
> > > the U-Boot prompt at boot-up, whether power-up, warm external
> > > reset or software reset. I have seen other people report the same
> issue.
> > >
> > > This seems to be due to U-Boot receiving "junk" data on the serial
> > > console. The BeagleBone Black has a pull-down resistor which was
> > > apparently added to try to mitigate this issue, but it doesn't entirely
> > > fix it.
> >
> > I wonder if this can be fixed for that board only?
>
> No, and it's not -exactly- a that board only problem.  It's a HW design
> issue that can show up elsewhere too.  I _think_ however in this case
> the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as
> that's one of the reason various other boards use that set of options.
>
> I would suggest bringing this up on the beaglebone list to see what the
> various people that ship and support these boards think, thanks!
>

I actually enabled this feature this week by default for beagleboard.org:

diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 27cb881..8699953 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
-CONFIG_SYS_EXTRA_OPTIONS="NAND"
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
+CONFIG_AUTOBOOT_DELAY_STR="d"
+CONFIG_AUTOBOOT_STOP_STR=" "
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y

It'll take time to replace older images but on target users can just:

cd /opt/scripts/tools/developers/
git pull
sudo ./update_bootloader.sh

U-Boot SPL 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31)
Trying to boot from MMC
bad magic


U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build:
jenkins-github_Bootloader-Builder-313

       Watchdog enabled
I2C:   ready
DRAM:  512 MiB
Reset Source: Global external warm reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=>


Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Tom Rini]

On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote:
> On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> > > Hi Craig,
> > >
> > > On 20 December 2015 at 19:07, Craig McQueen
> > > <craig.mcqueen@innerrange.com> wrote:
> > > > This is to avoid the boot sequence halting due to initial "junk"
> > > > received on serial input.
> > > >
> > > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > > > ---
> > > > I have found that on the BeagleBone Black, U-Boot occasionally halts at
> > > > the U-Boot prompt at boot-up, whether power-up, warm external
> > > > reset or software reset. I have seen other people report the same
> > issue.
> > > >
> > > > This seems to be due to U-Boot receiving "junk" data on the serial
> > > > console. The BeagleBone Black has a pull-down resistor which was
> > > > apparently added to try to mitigate this issue, but it doesn't entirely
> > > > fix it.
> > >
> > > I wonder if this can be fixed for that board only?
> >
> > No, and it's not -exactly- a that board only problem.  It's a HW design
> > issue that can show up elsewhere too.  I _think_ however in this case
> > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as
> > that's one of the reason various other boards use that set of options.
> >
> > I would suggest bringing this up on the beaglebone list to see what the
> > various people that ship and support these boards think, thanks!
> >
> 
> I actually enabled this feature this week by default for beagleboard.org:
> 
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index 27cb881..8699953 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
> -CONFIG_SYS_EXTRA_OPTIONS="NAND"
> +CONFIG_AUTOBOOT_KEYED=y
> +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
> +CONFIG_AUTOBOOT_DELAY_STR="d"
> +CONFIG_AUTOBOOT_STOP_STR=" "
>  # CONFIG_CMD_IMLS is not set
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
> 
> It'll take time to replace older images but on target users can just:
> 
> cd /opt/scripts/tools/developers/
> git pull
> sudo ./update_bootloader.sh
> 
> U-Boot SPL 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31)
> Trying to boot from MMC
> bad magic
> 
> 
> U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build:
> jenkins-github_Bootloader-Builder-313
> 
>        Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> Reset Source: Global external warm reset has occurred.
> Reset Source: Power-on reset has occurred.
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
> 
> Net:   <ethaddr> not set. Validating first E-fuse MAC
> cpsw, usb_ether
> Press SPACE to abort autoboot in 2 seconds
> =>

Space eh? OK.  Now would be the time to push this upstream as the merge
window just opened :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160114/eda9797c/attachment.sig>

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Robert Nelson]

On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini <trini@konsulko.com> wrote:

> On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote:
> > On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> > > > Hi Craig,
> > > >
> > > > On 20 December 2015 at 19:07, Craig McQueen
> > > > <craig.mcqueen@innerrange.com> wrote:
> > > > > This is to avoid the boot sequence halting due to initial "junk"
> > > > > received on serial input.
> > > > >
> > > > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > > > > ---
> > > > > I have found that on the BeagleBone Black, U-Boot occasionally
> halts at
> > > > > the U-Boot prompt at boot-up, whether power-up, warm external
> > > > > reset or software reset. I have seen other people report the same
> > > issue.
> > > > >
> > > > > This seems to be due to U-Boot receiving "junk" data on the serial
> > > > > console. The BeagleBone Black has a pull-down resistor which was
> > > > > apparently added to try to mitigate this issue, but it doesn't
> entirely
> > > > > fix it.
> > > >
> > > > I wonder if this can be fixed for that board only?
> > >
> > > No, and it's not -exactly- a that board only problem.  It's a HW design
> > > issue that can show up elsewhere too.  I _think_ however in this case
> > > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC
> as
> > > that's one of the reason various other boards use that set of options.
> > >
> > > I would suggest bringing this up on the beaglebone list to see what the
> > > various people that ship and support these boards think, thanks!
> > >
> >
> > I actually enabled this feature this week by default for beagleboard.org
> :
> >
> > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > index 27cb881..8699953 100644
> > --- a/configs/am335x_evm_defconfig
> > +++ b/configs/am335x_evm_defconfig
> > @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y
> >  CONFIG_SPL_STACK_R_ADDR=0x82000000
> >  CONFIG_SPL=y
> >  CONFIG_SPL_STACK_R=y
> > -CONFIG_SYS_EXTRA_OPTIONS="NAND"
> > +CONFIG_AUTOBOOT_KEYED=y
> > +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
> > +CONFIG_AUTOBOOT_DELAY_STR="d"
> > +CONFIG_AUTOBOOT_STOP_STR=" "
> >  # CONFIG_CMD_IMLS is not set
> >  # CONFIG_CMD_FLASH is not set
> >  CONFIG_CMD_GPIO=y
> >
> > It'll take time to replace older images but on target users can just:
> >
> > cd /opt/scripts/tools/developers/
> > git pull
> > sudo ./update_bootloader.sh
> >
> > U-Boot SPL 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31)
> > Trying to boot from MMC
> > bad magic
> >
> >
> > U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build:
> > jenkins-github_Bootloader-Builder-313
> >
> >        Watchdog enabled
> > I2C:   ready
> > DRAM:  512 MiB
> > Reset Source: Global external warm reset has occurred.
> > Reset Source: Power-on reset has occurred.
> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > Using default environment
> >
> > Net:   <ethaddr> not set. Validating first E-fuse MAC
> > cpsw, usb_ether
> > Press SPACE to abort autoboot in 2 seconds
> > =>
>
> Space eh? OK.  Now would be the time to push this upstream as the merge
> window just opened :)
>

That seemed like the most common when i looked at it..

grep -R "AUTOBOOT_PROMPT" configs/*defconfig

Do you want me to hit all 3 bbb related configs?

beagleboard.org uses: am335x_evm_defconfig

I know some users use:
am335x_boneblack_defconfig
am335x_boneblack_vboot_defconfig

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Tom Rini]

On Thu, Jan 14, 2016 at 11:56:29AM -0600, Robert Nelson wrote:
> On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote:
> > > On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> > > > > Hi Craig,
> > > > >
> > > > > On 20 December 2015 at 19:07, Craig McQueen
> > > > > <craig.mcqueen@innerrange.com> wrote:
> > > > > > This is to avoid the boot sequence halting due to initial "junk"
> > > > > > received on serial input.
> > > > > >
> > > > > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > > > > > ---
> > > > > > I have found that on the BeagleBone Black, U-Boot occasionally
> > halts at
> > > > > > the U-Boot prompt at boot-up, whether power-up, warm external
> > > > > > reset or software reset. I have seen other people report the same
> > > > issue.
> > > > > >
> > > > > > This seems to be due to U-Boot receiving "junk" data on the serial
> > > > > > console. The BeagleBone Black has a pull-down resistor which was
> > > > > > apparently added to try to mitigate this issue, but it doesn't
> > entirely
> > > > > > fix it.
> > > > >
> > > > > I wonder if this can be fixed for that board only?
> > > >
> > > > No, and it's not -exactly- a that board only problem.  It's a HW design
> > > > issue that can show up elsewhere too.  I _think_ however in this case
> > > > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC
> > as
> > > > that's one of the reason various other boards use that set of options.
> > > >
> > > > I would suggest bringing this up on the beaglebone list to see what the
> > > > various people that ship and support these boards think, thanks!
> > > >
> > >
> > > I actually enabled this feature this week by default for beagleboard.org
> > :
> > >
> > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > > index 27cb881..8699953 100644
> > > --- a/configs/am335x_evm_defconfig
> > > +++ b/configs/am335x_evm_defconfig
> > > @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y
> > >  CONFIG_SPL_STACK_R_ADDR=0x82000000
> > >  CONFIG_SPL=y
> > >  CONFIG_SPL_STACK_R=y
> > > -CONFIG_SYS_EXTRA_OPTIONS="NAND"
> > > +CONFIG_AUTOBOOT_KEYED=y
> > > +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
> > > +CONFIG_AUTOBOOT_DELAY_STR="d"
> > > +CONFIG_AUTOBOOT_STOP_STR=" "
> > >  # CONFIG_CMD_IMLS is not set
> > >  # CONFIG_CMD_FLASH is not set
> > >  CONFIG_CMD_GPIO=y
> > >
> > > It'll take time to replace older images but on target users can just:
> > >
> > > cd /opt/scripts/tools/developers/
> > > git pull
> > > sudo ./update_bootloader.sh
> > >
> > > U-Boot SPL 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31)
> > > Trying to boot from MMC
> > > bad magic
> > >
> > >
> > > U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build:
> > > jenkins-github_Bootloader-Builder-313
> > >
> > >        Watchdog enabled
> > > I2C:   ready
> > > DRAM:  512 MiB
> > > Reset Source: Global external warm reset has occurred.
> > > Reset Source: Power-on reset has occurred.
> > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > Using default environment
> > >
> > > Net:   <ethaddr> not set. Validating first E-fuse MAC
> > > cpsw, usb_ether
> > > Press SPACE to abort autoboot in 2 seconds
> > > =>
> >
> > Space eh? OK.  Now would be the time to push this upstream as the merge
> > window just opened :)
> >
> 
> That seemed like the most common when i looked at it..
> 
> grep -R "AUTOBOOT_PROMPT" configs/*defconfig
> 
> Do you want me to hit all 3 bbb related configs?
> 
> beagleboard.org uses: am335x_evm_defconfig
> 
> I know some users use:
> am335x_boneblack_defconfig
> am335x_boneblack_vboot_defconfig

Yeah, hit those two as well please.  We can ignore the NOR ones since
people with a NOR cape likely have their UART hooked up anyhow and
that's iirc when the junk is a big problem.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160114/e4abdbbc/attachment.sig>

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Craig McQueen]

> Tom Rini wrote:
> 
> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
> > Hi Craig,
> >
> > On 20 December 2015 at 19:07, Craig McQueen
> > <craig.mcqueen@innerrange.com> wrote:
> > > This is to avoid the boot sequence halting due to initial "junk"
> > > received on serial input.
> > >
> > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
> > > ---
> > > I have found that on the BeagleBone Black, U-Boot occasionally halts
> > > at the U-Boot prompt at boot-up, whether power-up, warm external
> > > reset or software reset. I have seen other people report the same issue.
> > >
> > > This seems to be due to U-Boot receiving "junk" data on the serial
> > > console. The BeagleBone Black has a pull-down resistor which was
> > > apparently added to try to mitigate this issue, but it doesn't
> > > entirely fix it.
> >
> > I wonder if this can be fixed for that board only?
> 
> No, and it's not -exactly- a that board only problem.  It's a HW design issue
> that can show up elsewhere too.  I _think_ however in this case the answer
> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's
> one of the reason various other boards use that set of options.
> 
> I would suggest bringing this up on the beaglebone list to see what the
> various people that ship and support these boards think, thanks!

Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around of the problem, rather than a fix of the root-cause. But maybe that's just my opinion. Simon Glass' suggestion (clear out the UART input buffer when the driver is probed) sounded reasonable, but I haven't tried it.

I think BeagleBone Black definitely needs _some_ sort of fix -- currently BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, then please implement a suitable alternative.

It could be worth checking the UART's error flags (break, framing error, parity error, etc), and ignoring a byte with any error. But it looks as though the U-Boot code would need more extensive changes to support that.

On what BeagleBone list do you suggest this should be brought up?

-- 
Craig McQueen

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Simon Glass]

Hi,

On 18 January 2016 at 23:46, Craig McQueen <craig.mcqueen@innerrange.com> wrote:
>> Tom Rini wrote:
>>
>> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
>> > Hi Craig,
>> >
>> > On 20 December 2015 at 19:07, Craig McQueen
>> > <craig.mcqueen@innerrange.com> wrote:
>> > > This is to avoid the boot sequence halting due to initial "junk"
>> > > received on serial input.
>> > >
>> > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
>> > > ---
>> > > I have found that on the BeagleBone Black, U-Boot occasionally halts
>> > > at the U-Boot prompt at boot-up, whether power-up, warm external
>> > > reset or software reset. I have seen other people report the same issue.
>> > >
>> > > This seems to be due to U-Boot receiving "junk" data on the serial
>> > > console. The BeagleBone Black has a pull-down resistor which was
>> > > apparently added to try to mitigate this issue, but it doesn't
>> > > entirely fix it.
>> >
>> > I wonder if this can be fixed for that board only?
>>
>> No, and it's not -exactly- a that board only problem.  It's a HW design issue
>> that can show up elsewhere too.  I _think_ however in this case the answer
>> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's
>> one of the reason various other boards use that set of options.
>>
>> I would suggest bringing this up on the beaglebone list to see what the
>> various people that ship and support these boards think, thanks!
>
> Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around of the problem, rather than a fix of the root-cause. But maybe that's just my opinion. Simon Glass' suggestion (clear out the UART input buffer when the driver is probed) sounded reasonable, but I haven't tried it.

Since it seems like a hardware bug, we can only have a workaround. A
real fix would involve fixing the root cause, i.e. fixing the
hardware.

>
> I think BeagleBone Black definitely needs _some_ sort of fix -- currently BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, then please implement a suitable alternative.

How about what Tom suggested? Ctrl-C is not likely to happen by accident.

>
> It could be worth checking the UART's error flags (break, framing error, parity error, etc), and ignoring a byte with any error. But it looks as though the U-Boot code would need more extensive changes to support that.

I'm not sure. You could add a Kconfig option to flush the UART on probe().

>
> On what BeagleBone list do you suggest this should be brought up?
>
> --
> Craig McQueen
>

Regads,
Simon

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Robert Nelson]

On Tue, Jan 19, 2016 at 10:35 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On 18 January 2016 at 23:46, Craig McQueen <craig.mcqueen@innerrange.com> wrote:
>>> Tom Rini wrote:
>>>
>>> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote:
>>> > Hi Craig,
>>> >
>>> > On 20 December 2015 at 19:07, Craig McQueen
>>> > <craig.mcqueen@innerrange.com> wrote:
>>> > > This is to avoid the boot sequence halting due to initial "junk"
>>> > > received on serial input.
>>> > >
>>> > > Signed-off-by: Craig McQueen <craig.mcqueen@innerrange.com>
>>> > > ---
>>> > > I have found that on the BeagleBone Black, U-Boot occasionally halts
>>> > > at the U-Boot prompt at boot-up, whether power-up, warm external
>>> > > reset or software reset. I have seen other people report the same issue.
>>> > >
>>> > > This seems to be due to U-Boot receiving "junk" data on the serial
>>> > > console. The BeagleBone Black has a pull-down resistor which was
>>> > > apparently added to try to mitigate this issue, but it doesn't
>>> > > entirely fix it.
>>> >
>>> > I wonder if this can be fixed for that board only?
>>>
>>> No, and it's not -exactly- a that board only problem.  It's a HW design issue
>>> that can show up elsewhere too.  I _think_ however in this case the answer
>>> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's
>>> one of the reason various other boards use that set of options.
>>>
>>> I would suggest bringing this up on the beaglebone list to see what the
>>> various people that ship and support these boards think, thanks!
>>
>> Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around of the problem, rather than a fix of the root-cause. But maybe that's just my opinion. Simon Glass' suggestion (clear out the UART input buffer when the driver is probed) sounded reasonable, but I haven't tried it.
>
> Since it seems like a hardware bug, we can only have a workaround. A
> real fix would involve fixing the root cause, i.e. fixing the
> hardware.
>
>>
>> I think BeagleBone Black definitely needs _some_ sort of fix -- currently BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, then please implement a suitable alternative.
>
> How about what Tom suggested? Ctrl-C is not likely to happen by accident.

This should be good enough for everyone, it'll look for an exact match
over serial "<space>" otherwise it'll ignore everything else:

http://lists.denx.de/pipermail/u-boot/2016-January/241286.html

Regards,

-- 
Robert Nelson
https://rcn-ee.com/