The aim of this SoC porting guide is to guide SoC Vendors on how to port RDK to their platforms.

Step 1 : Get a board with Linux and drivers

RDK is based on Yocto Linux. Prior to porting RDK on an SoC, the precondition is to have the SoC platform running on Linux. The Linux version can be a SoC-specific one with kernel 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 the SoC platform, like WiFi, so that the unit can work independently and completely from an SoC point of view.

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

Once the SoC vendor is ready with its 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 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.

Step 3 : Compare and verify the compiler flags used in RDK and in the 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 the target platform( For example, RDK considers hardware floating point in the platform whereas some platforms are on software-based floating point ). SoC vendors 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 the build-time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "

Step 4 : Compare the open-source versions used in a 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, the vendor needs to make required changes to make the open-source version match the RDK requirements as best as possible, by adding required patches in SoC platform 

Check below layers for all open-sourced 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

Step 5 : Move the RDK recipes to platform Yocto build

For platform-specific recipes, keep them in the SoC meta-layer. While it is a good practice to start afresh with a new manifest for the target platform, a 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 - toolchain, SDK, kernel, drivers, etc.. to corresponding SoC Gerrit repos/ artifactory as applicable
• Populate meta SoC layer with the initial set of changes needed to build a kernel, SoC components, etc.
• If there is any SoC reference board exists, create a corresponding machine configuration in the SoC layer, and create an image target to be able to build a final image for the reference board. This layer should be separated out within the meta SoC layer from other common SoC, common chip sub-layers which will be usually used by the 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 the "NEEDED_BSPLAYERS" field to include required SoC, OEM layers in the build
• Any unwanted recipes during the early stage of bringing up can be masked using BBMASK if needed.

Step 6: Get a successful build

Add a platform-specific main recipe to create an image.

HAL implementation by SoC