In this chapter, we will cover the following recipes:
In the previous chapter, we became comfortable with the build system and the reference hardware we are using. We built images, ran them, and learned how to customize and optimize our build system.
Now we have our build environment ready with the Yocto Project, it's time to think about beginning development work on our embedded Linux project.
Most embedded Linux projects require both custom hardware and software. An early task in the development process is to test different hardware reference boards and select one to base our design on. As we saw in the Building Wandboard images recipe in Chapter 1, The Build System, for this book we have chosen the Wandboard, an NXP i.MX6-based platform, as it is an affordable and open board, which makes it perfect for our needs.
The Wandboard uses a SoM that is then mounted into a carrier board and sold as a single-board computer. As the schematics are open, the SoM could be used with a different carrier board design for a much more specific product...
The changes needed to support a new hardware platform, or machine, are kept on a separate Yocto layer, called a BSP layer. This separation is best for future updates and patches to the system. A BSP layer can support any number of new machines and any new software feature that is linked to the hardware itself.
By convention, Yocto layer names start with meta, short for metadata. A BSP layer may then add a bsp keyword, and finally a unique name. We will call our layer meta-bsp-custom.
There are several ways to create a new layer:
meta-skeleton layer included in Pokyyocto-layer command-line toolYou can have a look at the meta-skeleton layer in Poky and see that it includes the following elements:
layer.conf file, where the layer configuration variables are setCOPYING.MIT license filerecipes- prefix with example recipes for BusyBox, the Linux kernel...The BSP that encapsulates the hardware modifications for a given platform is mostly located in the bootloader, usually U-Boot (Das U-Boot) for ARM devices, and the Linux kernel. Both U-Boot and the Linux kernel have upstream development trees, at git.denx.de and http://kernel.org/ respectively, but it is very common for manufacturers of embedded hardware to provide their own trees for both bootloader and kernel.
Development in U-Boot and the Linux kernel is usually done externally to Yocto, as they are easy and quicker to build using a cross-compilation toolchain, like the one provided by Yocto's SDK.
The development work is then integrated into Yocto in one of two ways:
bbappend files. This method will build the same source as the reference design board we are using as a base, and apply our changes over it. This is what we have seen in the previous recipe.We have seen how to modify the Yocto build system to both modify a U-Boot or Linux kernel recipe by adding patches or by building from a modified Git repository. Now we will see how to modify and build the U-Boot source in order to introduce our changes.
Even though the Yocto Project is very flexible, it is best not to use the Yocto Project build system while developing the BSP. The U-Boot and Linux kernel binaries are separate artifacts and can be programmed individually, so it is faster and less error-prone to just build them using the standalone Yocto SDK and not the Yocto build system. This also abstracts BSP developers from the complexities of the Yocto build system.
The Linux kernel is a monolithic kernel and, as such, shares the same address space. Although it has the ability to load modules at runtime, the kernel must contain all the symbols the module uses at compilation time. Once the module is loaded, it will share the kernel's address space too.
The kernel build system (kbuild), uses conditional compilation to decide which parts of the kernel are compiled. kbuild is independent of the Yocto build system.
In this recipe, we will explain how kbuild works.
The kernel kbuild system reads its configuration at build time from a .config text file in the kernel root directory. This is referred to as the kernel configuration file. It is a text file where each line contains a single configuration variable that starts with the CONFIG_ prefix.
There are multiple ways to modify a kernel configuration file:
.config file, although this is not recommended.The Linux kernel contains a set of default machine configurations. For ARM, these are under the arch/arm/configs directory on the Linux source. The Yocto Project, however, uses a copy of this configuration file inside the BSP layer metadata. This enables the use of different configuration files for different purposes.
In this recipe, we will see how to configure the Linux kernel and add the resulting configuration file to our BSP layer.
Before configuring the kernel, we need to provide a default configuration for our machine, which is the one the Yocto project uses to configure a kernel. When defining a new machine in your BSP layer, you need to provide a defconfig file.
The Wandboard's defconfig file is stored under sources/meta-freescale-3rdparty/recipes-kernel/linux/linux-wandboard/defconfig.
This will be the base defconfig file for our custom hardware, so we copy it to our BSP layer:
$ cd /opt/yocto/fsl-community-bsp/sources$ mkdir -p meta-bsp-custom...
As was the case with U-Boot, Linux kernel development is quicker and less error-prone when using the Yocto SDK to build it. However, for smaller changes, the Yocto build system can also be used.
In this recipe, we will show you how to build and modify the Linux kernel source both with Yocto's SDK and the Yocto build system, and boot our target device with it.
We will use the Yocto Project's SDK already installed in your host:
$ source /opt/poky/2.4/environment-setup-cortexa9hf-neon-poky-linux-gnueabi$ cd /opt/yocto/linux-wandboard$ cp /opt/yocto/fsl-community-bsp/sources/meta-bsp-custom/recipes-kernel/linux/linux-wandboard-4.1-2.0.x/wandboard-custom/defconfig arch/arm/configs/wandboard_defconfig$ make wandboard_defconfig
$ make -jNThe Linux kernel has the ability to load modules at runtime that extend the kernel's functionality. Kernel modules share the kernel's address space and have to be linked against the kernel they are going to be loaded onto. Most device drivers in the Linux kernel can either be compiled into the kernel itself (built-in) or as loadable kernel modules that need to be placed in the root filesystem under the /lib/modules directory.
The recommended approach to develop and distribute a kernel module is to do it with the kernel source. A module in the kernel tree uses the kernel's kbuild system to build itself, so as long as it is selected as a module in the kernel configuration and the kernel has module support enabled, Yocto will build it.
However, it is not always possible to develop a module in the kernel. Common examples are hardware manufacturers that provide Linux drivers for a wide variety of kernel versions and have an internal development process separated...
We will highlight some of the most common methods employed by kernel developers to debug kernel issues.
Above all, debugging the Linux kernel remains a manual process, and the most important developer tool is the ability to print debug messages.
The kernel uses the printk function, which is very similar syntactically to the printf function call from standard C libraries, with the addition of an optional log level. The allowed formats are documented in the kernel source under Documentation/printk-formats.txt.
The printk functionality needs to be compiled into the kernel with the CONFIG_PRINTK configuration variable. You can also configure the Linux kernel to prepend a precise timestamp to every message with the CONFIG_PRINTK_TIME configuration variable, or even better, with the printk.time kernel command-line argument or through the sysfs under /sys/module/printk/parameters.
We have seen the most general techniques for debugging the Linux kernel. However, some special scenarios require the use of different methods. One of the most common scenarios in embedded Linux development is the debugging of the booting process. This recipe will explain some of the techniques used to debug the kernel's booting process.
A kernel crashing on boot usually provides no output whatsoever on the console. As daunting as that may seem, there are techniques we can use to extract debug information. Early crashes usually happen before the serial console has been initialized, so even if there were log messages, we would not see them. The first thing we will show is how to enable early log messages that do not need the serial driver.
In case that is not enough, we will also show techniques to access the log buffer in memory.
Recent versions of the Linux kernel contain a set of tracers that, by instrumenting the kernel, allow you to analyze different areas such as the following:
The tracers have no performance overhead when not enabled.
The tracing system can be used in a wide variety of debugging scenarios, but one of the most common tracers used is the function tracer. It instruments every kernel function with an NOP call that is replaced and used to trace the kernel functions when a trace point is enabled.
To enable the function tracer in the kernel, use the CONFIG_FUNCTION_TRACER and CONFIG_FUNCTION_GRAPH_TRACER configuration variables.
The kernel tracing system is controlled via a tracing file in the debug filesystem, which is mounted by default on Yocto's default images. If not, you can mount it with the following:
$ mount -t...The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system.
In this recipe, we will explain how to work with device trees.
Devices that cannot be discovered by the CPU are handled by the platform devices API on the Linux kernel. The device tree replaces the legacy platform data where hardware characteristics were hardcoded in the kernel source so that platform devices can be instantiated. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command-line, and more.
The device tree was first used by the PowerPC architecture and was adopted later on by ARM and all others, except x86. It was defined by the Open Firmware specification, which defined the flattened device tree format in Power.org Standard for Embedded Power Architecture Platform Requirements...
This recipe will show some techniques to debug common problems with the device tree.
As mentioned before, problems with the syntax of device tree files usually result in the kernel crashing early in the boot process. Other types of problems are more subtle and usually appear once a driver is making use of the information provided by the device tree. For both types of problems, it is helpful to be able to look not only at the device tree syntax file, but also at the device tree blob, as it is read by both U-Boot and the Linux kernel. It may also be helpful to modify the device tree on the fly using the tools that U-Boot offers.
Let's see how to access the device tree at runtime, both from a running U-Boot and Linux.
© 2018 Packt Publishing Limited All Rights Reserved
