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" >> > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
