[meta-freescale] SOC_FAMILY Rework

[Daiane Angolini]

On Thu, Jul 9, 2015 at 12:17 PM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> On Thu, Jul 9, 2015 at 11:54 AM, Daiane Angolini <daiane.list at gmail.com> wrote:
>> On Thu, Jul 9, 2015 at 11:05 AM, Otavio Salvador
>> <otavio at ossystems.com.br> wrote:
>>> Hello Daiane,
>>>
>>> First, thank you for preparing this e-mail.
>>>
>>> On Wed, Jul 8, 2015 at 4:42 PM, Daiane Angolini <daiane.list at gmail.com> wrote:
>>>> We have today the following SOC_FAMILY tree (for meta-fsl-arm)
>>>>
>>>> i.MX -> mx3 -> mx31;
>>>> i.MX -> mx3 -> mx35;
>>>> i.MX -> mx5 -> mx51;
>>>> i.MX -> mx5 -> mx53;
>>>> i.MX -> mx6 -> mx6dl;
>>>> i.MX -> mx6 -> mx6q;
>>>> i.MX -> mx6 -> mx6sl;
>>>> i.MX -> mx6 -> mx6sx;
>>>> i.MX -> mxs -> mx23;
>>>> i.MX -> mxs -> mx28;
>>>
>>> Those are fine, as far as I can see.
>>
>> I'm sorry, Otavio, but you are not re-thinking what we have. I don't
>> think this list is fine. I don't see why to separate imx5 from imxs.
>> And, after GCC 5.X is up and linux-imx_2.6.35 is gone, imx5 will be
>> exactly like a imx3.
>
> Yes; when it goes than mx5 will be in mainline use as will be mx28
> (mx23 is already using it).
>
> However this is a new environment and when this happens we can rework
> this. I am not sure we can kill the SoC families as it is needed for
> U-Boot and other things internally as well (see mxs and imx-base
> files).

Only to be extra clear on my words. I'm talking about a future change,
mainly if meta-freescale takes place. I don't think we should rework
SOC_FAMILY in a normal meta-fsl-arm development cycle.


>
> ...
>>>> Another important thing to keep in mind is the deepness. How deep
>>>> should be the OVERRIDE tree? Two or tree levels?
>>>
>>> Not a big deal; it depends if it makes usage sense or not. Current set
>>> seems good for me.
>>
>> In fact I think it's a big deal.
>>
>> Maybe there is not so much difference between 2 and 3, but if you
>> think about 30 levels it is indeed a big deal.
>>
>> I understand the number of levels is arbitrary. But it only means we
>> must decide which are the prefect deepness.
>
> Every modularization imposes complexity so I think usefulness is the
> metric to be put in place here.
>
>>>> OVERRIDE should be used to cluster BSP packages and configurations
>>>> accordingly with SoC and machine features. Today the meta-fsl-arm BSP
>>>> packages can be seen in the table [1]. Most of packages are the same
>>>> for all i.MX boards (including kernel and u-boot not included in the
>>>> table), but some are very specific to a group of SoCs only (i.e.
>>>> fsl-alsa-plugins), and there is the case where a package is for only
>>>> one SoC Family, but has big inner segmentation (Vivante)
>>>>
>>>> [1] https://github.com/Freescale/Documentation/blob/master/release-notes/source/soc-pkg-optimization.inc
>>>
>>> Agreed.
>>>
>>>> The classic example of a crazy OVERRIDE is ‘mxs’. It was included in
>>>> the past to cluster imx23 and imx28 because they are the only 2 board
>>>> using imx-bootlets. Does ‘mxs’ make sense nowaday? Would imx6UL be
>>>> more related with imx28 than with imx6Q? Would imx6SX be clustered
>>>> with vf60?
>>>
>>> I think UL will end being a mx6ul and it will demand the check of all
>>> mx6 uses to see if it is compatible or not. See Lauren's patch
>>> regarding the GPU presence in Weston for an example.
>>>
>>>> Maybe, we can concentrate the OVERRIDE only around GPU and VPU. We
>>>> have an extensive segmentation of OVERRIDE for imx6, and a cluster for
>>>> all the SoCs without GPU (vf,layerscape?,imx2,imx3,imx6UL, imx7)
>>>
>>> It does not work. The point of OVERRIDE is to make changes in a set of
>>> SoCs and we cannot contaminate other BSP (Intel, TI, Samsung,
>>> Qualcomm...)
>>
>> GPU is a SoC characteristic, and it's obvious it's the most important
>> BSP piece on i.MX6 family. Instead of having a tree like:
>>
>> imx -> imx6 -> everysingle soc
>>
>> We could have something like:
>>
>> imx -> imx6-light -> ligh socs
>> imx -> imx6-heavy -> heavy socs
>>
>> and, instead of list "everysingle soc" when setting GPU BSP, we can
>> list only "light and heavy".
>>
>> The downside is to list "light and heavy" in packages for imx6
>
> I don't agree; we don't know what i.MX8 will look like, what i.MX9
> will look like so we should put it as close as possible for product
> family.

We never know the future. So the argument "we don't know the future"
is not good enough.

But I understand what you mean instead. You mean imx6 today is the
exception, not the rule. In case another exception (imx8 or imx9)
this can become the rule in the future.


Daiane
>
> The feature set is too fragmented and too SoC specific so grouping it
> in super-groups is risky.
>
>> I don't see how it will contaminate other BSP. I'm trying to stress
>> the imx OVERRIDE just included.
>
> IF we use the overrides wrong it does.
>
> There is an arm override, we cannot use this for an i.MX patch as TI
> would be affected, for example.And as an exception it should be cared
>
>>>> I only thing this is the right timing to review and rework SOC_FAMILY.
>>>> I'm i.MX biased, so I can only say about i.MX, would be glad to hear
>>>> feedback from Vybrid and QoirQ.
>>>
>>> As I said before, the QorIQ should have common and arch specific
>>> overrides (I see the former going to be most used) and i.MX global
>>> override will be rarely used.
>>
>> One argument to keep things like it is today is learning curve
>> one argument to change it in meta-freescale is upgrade path
>
> I think Vybrid and Layerscape does need rework. mx5 and mxs may be
> reduced once we move to mainline  but not killed and they are not same
> thing as well.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750