View source for Talk:BeagleBone Black Extracting eMMC contents
|Thread title||Replies||Last modified|
|Buildroot image for flashing .img.xz file||0||18:24, 30 September 2021|
|Flash unsuccessful||9||10:01, 5 December 2017|
|BeagleBone Black Rev A5A||1||13:37, 12 November 2016|
|Thanks, Issues, and Suggestions||6||09:56, 4 August 2016|
|BeagleBoneGreen||1||13:59, 9 March 2016|
|Issues with REV A6||0||13:10, 19 May 2015|
|restore: No space left on device||1||06:08, 12 March 2015|
|simple Kudos thread!||6||07:36, 6 February 2015|
|Rev. C boards from Element14||3||18:51, 2 January 2015|
|Filesystem problems when restoring||1||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||2||13:29, 12 December 2014|
I've had enough people ask, that I'm reviving my Buildroot flashing/extraction image. Right now, I just have the flashing part. This was initially done to update the contents of an old Angstrom image that needed a kernel update.
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?
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!
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?
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?
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.
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
- * Open a command window and enter diskpart
- * Select the SD-card as disk with select disk (list disk shows all disk)
- * Enter clear (make really sure, that you selected the SD-card)
- * Keep diskpart open
- * Open the disk-management in Windows
- * Create a new partition with exactly 4048 MB and format it with FAT16
- * Go back to diskpart, enter "select partition 1" and afterwards active
- * Create a folder "dtds" on the SD-card
- Copy the entire content of https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip 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.
When using the REV C BBB from element14, the folder created should be named "dtbs". The above post has a mistake.
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?
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
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.
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.
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...
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:
dd if=/dev/mmcblk1 bs=100M | gzip -c > /mnt/BBB-eMMC-$RANDOM.img.gz >>/mnt/autorun.log 2>&1
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.
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.
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!
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?
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!
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?
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:
- 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.
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?
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?
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.
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
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.
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.
You can mark an SD partition active by following: http://www.kozio.com/blog/how-do-i-make-an-sd-card-partition-active-under-windows-7
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.
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
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.
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.
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?
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
You do not have permission to edit this page, for the following reasons:
- The action you have requested is limited to users in the group: Users.
- You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.
@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!