The first thing you need to do is set up the Yocto Project build environment by sourcing the environment setup script as follows:

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

The build_dir is optional and specifies the directory Yocto Project uses for the build. If you do not specify a build directory it defaults to build in your current working directory. A common practice is to use a different build directory for different targets. For example, ~/build/x86 for a qemux86 target, and ~/build/arm for a qemuarm target. See oe-init-build-env for more information on this script.

Once the Yocto Project build environment is set up, you can build a target using:

     $ bitbake <target>
            

The target is the name of the recipe you want to build. Common targets are the images in meta/recipes-core/images, /meta/recipes-sato/images, etc. all found in the Yocto Project files. Or, the target can be the name of a recipe for a specific piece of software such as busybox. For more details about the images the Yocto Project supports, see the "Reference: Images" appendix.

When building an image using GPL components, you need to maintain your original settings and not switch back and forth applying different versions of the GNU Public License. If you rebuild using different versions of GPL, dependency errors might occur due to some components not being rebuilt.

The log file for shell tasks is available in ${WORKDIR}/temp/log.do_taskname.pid. For example, the compile task for the QEMU minimal image for the x86 machine (qemux86) might be tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_compile.20830. To see what BitBake runs to generate that log, look at the corresponding run.do_taskname.pid file located in the same directory.

Presently, the output from Python tasks is sent directly to the console.

Any given package consists of a set of tasks. The standard BitBake behavior in most cases is: fetch, unpack, patch, configure, compile, install, package, package_write, and build. The default task is build and any tasks on which it depends build first. Some tasks exist, such as devshell, that are not part of the default build chain. If you wish to run a task that is not part of the default build chain, you can use the -c option in BitBake as follows:

     $ bitbake matchbox-desktop -c devshell
            

If you wish to rerun a task, use the -f force option. For example, the following sequence forces recompilation after changing files in the working directory.

     $ bitbake matchbox-desktop
               .
               .
        [make some changes to the source code in the working directory]
               .
               .
     $ bitbake matchbox-desktop -c compile -f
     $ bitbake matchbox-desktop
            

This sequence first builds matchbox-desktop and then recompiles it. The last command reruns all tasks (basically the packaging tasks) after the compile. BitBake recognizes that the compile task was rerun and therefore understands that the other tasks also need to be run again.

You can view a list of tasks in a given package by running the listtasks task as follows:

     $ bitbake matchbox-desktop -c listtasks
            

The results are in the file ${WORKDIR}/temp/log.do_listtasks.

Sometimes it can be hard to see why BitBake wants to build some other packages before a given package you have specified. The bitbake -g targetname command creates the depends.dot and task-depends.dot files in the current directory. These files show the package and task dependencies and are useful for debugging problems. You can use the bitbake -g -u depexp targetname command to display the results in a more human-readable form.

You can see debug output from BitBake by using the -D option. The debug output gives more information about what BitBake is doing and the reason behind it. Each -D option you use increases the logging level. The most common usage is -DDD.

The output from bitbake -DDD -v targetname can reveal why BitBake chose a certain version of a package or why BitBake picked a certain provider. This command could also help you in a situation where you think BitBake did something unexpected.

If you really want to build a specific .bb file, you can use the command form bitbake -b <somepath/somefile.bb>. This command form does not check for dependencies so you should use it only when you know its dependencies already exist. You can also specify fragments of the filename. In this case, BitBake checks for a unique match.

The -e option dumps the resulting environment for either the configuration (no package specified) or for a specific package when specified; or -b recipename to show the environment from parsing a single recipe file only.

Best practices exist while writing recipes that both log build progress and act on build conditions such as warnings and errors. Both Python and Bash language bindings exist for the logging mechanism:

For guidance on how logging is handled in both Python and Bash recipes, see the logging.bbclass file in the meta/classes directory of the Yocto Project files.

     python do_listtasks() {
         bb.debug(2, "Starting to figure out the task list")
         if noteworthy_condition:
             bb.note("There are 47 tasks to run")
         bb.debug(2, "Got to point xyz")
         if warning_trigger:
             bb.warn("Detected warning_trigger, this might be a problem later.")
         if recoverable_error:
             bb.error("Hit recoverable_error, you really need to fix this!")
         if fatal_error:
             bb.fatal("fatal_error detected, unable to print the task list")
         bb.plain("The tasks present are abc")
         bb.debug(2, "Finished figuring out the tasklist")
     }
                

     do_my_function() {
         bbdebug 2 "Running do_my_function"
         if [ exceptional_condition ]; then
             bbnote "Hit exceptional_condition"
         fi
         bbdebug 2  "Got to point xyz"
         if [ warning_trigger ]; then
             bbwarn "Detected warning_trigger, this might cause a problem later."
         fi
         if [ recoverable_error ]; then
             bberror "Hit recoverable_error, correcting"
         fi
         if [ fatal_error ]; then
             bbfatal "fatal_error detected"
         fi
         bbdebug 2 "Completed do_my_function"
     }
                

Here are some other tips that you might find useful:

BitBake is the tool at the heart of the Yocto Project and is responsible for parsing the metadata, generating a list of tasks from it, and then executing those tasks. To see a list of the options BitBake supports, use the following help command:

     $ bitbake --help
            

The most common usage for BitBake is bitbake <packagename>, where packagename is the name of the package you want to build (referred to as the "target" in this manual). The target often equates to the first part of a .bb filename. So, to run the matchbox-desktop_1.2.3.bb file, you might type the following:

     $ bitbake matchbox-desktop
            

Several different versions of matchbox-desktop might exist. BitBake chooses the one selected by the distribution configuration. You can get more details about how BitBake chooses between different target versions and providers in the "Preferences and Providers" section.

BitBake also tries to execute any dependent tasks first. So for example, before building matchbox-desktop, BitBake would build a cross compiler and eglibc if they had not already been built.

A useful BitBake option to consider is the -k or --continue option. This option instructs BitBake to try and continue processing the job as much as possible even after encountering an error. When an error occurs, the target that failed and those that depend on it cannot be remade. However, when you use this option other dependencies can still be processed.

The .bb files are usually referred to as "recipes." In general, a recipe contains information about a single piece of software. The information includes the location from which to download the source patches (if any are needed), which special configuration options to apply, how to compile the source files, and how to package the compiled output.

The term "package" can also be used to describe recipes. However, since the same word is used for the packaged output from the Yocto Project (i.e. .ipk or .deb files), this document avoids using the term "package" when referring to recipes.

Class files (.bbclass) contain information that is useful to share between metadata files. An example is the Autotools class, which contains common settings for any application that Autotools uses. The "Reference: Classes" appendix provides details about common classes and how to use them.

The configuration files (.conf) define various configuration variables that govern the Yocto Project build process. These files fall into several areas that define machine configuration options, distribution configuration options, compiler tuning options, general common configuration options and user configuration options (local.conf, which is found in the Yocto Project files build directory).

When determining what parts of the system need to be built, BitBake uses a per-task basis and does not use a per-recipe basis. You might wonder why using a per-task basis is preferred over a per-recipe basis. To help explain, consider having the IPK packaging backend enabled and then switching to DEB. In this case, do_install and do_package output are still valid. However, with a per-recipe approach, the build would not include the .deb files. Consequently, you would have to invalidate the whole build and rerun it. Rerunning everything is not the best situation. Also in this case, the core must be "taught" much about specific tasks. This methodology does not scale well and does not allow users to easily add new tasks in layers or as external recipes without touching the packaged-staging core.

The shared state code uses a checksum, which is a unique signature of a task's inputs, to determine if a task needs to be run again. Because it is a change in a task's inputs that triggers a rerun, the process needs to detect all the inputs to a given task. For shell tasks, this turns out to be fairly easy because the build process generates a "run" shell script for each task and it is possible to create a checksum that gives you a good idea of when the task's data changes.

To complicate the problem, there are things that should not be included in the checksum. First, there is the actual specific build path of a given task - the WORKDIR. It does not matter if the working directory changes because it should not affect the output for target packages. Also, the build process has the objective of making native/cross packages relocatable. The checksum therefore needs to exclude WORKDIR. The simplistic approach for excluding the working directory is to set WORKDIR to some fixed value and create the checksum for the "run" script.

Another problem results from the "run" scripts containing functions that might or might not get called. The incremental build solution contains code that figures out dependencies between shell functions. This code is used to prune the "run" scripts down to the minimum set, thereby alleviating this problem and making the "run" scripts much more readable as a bonus.

So far we have solutions for shell scripts. What about python tasks? The same approach applies even though these tasks are more difficult. The process needs to figure out what variables a python function accesses and what functions it calls. Again, the incremental build solution contains code that first figures out the variable and function dependencies, and then creates a checksum for the data used as the input to the task.

Like the WORKDIR case, situations exist where dependencies should be ignored. For these cases, you can instruct the build process to ignore a dependency by using a line like the following:

     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
            

This example ensures that the PACKAGE_ARCHS variable does not depend on the value of MACHINE, even if it does reference it.

Equally, there are cases where we need to add dependencies BitBake is not able to find. You can accomplish this by using a line like the following:

      PACKAGE_ARCHS[vardeps] = "MACHINE"
            

This example explicitly adds the MACHINE variable as a dependency for PACKAGE_ARCHS.

Consider a case with inline python, for example, where BitBake is not able to figure out dependencies. When running in debug mode (i.e. using -DDD), BitBake produces output when it discovers something for which it cannot figure out dependencies. The Yocto Project team has currently not managed to cover those dependencies in detail and is aware of the need to fix this situation.

Thus far, this section has limited discussion to the direct inputs into a task. Information based on direct inputs is referred to as the "basehash" in the code. However, there is still the question of a task's indirect inputs - the things that were already built and present in the build directory. The checksum (or signature) for a particular task needs to add the hashes of all the tasks on which the particular task depends. Choosing which dependencies to add is a policy decision. However, the effect is to generate a master checksum that combines the basehash and the hashes of the task's dependencies.

At the code level, there are a variety of ways both the basehash and the dependent task hashes can be influenced. Within the BitBake configuration file, we can give BitBake some extra information to help it construct the basehash. The following statements effectively result in a list of global variable dependency excludes - variables never included in any checksum:

  BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
  BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
  BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
  BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
            

The previous example actually excludes WORKDIR since it is actually constructed as a path within TMPDIR, which is on the whitelist.

The rules for deciding which hashes of dependent tasks to include through dependency chains are more complex and are generally accomplished with a python function. The code in meta/lib/oe/sstatesig.py shows two examples of this and also illustrates how you can insert your own policy into the system if so desired. This file defines the two basic signature generators OE-Core uses: "OEBasic" and "OEBasicHash". By default, there is a dummy "noop" signature handler enabled in BitBake. This means that behavior is unchanged from previous versions. OE-Core uses the "OEBasic" signature handler by default through this setting in the bitbake.conf file:

  BB_SIGNATURE_HANDLER ?= "OEBasic"
            

The "OEBasicHash" BB_SIGNATURE_HANDLER is the same as the "OEBasic" version but adds the task hash to the stamp files. This results in any metadata change that changes the task hash, automatically causing the task to be run again. This removes the need to bump PR values and changes to metadata automatically ripple across the build. Currently, this behavior is not the default behavior for OE-Core but is the default in poky.

It is also worth noting that the end result of these signature generators is to make some dependency and hash information available to the build. This information includes:

  BB_BASEHASH_task-<taskname> - the base hashes for each task in the recipe
  BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task
  BBHASHDEPS_<filename:taskname> - The task dependencies for each task
  BB_TASKHASH - the hash of the currently running task
            

Checksums and dependencies, as discussed in the previous section, solve half the problem. The other part of the problem is being able to use checksum information during the build and being able to reuse or rebuild specific components.

The shared state class (sstate.bbclass) is a relatively generic implementation of how to "capture" a snapshot of a given task. The idea is that the build process does not care about the source of a task's output. Output could be freshly built or it could be downloaded and unpacked from somewhere - the build process doesn't need to worry about its source.

There are two types of output, one is just about creating a directory in WORKDIR. A good example is the output of either do_install or do_package. The other type of output occurs when a set of data is merged into a shared directory tree such as the sysroot.

The Yocto Project team has tried to keep the details of the implementation hidden in sstate.bbclass. From a user's perspective, adding shared state wrapping to a task is as simple as this do_deploy example taken from do_deploy.bbclass:

     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
     SSTATETASKS += "do_deploy"
     do_deploy[sstate-name] = "deploy"
     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"

     python do_deploy_setscene () {
         sstate_setscene(d)
     }
     addtask do_deploy_setscene
            

In the example, we add some extra flags to the task, a name field ("deploy"), an input directory where the task sends data, and the output directory where the data from the task should eventually be copied. We also add a _setscene variant of the task and add the task name to the SSTATETASKS list.

If you have a directory whose contents you need to preserve, you can do this with a line like the following:

     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
            

This method, as well as the following example, also works for multiple directories.

     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
     do_package[sstate-lockfile] = "${PACKAGELOCK}"
            

These methods also include the ability to take a lockfile when manipulating shared state directory structures since some cases are sensitive to file additions or removals.

Behind the scenes, the shared state code works by looking in SSTATE_DIR and SSTATE_MIRRORS for shared state files. Here is an example:

     SSTATE_MIRRORS ?= "\
     file://.* http://someserver.tld/share/sstate/ \n \
     file://.* file:///some/local/dir/sstate/"
            

The shared state package validity can be detected just by looking at the filename since the filename contains the task checksum (or signature) as described earlier in this section. If a valid shared state package is found, the build process downloads it and uses it to accelerate the task.

The build processes uses the *_setscene tasks for the task acceleration phase. BitBake goes through this phase before the main execution code and tries to accelerate any tasks for which it can find shared state packages. If a shared state package for a task is available, the shared state package is used. This means the task and any tasks on which it is dependent are not executed.

As a real world example, the aim is when building an IPK-based image, only the do_package_write_ipk tasks would have their shared state packages fetched and extracted. Since the sysroot is not used, it would never get extracted. This is another reason why a task-based approach is preferred over a recipe-based approach, which would have to install the output from every task.

The code in the Yocto Project that supports incremental builds is not simple code. This section presents some tips and tricks that help you work around issues related to shared state code.

While the x32 psABI specifications are not fully finalized, this Yocto Project release supports current development specifications of x32 psABI. As of this release of the Yocto Project, x32 psABI support exists as follows:

As of this Yocto Project release, the x32 psABI kernel and library interfaces specifications are not finalized.

Future Plans for the x32 psABI in the Yocto Project include the following:

Despite the fact the x32 psABI support is in development state for this release of the Yocto Project, you can follow these steps to use the x32 spABI:

The license of an upstream project might change in the future. In order to prevent these changes going unnoticed, the Yocto Project provides a LIC_FILES_CHKSUM variable to track changes to the license text. The checksums are validated at the end of the configure step, and if the checksums do not match, the build will fail.

     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
                         file://licfile2.txt;endline=50;md5=zzzz \
                         ..."
                

     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
                

By default, the Yocto Project build system disables components that have commercial or other special licensing requirements. Such requirements are defined on a recipe-by-recipe basis through the LICENSE_FLAGS variable definition in the affected recipe. For instance, the $HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly recipe contains the following statement:

     LICENSE_FLAGS = "commercial"
            

Here is a slightly more complicated example that contains both an explicit package name and version (after variable expansion):

     LICENSE_FLAGS = "license_${PN}_${PV}"
            

In order for a component restricted by a LICENSE_FLAGS definition to be enabled and included in an image, it needs to have a matching entry in the global LICENSE_FLAGS_WHITELIST variable, which is a variable typically defined in your local.conf file. For example, to enable the $HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly package, you could add either the string "commercial_gst-plugins-ugly" or the more general string "commercial" to LICENSE_FLAGS_WHITELIST. See the "License Flag Matching" section for a full explanation of how LICENSE_FLAGS matching works. Here is the example:

     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
            

Likewise, to additionally enable the package containing LICENSE_FLAGS = "license_${PN}_${PV}", and assuming that the actual recipe name was emgd_1.10.bb, the following string would enable that package as well as the original gst-plugins-ugly package:

     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
            

As a convenience, you do not need to specify the complete license string in the whitelist for every package. you can use an abbreviated form, which consists of just the first portion or portions of the license string before the initial underscore character or characters. A partial string will match any license that contains the given string as the first portion of its license. For example, the following whitelist string will also match both of the packages previously mentioned as well as any other packages that have licenses starting with "commercial" or "license".

     LICENSE_FLAGS_WHITELIST = "commercial license"
            

     LICENSE_FLAGS = "commercial"
                

     COMMERCIAL_AUDIO_PLUGINS ?= ""
     COMMERCIAL_VIDEO_PLUGINS ?= ""
     COMMERCIAL_QT = ""
                

     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
        gst-plugins-ugly-mpegaudioparse"
     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
     COMMERCIAL_QT ?= "qmmp"
     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
                

     LICENSE_FLAGS_WHITELIST = "commercial"
                

You can find these files in the BSP Layer at:

     meta-<bsp_name>/<bsp_license_file>
                

These optional files satisfy licensing requirements for the BSP. The type or types of files here can vary depending on the licensing requirements. For example, in the Crown Bay BSP all licensing requirements are handled with the COPYING.MIT file.

Licensing files can be MIT, BSD, GPLv*, and so forth. These files are recommended for the BSP but are optional and totally up to the BSP developer.

You can find this file in the BSP Layer at:

     meta-<bsp_name>/README
                

This file provides information on how to boot the live images that are optionally included in the binary/ directory. The README file also provides special information needed for building the image.

At a minimum, the README file must contain a list of dependencies, such as the names of any other layers on which the BSP depends and the name of the BSP maintainer with his or her contact information.

You can find this file in the BSP Layer at:

     meta-<bsp_name>/README.sources
                

This file provides information on where to locate the BSP source files. For example, information provides where to find the sources that comprise the images shipped with the BSP. Information is also included to help you find the metadata used to generate the images that ship with the BSP.

You can find these files in the BSP Layer at:

     meta-<bsp_name>/binary/<bootable_images>
                

This optional area contains useful pre-built kernels and user-space filesystem images appropriate to the target system. This directory typically contains graphical (e.g. sato) and minimal live images when the BSP tarball has been created and made available in the Yocto Project website. You can use these kernels and images to get a system running and quickly get started on development tasks.

The exact types of binaries present are highly hardware-dependent. However, a README file should be present in the BSP Layer that explains how to use the kernels and images with the target hardware. If pre-built binaries are present, source code to meet licensing requirements must also exist in some form.

You can find this file in the BSP Layer at:

     meta-<bsp_name>/conf/layer.conf
                

The conf/layer.conf file identifies the file structure as a Yocto Project layer, identifies the contents of the layer, and contains information about how Yocto Project should use it. Generally, a standard boilerplate file such as the following works. In the following example, you would replace "bsp" and "_bsp" with the actual name of the BSP (i.e. <bsp_name> from the example template).

     # We have a conf and classes directory, add to BBPATH
     BBPATH := "${BBPATH}:${LAYERDIR}"

     # We have a recipes directory, add to BBFILES
     BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ 
                 ${LAYERDIR}/recipes/*/*.bbappend"

     BBFILE_COLLECTIONS += "bsp"
     BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
     BBFILE_PRIORITY_bsp = "6"
                

To illustrate the string substitutions, here are the last three statements from the Crown Bay conf/layer.conf file:

     BBFILE_COLLECTIONS += "crownbay"
     BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
     BBFILE_PRIORITY_crownbay = "6"
                

This file simply makes BitBake aware of the recipes and configuration directories. The file must exist so that the Yocto Project build system can recognize the BSP.

You can find these files in the BSP Layer at:

     meta-<bsp_name>/conf/machine/*.conf
                

The machine files bind together all the information contained elsewhere in the BSP into a format that the Yocto Project build system can understand. If the BSP supports multiple machines, multiple machine configuration files can be present. These filenames correspond to the values to which users have set the MACHINE variable.

These files define things such as the kernel package to use (PREFERRED_PROVIDER of virtual/kernel), the hardware drivers to include in different types of images, any special software components that are needed, any bootloader information, and also any special image format requirements.

Each BSP Layer requires at least one machine file. However, you can supply more than one file. For example, in the Crown Bay BSP shown earlier in this section, the conf/machine directory contains two configuration files: crownbay.conf and crownbay-noemgd.conf. The crownbay.conf file is used for the Crown Bay BSP that supports the Intel® Embedded Media and Graphics Driver (Intel® EMGD), while the crownbay-noemgd.conf file is used for the Crown Bay BSP that does not support the Intel® EMGD.

This crownbay.conf file could also include a hardware "tuning" file that is commonly used to define the package architecture and specify optimization flags, which are carefully chosen to give best performance on a given processor.

Tuning files are found in the meta/conf/machine/include directory of the Yocto Project Files. Tuning files can also reside in the BSP Layer itself. For example, the ia32-base.inc file resides in the meta-intel BSP Layer in conf/machine/include.

To use an include file, you simply include them in the machine configuration file. For example, the Crown Bay BSP crownbay.conf has the following statements:

     include conf/machine/include/tune-atom.inc
     include conf/machine/include/ia32-base.inc
                

You can find these files in the BSP Layer at:

     meta-<bsp_name>/recipes-bsp/*
                

This optional directory contains miscellaneous recipe files for the BSP. Most notably would be the formfactor files. For example, in the Crown Bay BSP there is the formfactor_0.0.bbappend file, which is an append file used to augment the recipe that starts the build. Furthermore, there are machine-specific settings used during the build that are defined by the machconfig files. In the Crown Bay example, two machconfig files exist: one that supports the Intel® Embedded Media and Graphics Driver (Intel® EMGD) and one that does not:

     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
     meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
     meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
                

You can find these files in the BSP Layer at:

     meta-<bsp_name>/recipes-core/*
                

This directory contains recipe files that are almost always necessary to build a useful, working Linux image. Thus, the term "core" is used to group these recipes. For example, in the Crown Bay BSP there is the task-core-tools-profile.bbappend file, which is an append file used to recommend that the SystemTap package be included as a package when the image is built.

You can find these files in the BSP Layer at:

     meta-<bsp_name>/recipes-graphics/*            
                

This optional directory contains recipes for the BSP if it has special requirements for graphics support. All files that are needed for the BSP to support a display are kept here. For example, the Crown Bay BSP contains two versions of the xorg.conf file. The version in crownbay builds a BSP that supports the Intel® Embedded Media Graphics Driver (EMGD), while the version in crownbay-noemgd builds a BSP that supports Video Electronics Standards Association (VESA) graphics only:

     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
                

You can find these files in the BSP Layer at:

     meta-<bsp_name>/recipes-kernel/linux/linux-yocto_*.bbappend
                

These files append your specific changes to the kernel you are using.

For your BSP, you typically want to use an existing Yocto Project kernel found in the Yocto Project Files at meta/recipes-kernel/linux. You can append your specific changes to the kernel recipe by using a similarly named append file, which is located in the BSP Layer (e.g. the meta-<bsp_name>/recipes-kernel/linux directory).

Suppose the BSP uses the linux-yocto_3.0.bb kernel, which is the preferred kernel to use for developing a new BSP using the Yocto Project. In other words, you have selected the kernel in your <bsp_name>.conf file by adding the following statements:

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

You would use the linux-yocto_3.0.bbappend file to append specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.

As an example, look at the existing Crown Bay BSP. The append file used is:

     meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
                

The following listing shows the file. Be aware that the actual commit ID strings in this example listing might be different than the actual strings in the file from the meta-intel Git source repository.

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

     COMPATIBLE_MACHINE_crownbay = "crownbay"
     KMACHINE_crownbay  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"

     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
     KMACHINE_crownbay-noemgd  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"

     SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"

     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
                

This append file contains statements used to support the Crown Bay BSP for both Intel® EMGD and the VESA graphics. The build process, in this case, recognizes and uses only the statements that apply to the defined machine name - crownbay in this case. So, the applicable statements in the linux-yocto_3.0.bbappend file are follows:

     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

     COMPATIBLE_MACHINE_crownbay = "crownbay"
     KMACHINE_crownbay  = "yocto/standard/crownbay"
     KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"

     SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
     SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
                

The append file defines crownbay as the compatible machine and defines the KMACHINE. The file also points to some configuration fragments to use by setting the KERNEL_FEATURES variable. The location for the configuration fragments is the kernel tree itself in the Yocto Project Build Directory under linux/meta. Finally, the append file points to the specific commits in the Yocto Project Files Git repository and the meta Git repository branches to identify the exact kernel needed to build the Crown Bay BSP.

One thing missing in this particular BSP, which you will typically need when developing a BSP, is the kernel configuration file (.config) for your BSP. When developing a BSP, you probably have a kernel configuration file or a set of kernel configuration files that, when taken together, define the kernel configuration for your BSP. You can accomplish this definition by putting the configurations in a file or a set of files inside a directory located at the same level as your append file and having the same name as the kernel. With all these conditions met simply reference those files in a SRC_URI statement in the append file.

For example, suppose you had a set of configuration options in a file called myconfig. If you put that file inside a directory named /linux-yocto and then added a SRC_URI statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built.

     SRC_URI += "file://myconfig"
                

As mentioned earlier, you can group related configurations into multiple files and name them all in the SRC_URI statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using a SRC_URI statement like the following in your append file:

     SRC_URI += "file://myconfig \
            file://eth.cfg \
            file://gfx.cfg"
                

The FILESEXTRAPATHS variable is in boilerplate form in the previous example in order to make it easy to do that. This variable must be in your layer or BitBake will not find the patches or configurations even if you have them in your SRC_URI. The FILESEXTRAPATHS variable enables the build process to find those configuration files.

Designed to have a command interface somewhat like Git, each tool is structured as a set of sub-commands under a top-level command. The top-level command (yocto-bsp or yocto-kernel) itself does nothing but invoke or provide help on the sub-commands it supports.

Both tools reside in the scripts/ subdirectory of the Yocto Project Files. Consequently, to use the scripts, you must source the environment just as you would when invoking a build:

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

The most immediately useful function is to get help on both tools. The built-in help system makes it easy to drill down at any time and view the syntax required for any specific command. Simply enter the name of the command, or the command along with help to display a list of the available sub-commands. Here is an example:

     $ yocto-bsp
     $ yocto-bsp help

     Usage:

     Create a customized Yocto BSP layer.

     usage: yocto-bsp [--version] [--help] COMMAND [ARGS]

     The most commonly used 'yocto-bsp' commands are:
     create            Create a new Yocto BSP
     list              List available values for options and BSP properties

     See 'yocto-bsp help COMMAND' for more information on a specific command.


     Options:
     --version    show program's version number and exit
     -h, --help   show this help message and exit
     -D, --debug  output debug information
                    

Similarly, entering just the name of a sub-command shows the detailed usage for that sub-command:

     $ yocto-bsp create

     Usage:

     Create a new Yocto BSP
     usage: yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>]
             [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]

                 This command creates a Yocto BSP based on the specified parameters.
                 The new BSP will be a new Yocto BSP layer contained by default within
                 the top-level directory specified as 'meta-bsp-name'.  The -o option
                 can be used to place the BSP layer in a directory with a different
                 name and location.

                 ...
                    

For any sub-command, you can also use the word 'help' just before the sub-command to get more extensive documentation:

     $ yocto-bsp help create

     NAME
     yocto-bsp create - Create a new Yocto BSP

     SYNOPSIS
     yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>]
             [-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]

     DESCRIPTION
     This command creates a Yocto BSP based on the specified
     parameters.  The new BSP will be a new Yocto BSP layer contained
     by default within the top-level directory specified as
     'meta-bsp-name'.  The -o option can be used to place the BSP layer
     in a directory with a different name and location.
			    
     The value of the 'karch' parameter determines the set of files
     that will be generated for the BSP, along with the specific set of
     'properties' that will be used to fill out the BSP-specific
     portions of the BSP.
			    
     ...
			    
     NOTE: Once created, you should add your new layer to your
     bblayers.conf file in order for it to be subsequently seen and
     modified by the yocto-kernel tool.
			    
     NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
     presence of the of the meta-intel layer, so you should also have a
     meta-intel layer present and added to your bblayers.conf as well.
                    

Now that you know where these two commands reside and how to access information on them, you should find it relatively straightforward to discover the commands necessary to create a BSP and perform basic kernel maintainence on that BSP using the tools. The next sections provide a concrete starting point to expand on a few points that might not be immediately obvious or that could use further explanation.

The yocto-bsp script creates a new BSP layer for any architecture supported by the Yocto Project, as well as QEMU versions of the same. The default mode of the script's operation is to prompt you for information needed to generate the BSP layer. For the current set of BSPs, the script prompts you for various important parameters such as:

You use the yocto-bsp create sub-command to create a new BSP layer. This command requires you to specify a particular architecture on which to base the BSP. Assuming you have sourced the environment, you can use the yocto-bsp list karch sub-command to list the architectures available for BSP creation as follows:

     $ yocto-bsp list karch
     Architectures available:
         arm
         powerpc
         i386
         mips
         x86_64
         qemu
                    

The remainder of this section presents an example that uses myarm as the machine name and qemu as the machine architecture. Of the available architectures, qemu is the only architecture that causes the script to prompt you further for an actual architecture. In every other way, this architecture is representative of how creating a BSP for a 'real' machine would work. The reason the example uses this architecture is because it is an emulated architecture and can easily be followed without requireing actual hardware.

As the yocto-bsp create command runs, default values for the prompts appear in brackets. Pressing enter without supplying anything on the command line or pressing enter and providing an invalid response causes the script to accept the default value.

Following is the complete example:

     $ yocto-bsp create myarm qemu
     Which qemu architecture would you like to use? [default: x86]
             1) common 32-bit x86
             2) common 64-bit x86
             3) common 32-bit ARM
             4) common 32-bit PowerPC
             5) common 32-bit MIPS
     3
     Would you like to use the default (3.2) kernel? (Y/n)
     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
     Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
             1) base
             2) standard/base
             3) standard/default/arm-versatile-926ejs
             4) standard/default/base
             5) standard/default/beagleboard
             6) standard/default/cedartrailbsp (copy).xml
             7) standard/default/common-pc-64/base
             8) standard/default/common-pc-64/jasperforest
             9) standard/default/common-pc-64/romley
             10) standard/default/common-pc-64/sugarbay
             11) standard/default/common-pc/atom-pc
             12) standard/default/common-pc/base
             13) standard/default/crownbay
             14) standard/default/emenlow
             15) standard/default/fishriver
             16) standard/default/fri2
             17) standard/default/fsl-mpc8315e-rdb
             18) standard/default/mti-malta32-be
             19) standard/default/mti-malta32-le
             20) standard/default/preempt-rt
             21) standard/default/qemu-ppc32
             22) standard/default/routerstationpro
             23) standard/preempt-rt/base
             24) standard/preempt-rt/qemu-ppc32
             25) standard/preempt-rt/routerstationpro
             26) standard/tiny
     3
     Do you need SMP support? (Y/n)
     Does your BSP have a touchscreen? (y/N)
     Does your BSP have a keyboard? (Y/n)
     New qemu BSP created in meta-myarm
                    

Let's take a closer look at the example now:

Once the BSP Layer is created, you must add it to your bblayers.conf file. Here is an example:

     BBLAYERS = " \
        /usr/local/src/yocto/meta \
        /usr/local/src/yocto/meta-yocto \
        /usr/local/src/yocto/meta-myarm \
        "
                    

Adding the layer to this file allows the build system to build the BSP and the yocto-kernel tool to be able to find the layer and other metadata it needs on which to operate.

Assuming you have created a Yocto Project BSP Layer using yocto-bsp and you added it to your BBLAYERS variable in the bblayers.conf file, you can now use the yocto-kernel script to add patches and configuration items to the BSP's kernel.

The yocto-kernel script allows you to add, remove, and list patches and kernel config settings to a Yocto Project BSP's kernel .bbappend file. All you need to do is use the appropriate sub-command. Recall that the easiest way to see exactly what sub-commands are available is to use the yocto-kernel built-in help as follows:

     $ yocto-kernel
     Usage:

     Modify and list Yocto BSP kernel config items and patches.

     usage: yocto-kernel [--version] [--help] COMMAND [ARGS]

     The most commonly used 'yocto-kernel' commands are:
     config list       List the modifiable set of bare kernel config options for a BSP
     config add        Add or modify bare kernel config options for a BSP 
     config rm         Remove bare kernel config options from a BSP
     patch list        List the patches associated with a BSP
     patch add         Patch the Yocto kernel for a BSP
     patch rm          Remove patches from a BSP

     See 'yocto-kernel help COMMAND' for more information on a specific command.
                    

The yocto-kernel patch add sub-command allows you to add a patch to a BSP. The following example adds two patches to the myarm BSP:

     $ yocto-kernel patch add myarm ~/test.patch
     Added patches:
             test.patch

     $ yocto-kernel patch add myarm ~/yocto-testmod.patch
     Added patches:
             yocto-testmod.patch
                    

You can verify patches have been added by using the yocto-kernel patch list sub-command. Here is an example:

     $ yocto-kernel patch list myarm
     The current set of machine-specific patches for myarm is:
             1) test.patch
             2) yocto-testmod.patch
                    

You can also use the yocto-kernel script to remove a patch using the yocto-kernel patch rm sub-command. Here is an example:

     $ yocto-kernel patch rm myarm
     Specify the patches to remove:
             1) test.patch
             2) yocto-testmod.patch
     1
     Removed patches:
             test.patch
                    

Again, using the yocto-kernel patch list sub-command, you can verify that the patch was in fact removed:

     $ yocto-kernel patch list myarm
     The current set of machine-specific patches for myarm is:
             1) yocto-testmod.patch
                    

In a completely similar way, you can use the yocto-kernel config add sub-command to add one or more kernel config item settings to a BSP. The following commands add a couple of config items to the myarm BSP:

     $ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
     Added items:
             CONFIG_MISC_DEVICES=y

     $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
     Added items:
             CONFIG_YOCTO_TESTMOD=y
                    

You can list the config items now associated with the BSP. Doing so shows you the config items you added as well as others associated with the BSP:

     $ yocto-kernel config list myarm
     The current set of machine-specific kernel config items for myarm is:
             1) CONFIG_MISC_DEVICES=y
             2) CONFIG_YOCTO_TESTMOD=y
                    

Finally, you can remove one or more config items using the yocto-kernel config rm sub-command in a manner completely analogous to yocto-kernel patch rm.

The Yocto Project provides toolchains that allow you to develop your application outside of the Yocto Project build system for specific hardware. These toolchains (called meta-toolchains) contain cross-development tools such as compilers, linkers, and debuggers that build your application for your target device. The Yocto Project also provides images that have toolchains for supported architectures included within the image. This allows you to compile, debug, or profile applications directly on the target device. See the "Reference: Images" appendix for a listing of the image types that Yocto Project supports.

Using the BitBake tool you can build a meta-toolchain or meta-toolchain-sdk target, which generates a tarball. Unpacking this tarball into the /opt/poky directory on your host produces a setup script (e.g. /opt/poky/environment-setup-i586-poky-linux) that you can source to initialize your build environment. Sourcing this script adds the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities to the PATH variable used by the Yocto Project build environment. Variables to assist pkgconfig and Autotools are also defined so that, for example, configure can find pre-generated test results for tests that need target hardware on which to run.

Using the toolchain with Autotool-enabled packages is straightforward - just pass the appropriate host option to configure. Following is an example:

     $ ./configure --host=arm-poky-linux-gnueabi
            

For projects that are not Autotool-enabled, it is usually just a case of ensuring you point to and use the cross-toolchain. For example, the following two lines of code in a Makefile that builds your application specify to use the cross-compiler arm-poky-linux-gnueabi-gcc and linker arm-poky-linux-gnueabi-ld, which are part of the meta-toolchain you would have previously established:

     CC=arm-poky-linux-gnueabi-gcc;
     LD=arm-poky-linux-gnueabi-ld;
            

The current release of the Yocto Project supports the Eclipse IDE plug-in to make developing software easier for the application developer. The plug-in provides capability extensions to the graphical IDE to allow for cross compilation, deployment and execution of the application within a QEMU emulation session. Support of the Eclipse plug-in also allows for cross debugging and profiling. Additionally, the Eclipse plug-in provides a suite of tools that allows the developer to perform remote profiling, tracing, collection of power consumption data, collection of latency data and collection of performance data.

To use the Eclipse plug-in you need the Eclipse Framework (Helios 3.6.1) along with other plug-ins installed into the Eclipse IDE. Once you have your environment setup you need to configure the Eclipse plug-in. For information on how to install and configure the Eclipse plug-in, see the "Working Within Eclipse" chapter in the Yocto Project Application Development Toolkit (ADT) User's Guide.

Running Poky QEMU images is covered in the "A Quick Test Run" section of the Yocto Project Quick Start.

The QEMU images shipped with the Yocto Project contain complete toolchains native to their target architectures. This support allows you to develop applications within QEMU similar to the way you would using a normal host development system.

Speed can be an issue depending on the target and host architecture mix. For example, using the qemux86 image in the emulator on an Intel-based 32-bit (x86) host machine is fast because the target and host architectures match. On the other hand, using the qemuarm image on the same Intel-based host can be slower. But, you still achieve faithful emulation of ARM-specific issues.

To speed things up, the QEMU images support using distcc to call a cross-compiler outside the emulated system. If you used runqemu to start QEMU, and distccd is present on the host system, any BitBake cross-compiling toolchain available from the build system is automatically used from within QEMU simply by calling distcc. You can accomplish this by defining the cross-compiler variable (e.g. export CC="distcc"). Alternatively, if a suitable SDK/toolchain is present in /opt/poky the toolchain is also automatically used.

Several mechanisms exist that let you connect to the system running on the QEMU emulator:

Working directly with the Yocto Project is a fast and effective development technique. The idea is that you can directly edit files in a working directory (WORKDIR) or the source directory (S) and then force specific tasks to rerun in order to test the changes. An example session working on the matchbox-desktop package might look like this:

     $ bitbake matchbox-desktop
     $ sh
     $ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
     $ cd matchbox-desktop-2
     $ vi src/main.c
           .
           .
      [Make your changes]
           .
           .
     $ exit
     $ bitbake matchbox-desktop -c compile -f
     $ bitbake matchbox-desktop
            

This example builds the matchbox-desktop package, creates a new terminal, changes into the work directory for the package, changes a file, exits out of the terminal, and then recompiles the package. Instead of using sh, you can also use two different terminals. However, the risk of using two terminals is that a command like unpack could destroy your changes in the work directory. Consequently, you need to work carefully.

It is useful when making changes directly to the work directory files to do so using the Quilt tool as detailed in the "Using a Quilt Workflow" section in the Yocto Project Development Manual. Using Quilt, you can copy patches into the recipe directory and use the patches directly through use of the SRC_URI variable.

For a review of the skills used in this section, see the "BitBake" and "Running Specific Tasks" sections.

When debugging certain commands or even when just editing packages, devshell can be a useful tool. Using devshell differs from the example shown in the previous section in that when you invoke devshell source files are extracted into your working directory and patches are applied. Then, a new terminal is opened and you are placed in the working directory. In the new terminal all the Yocto Project build-related environment variables are still defined so you can use commands such as configure and make. The commands execute just as if the Yocto Project build system were executing them. Consequently, working this way can be helpful when debugging a build or preparing software to be used with the Yocto Project build system.

Following is an example that uses devshell on a target named matchbox-desktop:

     $ bitbake matchbox-desktop -c devshell
            

This command opens a terminal with a shell prompt within the Poky environment. The following occurs:

Within this environment, you can run configure or compile commands as if they were being run by the Yocto Project build system itself. As noted earlier, the working directory also automatically changes to the source directory (S).

When you are finished, you just exit the shell or close the terminal window.

The default shell used by devshell is xterm. For examples of available options, see the "UI/Interaction Configuration" section of the meta/conf/bitbake.conf configuration file in the Yocto Project files.

Because an external shell is launched rather than opening directly into the original terminal window, it allows easier interaction with BitBake's multiple threads as well as accomodates a future client/server split.

If you're working on a recipe that pulls from an external Source Code Manager (SCM), it is possible to have the Yocto Project build system notice new changes added to the SCM and then build the package that depends on them using the latest version. This only works for SCMs from which it is possible to get a sensible revision number for changes. Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories.

To enable this behavior, simply add the following to the local.conf configuration file in the build directory of the Yocto Project files:

     SRCREV_pn-<PN> = "${AUTOREV}"
            

where PN is the name of the package for which you want to enable automatic source revision updating.

First, make sure Gdbserver is installed on the target. If it is not, install the package gdbserver, which needs the libthread-db1 package.

As an example, to launch Gdbserver on the target and make it ready to "debug" a program located at /path/to/inferior, connect to the target and launch:

     $ gdbserver localhost:2345 /path/to/inferior
            

Gdbserver should now be listening on port 2345 for debugging commands coming from a remote GDB process that is running on the host computer. Communication between Gdbserver and the host GDB are done using TCP. To use other communication protocols, please refer to the Gdbserver documentation.

Running GDB on the host computer takes a number of stages. This section describes those stages.

 
     /usr/local/poky/eabi-glibc/arm/bin/arm-poky-linux-gnueabi-gdb
                

     $ bitbake gdb-cross
                

     tmp/sysroots/<host-arch>/usr/bin/<target-abi>-gdb 
                

     $ <target-abi>-gdb rootfs/usr/bin/foo
                

     $ set solib-absolute-prefix /path/to/tmp/rootfs
                

     $ target remote remote-target-ip-address:2345
                

     (gdb) break main
     (gdb) continue
                

Using OProfile you can perform all the profiling work on the target device. A simple OProfile session might look like the following:

     # opcontrol --reset
     # opcontrol --start --separate=lib --no-vmlinux -c 5
              .
              .
        [do whatever is being profiled]
              .
              .
     # opcontrol --stop
     $ opreport -cl
            

In this example, the reset command clears any previously profiled data. The next command starts OProfile. The options used when starting the profiler separate dynamic library data within applications, disable kernel profiling, and enable callgraphing up to five levels deep.

After you perform your profiling tasks, the next command stops the profiler. After that, you can view results with the opreport command with options to see the separate library symbols and callgraph information.

Callgraphing logs information about time spent in functions and about a function's calling function (parent) and called functions (children). The higher the callgraphing depth, the more accurate the results. However, higher depths also increase the logging overhead. Consequently, you should take care when setting the callgraphing depth.

For more information on using OProfile, see the OProfile online documentation at http://oprofile.sourceforge.net/docs/.

A graphical user interface for OProfile is also available. You can download and build this interface from the Yocto Project at http://git.yoctoproject.org/cgit.cgi/oprofileui/. If the "tools-profile" image feature is selected, all necessary binaries are installed onto the target device for OProfileUI interaction.

Even though the Yocto Project usually includes all needed patches on the target device, you might find you need other OProfile patches for recent OProfileUI features. If so, see the OProfileUI README for the most recent information.

     # opcontrol --reset
     # opcontrol --start --separate=lib --no-vmlinux -c 5
            .
            .
     [do whatever is being profiled]
            .
            .
     # opcontrol --stop
     # oparchive -o my_archive