BitBaking Software Packages and Images

The command that does everything in the correct order, parallelizing whenever possible and reporting errors in Yocto (and OpenEmbedded, on which Yocto is based), is BitBake, which calls a series of actions for each software recipe (files ending with .bb). BitBake

1. fetches sources and unpacks and verifies the checksum,

2. configures software packages,

3. compiles software packages in the desired architecture (some for the host, some for the target system, as needed),

4. installs in a host or native sysroot directory, and

5. creates software packages and installs them in the target image or directory.

The bitbake command is mostly called with the desired recipe as a single argument, but it also has some options to control the build process or clean up after a failed build, to avoid errors from leftover files. The standard command for building the Poky sample distribution would be

bitbake core-image-minimal

Of course, the real name of the target image is provided by the target distribution's build recipes.

A Simple Raspberry Pi "Hardware Up" Image

A good start for building Raspberry Pi images based on Yocto/Poky is the Board Support Package layer meta-raspberrypi from Yocto Project, which is available under the MIT license [4]. It features recipes to build a recent kernel, base system (SysVinit or systemd – your choice), and embedded Qt5 for building applications running directly on the framebuffer (which I will probably not use; Knoppix needs full X11 support to provide a common desktop). The simple original image is created by

bitbake rpi-hwup-image

which builds a kernel, bootloader, and root filesystem as an SD card image and needs about two hours for the first run. This SD card image successfully boots the Raspberry Pi 2 into a shell and even supports the serial port connection over GPIO pins.

More Layers

The meta-office layer that contains LibreOffice was fetched from GitHub [5] and meta-lxde from OpenEmbedded [6]. If space is tight on the disk used for building the distro, adding this line to build/conf/local.conf makes sure that unpacked sources and temporary files are being removed after successfully building a component:

INHERIT += "rm_work"

The current layer configuration for Knoppix for Raspberry Pi is set forth in build/conf/bblayers.conf shown in Listing 2.

The meta-raspi-knoppix directory contains all recipes for Knoppix-specific packages, custom kernel configurations and patches, and software choices. The contents of file meta-raspi-knoppix/recipes-core/images/rpi-knoppix-image.bb are shown in Listing 3.

The current feature list for Knoppix for Raspberry Pi includes:

• Cloop block compression. Unlike the Intel/AMD architecture DVD version of Knoppix, compression is not really needed for space reasons, because the usual Raspberry Pi SD card size of 8GB is plenty. However, if the system is compressed, physical reads are reduced to about a third of the usual volume, which may speed up read access and makes it easier to update the system in the form of compressed files containing all essential data except for the user's private files and configuration. Benchmarks for the choice of fastest decompression algorithm on the Raspberry Pi's CPU architecture need to show whether there is a substantial performance gain in this approach.
• AuFS [7] stacked filesystem. If system data is compressed in a read-only cloop container file, the user's changes need to be stored inside a writable partition mounted as overlay.
• ADRIANE audio desktop assisting blind computer users.
• Accelerated graphics support for Compiz.
• LXDE, LibreOffice, browser(s), ….

AuFS and cloop have already been tested successfully as patches for the kernel, and both are working fine on the architecture (although the gzip algorithm implementation seems much slower on ARM than on Intel/AMD).

The build process for the Knoppix image is started with:

bitbake rpi-knoppix-image

Because of the libreoffice package, the build process now takes half a day on my build machine, compared with the two hours of the initial "minimal" image.

If a recipe fails to build in the process, it might be necessary to remove the sstate-cache files for that component to force a "clean build" of all included binaries:

bitbake -c cleansstate libreoffice

One very useful debugging tool is the devshell subcommand of bitbake; for example:

bitbake -c devshell linux-raspberrypi

Instead of building a package, this command will change directory to the unpacked sources and then start an xterm terminal window with a shell – with all variables correctly set for the recipe – and allow a manual build, as in the traditional

./configure
make
...

to detect errors in the build process and allow manually changing files in the temporary build folders.

After all required recipes are completed in

bitbake rpi-knoppix-image

(which adds up to around 8,000 tasks that BitBake shows during the build process), an SD card image resides in build/tmp/deploy/images/raspberrypi2/ that can be flashed to an SD card. For example, for an MMC card reader, use:

dd if=rpi-knoppix-image-raspberrypi2.rpi-sdimg of=/dev/mmcblk0 bs=1M

Booting the image on Raspberry Pis 2 and 3 worked perfectly for me, although I'm not yet starting the graphical environment and haven't changed the startup procedure to the Knoppix-specific "single shell script" boot. Of course, the Yocto-created image does not offer much of the software yet that you would get in a Raspbian installation, but it's comparably small and only contains software really needed for now.

I will continue writing about the next steps of creating Knoppix for Raspberry Pi in the next issue.

The Author

Klaus Knopper is an engineer, creator of Knoppix, and co-founder of LinuxTag expo. He works as a regular professor at the University of Applied Sciences, Kaiserslautern, Germany.