[yocto] Looking at using Yocto, have General Adoption questions

[Khem Raj]

Hi Richard

On 5/9/18 1:03 PM, Richard Koch wrote:
> Hello list.
> 
> I'm looking for some general use cases for how a firmware development 
> team such as ourselves has adopted Yocto in to their non-Yocto based 
> environment.
> 
> We have a group of firmware developers that currently develop for 
> various iMX6 based
> controller boards. For those boards we have not been using Yocto but 
> utilize a patched kernel and u-boot from the SOM mfr.
> We then modified those and developed our own rootfs (manually).
> 
> Our build is source controlled through SVN. We use Linaro based ARM 
> cross compilers to
> build u-boot/kernel and our applications. This is packaged up in to a 
> .deb file and installed
> as an upgrade on to an SDCard that already contains a baseline 
> u-boot/kernel/rootfs.
> 
> We have requirements for a new design that we would like to base off of 
> the NXP MCIMX7D-SABRE eval board.
> For this eval board there is a suggested BSP that to use which is Yocto 
> based.
> 
> I have followed NXP's Yocto guide to download, configure, and build an 
> SDCard image which boots
> successfully on this eval board.
> 
> The Yocto build consumed ~26GB of disk space and took most of the day to 
> build on an i7 Quad 32GB Ubuntu 16.04 PC.
> 
> So I am wondering how to introduce this to our current build environment 
> and development team.
> I understand the concept is to take the imx7dsabresd recipe/meta-layer/? 
> and port that to our own design.
> 
> After successfully porting the eval BSP to our own design;
> 
> How does a team of developers such as ourselves:
> 

I would suggest that you generate a eSDK, then let your teams use eSDK 
for doing development, configure a CI system which is integrating the 
changes and creating updates for extensible SDK, the diskspace and build 
time is first one investment you would do thereafter it would be 
incremental on the builder, for your dev teams it would be all prebuilt 
and they would only build the things they change

https://wiki.yoctoproject.org/wiki/Extensible_SDK
https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK


> Control the source code changes?

There are several ways you can do it, use a sandbox tool like android 
repo to manage the project, where you create local mirrors of upstream 
nxp layers repos and create your internal branches for yourself which 
follow the corresponding upstream branches. Then you can manually merge 
or cherry-pick changes from upstream repositories as you wish to do.
You can also use git submodules to manage the project

If you dont make any changes to upstream layers then you might not want 
to create local branches and still use something like android repo or 
git submodules to manage the project.

see following for git-submodule based example

https://github.com/cbrake/oe-build/

IIRC NXP already uses repo to manage projects but here is another example

https://github.com/Angstrom-distribution/angstrom-manifest


> Do we check/convert the whole Yocto git repo in to our SVN or is there a 
> suggested way to trim down to a manageable subset?

It would be better if you were to use git for SCM since merging/syncing 
would become so much streamlined but you can use SVN if you have to, you 
might not be able to use the workspace management tools like above but 
you can still use something like gclient probably

> How do we update our new recipe/meta-layer/? when the NXP 
> recipe/meta-layer/? we derived it from changes upstream due to 
> security/bug fixes?


see above

> 
> Appreciate any advice,
> 

hope that helps. Feel free to ask further questions.