Power measurement with BayLibre’s ACME cape

When working on optimizing the power consumption of a board we need a way to measure its consumption. We recently bought an ACME from BayLibre to do that.

Overview of the ACME

The ACME is an extension board for the BeagleBone Black, providing multi-channel power and temperature measurements capabilities. The cape itself has eight probe connectors allowing to do multi-channel measurements. Probes for USB, Jack or HE10 can be bought separately depending on boards you want to monitor.


Last but not least, the ACME is fully open source, from the hardware to the software.

First setup

Ready to use pre-built images are available and can be flashed on an SD card. There are two different images: one acting as a standalone device and one providing an IIO capture daemon. While the later can be used in automated farms, we chose the standalone image which provides user-space tools to control the probes and is more suited to power consumption development topics.

The standalone image userspace can also be built manually using Buildroot, a provided custom configuration and custom init scripts. The kernel should be built using a custom configuration and the device tree needs to be patched.

Using the ACME

To control the probes and get measured values the Sigrok software is used. There is currently no support to send data over the network. Because of this limitation we need to access the BeagleBone Black shell through SSH and run our commands there.

We can display information about the detected probe, by running:

# sigrok-cli --show --driver=baylibre-acme
Driver functions:
    Continuous sampling
    Sample limit
    Time limit
    Sample rate
baylibre-acme - BayLibre ACME with 3 channels: P1_ENRG_PWR P1_ENRG_CURR P1_ENRG_VOL
Channel groups:
    Probe_1: channels P1_ENRG_PWR P1_ENRG_CURR P1_ENRG_VOL
Supported configuration options across all channel groups:
    limit_samples: 0 (current)
    limit_time: 0 (current)
    samplerate (1 Hz - 500 Hz in steps of 1 Hz)

The driver has four parameters (continuous sampling, sample limit, time limit and sample rate) and has one probe attached with three channels (PWR, CURR and VOL). The acquisition parameters help configuring data acquisition by giving sampling limits or rates. The rates are given in Hertz, and should be within the 1 and 500Hz range when using an ACME.

For example, to sample at 20Hz and display the power consumption measured by our probe P1:

# sigrok-cli --driver=baylibre-acme --channels=P1_ENRG_PWR \
      --continuous --config samplerate=20
P1_ENRG_PWR: 1.000000 W
P1_ENRG_PWR: 1.210000 W
P1_ENRG_PWR: 1.210000 W

Of course there are many more options as shown in the Sigrok CLI manual.

Beta image

A new image is being developed and will change the way to use the ACME. As it’s already available in beta we tested it (and didn’t come back to the stable image). This new version aims to only use IIO to provide the probes data, instead of having a custom Sigrok driver. The main advantage is many software are IIO aware, or will be, as it’s the standard way to use this kind of sensors with the Linux kernel. Last but not least, IIO provides ways to communicate over the network.

A new webpage is available to find information on how to use the beta image, on https://baylibre-acme.github.io. This image isn’t compatible with the current stable one, which we previously described.

The first nice thing to notice when using the beta image is the Bonjour support which helps us communicating with the board in an effortless way:

$ ping baylibre-acme.local

A new tool, acme-cli, is provided to control the probes to switch them on or off given the needs. To switch on or off the first probe:

$ ./acme-cli switch_on 1
$ ./acme-cli switch_off 1

We do not need any additional custom software to use the board, as the sensors data is available using the IIO interface. This means we should be able to use any IIO aware tool to gather the power consumption values:

  • Sigrok, on the laptop/machine this time as IIO is able to communicate over the network;
  • libiio/examples, which provides the iio-monitor tool;
  • iio-capture, which is a fork of iio-readdev designed by BayLibre for an integration into LAVA (automated tests);
  • and many more..


We didn’t use all the possibilities offered by the ACME cape yet but so far it helped us a lot when working on power consumption related topics. The ACME cape is simple to use and comes with a working pre-built image. The beta image offers the IIO support which improved the usability of the device, and even though it’s in a beta version we would recommend to use it.

A Kickstarter for a low cost Marvell ARM64 board

At the beginning of October a Kickstarter campaign was launched to fund the development of a low-cost board based on one of the latest Marvell ARM 64-bit SoC: the Armada 3700. While being under $50, the board would allow using most of the Armada 3700 features:

  • Gigabit Ethernet
  • SATA
  • USB 3.0
  • miniPCIe

ESPRESSObin interfaces

The Kickstarter campaign was started by Globalscale Technologies, who has already produced numerous Marvell boards in the past: the Armada 370 based Mirabox, the Kirkwood based SheevaPlug, DreamPlug and more.

We pushed the initial support of this SoC to the mainline Linux kernel 6 months ago, and it landed in Linux 4.6. There are still a number of hardware features that are not yet supported in the mainline kernel, but we are actively working on it. As an example, support for the PCIe controller was merged in Linux 4.8, released last Sunday. According to the Kickstarter page the first boards would be delivered in January 2017 and by this time we hope to have managed to push more support for this SoC to the mainline Linux kernel.

We have been working on the mainline support of the Marvell SoC for 4 years and we are glad to see at last the first board under $50 using this SoC. We hope it will help expanding the open source community around this SoC family and will bring more contributions to the Marvell EBU SoCs.

Embedded Linux training update: Atmel Xplained, and more!

Atmel SAMA5D3 Xplained boardWe are happy to announce that we have published a significant update of our Embedded Linux training course. As all our training materials, this update is freely available for everyone, under a Creative Commons (CC-BY-SA) license.

This update brings the following major improvements to the training session:

  • The hardware platform used for all the practical labs is the Atmel SAMA5D3 Xplained platform, a popular platform that features the ARMv7 compatible Atmel SAMA5D3 processor on a board with expansion headers compatible with Arduino shields. The fact that the platform is very well supported by the mainline Linux kernel, and the easy access to a wide range of Arduino shields makes it a very useful prototyping platform for many projects. Of course, as usual, participants to our public training sessions keep their board after the end of the course! Note we continue to support the IGEPv2 board from ISEE for customers who prefer this option.
  • The practical labs that consist in Cross-compiling third party libraries and applications and Working with Buildroot now use a USB audio device connected to the Xplained board on the hardware side, and various audio libraries/applications on the software side. This replaces our previous labs which were using DirectFB as an example of a graphical library used in a system emulated under QEMU. We indeed believe that practical labs on real hardware are much more interesting and exciting.
  • Many updates were made to various software components used in the training session: the toolchain components were all updated and we now use a hard float toolchain, more recent U-Boot and Linux kernel versions are used, etc.

The training materials are available as pre-compiled PDF (slides, labs, agenda), but their source code in also available in our Git repository.

If you are interested in this training session, see the dates of our public training sessions, or order one to be held at your location. Do not hesitate to contact us at training@bootlin.com for further details!

It is worth mentioning that for the purpose of the development of this training session, we did a few contributions to open-source projects:

Thanks a lot to our engineers Maxime Ripard and Alexandre Belloni, who worked on this major update of our training session.

ISEE working on IGEPv5 board with OMAP5

ISEE logoOur partner ISEE is famous for their IGEPv2 board that we use in our embedded Linux course. This board is both powerful (running at 1 GHz) and featureful (on-board WiFi and Bluetooth, many connectors and expansion capabilities).

The good news is that ISEE has started to develop a new IGEPv5 board, which will be based on the new OMAP5 processor from Texas Instruments. This processor features in particular 2 ARM Cortex A15 cores running at up to 2 GHz, DDR3 RAM support, USB3, full HD 3D recording, and supporting 4 displays and cameras at the same time. Can you imagine what systems you could create with such a CPU?

If you are interested in such a board, it is still time for you to give them your inputs and expectations.

What should a perfect OMAP5 board be like? Don’t hesitate to leave your comments on this blog post. Be sure that ISEE will pay attention to them.

Embedded Linux practical labs with the Beagle Board

Beagle boardGet valuable embedded Linux experience using our practical labs on a Beagle Board.

We were asked to customize our embedded Linux training session with specific labs on OMAP 3530 hardware. After a successful delivery on the customer site, using Beagle boards, here are our training materials, released as usual under the terms of the Creative Commons Attribution-ShareAlike 3.0 license:

If you are the happy owner of such a board (both attractive and cheap), or are interested in getting one, you can get valuable embedded Linux experience by reading our lecture materials and by taking our practical labs.

Here’s what you would practise with if you decide to take our labs:

  • Build a cross-compiling toolchain with crosstool-NG
  • Compile U-boot and the X-loader and install it on MMC and flash storage.
  • Manipulate Linux kernel sources and apply source patches
  • Configure, compile and boot a Linux kernel for an emulated PC target
  • Configure, cross-compile and boot a Linux kernel on your Beagle Board
  • Build a tiny filesystem from scratch, based on BusyBox, and with a web server interface. Practice with NFS booting.
  • Put your filesystem on MMC storage, replacing NFS. Practice with SquashFS.
  • Put your filesystem on internal NAND flash storage. Practice with JFFS2 too.
  • Manually cross-compile libraries (zlib, libpng, libjpeg, FreeType and DirectFB) and a DirectFB examples, getting familiar with the tricks required to cross-compile components provided by the community.
  • Build the same kind of graphical system automatically with Buildroot.
  • Compile your own application against existing libraries. Debug a target application with strace, ltrace and gdbserver running on the target.
  • Do experiments with the rt-preempt patches. Measure scheduling latency improvements.
  • Implement hotplugging with mdev, BusyBox’s lightweight alternative to udev.

Note that the labs were tested with Rev. C boards, but are also supposed to work fine with Rev. B ones. You may also be able to reuse some of our instructions with other boards with a TI OMAP3 processor.

Of course, if you like the materials, you can also ask your company to order such a training session from us. We will be delighted to come to your place and spend time with you and your colleagues.

CALAO boards supported in mainline U-Boot

CALAO SystemsI’m happy to announce that a couple days ago, support for the CALAO SBC35-A9G20, TNY-A9260 and TNY-A9G20 boards made its way into the U-Boot git repository. Sadly, it’s not possible to boot from an MMC/SD card with the SBC35 yet, but it’s something I’m currently working on.

Support for all these cards will be available in the next U-Boot release, due in November.

The Bifferboard: tiny, low power embedded x86 board

A nice, cheap and tiny x86 embedded board that runs Linux and just consumes 1W. It has all the basic connectivity you need in an embedded system.

As you may already know, we maintain a list of attractive and Linux friendly embedded boards. Whenever we find a new board that is attractive and meets our strict criteria (supporting Linux or other free kernels, public pricelist, public documentation and website with an English version), we add this board to our list. This way, we don’t forget about any useful board, and we can offer useful guidance to our customers and to any embedded system developer looking for a suitable hardware platform.

Somebody at Bifferos.com has just contacted us to let us know about their Bifferboard product. Here are its announced features:

  • Bifferboard150MHz RDC CPU, Intel 486SX compatible
  • 1 watt power consumption (200mA @5v)
  • 68mm x 28mm x 19mm
  • 32MB SDRAM/1MB Flash
  • 10/100 Ethernet
  • Serial console 115200 baud
  • 4-pin JTAG (can be used as GPIO)
  • 2 GPIO (1 LED, 1 button)
  • Linux + OpenWrt
  • 29 UK pounds

The board has two components: the CPU board, and the I/O one, offering Ethernet and USB host connectivity. For a serial port, you can order a special cable from their shop, which connects to a USB port on your workstation.

Thanks to its low power consumption, the Bifferboard can even be powered by USB. According to its makers, the board can do anything a NSLU2 device can do. It is just cheaper (approximately 33 EUR at the time of this writing).

Last but not least, most Bifferboard hardware can be emulated with QEMU.

While it could also be suitable for mass production projects, it can be at least a nice platform for prototypes, hobby, research and educational projects.

Of course, if you know about other attractive boards that we could add to our list, please post a comment or send us e-mail.

Building Android on Beagle

Note: these instructions are now out of date and refer to URLs which no longer exist. See the elinux.org wiki for more recent instructions.

These instructions are derived from Embinux.org’s Android Porting Guide to Beagle Board (the corresponding web page no longer exists), based on their work to port Android on the Beagle board. They correct multiple inaccuracies in this guide, and also add many useful details.

These instructions were tested on xubuntu 9.04. There shouldn’t be many differences if you use other recent Ubuntu or Debian versions.

Install needed software packages

At the time of this writing, note that Android requires Sun’s Java5 JDK, and doesn’t support the Java6 one.

apt-get update
apt-get dist-upgrade
apt-get install git-core bison sun-java5-jdk flex g++ zlib1g-dev
apt-get install  libx11-dev libncurses5-dev gperf uboot-mkimage

Android also uses its own repo script as a git front-end:

mkdir -p ~/bin
cd ~/bin
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > repo
chmod +x repo

We are also going to need a 2007q3 toolchain from Code Sourcery

wget http://www.codesourcery.com/sgpp/lite/arm/portal/package1787/public/arm-none-linux-gnueabi/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
cd /opt
sudo tar jxf arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

You could also get this toolchain from our website:

wget /pub/demos/beagleboard/android/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzma
cd /opt
sudo tar --lzma -xf ~/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzma

Download sources

Our instructions create a directory in your home directory, but of course, it can be placed anywhere!

 mkdir ~/beagledroid
 cd ~/beagledroid
 repo init -u git://labs.embinux.org/repo/android/platform/beaglemanifest.git/
 repo sync

Caution: this can take a lot of time, as this downloads and extracts 2.4 GB of data. On a fast workstation with a 500KB/s Internet connection, it took about 90 minutes.

Building Android


If your workstation has multiple CPUs, you could save a lot of time by running multiple jobs in parallel:

make -j 4

On our machine, this took about 4 hours!

Building the kernel

export CC_PATH=/opt/arm-2007q3/bin/arm-none-linux-gnueabi-
cd ~/beagledroid/kernel

Copying the Android root filesystem

Android’s root file system is generated in ~/beagledroid/out/target/product/generic

cd ~/beagledroid/out/target/product/generic
mkdir ~/beagledroid/rootfs
cp -a root/* ~/beagledroid/rootfs/
cp -a system/* ~/beagledroid/rootfs/system/
cd ~/beagledroid/rootfs
sudo chown -R root.root .
sudo chmod -R a+rwX data system 

Formatting an MMC/SD card

First connect your card reader to your workstation, with the MMC/SD card inside. Type the dmesg command to see which device is used by your workstation. Let’s assume that this device is /dev/sdb

Type the mount command to check your currently mounted partitions. If MMC/SD partitions are mounted, unmount them.

In a terminal edit partitions with fdisk:

sudo fdisk /dev/sdb

Delete any existing partition with the d command.

Now, create the boot partition:

Command (m for help): n 
Command action 
   e   extended 
   p   primary partition (1-4) 
Partition number (1-4): 1 
First cylinder (1-239, default 1): 1 
Last cylinder, +cylinders or +size{K,M,G} (1-239, default 239): +64M

Change its type to FAT32:

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Using the n command again, create a second partition filling up the rest of your card (just accept default values).

Now, format the partitions in your card:

sudo mkfs.vfat -n beagleboot -F 32 /dev/sdb1
sudo mkfs.ext3 /dev/sdb2

Remove and insert your card again. Your new partitions should be mounted automatically.

Copying data to the MMC/SD card

Start by copying the X-loader and U-boot on the first partition.

cd /media/beagleboot
wget /pub/demos/beagleboard/android/MLO
cp ~/beagledroid/kernel/arch/arm/boot/uImage .

Now copy the Android root filesystem to the second partition (assuming it is mounted on /media/disk:

sudo rsync -a ~/beagledroid/rootfs/ /media/disk/

Finish by unmounting your MMC/SD partitions:

sudo umount /media/beagleboot
sudo umount /media/disk

Boot setup

The last thing left to do is to specify how the board boots Linux.

Plug the Beagle board on your computer, and also connect it to a DVI-D monitor. Start minicom (corresponding to Hyperterminal in Windows) on /dev/ttyS0, or on /dev/ttyUSB0 if you are using a serial to USB adapter. Power up the board.

First, stop Minicom from truncating long lines by typing [Ctrl] [a] followed by z and w.

In the U-boot prompt, make the board boot automatically on the MMC/SD card:

setenv bootcmd 'mmc init;fatload mmc 0 80000000 uImage;bootm 80000000'

Now set the kernel command line arguments:

setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2 video=omapfb.mode=dvi:1280x720MR-24@50 init=/init rootfstype=ext3 rw rootdelay=1 nohz=off androidboot.console=ttyS2

You may need to adapt the video settings to the capabilities of your DVI display. You should now see Android boot!

Beagle board MMC boot myths?

Booting a Beagle board from an MMC/SD should be easier than what people tell you

Beagle boardAt the time of this writing, most documentation that you can find on the web about the Beagle board will tell you that you need to take special preparation steps if you wish to boot your board on an MMC/SD card:

  • The card requires a special geometry: 255 heads and 63 sectors per track
  • The first partition on the card, with a FAT type, must be marked as bootable
  • The X-loader (MLO file), must be copied to the first sectors of the first partition. As a consequence, you should copy this file first.

As my colleague Florent Peyraud and TI engineers started to suspect, all this is not always required. I’ve just made tests with my Rev C2 Beagle board:

  • I took a brand new MMC/SD card. fdisk showed that it had 57 heads and 56 sectors per track.
  • I created the partitions again, and didn’t flag the first one as bootable.
  • After formatting the first partition in FAT32 format, I first copied the u-boot.bin and uImage files, and then the MLO one.

After all this, I had no problem booting my Beagle board on the MMC/SD card. At least with my Rev C2 board, what TI engineers expected was true: the board romcode understood the FAT format, and therefore just needed a file with the MLO name, whatever its physical location on the card.

Does anyone know whether the requirements used to be true with earlier Beagle board romcode releases, or in special cases?

USB-Ethernet device for Linux

Useful device when you work with an embedded development board

For our Embedded Linux training sessions, I was looking for a USB to Ethernet device. Since Linux supported devices are often difficult to find, I’m glad to share my investigations here.

When you use an embedded development board, you must connect it to your computer with an Ethernet cable, for example to transfer a new kernel image to U-boot through tftp, or to make your board boot on a directory on your workstation, exported with NFS.

You could connect both the board and computer to your local network, which would still allow your computer to connect to the Internet while you work with the board. However, you may create conflicts on your local network if you don’t use DHCP to assign an IP address to your board (if your DHCP server even accepts this new device on the network). In a training environment, you are also likely to run out of Ethernet outlets in the training room if you have to connect 8 such boards. Hence, a direct connection between the board and your workstation’s Ethernet port is often the most convenient solution.

If you can’t use WIFI to keep your computer connected to the outside world, a good solution is to add an extra Ethernet port to your computer by using an USB-to-Ethernet device.

My colleague Thomas and I started looking for such devices that would be supported by Linux. Here are a few that we found:

  • D-Link DUB-E100. Supported by the USB_NET_AX8817X driver. However, this product is bulky and quite heavy (at least 100 grams).
  • TRENDnet TU2-E100. Supported by the same driver, but still bulk (August 2015 update: now replaced by a more recent version, now almost as small as the Apple one, and supported out of the box in Linux. See the comment about this device.)
  • Linksys USB 200m. Supported by the same Linux driver and has a much more acceptable size, but customer reviews complain that its connector can break easily.
  • Apple USB Ethernet Adapter. This should be working out of the box in Linux. At least the MB442Z/A or MC704ZM/A references did, but Apple now sells a new reference that might have a different chipset. It is beautiful, small and light. Support for this device (at least the references I mentioned) was added to Linux 2.6.26 through the same driver. You should be able to use it in recent distros.

Apple USB to EthernetSo, I recommend the Apple device. I event posted a comment on the Apple Store, titled “Perfect for Linux”! I hope the Apple droids won’t censor it. Don’t hesitate to buy it, so that we can confirm that the latest reference is supported too.

I can’t tell whether this could happen with Apple. This was the first Apple device I ever bought…