The Yocto layer re-architect for FSL QorIQ SDK

The Yocto layer re-architect for FSL QorIQ SDK

[zhenhua.luo]

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]

Hi all,



Along with the Layerscape ARM platforms support in QorIQ SDK, there are more and more common recipes for QorIQ PPC targets and QorIQ Layerscape ARM targets, to avoid the duplicated recipes which are maintained in fsl-arm and fsl-ppc layer separately, and make the layers hierarchical for FSL QorIQ SDK, the unified top layer(meta-fsl-qoriq) and corresponding sub-layers(meta-arm and meta-ppc) mechanism is proposed.



Following is the structure of the meta-fsl-qoriq layer.

meta-fsl-qoriq

|--- common                   # the common recipes for QorIQ ARM and PPC targets

|--- conf

|    |--- layar.conf          # the layer conf file of top layer

|--- COPYING                  # the license file of FSL QorIQ layer

|--- meta-arm                 # the sub-layer for recipes specific to QorIQ ARM targets

|    |--- conf

|    |    |--- layer.conf     # the layer conf file of QorIQ ARM sub-layer

|    |    |--- machine        # the machine conf files of QorIQ ARM platforms

|    |--- README              # README of QorIQ ARM sub-layer

|    |--- recipes-...           # the recipes of QorIQ ARM targets

|--- meta-ppc                 # the sub-layer for recipes specific to QorIQ PPC targets

|    |--- conf

|    |    |--- layer.conf     # the layer conf file of QorIQ PPC sub-layer

|    |    |--- machine        # the machine conf files of QorIQ PPC platforms

|    |--- README              # README of QorIQ PPC sub-layer

|    |--- recipes-...           # the recipes of QorIQ PPC targets

|--- meta-...                   # other layers for QorIQ SDK support, e.g. meta-toolchain

|--- README                   # README of top layer



The meta-fsl-ppc layer will be retired and replaced by the new meta-fsl-qoriq layer.



Can you please review? Your comments and suggestions are welcome.





Best Regards,



Zhenhua

[-- Attachment #2: Type: text/html, Size: 6511 bytes --]

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Daiane Angolini]

On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com
<zhenhua.luo@freescale.com> wrote:
> Hi all,
>
>
>
> Along with the Layerscape ARM platforms support in QorIQ SDK, there are more
> and more common recipes for QorIQ PPC targets and QorIQ Layerscape ARM
> targets, to avoid the duplicated recipes which are maintained in fsl-arm and
> fsl-ppc layer separately, and make the layers hierarchical for FSL QorIQ
> SDK, the unified top layer(meta-fsl-qoriq) and corresponding
> sub-layers(meta-arm and meta-ppc) mechanism is proposed.

When you say "sub-layers" do you mean you are going to have one layer
*inside* another?

Why do you think it´s a good idea? Why not having the sub-layer separated?

>
>
>
> Following is the structure of the meta-fsl-qoriq layer.
>
> meta-fsl-qoriq
>
> |--- common                   # the common recipes for QorIQ ARM and PPC
> targets

What is common? Can you provide an example?

Daiane
>
> |--- conf
>
> |    |--- layar.conf          # the layer conf file of top layer
>
> |--- COPYING                  # the license file of FSL QorIQ layer
>
> |--- meta-arm                 # the sub-layer for recipes specific to QorIQ
> ARM targets
>
> |    |--- conf
>
> |    |    |--- layer.conf     # the layer conf file of QorIQ ARM sub-layer
>
> |    |    |--- machine        # the machine conf files of QorIQ ARM
> platforms
>
> |    |--- README              # README of QorIQ ARM sub-layer
>
> |    |--- recipes-…           # the recipes of QorIQ ARM targets
>
> |--- meta-ppc                 # the sub-layer for recipes specific to QorIQ
> PPC targets
>
> |    |--- conf
>
> |    |    |--- layer.conf     # the layer conf file of QorIQ PPC sub-layer
>
> |    |    |--- machine        # the machine conf files of QorIQ PPC
> platforms
>
> |    |--- README              # README of QorIQ PPC sub-layer
>
> |    |--- recipes-…           # the recipes of QorIQ PPC targets
>
> |--- meta-…                   # other layers for QorIQ SDK support, e.g.
> meta-toolchain
>
> |--- README                   # README of top layer
>
>
>
> The meta-fsl-ppc layer will be retired and replaced by the new
> meta-fsl-qoriq layer.
>
>
>
> Can you please review? Your comments and suggestions are welcome.
>
>
>
>
>
> Best Regards,
>
>
>
> Zhenhua
>
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com <
zhenhua.luo@freescale.com> wrote:

>
>
>  Following is the structure of the meta-fsl-qoriq layer.
>
> meta-fsl-qoriq
>
> |--- common                   # the common recipes for QorIQ ARM and PPC
> targets
>
> |--- conf
>
> |    |--- layar.conf          # the layer conf file of top layer
>
> |--- COPYING                  # the license file of FSL QorIQ layer
>
> |--- meta-arm                 # the sub-layer for recipes specific to
> QorIQ ARM targets
>
> |    |--- conf
>
> |    |    |--- layer.conf     # the layer conf file of QorIQ ARM sub-layer
>
> |    |    |--- machine        # the machine conf files of QorIQ ARM
> platforms
>
> |    |--- README              # README of QorIQ ARM sub-layer
>
> |    |--- recipes-…           # the recipes of QorIQ ARM targets
>
> |--- meta-ppc                 # the sub-layer for recipes specific to
> QorIQ PPC targets
>
> |    |--- conf
>
> |    |    |--- layer.conf     # the layer conf file of QorIQ PPC sub-layer
>
> |    |    |--- machine        # the machine conf files of QorIQ PPC
> platforms
>
> |    |--- README              # README of QorIQ PPC sub-layer
>
> |    |--- recipes-…           # the recipes of QorIQ PPC targets
>
> |--- meta-…                   # other layers for QorIQ SDK support, e.g.
> meta-toolchain
>
> |--- README                   # README of top layer
>
>
>
> The meta-fsl-ppc layer will be retired and replaced by the new
> meta-fsl-qoriq layer.
>
>
>
> Can you please review? Your comments and suggestions are welcome.
>

I think it is too soon to talk about any reorganization of the layers. I am
still awaiting for the layers cleanup on the meta-fsl-ppc as several
recipes there belong to other layers (meta-networking, meta-oe and so on).

We also don't have the list of common recipes, so at this moment this is
still a guess about the common recipes.

LS1 is merged in fsl-arm so you can include it into FSL SDK in your git
submodules/supergit/repo file.

I see no benefit merging it, just cons ...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 3720 bytes --]

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Bob Cochran]

On 09/22/2014 08:51 AM, Otavio Salvador wrote:
>
>
> On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com
> <mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com
> <mailto:zhenhua.luo@freescale.com>> wrote:
>
>
>     __
>
>     Following is the structure of the meta-fsl-qoriq layer. __ __
>
>     meta-fsl-qoriq____
>
>     |--- common                   # the common recipes for QorIQ ARM and



[snip]


>     __ __
>
>     Can you please review? Your comments and suggestions are welcome.
>
>
> I think it is too soon to talk about any reorganization of the layers. I
> am still awaiting for the layers cleanup on the meta-fsl-ppc as several
> recipes there belong to other layers (meta-networking, meta-oe and so on).
>
> We also don't have the list of common recipes, so at this moment this is
> still a guess about the common recipes.
>
> LS1 is merged in fsl-arm so you can include it into FSL SDK in your git
> submodules/supergit/repo file.
>
> I see no benefit merging it, just cons ...


The benefit I see is that it logically groups all QorIQ parts together, 
which I believe is important.

When Freescale needs to provide support for LS2A (next generation) DPAA, 
the current organization will become a mess.  A lot (if not most) of the 
QorIQ BSP layer is for DPAA / networking, and I don't think it will make 
sense to have these duplicated in both meta-fsl-ppc and meta-fsl-arm, or 
have DPAA code that will be built for the ARM in meta-fsl-ppc (or vice 
versa).

I would hope that having this code organized in logical layers under the 
scope of QorIQ would make it more manageable in migrating from something 
like a TXXX device to an LS2A device.

However, I certainly understand you not wanting to change everything 
before there is stability in what we currently have.

I'm building with meta-fsl-ppc on a daily basis, but I'm not using 
anything else in the community tree (e.g., demos, meta-fsl-arm, repo, 
etc.) because my perception is it isn't ready for me as a QorIQ developer.

Zhenhua, when are you looking to make these changes?  Will this be a 
master-next sort of thing after the end of the year, or do you want to 
do all this now?


>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>
>

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Otavio Salvador]

On Mon, Sep 22, 2014 at 10:43 AM, Bob Cochran <yocto@mindchasers.com> wrote:
>
> On 09/22/2014 08:51 AM, Otavio Salvador wrote:
>>
>>
>>
>> On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com
>> <mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com
>> <mailto:zhenhua.luo@freescale.com>> wrote:
>>
>>
>>     __
>>
>>     Following is the structure of the meta-fsl-qoriq layer. __ __
>>
>>     meta-fsl-qoriq____
>>
>>     |--- common                   # the common recipes for QorIQ ARM and
>
>
>
>
> [snip]
>
>
>>     __ __
>>
>>     Can you please review? Your comments and suggestions are welcome.
>>
>>
>> I think it is too soon to talk about any reorganization of the layers. I
>> am still awaiting for the layers cleanup on the meta-fsl-ppc as several
>> recipes there belong to other layers (meta-networking, meta-oe and so on).
>>
>> We also don't have the list of common recipes, so at this moment this is
>> still a guess about the common recipes.
>>
>> LS1 is merged in fsl-arm so you can include it into FSL SDK in your git
>> submodules/supergit/repo file.
>>
>> I see no benefit merging it, just cons ...
>
>
>
> The benefit I see is that it logically groups all QorIQ parts together, which I believe is important.


This does not make sense, sorry. If this would be the case you'd merge
it in OE-Core as you also use GCC, GLibC and so on.

>
> When Freescale needs to provide support for LS2A (next generation) DPAA, the current organization will become a mess.  A lot (if not most) of the QorIQ BSP layer is for DPAA / networking, and I don't think it will make sense to have these duplicated in both meta-fsl-ppc and meta-fsl-arm, or have DPAA code that will be built for the ARM in meta-fsl-ppc (or vice versa).


FSL processors are the ONLY one in the World to provide DPAA? I will
provide two possible routes:

 - If FSL is the only DPAA provider, we make a mets-fsl-dpaa layer
 - If NOT we move DPAA to meta-networking layer where it seems to belong

> I would hope that having this code organized in logical layers under the scope of QorIQ would make it more manageable in migrating from something like a TXXX device to an LS2A device.

I have customers moving from/to TI and FSL, those use meta-ti and
fsl-arm in SAME setup with no issues. It is as easy as change the
machine name.

How users from meta-fsl-ppc will migrated for any new layer layout?
Freescale will break every product layer out there for no good reason,
it seems. The previous repository cannot be removed without critical
impacts.

...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Richard Schmitt]

>> Freescale will break every product layer out there for no good reason, it seems. The 
>> previous repository cannot be removed without critical impacts.

I don't see that.  Currently meta-fsl-ppc is only used by customers building for QorIQ based boards.  So essentially we are renaming meta-fsl-ppc to be meta-fsl-qoriq.

Then as we add our ARM support for LS1 and LS2, they will be BSPs under meta-fsl-qoriq.  

>> FSL processors are the ONLY one in the World to provide DPAA?

Yes, they are.  and logically it is possible for both our ARM and PPC products to support it.  It is why we want a meta-fsl-qoriq layer, so that we could put things like meta-fsl-dpaa in it.

We are trying to model the intel support.  There is a meta-intel layer with individual bsps and a common layer underneath it.

This seems to be the best approach to handle a collection of related products out there.

>> I think it is too soon to talk about any reorganization of the 
>> layers. I am still awaiting for the layers cleanup on the 
>> meta-fsl-ppc as several recipes there belong to other layers (meta-networking, meta-oe and so on).

That doesn't make sense to me.  The idea is to cleanup the layers as part of the restructuring.  Why would we want to do it as separate steps.  

>> I have customers moving from/to TI and FSL, those use meta-ti and fsl-arm in SAME 
>> setup with no issues. It is as easy as change the machine name.

That may be fine for generic arm boards, but our BSPs will be extending the generic architectures.

Rich

-----Original Message-----
From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
Sent: Monday, September 22, 2014 9:15 AM
To: Bob Cochran
Cc: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org; Schmitt Richard-B43082; Brownfield Phil-RTJE20; Weng White-B18292
Subject: Re: [meta-freescale] The Yocto layer re-architect for FSL QorIQ SDK

On Mon, Sep 22, 2014 at 10:43 AM, Bob Cochran <yocto@mindchasers.com> wrote:
>
> On 09/22/2014 08:51 AM, Otavio Salvador wrote:
>>
>>
>>
>> On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com 
>> <mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com 
>> <mailto:zhenhua.luo@freescale.com>> wrote:
>>
>>
>>     __
>>
>>     Following is the structure of the meta-fsl-qoriq layer. __ __
>>
>>     meta-fsl-qoriq____
>>
>>     |--- common                   # the common recipes for QorIQ ARM and
>
>
>
>
> [snip]
>
>
>>     __ __
>>
>>     Can you please review? Your comments and suggestions are welcome.
>>
>>
>> I think it is too soon to talk about any reorganization of the 
>> layers. I am still awaiting for the layers cleanup on the 
>> meta-fsl-ppc as several recipes there belong to other layers (meta-networking, meta-oe and so on).
>>
>> We also don't have the list of common recipes, so at this moment this 
>> is still a guess about the common recipes.
>>
>> LS1 is merged in fsl-arm so you can include it into FSL SDK in your 
>> git submodules/supergit/repo file.
>>
>> I see no benefit merging it, just cons ...
>
>
>
> The benefit I see is that it logically groups all QorIQ parts together, which I believe is important.


This does not make sense, sorry. If this would be the case you'd merge it in OE-Core as you also use GCC, GLibC and so on.

>
> When Freescale needs to provide support for LS2A (next generation) DPAA, the current organization will become a mess.  A lot (if not most) of the QorIQ BSP layer is for DPAA / networking, and I don't think it will make sense to have these duplicated in both meta-fsl-ppc and meta-fsl-arm, or have DPAA code that will be built for the ARM in meta-fsl-ppc (or vice versa).


FSL processors are the ONLY one in the World to provide DPAA? I will provide two possible routes:

 - If FSL is the only DPAA provider, we make a mets-fsl-dpaa layer
 - If NOT we move DPAA to meta-networking layer where it seems to belong

> I would hope that having this code organized in logical layers under the scope of QorIQ would make it more manageable in migrating from something like a TXXX device to an LS2A device.

I have customers moving from/to TI and FSL, those use meta-ti and fsl-arm in SAME setup with no issues. It is as easy as change the machine name.

How users from meta-fsl-ppc will migrated for any new layer layout?
Freescale will break every product layer out there for no good reason, it seems. The previous repository cannot be removed without critical impacts.

...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: The Yocto layer re-architect for FSL QorIQ SDK

[zhenhua.luo]

> -----Original Message-----
> From: angolini@gmail.com [mailto:angolini@gmail.com] On Behalf Of Daiane
> Angolini
> Sent: Monday, September 22, 2014 7:55 PM
> >
> > Along with the Layerscape ARM platforms support in QorIQ SDK, there
> > are more and more common recipes for QorIQ PPC targets and QorIQ
> > Layerscape ARM targets, to avoid the duplicated recipes which are
> > maintained in fsl-arm and fsl-ppc layer separately, and make the
> > layers hierarchical for FSL QorIQ SDK, the unified top
> > layer(meta-fsl-qoriq) and corresponding sub-layers(meta-arm and meta-ppc)
> mechanism is proposed.
> 
> When you say "sub-layers" do you mean you are going to have one layer
> *inside* another?
[Luo Zhenhua-B19537] There are two level layers in meta-fsl-qoriq, meta-fsl-qoriq the top layer which manages the common recipes for QorIQ targets, the second level layer is specific to cpu type: arm and ppc. I am not sure sub-layer is the best description for it. 

> Why do you think it´s a good idea? Why not having the sub-layer separated?
[Luo Zhenhua-B19537] This architecture manages recipes of QorIQ recipes in a unified top layer, users can find everything in one repository instead of fetch separate layers one by one, it also make the layers  hierarchical and clear: common bits, arm specific bits, ppc specific bits.  IMO, this structure can facilitate the maintenance and usage. All bits can be managed by one git repository instead of multiple. 

"meta-intel" is an example for those layer structure. 

> > |--- common                   # the common recipes for QorIQ ARM and PPC
> > targets
> 
> What is common? Can you provide an example?
[Luo Zhenhua-B19537] u-boot, linux, rcw, cst, qemu recipes can be shared by QorIQ ARM and QorIQ PPC targets, there will be more in future. 


Best Regards,

Zhenhua
 
> Daiane
> >
> > |--- conf
> >
> > |    |--- layar.conf          # the layer conf file of top layer
> >
> > |--- COPYING                  # the license file of FSL QorIQ layer
> >
> > |--- meta-arm                 # the sub-layer for recipes specific to QorIQ
> > ARM targets
> >
> > |    |--- conf
> >
> > |    |    |--- layer.conf     # the layer conf file of QorIQ ARM sub-layer
> >
> > |    |    |--- machine        # the machine conf files of QorIQ ARM
> > platforms
> >
> > |    |--- README              # README of QorIQ ARM sub-layer
> >
> > |    |--- recipes-…           # the recipes of QorIQ ARM targets
> >
> > |--- meta-ppc                 # the sub-layer for recipes specific to QorIQ
> > PPC targets
> >
> > |    |--- conf
> >
> > |    |    |--- layer.conf     # the layer conf file of QorIQ PPC sub-layer
> >
> > |    |    |--- machine        # the machine conf files of QorIQ PPC
> > platforms
> >
> > |    |--- README              # README of QorIQ PPC sub-layer
> >
> > |    |--- recipes-…           # the recipes of QorIQ PPC targets
> >
> > |--- meta-…                   # other layers for QorIQ SDK support, e.g.
> > meta-toolchain
> >
> > |--- README                   # README of top layer
> >
> >
> >
> > The meta-fsl-ppc layer will be retired and replaced by the new
> > meta-fsl-qoriq layer.
> >
> >
> >
> > Can you please review? Your comments and suggestions are welcome.
> >
> >
> >
> >
> >
> > Best Regards,
> >
> >
> >
> > Zhenhua
> >
> >
> > --
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
> >

Re: The Yocto layer re-architect for FSL QorIQ SDK

[zhenhua.luo]

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Monday, September 22, 2014 9:44 PM
> 
> On 09/22/2014 08:51 AM, Otavio Salvador wrote:
> >
> > On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com
> > <mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com
> > <mailto:zhenhua.luo@freescale.com>> wrote:
> >
> >     Can you please review? Your comments and suggestions are welcome.
> >
> >
> > I think it is too soon to talk about any reorganization of the layers.
> > I am still awaiting for the layers cleanup on the meta-fsl-ppc as
> > several recipes there belong to other layers (meta-networking, meta-oe and
> so on).
> >
> > We also don't have the list of common recipes, so at this moment this
> > is still a guess about the common recipes.
[Luo Zhenhua-B19537] Currently u-boot, linux, rcw, cst, apptrk, asf recipes can be shared by QorIQ ARM and QorIQ PPC targets, there will be more common packages in future. 

> > LS1 is merged in fsl-arm so you can include it into FSL SDK in your
> > git submodules/supergit/repo file.
[Luo Zhenhua-B19537] This is the method we used now, actually u-boot/linux/rcw recipes is duplicated in current fsl-arm and fsl-ppc layer,  the new meta-fsl-qoriq layer can avoid such duplication and manage the QorIQ recipes more logically. 

> > I see no benefit merging it, just cons ...
> 
> The benefit I see is that it logically groups all QorIQ parts together, which I
> believe is important.
> 
> When Freescale needs to provide support for LS2A (next generation) DPAA,
> the current organization will become a mess.  A lot (if not most) of the QorIQ
> BSP layer is for DPAA / networking, and I don't think it will make sense to have
> these duplicated in both meta-fsl-ppc and meta-fsl-arm, or have DPAA code
> that will be built for the ARM in meta-fsl-ppc (or vice versa).
> 
> I would hope that having this code organized in logical layers under the scope
> of QorIQ would make it more manageable in migrating from something like a
> TXXX device to an LS2A device.
> 
> However, I certainly understand you not wanting to change everything before
> there is stability in what we currently have.
[Luo Zhenhua-B19537] The new layer architecture is not conflict with the integration of meta-fsl-ppc, the work of fsl-ppc layer integration is on-going, we are preparing the patches of documents and fsl-ppc optimization, the ideal situation is to finish it for Yocto 1.7 release. This schedule might be deferred due to the tough schedule and limited resource. 
    When the meta-fsl-qoriq is ready, we can replace fsl-ppc with fsl-qoriq in the FSL community BSP. 

> I'm building with meta-fsl-ppc on a daily basis, but I'm not using anything else in
> the community tree (e.g., demos, meta-fsl-arm, repo,
> etc.) because my perception is it isn't ready for me as a QorIQ developer.
[Luo Zhenhua-B19537] With regard to the common bblayers.conf template, I think we can use a more flexible way to only add required layers for specific target instead of use the same bblayers.conf for all FSL targets. This can avoid including unnecessary layers and cross-impaction of layers.  

> Zhenhua, when are you looking to make these changes?  Will this be a master-
> next sort of thing after the end of the year, or do you want to do all this now?
[Luo Zhenhua-B19537] We want to make fsl-ppc stuffs in master instead of master-next, the original plan is to finish the fsl-ppc integration for Yocto 1.7, but the schedule might be deferred due to limited resource. I believe the work can be done this year.  

Regarding the new meta-fsl-qoriq layer, our goal is to make the layer ready for usage this year. 


Best Regards,

Zhenhua

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Otavio Salvador]

On Mon, Sep 22, 2014 at 11:32 AM, Richard Schmitt
<richard.schmitt@freescale.com> wrote:
>>> Freescale will break every product layer out there for no good reason, it seems. The
>>> previous repository cannot be removed without critical impacts.
>
> I don't see that.  Currently meta-fsl-ppc is only used by customers building for QorIQ based boards.  So essentially we are renaming meta-fsl-ppc to be meta-fsl-qoriq.
>
> Then as we add our ARM support for LS1 and LS2, they will be BSPs under meta-fsl-qoriq.

Yes and I have several customers using meta-fsl-ppc layer in their
projects. So it is unacceptable to drop meta-fsl-ppc from the Yocto
Project Git server. There are other ways to do it, if it is really
necessary, more about it later...

>>> FSL processors are the ONLY one in the World to provide DPAA?
>
> Yes, they are.  and logically it is possible for both our ARM and PPC products to support it.  It is why we want a meta-fsl-qoriq layer, so that we could put things like meta-fsl-dpaa in it.
>
> We are trying to model the intel support.  There is a meta-intel layer with individual bsps and a common layer underneath it.
>
> This seems to be the best approach to handle a collection of related products out there.

The Intel layer is not what I'd use as reference. If you see its
popularity it is quite suboptimal and they are doing a very horrible
job in the Intel Galileo and Intel Edison support. To be sincere I
think we are doing an amazingly better job in our community and been
succeed in getting more and more people interested in Freescale
products here.

I do think we may need to rework QorlQ structure but the proposed way
might impose fragmentation instead of providing a turn-key solution
for QorlQ users. In fact, most of platform users does not care if it
is a PPC or ARM core but if does fulfill their needs or not. The same
applies for Yocto Project tools.

I have a different view how to organize the layer basically merging
the QorlQ machines in a single layer but without Core CPU split; this
easies the visualization of layer and reusability a lot. I can help on
this if you like this approach.

>>> I think it is too soon to talk about any reorganization of the
>>> layers. I am still awaiting for the layers cleanup on the
>>> meta-fsl-ppc as several recipes there belong to other layers (meta-networking, meta-oe and so on).
>
> That doesn't make sense to me.  The idea is to cleanup the layers as part of the restructuring.  Why would we want to do it as separate steps.

Sorry but several recipes included in meta-fsl-ppc currently does not
belong there. There are network utilities, and etc. which  should be
moved out from it and submitted to meta-oe/meta-networking layer.

>>> I have customers moving from/to TI and FSL, those use meta-ti and fsl-arm in SAME
>>> setup with no issues. It is as easy as change the machine name.
>
> That may be fine for generic arm boards, but our BSPs will be extending the generic architectures.

Ideally yes, but this is not what happens nowadays. The metadata
provided by meta-fsl-ppc does not behave properly when used with other
layers. There has some progress on it as Luo and Ting has did some
work on this area, but we are still far from complete.

Richard, don't get me wrong, I understand what you're trying to
archive here and I agree with your goal. However we seem to disagree
on the steps to get there and I think the current proposed approach is
not the in a technical perspective.

I think it is impossible to accomplish this for 1.7 but I am willing
to help if you, and your team, are open to it. We need to discuss the
steps and get people actually doing them so we move to the right
direction.

Best Regards,

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: The Yocto layer re-architect for FSL QorIQ SDK

[Bob Cochran]

On 09/22/2014 10:32 AM, Richard Schmitt wrote:
>>> Freescale will break every product layer out there for no good reason, it seems. The
>>> previous repository cannot be removed without critical impacts.
>
> I don't see that.  Currently meta-fsl-ppc is only used by customers building for QorIQ based boards.  So essentially we are renaming meta-fsl-ppc to be meta-fsl-qoriq.
>
> Then as we add our ARM support for LS1 and LS2, they will be BSPs under meta-fsl-qoriq.
>
>>> FSL processors are the ONLY one in the World to provide DPAA?
>
> Yes, they are.  and logically it is possible for both our ARM and PPC products to support it.  It is why we want a meta-fsl-qoriq layer, so that we could put things like meta-fsl-dpaa in it.
>
> We are trying to model the intel support.  There is a meta-intel layer with individual bsps and a common layer underneath it.
>
> This seems to be the best approach to handle a collection of related products out there.
>
>>> I think it is too soon to talk about any reorganization of the
>>> layers. I am still awaiting for the layers cleanup on the
>>> meta-fsl-ppc as several recipes there belong to other layers (meta-networking, meta-oe and so on).
>
> That doesn't make sense to me.  The idea is to cleanup the layers as part of the restructuring.  Why would we want to do it as separate steps.


When can we expect to see the restructuring take place?

Also, can we please get a ballpark estimate on when further 
infrastructure support will come online as discussed in previous QorIQ 
planning emails (e.g., Zhenhua's "The proposal of FSL QorIQ SDK 
upstream" email on 7/16/14).

Specifically, I would like to get an idea on when I can expect to see 
the following:

• Setup public bug management system for FSL SDKs

• Setup an external mailing list for external git repository for FSL SDK 
discussion, patch submission, patch review.

Is this going to happen this year?  I don't know whether I should depend 
on this happening, but I view it as important to my project.

I have to believe that Freescale has internally numerous patches to 
SDK1.6 that they don't make available to their customers unless a 
service request is entered.  This is a tremendous duplication of effort 
and causes customer wheels to spin.  I'm counting on soon seeing a 
process in place that makes patches available to the 3.12 kernel that 
shipped with SDK1.6.  Am I being foolish?

thank you,

Bob





>
>>> I have customers moving from/to TI and FSL, those use meta-ti and fsl-arm in SAME
>>> setup with no issues. It is as easy as change the machine name.
>
> That may be fine for generic arm boards, but our BSPs will be extending the generic architectures.
>
> Rich
>
> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
> Sent: Monday, September 22, 2014 9:15 AM
> To: Bob Cochran
> Cc: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org; Schmitt Richard-B43082; Brownfield Phil-RTJE20; Weng White-B18292
> Subject: Re: [meta-freescale] The Yocto layer re-architect for FSL QorIQ SDK
>
> On Mon, Sep 22, 2014 at 10:43 AM, Bob Cochran <yocto@mindchasers.com> wrote:
>>
>> On 09/22/2014 08:51 AM, Otavio Salvador wrote:
>>>
>>>
>>>
>>> On Mon, Sep 22, 2014 at 7:20 AM, zhenhua.luo@freescale.com
>>> <mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com
>>> <mailto:zhenhua.luo@freescale.com>> wrote:
>>>
>>>
>>>      __
>>>
>>>      Following is the structure of the meta-fsl-qoriq layer. __ __
>>>
>>>      meta-fsl-qoriq____
>>>
>>>      |--- common                   # the common recipes for QorIQ ARM and
>>
>>
>>
>>
>> [snip]
>>
>>
>>>      __ __
>>>
>>>      Can you please review? Your comments and suggestions are welcome.
>>>
>>>
>>> I think it is too soon to talk about any reorganization of the
>>> layers. I am still awaiting for the layers cleanup on the
>>> meta-fsl-ppc as several recipes there belong to other layers (meta-networking, meta-oe and so on).
>>>
>>> We also don't have the list of common recipes, so at this moment this
>>> is still a guess about the common recipes.
>>>
>>> LS1 is merged in fsl-arm so you can include it into FSL SDK in your
>>> git submodules/supergit/repo file.
>>>
>>> I see no benefit merging it, just cons ...
>>
>>
>>
>> The benefit I see is that it logically groups all QorIQ parts together, which I believe is important.
>
>
> This does not make sense, sorry. If this would be the case you'd merge it in OE-Core as you also use GCC, GLibC and so on.
>
>>
>> When Freescale needs to provide support for LS2A (next generation) DPAA, the current organization will become a mess.  A lot (if not most) of the QorIQ BSP layer is for DPAA / networking, and I don't think it will make sense to have these duplicated in both meta-fsl-ppc and meta-fsl-arm, or have DPAA code that will be built for the ARM in meta-fsl-ppc (or vice versa).
>
>
> FSL processors are the ONLY one in the World to provide DPAA? I will provide two possible routes:
>
>   - If FSL is the only DPAA provider, we make a mets-fsl-dpaa layer
>   - If NOT we move DPAA to meta-networking layer where it seems to belong
>
>> I would hope that having this code organized in logical layers under the scope of QorIQ would make it more manageable in migrating from something like a TXXX device to an LS2A device.
>
> I have customers moving from/to TI and FSL, those use meta-ti and fsl-arm in SAME setup with no issues. It is as easy as change the machine name.
>
> How users from meta-fsl-ppc will migrated for any new layer layout?
> Freescale will break every product layer out there for no good reason, it seems. The previous repository cannot be removed without critical impacts.
>
> ...
>