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. -- 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
