Yocto Bitbake Build Process

In this document I’ll try to document learning process of Bitbake build system.

Initial steps

Checkout the yocto build

git clone -b mickledore git://git.yoctoproject.org/poky.git
cd poky

Run the build for x86-64 build

source  oe-init-build-env
bitbake core-image-minimal
runqemu core-image-minimal

This will download and run all relevant commands to build final runnable image.

High-Level process

Once the build is execute bitbake core-image-minimal the following steps will occur from the perspective of configuration:

• Read build/conf/bblayers.conf configuration file
  • Read BBLAYERS variable (space separated list of layers)
• Read build/conf/local.conf configuration file
  • Optional MACHINE variable defining machine specification
  • Package manager with PACKAGE_CLASSES. Can be debian, yum, ipk or can be image based.
  • SDKMACHINE variable defining target SDK architecture
  • EXTRA_IMAGE_FEATURES variable defined as list of extra features
  • Other…
• Read recipe for each <layer>/config/layer.conf. For each <layer> in BBLAYERS.
• Read all bbappend files
• Read all .inc files
• Build process

Bitbake Layer

Bitbake layer groups various recipes into cohesive set. There are various layer types but two most common are:

• BSP (Board Support Package) layer which provides support for hardware board (rpi, banana pi, etc…)
• Distribution layers are specific to distribution. Examples are meta-yocto-bsp or meta-openembedded.
• Software layers provide specific sets of software. Example is meta-qt5.
• Vendor Layers contain third-party or vendor specific recipes.
• Application Layers contain layers related to particular applications.
• User Layers contain final image (user) specific recipes. Usually proprietary software.

Bitbake dependency types

Bitbake handles several types of dependencies. Here are the most commonly worked on dependency types:

• Build Dependencies (DEPENDS): Defines which packages must be built before the recipe. Useful for packages that rely on libraries or tools from other packages. For example, package depends on other one as it’s headers need to be present.
• Runtime Dependencies (RDEPENDS): These are the packages which are required by the recipe at runtime.
• Task Dependencies: These are dependencies that exists between different tasks in a single recipe or between task across multiple recipes. For example, the do_compile task typically depends on the do_configure task.
• Inter-Layer Dependencies (LAYERDEPENDS): Defines on which other layer ‘current’ layer depends on.
• Build-Tile Dependencies: Recipes ending with -native are related to tools that are used during build-time on build host.

Recipes

Bitbake Recipe is a set of definitions describing how a certain “package” should be build. Recipe depends on a class “.bbclass” which knows how to build a specific type of application (cmake, make, etc…), method of pulling the code from the repository/web location, set of patches which are applied before building, package dependencies and the identifier that the package provides (PROVIDES variable) and what package provides at runtime (RPROVIDES). If package conflicts with other pacakge we may indicate it with RCONFLICTS variable. REPLACES variable defines names of packages it can replace.

Each package specifies package version variable (PV) and package name (PN).

When Bitbake builds the recipe it by default chooses highest version (many recipes may provide same package). This can be controlled or overwritten as needed.

Location of source code is specified using SRC_URI variable. Optionally hash of the artifact can be specified using SRC_URI[sha256sum] = “…”.

Common recipe build tasks:

• do_fetch
• do_unpack
• do_patch
• do_configure, do_compile
• do_install, do_package

include/require vs inherit

include keyword includes ‘.inc’ file contents (shared between 2 or more recipes in a layer). require is the same as include but will terminate if fails. inherit keyword inherits bbclass (Bitbake class) such as cmake.

Yocto SDK

Yocto SDK is a optional toolset which can be build by Yocto build system. That toolset contains all needed files/packages/executables that can then be used by the developers to build executables targeted for the end device. In this way, the developers do not need to use complete Yocto system locally, but rather just a subset of tools, which is freely distributable. There are two types of SDK’s:

• Cross-development SDK (run on developers PC, or CI pipeline
• Native SDK (running on target device)

Bitbake commands