Talk:BeagleBone Black Extracting eMMC contents

From eLinux.org
Jump to: navigation, search

Contents

Thread titleRepliesLast modified
Flash unsuccessful910:01, 5 December 2017
BeagleBone Black Rev A5A113:37, 12 November 2016
Thanks, Issues, and Suggestions609:56, 4 August 2016
BeagleBoneGreen113:59, 9 March 2016
Issues with REV A6013:10, 19 May 2015
restore: No space left on device106:08, 12 March 2015
simple Kudos thread!607:36, 6 February 2015
Rev. C boards from Element14318:51, 2 January 2015
Filesystem problems when restoring112:56, 31 December 2014
BeagleBone Black Rev B6 - USER LED's will not turn on at all when trying to boot from SD / USB213:29, 12 December 2014

Flash unsuccessful

Hi everyone,

I seem to have an issue when flashing a new beaglebone black Rev C. On my "master" beaglebone black Rev. C, I can successfully (I think) clone the disk image to a uSD card. Then, after editing the autostart file appropriately, I plugged the uSD card into the new beaglebone black, and was able to get it to boot and start to clone (USR0 flashing in a non-heartbeat fashion and whatnot). However, the "flashing" process seems to only take like 5 minutes, and once its done and I remove the card and reboot, the beaglebone won't boot up at all. I've tried recloning my master beaglebone multiple times, and making some of the slight variations of edits to the autostart file as recommended in this discussion, but I can't seem to get a bootable image to clone to the fresh beaglebone. Am I doing something wrong? My master beaglebone uses about 3GB of the eMMC, but the cloned image is more like 1GB. I read that you can only clone 2GB, am I getting messed up since I'm trying to clone 3GB? Or is the cloned image only showing up as ~1GB because it's compressed on the fly while it's cloning (I do use the gzip command in the autostart file). What am I doing wrong and why can't I seem to get this to work?

Thanks!

12:39, 20 May 2015

UPDATE:

So I was unable to get the flash to work, but I think I figured out in general what was causing the issue. All of the beaglebones I have are Rev. C, however one was from Element14 and is a little older, and the others were just recently purchased from a source other than Element14 (unsure of the actual source, someone else at work bought them). Anyways, I was trying to flash the image from the older Element14 beaglebone to the newer beaglebone and figured that should work since they were all Rev. C beaglebones. I tried all sorts of variations on the clone and flash process, but was never able to get it to work. However, I setup one of the newer beaglebones with the exact same OS, apps, and settings as the Element14 beaglebone, and was able to successfully clone that beaglebone image to another one of the newer beaglebones. I'm not exactly sure what's going on, but I figured this information might be useful to someone else who might be running into similar issues.

Something odd or different must have been going on with the Element14 beaglebone image that, when flashed to the newer beaglebone, was causing it to not boot properly (see the above post). If anyone has any thoughts, I'd definitely love to hear them. Thanks!

05:06, 26 May 2015

I had a similar issue with a new batch of BBB not taking the image. It appears to me that a Rev C is not a Rev C. Or perhaps Rev C only refers to the hardware and not the OS installed. Using fdisk and looking at the partition of the eMMC my old board had 3867MB available (image created with this version). Using the new board the partition reported 3825MB. I found a third board that reported 3925MB. All boards purchased in the last year and a half I think.

So I made my partitions use about 150MB less so maybe it will work for a year or two.

So can anyone explain what is going on and what we need to do?

THanks

06:15, 14 June 2016

Interesting. I have to say I've not seen this problem, however, if I understand correctly, cloning is being used to copy the image from a working Rev.C BBB to other Rev.C BBBs? I guess I'm a little confused, as I'm wondering why? If you have a flasher-image on an sdcard, why wouldn't you just use that to flash each Rev.C board?

06:31, 14 June 2016

IN my case and probably others. I have created overlays for a custom cape. Added libraries, software, image etc. I documented it this time, but it took 2 hours to do it. Ok, I was side tracked some, but with cloning you turn it on and wait for the LEDs to stop blinking. Who cares if you get side tracked.

09:04, 14 June 2016

Ah yes, that makes sense. You're right, it should just work. I'm not sure what's going on, hopefully someone from the Beagleboard team can help.

09:13, 14 June 2016
 
 
 
 

Hi, since I spent two hours figuring out how the backup of the interal emmc storage works, here is how I got it running on a recent REV C BBB from Element14:

  • The SD-card really has to be formatted with FAT16, which is only possible with SD-cards <= 4 GB
  1. * Open a command window and enter diskpart
  2. * Select the SD-card as disk with select disk (list disk shows all disk)
  3. * Enter clear (make really sure, that you selected the SD-card)
  4. * Keep diskpart open
  5. * Open the disk-management in Windows
  6. * Create a new partition with exactly 4048 MB and format it with FAT16
  7. * Go back to diskpart, enter "select partition 1" and afterwards active
  8. * Create a folder "dtds" on the SD-card

Copy am335x-boneblack.dtb into the dtds folder Insert the SD-card into the BBB and just power it up (no need to hold down the S2-button)

The USR0 LED should start blinking in a regular pattern (not the heartbeat pattern)

But now the backup solution works really fine and is perfect to clone a running configuration for the BBB onto further BBBs.

00:35, 23 July 2015

Very Important:

When using the REV C BBB from element14, the folder created should be named "dtbs". The above post has a mistake.

14:42, 2 December 2015
 

I got a new cards from Embest. This solution isn't works. It mean "Copy the entire content of https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip" not allow me to flash an image.

May be exist an other way?

09:53, 5 December 2017

It's not flashing it's copying. You have to unzip that file either directly to the sdcard or to your hard drive and then copy it to the sdcard.

10:01, 5 December 2017
 
 
 

BeagleBone Black Rev A5A

Thanks for this article, very helpful.

In regards to the BBB Rev A5A, the partition name is mmcblk0p1 not mmcblk1p2.

Aside from the above, the procedure works fine, both backup and restore. I did populate the dtbs subdirectory as a precaution, but I don't know if it's necessary.

Regards, Mike Kelly

13:04, 12 November 2016

Whether eMMC is mmcblk0 or mmcblk1 does not depend on hardware revision, it depends on kernel version and whether any μSD card is inserted at boot time. In principle it is non-deterministic since it depends on the order in which the devices are detected, but it seems that they respond quickly enough to make it depend on probe order only in practice.

I've patched my own kernel to make mmcblk numbering deterministic based on DT alias definitions, so mmcblk0 is then always μSD and mmcblk1 always eMMC. Robert Nelson merged these patches in his 4.9 kernel series.

13:37, 12 November 2016
 

Thanks, Issues, and Suggestions

First off, thank you; this is a perfect way to handle reading/writing images.

However, it seems that the current boot image does not support writing files to FAT32 greater than 2GB, which makes it where a full image cannot be captured. I tried multiple SD cards formatted various ways, all of which only returned an image file of 2GB. By capturing the dd output to a log file I noticed:

dd: writing '/mnt/BeagleBoneBlack-eMMC-image-9466.img': File too large
206+0 records in
204+1 records out

At first I thought it was an issue with how the SD card was formatted, however by just booting the BBB to Debian and running a dd I was able to copy 4GB to the same SD card:

dd if=/dev/zero of=/mnt/zero.img bs=10M
410+0 records in
409+0 records out
4294967295 bytes (4.3 GB) copied, 421.259 s, 10.2 MB/s

So it would seem there is a big flaw in the current build. Perhaps it is related to this issue: https://groups.google.com/forum/#!topic/android-porting/alF-avcQNfI, which mentions some older linux kernels had the same issue?


I also suggest:

* Changing the dd line in the save autorun.sh to "dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M &> /mnt/autorun.log", or maybe even checking the length of the dd to ensure a full write.
* Providing a warning that you should check that your img file is 4GB.
* Note that the SD partition has to be "active" (as SaintGimp already mentioned, I just had the same issue initially).
* Note that (on at least some revisions) the beaglebone must be powered by the barrel jack for it to work (I'm on a rev c board).
* Note that you must let go of the S2 button after a couple seconds.
12:52, 31 December 2014

Small update... it has the same file size limit using an ext2 partition. Weird.

There are no file size limits, e.g. by running "ulimit -a".

My only guess now is that the kernel or dd weren't compiled with LFS, e.g. the _FILE_OFFSET_BITS are not correct...

18:53, 2 January 2015

I confirmed this on a rev. C board. The images are limited to 2Gb. I agree that it looks like the save-emmc image was not compiled with large file support. There's a way around it though, I added on-the-fly compression to commands in aurorun.sh:

  1. backup

dd if=/dev/mmcblk1 bs=100M | gzip -c > /mnt/BBB-eMMC-$RANDOM.img.gz >>/mnt/autorun.log 2>&1

  1. restore

gunzip -c /mnt/BBB-stockDebian.revC.img.gz | dd of=/dev/mmcblk1 bs=100M >>/mnt/autorun.log 2>&1

(thanks for the idea to send the output to a log file by they way, this adaptation gets both stdin and stdout) It takes a lot longer: >20 minutes to compress and ~15 to decompress but the resulting stock debian image is 572 megabytes. That's from a 4 gig eMMC that is 42% full. That means that unless you are trying to image an eMMC drive full of compressed movies or images then it should always fit under the 2 gig limit, plus you can fit more images on your SD card.

14:35, 5 January 2015

Thanks for the confirmation! I thought I was going crazy...

I like the fix too. I ended up just booting a full stock image and dd'ing the image that way, but this is probably better. I guess I was kind of worried it wouldn't be able to read past the 2GB limit on mmcblk1 either.

15:12, 6 January 2015

Agreed that the 2GB limit isn't on all FAT partitions, only non-FAT32 partitions. This really isn't an issue with the shared image as I don't provide the format information (which makes it easier to work with non-Linux systems). The work-around of always compressing the images seems practical, so I added it to my image.

Thanks for all your trouble-shooting!

07:34, 6 February 2015

Oh, sorry I just sent you a talk message before I saw your reply here.

Well the current build can't even write files larger than 2GB to ext partitions. I was also able to write a 4GB file to the same SD card and FAT partition (using the stock build or a PC) that this build could only write a 2GB file to, so it almost certainly isn't a filesystem issue.

Almost all FAT partitions nowadays are FAT32 (as older versions can't even make partitions that are larger than 4GB), so it is very unlikely that is the issue either.

It's been a while since I built linux, but it would seem that this is an issue with the kernel build. I would have assumed that large file support was always built in to recent kernels, but perhaps some how it was omitted or broken on this build?

08:47, 6 February 2015
 
 
 
 

When I try to make my own version of this from the "Build steps" instructions, it runs for about 15 minutes on the "make" part then gives me this error: buildroot-save-emmc-0.0.1/output/build/linux-ddd36e546e53d3c493075bbebd6188ee843208f9/scripts/gen_initramfs_list.sh: Cannot open '../../images/rootfs.cpio.gz'


Isn't it supposed to be generating the rootfs file? What am I doing wrong?


The reason I have to make my own version of this is that my BeagleBone Green gives me a "mmc1: unrecognised EXT_CSD revision 7" error and doesn't let me write to the eMMC. So I have to patch the kernel. But I don't know where to go from there!

https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&s#!category-topic/beagleboard/seeed-beaglebone-green/l1GtJPIRvHU


I *can't* be the only person in the world with this problem. I've spent over 18 hours trying to fix this problem. What can I do?

09:56, 4 August 2016
 

BeagleBoneGreen

Just got a BBG from Seed Studio and it fails to boot the image from SD card. Following on the experience of the E14 BBB I hooked up a serial console and sure enough:

reading /dtbs/am335x-bonegreen.dtb

    • Unable to read file /dtbs/am335x-bonegreen.dtb **

I confirmed that am335x-bonegreen.dtb on the board does not differ from am335x-boneblack.dtb on the SD card except in name so I copied the file with the "green" name and it boots and works normally. I will update the instructions.

14:45, 2 February 2016

The .dtb files should differ as the Green does not have HDMI. am335x-bonegreen.dtb should exist on newer images. It seems your problem could be related to the version of u-boot not aligning with the contents of the microSD card. Did you try holding the BOOT button when applying power to make sure the microSD card version of u-boot ran?

13:59, 9 March 2016
 

Issues with REV A6

First of all, thank you for this post, it works great on my latest BBBs (REV C). However, I cannot get it to work with my older BBBs (REV A6). We have quite a few of the older versions laying around and would like to use those for some KIOSKs we are setting up in house. Unfortunately, the script does not want to work on these boards. The script is booting to the SD card but it does not appear to recognize (or mount) the eMMC. I added `ls /dev > /mnt/dev.txt` to the bash script so I could see the device list, and there is only mmcblk0, there is not a mmcblk1. I am powering the device with a 5V, 2A power supply and have disconnected all other cables (as suggested in other posts) and still no luck. The device goes straight to a solid LED and writes the dev.txt and a 1KB img.gz file. I have tried running it on multiple boards and am unsure what to try next. Any thoughts as to why the eMMC is not being loaded/mounted?

13:10, 19 May 2015

restore: No space left on device

with some BBB's we have no problem restoring an older angstrom image with dd (Angstrom image uncompressed is 2.1GB) . Image was creating with dd from running system.However,, anyone know why even using this script that some fail with "dd: writing '/dev/mmcblk1': No space left on device" . Yes, the image is compressed as well. Is the only option to recreate the iamge and bring the image down to < 2 GB ? Its just odd that it restores the image on some devices w/out issue.

04:39, 20 February 2015

You need to try to keep the format of the eMMC under 2GB to make sure you can replicate it. As long as that is true, the error should be harmless.

06:08, 12 March 2015
 

simple Kudos thread!

Thank you. Worked beautifully. And so simple!

07:19, 8 January 2014

I have tried this procedure but my Beaglebone Black (BBB) does not boot from the microSD, just from the on-board eMMC. I have limited experience with Linux-based systems and so i am sure I am doing, or not, something simple. I am using a rev A5C BBB with a 4GB FAT32 micrSD. Any pointers will be gratefully received. JohnG

10:28, 12 February 2014
 

I'm having the same issue as jgainsborough.

I formatted a 4GB SDHC as FAT32, extracted the zip to it, inserted into powered-off BBB, held down USER/BOOT applied power, and waited. Never saw any lights other than the power light. Have tried many times, holding down USER/BOOT for as long as 30 seconds.

Have tried with USB and with power supply. Same behavior. Board boots runs fine from internal memory.

13:48, 16 February 2014
 

The page neglects to mention that the partition on the SD must be marked active in order to be booted from when you hold down the USER/BOOT button.

23:47, 20 February 2014
10:09, 12 November 2014

I had to hold down the S2 (USER/BOOT) button near the microSD card, while applying power to the board (by plugging in USB cable) in order to boot this firmware and extract the eMMC image. Pressing RESET while holding the S2 button did not work. After several seconds, I released the S2 button and then the LEDs started blinking. It seems the boot sequence doesn't proceed while S2 is being held down.

Edit: A further test shows that holding the S2 button for too long (15+ seconds) causes the board to turn off.

Note: I just formatted the card with FAT32 and copied the files to it. I did NOT mark the partition as 'active', but DID have to hold down the S2 button when applying power.

12:41, 12 December 2014

Wish I'd noticed all these comments earlier. When in doubt, you might drop a note to http://beagleboard.org/discuss.

07:36, 6 February 2015
 
 
 
 

Rev. C boards from Element14

First, thanks for this incredibly useful tool - I use it all the time! I recently got some Rev. C boards from Element14 and the tool stopped working. It appears to be a change in the U-Boot.img on the EMMC. If you are having this problem and save-emmc isn't loading automatically when you insert the SD card you may be able to work around it by mounting the card and creating a directory called 'dtbs' and copying the file named am335x-boneblack.dtb into that directory.

More detail can be found here: http://www.element14.com/community/message/136214/l/re-bbb-s2-user-boot-button-not-working-on-element14-board

I learned a lot about this process here: https://www.marshut.net/irqnmm/changing-bbb-boot-default-from-emmc-to-usd.html

14:53, 31 December 2014

Interesting, I just got the Element 14 Rev C board and didn't see this problem. I did have to use the barrel jack though, and had the other issues I mentioned.

15:27, 31 December 2014

I think in this case you are using the S2 button to boot completely off the SD card and thereby getting a consistent U-Boot image. I'm just sticking the card in an powering up the board, which relies on the U-Boot image loaded on the eMMC. There's not a strong reason to do that except that booting without S2 is simpler and does not require using the barrel jack.

12:57, 2 January 2015

Ah, got it; thanks for the clarification -- I didn't realize you could bypass the S2 and barrel by doing it this way. This is handy :)

18:51, 2 January 2015
 
 
 

Filesystem problems when restoring

Hello, and thank you for this awesome tool!

I've successfully captured several .img files, which worked very well, and I've made the edits to autorun.sh to place these images back onto the emmc of a beaglebone.

The process of copying the image back to the emmc seems to go well, the light pattern matches what I see when copying an image from EMMC to SD: LED USR0 blinks for about 5 minutes, and then stops. I power off, and boot the system

Things seemed to work ok at first, most of my changes are intact....however, some things are not. A few files (/etc/hostname, /etc/hosts, and so on) are missing. I noted on further investigation that the filesystem is mounted read only, so there seems to be something wrong with the volume on the EMMC

Any idea what would cause this? Maybe just an improper shutdown before I captured the image?

14:14, 1 December 2014

I noticed that my images were only 2GB (see above comment). Can you verify you captured full images? Also, you can try dd'ing the captured image over to another sd card and mounting the partitions in linux to take a look at what you actually captured.

12:56, 31 December 2014
 

BeagleBone Black Rev B6 - USER LED's will not turn on at all when trying to boot from SD / USB

I'm working with BeagleBone Black Rev B6 (Debian) for work.

I would like to make an image of the emmc so I can duplicate the entire project with ease.

I've read multiple pages online describing the process of formatting an SD card, putting it into the BBB whilst powered off, and holding S2 when the board is powered on.

When I do this, the USER LED's do not turn on at all.

I've read this can be caused by not having enough power to the board.

I have tried a number of things to see what the issue:

* I've tested multiple boards (All BBB Rev B6)
* 2 different USB Cables
* 3 different USB ports
* 2 different 5v 1.2a power supplies
* Formatted my 16G SD Card (Came with the BBB) to FAT32 Partition, marked as active
* Copied over the files from the download as instructed
* Different combinations of holding the S2 button upon power on, pressing the reset button, etc etc


I believe that I can make an image of the OS and all the files on the BBB with the dd command, so that is what I will resort to. I will be preparing some 50+ of these BBB's in the coming month, and I would like a very easy and streamlined way of doing all this.

Thanks for the help

11:01, 13 August 2014

Further information:

* I am able to mount and read the SD card from within the OS on the BBB.

Question:

* When I am told that the SD card needs to be FAT formatted, is FAT32 sufficient for this? Or should I be using something like FAT16?
11:04, 13 August 2014

@Cjohnweb -- FAT32 worked for me (formatted from a Windows 7 virtual machine).

Initially, I had many failed attempts when I tried to extract the eMMC image. I tried different types of FAT file systems, using different OS's to perform the format, marking the card as 'active' or 'bootable', copying the files to the card in a specific order (so the MLO and u-boot.img files were first in the file allocation table), all to no avail. Eventually, I discovered you have to hold the S2 button while power is applied, and then release the button a few seconds later. Holding the S2 button and pressing RESET did NOT work for me. Holding the S2 button for too long also does not work (the board just turns off).

It all seems painfully simple in hindsight, but when I first read this Wiki article it didn't say anything about the S2 button, and nothing I tried worked. Even when I was holding the S2 button, I was just pressing RESET, which also doesn't work.

Hopefully this helps!

13:29, 12 December 2014