The updated proposal of FSL Yocto layers reorg - 4-Mar

The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

[-- Attachment #1.1: Type: text/plain, Size: 4799 bytes --]

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@yoctopoject.org<mailto:meta-freescale@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

[-- Attachment #1.2: Type: text/html, Size: 15499 bytes --]

[-- Attachment #2: image002.jpg --]
[-- Type: image/jpeg, Size: 80017 bytes --]

Re: 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@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@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@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> Behalf Of Otavio Salvador
> >
> >   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).
[Luo Zhenhua-B19537] multimedia, networking and layerscape are for different SDKs specific bits. The common recipes will be put into meta-fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot, kernel, etc). Please elaborate if I don't fully follow your comments.

> > * 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?
[Luo Zhenhua-B19537] This layer is same as https://github.com/Freescale/fsl-community-bsp-platform, a manifest and a README are included. 

> > * 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.
[Luo Zhenhua-B19537] I understand your concern. This might be related to the FSL source code delivery/upstream process, we can have further internal discussion. 

> >  * 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?
[Luo Zhenhua-B19537] Not every kernel patch in FSL SDK can be upstreamed timely due to different reasons. 

> >  * 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.
[Luo Zhenhua-B19537] Agree to minimize the gap. 


Best Regards,

Zhenhua

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Otavio Salvador]

On Thu, Mar 7, 2013 at 4:32 AM, Luo Zhenhua-B19537 <B19537@freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>> Behalf Of Otavio Salvador
>> >
>> >   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).
> [Luo Zhenhua-B19537] multimedia, networking and layerscape are for different SDKs specific bits. The common recipes will be put into meta-fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot, kernel, etc). Please elaborate if I don't fully follow your comments.

I understand now but could you give an example of specific thing which
would go to layerscape layer?

>> > * 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?
> [Luo Zhenhua-B19537] This layer is same as https://github.com/Freescale/fsl-community-bsp-platform, a manifest and a README are included.

In this case the naming is bad. I'd call it fsl-sdk or fsl-bsp. The
meta prefix is used for layers and it is not going to be the case as
it will be a ready to use solution which groups a set of layers.

>> > * 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.
> [Luo Zhenhua-B19537] I understand your concern. This might be related to the FSL source code delivery/upstream process, we can have further internal discussion.

That'd be good. It'd make contributions much easier from/for the community.

>> >  * 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?
> [Luo Zhenhua-B19537] Not every kernel patch in FSL SDK can be upstreamed timely due to different reasons.

Well due license compliance point of view it do need to be make
available after you give it for a partner/customer as it is the start
of the distribution phase. I understand some changes does need much
more time for review and proper testing but if those could go to a
specific branch or tree which is widely known it is not official
release and not supported, it might alleviate the problem.

>> >  * 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.
> [Luo Zhenhua-B19537] Agree to minimize the gap.

Regards,

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

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> Behalf Of Otavio Salvador
> 
> >> >   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).
> > [Luo Zhenhua-B19537] multimedia, networking and layerscape are for
> different SDKs specific bits. The common recipes will be put into meta-
> fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot,
> kernel, etc). Please elaborate if I don't fully follow your comments.
> 
> I understand now but could you give an example of specific thing which
> would go to layerscape layer?
[Luo Zhenhua-B19537] what I can imagine is layerscape distro conf file, udev rules of ethernet port rename, demo rootfs image recipes, maybe more...

> >> > * 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?
> > [Luo Zhenhua-B19537] This layer is same as
> https://github.com/Freescale/fsl-community-bsp-platform, a manifest and a
> README are included.
> 
> In this case the naming is bad. I'd call it fsl-sdk or fsl-bsp. The meta
> prefix is used for layers and it is not going to be the case as it will
> be a ready to use solution which groups a set of layers.
[Luo Zhenhua-B19537] how about fsl-yocto-sdk to differentiate with other packaging tools, e.g. LTIB?


Best Regards,

Zhenhua

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Otavio Salvador]

On Fri, Mar 8, 2013 at 4:04 AM, Luo Zhenhua-B19537 <B19537@freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>> Behalf Of Otavio Salvador
>>
>> >> >   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).
>> > [Luo Zhenhua-B19537] multimedia, networking and layerscape are for
>> different SDKs specific bits. The common recipes will be put into meta-
>> fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot,
>> kernel, etc). Please elaborate if I don't fully follow your comments.
>>
>> I understand now but could you give an example of specific thing which
>> would go to layerscape layer?
> [Luo Zhenhua-B19537] what I can imagine is layerscape distro conf file, udev rules of ethernet port rename, demo rootfs image recipes, maybe more...

udev rules can be add to BSP depending on how they're used. However
all this seems more meta-fsl-networking thingy than a specific SDK.

>> >> > * 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?
>> > [Luo Zhenhua-B19537] This layer is same as
>> https://github.com/Freescale/fsl-community-bsp-platform, a manifest and a
>> README are included.
>>
>> In this case the naming is bad. I'd call it fsl-sdk or fsl-bsp. The meta
>> prefix is used for layers and it is not going to be the case as it will
>> be a ready to use solution which groups a set of layers.
> [Luo Zhenhua-B19537] how about fsl-yocto-sdk to differentiate with other packaging tools, e.g. LTIB?

It works fine; my main concern is with the 'meta' prefix as it gives
the wrong message to user.

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

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Matthew McClintock]

On Fri, Mar 8, 2013 at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Fri, Mar 8, 2013 at 4:04 AM, Luo Zhenhua-B19537 <B19537@freescale.com> wrote:
>>> -----Original Message-----
>>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>>> Behalf Of Otavio Salvador
>>>
>>> >> >   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).
>>> > [Luo Zhenhua-B19537] multimedia, networking and layerscape are for
>>> different SDKs specific bits. The common recipes will be put into meta-
>>> fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot,
>>> kernel, etc). Please elaborate if I don't fully follow your comments.
>>>
>>> I understand now but could you give an example of specific thing which
>>> would go to layerscape layer?
>> [Luo Zhenhua-B19537] what I can imagine is layerscape distro conf file, udev rules of ethernet port rename, demo rootfs image recipes, maybe more...
>
> udev rules can be add to BSP depending on how they're used. However
> all this seems more meta-fsl-networking thingy than a specific SDK.

Why is layerscape a new SDK? Won't it fall under the networking umbrella?

The same images, etc should be generated from the networking SDK. You
can tweak MACHINE_EXTRA_RECOMMENDS type things for different hardware
but that should be minimal and ideally under one umbrella layer.

-M

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Bob Cochran]

On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
> Hello all,
>
> I have incorporated the comments of previous discussion into the reorg
> design document, please take a look.
>

Zhenhua,

What's the plan for this reorg design document?  I would very much like 
to see Freescale keep this document maintained & synced with the repos & 
SDK releases as time progresses & development continues.  Otherwise, 
your intent may be forgotten and the actual implementation & direction 
may drift off into the woods....

Bob

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Eric Bénard]

Hi Zhenhua,

Le Mon, 4 Mar 2013 03:48:10 +0000,
Luo Zhenhua-B19537 <B19537@freescale.com> a écrit :
-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.
> 
it would be great to keep a public work in progress branch so that users
can get fixes and test them (even if this branch is not officially
supported).
For example, continuing to push patches to this branch for 2.6.35
based BSP :
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain
seems interesting (and having a similar _maintain branch for i.MX6
seems also interesting).

Best regards,
Eric

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

Bob, 

There is a draft plan in the proposal, the stage1 is planned to be completed in June of 2013, and the finish time of stage2 is end of 2013.

When the proposal gets the final agreement, we will create the detailed plan and keep git repos/development progress/SDK releases synced with our plan.

Actually, we have begun the development, you can see some reorg changes n http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/log/.


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Sunday, March 10, 2013 11:20 PM
> To: Luo Zhenhua-B19537
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
> reorg - 4-Mar
> 
> On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
> > Hello all,
> >
> > I have incorporated the comments of previous discussion into the reorg
> > design document, please take a look.
> >
> 
> Zhenhua,
> 
> What's the plan for this reorg design document?  I would very much like
> to see Freescale keep this document maintained & synced with the repos &
> SDK releases as time progresses & development continues.  Otherwise, your
> intent may be forgotten and the actual implementation & direction may
> drift off into the woods....
> 
> Bob
> 

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

Hi Eric, 

Thanks for your good suggestion. 


Best Regards,

Zhenhua


> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Tuesday, March 12, 2013 1:33 AM
> To: Luo Zhenhua-B19537
> Cc: meta-freescale@yoctoproject.org; Wang Larry-B38019; Mahadevan Mahesh-
> R9AADQ; Angolini Daiane-B19406; Schmitt Richard-B43082; Trefny Thomas-
> RAT188
> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
> reorg - 4-Mar
> 
> Hi Zhenhua,
> 
> Le Mon, 4 Mar 2013 03:48:10 +0000,
> Luo Zhenhua-B19537 <B19537@freescale.com> a écrit :
> -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.
> >
> it would be great to keep a public work in progress branch so that users
> can get fixes and test them (even if this branch is not officially
> supported).
> For example, continuing to push patches to this branch for 2.6.35 based
> BSP :
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
> imx.git/log/?h=imx_2.6.35_maintain
> seems interesting (and having a similar _maintain branch for i.MX6 seems
> also interesting).
> 
> Best regards,
> Eric

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Matthew McClintock]

Can we convert this to a text file and check it into the git repo ASAP?

-M

On Mon, Mar 11, 2013 at 9:27 PM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> Hi Eric,
>
> Thanks for your good suggestion.
>
>
> Best Regards,
>
> Zhenhua
>
>
>> -----Original Message-----
>> From: Eric Bénard [mailto:eric@eukrea.com]
>> Sent: Tuesday, March 12, 2013 1:33 AM
>> To: Luo Zhenhua-B19537
>> Cc: meta-freescale@yoctoproject.org; Wang Larry-B38019; Mahadevan Mahesh-
>> R9AADQ; Angolini Daiane-B19406; Schmitt Richard-B43082; Trefny Thomas-
>> RAT188
>> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
>> reorg - 4-Mar
>>
>> Hi Zhenhua,
>>
>> Le Mon, 4 Mar 2013 03:48:10 +0000,
>> Luo Zhenhua-B19537 <B19537@freescale.com> a écrit :
>> -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.
>> >
>> it would be great to keep a public work in progress branch so that users
>> can get fixes and test them (even if this branch is not officially
>> supported).
>> For example, continuing to push patches to this branch for 2.6.35 based
>> BSP :
>> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
>> imx.git/log/?h=imx_2.6.35_maintain
>> seems interesting (and having a similar _maintain branch for i.MX6 seems
>> also interesting).
>>
>> Best regards,
>> Eric
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

Sure, I can create a text version, any suggestion on which git tree should the file reside in?


Best Regards,

Zhenhua


> -----Original Message-----
> From: Matthew McClintock [mailto:msm-oss@mcclintock.net]
> Sent: Tuesday, March 12, 2013 12:02 PM
> To: Luo Zhenhua-B19537
> Cc: Eric Bénard; Wang Larry-B38019; Mahadevan Mahesh-R9AADQ; Angolini
> Daiane-B19406; Schmitt Richard-B43082; meta-freescale@yoctoproject.org;
> Trefny Thomas-RAT188
> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
> reorg - 4-Mar
> 
> Can we convert this to a text file and check it into the git repo ASAP?
> 
> -M
> 
> On Mon, Mar 11, 2013 at 9:27 PM, Luo Zhenhua-B19537 <B19537@freescale.com>
> wrote:
> > Hi Eric,
> >
> > Thanks for your good suggestion.
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >
> >> -----Original Message-----
> >> From: Eric Bénard [mailto:eric@eukrea.com]
> >> Sent: Tuesday, March 12, 2013 1:33 AM
> >> To: Luo Zhenhua-B19537
> >> Cc: meta-freescale@yoctoproject.org; Wang Larry-B38019; Mahadevan
> >> Mahesh- R9AADQ; Angolini Daiane-B19406; Schmitt Richard-B43082;
> >> Trefny Thomas-
> >> RAT188
> >> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto
> >> layers reorg - 4-Mar
> >>
> >> Hi Zhenhua,
> >>
> >> Le Mon, 4 Mar 2013 03:48:10 +0000,
> >> Luo Zhenhua-B19537 <B19537@freescale.com> a écrit :
> >> -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.
> >> >
> >> it would be great to keep a public work in progress branch so that
> >> users can get fixes and test them (even if this branch is not
> >> officially supported).
> >> For example, continuing to push patches to this branch for 2.6.35
> >> based BSP :
> >> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
> >> imx.git/log/?h=imx_2.6.35_maintain
> >> seems interesting (and having a similar _maintain branch for i.MX6
> >> seems also interesting).
> >>
> >> Best regards,
> >> Eric
> >
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Otavio Salvador]

On Tue, Mar 12, 2013 at 6:28 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> Sure, I can create a text version, any suggestion on which git tree should the file reside in?

Maybe a new one? You could use
https://en.wikipedia.org/wiki/ReStructuredText so we can easily
generate a document from it.

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

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Matthew McClintock]

On Tue, Mar 12, 2013 at 7:46 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Mar 12, 2013 at 6:28 AM, Luo Zhenhua-B19537
> <B19537@freescale.com> wrote:
>> Sure, I can create a text version, any suggestion on which git tree should the file reside in?
>
> Maybe a new one? You could use

Maybe an empty meta-freescale? Ha, that's a good point on where it should live.

Maybe just in the YP / OE wiki?

-M

> https://en.wikipedia.org/wiki/ReStructuredText so we can easily
> generate a document from it.
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Otavio Salvador]

On Tue, Mar 12, 2013 at 11:45 AM, Matthew McClintock
<msm-oss@mcclintock.net> wrote:
> On Tue, Mar 12, 2013 at 7:46 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Mar 12, 2013 at 6:28 AM, Luo Zhenhua-B19537
>> <B19537@freescale.com> wrote:
>>> Sure, I can create a text version, any suggestion on which git tree should the file reside in?
>>
>> Maybe a new one? You could use
>
> Maybe an empty meta-freescale? Ha, that's a good point on where it should live.
>
> Maybe just in the YP / OE wiki?

YP Wiki seems like a good place; my main concern is if it'd be
considered *official* from FSL point of view.

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

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Bob Cochran]

On 03/12/2013 10:50 AM, Otavio Salvador wrote:
>   my main concern is if it'd be
> considered*official*  from FSL point of view.

How about utilizing the blank "about tab" on the fsl public git site?

http://git.freescale.com/git/cgit.cgi/?p=about

Your yocto layers reorg impacts both the yocto and the fsl public git 
site, correct?

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

[Bob Cochran]

Hi Zhenhua,

Can we get an update on Layerscape?  It's been about 6 months since the 
Yocto layers organization for Layerscape was last talked about on this 
board.

When will we first see an instance of the stage 2 organization (e.g., 
meta-fsl-layerscape) in the yocto project source repos 
(http://git.yoctoproject.org/cgit/cgit.cgi/)?

Thanks,

Bob




On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
> 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@yoctopoject.org
> <mailto:meta-freescale@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
>
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

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

[Luo Zhenhua-B19537]

Hi Bob,

We are working on the recipes of Layerscape, the first LS SDK will be released in the early of 2014. The LS common recipes will be submitted to meta-fsl-ppc/meta-fsl-arm when LS is formally released. 

Regarding meta-fsl-layerscape, it can be published in YP official git repository(http://git.yoctoproject.org/cgit/cgit.cgi/) and FSL official git repository(http://git.yoctoproject.org/cgit/cgit.cgi/)?) if no internal git url is referred. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Monday, September 30, 2013 9:54 AM
> To: Luo Zhenhua-B19537
> Cc: Yocto discussion list
> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
> reorg - 4-Mar
> 
> Hi Zhenhua,
> 
> Can we get an update on Layerscape?  It's been about 6 months since the
> Yocto layers organization for Layerscape was last talked about on this
> board.
> 
> When will we first see an instance of the stage 2 organization (e.g.,
> meta-fsl-layerscape) in the yocto project source repos
> (http://git.yoctoproject.org/cgit/cgit.cgi/)?
> 
> Thanks,
> 
> Bob
> 
> 
> 
> 
> On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
> > 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@yoctopoject.org
> > <mailto:meta-freescale@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
> >
> >
> >
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
> >
> 

Re: The updated proposal of FSL Yocto layers reorg - 4-Mar

[Luo Zhenhua-B19537]

Hi Bob,

We are working on the recipes of Layerscape, the first LS SDK will be released in the early of 2014. The LS common recipes will be submitted to meta-fsl-ppc/meta-fsl-arm when LS is formally released. 

Regarding meta-fsl-layerscape, it can be published in YP official git repository(http://git.yoctoproject.org/cgit/cgit.cgi/) and FSL official git repository(http://git.yoctoproject.org/cgit/cgit.cgi/)?) if no internal git url is referred. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Monday, September 30, 2013 9:54 AM
> To: Luo Zhenhua-B19537
> Cc: Yocto discussion list
> Subject: Re: [meta-freescale] The updated proposal of FSL Yocto layers
> reorg - 4-Mar
> 
> Hi Zhenhua,
> 
> Can we get an update on Layerscape?  It's been about 6 months since the
> Yocto layers organization for Layerscape was last talked about on this
> board.
> 
> When will we first see an instance of the stage 2 organization (e.g.,
> meta-fsl-layerscape) in the yocto project source repos
> (http://git.yoctoproject.org/cgit/cgit.cgi/)?
> 
> Thanks,
> 
> Bob
> 
> 
> 
> 
> On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
> > 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@yoctopoject.org
> > <mailto:meta-freescale@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
> >
> >
> >
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
> >
>