Hi, I don't know if my issue is the same described here, my BBB never boots with something connected to I/O lines, if I disconnect, boots BBB and then reconnected I/Os everything works fine.
Em segunda-feira, 28 de outubro de 2013 19h18min20s UTC-2, AndrewTaneGlen escreveu: > > RESOLVED: > > Upon investigating the u-boot output we found we were facing the same > problem reported earlier in this thread by duckhunter: u-boot was detecting > spurious data on uart0 and entering the u-boot console on about 1/20 > power-ups. > > 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 Friday, 25 October 2013 10:00:44 UTC+13, Gerald wrote: >> >> That is correct. The power button is only good for shutting it down with >> power attached and turning it back on with power still attached. >> >> UBoot uses the UART0 debug port on the header, J1, on the board. >> >> Gerald >> >> >> >> >> On Thu, Oct 24, 2013 at 3:57 PM, AndrewTaneGlen <[email protected]> >> wrote: >> >>> When it fails to boot after connecting 5V, a short press of the power >>> switch has no effect. The kernel has not booted, so the button press event >>> is going nowhere. >>> >>> From this failure mode, pressing and holding the power switch until the >>> power led goes off and then releasing it causes the device to boot - as >>> does a short press of the reset switch. This is what has led me to the >>> conclusion that the only way to guarantee the device boots after applying >>> power is to control the reset signal with a watchdog circuit triggered off >>> a transition of the heart-beat signal (or something similar). >>> >>> I'm wondering if it possibly is getting to u-boot under this failure >>> mode. Do you know if any of the uarts available on P9 are configured by >>> default for u-boot? >>> >>> Cheers, >>> Andrew. >>> >>> On Friday, 25 October 2013 09:14:18 UTC+13, Gerald wrote: >>> >>>> You must just press the power button once. Not hold it. If you do >>>> it just power cycles. Pressing the button once let's the Linux kernel >>>> shutdown after a 60 second time out. >>>> >>>> Try it again using the power button as it was intended. >>>> >>>> Gerald >>>> >>>> >>>> >>>> On Thu, Oct 24, 2013 at 3:05 PM, AndrewTaneGlen <[email protected]> >>>> wrote: >>>> >>>>> Hi Gerald, thank you for your response. >>>>> >>>>> I tried the following (Using a new BBB with no SD card inserted, and >>>>> nothing else connected to it at all): >>>>> >>>>> Firstly, plug in 5V barrel connector (connected to regulated 5V, >>>>> measured with good multimeter as 5.0001V), then: >>>>> >>>>> 1) Wait to see he heartbeat led (D2) come on. >>>>> >>>>> 2) Press and hold the power key until the power led (D1) goes off. >>>>> >>>>> 3) Release the power key >>>>> >>>>> Repeating this process (with 5V connected the entire time) the device >>>>> failed to boot (the heartbeat led failed to come on) on the 14th try, and >>>>> continues to do so about 1/20. >>>>> >>>>> I'm using the BBB in a location away from any regular user interaction >>>>> and with a power supply that can come on and go off randomly (it >>>>> functions >>>>> as a wifi client I connect to and control/monitor with an ipad), so >>>>> unfortunately I don't have the ability to manually press the power or >>>>> reset >>>>> buttons to ensure the device always comes on when power is applied (at >>>>> least as I intend to use it). >>>>> >>>>> What I will do, as a kind of nuclear option, is reassign the >>>>> heart-beat led to a spare gpio on P9, and implement a basic watchdog >>>>> circuit that will pull the 'SYS_RESETn' low for a couple of hundred >>>>> milliseconds if it doesn't see a change in state of the heart-beat signal >>>>> within about 10 seconds. This should give a 100% guarantee that (as long >>>>> as >>>>> the hardware is ok) the kernel will eventually get booted whenever power >>>>> is >>>>> applied. >>>>> >>>>> There is a TI part, the TPS382x that is nearly perfect for this task, >>>>> but has a non-configurable delay time of 1.6s - I'll try to find >>>>> something >>>>> like this. >>>>> >>>>> Cheers, >>>>> Andrew. >>>>> >>>>> >>>>> >>>>> >>>>> On Friday, 25 October 2013 02:01:51 UTC+13, Gerald wrote: >>>>> >>>>>> I don't see that fix as being the issue you are seeing. But, when >>>>>> they are available, you can certainly give it a try. >>>>>> >>>>>> The reset button is a warm reset button. It is not the power on reset >>>>>> for the board. >>>>>> >>>>>> I suggest that you use the power button as it is intended and use it >>>>>> to power off the board and then power on the board. See what sort of >>>>>> results you get in that use case. >>>>>> >>>>>> Gerald >>>>>> >>>>>> >>>>>> On Wed, Oct 23, 2013 at 9:41 PM, AndrewTaneGlen <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> I am also having this problem - with a bench top power supply set to >>>>>>> 5V and 5A, plugging into the barrel connector with no SD card inserted, >>>>>>> so >>>>>>> running the default Angstrom image from flash, the device will fail to >>>>>>> boot >>>>>>> at least 1 in 20 tries. A similar failure rate was observed on my two >>>>>>> other >>>>>>> boards. >>>>>>> >>>>>>> I noticed a new board revision has been a released - the A6. The >>>>>>> list of revisions included a reference to fixing a random glitch in >>>>>>> the SYS_RESETn signal. Could this possibly address the problem I have >>>>>>> been >>>>>>> seeing - I would be more than happy to buy more boards if this is the >>>>>>> case. >>>>>>> >>>>>>> Regardless of the new release, I have tried various experiments to >>>>>>> find a 100% reliable way of making the A5C board boot, as follows: >>>>>>> >>>>>>> 1) Hold reset button, connect power, release reset button after ~1 >>>>>>> second. >>>>>>> >>>>>>> 2) Connect power, press and hold reset button, then release after ~1 >>>>>>> second. >>>>>>> >>>>>>> 3) Hold Power button, connect power, wait till power led goes off, >>>>>>> then release power button. >>>>>>> >>>>>>> All of these also failed at varying rates, but all showing at least >>>>>>> one failure out of 40 tries - which is unfortunate as I am building a >>>>>>> custom cape that will have access to the reset and power signals, so I >>>>>>> there was some sure fire way of making it boot this would have been >>>>>>> fairly >>>>>>> easy to include in my design. >>>>>>> >>>>>>> Any further info would be greatly appreciated. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Andrew. >>>>>>> >>>>>>> >>>>>>> On Saturday, 28 September 2013 10:04:06 UTC+12, [email protected] >>>>>>> wrote: >>>>>>>> >>>>>>>> Same problem here, its showing up in 2 ways. The Beagle Board Black >>>>>>>> has a power control IC that is sensitive to 5 volt rise time and has >>>>>>>> frozen >>>>>>>> up under short brownout situations..in fact, I can freeze it up at >>>>>>>> will by >>>>>>>> dropping out 5 V for about 100mS, it will lock up with 3.3 volts >>>>>>>> turned off >>>>>>>> even though the 5 volt input is good. Removing the 5 volt input for >>>>>>>> more >>>>>>>> than 1 second restores normal 3.3 Volt power and all is good. The >>>>>>>> other >>>>>>>> way..I'm still investigating, it refuses to boot about 1 in 20 tries >>>>>>>> for >>>>>>>> reasons that are so far unknown. In this instance I have power supply >>>>>>>> monitoring instruments all over this board, and the power supply >>>>>>>> controller >>>>>>>> is working even when the lockup occurs. So I'm mainly interested in >>>>>>>> the >>>>>>>> situation where the blue lights are on but the board is not booting. >>>>>>>> We are >>>>>>>> running a port of Debian Linux. >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, July 31, 2013 5:48:54 PM UTC-4, [email protected] >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> we have a problem with our Beagle Bone Black (A5C). We are using >>>>>>>>> Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no >>>>>>>>> SD >>>>>>>>> Card). The Beagle Bone is placed in a case and we have connected it >>>>>>>>> to a DC >>>>>>>>> power supply. Sometimes (I would say every 5 to 10 times), when we >>>>>>>>> are >>>>>>>>> plugging in our power supply, the BeagleBone powers on (Power LED is >>>>>>>>> on), >>>>>>>>> but nothing more happens (none of the other four LEDs is on). If we >>>>>>>>> are now >>>>>>>>> removing the power supply and putting it in again, the BBB starts >>>>>>>>> normally. >>>>>>>>> I guess the power supply is strong enough: 5A@5V. >>>>>>>>> >>>>>>>>> Thanks for your help in advance. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> duckhunter >>>>>>>>> >>>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> -- >>>>> 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 [email protected]. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
