Author Archives: Dimitris Lampridis

How-to create a custom microSD card image for the BeagleBone Black

beagle logoThis article serves as a guide on how to create a custom microSD card image for the BeagleBone Black. The steps described in this guide are pretty much platform agnostic. One could also adjust them to other systems, besides the BeagleBone Black.

The BeagleBone Black is an open hardware ARM single-board computer, very popular for its attractive price and rich set of features.

The system ships with an Ångström Linux distribution installed in its internal 2GB flash, while a microSD card slot allows running other operating systems as well (or replacing the contents of the internal flash).

Various pre-made microSD card images are available, and has very detailed steps on creating a microSD with your own contents.

However, what we could not find (and decided to write about it) was a guide on how to generate our own image of a microSD for the BeagleBone Black. This can come in handy in several situations, such as when you want to:

  • prepare all the work without having the actual microSD card at hand.
  • use the card image in a virtual machine.
  • maintain different versions of your installation.
  • automate the process via scripts, without being forced to write the result to a microSD card every time.
  • speed up the creation of multiple microSD cards from the same image.

The following links were used as input while writing this guide.


In order to perform the tasks described in this guide, you will need the following.

  • A standard GNU/linux distribution. We use Debian.
  • Root access via sudo. If you prefer su, adjust the steps accordingly.
  • The sfdisk tool. In Debian-based distributions, install the package “util-linux”.
  • The kpartx tool. In Debian-based distributions, install the package “kpartx”.
  • The mkfs.vfat and mkfs.ext4 tools. In Debian-based distributions, install the packages “dosfstools” and “e2fsprogs”.

Optionally, you might also want to use the following.

  • The ddrescue tool. In Debian-based distributions, install the package “gddrescue”.
  • The qemu-img tool. In Debian-based distributions, install the package “qemu-utils”.

If you use a Debian-based distribution and you want to install all of the above tools at once, you can issue the following command.

$ sudo apt-get install util-linux kpartx dosfstools e2fsprogs gddrescue qemu-utils

Image preparation

Create an empty image

The first step is to create an empty image file of an appropriate size. For our example, we will be creating a 500MiB image file (with a MiB being defined by IEC as 1024×1024 bytes, also known as a Mebibyte).

This task can be accomplished in many ways. The most standard way is to use the dd command, which is available and installed in all GNU/Linux distributions, as part of the GNU coreutils software package.

$ dd if=/dev/zero of=bbb.img bs=1M count=500

In the above command, we create a file named bbb.img, filled with zeroes, using 500 blocks of 1MiB each.

Another way is to make use of a little utility from QEMU.

$ qemu-img create bbb.img 500M

Partition the image

The next step is to create partitions inside the empty image file, as if it were a physical storage media. We use sfdisk for this task and we provide all the necessary parameters via standard input.

$ sudo sfdisk --in-order --Linux --unit M bbb.img << EOF

In the above example, we create two partitions inside our image file. The first one will be the boot partition, starting at an offset of 1MiB, with a size of 48MiB and partition id “W95 FAT16 (LBA)”. The second one will consume all remaining space (451MiB in our example) and will have the default partition id (“Linux”).

Format and mount the partitions

As with any newly-partitioned media, we also have to create filesystems inside our partitions.

However, before we do that, we will use the excellent kpartx command from multipath-tools, to make the handling of the partitions inside our image easier.

$ sudo kpartx -av bbb.img

Keep note of the output of the above command, in our example it was:

add map loop0p1 (253:0): 0 98304 linear /dev/loop0 2048
add map loop0p2 (253:1): 0 923648 linear /dev/loop0 100352

We are mainly interested in the loop device name (in our case loop0).

The above command makes use of the device mapper mechanism of the linux kernel to create virtual block devices for the two partitions inside our image. Assuming that kpartx reported loop0 as the loop device name, our two partitions will now be available as /dev/mapper/loop0p1 and /dev/mapper/loop0p2.

We can now format our partitions and mount them in temporary folders. We use FAT16 for the boot partition and assign the label “boot” to it, and EXT4 for the root partition and assign the label “rootfs” to it.

$ sudo mkfs.vfat -F 16 /dev/mapper/loop0p1 -n boot
sudo mkfs.ext4 /dev/mapper/loop0p2 -L rootfs
mkdir -p tmpmnt/boot
mkdir -p tmpmnt/rootfs
sudo mount /dev/mapper/loop0p1 tmpmnt/boot/
sudo mount /dev/mapper/loop0p2 tmpmnt/rootfs/

Make sure that you replace the loop device names with whatever was reported when you executed the kpartx command.

We are now ready to add files to our image.

Adding files to image

With both our partitions mounted as virtual block devices, we can copy any files we like into them, using any standard file copying method, be it command-line or graphical.

For a typical BeagleBone Black installation, we will be copying the bootloader (u-boot), the linux kernel image (zImage) and the compiled device tree structures (.dtb files) to the boot partition, while the actual root filesystem and any linux kernel modules will be copied to the root partition.

You can refer to the BeagleBone Black page on for more information on how to obtain these files and where exactly to copy them inside your image file.

You can also check out the Debian Live project if you are looking for a way to generate your own root file system from scratch.

Assuming that you have the bootloader, kernel and filesystem, make sure that you first copy the MLO file, followed by the u-boot.img file of the bootloader into an empty, freshly formatted FAT16 boot partition. The remaining files can be copied in any order.

Finish image creation

When we are done with adding files to the image, we must make sure that all files have finished being copied to the image, unmount the virtual block devices and release them.

$ sync
sudo umount tmpmnt/boot/
sudo umount tmpmnt/rootfs/
sudo kpartx -dv bbb.img

That’s all. The image is now ready and you can use it as it is, or copy it to a microSD card.

Copy image to microSD card (optional)

To copy the image file to a microSD card, you can use the standard dd command.

$ sudo dd if=bbb.img of=[block_device]

Alternatively, we suggest using ddrescue, which has a more verbose output.

$ sudo ddrescue -f bbb.img [block_device]

In the above commands, replace [block_device] with the block device name of your microSD card (such as /dev/sdx).


Tinkering for the masses

3d printer reprapHumans have always been good at making things, from tools and machines, to constructions and works of art. However, as the manufacturing process evolved from basic crafting, through the industrial revolution and into high-precision automated manufacturing, the cost of the equipment required for making anything useful increased to the point where only a very small part of the human society could afford the investment.

This oligopoly of production facilities is to the detriment of our society, since it greatly restricts the rate of introduction of novel and disruptive inventions. During the last five years though, a new concept has emerged to challenge this well-established centralized production model.

Distributed manufacturing is the concept of making all the necessary production tools and facilities accessible to everyone, in order to arrive to localized and demand-driven distributed production. One of the key technologies to distributed manufacturing is 3D printing.

3D printing is the fascinating process of making a solid object from a digital computer model. In other words, what starts as a virtual object in our computer screen, becomes a real object that we can see, touch and use in the world that we live in!

3D printing technology has been around for some years now. Though the idea was originally introduced in the early 80s, it took two decades for it to become attractive to the manufacturing industry. My first contact with 3D printing was in the early 2000s when I studied the applications of 3D rapid prototyping for medical applications as part of a university course in 3D modeling technologies for medical applications.

Later on, in 2010, while I was attending FOSDEM in Brussels, I saw the introduction of RepRap, one of the first low-cost open hardware 3D printers for domestic use. I was very impressed by the idea of distributed manufacturing and self-replicating machines, as advocated by the inventors of RepRap. I believe that it is thanks to the market pressure applied by RepRap and all its peer machines that, according to an article in the Bits blog of the New York Times, the cost of 3D printers has decreased dramatically since about 2010, with machines that used to cost 20K USD costing significantly less than 1K USD.

With this sudden drop in the prices of 3D printers, we’ve also seen the appearance of websites offering 3D printing services. Today, whether you own a 3D printer or not, it is simpler and more accessible than ever to simply sit in front of your computer, make a 3D model, click on a couple of buttons and create a real-world object.

Well, not really! As I’m sure many people from the manufacturing industry will know very well, it turns out that it is one thing to design something in the perfect theoretical world of CAD software, and a completely different thing to try and manufacture it, using a machine and materials with physical limitations. As an example, if a 3D printer can only make objects as thin as a few millimeters, you cannot manufacture something like a needle with it.

What we need then is some sort of validation software, a tool that, given the limitations of our process, it can guide us into designing a manufacturable 3D model.

Enter Blender!

Blender is an open source 3D modeling and animation software, one of the very impressive examples of free software. Like most 3D modeling tools, Blender already supports 3D printing modeling and file-formats (since 2002). What makes Blender different though is that, since version 2.67 (released in May 2013), it provides real-time Mesh Analysis and a 3D Printing Toolbox.

blender mesh thickness analysis

Real-time mesh thickness and sharpness checking with Blender

With these new features, Blender offers the possibility to:

  • get statistics such as object volume and surface area.
  • check whether the object is solid.
  • detect geometric problems such as mesh intersections, zero length edges,zero area faces and distorted faces.
  • check the thickness and sharpness of surfaces.
  • check for overhang.
  • clean the model by removing isolated faces, edges and vertices, as well as distorted faces.
  • re-scale based on a target volume or maximum allowed length.

3D printing for the massesFurthermore, the Blender Foundation has produced a 3+ hours training DVD where Dolf Veenvliet, a Dutch artist who uses 3D printing and Blender for sculpture design, explains how to make the most of these new tools. It includes a basic introduction to Blender itself, a discussion on the new tools for 3D printing, advice for good quality 3D prints and sample models to experiment with. You can also watch the introduction here.

Happy tinkering 🙂


Advances of open hardware in the scientific community

Open Source Hardware logoEven since CERN launched the Open Hardware initiative in 2011, the idea of open hardware has been gaining momentum within the scientific community.

CERN has been a very strong supporter of open hardware design methodologies as a platform for sharing ideas and results with the rest of the scientific community. To this end, and recognizing that the existing open source licenses are pretty much software-oriented (and as such they cannot be easily applied to hardware designs, at least not without leaving room for ambiguities), they introduced the CERN OHL (Open Hardware License). Furthermore, they supported the creation of the Open Hardware Repository, a website dedicated to hosting open hardware projects.

Among the many interesting projects and tools hosted today at the Open Hardware Repository, our attention was drawn to the FMC projects page, a growing collection of mezzanine and carrier boards complying to the VITA 57 (aka. FMC) standard. The list of boards is impressive, as is their functionality. Many of those boards are designed for use in important scientific experiments.

Other notable projects include White Rabbit, a fully deterministic Ethernet-based network for general purpose data transfer and synchronization, whose developers claim that it can synchronize over 1000 nodes with sub-nanosecond accuracy over fiber lengths of up to 10 km, and HDL Core Lib, a collection of reusable generic HDL cores, such as memory and I/O interface controllers.

The value of this repository cannot be underestimated, either as a rich library of projects that can be re-used, adapted and improved, or as an excellent educational tool for aspiring electronic hardware designers. One can only hope that the collection of open hardware projects will keep growing and that the insight demonstrated by the scientific community will be followed by others as well.


The state of open source Linux drivers for ARM SoC GPUs

Linux software glxgears runnning on ARM SoC GPUOne of the main hurdles in designing an embedded Linux computing solution based on one of the many available ARM System-on-Chip products is that of the (lack of) availability of a proper display device driver.

Indeed, there is still a lot left to be desired on the topic of Linux graphics support from the ARM SoC manufacturers. And while this might be acceptable for many “headless” embedded applications, it is definitely a big issue when there is a need for a responsive graphical user interface, particularly if the target application requires 3D accelerated graphics.

In order to address this problem, several open source projects have been initiated, each with the aim of providing an open source driver for a particular ARM SoC. Some of them are backed by their respective ARM SoC manufacturers, others are purely based on reverse engineering.

However, each of these projects is in some state of completeness, with different development roadmaps and priorities. As such, the answer to the question “which ARM SoC GPU is better supported in Linux right now?” is not not an easy one.

There is a very informative post over at Emmanuel Deloget’s Blog, regarding the state of open source linux drivers for SoC GPUs, such as those found within ARM SoCs. This topic is further discussed in an interesting follow-up interview with developers of various SoC GPU open source drivers.