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