Embedded Linux Development Using Yocto Project Cookbook: Practical recipes to help you leverage the power of Yocto to build exciting Linux-based systems , Second Edition

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.

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:

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 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.

$ 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.

$ 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 -jN

The 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.

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.

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.

$ 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.

This recipe will show some techniques to debug common problems with the device tree.