Getting Started

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 Accelerator product 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. It is mandatory to go through this program in order to brand user's platform as RDK compliant product.

SDK Releases

Once the RDK bring-up in SoC is completed, the vendor needs to plan on the delivery of the software to OEM vendors. This usually happens in 2 ways:

HAL + SDK binary

In this approach will make use of the RDK Artifactory server. Artifactory server is a Repository Manager that functions as a single access point organizing all the binary resources including proprietary libraries, remote artifacts and other 3rd party resources. It is a secure and restricted server, only collaboration members will have access to this server. SOC secure information like secure components such as PlayReady, widevine and Dolby libraries etc. can be hosted in Artifactory server.

SoC vendor can define a HAL layer, share the source of HAL & yocto meta layer that can be stored in RDK CMF Git repository (which will be shared only  to authorized OEM vendors who will work in collaboration with the SoC vendor), share the SDK binary that can be stored in RDK Artifactory (which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor) and then publish necessary documentation on how to build the SoC SDK. SoC vendor can use the git/ Artifactory for periodic updated (for releases) or for bug fixes. All the source code, binary and documentation will be strictly access restricted and access will be allowed only for authorized personnel by SoC vendor.

Artifactory server can be accessed by adding the Artifactory details and login credentials in the .netrc file, just like it is done for normal git repositories. A sample is given below:

machine your.artifactory.host
login YOUR_ARTIFACTORY_USERNAME
password YOUR_PASSWORD_OR_KEY_OR_TOKEN

Complete source code

In this approach, SoC vendor can define a HAL layer, share the source of HAL , yocto meta layer and SDK source code that can be stored in RDK CMF Git repository( which will be shared only  to authorized OEM vendors who will work in collaboration with the SoC vendor )  and then publish necessary documentation on how to build the SoC SDK. SoC vendor can use the git for periodic updated ( for releases ) or for bug fixes. All the source code and documentation will be strictly access restricted and access will be allowed only for authorized personnel by SoC vendor.

For both approaches, the RDKM collaboration zone will be used with strict access restrictions.

Collaboration with OEMs

After a successful bring up of RDK on SoC platform, the next step will be to allow OEMs to work with SoCs to get a device based on the SoC platform. RDKM offers collaboration space for SoCs which would help SoCs to collaborate with OEM and RDK teams (as well as any 3rd party) in their journey to engineer a successful RDK product. 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 etc.

Please refer RDKM On-boarding for more details on facilities available for SoCs and OEMs as part of collaboration zone . In short, it will include:

• Access restricted Git repositories and Artifactory servers
• Access restricted Confluence and JIRA spaces for Management and Documentation
• Access to RDKM support as well as extended documentation
• Access to test & certification support 

Below are the list of components that has a 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.

Licensed

Closed Caption

ccReader module which does the closed caption decoding is having HAL dependency. API's are specified in ccDataReader.h

More details on HAL interface can be found here: closed Caption HAL API's

DirectFB

Graphics library porting for SoC.

DVRManager

AES Encryption and decryption of packets handled from DVRManager SoC Layer.

Mediaframework

Porting of mediaframework involves porting of the following sub-modules:

• halcdl
• haldsg
• halpod
• halsnmp
• halmfr
• halplatform

Details about HAL API's that require porting is published as part of Doxygen Documentation activity in Mediaframework HAL API Specification.

ServiceManager

Service Manager as such doesn't have an HAL part to be implemented, however it can have a platform part that extends/alters it's functionality with few of the legacy services such as Power management (deep sleep), Front panel control, and so on.

wpeframework/OCDMi

PlayReady and WideVine Open CDMi implementation - specific to platform.