RDK-V 4.0 - SOC Porting Guide

Before You Begin

Product Specifications

The first step to get a fully functional product is the define the product features and see if they meet the standard requirements. A list of expected features from an IP based RDK-V Accelerator are listed at Product Specifications.  SoC can use this as a guide while engineering the RDK SoC platform.

RDKM On-boarding

RDKM offers collaboration space for SoCs which would help SoCs to collaborate with OEM and RDK teams (as well as any 3rd party). RDKM collaboration zone includes features like (but not limited to) CMF facility to maintain build manifests as well as SoC/OEM specific code, SoC SDK artifact storage facility, JIRA & RDK Wiki spaces, integration with Test & Certification suites, monthly & release tagging and so on.

Product Engineering

Once the product features are decided, the device engineering can be started. SoC needs to decide on the hardware layout that incorporates components to the target board. A sample expected hardware specification list as well as a sample flash layout is available at Product Engineering. 

SoC Platform Firmware

SoC can make use of the details available at SoC Platform Firmware to start developing a Yocto build to engineer the device firmware builds based on RDK Yocto build setup.

RDK Certification Suite Package

RDKM offers an in-house Test & certification suite that facilitates SoCs to get their video certified as RDK Compliant device. Certification program includes testing which validates the RDK stack on the device with defined test suite called as RDK Certification Test Suite.

Procedure of porting RDK to SoC

Step 1 : Get a board with Linux and drivers

RDK is based on yocto based linux distribution so SoC vendors has to get a board that is running on linux which is a SoC version of linux with the required drivers that are needed to run all the hardware that are associated in the board like Wifi.

Linux version that is having can be optimzed and hardened by linux kernal can be hardened by SoC vendor itself because RDK is not dealing with hardening Linux in the SOC port so whatever is required is the job of SoC how to hardening how to make it secure those things it is responsibility of SoC vendor.

Mostly they will be having linux for on their board with required drivers.

Add platform/OEM specific Machine DISTRO config file to set the build distribution. For example: meta-cmf-raspberrypi/conf/machine/raspberrypi-rdk-broadband.conf .

Step 2 : Move the build to Yocto, compare it to supported Yocto version of RDK

RDK is based on yocto build setup so if their is not based on yocto so they need to migrate to yocto format so that they can easily adopt on top of it. In case they are not doing it will be little difficult for them to first port the complete RDK and later keep the patches. So ,it is always recommended to port yocto on top of , recommended to convert their linux distribution to a yocto based build.

Yocto 3.1 Upgradation support the following:

• Version upgrades for bitbake, GStreamer, and other OE components

• Linux kernel 5.4 or above

• Extensible SDK

Each component in RDK is a standalone repository with its own individual build tools producing a library or set of binaries. When we upgrade the OE layers to the newer versions, we need to make necessary changes in the RDK Yocto meta layers which use these components, to avoid build failures.

Step 3 : Compare and verify the compiler flags used in RDK and in platform to avoid issues

For example, RDK considers hardware floating point in platform where as some platforms are on software based floating point

Specific DISTRO_FEATURES added to add build time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "

Step 4 : Compare the open source versions used in platform as different versions will cause problems

Check below layers for all opensourced version packages recipes used in RDK. If multiple recipes with different versions are available, then check for the value of PREFFERED_VERSION_<recipe name> set.

Meta layers : -  meta-openembedded, openembedded-core, meta-rdk-ext, meta-rdk, meta-cmf

Step 5 : Move the RDK recipes to platform yocto build

For platform specific recipes, keep them in oem/soc meta layer

Usually manifest of the most recent deployed device of same class can be used as reference for creating initial manifest

Check all device specific repos in the reference manifest, and ensure corresponding device repos are created for this new device as needed, and update the manifest with these updated repos

• Create artifactory repo for the project with appropriate permissions for vendors. This is used for hosting any binaries required for the project

• Check-in SoC components - tool chain, sdk, kernel, drivers, etc.. to corresponding SoC gerrit repos/ artifactory as applicable

• Populate meta soc layer with initial set of changes needed to build kernel, soc components, etc..

• If there is any SoC reference board exists, create corresponding machine configuration in SoC layer, and create a image target to be able to build final image for the reference board. This layer should be separated out within meta soc layer from other common soc, common chip sub layers which will be usually used by meta oem layer as well.

• Populate meta oem layer with machine configuration and other bare minimum changes required to generate a target image for OEM board.

• machine configuration can be updated with "NEEDED_BSPLAYERS" field to include required soc, oem layers in the build

• Any unwanted recipes during early stage of bring up can be masked using BBMASK, if needed

Step 6 : Get a successful build

Add platform specific main recipe to create image.

Components that has HAL layer implementation that needs to be ported by SoC vendors :

Device Settings

Device settings component is having a HAL interface to control device specific peripherals such as video port, audio port and display and front panel. 

More details on HAL interface can be found here: Device Settings HAL Types & Public API DTCP HAL Interfaces.

DTCP

Integrates the SoC provided DTCP library with DTCP/IP manager Interface implementation which manages source/sink DTCP/IP sessions and performs the encryption/decryption.

Hal Interface specification: DTCP HAL Interfaces

tr69hostif

Contains SoC specific MOCA libraries, headers and MOCA profile codes.

API Details: TR69 Host Interface Handler

gst-plugins-rdk /qamtunersrc

qamtunersrc is a push based gstreamer source plugin which tunes to the given service and provides the SPTS data.

• Manages tuner and demux
• Filters PIDs required for SPTS
• Output SPTS as gstreamer buffer

Properties

1. Modulation:
2. Frequency: frequency to tune in KHZ
3. Tunerid: Tuner Handle

Depends on platform specific libraries for tune, filtering, and pod functionalities.

gst-plugins-soc /playersinkbin

Playersinkbin is a gstreamer bin element consisting of demux, decoder and sink elements. A template file gstplayersinkbin.c.template and gstplayersinkbin.h.template are provided as a reference for SoC implementation. SoC has to add details of platform specific plugins and implement the required properties expected out of them.

hdmicec

SDK Vendors should implement CEC driver interface API as specified in hdmi_cec_driver.h

HAL Interface Specificcation: HDMI-CEC HAL API's specification

iarmmgrs

Power, IR and DeepSleep modules are having SoC dependency. API's are specified in plat_power.h, plat_ir.h and deepSleepMgr.h

More details about api's can be found here

westeros-soc

Contains functions for creating and handling native eglwindow. Hal api's are specified in westeros-gl.h

Wi-Fi (Client)

Wi-Fi Client HAL provides an interface (data structures and API) to interact with underlying Wi-Fi driver and enabling the client to be connected with an Access Point.

Hal API's are specified in wifi_client_hal.h. Doxygen Link: Wifi HAL API Specification

Provisioning - iCrypto

Set of Cryptographic API's Implementation, can be used to achieve all type of Cryptographic requirements from Premium App.

Graphics - westeros backend

Media Pipeline Backend layer is a module in device layer which glues the media pipeline capabilities of the device to that of the IgnitionX.

Input key handling

As part of integrating Premium Apps as a native application on the RDK stack, the Premium Apps Video Porting (PVP) Layer needs to be implemented. The PVP Layer consists of the following modules:

• Ignition Device Layer
  • Common
  • Display
  • Input
  • TTS
  • Secure Storage
  • Message Bus
• Device Properties Provider
• Media Pipeline Backend
• PlayReady DRM

Media Playback - gstreamer

Abstraction layer for third-party applications to get specific GStreamer values from the SoC pipeline.

DRM (playready, widevine, TEE, SVP etc.)

Amazon assets are encrypted using Microsoft PlayReady. A robust implementation of the PlayReady must be provided for porting kit to decrypt assets.

TTS

Text-to-speech converts text into spoken voice output to help customers navigate the Prime Video application without seeing the screen. Text-to-speech is mandatory for the US region and optional in other regions.