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