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.
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto