Chapter 6: Selecting a Build System

In the preceding chapters, we covered the four elements of embedded Linux and showed you, step by step, how to build a toolchain, a bootloader, a kernel, and a root filesystem, before combining them into a basic embedded Linux system. And there are a lot of steps! Now, it is time to look at ways to simplify this process by automating it as much as possible. We will look at how embedded build systems can help and look at two of them in particular: Buildroot and the Yocto Project. Both are complex and flexible tools, and it would require an entire book to describe how they work in full. In this chapter, I only want to show you the general ideas behind build systems. I will show you how to build a simple device image to get an overall feel of the system, and then how to make some useful changes using the Nova board example from the previous chapters, as well as the Raspberry Pi 4.

In this chapter, we will cover the following topics:

• Comparing...

Technical requirements

To follow along with the examples in this chapter, make sure you have the following:

• A Linux-based host system with a minimum of 60 GB of available disk space
• Etcher for Linux
• A microSD card reader and card
• A USB to TTL 3.3V serial cable
• A Raspberry Pi 4
• A 5V 3A USB-C power supply
• An Ethernet cable and port for network connectivity
• A BeagleBone Black
• A 5V 1A DC power supply

All the code for this chapter can be found in the Chapter06 folder of this book's GitHub repository: https://github.com/PacktPublishing/Mastering-Embedded-Linux-Programming-Third-Edition.

Comparing build systems

I described the process of creating a system manually in Chapter 5, Building a Root Filesystem, as the Roll Your Own (RYO) process. It has the advantage that you are in complete control of the software, and you can tailor it to do anything you like. If you want it to do something truly odd but innovative, or if you want to reduce the memory footprint to the smallest size possible, RYO is the way to go. But, in the vast majority of situations, building manually is a waste of time and produces inferior, unmaintainable systems.

The idea of a build system is to automate all the steps I have described up to this point.
A build system should be able to build, from upstream source code, some or all of
the following:

• A toolchain
• A bootloader
• A kernel
• A root filesystem

Building from upstream source code is important for a number of reasons. It means that you have the peace of mind that you can rebuild at any time, without external dependencies...

Distributing binaries

Mainstream Linux distributions are, in most cases, constructed from collections of binary (precompiled) packages in either RPM or DEB format. RPM stands for the Red Hat package manager and is used in Red Hat, SUSE, Fedora, and other distributions based
on them. Debian and Debian-derived distributions, including Ubuntu and Mint, use
the Debian package manager format known as DEB. In addition, there is a lightweight format specific to embedded devices known as the Itsy package format or IPK, which is based on DEB.

The ability to include a package manager on the device is one of the big differentiators between build systems. Once you have a package manager on the target device, you have an easy path to deploy new packages to it and to update the existing ones. I will talk about the implications of this in Chapter 10, Updating Software in the Field.

Introducing Buildroot

The current versions of Buildroot are capable of building a toolchain, a bootloader, a kernel, and a root filesystem. It uses GNU Make as the principal build tool. There is good online documentation at https://buildroot.org/docs.html, including The Buildroot user manual at https://buildroot.org/downloads/manual/manual.html.

Background

Buildroot was one of the first build systems. It began as part of the uClinux and uClibc projects as a way of generating a small root filesystem for testing. It became a separate project in late 2001 and continued to evolve through to 2006, after which it went into a rather dormant phase. However, since 2009, when Peter Korsgaard took over stewardship, it has been developing rapidly, adding support for glibc-based toolchains and a greatly increased number of packages and target boards.

As a matter of interest, Buildroot is also the ancestor of another popular build system, OpenWrt (http://wiki.openwrt.org), which forked...

Introducing the Yocto Project

The Yocto Project is a more complex beast than Buildroot. Not only can it build toolchains, bootloaders, kernels, and root filesystems as Buildroot can, but it can generate an entire Linux distribution for you with binary packages that can be installed at runtime. The build process is structured around groups of recipes, similar to Buildroot packages but written using a combination of Python and shell script. The Yocto Project includes a task scheduler called BitBake that produces whatever you have configured, from the recipes. There is plenty of online documentation at https://www.yoctoproject.org.

Background

The structure of the Yocto Project makes more sense if you look at the background first. Its roots are in OpenEmbedded (https://openembedded.org), which, in turn, grew out of a number of projects to port Linux to various handheld computers, including the Sharp Zaurus and the Compaq iPaq. OpenEmbedded came to life in 2003 as the build system...

Summary

In this chapter, you learned how to use both Buildroot and the Yocto Project to configure, customize, and build embedded Linux images. We used Buildroot to create a BSP with a custom U-Boot patch and device tree specification for a hypothetical board based on the BeagleBone Black. We then learned how to add our own code to an image in the form of a Buildroot package. You were also introduced to the Yocto Project, which we will cover in depth in the next two chapters. In particular, you learned some basic BitBake terminology, how to write an image recipe, and how to create an SDK.

Don't forget that any devices you create using these tools will need to be maintained in the field for a period of time, often over many years. Both the Yocto Project and Buildroot provide point releases for about 1 year after the initial release, and the Yocto Project now offers long term support for at least 2 years. In either case, you will find yourself having to maintain your release yourself...

Further reading

The following resources contain more information about the topics that were introduced in this chapter:

• The Buildroot user manual, Buildroot Association: http://buildroot.org/downloads/manual/manual.html
• Yocto Project documentation, Yocto Project: https://www.yoctoproject.org/documentation
• Embedded Linux Development Using the Yocto Project Cookbook, by Alex González