| Message ID | 1450663670-29212-1-git-send-email-craig.mcqueen@innerrange.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Regards, Simon
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 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?
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
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,
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;
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(-)