An Introduction to the Yocto Project

The Yocto Project is an open source project initiated by the Linux Foundation, which makes development on embedded devices easier and portable. It's an end-to-end embedded Linux development environment with various tools, configuration files and documentation, and pretty much has everything one needs. This article attempts to introduce the project, and is by no means a complete tutorial. It assumes that the reader is familiar with the nuances of embedded development environments.

The industry has seen a proliferation of embedded devices and processors. As these have grown more powerful and feature-rich, the use and popularity of the Linux operating system has skyrocketed. One of the driving factors for its popularity is because it remains open source, offers free licensing and extensive usage, which in turn has led to an abundance of applications.

However, embedded developers cannot simply pick up a standard Linux distribution or application for use in their tiny environments. They face challenging tasks like handpicking boot-loaders, the kernel, libraries, applications, and development tools specific to their custom hardware environment, before cross-compiling and optimising them to fit in their minuscule embedded environments.

The solutions to these challenges are not easy, and a developer’s group will need considerable effort, experience and exposure to address them. Moreover, spending time on these problems will leave developers with little time and energy to really concentrate on the core task of building excellent features for their boards. Non-commercial and commercial embedded Linux distributors offer well-tested solutions for specific embedded processors, but for an embedded developer, this is a nightmare. Every new project demands the learning of a new set of tools and development environments prior to even getting started.

Evolution

It all started with the OpenZaurus distribution, which had a tool called buildroot to solve some of the problems faced by embedded developers. The constraints with buildroot were that it could not scale to different targets apart from Sharp's Zaurus. Its users eventually began discussing about the possibilities of a new generic build, which led to the beginning of OpenEmbedded (OE). This is an embedded build system, and provides a 'build from source' methodology, to reliably bootstrap customised Linux distributions that cater to embedded devices and beyond. It has a robust structure for metadata, and vast coverage for open source software. Feature wise, it came out as the most advanced system in the market, and being specifically designed for the customisation needs of the embedded market space, soon became the industry standard. A large number of organisations were using OE, which in turn increased support and enhanced the internals of the OE. While being a very good first-of-its-kind base, OE suffered due to its complexity, steep learning curve and lack of documentation. Apart from being a build system, OE started to collate various other tools as well—while it was inherently not designed to do so.

In November 2010, industry leaders joined together to form the Yocto Project under the umbrella of the Linux Foundation, and announced that the work would continue under this new name. Despite Yocto being a fork of OpenEmbedded, the common areas are now down to OE-core. This is mutually beneficial for both OE and Yocto, where the resultant output is a high-quality OE-core with fewer fully featured software tools in a single framework. Yocto got a head start with a project built on commercial learnings and community acceptance.

The Yocto Project

According to the Yocto Project website: “It’s not an embedded Linux distribution—it creates a custom one for you.”

With its vibrant community, the Yocto Project has rapidly gained traction among silicon companies, embedded developers, operating system providers and tools providers, thus capturing the entire gamut of embedded development. Some of the famous names involved are Cavium Networks, Dell, FreeScale Semiconductor, Intel, Texas Instruments, etc. Despite being funded by several major organisations, the Yocto Project remains independently governed by the Linux Foundation, based on the open source principles of collaboration and transparency.

Yocto gives developers a head start by providing hardware BSPs (Board Support Packages) a standardised format across architectures, the latest and well-tested metadata for the kernel, an ‘automagically’ created Application Developer Kit (ADK), and great flexibility for embedded device requirements.

As per Yocto's documentation page (yoctoproject.org/

documentation), currently four target architectures—ARM, MIPS, PowerPC and x86 (32 and 64 bit)—are supported. For each of these, there is support for a QEMU virtual machine, where images can be booted under emulation. For each architecture, there is sample hardware for reference implementation. These are: ƒ ARM: BeagleBoard ƒ PowerPC: FreeScale mpc8315e-rdb ƒ MIPS: Ubiquity Networks Router Station ƒ x86: Atom Black Sand, WEBS-2120

Some of the highlights of Yocto are: → A new release every six months with the latest software components. → A repository for open industry specific BSPs. → Thorough documentation.

The essential tools and components of Yocto

Poky

One of the fundamental components is the reference build system called Poky (originally derived from Poky Linux). Created by Richard Purdie, Poky is a large and complex system, which combines various components such as BitBake (core building engine), Metadata (the config present in the form layers), common generic OE-core, BSPs (interface layers between hardware and OS), and documentation for its build system. Poky's de facto tool-chain is based on the GNU Compiler Collection (GCC), but other tool-chains can be used as well.

ADT

Found at http://www.yoctoproject.org/projects/applicationdevelopment-toolkit-adt, this is a toolkit to enable software developers to provide an SDK that can be used by end user developers. ADT has Qemu, build tool-chains, profilers and debuggers as a part of it.

Hob

A new entrant into the project, this tool provides a graphical interface to BitBake. Most tasks that are done on the commandline can be achieved by the Hob GUI. Hob runs as a standalone tool. A new Web-based tool called WebHob is on its way.

Note: There are more tools in the Yocto Project; explore them at http://www.yoctoproject.org/projects.

The Yocto build process

The build process consists of fetching the source from various defined sources, patching the code if required, compiling the big bunch, and throwing out image or ROM files. See Figure 2.

Download and try Yocto

Let's get our hands dirty setting up Yocto. Visit http://yoctoproject. org, click Documentation to keep it handy. Next, bring up a Linux system and install all the necessary dependencies. The

IP

scripts

kernel System binaries BSP

Config files

Custom patches Custom tools kernel bootloaders

Makefile s

Kernel code libraries

Arch files

Elibc/gli bc IDE plugins

Binaries Application code

depend encies Cross compiler s

packagi ng SDK

images IMAGE/ROM

IMAGE SPECIFIC BUILD SDK

SDK SPECIFIC BUILD

BUILD PROCESS

Public repos Private code Git/CVS/SCM

Board support config Metadata config System config user config

Generic Embedded Development environment Yocto Environment

Figure 1: A generic embedded environment transformed to Yocto Project

Figure 2: Yocto build process overview

FETCHING PATCHING COMPLIATION

IMAGE

Figure 3: Screenshot of dependencies on an Ubuntu machine

Figure 4: Sourcing the open embedded environment

dependencies for an Ubuntu system are in Figure 3. Refer to your Quick Start Guide if you are working on a different distro. Download the latest Yocto release with Git, using the command git clone git:// git.yoctoproject.org/poky.git to do so. Tarballs are also available.

Explore the main config in the directory conf/local.conf. For a machine with more than one CPU, you can have multiple compilation threads:

BB_NUMBER_THREADS=”2” PARALLEL_MAKE=”-j 2”

Set the environment by sourcing the ‘oe-init-build-env’ file in the main directory. This file should be sourced (. ./oe-init-build-env) and not executed in a sub-shell. See Figure 4. Once this is done, you are automatically moved to a different directory called poky/build.

Execute bitbake –k core-image-minimal. This is the minimalist image being created, of the x86 type. By changing options, you can compile for different architectures and different types of images.

Figure 5: Initiating hob tool

Figure 7: Hob selection page where you can select base image type and customise layers Figure 6: Hob screenshot while it is parsing various recipients

Figure 8: Hob build process which will produce the final image

Let’s try Hob here—see Figure 5 (terminal) and Figure 6 (Hob GUI start-up). The next step is shown in Figure 7. As you can see, the target qemux86 has been selected. Next, select ‘core-image-minimal’ and kick off the build. Hob starts building (Figure 8). This is going to take some time, depending on the config and parallelism options you have set.

After the build, you can execute runqemu qemux86 to run the Qemu emulator with the newly compiled image.

Some of the other configuration files in the Poky system are: 1) Configuration (*.conf)—global variables ƒ build/conf/local.conf (local user-defined variables) ƒ ./meta-yocto/conf/distro/poky.conf (Yocto policy config variables) ƒ ./meta/conf/machine (machine-specific variables) 2) conf/local.conf—additional features: ƒ EXTRA_IMAGE_FEATURES adds features (groups of packages) ƒ INCOMPATIBLE_LICENSE = ‘GPLv3’ eliminates packages using this licence 3) Recipes for building packages ƒ For instance, meta/recipes-core/glib-2.0/glib2.0_2.32.4.bb builds GLib and installs it.

The documentation provides excellent explanations for many other files.

You must, however, watch out for the following: ƒ If custom patches, which are pulled from upstream, are incorporated in the source, Yocto needs to carry them within,

and apply and fix these patches for every future update. ƒ Kickstarting a project in Yocto involves a fair bit of set-up work initially. ƒ Yocto does not mandate any version control while pulling code from upstream.

Getting involved

Like every other open source project out there, Yocto depends on contributions from members like you and me. Refer to the contribution pages at yoctoproject.org, and be a part of this excellent project.

Mastering Yocto tools effectively can be a little daunting initially, but the time spent on it is well worth it. The flexible customisation and configurable options give versatile projectspecific control, which will help developers of embedded systems to concentrate on their core software development.

References

[1] http://www.yoctoproject.org [2] #yocto on irc freenode.irc.net (#yocto channel)

Acknowledgements

I am profoundly thankful to Divyanshu Verma and Tandava Popuri for reviewing this article and providing constructive feedback.

By: Surya Prabhakar

The author works as a software development engineer for the Linux Engineering Group of Dell India R&D Centre, Bengaluru. He has close to 10 years of industry experience and has worked on Linux, embedded systems, virtualisation, cloud computing, etc. He can be reached at surya_prabhakar@dell.com.