Hi, Just as a +1 to Andrew's findings: I have done a simple test with two BBBs to verify the presence and fix of the boot issue. The BBB under test had pins 1 and 5 of its UART0 port connected to an FTDI converter cable, which was plugged into the second BBB's USB port. The system reset pin (P9_10) of the BBB under test was wired to a GPIO pin on the other BBB. I then ran a shell script that pulled the reset pin high whenever "Starting kernel ..." was being printed on the serial console, and counted the number of resets. After some cycles the board would enter the U-Boot console and get stuck there. In three attempts with an A6A board, it took 3, 64 and 37 resets respectively for the board to get stuck. On a rev. C board, the problem occurred after 24, 31 and 3 resets. The U-Boot version used for these tests is fairly old (U-Boot SPL 2013.04-rc1-14237-g90639fe-dirty (Apr 13 2013 - 13:57:11) / U-Boot 2013.04 (Apr 23 2013 - 18:26:39))
I then copied the fixed u-boot provided by Guglielmo (https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg) to the board's eMMC. When repeating the test, I now got past 1000 cycles on both BBBs (rev. A6A and rev. C) without a single boot failure. In summary, this software fix is still highly useful. Thank you Andrew and Guglielmo for your work! Martin On Monday, November 3, 2014 at 10:34:02 PM UTC+1, AndrewTaneGlen wrote: > > Hi Shu, > > I think I answered this in an earlier post, cut/pasted below: > > Rather than making any hardware mods I decided to reconfigured u-boot to > look for a specific key sequence before entering the u-boot console. To do > this I firstly downloaded and rebuilt u-boot following instructions here: > http://eewiki.net/display/linuxonarm/BeagleBone+Black# > BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config > produced the same 'failure' rate) > I then modified '/include/config.h' in the u-boot source files, adding the > following: > > #define CONFIG_AUTOBOOT_KEYED 1 > #define CONFIG_AUTOBOOT_DELAY_STR "uboot" > > This now forces a user to enter the string 'uboot' before entering the > u-boot console, otherwise the device will boot up normally. > > Rebuilding with this configuration still gave the same failure rate > however. This is when I learned that the boot files on the eMMC flash are > still loading before jumping to the files on the sd card I am using. So > upon deleting the MLO file on the eMMC flash I had more luck. > > We setup a programmable power supply and a script looking at the output of > uart0 to detect whether the device had successfully booted or had become > stuck in u-boot, and then left it cycling power. We were then able to get > many hundreds of consecutive successful boots - we only stopped the test > because we decided it would probably never fail. > > So in the end it all came down to spurious data on uart0 - along with > disabling booting from the eMMC. (we could have simply reconfigured u-boot > on the eMMC in the same way, but disabling it drops a few seconds off the > boot time). > > > Thanks for all your help Gerald (and duckhunter). > > Regards, > Andrew Glen > > On 4 November 2014 10:12, Shu Liu <shu...@vensi.com <javascript:>> wrote: > >> Mikkel, >> >> You don't have to remove the whole U15. You can just give a 3.3V pull-up >> to the 4th PIN on the J1 connector. Then the board will not be stuck at the >> UBOOT anymore. >> >> My question is how to fix it from software perspective? In u-Boot source, >> how can we make sure it is not stuck? >> >> If anyone can answer my question, i would really appreciate it. >> >> Regards, >> Shu >> >> On Friday, October 31, 2014 12:19:11 PM UTC-5, mi...@mikini.dk wrote: >>> >>> >>> On October 16th 2014 21.26.23 UTC+2 Gerald wrote: >>>> >>>> Is the power LED shutoff too? >>>> Gerald >>>> >>> >>> Hi Gerald. >>> >>> I'm also affected by the OP's issue of periodic failing boots on BBB (I >>> got all REV Bs). >>> >>> My experience has always been with the power led lighting up and the >>> system stuck without booting. Pressing the reset switch takes the system >>> out of this locked up state, but neither boot switch or power switch has >>> any effect. >>> >>> I am very interested in your input on the successful experiences put >>> forward by Andrew and Marcus in May, about modifying uboot to remedy noise >>> input on UART0_RXD (pin E15 of AM3358). >>> >>> I have done some tests today documenting the basic issue and some >>> followup experiments investigating this specific cause, and I would >>> appreciate if you could take a look and comment on the resulting >>> speculations. You can find the details here; http://www.mikini.dk/index. >>> php/2014/10/beaglebone-black-periodic-boot-failure- >>> establishing-failure-rate-and-possible-cause. >>> >>> Executive summary; removing U15 (SN74LVC2G241: UART0 powerdown >>> isolation) seems to remedy the boot issue on a CircuitCo-produced BBB in my >>> possession. >>> >>> Although my result is inconclusive, as I was careless enough to rush >>> myself into omitting a pre-modification test, verifying the failure rate of >>> the unmodified BBB. >>> >>> >>> Thanks in advance for your help, and for my Beagle puppies ;). >>> Mikkel >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/aXv6An1xfqI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> beagleboard...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
