[meta-freescale] SOC_FAMILY Rework

Luo Zhenhua zhenhua.luo at freescale.com
Thu Jul 9 22:41:17 PDT 2015


The OVERRIDE scenario is more complex for QorIQ than i.MX, it is hard to have a fixed definition for the SOC_FAMILY/OVERRIDE and levels, the definition depends on the actual needs and might be changes along with new boards involvement. 

To be specific for the SOC_FAMILY and OVERRIDE definition of QorIQ, the following is the basic OVERRIDE tree currently, we also have special cases besides of the following tree. E.g. e5500  core includes p50x0, t102x, t104x, some  packages and features(l2switch, auto-response) are specific to t104x series, so we need to define a t104x SOC family(qoriq -> qoriq-ppc -> qoriq-ppce6500 -> t104x). 

Basic SOC family definition
* qoriq -> qoriq-arm -> ls1021a 
* qoriq -> qoriq-arm -> ls104xa (not upstreamed)
* qoriq -> qoriq-arm -> ls108xa (not upstreamed)
* qoriq -> qoriq-arm -> ls208xa (not upstreamed)
* qoriq -> qoriq-ppc -> qoriq-ppce500v2
* qoriq -> qoriq-ppc -> qoriq-ppce500mc
* qoriq -> qoriq-ppc -> qoriq-ppce5500
* qoriq -> qoriq-ppc -> qoriq-ppc64e5500
* qoriq -> qoriq-ppc -> qoriq-ppce6500
* qoriq -> qoriq-ppc -> qoriq-ppc64e6500


Best Regards,

Zhenhua

> -----Original Message-----
> From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-
> bounces at yoctoproject.org] On Behalf Of Daiane Angolini
> Sent: Thursday, July 09, 2015 3:43 AM
> To: meta-freescale at yoctoproject.org
> Subject: [meta-freescale] SOC_FAMILY Rework
> 
> 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;
> Layerscape -> ls102xa;
> Vybrid -> vf -> vf50;
> Vybrid -> vf -> vf60;
> 
> Where i.MX, Layerscape and Vybrid are only included for visual purposes, not
> being a real OVERRIDE today (the imx inclusion is a pending patch in ML right
> now)
> 
> 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.
> 
> Another important thing to keep in mind is the deepness. How deep should be
> the OVERRIDE tree? Two or tree levels?
> 
> 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
> 
> 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?
> 
> 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)
> 
> 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.
> 
> Regards,
> Daiane
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale


More information about the meta-freescale mailing list