You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

The Aim of this document is to explain on what OEM layer does which sits on top of SoC layer and adds support for software for boot-up, image updates, and APIs to handle custom drivers. These could be specializations to the generic or SoC components or complementary software components provided by the OEM to create a fully functional set-top device.

On this Page:

Before You Begin

RDK License

OEMs are advised to get into an agreement with RDK Management LLC to obtain the free license so as to use the complete RDK Code base in their platform. More details about license is available at https://rdkcentral.com/licenses/ . Please email info@rdkcentral.com if you have additional questions about licenses or membership

Overview

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 Set-top box are listed at Product Specifications. OEM can cross check the expected features/specifications with the capabilities of the SoC platform being used and can finalize the features supported by the product.

For details of product specifications, please refer:   Product Specifications

RDKM On-boarding

RDKM offers collaboration space for OEMs which would help OEMs to collaborate with SoC 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.

For details of RDKM On-boarding process, please refer: RDKM On-boarding

Product Engineering 

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

For details of product engineering, please refer:  Product Engineering

Device Firmware

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

For details please refer:  Device Firmware

RDK Certification Suite Package

RDKM offers an in-house Test & certification suite that facilitates OEMs to get their IP based 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.

For details on the RDK Certification please refer: RDK IP Set-top Product Certification

Procedure for OEM porting of RDK

The aim of this document is to explain the procedure for OEM porting of RDK.


Step 1 : Selection of SoC board with RDK ported on it

Refer this page SoC Platform Firmware to know the details about Yocto manifests, SoC meta-layer creation includes adding the Machine Configuration File for the new SoC .

Step 2 : Add OEM components

OEM needs to add OEM specific components like Firmware Upgrade, Secure Boot Loader, MFR libraries, Vendor Specific Information, NVRAM files and partition, Provisioning, OEM Specific drivers, STB Utilities, RDK Device-Specific Patches, Image Generation Utiities etc. as well as interfacing layers to the generic RDK for relevant OEM code modules ( see below )

Step 3 : Upgrade RDK/SoC components for OEM changes

Any Revision change in SoC layer is usually done by SoC’s build environment and the new SDK or revision is updated in recipe. If a new recipe is added for any update in SoC software, then can be handled using PREFERRED_VERSION Yocto flag in meta layer

Components of OEM Interface

Bluetooth

Bluetooth Manager implements the Bluetooth HAL i.e. Bluetooth Core (BTRCore) API. Bluetooth HAL interface provides a software abstraction layer that interfaces with the actual Bluetooth implementation and/or drivers. RDK Bluetooth HAL layer enables projects to pick any Bluetooth profiles as per their requirements. Bluetooth HAL uses BlueZ5.42 stack which is a quite popular Linux Bluetooth library.

  • Bluetooth HAL - Provides APIs to perform Bluetooth operations by abstracting and simplifying the complexities of Bt-Ifce (& BLuez)
  • Bt-Ifce - Abstracts Bluez versions and serves as a HAL for other Bluetooth stacks - Interacts with Bluez over DBus
  • Bluez - Interacts with kernel layer bluetooth modules

Modules

Crash Upload

  • Uploads core dumps to a FTP server if there are any

  • This interface is optional, OEM may implement a customized script for uploading the crash dump files to a server using specific certificate files

Device Settings

  • OEM implementation includes device specific configuration parameters & customizing data structures for front panel setting and so on

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
  • Provides setup scripts to initialize the default DTCP data to device specific persistent partition

hwselftest

Provides platform specific configuration options for Hardware test. Which will run periodically in background to check attached hardware health.

  • OEM dependency is limited to providing a configuration file hwselftest.conf which defines the hardware interfaces that should be tested e.g. partition name, HDMI, IR, MOCA and so on

LED Manager

LED Manager is used to control the LED patterns during different system events.

  • OEM should implement the template code to ensure that it matches with their LED coloring scheme and other configuration parameters such as brightness level and number of LED types, multi-color or single color LEDs

tenableHDCP

This handles the HDCP service operations such as enable or disable the HDCP.

  • OEM interface includes implementing manufacturer specific calls to read the keys and so on

Wi-Fi

  • OEM specific Wi-Fi driver configuration files and utility library can be added optionally


For details on the Wi-Fi HAL Public APIs and Data Types, please refer: https://wiki.rdkcentral.com/doxygen/rdkv-opensourced/df/dce/group___w_i_f_i___h_a_l.html


  • No labels

DISCLAIMER: Please note that the use of the RDK Wiki is subject to its Privacy Policy & Terms of Use. In addition, this Wiki may be accessed by all RDK licensees and their contractors.