Beaglebone Black image cloning failure

Hi everyone,

I have been working with the BeagleBone Black Rev C for work. It seems that I am having an issue cloning an image to the eMMC of a new beaglebone. I can successfully clone an image to a microSD card and flash some older beaglebone black Rev C boards without problem. This is similar to user Mgeorgia’s issue on this forum: http://elinux.org/Talk:BeagleBone_Black_Extracting_eMMC_contents

When attempting to flash recently received beaglebone blacks, the serial output is 100% identical compared to flashing an old beaglebone with the same image. The output designates successful flashing. However, the new boards do not boot up after a power cycle and never boot again. The serial outputs a stream of “CCCCCCCC.”

Using the same method, I can successfully flash the original stock image onto the new beaglebones. I can flash images to older beaglebones as well. There is only an issue when trying to clone an image from an older beaglebone over to a new beaglebone I recently received, although the serial output does not indicate this. All beaglebones I am working with are Rev C.

I have been using the disk dump command, dd, as per the official eMMC extracting/flashing page: http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents. I also tried to flash without on the fly compression. The issue is still present.

I want to point out that all of the boards with this issue seem to have the wrong eMMC device. The last 15 I received have a Kingston eMMC part number “EMMC04G-S100.” When I look at the BOM spreadsheet on the official webpage (http://elinux.org/Beagleboard:BeagleBoneBlack), this eMMC is not listed there. The only ones are: Kingston KE4CN2H5A and Micron MTFC4GLDEA 0M WT.

Does this matter? Could this be causing an issue when flashing the eMMC? Is this actually an allowed alternative and the BOM on the page hasn’t been updated? I see that this different eMMC has a 5.0 class standard (as opposed to the 4.5 and 4.41 of the BOM specified Kingston and Micron chips, respectively).

What can I do to get around this? Any help is greatly appreciated! Thanks!

Standard manufacturing procedure, one eMMC goes eol, a newer eMMC comes out.

For "dd" based backup/recovery tools the newer eMMC is slightly smaller..

#Micron 3744MB (bbb): 3925868544 bytes
#Kingston 3688MB (bbb): 3867148288 bytes
#Kingston 3648MB (x15): 3825205248 bytes

Which is why the official 'flashers" use rsync..

Regards,

Thanks for the info. Even though it’s slightly smaller, the images I tried to flash are ~2.1 GB. I would think the smaller size limit shouldn’t make a difference, or is that not entirely correct?

I am only familiar with cloning using the dd method used here: http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents.

Can rsync clone the disc image similar to the dd method? Could you please point me to some references/examples of proper use of rsync to clone a production beaglebone to another beaglebone using a micro SD card?

Well there's a version that uses rsync that is shipped inside every
debian image already..

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh

under

/opt/scripts/tools/eMMC/

git pull to get the latest in that directory, but if "cat /etc/dogtag"
is too "old" it may fail.. (if that folder doesn't exist your image
is too old)

all the image listed here have it:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

Regards,

Hi Kevin,

We are cloning BBBs using dd, and we noticed a similar problem: even with a small image, the flashing sometimes fails (blank console when booting from eMMC)
If we redo exactly the same flashing procedure on the same BBB, it usually works.
It looks like dd fails when it is started to early after BBB boot. Maybe some I/O overflow if dd is used while the system is still booting and reading a lot of stuff from the sdCard.
If we just wait for ~30seconds after the prompt, the flashing procedure looks much more reliable.

Hi Julien,

That is something we also came across previously and handled in the same way as well. That didn’t solve our flashing problem.

The issue was the slightly smaller size of the eMMC. To fix our flashing problem, we took a older programmed board and re-sized the partition to 3 GB. We flashed this image to a micro SD using the compression method on http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents. Then we flashed a board with the new Kingston eMMC using the decompression method detailed the link. The beaglebones with new Kingston eMMCs are now able to be flashed with this new image. The initial delay is still required.