Bulk flashing of BBB eMMC

What is the quickest way to bulk flash say 10 BBB’s eMMC?

At the moment I have 10 Micro SD Card with a custom flasher image on and this works but wondered if there was a more slick solution out there at all?

A bulk SD card copier.

Gerald

Thanks Gerald,

That wasn’t really the issue as I can do that part no problem. Was curious if there was another way of flashing BBB’s en masse via another means other than SD cards.

I know of no other way. That is why that is the way we do it in production. It works out fine for use. We use the duplicator to crate a bunch of card sand we use them to flash the boards during burn in.

Gerald

You could boot over network, load rootfs over NFS, but in the end, you till need an sdcard for the bootloaders . …

Hello Lee,

my process is that I have a running Linux on a bootable SD card.
As a autostart service, there is a scripted executed, which performs

  1. partitioning of the eMMC card
  2. copy u-boot.bin and MLO to the first sectors of the eMMC
  3. format the 1st (and only) partition with ext4 file system
  4. unzip/untar a master tar.gz from the boot media to the data partition
  5. patch the extracted uEnv.txt with the actual UUID of the partition on eMMC
  6. initiate regeneration of ssh host keys (touch /etc/ssh/ssh.regenerate)
  7. sync
  8. power off

That takes about 1min to flash one Beaglebone. It takes somewhat longer if the BBB is not connected to a network, because then it needs a network timeout to proceed

cheers, Günter (dl4mea)

Thanks for all of your experiences. Interesting you use the SD in production. That is similar to what I am doing now.

Günter, that is much quicker than the 5 minutes I have it down to at the moment so may invest some time in that process.

Lee

One other option not mentioned. Which is “burning” from USB.

Pretty much, all methods requires an sdcard, period. So, just using a large sdcard, with a small boot / rootfs, and a larger partition mounted, where every with all the data needed to be “burned” to eMMC. Thats all that’s needed.

So the data partition can be anything, then it’s just a matter of mounting that media, and using it exactly how an sdcard would be used in it’s stead. network mount, sdcard, USB media, whatever. It all the same at this point.

I do recall something about “serial boot”, but meh that sounds like a huge hassle . . . but also note that an NFS mount will be slower than both USB, or using the sdcard directly. In fact, for reads, I do not think anything will be faster than sdcard . . . in this context.

Yeah thanks William, I was hoping there was a serial method but thinking that through I think it would be slower than an SD card!

I should also add, that I tested USB read / write speeds a couple years ago. Reads were actually slower than NFS, but write were around 20MB/s.

Anyway, we’re talking ancient 3.8.x, so perhaps with the newer 4.1.x kernels that’s been improved ?

I don't have a direct apples to apples comparison.

The default eMMC flashers use rsync to copy a 'ro' microSD image to the eMMC

I did implement a usb based, but that boots off of a microSD, mounts the
usb and flashes the eMMC via bmap-tools, however it's a *.xz compressed
image on the usb drive.. Which slows it down.

With Jessie, the current 4gb images take about 18:30-ish, with this change
we are back to 11:30-ish

https://github.com/RobertCNelson/boot-scripts/commit/ff8719e152f4464ffc695af3f820883cea29d543

Regards,

Wow that is a sizeable difference, I will create some new SD cards later to speed things up! :slight_smile:

As Robert mentioned, I've also been using the BBBlfs project, which
provides a USB-based bootloader, to load a kernel plus userspace where
the eMMC looks like a USB flash drive. Usability across operating
systems have kept us from pushing BBBlfs out as the default for end
users where usability and not speed is the main concern.

For production, however, I've heard that some eMMC providers will put
images onto the eMMC so that they arrived pre-programmed on your dock.
I'm not sure how cost effective that is.

For workshops and my cape tester setup, I've been trying to get a
BeagleBone Black setup as a BBBlfs host and use udev rules to trigger
flashing when a BeagleBone is attached. Just as I was starting to test
it, I walked up with a big static charge and zapped my cape tester
setup. :frowning:

I was going to start with a udev rule like this:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="a4a2",
ACTION=="add", RUN+="cd /root/BBBlfs/bin && ./usb_flasher"

Next would be to figure out how to disable udisks so that the eMMC
doesn't get mounted, then use another udev rule with bmaptools to
trigger the programming.

I'd also put some kind of cron job to download the latest images off
of http://builds.beagleboard.org to try to make my setup complete.

For workshops and my cape tester setup, I’ve been trying to get a
BeagleBone Black setup as a BBBlfs host and use udev rules to trigger
flashing when a BeagleBone is attached. Just as I was starting to test
it, I walked up with a big static charge and zapped my cape tester
setup. :frowning:

Ouch !!! Do you by any chance have a worklog of this setup Jason ? I’d be willing to setup and test this myself. BBBlfs is pretty interesting, but I was under the impression this was an Android only thing - As per the GSoC project . . . granted, Android is (sort of ) Linux too . . . I did find the github project page, the instructions seem complete, but I was more interested in knowing what you had for a run script off the udev rule mentioned above.