Versions Compared

Old Version 4

changes.mady.by.user Z-Reshmi K R

Saved on

compared with

New Version 5

changes.mady.by.user Z-Reshmi K R

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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. Device will be categorized as Low Profile and High Profile device based on the hardware capabilities. In a low profile device 4k support might be optional but it is expected to have 4k support in high profile device.

Device Firmware

OEM can make use of the below details to start developing a Yocto build to engineer 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 are 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 needs 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
title Click here to see set of sample manifests for developing OEM specific manifests

#

File

Remarks

1

Device Specific Manifest

This is the starting point of the build and is specific to a device. Usually it contains references to other manifest files which will be having  specific set of repos

6

Third party apps

This manifest can contain meta layers related to Premium streaming applications which are chosen by OEM

5

RDK-V manifest

This manifest can contain meta layers specific to RDK & RDK-V and , for EXTERNALSRC cases, the RDK & RDK-V component repo details too. It might be supplemented with a conf file too

3

OEM manifest

This manifest contains meta layer details of OEM( which might or might not be generic across OEMs multiple devices ) and , optionally, some OEM specific repos

2

SoC manifest

This manifest contains meta layer details of SoC and , optionally, some SoC specific repos

4

OE layers manifest

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 the links RDK-B OEM Specific Porting and Guideline for SoC and OEM Vendors

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.

$ yocto-layer create mylayer

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

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


Expand
title Click here for more details on SoC/OEM meta-layer creation

Adding a new machine to Yocto involves the following:

Create a new layer which will hold all the recipes and machine configurations 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 :               

$  git clone https://github.com/seife/yocto-poky.git 

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>

Eg :

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.

...

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 SoCs to work with OEMs to get a device based on the SoC platform. 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 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 

Procedure for OEM porting of RDK

...

The aim of this document is to explain the procedure for OEM porting of RDK.


draw.io Diagram
bordertrue
diagramNameProcedure for OEM porting of
RDK<image to be added from OEM-video page>
RDK
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth803
revision1

Step 1 : Selection of SoC board with RDK ported on it

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 .

Step 2 : Add OEM components

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 )

Step 3 : Upgrade RDK/SoC components for OEM changes

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

Components of OEM Interface

Bluetooth

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.

  • Bluetooth HAL - Provides APIs to perform Bluetooth operations by abstracting and simplifying the complexities of Bt-Ifce (& BLuez)
  • Bt-Ifce - Abstracts Bluez versions and serves as a HAL for other Bluetooth stacks - Interacts with Bluez over DBus
  • Bluez - Interacts with kernel layer bluetooth modules

Modules

Crash Upload

  • 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

Device Settings

  • OEM implementation includes device specific configuration parameters & customizing data structures for front panel setting and so on

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
  • Provides setup scripts to initialize the default DTCP data to device specific persistent partition

hwselftest

Provides platform specific configuration options for Hardware test. Which will run periodically in background to check attached hardware health.

  • OEM dependency is limited to providing a configuration file hwselftest.conf which defines the hardware interfaces that should be tested e.g. partition name, HDMI, IR, MOCA and so on

LED Manager

LED Manager is used to control the LED patterns during different system events.

  • OEM should implement the template code to ensure that it matches with their LED coloring scheme and other configuration parameters such as brightness level and number of LED types, multi-color or single color LEDs

tenableHDCP

This handles the HDCP service operations such as enable or disable the HDCP.

  • OEM interface includes implementing manufacturer specific calls to read the keys and so on

Wi-Fi

  • OEM specific Wi-Fi driver configuration files and utility library can be added optionally


For details on the Wi-Fi HAL Public APIs and Data Types, please refer: https://wiki.rdkcentral.com/doxygen/rdkv-opensourced/df/dce/group___w_i_f_i___h_a_l.html