Hi Daiane,

On 07/07/2015 03:30 PM, Daiane Angolini wrote:

On Mon, Jul 6, 2015 at 5:50 PM, Ann Thornton <Ann.Thornton@freescale.com> wrote:

Hi Nikolay,

QorIQ will be merged into a common layer with i.MX.
See "[meta-freescale] Freescale meta-freescale announcement of new layer"

Ann, Nikolay,

Currently on 1.8 (fido) of meta-fsl-arm we already have 3 different
product lines from Freescale: i.MX, Layerscape/QoirQ and Vybrid. And
currently the OVERRIDE "imx" is not exactly needed (if you think
everything has been working fine so far).

Please see [1], the heads (imx, vybrid and layerscape) are not from
the meta-fsl-arm source code, but faked for the picture.

Back to 1.6 RN I was able to find vybrid already being graphically
represented in a SOC Family tree.

So, the argument that imx is needed because of meta-freescale is not
right. Having a OVERRIDE for imx and vybrid and layerscape may make
sense because of some future differentiation on the BSP regarding
product lines.

On the other hand, if we have time, we can discuss it a lot. For
example, if you take the imx6, you see, from BSP point of view, we
have more diverging than converging packages. Would it make sense to

Indeed, I also think that the "imx" family will cover a set of such
widely different SoCs, so I was wondering whether there's any practical
use case where we can address all these SoCs as "the imx". We already
have "imx6*" overrides, which are both specific and works to separate
from qoriq.

keep the "imx6" OVERRIDE today?

I would like to have the SOC_FAMILY tree reviewed for sure. I know we
have a lot of possible enhancement there. But I really don't get the
overall picture only with this patch.

And, the commit log is wrong. We already have non-imx machines in meta-fsl-arm.

[1] http://freescale.github.io/doc/release-notes/1.8/index.html#soc-hierarchy

Regards,
Daiane

Ann

On 7/6/2015 3:34 PM, Nikolay Dimitrov wrote:

Hi Ann,

On 07/06/2015 10:04 PM, Ann Thornton wrote:

Soon non-imx machines will be added to the builds.  We need to be able to
specify imx machines to distinguish between them in recipes. This change
allows _imx to be used to limit actions to i.MX machines.


Can you please explain why there's this need for such generalization?
This "imx" family covers quite a diverse set of SoCs.

Regards,
Nikolay



--
Ann Thornton

Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com

--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Regards,
Nikolay