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

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,

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

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,

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 Rini wrote:

> Hi Craig,
>
> > 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?

Hi,

Tom Rini wrote:

> Hi Craig,
>
> > 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

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,