Yocto Overview

The Yocto Project provides tools, templates, and methodologies to build custom Linux-based software distributions for embedded systems. It enables developers to create optimized Linux images for a wide range of devices, including IoT devices, embedded systems, and appliances, with flexibility and customization options. For more you can visit Yocto Project Overview and Concepts Manual. 

In this page:

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:

ParametersDescriptionExample
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, etcSRC_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/LDFLAGSCFLAGS 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"
DEPENDDEPEND is a recipe parameter that defines the dependencies of a specific component or recipeDEPENDS += "python3"
do_install ()It is a task function in a recipe that is responsible for installing the built files of the packagedo_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.

Patches can be applied to recipe files. Patch files extension *.patch. Place the patch file in subdirectory of recipe named (component) folder. The subdirectory should be preferably named as that of component or as ‘files’. Add the below line to the recipe file
SRC_URI += “file://temp.patch“

This section describes how to make changes and build any particular component in RDK stack. 

Apply Patch and Build Component

1) Add the below line to the recipe of the component you need to modify.

        SRC_URI += “file://<name>.patch”                              

        eg:  SRC_URI += “file://temp.patch” in  meta-rdk/recipes-common/breakpad_wrapper/breakpad-wrapper.bb                           

2) Create a folder named “files” in the same folder of recipe. 

eg: In meta-rdk-video/recipes-extended/breakpad-wrapper.bb/

3) Create a blank file with the same name given in the recipe.

         touch files/<name>.patch 

         eg: touch files/temp.patch                             

4) bitbake <recipe> -c devshell        

5) Do “quilt top” and verify if the patch file is reflected there. 

    eg:

        # quilt top

        patches/temp.patch

6) quilt add “filename which you need to modify” (If multiple files are there, then add all those)

        eg: quilt add Makefile.am configure.ac              

7) Make necessary modifications required for these files.

8) quilt refresh

9) Verify if your modifications are reflected in the patch file.

         vi patches/<name>.patch

10) Now replace this patch file with original one in files folder.

         eg: cp patches/temp.patch ~/…/meta-rdk/recipes-common/breakpad_wrapper/files/temp.patch

11) exit

12) Do a clean and then build.

bitbake -ccleanall breakpad_wrapper 

bitbake breakpad_wrapper



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.

TASKDESCRIPTIONFUNCTION

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 NameDescription 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. 
Defines variables such as  PACKAGE_CLASSES, LICENSE_FLAGS_WHITELIST, PACKAGECONFIG

build-raspberrypi4-64-rdk-android-mc/conf/auto.conf 
bblayers.conf 

Manages layer configuration, specifying enabled layers and their paths.
Defines variables such as LCONF_VERSION, BBPATH, BBFILES, RDKROOT, BBLAYERS. 

build-raspberrypi4-64-rdk-android-mc/conf/bblayers.conf

 

local.conf 

User-editable configuration file for customizing the build environment and embedded Linux system.
Defines variables such as BB_NUMBER_THREADS, DISTRO,DL_DIR,SSTATE_DIR, EXTRA_IMAGE_FEATURES,INHERIT,  DISTRO_CODENAME,  CONF_VERSION. 

build-raspberrypi4-64-rdk-android-mc/conf/local.conf


For more you can visit Yocto Project Overview and Concepts Manual. 

  • No labels

DISCLAIMER: Please note that the use of the RDK Wiki is subject to its Privacy Policy & Terms of Use. In addition, this Wiki may be accessed by all RDK licensees and their contractors.