On Fri, Mar 1, 2013 at 12:30 PM, 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.
I understand i.MX and Vybrid is different however this is not uncommon in different layers. Texas Instruments does exactly this and have different OMAP and SoC versions in same meta-ti layer so it is quite easy to user to know where to look at when looking for a SoC support. Intel also does the same supporting Atom (< D2xxx and newer) in same BSP. We also does this supporting i.MXS, i.MX5 and i.MX6 in same BSP and all those are quite different from BSP point of view. Technically I see no reason why to split the layer in several sub-layers and it is more confusing for customers in my point of view as someone looking for a SoC support will end up to figure out the market name of it before finding out where to look for the BSP. This split may be important, or not, depending how Freescale intend to release the SDK (which will have the BSPs on it). In case all BSP are in sync with Yocto GIT and no internal forks are used, it might be good to have the split as each SoC might have different responsable team (even though I still believe it all needs to be tested together to ensure it all work fine in this case) however if the SDK will use internal forks and have a not synchronized release with Yocto so it is less important as Freescale will be able to merge the public and community driven BSP at any time and use it as base for next release. -- 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
