RDK Yocto Build Systems

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 devices like set-top boxes, smart TVs etc. To fully understand the concepts presented in this document, it is recommended to read RDK Yocto Build System Overview - DOCUMENTATION - RDK Central Wiki as an introduction to the concepts explored in this document.

Introduction

Folder overview in Yocto for RDK-V:

This document focuses on the example of the RDK video devicesettings module.The devicesettings module provides functionality related to device settings management within the context of the Raspberry Pi platform and the RDK (Reference Design Kit) video meta-layer.
devicesettings comes under these layers: meta-cmf-raspberrypi, meta-cmf-video, meta-rdk-video.

Module Structure

devicesettings module is structured as:

meta-rdk-video
|        └── recipes-extended
|          └── devicesettings
|               ├── devicesettings_git.bb
|               └── devicesettings-hal-headers_git.bb
|
meta-cmf-raspberrypi
           └── meta-rdk-video   
               └── recipes-extended
                   └── devicesettings
                      ├── devicesettings_git.bbappend
                      └── devicesettings-hal-raspberrypi_git.bb

The devicesettings recipe, represented by "devicesettings_git.bb", is responsible for building the devicesettings package from the corresponding source code. It defines the necessary build steps, dependencies, and configurations to create the devicesettings package, and in "devicesettings-hal-headers_git.bb", hal-specific definitions are available.

Also for devicesettings, certain overrides exist in other meta layers, which can be device specific, here we are focusing on raspberrypi device, there are dedicated recipe specific to the 'raspberrypi' hardware abstraction layer (HAL) and append file. 

Recipe Parameters

Below are some of the important parameters present in the recipes:

Parameters in append file-
The *. bbappend file provided above is specifying additional CFLAGS (compiler flags) for the build process. 
The line CFLAGS += " -DHAS_HDCP_CALLBACK -DHAS_FLASH_PERSISTENT" adds two specific compiler flags to the existing CFLAGS.

1. -DHAS_HDCP_CALLBACK: This flag defines the macro HAS_HDCP_CALLBACK, which indicates that the build should include support for HDCP (High-bandwidth Digital Content Protection) callback functionality.

2. -DHAS_FLASH_PERSISTENT: This flag defines the macro HAS_FLASH_PERSISTENT, indicating that the build should include support for persistent storage on Flash memory.

In this example, we are referring to the above mentioned append file. Similarly, if we need to include any additional modifications to the recipe, we can do so by adding them in the append file within the SOC and OEM layers.

Building the Module

To build the devicesettings module, execute the following command with Bitbake:"bitbake lib32-devicesettings"

We can add the Install task bitbake command, which can be helpful if modifications have been made to the devicesettings source code and there is a need to copy the resulting binaries and libraries from the devicesettings build directory to the target system. The following command can be used:

Install bitbake -c install -f devicesettings

If someone needs to execute a task-wise module, the following commands can be used:

If we want to list down rdkv specific components- Execute bitbake -s it will list down all the components.

RDK Package Groups

During the image creation phase of the build process, package groups are added to organize and include related packages in the final image.
devicesettings module is included in:
meta-rdk/recipes-core/packagegroup/packagegroup-rdk-media-common.bb

• packagegroup-rdk-media-common - contains common RDK (non-OSS) components for mediaclient, mediaserver build types. These components are essential for building media-related functionalities in RDK-based systems.

Yocto Build Images

• All the components are built using individual recipes. There shall be a main image recipe (example , rdk-generic-image) which includes all other required recipe and create the final RFS
• Package groups recipe is one support a image recipe to select the set of packages
• The recipes will be called in sequence- opensource components, Kernel, SDK, RDK, MSO, Packaging and create final image.
• The final linux and RFS  image will be created under build_folder/tmp/deploy/images

Target image name:-

Yocto build Image target names are of format- <RDK vendor>-<profile>-<build-type>-<developer>-image
Example-
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.wic
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.wic.bz2
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.tar.gz

 Debugging:

When facing errors or failures while executing a bitbake action, such as compilation or configuration errors, the specific log files can be found in the following directory structure:
Path: build-raspberrypi4-64-rdk-android-ipmc/tmp/work/raspberrypi4_64_rdk_android_ipmc-rdk-linux/devicesettings/5+gitr999-r0/temp/
Example

• log.do_compile: This file contains the error logs related to the compilation process. It provides information about any issues encountered during the translation of source code into executable or object files.

• log.do_configure: This file contains the error logs associated with the configuration step. It helps identify any problems encountered while setting up the build configuration, such as missing dependencies or incorrect settings.

ERROR: lib32-devicesettings-5+gitr999-r0 do_compile: oe_runmake failed
ERROR: Logfile of failure stored in: ~/rpi_build/raspberrypi4-64-rdk-hybrid/tmp/work/armv7at2hf-neon-vfpv4-rdkmllib32-linux-gnueabi/lib32-devicesettings/5+gitr999-r0/temp/log.do_compile.4085187

The provided example demonstrates a compilation error in the "devicesettings" package. The details of the error can be found in the specified log file, which can be analyzed by searching for the keyword "error".