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

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:

• Manually, once you know what is required
• By copying the meta-skeleton layer included in Poky
• By using the yocto-layer command-line tool

You can have a...

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

• With patches added to the kernel and U-Boot bbappend files. This method will build the same source as the reference design board we are using as a base, and apply our changes...

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

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

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:

1. Prepare the environment as follows:

$ source /opt/poky/2.4/environment-setup-cortexa9hf-neon-poky-linux-gnueabi  

2. Configure the kernel with the default machine configuration:

$ cd /opt/yocto/linux-wandboard
$ cp /opt/yocto/fsl-community-bsp/sources...