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

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

[Junling Zheng]

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@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)}"
-
 # Little Endian base configs
 AVAILTUNES += "aarch64 aarch64_be"
 ARMPKGARCH_tune-aarch64 ?= "aarch64"
-- 
2.17.1

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

[Khem Raj]

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

>   # Little Endian base configs
>   AVAILTUNES += "aarch64 aarch64_be"
>   ARMPKGARCH_tune-aarch64 ?= "aarch64"
> 

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

[Adrian Bunk]

On Mon, Mar 02, 2020 at 10:29:37AM -0800, 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@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.
>...

As far as I am aware all other distributions and config.guess are 
treating aarch64/arm64 as little endian and 64bit, unless suffixed.

cu
Adrian

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

[Junling Zheng]

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@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"
>>
> 
> 

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-
> bounces@lists.openembedded.org> On Behalf Of Junling Zheng
> Sent: den 3 mars 2020 04:11
> To: Khem Raj <raj.khem@gmail.com>; openembedded-
> core@lists.openembedded.org
> Cc: wangnan0@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@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

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

[Herve Jourdain]

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,
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
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@lists.openembedded.org
<openembedded-core-bounces@lists.openembedded.org> On Behalf Of Peter
Kjellerstedt
Sent: 03 March 2020 13:00
To: Junling Zheng <zhengjunling@huawei.com>; Khem Raj <raj.khem@gmail.com>;
openembedded-core@lists.openembedded.org
Cc: wangnan0@huawei.com
Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
MACHINEOVERRIDES

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org 
> <openembedded-core- bounces@lists.openembedded.org> On Behalf Of 
> Junling Zheng
> Sent: den 3 mars 2020 04:11
> To: Khem Raj <raj.khem@gmail.com>; openembedded- 
> core@lists.openembedded.org
> Cc: wangnan0@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@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

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: Herve Jourdain <herve.jourdain@neuf.fr>
> Sent: den 3 mars 2020 14:05
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; 'Junling Zheng'
> <zhengjunling@huawei.com>; 'Khem Raj' <raj.khem@gmail.com>; openembedded-
> core@lists.openembedded.org
> Cc: wangnan0@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@lists.openembedded.org
> <openembedded-core-bounces@lists.openembedded.org> On Behalf Of Peter
> Kjellerstedt
> Sent: 03 March 2020 13:00
> To: Junling Zheng <zhengjunling@huawei.com>; Khem Raj
> <raj.khem@gmail.com>;
> openembedded-core@lists.openembedded.org
> Cc: wangnan0@huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
> MACHINEOVERRIDES
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > <openembedded-core- bounces@lists.openembedded.org> On Behalf Of
> > Junling Zheng
> > Sent: den 3 mars 2020 04:11
> > To: Khem Raj <raj.khem@gmail.com>; openembedded-
> > core@lists.openembedded.org
> > Cc: wangnan0@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@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

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

[Adrian Bunk]

On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote:
>...
> 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.

What does "aarch64" actually mean here?
Does it also cover 32bit-only aarch64 CPUs?

Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from aarch32.

Different from x86, there is no ABI that is available in all aarch64 CPUs.
They can be 32bit-only or 64bit-only, and aarch32 support is optional.

> //Peter

cu
Adrian

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

[Junling Zheng]

On 2020/3/3 19:59, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-
>> bounces@lists.openembedded.org> On Behalf Of Junling Zheng
>> Sent: den 3 mars 2020 04:11
>> To: Khem Raj <raj.khem@gmail.com>; openembedded-
>> core@lists.openembedded.org
>> Cc: wangnan0@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@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)}"
> 

arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc requires arch-armv8a.inc.

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

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: Adrian Bunk <bunk@stusta.de>
> Sent: den 3 mars 2020 14:40
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: Junling Zheng <zhengjunling@huawei.com>; Khem Raj
> <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org;
> wangnan0@huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
> MACHINEOVERRIDES
> 
> On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote:
> >...
> > 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.
> 
> What does "aarch64" actually mean here?
> Does it also cover 32bit-only aarch64 CPUs?

We haven't had to reflect about that as all aarch64 based SoCs we use 
are 64-bit only. So I guess we live in a simplified world. Still, we 
need a way to separate them from our armv7 or mips based SoCs...

> Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from
> aarch32.
> 
> Different from x86, there is no ABI that is available in all aarch64 CPUs.
> They can be 32bit-only or 64bit-only, and aarch32 support is optional.
> 
> > //Peter
> 
> cu
> Adrian

//Peter

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: Junling Zheng <zhengjunling@huawei.com>
> Sent: den 3 mars 2020 15:14
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Khem Raj
> <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org
> Cc: wangnan0@huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
> MACHINEOVERRIDES
> 
> On 2020/3/3 19:59, Peter Kjellerstedt wrote:
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org <openembedded-
> core-
> >> bounces@lists.openembedded.org> On Behalf Of Junling Zheng
> >> Sent: den 3 mars 2020 04:11
> >> To: Khem Raj <raj.khem@gmail.com>; openembedded-
> >> core@lists.openembedded.org
> >> Cc: wangnan0@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@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)}"
> >
> 
> arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc
> requires arch-armv8a.inc.

But it never adds "armv8a" (or ${TUNE_FEATURES_tune-armv8a}) to 
TUNE_FEATURES, it adds "aarch64", so the above is never triggered...

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

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

[Junling Zheng]

On 2020/3/3 22:20, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: Junling Zheng <zhengjunling@huawei.com>
>> Sent: den 3 mars 2020 15:14
>> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Khem Raj
>> <raj.khem@gmail.com>; openembedded-core@lists.openembedded.org
>> Cc: wangnan0@huawei.com
>> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
>> MACHINEOVERRIDES
>>
>> On 2020/3/3 19:59, Peter Kjellerstedt wrote:
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org <openembedded-
>> core-
>>>> bounces@lists.openembedded.org> On Behalf Of Junling Zheng
>>>> Sent: den 3 mars 2020 04:11
>>>> To: Khem Raj <raj.khem@gmail.com>; openembedded-
>>>> core@lists.openembedded.org
>>>> Cc: wangnan0@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@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)}"
>>>
>>
>> arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc
>> requires arch-armv8a.inc.
> 
> But it never adds "armv8a" (or ${TUNE_FEATURES_tune-armv8a}) to 
> TUNE_FEATURES, it adds "aarch64", so the above is never triggered...
> 

I guess the logic is: if you set DEFAULTTUNE as armv8a, then it will add "armv8a"
to TUNE_FEATURES, and then "armv8a:" will be added into MACHINEOVERRIDES. Am I right?

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

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

[Jeremy Puhlman]

On 3/3/2020 5:39 AM, Adrian Bunk wrote:
> On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote:
>> ...
>> 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.
> What does "aarch64" actually mean here?
> Does it also cover 32bit-only aarch64 CPUs?
>
> Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from aarch32.
>
> Different from x86, there is no ABI that is available in all aarch64 CPUs.
> They can be 32bit-only or 64bit-only, and aarch32 support is optional.

In our past work with ilp32, aarch64 usually covered both because in 
general the abi's have more in common then
they are different. If something specific for ilp32 was required we 
would use the aarch64ipl32 override to resolve
the issue. Not so sure about aarch32 as  I haven't done much with it.

-- 

Jeremy A. Puhlman
jpuhlman@mvista.com

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

[Khem Raj]

On 3/2/20 1:34 PM, Adrian Bunk wrote:
> On Mon, Mar 02, 2020 at 10:29:37AM -0800, 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@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.
>> ...
> 
> As far as I am aware all other distributions and config.guess are
> treating aarch64/arm64 as little endian and 64bit, unless suffixed.

this is effective only in defining overrides and like we have for mips 
there is a common override like mipsarch, that apply to all mips. and 
mips in itself does mean MIPS BE, so my question was if there is a value 
in having a common overrrided across all aarch64 variants we have 
irrepective of endianness or wordlength, its fine if we want to treat 
aarch64 as LE

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

[Khem Raj]

On 3/3/20 3:59 AM, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-
>> bounces@lists.openembedded.org> On Behalf Of Junling Zheng
>> Sent: den 3 mars 2020 04:11
>> To: Khem Raj <raj.khem@gmail.com>; openembedded-
>> core@lists.openembedded.org
>> Cc: wangnan0@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@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.

I think armv8a or somesuch might be better in the above usecase, but so 
far I think we have treated aarch64 as common arm64 notation, so 
removing this might have more changes needed in rest of metadata, which 
would be not good.
> 
> //Peter
>