Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Tue, Jan 19, 2016 at 10:35 PM, Simon Glass wrote: > Hi, > > On 18 January 2016 at 23:46, Craig McQueen > 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 >>> > wrote: >>> > > This is to avoid the boot sequence halting due to initial "junk" >>> > > received on serial input. >>> > > >>> > > Signed-off-by: Craig McQueen >>> > > --- >>> > > 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 "" otherwise it'll ignore everything else: http://lists.denx.de/pipermail/u-boot/2016-January/241286.html Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
Hi, On 18 January 2016 at 23:46, Craig McQueen 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 >> > wrote: >> > > This is to avoid the boot sequence halting due to initial "junk" >> > > received on serial input. >> > > >> > > Signed-off-by: Craig McQueen >> > > --- >> > > 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
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
> 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 > > wrote: > > > This is to avoid the boot sequence halting due to initial "junk" > > > received on serial input. > > > > > > Signed-off-by: Craig McQueen > > > --- > > > 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:56:29AM -0600, Robert Nelson wrote: > On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini 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 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 > > > > > wrote: > > > > > > This is to avoid the boot sequence halting due to initial "junk" > > > > > > received on serial input. > > > > > > > > > > > > Signed-off-by: Craig McQueen > > > > > > --- > > > > > > 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=0x8200 > > > 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-1-g4eb802e (Jan 13 2016 - 11:14:31) > > > Trying to boot from MMC > > > bad magic > > > > > > > > > U-Boot 2016.01-1-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: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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini 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 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 > > > > wrote: > > > > > This is to avoid the boot sequence halting due to initial "junk" > > > > > received on serial input. > > > > > > > > > > Signed-off-by: Craig McQueen > > > > > --- > > > > > 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=0x8200 > > 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-1-g4eb802e (Jan 13 2016 - 11:14:31) > > Trying to boot from MMC > > bad magic > > > > > > U-Boot 2016.01-1-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: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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote: > On Thu, Jan 14, 2016 at 11:31 AM, 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 > > > wrote: > > > > This is to avoid the boot sequence halting due to initial "junk" > > > > received on serial input. > > > > > > > > Signed-off-by: Craig McQueen > > > > --- > > > > 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=0x8200 > 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-1-g4eb802e (Jan 13 2016 - 11:14:31) > Trying to boot from MMC > bad magic > > > U-Boot 2016.01-1-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: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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:31 AM, 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 > > wrote: > > > This is to avoid the boot sequence halting due to initial "junk" > > > received on serial input. > > > > > > Signed-off-by: Craig McQueen > > > --- > > > 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=0x8200 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-1-g4eb802e (Jan 13 2016 - 11:14:31) Trying to boot from MMC bad magic U-Boot 2016.01-1-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: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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: > Hi Craig, > > On 20 December 2015 at 19:07, Craig McQueen > wrote: > > This is to avoid the boot sequence halting due to initial "junk" > > received on serial input. > > > > Signed-off-by: Craig McQueen > > --- > > 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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
Hi Craig,
On 20 December 2015 at 19:07, Craig McQueen
wrote:
> This is to avoid the boot sequence halting due to initial "junk"
> received on serial input.
>
> Signed-off-by: Craig McQueen
> ---
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
This is to avoid the boot sequence halting due to initial "junk"
received on serial input.
Signed-off-by: Craig McQueen
---
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
