* [RFC PATCH 2/3] conf/machine: Overhaul tune include files
@ 2011-07-11 15:57 Richard Purdie
2011-07-11 16:34 ` Koen Kooi
0 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2011-07-11 15:57 UTC (permalink / raw)
To: openembedded-core
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@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-yocto/conf/machine/beagleboard.conf b/meta-yocto/conf/machine/beagleboard.conf
index fddacf9..0b3cebc 100644
--- a/meta-yocto/conf/machine/beagleboard.conf
+++ b/meta-yocto/conf/machine/beagleboard.conf
@@ -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 \
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 463991d..5258c91 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -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)
##################################################################
diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 2ea3c9d..d18a7ba 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -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"
diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
index 564b557..3ee2e90 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -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"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 9d546c9..eeb63f4 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -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:
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
index 5446ce8..a7dc1be 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -1,3 +1,5 @@
+require conf/machine/include/arch-arm.inc
+
FEED_ARCH = "armv4t"
BASE_PACKAGE_ARCH = "armv4t"
PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
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
+
+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}"
+
diff --git a/meta/conf/machine/include/tune-atom.inc b/meta/conf/machine/include/tune-atom.inc
index 399ea54..b00c223 100644
--- a/meta/conf/machine/include/tune-atom.inc
+++ b/meta/conf/machine/include/tune-atom.inc
@@ -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"
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
# 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}"
+
diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
index f136710..7e1e2f7 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -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
diff --git a/meta/conf/machine/include/tune-thumb.inc b/meta/conf/machine/include/tune-thumb.inc
index a25cb53..548868f 100644
--- a/meta/conf/machine/include/tune-thumb.inc
+++ b/meta/conf/machine/include/tune-thumb.inc
@@ -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"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 8b14731..2eb885b 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -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"
--
1.7.4.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-11 15:57 [RFC PATCH 2/3] conf/machine: Overhaul tune include files Richard Purdie
@ 2011-07-11 16:34 ` Koen Kooi
2011-07-11 16:47 ` Richard Purdie
0 siblings, 1 reply; 8+ messages in thread
From: Koen Kooi @ 2011-07-11 16:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-11 16:34 ` Koen Kooi
@ 2011-07-11 16:47 ` Richard Purdie
2011-07-11 16:49 ` Richard Purdie
2011-07-11 17:04 ` Koen Kooi
0 siblings, 2 replies; 8+ messages in thread
From: Richard Purdie @ 2011-07-11 16:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Mon, 2011-07-11 at 18:34 +0200, Koen Kooi wrote:
> 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@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?
Oops, sorry, those dropped out the patchset as I was cleaning it up. I
makes a lot more sense with these. They are:
diff --git a/meta/conf/machine/include/arch-arm.inc b/meta/conf/machine/include/arch-arm.inc
new file mode 100644
index 0000000..bf2df5f
--- a/dev/null
+++ b/meta/conf/machine/include/arch-arm.inc
@@ -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)}"
diff --git a/meta/conf/machine/include/arch-ia32.inc b/meta/conf/machine/include/arch-ia32.inc
new file mode 100644
index 0000000..8d3f678
--- a/dev/null
+++ b/meta/conf/machine/include/arch-ia32.inc
@@ -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
> > +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.
These need splitting off into different options. The info you've added
below gives me a better idea of how to do that.
> > # 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?
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}"
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-11 16:47 ` Richard Purdie
@ 2011-07-11 16:49 ` Richard Purdie
2011-07-11 17:04 ` Koen Kooi
1 sibling, 0 replies; 8+ messages in thread
From: Richard Purdie @ 2011-07-11 16:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Mon, 2011-07-11 at 17:47 +0100, Richard Purdie wrote:
> On Mon, 2011-07-11 at 18:34 +0200, Koen Kooi wrote:
> > 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}"
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-11 16:47 ` Richard Purdie
2011-07-11 16:49 ` Richard Purdie
@ 2011-07-11 17:04 ` Koen Kooi
2011-07-12 8:41 ` Richard Purdie
1 sibling, 1 reply; 8+ messages in thread
From: Koen Kooi @ 2011-07-11 17:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
> On Mon, 2011-07-11 at 18:34 +0200, Koen Kooi wrote:
>> 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@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?
>
> Oops, sorry, those dropped out the patchset as I was cleaning it up. I
> makes a lot more sense with these. They are:
>
> diff --git a/meta/conf/machine/include/arch-arm.inc b/meta/conf/machine/include/arch-arm.inc
> new file mode 100644
> index 0000000..bf2df5f
> --- a/dev/null
> +++ b/meta/conf/machine/include/arch-arm.inc
> @@ -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)}"
> diff --git a/meta/conf/machine/include/arch-ia32.inc b/meta/conf/machine/include/arch-ia32.inc
> new file mode 100644
> index 0000000..8d3f678
> --- a/dev/null
> +++ b/meta/conf/machine/include/arch-ia32.inc
> @@ -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
>
>>> +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.
>
> 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.
>>> # 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?
>
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-11 17:04 ` Koen Kooi
@ 2011-07-12 8:41 ` Richard Purdie
2011-07-12 9:30 ` Koen Kooi
0 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2011-07-12 8:41 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Mon, 2011-07-11 at 19:04 +0200, Koen Kooi wrote:
> Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
> >> 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}"
>
> 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:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp4&id=d2a0bf99fd573221f230bb5253b85166997fac69
Cheers,
Richard
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-12 8:41 ` Richard Purdie
@ 2011-07-12 9:30 ` Koen Kooi
2011-07-12 11:25 ` Richard Purdie
0 siblings, 1 reply; 8+ messages in thread
From: Koen Kooi @ 2011-07-12 9:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 12 jul 2011, om 10:41 heeft Richard Purdie het volgende geschreven:
> On Mon, 2011-07-11 at 19:04 +0200, Koen Kooi wrote:
>> Op 11 jul 2011, om 18:47 heeft Richard Purdie het volgende geschreven:
>>>> 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}"
>>
>> 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:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp4&id=d2a0bf99fd573221f230bb5253b85166997fac69
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:
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 2/3] conf/machine: Overhaul tune include files
2011-07-12 9:30 ` Koen Kooi
@ 2011-07-12 11:25 ` Richard Purdie
0 siblings, 0 replies; 8+ messages in thread
From: Richard Purdie @ 2011-07-12 11:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-12 at 11:30 +0200, Koen Kooi wrote:
> Op 12 jul 2011, om 10:41 heeft Richard Purdie het volgende geschreven:
> > An updated version of this with a few more pieces filled out is
> > available at:
> >
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp4&id=d2a0bf99fd573221f230bb5253b85166997fac69
>
> 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"
> 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"
> And
>
> ARM_FP_ABI = "hardfp"
>
> becomes
>
> TUNE_FEATURES += "callconvention-hard"
Correct.
> 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.
> I would also add something like the following:
>
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -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.
> Finally a small nitpick: debian uses 'hf' as hardfloat suffix and I prefer that over '-hfp'.
Easy to change, I have no real preference.
> Meego calls it armv8, but let's not go there.
Agreed ;-).
Cheers,
Richard
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-07-12 11:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-11 15:57 [RFC PATCH 2/3] conf/machine: Overhaul tune include files Richard Purdie
2011-07-11 16:34 ` Koen Kooi
2011-07-11 16:47 ` Richard Purdie
2011-07-11 16:49 ` Richard Purdie
2011-07-11 17:04 ` Koen Kooi
2011-07-12 8:41 ` Richard Purdie
2011-07-12 9:30 ` Koen Kooi
2011-07-12 11:25 ` Richard Purdie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.