On 2020/3/3 22:20, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: Junling Zheng <[email protected]> >> Sent: den 3 mars 2020 15:14 >> To: Peter Kjellerstedt <[email protected]>; Khem Raj >> <[email protected]>; [email protected] >> Cc: [email protected] >> 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: [email protected] <openembedded- >> core- >>>> [email protected]> On Behalf Of Junling Zheng >>>> Sent: den 3 mars 2020 04:11 >>>> To: Khem Raj <[email protected]>; openembedded- >>>> [email protected] >>>> Cc: [email protected] >>>> 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 <[email protected]> >>>>>> --- >>>>>> 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 > > > . > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
