BUILDING EMBEDDED LINUX SYSTEMS

USING SYSTEM BUILDER

CHRISTOPHER HALLINAN, TECHNICAL MARKETING ENGINEER

W H I T E P A P E R

E M B E D D E D S O F T W A R E

w w w.m e n t o r.c o m
Building Embedded Linux Systems Using System Builder

INTRODUCTION
Few doubt that Linux now dominates the embedded systems marketplace. Linux has found its way into nearly
every product segment, from consumer electronics to the “big iron” boxes used to power global wireless and
landline networks. It is not a stretch of one’s imagination to assume that many modern households have one
or more Linux-powered appliances.

Linux® can be found in nearly every part of our lives, from diagnostic medical devices, the navigation, entertainment
and engine control systems of our automobiles, to the wireless access points powering our homes. Linux has
even found its way into demanding hard real time applications as well as mission critical commercial, military
and aerospace applications.

CHALLENGES USING OPEN SOURCE

One of the major reasons why Linux has become so successful in embedded systems also contributes to the
challenges inherent in developing and deploying embedded Linux-based devices. Open source software in
general, and Linux in particular move at a dizzying pace.

Figure 1 illustrates the monthly volume of messages to the Linux kernel mailing list. This mail list averages almost
thirteen thousand messages per month. That is well over four hundred emails in a single day, including weekends!

Figure 1 - Monthly traffic (messages) on the Linux kernel mailing list.

The Linux kernel is but one small component of an embedded Linux system. A complete Linux system
consists of a bootloader, Linux kernel and many dozens, often hundreds of application packages. These packages
contain the programs, libraries and configuration files that make up a Linux system.

The embedded Linux developer also needs to have a functional cross-toolchain and other development tools to
help build and customize his embedded Linux system. The cross-toolchain and other tools, such as analysis and
profiling tools need to run correctly on his choice of development host.

EMBEDDED PRESENTS UNIQUE CHALLENGES

It is not so difficult today to download a Linux kernel from kernel.org and compile it to run on a modern Intel-based
x86 machine. However, when the underlying machine is of a different architecture, such as Power Architecture or

w w w. m e nto r. co m
2
Building Embedded Linux Systems Using System Builder

MIPS, it is a different story altogether. It is no secret that most of the mainline kernel developers focus on
traditional desktop and server applications that are dominated by Intel and AMD x86 machines.

Embedded Linux developers are far smaller in number. It is not uncommon that patches and fixes for non-x86
architectures lag significantly behind those for x86. In fact, many patches and board ports never reach mainline
kernel.org. This is especially true for hardware platforms that are not in the popular market, such as the majority
of reference platforms produced by the leading semiconductor manufacturers.

Building an embedded Linux distribution for non-x86 architectures is much more challenging than for x86.
For starters, you need a toolchain of high quality, and these are usually only available from commercial sources.
You will also need a bulletproof kernel ported not only to your architecture, but also to your particular board. On
top of that, you will need the runtime packages that make up the system, including the standard C library family
and other runtime libraries and system configuration files that make up an embedded system. All of these
components must play nice together, and that alone is a non-trivial challenge. Package version dependency has
always been challenging in the Linux world.

ONE SIZE DOES NOT FIT ALL

Traditional embedded Linux distributions have been an all-or-nothing proposition. They were created to be
generic – to apply to a large variety of embedded applications. This often meant that you got many packages and
components you did not need. Worse, it often meant there were critical components that your system requires
that were not present.

LARGE SCOPE OF EXPERTISE REQUIRED

To build your own embedded Linux distribution, you need a broad range of specialized expertise. At a minimum,
you will need developers with experience in the following disciplines:

■■ Hardware/BSP – This includes detailed knowledge of the complex System-on-Chip (SOCs) being offered today,
including a solid understanding of the underlying hardware architecture.
■■ Compilers/Toolchain – Compilers are bug-free, right? Open source compilers are subject to the same rapid
development and therefore instability as other open source components, and they can be particularly difficult
to diagnose and fix.
■■ Linux kernel – Back to revision 0.9, the Linux kernel was reasonably easy to understand, modify and fix.
Today’s Linux kernel has something north of twenty million lines of text, not including documentation, and
has become highly complex requiring specialized skills even for simple bug fixes.
■■ Userland – The challenge with userland packages is simply the vast number and variety of packages. Many are
not cross-compiler friendly, and some are quite specialized.
■■ Development Tools – There are many options for development tools, from sparse (printf debugging and
occasional use of gdb) to full blown IDEs. Assembling a capable suite of tools is no small task.
Despite the challenges outlined above, a Linux-based operating system offers the richest set of applications and
widest choice of hardware platforms and devices than any other operating system available today.

The challenge becomes how to leverage the available open source components and technology in a way that is
both cost effective and timely. Integrating open source components, together with other intellectual property
such as in-house developed code, software from a semiconductor vendor, and perhaps 3rd party solutions from
ISVs is what Mentor Embedded™ System Builder is all about.

w w w. m e nto r. co m
3
Building Embedded Linux Systems Using System Builder

Figure 2 - Integration of multiple IP into a customized distribution tailored to your requirements.

MENTOR EMBEDDED SYSTEM BUILDER

The Mentor Embedded System Builder is a flexible, highly configurable build system provided by Mentor Graphics.
System Builder is architected around the open source build system called OpenEmbedded. System Builder provides
the embedded developer with the tools to:

■■ Acquire and integrate embedded Linux platform code and other IP from semiconductor manufactures and
other system suppliers
■■ Create software Bill of Materials (BOM)
■■ Track versions of the Linux kernel and other open source software components and dependencies
■■ Offer traceability of sources used in derived binaries
■■ Help OEMs comply with open source license obligations

SYSTEM BUILDER: BASED ON OPENEMBEDDED

Mentor Embedded System Builder is architected from OpenEmbedded, a successful open source build system
derived from the OpenZaurus project circa 2003. OpenEmbedded was created to overcome the limitations in the
existing build systems of the era. Since it’s inception, OpenEmbedded has found its way into a significant number
of commercial and open source projects. The build engine – bitbake – is based on concepts from Gentoo/portage.

OE PROJECT GOALS
The OpenEmbedded development team had specific goals for the project. These goals included the following:

■■ Handle cross-compilation even for complex packages, including gcc and glibc
■■ Manage and resolve package dependencies
■■ Emit packages in any possible type, the default being the lightweight .ipk package type

w w w. m e nto r. co m
4
Building Embedded Linux Systems Using System Builder

■■ Create images and feeds from packages

■■ The system must be highly configurable, with support for multiple platforms, architectures, machines and
distributions. In this context, the term machines refers to an embedded board
■■ The metadata language used to describe projects must be easy to use and reuse

OE COMPONENTS
OpenEmbedded is composed of two primary components – bitbake and metadata. Bitbake is the build engine,
and is the heart of the build system. Bitbake reads instructions (metadata) and acts on them in order to build an
embedded Linux distribution.

Metadata is a structured collection of instructions that tell bitbake what to build. It’s important to keep in mind
what metadata is, and what it is not. Metadata exists in four general categories: recipes, tasks, classes and
configuration metadata. Metadata is not source code. A recipe tells bitbake where and how to download source
code, but metadata itself contains none.

ATTRIBUTES OF OPEN EMBEDDED

OpenEmbedded is capable of building for multiple target devices from a single code base. The bitbake tool
automatically builds any required dependencies. This applies to runtime dependencies as well as build
dependencies. Multiple types of flashable root file system images can be created for booting directly on the
target device.

OpenEmbedded supports a wide variety of package formats, including .rpm, .deb, .ipk. and more. OpenEmbedded
supports automatic building of cross-tools if required. Support for using external toolchains is also possible with
OpenEmbedded. OpenEmbedded can build host-compatible (native) utilities required during the build process,
which helps provide robust support across a wide variety of host systems.

SYSTEM BUILDER BUILDS ON OE STRENGTHS

Mentor Embedded System Builder builds upon OpenEmbedded framework. System Builder enhances
OpenEmbedded by adding the following features:

■■ System Builder starts with a commercial quality package repository, which enhances system reliability and
significantly reduces system build time.
■■ Easy configuration management is provided either via the command line or from a graphical user interface.
This speeds project creation and provides a sane, default “out-of-the-box” configuration.
■■ Configuration Knobs enable specific board-related features.
■■ Caching of intermediate build objects speeds up incremental builds.
■■ Bill of Materials (BOM) generator generates a list of package components and their associated licenses. This
facilitates legal and regulatory compliance.
■■ Binary to Source Tagging provides traceability from a binary to the source code archive that produced it.
■■ System Builder can build an Application Developer Kit (ADK) which provides an easy out-of-the-box
application development environment for those developers who do not need a full platform development kit.

w w w. m e nto r. co m
5
Building Embedded Linux Systems Using System Builder

Figure 3 - The central role of System Builder during Linux platform development.

UNDERSTANDING METADATA
Metadata exists four general categories. These are: recipes, tasks, classes and configuration. Recipes usually
describe build instructions for a single package. Tasks are often used to group packages together for root file
system creation. Classes, analogous to classes in object-oriented languages, are a mechanism to encapsulate
common functionality that can be inherited by recipes and tasks. Configuration metadata is used to drive the
overall attributes of the embedded Linux distribution that System Builder creates.

RECIPE BASICS
Each recipe has a set of default tasks, provided by a base class in OpenEmbedded called base.bbclass. The default
tasks provided for every recipe are illustrated in Figure 4.

Figure 4 - Default tasks for generic recipe.

w w w. m e nto r. co m
6
Building Embedded Linux Systems Using System Builder

These default tasks can be overridden by a given recipe to accomplish a particular task. Let’s look at a simple
minimal recipe to see how this works.

A simple hello world recipe with a file name like hello-1.0.0.bb might look like this:

DESCRIPTION = “Hello demo project”

PR = “r0”

SRC_URI = “http://localhost/sources/hello-1.0.0.tar.gz”

The description field is informational, and can contain any text. It is meant as a short explanation for what the
recipe builds. PR is a specific OpenEmbedded variable and refers to the recipe version. If you make changes to a
recipe, prudence dictates that you bump the PR.

The SRC_URI tells bitbake where to find the source code for the package being built. In this example, the source is
contained in a tarball on the local machine, served up via the HTTP protocol. The source code can be a simple C
source file accompanied by a one-line makefile, or it can be a large software project, with many subdirectories and
it’s own custom build system. In the former case, this simple recipe is all that is needed to build it. In the
latter, you might have to override some of the default recipe tasks in order to issue the proper build
instructions to your project.

In our example hello recipe, the source tarball is trivial – it contains the usual hello world C program, and a one-line
makefile containing the single binary target and its dependency:

hello: hello.o

Bitbake takes care of the rest. When this recipe is built, using a simple command such as ‘bitbake hello’, the
default tasks are applied to the recipe to cause it to be built. do _ fetch downloads the tarball to the working
directory, do _ unpack unpacks the tarball into the working source directory, and do _ compile calls make on
the resulting source directory.

Other recipe tasks are responsible for placing any build artifacts into a staging area, where they are made available
in case other packages depend on them for building, and so that the artifacts can eventually be packaged into a
.ipk named after the original (hello-1.0.0) recipe.

Finally, a special recipe called a task1 takes the output package and places its contents into a root file system.

TASKS
A task is a special kind of recipe that groups packages together for inclusion in a file system image. A task can
define an image or a collection of packages for use in an image. A simple task may specify the base functionality
for booting a particular target, or the packages required for a specific functionality, such as task-perl-module-
all.bb. A more complex task might use python code to pull packages into an image based on features defined
with a particular machine. A good example of this type of task is task-base.bb.

1Note that the term “task” is overloaded in OpenEmbedded terminology. In the case of a recipe, a task is a method
or function specific to a given step in the build, such as do_build or do_install. When speaking of metadata, a task
is a special type of recipe that is often used to group packages together.

w w w. m e nto r. co m
7
Building Embedded Linux Systems Using System Builder

CLASSES
Classes are used in System Builder in a similar manner to those used in traditional object oriented programming
languages such as C++ and Java. Classes are used to abstract common functionality that can then be inherited by
any recipe.

A good example of a System Builder class is autotools.bbclass. This class implements the methods typically
used to build autotools-based packages. Among these methods is the familiar ./configure step familiar to anyone
who has compiled packages on a Linux host. The default configure method provided by autotools.bbclass
knows how to specify the proper parameters for cross-compiling in your given environment.

COLLECTIONS
Metadata is layered through the concept of collections. A collection is simply a grouping of particular types of
metadata. A typical embedded Linux distribution is built up from layers of metadata from the most generic to the
most specific. Figure 5 illustrates the layered nature of collections of metadata.

Collections allow you to make modifications to existing System Builder metadata without actually changing the
underlying recipe. Simply add your own collection, copy the desired recipe to your own collection, and modify it
for your particular purposes.

Figure 5 - It’s important to realize that all collections have a layered relationship.

CONFIGURING SYSTEM BUILDER

We have briefly looked at the types of metadata, including recipes, tasks and classes. The fourth general category
of metadata is configuration. In general, there are four types of configuration files within System Builder:

■■ Machine configuration – Each physical machine (reference platform or board) has a dedicated machine
configuration file. This file defines attributes specific to the machine, such as architecture, hardware features,
type and organization of Flash memory, serial console settings, etc.
■■ Distribution configuration – High-level attributes of the distribution are defined here. These may include
default image types, libc selection, preferred versions of critical packages, such as gcc, glibc, binutils, etc.
■■ Bitbake configuration – This is the “plumbing” for bitbake. This level of configuration defines global file search
paths, target file system layout, architecture-dependent build variables and defines a set of default software
packages prerequisites.

w w w. m e nto r. co m
8
Building Embedded Linux Systems Using System Builder

■■ Local configuration – Configuration is layered, in a similar manner to collections. Settings in local.conf

override all other levels of configuration, and this is where most of your customizations will take place.

Most of the changes you may need to make to customize your embedded Linux distribution can be made in
local.conf. The following are some examples of typical customizations you might make in your local.conf:

IMAGE_FSTYPES += jffs2
PREFERRED_VERSION_busybox = “1.13.2”
IMAGE_INSTALL_append = “ lmbench”

The first line instructs System Builder to generate a jffs2 file system image as part of its final output. The second line
pins the version of busybox to 1.13.2. There are typically multiple versions of a recipe for a given package available.
The final line adds the lmbench package to your target file system image.

SYSTEM BUILDER PROJECT WORKFLOW

Creating your first System Builder project based on a specific reference board couldn’t be easier. Installation takes a
few mouse clicks in a graphical installer. System Builder comes with a project creation tool that populates several
key configuration files and sets up the build area. The project creation tool also produces a script that when
sourced, sets up your system’s environment in preparation for a bitbake build.

After project creation, bitbake is invoked on an image recipe, similar to the following:

$ bitbake devel-image

Figure 6 illustrates the process.

Figure 6 - System Builder workflow.

Once bitbake finishes building an image recipe, your output directory typically contains all the images necessary to
boot your target board. The output images include the following:

■■ Bootloader image for your platform

■■ Device Tree Binary (if required for your platform)
■■ Kernel and device drivers (loadable modules)

w w w. m e nto r. co m
9
Building Embedded Linux Systems Using System Builder

■■ Root file system images (jffs2, ext3, etc.)

■■ Packages for all root file system contents
■■ Bill of Materials (BOM) if desired

SUMMARY
Linux has been deployed as the defacto standard for a wide variety of embedded applications across virtually
every market segment. Developers today are facing huge development challenges brought on by insanely short
development cycles and ever-increasing hardware and software complexity driven by customer demand and
competitive pressures. One of the distinguishing characteristics of embedded systems is that each is a unique
combination of hardware and software components.

Mentor Embedded Linux System Builder provides the foundation for building custom platform software that
includes commercial quality Linux components, IP from semiconductor manufacturers, middleware from ISVs, and
in-house developed code. System Builder provides the platform developer with much more than effortless
assemble-compile-deploy. System Builder offers developers significant value over open source, including easy
configuration management with sane, out-of-the-box platform configurations, caching of intermediate build
objects to significantly reduce build time, BOM generator for legal and regulatory compliance, software traceability
from binary objects to the source archives which produced them, and an application developer kit for rapid
deployment to project team members.

The Mentor Embedded family of products and services, including embedded software IP, tools, and professional
consultant services stand ready to assist developers and silicon partners to customize and optimize their product
for design and cost efficiency. Mentor Embedded continues to lead the industry with involvement in open source
community (Linux, Android, and MeeGo) and innovations such as Android beyond mobile handsets and multi-OS
on multicore architectures.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.

For the latest product information, call us or visit: w w w.m e n t o r.c o m

©2010 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and
may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 06-10 TECH9090-w