Page History

...

Step 1 : Get a board with Linux and drivers

RDK is based on 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 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 are the responsibility of SoC vendor. Mostly SoC vendors will be having linux on their board with required drivers.Add platform/OEM specific Machine DISTRO config file to set the build distribution. For example: meta-cmf-raspberrypi/conf/machine/raspberrypi-rdk-broadband.conf .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.

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

RDK is based on Yocto build setup so if Once SoC vendor build is not based on Yocto then they need to migrate to Yocto format so that they can easily adopt on top of it. In case they are not doing then they have to first port the complete RDK and later keep the patches. So ,it is always recommended to port/migrate to Yocto on top of their build system, recommended way is to convert their linux distribution to a Yocto based build.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:

...

Each component in RDK is a standalone repository with its own individual build tools producing a library or set of binaries. When we upgrade the OE layers are upgraded to the newer versions, we necessary changes need to make necessary changes be made in the RDK Yocto meta layers which use these components, to avoid build failures.

Step 3 : Compare and verify the compiler flags used in RDK and in platform to avoid issues

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 add support build time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "

Step 4 : Compare the open source versions used in platform as different versions will cause problems

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.

...

For platform specific recipes, keep them in OEM/ SOC meta layer. Usually manifest of the most recent deployed device of same class 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 reference for creating initial manifesta 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

...