[OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES

Tue Mar 3 13:33:28 UTC 2020

> -----Original Message-----
> From: Herve Jourdain <herve.jourdain at neuf.fr>
> Sent: den 3 mars 2020 14:05
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>; 'Junling Zheng'
> <zhengjunling at huawei.com>; 'Khem Raj' <raj.khem at gmail.com>; openembedded-
> core at lists.openembedded.org
> Cc: wangnan0 at huawei.com
> Subject: RE: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
> MACHINEOVERRIDES
> 
> Hi,
> 
> Just my 2 cents about this.
> armv8-a is the architecture of the arm core, while aarch64/aarch32 is the
> execution mode on said architecture.
> So I believe that we should have overrides for BOTH the architecture and the
> execution mode, as you can have armv8-a executing in 32 bits mode - and btw,

There is still an override for aarch64 even after removing it from 
MACHINEOVERRIDES. It is provided via ${TRANSLATED_TARGET_ARCH}, which 
will be either "aarch64" or "aarch64-be". The problem before was that 
for big endian tunes, both aarch64 and aarch64-be would be overrides.

> the instruction set in 32 bits mode is not exactly the same as armv7-ve, so
> in terms of optimization it does help to know you're running on an armv8-a
> architecture, even if it's in 32 bits mode.
> There was no such problem before armv8-a architecture, since all previous
> architectures were running in 32 bits mode only. Armv8-a changes that as
> it's a "hybrid", with support for both aarch64 and aarch32.
> I expect later arch to support only aarch64.
> 
> There is also an additional thing to consider, there is not just one armv8-a
> profiles, there already are several, and they shall all be taken into account.
> I believe that at this time, the valid ones are armv8.0-a, armv8.1-a,
> armv8.2-a, armv8.3-a  and armv8.4-a.
> 
> And let me answer before someone asks, yes the gcc compiler DOES provide
> compiler options for all those architectures, with those exact names -
> except armv8.0-a is just named armv8-a (-march=armv8-a or -march=armv8.[1,2,3,4]-a).
> So it just makes sense to support them all.
> 
> So overall, I believe we should support all those arm v8 architectures, and
> add the corresponding override to the cpu definition files (for instance, as
> Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75
> would be an armv8.2-a).
> 
> Finally, the arm architecture is slightly more complex than just armv8.x-a,
> since the support for "features" is optional. So at least "crc" and "crypto"
> features should be added, in order to have a "comprehensive" view of the
> armv8 architecture. And yes, the "features" are also supported by the gcc
> compiler.
> So the arm architecture would really be fully defined by
> armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they

The crc and crypto features are currently specified in TUNE_FEATURES. Not 
sure if it is a good idea to include them in MACHINEOVERRIDES as well, 
but my gut instinct says it is not.

> implemented or not as optional features. And this is probably what should
> end up going into the tune-cortexa53.inc and others (and should be
> override-able, since again not all cortexa53 are created the same).
> 
> Cheers,
> Herve
> 
> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> <openembedded-core-bounces at lists.openembedded.org> On Behalf Of Peter
> Kjellerstedt
> Sent: 03 March 2020 13:00
> To: Junling Zheng <zhengjunling at huawei.com>; Khem Raj
> <raj.khem at gmail.com>;
> openembedded-core at lists.openembedded.org
> Cc: wangnan0 at huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
> MACHINEOVERRIDES
> 
> > -----Original Message-----
> > From: openembedded-core-bounces at lists.openembedded.org
> > <openembedded-core- bounces at lists.openembedded.org> On Behalf Of
> > Junling Zheng
> > Sent: den 3 mars 2020 04:11
> > To: Khem Raj <raj.khem at gmail.com>; openembedded-
> > core at lists.openembedded.org
> > Cc: wangnan0 at huawei.com
> > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64
> > in MACHINEOVERRIDES
> >
> > On 2020/3/3 2:29, Khem Raj wrote:
> > >
> > >
> > > On 3/2/20 9:11 AM, Junling Zheng wrote:
> > >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES
> > >> with "aarch64:", which has the higher priority than
> TRANSLATED_TARGET_ARCH.
> > >> So, for aarch64 big endian, the variable '<foo>_aarch64' will
> > >> override not only '<foo>', but also '<foo>_aarch64-be', thus we
> > >> will get an incorrect variable.
> > >>
> > >> Signed-off-by: Junling Zheng <zhengjunling at huawei.com>
> > >> ---
> > >>   meta/conf/machine/include/arm/arch-arm64.inc | 2 --
> > >>   1 file changed, 2 deletions(-)
> > >>
> > >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc
> > b/meta/conf/machine/include/arm/arch-arm64.inc
> > >> index 53f4566815..32294bd218 100644
> > >> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> > >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> > >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc
> > >>     TUNEVALID[aarch64] = "Enable instructions for aarch64"
> > >>   -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',
> 'aarch64', 'aarch64:', '' ,d)}"
> > >> -
> > >
> > > if its removed here, where is it being added for other machines,
> > question is, should we treat aarch64 as LE equivalent of aarch64_be
> > > or should be treated as common aarch64 and a new define like
> > > aarch64_le
> > defined.
> > >
> >
> > Currently, for arm64, we have aarch64_be to represent big endian, but
> > no overrides to represent little endian only.
> >
> > So, IMO, we should treat aarch64 as little enaian only, like arm and
> > armeb.
> >
> > >>   # Little Endian base configs
> > >>   AVAILTUNES += "aarch64 aarch64_be"
> > >>   ARMPKGARCH_tune-aarch64 ?= "aarch64"
> 
> Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or
> similar. This is how it is done for the armv7* based chips. E.g., I would
> expect to see tune-cortexa53.inc have:
> 
> MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53',
> 'armv8a:', '' ,d)}"
> 
> Which corresponds to how it is done for armv7*.
> 
> At least we currently rely on being able to do, e.g.:
> 
> COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve"
> 
> and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable
> substitute.
> 
> //Peter

//Peter