Mastering Embedded Linux Programming - Second Edition

Chris Simmonds

• Publisher: Packt Publishing
• Year: 2017
• ISBN:
  9781787288850
• Edition: 2
• Topic: Computer Science
• Subtopic: Operating Systems
• Index: Computer Science

Master the techniques needed to build great, efficient embedded devices on LinuxAbout This Book• Discover how to build and configure reliable embedded Linux devices• This book has been updated to include Linux 4.9 and Yocto Project 2.2 (Morty)• This comprehensive guide covers the remote update of devices in the field and power managementWho This Book Is ForIf you are an engineer who wishes to understand and use Linux in embedded devices, this book is for you. It is also for Linux developers and system programmers who are familiar with embedded systems and want to learn and program the best in class devices. It is appropriate for students studying embedded techniques, for developers implementing embedded Linux devices, and engineers supporting existing Linux devices.What You Will Learn• Evaluate the Board Support Packages offered by most manufacturers of a system on chip or embedded module• Use Buildroot and the Yocto Project to create embedded Linux systems quickly and efficiently• Update IoT devices in the field without compromising security• Reduce the power budget of devices to make batteries last longer• Interact with the hardware without having to write kernel device drivers• Debug devices remotely using GDB, and see how to measure the performance of the systems using powerful tools such as perk, ftrace, and valgrind• Find out how to configure Linux as a real-time operating systemIn DetailEmbedded Linux runs many of the devices we use every day, from smart TVs to WiFi routers, test equipment to industrial controllers - all of them have Linux at their heart. Linux is a core technology in the implementation of the inter-connected world of the Internet of Things.The comprehensive guide shows you the technologies and techniques required to build Linux into embedded systems. You will begin by learning about the fundamental elements that underpin all embedded Linux projects: the toolchain, the bootloader, the kernel, and the root filesystem. You'll see how to create each of these elements from scratch, and how to automate the process using Buildroot and the Yocto Project.Moving on, you'll find out how to implement an effective storage strategy for flash memory chips, and how to install updates to the device remotely once it is deployed. You'll also get to know the key aspects of writing code for embedded Linux, such as how to access hardware from applications, the implications of writing multi-threaded code, and techniques to manage memory in an efficient way. The final chapters show you how to debug your code, both in applications and in the Linux kernel, and how to profile the system so that you can look out for performance bottlenecks.By the end of the book, you will have a complete overview of the steps required to create a successful embedded Linux system.Style and approachThis book is an easy-to-follow and pragmatic guide with in-depth analysis of the implementation of embedded devices. It follows the life cycle of a project from inception through to completion, at each stage giving both the theory that underlies the topic and practical step-by-step walkthroughs of an example implementation.

Building a Root Filesystem

The root filesystem is the fourth and the final element of embedded Linux. Once you have read this chapter, you will be able build, boot, and run a simple embedded Linux system.

The techniques I will describe here are broadly known as roll your own or RYO. Back in the earlier days of embedded Linux, this was the only way to create a root filesystem. There are still some use cases where an RYO root filesystem is applicable, for example, when the amount of RAM or storage is very limited, for quick demonstrations, or for any case in which your requirements are not (easily) covered by the standard build system tools. Nevertheless, these cases are quite rare. Let me emphasize that the purpose of this chapter is educational; it is not meant to be a recipe for building everyday embedded systems: use the tools described in the next chapter for this.

The first objective is to create a minimal root filesystem that will give us a shell prompt. Then, using this as a base, we will add scripts to start up other programs and configure a network interface and user permissions. There are worked examples for both the BeagleBone Black and QEMU targets. Knowing how to build the root filesystem from scratch is a useful skill, and it will help you to understand what is going on when we look at more complex examples in later chapters.

In this chapter, we will cover the following topics:

• What should be in the root filesystem?
• Transferring the root filesystem to the target.
• Creating a boot initramfs.
• The init program.
• Configuring user accounts.
• A better way of managing device nodes.
• Configuring the network.
• Creating filesystem images with device tables.
• Mounting the root filesystem using NFS.

What should be in the root filesystem?

The kernel will get a root filesystem, either an initramfs, passed as a pointer from the bootloader, or by mounting the block device given on the kernel command line by the root= parameter. Once it has a root filesystem, the kernel will execute the first program, by default named init, as described in the section Early user space in Chapter 4, Configuring and Building the Kernel. Then, as far as the kernel is concerned, its job is complete. It is up to the init program to begin starting other programs and so bring the system to life.

To make a minimal root filesystem, you need these components:

• init: This is the program that starts everything off, usually by running a series of scripts. I will describe how init works in much more detail in Chapter 10, Starting Up – The init Program
• Shell: You need a shell to give you a command prompt but, more importantly, also to run the shell scripts called by init and other programs.
• Daemons: A daemon is a background program that provides a service to others. Good examples are the system log daemon (syslogd) and the secure shell daemon (sshd). The init program must start the initial population of daemons to support the main system applications. In fact, init is itself a daemon: it is the daemon that provides the service of launching other daemons.
• Shared libraries: Most programs are linked with shared libraries, and so they must be present in the root filesystem.
• Configuration files: The configuration for init and other daemons is stored in a series of text files, usually in the /etc directory.
• Device nodes: These are the special files that give access to various device drivers.
• /proc and /sys: These two pseudo filesystems represent kernel data structures as a hierarchy of directories and files. Many programs and library functions depend on proc and sys.
• Kernel modules: If you have configured some parts of your kernel to be modules, they need to be installed in the root filesystem, usually in /lib/modules/[kernel version].

In addition, there are the device-specific applications that make the device do the job it is intended for, and also the run-time data files that they generate.

In some cases, you could condense most of these components into a single, statically-linked program, and start the program instead of init. For example, if your program was named /myprog, you would add the following command to the kernel command line: init=/myprog. I have come across such a configuration only once, in a secure system in which the fork system call had been disabled, thus making it impossible for any other program to be started. The downside of this approach is that you can't make use of the many tools that normally go into an embedded system; you have to do everything yourself.

The directory layout

Interestingly, the Linux kernel does not care about the layout of files and directories beyond the existence of the program named by init= or rdinit=, so you are free to put things wherever you like. As an example, compare the file layout of a device running Android to that of a desktop Linux distribution: they are almost completely different.

However, many programs expect certain files to be in certain places, and it helps us developers if devi...