Chapter 7: Developing with Yocto

Bringing up Linux on unsupported hardware can be a painstaking process. Luckily, Yocto provides Board Support Packages (BSPs) to bootstrap embedded Linux development on popular single-board computers such as the BeagleBone Black and Raspberry Pi 4. Building on top of an existing BSP layer lets us quickly take advantage of complex built-in peripherals such as Bluetooth and Wi-Fi. In this chapter, we will create a custom application layer to do just that.

Next, we will look at the development workflow that's enabled by Yocto's extensible SDK. Modifying software running on a target device usually means swapping out the SD card. Since rebuilding and redeploying full images is too time-consuming, I will show you how to use devtool to quickly automate and iterate over your work. While doing so, you will learn how to save your work in your own layers so that it does not get lost.

Yocto not only builds Linux images but entire Linux distributions...

Technical requirements

To follow along with the examples in this chapter, make sure you have the following:

• A Linux-based host system with a minimum of 60 GB available disk space
• Yocto 3.1 (Dunfell) LTS release
• Etcher for Linux
• A microSD card reader and card
• A Raspberry Pi 4
• A 5V 3A USB-C power supply
• An Ethernet cable and port for network connectivity
• A Wi-Fi router
• A smartphone with Bluetooth

You should have already built the 3.1 (Dunfell) LTS release of Yocto in Chapter 6, Selecting a Build System. If you have not, then please refer to the Compatible Linux Distribution and Build Host Packages sections of the Yocto Project Quick Build guide (https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html) before building Yocto on your Linux host according to the instructions in Chapter 6.

All the code for this chapter can be found in the Chapter07 folder of this book's GitHub repository: https://github...

Building on top of an existing BSP

A Board Support Package (BSP) layer adds support for a particular hardware device or family of devices to Yocto. This support usually includes the bootloader, device tree blobs, and additional kernel drivers needed to boot Linux on that specific hardware. A BSP may also include any additional user space software and peripheral firmware needed to fully enable and utilize all the features of the hardware. By convention, BSP layer names start with the meta- prefix, followed by the machine's name. Locating the best BSP for your target device is the first step toward building a bootable image for it using Yocto.

The OpenEmbedded layer index (https://layers.openembedded.org/layerindex) is the best place to start looking for quality BSPs. Your board's manufacturer or silicon vendor may also offer BSP layers. The Yocto Project provides a BSP for all variants of the Raspberry Pi. You can find the GitHub repository for that BSP layer and all the...

Capturing changes with devtool

In the previous chapter, you learned how to create a recipe for a helloworld program from scratch. A copy-paste approach to packaging recipes may work initially, but it soon becomes very frustrating as your project grows and the number of recipes you need to maintain multiplies. I'm here to show you a better way of working with package recipes – both yours and those that are contributed to upstream by some third party. It is called devtool and it is the cornerstone of Yocto's extensible SDK.

Development workflows

Before you get started with devtool, you want to make sure that you're doing your work in a new layer instead of modifying recipes in-tree. Otherwise, you could easily overwrite and lose hours and hours of work:

1. First, navigate one level above the directory where you cloned Yocto.
2. Next, set up your BitBake work environment:

   $ source poky/oe-init-build-env build-mine

   This sets a bunch of environment variables...

Building your own distro

At the start of the previous chapter, I told you that Yocto gives you the ability to build your own custom Linux distribution. This is done by way of a distro layer like meta-poky. As we have seen, you don't need your own distro layer to build your own custom images. You can go a long way without ever having to modify any of Poky's distribution metadata. But if you want to alter distro policies (for example, features, C library implementations, choice of package manager, and so on), then you can choose to build your own distro.

Building your own distro is a three-step process:

1. Create a new distro layer.
2. Create a distro configuration file.
3. Add more recipes to your distro.

But before we get into the technical details of how to do that, let's consider when it's the right time to roll your own distro.

When and when not to

Distro settings define the package format (rpm, deb, or ipk), package feed, init system ...

Provisioning a remote package server

Setting up an HTTP remote package server and pointing your target clients at it is easier than you might think. The client-side server address configuration varies between package managers. We will configure opkg manually on the Raspberry Pi 4.

Let's start with the package server:

1. First, navigate one level above the directory where you cloned Yocto.
2. Next, set up your BitBake work environment:

   $ source poky/oe-init-build-env build-rpi

   This sets a bunch of environment variables and puts you back in the
   build-rpi directory.

3. Build the curl package:

   $ bitbake curl

4. Populate the package index:

   $ bitbake package-index

5. Locate the package installer files:

   $ ls tmp-glibc/deploy/ipk

   There should be three directories named aarch64, all, and raspberrypi4_64 in ipk. The architecture directory is aarch64, while the machine directory is raspberrypi4_64. The names of these two directories will vary, depending on how your image has been configured...

Summary

I know that was a lot to absorb. And trust me – this is just the beginning. Yocto is a never-ending rabbit hole that you don't climb out of. The recipes and tools are constantly changing and much of the documentation, while there is lots of it, is sadly out of date. Luckily, there is devtool, which automates much of the tedium and mistakes of
copy-paste development away. If you use the tools provided for you and continually save your work to your own layers, Yocto doesn't have to be painful. Before you know it, you'll be rolling your own distro layer and running your own remote package server.

A remote package server is just one way to deploy packages and applications. We will learn about a few others later in Chapter 16, Packaging Python. Despite the title, some of the techniques we'll look at in that chapter (for example, conda and Docker) apply to any programming language. While package managers are great for development, runtime package management...

Further reading

The following resources contain more information about the topics that were introduced in this chapter:

• Transitioning to a Custom Environment, Yocto Project: https://www.yoctoproject.org/docs/transitioning-to-a-custom-environment
• Yocto Project Development Manual, by Scott Rifenbark: https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html
• Using Devtool to Streamline Your Yocto Project Workflow, by Tim Orling:
  https://www.youtube.com/watch?v=CiD7rB35CRE
• Using a Yocto build workstation as a remote opkg repository, Jumpnow Technologies: https://jumpnowtek.com/yocto/Using-your-build-workstation-as-a-remote-package-repository.html