[OE-core] [PATCHv2][RFC] arch-armv7ve.inc: respect armv7a override as well

[Andre McCurdy]

On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> On Fri, Jan 08, 2016 at 08:24:36AM -0800, Andre McCurdy wrote:
>> On Fri, Jan 8, 2016 at 4:44 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> > * in all cases we currently have we consider armv7ve to be compatible with armv7a
>>
>> Is this a short term workaround or a long term solution?
>
> It's just RFC for discussion.
>
>> If it's a long term solution then how will armv7m and armv7r be
>> handled? They are likely to need to duplicate a lot of the current
>> armv7a over-rides too.
>
> armv7a and armv7ve are much closer than armv7a and armv7m or armv7r as
> Khem said in earlier discussion.

I'm not sure what the definition of "close" is here. An armv7a CPU can
not run armv7ve binaries.

Saying armv7a and armv7ve are close is like saying armv4 and armv5 are
close. True in some respects, but they don't define each other's
over-rides.

> And maybe it's because fewer people use
> armv7[rm], but currently these 2 aren't used anywhere as overrides (in
> layers I've in world builds).
>
>> Maybe adding a generic "armv7" over-ride which can be enabled by all
>> armv7 variants is a better option?
>
> Maybe, but that will change how armv7r and armv7m are currently built, I
> cannot say if for better or worse, I don't use either.

I doubt that armv7m or armv7r are buildable at all. Perhaps we should
drop the tune-cortexm1.inc, tune-cortexm3.inc and tune-cortexr4.inc
files completely and stop pretending that they might work?

>> Either way, I'd like to continue cleaning up of the existing armv7a
>> over-rides (e.g. the libav armv7a specific optimisation is likely
>> bogus and should be removed, etc).
>>
>>
>> > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
>> > ---
>> >  meta/conf/machine/include/arm/arch-armv7ve.inc | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc
>> > index 79e1ef6..d0fdff7 100644
>> > --- a/meta/conf/machine/include/arm/arch-armv7ve.inc
>> > +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc
>> > @@ -3,7 +3,8 @@ DEFAULTTUNE ?= "armv7ve"
>> >  TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"
>> >  TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"
>> >  TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', ' -march=armv7ve', '', d)}"
>> > -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"
>> > +# In all cases we currently have we consider armv7ve to be compatible with armv7a
>> > +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:armv7a:', '' ,d)}"
>> >
>> >  require conf/machine/include/arm/arch-armv6.inc
>> >  require conf/machine/include/arm/feature-arm-neon.inc
>> > --
>> > 2.7.0
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core at lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com