[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 at 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