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. On Tuesday, September 15, 2015 at 2:49:30 PM UTC-7, julien wrote: > > > 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. > > > > > On Thursday, August 27, 2015 at 7:23:55 PM UTC+2, Kevin Fructuoso wrote: >> >> 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? >> >> >> On Thursday, August 27, 2015 at 8:43:40 AM UTC-7, RobertCNelson wrote: >>> >>> On Thu, Aug 27, 2015 at 10:35 AM, Kevin Fructuoso >>> <[email protected]> wrote: >>> > 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. >>> >>> 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, >>> >>> -- >>> Robert Nelson >>> https://rcn-ee.com/ >>> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
