[OE-core] [RFC PATCH 2/3] conf/machine: Overhaul tune include files

[Koen Kooi]

Op 11 jul 2011, om 17:57 heeft Richard Purdie het volgende geschreven:

> There is currently considerable confusion over how the tune files
> operate and hwo these interact with the rest of the build system.
> 
> This update/overhaul changes things so the tune files are primarily
> responsible for setting:
> 
> TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value
> that represents the architecture we're targetting.
> 
> TUNE_PKGARCH - The value that represents the tune configuration that
> this set of tune parameters results in.
> 
> The tune files continue to be responsible for setting the compiler
> flags as previously.
> 
> To determine the values for these fields, the tune code looks at
> the values set in TUNE_FEATURES. Possible values that can be included
> in this variable for a given tune file are shown in the TUNEVALID
> variable.
> 
> This code allows several significant improvements:
> 
> 1) The core can now always determine the target architecture value,
> even when TARGET_ARCH needs to be reset to something different.
> 
> 2) The tune code can allow for the definition of multilib configurations
> which can be enabled in the TUNE_FEATURES variable by the multilib class.
> 
> 3) Distros can easily configure/override specific tunable values
> that they're specifically interested in.
> 
> 4) Several versions of partial and buggy architecture support can be
> rolled into one good implementation (e.g. the arm endianness support).
> 
> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> ---
> meta-yocto/conf/machine/beagleboard.conf         |    1 -
> meta/conf/bitbake.conf                           |   11 +++++++----
> meta/conf/machine/include/tune-arm1136jf-s.inc   |    2 ++
> meta/conf/machine/include/tune-arm920t.inc       |    2 ++
> meta/conf/machine/include/tune-arm926ejs.inc     |    2 ++
> meta/conf/machine/include/tune-arm9tdmi.inc      |    2 ++
> meta/conf/machine/include/tune-armv7.inc         |   16 ++++++++++++----
> meta/conf/machine/include/tune-atom.inc          |    8 ++++++--
> meta/conf/machine/include/tune-cortexa8.inc      |   10 +++++++---
> meta/conf/machine/include/tune-strongarm1100.inc |    2 ++
> meta/conf/machine/include/tune-thumb.inc         |   22 ++++------------------
> meta/conf/machine/qemux86.conf                   |    3 ++-
> 12 files changed, 48 insertions(+), 33 deletions(-)

> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
> index 979d6fe..6f7062f 100644
> --- a/meta/conf/machine/include/tune-armv7.inc
> +++ b/meta/conf/machine/include/tune-armv7.inc
> @@ -1,7 +1,15 @@
> +require conf/machine/include/arch-arm.inc

Where does that file live?

> +TUNE_PKGARCH = "armv7"
> +TUNE_FEATURES_tune-armv7 ??= "hard-fpu"
> +
> # valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
> # valid option for -mtune: `cortex-a8', `cortex-r4', `cortex-m3', `cortex-m1'
> # This will NOT compile programs in 'ARM' mode, which is what you really want
> -TARGET_CC_ARCH = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
> -FEED_ARCH = "armv7"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
> -BASE_PACKAGE_ARCH = "armv7"
> +TARGET_CC_ARCH += "-march=armv7"
> +TARGET_CC_ARCH += "-mfpu=vfp -mfloat-abi=softfp"
> +
> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "hard-fpu", "hard", "soft" ,d)}"

So the above takes care of the softfp calling conventions with hardware support or not, this doesn't take care of the hardfp calling conventions (mfloat-abi=hard)

> +PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}"

> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index a5b982a..74c1e9e 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,3 +1,8 @@
> +require conf/machine/include/arch-arm.inc
> +
> +TUNE_PKGARCH = "armv7a"
> +TUNE_FEATURES_tune-armv7a ??= "hard-fpu"
> +
> # Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3]
> # [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
> # [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html 
> @@ -8,6 +13,5 @@ TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp

And here you set mfpu=neon, while it's optional in both the cortex-a8 and armv7a standards. It also shows that we're messing with hardware option (neon, vfp) and software option (softp) in one line. 

> # Other potentially useful options
> #-ftree-vectorize -ffast-math -fno-omit-frame-pointer
> 
> -FEED_ARCH = "armv7a"
> -BASE_PACKAGE_ARCH = "armv7a"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
> +PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX} armv7a${ENDSUFX}"

Taking armv7a as an example with my angstrom hat on I need the following knobs:

1) softp or hardfp calling conventions, resulting in a different package arch (e.g. armv7a vs armv7ahf) (link incompatible)
2) neon or not, resulting in a different packagearch (e.g armv7a vs armv7a-vfponly) (link compatible)
3) Thumb2 or arm mode, no direct need for different packagearch, they are compatible
4) use FPU fw or not (TARGET_PFU) (slightly different from 2.)

Do you have any examples on how the package arch will look with this patchset?

regards,

Koen