RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Below are the list of components that has a HAL layer implementation that needs to be ported by SoC vendors.
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.
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.
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
Contains SoC specific MOCA libraries, headers and MOCA profile codes.
API Details: TR69 Host Interface Handler
qamtunersrc is a push based gstreamer source plugin which tunes to the given service and provides the SPTS data.
Properties:
Depends on platform specific libraries for tune, filtering, and pod functionalities.
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.
SDK Vendors should implement CEC driver interface API as specified in hdmi_cec_driver.h
HAL Interface Specificcation: HDMI-CEC HAL API's specification
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
Contains functions for creating and handling native eglwindow. Hal api's are specified in westeros-gl.h
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
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
Graphics library porting for SoC.
AES Encryption and decryption of packets handled from DVRManager SoC Layer.
Porting of mediaframework involves porting of the following sub-modules:
Details about HAL API's that require porting is published as part of Doxygen Documentation activity in Mediaframework HAL API Specification.
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.
PlayReady and WideVine Open CDMi implementation - specific to platform.