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.

...

Add platform/OEM specific Machine DISTRO config file to set the build distribution. For example: meta-cmf-raspberrypi/conf/machine/raspberrypi-rdk-broadband.conf .

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

RDK is based on yocto build setup so if their is not based on yocto so they need to migrate to 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 to first port the complete RDK and later keep the patches. So ,it is always recommended to port yocto on top of , recommended to convert their linux distribution to a yocto based build.

...

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 to the newer versions, we need to make necessary changes 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

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 "

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

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

Step 5 : Move the RDK recipes to platform yocto build

For platform specific recipes, keep them in oem/soc meta layer

...

• 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 within 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

Step 6 : Get a successful build

Add platform specific main recipe to create image.

...

...

.

Components that has HAL layer implementation that needs to be ported by SoC vendors :

...