* SOC_FAMILY Rework @ 2015-07-08 19:42 Daiane Angolini 2015-07-09 14:05 ` Otavio Salvador 2015-07-10 5:41 ` Luo Zhenhua 0 siblings, 2 replies; 15+ messages in thread From: Daiane Angolini @ 2015-07-08 19:42 UTC (permalink / raw) To: meta-freescale 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-08 19:42 SOC_FAMILY Rework Daiane Angolini @ 2015-07-09 14:05 ` Otavio Salvador 2015-07-09 14:54 ` Daiane Angolini 2015-07-10 5:41 ` Luo Zhenhua 1 sibling, 1 reply; 15+ messages in thread From: Otavio Salvador @ 2015-07-09 14:05 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale Hello Daiane, First, thank you for preparing this e-mail. On Wed, Jul 8, 2015 at 4:42 PM, Daiane Angolini <daiane.list@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 14:05 ` Otavio Salvador @ 2015-07-09 14:54 ` Daiane Angolini 2015-07-09 15:17 ` Otavio Salvador ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Daiane Angolini @ 2015-07-09 14:54 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale On Thu, Jul 9, 2015 at 11:05 AM, Otavio Salvador <otavio@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@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. > >> 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. ok > >> 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. > >> 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 see how it will contaminate other BSP. I'm trying to stress the imx OVERRIDE just included. > >> 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 Daiane > > -- > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 14:54 ` Daiane Angolini @ 2015-07-09 15:17 ` Otavio Salvador 2015-07-10 11:45 ` Daiane Angolini 2015-07-09 15:18 ` Eric Bénard 2015-07-09 15:20 ` Nikolay Dimitrov 2 siblings, 1 reply; 15+ messages in thread From: Otavio Salvador @ 2015-07-09 15:17 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale On Thu, Jul 9, 2015 at 11:54 AM, Daiane Angolini <daiane.list@gmail.com> wrote: > On Thu, Jul 9, 2015 at 11:05 AM, Otavio Salvador > <otavio@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@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). ... >>> 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. 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. >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:17 ` Otavio Salvador @ 2015-07-10 11:45 ` Daiane Angolini 0 siblings, 0 replies; 15+ messages in thread From: Daiane Angolini @ 2015-07-10 11:45 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale On Thu, Jul 9, 2015 at 12:17 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Thu, Jul 9, 2015 at 11:54 AM, Daiane Angolini <daiane.list@gmail.com> wrote: >> On Thu, Jul 9, 2015 at 11:05 AM, Otavio Salvador >> <otavio@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@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 14:54 ` Daiane Angolini 2015-07-09 15:17 ` Otavio Salvador @ 2015-07-09 15:18 ` Eric Bénard 2015-07-09 15:25 ` Otavio Salvador 2015-07-10 11:49 ` Daiane Angolini 2015-07-09 15:20 ` Nikolay Dimitrov 2 siblings, 2 replies; 15+ messages in thread From: Eric Bénard @ 2015-07-09 15:18 UTC (permalink / raw) To: Daiane Angolini; +Cc: meta-freescale, Otavio Salvador Hi Daiane, Le Thu, 9 Jul 2015 11:54:14 -0300, Daiane Angolini <daiane.list@gmail.com> a écrit : > 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. > Does that mean there is an updated GPU library and full IPU drivers for more recent kernels than 2.6.35 for i.MX53 ? Thanks, Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:18 ` Eric Bénard @ 2015-07-09 15:25 ` Otavio Salvador 2015-07-09 15:47 ` Eric Bénard 2015-07-10 11:49 ` Daiane Angolini 1 sibling, 1 reply; 15+ messages in thread From: Otavio Salvador @ 2015-07-09 15:25 UTC (permalink / raw) To: Eric Bénard; +Cc: meta-freescale On Thu, Jul 9, 2015 at 12:18 PM, Eric Bénard <eric@eukrea.com> wrote: > Hi Daiane, > > Le Thu, 9 Jul 2015 11:54:14 -0300, > Daiane Angolini <daiane.list@gmail.com> a écrit : >> 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. >> > Does that mean there is an updated GPU library and full IPU drivers for > more recent kernels than 2.6.35 for i.MX53 ? This means mx5 will likely don't have GPU support in Yocto Project 1.9; VPU will likely work using mainline CODA. -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:25 ` Otavio Salvador @ 2015-07-09 15:47 ` Eric Bénard 2015-07-09 16:45 ` Otavio Salvador 0 siblings, 1 reply; 15+ messages in thread From: Eric Bénard @ 2015-07-09 15:47 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale Hi Otavio, Le Thu, 9 Jul 2015 12:25:27 -0300, Otavio Salvador <otavio@ossystems.com.br> a écrit : > On Thu, Jul 9, 2015 at 12:18 PM, Eric Bénard <eric@eukrea.com> wrote: > > Hi Daiane, > > > > Le Thu, 9 Jul 2015 11:54:14 -0300, > > Daiane Angolini <daiane.list@gmail.com> a écrit : > >> 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. > >> > > Does that mean there is an updated GPU library and full IPU drivers for > > more recent kernels than 2.6.35 for i.MX53 ? > > This means mx5 will likely don't have GPU support in Yocto Project > 1.9; VPU will likely work using mainline CODA. > and also most of the tools mixing VPU & IPU (CSI for example) ... Is that what you want in a "reference" BSP for reference platforms ? Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:47 ` Eric Bénard @ 2015-07-09 16:45 ` Otavio Salvador 2015-07-09 19:39 ` Eric Bénard 0 siblings, 1 reply; 15+ messages in thread From: Otavio Salvador @ 2015-07-09 16:45 UTC (permalink / raw) To: Eric Bénard; +Cc: meta-freescale On Thu, Jul 9, 2015 at 12:47 PM, Eric Bénard <eric@eukrea.com> wrote: > Le Thu, 9 Jul 2015 12:25:27 -0300, > Otavio Salvador <otavio@ossystems.com.br> a écrit : > >> On Thu, Jul 9, 2015 at 12:18 PM, Eric Bénard <eric@eukrea.com> wrote: >> > Hi Daiane, >> > >> > Le Thu, 9 Jul 2015 11:54:14 -0300, >> > Daiane Angolini <daiane.list@gmail.com> a écrit : >> >> 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. >> >> >> > Does that mean there is an updated GPU library and full IPU drivers for >> > more recent kernels than 2.6.35 for i.MX53 ? >> >> This means mx5 will likely don't have GPU support in Yocto Project >> 1.9; VPU will likely work using mainline CODA. >> > and also most of the tools mixing VPU & IPU (CSI for example) ... > Is that what you want in a "reference" BSP for reference platforms ? If Freescale does not upgrade the AMD support components for newer kernel someone needs to do it. As a community member you are welcome to-do so, especially as Eukrea has mx5-based SoMs. If no one does it, it will be removed. -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 16:45 ` Otavio Salvador @ 2015-07-09 19:39 ` Eric Bénard 0 siblings, 0 replies; 15+ messages in thread From: Eric Bénard @ 2015-07-09 19:39 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale Hi Otavio, Le Thu, 9 Jul 2015 13:45:10 -0300, Otavio Salvador <otavio@ossystems.com.br> a écrit : > On Thu, Jul 9, 2015 at 12:47 PM, Eric Bénard <eric@eukrea.com> wrote: > > Le Thu, 9 Jul 2015 12:25:27 -0300, > > Otavio Salvador <otavio@ossystems.com.br> a écrit : > > > >> On Thu, Jul 9, 2015 at 12:18 PM, Eric Bénard <eric@eukrea.com> wrote: > >> > Hi Daiane, > >> > > >> > Le Thu, 9 Jul 2015 11:54:14 -0300, > >> > Daiane Angolini <daiane.list@gmail.com> a écrit : > >> >> 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. > >> >> > >> > Does that mean there is an updated GPU library and full IPU drivers for > >> > more recent kernels than 2.6.35 for i.MX53 ? > >> > >> This means mx5 will likely don't have GPU support in Yocto Project > >> 1.9; VPU will likely work using mainline CODA. > >> > > and also most of the tools mixing VPU & IPU (CSI for example) ... > > Is that what you want in a "reference" BSP for reference platforms ? > > If Freescale does not upgrade the AMD support components for newer > kernel someone needs to do it. > > As a community member you are welcome to-do so, especially as Eukrea > has mx5-based SoMs. If no one does it, it will be removed. > So just remove it, no interest to spend time on that old chipset support in 2015 especially when AMD's libraries are proprietary and when Freescale didn't even bother to provide a hard float version despite several requests. Best regards Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:18 ` Eric Bénard 2015-07-09 15:25 ` Otavio Salvador @ 2015-07-10 11:49 ` Daiane Angolini 1 sibling, 0 replies; 15+ messages in thread From: Daiane Angolini @ 2015-07-10 11:49 UTC (permalink / raw) To: Eric Bénard; +Cc: meta-freescale, Otavio Salvador On Thu, Jul 9, 2015 at 12:18 PM, Eric Bénard <eric@eukrea.com> wrote: > Hi Daiane, > > Le Thu, 9 Jul 2015 11:54:14 -0300, > Daiane Angolini <daiane.list@gmail.com> a écrit : >> 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. >> > Does that mean there is an updated GPU library and full IPU drivers for > more recent kernels than 2.6.35 for i.MX53 ? Not that I know, Eric. The topic about i.MX53 become mailine was discussed in last community meeting, and we was not able to figure out a better option. At least I personally cannot take this task. If needed we can setup another meeting or open a new thread on this topic. Daiane > > Thanks, > Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 14:54 ` Daiane Angolini 2015-07-09 15:17 ` Otavio Salvador 2015-07-09 15:18 ` Eric Bénard @ 2015-07-09 15:20 ` Nikolay Dimitrov 2015-07-09 15:26 ` Otavio Salvador 2015-07-10 11:59 ` Daiane Angolini 2 siblings, 2 replies; 15+ messages in thread From: Nikolay Dimitrov @ 2015-07-09 15:20 UTC (permalink / raw) To: Daiane Angolini, Otavio Salvador; +Cc: meta-freescale Hi Daiane, On 07/09/2015 05:54 PM, Daiane Angolini wrote: >> 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 see how it will contaminate other BSP. I'm trying to stress > the imx OVERRIDE just included. This is an excellent example. The OVERRIDEs should generalize, not specialize (although you can always interpret a root-leaf traversal as a specialization :D). Detailed specialization will lead to OVERRIDEs tree explosion while trying to express every single SOC feature on each level of the tree. If we try to express SOC features via OVERRIDE mechanism, it's imho doomed. Regards, Nikolay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:20 ` Nikolay Dimitrov @ 2015-07-09 15:26 ` Otavio Salvador 2015-07-10 11:59 ` Daiane Angolini 1 sibling, 0 replies; 15+ messages in thread From: Otavio Salvador @ 2015-07-09 15:26 UTC (permalink / raw) To: Nikolay Dimitrov; +Cc: meta-freescale On Thu, Jul 9, 2015 at 12:20 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote: > On 07/09/2015 05:54 PM, Daiane Angolini wrote: >>> >>> 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 see how it will contaminate other BSP. I'm trying to stress >> the imx OVERRIDE just included. > > > This is an excellent example. The OVERRIDEs should generalize, not > specialize (although you can always interpret a root-leaf traversal as > a specialization :D). Detailed specialization will lead to OVERRIDEs > tree explosion while trying to express every single SOC feature on each > level of the tree. > > If we try to express SOC features via OVERRIDE mechanism, it's imho > doomed. That's why we use the family. mx53; mx6q; ... -- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-09 15:20 ` Nikolay Dimitrov 2015-07-09 15:26 ` Otavio Salvador @ 2015-07-10 11:59 ` Daiane Angolini 1 sibling, 0 replies; 15+ messages in thread From: Daiane Angolini @ 2015-07-10 11:59 UTC (permalink / raw) To: Nikolay Dimitrov; +Cc: meta-freescale, Otavio Salvador On Thu, Jul 9, 2015 at 12:20 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote: > Hi Daiane, > > On 07/09/2015 05:54 PM, Daiane Angolini wrote: >>> >>> 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 see how it will contaminate other BSP. I'm trying to stress >> the imx OVERRIDE just included. > > > This is an excellent example. The OVERRIDEs should generalize, not > specialize (although you can always interpret a root-leaf traversal as > a specialization :D). Detailed specialization will lead to OVERRIDEs > tree explosion while trying to express every single SOC feature on each > level of the tree. The problem is that the i.MX6 shares only the name and the core. And share the core is nothing (as i.MX can share the ARM core of any other product in the world) It's like i.MX6UL was the adopted brother. It shares the name but no genetic features. Of course we can use the marketing name on OVERRIDE, but I would prefer if we focus on the SoC convergence instead. > > If we try to express SOC features via OVERRIDE mechanism, it's imho > doomed. I have a crush on philosophy, so I apologize in advance. But i.MX is basicaly it's GPU. Mainly if you think about i.MX6. Represent GPU characteristics on OVERRIDE is not represent a feature, but a core feature. However, I remember Otavio's argument i.MX6 is the exception now, not the rule. Daiane > > Regards, > Nikolay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: SOC_FAMILY Rework 2015-07-08 19:42 SOC_FAMILY Rework Daiane Angolini 2015-07-09 14:05 ` Otavio Salvador @ 2015-07-10 5:41 ` Luo Zhenhua 1 sibling, 0 replies; 15+ messages in thread From: Luo Zhenhua @ 2015-07-10 5:41 UTC (permalink / raw) To: Daiane Angolini, meta-freescale 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@yoctoproject.org [mailto:meta-freescale- > bounces@yoctoproject.org] On Behalf Of Daiane Angolini > Sent: Thursday, July 09, 2015 3:43 AM > To: meta-freescale@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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-07-10 11:59 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-08 19:42 SOC_FAMILY Rework Daiane Angolini 2015-07-09 14:05 ` Otavio Salvador 2015-07-09 14:54 ` Daiane Angolini 2015-07-09 15:17 ` Otavio Salvador 2015-07-10 11:45 ` Daiane Angolini 2015-07-09 15:18 ` Eric Bénard 2015-07-09 15:25 ` Otavio Salvador 2015-07-09 15:47 ` Eric Bénard 2015-07-09 16:45 ` Otavio Salvador 2015-07-09 19:39 ` Eric Bénard 2015-07-10 11:49 ` Daiane Angolini 2015-07-09 15:20 ` Nikolay Dimitrov 2015-07-09 15:26 ` Otavio Salvador 2015-07-10 11:59 ` Daiane Angolini 2015-07-10 5:41 ` Luo Zhenhua
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.