Embedded Linux

Configuration & Build Process of an Embedded Linux System

© 2017 Arm Limited

Goal

To illustrate the configuration & build process of an embedded Linux system

To illustrate the concept of build systems

2 © 2017 Arm Limited

Summary

Introduction
The workflow
The build systems
Yocto

3 © 2017 Arm Limited

Summary

Introduction
The workflow
The build systems
Yocto

4 © 2017 Arm Limited

Introduction MicroSD
Layout

An embedded Linux system requires the following components to RAW unformatted

U-Boot
operate: space
• The bootloader
• The Linux Kernel Linux Kernel
• The device tree blob FAT file system
• The Root File System

All these components shall be: DTB

• Configured for the embedded system hardware platform

• Compiled and linked into an executable format
• Deployed into the embedded system persistent storage for booting and operations Root File Ext file system
System

5 © 2017 Arm Limited

Summary

Introduction
The workflow
The build systems
Yocto

6 © 2017 Arm Limited

The Workflow
System
Bootloader Linux Kernel
programs
source code source code
source code

Hw-specific Hw-specific Application

configuration Cross compiler configuration Cross compiler specific Cross compiler
configuration

System
programs
binary

Bootloader Linux Kernel

DTB Root File System
binary binary

7 © 2017 Arm Limited

The Workflow

The Bootloader source code shall be procured. Bootloader

source code
It shall be configured for the specific hw of the embedded system.
• The proper CPU shall be selected. Hw-specific
configuration Cross compiler
• The proper board shall be selected.
• Custom configuration may be needed if the hw is non-standard.

It shall be cross-compiled for the CPU of choice obtaining the

executable code.
Bootloader
It shall be copied into the boot device.
binary
• First sector of a MicroSD card
• Bootflash device on the embedded system board

8 © 2017 Arm Limited

The Workflow
The Linux Kernel source code shall be procured.
Linux Kernel
It shall be configured for the specific hw of the embedded system. source code
• The proper CPU shall be selected.
• The proper board shall be selected. Hw-specific
configuration Cross compiler
• Custom configuration may be needed if the hw is non-standard.

It shall be cross-compiled for obtaining

• Executable Linux kernel
• Executable Linux kernel modules
• Device Tree Blob Linux Kernel
DTB
binary
The obtained files shall be copied into the boot device.
• Partition on a MicroSD device
• Bootflash device on the embedded system board
9 © 2017 Arm Limited
The Workflow
System
The system programs source code shall be procured. programs
source code
• Downloaded from Internet
• Received from operating system vendor Application
specific Cross compiler
They shall be configured for the specific application. configuration
• Only the system programs needed for the application the embedded system is System
intended for shall be considered. programs
They shall be cross-compiled obtaining the executable binary. binary

10 © 2017 Arm Limited

The Workflow
The root file system shall be prepared.
/ # Disk root
It typically requires /bin
/lib
#
#
Repository for binary files
Repository for library files
/dev # Repository for device files
• To create a file and mount it as a volume on the console c 5 1 # Console device file
development host null c 1 3
zero c 1 5
#
#
Null device file
All-zero device file
tty c 5 0 # Serial console device file
• To format it using any of the file systems Linux supports (e.g., tty0 c 4 0 # Serial terminal device file
ext3) tty1 c 4 1 #
tty2 c 4 2 #
tty3 c 4 3 #
• To create the required directory tree tty4 c 4 4 #
tty5 c 4 5 #
• To populate it with the needed configuration files /etc # Repository for config files
inittab # The inittab
• To populate it with the system program binary /init.d
rcS
#
#
Repository for init config files
The script run at sysinit
/proc # The /proc file system
The root file system shall be copied into the /sbin
/tmp
#
#
Repository for accessory binary files
Repository for temporary files
embedded system persistent storage. /var
/usr
#
#
Repository for optional config files
Repository for user files
/sys # Repository for system service files
• Partition on a MicroSD device /media # Mount point for removable storage

• Bootflash device on the embedded system board

11 © 2017 Arm Limited
Summary

Introduction
The workflow
The build systems
Yocto

12 © 2017 Arm Limited

Build Systems

Building an embedded Linux system is a complex operation.

• Multiple sources shall be configured and compiled.
• Root file system shall be updated at each build through a non-trivial task.
• In cases of multiple hw and multiple hw configurations, manual iteration is needed.

Tools, known as build systems, are available to automate such operations.

Build systems takes care of:
• Building the cross compiler for the selected embedded system CPU
• Managing bootloader/kernel/system programs configuration
• Managing bootloader/kernel/system program build
• Preparation of the root file system and boot device image preparation

13 © 2017 Arm Limited

Build Systems

Several solutions are available.

Hw-vendor custom-built systems
• NXP Linux Target Image Builder (LTIB)

Open-source build systems, among which the most popular are Yocto and Buildroot
• Very actively maintained and developed projects
• Widely used in the industry
• Built from scratch from source toolchain, bootloaders, kernel, and root file system

14 © 2017 Arm Limited

Buildroot vs Yocto: General Aspects

Buildroot Yocto
• Focus on simplicity • Provides core recipes and use layers to get support
for more packages and more machines
• Use existing technologies: kconfig, make
• Custom modifications should stay in a separate layer
• Open community
• Versatile build system: tries to be as flexible as
possible and to handle most use cases
• Open community but governed by the Yocto Project
Advisory Board

15 © 2017 Arm Limited

Buildroot vs Yocto: Configuration

Buildroot reuses kconfig from the Linux In Yocto the configuration is separated in
kernel multiple parts:
• Entire configuration stored in a single • Distribution configuration (general configuration,
.config/defconfig toolchain selection, etc.)
• Defines all aspects of the system: architecture, • Machine configuration (defines the hw architecture,
kernel version/config, bootloaders, user-space hw features, BSP)
packages, etc.
• Image recipe (what system programs should be
• Building the same system for different machines to installed on the target)
be handled separately
• Local configuration (e.g., how many threads to use
when compiling, whether to remove build artifacts,
etc.)
• Allows to build the same image for different
machines or using different distributions or different
images for one machine

16 © 2017 Arm Limited

Buildroot vs Yocto: Purpose

Buildroot is intended for Yocto is intended for

• Very small root file systems (< 8 MB) • Large root file systems
• Simple embedded system (with limited number of • Large embedded systems
system programs)
• Support for multiple hw configurations
• Non-dedicated build engineers (e.g., engineers that
are not focused only in building embedded Linux)
• Dedicated build engineers

17 © 2017 Arm Limited

Summary

Introduction
The workflow
The build systems
Yocto

18 © 2017 Arm Limited

The Yocto Project

Open-source project hosted by the Linux Foundation

Collaboration of multiple projects that make up the “Yocto Project”
• Bitbake: build tool
• OpenEmbedded core: software framework used for creating Linux distributions
• Poky: a reference distribution of the Yocto Project, containing the OpenEmbedded Build System (BitBake and
OpenEmbedded Core) and a set of metadata to start building custom embedded Linux systems
• Application Development Toolkit: provides application developer a way to write sw running on the custom-built
embedded Linux system without the need for knowing build systems

Support for Arm, PPC, MIPS, and x86

19 © 2017 Arm Limited

The Yocto Build System
Developer-specific layer
It is composed of multiple layers which are
containers for the building blocks of the system. Commercial layer from
operating system vendor
Layers do not contain components source code,
only their metadata, called recipes.
User interface-specific layer
Recipes define how to build binary outputs called
packages. Board Support Package
layer

Yocto-specific layer
metadata (meta-yocto)

OpenEmbedded core
metadata (oe-core)
20 © 2017 Arm Limited
The Build System Workflow

Source: http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html

21 © 2017 Arm Limited

The Build System Workflow: Configuration Files

meta/conf/bitbake.conf – default configuration

User
Configuration
build/conf/bblayers.conf – layers to be used during build process

*/conf/layers.conf – layer configuration Metadata

(.bb + patches)

build/conf/local.conf – user-define configuration

Machine (BSP)
meta-yocto/conf/distro/poky.conf – distribution policy Configuration

meta-yocto-bsp/conf/machine/board-name.conf – configuration of Policy

the board support pacakge Configuration

meta/conf/machine/include/tune-CPU-name.inc – CPU-specific
configuration

22 © 2017 Arm Limited

The Build System Workflow: User Configuration
build/conf/local.conf is used to Example for the RaspberryPi 3
override the default configuration and
local.conf (fragment)
define what to build.
• BB_NUMBER_THREADS and PARALLEL_MAKE MACHINE ??= 'raspberrypi3'
DISTRO ?= 'poky'
• MACHINE settings
bblayer.conf (fragment)
• DISTRO settings BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
• INCOMPATIBLE_LICENSE = “GPLv3” ${BSPDIR}/sources/poky/meta-yocto \
${BSPDIR}/sources/poky/meta-yocto-bsp \
• EXTRA_IMAGE_FEATURES \
${BSPDIR}/sources/meta-openembedded/meta-oe \
build/conf/bblayers.conf is used to ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
${BSPDIR}/sources/meta-openembedded/meta-networking \
configure which layers to use. ${BSPDIR}/sources/meta-openembedded/meta-python \
\
• Add Yocto Project Compatible layers to the ${BSPDIR}/sources/meta-fsl-arm \
BBLAYERS ${BSPDIR}/sources/meta-fsl-arm-extra \
${BSPDIR}/sources/meta-fsl-demos \
${BSPDIR}/sources/meta-raspberrypi \
• Default: meta (oe-core), meta-yocto, and meta-
yocto-bsp
23 © 2017 Arm Limited
The Build System Workflow: Metadata
Recipes for building packages Example for the Raspberry Pi 3
Recipes inherit the system configuration and rpi-basic-image.bb (fragment)
adjust it to describe how to build and package
# Base this image on rpi-hwup-image
the software. include rpi-hwup-image.bb

Can be extended and enhanced via layers SPLASH = "psplash-raspberrypi"

Compatible with OpenEmbedded IMAGE_FEATURES += "ssh-server-dropbear splash"

24 © 2017 Arm Limited

The Build System Workflow: Machine (BSP) Configuration
Configuration files that describe a machine Example for the RaspberryPi 3
• Define board specific kernel configuration raspberrypi3.conf (fragment)

• Processor/SOC Tuning files #@TYPE: Machine

#@NAME: RaspberryPi 3 Development Board

Machine configuration refers to kernel #@DESCRIPTION: Machine configuration for the RaspberryPi 3

sources. MACHINEOVERRIDES = "raspberrypi2:${MACHINE}"

MACHINE_EXTRA_RRECOMMENDS += " kernel-modules wl18xx-conf

Compatible with OpenEmbedded uim-sysfs bt-firmware gator"

include conf/machine/raspberrypi2.conf

SERIAL_CONSOLE = "115200 ttyS0"

KERNEL_MODULE_AUTOLOAD += "g_serial hello"

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-gator"

25 © 2017 Arm Limited

The Build System Workflow: Distribution Policy

Defines distribution policies that affect the way individual recipes are built
• May set alternative preferred versions of recipes
• May enable/disable features
• May configure specific package rules
• May adjust image deployment settings

Enabled via the DISTRO setting

Four predefined settings:
• poky-bleeding: enables bleeding edge packages
• poky: core distribution definition, defines the base
• poky-lsb: enable items required for LSB support
• poky-tiny: construct a smaller than normal system
26 © 2017 Arm Limited
The Build System Workflow: Source Fetching

Recipes tell the location of all sources, patches, and files.

• These may exist on the internet or be local (See SRC_URI in the *.bb files).

Bitbake can get the sources from git, svn, bzr, or tarballs.
Versions of packages can be fixed or updated automatically
(Add SRCREV_pn-PN = “${AUTOREV}” to local.conf).
The Yocto Project mirrors sources to ensure source reliability.

27 © 2017 Arm Limited

The Build System Workflow: Patching

Once sources are obtained, they are extracted.

Patches are applied in the order they appear in SRC_URI.
In this stage, application-specific patches are applied.
• Custom modifications to the open-source code that are mandated by the
specific application for which the embedded system is intended for

28 © 2017 Arm Limited

The Build System Workflow: Configure/Compile/Install

The recipe specifies configuration and compilation rules.

• Various standard build rules are available, such as autotools and gettext.
• Standard ways to specify custom environment flags
• Install step runs under “pseudo”, allows special files, permissions, and owners/
groups to be set.

29 © 2017 Arm Limited

The Build System Workflow: Output Analysis/Packaging

Output Analysis
• Categorize generated software (debug, dev, docs, and
locales)
• Split runtime and debug information

Perform QA tests (sanity checks)

Package Generation
• Support the popular formats: RPM, Debian, and ipk
• Set preferred format using PACKAGE_CLASSES in
local.conf
• Package files can be manually defined to override
automatic settings.

30 © 2017 Arm Limited

The Build System Workflow: Image Generation

Images are constructed using the packages

built earlier and put into the Package
Feeds.
Decisions of what to install on the image is
based on the minimum defined set of
required components in an image recipe.
This minimum set is then expanded based
on dependencies to produce a package
solution.
Images may be generated in a variety of
formats (tar.bz2, ext2, ext3, jffs, etc.).

31 © 2017 Arm Limited

The Build System Workflow: SDK Generation

A specific SDK recipe may be created .

SDK may be based on the contents of the
image generation.
SDK contains native applications, cross
toolchain, and installation scripts.
May be used by the Eclipse Application
Developer Tool to enable App Developers

32 © 2017 Arm Limited