On Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Otavio Salvador >> Sent: Saturday, March 09, 2013 6:11 AM >> To: Maupin, Chase >> Cc: Denys Dmytriyenko; Patches and discussions about the oe-core >> layer >> Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY >> override order >> >> On Fri, Mar 8, 2013 at 7:16 PM, Maupin, Chase >> <[email protected]> wrote: >> >> -----Original Message----- >> >> From: [email protected] >> >> [mailto:[email protected]] On Behalf Of Otavio >> Salvador >> >> Sent: Friday, March 08, 2013 2:27 PM >> >> To: Denys Dmytriyenko >> >> Cc: Maupin, Chase; Patches and discussions about the oe-core >> >> layer >> >> Subject: Re: [OE-core] [PATCH] soc-family: fix SOC_FAMILY >> >> override order >> >> >> >> On Fri, Mar 8, 2013 at 5:06 PM, Denys Dmytriyenko >> >> <[email protected]> wrote: >> >> > On Fri, Mar 08, 2013 at 03:52:57PM -0300, Otavio Salvador >> >> wrote: >> >> >> On Fri, Mar 8, 2013 at 2:51 PM, Chase Maupin >> >> <[email protected]> wrote: >> >> >> > * the current order has SOC_FAMILY settings, which are >> >> generic >> >> >> > settings for a group of devices, overriding the machine >> >> specific >> >> >> > settings. For example: >> >> >> > >> >> >> > KERNEL_DEVICETREE_ti33x = "xxxx" >> >> >> > KERNEL_DEVICETREE_beaglebone = "yyyy" >> >> >> > >> >> >> > Should yield "yyyy" when building for the beaglebone >> >> because >> >> >> > that is a more specific device than ti33x. However, >> >> without this >> >> >> > change the result is that the value is set to "xxxx" >> >> meaning the >> >> >> > more generic setting overrides the more specific >> setting. >> >> >> > >> >> >> > Signed-off-by: Chase Maupin <[email protected]> >> >> >> >> >> >> Maybe while on that you could look at supporting xx:yy as >> SoC >> >> family? >> >> >> like am37xx:am3715 ? >> >> > >> >> > Did you mean am3517? That's a slightly different variant of >> >> am35x/omap35x SoC. >> >> >> >> Yes; sorry ... what I meant was 'am35xx:am3517' >> >> >> >> > But if you really meant am3715 (as well as am3705, am3725 >> and >> >> am3730), then >> >> > those are variants of am37x SoC, just with some subsystems, >> >> like SGX or DSP, >> >> > being absent or present. Having those variants handled by >> >> SOC_FAMILY would be >> >> > an overkill. Instead, we've started using MACHINE_FEATURES >> to >> >> distinguish >> >> > between those variants of the same SoC, by checking for >> "sgx" >> >> and/or "dsp" >> >> > flags there and pulling in needed software components >> >> accordingly. >> >> >> >> My main concern here is that COMPATIBLE_MACHINE also parses >> >> SOC_FAMILY >> >> however if you have two (as the 'am35xx:am3517') it is going >> to >> >> fail; >> >> it could split it and parse it individually. >> > >> > Sorry, I'm not sure if I'm following here. Are you saying you >> would find it useful to have support for a MACHINE to have more >> than one SOC_FAMILY? In the example above I would have expected >> that you would have a machine config file for am3517 which has an >> SOC_FAMILY of am35xx. Why would you specify two SOC_FAMILY >> values per machine? >> >> We can have more generic to more specific combinations. >> >> > Or are you trying to build something like omap3->am35xx->am3517 >> where you can use omap3 as a more generic setting but still use >> am35xx for a slightly more restrictive group that is still >> grouping like parts, and finally you use am3517 for the exact >> part? >> >> Exactly so we avoid duplication stuff to boards or SoCs. Another >> example of use: imx -> mx6q -> mx6. > > I see. This could be of some use and I'll play with it. This should not be > required though for this patch since right now I want to fix the order issue. > Any objection to the patch as is?
No; not really. I just wanted to ask if you could look at it as well so we can have it working. It does make things much easier for all us. -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
