On Fri, Mar 1, 2013 at 9:30 AM, Wang Larry-B38019 <b38...@freescale.com> wrote: > 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.
Ok, but you want an entirely separate layer what will live in the core support layer? A linux/u-boot recipe for the machine? That's not that hard to keep in sync. If we do add another layer, I'd prefer NOT to rename meta-fsl-arm and just add the new one by itself. However, I don't think it's really needed. -M > > Thanks! > Larry > > -----Original Message----- > From: otavio.salva...@gmail.com [mailto:otavio.salva...@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@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 <b19...@freescale.com> > wrote: >>> -----Original Message----- >>> From: otavio.salva...@gmail.com [mailto:otavio.salva...@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: ota...@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > > > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale _______________________________________________ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
