[meta-freescale] SOC_FAMILY Rework

[Otavio Salvador]

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.

> Layerscape -> ls102xa;

I think this should be:

qoriq -> qoriq-arm -> ls102xa

> Vybrid -> vf -> vf50;
> Vybrid -> vf -> vf60;

I would change this for:

vybrid > vf50;
vybrid > vf60;

...
> Some of the points I think is important to consider when choosing a
> OVERRIDE tree is the SoC divergence and convergence. In i.MX case, we
> have some obvious examples such as GPU type, existence of VPU, and
> machine features such as CAN (although imx6 generally supports CAN,
> there are some board with connector, and other without it).
>
> In CAN case, CAN is a SoC feature enabled by the board or not. In WIFI
> case, it’s only a board feature.
>
> So, the points to rule the OVERRIDE is SoC features and board features.

Not really.

The SoC override is to offer a way to modify the source for ALL boards
and also to offer the possibility to cluster binary compatible
binaries.

This ends affecting the MACHINE_SOCARCH and the SoC subarch we
designed to avoid too much rebuilds. Features as CAN or WIFI are
machine features and shouldn't be mapped for SoC overrides.

> 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.

> 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...)

> 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.

-- 
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