Re: [U-Boot] [ELDK] U-Boot default CONFIG_AUTOBOOT_DELAY_STR
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
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
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
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@usgs.gov
with regards, pekon
participants (4)
-
Gupta, Pekon -
Karen Shaeffer -
Larry Baker -
Wolfgang Denk