> > *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. *
This has been in effect since around kernel 3.8.13-bone47 on Wheezy. Since partition, with MLO, and u-boot.img being located in the first 1M of the partition. On Tue, Oct 6, 2015 at 3:24 PM, <[email protected]> wrote: > 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 <[email protected]> >> wrote: >> >On Fri, Oct 2, 2015 at 5:23 PM, Brian Adams <[email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
