Let me know if I need to put this in a new thread, or if someone wants to take off the group entirely.
I followed the directions here: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. Specifically this section: Bootloader: U-Boot and the bootloader portion of Setup microSD card. After following those directions the Beagle Bone fails to boot, leaving 2 LEDS on and messages on UART0 saying that there is no partition table. I see the next step in Setup microSD card is creating the partition table, but that doesn't seem to be working it complains that the device is currently busy. I'd prefer not to blow away the operating system if that's possible? Just to see what happened I forced the sfdisk command and it seemed to create 4 partitions, only one of which had a size which seems right to me. When i rebooted though I get an error that says bad device mmc 1. Any ideas? Thanks, Chris On Tue, Oct 6, 2015 at 8:34 PM, William Hermans <[email protected]> wrote: > 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 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 > [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.
