Hi, On 18 January 2016 at 23:46, Craig McQueen <craig.mcqu...@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.mcqu...@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.mcqu...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot