Re: [meta-fsl-arm][PATCH v2] imx-base.inc mxs-base.inc: Add imx MACHINEOVERRIDES

[Ann Thornton <Ann.Thornton@freescale.com>]

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


It is true that mx6 can be used today but soon there will be mx7 and mx8 
and the list will get longer.  Also qoriq and automotive will be added 
in which we will want to exclude from i.mx.  There are recipes, images, 
and packagegroups that currently don't need to check for the machine 
that will need to coming up and bbappends that will be needed to 
differentiate between machines. imx would be a convenience that will be 
useful in the near future. The alternative is a long list of i.MX machines.

Ann


On 7/7/2015 10:12 AM, Nikolay Dimitrov wrote:
> 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


-- 
Ann Thornton

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

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