RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Page History
| Background Color | ||||||
|---|---|---|---|---|---|---|
| ||||||
Before You BeginAnchor |
|
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
...
the licenses are 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 SoC - Approach Anchor |
|
This section will detail the recommended step by step procedure of adopting RDK by a SoC
Product Specifications
The first step to
...
getting 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. SoC can use this as a guide while engineering the RDK SoC platform.
RDKM On-boarding Anchor RDKM On-
| RDKM On- |
...
boarding RDKM On-boarding
| 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 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.
Roles & Responsibilities
A table explaining the roles & responsibilities of SoC & RDKM in the collaboration zone is given below:
# | Activity | Owner | Remarks |
|---|---|---|---|
1 | RDKM | RDKM will setup Collaboration space, access restrictions | |
2 | SoC | JIRA project. SoC will be the owner |
...
of the JIRA project | |||
3 | SoC/RDKM | RDKM will create the space and SoC push the code changes | |
4 | SoC | Create necessary device specific HAL implementation for porting RDK into Accelerator | |
5 | SoC |
...
Details which SDK version is to be used. RDKM will support the integration with SoC libraries | |||
6 | SoC | Manifest for building the accelerator | |
7 | UI |
...
RDKM/SoC | Comes with pre-integrated UI’s, SoC and RDKM will discuss on the default UI | ||
8 | Create RDK build from CMF GIT | SoC/ RDKM | Both teams work together to build Accelerator from CMF |
9 | Provide Devices to RDKM team | SoC | |
10 | Device flashing instructions/recovery mechanisms | SoC | SoC should share the device flashing instruction |
11 | RDKM/SoC | RDK Certification Suite | |
12 | Monthly release & tagging | SoC | Monthly tagging and release with stakeholders along with test results |
...
| Anchor | ||
|---|---|---|
|
...
|
| Expand | ||
|---|---|---|
| ||
It is expected that SoC has already obtained a license to work with RDKM (If not, SoC 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 | ||
|---|---|---|
| ||
SoC 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 SoC. 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 the 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 |
...
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 |
Product Engineering
Once the product features are decided, the device engineering can be started. SoC needs to decide on the hardware layout that incorporates components to the target board.
...
The device will be categorized
...
either as a home broadband device or a business gateway.
SoC Platform Firmware
SoC can make use of the below details available to start developing a Yocto build to
...
engineering the device firmware builds based on RDK Yocto build setup.
Yocto Manifests
Yocto based RDK builds are flexible enough to easily accommodate SoC / OEM / MSO / third party 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 SoC specific manifests are given below
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
...
|
...
|
...
|
...
|
...
|
...
|
The default manifest repo in RDKM Git is at https://code.rdkcentral.com/r/#/c/manifests/ . SoC can use the 'collaboration'
...
subsection in this repo to add their platform-specific manifests which will be under collaboration zone restrictions. The location will
...
be https://code.rdkcentral.com/r/collaboration/SoC/<platform>/<platform-manifests>
For more details on getting RDK-B ported to
...
a SoC device, please refer
...
RDK porting guide to SoC vendors .
SoC/OEM meta-layer creation
To match the layered structure of Yocto builds, a SoC-specific layer is used to include SoC changes and additions.
...
Use the yocto-layer create sub-command to create a new general layer.
$ yocto-layer create mylayer |
There shall be a separate device (machine) configuration file (.conf) for each device for the particular chip family for which the layer is intended
...
.
...
The general naming terminology for the SoC layer is meta-rdk-SoC-<SoC name>
The device (machine) configuration file shall include the corresponding include (.inc) file to get machine configuration details.
| Expand | ||
|---|---|---|
| ||
Adding |
...
the Machine Configuration File for the new SoC/OEM |
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 code base 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.
...
Please enter the layer priority you'd like to use for the layer: [default: 6] 6
Would you like to have an example recipe created? (y/n) [default: n] n
Would you like to have an example bbappend file created? (y/n) [default: n] n
New layer created in meta-new-layer.
There shall be 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 corresponding include (.inc) file to get machine configuration details.
Adding the Machine Configuration File for the new SoC/OEM
To 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:
- TARGET_ARCH (e.g. "arm")
- PREFERRED_PROVIDER_virtual/kernel (see below)
- MACHINE_FEATURES
You might also need these variables:
- KERNEL_IMAGETYPE (e.g. "zImage")
- IMAGE_FSTYPES (e.g. "tar.gz")
- The default configuration is defined in meta-rdk/conf/distro/rdk.conf and it should be overwritten by the machine specific conf file.
Adding a Kernel for the Machine
The 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, following steps need to be done,
- Setting up a SRC_URI.
- Specify any necessary patches
- Create a configure task that configures the unpacked kernel with a defconfig.
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:
- COMPATIBLE_MACHINE = '(qemux86|qemumips)'
Adding Recipe for SoC/OEM
The following kind of recipes can be added to SoC/OEM layer. The recipes shall be grouped as described in slide “BSP Reference Layer”
- recipes (.bb) to build Kernel
- recipes(.bb) to build SDK
- Kernel patches (SoC/OEM specific - if any)
- SDK patches (SoC/OEM specific - if any)
- Any SoC/OEM specific scripts or files which need to be installed in RF
Creating packages for building images
Create a custom packagegroup 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.
...
meta-rdk-soc-<soc>/meta-<processor_name>/recipes-core/packagegroups/packagegroup-rdk-ccsp-broadband.bbappend:RDEPENDS_packagegroup-rdk-ccsp-broadband_append += " \ ccsp-cr \ rsync \ utopia \ lighttpd \..."
Create a custom image for required SoC/OEM. For example:
...
meta-rdk-<soc>/meta-<processor_name>/recipes-core/images/<image>.bb:IMAGE_INSTALL += " \ packagegroup-<soc/oem specific packages> \ ""
Adding your own custom layer
Use the yocto-layer create sub-command to create a new layer.
...
$ yocto-layer create newlayer
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.
TDK and RDK Certification Suite Package
RDKM offers an in-house Test & certification suite that facilitates SoCs to get their IP Set-top product certified as RDK Compliant device.
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).
SDK Releases
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:
HAL + SDK binary
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.
...
To 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. |
TDK
RDKM offers an in-house Test suite that facilitates SoCs to get their devices tested for their features.
For more details on TDK refer: TDK-B Documentation
SDK Releases
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:
HAL + SDK binary
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.
SoC vendor can define a HAL layer, share the source of HAL & yocto meta layer that can be stored in RDK CMF Git repository (which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor), share the SDK binary that can be stored in RDK Artifactory (which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor) and then publish necessary documentation on how to build the SoC SDK. SoC vendor 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 the SoC 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
In this approach, SoC vendor can define a HAL layer, share the source of HAL, yocto meta layer, and SDK source code that can be stored in RDK CMF Git repository( which will be shared
...
only to authorized OEM vendors who will work in collaboration with the SoC vendor )
...
and then publish necessary documentation on how to build the SoC SDK. SoC
...
vendors can use the git
...
for periodic
...
updates ( for releases ) or for bug fixes. All the source code
...
and documentation will be strictly access restricted and access will be allowed only for authorized personnel by the SoC vendor.
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
In this approach, SoC vendor can define a HAL layer, share the source of HAL , yocto meta layer and SDK source code that can be stored in RDK CMF Git repository( which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor ) and then publish necessary documentation on how to build the SoC SDK. SoC vendor can use the git for periodic update ( for releases ) or for bug fixes. All the source code and documentation will be strictly access restricted and access will be allowed only for authorized personnel by SoC vendor.
For both approaches, the RDKM collaboration zone will be used with strict access restrictions.
Collaboration with OEMs
After a successful bring up of RDK on SoC platform, the next step will be to allow OEMs to work with SoCs to get a device based on the SoC platform. RDKM offers collaboration space for SoCs which would help SoCs to collaborate with OEM and RDK teams (as well as any 3rd party) in their journey to engineer 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 specific code, SoC SDK artifact storage facility, JIRA & RDK Wiki spaces, integration with Test & Certification suites, monthly & release tagging etc.
Please refer RDKM On-boarding for more details on facilities available for SoCs and OEMs as part of 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
RDK porting guide to SoC vendors
The aim of this SoC porting guide is to guide SoC Vendors on how to port RDK to their platforms.
Step 1 : Get a board with Linux and drivers
RDK is based on Yocto Linux. Prior to porting RDK on a SoC , the precondition is to have the SoC platform running on Linux. The Linux version can be a SoC specific one with kernal hardening and other OS optimizations specific to SoC, as RDK could easily run on top of vendor specific Linux. SoC should also provide drivers for the other peripherals in SoC platform, like WiFi, so that the unit can work independently and completely from a SoC point of view.
Step 2 : Move the build to Yocto, compare it to supported Yocto version of RDK
Once SoC vendor is ready with an own port of Linux + drivers for the SoC platform, it is time to migrate the platform to Yocto based builds. If the SoC is already having a Yocto based Linux, this step can be skipped. The current Yocto versions supported are Yocto 3.1- Dunfell ( preferred ) as well as Yocto 2.2- Morty ( soon to be deprecated )
Yocto 3.1 Upgradation support the following:
- Version upgrades for bitbake, GStreamer and other OE components
- Linux kernel 5.4 or above
- Extensible SDK
Each component in RDK is a standalone repository with its own individual build tools producing a library or set of binaries. When OE layers are upgraded to the newer versions, necessary changes need to be made in the RDK Yocto meta layers which use these components, to avoid build failures.
Step 3 : Compare and verify the compiler flags used in RDK and in platform to avoid issues
This is an important step while porting RDK to a new SoC platform. RDK Linux is built with considering particular build flags/features in target platform( For example, RDK considers hardware floating point in platform where as some platforms are on software based floating point ). SoC vendor need to analyze such flags in RDK and then make a comparison with the existing SoC platform Linux to ensure compatibility or to understand the required modifications in RDK code so as to house the compatibility changes
Specific DISTRO_FEATURES can be added to support build time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "
Step 4 : Compare the open source versions used in platform as different versions will cause problems
Depending on the Yocto version, the RDK build will be working with some particular version of Open source components. This might either be a dependency with the Yocto version compatibility as such or with RDK ( functionality or license issues ). If the SoC Linux has some version dependency on particular open source software and, if it conflicts with the version in RDK, vendor needs to make required changes to make the open source version to match the RDK requirements as best as possible, by adding required patches in SoC platform
Check below layers for all opensourced version packages recipes used in RDK. If multiple recipes with different versions are available, then check for the value of PREFFERED_VERSION_<recipe name> set.
Meta layers : - meta-openembedded, openembedded-core, meta-rdk-ext, meta-rdk, meta-cmf
Step 5 : Move the RDK recipes to platform Yocto build
For platform specific recipes, keep them in SoC meta layer. While it is a good practice to start afresh with a new manifest for the target platform, manifest file for a similar featured platform can be used as a starting point too. Check all device specific repos in the reference manifest, and ensure corresponding device repos are created for this new device as needed, and update the manifest with these updated repos
- Create artifactory repo for the project with appropriate permissions for vendors. This is used for hosting any binaries required for the project
- Check-in SoC components - tool chain, SDK, kernel, drivers, etc.. to corresponding SoC gerrit repos/ artifactory as applicable
- Populate meta SoC layer with initial set of changes needed to build kernel, SoC components, etc..
- If there is any SoC reference board exists, create corresponding machine configuration in SoC layer, and create an image target to be able to build final image for the reference board. This layer should be separated out with in meta SoC layer from other common SoC, common chip sub layers which will be usually used by meta OEM layer as well.
- Populate meta OEM layer with machine configuration and other bare minimum changes required to generate a target image for OEM board.
- Machine configuration can be updated with "NEEDED_BSPLAYERS" field to include required SoC, OEM layers in the build
- Any unwanted recipes during early stage of bring up can be masked using BBMASK, if needed.
Step 6 : Get a successful build
Add platform specific main recipe to create image.
Refer RDK-B Porting Guide for more details
HAL implementation by SoC
Hardware Abstraction Layer (HAL)
Device Settings
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.
DTCP
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
tr69hostif
Contains SoC specific MOCA libraries, headers and MOCA profile codes.
API Details: TR69 Host Interface Handler
For more details on tr69hostif, please refer: tr69hostif
gst-plugins-rdk /qamtunersrc
qamtunersrc is a push based gstreamer source plugin which tunes to the given service and provides the SPTS data.
- Manages tuner and demux
- Filters PIDs required for SPTS
- Output SPTS as gstreamer buffer
Properties
- Modulation:
- Frequency: frequency to tune in KHZ
- Tunerid: Tuner Handle
Depends on platform specific libraries for tune, filtering, and pod functionalities.
gst-plugins-SoC /playersinkbin
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.
hdmicec
SDK Vendors should implement CEC driver interface API as specified in hdmi_cec_driver.h
HAL Interface Specificcation: HDMI-CEC HAL APIs specification
iarmmgrs
Power, IR and DeepSleep modules are having SoC dependency. APIs are specified in plat_power.h, plat_ir.h and deepSleepMgr.h
More details about APIs can be found here
westeros-SoC
Contains functions for creating and handling native eglwindow. HAL APIs are specified in westeros-gl.h
Wi-Fi (Client)
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 APIs are specified in wifi_client_hal.h. Doxygen Link: Wifi HAL API Specification
Provisioning - iCrypto
Set of Cryptographic APIs Implementation, can be used to achieve all type of Cryptographic requirements from Premium App.
Graphics - westeros backend
Media Pipeline Backend layer is a module in device layer which glues the media pipeline capabilities of the device to that of the IgnitionX.
Input key handling
As part of integrating Premium Apps as a native application on the RDK stack, the Premium Apps Video Porting (PVP) Layer needs to be implemented. The PVP Layer consists of the following modules:
- Ignition Device Layer
- Common
- Display
- Input
- TTS
- Secure Storage
- Message Bus
- Device Properties Provider
- Media Pipeline Backend
- PlayReady DRM
Media Playback - gstreamer
Abstraction layer for third-party applications to get specific GStreamer values from the SoC pipeline.
DRM (playready, widevine, TEE, SVP etc.)
Amazon assets are encrypted using Microsoft PlayReady. A robust implementation of the PlayReady must be provided for porting kit to decrypt assets.
TTS
Text-to-speech converts text into spoken voice output to help customers navigate the Prime Video application without seeing the screen. Text-to-speech is mandatory for the US region and optional in other regions.
Closed Caption
ccReader module which does the closed caption decoding is having HAL dependency. APIs are specified in ccDataReader.h
More details on HAL interface can be found here: closed Caption HAL APIs
DirectFB
Graphics library porting for SoC.
For more details on DirectFB, please refer: DirectFB
DVRManager
AES Encryption and decryption of packets handled from DVRManager SoC Layer.
Mediaframework
Porting of mediaframework involves porting of the following sub-modules:
- halcdl
- haldsg
- halpod
- halsnmp
- halmfr
- halplatform
Details about HAL APIs that require porting is published as part of Doxygen Documentation activity in Mediaframework HAL API Specification.
ServiceManager
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.
For more details on ServiceManager, please refer: ServiceManager
wpeframework/OCDMi
...
For both approaches, the RDKM collaboration zone will be used with strict access restrictions.
Collaboration with OEMs
After a successful bring-up of RDK on the SoC platform, the next step will be to allow OEMs to work with SoCs to get a device based on the SoC platform. RDKM offers collaboration space for SoCs which would help SoCs to collaborate with OEM and RDK teams (as well as any 3rd party) in their journey to engineering 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 specific code, SoC SDK 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 SoCs and OEMs 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
| Background Color | ||||||
|---|---|---|---|---|---|---|
| ||||||
RDK porting guide to SoC vendorsAnchor |
|
| Include Page | ||||
|---|---|---|---|---|
|
Overview
Community Forums
Content Tools
Tasks