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 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 needed to set up 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. Currently, the supported distributions are the following:

• Ubuntu 12.04 (LTS)

• Ubuntu 13.10

• Ubuntu 14.04 (LTS)

• Fedora release 19 (Schrödinger's Cat)

• Fedora release 20 (Heisenbug)

• CentOS release 6.4

• CentOS release 6.5

• Debian GNU/Linux 7.x (Wheezy)

• openSUSE 12.2

• openSUSE 12.3

• openSUSE 13.1

If our preferred distribution is not in 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 find instructions for Debian and Fedora, our preferred...

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, using the following command:

$: git clone git://git.yoctoproject.org/poky --branch daisy

Tip

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 1.6 and Poky Version 11.0. The code name is Daisy, as 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 build environment. The script must be run as shown:

$: source poky/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, choose 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 we probably want to change from the default is the following:

BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
MACHINE ??= "qemux86"

Tip

BB_NUMBER_THREADS and PARALLEL_MAKE should be set to twice the host processor's number of cores.

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

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 running the following command from the poky directory:

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

All the recipes provide images which are, in essence, a set of unpacked and configured packages, generating a filesystem that we can use on an actual hardware.

Next, we can see a short description of available images, as follows:

• build-appliance-image: This is a virtual machine image which can be run by either VMware Player or VMware Workstation that allows to run builds.

• core-image-full-cmdline: This is a console-only image with full support for the target device hardware.

• 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-minimal-dev: This image includes all contents of the core-image-minimal image and adds headers and libraries that we can use...

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 sample to run without involving an 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, MIPS, MIPS64, PowerPC, and x86 and x86-64 emulations are supported.

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

$: runqemu <machine> <zimage> <filesystems>

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 Hob, which provides a human friendly interface for BitBake, and we will use it to build an image and customize it further.