* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 11:59 ` Peter Kjellerstedt
@ 2020-03-03 13:05 ` Herve Jourdain
2020-03-03 13:33 ` Peter Kjellerstedt
2020-03-03 13:39 ` Adrian Bunk
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Herve Jourdain @ 2020-03-03 13:05 UTC (permalink / raw)
To: 'Peter Kjellerstedt', 'Junling Zheng',
'Khem Raj',
openembedded-core
Cc: wangnan0
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 13:05 ` Herve Jourdain
@ 2020-03-03 13:33 ` Peter Kjellerstedt
0 siblings, 0 replies; 15+ messages in thread
From: Peter Kjellerstedt @ 2020-03-03 13:33 UTC (permalink / raw)
To: Herve Jourdain, 'Junling Zheng', 'Khem Raj',
openembedded-core
Cc: wangnan0
> -----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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 11:59 ` Peter Kjellerstedt
2020-03-03 13:05 ` Herve Jourdain
@ 2020-03-03 13:39 ` Adrian Bunk
2020-03-03 14:19 ` Peter Kjellerstedt
2020-03-03 19:21 ` Jeremy Puhlman
2020-03-03 14:13 ` Junling Zheng
2020-03-03 19:31 ` Khem Raj
3 siblings, 2 replies; 15+ messages in thread
From: Adrian Bunk @ 2020-03-03 13:39 UTC (permalink / raw)
To: Peter Kjellerstedt; +Cc: wangnan0, openembedded-core
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 13:39 ` Adrian Bunk
@ 2020-03-03 14:19 ` Peter Kjellerstedt
2020-03-03 19:21 ` Jeremy Puhlman
1 sibling, 0 replies; 15+ messages in thread
From: Peter Kjellerstedt @ 2020-03-03 14:19 UTC (permalink / raw)
To: Adrian Bunk; +Cc: wangnan0, openembedded-core
> -----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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 13:39 ` Adrian Bunk
2020-03-03 14:19 ` Peter Kjellerstedt
@ 2020-03-03 19:21 ` Jeremy Puhlman
1 sibling, 0 replies; 15+ messages in thread
From: Jeremy Puhlman @ 2020-03-03 19:21 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 11:59 ` Peter Kjellerstedt
2020-03-03 13:05 ` Herve Jourdain
2020-03-03 13:39 ` Adrian Bunk
@ 2020-03-03 14:13 ` Junling Zheng
2020-03-03 14:20 ` Peter Kjellerstedt
2020-03-03 19:31 ` Khem Raj
3 siblings, 1 reply; 15+ messages in thread
From: Junling Zheng @ 2020-03-03 14:13 UTC (permalink / raw)
To: Peter Kjellerstedt, Khem Raj, openembedded-core; +Cc: wangnan0
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
>
>
> .
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 14:13 ` Junling Zheng
@ 2020-03-03 14:20 ` Peter Kjellerstedt
2020-03-03 14:39 ` Junling Zheng
0 siblings, 1 reply; 15+ messages in thread
From: Peter Kjellerstedt @ 2020-03-03 14:20 UTC (permalink / raw)
To: Junling Zheng, Khem Raj, openembedded-core; +Cc: wangnan0
> -----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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 14:20 ` Peter Kjellerstedt
@ 2020-03-03 14:39 ` Junling Zheng
0 siblings, 0 replies; 15+ messages in thread
From: Junling Zheng @ 2020-03-03 14:39 UTC (permalink / raw)
To: Peter Kjellerstedt, Khem Raj, openembedded-core; +Cc: wangnan0
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
>
>
> .
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES
2020-03-03 11:59 ` Peter Kjellerstedt
` (2 preceding siblings ...)
2020-03-03 14:13 ` Junling Zheng
@ 2020-03-03 19:31 ` Khem Raj
3 siblings, 0 replies; 15+ messages in thread
From: Khem Raj @ 2020-03-03 19:31 UTC (permalink / raw)
To: Peter Kjellerstedt, Junling Zheng, openembedded-core; +Cc: wangnan0
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
>
^ permalink raw reply [flat|nested] 15+ messages in thread