[U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[Wolfgang Denk]

Dear Larry,

In message <5070A944-CC27-4388-91E5-78B0792E590C@usgs.gov> you wrote:
> 
> A recent situation has awakened me to a a behavior of U-Boot that maybe should be changed.

U-Boot related questions should better be discussed on the U-Boot
(rather than the ELDK) mailing list.  I'm adding the U-Boot list on
Cc.

> I am experimenting with a BeagleBone Black (BBB) single-board
> computer.  Occasionally when I perform a reboot, the BBB never
> finishes booting Linux.  When I happen to have a console cable
> connected, I see the U-Boot prompt.  This explains why the BBB has not
> booted Linux.  But it is a mystery why U-Boot is waiting for a command
> when I did not request interrupting the autoboot sequence.
> 
> I found many others reporting the same experience -- and no solution.
> Until I found Andrew Glen's 10/28/2013 post at
> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI about
> U-Boot hangs likely due to noise on the UART0 port.  The solution he
> applied was to rebuild U-Boot to require specific text -- "uboot" --
> to interrupt the autoboot sequence.  (BBB have no flash, so there is
> no opportunity to permanently alter any U-Boot environment variables,
> if this is settable.)

You should be able to store the environment on SDCard.

> It occurs to me that this might be a more common occurrence on any
> number of circuit boards.

No, this is in no way a common issue.  If you have any such line noise
on a serial port, you should start looking for hardware (design)
problems.  This is _not_ normal.  IF several boards of a specific
brand show such a problem, then I'm willing to bet that it's caused by
broken  (or simply too cheap) hardware design.

No industrial grade board I've ever seen has any such issues.

> I have used many ARM single-board computers that have U-Boot.  As far
> as I recall, they all prompt "Hit any key to stop autoboot:".  It is
> probably not such a good idea that ANY character can interrupt the
> U-Boot autoboot sequence.  Perhaps the default should be to require an
> unusual character, like F2 or DEL for BIOS.  Or a multi-character
> sequence within a short period of time, like the "+++" to enter
> command mode on the old Hayes modems.

U-Boot allows you to do that, if you really need/want to.

> As I said, this awakening only occurred to me because of my recent
> experience with boot failures.  My realization is that U-Boot could
> probably do a little better job of protecting our (likely unattended,
> embedded) systems with a minimum of change to the code.  I plan to
> make it my practice to #define CONFIG_AUTOBOOT_DELAY_STR.  I'm
> thinking that should probably be the default.

U-Boot allows you such customization.  But I disagree that this should
be the default.  Actually you are just papering over a hardware
problem.  Line noise on a serial port that inserts phantom characters
is something that should be fixed, not ignored.  And on ony well-
behaving hardware the problem that bothers you simply does not exist.

> Thank you for your valuable contributions (U-Boot and more).

You are welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt

[U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[Karen Shaeffer]

On Tue, Jun 17, 2014 at 06:42:52AM +0200, Wolfgang Denk wrote:
> Dear Larry,
> 
> In message <5070A944-CC27-4388-91E5-78B0792E590C@usgs.gov> you wrote:
> > 
> > A recent situation has awakened me to a a behavior of U-Boot that maybe should be changed.
> 
> U-Boot related questions should better be discussed on the U-Boot
> (rather than the ELDK) mailing list.  I'm adding the U-Boot list on
> Cc.
> 
> > I am experimenting with a BeagleBone Black (BBB) single-board
> > computer.  Occasionally when I perform a reboot, the BBB never
> > finishes booting Linux.  When I happen to have a console cable
> > connected, I see the U-Boot prompt.  This explains why the BBB has not
> > booted Linux.  But it is a mystery why U-Boot is waiting for a command
> > when I did not request interrupting the autoboot sequence.
> > 
> > I found many others reporting the same experience -- and no solution.
> > Until I found Andrew Glen's 10/28/2013 post at
> > https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI about
> > U-Boot hangs likely due to noise on the UART0 port.  The solution he
> > applied was to rebuild U-Boot to require specific text -- "uboot" --
> > to interrupt the autoboot sequence.  (BBB have no flash, so there is
> > no opportunity to permanently alter any U-Boot environment variables,
> > if this is settable.)
> 
> You should be able to store the environment on SDCard.
> 
> > It occurs to me that this might be a more common occurrence on any
> > number of circuit boards.
> 
> No, this is in no way a common issue.  If you have any such line noise
> on a serial port, you should start looking for hardware (design)
> problems.  This is _not_ normal.  IF several boards of a specific
> brand show such a problem, then I'm willing to bet that it's caused by
> broken  (or simply too cheap) hardware design.
> 
> No industrial grade board I've ever seen has any such issues.
> 
Hello,
I agree line noise on a serial port is a hardware design problem. But I
have seen such problems on servers in data centers, where there was a lot
of electrical noise coupled into the serial port cable, acting as an
antenna coupling that noise into the serial port terminal. This only
happened on a small percentage of that hardware model's instances in that
lab, but it was fully investigated and was easily repeatable on the
defective hardware. We patched the software to close a related security
issue and documented the potential hardware issue. It wasn't an issue
we cared to engage the hardware vendor about.

enjoy,
Karen
-- 
Karen Shaeffer                 Be aware: If you see an obstacle in your path,
Neuralscape Services           that obstacle is your path.        Zen proverb

[U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[Gupta, Pekon]

Hi Larry,

>From: Wolfgang Denk
>>In message <baker@usgs.gov> wrote:
>>
>> A recent situation has awakened me to a a behavior of U-Boot that maybe should be changed.
>
>U-Boot related questions should better be discussed on the U-Boot
>(rather than the ELDK) mailing list.  I'm adding the U-Boot list on
>Cc.
>
>> I am experimenting with a BeagleBone Black (BBB) single-board
>> computer.  Occasionally when I perform a reboot, the BBB never
>> finishes booting Linux.  When I happen to have a console cable
>> connected, I see the U-Boot prompt.  This explains why the BBB has not
>> booted Linux.  But it is a mystery why U-Boot is waiting for a command
>> when I did not request interrupting the autoboot sequence.
>>
>> I found many others reporting the same experience -- and no solution.
>> Until I found Andrew Glen's 10/28/2013 post at
>> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI about
>> U-Boot hangs likely due to noise on the UART0 port.  The solution he
>> applied was to rebuild U-Boot to require specific text -- "uboot" --
>> to interrupt the autoboot sequence.  (BBB have no flash, so there is
>> no opportunity to permanently alter any U-Boot environment variables,
>> if this is settable.)
>
>You should be able to store the environment on SDCard.
>
>> It occurs to me that this might be a more common occurrence on any
>> number of circuit boards.
>
>No, this is in no way a common issue.  If you have any such line noise
>on a serial port, you should start looking for hardware (design)
>problems.  This is _not_ normal.  IF several boards of a specific
>brand show such a problem, then I'm willing to bet that it's caused by
>broken  (or simply too cheap) hardware design.
>

The fix and issue is given in the same mail as provided by you
...
"I think we've found an issue. As I already mentioned, when an FTDI cable is connected everything works fine. First we thought it could be a grounding problem, but we couldn't found anything. Afterwards we had only the TX and GND signal of the FTDI cable connected, so we could see what the BB sends. We found out, that the BB goes into the U-Boot mode (the mode where you have to hit a key shortly after power up). It seems like that the BB receives something over the RX signal of the FTDI. We think the problem is the pull down resistor of the RX signal. We have changed it to a pull up, since the idle state of the UART is 3.3V, and changed the resistor to 10k instead of 100k. Now everything works fine.

Regards,
duckhunter"
...
There are other responses too on same mail-thread which you can explore. 

with regards, pekon

[U-Boot] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[Larry Baker]

On Jun 16, 2014, at 10:41 PM, Gupta, Pekon wrote:

> Hi Larry,
> 
>> From: Wolfgang Denk
>>> In message <baker@usgs.gov> wrote:
>>> 
>>> A recent situation has awakened me to a a behavior of U-Boot that maybe should be changed.
>> 
>> U-Boot related questions should better be discussed on the U-Boot
>> (rather than the ELDK) mailing list.  I'm adding the U-Boot list on
>> Cc.
>> 
>>> I am experimenting with a BeagleBone Black (BBB) single-board
>>> computer.  Occasionally when I perform a reboot, the BBB never
>>> finishes booting Linux.  When I happen to have a console cable
>>> connected, I see the U-Boot prompt.  This explains why the BBB has not
>>> booted Linux.  But it is a mystery why U-Boot is waiting for a command
>>> when I did not request interrupting the autoboot sequence.
>>> 
>>> I found many others reporting the same experience -- and no solution.
>>> Until I found Andrew Glen's 10/28/2013 post at
>>> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI about
>>> U-Boot hangs likely due to noise on the UART0 port.  The solution he
>>> applied was to rebuild U-Boot to require specific text -- "uboot" --
>>> to interrupt the autoboot sequence.  (BBB have no flash, so there is
>>> no opportunity to permanently alter any U-Boot environment variables,
>>> if this is settable.)
>> 
>> You should be able to store the environment on SDCard.
>> 
>>> It occurs to me that this might be a more common occurrence on any
>>> number of circuit boards.
>> 
>> No, this is in no way a common issue.  If you have any such line noise
>> on a serial port, you should start looking for hardware (design)
>> problems.  This is _not_ normal.  IF several boards of a specific
>> brand show such a problem, then I'm willing to bet that it's caused by
>> broken  (or simply too cheap) hardware design.
>> 
> 
> The fix and issue is given in the same mail as provided by you
> ...
> "I think we've found an issue. As I already mentioned, when an FTDI cable is connected everything works fine. First we thought it could be a grounding problem, but we couldn't found anything. Afterwards we had only the TX and GND signal of the FTDI cable connected, so we could see what the BB sends. We found out, that the BB goes into the U-Boot mode (the mode where you have to hit a key shortly after power up). It seems like that the BB receives something over the RX signal of the FTDI. We think the problem is the pull down resistor of the RX signal. We have changed it to a pull up, since the idle state of the UART is 3.3V, and changed the resistor to 10k instead of 100k. Now everything works fine.
> 
> Regards,
> duckhunter"
> ...
> There are other responses too on same mail-thread which you can explore. 
> 

I experience the unrequested U-Boot prompt even when the FTDI cable is attached.  I saw many suggestions for fixes on various web pages, and none of them seemed to work for everyone that tried them.  The fix to slightly harden U-Boot's behavior worked.

I agree completely with Wolfgang's opinion about either the design or quality of the hardware.  Is this a lower quality hobbyist device?  Perhaps.  It is also affordable, very popular, and very useful.  This is a dedicated (~TTL, not RS-232) console port, not typically exposed to the user of the device, whose sole purpose is to interact directly with the embedded U-Boot and Linux.  Is it really such a good thing that U-Boot is so promiscuous in what it is willing to accept as an invitation to converse?  I think it is good defensive programming to be a bit pickier.  What is the harm?

I do not wish to argue with anyone about it.  I can make the change for myself and I will certainly document the reason I am making the change in my notes.

Thank you for your suggestions.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

> with regards, pekon

[U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR

[Stefano Babic]

Hi Larry,

On 18/06/2014 00:35, Larry Baker wrote:

> 
> I experience the unrequested U-Boot prompt even when the FTDI cable
> is attached.  I saw many suggestions for fixes on various web pages,
> and none of them seemed to work for everyone that tried them.  The
> fix to slightly harden U-Boot's behavior worked.
> 
> I agree completely with Wolfgang's opinion about either the design or
> quality of the hardware.  Is this a lower quality hobbyist device?
> Perhaps.  It is also affordable, very popular, and very useful.  This
> is a dedicated (~TTL, not RS-232) console port, not typically exposed
> to the user of the device, whose sole purpose is to interact directly
> with the embedded U-Boot and Linux.  Is it really such a good thing
> that U-Boot is so promiscuous in what it is willing to accept as an
> invitation to converse?  I think it is good defensive programming to
> be a bit pickier.  What is the harm?
> 
> I do not wish to argue with anyone about it.  I can make the change
> for myself and I will certainly document the reason I am making the
> change in my notes.

The best thing you can do is to send an appropriate patch to u-boot ML
and in CC to the TI Maintainer (Tom Rini), asking for review. Adding
 CONFIG_AUTOBOOT_DELAY_STR change behavior for other boards, too,
because am335x_evm.h is used by several boards, not only BBB. Which
board is running is verified at runtime, see board_is_bone() in
am335x/board.c code. The same hardware issue seems that does not affect
other boards. Maybe you can add a runtime check and change the behavior
only on BBB.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================