[oe] [meta-oe][PATCH] ne10: set NE10_TARGET_ARCH with an override instead of anonymous python

Martin Jansa martin.jansa at gmail.com
Fri Apr 26 19:27:25 UTC 2019


I'm not using ne10 or libopus anywhere, it was just breaking
sstate-diff-machines.sh script by adding that unjustifiable dependency
based on TUNE_FEATURES.

I was going to send v2 with the armv7ve entries as requested by Andreas (I
forgot that armv7ve tunes no longer include armv7a in overrides), but if
someone wants to rework it to test for neon in TUNE_FEATURES feel free to
do so.

It didn't check for neon before, so at least this change didn't make it
worse.

On Fri, Apr 26, 2019 at 7:35 PM Khem Raj <raj.khem at gmail.com> wrote:

> On Thu, Apr 25, 2019 at 10:21 PM Adrian Bunk <bunk at stusta.de> wrote:
> >
> > On Wed, Apr 24, 2019 at 07:00:38PM +0000, Martin Jansa wrote:
> > > * set COMPATIBLE_MACHINE to (^$) to prevent building it for any other
> > >   architectures than armv7a and aarch64
> > > * with new arm tune files it's easy to have armv7a in OVERRIDES even
> > >   when there isn't armv7a in TUNE_FEATURES:
> > >   meta/conf/machine/include/tune-cortexa9.inc:7
> > >      "${@bb.utils.contains('TUNE_FEATURES', 'cortexa9', 'armv7a:',
> '',d)}"
> > >   in cases like this COMPATIBLE_MACHINE was satisfied thanks to the
> > >   armv7a OVERRIDE, but then the anonymous python was failing with:
> > >   ne10 was skipped: Incompatible with archs other than armv7 and
> aarch64
> > >...
> >
> > How does this handle Cortex A9 SoCs without NEON support?
>
> this is a valid concern although rare but this combination is out
> there ( tegra2 )
> and ne10 needs neon, so probably its better to check for neon in tune
> features
>  than anything else first.
>


More information about the Openembedded-devel mailing list