RDK Yocto Build System Overview
Yocto in RDK
The primary function of the Yocto Project within RDK development is the building and packaging of multiple components. RDK leverages the capabilities of the Yocto Project to create customized Linux-based software distributions that power the devices like set-top boxes, smart TVs etc.
Advantages-
- An automated build system that streamlines the compilation, configuration, and packaging processes.
- Support for major embedded architectures
- A layered mechanism for configuration extension,
- Developers benefit from features such as easy migration to different hardware platforms.
RDK Yocto Layer Structure
The RDK Yocto layer structure is designed to build the RDK stack for embedded devices using the Yocto Project and the OpenEmbedded build system.
The layer structure consists of the following components:
- meta-rdk-<operator>: This layer contains operator-specific recipes and configurations. It focuses on customizations and configurations specific to individual operators.
- meta-rdk-soc/oem: This layer includes system-on-chip (SoC) or original equipment manufacturer (OEM) specific recipes and configurations.
If there are multiple target platforms under the same SOC/OEM, they can be appended to the layer and differentiated using model names. For example:
meta-rdk-soc-skyworth-rtd
meta-rdk-soc-skyworth-hx4x
- meta-rdk: This layer contains common RDK component recipes and distribution policies. It serves as the central layer for RDK (Reference Design Kit) components and provides a standardized set of recipes and configurations for RDK-based systems.
meta-rdk-video- It is focused on video-related recipes and configurations for RDK-based systems.
meta-rdk-ext-These are extension layer that provides additional recipes, components, and configurations for RDK-based systems. Example- webkit. - meta-openembedded: This layer is part of the OpenEmbedded project, which provides a collection of open-source recipes and components for embedded systems. It includes a wide range of recipes and configurations that can be leveraged to build customized embedded systems. This layer offers additional flexibility and options for extending the functionality of the RDK-based system.
-
meta-cmf-<operator>: This layer contains CMF recipes and configurations specific to operator customizations. It provides a framework for operator-specific modifications, such as branding, custom applications, or services tailored to their specific requirements.
Meta-Layers
Meta-layers contains configuration, recipes, classes, and patches. These include configuration files (*.conf), classes (*.bbclass), and recipes (*.bb, *.bbappend), which are the logical units of software/images to build.
RDK meta-layers provide the necessary components, recipes, and configurations to build the RDK stack.
- meta-rdk: layer includes common RDK components and follows distribution policies based on the Poky project.
- meta-rdk-bsp: BSP layers, such as meta-rdk-bsp and meta-rdk-bsp-<soc-bsp-layer> or meta-rdk-bsp-<oem-bsp-layer>, provide the necessary components, recipes, and configurations to build the RDK stack.
Examples of BSP layers include meta-rdk-broadcom and meta-rdk-pace. - meta-raspberrypi: Boards support layer, Reference for porting, Create meta-rdk-bsp delta layers for existing BSPs
Example:- Meta layers contain recipes
Reference-
├── conf
├── recipes-bsp
├── recipes-core
├── recipes-devtools
├── recipes-extended
├──recipes-connectivity
├── recipes-networking
├── recipes-graphics
└── scripts
Under recipe one can find- eg
recipes-core
glibc
├── glibc_2.3%.bbappend
└── glibc_%.bbappend
glib-networking
└── glib-networking_2.48.2.bb
glib-openssl
├── files
│ ├── relax_read_error_handling.patch
└── glib-openssl_2.50.3.bb
Recipes
Recipes are the most basic metadata files denoted by the file extension *.bb. Recipes can build one or more packages from source code.
Some of the essential parameters used in recipes are mentioned below:
| Parameters | Description | Example |
|---|---|---|
| source code URI (SRC_URI) | The SRC_URI variable is used to specify the source files that are needed to build a recipe. It can point to different locations, such as online repositories, local directories, or mirrors. It supports various protocols, such as git, http, ftp, file, etc | SRC_URI = “git://github.com/rdkcentral/rdkperf;protocol=git;branch=main“ |
| source revision (SRCREV) | We use source revision (SRCREV) to specify the exact revision of the source code that we want to use for a recipe | /*SRCREV – specifies the specific revision */ SRCREV_ = “${AUTOREV} |
| package version (PV) | Package version also allows user to choose the most suitable or preferred version of software for their needs. | /*PV – Package version*/ PV = “${RDK_RELEASE}+git${SRCPV}” |
| source directory (S), | The source directory (S) is the location in the build Directory when unpacked recipe source code resides. | /*S – Source dir*/ S = “${WORKDIR}/git/” |
| CFLAGS/LDFLAGS | CFLAGS is a recipe parameter that allows you to specify compiler flags for the C programming language and LDFLAGS are to specify linker flags during the build process | CFLAGS += “-O2” LDFLAGS += “-L${WORKDIR}/mylib -1mylib” |
| DEPEND | DEPEND is a recipe parameter that defines the dependencies of a specific component or recipe | DEPENDS += “python3” |
| do_install () | It is a task function in a recipe that is responsible for installing the built files of the package | do_install () { install -d $ {D}${bindir} } |
Additionally, there are append files (*.bbappend) that extend or modify existing recipes.
Patching
Recommended Approach-
If we are making any changes, we need to upstream those changes to the corresponding repositories rather than creating patches.
More information on patches can be found in below section.
External SRC and non external src
External SRC is used in the Yocto Project to specify an external source for a recipe. By setting the EXTERNALSRC variable, you can build software from a source located outside the default Build directory. To use an external source, inherit the externalsrc class and set EXTERNALSRC to the path of your source code. For example:
INHERIT += “externalsrc”
EXTERNALSRC_pn-myrecipe = “path-to-your-source-tree”
By default, the externalsrc.bbclass builds the source code in a separate directory, but you can set EXTERNALSRC_BUILD to specify a different directory. For more details, refer to the Yocto Project Overview and Concepts Manual.
Non external SRC is the default way of building a recipe, where the source files are fetched from the SRC_URI variable. This can be a local file, a remote URL, a git repository, or any other supported protocol. The source files are then unpacked, patched, configured, compiled, and packaged by the Yocto build system.
Example- It is usually present in the recipe files
SRC_URI = “git://github.com/rdkcentral/rdkperf;protocol=git;branch=main“
The SoC / OEM layer Recommended Practice
- Create a new layer which will hold all the recipes and machine configurations for the new SoC/OEM.
- Adding the Machine Configuration File for the new SoC/OEM.
- Adding a Kernel for the Machine.
- Adding Recipe for SoC/OEM
- Creating packages for building images
- Separate layers must be available for an OEM, if different SoCs are used
“meta-rdk-soc-X-oem-Y”,”meta-rdk–soc-X-oem-Z”, etc
Quick References
This guide is intended to help developers understand the Yocto framework in RDK so they can extend the existing functionality.
BitBake Main Tasks
Bitbake executes all the layers starting with a prefix ‘meta’. It parses the build classes, configuration files, and recipes and executes each task by creating a shell script on-the-fly.
| TASK | DESCRIPTION | FUNCTION |
|---|---|---|
Fetch | Fetches the source code | do_fetch |
Unpack | Unpacks the source code into a working directory | do_unpack |
Patch | Locates patch files and applies them to the source code | do_patch |
Configure | Configures the source by enabling and disabling any build-time and configuration options for the software being built | do_configure |
Compile | Compiles the source in the compilation directory | do_compile |
Install | Copies files from the compilation directory to a holding area | do_install |
Populate SYSROOT | Copies a subset of files installed by do_install into the sysroot in order to make them available to other recipes | do_populate_sysroot |
Package | Analyzes the content of the holding area and splits it into subsets based on available packages and files | do_package |
Root FS | Creates the root filesystem (file and directory structure) for an image | do_rootfs |
Configuration
Configuration (*.conf) comprises of global definition of variables. They define various settings and variables that control the build process and customize the resulting embedded Linux system. Here are some commonly used configuration files and their purposes:
| File Name | Description | Configuration file path |
|---|---|---|
| layer.conf | Configuration file for Yocto Project layers, defining metadata and layer-specific settings. It contains definitions such as BBPATH, BBFILES, LAYERDEPENDS_cmf-raspberrypi | meta-cmf-raspberrypi/conf/layer.conf |
| machine/<configuration_file_name>.conf Eg- raspberrypi4-64-rdk-hybrid.conf | Machine/BSP-specific configuration file. It contains extensions and customizations for a specific machine. Defines MACHINE_IMAGE_NAME, DISTRO_FEATURES_append, ENABLE_HDMI_FORCE_HOTPLUG | meta-cmf-raspberrypi/conf/machine/xxx.conffiles |
| auto.conf | This file is automatically generated and resides in the build directory. It is used for customizing and controlling the build process. | build-raspberrypi4-64-rdk-android-mc/conf/auto.conf |
| bblayers.conf | Manages layer configuration, specifying enabled layers and their paths. | build-raspberrypi4-64-rdk-android-mc/conf/bblayers.conf
|
| local.conf | User-editable configuration file for customizing the build environment and embedded Linux system. | build-raspberrypi4-64-rdk-android-mc/conf/local.conf |
For more you can visit Yocto Project Overview and Concepts Manual.