[OE-core] [PATCH 0/6] Correct and improve the ARM tunings
Peter Kjellerstedt
peter.kjellerstedt at axis.com
Wed Apr 17 10:26:51 UTC 2019
Yes, that definitely looks wrong. Fortunately for us, we are only using SoCs based on Cortex A53 so far so it is not something that has affected us (yet)…
Oh, and for some more messy fun, take a look at tune-cortexa32.inc. Cortex A32 uses ARMv8 but only supports aarch32. However, the tune file says to use aarch64, which makes me believe that no one is actually using that tune file… I gave up trying to correct is as it is not currently possible to configure a tune to use ARMv8 without aarch64 and I don’t know if it is worth the effort until someone actually has a SoC based on Cortex A32 they want to build for.
//Peter
From: Martin Jansa <martin.jansa at gmail.com>
Sent: den 17 april 2019 10:33
To: Andre McCurdy <armccurdy at gmail.com>
Cc: Adrian Bunk <bunk at stusta.de>; Peter Kjellerstedt <peter.kjellerstedt at axis.com>; OE Core mailing list <openembedded-core at lists.openembedded.org>
Subject: Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
It's not caused by this change (not the previous one I believe), but today I've noticed that aarch64 tunes don't set TUNE_PKGARCH correctly.
e.g. with raspberrypi3-64 which since this commit:
https://github.com/agherzan/meta-raspberrypi/commit/9cc89cb7341d633b6fc3a92b937b5560d26257a1
uses conf/machine/include/tune-cortexa53.inc I was expecting it to use cortexa53 specific TUNE_PKGARCH (and stop messing with other MACHINEs which are using aarch64 package feed).
There is indeed:
DEFAULTTUNE="cortexa53"
and mcpu=cortex-a53+crc in CC:
export CC="aarch64-webos-linux-gcc -mcpu=cortex-a53+crc --sysroot=/OE/build/luneos-warrior/webos-ports/tmp-glibc/work/aarch64-webos-linux/zlib/1.2.11-r0/recipe-sysroot"
But
ARMPKGARCH="cortexa53"
# $TUNE_PKGARCH_32
# set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29
# "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
TUNE_PKGARCH_32="cortexa53"
#
# $TUNE_PKGARCH_64
# set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23
# "aarch64${ARMPKGSFX_ENDIAN_64}"
TUNE_PKGARCH_64="aarch64"
# "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}<mailto:$%7b at bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d>"
TUNE_PKGARCH="aarch64"
so the packages built with -mcpu=cortex-a53+crc (and rpi overrides) end in the same TUNE_PKGARCH as other MACHINEs which include e.g.
conf/machine/include/arm/arch-arm64.inc and DEFAULTTUNE="aarch64" which surprisingly uses aarch64 in both TUNE_PKGARCH_32/64:
# "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}<mailto:$%7b at bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d>"
TUNE_PKGARCH="aarch64"
#
# $TUNE_PKGARCH_32
# set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29
# "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
TUNE_PKGARCH_32="aarch64"
#
# $TUNE_PKGARCH_64
# set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23
# "aarch64${ARMPKGSFX_ENDIAN_64}"
TUNE_PKGARCH_64="aarch64"
Looks like aarch64 are even bigger mess than arm tunes already :/.
On Wed, Apr 3, 2019 at 10:48 PM Andre McCurdy <armccurdy at gmail.com<mailto:armccurdy at gmail.com>> wrote:
On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk <bunk at stusta.de<mailto:bunk at stusta.de>> wrote:
> On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote:
> > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk <bunk at stusta.de<mailto:bunk at stusta.de>> wrote:
> > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote:
> > > >...
> > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t"
> > > > which is the convention used throughout all the tune files.
> > > >...
> > >
> > > Unfortunately this is not true.
> > >
> > > OE has both armv7a and armv7at tunes.
> > >
> > > There is no armv7a without Thumb support,
> > > so no -march=armv7-at exists in gcc.
> > >
> > > Both armv7a and armv7at tunes pass the same march to gcc,
> > > but [1] is not true:
> > > Default to using the Thumb-2 instruction set for armv7a and above.
> > >
> > > The hardware supports Thumb-2 in any case, the actual difference between
> > > the armv7a and armv7at OE tunes is whether OE tells the compiler to
> > > generate ARM or Thumb-2 code.
> > >
> > > OE has both armv6 and armv6t tunes.
> > >
> > > There is no armv6 without Thumb support
> > > so no -march=armv6t exists in gcc.
> > >
> > > Some v6 support only Thumb-1 and some v6 support also Thumb-2,
> > > so what gcc does have is an -march=armv6t2.
> > > But OE lacks tunes for that.
> > >
> > > For matching the gcc options it would be correct to remove all
> > > armv6t and armv7at tunes that have no coresponding gcc options,
> > > and add armv6t2 tunes.
> >
> > Aligning the tuning options exposed via the machine config files to
> > those supported by gcc seems like a worthy goal... but would be a big
> > upheaval at this point.
> >
> > Note that the problem isn't specific to ARM. There are similar issues
> > for x86, but there we seem happy to provide a very minimal abstraction
> > with no attempt to track gcc. e.g. "corei7" hasn't been a documented
> > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to
> > -march=nehalem to hide that fact from end users.
> >
> > So the high level question seems to be: should DEFAULTTUNE even
> > attempt to provide a full featured mapping to the options provided by
> > gcc? Are we happy to expose a limited subset without a 1:1 mapping for
> > the options we do expose (current ARM approach) or is it better for
> > DEFAULTTUNE to hide away all the complexity of the options provided by
> > gcc (current x86 approach).
>
> The current 32bit ARM[1] approach seems to be an attempt
> of a 1:1 mapping.
>
> For ARMv8 it is already obvious that DEFAULTTUNE is not long-term
> maintainable, and duplicating all the gcc rules regarding feature
> flags[2] also sounds like a pointless exercise.
>
> What are actually the benefits of DEFAULTTUNE with all the tune files,
> compared to just let the user provide a string that is passed to -march?
Restricting the user to a certain set of DEFAULTTUNE options means
there will always be a valid mapping from DEFAULTTUNE to
PACKAGE_EXTRA_ARCHS.
If we let the user pass an arbitrary string to -march then we lose the
ability to determine that (for example) it's safe for a
"armv7athf-vfpv3" machine to pull from a "armv7athf-vfpv3d16" package
feed.
Whether or not anyone in the real world actually maintains a generic
package feed and pulls from it from multiple machine specific builds
(verses setting up separate package feeds for each DEFAULTTUNE they
care about) would be an interesting question...
> cu
> Adrian
>
> [1] ARM <= v7, not the differing 32bit ABI of ARMv8
> [2] example:
> 'fp16fml'
> Enable FP16 fmla extension. This also enables FP16 extensions and
> floating-point instructions. This option is enabled by default for
> '-march=armv8.4-a'. Use of this option with architectures prior to
> Armv8.2-A is not supported.
>
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core at lists.openembedded.org<mailto:Openembedded-core at lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190417/a3e37537/attachment-0001.html>
More information about the Openembedded-core
mailing list