I also am experiencing this issue. I'm trying to avoid a hardware modification so I was trying to follow Mikkel's post: http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue. However I can't find a FAT partition on my sd-card.. Is this something that changed when switching from Angstrom to Debian? Searching for u-boot.img and MLO and only found them in the u-boot backup folder so I assume that's not what I need to change.
I'm running the Debian image from 03-01-2015. Using the newer images did not increase reliability by much. Thanks, Chris On Saturday, October 3, 2015 at 6:54:51 AM UTC-4, Mikkel Kirkgaard Nielsen wrote: > > > > On 3. okt. 2015 00.29.26 CEST, Robert Nelson <robert...@gmail.com > <javascript:>> wrote: > >On Fri, Oct 2, 2015 at 5:23 PM, Brian Adams <br...@openrov.com > <javascript:>> wrote: > >we are still experiencing a 4.5% boot failure rate > >For a board that "stops" what happens when you plug in a usb-usart, > >are you really in u-boot? > >(u-boot prompt should echo back on the first enter) > > Characters on uart0 was clearly, without any doubt, what interrupted the > boot when I did my testing last winter (that was the unmodified uboot); > http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue > > I checked numerous times with a serial connection that uboot was indeed > waiting for commands on uart0 in this condition. > > As for the cause, I still have a suspicion towards the circuitry design > around the buffer U15 and its OE and _OE (discussed in > http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause). > > But I guess nobody wants to waste time analyzing this issue on a stale > design such as the BB. > > >One reason i can't lock down u-boot by default, CircuitCo's tester > >expect to take over u-boot to program the eeprom as part of their > >tester machines.. > > And that is indeed a valid argument for keeping the feature. Changing > stuff in factory is non-trivial. > But still you would probably be able to identify the one character that > their testers actually do use to stop boot and only react to that one. That > would lower possibility by 2^8 (if all chars are still valid in current > uboot). > Or future CircuitCo production image uboots could be built from a > branch/fork/patchset that stops on one char as now. This would allow the > proper "wait for string" solution to be implemented in the default uboot. > People doing their own builds like Brian would then actually build a uboot > that doesn't intendedly ruin boot stability. > > It is really disheartening to know that people are still fighting this > problem even though a solution is well-known and has been for such a long > time. > > Mikkel > -- > Sendt fra min Android telefon med K-9 Mail. Undskyld hvis jeg er lidt > kortfattet. > -- 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.
