Date: Fri, 29 Mar 2024 00:09:20 +0000 (UTC) Message-ID: <152323263.17502.1711670960121@localhost> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_17501_1906641746.1711670960120" ------=_Part_17501_1906641746.1711670960120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page provides the details and gu= idance 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.
The first step to get a fully func= tional product is to define the product features and see if they meet the s= tandard requirements. See here to know what are all the = features available in RDK-V and can implement based on your requirement. Op= erator can use this as a guide while engineering the RDK Operator platform.=
Operators can make use of the deta= ils available below to start d= eveloping a Yocto build to do the final additions of Operator specific chan= ges to the device. This will help Operator to add their own final product f= eatures as well as Operator specific patches/changes.
Yocto based RDK builds are flexib= le 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 Yo= cto build layers, meta layers , rdk as well as open source components that = needs to be fetched during initial stages ( than during bitbake time ) as w= ell 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
To match the layered structure of= Yocto builds, a Operator specific layer is used to include Operator change= s and additions. Use the yoct= o-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-&l= t;soc name>
The device (machine) configuration file shall include corresponding incl= ude (.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' .
To add a machine configuration, you need to add a .conf file with detail= s 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 multipl= e append files. Operator can add the Operator layer details to required pac= kage group append files applicable to the target device build to get the fe= atures into the final build
Operators will be having a range of Operator specific applications from = simple generic device information apps to Operator specific content applica= tions. RDK's Yocto based layered structure allows Operators to easily integ= rate, 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 deta= ils.
Follow the below steps to get Lightning UI running in devices:
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 gen= eric 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 easi= ly 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 A= pp 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 im= age 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 O= perator type.
Provisioning support refers to the= scenario such as when you launch Sample app on your mobile it takes to log= in 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 str= ategy, could add support for this in the device. While there are some gener= ic 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.= span>
Once the device engineering is completed from Operator side, the device = can be test and verified easily by the Certification support provided by RD= KM. Details of coverage as well as major cases are explained here (only for RDK licensee) .
Certification suite is available a= t RDK IP Set-top Pro= duct Certification (only fo= r RDK licensee) and for TDK test app please refer = TDK-V Documentation.
In short, to get an RDK based dev= ice to field, Operators need to get