On Mon, Mar 11, 2013 at 3:52 PM, Denys Dmytriyenko <[email protected]> wrote: > On Mon, Mar 11, 2013 at 06:03:25PM +0000, Maupin, Chase wrote: >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] 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 >> > <[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. >> >> 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)$"
The only change I think we need is to pass, for the parser, each value of SOC_FAMILY, so the regexp is applied to each value. -- 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
