How to customize an embedded Linux distribution

Why do you want to customize?

In the past, many embedded projects used off-the-shelf distributions and then stripped them to just the basics necessary for a variety of reasons. First, remove unwanted packages to reduce the amount of storage space used. At startup, embedded systems generally do not require a large amount of storage space and available storage space. While the embedded system is running, it is possible to copy a large amount of operating system files from non-volatile memory into memory. Second, removing unused packages can reduce the possible attack surface. If you don't need them, there is no need to hang these potentially vulnerable packages on it. Finally, removing unused packages can reduce the overhead of release management. If there is a dependency between the packages, meaning that any one package request is updated from upstream, then they must all be synchronized. That may lead to verification nightmares.

However, removing a package from an existing distribution is not as easy as it is said. Removing a package may break various dependencies with other packages and may change dependencies in upstream release management. In addition, because some packages are natively integrated into the boot or runtime process, they cannot be easily removed easily. All of this is the management of platforms outside the project and can lead to unexpected development delays.

A popular option is to build a custom distribution using the build tools provided by the upstream distribution vendor. Both Gentoo and Debian offer this bottom-up approach. Perhaps the most popular of these build tools is Debian's debootstrap utility. It takes the pre-built core components and allows users to pick out the packages they are interested in to build their own platform. However, debootstrap was originally only available on the x86 platform, although there is now an ARM (and possibly other platforms) option. The debootstrap and Gentoo catalyst still need to remove dependency management from the local project.

Some people think that it is much easier to let others manage platform software (like Android) than to manage it yourself. However, those distributions are versatile, and when you use it on a lightweight, resource-limited IoT device, you may think twice about any resources that are taken from your hands.

The cornerstone of system guidance

A custom Linux distribution requires many software components. The first of these is the toolchain toolchain. A toolchain is a set of tools for compiling software. This includes (but is not limited to) a compiler, linker, binary manipulation tools, and a standard C library. The toolchain is built specifically for a specific target hardware device. If a toolchain built on an x86 system wants to be used in a Raspberry Pi, then this toolchain is called a cross-compilation toolchain. When working on small embedded devices with very limited memory and storage, it is best to use a cross-compilation toolchain. It's important to note that even applications that use scripting languages ​​like JavaScript that need to run on a particular platform for specific purposes need to be compiled with a cross-compilation toolchain.

Figure 1. Compile dependencies and boot order

The cross-compilation toolchain is used to build software components for the target hardware. The first component needed is the bootloader bootloader. When the computer motherboard is powered up, the processor (which may vary, depending on the design) attempts to jump to a specific memory location to start running the software. That memory location is where the boot loader is saved. The hardware may have a built-in boot loader that may be copied directly into memory from its storage location or possibly before it runs. There may also be multiple boot loaders. For example, the first stage boot loader might be in the hardware's NAND or NOR flash. Its only function is to set up the hardware to execute the second stage boot loader - for example, a boot loader that can be loaded and run on the SD card.

The bootloader is able to get enough information from the hardware, load Linux into memory and jump to the right place, effectively handing over control to Linux. Linux is an operating system. This means that in this design, it does nothing except monitor hardware and provide services to upper-level software (that is, applications). There are usually a variety of firmware blocks in the Linux kernel. Those pre-compiled software objects usually contain the private IP (knowledge assets) of the devices used by the hardware platform. When building a custom distribution, it may ask for some required firmware blocks not provided by the Linux kernel source tree before compiling the kernel.

The application is stored in the root file system, which is built by compilation, which aggregates various software libraries, tools, scripts, and configuration files. In general, they all offer a variety of services, such as network configuration and USB device mounting, which are all needed for the project application that will run.

In general, a complete system build requires the following components:

a cross-compilation toolchain

One or more boot loaders

Linux kernel and related firmware blocks

A root file system containing libraries, tools, and utilities

Customized application

Start building with the right tools

The components of the cross-compilation toolchain can be built by hand, but this is a very complicated process. Fortunately, existing tools make this process easy. Perhaps the best tool for building a cross-compilation toolchain is Crosstool-NG, which uses the same kconfig menu system as the Linux kernel to build every detail and aspect of the toolchain. The key to using this tool is to find the right configuration item for the target platform. Configuration items usually contain the following:

The target architecture, for example, is ARM or x86.

Byte order: Little endian byte order (in general, Intel uses this order) or big endian byte order (in general, ARM or other platforms use this order).

The CPU type known to the compiler, for example, GCC can use -mcpu or --with-cpu.

Supported floating point types, if any, for example, GCC can use -mfpu or --with-fpu.

Binary utility binuTIls, C library, and specific version information for the C compiler.

Figure 2. Crosstool-NG configuration menu

The first four cases are generally available from the processor manufacturer's documentation. For newer processors, they may not be easy to find, but like Raspberry Pi or BeagleBoards (and their descendants and branches), you can find relevant information in places like the embedded Linux Wiki.

The binary utility, C library, and version of the C compiler will be separated from any other toolchain provided by third parties. First, each of them has multiple providers. Linaro offers the most advanced version of the latest processor types and is working to incorporate this support into upstream projects like the GNU C library. Although you can use a variety of provider tools, you may still want to use the off-the-shelf GNU toolchain or the same Linaro version.

Another important choice in Crosstool-NG is the version of the Linux kernel. This choice will get the header headers for the various toolchain components, but it doesn't have to be the same as the Linux kernel you will boot on the target hardware. It is important to choose a Linux kernel that is not updated to the kernel of the target hardware. If possible, try to choose a long-term support (LTS) kernel that is older than the kernel used by the target hardware.

The build of the toolchain is the most complex process for most developers who are unfamiliar with building custom distributions. Fortunately, the binary toolchain for most hardware platforms can be found. If you have a problem building a custom toolchain, you can search online for places like the embedded Linux wiki to find the pre-built toolchain.

Boot option

After building the toolchain, the next step is to boot the loader. The boot loader is used to set up the hardware so that more and more complex software can use it. The first stage bootloader is usually provided by the target platform manufacturer and is typically burned to hardware-like storage such as EEPROM or NOR flash. The first stage bootloader will boot the device from here (for example, an SD memory card). The Raspberry Pi's boot loader is like this, so there is no need to create a custom boot loader.

Despite this, many projects have added a second-stage bootloader to perform a variety of tasks. One such task is provided without the need to use a Linux kernel or a user space tool like plymouth to provide a startup animation. A more common second-stage bootloader task is to provide network-based boot or make a disk attached to the PCI available. In that case, a third-stage boot loader, such as GRUB, might be necessary to get the system up and running.

Most importantly, the bootloader loads the Linux kernel and starts it. If the first stage boot loader does not provide a mechanism for passing kernel parameters at startup, then it must be provided in the second stage boot loader.

There are many open source boot loaders available. U-Boot projects are typically used on ARM platforms like the Raspberry Pi. CoreBoot is typically used on x86 platforms like Chromebooks. The boot loader is specific to the target hardware. The choice of bootloader depends on the needs of the project and the target hardware (you can go online to search the list of open source bootloaders online).

Now when Linux is on the scene

The bootloader will load the Linux kernel into memory and then run it. Linux is like an extended boot loader: it does hardware setup and is ready to load advanced software. The core of the kernel will set up and provide memory shared between the application and the hardware; provide a task manager to allow multiple applications to run simultaneously; initialize hardware that is not configured by the bootloader or that has been configured but not completed Component; and open the human-computer interface. The kernel may not be configured to do this on its own, but it can contain an embedded, lightweight file system that is well known for initramfs or initrd, which can be created independently of the kernel for Go to assist in setting up the hardware.

Another thing that the kernel does is to download the binary block (often called firmware) to the hardware device. Firmware is an object file precompiled in a specific format for initializing specific hardware where the bootloader or kernel cannot access it. Many of these firmware objects are available from the Linux kernel source repository, but there are many other firmware available only from specific hardware vendors. For example, devices that often provide firmware by themselves include digital television tuners or WiFi network cards.

The firmware can be loaded from initramfs or after the kernel has started the init process from the root filesystem. However, when you create a custom Linux distribution, the process of creating a kernel is often the process of getting the various firmware.

Lightweight core platform

The last thing the Linux kernel does is try to run a special program called the init process. The name of this special program may be init or linuxrc or the name passed to the kernel by the loader. The init process is kept in a file system that can be accessed by the kernel. In the case of initramfs, this file system is kept in memory (it may be placed there by the kernel itself or it may be placed there by the bootloader). However, initramfs is usually not complete enough to run more complex applications. So another file system is needed, which is known as the root file system.

Figure 3. Build the root configuration menu

The initramfs file system can be built using the Linux kernel itself, but it is more common to create it using a project called BusyBox. BusyBox combines many GNU utilities (such as grep or awk) into a single binary file to reduce the size of the file system itself. BusyBox is usually used to start the root file system creation process.

However, BusyBox is designed to be lightweight. It is not intended to provide all the tools needed for the target platform, and even the tools provided are functionally simplified. BusyBox has a "sister" project called Buildroot, which can be used to get a complete root filesystem, providing a variety of libraries, utilities, and scripting languages. Like Crosstool-NG and the Linux kernel, both BusyBox and Buildroot allow the kconfig menu system to be used to customize the configuration. More importantly, the Buildroot system automatically handles dependencies, so the selected utility will ensure that the software needed for the program will be built and installed into the root file system.

Buildroot can generate a root file system package in a variety of formats. However, it is important to note that this file system is archived. Individual utilities and libraries are not packaged in Debian or RPM format. Using Buildroot will generate a root file system image, but its contents are not separate packages. Even so, Buildroot provides support for opkg and rpm package managers. This means that although the root file system itself does not support package management, custom applications installed on the root file system are capable of package management.

Cross compilation and scripting

One of the features of Buildroot is the ability to generate a temporary tree. This directory contains libraries and utilities that can be used to cross-compile other applications. Using a temporary tree and cross-compilation toolchain makes it possible to compile applications other than Buildroot on the host system instead of the target platform. After using the rpm or opkg package management software, these applications can be installed on the target platform's root file system using the package management software at runtime.

Most custom systems are built around the idea of ​​building applications in a scripting language. If you need to run scripts on the target platform, there are many options available on Buildroot, including Python, PHP, Lua, and Node.js-based JavaScript. Support is also provided for applications that require OpenSSL encryption.

What to do next

The compilation process for the Linux kernel and boot loader is the same as for most applications. Their build system is designed to build a dedicated software bit. Crosstool-NG and Buildroot are meta build metabuilds. Meta-construction encapsulates a collection of software that has its own build system into a build system. Reliable meta-builds include Yocto and OpenEmbedded. The benefit of Buildroot is that it can easily package higher-level meta-builds to automate the build process for custom Linux distributions. After doing this, you will open the option that Buildroot points to the project-specific cache repository. Using a cached repository speeds up the development process and provides a build snapshot without worrying about changes to the upstream repository.

An example of implementing an advanced build system is the PiBox. PiBox is a meta-construct that encapsulates the various tools discussed in this article. Its purpose is to add a generic GNU Make target architecture around all tools to build a core platform that can build or distribute other software. The PiBox Media Center and the kiosk project are implementations of application layer software installed on top of the core platform to create a build platform. The Iron Man project extends this application for home automation purposes, integrating the management of voice management and IoT devices.

However, if PiBox does not have these core software tools, it can't do anything. And, if you don't delve into the build process of a complete custom distribution, you won't be able to run PiBox properly. Moreover, without the long-term dedication of the PiBox development team to the project, there would be no PiBox project, which completed a number of tasks in the custom release build.