Chapter 2. Baking Our Poky-Based System

In this chapter we will understand the basic concepts involved in the Poky workflow. Let's get our hands dirty with the steps to download and configure, prepare the Poky build environment, and bake something usable. The steps covered here are commonly used for testing and development. They give us the whole experience of using Poky and a taste of its capabilities.

Configuring a host system

The process that we need to set up on our host system depends on the distribution we run on it. Poky has a set of supported Linux distributions, and if we are new to embedded Linux development, it is advisable to use one of the supported Linux distributions to avoid wasting time debugging build issues related to the host system support.

If you use the current release of one of following distributions, you should be good:

• Ubuntu
• Fedora
• CentOS
• Debian
• openSUSE

To confirm if your version is supported, it is advisable to check the official documentation online at http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#detailed-supported-distros.

If your preferred distribution is not on the preceding list, it doesn't mean it is not possible to use Poky on it. However, it is unknown whether it will work, and we may get unexpected results.

The packages that need to be installed into the host system vary from one distribution to another. Throughout this book, you will...

Downloading the Poky source code

After we install the needed packages into our development host system, we need to get the Poky source code that can be downloaded with Git by using the following command:

$ git clone git://git.yoctoproject.org/poky -b rocko

Note

Learn more about Git at http://git-scm.com.

After the download process is complete, we should have the following contents inside the poky directory:

Note

The examples and code presented in this and the next chapters use the Yocto Project Version 2.4. The code name is Rocko, as the reference.

Preparing the build environment

Inside the poky directory, there is a script named oe-init-build-env, which should be used to set up the building environment. The script must be run as shown:

$ source oe-init-build-env [build-directory]

Here, build-directory is an optional parameter for the name of the directory where the environment is set; in case it is not given, it defaults to build. The build-directory is the place where we perform the builds.

It is very convenient to use different build directories. We can work on distinct projects in parallel or different experimental setups without affecting our other builds.

Note

Throughout the book, we will use build as the build directory. When we need to point to a file inside the build directory, we will adopt the same convention, for example, build/conf/local.conf.

Knowing the local.conf file

When we initialize a build environment, it creates a file called build/conf/local.conf, which is a powerful tool that can configure almost every aspect of the build process. We can set the machine we are building for, the toolchain host architecture to be used for a custom cross-toolchain, optimize options for maximum build time reduction, and so on. The comments inside the build/conf/local.conf file are a very good documentation and reference of possible variables, and their defaults. The minimal set of variables that we probably want to change from the default is the following:

MACHINE ??= "qemux86"

The MACHINE variable is where we determine the target machine we wish to build for. At the time of writing this book, Poky supports the following machines in its reference BSP:

• beaglebone: This is BeagleBone, that is the reference platform for 32-bit ARM
• genericx86: This is a generic support for 32-bit x86-based machines
• genericx86-64: This is a generic support for 64...

Building a target image

Poky provides several predesigned image recipes that we can use to build our own binary image. We can check the list of available images by running the following command from the poky directory:

$ ls meta*/recipes*/images/*.bb

All the recipes provide images which are a set of unpacked and configured packages, generating a filesystem that we can use on a hardware or one of the supported QEMU machines.

Next, we can see the list of most commonly used images:

• core-image-minimal: This is a small image allowing a device to boot, and it is very useful for kernel and boot loader tests and development.
• core-image-base: This is a console-only image that fully supports the target device hardware.
• core-image-weston: This is an image that provides the Wayland protocol libraries and the reference Weston compositor.
• core-image-x11: This is a very basic X11 image with a terminal.
• core-image-sato: This is an image with Sato support and a mobile environment for mobile devices that use X11...

Running images in QEMU

As many projects have a small portion that is hardware dependent, the hardware emulation comes to speed up the development process by enabling a test run without involving any actual hardware.

Quick EMUlator (QEMU) is a free and open source software package that performs hardware virtualization. The QEMU-based machines allow test and development without real hardware. Currently, the ARM, ARM64, MIPS, MIPS64, PowerPC, and x86 and x86-64 emulations are supported.

The runqemu script enables and makes use of QEMU with the OpenEmbedded-Core supported machines easier. The way to run the script is as follows:

$ runqemu <machine> <zimage> <filesystem>

Here, <machine> is the machine/architecture to be used as qemuarm, qemumips, qemuppc, qemux86, or qemux86-64. Also, <zimage> is the path to a kernel (for example, zimage-qemuarm.bin). Finally, <filesystem> is the path to an ext3 image (for example, filesystem-qemuarm.ext3) or an NFS directory....

Summary

In this chapter we learned the steps needed to set up Poky and get our first image built. We ran that image using runqemu, which gave us a good overview of the available capabilities. In the next chapter, we will be introduced to Toaster, which provides a human friendly interface for BitBake, and we will use it to build an image and customize it further.