[meta-freescale] Please review the proposal of FSL Yocto layers reorg

[Wang Larry-B38019]

About meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid, the reason we prefer the second one is i.MX and Vybrid are so different.  They have different IP blocks, different device drivers in kernel, different interface libs in user space, different SW development/release schedules, different customers.  For that sense, this "ARM" is NOT that "ARM", just like i.MX ARM is not OMAP ARM.  Separating them is more flexible for us, and less confusion for our customers.

Thanks!
Larry 

-----Original Message-----
From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On Behalf Of Otavio Salvador
Sent: Wednesday, February 27, 2013 6:09 AM
To: Luo Zhenhua-B19537
Cc: McClintock Matthew-B29882; Li Yi i.MX-R80015; Mahadevan Mahesh-R9AADQ; Weng White-B18292; Angolini Daiane-B19406; Wang Larry-B38019; Liu Ting-B28495; meta-freescale at yoctoproject.org; Schmitt Richard-B43082; Trefny Thomas-RAT188
Subject: Re: Please review the proposal of FSL Yocto layers reorg

On Wed, Feb 27, 2013 at 3:57 AM, Luo Zhenhua-B19537 <B19537 at freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On 
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, February 27, 2013 5:44 AM
>>
>> > 2) I still don't really see the point in renaming from meta-fsl-ppc 
>> > -> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I 
>> > wonder what others think about this. It seems like unneeded changes 
>> > that will just cause confusion. Why not just put vybird in meta-fsl-arm?
>>
>> I support this idea and it'd make users' life much easier.
> [Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets.
>         i.MX guys, any other reason for the renaming?

Not necessarially; personally I think users will like to have to worry about less layers. It even facilitates the reuse of code and make documentation easier. From my point of view, meta-fsl-arm and meta-fsl-ppc could be the two BSP layers and others could be add around (meta-fsl-networking, meta-fsl-multimedia, ...) in git.freescale.com for extra images and demo recipes.

>> > 3) I think we should delay the creation of some of these layers 
>> > until we really have packages that are duplicated between two layers (e.g.
>> > meta-layerscape can wait until we have a recipe that is needed for 
>> > both ARM and PPC and is not upstream in another layer)
>>
>> Personally I think it won't happen often as usually it'll not be a 
>> BSP package that will fit in this set so it'll end in 
>> meta-virtualization or meta-networking eventually.
> [Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible.

Good.

>> > 4) I think we need some more info about the "unifed" layer. I don't 
>> > think it needs to exist yet, but maybe others would like to see it.
>> > Personally, I think it can be created automatically much like poky 
>> > is now.
>>
>> As I said, I fear it adding more confusing than solving. It might 
>> making users wonder which layer he/she will use and don't know 
>> exactly the difference between the merged layer and the individual ones.
> [Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository.

But it won't include all needed parts for user so it will only add confusion. What makes fsl-community-bsp nice is that it does all for you and gives you a working solution however meta-freescale will give you a set of layers, only.

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