For more information you can read my blog post here: http://www.embeddedhobbyist.com/2015/09/beaglebone-black-working-with-debianlinux-images/
It's briefly covered in the "Advanced usage of tar" section. On Tue, Oct 6, 2015 at 5:31 PM, William Hermans <[email protected]> wrote: > *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.
