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:

• 150MHz RDC CPU, Intel 486SX compatible
• 1 watt power consumption (200mA @5v)
• 68mm x 28mm x 19mm
• 32MB SDRAM/1MB Flash
• OHCI/EHCI USB 2.0
• 10/100 Ethernet
• Serial console 115200 baud
• 4-pin JTAG (can be used as GPIO)
• 2 GPIO (1 LED, 1 button)
• Linux 2.6.27.5 + 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, it seems that you have to make your own cable.

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.

In addition to root filesystem generation, Buildroot is also known for its ability to generate a uClibc-based cross-compilation toolchain. Buildroot used to be for quite some time the only way to generate a toolchain based on this size-effective C library, but it is no longer the case with Crosstool-NG supporting glibc, uClibc and eglibc.

However, I’ve personaly never been really satisfied with uClibc generation of cross-compiling toolchains:

• It mixes the process of the cross-compilingn toolchain generation with the process of root filesystem generation, which are, in my opinion, two very different processes. Once your toolchain is generated, you generally don’t touch it, but regenerate your root filesystem dozens or hundred of times until all your components are here and properly integrated.
• The attention paid to toolchain generation in the Buildroot project itself is relatively small, while other projects like Crosstool-NG or vendors like Codesourcery, are specifically dedicated to providing toolchains. The fact that, for example, uClibc is the only C library supported is one example of this.
• It might necessary, for various reasons, make sense to use an already existing toolchain.

Support for the usage of external toolchains has already been present in Buildroot for a long time, but wasn’t developed enough to be easily usable. Months ago, I’ve started to improve the situation (here, here, here and here), and last week, two other patches have been integrated.

• The first patch, visible here removes the ugly configuration option that allows to configure the set of libraries that must be copied to the target filesystem, and replaces it with a nice selection of the C libary type: uClibc or glibc. It makes it clear that generating Linux system with the glibc library is possible with Buildroot, even if Buildroot has often been advertised as a uClibc only tool.
• The second patch, visible here adds checks for the conformity of Buildroot configuration versus the C library configuration. There are configuration options in Buildroot that must tell whether the C library supports IPv6, supports RPC, supports locale, supports large file, etc. These options must be set in the configuration interface according to the C library configuration, because some userspace packages depend on them. The added checks verify that the value set to these options match the configuration of your C library

So, now, external toolchains are a little bit easier to use with Buildroot, and your own vendor toolchain, Codesourcery toolchains or any other toolchain can be used with Buildroot. The only requirement is that the toolchain supports the sysroot feature, which is very common in most toolchains.

These instructions are derived from Embinux.org’s Android Porting Guide to Beagle Board, 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
wget http://android.git.kernel.org/repo
chmod +x repo

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

cd
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:

cd
wget http://free-electrons.com/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.

If your corporate network doesn’t let you use the git protocol, you can use our snapshot available on http://free-electrons.com/pub/demos/beagleboard/android/:

cd
tar --lzma -xvf beagledroid-git-20090603.tar.lzma

Building Android

make

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
../vendor/embinux/support-tools/beagle_build_kernel.sh

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)
p
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 http://free-electrons.com/pub/demos/beagleboard/android/MLO
http://free-electrons.com/pub/demos/beagleboard/android/u-boot.bin
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'
saveenv

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!

At 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?

Just a quick note after the announcement that has just been made at the Embedded Linux Conference (ELC) in San Francisco…

Tim Bird has just announced that the next European edition of ELC will be in Grenoble, France, on October 15-16. As the new conference home page says, it will be colocated with ESWEEK.

We are very excited about this news, as Grenoble is a not only a beautiful place, but also a very dynamic city full of universities and high-tech companies. We will do our best to incite people to attend the conference, and of course to speak about their projects and propose demos.

This is an exciting conference with a very interesting program, and we are proud to be part of it:

• Monday, April 6, 7:30-9:00 pm
  System size BOF (Michael)
• Tuesday, April 7, 11:00-11:50 am
  Update on filesystems for flash storage (Michael)
• Tuesday, April 7, 4:40-5:30 pm
  Building Embedded Linux Systems with Buildroot (Thomas)
• Wednesday, April 8, 1:00-1:45 pm
  Build tools BOF (Thomas)

If participate to this conference too, and if you are interested in the above topics, or in topics we covered in this blog, don’t hesitate to come and chat with us. We will both arrive on Saturday afternoon, so we could even meet before the conference starts.

If you can’t make it to this conference, we will also shoot and share videos as usual, so at least you won’t miss the technical contents. You will just miss the beer together…

For embedded users, the most important new feature is certainly the inclusion of Squashfs, a read-only compressed filesystem. This filesystem is very well-suited to store the immutable parts of an embedded system (applications, libraries, static data, etc.), and replaces the old cramfs filesystem which had some strong limitations (file size, filesystem size and limited compression).

Squashfs is a block filesystem, but since it is read-only, you can also use it on flash partitions, through the mtdblock driver. It’s fine as you just write the filesystem image once. Don’t hesitate to try it to get the best performance out of your flash partitions. Ideally, you should even use it on top of UBI, which would transparently allow the read-only parts of your filesystem to participate to wear-leveling. See our choosing filesystems presentation for details.

This new release also adds Fastboot support, at least for scsi probes and libata port scan. This is a step forward to reducing boot time, which is often critical in embedded systems.

2.6.29 also allows stripping of generated symbols under CONFIG_KALLSYMS_ALL, saving up to 200 KB for kernels built with this feature. This is nice for embedded systems with very little RAM, which still need this feature during development.

Another new feature of this kernel is the support for the Samsung S3C64XX CPUs. Of course, a lot of new boards and devices are supported, such as the framebuffer of the i.MX 31 CPU, or the SMSC LAN911x and LAN912x Ethernet controllers.

The other major features of this new kernel, not necessarily interesting for embedded systems are the inclusion of the btrfs filesystem, the inclusion of the kernel modesetting code, support for WiMAX, scalability improvements (support of 4096 CPUs!), filesystem freezing capability, filesystem improvements and many new drivers.

For more details on the 2.6.29 improvements, the best resource is certainly the human-readable changelog written by the KernelNewbies.org community.

I remember using to this project and contributing to it back in 2004 when I still was an intern during my studies. One of my contributions was the writing of documentation for the project, which is still the official documentation. Since 2004, the project has evolved, but there was no clear maintainer and no stable releases. The developer community around Buildroot was not completely satisfied since no one was merging the proposed fixes and improvements, since there was no official maintainer. And Buildroot was difficult to use for users because it didn’t offer any kind of stable releas : users had to pick a random SVN checkout and cross fingers to get a reasonably-working version.

In January 2009, as part of the traditionnal new year’s resolution, Peter Korsgaard, one of the active Buildroot developer, volunteered to step up as the official maintainer and to deliver releases. And indeed, he integrated many patches that were floating around, released several release candidates before releasing Buildroot 2009.02 on February, 12th. Since then he continues to make very interesting improvements to Buildroot, replies on the mailing list, review and merge the proposed patches. A new bug tracker has been set up, and the source code will soon be moved over the Git distributed version control system.

Definitely, it’s a new life starting for the Buildroot project. As a long-time user and occasional contributor of the project, I’m glad to see such evolution.

Here are the available videos, with my personal comments. Of course, except the talk about CMake, all of them come from the embedded devroom. Thanks to the speakers for sharing their knowledge and presenting their projects !

• Wt, a C++ web toolkit, for rich web interfaces to embedded systems, by Pieter Libin (Noesis Solutions)
  Video (44 minutes, 124M)
  Presentation of a Web application generator, which generates a Web application including a web server from a C++ description. The C++ design is based on many ideas coming from Qt, which eases the creation of the graphical application. Certainly a very interesting tool for embedded systems.
• Hacking with modular hardware: the BUG, by Ken Gilmer (Bug Labs)
  Video (43 minutes, 129M)
  The BUG is a set of hardware modules that can be combined together. A base module contains the CPU, memory and other basic components, while additional modules can provide GPS, Wifi, webcam, I/O lines and many others. Of course, it comes with a completely free software SDK. Can be an interesting starting point for prototyping or hobbyist embedded hacking, even though the hardware is quite expensive.
• Building Embedded Linux Systems with PTXdist, by Robert Schwebel (Pengutronix)
  Video (68 minutes, 151M)
  A very good presentation on why system building tools are needed for Embedded Linux systems (cross-compiling issues, etc.), and how PTXdist fits this need. Even though I’m personally quite fan of Buildroot, PTXdist’s competitor, the presentation was very interesting.
• Development on the OpenMoko with hackable:1, by Pierre Pronchery (Bearstech)
  Video (55 minutes, 189M)
  A hands-on lab on the OpenMoko, which unfortunately was too short to be really interesting, and restricted to only the 10-12 people at the front of the room. Interesting for the people who did it, probably not so interesting to watch afterwards.
• Development and Certification of Linux-Based Fire Safety & Security Systems, by Baurzhan Ismagulov (Siemens)
  Video (47 minutes, 124M)
  The topic of the talk was really appealing, because the use of free software in environments where human life is in danger has always caused many debates and discussions. Unfortunately, the talk completely misses the point : the speaker spent the whole talk discussing Germany-specific rules and laws for the certification of fire safety and security systems, almost without saying a word on how Linux can match these rules.
• Maemo on BeagleBoard, by Juha Kallionen (Nokia)
  Video (20 minutes, 51M)
  Good talk, but not a lot of content, outside of « Hey, we run Maemo on BeagleBoard, try it !». A kind of announcement talk, I would say.
• Advanced power management for OMAP3, by Peter De Schrijver (Nokia)
  Video (49 minutes, 169M)
  A very interesting, in-depth, technical talk about the power management features of the OMAP3 CPU and how these features can be used by the Linux kernel.
• Emdebian 1.0 release - small and super small Debian, by Neil Williams (Debian)
  Video (86 minutes, 257M)
  Again, another interesting talk about the status of Emdebian, which has just reached 1.0. Neil described both Emdebian Crush and Emdebian Grip, that are two different approaches for making Debian more suitable for embedded systems. Very good progress has been made, and Emdebian is certainly something that should now be considered as a distribution for embedded systems.
• CMake - what can it do for your project, by Alexander Neundorf
  Video (45 minutes, 167M)
  A general introduction to CMake, with lots of examples and demonstrations. Very nice for those who never had the opportunity to look at CMake.

See our conference videos page for more videos.

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 bulky.
• 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 is the one I eventually chose. It is beautiful, small and light, and just works out of the box when you plug it in. Support for this device to Linux 2.6.26 through the same driver. You should be able to use it in recent distros.

So, 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. If you decide to buy it, just make sure that it bears the MB442Z/A reference in your shopping cart. If the reference changes, it could mean that they switched to another chipset, without changing the model name. This happens often with other vendors, unfortunately.

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