RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
<Work in progress. only the skeleton added>
Background Color | ||||||
---|---|---|---|---|---|---|
| ||||||
Before You Begin Anchor |
|
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
...
Background Color | ||||||
---|---|---|---|---|---|---|
| ||||||
Bringing up RDK by OEM- Approach Anchor |
|
...
|
This section will detail the recommended step by step procedure of adopting RDK by OEM
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.
Anchor | ||||
---|---|---|---|---|
|
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 3rd 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.
A table explaining the roles & responsibilities of OEM & RDKM in the collaboration zone is given below:
# | Activity | Owner | Remarks |
---|---|---|---|
1 | RDKM | RDKM will setup Collaboration space, access restrictions | |
2 | OEM | JIRA project. OEM will be the owner |
...
of the JIRA project. | |||
3 | OEM/RDKM | RDKM will create the space and SoC/OEM push the code changes | |
4 | OEM | Create necessary device specific HAL implementation for porting RDK into Accelerator | |
5 | RDKM |
...
Details which SDK version to be used. RDKM will support the integration with OEM libraries | |||
6 | OEM | Manifest for building the accelerator | |
7 |
...
Remote control integration(only for RDK licensee)
...
RDKM/OEM
...
RDKM approved RCU’s are enabled by default
...
8
...
...
RDKM/OEM
...
Comes with pre-integrated UI’s, OEM and RDKM will discuss ont he default UI
...
9
...
Create Accelerator build from CMF GIT
...
OEM / RDKM
...
Both teams work together to build Accelerator from CMF.
...
10
...
Provide Devices to RDKM team
...
OEM
...
11
...
Device flashing instructions / recovery mechanisms
...
OEM
...
OEM should share the device flashing instruction.
...
12
...
Sanity, Functionality Testing & automation tests
...
RDKM/OEM
...
RDK Certification Suite(only for RDK licensee)
...
13
...
Monthly release & tagging
...
OEM
...
Monthly tagging and release with stakeholders along with test results
...
title | Click here for more details such as creating collaboration zone, creating user accounts for OEM Members, creating a JIRA project for OEM etc. |
---|
It is expected that OEM has already obtained a license to work with RDKM (If not, OEM can send a mail to support@rdkcentral.com to start off with the discussions) .
With this user account an INFRA ticket can be raised at https://jira.rdkcentral.com to create a collaboration repo. The ticket should contain the details for
OEM users can sign up at https://wiki.rdkcentral.com/signup.action to create a user account in RDK. For any issues faced, a mail can be sent to support@rdkcentral.com
An INFRA ticket needs to be raised at https://jira.rdkcentral.com with the below details
Provide Devices to RDKM team | OEM | ||
8 | Device flashing instructions/recovery mechanisms | OEM | OEM should share the device flashing instruction. |
9 | Sanity, Functionality Testing & automation tests | RDKM/OEM | |
10 | Monthly release & tagging | OEM | Monthly tagging and release with stakeholders along with test results |
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
It is expected that OEM has already obtained a license to work with RDKM (If not, OEM can send a mail to support@rdkcentral.com to start off with the discussions) . With this user account, an INFRA ticket can be raised at https://jira.rdkcentral.com to create a collaboration repo. The ticket should contain the details for
|
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
OEM users can sign up at https://wiki.rdkcentral.com/signup.action to create a user account in RDK. For any issues faced, a mail can be sent to support@rdkcentral.com |
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
An INFRA ticket needs to be raised at https://jira.rdkcentral.com with the below details |
For any issues faced, a mail can be sent to support@rdkcentral.com |
Anchor | ||
---|---|---|
|
...
|
Expand | ||
---|---|---|
| ||
An INFRA ticket needs to be raised at https://jira.rdkcentral.com to create a JIRA project for OEM. Once approvals are received along with required access restrictions, the project will be created. . For any issues faced, a mail can be sent to support@rdkcentral.com |
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
To get a Git repository a request needs to be raised to CMF team using the CMFSUPPORT ticket at https://jira.rdkcentral.com . Once approvals are received along with required access restrictions, the repo will be created. Any changes in merge permissions can be requested in same ticket. For creating any specific branches in the repo, another ticket in the same CMFSUPPORT can be raised. For any issues faced, a mail can be sent to support@rdkcentral.com . Once the git repo is created, it can be accessed at https://code.rdkcentral.com |
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
An INFRA ticket needs to be raised at https://jira.rdkcentral.com to get access to SDK artifacts. Once approvals are received along with required access restrictions, the access should be in place. For any issues faced, a mail can be sent to support@rdkcentral.com |
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.
...
Anchor | ||||
---|---|---|---|---|
|
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
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
...
|
...
6
...
|
...
5
|
...
|
...
|
...
|
...
|
...
|
...
2
...
...
This manifest contains meta layer details of SoC and , optionally, some SoC specific repos
...
4
...
...
This manifest has details of the basic Yocto Open Embedded layers
|
For more details on getting RDK-B ported to an OEM device, please refer to the
...
...
.
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.
Expand | ||
---|---|---|
| ||
Adding a new machine to Yocto involves the following:Create a new layer |
...
that will hold all the recipes and machine configurations for the new SoC/OEMthe yocto-layer command is not enabled by default, If you want to add a new layer using the "yocto-layer" script, |
...
you need to first download the poky and put it in your |
...
codebase, and run the script to create a new folder. You can download poky from git using :
Use the yocto-layer create sub-command to create a new general layer. $ yocto-layer create mylayer <specify the layer which you need to be created> Please enter the layer priority you'd like to use for the layer: [default: 6] 6 There shall be a separate device (machine) configuration file (.conf) for each device for the particular chip family for which the layer is intended for. For Eg: A layer "meta-rdk-oem-OEM-X-SOC-Y" means this layer shall be able to build any devices manufactured by OEM "X" with all variants of SoC "Y" like Y-1,Y-2 etc The device (machine) configuration file shall include the corresponding include (.inc) file to get machine configuration details. Adding the Machine Configuration File for the new SoC/OEMTo add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file. The most important variables to set in this file are as follows:
You might also need these variables:
Adding a Kernel for the MachineThe OpenEmbedded build system needs to be able to build a kernel for the machine. We need to either create a new kernel recipe for this machine |
...
or extend an existing recipe. We can find several kernel examples in the source The directory at meta/recipes-kernel/linux that you can use as references. If you are creating a new recipe, the following steps need to be done,
If you are extending an existing kernel, it is usually a matter of adding a suitable defconfig file. The file needs to be added into a location similar to defconfig files used for other machines in a given kernel. A possible way to do this is by listing the file in the SRC_URI and adding the machine to the expression in COMPATIBLE_MACHINE:
Adding Recipe for SoC/OEMThe following kind of recipes can be added to SoC/OEM layer. The recipes shall be grouped as described in slide “BSP Reference Layer”
Creating packages for building imagesCreate a custom |
...
package group for the SoC/OEM which shall list all the recipes that are required for this image. For example, the following recipe can be appended to the broadband package group.
Create a custom image for the required SoC/OEM. For example:
Adding your own custom layerUse the yocto-layer create sub-command to create a new layer.
Add this to ./meta-rdk/conf/bblayers.conf.sample. Recipes can be placed inside recipes-< > folders. There can be a configuration file inside conf/ for layer-specific configuration and classes folder for keeping information that is useful to share between metadata files. |
...
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
...
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.
Certification suite is available at RDK IP Set-top Product Certification(only for RDK licensee) and for TDK test app please refer TDK-BV Documentation(only for RDK licensee).
Once the RDK bring-up in SoC is completed, the vendor needs to plan on the delivery of the software to OEM vendors. This usually happens in 2 ways:
In this approach will 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 secure information can be hosted in Artifactory server.
...
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.
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 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
...
image. 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
...
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
...
image. 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.
...
After a successful bring-up of
...
an RDK based image in OEM device, the next step will be to allow
...
operators to work with OEMs to get
...
operator code on that OEM device. RDKM offers collaboration space for
...
OEMs to
...
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/Operator specific code, SoC
...
and OEM artifact storage facility, JIRA & RDK Wiki spaces, integration with
...
test suites, monthly & release tagging, etc.
Please refer
...
...
for more details on facilities available for OEMs and SoCs
...
as part of the collaboration zone. In short, it will include:
Background Color | ||
---|---|---|
| ||
Procedure for OEM porting of RDK |
...
Anchor |
|
...
|
...
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
Refer RDK-B Porting Guide for more details
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.
...
Include Page | ||||
---|---|---|---|---|
|