Open Embedded: An alternative way to build embedded Linux distributions

As embedded processors have grown more powerful and feature-rich, the popularity of the Linux operating system in embedded applications has grown in leaps and bounds. Although the fact that Linux is open source and free of licensing fees is one major driver of its popularity, another key driver is the wealth of application software and drivers available as a result of Linux’s widespread usage in the desktop and server arenas.

However, embedded developers cannot simply pick up desktop Linux distributions or applications for use in their systems. Broadly speaking, embedded Linux developers face three main challenges:

1. assembling a compatible combination of bootloader, kernel, library, application, and development tool components for the processor and peripherals used in their hardware;

2. correctly cross-building a multi-megabyte image; and

3. optimizing the various kernel and user-space components to reduce the footprint and associated memory cost.

Solutions to these challenges are far from straightforward and for a development team to achieve them requires significant effort and experience. Commercial embedded Linux vendors offer pre-tested solutions for particular embedded processors, but for developers who prefer a ‘roll your own’ approach to Linux, the Open Embedded (OE) build environment provides a methodology to reliably build customized Linux distributions for many embedded devices. A number of companies have been using OE to build embedded Linux kernel ports along with complete distributions, resulting in an increasing level of support to maintain and enhance key elements of the OE infrastructure.

In addition, a growing number of embedded Linux distributions (such as Angstrom) utilize OE. Although these distributions are not formally part of OE, they add to the attraction of using OE by providing ready-to-run starting points for developers. A final attraction is that some of the newer commercial distributions from companies such as MontaVista and Mentor Graphics are now based on OE. These provide additional tooling and commercially supported distributions.

In this article we present an overview of the key elements of the OE build environment and illustrate how these elements can be applied to build and customize Linux distributions. The Texas Instruments Arago distribution, which is based on the Angstrom distribution, will be used as example of how to create a new distribution based on OE and the distributions that already use it.

Most of the Arago- or Angstrom-based example scripts shown here have been modified slightly to more concisely demonstrate key concepts of OE. Developers should access the original scripts at the websites listed at the end of the article to view complete real-world implementations.

An Overview of Open Embedded

OE is based on BitBake, a cross-compilation and build tool developed for embedded applications. Developers use BitBake by creating various configuration and recipe files that instruct BitBake on which sources to build and how to build them. OE is essentially a database of these recipe (.bb) and configuration (.conf) files that developers can draw on to cross-compile combinations of components for a variety of embedded platforms.

OE has thousands of recipes to build both individual packages and complete images. A package can be anything from a bootloader through a kernel to a user-space application or set of development tools. The recipe knows where to access the source for a package, how to build it for a particular target, and ensures that a package’s dependencies are all built as well, relieving developers of the need to understand every piece of software required to add a particular capability to their application. OE can create packages in a variety of package formats (tar, rpm, deb, ipk) and can create package feeds for a distribution.

Most OE users will typically begin by selecting a particular distribution rather than building individual packages. The advantage of using an existing distribution is that it will often be necessary to select certain package versions to get a working combination. Distributions address this key function. They often provide a ‘stable’ build in addition to a ‘latest’ build to avoid the inherent instabilities that come from trying to combine the latest versions of everything.

A key benefit of OE is that it allows software development kit (SDK) generation. While some development teams may prefer to build their complete applications in OE, others may have a dedicated team that builds Linux platforms for application development teams to use. In these circumstances, the Linux platform team can generate a Linux distribution as a SDK that is easily incorporated into the build flow preferred by an application team. As a result, there is no need for application development teams to be OE experts.

A critical aspect of the OE database is that much of it is maintained by developers employed by parties with an interest in ensuring successful Linux distribution builds on embedded devices. This maintenance effort is critical given the amount of change occurring in the Linux kernel and application space.

A Quick Look at BitBake

The build tool developers are typically most familiar with is ‘make’, which is designed to build a single project based on a set of interdependent makefiles. This approach does not scale well to the task of creating a variety of Linux distributions each containing an arbitrary collection of packages (often hundreds of them), many of which are largely independent of each other, for an arbitrary set of platforms.

These limitations have led to the creation of a number of build tools for Linux distributions, such as Buildroot and BitBake. BitBake’s hierarchical recipes enable individual package build instructions to be maintained independently, but the packages themselves are easily aggregated and built in proper order to create large images. Thus it can build an individual package for later incorporation in a binary feed as well as complete images.

One important aspect of BitBake is that it does not dictate the way an individual package is built. The recipe (or associated class) for a package can specify any build tool, such as the GNU autotools, making it relatively straightforward to import packages into OE.

To address the need to select specific versions of packages that are known to work together and to specify the different embedded targets, BitBake uses configuration files.

BitBake fetches the package sources from the internet via wget (or any other Software Configuration Management tool such as Git or svn) using the location information in the recipe (Figure 1 below). It then applies any patches that are specified in the package description, which is a common requirement when cross-compiling packages for an embedded processor. The package collection is specified in the higher-level recipes such as those for images and tasks.



Since many developers will want to use an existing distribution, BitBake enables a developer to override distribution defaults by placing customized recipes or configuration files earlier in the BBPATH search path. This enables developers to tweak a distribution for their own needs without having to directly modify (and then subsequently maintain custom copies of) the existing distribution files. This approach in OE is called ‘layering’ and each collection of recipes is called an ‘overlay’.

We’ll now examine some of the different recipe and configuration files to shed a more detailed light on how OE and BitBake work. We will start by looking at the recipe types.

Information is shared by www.irvs.info