On Mon, Mar 11, 2013 at 06:03:25PM +0000, Maupin, Chase wrote: > > -----Original Message----- > > From: otavio.salva...@gmail.com > > [mailto:otavio.salva...@gmail.com] On Behalf Of Otavio Salvador > > Sent: Monday, March 11, 2013 11:24 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 Mon, Mar 11, 2013 at 11:49 AM, Maupin, Chase > > <chase.mau...@ti.com> wrote: > > >> -----Original Message----- > > >> From: otavio.salva...@gmail.com > > >> [mailto:otavio.salva...@gmail.com] 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 > > >> <chase.mau...@ti.com> wrote: > > >> >> -----Original Message----- > > >> >> From: otavio.salva...@gmail.com > > >> >> [mailto:otavio.salva...@gmail.com] 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 > > >> >> <de...@denix.org> 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 > > >> >> <chase.mau...@ti.com> 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 <chase.mau...@ti.com> > > >> >> >> > > >> >> >> 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. > > Sure. Btw, I noticed a weirdness when looking at this where the > COMPATIBLE_MACHINE being evaluated evaulated/matched only has to be a > substring of the SOC family to work. For example if I have: > > MACHINE = omap5-evm > SOC_FAMILY = omap-a15 > COMPATIBLE_MACHINE = omap > > Then this will work because "omap" (the COMPATIBLE_MACHINE) is a substring > of SOC_FAMILY (and technically also a substring of omap5-evm) > > Even setting COMPATIBLE_MACHINE to omap- will work because that is a > substring of omap-a15. So the "match" operation is not really precise > enough. I'm wondering if this needs to be changed to do an exact match.
COMPATIBLE_MACHINE is a regular expression and after thinking about it some more and digging around, I believe it was implemented that way on purpose, to be as inclusive as possible, so you can do things like "nokia(800|770)" or what I do in Arago - "(?!arago)". Or in case of COMPATIBLE_HOST it could be "^(i.86|x86_64|powerpc).*-linux". So, if you need an exact match, then specify it with the regular expression syntax: COMPATIBLE_MACHINE = "^omap$" The above won't match either of the examples you provided above, unless MACHINE or SOC_FAMILY are specifically set to "omap". For multiple entries in COMPATIBLE_MACHINE, use "^(omap|davinci)$" -- Denys _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core