Book Image

Using Yocto Project with BeagleBone Black

By : Hafiz Muhammad I Sadiq, Irfan Sadiq
Book Image

Using Yocto Project with BeagleBone Black

By: Hafiz Muhammad I Sadiq, Irfan Sadiq

Overview of this book

Table of Contents (17 chapters)
Using Yocto Project with BeagleBone Black
About the Author
About the Reviewers

More about configuration files

We have already visited some configuration files during the build process. There are some more configuration files that were not discussed during the build process in order to avoid making it lengthier. These are bitbake.conf and machine.conf. Let's look at them.


You won't find a file with this name. Here, machine is a placeholder for the target board we are preparing our images for. For example, in our case, this file is beaglebone.conf and in the preceding configuration, it is available as beaglebone.conf in the poky/meta-yocto-bsp/conf/machine/ directory.

All of the machine- specific configurations are done in this file. We need to know about it and have some basic understanding of its contents so that we can modify it, if required. Let's go through it. The top-level header contains information in tags for documentation:

#@TYPE: Machine
#@NAME: Beaglebone machine
#@DESCRIPTION: Machine configuration for and boards

The preferred xserver can be used:

PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
XSERVER ?= "xserver-xorg \
           xf86-input-evdev \
           xf86-input-mouse \
           xf86-video-fbdev \

What extra recipes need to be built? These are built here:

MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"

Set image dependencies:


Architecture-specific configurations are found in tune files. Here, we will set the available one that will fulfill our requirements:

DEFAULTTUNE ?= "cortexa8hf-neon"
include conf/machine/include/

These tune files are present under Poky on the path that we are using in include directive.

Here, we will specify the type of filesystem images we want to create for our machine. There are other options to choose from. Also, here, we will set extra image commands in the case of the jffs2 image:

IMAGE_FSTYPES += "tar.bz2 jffs2"
EXTRA_IMAGECMD_jffs2 = "-lnp "

One of the most important options is the serial debug console. Here, we are defining our eyes with which to peek inside the board:

SERIAL_CONSOLE = "115200 ttyO0"

Here, we are tweaking our kernel options to see what recipe should be used for kernel compilation and what version of kernel needs to be built. For this, we will use the Yocto Project keywords, PREFERRED_PROVIDER and PREFERRED_VERSION:

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.14%"

We can also create another kernel image, zImage. Since this is a generic machine for BeagleBone Black and White versions, we will create device tree binary files for both of the target. You can opt not to build DTB for BeagleBone White, but this won't make much difference in terms of build time or cleanliness, if you are considering such things. Also, we can set any extra arguments that need to be passed to KERNEL:

KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"

Here, we will configure most of the aspects of our bootloaders. We will set MLO as the binary name for stage-one bootloader so that we will have it created as MLO, as we saw in the images directory. We will specify a u-boot suffix, img, to be used so that we have the u-boot.img file created. Other options are also related to u-boot, such as these:

UBOOT_MACHINE = "am335x_evm_config"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"

Now, we will determine the features that we want our machine to support or, more precisely, the features it has the ability to support. We will also determine which features we want turn on:

MACHINE_FEATURES = "usbgadget usbhost vfat alsa" 


As the name signifies, this file is related to BitBake, the real engine behind Yocto Project, which is responsible for the simplification of our build process. This file is parsed first and then the rest of the configuration files listed in it are parsed. This file is found under poky/meta/conf/ as bitbake.conf. This is not a small file, so we cannot go through it line by line. It contains more than 700 lines of configuration and metadata. Almost all the metadata used in our recipes is defined in this file.

It is not a standalone file. Instead, it includes other files from the conf directory. We can find all the files that were described earlier in it. So, bitbake.conf uses these files and the metadata definitions in them. For example, if you remember, we used some variables such as DL_DIR, TOPDIR, and TMPDIR, You can find all these variables in this file, along with their default values. This file has all the metadata arranged in different sections. It contains about 20 different sections. Variables defined in one section are used in other sections. Let's have a brief look at some of these sections.

Standard target filesystem paths

These are standard filesystem paths extensively used in different recipes. This section has further subsections. You won't need to change these variables, but you should reference these while developing recipes.

Architecture-dependent build variables

This is also a huge set of variables to define architecture-dependent metadata. These variables are prefixed with BUILD_, HOST_, TARGET_, and SDK_ so as to clarify their domain of affect.

Package default variables

Variables from this section are extensively used in recipes. These variables are used in every recipe. We will discuss most of these variables in the upcoming chapters.

General work and output directories for the build system

We have touched some of these variables while configuring our build. These define most of the build directory structure. This section contains a staging-related section. This section is very important for cross compilation, which is usually the case when using Yocto Project.

Specific image creation and rootfs population information

These variables define different properties of our root filesystem image. For example, from variables such as IMAGE_NAME, you can infer how the name of our image, core-image-sato-beaglebone-20141126124205, is created.

Build flags and options

Of course, our build flags go into this section. You can see different flags related to compiler, linker, and Make in this section.

Download locations and utilities

This section contains mirror definitions for speeding up the build process. Since we are creating BSPs that contain a lot of packages, we face time constraints. Yocto Project tries to tackle such obstacles in this way. Also, you can see commands to fetch from different versioning systems in this section.

Including the rest of the config files

As we already discussed, this file includes other configuration files. Here, you can see the list of these files.

To avoid wasting time, I am skipping the other sections. You can have a look at them at your leisure.