RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Papers & Presentations Archive
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 86 Next »
RDK is a community-based project that enables developers, vendors, and cable operators to utilize a defined stack of software on one layer for provisioning set-top boxes and gateways. Unique features of RDK, such as its commitment to open source, the speed, and flexibility of RDK-based devices, set it apart from conventional set-top software stacks.
The standardized RDK‐V stack provides a common method for managing complex video and management functions, including rendering, content, content security, device management, networking, and peripherals.
The RDK‐V Feature List is categorized based on the following functions. Enhancements and new features are developed and contributed asynchronously by members of the RDK Community.
The device dependency in this context meant that the feature is only available in some OEM devices and not generally available in raspberry pi like reference devices.
Category | Feature | Description | Supported by IP/Hybrid/TV | Dependency (If any) |
Conditional Access | DRM | PlayReady 4.4 | IP STB, Hybrid STB, and TV | Device Dependency |
Widevine 16 | IP STB, Hybrid STB, and TV | Device Dependency | ||
Common SVP | IP STB, Hybrid STB, and TV | Device Dependency | ||
Support HTML5 encrypted video via EME v3 for Widevine | IP STB, Hybrid STB, and TV | Device Dependency | ||
Conditional Access | Verimatrix | Hybrid | Device Dependency | |
AnyCAS | Hybrid | Device Dependency | ||
CommScope CableCard Decrypt, PPV Ready | Hybrid | Device Dependency | ||
Technicolor CableCard Decrypt, PPV Ready | Hybrid | Device Dependency | ||
DTCP | DTCP integration | Hybrid-media client | No | |
Device Security | Input sanitization | IP STB, Hybrid STB, and TV | NO | |
Upgrade to OpenSSL 1.1.1.l | IP STB, Hybrid STB, and TV | NO | ||
Upgrade to NTP 4.2.8.p11 | IP STB, Hybrid STB, and TV | NO | ||
Run applications in a secure container | IP STB, Hybrid STB, and TV | NO | ||
Secure bootloader | IP STB, Hybrid STB, and TV | Device Dependency | ||
Security | DAC (Containerization) using Dobby | IP STB, Hybrid STB, and TV | NO | |
Rialto | IP STB, Hybrid STB, and TV | NO | ||
Packager (Lisa) | IP STB, Hybrid STB, and TV | NO | ||
AppArmor | IP STB, Hybrid STB, and TV | NO | ||
Kernel Hardening | IP STB, Hybrid STB, and TV | Device Dependency | ||
Build & Platform | Yocto version | Yocto 3.1 (Dunfell) | IP STB, Hybrid STB, and TV | NO |
Kernel | Android common kernel | IP STB, Hybrid STB, and TV | NO | |
Init system | Systemd v244 (Yocto 3.1) | IP STB, Hybrid STB, and TV | NO | |
Application Manager | RDK Shell | IP STB, Hybrid STB, and TV | NO | |
Video Player | IP | UVE (AAMP) | IP STB, Hybrid STB, and TV | NO |
QAM | UVE via RMF (QAMSrc) | Hybrid STB | Device Dependency | |
DVB (Mediarite) | UVE via RMF | Hybrid STB | Device Dependency | |
DVB (DTVKit) | Sessionmanager via RMF | Hybrid STB | NO | |
TSB | Fog | IP STB, Hybrid STB, and TV | NO | |
DAC Apps | RIALTO | NO | ||
Content Related | Adaptive Bit Rate | HLS (HLS v3 and HLS v4) | IP STB, Hybrid STB, and TV | NO |
---|---|---|---|---|
MPEG-DASH | IP STB, Hybrid STB, and TV | NO | ||
HTML-5 Video (MSE/ESE) | IP STB, Hybrid STB, and TV | NO | ||
MPEG-DASH (Native) | IP STB, Hybrid STB, and TV | NO | ||
Audio Output Formats | Stereo | IP STB, Hybrid STB, and TV | NO | |
Dolby Digital | IP STB, Hybrid STB, and TV | Device Dependency | ||
Dolby ATMOS | IP STB, Hybrid STB, and TV | Device Dependency | ||
Dolby Digital Plus (7.1 Channels) | IP STB, Hybrid STB, and TV | Device Dependency | ||
Split HDMI and SPDIF audio outputs | IP STB, Hybrid STB, and TV | Device Dependency | ||
Bit stream Pass-through | IP STB, Hybrid STB, and TV | Device Dependency | ||
Dolby MS12 | IP STB, Hybrid STB, and TV | Device Dependency | ||
Audio Tracks | SAP, DVS | IP STB, Hybrid STB, and TV | Device Dependency | |
Codecs | H264 | IP STB, Hybrid STB, and TV | NO | |
MPEG2, VP8, VP9, High Efficiency Video Coding (HEVC) (H.265/MPEG-H Part 10) | IP STB, Hybrid STB, and TV | Device Dependency | ||
HDR 10 Bit (HEVC HLS) for IP settop | IP STB, Hybrid STB, and TV | Device Dependency | ||
Captions | 608, 708,subtec VTT | IP STB, Hybrid STB | Region Dependency | |
Delivery | Broadcast, Video on Demand | IP STB, Hybrid STB, and TV | NO | |
Video over Wi-Fi Ready | IP STB, Hybrid STB, and TV | Device Dependency | ||
Secondary Audio Output to Bluetooth devices | IP STB, Hybrid STB, and TV | Device Dependency | ||
IP Multiroom Music Playback (STB to Speakers) | IP STB, Hybrid STB, and TV | Device Dependency | ||
DVB | Broadcast DVB support | Hybrid STB, and TV | Device Dependency | |
Subtitles | IP STB | Device Dependency | ||
Teletext | Hybrid STB, and TV | Device Dependency | ||
In-Band System Information | Hybrid | Device Dependency | ||
EAS | QAM EAS | Hybrid | NO | |
IP EAS | TV | NO | ||
UHD/4K | RDKServices for 4K and HDR capability information across devices | IP STB, Hybrid STB, and TV | Device Dependency | |
Supports IP Time Shift Buffer for DASH Linear content | IP STB, Hybrid STB, and TV | NO | ||
Content Delivery | Video Input Formats | MPEG2, H.264, VP8 (h264 for RPI4) | TV,IP STB | NO |
Video Output Resolutions | 480i(not in amlogic), 480p, 720p, 1080i, 1080p | IP STB, Hybrid STB, and TV | NO | |
Ultra HD/4K, Advanced High Dynamic Range (HDR) | IP STB, Hybrid STB, and TV | Device Dependency | ||
Dolby Vision Advanced HDR for VOD | IP STB, Hybrid STB, and TV | Device Dependency | ||
HDR 10 | IP STB, Hybrid STB, and TV | Device Dependency | ||
Video Over WiFi | UPnP | IP STB, Hybrid STB, and TV | NO | |
VOD | IP VOD | IP STB, Hybrid STB, and TV | NO | |
Ad Insertion | Ad Insertion | Client Side Ad Insertion (Linear Segmented Advertisement) | Hybrid STB | Device Dependency |
Server side Ad Insertion | IP STB | Cloud Dependency | ||
Ad Insertion – Linear Segmented Advertising | LSA support for ad content read failure | Hybrid STB | Cloud Dependency | |
LSA support for back-to-back ads | Hybrid STB | Cloud Dependency | ||
IP DAI | Handle DASH IP VOD Dynamic Ad Insertion (DAI) Transitions | IP STB and TV | Cloud Dependency | |
Rendering | Framework | Firebolt V1.0 | IP STB, Hybrid STB, and TV | NO |
Ripple | IP STB, Hybrid STB, and TV | NO | ||
Lightning V2.8 | IP STB, Hybrid STB, and TV | NO | ||
QT for BLE V5.1.1 OSS version | IP STB, Hybrid STB, and TV | NO | ||
Core Thunder framework Version R2 | IP STB, Hybrid STB, and TV | NO | ||
Browser - WPEWebkit V2.28 | IP STB, Hybrid STB, and TV | NO | ||
Browser Engine | QT WebKit | IP STB, Hybrid STB, and TV | NO | |
WebKit Pure Embedded integration | IP STB, Hybrid STB, and TV | NO | ||
Connection Security | SSL/TLS | IP STB, Hybrid STB, and TV | NO | |
Plugins | WebRTC | IP STB, Hybrid STB, and TV | NO | |
Graphics | OpenGL ES | IP STB, Hybrid STB, and TV | NO | |
Rendering | ESSOS with Westeros | IP STB, Hybrid STB, and TV | NO | |
Gstreamer | Gstreamer 1.18 | IP STB, Hybrid STB, and TV | NO | |
Device Management | Feature Control | Securing RFC parameters via encryption | IP STB, Hybrid STB, and TV | NO |
RFC with Xconf rules | IP STB, Hybrid STB, and TV | NO | ||
Firmware Download Enhancements | Omit IP Address From Xconf Firmware Download Request | IP STB, Hybrid STB, and TV | NO | |
Firmware Upgrade-SWUpdate with XConf and Webpa | IP STB, Hybrid STB, and TV | NO | ||
Logging | TFTP Log Upload, HTTP Log Upload | IP STB, Hybrid STB, and TV | Cloud Dependency | |
Distribute (smear) logging uploads (dependent on XCONF Server) | IP STB, Hybrid STB, and TV | Cloud Dependency | ||
Memory Optimization | Use Flash/SD Card for Firmware Download Temporary Storage (CDL scratchpad) | IP STB, Hybrid STB, and TV | Device Dependency | |
Platform Enhancements | Common WiFi HAL for RDK Video | IP STB, Hybrid STB, and TV | NO | |
Converge to GCC V9.3x for all Yocto versions | IP STB, Hybrid STB, and TV | NO | ||
Power | Standby, Light Sleep | IP STB, Hybrid STB, and TV | NO | |
Deep Sleep on IP Clients | IP STB and TV | Device Dependency | ||
Power Save | Supports ability to enable HDMI port while in standby mode | IP STB, Hybrid STB, and TV | Device Dependency | |
Remote Management | TR-069 | IP STB, Hybrid STB, and TV | Cloud Dependency | |
WebPA (IP Clients) | IP STB | NO | ||
WebPA (QAM Clients) | Hybrid STB | NO | ||
ssh (secure shell into the device)/ reverse ssh (send trigger to have device initiate ssh) | IP STB, Hybrid STB, and TV | Cloud Dependency | ||
Feature Control (Remotely enable/ disable individual features on devices without new code deployment) | IP STB, Hybrid STB, and TV | Cloud Dependency | ||
Resource Optimization | Improved handling of app termination/suspension conditions (based on available memory rather than concurrency) | IP STB, Hybrid STB, and TV | NO | |
Revenant | Persistent WiFi Enable/Disable | IP STB, Hybrid STB, and TV | NO | |
Self Healing | Supports hardware self test | IP STB, Hybrid STB, and TV | Device Dependency | |
Thermal Monitoring and Shutdown | IP STB, Hybrid STB, and TV | NO | ||
Telemetry | Telemetry 2.0 (via WebPA) | NO | ||
TR-181 Object Telemetry | IP STB, Hybrid STB, and TV | Cloud Dependency | ||
IP Video Telemetry | IP STB, Hybrid STB, and TV | NO | ||
WiFi Band & AP Steering | Dual Band WiFi | IP STB and TV | NO | |
Networking | WAN IP | eSTB IPv4 | IP STB, Hybrid STB, and TV | NO |
IPv6 for IP clients | IP STB, Hybrid STB, and TV | NO | ||
LAN IP | Auto IP, DHCP, Dual Virtual | Hybrid STB | NO | |
Wi-Fi | IP STB, Hybrid STB, and TV | NO | ||
LAN | IP STB, Hybrid STB, and TV | NO | ||
Wi-Fi | WPA Enterprise (IP settop to use Wi-Fi 802.1x authentication) Ready | IP STB and TV | Device Dependency | |
Ports/Peripherals | Audio Output Ports | Bluetooth Audio Output Ready | IP STB, Hybrid STB, and TV | Device Dependency |
HDMI | HDMI Out, HDCP Enforcement, | IP STB, Hybrid STB, and TV | NO | |
HDMI In | TV | Device Dependency | ||
HDMI Consumer Electronics Control (HDMI-CEC) Power Sync | IP STB, Hybrid STB, and TV | NO | ||
HDMI Switching (Combine CEC and HDMI Input features to enable advanced switching) | TV | Device Dependency | ||
USB | WebRTC Camera Ready | IP STB, Hybrid STB, and TV | Device Dependency | |
USB Port Detection and Control Ready | IP STB, Hybrid STB, and TV | Device Dependency | ||
USB Camera Support Ready | IP STB, Hybrid STB, and TV | Device Dependency | ||
WebRTC HW acceleration for encode/decode to enhance performance | IP STB, Hybrid STB, and TV | NO | ||
USB Filesystem Support | IP STB, Hybrid STB, and TV | NO | ||
USB Hot-plug | IP STB, Hybrid STB, and TV | NO | ||
User Input | Voice Stack | IP STB, Hybrid STB, and TV | NO | |
RF4CE remote | IP STB, Hybrid STB, and TV | Device and Cloud Dependency | ||
BLE voice remote | IP STB, Hybrid STB, and TV | NO | ||
External Audio support | IP STB, Hybrid STB, and TV | Device Dependency | ||
IR Remote | IP STB, Hybrid STB, and TV | Device Dependency | ||
Voice Remote (RF4CE based) Ready | IP STB, Hybrid STB, and TV | Device and Cloud Dependency | ||
Video Output Ports | HDMI | IP STB, Hybrid STB, and TV | NO | |
Apps | Streaming Apps | YouTube V23 and Amazon Prime V4 | IP STB, Hybrid STB, and TV | Device Dependency |
TV Settings | Power, Standby | TV | NO | |
LED | TV | NO | ||
Zoom, aspect ratio | TV | NO | ||
AQ/PQ | QoS | TV | NO | |
Screen cast | Application Casting & control | DIAL V2.2.1 | IP STB, Hybrid STB, and TV | NO |
UI/UX | Reference App | IP STB, Hybrid STB, and TV | NO | |
Gaming | HDMI-CEC DAL - Dynamic Auto Lipsync | TV | NO | |
Low Latency Game Mode for HDMI Input | TV | NO | ||
Game Mode, Auto Low Latency Mode | TV | NO | ||
AQ/PQ | TV | Device dependency | ||
Digital Assistant (Voice) | Alexa (Push to talk) | IP STB, Hybrid STB, and TV | NO | |
Voice enabled Bluetooth remote | IP STB, Hybrid STB, and TV | NO | ||
Voice Assistant | IP STB, Hybrid STB, and TV | Device dependency |
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/.
This guide provides step-by-step instructions for bringing up RDK using a Raspberry Pi as the target device. The document covers the necessary hardware & build setup, build instructions, and detailed flashing instructions to get your Raspberry Pi ready to run the RDK software.
The RDK port for Raspberry Pi makes the RDK software stack available on a popular hardware device. Raspberry Pi (RPI) for RDK-V supports Dunfell builds. A variety of images based on requirements can be built for RPI, such as Media Client, Media Gateway Hybrid, and IP Client STB.
Git- 1.8.3.1 or greater Python- 3.8.10 tar- 1.24 or greater
The instructions provided below are meant to be executed via the command line on an Ubuntu machine.
# essential package installation # super user mode is required # major essential packages sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib g++-multilib build-essential chrpath socat bison curl cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm
sudo dpkg-reconfigure dash
Select “No”.
To choose bash, when the prompt asks if you want to use dash as the default system shell - select “No”.
Upgrade your Git version to 1.8.x or higher.
Once git is installed, configure your name and email using the below commands.
# review your existing configuration git config --list --show-origin # configure user name and email address git config --global user.name "John Doe" git config --global user.email johndoe@example.com # configure git cookies. Needed for Gerrit to only contact the LDAP backend once. git config --global http.cookieFile /tmp/gitcookie.txt git config --global http.saveCookies true
In order to use Yocto build system, first you need to make sure that repo is properly installed on the machine:
# create a bin directory mkdir ~/bin export PATH=~/bin:$PATH # Download the repo tool and ensure that it is executable curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo
*Note: it is also recommended to put credentials in .netrc when interacting with the repo.
A sample .netrc file is illustrated below.
machine code.rdkcentral.com login <YOUR_USERNAME> password <YOUR_PASSWORD> |
---|
# initialize the manifest with repo tool repo init -u https://code.rdkcentral.com/r/manifests -b 6.0.0 -m rdkv.xml repo sync --no-clone-bundle --no-tags MACHINE=raspberrypi4-64-rdk-android-mc source meta-cmf-raspberrypi/setup-environment bitbake lib32-rdk-generic-mediaclient-wpe-image # To build tdk image bitbake lib32-rdk-generic-mediaclient-wpe-tdk-image
The generated image resides under the directory build-<MACHINE>/tmp/deploy/images/<MACHINE>
of the Yocto workspace.
This section outlines two methods for flashing: Flashing the SD Card (flashing steps in a Linux environment) and using balenaEtcher App (flashing in Windows).
1. Insert an SD card in the SD card port of the USB SD card reader (or Laptop).
(Prefer to use a 32gb SD card and there should be minimum 12gb free space available in the device.)
2. Verify that the SD card has been detected by executing either of the commands listed below.
$lsblk $sudo fdisk –l
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 350M 0 part ├─sda2 8:2 0 3G 0 part ├─sda3 8:3 0 896.4G 0 part / ├─sda4 8:4 0 1K 0 part └─sda5 8:5 0 31.8G 0 part [SWAP] sdb 8:16 1 14.9G 0 disk ├─sdb1 8:17 1 40M 0 part /media/raspberrypi └─sdb2 8:18 1 552M 0 part /media/dd5efb34-1d40-4e50-bbc2-a75d3e02af97 sr0 11:0 1 1024M 0 rom
$mount
$ mount /dev/sda3 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) none on /tmp/guest-zdrO76 type tmpfs (rw,mode=700) gvfs-fuse-daemon on /var/lib/lightdm/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lightdm) /dev/sdb1 on /media/raspberrypi type vfat (rw,nosuid,nodev,uid=136,gid=148,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks) /dev/sdb2 on /media/dd5efb34-1d40-4e50-bbc2-a75d3e02af97 type ext3 (rw,nosuid,nodev,uhelper=udisks)
$umount <partition-mountpoint>
$ sudo umount /dev/sdb1 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 350M 0 part ├─sda2 8:2 0 3G 0 part ├─sda3 8:3 0 896.4G 0 part / ├─sda4 8:4 0 1K 0 part └─sda5 8:5 0 31.8G 0 part [SWAP] sdb 8:16 1 14.9G 0 disk ├─sdb1 8:17 1 40M 0 part └─sdb2 8:18 1 552M 0 part /media/dd5efb34-1d40-4e50-bbc2-a75d3e02af97 sr0 11:0 1 1024M 0 rom $ sudo umount /dev/sdb2 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 350M 0 part ├─sda2 8:2 0 3G 0 part ├─sda3 8:3 0 896.4G 0 part / ├─sda4 8:4 0 1K 0 part └─sda5 8:5 0 31.8G 0 part [SWAP] sdb 8:16 1 14.9G 0 disk ├─sdb1 8:17 1 40M 0 part └─sdb2 8:18 1 552M 0 part sr0 11:0 1 1024M 0 rom
$sudo dd if=<path to ImageName.Rpi-sdimg> of=<path to SD card space> bs=4M Example: $sudo dd if=rdk-generic-mediaclient-wpe-image.Rpi-sdimg of=/dev/sdb bs=4M 149+0 records in 149+0 records out 624951296 bytes (625 MB) copied, 39.7752 s, 15.7 MB/s
To flash the image on an SD card, you will need to download the balenaEtcher application-https://www.balena.io/etcher/ .
*Note: Prefer to use a 32GB SD card and there should be a minimum of 12GB of free space available in the device. Be sure to remove all other portable flash drives/hard drives/SD cards from your computer before flashing the RDK image.
Once image flashing is done, remove the SD card from the device/laptop and insert the SD card into the microSD card slot on the underside of your Raspberry Pi.
Power on the Raspberry Pi.
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 primary function of the Yocto Project within RDK development is the building and packaging of multiple components. RDK leverages the capabilities of the Yocto Project to create customized Linux-based software distributions that power devices like set-top boxes, smart TVs etc. To fully understand the concepts presented in this document, it is recommended to read RDK Yocto Build System Overview - DOCUMENTATION - RDK Central Wiki as an introduction to the concepts explored in this document.
The starting point for the Yocto build is a manifest file. The manifest file is an xml file that contains details of the different layers (including their repository URL, target location where they need to be downloaded and any specific version - like branch or tag - which need to be used ) that needs to be fetched during initial stages of the builds. The manifest file will be usually used to download the repositories with details of meta layers and build configurations. A set of sample manifests that can be used as a template for developing vendor specific manifests are given below ( along with sample manifest for OEM and third party)
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 OEM and , optionally, some OEM 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 |
Folder overview in Yocto for RDK-V:
meta-rdk-video/recipes-connectivity
: This folder consists of recipes related to connectivity functionalities. These recipes provide components and utilities for establishing and managing network connections in RDK-V.
meta-rdk-video/recipes-graphics
: This folder contains recipes for graphics-related components in RDK-V. It includes recipes for graphical user interfaces (GUIs), graphics libraries, and rendering engines.
meta-rdk-video/recipes-multimedia
: This folder includes recipes for multimedia components in RDK-V. It covers recipes for audio playback, recording, multimedia frameworks, and related utilities.
meta-rdk-video/recipes-core
: This folder contains core recipes that are essential for RDK-V. It includes recipes for core system components, utilities, and configurations.
meta-rdk-video/recipes-extended
: This folder includes additional recipes that extend the functionality of RDK-V. It covers recipes for various extended components, tools, and services.
meta-rdk-video/recipes-support
: This folder contains recipes for support components in RDK-V. It includes recipes for debugging tools, logging utilities, and other support-related functionalities.
meta-rdk-video/recipes-devtools
: This folder contains recipes that provide development tools and utilities in RDK-B. These tools assist in the development and debugging processes, making it easier to build, test, and analyze the software.meta-rdk/recipes-video
: This folder contains recipes related to video components in RDK-V. It includes recipes for video playback, streaming, codecs, and other video-related functionalities.
meta-rdk-video/conf:
conf files define various settings and variables that control the build process and customize the resulting embedded Linux system. It consists of distro and layer.conf file.This document focuses on the example of the RDK video devicesettings module.The devicesettings module provides functionality related to device settings management within the context of the Raspberry Pi platform and the RDK (Reference Design Kit) video meta-layer.
devicesettings comes under these layers: meta-cmf-raspberrypi, meta-cmf-video, meta-rdk-video.
devicesettings module is structured as:
meta-rdk-video
| └── recipes-extended
| └── devicesettings
| ├── devicesettings_git.bb
| └── devicesettings-hal-headers_git.bb
|
meta-cmf-raspberrypi
└── meta-rdk-video
└── recipes-extended
└── devicesettings
├── devicesettings_git.bbappend
└── devicesettings-hal-raspberrypi_git.bb
The devicesettings recipe, represented by "devicesettings_git.bb", is responsible for building the devicesettings package from the corresponding source code. It defines the necessary build steps, dependencies, and configurations to create the devicesettings package, and in "devicesettings-hal-headers_git.bb", hal-specific definitions are available.
Also for devicesettings, certain overrides exist in other meta layers, which can be device specific, here we are focusing on raspberrypi device, there are dedicated recipe specific to the 'raspberrypi' hardware abstraction layer (HAL) and append file.
Below are some of the important parameters present in the recipes:
Parameters | Description |
---|---|
SRC_URI | URI of source code, patches and extra files to be used to build packages. Uses different fetchers based on the URI. |
DEPENDS/RDEPENDS_${PN} | Build time and run time package dependencies, where ${PN} represents the package name defined in the recipe. |
CFLAGS/CXXFLAGS/LDFLAGS | environment variables commonly used in software development to specify compilation and linking options for C and C++ programs |
do_install(), do_configure_prepend(), do_compile() | These are integral parts of the build process, they enable developers to customize the configuration, compilation, and installation steps of software packages, providing flexibility and control over the build process. |
Parameters in append file-
The *. bbappend file provided above is specifying additional CFLAGS (compiler flags) for the build process.
The line CFLAGS += " -DHAS_HDCP_CALLBACK -DHAS_FLASH_PERSISTENT"
adds two specific compiler flags to the existing CFLAGS.
-DHAS_HDCP_CALLBACK
: This flag defines the macro HAS_HDCP_CALLBACK
, which indicates that the build should include support for HDCP (High-bandwidth Digital Content Protection) callback functionality.
-DHAS_FLASH_PERSISTENT
: This flag defines the macro HAS_FLASH_PERSISTENT
, indicating that the build should include support for persistent storage on Flash memory.
In this example, we are referring to the above mentioned append file. Similarly, if we need to include any additional modifications to the recipe, we can do so by adding them in the append file within the SOC and OEM layers.
To build the devicesettings module, execute the following command with Bitbake:"bitbake lib32-devicesettings"
We can add the Install task bitbake command, which can be helpful if modifications have been made to the devicesettings source code and there is a need to copy the resulting binaries and libraries from the devicesettings build directory to the target system. The following command can be used:
Install bitbake -c install -f devicesettings
If someone needs to execute a task-wise module, the following commands can be used:
Action | Bitbake command |
---|---|
configure | bitbake -c configure -f lib32-devicesettings |
compilation | bitbake -c compile -f lib32-devicesettings |
cleanall | bitbake -c cleanall lib32-devicesettings |
cleansstate | bitbake -c cleansstate lib32-devicesettings |
If we want to list down rdkv specific components- Execute bitbake -s it will list down all the components.
During the image creation phase of the build process, package groups are added to organize and include related packages in the final image.
devicesettings module is included in:
meta-rdk/recipes-core/packagegroup/packagegroup-rdk-media-common.bb
Target image name:-
Image name | Description |
---|---|
rdk-generic-hybrid-image | A generic RDK build for hybrid devices with QAM-based tuners, enabling streaming and broadcasting of QAM content. |
rdk-oss-image | An RDK image based on open-source software components, providing flexibility and customization options. |
rdk-generic-mediaclient-image | A generic RDK build for media client devices capable of streaming IP-based or QAM content from hybrid devices. |
rdk-generic-ipclient-image | A generic RDK build for IP client devices, suitable for scenarios where an RDK license is not mandatory. |
Yocto build Image target names are of format- <RDK vendor>-<profile>-<build-type>-<developer>-image
Example-
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.wic
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.wic.bz2
rdk-generic-mediaclient-wpe-image_FBT_6.0.0-rc4_20231108131757.rootfs.tar.gz
When facing errors or failures while executing a bitbake action, such as compilation or configuration errors, the specific log files can be found in the following directory structure:
Path: build-raspberrypi4-64-rdk-android-ipmc/tmp/work/raspberrypi4_64_rdk_android_ipmc-rdk-linux/devicesettings/5+gitr999-r0/temp/
Example
log.do_compile: This file contains the error logs related to the compilation process. It provides information about any issues encountered during the translation of source code into executable or object files.
log.do_configure: This file contains the error logs associated with the configuration step. It helps identify any problems encountered while setting up the build configuration, such as missing dependencies or incorrect settings.
ERROR: lib32-devicesettings-5+gitr999-r0 do_compile: oe_runmake failed ERROR: Logfile of failure stored in: ~/rpi_build/raspberrypi4-64-rdk-hybrid/tmp/work/armv7at2hf-neon-vfpv4-rdkmllib32-linux-gnueabi/lib32-devicesettings/5+gitr999-r0/temp/log.do_compile.4085187
The provided example demonstrates a compilation error in the "devicesettings" package. The details of the error can be found in the specified log file, which can be analyzed by searching for the keyword "error".
The path provided in the example is specific to the mentioned build environment. In your actual working environment, the paths may differ depending on the build system or project structure you are using.
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
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 Support
RDK Source Code
API Documentation
RDK V Releases
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 RDKCentral. Evaluate Confluence today.