Poky contains a set of default target images. You can list them by executing the following commands:
$ cd /opt/yocto/poky$ ls meta*/recipes*/images/*.bb
A full description of the different images can be found in the Yocto Project Reference Manual, on Chapter 13, Images. Typically, these default images are used as a base and customized for your own project needs. The most frequently used base default images are:
core-image-minimal: This is the smallest BusyBox, sysvinit, and udev-based console-only image
core-image-full-cmdline: This is the BusyBox-based console-only image with full hardware support and a more complete Linux system, including Bash
core-image-lsb: This is a console-only image that is based on Linux Standard Base (LSB) compliance
core-image-x11: This is the basic X11 Windows-system-based image with a graphical terminal
core-image-sato: This is the X11 Window-system-based image with a SATO theme and a GNOME mobile desktop environment
core-image-weston: This is a Wayland protocol and Weston reference compositor-based image
You will also find images with the following suffixes:
dev: This image is suitable for development work, as it contains headers and libraries
sdk: This image includes a complete SDK that can be used for development on the target
initramfs: This is an image that can be used for a RAM-based root filesystem, which can optionally be embedded with the Linux kernel
- To build an image, we need to configure the machine we are building it for and pass its name to BitBake. For example, for the
qemuarmmachine, we would run the following:
$ cd /opt/yocto/poky/$ source /opt/yocto/poky/oe-init-build-env qemuarm$ MACHINE=qemuarm bitbake core-image-minimal
- Or we could export the
MACHINEvariable to the current shell environment before sourcing the
oe-init-build-envscript with the following:
$ export MACHINE=qemuarm
- On an already configured project, we could also edit the
conf/local.confconfiguration file to change the default machine to
- #MACHINE ?= "qemuarm" + MACHINE ?= "qemuarm"
- Then, after setting up the environment, we execute the following:
$ bitbake core-image-minimal
With the preceding steps, BitBake will launch the build process for the specified target image.
When you pass a target recipe to BitBake, it first parses the following configuration files in order:
conf/bblayers.conf: This file is parsed to find all the configured layers
conf/layer.conf: This file is parsed on each configured layer
meta/conf/bitbake.conf: This file is parsed for its own configuration
conf/local.conf: This file is used for any other configuration the user may have for the current build
conf/machine/<machine>.conf: This file is the machine configuration; in our case, this is
conf/distro/<distro>.conf: This file is the distribution policy; by default, this is the
There are also some other distribution variants included with Poky:
poky-bleeding: Extension to the Poky default distribution that includes the most up-to-date versions of packages
poky-lsb: LSB compliance extension to Poky
poky-tiny: Oriented to create headless systems with the smallest Linux kernel and BusyBox read-only or RAM-based root filesystems, using the
And then, BitBake parses the target recipe that has been provided and its dependencies. The outcome is a set of interdependent tasks that BitBake will then execute in order.
A depiction of the BitBake build process is shown in the following diagram:
BitBake build process
Most developers won't be interested in keeping the whole build output for every package, so it is recommended to configure your project to remove it with the following configuration in your
INHERIT += "rm_work"
But at the same time, configuring it for all packages means that you won't be able to develop or debug them.
You can add a list of packages to exclude from cleaning by adding them to the
RM_WORK_EXCLUDE variable. For example, if you are going to do BSP work, a good setting might be:
RM_WORK_EXCLUDE += "linux-wandboard u-boot-fslc"
Remember that you can use a custom template
local.conf.sample configuration file in your own layer to keep these configurations and apply them for all projects so that they can be shared across all developers.
On a normal build, the
-dbg packages that include debug symbols are not needed. To avoid creating
-dbg packages, do this:
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
Once the build finishes, you can find the output images in the
tmp/deploy/images/qemuarm directory inside your build directory.
You can test run your images on the QEMU emulator by executing this:
$ runqemu qemuarm core-image-minimal
runqemu script included in Poky's
scripts directory is a launch wrapper around the QEMU machine emulator to simplify its usage.
The Yocto Project also has a set of precompiled images for supported hardware platforms that can be downloaded from http://downloads.yoctoproject.org/releases/yocto/yocto-2.4/machines/.