RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
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 Settop box is available here. 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.
This should be used only as a reference and not a final set of features.
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.
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 IP based STB's hardware specification list as well as a sample flash layout is available at Product Engineering.
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.
RDKM offers an in-house Test & certification suite that facilitates OEMs 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.
For more details on the RDK Certification, please refer IP based STB's Certification process available here
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 .
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 )
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
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.
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
Provides platform specific configuration options for Hardware test. Which will run periodically in background to check attached hardware health.
LED Manager is used to control the LED patterns during different system events.
This handles the HDCP service operations such as enable or disable the HDCP.
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