Embedded Linux

Linux-based Embedded System Component Stack

© 2017 Arm Limited

Goals

To illustrate the main components of a Linux-based embedded system

To analyze the bootstrap process

2 © 2017 Arm Limited

Summary

Introduction
Bootloader
Kernel
Device tree
System programs
Application
Root filesystem

3 © 2017 Arm Limited

Summary

Introduction
Bootloader
Kernel
Device tree
System programs
Application
Root filesystem

4 © 2017 Arm Limited

Linux-based Embedded System Components

Root File
Application

System
Bootloader
System Programs
• Software executed at power-up to set-up the hardware to run
the operating system
System Call Interface
Device tree
Process Virtual File

kernel
Linux
• A tree data structure with nodes that describe the physical Management System
devices in the hardware needed by the Linux kernel to
initialize properly the device drivers Memory Network
Management Management
Linux Kernel
Device Drivers
• The operating system code providing all the services to
manage the hardware resources
Bootloader Device tree

Hardware
5 © 2017 Arm Limited
Linux-based Embedded System Components

Root File
Application

System
System programs
System Programs
• User-friendly utilities to access operating system services

Application System Call Interface

• Software implementing the functionalities to be delivered to Process Virtual File

Kernel
Linux
the embedded system user Management System
Root filesystem Memory Network
• Container for the Linux Kernel configuration files, the system
Management Management
programs, and the application
Device Drivers

Bootloader Device tree

Hardware
6 © 2017 Arm Limited
Reference Hardware Model

Embedded System Hardware components:

Embedded System Hardware
• RAM memory: volatile memory storing data/code
• CPU: processor running software Boot Flash
• I/O: peripherals to get inputs from the user, and to CPU
provide outputs to the user RAM
• Boot Flash: small non-volatile memory needed at power- Memory Mass
up (discussed later) Memory
• Mass Memory Flash: large non-volatile memory I/O Flash
(discussed later)

7 © 2017 Arm Limited

Reference Hardware Model Implementations

Multiple implementations of the reference hardware model are possible. For example:
• Microcontroller-based implementation: a single device hosts most of the reference model components (e.g. CPU,
RAM memory, boot flash).
• System-on-Chip implementation: most of the reference model components are discrete components, while the CPU
is integrated with some of them (e.g. I/O, boot flash).
Microcontroller (MCU) System on Chip (SoC)

CPU CPU
RAM RAM Mass
Boot
Memory Memory Memory
Flash
Boot Flash
I/O I/O
Flash

8 © 2017 Arm Limited

CPU Memory Map Memory map of NXP
LPC1768 (Cortex-M3)

The CPU generates 2N different addresses (02N-1).

• N=number of bits of the address bus

Each device (memory, I/O, etc.) is associated with a

range of addresses.
The memory map describes this association for all the
devices.

9 © 2017 Arm Limited

Summary

Introduction
Bootloader
Kernel
Device tree
System programs
Application
Root filesystem

10 © 2017 Arm Limited

The Role of the Bootloader

A processor is designed to run software from “somewhere”.

To start running the software, the processor needs to know:
• Where the software is located
• How to get access to the software location
• Where the stack is located

11 © 2017 Arm Limited

The Role of the Bootloader

When powered-up, the processor needs a simple way to get the information it needs.
• Where the software is located
• How to get access to the software location
• Where the stack is located

At power-up, the program counter is set to a default known value, the reset vector.
• The software starting at the reset vector, which will load the bootloader, which takes care of providing the processor
all the needed information.
• The operations performed depend on the system architecture.

12 © 2017 Arm Limited

Possible Scenarios
Microcontroller (MCU)

Scenario 1, typical of microcontrollers CPU

• All the sw (bootloader + device tree + operating system + root RAM Boot
filesystem) is stored in persistent storage (boot flash) Memory Flash
embedded in the microcontroller. I/O
• All the sw is executed from the persistent storage.
• The CPU reset vector is located in the boot flash.
• The RAM Memory is embedded in the microcontroller and is
Data Application

Root File
used for data, stack and heap only.

System
Stack System
Heap Programs
Operating
System
Device tree
Bootloader

13 © 2017 Arm Limited

Possible Scenarios
System-on-Chip
Scenario 2, typical of System-on-Chip
• The bootloader is stored into the boot flash. CPU
RAM Mass
• The CPU reset vector is located in the boot flash. Memory Memory
Boot Flash
• The root filesystem, operating systems, and device tree I/O
are stored in the mass memory flash and loaded in RAM Flash
memory by the bootloader.
• The RAM memory is external to the SoC. It will store the
operating system + application software, root filesystem Bootloader
Application
(if configured as RAM disk), data, stack, and heap. Data
Stack System
Heap Programs
Operating
System
Device tree

14 © 2017 Arm Limited

An Example of Bootloader Operations
0x0003_FFFF
RAM
Let’s consider Scenario 2 for a given SoC with Memory
the following memory map:
• RAM memory 512 kbytes (arranged as 128 kwords,
each 32 bytes long), from 0x0002_0000 to 0x0003_FFFF
• Mass memory flash 256 kbytes (same organization as
before), from 0x0001_0000 to 0x0001_FFFF
0x0001_FFFF
• Boot flash 256 kbytes (same organization as before), Mass
from 0x000_0000 to 0x0000_FFFF Memory
Flash

Boot Flash 0x0000_FFFF

CPU reset vector 0x0000_0000

15 © 2017 Arm Limited

An Example of Bootloader Operations
0x0003_FFFF
RAM
Time = before power up Memory

The boot flash is preloaded with the bootloader

• First bootloader instruction at 0x0000_0FFF
• Last bootloader instruction at 0x0000_AFFF

The mass memory flash is preloaded with: 0x0001_FFFF

Application Mass
• Device tree (DT) SP Memory
OS
• Operating systems (OS) DT Flash
• System programs (SP) 0x0000_FFFF
Boot Flash
• Application 0x0000_AFFF Bootloader

b 0x0000_0FFF
CPU reset vector 0x0000_0000 0x0000_0000

16 © 2017 Arm Limited

An Example of Bootloader Operations
0x0003_FFFF
RAM
Time = power up Memory

The CPU starts executing software from the reset

vector:
• It jumps to the first instruction of the bootloader.
• It runs the bootloader software from booth flash memory.
0x0001_FFFF
Application Mass
SP Memory
OS
DT Flash

Boot Flash 0x0000_FFFF

0x0000_AFFF Bootloader

b 0x0000_0FFF
CPU reset vector 0x0000_0000 0x0000_0000

17 © 2017 Arm Limited

An Example of Bootloader Operations
0x0003_FFFF
RAM
Time = during bootstrap Memory

The CPU executes bootloader software that:

• Initializes the CPU RAM memory controller
• Sets up the CPU registers for mapping stack and heap to RAM
memory
0x0001_FFFF
• Copies device tree, operating system, system programs, and Application Mass
applications to RAM memory SP Memory
OS
DT Flash

Boot Flash 0x0000_FFFF

0x0000_AFFF Bootloader

b 0x0000_0FFF
CPU reset vector 0x0000_0000 0x0000_0000

18 © 2017 Arm Limited

An Example of Bootloader Operations
0x0003_FFFF
Stack RAM
Time = end of bootstrap Heap Memory

The bootloader jumps to the first instruction of

the operating system. Application
SP

The CPU now executes the operating system OS

DT
software, which is responsible for: 0x0001_FFFF
• Setting-up the execution environment for the application
Application Mass
SP Memory
• Starting application execution OS
Flash
DT

Boot Flash 0x0000_FFFF

0x0000_AFFF Bootloader

b 0x0000_0FFF
CPU reset vector 0x0000_0000 0x0000_0000

19 © 2017 Arm Limited

Summary

Introduction
Bootloader
Kernel
Device tree
System programs
Application
Root filesystem

20 © 2017 Arm Limited

Linux Kernel

The Linux Kernel is the software responsible for optimally managing the embedded
system’s hardware resources.
It offers services such as: System Call Interface
• Process management Process Virtual File

Kernel
Linux
• Process scheduling Management System
• Inter-process communication Memory Network
• Memory management Management Management
• I/O management (device drivers) Device Drivers
• File system
• Networking
• And more

21 © 2017 Arm Limited

Linux Kernel

The Linux kernel adopts a layered operating system Application

Space
User
architecture:
System Programs
• The operating system is divided into two layers, one (user space)
built on top of the other (Kernel space).
• User space and Kernel space are different address spaces. System Call Interface
• Basic services are delivered by a single executable, monolithic Process Virtual File
Kernel.

Space
Kernel
Management System
• Services can be extended at run-time through loadable Kernel
modules Memory Network
Management Management
Device Drivers Loadable
Module

22 © 2017 Arm Limited

Monolithic kernel
Linux Kernel

Advantage Application

Space
User
• Good separation between application/system programs System Programs
and kernel. Bugs in the user space do not corrupt the
kernel.

Disadvantages System Call Interface

• Bugs in one Kernel component (e.g. a new device driver) Process Virtual File

Space
Kernel
can crash the whole system. Management System
Memory Network
Management Management
Device Drivers Loadable
Module

23 © 2017 Arm Limited

Monolithic kernel
Summary

Introduction
Bootloader
Kernel
Device tree
System programs
Application
Root filesystem

24 © 2017 Arm Limited

Device Tree

To manage hardware resources, the Kernel must know which resources are available in
the embedded system (i.e. the hardware description: I/O devices, memory, etc).
There are two ways to provide this information to the Kernel:
• Hardcode it into the Kernel binary code. Each modification to the hardware definition requires recompiling the
source code.
• Provide it to the Kernel when the bootloader uses a binary file, the device tree blob.

A device tree blob (DTB) file is produced from a device tree source (DTS).
• A hardware definition can be changed more easily as only DTS recompilation is needed.
• Kernel recompilation is not needed upon changes to the hardware definition. This is a big time saver.

25 © 2017 Arm Limited

Summary

Introduction
Bootloader
Device tree
Kernel
System programs
Application
Root filesystem

26 © 2017 Arm Limited

System Programs

System programs provide a convenient environment for program development and

execution.
They can be divided into:
• Status information
• File modification
• Programming language support
• Program loading and execution
• Communications
• Application programs

27 © 2017 Arm Limited

Summary

Introduction
Bootloader
Device tree
Kernel
System programs
Application
Root filesystem

28 © 2017 Arm Limited

Application

The application is the software required to provide the end user service for which the
embedded system was conceived.
Examples can be found in many different products:
• Network Attached Storage (NAS)
• Network router
• In-vehicle infotainment
• Specialized lab equipment
• And more

29 © 2017 Arm Limited

Summary

Introduction
Bootloader
Device tree
Kernel
System programs
Application
Root filesystem

30 © 2017 Arm Limited

Root Filesystem

The Linux Kernel needs a file system, called a root filesystem, at startup.
• It contains the configuration file needed to prepare the execution environment for the application (e.g. setting up
the Ethernet address).
• It contains the first user-level process (init).

The root filesystem can be:

• A portion of the RAM treated as a file system known as Initial RAM Disk (initrd), if the embedded system does not
need to store data persistently during its operations
• A persistent storage in the embedded system, if the embedded system has to store data persistently during its
operations
• A persistent storage accessed over the network, if developing a Linux-based embedded system

31 © 2017 Arm Limited

Typical Layout of the Root Filesystem
/ # Disk root
/bin # Repository for binary files
/lib # Repository for library files
/dev # Repository for device files
console c 5 1 # Console device file
null c 1 3 # Null device file
zero c 1 5 # All-zero device file
tty c 5 0 # Serial console device file
tty0 c 4 0 # Serial terminal device file
tty1 c 4 1 #
tty2 c 4 2 #
tty3 c 4 3 #
tty4 c 4 4 #
tty5 c 4 5 #
/etc # Repository for config files
inittab # The inittab
/init.d # Repository for init config files
rcS # The script run at sysinit
/proc # The /proc file system
/sbin # Repository for accessory binary files
/tmp # Repository for temporary files
/var # Repository for optional config files
/usr # Repository for user files
/sys # Repository for system service files
32 © 2017 Arm Limited /media # Mount point for removable storage