conf/machine: Overhaul tune include files
RFC PATCH 2/3 conf/machine: Overhaul tune include files
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).
--- 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(-)
meta-yocto/conf/machine/beagleboard.conf +0 -1
@@ -1,7 +1,6 @@ #@TYPE: Machine #@NAME: Beagleboard machine #@DESCRIPTION: Machine configuration for the http://beagleboard.org/ board -TARGET_ARCH = "arm" PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86-lite" XSERVER = "xserver-xf86-lite \
meta/conf/bitbake.conf +7 -4
@@ -76,7 +76,7 @@ HOST_PREFIX = "${TARGET_PREFIX}" HOST_CC_ARCH = "${TARGET_CC_ARCH}" HOST_EXEEXT = "" -TARGET_ARCH = "INVALID" +TARGET_ARCH = "${TUNE_ARCH}" TARGET_OS = "INVALID" TARGET_VENDOR = "-oe" TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, 1) == ('' or 'custom')]}"
@@ -90,9 +90,9 @@ SDK_SYS = "${SDK_ARCH}${SDK_VENDOR}${@['-' + bb.data.getVar('SDK_OS', d, 1), ''] SDK_PREFIX = "${SDK_SYS}-" SDK_CC_ARCH = "${BUILD_CC_ARCH}" -BASE_PACKAGE_ARCH = "${HOST_ARCH}" -PACKAGE_ARCH = "${BASE_PACKAGE_ARCH}" -MACHINE_ARCH = "${@[bb.data.getVar('BASE_PACKAGE_ARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-', '_')}" +BASE_PACKAGE_ARCH = "${TUNE_PKGARCH}" +PACKAGE_ARCH = "${BASE_PACKAGE_PKGARCH}" +MACHINE_ARCH = "${@[bb.data.getVar('TUNE_PKGARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-', '_')}" PACKAGE_EXTRA_ARCHS ??= "${TARGET_ARCH}" PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}" # MACHINE_ARCH shouldn't be included here as a variable dependency
@@ -654,6 +654,9 @@ include conf/documentation.conf require conf/sanity.conf require conf/abi_version.conf +TUNE_ARCH ?= "INVALID" +TUNE_FEATURES ?= "${TUNE_FEATURES_tune-${TUNE_PKGARCH}}" + ################################################################## # Weak variables (usually to retain backwards compatibility) ##################################################################
meta/conf/machine/include/tune-arm1136jf-s.inc +2 -0
@@ -1,3 +1,5 @@ +require conf/machine/include/arch-arm.inc + TARGET_CC_ARCH = "-march=armv6j -mtune=arm1136jf-s" TARGET_CC_ARCH += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}" FEED_ARCH = "armv6"
meta/conf/machine/include/tune-arm920t.inc +2 -0
@@ -1,3 +1,5 @@ +require conf/machine/include/arch-arm.inc + FEED_ARCH = "armv4t" BASE_PACKAGE_ARCH = "armv4t" TARGET_CC_ARCH = "-march=armv4t -mtune=arm920t"
meta/conf/machine/include/tune-arm926ejs.inc +2 -0
@@ -1,3 +1,5 @@ +require conf/machine/include/arch-arm.inc + FEED_ARCH = "armv5te" PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te" # For gcc 3.x you need:
meta/conf/machine/include/tune-arm9tdmi.inc +2 -0
@@ -1,3 +1,5 @@ +require conf/machine/include/arch-arm.inc + FEED_ARCH = "armv4t" BASE_PACKAGE_ARCH = "armv4t" PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
meta/conf/machine/include/tune-armv7.inc +12 -4
@@ -1,7 +1,15 @@ +require conf/machine/include/arch-arm.inc + +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)}" + +PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}" +
meta/conf/machine/include/tune-atom.inc +6 -2
@@ -1,5 +1,9 @@ -BASE_PACKAGE_ARCH = "core2" +require conf/machine/include/arch-ia32.inc + +TUNE_PKGARCH = "core2" +TUNE_FEATURES_tune-core2 ??= "" + TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse" -#MOBLIN_CFLAGS = "-Os -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables" +TARGET_CC_ARCH_ml-tune-lib64 = "-m64 -march=core2 -msse3 -mtune=generic -mfpmath=sse" PACKAGE_EXTRA_ARCHS = "x86 i386 i486 i586 i686 core2"
meta/conf/machine/include/tune-cortexa8.inc +7 -3
@@ -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 # 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}" +
meta/conf/machine/include/tune-strongarm1100.inc +2 -0
@@ -1,3 +1,5 @@ +require conf/machine/include/arch-arm.inc + # This machine lists common configuration options for Strongarm 1100 devices # NOTE: The Zaurus Collie also has a Strongarm processor, but uses the 1110 type
meta/conf/machine/include/tune-thumb.inc +4 -18
@@ -1,32 +1,18 @@ -#tune file for thumb instructions - -ARM_INSTRUCTION_SET ?= "arm" -# "arm" "thumb" # The instruction set the compiler should use when generating application # code. The kernel is always compiled with arm code at present. arm code # is the original 32 bit ARM instruction set, thumb code is the 16 bit # encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size) # but requires more instructions (140% for 70% smaller code) so may be # slower. +TARGET_CC_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "thumb-instructions", "-mthumb", "-mno-thumb" ,d)}" +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb-instructions", ":thumb", "" ,d)} -THUMB_INTERWORK ?= "yes" -# "yes" "no" # Whether to compile with code to allow interworking between the two # instruction sets. This allows thumb code to be executed on a primarily # arm system and vice versa. It is strongly recommended that DISTROs not # turn this off - the actual cost is very small. +TARGET_CC_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "thumb-interwork", "-mthumb-interwork", "-mno-thumb-interwork" ,d)}" +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb-interwork", ":thumb-interwork", "" ,d)} -OVERRIDE_THUMB = "${@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}" -OVERRIDE_INTERWORK = "${@['', ':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}" -OVERRIDES .= "${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}" - -# Compiler and linker options for application code and kernel code. These -# options ensure that the compiler has the correct settings for the selected -# instruction set and interworking. -ARM_INTERWORK_M_OPT = "${@['-mno-thumb-interwork', '-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}" -ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}" - -# -TARGET_CC_ARCH += "${ARM_INTERWORK_M_OPT} ${ARM_THUMB_M_OPT}" TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
meta/conf/machine/qemux86.conf +2 -1
@@ -2,7 +2,8 @@ #@NAME: common_pc #@DESCRIPTION: Machine configuration for running a common x86 -TARGET_ARCH = "i586" +require conf/machine/include/arch-ia32.inc +TUNE_PKGARCH = "i586" PREFERRED_PROVIDER_virtual/libgl = "mesa-dri" PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
Signature · 1 line
1.7.4.1
Op 11 jul 2011, om 17:57 heeft Richard Purdie het volgende geschreven:
Quoted 55 lines
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 asTARGET_ARCHand 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_ARCHneeds 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_FEATURESvariable 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 <[email protected]>---
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(-)meta/conf/machine/include/tune-armv7.inc +0
-0
meta/conf/machine/include/tune-armv7.inc line 1
Quoted 1 line
meta/conf/machine/include/tune-armv7.inc +1
-0@@ -1,7 +1,15 @@ +require conf/machine/include/arch-arm.inc
Where does that file live?
Quoted 4 lines
meta/conf/machine/include/tune-armv7.inc +3
-0+TUNE_PKGARCH = "armv7" +TUNE_FEATURES_tune-armv7 ??= "hard-fpu" + # valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
meta/conf/machine/include/tune-armv7.inc line 12
Quoted 10 lines
meta/conf/machine/include/tune-armv7.inc +4
-4# 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)
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
Quoted 16 lines
meta/conf/machine/include/tune-armv7.inc +1
-0+PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}"meta/conf/machine/include/tune-cortexa8.inc +5
-0@@ -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.
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp · line 16
Quoted 7 lines
meta/conf/machine/include/tune-cortexa8.inc +1
-3# 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
Quoted 52 lines · Koen Kooi
Op 11 jul 2011, om 17:57 heeft Richard Purdie het volgende geschreven:
Quoted 49 lines
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 asTARGET_ARCHand 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_ARCHneeds 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_FEATURESvariable 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 <[email protected]>---
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(-)
Quoted 8 lines
meta/conf/machine/include/tune-armv7.inc line 1
Quoted 6 lines
meta/conf/machine/include/tune-armv7.inc +1
-0@@ -1,7 +1,15 @@ +require conf/machine/include/arch-arm.incWhere does that file live?
Oops, sorry, those dropped out the patchset as I was cleaning it up. I makes a lot more sense with these. They are:
meta/conf/machine/include/arch-arm.inc renamed from dev/null +4 -0
@@ -0,0 +1,4 @@ +TUNEVALID += "bigendian" +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm" ,d)}" + +ENDSUFX = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "" ,d)}"
meta/conf/machine/include/arch-ia32.inc renamed from dev/null +17 -0
@@ -0,0 +1,17 @@ +TUNEVALID += "m64" +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "m64", "x86_64", "i586" ,d)}" + +TUNEVALID += "ml-lib32" +TUNE_ARCH_ml-tune-lib32 = "i586" +base_libdir_ml-tune-lib32 = "${base_prefix}/lib32" +libdir_ml-tune-lib32 = "${exec_prefix}/lib32" +TUNEOVERRIDES += "${@bb.utils.contains("TUNE_FEATURES", "ml-lib32", ":ml-tune-lib32", "", d)}" + +TUNEVALID += "ml-lib64" +TUNE_ARCH_ml-tune-lib64 = "x86_64" +base_libdir_ml-tune-lib64 = "${base_prefix}/lib64" +libdir_ml-tune-lib64 = "${exec_prefix}/lib64" +TUNEOVERRIDES += "${bb.utils.contains("TUNE_FEATURES", "ml-lib64", ":ml-tune-lib64", "", d)}" + +OVERRIDES .= "${TUNEOVERRIDES}" +
--
cgit v0.8.3.3-89-gbf82
Quoted 29 lines
Quoted 4 lines
meta/conf/machine/include/tune-armv7.inc +3
-0+TUNE_PKGARCH = "armv7" +TUNE_FEATURES_tune-armv7 ??= "hard-fpu" + # valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'meta/conf/machine/include/tune-armv7.inc line 11
Quoted 10 lines
meta/conf/machine/include/tune-armv7.inc +4
-4# 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)
Quoted 12 lines
meta/conf/machine/include/tune-armv7.inc +1
-0+PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}"meta/conf/machine/include/tune-cortexa8.inc +5
-0@@ -1,3 +1,8 @@ +require conf/machine/include/arch-arm.inc + +TUNE_PKGARCH = "armv7a" +TUNE_FEATURES_tune-armv7a ??= "hard-fpu" +
Quoted 8 lines
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
Quoted 4 lines
meta/conf/machine/include/tune-cortexa8.inc +0
-0# 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=softfpAnd 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.
These need splitting off into different options. The info you've added below gives me a better idea of how to do that.
Quoted 10 lines
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp · line 16
Quoted 7 lines
meta/conf/machine/include/tune-cortexa8.inc +1
-3# 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:
Quoted 6 lines
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?
I added in code to differentiate between big and little endian. We can add in code to add extra options, e.g. in the tune-armv7 case:
TARGET_CC_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"
Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
Quoted 139 lines · Koen Kooi
Quoted 52 lines
Op 11 jul 2011, om 17:57 heeft Richard Purdie het volgende geschreven:
Quoted 49 lines
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 asTARGET_ARCHand 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_ARCHneeds 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_FEATURESvariable 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 <[email protected]>---
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(-)Quoted 8 lines
meta/conf/machine/include/tune-armv7.inc line 1
Quoted 6 lines
meta/conf/machine/include/tune-armv7.inc +1
-0@@ -1,7 +1,15 @@ +require conf/machine/include/arch-arm.incWhere does that file live?
Oops, sorry, those dropped out the patchset as I was cleaning it up. I makes a lot more sense with these. They are:
meta/conf/machine/include/arch-arm.inc renamed from dev/null +4
-0@@ -0,0 +1,4 @@ +TUNEVALID += "bigendian" +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm" ,d)}" + +ENDSUFX = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "" ,d)}"meta/conf/machine/include/arch-ia32.inc renamed from dev/null +17
-1@@ -0,0 +1,17 @@ +TUNEVALID += "m64" +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "m64", "x86_64", "i586" ,d)}" + +TUNEVALID += "ml-lib32" +TUNE_ARCH_ml-tune-lib32 = "i586" +base_libdir_ml-tune-lib32 = "${base_prefix}/lib32" +libdir_ml-tune-lib32 = "${exec_prefix}/lib32" +TUNEOVERRIDES += "${@bb.utils.contains("TUNE_FEATURES", "ml-lib32", ":ml-tune-lib32", "", d)}" + +TUNEVALID += "ml-lib64" +TUNE_ARCH_ml-tune-lib64 = "x86_64" +base_libdir_ml-tune-lib64 = "${base_prefix}/lib64" +libdir_ml-tune-lib64 = "${exec_prefix}/lib64" +TUNEOVERRIDES += "${bb.utils.contains("TUNE_FEATURES", "ml-lib64", ":ml-tune-lib64", "", d)}" + +OVERRIDES .= "${TUNEOVERRIDES}" + --cgit v0.8.3.3-89-gbf82
Quoted 29 lines
Quoted 4 lines
meta/conf/machine/include/tune-armv7.inc +3
-0+TUNE_PKGARCH = "armv7" +TUNE_FEATURES_tune-armv7 ??= "hard-fpu" + # valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'meta/conf/machine/include/tune-armv7.inc line 11
Quoted 10 lines
meta/conf/machine/include/tune-armv7.inc +4
-4# 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)
Quoted 12 lines
meta/conf/machine/include/tune-armv7.inc +1
-0+PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH} armv4${ENDSUFX} armv4t${ENDSUFX} armv5te${ENDSUFX} armv6${ENDSUFX} armv7${ENDSUFX}"meta/conf/machine/include/tune-cortexa8.inc +5
-0@@ -1,3 +1,8 @@ +require conf/machine/include/arch-arm.inc + +TUNE_PKGARCH = "armv7a" +TUNE_FEATURES_tune-armv7a ??= "hard-fpu" +Quoted 8 lines
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
Quoted 4 lines
meta/conf/machine/include/tune-cortexa8.inc +0
-0# 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=softfpAnd 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.
Quoted 2 lines
These need splitting off into different options. The info you've added below gives me a better idea of how to do that.
It's a mess and seems to be specific to arm, although ppc-spe and mips have similar issues.
Quoted 17 lines
Quoted 10 lines
meta/conf/machine/include/tune-cortexa8.inc TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp · line 16
Quoted 7 lines
meta/conf/machine/include/tune-cortexa8.inc +1
-3# 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:
Quoted 6 lines
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?
Quoted 7 lines
I added in code to differentiate between big and little endian. We can add in code to add extra options, e.g. in the tune-armv7 case:
TARGET_CC_ARCH+= "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
PACKAGE_EXTRA_ARCHS= "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"
And SUFX2 being 'hf' or '', right? If so, the proposal looks good to me, but I need to digest it some more.
Quoted 14 lines · Koen Kooi
Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
Quoted 13 lines
Quoted 8 lines
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?
I added in code to differentiate between big and little endian. We can add in code to add extra options, e.g. in the tune-armv7 case:
Quoted 5 lines
Quoted 3 lines
TARGET_CC_ARCH+= "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
PACKAGE_EXTRA_ARCHS= "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"And SUFX2 being 'hf' or '', right? If so, the proposal looks good to me, but I need to digest it some more.
Correct.
An updated version of this with a few more pieces filled out is available at:
Cheers,
Richard
Op 12 jul 2011, om 10:41 heeft Richard Purdie het volgende geschreven:
Quoted 19 lines · Koen Kooi
Quoted 18 lines
Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
Quoted 16 lines
Quoted 8 lines
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?
I added in code to differentiate between big and little endian. We can add in code to add extra options, e.g. in the tune-armv7 case:
TARGET_CC_ARCH+= "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
PACKAGE_EXTRA_ARCHS= "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"
Quoted 8 lines
Quoted 1 line
And SUFX2 being 'hf' or '', right? If so, the proposal looks good to me, but I need to digest it some more.
Correct.
An updated version of this with a few more pieces filled out is available at:
If I understand it correctly
TARGET_FPU_armv7a = "hard"
TARGET_FPU ?= "soft"
becomes
TUNE_FEATURES_append_armv7a = " hard"
And
ARM_FP_ABI = "hardfp"
becomes
TUNE_FEATURES += "callconvention-hard"
And to maintain the status quo for beagleboard/angstrom:
TUNE_FEATURES_append_omap3 = " neon"
I would also add something like the following:
meta/classes/base.bbclass +1 -1
@@ -166,7 +166,7 @@ python base_eventhandler() { if name.startswith("BuildStarted"): bb.data.setVar( 'BB_VERSION', bb.__version__, e.data ) - statusvars = ['BB_VERSION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO', 'DISTRO_VERSION','TARGET_FPU'] + statusvars = ['BB_VERSION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO', 'DISTRO_VERSION','TUNE_FEATURES'] statuslines = ["%-17s = \"%s\"" % (i, bb.data.getVar(i, e.data, 1) or '') for i in statusvars]
Finally a small nitpick: debian uses 'hf' as hardfloat suffix and I prefer that over '-hfp'. Meego calls it armv8, but let's not go there.
regards,
Koen
Quoted 10 lines · Koen Kooi
Op 12 jul 2011, om 10:41 heeft Richard Purdie het volgende geschreven:
Quoted 4 lines
An updated version of this with a few more pieces filled out is available at:
If I understand it correctly
TARGET_FPU_armv7a= "hard"
TARGET_FPU?= "soft"
These actually become the defaults for armv7 since:
meta/conf/machine/include/tune-armv7.inc:
TUNE_FEATURES_tune-armv7 ??= "fpu-hard"
Quoted 3 lines
becomes
TUNE_FEATURES_append_armv7a= " hard"
but the distro can override TUNE_FEATURES_tune-armv7 as required. The value in question would be "" or "fpu-hard". You'd actually want:
TUNE_FEATURES_tune-armv7_append = "xxx"
or just set it to what you want:
TUNE_FEATURES_tune-armv7 = "fpu-hard neon"
Quoted 7 lines
And
ARM_FP_ABI= "hardfp"becomes
TUNE_FEATURES += "callconvention-hard"
Correct.
Quoted 3 lines
And to maintain the status quo for beagleboard/angstrom:
TUNE_FEATURES_append_omap3= " neon"
There isn't an omap3 tune in there at present but:
meta/conf/machine/include/tune-cortexa8.inc:
TUNE_FEATURES_tune-cortexa8 ??= "hard-fpu neon"
so neon is the default for that platform. I'm imagining that for omap3 we can do something similar.
meta/classes/base.bbclass python base_eventhandler() { · line 169
Quoted 10 lines
I would also add something like the following:
meta/classes/base.bbclass +1
-1@@ -166,7 +166,7 @@ python base_eventhandler() { if name.startswith("BuildStarted"): bb.data.setVar( 'BB_VERSION', bb.__version__, e.data ) - statusvars = ['BB_VERSION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO', 'DISTRO_VERSION','TARGET_FPU'] + statusvars = ['BB_VERSION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO', 'DISTRO_VERSION','TUNE_FEATURES'] statuslines = ["%-17s = \"%s\"" % (i, bb.data.getVar(i, e.data, 1) or '') for i in statusvars]
Agreed, that is a useful touch and makes that line in the status way more useful for other architectures too.
Quoted 1 line
Finally a small nitpick: debian uses 'hf' as hardfloat suffix and I prefer that over '-hfp'.
Easy to change, I have no real preference.
Quoted 1 line
Meego calls it armv8, but let's not go there.
Agreed ;-).
Cheers,
Richard
Quoted 10 lines · Richard Purdie
Quoted 8 lines · Koen Kooi
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?
Quoted 7 lines
I added in code to differentiate between big and little endian. We can add in code to add extra options, e.g. in the tune-armv7 case:
TARGET_CC_ARCH+= "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}"
PACKAGE_EXTRA_ARCHS= "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"
Sorry, I hit sent early accidently whilst trying to paste something in here.
I was thinking something along these lines:
TUNE_PKGARCH = "armv7${SUFX2}"TARGET_CC_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hardfp", "-mfloat-abi=softfp" ,d)}" SUFX2 = "${@bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-hfp", "" ,d)}
PACKAGE_EXTRA_ARCHS = "${TUNE_ARCH}${SUFX2} armv4${ENDSUFX}${SUFX2} armv4t${ENDSUFX}${SUFX2} armv5te${ENDSUFX}${SUFX2} armv6${ENDSUFX}${SUFX2} armv7${ENDSUFX}${SUFX2}"
Where "hardfp" support might be in tune-arm-feature-hardfp.inc