In this chapter, we will discover the Yocto Project and its main principles. All the concepts used throughout the book will be introduced here. We will discuss the history of the Yocto Project, the build system, Poky, OpenEmbedded-Core, BitBake, metadata, and the Yocto Project workflow.
The Yocto Project is an umbrella project covering a fairly wide gamut of embedded Linux technologies. It is not a Linux distribution, as explained on the Yocto Project website:
"The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture."
Sponsored by the Linux Foundation, the Yocto Project is more than a build system. It provides tools, processes, templates and methods so that developers can rapidly create and deploy products for embedded devices(the Raspberry Pi, Beagleboard, Nitrogen6x, SAMA5D3, Olinuxino, and so on) or QEMU. The two main components that make up the Yocto Project are:
Poky: This is the build system (the reference distribution).
BitBake: This is the scheduler. It is a tool based on the Gentoo distribution.
Around November 2010, the Linux Foundation announced that this entire work would continue under the banner of the Yocto Project as a project sponsored by the Linux Foundation (with Richard Purdie, Fellow of the Linux Foundation, as Architect). It was then established that the Yocto Project and OpenEmbedded would coordinate on a core set of package metadata called OE-Core, combining the best of both Poky and OpenEmbedded with an increased use of layering for additional components.
As mentioned before, we are in the world of build systems with the Yocto Project. A build system enables you to:
Compile or cross-compile applications
Test output binaries and ecosystem compatibility
Deploy generated images
To perform these steps, several tools exist. These are some of them:
For example, Buildroot is a set of makefiles for automated generation in embedded systems. It supports compiling the bootloader (U-Boot, for example), kernel (zImage or bzImage), and basic controls through BusyBox and third-party applications. Buildroot works on various architectures, such as ARM, x86, and MIPS. For further information, refer to the full documentation in English at https://buildroot.org/docs.html .
"Buildroot is a tool maintained in part by a French company that specializes in embedded Linux development called Free Electrons"
Buildroot is a much more simplistic approach than the one we will discover through this book on the Yocto Project. Buildroot is rather dedicated to firmware generation, while Yocto/OpenEmbedded is oriented towards distribution. Buildroot offers 700 recipes compared to the Yocto Project, which offers over 8000.
The core components (other available tools are optional) of the Yocto Project are:
The BSP layer (meta-raspberry, meta-fsl-arm, meta-ti, meta-intel, meta-sunxi, and so on)
The following diagram shows all the layers that we will discover through this book. We will study all the tools through various examples, allowing better comprehension.
Poky is the reference Yocto Project distribution. It contains some of basic components (called the build system) of OpenEmbedded and a set of metadata for creating embedded distributions for a number of targets. It is platform independent and performs cross-compiling using the BitBake tool (a task scheduler), OpenEmbedded-Core, and a default set of metadata, as shown in the following figure. It provides the mechanism to build and combine thousands of distributed open source projects.
The Poky build system is poised to become the reference in the industrial world as evinces by industry leaders such as Wind River, Intel, Montavista, and Mentor Graphics.
Angstrom ( http://www.angstrom-distribution.org/ ) is another distribution based on OpenEmbedded-Core. You might consider Angstrom and Poky to be close cousins, because Poky is also based on OpenEmbedded-Core.
BitBake, the build engine, is a task scheduler (like GNU Make) which parses several scripts (shell and Python, for example).
Once the environment is built, BitBake will execute the task that has been requested. If no task is provided, BitBake will run the default task, called
To run a task, BitBake will first look for an environment variable called
do_ <task name>, which will contain the task code to execute (in Python or a shell). So, to compile a Yocto recipe, use the code contained in the
In short, from the information contained in the recipes (or metadata), it downloads the sources of projects from the Internet, a local directory, or a version-control system (such as Git), and then builds in the order determined by the dependency graph generated dynamically. Finally, it installs binaries, generates the corresponding package, and builds the final image, which can be installed on the target (Raspberry Pi for us).
The following picture shows how BitBake works:
The OpenEmbedded-Core metadata collection (meta in the following diagram) provides the engine of the Poky build tool. It is designed to provide the core features (several recipes). It provides support for six different processor architectures (ARM, x86, x86-64, PowerPC, MIPS, and MIPS64), supporting only QEMU-emulated machines.
The organization of OpenEmbedded-Core is depicted here:
This layer includes different recipes, which describe how to fetch, configure, compile and package applications and images.
Metadata, which is composed of a mix of Python and shell script text files (
.inc), provides a tremendously flexible system. Metadata refers to the build instructions themselves as well as the data used to control what things get built and to affect how they are built. The metadata also includes commands and data used to indicate which versions of software are used and where they are obtained from. Poky uses this to extend OpenEmbedded-Core and includes two different layers, which are another metadata subset. Here are their details:
* meta-yocto: This layer provides the default and supported distributions, visual branding, and metadata tracking information (maintainers, upstream status, and so on)
* meta-yocto-bsp: This layer, on top of it, provides the hardware reference board support (BSP) for use in Poky
We will discover metadata in depth through Chapter 4, Understanding the BitBake tool.
The following diagram represents the Yocto Project development environment at a high level in order to present the cross-compilation framework:
Let's look at what the components in the diagram stand for:
* User Configuration : This is metadata you can use to control the build process.
* Metadata layers : These are various layers that provide software, machine, and distribution metadata.
* Source files : These contain upstream releases, local projects, and source control management (Git, SVN, and so on).
* Build system : These are processes under the control of BitBake. This block expands on how BitBake fetches source files, applies patches, completes compilation, analyzes output for package generation, creates and tests packages, generates images, and generates cross-development tools.
* Package feeds : These are directories containing output packages (RPM, DEB, or IPK), which are subsequently used in the construction of an image or SDK produced by the build system. These feeds can also be copied and shared using a web server or other means to facilitate extending or updating existing images on devices at runtime if runtime package management is enabled.
* Images : These are images produced by the development process (the pieces that compose the operating system, such as the kernel image, bootloader, and rootfs).
* Application development SDK : These are cross-development tools that are produced along with an image or separately with BitBake.
This first chapter provided an overview on how the Yocto Project works, the core components that form it, such as Poky, OpenEmbedded-Core, and BitBake, and how they work within the Yocto Project.
In the next chapter, we will practice the workflow of the Yocto Project with different steps to download, configure, and prepare the Poky build environment in order to generate our first Poky image for the Raspberry Pi.