[meta-freescale] The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

Hello all,



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

[yocto-re-org.png]



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:

      meta-fsl-toolchain

      |-- meta-gcc4.6-eglib2.13-binutils-2.21a

      |-- meta-gcc4.7-eglib2.15-binutils-2.23

* SCM

  * 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.





Best Regards,



Zhenhua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130304/f716eacd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 88970 bytes
Desc: image002.jpg
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130304/f716eacd/attachment.jpg>