RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Table of Contents |
---|
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. 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.
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 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 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.
Info |
---|
For details on the RDK Certification please refer: RDK Video Accelerator Certification |
The OEM layer features optimized components for SoC specific RDK provided by the OEM. This includes OEM 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.
Below is the list of component having an OEM interface i.e. either they have a device specific part of the code or add OEM specific improvement to the component.
Bluetooth driver integration.
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.
Show If | ||
---|---|---|
| ||
List of other components that require porting can be found here. |
Show If | ||
---|---|---|
| ||
LicensedManufacturer LibraryThe Manufacturer Library implements a set of interfaces that enable configuration and usage of vendor specific components in the STB. InterfacesMFR API: The APIs comprise of functions that allow to -
eCM API: The eCM API is intended to be used by DSGCC. It allows to -
FPD API: The API controls front panel’s indicators and allows to register key stroke callbacks -
Storage ManagerProvides following functionalities in handling of storage devices such as SD card and so on.
[SDCARD_CONFIG] SYSINTA collection of system integration shell scripts and configuration files that handles many of the initialization and routine job such as bringing up applications or rotating log etc. OEM can define following parts of sysint code.
|