This document helps vendors understand how to create a successful port of RDK on their platform with the help of the HAL API Specification for different RDK Components, as well as how the port can be successfully certified. Depending on the device profile ( IP STB, RDK TV, Hybrid STB, etc. ), vendors may choose the relevant components and perform the port by implementing the HAL layer.

Details of how to port third-party software stacks or applications to a SoC platform are out of the scope of this porting guide.

Version details

Prerequisites

The vendor is expected to have certain prerequisites before proceeding to the porting process, which include:

• RDK device profile:

  • Decide on the profile by referring to the available RDK profiles and have a platform with the expected capabilities for the chosen profile. Depending on the device profile selected, the components that are required to be ported are available in the HAL table below.

• RDK HAL API Source code access:
  
  • The RDK source code is distributed across multiple source code repositories which are available in RDK Central GitHub.

• Platform-specific Android Kernel:

  • It is highly recommended to use an Android kernel for the target platform as RDK is moving towards an Android kernel. However, it is the discretion of SOC to use their own version of kernel be it Android or non Android.

• Platform SDK with proper build system:

  • While there is no dependency on a particular build framework for the vendor to implement the HAL layer and get it certified, it is recommended to use the Yocto ( Dunfell ) build framework for the following reasons.
    • RDK uses Yocto build framework
    • Once the HAL layer is implemented and certified, an existing build framework based on Yocto will make it very easy to integrate the HAL layer into the RDK stack

Porting

Environment:

Yocto based build environment( recommended ) :

RDK uses the Yocto Bitbake build system to generate RDK builds. The flexibility of Yocto to add/ remove components or layers with much ease helps to keep RDK working fine with multiple sets of SoC/ OEM/ Operator / Third-party software combinations. Using Yocto as the build environment will help the vendors to easily plug RDK on top of their HAL implementation thereby reducing integration time at a later point once the HAL is certified. There would be a basic RDK build system on which SoC could add their Soc layer, OEM could add their OEM layer, and finally, Operator could add their Operator layer. The starting point for the Yocto build is a manifest file. For more details, please refer to the manifest file.

Steps to setup a Yocto-based build environment is detailed below:

Host Setup Details

For host setup details, refer to this link: Try Out RDK- Video#BuildSetupInstructions

Initializing the build environment

While the actual build setup depends on how the vendor wants to set it up, a sample Yocto build system for the RDK generic reference platforms is given below as a reference

mkdir <workspace directory>
cd <workspace directory>
#for Media Client,Hybrid Gateway, and Hybrid Gateway with operator Ref.App follow below repo init command
repo init -u https://code.rdkcentral.com/r/manifests -b dunfell -m rdkv-nosrc.xml
#for Client STB follow below repo init command
repo init -u https://code.rdkcentral.com/r/rdkcmf/manifests -b dunfell -m rdkv-extsrc.xml
repo sync -j `nproc` --no-clone-bundle --no-tags

Add the vendor layer in Yocto

• Click here to understand and create layers.
• Refer to this link to know about the RDK Yocto Layer Structure.

Vendor-specific build environment:

Vendor can use the build framework of their choice to create the software for their platform. This will help the vendor to use their existing build framework and develop the RDK HAL layer on top of their platform/SDK using it. As this framework varies from vendor to vendor ( for eg: Yocto BitBake, Buildroot, etc. to name a few ) there are no generic steps that can be shared towards this, and depends on the vendors build setup.

For FAQs on Yocto Build, please refer to the Build FAQ.

Kernel

In the RDK-V ecosystem, the SOC team provides the kernel and associated drivers required for respective devices. As of RDK-6, there was no requirement for a specific Android kernel version. Different SOC platforms use different versions.

The responsibilities can be divided between the SOC vendor, RDK system integrator, and OEM vendor.

Prerequisites

• Required Kernel configurations to be enabled for RDK6.x have to be shared with SOC.
  • For other kernel configuration-dependent RDK features (container, AppArmor)
  • Identify any other kernel configurations needed for RDK functionality

Assumptions

• For SOC reference devices, providing updated kernel release along with dependent package (SDK) is the responsibility of SOC partners.
• For OEM VA devices, ideally, it is the OEM's responsibility to get an updated kernel from SOC and then integrate OEM-dependent components/drivers on top of it. But in most cases, the RDK system integrator (RDKM platform team in this case) does this job of getting kernel release from SOC and coordinating with OEM and other 3rd party vendors to integrate their respective modules with the updated kernel.
• For open platforms (RPI), it is the responsibility of the RPI RDK platform development team to download the Android RPI kernel, update relevant configurations and drivers and supporting packages, and upgrade the kernel.

For high-level design/architecture of the Android kernel, please refer android kernel architecture page .

NOTE: In the future, all RDK devices will be upgraded to the 64-bit Android Common Kernel 5.15 for the RDK7 release.

HAL

RDK provides a set of HAL APIs that will abstract the platform from RDK. Vendors need to implement the HAL APIs to meet the HAL Specifications as described in the HAL Documentation for each component in the below table. Details of which HAL components need to be implemented for each device profile and their documentation are specified in the HAL table below. 

OEM&SOC : This indicates corresponding HAL needs to be implemented by both OEM and SOC

SOC : This indicates corresponding HAL needs to be implemented by SOC

OEM : This indicates corresponding HAL needs to be implemented by OEM

Certification

RDK certification program facilitates users to get their Video Accelerator product certified as RDK compliance device.

RDKM provides the RDK Certification suite to verify the compliance of the RDK Video Accelerator device. The certification program includes testing that validates the RDK  stack on the user platform with a defined test suite called as RDK Certification Test Suite.  It is mandatory to go through this program in order to brand the user's platform as an RDK-compliant product.