[OE-core] [PATCH 0/6] Correct and improve the ARM tunings

Wed Apr 17 08:33:18 UTC 2019

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)}"
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)}"
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> wrote:

> On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk <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> 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
> 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/4aa9b97f/attachment.html>