[meta-freescale] The updated proposal of FSL Yocto layers reorg - 4-Mar
B19537 at freescale.com
Sun Mar 3 19:48:10 PST 2013
I have incorporated the comments of previous discussion into the reorg design document, please take a look.
Summary of Yocto reorg
* To support Layerscape release, both ARM architecture and PPC architecture are required to be supported by Yocto.
* Currently Yocto support for i.MX SDK and QorIQ SDK are developed and maintained separately, some duplicated packages are not shared between ARM SDK and PPC SDK. And will not be efficient and effective maintained for Layerscape support.
* More clear naming of Yocto layers for FSL specific will be helpful for PPC, ARM and Layercape support simultaneously.
* Subsequent slides introduces the plan and design of FSL Yocto layers re-org.
FSL Yocto Layers Reorg Diagram
FSL Yocto Layers Reorg - Stage1
* Stage1: ~ Jun-2013
* Following layers will coexist:
poky: the opensource version
meta-oe: the opensource branch corresponding to poky
meta-virtualization: the opensource virtualization layer
meta-fsl-ppc-toolchain: fsl toolchain recipes
meta-fsl-ppc: fsl public packages for PPC targets
meta-fsl-ppc-private: fsl private packages for PPC targets
meta-fsl-arm: fsl packages for ARM targets
meta-fsl-demos: demo rootfs recipes of ARM targets
meta-fsl-networking: recipes specific to networking SDK
Other necessary upstream layers
FSL Yocto Layers Reorg - Stage2
* Stage2: Jul-2013 ~ Dec-2013
* Following change will be made:
Poky/meta-oe/meta-virtualization for opensource are reused
Following architecture specific layers are maintained in git.am.freescale.net, git.freescale.com and git.yoctoproject.org
meta-fsl-arm: layer for FSL arm machines
meta-fsl-ppc: layer for FSL ppc machines
Following SDK specific layers are maintained in git.am.freescale.net and git.freescale.com
meta-fsl-toolchain: layer for fsl toolchain recipes
meta-fsl-multimedia: layer for multimedia SDK
meta-fsl-networking: layer for networking SDK
meta-fsl-layerscape: layer for layerscape SDK
FSL Yocto Layers Reorg - More info
* Layer of getting layers specific to Freescale SDK
* Layer name: meta-freescale-sdk
* The function of this layer is similar as https://github.com/Freescale/fsl-community-bsp-platform and it is maintained in FSL internal/external git tree
* A branch is created for each FSL SDK release to include the scripts to fetch necessary layers of specified version
* Multiple branch maintain
* Align with the branch policy of poky: denzil, danny, master ...
* A tag of sub-layers will be created for each FSL release
* Upstream / public branches will try to work with all Yocto releases, while SDK releases could contain a lot of hacks to more things working, or pre-release things out there door.
* SDK releases sometimes skip entire Yocto releases (e.g. danny). SDK versions may contain slightly different versions. This comes into play more with oe-core where we don't have official control and we need to include a specific fix for the SDK. Layers themselves tend to have less reason to deviate from the upstream versions since we control both sides so they should be the same.
* Meta-fsl-toolchain layer maintain
* This layer is maintained in FSL internal/external git tree
* Directory structure:
* Unify the mailing list of FSL layers
* Opensource: meta-freescale at yoctopoject.org<mailto:meta-freescale at yoctopoject.org>
* U-boot/Linux on FSL official git tree (git.freescale.com)
* The source in git.freescale.com will be updated when SDK is formally released, since full verification should be conducted to ensure quality. So Kernel in FSL official git tree will not be synced with internal git tree during the developing phase.
* The kernel team can't have everything upstreamed for an SDK release and supporting all feature and bug fixes. Besides we will pick a kernel and test and fix it so it will always fall out of sync. (e.g. latest kernel release - 1 release + fixes).
* Yocto sync on git.am.freescale.net, gitfrescale.com and git.yoctoproject.org
* These should be much closer to the same for the layers we control. Due to the limited resources spread around, we can't always get all fixes in the oe-core/poky for an SDK release timely. But a lot of times we can get them into the branch for that release and eventually a point release. Upstream/public branches will try to work with all Yocto releases, while SDK releases could contain a lot of hacks to more things working.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 88970 bytes
More information about the meta-freescale