RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
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.
RDK Versions | Applicability |
---|---|
6.1 | All RDK-V device profiles |
The vendor is expected to have certain prerequisites before proceeding to the porting process, which include:
RDK device profile:
Platform-specific Android Kernel:
Platform SDK with proper build system:
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:
For host setup details, refer to this link: Try Out RDK- Video#BuildSetupInstructions
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
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
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 |
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.
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.
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.
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.
Anchor Generic HAL Generic HAL
HAL documentation | Source code | License type | HAL implementation owner | Device profile applicability | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Open Source |
| IP STB Hybrid STB TV | ||||||||||
Licensed |
| IP STB Hybrid STB TV | ||||||||||
0.2.0 | Open Source |
| IP STB Hybrid STB TV | |||||||||
0.2.0 | Open Source |
| IP STB Hybrid STB TV | |||||||||
Licensed |
| Hybrid STB | ||||||||||
Open Source |
| IP STB Hybrid STB TV | ||||||||||
Open Source |
| IP STB Hybrid STB TV | ||||||||||
Licensed |
| IP STB Hybrid STB TV | ||||||||||
Open Source |
| Hybrid STB | ||||||||||
Open Source |
| IP STB Hybrid STB TV | ||||||||||
Open Source |
| IP STB Hybrid STB TV | ||||||||||
Open Source |
| Hybrid STB TV | ||||||||||
Open Source |
| TV | ||||||||||
Open Source |
| IP STB Hybrid STB TV | ||||||||||
AVSync | 1.0.0 | Open Source |
| IP STB Hybrid STB TV | ||||||||
libDRM | 1.0.0 | Open Source |
| IP STB Hybrid STB TV | ||||||||
1.0.0 | Licensed |
| IP STB Hybrid STB TV | |||||||||
SVP (Specification Document) | beta | Open Source | NA | IP STB Hybrid STB TV | ||||||||
Westeros-sink-soc | Open Source |
| IP STB Hybrid STB TV |
Status | ||||
---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
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.