> -----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? 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? > > -- > Otavio Salvador O.S. Systems > E-mail: ota...@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 > http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
