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

[Otavio Salvador]

On Mon, Mar 4, 2013 at 12:48 AM, Luo Zhenhua-B19537
<B19537 at freescale.com> wrote:
>
> Hello all,


First, I'd like to thank you to avoid the big attachment in the
e-mail. It does make everyone's life easier.

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


Great.

> 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

I thought meta-fsl-layerscape would merge with meta-fsl-networking and
BSP part to be in meta-fsl-arm (as Vybrid).

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

It is still not clear to me what would be included here. Can you
please give a example directory structure for reference?

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

This is already done.

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

This is bad specially because people end redoing a lot of work which
has already been done. If you could make it public but marked as
experimental it'd be great as it would allow more people to help to
track down possible issues and would make the development more
community friendly.

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

Sorry, I fail to understand what you mean here. Do you mind to explain it to me?

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

Yes I think a level of divergence is unavoidable but it should be kept
at minimum.

Regards,

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br