RDK Resources
RDK Preferred
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Papers & Presentations Archive
.
Key Components available in the THUNDER Framework -
Thunder is a small framework built for embedded devices. It consists out of the following main components -
Thunder and RDK Services are key components for micro services to bring into any Box. Thunder offers an event driven interface framework for subsystem availability signaling to the plugins. This framework is utilized to realize concurrent startup scenario using a conditional evaluation only in case a condition changes. This allows for startup without requiring sleeps, or resource consuming polling mechanisms.
For each micro service, we need to implement one plugin as part of RDK Services, and Nano or microservices should configured as part of any of these subsystems.
Designed for Apps:
Goal is to enable/bridge embedded low level C/C++ technology to the Javascript world and it is done by using Javascript enabler.
Application framework is built on Hardware abstraction Layer, on top of abstraction layer there is a WPE Framework. WPE framework itself dispatched internally that actually starts micro and nano services. Micro and Nano services are exposed to certain interfaces so at the end the system can locked down and executing.
From Apps, there are external input interface that can send in JSONRPC messages, JSONRPC messages through dispatcher will be routed to proper micro/nano services.
Modular architecture
Separation of concern
Interface based
Agnostic to process boundaries (JSONRPC/COMRPC)
Integral implementation of security features
Small footprint, low resource usage
Uniformity
WebControl
Scoped Traceability (controlled from Web)
Execution architecture (resource constrained)
Ease of use when building a plugin
No hard-linked dependencies
Most important part of framework is to make sure we can run processes & separate process, we can run nano/micro services out of process. So, we need to communicate to nano/micro services throughout API's.
These API's are actually incremented in 2 ways.
COMRPC is a binary RPC migration
C header files with a struct definition and pure abstract methods
QueryInterface/AddRef/Release
COMRPC migration is part of WPEFramework. If we have COMRPC 'C' migration, the communication layer below are main sockets for TCP Server. It means we could communicate with any interface to other host.
JSONRPC is to communicate JSON object messages.
JSON data objects, boiler plated handlers and documentation are generated from a JSON specification file!!
Actual exchange data in JSON format : RFC4627
For deeper and detailed information of JSONRPC ,Please refer https://www.jsonrpc.org/specification
This gives us information regarding once system is ready ,what kind of micro/nano services are all available.
Difference between micro and nano is that micro service actually requires graphics -graphical resources or player resources.
Webinar : RDK 4.0 Native App
The RDK‐V standardized stack provides a common method to manage complex video and management functions such as rendering, content, content security, device management, networking, & peripherals.
The RDK‐V Feature List is categorized by the below functions, Enhancements and new features are developed and contributed asynchronously by members of the RDK Community.
A preview of proposed features for RDK6 may be found here
Category | Feature | Description | Dependency (If any) |
Conditional Access | Conditional Access | CommScope CableCard Decrypt, PPV Ready | Device Dependency |
---|---|---|---|
Technicolor CableCard Decrypt, PPV Ready | Device Dependency | ||
Containerization of key processes in support of European CA requirements (D-BUS, RMF, container for remaining processes) | |||
CI++ | Device Dependency/Region dependency | ||
DRM | PlayReady 2.5 with RDK Security API integration | ||
CDMi with PlayReady 2.5 integration EME v1 | |||
CDMi with Widevine v14 integration | |||
DTCP | DTCP integration | ||
Secure Connections | Remove all lower TLS fallbacks for connections to Xconf/DCM | ||
Device Security | Input sanitization of htmldiag cgi-bin scripts | ||
Upgrade to OpenSSL1.0.2o (Yocto Platforms) | |||
Upgrade to NTP 4.2.8.p11 | Device Dependency | ||
Disable USB Input HID Device | Device Dependency | ||
Run applications in a secure container | |||
Secure bootloader | |||
Content Related | Adaptive Bit Rate | HLS (HLS v3 and HLS v4) | |
MPEG-DASH (gstreamer plug-in) | |||
HTLM-5 Video (MSE/ESE) | |||
MPEG-DASH (Native) | |||
Audio Input Formats | MPEG, MP3, AAC, LPCM, AC3 | ||
Audio Output Formats | Stereo | ||
Dolby Digital | |||
Dolby ATMOS | |||
Dolby Digital Plus (7.1 Channels) | |||
Split HDMI and SPDIF audio outputs | |||
Bit stream Pass-through | |||
Dolby MS12 | Device Dependency | ||
Audio Tracks | SAP, DVS | ||
Codecs | MPEG2, H.264, VP8 | ||
High Efficiency Video Coding (HEVC) (H.265/MPEG-H Part 10) | |||
HDR 10 Bit (HEVC HLS) for IP settop | Device Dependency | ||
HDR 10 4K IP VOD | Device Dependency | ||
Delivery | Broadcast, Video on Demand | ||
Switched Digital Video | |||
Video over Wi-Fi (XG->Xi, XG->XB/XW->Xi, XB->IP) Ready | Device Dependency | ||
IP Multiroom Music Playback (STB to Speakers) | |||
DVB | Broadcast DVB-C support | ||
Teletext, Subtitles | |||
In-Band System Information | |||
EAS | QAM EAS, IP EAS | ||
Song Identification | Create Audio Tracks for song recognition services | ||
UHD/4K | Service Manager APIs for 4K and HDR capability information across devices | Device Dependency | |
Content Delivery | Video Input Formats | MPEG2, H.264, VP8 | |
Video Output Resolutions | 480i, 480p, 720p, 1080i, 1080p | ||
Ultra HD/4K, Advanced High Dynamic Range (HDR) | Device Dependency | ||
Dolby Vision Advanced HDR for VOD | Device Dependency | ||
Video Over WiFi | Refactor UPnP on Xi to be compatible with XB | ||
VOD | QAM VOD, IP VOD | ||
Ad Insertion | Ad Insertion | Client Side Ad Insertion (Linear Segmented Advertisement) | |
RFC Control of LSA – “Programmer Enablement” | Cloud Dependency | ||
Reassemble segmented SCTE-35 splice information | |||
Ad Insertion – Linear Segmented Advertising | LSA support for back-to-back ads | Cloud Dependency | |
LSA support for back-to-back ads | |||
IP DAI | Handle DASH IP VOD Dynamic Ad Insertion (DAI) Transitions | Cloud Dependency | |
Handle DASH IP VOD Dynamic Ad Insertion (DAI) Hangnail Fragments | Cloud Dependency | ||
Rendering | Advertising Impressions/ Ad Watermarking | Monitor primary tuner for ETV Ad Data, report upstream | Cloud Dependency |
APIs | Service Manager | ||
App Framework | AAMP / RDK MediaPlayer integration on Raspberry Pi | ||
AAMP Buffer health monitoring | |||
Sound Playback for Spark + Native Apps | |||
Firebolt ® SDK download from USB | |||
Optimus Prime application manager | |||
Firebolt ® on Raspberry Pi | |||
Browser Engine | QT WebKit 5.1.1 | ||
WebKit Pure Embedded integration | |||
Connection Security | SSL/TLS | ||
Graphics | DirectFB, OpenGL ES | ||
Plugins | WebRTC | ||
Rendering | QT 5.1.1 | ||
Westeros Wayland Based Compositor | |||
WPE WebKit | WPE on Raspberry Pi | ||
Device Management | App Launch Optimization | Migrate from system-journald to syslog-ng for improved performance (~10% reduction in CPU load) | |
Bluetooth Audio | Optimize Bluetooth Discovery & Pairing | ||
Build | Yocto 2.2 Morty on Raspberry Pi Reference Platform | ||
Download | TFTP (CDL), HTTP | ||
Download Enhancements (% download, Log timestamps) | |||
Feature Control | Securing RFC parameters via encryption | ||
Firmware Download Enhancements | Omit IP Address From Xconf Firmware Download Request | ||
Image Compression | Brotli Firmware Image Compression | ||
Implementation | Converge RDK Video and RDK Broadband Messaging Bus | ||
Initialization & Resets | Remote Reboot, Warehouse Reset, Factory Reset | Cloud Dependency | |
Detect & log absence of RF signal within 30s of boot (Thermo) | |||
Boot Time Optimization (Phase 1) –Approx 5% reduction in Boot Time | |||
Boot Time Optimization (Phase 2) – 20% reduction in Boot Time | |||
Kernel | Linux 4.14 on Raspberry Pi Reference Platform | ||
Local Diagnostics | HTML Diagnostics | ||
Tuner Reservation Diagnostics | |||
Front Panel LED | |||
Logging | TFTP Log Upload, HTTP Log Upload | Cloud Dependency | |
Distribute (smear) logging uploads (dependent on XCONF Server) | Cloud Dependency | ||
Memory Optimization | Use Flash/SD Card for Firmware Download Temporary Storage (CDL scratchpad) | Device Dependency | |
MoCa 2.0 | Supports MoCa 2.0 diagnostics | Device Dependency | |
Platform Enhancements | Common WiFi HAL for RDK Video | Device Dependency | |
Converge to GCC V6.4 for all Yocto versions | Device Dependency | ||
Uniform flash mounting services for Video devices | |||
Power | Standby, Light Sleep | ||
Deep Sleep on IP Clients | Device Dependency | ||
Power Save | Supports ability to enable HDMI port while in standby mode | ||
Remote Management | SNMP, TR-069, TR-135 | Cloud Dependency | |
SNMP v3 | |||
SNMP Security Hardening | |||
WebPA (IP Clients) | |||
WebPA (QAM Clients) | |||
ssh (secure shell into the device)/ reverse ssh (send trigger to have device initiate ssh) | |||
Feature Control (Remotely enable/ disable individual features on devices without new code deployment) | Cloud Dependency | ||
Resource Optimization | Improved handling of app termination/suspension conditions (based on available memory rather than concurrency) | ||
Revenant | Persistent WiFi Enable/Disable | ||
Security | Intrusion Detection | ||
Self Healing | Supports hardware self test | Device Dependency | |
Thermal Monitoring and Shutdown | |||
Self Test | Self Test App | Device Dependency | |
Hardware Self Test via WebPA | Device Dependency | ||
Telemetry | TR-181 Object Telemetry | Cloud Dependency | |
IP Video Telemetry | |||
Tools | DOCSIS Spectrum Analyzer | ||
WiFi Band & AP Steering | Configurable WiFi Roaming Settings | ||
Dual Band WiFi | |||
Networking | DLNA | VidiPath (DNLA CVP-2) | |
DSG | DOCSIS ready | ||
IP Direct | IP Direct support on DOCSIS devices | ||
LAN IP | Auto IP, DHCP, Dual Virtual | ||
MOCA | MOCA 2.0 support on the home network | Device Dependency | |
WAN IP | eCM IPv4/IPv6, eSTB IPv4 | ||
IPv6 for IP clients | |||
Wi-Fi | Onboard/Recovery SSID (Lost+Found) Ready | Device Dependency | |
WPA Enterprise (IP settop to use Wi-Fi 802.1x authentication) Ready | Device Dependency | ||
Ports/Peripherals | Audio Output Ports | HDMI, SPDIF, Composite Ready | Device Dependency |
Bluetooth Audio Output Ready | Device Dependency | ||
HDMI | HDMI Out, HDCP Enforcement, HDMI In | ||
HDMI Consumer Electronics Control (HDMI-CEC) Power Sync | |||
HDMI Switching (Combine CEC and HDMI Input features to enable advanced switching) | |||
USB | WebRTC Camera Ready | Device Dependency | |
USB Port Detection and Control Ready | Device Dependency | ||
USB Camera Support Ready | Device Dependency | ||
WebRTC HW acceleration for encode/decode to enhance performance | |||
USB Filesystem Support | |||
USB Hot-plug | |||
User Input | IR Remote | ||
BLE Remote | |||
RF Remote with Automatic Pairing to Settop Ready | Device Dependency | ||
Voice Remote (RF4CE based) Ready | Device and Cloud Dependency | ||
Video Output Ports | HDMI, Component, Composite | ||
Video Input ports | HDMI, Component, Composite | ||
Apps | Premium Apps | Netflix, Youtube, Amazon Prime | |
Lightning/HTML Apps | |||
Appstore | |||
TV Settings | Power, Standby | ||
LED | |||
Zoom, aspect ratio | |||
AQ/PQ | QoS | ||
Firmware Upgrade | |||
Casting | Application Casting & control | DIAL | |
Chromecast | |||
Airplay | |||
Matter | |||
Miracast | |||
Gaming | Epic Game Mode | ||
HDMI-CEC DAL - Dynamic Auto Lipsync | |||
Low Latency Game Mode for HDMI Input | |||
Game Mode, Auto Low Latency Mode | |||
AQ/PQ | |||
Voice support | Voice enabled Bluetooth remote | ||
Alexa | |||
Google Voice |
Join RDK
Here we describe how community members and developers can access RDK source code and join the RDK membership programs.
To sign the RDK License to gain access to build recipes and manifest for RDK profiles click here.
RDK is an open source code project distributed through industry standard open source licenses e.g. Apache 2.0. The RDK source code can be accessed from the RDK Code Management Facility at RDK Central Gerrit. Read only access is also available at the RDK GitHub mirror. RDK documentation is open and available to all at the RDK Central Wiki. RDK Wiki also hosts open-to-all community forums to discuss anything RDK.
While most of the RDK components are available as described above, a handful of components are distributed under the free RDK License Agreement.
To obtain the RDK License Agreement, please complete the application at https://rdkcentral.com/licenses/. Upon full execution of the agreement, you will be provided access to the RDK source code components. Please contact RDK Management at info@rdkcentral.com in case you need more information.
The Preferred Program was developed in response to requests from community members for enhanced support & collaboration. Membership provides access to advanced tools, expert technical guidance, training, advanced documentation, avenues for collaboration and invites to the RDK member conferences. Preferred members collaborate closely within the RDK eco-system on evolving RDK technology.
The Preffered Program is modeled on leading open source project membership programs. To join, please submit the completed membership agreement. Please check https://rdkcentral.com/join/memberships/ for additional information. You may also email membership@rdkcentral.com to join or get more detailed information.
The Preferred Plus Program is an exciting new way for RDK Preferred members to get additional exposure for their participation in RDK. It acts as an advertising platform to drive awareness of their products, services, skills and knowledge using RDK Management Media. The membership page on RDK Central outlines more information on the RDK Preferred Plus Program at https://rdkcentral.com/join/memberships/.
The RDK emulator is an x86 based implementation of the RDK software stack that runs on desktop computers. For more details, please follow below link.
RDK port for Raspberry Pi makes the RDK software stack available on a popular hardware device. For more details, please follow below link
Deployment ready Product Branch has been created for RDK components that the community will push changes to review & It is with higher standards of test qualification
Component owners/reviewers/approvers, defined as specific groups in Gerrit, will be added to the review by default. You may request additional feedback by specifically adding reviewers via the Gerrit web GUI.
Product branch is a deployment ready branch is created for RDK components that the community will push changes to review.
Refer to Product Branch for the Components hosted in CMF Gerrit (https://code.rdkcentral.com)
Refer to RDK Central GitHub Components & its Branches hosted in https://github.com/rdkcentral/
Monthly Sprint Branch (rdk-dev-yymm) is a new CMF integration branch, created monthly and baseline off Product Branch. This branch will be hosted per repository in conjunction with Product branch with the goal of incorporating community changes at the earliest juncture.
Once community changes is approved, will be cherry-picked to Monthly Sprint branch (rdk-dev-yymm) and will thus be available prior to the completion of down-streaming to Regression Branch / round-trip process.
Regression branch is the branch used for validation of the contributions. Approved contributions will be down-streamed to Regression Branch for pre-deployment validation using their test process.
Down streamed Community changes, successfully merged to Regression branch, after pre-deployment test validation, the code changes will be cherry-picked to Product Branch.
Code Submission Process - RDK Central Gerrit
Code Submission Process - RDK Central GitHub
On a periodic basis, RDK code is tested and released to the community as CMF releases. This will be generic RDK code without dependency to any platform. CMF code can be built for emulator or raspberry-pi or can be ported to a specific platform (RDK Porting).
While working with CMF stack, one might find ways to enhance RDK code by adding new features or bug fixes as RDK contribution. The general CMF contribution workflow is as follows:
Detailed information on contributing code changes to RDK can be found here: Code Management Documentation
Support tickets can be raised to get request support from RDK Community Support team. This can be for the bugs you faced, doubts you have or any code contributions which you think might enhance RDK.
RDK Support ticket can be raised here: https://jira.rdkcentral.com/jira
Categories of support tickets are:
Issue type | Name | Description |
---|---|---|
General Support Issues | RDK_JIRA_<Company_Name> | Raise a JIRA ticket in your Company Specific Project. This project is accessible only to Preferred member companies. |
Code Management Facility Support | RDKCMF | Code contributions to CMF as part of bug fixing or feature enhancement comes under this category. Updating of code from RDK to CMF is also tracked in these. |
RDK Support | RDK | Anybody with RDK Support credentials can create this category of tickets. |
Raspberry-pi (HDP) Support | RPI | Rapsberry-pi support tickets (only for Preferred members) |
Default | RDK_JIRA_TRIAGE | By default, support type will be RDK_JIRA_TRIAGE. All normal users without RDK support credentials can create these JIRA tickets via mailing to support@rdkcentral.com. This will be filtered to appropriate category by triage team. |
Here all the data is streamed from the media streamer through Home networking sink. HNSrc in the Client will receive the data from HNSink and playback using the RMF pipeline.
The Block diagram for the live streaming is as follows:
The Yocto Project is an open source collaboration project that provides templates, tools and methods to help create custom Linux-based systems for embedded products. It is an open source project initiated by the Linux Foundation in 2010. The Yocto Project uses the OpenEmbedded build system to construct complete Linux images.
The core components of the Yocto Project are:
BitBake is the task executor and scheduler used by the OpenEmbedded build system to build images. BitBake is a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex inter-task dependency constraints. BitBake stores the output of each task in a directory, the shared state cache. Its location is controlled by the SSTATE_DIR variable. This cache is use to speed up compilation.
Bitbake executes all the layers starting with a prefix ‘meta’.
The build/ directory
Meta-layer contains configuration, recipes, classes, patches.
Bitbake parses the build classes, config files, and recipes. For every task, a shell script on-the-fly is created and executed.
Recipes are essentially a set of instructions for building packages. A recipe describes where you get source code and which patches to apply. Recipes describe dependencies for libraries or for other recipes, and they also contain configuration and compilation options. Recipes contain the logical unit of execution, the software to build, the images to build, and use the .bb file extension.
The recipes are parsed by the BitBake build engine. The format of a recipe file name is <package-name>_<version>.bb
A recipe contains configuration variables: name, license, dependencies, path to retrieve the source code etc. It also contains functions that can be run (fetch, configure, compile. . .), called tasks.
Recipe provides:
Files that append build information to a recipe file. Append files are known as BitBake append files and .bbappend files. The OpenEmbedded build system expects every append file to have a corresponding recipe (.bb) file. Furthermore, the append file and corresponding recipe file must use the same root filename. The filenames can differ only in the file type suffix used (e.g. formfactor_0.0.bb and formfactor_0.0.bbappend).
Information in append files overrides the information in the similarly-named recipe file.
Patches can be applied to recipe files. Patch files should be having extension *.patch. Place the patch file in subdirectory of recipe named (component) folder. The subdirectory should be preferably named as that of component or as ‘files’. Add the below line to the recipe file
SRC_URI += file://filename.patch
By default, the OpenEmbedded build system uses the Build Directory when building source code. The build process involves fetching the source files, unpacking them, and then patching them if necessary before the build takes place.
Yocto place individual components at discrete locations for the build purpose. For example; consider emulator build
../../< Project Folder> /build-qemux86mc/tmp/work/i586-rdk-linux/iarmbus
../../<Project Folder> /build-qemux86mc/tmp/work/qemux86mc-rdk-linux/devicesettings
It will be difficult for a developer to do a code walk through since the entire source code is spread across multiple directories. You might want to build software from source files that are external to and thus outside of the OpenEmbedded build system.For example
../../<Project Folder> /generic
You want the recipe's SRC_URI variable to point to the external directory and use it as is, not copy it. Yocto provides a solution to this by its external SRC support. By this all the components will be pulled to a single place. Say, you are component owner and only focused to modify source code of that component and build it alone. Modify the files under ../../<Project Folder> /generic/iarmbus (as an example; you can modify any component like this)
bitbake iarmbus (as an example; you can build any component like this)
To build from software that comes from an external source, all you need to do is inherit the externalsrc class and then set the EXTERNALSRC variable to point to your external source code.
The statements to put in your local.conf file are illustrated below:
INHERIT += "externalsrc" EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
By default, externalsrc.bbclass builds the source code in a directory separate from the external source directory as specified by EXTERNALSRC. If you need to have the source built in the same directory in which it resides, or some other nominated directory, you can set EXTERNALSRC_BUILD to point to that directory:
EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
To know the components building from external SRC, see the content of the file ../../< Project Folder> /build-qemux86mc/conf/auto.conf (In case of emulator)
https://www.yoctoproject.org/
http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html
https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
http://www.yoctoproject.org/docs/1.3.2/poky-ref-manual/poky-ref-manual.html
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html
http://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.youtube.com/watch?v=n6juaOiKJSw
The below diagram shows the Yocto layer structure designed to build RDK stack. Layer definition is present in build/conf/bblayers.conf
MSO specific recipes and configuration to be placed in
OEM specific recipes and configuration to be placed in
SoC specific recipes and configuration to be placed in
The generic yocto layers are needed along with the BSP layer for the build. They are:
meta-rdk:
meta-cmf:
meta-rdk-bsp-emulator:
meta-cmf-bsp-emulator:
Contents of SoC layer shall be
Same SoC layer can be integrated with different OEM layers
Contents of OEM layer shall be
Separate layers must be available for an OEM, if different SoCs are used
"meta-rdk-oem-OEM-X-SOC-Y","meta-rdk-oem-OEM-X-SOC-Z“, etc.
Yocto build Image target names roughly look like <RDK vendor>-<profile>-<build-type>-<developer>-image
This section is intended to help SoC/ OEM vendors to integrate RDK's Yocto framework to their platform.
A basic description about SoC and OEM layers can be found here: Yocto layers
All the work needs be done only in the meta-rdk-oem layer
Write a recipe <oem>-image-tools-native.bb under recipes-tools to copy all the tools, binaries and scripts needed to create custom oem image to the staging binary directory
Adding a new machine to the Yocto Project is a straightforward process which involves following steps:
Use the yocto-layer create sub-command to create a new general 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
The device (machine) configuration file shall include corresponding include (.inc) file to get machine configuration details.
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:
The default configuration are defined in meta-rdk/conf/distro/rdk.conf and it should be overwritten by the machine specific conf file.
For example, meta-rdk-oem-<>/meta-<>/conf/machine/include/<>.inc
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. There are several kernel examples in the Source Directory at meta/recipes-kernel/linux that can be used as references.
If you are creating a new recipe, 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:
The following kind of recipes can be added to SoC/OEM layer. The recipes shall be grouped as described in slide “BSP Reference Layer”
Bitbake executes all the layers starting with a prefix ‘meta’. It parses the build classes, configuration files, and recipes and executes each task by creating a shell script on-the-fly.
TASK | DESCRIPTION | FUNCTION |
Build | Default task for a recipe - depends on all other normal tasks required to 'build' a recipe | do_build |
Init RAMFS | Combines an initial ramdisk image and kernel together to form a single image | do_bundle_initramfs |
Check URI | Validates the SRC_URI value | do_checkuri |
Clean | Removes all output files for a target | do_clean |
Clean all | Removes all output files, shared state cache, and downloaded source files for a target | do_cleanall |
Clean SSTATE | Removes all output files and shared state cache for a target | do_cleansstate |
Compile | Compiles the source in the compilation directory | do_compile |
Configure | Configures the source by enabling and disabling any build-time and configuration options for the software being built | do_configure |
Dev Shell | Starts a shell with the environment set up for development/debugging | do_devshell |
Fetch | Fetches the source code | do_fetch |
Install | Copies files from the compilation directory to a holding area | do_install |
List Tasks | Lists all defined tasks for a target | do_listtasks |
Package | Analyzes the content of the holding area and splits it into subsets based on available packages and files | do_package |
Package QA | Runs QA checks on packaged files | do_package_qa |
Write IPK | Creates the actual IPK packages and places them in the Package Feed area | do_package_write_ipk |
Patch | Locates patch files and applies them to the source code | do_patch |
Populate License | Writes license information for the recipe that is collected later when the image is constructed | do_populate_lic |
Populate SDK | Creates the file and directory structure for an installable SDK | do_populate_sdk |
Populate SYSROOT | Copies a subset of files installed by do_install into the sysroot in order to make them available to other recipes | do_populate_sysroot |
Root FS | Creates the root filesystem (file and directory structure) for an image | do_rootfs |
Unpack | Unpacks the source code into a working directory | do_unpack |
Configuration
Configuration (*.conf) comprises of global definition of variables. There are two types of configurations:
BSPs are layers that add machine settings and recipes. It contains extensions and customizations to base system. They are added to the BBLAYERS variable in build/conf/bblayers.conf
Machine settings are specified in a layer's conf/machine/xxx.conffile(s)
For Example:
../meta-rdk-bsp-emulator/conf/machine/qemux86hyb.conf
For Device:
../meta-rdk-oem-<OEM Name>-<SoCName>/conf/machine/<configuration_file_name>.conf
Recipes are the most basic metadata files which are denoted by the file extension*.bb. Recipes can build one or more packages from source code.
They provide:
Append files are identified by the extension *.bbappend. They are used to extend or override information in an existing recipe file. BitBake expects every append file to have a corresponding recipe (*.bb) file. A missing .bb file will be shown as an warning by the BitBake parser. The append file and corresponding recipe file must use the same root filename.
Example: devicesettings_git.bb & devicesettings_git.bbappend
These are set automatically by bitbake.
Build time package variables
Runtime package variables
Variables you commonly set
Patches can be applied to recipe files. Patch files extension *.patch. Place the patch file in subdirectory of recipe named (component) folder. The subdirectory should be preferably named as that of component or as ‘files’. Add the below line to the recipe file
SRC_URI += "file://temp.patch"
More information on patches can be found here
SSTATE ( shared state ) is the way OE speeds up builds. A much detailed conceptual description please read http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache
OE/Yocto has a feature called SSTATE(shared state) to deliver prebuilts amongst users. Shared state is currently configured with OE/Yocto projects.
This page provides the details and guidance to the SoC Vendors on how to adopt RDK. The porting procedure and the procedures for SoC to get an RDK based Platform up and running is also described in detail.
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 a SoC
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-V and can implement based on your requirement. SoC can use this as a guide while engineering the RDK SoC platform.
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 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 for 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 | Which SDK version to be used. RDKM will support the integration with SoC libraries | |
6 | SoC | Manifest for building the accelerator | |
7 | UI/UX(only for RDK licensee) | 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 |
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:
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
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
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
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
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. SoC needs to decide on the hardware layout that incorporates components to the target 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.
Reference Flash Layout |
---|
flash0.macadr EMMC flash Data : 1024B flash0.nvram EMMC flash Data : 64KB flash0.recovery EMMC flash Data : 256MB flash0.vendor EMMC flash Data : 128MB flash0.kernel_a EMMC flash Data : 128MB flash0.kernel_b EMMC flash Data : 128MB flash0.rootfs_a EMMC flash Data : 1024MB flash0.rootfs_b EMMC flash Data : 1024MB flash0.rootdata EMMC flash Data : 2048MB flash0.rsvd EMMC flash Data : 10174MB |
SoC can make use of the below details available 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 / MSO / third party 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 SoC specific manifests are given below
# | File | Remarks |
---|---|---|
1 | This is the starting point of the build and is specific to a device/board . If the SoC has only one target device /board, still it is recommended to maintain a different manifest for SoC for keeping it future-proof. Usually it contains references to other manifest files which will be having specific set of repos | |
2 | This manifest contains meta layer details of SoC and , optionally, some SoC specific repos | |
3 | This manifest has details of the basic Yocto Open Embedded layers | |
4 | 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 | |
5 | Third Party Apps manifest | This manifest can contain meta layers related to Premium streaming applications which are chosen by SoC |
The default manifest repo in RDKM Git is at https://code.rdkcentral.com/r/#/c/manifests/ . SoC can use the 'collaboration' sub section 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>
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 separate device (machine) configuration file (.conf) for each device for the particular chip family for which the layer is intended for. The general naming terminology for SoC layer is meta-rdk-SoC-<SoC name>
The device (machine) configuration file shall include corresponding include (.inc) file to get machine configuration details.
Each meta-* layer should have a conf folder containing the machine configuration we can select during 'source setup-environment' . Optionally it can also have a class/classes folder for keeping information that is useful to share between metadata files.
To add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file. In the machine conf file the basic machine configuration should be defined.
SoC can have several meta-rdk-<chip-set> layers containing chip specific implementation.
Generally conf file name will be SoC name. If both OEM and SoC are present then machine configuration should be coming from master i.e. OEM . It means whatever image that gets created comes from meta-rdk-oem
The most important variables to set in this file are as follows :
MACHINEOVERRIDES=" "
For SoC, The most important variables to set in this conf file are as follows :
TARGET_ARCH (e.g. "arm") PREFERRED_PROVIDER_virtual/kernel (Eg:"linux-<chip set name>") MACHINE_FEATURES (e.g. "apm screen wifi") KERNEL_IMAGETYPE (e.g. "uImage") IMAGE_FSTYPES (e.g. "tar.gz ext4")
Standard meta-rdk/recipe-core/images will have different kinds of images which one can use and build.
This recipe-core/images will have bbappend or main image name. If meta-rdk is used( i.e. meta-rdk image ) then bbappend of that image client is required
For example,
<image name>.bbappend
Define "bbappend of images" and "conf file" as required.
Generally SoC meta-layer (Eg: meta-<SoC name>) will have following recipes
SoC meta layer recipes- ========================================= recipes-bsp recipes-core recipes-kernel recipes-connectivity recipes-graphics recipes-support etc The structure of meta-<SoC name>/recipes-support/<SoC-img-packer>/ is as follows - ========================================= $ls <SoC-img-packer-native>.bb files
RDKM offers an in-house Test & certification suite that facilitates SoCs to get their IP Set-top 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.
Certification suite is available at RDK IP Set-top Product Certification(only for RDK licensee) and for TDK test app please refer TDK-V 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. SoC secure information like secure components such as PlayReady, widevine and Dolby libraries etc. can be hosted in Artifactory 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 updated (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 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
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 updated ( 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.
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:
The aim of this SoC porting guide is to guide SoC Vendors on how to port RDK to their platforms.
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.
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.
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 "
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
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 a 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.
Add platform specific main recipe to create image.
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
For more details on tr69hostif, please refer: tr69hostif
qamtunersrc is a push based gstreamer source plugin which tunes to the given service and provides the SPTS data.
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 APIs specification
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
Contains functions for creating and handling native eglwindow. HAL APIs 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 APIs are specified in wifi_client_hal.h. Doxygen Link: Wifi HAL API Specification
Set of Cryptographic APIs Implementation, can be used to achieve all type of Cryptographic requirements from Premium App.
Media Pipeline Backend layer is a module in device layer which glues the media pipeline capabilities of the device to that of the IgnitionX.
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:
Abstraction layer for third-party applications to get specific GStreamer values from the SoC pipeline.
Amazon assets are encrypted using Microsoft PlayReady. A robust implementation of the PlayReady must be provided for porting kit to decrypt assets.
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.
This page provides the step by step procedures for OEMs to adopt RDK. OEM layer sits on top of SoC layer and later adds support for software for boot-up, image updates, and APIs to handle custom drivers. These could be specializations to the generic or SoC components or complementary software components provided by the OEM to create a fully functional set-top device.
OEMs 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.
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-V and can implement based on your requirement. 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 provides a collaboration zone facility for OEMs to facilitate easier engineering of RDK based devices. The collaboration zone will help OEMs to work with SoCs, 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 for 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 | Which SDK version to be used. RDKM will support the integration with OEM libraries | |
6 | OEM | Manifest for building the accelerator | |
7 | 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 | |
13 | Monthly release & tagging | OEM | Monthly tagging and release with stakeholders along with test results |
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
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 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
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
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. 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.
Reference Flash Layout |
---|
flash0.macadr EMMC flash Data : 1024B flash0.nvram EMMC flash Data : 64KB flash0.recovery EMMC flash Data : 256MB flash0.vendor EMMC flash Data : 128MB flash0.kernel_a EMMC flash Data : 128MB flash0.kernel_b EMMC flash Data : 128MB flash0.rootfs_a EMMC flash Data : 1024MB flash0.rootfs_b EMMC flash Data : 1024MB flash0.rootdata EMMC flash Data : 2048MB flash0.rsvd EMMC flash Data : 10174MB |
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
# | File | Remarks |
---|---|---|
1 | 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 | |
2 | This manifest contains meta layer details of SoC and , optionally, some SoC specific repos | |
3 | 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 | |
4 | This manifest has details of the basic Yocto Open Embedded layers | |
5 | 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 | |
6 | Third party apps | This manifest can contain meta layers related to Premium streaming applications which are chosen by OEM |
For more details on getting RDK-V ported to an OEM device, please refer the links Add New SoC and OEM to RDK , RDK-V OEM Specific Porting and Guideline for SoC and OEM Vendors
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 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.
Each meta-* layer should have a conf folder containing the machine configuration we can select during 'source setup-environment' . Optionally it can also have a class/classes folder for keeping information that is useful to share between metadata files.
To add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file. In the machine conf file the basic machine configuration should be defined.
OEM can have several meta-rdk-<oem> layers containing chip specific implementation.
Generally conf file name will be SoC name. If both OEM and SoC are present then machine configuration should be coming from master i.e. OEM . It means whatever image that gets created comes from meta-rdk-oem
The most important variables to set in this file are as follows :
|
For SoC, The most important variables to set in this conf file are as follows :
|
Standard meta-rdk/recipe-core/images will have different kinds of images which one can use and build.
This recipe-core/images will have bbappend or main image name. If meta-rdk is used( i.e. meta-rdk image ) then bbappend of that image client is required
For example,
<image name>.bbappend
Define "bbappend of images" and "conf file" as required.
The following kind of recipes can be added to SoC/OEM layer. The recipes shall be grouped as described in “BSP Reference Layer”.
RDKM offers an in-house Test & certification suite that facilitates OEMs to get their IP based 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.
Certification suite is available at RDK IP Set-top Product Certification(only for RDK licensee) and for TDK test app please refer TDK-V Documentation.
Once the RDK bring-up in SoC is completed, the software is delivered to OEM by the SoC 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.
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 SDK. OEM vendor can use the git/ Artifactory for periodic updated (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 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
in this approach, 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 and then publish necessary documentation on how to build the OEM SDK.OEM vendor can use the git/ Artifactory for periodic updated (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 vendor.
For both approaches, the RDKM collaboration zone will be used with strict access restrictions.
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:
The aim of this document is to explain the procedure for OEM porting of RDK.
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
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.
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
Before You Begin
RDK License
Operators 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 page provides the details and guidance to the Operators on how to adopt RDK. The step by step procedure for an operator to get an RDK based Platform up and running is also described in detail.
Error rendering macro 'excerpt-include'
User 'null' does not have permission to view the page.
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-V and can implement based on your requirement. Operator can use this as a guide while engineering the RDK Operator platform.
Operators can make use of the details available below to start developing a Yocto build to do the final additions of Operator specific changes to the device. This will help Operator to add their own final product features as well as Operator specific patches/changes.
Yocto based RDK builds are flexible enough to easily accommodate SoC / OEM / Operator / third party 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 Operator specific manifests are given below
# | File | Remarks |
---|---|---|
1 | This is the starting point of the build and is specific to a device/board . If the SoC/OEM has only one target device /board, still it is recommended to maintain a different manifest for SoC/OEM for keeping it future-proof. Usually it contains references to other manifest files which will be having specific set of repos | |
2 | This manifest contains meta layer details of SoC and , optionally, some SoC specific repos | |
3 | OEM Manifest | This manifest contains meta layer details of OEM and , optionally, some OEM specific repos |
4 | Operator Manifest | This manifest contains meta layer details for operators and , optionally, some operator specific layers. |
5 | This manifest has details of the basic Yocto Open Embedded layers | |
6 | 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 | |
7 | Third party Apps manifest | This manifest can contain meta layers related to premium streaming applications which are chosen by Operator |
The default manifest repo in RDKM Git is at https://code.rdkcentral.com/r/#/c/manifests/ . Operator need to have their own manifest file in this location which will be mentioned in the 'Device specific manifest' - which is the starting point of builds for a particular target device
To match the layered structure of Yocto builds, a Operator specific layer is used to include Operator 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 chip family for which the layer is intended for. The general naming terminology for Operator layer is meta-rdk-<soc name>
The device (machine) configuration file shall include corresponding include (.inc) file to get machine configuration details.
Each meta-* layer should have a conf folder containing the machine configuration we can select during 'source setup-environment' . Optionally it can also have a class/classes folder for keeping information that is useful to share between metadata files.
To add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file. In the machine conf file the basic machine configuration should be defined.
Once the conf files are in place, the layer details need to be added to the corresponding package group file. Based on platform, the package group file will be grouped into multiple files with one bitbake fiile and multiple append files. Operator can add the Operator layer details to required package group append files applicable to the target device build to get the features into the final build
Operators will be having a range of Operator specific applications from simple generic device information apps to Operator specific content applications. RDK's Yocto based layered structure allows Operators to easily integrate, upgrade and maintain their apps in their RDK based IP Set-top devices. For more details on App support in RDK, please refer Applications(only for RDK licensee) as well as Operator Platform Firmware for the engineering details.
Follow the below steps to get Lightning UI running in devices:
This section details about how to customize the current UI source code and develop further.
Follow the commands to run the application on you laptop.
Type lng to confirm the installation. You will see the below output.
$ npm install -g @lightningjs/cli $ lng Usage: index lightning-cli <command> [options] Options: -V, --version output the version number -h, --help display help for command Commands: create - Create a new Lightning App build - Build a local development version of the Lightning App serve - Start a local webserver and run a built Lightning App in a web browser watch - Watch for file changes and automatically rebuild the App dev - Build a local Lightning App, start a local webserver, run a built Lightning App in a web browser and watch for changes docs - Open the Lightning-SDK documentation dist [options] - Create a standalone distributable version of the Lightning App upload - Upload the Lightning App to the Metrological Back Office to be published in an App Store update - Update the Lightning-CLI to the latest version help [command] - display help for command
Clone repo
$ git clone "https://code.rdkcentral.com/r/components/opensource/RDK_apps" $ cd RDK_apps $ git checkout rdk-next $ cd accelerator-home-ui Note: if you are not able to launch offline UI, add .env file inside accelerator-home-ui/ and add 'LNG_BUNDLER=esbuild' to force the bundler. Make sure you have esbuild dependency (npm install esbuild) $ npm install
Build and Host
$ lng build $ lng serve
App will be hosted on http://127.0.0.1:8080
What operators need to do if they plan to use Accelerator UI as such ( or with minimal changes )?
What operators need to do if they plan to use a different UI?
Along with the Operator specific apps, Operator can support a lot of generic apps in RDK IP Set-top devices by taking advantage of RDK Support for Native as well as Web Apps in IP based Set-top platforms. Operator can easily port native apps in their platforms (for some third party apps, Operator need to obtain certification from those third party) or can host their own app store and then use Web Apps to show content. For more information on App support in RDK, please refer Applications (only for RDK licensee).
The Factory Test App is a special standalone application used for production line testing at the TV assembly factory of the OEM manufacturer. It is embedded directly in the firmware image that gets flashed onto the boards on the TV production line.
<ToDo>
Operator needs to add provisioning support in device so that Device provisioning can be done once deployed at customer premise. The steps for this varies based on platform as well as Operator type.
Provisioning support refers to the scenario such as when you launch Sample app on your mobile it takes to login page and so you have to login there, account there i.e. actually the app has to authenticate your login.
Disaster recovery is an inevitable part of the CPE life cycle. Operator, based on their disaster recovery strategy, could add support for this in the device. While there are some generic guidelines followed across industry, there is no single step that works for all. Operators could easily add their business logic to RDK as part of Operator firmware engineering as described in Operator Platform Firmware.
As an operator they have to handle crashes/disaster happens and support any factory reset like OTA upgrade.
Once the device engineering is completed from Operator side, the device can be test and verified easily by the Certification support provided by RDKM. Details of coverage as well as major cases are explained here (only for RDK licensee) .
Certification suite is available at RDK IP Set-top Product Certification (only for RDK licensee) and for TDK test app please refer TDK-V Documentation.
In short, to get an RDK based device to field, Operators need to get
RDK Video Certification Page :
This page is currently accessible to RDK licensees only. To obtain a free RDK License Agreement, please fill out the RDK License Application Form on the Join RDK page.
TDK-V Documentation Page :
This page is currently accessible to RDK licensees only. To obtain a free RDK License Agreement, please fill out the RDK License Application Form on the Join RDK page.
RDK Source Code
To set git username and password, use the following commands.
$git config --global user.name "Your Name"
$git config --global user.email "youremail@yourdomain.com"
Issue:
While trying to do a repository initialization, the user will be prompted for a password.
Example console log:
Password for 'https://code.rdkcentral.com': remote: Unauthorized fatal: Authentication failed for 'https://<username>@code.rdkcentral.com/r/manifests/'
Possible reasons and solutions:
Not having a valid RDK Credential
Obtain valid RDK credentials : Users must have a valid RDK Central Credentials. To register use the link below
User registration without valid company email address
Update the credentials in $HOME/.netrc file, a sample of the file is given below
.netrc
machine code.rdkcentral.com login <user-name> password <Password>
Issue:
In few incidents, the user may not be having the required permission to download the code although having a valid combination of username/password combination.
Example console log:
Username for 'https://code.rdkcentral.com': rdknewuser
Password for 'https://rdknewuser@code.rdkcentral.com':
fatal: remote error: Service not enabled
fatal: cannot obtain manifest https://code.rdkcentral.com/r/manifests
Approach RDK support with the necessary approval to get the requested privilege.
Github no more supports direct password login and allows only Personal Access tokens. To generate a new token,
Eg: machine github.com login sampleuser password ghp_73ozr1OhWvUI1htuRCVwPyWF4Va1234ABCD
GitHub Workflow Steps:
Possible reasons and solutions:
If you are already using the Personal Access Token and getting a 403, chances are that the token has auto-expired.
You can generate a new token in Github by going to "https://github.com -> Settings -> Developer Settings -> Personal Access Tokens", Clicking on "Generate a new token" and then replacing your old token inside the ~/.netrc file with the newly generated one.
Mask the recipe in platform specific MACHINE conf file and run the source command again to build.
For example, to MASK ccsp-gwprovapp-ethwan in Rpi build, add below line in Rpi specific Machine conf file. Add below line in file
“meta-cmf-raspberrypi/conf/machine/raspberrypi-rdk-broadband.conf ”
BBMASK .= "|.meta-rdk-broadband/recipes-ccsp/ccsp/ccsp-gwprovapp-ethwan.bb"
Run the source command again to build
source meta-cmf-raspberrypi/setup-environment -> select respective conf file
If you encounter below error,
repo: warning: Python 2 is no longer supported; Please upgrade to Python 3.6+.
Downloading Repo source from https://gerrit.googlesource.com/git-repo
remote: Counting objects: 1, done
remote: Finding sources: 100% (41/41)
remote: Total 41 (delta 14), reused 41 (delta 14)
Unpacking objects: 100% (41/41), done.
Traceback (most recent call last):
File "<File Path>", line 56, in <module>
from subcmds.version import Version
File "<File Path>", line 38, in <module>
['%s' % name])
File "<File Path>", line 27, in <module>
from hooks import RepoHook
File "<File Path>", line 472
file=sys.stderr)
^
SyntaxError: invalid syntax
Upgrade the repo using below command to use with python3.
curl https://storage.googleapis.com/git-repo-downloads/repo-1 > ~/bin/repochmod a+x ~/bin/repopython3 ~/bin/repo init -u <repo URL>python3 ~/bin/repo sync
Make sure that the build machine is having required packages installed for specific Yocto flavor.
Eg: https://docs.yoctoproject.org/3.2.3/ref-manual/ref-system-requirements.html
Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.
There are tools within BitBake that enable this level of details.
In addition, the toaster is a new graphical user interface for BitBake that makes these tools much easier to use.
As with any complex system, the real answer is it depends, but of course that is not very helpful. The simplest method for adding a single package to your build is to add
the below line to conf/local.conf
:
Use your own package name in place of package. Note the leading space before the package name. If you want to add multiple packages, you can use multiple lines like the above, or list all packages on a single line with:
Although If you add in local.conf , that is not permanent change. For permanent addition of that package in final rootfs, you need to be added in image recipe or any package group which is included in the image recipe.
Prebuilds are handled internally by Yocto by using sstate-cache. If a prebuilt from a known good build is available, the build can point to that folder via the conf file inside the ./build<buildtype>/conf/ folder so that the prebuilts are picked up from the location
This depend entirely on multiple factors like capacity of build machine, first time build or repeated build in the same work space as well as changes in components on which the component in question depends on( if there is a change, the depending component is first built and then the dependent component ) and hence cannot be answered directly.
When you checkout sandbox every component is independently buildable, and bitbake ( OE's build engine) is responsible to identify and sort the component dependency chain and ensure its built along. if you were to build a single component the commands are
bitbake <component>
where component is in one to one relation with .bb ( recipe ) file that can be found in the Yocto/OE metadata ( meta-rdk* layers ) e.g. if you were to build rdkbrowser then you would see that its recipe is housed in generic layer called meta-rdk-cmf and recipe is called rdkbrowser.bb so the command would be
bitbake rdkbrowser
However this will only generate CMF component and for packaging it up into final image you still have to build the image component to repackage rdkbrowser
bitbake rdk-generic-hybrid-wpe-image
would generate the CMF generic image for hybrid devices. it will only rebuild the affected components when building the image if nothing has changed it will not recreate the image.
bitbake has division of work into individual tasks for a component. Secondly, the recipes are wired to notice changes in upstream repository as well when you do repo sync. You can use below command to see what all individual tasks are available.
bitbake -c listtasks <component>
It will show an output like
do_build Default task for a recipe - depends on all other normal tasks required to 'build' a recipe
do_bundle_initramfs Combines an initial ramdisk image and kernel together to form a single image
do_checkuri Validates the SRC_URI value
do_checkuriall Validates the SRC_URI value for all recipes required to build a target
do_clean Removes all output files for a target
do_cleanall Removes all output files, shared state cache, and downloaded source files for a target
do_cleansstate Removes all output files and shared state cache for a target
do_compile Compiles the source in the compilation directory
You can rerun any of the above tasks
bitbake -C compile rdkbrowser
would force recompile of servicemanager, if you wish to perform all the build steps for a component you can do that too by
bitbake -c cleansstate rdkbrowser; bitbake rdkbrowser
Similarly, in general you can have:
bitbake <target> -c<task_to_be_executed>
This will ensure do_<task_to_be_executed>() will be called.
task_to_be_executed can fetch, unpack, configure, compile, install, package etc
If we were to draw parallels
--rebuild = bitbake -c cleansstate <component> ; bitbake <component>
--build-only = bitbake <component>
--skip-package is delegated to shared state mechanism to figure out at present.
Unless you do 'repo sync' sources will not be updated
'repo sync' can cover only components with external src support, it means that in cases when SRCREV is set to AUTOREV and component doesn't support external src, then bitbake will try to update sources from a remote repository during build time.
There is no documentation for AUTOREV, but it's doing only one function - check remote repository for any new sources updates.
|
You can prevent this behaviour by changing BB_SRCREV_POLICY variable in you local <sandbox>/conf/local.conf
|
|
These are OE metadata variables, bitbake has preprocessing options where it expands all the local bitbake variables so you could take advantage of that option to figure it out
bitbake -e rf4ce | grep "^S ="
bitbake -e rf4ce | grep "^WORKDIR ="
It can be used to check for any bitbake variable, alternatively you can pipe the whole bitbake -e output to a file and inspect the file in your favourite editor
temp
directory. Log files are named log.taskname-Eg:compile logs are present in the file log.do_compile.
Bitbake maintains logs separately for each of the tasks that run while building the component. These tasks are typically the fetch task, the compile task, install task and so on.The warnings like -Werror -Wall -Wextra are turned on for compiler for most of the Ccsp components .All these warnings must be fixed for successful compilation as all warnings are treated as errors.
Werrors due to unused parameters in code can be fixed by using:
UNREFERENCED_PARAMETER(user_data); ,if user_data variable is not used in the scope of definition of the function .
* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-...:
* net-snmp *
* opkg_install_cmd: Cannot install package packagegroup-....
The above error indicates that :
You asked for adding net-snmp ( the package ) not ( the recipe ) now net-snmp ( the recipe ) may generate a number of ( packages ) so you should add the packages ( runtime items) to the package groups and not the recipes ( build time items). Usually yocto/OE does generate a output package with same name as input recipe so for net-snmp.bb there will be a net-snmp ipk but thats just a common case not a hard and fast rule.
Now in this particular case when a package has nothing to emit into the ${PN} package the package is left empty and hence not emitted. If you want to emit the package regardless you have to add
ALLOW_EMPTY_<package> = "1" in the recipe,but this is less of a usecase to demand empty packages. If you expressed the packagegroup RDEPENDS correctly you would not need it.
sstate-cache is always adding new versions and hence is growing in size always, thankfully we have a tool in Yocto to manage it, here is a sample on how to do it for raspberrypi you can set WORKSPACE and MACH variables to point to the values for machine
sstate-manage.sh
|
To enable kernel/busybox features you can append metadata to the recipes (i.e. .bb files) by simply creating an append file (i.e. .bbappend files) and including metadata in it. If the features needs to be enabled across all the platforms then add in meta-rdk-rpi meta or if it's specific to a platform then append to the recipes available in OEM layer specific to the platform.
Below example shows how to enable IPSec on Yocto builds:
Make sure .bbappend has the same root name as their corresponding .bb recipes.
Sample failure logs:
error: generic/devicesettings/generic/: contains uncommitted changes
error: generic/rdkbrowser/: branch master is published (but not merged) and is now 11 commits behind
error: meta-rdk-oem-X/: contains uncommitted changes
git rebase —abort
git rebase rdkgerrit/master ( or rdkgerrit/stable2)
git checkout --ours FILE
grep -lr ‘<<<<<<<<’. | xargs git checkout --ours
git checkout --yours FILE
grep -lr ‘<<<<<<<<’. | xargs git checkout –theirs
FILES_${PN}-dev += " file1 file2 etc"
Yocto project build system has a utility which can provide information about which package (ipk or rpm) is providing a given file, this helps in finding further information on packaging e.g. if you want to do more finer packaging, run the following command in your build environment
oe-pkgdata-util find-path /lib/libc.so.6
glibc: /lib/libc.so.6
Common build failures are reported in Yocto builds. Some build failures are hard to analyze with logs, unless we get access to the failure workspace. In most cases they are hard to reproduce on local workspace. We go through multiple iteration of builds, lock down the node and then debug. To debug these failures use Packages file found under tmp/deploy/ipk directory on you local workspace .
The signal core dump that are generated under /tmp can be decoded using gdb
Procedure :
This should be because of architecture bit mismatch . To overcome this should either choose the right target platform or put the executable file as a tar file in bb file.
Issue:
While building the stack, the bitbake process will be aborted if the disk space runs low beyond the minimum requirement.
Example console log:
WARNING: The free space of /mnt/home/gpsahu01/cmf/test/build-qemux86hyb/tmp (/dev/vdb) is running low (0.999GB left)
ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"!
WARNING: The free space of /mnt/home/gpsahu01/cmf/test/downloads (/dev/vdb) is running low (0.095GB left)
ERROR: Immediately abort since the disk space monitor action is "ABORT"!
NOTE: Sending SIGTERM to remaining 1 tasks
Possible solution:
Yocto stack requires more than 30 GB of free disk space for build to complete, so it is required to keep sufficient disk space available before starting the build process.
Issue:
Bitbake complains about a missing “sys/cdefs.h” and the error can be encountered in random recipes when we move from one build host to other.
Example console log:
compilation terminated.
| In file included from /usr/include/stdio.h:27:0,
| from ./src/kern_head.c:13:
| /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory
| # include <sys/cdefs.h>
| ^
| compilation terminated.
| In file included from /usr/include/stdio.h:27:0,
| from ./src/sstrip.c:9:
| /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory
| # include <sys/cdefs.h>
| ^
| compilation terminated.
| make: *** [encode] Error 1
| make: *** Waiting for unfinished jobs....
| make: *** [kern_head] Error 1
| make: *** [sstrip] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command
This issue may be caused by a missing “g++-multilib” package in the build host (observed in Ubuntu 14.4). Installing the package with “sudo apt-get install g++-multilib” should resolve this issue. Also the build machines should be configured following the procedure as per Setup guide to avoid similar issues.
Issue:
The bitbake process terminates after complaining about a non-existent path or environment variable.
Example console log #1:
ERROR: Function failed: iarmbus: LIC_FILES_CHKSUM points to an invalid file: ${RDK_ROOT_PATH}/components/generic/iarmbus/core/include/libIARM.h
Example console log #2:
ERROR: ParseError at /mnt/home/gpsahu01/cmf/test/meta-virtualization/recipes-extended/images/cloud-image-controller.bb:29: Could not inherit file classes/image-vm.bbclass
Possible solution:
This may be due to a wrongly setup environment e.g. we have executed “meta-rdk/setup-environment” instead of sourcing “meta-cmf/setup-environment”
Issue:
The issue is observed during setup and machine selection stage, setup-environment script will throw unexpected error about non-existing layer paths.
Example console log:
gpsahu01@dvm-wcdcc-tata-001:~/cmf/emulator-2.1-20160919$ source meta-cmf/setup-environment
1) meta-raspberrypi/conf/machine/raspberrypi0.conf 7) meta-rdk-bsp-emulator/conf/machine/qemux86hyb.conf
2) meta-raspberrypi/conf/machine/raspberrypi2.conf 8) meta-rdk-bsp-emulator/conf/machine/qemux86mc.conf
[…]
Please enter your choice of machine [1..11]: 7
### Shell environment set up for builds. ###
Writing auto.conf ...
Writing versions.txt ...
-bash: cd: ../meta-browser//: No such file or directory
fatal: Not a git repository (or any parent up to mount point /mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
-bash: ../patches/rdk-oe/meta-linaro//*.patch: No such file or directory
-bash: cd: ../meta-openembedded//: No such file or directory
fatal: Not a git repository (or any parent up to mount point /mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Possible solution:
If the host PC has set colored terminal output for commands then it may cause unexpected errors being shown during execution of meta-cmf/setup-environment script. To fix the problem we can run following command:
gpsahu01@dvm-wcdcc-tata-001:~/cmf/emulator-2.1-20160919$ alias ls='ls --color=no'
Issue:
Fetch timeout or failure can happen due to following network problems.
- Network not accessible
- Restriction in Firewall
- Invalid Proxy configuration
- Unable to resolve DNS in IPv6 networks
Example console log:
Fetching projects: 96% (91/94) Fetching project openembedded/meta-linaro
Fetching projects: 97% (92/94) fatal: read error: Connection timed out
fatal: read error: Connection timed out
fatal: read error: Connection timed out
error: Cannot fetch meta-virtualization
warn: --force-broken, continuing to sync
Fetching projects: 98% (93/94) error: Cannot fetch meta-java
warn: --force-broken, continuing to sync
Fetching projects: 100% (94/94)
error: Exited sync due to fetch errors
Possible solution:
- Using VPN may have some restrictions sometime it may not allow GIT access.
- Ensure that the ports for HTTPS, SSH, HTTP are opened by the firewall and the policy doesn’t block common open source repositories.
- In case of IPv6 networks issues, force GIT to use IPv4.
Also Following options can be considered while debugging:
Option #1) Need to flush the IP rules:
enter the command
$ iptables -F
and check
$) git clone git://git.lighttpd.net/lighttpd/lighttpd-1.x.git
Option #2) Check for the port 22 is open or not by doing nmap
$ nmap -p 22 10.11.107.0-255"
(check for ipaddress 10.11.106.62)
$ ssh -v git@github.com
if it adds it will ask for input()yes/no- Type yes
$ git clone git://github.com/lighttpd/lighttpd1.4.git;branch=lighttpd-1.5.x
Option #3) replacing the git// with https:// which uses port 443
$ git config --global url."https://".instead of git://
and try $ "git clone git://git.lighttpd.net/lighttpd/lighttpd-1.x.git"
Option #4) in a few cases, the access to GIT repository is via SSH. To use SSH URLs with GIT repository, an SSH key-pair must be generated on the build PC and add the public key to your GitHub account.
For information on setting up an SSH key-pair, see "Generating an SSH key."
https://help.github.com/articles/generating-an-ssh-key/
Issue:
When we try to build a very old branch of the code, the manifest file will not be up-to-date as few of the open-source URLs might not be continuing support of older branches or versions of software.
Example console log:
WARNING: Failed to fetch URL git://code.qt.io/qt/qtlocation.git;branch=stable, attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision f28408346243cf090326f4738fd838219c21e00f in branch stable even from upstream
ERROR: Function failed: Fetcher failure for URL: 'git://code.qt.io/qt/qtlocation.git;branch=stable'. Unable to fetch URL from any source
Possible solution:
It is recommended to build with more recent branches, as the code will be well maintained and will have updated features.
Issue:
An Open source URL is broken either due to the website is down temporarily or it is permanently removed.
Example console log:
WARNING: Failed to fetch URL http://directfb.org/downloads/Core/linux-fusion/linux-fusion-9.0.3.tar.gz, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 4, no output
ERROR: Function failed: Fetcher failure for URL: 'http://directfb.org/downloads/Core/linux-fusion/linux-fusion-9.0.3.tar.gz'. Unable to fetch URL from any source
Temporary workaround: In case of archives (.tar or .zip etc.), if the file is available from a previously built stack then it can be copied and an empty file with the name <archive-name>.done has to be created to bypass looking for downloading the file.
Fixing the recipe: If the problematic recipe is available from any other alternative mirror, update the same in SRC_URI part of the recipe. Few components may be available in common mirrors such as github, web.archive.org, oipf.tv etc.
Looks like memory issue hence changing Ubuntu to 64 bit version should resolve the issue. The below are the Ubuntu configurations,
16GB Swap
To include a specific feature that is not available in base build, enable the feature specific DISTRO flag in platform specific config file. For example to include USPA feature in Rpi build,
Add the DISTRO specific flag in Rpi platform specific conf file
In File meta-cmf-raspberrypi/conf/distro/include/rdk-rpi.inc
Add DISTRO_FEATURES_append = " usppa" (to include the feature if not there)
DISTRO_FEATURES_remove = " usppa" (to remove the feature)
Make sure the recipe is part of the package build
In File meta-rdk/recipes-core/packagegroups/packagegroup-rdk-ccsp-broadband.bb must be included as a DISTRO protected feature RDEPENDS_packagegroup-rdk-ccsp-broadband += " \ ${@bb.utils.contains('DISTRO_FEATURES', 'usppa', "usp-pa", "", d)}"
ERROR: ParseError at /home/a1602446/build-raspberrypi-rdk-broadband/conf/local.conf:247: Could not include required file conf/distro/include/##RDK_FLAVOR##.inc
Above error occurs intermittently, which can be fixed by retrying the source command for setup_environment file.
In case of Rpi, it is
Please refer Compile-time Build Variants Flags
Issue:
Bitbake fails on populate sysroot state when building with an un-clean stack.
Example console log:
ERROR: Function failed: llvm_sysroot_preprocess (log file is located at /mnt/home/gpsahu01/cmf/test/build-qemux86hyb/tmp/work/i586-rdk-linux/llvm3.3/3.3-r0/temp/log.do_populate_sysroot.9648)
Possible solution:
This may happen when a previous build process was unexpectedly terminated or aborted. Re-build after cleaning the problematic recipe or image (bitbake <recipe> -c cleanall) would fix the issue.
Issue:
Bitbake terminates the compilation process on ‘do_patch’ task. This may happen in following cases:
- When using an old recipe file where the SRC_URI link has updated its folder structure.
- Wrongly formatted patch file (run dos2unix for conversion)
- Incorrect patch level (p0, p1, etc.)
Example console log:
ERROR: Command Error: exit status: 1 Output:
Applying patch 0001-src-Makefile.am-Dont-check-if-we-are-cross-compiling.patch
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
diff --git a/src/Makefile.am b/src/Makefile.am |
index eb50e37..c1e3d64 100644 |
— a/src/Makefile.am |
+++ b/src/Makefile.am |
From the above output it seems that the file to which patch will be applied is not found, possible reason may be the source folder structure doesn’t match with the destination folder structure. E.g. the source directory or ${S} starts from the relative path ‘src’ folder and we are trying to patch outside of it.
By default bitbake patches the files with patch level ‘p1’ so creating a patch file which matches destination folder structure would solve this issue. Another option is to alter the patch level. E.g.
SRC_URI += file://docsis_3383.patch;striplevel=0
Issue:
Bitbake complains about md5sum mismatch when a recipe has retained old md5sum value while the source file is updated.
Example console log:
ERROR: gst-plugins-playersinkbin-noop: md5 data is not matching for file://gstplayersinkbin.c;md5=0f518921aef846c156f91ce4dd6b7c76
ERROR: gst-plugins-playersinkbin-noop: The new md5 checksum is 958142c8f2783c6c4f357f561585b4da
Possible solution:
Update the new md5sum value of the file in recipe. This can be done using following steps:
:…/meta-rdk/recipes-extended/gst-plugins-playersinkbin/files$ md5sum -t gstplayersinkbin.c
958142c8f2783c6c4f357f561585b4da gstplayersinkbin.c
Now change the above value in recipe:
LIC_FILES_CHKSUM = "file://gstplayersinkbin.c;md5=958142c8f2783c6c4f357f561585b4da \”
Example Console Log :
repo: warning: Python 2 is no longer supported; Please upgrade to Python 3.6+.
Downloading Repo source from https://gerrit.googlesource.com/git-repo
remote: Finding sources: 100% (32/32)
remote: Total 32 (delta 14), reused 32 (delta 14)
Unpacking objects: 100% (32/32), done.
File "/mnt/home /cmf/.repo/repo/main.py", line 79
file=sys.stderr)
^
SyntaxError: invalid syntax
If you're using an older system without Python 3.6+, try downloading an older version of the Repo Launcher that still supports Python 2.7.
Possible Solution :
# create a bin directory
mkdir ~/bin
export PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo-1 > ~/bin/repo
chmod a+x ~/bin/repo
ERROR: trower-base64-git+AUTOINC+fbb9440ae2-r0 do_fetch: Fetcher failure: Unable to find revision fbb9440ae2bc1118866baefcea7ff814f16613dd in branch master even from upstream
ERROR: trower-base64-git+AUTOINC+fbb9440ae2-r0 do_fetch: Fetcher failure for URL: 'git://github.com/Comcast/trower-base64.git'. Unable to fetch URL from any source.
ERROR: trower-base64-git+AUTOINC+fbb9440ae2-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /builds/__repo/build-brcm968360GW/tmp/work/cortexa7t2-vfp-rdk-linux-gnueabi/trower-base64/git+AUTOINC+fbb9440ae2-r0/temp/log.do_fetch.18310
ERROR: Task (/builds/__repo/meta-rdk-ext/recipes-support/trower-base64/trower-base64_1.0.bb:do_fetch) failed with exit code '1
Few points to check here,
First check if the SRC_URL can be accessed manually in browser
Check the path of the URL is proper and check the branch detail as well
For example, above error can be fixed by appending branch=main in the SRC_URL path
RDK Reference Platform :
RDK Accelerator :
RDK Device Management :
WEBINARS Home :
Test Development Kit (TDK) :
Release details:
The dmcli command for emulator platform use simu instead of eRT and this is the reason for failing in emulator.
A sample command is :
dmcli simu getv Device.
The devices can connect over wifi to Raspberrypi by knowing the SSID and the corresponding password of the RaspberryPi Wifi network, which will be WPA2-PSK protected.
As of now, RDKM is not providing a ready-to-use pre-built image for emulator. But you can easily create an emulator build in an Ubuntu linux machine by following the instructions given at RDK-B Emulator Build Instructions .
mkdir tmp/;
cd tmp/
wget https://repo.turris.cz/hbl/omnia/packages/turrispackages/u-boot-omnia_2019-07-7_arm_cortex-a9_vfpv3.ipk
tar xf u-boot-omnia_2019-07-7_arm_cortex-a9_vfpv3.ipk
tar xf data.tar.gz
cd usr/share/omnia/
flash_eraseall /dev/mtd0
nandwrite /dev/mtd0 uboot-devel
cd ../../../..
rm -rf tmp
mkdir tmp; cd tmp/
wget https://repo.turris.cz/hbl/omnia/packages/turrispackages/rescue-image_3.2-1_arm_cortex-a9_vfpv3.ipk
tar xf rescue-image_3.2-1_arm_cortex-a9_vfpv3.ipk
tar xf data.tar.gz
cd usr/share/rescue-image/
flash_eraseall /dev/mtd1
nandwrite /dev/mtd1 image.fit.lzma
cd ../../../..
rm -rf tmp
When we pass Legacy zImage(kernel) image with newer model of turris Omnia we get this error. We need to provide FIT rescue image for newer model of Turris Omnia
Go into u-boot prompt and get back to OpenWRT (failsafe) OS
=>env set yocto_mmcload false
=>saveenv
=>reset
Format /dev/mmcblk0p3 and /dev/mmcblk0p5 and new RDKB firmware into p3 and p5 partitions
To get back to RDKB image
=>env set yocto_mmcload setenv bootargs \"\$yocto_bootargs cfg80211.freg=\$regdomain\"\; ext2load mmc 0:3 0x01000000 zImage\; ext2load mmc 0:3 0x02000000 armada-385-turris-omnia.dtb
=>saveenv
=>reset
Follow "Flashing with Medkit & Sysupgrade images" section in https://wiki.rdkcentral.com/pages/viewpage.action?pageId=114986683
Legacy and FIT image
TurrisFwUpgrade.sh is written with two models in mind(older and newer)Older model has this partitions in internal flash
mmcblk0p1 - openwrt bootfs
mmcblk0p2 - openwrt rootfs
mmcblk0p3 - rdk bootfs
mmcblk0p4 - Extended partition
mmcblk0p5- rdk rootfs(1)
mmcblk0p6 - nvram
mmcblk0p7 - rdk rootfs(2) for firmware upgradeNewer model has this partitions in internal flash
mmcblk0p1 - rdk bootfs
mmcblk0p2 - rdk rootfs(1)
mmcblk0p3 - rdk rootfs(2) for firmware upgrade
mmcblk0p4 - Extended partition
mmcblk0p5 - nvramThis TurrisFwUpgrade.sh script will fill new rootfs in alternate partition swap the rootfs partition and copy zImage (in bootfs) in internal flash memory.
We can change the resolution in rms.conf file that is there in /ust/local/rms/bin/ directory.
Yes, we have used AWS server to store 24*7 data for CVR.
Use gstreamer plugin mainly, v4l2src plugin to capture data from camera.
AS of now we used confidential page to check this feature,we are trying to support google based signalling server to resolve this conflict.
h264 encoded format is supported for RMS live streaming and Continuous video recording(CVR).
No. An organization must be a member of the Digital Living Network Alliance to obtain a DLNA license.
Yes.
Use below command format -
(The quarterly release name can be given with -b option)
It is possible to consume mediaplayer events in Lightning -http://cdn.dashjs.org/latest/jsdoc/streaming_MediaPlayerEvents.js.html
Example:
const events = ["playbackStateChanged", "playbackCompleted", "playbackSpeedChanged",
"playbackFailed", "mediaMetadata", "timedMetadata", "playbackProgressUpdate",
"playbackStarted", "bufferingChanged", "durationChanged", "decoderAvailable" ];
events.forEach(event => {
player.addEventListener(event, (e) => {
this.fire(event, {event: e});
});
});
IARM bus interface are used to get the events notification from the system level like IR key, power, storage space, etc. could be better used in native apps.
Servicemanager acts as a subscriber who will receive the events from IARM Bus and post it to MSO Backend. The ServiceManager is the one well known facility for cloud-based applications to gain access to device vended functionality whether they are written in HTML .
The better alternative is of course the "AbstractService" class as it is the newer version and derived from the "Service" class and has a superset of features of the service class. However, pure virtual functions may be useful for enforcing OOPS convention of data hiding and abstraction.
First modify the config/xml file which will be there in the component you are writing objects and then respective handlers you have to call in xml.
WPE WebKit has limited support for HTMLMediaElement.canPlayType() and MediaSource.isTypeSupported(). It implements checks for container, video width/height/framerate, and basic verification of codec (it doesn't check for profile & level)
Make sure DASH.js uses utf-8 as a content type format for license requests (playready challenge is utf-8 encoded)
WPE media element: no audio track selection; WPE MSE Google Shaka: selectAudioLanguage(language, role), or selectVariantTrack(track); WPE AAMP UVE: set
Inject the following JS code to handle MoneyBadger requests (some)
window.ServiceManager = {};
window.ServiceManager.version = '2.0';
window.ServiceManager.getServiceForJavaScript = function(name, serviceReadyCb) {
class BridgeObject
{
JSMessageChanged(msgStr)
{
let msg = JSON.parse(msgStr);
console.log('badger action=', msg.action, 'pid=', msg.pid);
if (msg.action === 'deviceCapabilities' || msg.action === 'info') {
setTimeout((msg) => {
let caps = {
videoDimensions: [3840, 2160],
hdr: { settopHdrSupport: 'DolbyVision', tvHdrSupport: 'DolbyVision' },
hdcp: { connected: true, currentHDCPVersion: '2.2' }
}
window.$badger.callback(msg.pid, true, caps)
}, 0, msg);
} else {
window.$badger.callback(msg.pid, false, {})
}
return true
}
}
if (name === 'com.comcast.BridgeObject_1')
serviceReadyCb(new BridgeObject);
}
Open <span style="color: #0000ff"><a href="https://www.ssllabs.com/ssltest/viewMyClient.html" class="external-link" rel="nofollow">https://www.ssllabs.com/ssltest/viewMyClient.html+</a></span> on box to get a report of supported TLS versions and ciphers
Yes, it is possible to use a remote control with rdkbrowser2.sh
touch /opt/remote_input_enable and reboot.
By default local storage is disabled. If the app requires this support, you need to contact Project management to enable it for the specific app.
You can modify the script to avoid the deletion of older files:
Client requests a tuner through URL(http,live), TRM server receives the request and checks for the valid reservation and reserves the tuner so that the client is provided with the service requested. Client also can extend or delete the reservation. It is also possible for a client to request a list of the active reservations.
For more details, Please refer https://wiki.rdkcentral.com/display/RDK/TRM#TRM-HowTRMworks
getDeviceInfo() - Retrives the device information of the device .
To get a mac address getDeviceInfo() needs to be called with string “getMacAddress” as an argument like getDeviceInfo(“macAddress”)
Yes , Please refer this link : Session Manager
No
End state architecture has scalability and security built into it.Refer RDK Alexa Echo Dot Voice Application .
This is a sample pipeline to play dtcp encrypted content using gst-launch
gst-launch-1.0 httpsrc location="http://127.0.0.1:8080/hnStreamStart?live=ocap://0x2c23&continueTSB=true" blocksize=131072 ! dtcpdec dtcp-src-ip="127.0.0.1" dtcp-port=5000 buffersize=131072 ! playersinkbin is-live=true.
core_log.txt
rebootInfo.log
messages.txt
There is no package manager support for downloading/installing packages. However you can manually install ipk packages.
RDK Device Settings is the component which handles the following configurations:
These properties are persisted in the STB and are read/applied on each boot-up.
For example: On a RDK emulator, the device setting properties are persisted in '/opt/persistent/ds/hostData' .
There are few sample applications available to test/force the settings e.g. setResolution can be used to force the resolution settings.
The Comcast RDK requires kernel logs, DOCSIS ECM logs, and syslog messages to be logged into specific files. These details can be provided by Comcast on request. The RDK set-top diagnostics and troubleshooting infrastructure requires these logs to be present and accessible via the ESTB interface to aid in the rapid troubleshooting of the device during development and deployment.
Flash and hard disk drive (HDD) requirements for RDK devices will differ depending on the deployment configuration. For example, a DVR will have an HDD but some other devices will not.
Flash is used to store the advanced bootloader (ABL), primary and secondary firmware images, serialization data, and other data that need to persist, including logs. Where possible on HDD devices, the HDD is leveraged to store dynamic content leaving flash on those devices to be primarily read-only. The partitioning scheme for on-board flash and HDD will therefore differ depending on the physical makeup of the device.
Please contact Comcast for more information.
libcrypto, openSSL and libpgp can be ported as it is. However the SoC security APIs need to be implemented to support Comcast security requirements.
There are no requirements for hardware optimization.
Execute $ npm run watch and then npm run serve separately in separate terminal.(tried on VS code)
For this,Install windows node env globally:
$ npm install -g win-node-env
root@RaspberryPi-Gateway:/# find . -iname libpcap* ./usr/lib/libpcap.so.1.7.4 ./usr/lib/libpcap.so.1
Currently no such pre-built images are available for download. You can follow the simple build instructions to generate your own build.
Eg:
The eRT (embedded router) subsystem is generally used to perform dmcli operations on Raspberry pi which can function as a basic router. To perform dmcli operations in emulator we use simu.
We're simply building the application using go build (without any Yocto recipes) as shown below -
env CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabihf-ld GOOS=linux GOARCH=arm GOARM=7 CGO_ENABLED=1 go build
Below are the two ways to enable debug logs for component
The steps are –
For reference please look into this attachment :
Follow the below steps to customize kernel –
Yes, igmp_snooper program is present in RDK-B .
There is a shell script named "service_mcastsnooper.sh" under /etc/utopia/service.d directory, and in the script, it will execute "igmp_snooper $sw_opt $if_opt $querier_opt
The data model can be managed via TR-069 , TR-181, management protocols like SNMP, WebUI, WEBPA .
Use NTP sync to run in the background to sync time with NTP servers.Update the NTP servers in ntp conf file if needed.
Minimum Hardware requirement :
The above requirement supports all the basic functionalities of RDK-B.
Yes. You can invoke the data models via dmcli commands from your service or via Cdm_GetParam set of APIs from your code. The TR-181 data model specifications that are available in the TR-181 data model XML for each component can be referred.
The CA certificate file and device certificate/private key can be configured in ccsp_tr069_pa_cfg.xml for https support.
There are already reserve SSID for Guest WiFi network. Just enable the SSID using the respective DM to get the features in place.
Duktape is a lightweight javascript engine (https://duktape.org/). Alone it does not provide a web development engine like php or node.js. Therefore,on top of duktape there is a templating engine(called jst) and web server api. To make migration as easy as possible the style of templating and api signiture will match php as closely as possible. Many php functions and variables will be rewritten in javascript, so that changes to the exist code is minimized.
It actually defines what kind of Internet traffic is allowed or blocked. For more details, Please Refer : Firewall - Rule persistence
Use journalctl -xu parodus or can look for parodus.log in the log folder i.e. /rdklogs/logs/.
In <image>.bbappend file , upgrade python version using ROOTFS_POSTPROCESS_COMMAND
Code :
#python upgrade IMAGE_INSTALL_append = " python3 " ROOTFS_POSTPROCESS_COMMAND += "enable_python3; " enable_python3() { ln -sf /usr/bin/python3 ${IMAGE_ROOTFS}${bindir}/python }
On compiling the code and flashing the image , python3 will be available in your board . Check with below command.
root@RaspberryPi-Gateway:~# python --version Python 3.5.2
Checksum mismatch error is related to Fetcher failure for URL . The ways to fix this error are as follows
yes, all logs are maintained in persistent path (opt/logs) log rotation available if size goes beyond. Log server are in place. More details on how logging is done in RDK can be found here: Log Upload, RDK Logger
Yes, Because telemetry itself is a subset of Device Configuration management aka DCM and we need to configure the DCM logupload settings before setting up telemetry configuration
By using T2 Report profiles, we can setup multiple telemetry profiles. Each profile can have different set of telemetry markers , telemetry upload location URL and telemetry upload schedule. The different telemetry JSON data will be uploaded separately. Thus multiple telemetry profiles is achieved.
Yes, the T2 report profile will have the upload URL along with the telemetry markers, The upload repository in different profiles can be same or different. So based on the configured URL in these T2 report profiles, the data will be uploaded to the respective URLs .
To know the Complete steps for xconf local setup , Please refer : Xconf Server - User guide for configuration and feature validation
In service.properties, you can add the following properties. The "seeds" property is just a comma-separated list of a few Cassandra hosts. If you are using a single host, then it's just that one. The other properties may not be needed.
connectionPools.SharedConnectionPool.seeds=192.168.0.100,192.168.0.101
connectionPools.SharedConnectionPool.localDatacenter=DC_NAME
connectionPools.SharedConnectionPool.readConsistencyLevel=CL_LOCAL_QUORUM
connectionPools.SharedConnectionPool.writeConsistencyLevel=CL_LOCAL_QUORUM
connectionPools.SharedConnectionPool.autoDiscoverHosts=true
Yes, it can be run on separate nodes. The admin and data service do not need to discover each other. They both use the Cassandra database, so they need to be able to reach it. If you install the admin and data service on separate nodes, you will probably have Cassandra on a third node. The service.properties file for each service should include the "seeds" property.
Steps -
Refer Xconf Server - User guide for configuration and feature validation#FeatureValidation(Firmwareupdate) for more details.
There should be a webpa server running somewhere (to which the device can contact). If the server is in place, you can run the commands to fetch data models from a PC that can connect to server or even from the RPi terminal itself.
As of now we don't have a provision to update the webPA url from xconf.
This is setting a parameter using webPA
curl -X PATCH http://35.155.171.121:9003/api/v2/device/mac:b827eb5681cd/config -d '{"parameters": [ {"dataType": 0, "name": "Device.WiFi.SSID.10001.SSID", "value": "Testing"}]}' -H 'Authorization:Basic d2VicGFAMTIzNDU2Nzg5MAo='
curl -X GET 'http://35.155.171.121:9003/api/v2/device/mac:b827eb5681cd/config?names=Device.WiFi.SSID.10001.SSID' -H 'Authorization:Basic d2VicGFAMTIzNDU2Nzg5MAo='
You can delete a model using below command
Retrieve list of models & check the particular entry is deleted:
.ns list for mac list
Themis was not part of the community XMidt server, we will discuss with developer and update the wiki.
Refer WebPA for more information.
Refer Environment Setup in RDK-C : WebPA Support#C:WebPASupport-EnvironmentSetup
TR-69 polls wide-and-deep across a device landscape, on a less frequent basis whereas WebPA can precision-poll for the most useful data, much more quickly. That’s mainly because it’s lightweight, and because the load can be redistributed into all the apps needing to access the data.
Example 1: Fetch device or feature parameter detail from client( RPI ) device through parodus by using webpa server.
Example 2: Setting the SSID Password :
Example 3: Getting the SSID for the board.
Refer WEBPA Validation Procedure Steps in RDK-C : WebPA Support#C:WebPASupport-WEBPAValidationProcedure for more information.
Yes ,it is possible to configure TFTP ipv4 and ipv6 locations in Xconf. Follow the steps specified here Xconf Server - User guide for configuration and feature validation#AddTFTPlocation
Xconf doesn’t store any data, be it logs or telemetry data. It only provides the configuration to the client device regarding where to upload the data, when to upload the data and what data it needs to be uploaded. So Xconf server doesn’t need any big data processing tools.
There is no direct interaction, both Xconf and WebPA serve different purpose. While Xconf is used by devices to fetch and configure the rules, webPA can be used to push/set the rules/attributes on a CPE device.
No, xconf doesn’t directly facilitate upload logs/telemetry data. It provides devices information on where/when to upload the log files or telemetry json files.
No, the maven-frontend-plugin plugin downloads/installs Node and NPM locally for your project, runs npm install. It's supposed to work on Windows, OS X and Linux.
Yes, If anyone needs to override the firmware download location, it's best to do it with a define property rule. It will only affect those devices identified in the rule.
Just like tftp location is overridden like this - Xconf Server - User guide for configuration and feature validation#AddTFTPlocation
The roadmap is always available to the Preferred and Preferred Plus members of RDK at https://wiki.rdkcentral.com/display/ASP/Roadmap . To become a preferred member as well as to know the benefits, please visit https://rdkcentral.com/memberships/ . For the non preferred members, you can get answers to specific queries on Roadmap items by contacting support@rdkcentral.com or asking at https://wiki.rdkcentral.com/display/FORUMS/FORUMS+Home .
Please refer Breakpad steps
On 15 August 2013 Comcast Cable and Time Warner Cable jointly announced the formation of RDK Management, LLC to fulfill the role of the "RDK Entity".
We will maintain compatibility with the previous RDK version as described by the guidelines in the agreement. Additional details will be posted on the RDK Wiki as they become available.
Licensee are not required to take a new baseline.
RDKM does not assess run-time royalties for the Generic RDK.
The infrastructure to support DVB exists today; but additional components may need to be developed to support the particular network type. Typical enhancements include converting a URI to a network-specific identifier in the SI handling, and enhancing the security processor to implement CA that doesn't use the cable card.
RDK supports CEA-708 and EIA-608.
The font-type used for Closed Captioning belongs to an opensource family called Droid with specific glyphs for closed captions. Incase operators are using licensed fonts they have to meet the exclusive license requirements for those fonts.
OEM vendors will need to work with font vendors to provide fonts that comply with FCC standards. RDK Support is looking into whether FCC-compliant open-source fonts are available, and will provide that information in a future update.
To add VOD support for a different system, the VOD client would be rewritten to talk to the appropriate backend to provide content. This is an independent implementation and not coupled to any specific MSO configuration. The client is responsible for tuning to the content, connecting it to a sink, and starting streaming. It comes into play only after a VOD request is received by the receiver, the purchase is completed, and the connection is created (i.e., broadcast has started from servers side). Because time shift buffers are not allowed for VOD content, trickplay commands are merely forwarded to the content source, which is responsible for taking the appropriate actions.
Yes, RDK supports these tags in the current version.
Device Settings is integrated with IARM, which invokes the HAL API to effect changes requested by the application. Interface specifications are available for application developers.
The IP client provided by RDK works with the RDK Server, not the general DMS. This is the direction for now. CVP-1 and CVP-2 certification are planned for RDK Servers.
Separate RDK release packages will be available for IP and Hybrid versions. The requirements will draw a clear distinction between IP and Hybrid components
Control of front-panel brightness and other front-panel controls such as LED displays, power-button and similar controls will be specified as part of the Comcast Manufacturer Interface Specification.
The answer can be "extsrc is used to faciliate easy development work. If it is preferred otherwise, there is a XXX-nosrc.xml manifest file which will be retained after the first build and hence saving time
Many developments & improvements happening in RDK .Few are listed below.
For latest updates see Announcements at https://wiki.rdkcentral.com/ page and " What is the Roadmap for the RDK?" question in this page to know about the Roadmap of RDK.
What this does:
In gerrit the changes will be put up for review in the branch you specified in your git review command (master or stable2). At the same time it will set the Topic field to the name of your local branch (i.e. my_special_changes). When gerrit sees topic fields with identical names it binds them together. So it forces project maintainers to press the "Submit Together" button so they go in at the same time once given +2.
Install SDK if it is not already installed by following the steps under the previous heading. Install Groovy version 2.0.7 / 2.0.6 (until M75)using the below command
sdk install groovy 2.0.6
Check groovy version :
From M76 release onwards, the supported groovy version is groovy 2.3.0. Install SDK if it is not already installed by following the steps under the previous heading. Install Groovy version 2.3.0 using the below command –
Check groovy version :
Follow are the commands to install MySQL
mysql installation will ask for the password during installation. (give the root password)
If validate_password plugin is present for Mysql, set the password policy as LOW using the below command
Login to mysql prompt
It will ask for password, give the root password given during installation.
There is no size restrictions imposed by RDK as such, the limits depends on SoC and OEM factors including Flash size. The firmware image will be compressed using SquashFS with LZMA compression.
No advanced options are currently supported by the IARM. It is mainly an event bus with a pub/sub metaphor. A lot of what is available is driven by the need. If some of the features are needed we should see a feature request. We are open to discussion of improvement as long as there is a case for it. No metrics have been captured at this time outside of the overall cloud metrics where IARM is part of the overall latency.
The various components in RDK have dependencies on other components, and some of these have similar functions. As long as the claims on memory and other system resources is small (e.g., Mongoose is a single file) it may be expedient to retain these redundant components.
It is optional and some devices is known to have HDMI 2.0 such as accelerator.
Checkout relevant code repos based on your requirements from https://code.rdkcentral.com/r/admin/repos
Help & Support
Still not able to find what you are looking for? Please reach out to RDK Support by sending an email to support@rdkcentral.com .
DISCLAIMER: Please note that the use of the RDK Wiki is subject to its Privacy Policy & Terms of Use. In addition, this Wiki may be accessed by all RDK licensees and their contractors.
Powered by a free Atlassian Confluence Open Source Project License granted to Cognizant United States. Evaluate Confluence today.