Page History

...

Step 1 : Get a board with Linux and drivers

RDK is based on yocto Yocto based linux distribution so SoC vendors has to get a board that is running on linux which is a SoC version of linux with the required drivers that are needed to run all the hardware that are associated in the board like Wifi. Linux version that is having can be optimzed and hardened by linux kernal kernel can be hardened by SoC vendor itself because RDK is not dealing with hardening Linux in the SOC port so whatever is required is the job of SoC like how to hardening, how to make it secure those things it is are the responsibility of SoC vendor. Mostly they SoC vendors will be having linux for on their board with required drivers.

...

Step 2 : Move the build to Yocto, compare it to supported Yocto version of RDK

RDK is based on yocto Yocto build setup so if their SoC vendor build is not based on yocto so Yocto then they need to migrate to yocto Yocto format so that they can easily adopt on top of it. In case they are not doing it will be little difficult for them then they have to first port the complete RDK and later keep the patches. So ,it is always recommended to port yocto /migrate to Yocto on top of their build system, recommended way is to convert their linux distribution to a yocto Yocto based build.

Yocto 3.1 Upgradation support the following:

• Version upgrades for bitbake, GStreamer , and other OE components

• Linux kernel 5.4 or above

• Extensible SDK

...

For example, RDK considers hardware floating point in platform where as some platforms are on software based floating point.

Specific DISTRO_FEATURES added to add build time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "

...

Meta layers : -  meta-openembedded, openembedded-core, meta-rdk-ext, meta-rdk, meta-cmf

Step 5 : Move the RDK recipes to platform

...

Yocto build

For platform specific recipes, keep them in oemOEM/soc SOC meta layer. Usually manifest of the most recent deployed device of same class can be used as reference for creating initial manifest. 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, sdkSDK, 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 within 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 socSoC, oem OEM layers in the build

• Any unwanted recipes during early stage of bring up can be masked using BBMASK, if needed.

Step 6 : Get a successful build

...