Extracting eMMC contents using FAT formatted card

There are lots of ways to extract the contents of the eMMC to save off and reuse. I’m proposing a method using Buildroot and an initramfs such that you can simply drop a few files from a .zip onto a normal, FAT-formatted SD card to perform the extraction. There are several things really handy here, such as the ability to edit autorun.sh to be whatever script you want to run on your board at boot. In the archive, I only have the necessary autorun.sh for saving your eMMC content. The flip-side is provided here in the text such that you need to go through a couple of steps before you trash your eMMC.

The steps for saving off your eMMC contents to a file:

  • Get a 4GB or larger uSD card that is FAT formatted.
  • Download https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip and extract the contents onto your uSD card.
  • Eject uSD card from your computer, insert into powered-off BeagleBone Black and apply power to your board.
  • You’ll notice USR0 (the LED closest to the S1 button in the corner) will (after about 20 seconds) start to blink steadily, rather than the double-pulse “heartbeat” pattern that is typical when your BeagleBone Black is running the typical Linux kernel configuration.
  • It’ll run for a bit under 10 minutes and then USR0 will stay ON steady. That’s your cue to remove power, remove the uSD card and put it back into your computer.
  • You should see a file called BeagleBoneBlack-eMMC-image-XXXXX.img, where XXXXX is a set of random numbers. Save off this file to use for restoring your image later.

Because the date won’t be set on your board, you might want to adjust the date on the file to remember when you made it. Delete the file if you want to make room for a new backup image. For storage on your computer, these images will typically compress very well, so use your favorite compression tool.

To restore the file, make sure there is a valid BeagleBoneBlack-eMMC-image-XXXX.img file on the uSD card and edit autorun.sh with your favorite text editor to contain the following:

#!/bin/sh
echo timer > /sys/class/leds/beaglebone:green:usr0/trigger
dd if=/mnt/BeagleBoneBlack-eMMC-image-XXXXX.img of=/dev/mmcblk1 bs=10M
sync
echo default-on > /sys/class/leds/beaglebone:green:usr0/trigger

NOTE: Be certain to replace the ‘XXXXX’ above with the proper name of your image file.

This image was built using Buildroot. The sources are at https://github.com/jadonk/buildroot with tag save-emmc-0.0.1. Download via https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1 or clone the git repo. It is a small fork from git://git.buildroot.net/buildroot tag e9f6011617528646768e69203e85fe64364b7efd.

To build, ‘make beagleboneblack_defconfig; make; ./mkuimage.sh’. Output files (am335x-boneblack.dtb, MLO, u-boot.img and uImage) will be in the output/images subdirectory. The following files were created manually.

uEnv.txt:

bootpart=0:1
bootdir=
fdtaddr=0x81FF0000
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
uenvcmd=load mmc 0 ${loadaddr} uImage;run loadfdt;setenv bootargs console=${console} ${optargs};bootm ${loadaddr} - ${fdtaddr}

autorun.sh:

#!/bin/sh
echo timer > /sys/class/leds/beaglebone:green:usr0/trigger
dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M
sync
echo default-on > /sys/class/leds/beaglebone:green:usr0/trigger

The kernel is based on https://github.com/beagleboard/kernel/commit/9fdb452245a58158a4bea787cdc663c17681bcfe, but I applied the patches, added firmware and uploaded it to https://github.com/beagleboard/linux/commit/ddd36e546e53d3c493075bbebd6188ee843208f9 to pull down in the Buildroot makefile. The link to the source for the firmware is in the commit.

I’ve applied to join the Buildroot mailing list to send these patches upstream. The power management firmware is not yet loading properly, but that is something I can look into.

Happy hacking!

Jason,

shouldn't this info go up on the elinux.org wiki?

Dave

Jason,

shouldn’t this info go up on the elinux.org wiki?

Absolutely. Any recommendation on the page location? I will upload it right away.

http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents

is a good place to start. i am working with bill traynor to organize howto pages along with other specific category groups...

Dave

http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents

Added. Feedback welcome.

autorun.sh:
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M
sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I think using dd and creating an image is a pretty bad way to build a backup.

I would suggest to use

sfdisk -d /dev/foo >sfdisk.emmc.txt
mount emmc
tar cpjf -C emmc .
umount emmc

Regards,

Alexander Holler

Of course, it should be

tar cpjf emmc.tar.bz2 -C emmc .

and another tar might be necessary for the second partition.

And putting such a script together with busybox into an in-kernel initramfs, and people would just have to build a card with one file, the uImage.

Regards,

Alexander Holler

I still like having autorun.sh such that the script can be easily customized without rebuilding. Of course, MLO and u-boot.img are also required. The discussed Buildroot-based image is using initramfs.

Seems like some work is required here to create the logic to make sure each partition is tar’d. Also, the restore script needs to be created. In general, this just requires some more testing. Any volunteers to try out the sfdisk/tar based solution?

Overall, I agree it is a much better approach and I will get started on it as soon as I’ve submitted the base Buildroot patches upstream. Is there an easy way to make subdirectories within the tar to hold the format table and each partition such that I don’t have to run tar twice and potentially run out of card space?

autorun.sh:
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img

bs=10M

sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I think using dd and creating an image is a pretty bad way to build a
backup.

I would suggest to use

sfdisk -d /dev/foo >sfdisk.emmc.txt
mount emmc
tar cpjf -C emmc .
umount emmc

Of course, it should be

tar cpjf emmc.tar.bz2 -C emmc .

and another tar might be necessary for the second partition.

And putting such a script together with busybox into an in-kernel
initramfs, and people would just have to build a card with one file, the
uImage.

I still like having autorun.sh such that the script can be easily
customized without rebuilding. Of course, MLO and u-boot.img are also
required. The discussed Buildroot-based image is using initramfs.

As long as the eMMC still works (the first partition there is ok), there is no need for mlo and u-boot on the sd-card.

Seems like some work is required here to create the logic to make sure each
partition is tar'd. Also, the restore script needs to be created. In
general, this just requires some more testing. Any volunteers to try out
the sfdisk/tar based solution?

To restore such a tar, use

tar xpjf emmc.tar.bz2 -C emmc --numeric-owner

after you've created or formatted and mounted the partition. And don't forget that --numeric-owner on restore, otherwise bad things might happen.

Regards,

Alexander Holler

autorun.sh:
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img

bs=10M

sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I think using dd and creating an image is a pretty bad way to build a
backup.

I would suggest to use

sfdisk -d /dev/foo >sfdisk.emmc.txt
mount emmc
tar cpjf -C emmc .
umount emmc

Of course, it should be

tar cpjf emmc.tar.bz2 -C emmc .

and another tar might be necessary for the second partition.

And putting such a script together with busybox into an in-kernel
initramfs, and people would just have to build a card with one file, the
uImage.

I still like having autorun.sh such that the script can be easily
customized without rebuilding. Of course, MLO and u-boot.img are also
required. The discussed Buildroot-based image is using initramfs.

As long as the eMMC still works (the first partition there is ok), there is
no need for mlo and u-boot on the sd-card.

Seems like some work is required here to create the logic to make sure
each
partition is tar'd. Also, the restore script needs to be created. In
general, this just requires some more testing. Any volunteers to try out
the sfdisk/tar based solution?

To restore such a tar, use

tar xpjf emmc.tar.bz2 -C emmc --numeric-owner

after you've created or formatted and mounted the partition. And don't
forget that --numeric-owner on restore, otherwise bad things might happen.

Any thoughts on saving off the format name and type of a partition?
sfdisk only saves that the partition is of type '83', not that it is
formatted as 'ext4' with a certain label.

Hi Jason,

I really like the method you propose. Except the fact I tried it and I can’t get it to work, or at least not following your directions.

  • I’ve flashed my BBB to Debian (http://elinux.org/BeagleBoardDebian) worked like a charm – now booting to the SD by default

  • I followed your instructions (8GB µSD, FAT32 formatted)

o If I press no button, the BBB boots on the eMMC

o If I press the “boot” button while plugging the power, the BBB just doesn’t boot (stays in a “powered off” state, with only the LED near the power plug on)

The BBB is brand new, so maybe they changed something.

Thanks for your help.

Hi Jason,

I really like the method you propose. Except the fact I tried it and I can't
get it to work, or at least not following your directions.

- I’ve flashed my BBB to Debian
(http://elinux.org/BeagleBoardDebian) worked like a charm – now booting to
the SD by default

- I followed your instructions (8GB µSD, FAT32 formatted)

o If I press no button, the BBB boots on the eMMC

This tells me that the bootloader you flashed onto the eMMC doesn't
properly work with the uEnv.txt put onto the uSD card as part of
following my instructions.

o If I press the “boot” button while plugging the power, the BBB just
doesn’t boot (stays in a “powered off” state, with only the LED near the
power plug on)

This means that the uSD card FAT partition isn't marked as bootable.
You can do that with 'fdisk' from your BeagleBone running Debian in
all likelihood.

root@beaglebone:~# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.23.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/mmcblk1: 3904 MB, 3904897024 bytes, 7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

        Device Boot Start End Blocks Id System
/dev/mmcblk1p1 * 2048 133119 65536 e W95 FAT16 (LBA)
/dev/mmcblk1p2 133120 7626751 3746816 83 Linux

The BBB is brand new, so maybe they changed something.

Who's "they"? It is possible CircuitCo switched the bootloader image
on the eMMC, but it sounds more like you did that above.

  • I followed your instructions (8GB µSD, FAT32 formatted)
    o If I press no button, the BBB boots on the eMMC

This tells me that the bootloader you flashed onto the eMMC doesn’t properly work with the uEnv.txt put onto the uSD card as part of following my instructions.

I’ve no idea what bootloader the Debian image flashed to my eMMC (as a lot of people, I know nothing about Angström, and the first thing I did was to put Debian into my device, a much more common distrib, because I just want a cheap linux server to do some stuff at home).
I’m kind of a noob using the BBB, sorry about that (I’m using a RPi for quite a while now, but I’m not considering myself as a power user – despite managing some linux servers and having a master in embedded systems, I’m a web developer and I love high level programming). What I mean but all that is: something that could look obvious to you isn’t for 95% of the people reading your guides, the 95% that aren’t doing BBB related stuff for a living.
But well, if I could boot onto the µSD using the boot button that would be ever more fine to me (I could leave the µSD into the BBB and boot on it when I want to backup my distrib).

o If I press the “boot” button while plugging the power, the BBB just
doesn’t boot (stays in a “powered off” state, with only the LED near the
power plug on)

This means that the uSD card FAT partition isn’t marked as bootable.
You can do that with ‘fdisk’ from your BeagleBone running Debian in all likelihood.

Huge thanks for the step by step :slight_smile:
I think it would be way easier for everybody (including you ^^) if you made a .img image of the card (maybe in different sizes?) – this would eliminate any possible mistake in the process.
As most people, I’m using Windows and formatting a card doesn’t mark the partition as bootable, so following your base instructions just doesn’t work.

I’ve found that my µSD is in /dev/mmcblk0 (I tried /dev/mmcblk1 at first and it bricked my BBB, I had to flash it again – not a big deal)

root@arm:~# cat /proc/partitions
major minor #blocks name

179 0 7822336 mmcblk0
179 1 7818240 mmcblk0p1
179 8 1875968 mmcblk1
179 9 72261 mmcblk1p1
179 10 1799280 mmcblk1p2
179 24 1024 mmcblk1boot1
179 16 1024 mmcblk1boot0

The card is now bootable:

root@arm:~# fdisk /dev/mmcblk0

Command (m for help): p

Disk /dev/mmcblk0: 8010 MB, 8010072064 bytes
214 heads, 8 sectors/track, 9138 cylinders, total 15644672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 8192 15644671 7818240 b W95 FAT32

It was still booting to the eMMC by default, so I powered it on while having the boot button but – no matter if I pressed the button for 4 seconds or until LEDs are on - it somewhat booted, but the USR0 was directly steady on. So I tried to reboot it (using the “reset” button) and it’s now correctly writing the image to the SD. I don’t really know how the “boot” button works, but considering this behaviour I would say it disables the eMMC while pressed, isn’t?
So my “create image process” is: power the BBB on with the boot button pressed for like 5s, and once the USR0 is steady on, press the reset button and then wait 10min for USR0 to be steady on again.
Again, thank you a lot for your help. I really like the BBB, the only think I don’t like is how difficult it is to make an image of the eMMC and your method is a huge step into making it simple.

root@beaglebone:~# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.23.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/mmcblk1: 3904 MB, 3904897024 bytes, 7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/mmcblk1p1 * 2048 133119 65536 e W95 FAT16 (LBA)
/dev/mmcblk1p2 133120 7626751 3746816 83 Linux

The BBB is brand new, so maybe they changed something.

Who’s “they”? It is possible CircuitCo switched the bootloader image on the eMMC, but it sounds more like you did that above.

Yeah, I thought maybe CircuitCo changed something in the bootloading or something, but it definitively doesn’t seems to be the issue here.

Well, grab a usb-serial adapter and find out what u-boot is doing. I
have a couple failsafe's in the bootloader i used when you flashed it
with debian to more 'easily' support empty microSD cards. However if
the "uEnv.txt" on your other microSD is not valid, it still keep
booting from eMMC.

So grab a usb-serial adapter and find out what u-boot's doing, as i
print out a few hints..

Regards,

Well, I’m perfectly fine with the way it behaves right now (I can keep the “imager/flasher” SD card plugged into the board).
Also I was unable to install the BB drivers on my computer (yes, the “Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)” is installed, as well as everything needed – I’m a .net web developper, Visual Studio installs all that stuff), I think there is a conflict with my existing TAP drivers or something (OpenVPN and/or Hamachi). But I don’t care enough to investigate this.
This won’t give you any hint I guess, but here is the failure screenshot: http://s16.postimg.org/md2nehe6t/Capture.png

Hi Vincent,

  From your screen shot it looks like you are running Win8. Have you disabled driver signature verification to see if the drivers will install?

-Wil

Hi Wil,
This worked! Thanks you very much for pointing this out! This is something that should be in the getting started…
Is there any particular reason why the driver is not signed?
The getting started guide is very detailed and very well done, giving lot of useful information, but don’t even address a major issue that affects a growing number of users (Windows 7 and Vista don’t have this issue?).

In my opinion, the BBB is an incredible piece of hardware, way superior to the RPi. But it’s WAY (and I mean WAY WAY WAY) less user friendly than the RPi: no guide is up to date, nothing is working like described in the guides, Angstrom is a confidential distrib (why choosing this by default? power users can install Angstrom by their own! People wants Ubuntu/Debian! (I personally prefer Debian when no GUI because Ubuntu’s do-release-upgrade always breaks everything)), and this is very unfortunate.
This gives a poor first user experience, limiting the growth of the community. It looks like the product is made for and by hyper specialized nerds.
As I understand, the beagleboard.org projects are community driven, so making the product accessible only to a very small part of the population is definitively not a good thing.

NB: I tried to edit the getting started guide to add the driver related issue in the troubleshooting section, but I guess it’s not a wiki – no edit link once logged in.

No problem, glad it worked.

-Wil

Hello,

I realize that this is an old thread, but was hoping that one of y’all might see this and shed some light on what I’m doing wrong…

I pulled the buildroot project from "https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1" since it’s exactly what I need (an initramfs with working support for the SD card; I can’t get MMC/SD to work with the mainline kernel and Buildroot 2013.11).

Problem is, when I follow the build instructions, it goes off to do a GIT clone on from GitHub of tag “ddd36e546e53d3c493075bbebd6188ee843208f9” to get Linux kernel patches. It appears to contact the GIT server, processes some 697MB with of data, builds a tarball on the remote end, and then downloads a “linux-ddd36e546e53d3c493075bbebd6188ee843208f9.tar.gz” tarball file with 20 bytes in it.

At this point, the Buildroot compile dies, since the tarball is truncated/corrupted/something.

I’m not very well versed in GIT internals; can anyone shed some light on what might be wrong so I can get this compiled? I will happily provide any logs or other information, but am too new at using GIT to know what to post up.

Thanks,
Jim

Did you try something like:
git clone git://github.com/jadonk/buildroot
in your terminal