BBB - Power button behavior in 05.27 and 05.28 flasher images

I had flashed the 05.28 image to see if the USB hotplug issues I was experiencing had been fixed. Sadly, they had not… However, shortly after, I saw Koen’s repeated comments that 05.27 should be used and 05.28 should NOT be used. So I decided I better follow his advice since he built both images.

I noted that he has deleted the 05.28 flasher image to reinforce the point. Point taken.

I then prepared my 05.27 microSD card and in my SSH session issued ‘shutdown now’ for a graceful shutdown. BBB shuts down nicely. So far so good.

I unplugged the power cable, inserted the microSD card, held down the boot button, and plugged the DC power cable back in. Again, so far, so good.

Wait… no blue power LED.

This has never happened before, so I was puzzled. I tried again, same thing. Then it occurred to me that perhaps I should try the power button. I’ve never tried it before and I hadn’t seen how the updates in the 05.27 and 05.28 images would have affected the power button behavior before the linux kernel had loaded, so I didn’t expect it to work.

But it did. So now I’m more confused.

Unfortunately, I was forced to leave for work before the 05.27 flash concluded so I couldn’t try reflashing once the 05.27 image was flashed to the eMMC to verify that this behavior persisted with a 05.27 image on the eMMC.

Is this expected behavior after the recent patches to support the power button?

As a side note that is peripherally related (power and boot at least), I have noticed that if I have the DC power supply plugged in and I have connected the USB cable to a windows PC, I can’t actually gracefully shutdown using ‘shutdown now’ - the BBB reboots. If the USB cable is not plugged in, this works just fine. So without understanding exactly how the PMIC works (haven’t studied up on that yet) it seems that if VBUS is detected it will boot even if it has just been ‘powered down’ via software control (I2C perhaps? Not sure since I haven’t researched it yet). Is this also expected behavior or is it supposed to completely shut down when both the USB and DC are plugged in just like it does when only DC power is plugged in?

Thanks for the hard work! It’s been a steep learning curve for this windows/*nix workstation guy to figure out the bleeding edge embedded stuff, but I’m enjoying it so far.


That is not the intended behaviour, it is supposed to shutdown when you issue 'shutdown'. I guess we're missing a few register writes to the pmic, this powerbutton stuff is uncharted territory I'm afraid.



Shutdown turns off the PMIC, which is still turned on. Unplugging and plugging back in the DC cable should reset it, assuming that the USB cable i snot plugged in.


Your PC is a Lotus Esprit Turbo.

The Beagle is a Prias !

Your PC has a multi core X86 processor and a bunch of RAM. The Bone doesn’t J

the pmic recycles with a change on input power, this is stated on the BB manual. For some reason if you shutdown and leave the usb connected it reboot, i saw this behavior with older images while testing the power button functionality ( after power off commad, pull to grd for a few secs ), maybe the usb bus power is unstable in some way that the pmic detects a rising edge, but thats me guessing


ohh, come on :slight_smile:

CPU speed has nothing to do with extremely slow writing to eMMC.

It does, when the "installer" also has to uncompress the replacement
image while untarring it to the eMMC..

Just for reference, it's taking me about 5-6 minutes "just" to copy
500Mb of target data to the eMMC (this includes a 'sync' call to flush
a buffer).

I believe Angstrom is copying somewhere around 1.5GB, so figure 15 -18
minutes to 'copy' the data, double that for the uncompression stage
and the 40-45 mins makes perfect sense..


and why it needs to uncompress/untar the image (before writing)?
isn’t kernel stored in eMMC in the same format (compressed/tared)?

besides, uncompressing is much faster then compressing, and on 1GHz ARM CPU uncompressing of the image is much faster then writing to the flash memory (thus, uncomressing, if it ever occurs has very little affect on total writing speed).

my uneducated guess: internal write procedure calls sync after every small chunk of data written into flash (and this is what causes a global slow-down).

btw, flashing of debian image (u-boot, kernel, and rootfs) into eMMC takes less then 4.5 minutes (I timed it to 4min 25 sec). Image is from

thus, 55 minutes of flashing Angstrom to eMMC (using the very same Class 10 Micro SD card) is unnecessary slow

To be fair: the Angstrom script, always re-partitions the drive, and
transfers about 1Gb to the eMMC, whereas i cheat by just re-formating
the existing partitions and only transferring 500Mb's, so maybe i save
a little with the partition table, but at-least double the time for
the data size.. I also use "rsync" vs "untar"...

So i'm not sure what's causing the 55 - (5min * 2) : 45 mins of extra stuff...