RDK License

SoC vendors 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

This section will detail the recommended step by step procedure of adopting RDK by OEM

Product Specifications

The first step to get a fully functional product is to define the product features and see if they meet the standard requirements. See here to know what are all the features available in RDK-B and can implement based on your requirement. OEM can use this as a guide while engineering the RDK OEM platform. 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 On-boarding

Anchor
RDKM On-boarding RDKM On-boarding

RDKM provides a collaboration zone facility for SoCs to facilitate easier engineering of RDK based devices. The collaboration zone will help SoCs to work with OEMs, RDKM and any 3^rd party along with a common space to develop & integrate, manage and verify the device. The zone includes facilities for code management, a confluence based RDK Wiki for knowledge management & sharing, a JIRA for tracking activity progress, issues as well as to manage the activities, a test setup to validate devices. The access restrictions implemented will help the collaboration zone to be accessible only for the authorized personnel thereby guarding any sensitive information related to SoC/OEM/Third party.

Roles & Responsibilities

A table explaining the roles & responsibilities of OEM & RDKM in the collaboration zone is given below:

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. The device will be categorized either as a home broadband device or a business gateway based on the hardware capabilities.

Device Firmware

OEM can make use of the below details to start developing a Yocto build to engineering the device firmware builds based on RDK Yocto build setup.

Yocto based RDK builds are flexible enough to easily accommodate SoC & OEM changes. The starting point for the Yocto builds is a manifest file. The manifest file is an xml file that contains details of the different open embedded Yocto build layers, meta layers, RDK as well as open-source components that need to be fetched during initial stages ( than during bitbake time ) as well as the URL locations from where the data can be pulled. A set of sample manifests that can be used as a template for developing OEM specific manifests are given below

For more details on getting RDK-B ported to an OEM device, please refer to the links RDK-B OEM Specific Porting .

SoC/OEM meta-layer creation

To match the layered structure of Yocto builds, a OEM-specific layer is used to include OEM changes and additions. Use the yocto-layer create sub-command to create a new general layer.

There shall be a separate device (machine) configuration file (.conf) for each device for the particular OEM for which the layer is intended. The general naming terminology for the OEM layer is meta-rdk-oem-<oem name>

The device (machine) configuration file shall include the corresponding include (.inc) file to get machine configuration details.

TDK

RDKM offers an in-house Test & certification suite that facilitates OEMs to get their devices tested for their features.

For more details on TDK refer: TDK-B Documentation

SDK Releases

Once the porting of RDK-B gets completed by SoC vendors, they will make it available for OEMs. SoC will provide the HAL+ SDK binary or the complete source code, which the OEMs can receive and install.

HAL + SDK binary

If the SoC vendor provides HAL+ SDK binary, the OEMs can 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. OEM and SoC secure information can be hosted on the Artifactory server.

OEM vendors will work in collaboration with the SoC vendor. SoC vendor can define a HAL layer, share the source of HAL & yocto Yocto meta layer that can be stored in RDK CMF Git repository, share the SDK binary that can be stored in RDK Artifactory (Shared only from authorized SoC vendors who will work in collaboration with the OEM vendor) and then publish necessary documentation on how to build the OEM SDKimage. OEM vendors can use the git/ Artifactory for periodic updates (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 OEM vendors.

The 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

If the SoC vendor provides complete source code, OEM vendors can work in collaboration with the SoC vendor. SoC vendor can define a HAL layer, share the source of HAL & yocto meta layer that can be stored in RDK CMF Git repository, and then publish necessary documentation on how to build the OEM SDK.OEM vendors can use the git/ Artifactory for periodic updates (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 OEM vendors.

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

Collaboration with

Operators

After a successful bring-up of an RDK on the OEM platformbased image in OEM device, the next step will be to allow OEMs operators to work with SoC vendors OEMs to get a device based on the OEM platformoperator code on that OEM device. RDKM offers collaboration space for OEMs which would help OEMs to collaborate with SoC and RDK teams (as well as any 3rd party) in their journey to engineering work with an operator specific layer and bring up 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/ SoC Operator specific code, Soc and OEM SDK artifact  artifact storage facility, JIRA & RDK Wiki spaces, integration with Test & Certification suites, monthly & release tagging, etc.

Please refer to RDKM On-boarding for more details on facilities available for OEMs and SoCs as part of the 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