BBB s2/ "user boot" button not working on element14 board?

Do you have external hardware connected to the pins while performing this action? From memory the pins that specify boot mode are connected to some of the pins on the BBB connectors, so this may be causing an impact maybe?

Usually I just hold down S2 for a few seconds after the LED turns on, and then just release S2 and let it do its thing. Maybe worth monitoring the serial port to see what is going on.

I've not tried this with a rev C, but I didn't think anything was different with regards to this procedure (and it is still the same procedure on the beaglebone website).

Good idea about the external hardware but the behavior is the same without anything attached except 5V power. I tried exactly what you suggested about releasing S2 quickly but when the power is connected and S2 is down the system will not boot even if it is released or if the reset button is pushed. The single power LED remains on but no boot action. Only a long press on the power button or a power cycle will cause it to do anything. As far as I can tell this only affects the Rev.C BBBs from element14. I have not tried rev. C boards from other suppliers but I have the same result with two different boards from E14.

It's worrisome because I don't think I have any way to flash or recover the system if I can't boot from an SD card.

Have you tried your procedure on earlier revision BBBs?

All I can suggest is checking your image is on correctly on the SD card, and observing the serial console output. If you wanted to be 100% sure, then it may be possible to

confirm from the revision C and earlier schematics, that the boot pins are connected the same way. The schematics are here: http://elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29

I'd be _extremely_ surprised if this is really a BBB issue, because Rev C has been around for many months now, and someone out there would have tried a

different build/image on it. I don't have a Rev C to try this on.

So, unfortunately I don't have an answer, but I strongly suggest (a) checking your procedure on Rev A or B, and (b) confirming you really do have a correct image on the SD card,

copied across correctly (as you probably know, there is a procedure to do that - here: http://beagleboard.org/getting-started )

EDIT: I just reread your post, and you state that the procedure works on other Rev C boards? That's extremely odd : ( I can't see why certain boards could behave different w.r.t. using S2 switch.

It is understandable if they behave different if S2 is not used, because the images already on them could be different I think. Is it possible to check the default image on them too?

Thanks for the ideas, I did try a rev B board with the same results but unlike the rev C board it does boot my system from an SD card automatically.

Hooking up a serial monitor and reading up on the boot process showed me what was going on, here is what I found in case it's helpful to others. Naturally there was nothing wrong with the BBB hardware.

When you hold down S2 and apply power, if you only get the single power LED and no boot action it's likely that your SD card is not formatted to boot this way. For the user LEDs to turn on it must read certain files off of the card, without them nothing appears on the serial console and no user LEDs light up. Make sure you have a recent image on the card and that it was written correctly.

I have been using save-emmc from elinux: http://elinux.org/Talk:BeagleBone_Black_Extracting_eMMC_contents

On a rev. A or B board it boots automatically when the SD card is inserted without needing to press S2 (in fact, it does not boot when I press S2). From what I understand the way that works is this:

1. read U-Boot.img from the eMMC, which by default tries to...

2. read uEnv.txt from the SD card, which can tell U-boot to...

3. boot from an image on the SD card instead of booting from the eMMC

Using a serial console I see that the rev. B board prints this message as it loads the device tree configuration:

reading /am335x-boneblack.dtb

24884 bytes read in 11 ms (2.2 MiB/s)

..and the rev C board says:

reading /dtbs/am335x-boneblack.dtb

** Unable to read file /dtbs/am335x-boneblack.dtb **

and fails over to booting from the eMMC instead. Presumably U-Boot.img on the rev. C board is different and is adding the "/dtbs/" to the search path. The simple fix was to mount the SD card, create a directory names 'dtbs' and copy the am335x-boneblack.dtb image into it. After that it boots automatically with any revision board. Presumably the U-boot image on the eMMC could also be changed but that might break something else so this simple fix works for me.

Thanks again for your help!

These BBB's don't always follow the rules.  I have an A6 version and a RevC board.  The A6 was acting a bit odd, couldn't get to a console.  I put the emmc flasher 2013.09.04 image on an SD card then held the boot button and powered up the.  It looked like it was flashing the emmc, took long enough.  When done I removed the SD card, powered on and it was "bricked".  I downloaded the image that is on the REV C board, put it on the SD card.  It booted from the SD card and ran fine, the exact same version as the Rev C board.  Then I downloaded the flasher version of the same image, put it on another SD card, popped that one into the A6 board powered on and it jumped right into the flasher, powered itself off when finished.  I removed the SD card and I now have two boards with the same software.  I never pressed the boot button on the second image, got no idea how it knew to flash the emmc.

You don't need the S2 button to boot off the SD card. The S2 button causes the bootloader to be read from the SD card, which in turn tries to boot from the SD card. The bootloader on the eMMC is typically also configured to look for a bootable SD card and boot that first so as long as the card is bootable and compatible with the bootloader on the eMMC it will work just by sticking it in and powering it on.

Of course, when you flash the eMMC you also flash the bootloader and that could change the default behavior. That may be the inconsistency you are noticing. I haven't found any variation from board to board as long as I flash with the same image. I do recommend jkridner's eMMC save/restore method referenced in my above post. It is the best way I have found of cloning and maintaining BBB images.

The instructions for updating to the latest software say to put the SD card with the image loaded in, hold S2 and apply power.  That was the reason I said these boards don't always follow the rules.

Hi Tom,

It's got nothing to do with the boards, as Kanoa mentions. Booting from SD card can happen without pressing S2 for the reason he says (i.e. depends on the particular image (Angstrom, Debian, whatever)

already on the eMMC and what the bootloader in the image is configured to do).

"The boards don't always follow the rules" doesn't make sense.

Tom Wyckoff wrote:

 

I never pressed the boot button on the second image, got no idea how it knew to flash the emmc.

See above.

When the documentation on the board, and I mean "on the board", not "about the board" says one thing and something else happens you have what I call "not always following the rules". If you've been using BBB's for a while this might be nothing new, but most of my work has been with Microchip products and TI MSP series I got accustomed to boards doing what the documentation says they will do under a certain set of circumstances.

I agree that the BBB documentation is a little misleading; that was the

source of my initial confusion. When you think about it though, the S2

button does work exactly like the "boot device" selection in the BIOS of

a PC. Just like a PC, the boot device might be a bootloader that will in

turn load an OS from almost anywhere. Like Tom, I was in a lower-level

MCU mindset, and I wasn't aware that a BBB normally uses a relatively

full-featured bootloader.