This chapter assumes that you are familiar with and have hands-on experience with embedded software. You should also be familiar with relevant terminology, such as bare-metal and RTOS. You should also know about common peripherals used in embedded systems, such as GPIO, I2C, SPI, and UART.

In this section, we will learn when embedded Linux is applicable to embedded systems. As mentioned earlier, embedded Linux usually involves a different development strategy and workflow from other embedded software patterns. Thus, it’s important to understand the types of systems and applications that are ideal to use and when not to use them.

When to use embedded Linux

To best understand when to use embedded Linux, I’d like to present the following figure, which represents a block diagram of a scientific instrument that I worked on:

Figure 1.1 – Typical embedded Linux system

The system consists of the following relevant hardware elements:

• A system-on-module (SoM), which contains a system-on-chip (SoC) along with other components to facilitate the operation of the SoC. For example, the SoM usually contains flash storage and RAM external to the SoC. The SoC, containing the CPU and other peripheral...

As embedded software engineers, we usually work in tandem with hardware engineers when designing and bringing up the custom hardware for our system. Typically, the hardware engineering team selects the components based on the system’s overall SWaP-C requirements. Once they have completed their initial selection, they work with us to confirm the selection and plan out design details, such as pin selection.

We must know whether the SoM/SoC selected by the hardware will support embedded Linux. The processor must be 32- or 64-bit. Extremely low-cost and low-power microcontrollers that use an 8- or 16-bit instruction set architecture generally won’t be able to run embedded Linux.

RAM and storage are also important requirements of an embedded Linux system. The minimum RAM requirement for embedded Linux is usually around 4 MB to 8 MB. However, for typical embedded applications requiring more robust networking, filesystem support...

In this section, we will review the architecture of embedded Linux. Specifically, we will briefly learn about the different software components that are typically part of an embedded Linux system. In future chapters, we will discuss each element in more detail.

Architecture

There are four distinct software elements in most embedded Linux systems, as shown in the following figure.

Figure 1.4 – embedded Linux components

Let us understand each of the components in detail:

• The first software component of embedded Linux is the bootloader, shown as BLD in the preceding figure. The bootloader is responsible for initializing the CPU and the necessary peripherals before launching the kernel. This can include clock configurations and RAM, which the Linux kernel may need to run correctly. The bootloader is also responsible for configuring the kernel itself, such as passing arguments to the kernel during boot...

In this section, we will learn about the embedded Linux boot process. Due to the different software components of an embedded Linux system and their complex structure, the boot process requires a detailed review. By the end of this section, we will have a comprehensive understanding of the Linux boot process, from power-up to a console terminal.

From power-up to kernel loading

The following diagram shows one variant of the first stage of the embedded Linux boot process:

Figure 1.6 – Bootloader operations during boot

When power is applied to the processor, it usually launches an initial bootloader in the read-only portion of its memory. Depending on the SoC, the ROM-based bootloader jumps to a fixed location in flash. This location contains another bootloader, usually U-Boot.

Another variant of this process involves another bootloader, the secondary program loader (SPL), which runs after the ROM-based bootloader and before U-Boot...

U-Boot is the most popular bootloader used on embedded Linux systems. It borrows a good deal of source code from the Linux kernel. U-Boot and the Linux kernel have header files in common, and U-Boot supports loading different variants of the Linux kernel.

Let’s briefly dive into U-Boot’s source code since I firmly believe we can truly understand how any application works by understanding the source code behind the implementation. We can retrieve U-Boot’s source code by executing the following command:

$ git clone git://git.denx.de/u-boot.git

We can retrieve version 2024.07 by executing the following command:

$ git checkout tags/v2024.07

Finally, we can use the ls command to view the directory structure of U-Boot’s source code, which is shown here:

Figure 1.9 – U-Boot source tree (version 2024.07)

Let’s review some of the more interesting directories:

• The api directory contains...

The Linux kernel has over 30 million lines of code, and its development has spanned nearly 35 years.

We can retrieve version 6.9 of the Linux kernel by executing the following commands:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
$ cd linux
$ git checkout tags/v6.9

The following figure shows the structure of the Linux kernel source code:

Figure 1.10 – Linux kernel code base

Similar to the previous section, we will review some of the more exciting directories:

• The arch directory contains source code specific to a particular CPU and SoC. For example, arch/arm/boot contains source files relevant to the boot process of ARM CPUs, and arch/arm/boot/dts contains Devicetree files for platforms with ARM-based processors. arch/arm/crypto contains hardware-accelerated cryptographic implementations, and arch/arm/kernel contains hardware-specific implementations of certain kernel functions...

The Devicetree allows the Linux kernel to learn about the hardware present on the system. The Linux kernel uses the information in the Devicetree to make the necessary function calls to initialize the underlying hardware.

The Devicetree is not specific to the Linux kernel. The Devicetree, abbreviated as DTS and more formally known as the Open Firmware Device Tree, is a construct initially conceived to describe hardware. It is both a data structure and a language, and is meant to be read by any OS, not just Linux, so that it can identify hardware during runtime and configure itself appropriately.

The Linux kernel uses the Devicetree for three main reasons:

• The first is to identify the system. Ideally, the devicetree could consistently describe all system details. However, there are some nuanced differences across systems. Thus, the kernel must be able to identify the machine early in the boot process to execute code specific to the machine...

While I firmly believe that embedded software engineers function best when they are running their software on real hardware, that may not always be the case. The examples in this book are intended to be executed on a Raspberry Pi 5. However, not everyone may have access to the Raspberry Pi 5 and may not be able to take advantage of the examples.

As an alternative, we can use the Quick Emulator (QEMU). QEMU is an open source virtualization application that allows us to run an embedded Linux system targeting an architecture or platform different from our development PC. We can use QEMU to simulate a good deal of the Raspberry Pi hardware to run our embedded Linux system. This will allow us to learn about the different components, even U-Boot, without having hardware. We will learn how to use QEMU to learn about the relevant component in future chapters.

In this chapter, we learned about the use cases where embedded Linux is appropriate for our system and the hardware requirements needed to run it adequately. Equally important, we learned when not to use embedded Linux. As we continue throughout the book, we will dive deeper into the subsystems covered in this chapter. Towards the middle of this book, we will see examples of applications that are perfectly suited for embedded Linux. As we learn about these applications in Chapter 9, 10, and 11, it’s important to refer to the lessons learned in this chapter to understand which elements are relevant for embedded Linux. We also learned about and built QEMU to simulate an embedded Linux system in case we don’t have access to the hardware used in the rest of the book, due to cost and availability in certain regions.

In the next chapter, we will learn about U-Boot.

Get this book’s PDF version and more

Scan the QR code (or go to packtpub.com/unlock...