* [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
[not found] <cover.1311683981.git.richard.purdie@linuxfoundation.org>
@ 2011-07-26 12:44 ` Richard Purdie
2011-07-26 12:46 ` Koen Kooi
` (5 more replies)
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
2011-07-26 12:44 ` [PATCH 3/3] Add basic PowerPC " Richard Purdie
2 siblings, 6 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 12:44 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/arm/arch-arm.inc | 16 +++++-
meta/conf/machine/include/arm/arch-armv4.inc | 24 +++++++++
meta/conf/machine/include/arm/arch-armv5-dsp.inc | 40 ++++++++++++++
meta/conf/machine/include/arm/arch-armv5.inc | 51 ++++++++++++++++++
meta/conf/machine/include/arm/arch-armv6.inc | 32 +++++++++++
meta/conf/machine/include/arm/arch-armv7.inc | 55 ++++++++++++++++++++
meta/conf/machine/include/arm/arch-armv7a.inc | 54 +++++++++++++++++++
meta/conf/machine/include/arm/feature-arm-neon.inc | 3 +
.../conf/machine/include/arm/feature-arm-thumb.inc | 25 +++++++++
meta/conf/machine/include/arm/feature-arm-vfp.inc | 6 ++
meta/conf/machine/include/tune-arm1136jf-s.inc | 14 +++---
meta/conf/machine/include/tune-arm920t.inc | 14 ++++--
meta/conf/machine/include/tune-arm926ejs.inc | 18 ++++---
meta/conf/machine/include/tune-arm9tdmi.inc | 14 ++++--
meta/conf/machine/include/tune-armv7.inc | 8 +---
meta/conf/machine/include/tune-cortexa8.inc | 21 ++++----
meta/conf/machine/include/tune-cortexm1.inc | 13 ++++-
meta/conf/machine/include/tune-cortexm3.inc | 18 +++++--
meta/conf/machine/include/tune-cortexr4.inc | 18 +++++--
meta/conf/machine/include/tune-ep9312.inc | 16 ++++--
meta/conf/machine/include/tune-iwmmxt.inc | 18 +++++--
meta/conf/machine/include/tune-strongarm1100.inc | 13 +++--
meta/conf/machine/include/tune-xscale.inc | 18 ++++--
23 files changed, 435 insertions(+), 74 deletions(-)
create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index c517df6..4ea8b2b 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -1,3 +1,17 @@
-TUNE_ARCH = "arm"
+
+TUNEVALID[bigendian] = "Enable big-endian mode."
+
+ARMPKGARCH ??= "arm"
+ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
+ARMPKGSFX_FPU ??= ""
+ARMPKGSFX_DSP ??= ""
+ARMPKGSFX_EABI ??= ""
+ARMPKGSFX_THUMB ??= ""
+
+TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
+TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
ABIEXTENSION = "eabi"
+
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
+
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
new file mode 100644
index 0000000..c014d20
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -0,0 +1,24 @@
+DEFAULTTUNE ?= "armv4"
+
+ARMPKGARCH ?= "armv4"
+
+TUNEVALID[armv4] = "Enable instructions for ARMv4"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
+
+require conf/machine/include/arm/arch-arm.inc
+require conf/machine/include/arm/feature-arm-thumb.inc
+
+# Little Endian
+AVAILTUNES += "armv4 armv4t"
+TUNE_FEATURES_tune-armv4 ?= "armv4"
+TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
+PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
+
+# Big Endian
+AVAILTUNES += "armv4b armv4tb"
+TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
+TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
+PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
+
diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
new file mode 100644
index 0000000..498a012
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -0,0 +1,40 @@
+ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
+
+require conf/machine/include/arm/arch-armv5.inc
+
+# Little Endian
+AVAILTUNES += "armv5e armv5te"
+TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
+TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
+PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
+
+# Little Endian + VFP/DSP
+AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
+TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
+TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
+TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv5eb armv5teb"
+TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
+TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
+PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
+
+# Big Endian + VFP/DSP
+AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
+TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
+TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
+TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
+
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
new file mode 100644
index 0000000..55cbe03
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -0,0 +1,51 @@
+DEFAULTTUNE ?= "armv5"
+
+ARMPKGARCH ?= "armv5"
+
+TUNEVALID[armv5] = "Enable instructions for ARMv5"
+TUNE_CONFLICTS[armv5] = "armv4"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
+
+ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
+
+require conf/machine/include/arm/arch-armv4.inc
+require conf/machine/include/arm/feature-arm-vfp.inc
+
+# Little Endian
+AVAILTUNES += "armv5 armv5t armv5e armv5te"
+TUNE_FEATURES_tune-armv5 ?= "armv5"
+TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
+PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
+
+# Little Endian + VFP/DSP
+AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
+TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
+TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
+TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv5b armv5tb"
+TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
+TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
+PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
+
+# Big Endian + VFP/DSP
+AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
+TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
+TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
+TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
+
+
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
new file mode 100644
index 0000000..20924c9
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -0,0 +1,32 @@
+DEFAULTTUNE ?= "armv6"
+
+ARMPKGARCH ?= "armv6"
+
+TUNEVALID[armv6] = "Enable instructions for ARMv6"
+TUNE_CONFLICTS[armv6] = "armv4 armv5"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+# Little Endian
+AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
+TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
+TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
+TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
+TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
+TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
+TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
+TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
+TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
+
diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
new file mode 100644
index 0000000..8bc8d10
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv7.inc
@@ -0,0 +1,55 @@
+DEFAULTTUNE ?= "armv7"
+
+ARMPKGARCH ?= "armv7"
+
+TUNEVALID[armv7] = "Enable instructions for ARMv7"
+TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
+
+require conf/machine/include/arm/arch-armv6.inc
+require conf/machine/include/arm/feature-arm-neon.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
+TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
+TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
+TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
+TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
+
+# VFP Tunes
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
+TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
+TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
+
+# Big Endian
+AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
+TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
+TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
+TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
+TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
+
+# Big Endian + VFP
+AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
+TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
+TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
+TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
+
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
new file mode 100644
index 0000000..ce9cee5
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -0,0 +1,54 @@
+DEFAULTTUNE ?= "armv7a"
+
+ARMPKGARCH ?= "armv7a"
+
+TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
+TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
+
+require conf/machine/include/arm/arch-armv7.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
+TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
+TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
+TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
+TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
+
+# VFP Tunes
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
+TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
+TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
+
+# Big Endian
+AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
+TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
+TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
+TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
+TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
+
+# Big Endian + VFP
+AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
+TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
+TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
+TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
+
diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
new file mode 100644
index 0000000..a7dac03
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
@@ -0,0 +1,3 @@
+TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
new file mode 100644
index 0000000..9a607c6
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -0,0 +1,25 @@
+# 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.
+TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
+OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
+
+# Note armv7 will hit on armv7a as well
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
+
+# 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.
+TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
+OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
+
+TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
new file mode 100644
index 0000000..29a925c
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
@@ -0,0 +1,6 @@
+TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
+
+TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
+ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 953f0dd..4f4a2eb 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -1,10 +1,10 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm1136jfs"
-TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
-TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
-TUNE_PKGARCH = "armv6"
+require conf/machine/include/arm/arch-armv6.inc
-ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
+TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
-require conf/machine/include/tune-thumb.inc
+AVAILTUNES += "arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
+PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
index 6c87026..b7584ab 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -1,5 +1,11 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm920t"
+
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
+
+AVAILTUNES += "arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
+PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
-TUNE_PKGARCH = "armv4t"
-TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 543ab62..7f2cc4e 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,9 +1,11 @@
-require conf/machine/include/arm/arch-arm.inc
-
-TUNE_PKGARCH = "armv5te"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
-# For gcc 3.x you need:
-#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
-# For gcc 4.x you need:
-TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
+DEFAULTTUNE ?= "arm926ejs"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
+
+AVAILTUNES += "arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
+PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
index f1001ac..0dc5c26 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -1,5 +1,11 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm9tdmi"
+
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
+
+AVAILTUNES += "arm9tdmi"
+TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
+PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
-TUNE_PKGARCH = "armv4t"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
-TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
index 8a68c0a..664c24b 100644
--- a/meta/conf/machine/include/tune-armv7.inc
+++ b/meta/conf/machine/include/tune-armv7.inc
@@ -1,8 +1,2 @@
-require conf/machine/include/arm/arch-arm.inc
+require conf/machine/include/arm/arch-armv7.inc
-# 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
-TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index ae50954..b07add4 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -1,15 +1,16 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexa8-neon"
+require conf/machine/include/arm/arch-armv7a.inc
-# 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
-# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
+TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
-TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
+AVAILTUNES += "cortexa8 cortexa8t"
+TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
+TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
+TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
-# Other potentially useful options
-#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
+PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
-TUNE_PKGARCH = "armv7a"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
index b944db4..493025d 100644
--- a/meta/conf/machine/include/tune-cortexm1.inc
+++ b/meta/conf/machine/include/tune-cortexm1.inc
@@ -1,4 +1,11 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexm1"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
+
+AVAILTUNES += "cortexm1"
+TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
+PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
-TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv6"
diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
index a77cbdd..f774fa6 100644
--- a/meta/conf/machine/include/tune-cortexm3.inc
+++ b/meta/conf/machine/include/tune-cortexm3.inc
@@ -1,5 +1,15 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexm3"
+ARMPKGARCH ?= "armv7m"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
+
+TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
+
+AVAILTUNES += "cortexm3"
+TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
+PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
-# valid options for -march: `armv7', `armv7-m'
-TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
index c9193ca..738f5af 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -1,5 +1,15 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexr4"
+ARMPKGARCH ?= "armv7r"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
+
+TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
+
+AVAILTUNES += "cortexr4"
+TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
+PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
-# valid options for -march: `armv7', `armv7-r'
-TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
index e04a00a..f10123f 100644
--- a/meta/conf/machine/include/tune-ep9312.inc
+++ b/meta/conf/machine/include/tune-ep9312.inc
@@ -1,9 +1,13 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "ep9312"
+ARMPKGARCH ?= "ep9312"
-TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
-# add "-mfp=maverick" for newer gcc versions > 4.0
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
+
+AVAILTUNES += "ep9312"
+TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
+PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
-#set arch to ep9312 for all generated packages
-PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
-TUNE_PKGARCH = "ep9312"
diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
index 6bb76d5..14f5955 100644
--- a/meta/conf/machine/include/tune-iwmmxt.inc
+++ b/meta/conf/machine/include/tune-iwmmxt.inc
@@ -1,8 +1,16 @@
-require conf/machine/include/arm/arch-arm.inc
-
# Configurations for the Intel PXA27x Appications Processor Family.
# Please use tune-xscale for PXA255/PXA26x based processors.
-TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
-TUNE_PKGARCH = "iwmmxt"
+
+DEFAULTTUNE ?= "iwmmxt"
+ARMPKGARCH ?= "iwmmxt"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
+
+AVAILTUNES += "iwmmxt"
+TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
+PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
+
diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
index 2b76069..66bab8e 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -1,9 +1,12 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "strongarm"
-TUNE_PKGARCH = "arm"
+require conf/machine/include/arm/arch-armv4.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
+TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
+
+AVAILTUNES += "strongarm"
+TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
+PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
-TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 71dba5b..0303320 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,11 +1,17 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "xscale"
-INHERIT += "siteinfo"
+require conf/machine/include/arm/arch-armv5-dsp.inc
-TUNE_CCARGS = "-march=armv5te -mtune=xscale"
-TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
-TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
-PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
+TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
+
+AVAILTUNES += "xscale"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
+
+AVAILTUNES += "xscale-be"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
--
1.7.4.1
^ permalink raw reply related [flat|nested] 92+ messages in thread
* [PATCH 2/3] Add basic Mips core tune config
[not found] <cover.1311683981.git.richard.purdie@linuxfoundation.org>
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
@ 2011-07-26 12:44 ` Richard Purdie
2011-07-26 14:41 ` Mark Hatle
` (2 more replies)
2011-07-26 12:44 ` [PATCH 3/3] Add basic PowerPC " Richard Purdie
2 siblings, 3 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 12:44 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/mips/arch-mips.inc | 64 +++++++++++++++++++++++++-
meta/conf/machine/include/tune-mips32.inc | 10 +++-
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
index f7f4eed..071e6b5 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -1 +1,63 @@
-TUNE_ARCH = "mips"
+# MIPS Architecture definition
+# 12 defined ABIs, all combinations of:
+# *) Big/Little Endian
+# *) Hardware/Software Floating Point
+# *) o32, n32, n64 ABI
+
+DEFAULTTUNE ?= "mips"
+
+# Endianess
+TUNEVALID[bigendian] = "Enable big-endian mode"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d)}"
+
+# ABI flags
+TUNEVALID[o32] = "MIPS o32 ABI"
+TUNECONFLICT[o32] = "n32 n64"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "o32", "-mabi=32", "", d)}"
+
+TUNEVALID[n32] = "MIPS64 n32 ABI"
+TUNECONFLICT[n32] = "o32 n64"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n32", "-mabi=n32", "", d)}"
+
+TUNEVALID[n64] = "MIPS64 n64 ABI"
+TUNECONFLICT[n64] = "o32 n32"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-mabi=64", "", d)}"
+
+# Floating point
+TUNEVALID[fpu-hard] = "Use hardware FPU"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
+TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
+
+# Package naming
+MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
+MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
+
+TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
+
+# Base tunes
+AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
+TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
+BASE_LIB_tune-mips = "lib"
+TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
+BASE_LIB_tune-mips64-n32 = "lib32"
+TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
+BASE_LIB_tune-mips64 = "lib64"
+TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
+BASE_LIB_tune-mipsel = "lib"
+TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
+BASE_LIB_tune-mips64el-n32 = "lib32"
+TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
+BASE_LIB_tune-mips64el = "lib64"
+TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
+BASE_LIB_tune-mips-nf = "lib"
+TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
+BASE_LIB_tune-mips64-nf-n32 = "lib32"
+TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
+BASE_LIB_tune-mips64-nf = "lib64"
+TUNE_FEATURES_tune-mipsel-nf = "o32"
+BASE_LIB_tune-mipsel-nf = "lib"
+TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
+BASE_LIB_tune-mips64el-nf-n32 = "lib32"
+TUNE_FEATURES_tune-mips64el-nf = "n64"
+BASE_LIB_tune-mips64el-nf = "lib64"
+
diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
index 28b0047..1f913df 100644
--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -1,4 +1,10 @@
+DEFAULTTUNE ?= "mips32"
+
require conf/machine/include/mips/arch-mips.inc
-TUNE_CCARGS = "-march=mips32"
-TUNE_PKGARCH = "mips"
+TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
+
+AVAILTUNES += "mips32"
+TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
+PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
--
1.7.4.1
^ permalink raw reply related [flat|nested] 92+ messages in thread
* [PATCH 3/3] Add basic PowerPC core tune config
[not found] <cover.1311683981.git.richard.purdie@linuxfoundation.org>
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
@ 2011-07-26 12:44 ` Richard Purdie
2011-07-26 13:47 ` Kumar Gala
2011-07-26 14:57 ` Mark Hatle
2 siblings, 2 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 12:44 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
6 files changed, 88 insertions(+), 18 deletions(-)
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index 17ace32..3f7befb 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -1,3 +1,44 @@
-TUNE_ARCH = "powerpc"
+# Power Architecture definition
+# Four defined ABIs, all combinations of:
+# *) Hard/Soft Floating Point
+# *) 32-bit/64-bit
+
+DEFAULTTUNE ?= "powerpc"
+
+TUNEVALID[m32] = "Power ELF32 standard ABI"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+
+TUNEVALID[m32-arch] = "Enable powerpc package architecture"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
+
+TUNEVALID[m64] = "Power ELF64 standard ABI"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
+
+TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
+
+TUNEVALID[fpu-hard] = "Use hardware FPU."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
+
+TUNEVALID[fpu-soft] = "Use software FPU."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
+TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
+
+TUNEVALID[spe] = "Enable SPE ABI extensions"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
+
+ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
+
+# Basic tune definitions
+AVAILTUNES += "powerpc powerpc-nf"
+TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
+BASE_LIB_tune-powerpc = "lib"
+TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
+BASE_LIB_tune-powerpc-nf = "lib"
+
+AVAILTUNES += "powerpc64 powerpc64-nf"
+TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
+BASE_LIB_tune-powerpc64 = "lib64"
+TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
+BASE_LIB_tune-powerpc64-nf = "lib64"
-ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
index 61c0669..6991ae0 100644
--- a/meta/conf/machine/include/tune-ppc603e.inc
+++ b/meta/conf/machine/include/tune-ppc603e.inc
@@ -1,5 +1,11 @@
+DEFAULTTUNE ?= "ppc603e"
+
require conf/machine/include/powerpc/arch-powerpc.inc
-TUNE_CCARGS = "-mcpu=603e -mhard-float"
-TUNE_PKGARCH = "ppc603e"
-PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
+TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
+
+AVAILTUNES += "ppc603e"
+TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
+PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
index a38e97c..652422f 100644
--- a/meta/conf/machine/include/tune-ppce300c2.inc
+++ b/meta/conf/machine/include/tune-ppce300c2.inc
@@ -1,5 +1,11 @@
+DEFAULTTUNE ?= "ppce300"
+
require conf/machine/include/powerpc/arch-powerpc.inc
-TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
-TUNE_PKGARCH = "ppce300"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
+TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
+
+AVAILTUNES += "ppce300"
+TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
+PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
index 22208f0..fe62445 100644
--- a/meta/conf/machine/include/tune-ppce500.inc
+++ b/meta/conf/machine/include/tune-ppce500.inc
@@ -1,6 +1,11 @@
+DEFAULTTUNE ?= "ppce500"
+
require conf/machine/include/powerpc/arch-powerpc.inc
-TUNE_CCARGS = "-mcpu=8540"
-BASE_PACKAGE_ARCH = "ppce500"
-TUNE_PKGARCH = "ppce500"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
+TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
+
+AVAILTUNES += "ppce500"
+TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
+PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
index 182d019..0d3640f 100644
--- a/meta/conf/machine/include/tune-ppce500mc.inc
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -1,5 +1,11 @@
+DEFAULTTUNE ?= "ppce500mc"
+
require conf/machine/include/powerpc/arch-powerpc.inc
-TUNE_CCARGS = "-mcpu=e500mc"
-TUNE_PKGARCH = "ppce500mc"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
+TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
+
+AVAILTUNES += "ppce500mc"
+TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
+PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
index daf2d58..e6b48a2 100644
--- a/meta/conf/machine/include/tune-ppce500v2.inc
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -1,5 +1,11 @@
+DEFAULTTUNE ?= "ppce500v2"
+
require conf/machine/include/powerpc/arch-powerpc.inc
-TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
-TUNE_PKGARCH = "ppce500v2"
-PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
+TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
+
+AVAILTUNES += "ppce500v2"
+TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
+PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
--
1.7.4.1
^ permalink raw reply related [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
@ 2011-07-26 12:46 ` Koen Kooi
2011-07-27 12:17 ` Phil Blundell
` (4 subsequent siblings)
5 siblings, 0 replies; 92+ messages in thread
From: Koen Kooi @ 2011-07-26 12:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Doing a build with this one applied now, will report back later
Op 26 jul. 2011, om 14:44 heeft Richard Purdie het volgende geschreven:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/arm/arch-arm.inc | 16 +++++-
> meta/conf/machine/include/arm/arch-armv4.inc | 24 +++++++++
> meta/conf/machine/include/arm/arch-armv5-dsp.inc | 40 ++++++++++++++
> meta/conf/machine/include/arm/arch-armv5.inc | 51 ++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv6.inc | 32 +++++++++++
> meta/conf/machine/include/arm/arch-armv7.inc | 55 ++++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv7a.inc | 54 +++++++++++++++++++
> meta/conf/machine/include/arm/feature-arm-neon.inc | 3 +
> .../conf/machine/include/arm/feature-arm-thumb.inc | 25 +++++++++
> meta/conf/machine/include/arm/feature-arm-vfp.inc | 6 ++
> meta/conf/machine/include/tune-arm1136jf-s.inc | 14 +++---
> meta/conf/machine/include/tune-arm920t.inc | 14 ++++--
> meta/conf/machine/include/tune-arm926ejs.inc | 18 ++++---
> meta/conf/machine/include/tune-arm9tdmi.inc | 14 ++++--
> meta/conf/machine/include/tune-armv7.inc | 8 +---
> meta/conf/machine/include/tune-cortexa8.inc | 21 ++++----
> meta/conf/machine/include/tune-cortexm1.inc | 13 ++++-
> meta/conf/machine/include/tune-cortexm3.inc | 18 +++++--
> meta/conf/machine/include/tune-cortexr4.inc | 18 +++++--
> meta/conf/machine/include/tune-ep9312.inc | 16 ++++--
> meta/conf/machine/include/tune-iwmmxt.inc | 18 +++++--
> meta/conf/machine/include/tune-strongarm1100.inc | 13 +++--
> meta/conf/machine/include/tune-xscale.inc | 18 ++++--
> 23 files changed, 435 insertions(+), 74 deletions(-)
> create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
> index c517df6..4ea8b2b 100644
> --- a/meta/conf/machine/include/arm/arch-arm.inc
> +++ b/meta/conf/machine/include/arm/arch-arm.inc
> @@ -1,3 +1,17 @@
> -TUNE_ARCH = "arm"
> +
> +TUNEVALID[bigendian] = "Enable big-endian mode."
> +
> +ARMPKGARCH ??= "arm"
> +ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
> +ARMPKGSFX_FPU ??= ""
> +ARMPKGSFX_DSP ??= ""
> +ARMPKGSFX_EABI ??= ""
> +ARMPKGSFX_THUMB ??= ""
> +
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
> +TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
>
> ABIEXTENSION = "eabi"
> +
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
> new file mode 100644
> index 0000000..c014d20
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> @@ -0,0 +1,24 @@
> +DEFAULTTUNE ?= "armv4"
> +
> +ARMPKGARCH ?= "armv4"
> +
> +TUNEVALID[armv4] = "Enable instructions for ARMv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
> +
> +require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/feature-arm-thumb.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv4 armv4t"
> +TUNE_FEATURES_tune-armv4 ?= "armv4"
> +TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
> +PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
> +
> +# Big Endian
> +AVAILTUNES += "armv4b armv4tb"
> +TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
> +TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> new file mode 100644
> index 0000000..498a012
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
> +TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
> +TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
> +TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5eb armv5teb"
> +TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
> +TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
> +TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +DEFAULTTUNE ?= "armv5"
> +
> +ARMPKGARCH ?= "armv5"
> +
> +TUNEVALID[armv5] = "Enable instructions for ARMv5"
> +TUNE_CONFLICTS[armv5] = "armv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
> +
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +require conf/machine/include/arm/feature-arm-vfp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> +TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5b armv5tb"
> +TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
> +TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
> +TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
> +
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
> new file mode 100644
> index 0000000..20924c9
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> @@ -0,0 +1,32 @@
> +DEFAULTTUNE ?= "armv6"
> +
> +ARMPKGARCH ?= "armv6"
> +
> +TUNEVALID[armv6] = "Enable instructions for ARMv6"
> +TUNE_CONFLICTS[armv6] = "armv4 armv5"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
> +TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
> +TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
> +TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
> +TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
> +TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
> +TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
> new file mode 100644
> index 0000000..8bc8d10
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7.inc
> @@ -0,0 +1,55 @@
> +DEFAULTTUNE ?= "armv7"
> +
> +ARMPKGARCH ?= "armv7"
> +
> +TUNEVALID[armv7] = "Enable instructions for ARMv7"
> +TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv6.inc
> +require conf/machine/include/arm/feature-arm-neon.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
> +TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
> +TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
> +TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
> +TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
> +TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
> +TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
> +TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
> +TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
> +TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> new file mode 100644
> index 0000000..ce9cee5
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -0,0 +1,54 @@
> +DEFAULTTUNE ?= "armv7a"
> +
> +ARMPKGARCH ?= "armv7a"
> +
> +TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
> +TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv7.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
> +TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
> +TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
> +TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
> +TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
> +TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
> +TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
> +TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
> +TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
> +TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
> new file mode 100644
> index 0000000..a7dac03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
> @@ -0,0 +1,3 @@
> +TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> new file mode 100644
> index 0000000..9a607c6
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -0,0 +1,25 @@
> +# 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.
> +TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
> +
> +# Note armv7 will hit on armv7a as well
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> +
> +# 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.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
> +
> +TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
> diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> new file mode 100644
> index 0000000..29a925c
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> @@ -0,0 +1,6 @@
> +TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
> +
> +TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
> index 953f0dd..4f4a2eb 100644
> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc
> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
> @@ -1,10 +1,10 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm1136jfs"
>
> -TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
> -TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
> -TUNE_PKGARCH = "armv6"
> +require conf/machine/include/arm/arch-armv6.inc
>
> -ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
> +TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
>
> -require conf/machine/include/tune-thumb.inc
> +AVAILTUNES += "arm1136jfs"
> +TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
> +PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
> index 6c87026..b7584ab 100644
> --- a/meta/conf/machine/include/tune-arm920t.inc
> +++ b/meta/conf/machine/include/tune-arm920t.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm920t"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
> +
> +AVAILTUNES += "arm920t"
> +TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
> +PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>
> -TUNE_PKGARCH = "armv4t"
> -TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
> index 543ab62..7f2cc4e 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -1,9 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> -TUNE_PKGARCH = "armv5te"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
> -# For gcc 3.x you need:
> -#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
> -# For gcc 4.x you need:
> -TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
> +DEFAULTTUNE ?= "arm926ejs"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
> +
> +AVAILTUNES += "arm926ejs"
> +TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>
> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
> index f1001ac..0dc5c26 100644
> --- a/meta/conf/machine/include/tune-arm9tdmi.inc
> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm9tdmi"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
> +
> +AVAILTUNES += "arm9tdmi"
> +TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
> +PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>
> -TUNE_PKGARCH = "armv4t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> -TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
> index 8a68c0a..664c24b 100644
> --- a/meta/conf/machine/include/tune-armv7.inc
> +++ b/meta/conf/machine/include/tune-armv7.inc
> @@ -1,8 +1,2 @@
> -require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/arch-armv7.inc
>
> -# 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
> -TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index ae50954..b07add4 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,15 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexa8-neon"
>
> +require conf/machine/include/arm/arch-armv7a.inc
>
> -# 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
> -# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
> +TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
>
> -TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
> +AVAILTUNES += "cortexa8 cortexa8t"
> +TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
> +TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
> +TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
>
> -# Other potentially useful options
> -#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
>
> -TUNE_PKGARCH = "armv7a"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
> diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
> index b944db4..493025d 100644
> --- a/meta/conf/machine/include/tune-cortexm1.inc
> +++ b/meta/conf/machine/include/tune-cortexm1.inc
> @@ -1,4 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm1"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
> +
> +AVAILTUNES += "cortexm1"
> +TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
>
> -TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv6"
> diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
> index a77cbdd..f774fa6 100644
> --- a/meta/conf/machine/include/tune-cortexm3.inc
> +++ b/meta/conf/machine/include/tune-cortexm3.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm3"
> +ARMPKGARCH ?= "armv7m"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
> +
> +TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexm3"
> +TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
>
> -# valid options for -march: `armv7', `armv7-m'
> -TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
> index c9193ca..738f5af 100644
> --- a/meta/conf/machine/include/tune-cortexr4.inc
> +++ b/meta/conf/machine/include/tune-cortexr4.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexr4"
> +ARMPKGARCH ?= "armv7r"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
> +
> +TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexr4"
> +TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
> +PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
>
> -# valid options for -march: `armv7', `armv7-r'
> -TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
> index e04a00a..f10123f 100644
> --- a/meta/conf/machine/include/tune-ep9312.inc
> +++ b/meta/conf/machine/include/tune-ep9312.inc
> @@ -1,9 +1,13 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "ep9312"
> +ARMPKGARCH ?= "ep9312"
>
> -TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
> -# add "-mfp=maverick" for newer gcc versions > 4.0
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
> +
> +AVAILTUNES += "ep9312"
> +TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
> +PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
>
> -#set arch to ep9312 for all generated packages
> -PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
> -TUNE_PKGARCH = "ep9312"
>
> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
> index 6bb76d5..14f5955 100644
> --- a/meta/conf/machine/include/tune-iwmmxt.inc
> +++ b/meta/conf/machine/include/tune-iwmmxt.inc
> @@ -1,8 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> # Configurations for the Intel PXA27x Appications Processor Family.
> # Please use tune-xscale for PXA255/PXA26x based processors.
> -TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
> -TUNE_PKGARCH = "iwmmxt"
> +
> +DEFAULTTUNE ?= "iwmmxt"
> +ARMPKGARCH ?= "iwmmxt"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
> +
> +AVAILTUNES += "iwmmxt"
> +TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
> +PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
> +
>
> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
> index 2b76069..66bab8e 100644
> --- a/meta/conf/machine/include/tune-strongarm1100.inc
> +++ b/meta/conf/machine/include/tune-strongarm1100.inc
> @@ -1,9 +1,12 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "strongarm"
>
> -TUNE_PKGARCH = "arm"
> +require conf/machine/include/arm/arch-armv4.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
> +TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
> +
> +AVAILTUNES += "strongarm"
> +TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
> +PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
>
> -TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
>
> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
> index 71dba5b..0303320 100644
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
>
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
>
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>
> # webkit-gtk has alignment issues with double instructions on armv5 so
> # disable them here
> --
> 1.7.4.1
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 12:44 ` [PATCH 3/3] Add basic PowerPC " Richard Purdie
@ 2011-07-26 13:47 ` Kumar Gala
2011-07-26 13:59 ` Richard Purdie
2011-07-26 14:57 ` Mark Hatle
1 sibling, 1 reply; 92+ messages in thread
From: Kumar Gala @ 2011-07-26 13:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> 6 files changed, 88 insertions(+), 18 deletions(-)
One thing I'm wondering about as we do this is the ability to pass --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs & libs for a given target.
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 13:47 ` Kumar Gala
@ 2011-07-26 13:59 ` Richard Purdie
2011-07-26 14:59 ` Mark Hatle
2011-07-26 15:22 ` Kumar Gala
0 siblings, 2 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 13:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> > meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> > meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> > 6 files changed, 88 insertions(+), 18 deletions(-)
>
> One thing I'm wondering about as we do this is the ability to pass
> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> & libs for a given target.
As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
correct march and mtune options to the compiler at runtime through
CFLAGS and friends.
You're already found the way to pass configuration to *libc using values
in TARGET_FPU to pickup the right configuration.
Is there a use case we're missing?
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
@ 2011-07-26 14:41 ` Mark Hatle
2011-07-26 16:51 ` Richard Purdie
2011-07-26 19:47 ` Khem Raj
2011-08-11 11:25 ` Phil Blundell
2 siblings, 1 reply; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 14:41 UTC (permalink / raw)
To: openembedded-core
Few quick items here:
On 7/26/11 7:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/mips/arch-mips.inc | 64 +++++++++++++++++++++++++-
> meta/conf/machine/include/tune-mips32.inc | 10 +++-
> 2 files changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> index f7f4eed..071e6b5 100644
> --- a/meta/conf/machine/include/mips/arch-mips.inc
> +++ b/meta/conf/machine/include/mips/arch-mips.inc
> @@ -1 +1,63 @@
...
> +# Floating point
> +TUNEVALID[fpu-hard] = "Use hardware FPU"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> +
> +# Package naming
> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
n32 is also MIPS64.
so a:
MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"
should fix the issue.
> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> +
> +# Base tunes
> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> +BASE_LIB_tune-mips = "lib"
> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> +BASE_LIB_tune-mips64-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> +BASE_LIB_tune-mips64 = "lib64"
> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> +BASE_LIB_tune-mipsel = "lib"
> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> +BASE_LIB_tune-mips64el-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> +BASE_LIB_tune-mips64el = "lib64"
> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> +BASE_LIB_tune-mips-nf = "lib"
> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> +BASE_LIB_tune-mips64-nf = "lib64"
> +TUNE_FEATURES_tune-mipsel-nf = "o32"
> +BASE_LIB_tune-mipsel-nf = "lib"
> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el-nf = "n64"
> +BASE_LIB_tune-mips64el-nf = "lib64"
> +
> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> index 28b0047..1f913df 100644
> --- a/meta/conf/machine/include/tune-mips32.inc
> +++ b/meta/conf/machine/include/tune-mips32.inc
> @@ -1,4 +1,10 @@
> +DEFAULTTUNE ?= "mips32"
> +
> require conf/machine/include/mips/arch-mips.inc
>
> -TUNE_CCARGS = "-march=mips32"
> -TUNE_PKGARCH = "mips"
> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
Do we have a way to specify that? Perhaps using the TUNECONFLICT?
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
> +
> +AVAILTUNES += "mips32"
> +TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
> +PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 12:44 ` [PATCH 3/3] Add basic PowerPC " Richard Purdie
2011-07-26 13:47 ` Kumar Gala
@ 2011-07-26 14:57 ` Mark Hatle
2011-07-26 16:36 ` Richard Purdie
1 sibling, 1 reply; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 14:57 UTC (permalink / raw)
To: openembedded-core
Comments below...
On 7/26/11 7:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> 6 files changed, 88 insertions(+), 18 deletions(-)
>
> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> index 17ace32..3f7befb 100644
> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> @@ -1,3 +1,44 @@
> -TUNE_ARCH = "powerpc"
> +# Power Architecture definition
> +# Four defined ABIs, all combinations of:
> +# *) Hard/Soft Floating Point
> +# *) 32-bit/64-bit
> +
> +DEFAULTTUNE ?= "powerpc"
> +
> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> +
> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> +
> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> +
> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
powerpc or powerpc64.
> +TUNEVALID[fpu-hard] = "Use hardware FPU."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
> +
> +TUNEVALID[fpu-soft] = "Use software FPU."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
Why specify both fpu-hard and fpu-soft? The "unusual" ABI is fpu-soft. It
would simplify it to only have to specify one, and you get the other automatically.
> +TUNEVALID[spe] = "Enable SPE ABI extensions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
> +
> +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
SPE instructions are specific to certain processors and not generic across all
of PPC. I would move this to each of the tunes where it may be used.
Also I see the ABIEXTENSION, but where is it being set?
In the core PowerPC specification there are two ABIs defined. The standard
classic PPC FPU hard-float (this is the long-running default), and a no-float
version that avoids passing via FPU registers.
There is a variant of the soft-float specific to certain processors.. each
processor has it's own variant depending on what registers it has. e500(v1 -
single precision) and e500v2 (double precision) each have their own variants. I
believe there is also an e300 variant that has a completely different SPE as well.
I assume from the above ppc-efd is double and efs is single... Perhaps an e500
tune file that specific the ABI extension and has knowledge of both e500(v1) and
e500v2?
> +# Basic tune definitions
> +AVAILTUNES += "powerpc powerpc-nf"
> +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
> +BASE_LIB_tune-powerpc = "lib"
> +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
> +BASE_LIB_tune-powerpc-nf = "lib"
> +
> +AVAILTUNES += "powerpc64 powerpc64-nf"
> +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
> +BASE_LIB_tune-powerpc64 = "lib64"
> +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
> +BASE_LIB_tune-powerpc64-nf = "lib64"
>
> -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
> diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
> index 61c0669..6991ae0 100644
> --- a/meta/conf/machine/include/tune-ppc603e.inc
> +++ b/meta/conf/machine/include/tune-ppc603e.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppc603e"
> +
> require conf/machine/include/powerpc/arch-powerpc.inc
>
> -TUNE_CCARGS = "-mcpu=603e -mhard-float"
> -TUNE_PKGARCH = "ppc603e"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
> +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> +
> +AVAILTUNES += "ppc603e"
> +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
> +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
Going back to my original comment, the m32-arch is missing... or m32 should mean
"powerpc" (my suggestion).
> diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
> index a38e97c..652422f 100644
> --- a/meta/conf/machine/include/tune-ppce300c2.inc
> +++ b/meta/conf/machine/include/tune-ppce300c2.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce300"
> +
> require conf/machine/include/powerpc/arch-powerpc.inc
>
> -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
> -TUNE_PKGARCH = "ppce300"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
> +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
> +
> +AVAILTUNES += "ppce300"
> +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
> +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
There is also a ppce300 as well as the e300c2, so I'd change the option to be
fully qualified. (One has floating point one doesn't..)
> diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
> index 22208f0..fe62445 100644
> --- a/meta/conf/machine/include/tune-ppce500.inc
> +++ b/meta/conf/machine/include/tune-ppce500.inc
> @@ -1,6 +1,11 @@
> +DEFAULTTUNE ?= "ppce500"
> +
> require conf/machine/include/powerpc/arch-powerpc.inc
>
> -TUNE_CCARGS = "-mcpu=8540"
> -BASE_PACKAGE_ARCH = "ppce500"
> -TUNE_PKGARCH = "ppce500"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
> +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
> +
> +AVAILTUNES += "ppce500"
> +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
This is the single precision e500 -- it should be specifying it's floating point
type.
> diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
> index 182d019..0d3640f 100644
> --- a/meta/conf/machine/include/tune-ppce500mc.inc
> +++ b/meta/conf/machine/include/tune-ppce500mc.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce500mc"
> +
> require conf/machine/include/powerpc/arch-powerpc.inc
>
> -TUNE_CCARGS = "-mcpu=e500mc"
> -TUNE_PKGARCH = "ppce500mc"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
> +
> +AVAILTUNES += "ppce500mc"
> +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
e500mc using the classic "hard-float" floating point unit.
> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
> index daf2d58..e6b48a2 100644
> --- a/meta/conf/machine/include/tune-ppce500v2.inc
> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> @@ -1,5 +1,11 @@
> +DEFAULTTUNE ?= "ppce500v2"
> +
> require conf/machine/include/powerpc/arch-powerpc.inc
>
> -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
> -TUNE_PKGARCH = "ppce500v2"
> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
> +
> +AVAILTUNES += "ppce500v2"
> +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
> +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
This one is double precision.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 13:59 ` Richard Purdie
@ 2011-07-26 14:59 ` Mark Hatle
2011-07-26 15:22 ` Kumar Gala
1 sibling, 0 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 14:59 UTC (permalink / raw)
To: openembedded-core
On 7/26/11 8:59 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>
>> One thing I'm wondering about as we do this is the ability to pass
>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>> & libs for a given target.
>
> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> correct march and mtune options to the compiler at runtime through
> CFLAGS and friends.
>
> You're already found the way to pass configuration to *libc using values
> in TARGET_FPU to pickup the right configuration.
>
> Is there a use case we're missing?
glibc is capable of some processor specific optimizations. So you can say I
want e500 or ppc603e or... as it's base configuration. This is useful on MIPS
as well.
My suggestion would be to use the TUNE_FEATURES in eglibc to figure out what
option(s) we want to pass to glibc. (We could also use the tune name, but I'd
be afraid that the names could change arbitrarily over time.. the tune_features
I would expect to have a longer life span.)
--Mark
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 13:59 ` Richard Purdie
2011-07-26 14:59 ` Mark Hatle
@ 2011-07-26 15:22 ` Kumar Gala
2011-07-26 16:18 ` Richard Purdie
2011-07-26 20:03 ` Khem Raj
1 sibling, 2 replies; 92+ messages in thread
From: Kumar Gala @ 2011-07-26 15:22 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>
>> One thing I'm wondering about as we do this is the ability to pass
>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>> & libs for a given target.
>
> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> correct march and mtune options to the compiler at runtime through
> CFLAGS and friends.
Hmm, gcc still supports this:
http://gcc.gnu.org/install/configure.html
--with-cpu=cpu
--with-cpu-32=cpu
--with-cpu-64=cpu
Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
http://gcc.gnu.org/install/specific.html
powerpc-*-*
You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
> You're already found the way to pass configuration to *libc using values
> in TARGET_FPU to pickup the right configuration.
>
> Is there a use case we're missing?
Yes, for [e]glibc we have optimized libc functions for a given / specific PPC processor. So we need someway to tell configure this.
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 15:22 ` Kumar Gala
@ 2011-07-26 16:18 ` Richard Purdie
2011-07-26 21:56 ` Kumar Gala
` (2 more replies)
2011-07-26 20:03 ` Khem Raj
1 sibling, 3 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
>
> > On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> >>
> >>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>> ---
> >>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> >>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> >>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> >>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >>
> >> One thing I'm wondering about as we do this is the ability to pass
> >> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> >> & libs for a given target.
> >
> > As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> > correct march and mtune options to the compiler at runtime through
> > CFLAGS and friends.
>
> Hmm, gcc still supports this:
>
> http://gcc.gnu.org/install/configure.html
>
> --with-cpu=cpu
> --with-cpu-32=cpu
> --with-cpu-64=cpu
> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
>
> http://gcc.gnu.org/install/specific.html
>
> powerpc-*-*
> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
I couldn't find that looking at the configure script :/.
Anyhow, according to that page, its to "Specify which cpu variant the
compiler should generate code for by default. cpu will be used as the
default value of the -mcpu= switch". Since we always specify -mcpu when
needed, I don't believe this is an issue for us as far as the build
system goes.
If you're talking about the gcc we build for the target, we should
really encode all the cpu/tune options in there, not just part of the
config so again, I don't think its appropriate to the way we use gcc.
> > You're already found the way to pass configuration to *libc using values
> > in TARGET_FPU to pickup the right configuration.
> >
> > Is there a use case we're missing?
>
> Yes, for [e]glibc we have optimized libc functions for a given /
> specific PPC processor. So we need someway to tell configure this.
I'd do this by looking for flags in TUNE_FEATURES as Mark has also
mentioned.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 14:57 ` Mark Hatle
@ 2011-07-26 16:36 ` Richard Purdie
2011-07-26 16:53 ` Mark Hatle
2011-07-26 20:13 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 16:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> On 7/26/11 7:44 AM, Richard Purdie wrote:
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> > meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> > meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> > meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> > 6 files changed, 88 insertions(+), 18 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > index 17ace32..3f7befb 100644
> > --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> > @@ -1,3 +1,44 @@
> > -TUNE_ARCH = "powerpc"
> > +# Power Architecture definition
> > +# Four defined ABIs, all combinations of:
> > +# *) Hard/Soft Floating Point
> > +# *) 32-bit/64-bit
> > +
> > +DEFAULTTUNE ?= "powerpc"
> > +
> > +TUNEVALID[m32] = "Power ELF32 standard ABI"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> > +
> > +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> > +
> > +TUNEVALID[m64] = "Power ELF64 standard ABI"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> > +
> > +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>
> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
> powerpc or powerpc64.
I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
there was a reason.
The missing piece is
TUNE_PKGARCH ?= "${TUNE_ARCH}"
and the trouble comes when a tune file wants to change this only when
its tune config is in action.
I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
TUNE_PKGARCH needs to take on the values for both configs.
> > +TUNEVALID[fpu-hard] = "Use hardware FPU."
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
> > +
> > +TUNEVALID[fpu-soft] = "Use software FPU."
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
> > +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
>
> Why specify both fpu-hard and fpu-soft? The "unusual" ABI is fpu-soft. It
> would simplify it to only have to specify one, and you get the other automatically.
The trouble is the spe pieces which seemed to imply TARGET_FPU should
take on a value of other than "soft". Setting it to "soft" if fpu-hard
isn't in TUNE_FEATURES therefore wasn't enough...
> > +TUNEVALID[spe] = "Enable SPE ABI extensions"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
> > +
> > +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
>
> SPE instructions are specific to certain processors and not generic across all
> of PPC. I would move this to each of the tunes where it may be used.
I guess this should be a feature file like thumb on arm?
> Also I see the ABIEXTENSION, but where is it being set?
I'm just migrating the existing code in that regard, I'm also puzzled as
to where that is getting set currently.
> > +# Basic tune definitions
> > +AVAILTUNES += "powerpc powerpc-nf"
> > +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
> > +BASE_LIB_tune-powerpc = "lib"
> > +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
> > +BASE_LIB_tune-powerpc-nf = "lib"
> > +
> > +AVAILTUNES += "powerpc64 powerpc64-nf"
> > +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
> > +BASE_LIB_tune-powerpc64 = "lib64"
> > +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
> > +BASE_LIB_tune-powerpc64-nf = "lib64"
> >
> > -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
> > diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
> > index 61c0669..6991ae0 100644
> > --- a/meta/conf/machine/include/tune-ppc603e.inc
> > +++ b/meta/conf/machine/include/tune-ppc603e.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppc603e"
> > +
> > require conf/machine/include/powerpc/arch-powerpc.inc
> >
> > -TUNE_CCARGS = "-mcpu=603e -mhard-float"
> > -TUNE_PKGARCH = "ppc603e"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
> > +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> > +
> > +AVAILTUNES += "ppc603e"
> > +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
> > +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
>
> Going back to my original comment, the m32-arch is missing... or m32 should mean
> "powerpc" (my suggestion).
No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
sense...
> > diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
> > index a38e97c..652422f 100644
> > --- a/meta/conf/machine/include/tune-ppce300c2.inc
> > +++ b/meta/conf/machine/include/tune-ppce300c2.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce300"
> > +
> > require conf/machine/include/powerpc/arch-powerpc.inc
> >
> > -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
> > -TUNE_PKGARCH = "ppce300"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
> > +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
> > +
> > +AVAILTUNES += "ppce300"
> > +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
>
> There is also a ppce300 as well as the e300c2, so I'd change the option to be
> fully qualified. (One has floating point one doesn't..)
Fair enough.
> > diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
> > index 22208f0..fe62445 100644
> > --- a/meta/conf/machine/include/tune-ppce500.inc
> > +++ b/meta/conf/machine/include/tune-ppce500.inc
> > @@ -1,6 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500"
> > +
> > require conf/machine/include/powerpc/arch-powerpc.inc
> >
> > -TUNE_CCARGS = "-mcpu=8540"
> > -BASE_PACKAGE_ARCH = "ppce500"
> > -TUNE_PKGARCH = "ppce500"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
> > +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
> > +
> > +AVAILTUNES += "ppce500"
> > +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
>
> This is the single precision e500 -- it should be specifying it's floating point
> type.
which is? :)
> > diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
> > index 182d019..0d3640f 100644
> > --- a/meta/conf/machine/include/tune-ppce500mc.inc
> > +++ b/meta/conf/machine/include/tune-ppce500mc.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500mc"
> > +
> > require conf/machine/include/powerpc/arch-powerpc.inc
> >
> > -TUNE_CCARGS = "-mcpu=e500mc"
> > -TUNE_PKGARCH = "ppce500mc"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
> > +
> > +AVAILTUNES += "ppce500mc"
> > +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
>
> e500mc using the classic "hard-float" floating point unit.
ok, so its hard-fpu...
> > diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
> > index daf2d58..e6b48a2 100644
> > --- a/meta/conf/machine/include/tune-ppce500v2.inc
> > +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> > @@ -1,5 +1,11 @@
> > +DEFAULTTUNE ?= "ppce500v2"
> > +
> > require conf/machine/include/powerpc/arch-powerpc.inc
> >
> > -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
> > -TUNE_PKGARCH = "ppce500v2"
> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
> > +
> > +AVAILTUNES += "ppce500v2"
> > +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
> > +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
>
> This one is double precision.
so hard-fpu?
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-07-26 14:41 ` Mark Hatle
@ 2011-07-26 16:51 ` Richard Purdie
2011-07-26 17:08 ` Mark Hatle
0 siblings, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 16:51 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 09:41 -0500, Mark Hatle wrote:
> Few quick items here:
>
> On 7/26/11 7:44 AM, Richard Purdie wrote:
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > meta/conf/machine/include/mips/arch-mips.inc | 64 +++++++++++++++++++++++++-
> > meta/conf/machine/include/tune-mips32.inc | 10 +++-
> > 2 files changed, 71 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> > index f7f4eed..071e6b5 100644
> > --- a/meta/conf/machine/include/mips/arch-mips.inc
> > +++ b/meta/conf/machine/include/mips/arch-mips.inc
> > @@ -1 +1,63 @@
> ...
>
> > +# Floating point
> > +TUNEVALID[fpu-hard] = "Use hardware FPU"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> > +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> > +
> > +# Package naming
> > +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> > +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
>
> n32 is also MIPS64.
>
> so a:
>
> MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"
>
> should fix the issue.
>
> > +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> > +
> > +# Base tunes
> > +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
> > +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> > +BASE_LIB_tune-mips = "lib"
> > +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> > +BASE_LIB_tune-mips64-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> > +BASE_LIB_tune-mips64 = "lib64"
> > +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> > +BASE_LIB_tune-mipsel = "lib"
> > +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> > +BASE_LIB_tune-mips64el-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> > +BASE_LIB_tune-mips64el = "lib64"
> > +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> > +BASE_LIB_tune-mips-nf = "lib"
> > +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> > +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> > +BASE_LIB_tune-mips64-nf = "lib64"
> > +TUNE_FEATURES_tune-mipsel-nf = "o32"
> > +BASE_LIB_tune-mipsel-nf = "lib"
> > +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> > +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> > +TUNE_FEATURES_tune-mips64el-nf = "n64"
> > +BASE_LIB_tune-mips64el-nf = "lib64"
> > +
> > diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> > index 28b0047..1f913df 100644
> > --- a/meta/conf/machine/include/tune-mips32.inc
> > +++ b/meta/conf/machine/include/tune-mips32.inc
> > @@ -1,4 +1,10 @@
> > +DEFAULTTUNE ?= "mips32"
> > +
> > require conf/machine/include/mips/arch-mips.inc
> >
> > -TUNE_CCARGS = "-march=mips32"
> > -TUNE_PKGARCH = "mips"
> > +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
>
> If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
> Do we have a way to specify that? Perhaps using the TUNECONFLICT?
Agreed, TUNE_CONFLICTS is the way to go. I've updated the patch on my
branch with this and the other tweak:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=2a31a7d38149b6bc972831964bfdeae7422c128c
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:36 ` Richard Purdie
@ 2011-07-26 16:53 ` Mark Hatle
2011-07-26 17:05 ` Richard Purdie
2011-07-26 20:13 ` Khem Raj
1 sibling, 1 reply; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 16:53 UTC (permalink / raw)
To: openembedded-core
On 7/26/11 11:36 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> index 17ace32..3f7befb 100644
>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>> @@ -1,3 +1,44 @@
>>> -TUNE_ARCH = "powerpc"
>>> +# Power Architecture definition
>>> +# Four defined ABIs, all combinations of:
>>> +# *) Hard/Soft Floating Point
>>> +# *) 32-bit/64-bit
>>> +
>>> +DEFAULTTUNE ?= "powerpc"
>>> +
>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>>> +
>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>>> +
>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>>> +
>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>
>> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
>> powerpc or powerpc64.
>
> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> there was a reason.
>
> The missing piece is
>
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>
> and the trouble comes when a tune file wants to change this only when
> its tune config is in action.
>
> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> TUNE_PKGARCH needs to take on the values for both configs.
As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64.. There is
no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
passed via gcc through the TUNE_CCARGS.
>>> +TUNEVALID[fpu-hard] = "Use hardware FPU."
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
>>> +
>>> +TUNEVALID[fpu-soft] = "Use software FPU."
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
>>> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
>>
>> Why specify both fpu-hard and fpu-soft? The "unusual" ABI is fpu-soft. It
>> would simplify it to only have to specify one, and you get the other automatically.
>
> The trouble is the spe pieces which seemed to imply TARGET_FPU should
> take on a value of other than "soft". Setting it to "soft" if fpu-hard
> isn't in TUNE_FEATURES therefore wasn't enough...
Can you do something like:
TARGET_FPU = "${@...if "fpu" is not in TUNE_FEATURES..., "hard"}"
TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
Then later in the tune's that have unique spe units..
TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "e500", "fpu-spe" ],
"ppc-efs", "", d)}"
TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "e500", "fpu-spe" ],
"ppc-efd", "", d)}"
>>> +TUNEVALID[spe] = "Enable SPE ABI extensions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
>>> +
>>> +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
>>
>> SPE instructions are specific to certain processors and not generic across all
>> of PPC. I would move this to each of the tunes where it may be used.
>
> I guess this should be a feature file like thumb on arm?
Unfortunately it's SoC specific on PowerPC. There is no uniform definition of
an SPE unit.. (SPE stands for Special Purpose Execution.. by spec, the SPE can
use any instruction set, and do any set of operations.. the individual cores
define what the SPE instructions do. The e500 and e500v2 have their own unique
SPEs that do math-like functionality. Other cores use the SPE instructions for
encryption services, multimedia, etc...)
Thats why the SPE settings need to be in the individual tune files, they are
unique to each core.
>> Also I see the ABIEXTENSION, but where is it being set?
>
> I'm just migrating the existing code in that regard, I'm also puzzled as
> to where that is getting set currently.
I think this is something we need to fix. The ABIEXTENSION contents look
reasonable, but again, I believe it's really core specific.
>>> +# Basic tune definitions
>>> +AVAILTUNES += "powerpc powerpc-nf"
>>> +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
>>> +BASE_LIB_tune-powerpc = "lib"
>>> +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
>>> +BASE_LIB_tune-powerpc-nf = "lib"
>>> +
>>> +AVAILTUNES += "powerpc64 powerpc64-nf"
>>> +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
>>> +BASE_LIB_tune-powerpc64 = "lib64"
>>> +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
>>> +BASE_LIB_tune-powerpc64-nf = "lib64"
>>>
>>> -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
>>> diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
>>> index 61c0669..6991ae0 100644
>>> --- a/meta/conf/machine/include/tune-ppc603e.inc
>>> +++ b/meta/conf/machine/include/tune-ppc603e.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppc603e"
>>> +
>>> require conf/machine/include/powerpc/arch-powerpc.inc
>>>
>>> -TUNE_CCARGS = "-mcpu=603e -mhard-float"
>>> -TUNE_PKGARCH = "ppc603e"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
>>> +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
>>> +
>>> +AVAILTUNES += "ppc603e"
>>> +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
>>
>> Going back to my original comment, the m32-arch is missing... or m32 should mean
>> "powerpc" (my suggestion).
>
> No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
> sense...
Yes, I understand.. TUNE_ARCH is the canonical arch, TUNE_PKGARCH is what to
call the packages generated.
So in the above features, if TUNE_ARCH is used as implemented m32-arch is
missing -- but on Power there are only two current options and the m32/m64
should be able to switch them.
>>> diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
>>> index a38e97c..652422f 100644
>>> --- a/meta/conf/machine/include/tune-ppce300c2.inc
>>> +++ b/meta/conf/machine/include/tune-ppce300c2.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce300"
>>> +
>>> require conf/machine/include/powerpc/arch-powerpc.inc
>>>
>>> -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
>>> -TUNE_PKGARCH = "ppce300"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
>>> +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce300"
>>> +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
>>
>> There is also a ppce300 as well as the e300c2, so I'd change the option to be
>> fully qualified. (One has floating point one doesn't..)
>
> Fair enough.
>
>>> diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
>>> index 22208f0..fe62445 100644
>>> --- a/meta/conf/machine/include/tune-ppce500.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500.inc
>>> @@ -1,6 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500"
>>> +
>>> require conf/machine/include/powerpc/arch-powerpc.inc
>>>
>>> -TUNE_CCARGS = "-mcpu=8540"
>>> -BASE_PACKAGE_ARCH = "ppce500"
>>> -TUNE_PKGARCH = "ppce500"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
>>> +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500"
>>> +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
>>
>> This is the single precision e500 -- it should be specifying it's floating point
>> type.
>
> which is? :)
Based on the above, ppc-efs.. (I believe these names are completely arbitrary...)
Ohh didn't notice before, but once you enable the spe floating point, the
registers are used and it's no longer soft-float anymore.. (hard-float = classic
PPC floating point unit). So the PACKAGE_EXTRA_ARCHS_tune-ppce500 should be
simply "ppce500"
>>> diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
>>> index 182d019..0d3640f 100644
>>> --- a/meta/conf/machine/include/tune-ppce500mc.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500mc.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500mc"
>>> +
>>> require conf/machine/include/powerpc/arch-powerpc.inc
>>>
>>> -TUNE_CCARGS = "-mcpu=e500mc"
>>> -TUNE_PKGARCH = "ppce500mc"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
>>> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500mc"
>>> +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
>>
>> e500mc using the classic "hard-float" floating point unit.
>
> ok, so its hard-fpu...
That is my understanding. Hopefully someone can verify this...
>>> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
>>> index daf2d58..e6b48a2 100644
>>> --- a/meta/conf/machine/include/tune-ppce500v2.inc
>>> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
>>> @@ -1,5 +1,11 @@
>>> +DEFAULTTUNE ?= "ppce500v2"
>>> +
>>> require conf/machine/include/powerpc/arch-powerpc.inc
>>>
>>> -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
>>> -TUNE_PKGARCH = "ppce500v2"
>>> -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
>>> +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
>>> +
>>> +AVAILTUNES += "ppce500v2"
>>> +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
>>> +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
>>
>> This one is double precision.
>
> so hard-fpu?
Nope.. this is the ppc-efd. Note, again not compatible w/ "powerpc".. and NOT
compatible with "ppce500". (Since they're different SPE units, the call passing
is different..)
Fun with extensible architectures.. :P
--Mark
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:53 ` Mark Hatle
@ 2011-07-26 17:05 ` Richard Purdie
2011-07-26 17:15 ` Mark Hatle
0 siblings, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 17:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
> On 7/26/11 11:36 AM, Richard Purdie wrote:
> > On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> >> On 7/26/11 7:44 AM, Richard Purdie wrote:
> >>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>> ---
> >>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> >>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> >>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> >>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> >>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> index 17ace32..3f7befb 100644
> >>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>> @@ -1,3 +1,44 @@
> >>> -TUNE_ARCH = "powerpc"
> >>> +# Power Architecture definition
> >>> +# Four defined ABIs, all combinations of:
> >>> +# *) Hard/Soft Floating Point
> >>> +# *) 32-bit/64-bit
> >>> +
> >>> +DEFAULTTUNE ?= "powerpc"
> >>> +
> >>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> >>> +
> >>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> >>> +
> >>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> >>> +
> >>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
> >>
> >> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
> >> powerpc or powerpc64.
> >
> > I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> > there was a reason.
> >
> > The missing piece is
> >
> > TUNE_PKGARCH ?= "${TUNE_ARCH}"
> >
> > and the trouble comes when a tune file wants to change this only when
> > its tune config is in action.
> >
> > I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> > TUNE_PKGARCH needs to take on the values for both configs.
>
> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64.. There is
> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
>
> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
> passed via gcc through the TUNE_CCARGS.
Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:
TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
and I want a multilib config using this as the m32 ABI and also have
powerpc64 as my other multilib. I can't select that as it will get
TUNE_PKGARCH wrong in the 64 bit case since:
TUNE_PKGARCH ?= "${TUNE_ARCH}"
is overwritten. I guess we could do:
TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"
?
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-07-26 16:51 ` Richard Purdie
@ 2011-07-26 17:08 ` Mark Hatle
0 siblings, 0 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 17:08 UTC (permalink / raw)
To: openembedded-core
On 7/26/11 11:51 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 09:41 -0500, Mark Hatle wrote:
>> Few quick items here:
>>
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> meta/conf/machine/include/mips/arch-mips.inc | 64 +++++++++++++++++++++++++-
>>> meta/conf/machine/include/tune-mips32.inc | 10 +++-
>>> 2 files changed, 71 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
>>> index f7f4eed..071e6b5 100644
>>> --- a/meta/conf/machine/include/mips/arch-mips.inc
>>> +++ b/meta/conf/machine/include/mips/arch-mips.inc
>>> @@ -1 +1,63 @@
>> ...
>>
>>> +# Floating point
>>> +TUNEVALID[fpu-hard] = "Use hardware FPU"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
>>> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
>>> +
>>> +# Package naming
>>> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
>>> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
>>
>> n32 is also MIPS64.
>>
>> so a:
>>
>> MIPSPKGSFX_BYTE .= "${@bb.utils.contains("TUNE_FEATURES", "n32" , "64", "", d)}"
>>
>> should fix the issue.
>>
>>> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
>>> +
>>> +# Base tunes
>>> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
>>> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips = "lib"
>>> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips64-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
>>> +BASE_LIB_tune-mips64 = "lib64"
>>> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
>>> +BASE_LIB_tune-mipsel = "lib"
>>> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
>>> +BASE_LIB_tune-mips64el-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
>>> +BASE_LIB_tune-mips64el = "lib64"
>>> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
>>> +BASE_LIB_tune-mips-nf = "lib"
>>> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
>>> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
>>> +BASE_LIB_tune-mips64-nf = "lib64"
>>> +TUNE_FEATURES_tune-mipsel-nf = "o32"
>>> +BASE_LIB_tune-mipsel-nf = "lib"
>>> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
>>> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
>>> +TUNE_FEATURES_tune-mips64el-nf = "n64"
>>> +BASE_LIB_tune-mips64el-nf = "lib64"
>>> +
>>> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
>>> index 28b0047..1f913df 100644
>>> --- a/meta/conf/machine/include/tune-mips32.inc
>>> +++ b/meta/conf/machine/include/tune-mips32.inc
>>> @@ -1,4 +1,10 @@
>>> +DEFAULTTUNE ?= "mips32"
>>> +
>>> require conf/machine/include/mips/arch-mips.inc
>>>
>>> -TUNE_CCARGS = "-march=mips32"
>>> -TUNE_PKGARCH = "mips"
>>> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
>>
>> If tune-mips32 is used, then all of the n32 and n64 variants are not possible.
>> Do we have a way to specify that? Perhaps using the TUNECONFLICT?
>
> Agreed, TUNE_CONFLICTS is the way to go. I've updated the patch on my
> branch with this and the other tweak:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=2a31a7d38149b6bc972831964bfdeae7422c128c
Looks good..
Acked-by: Mark Hatle <mark.hatle@windriver.com>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 17:05 ` Richard Purdie
@ 2011-07-26 17:15 ` Mark Hatle
2011-07-26 19:21 ` Richard Purdie
0 siblings, 1 reply; 92+ messages in thread
From: Mark Hatle @ 2011-07-26 17:15 UTC (permalink / raw)
To: openembedded-core
On 7/26/11 12:05 PM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
>> On 7/26/11 11:36 AM, Richard Purdie wrote:
>>> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>>>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>>> ---
>>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>>>
>>>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> index 17ace32..3f7befb 100644
>>>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>>>>> @@ -1,3 +1,44 @@
>>>>> -TUNE_ARCH = "powerpc"
>>>>> +# Power Architecture definition
>>>>> +# Four defined ABIs, all combinations of:
>>>>> +# *) Hard/Soft Floating Point
>>>>> +# *) 32-bit/64-bit
>>>>> +
>>>>> +DEFAULTTUNE ?= "powerpc"
>>>>> +
>>>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>>>>> +
>>>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>>>
>>>> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
>>>> powerpc or powerpc64.
>>>
>>> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
>>> there was a reason.
>>>
>>> The missing piece is
>>>
>>> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>>>
>>> and the trouble comes when a tune file wants to change this only when
>>> its tune config is in action.
>>>
>>> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
>>> TUNE_PKGARCH needs to take on the values for both configs.
>>
>> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64.. There is
>> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
>>
>> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
>> passed via gcc through the TUNE_CCARGS.
>
> Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:
>
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
>
> and I want a multilib config using this as the m32 ABI and also have
> powerpc64 as my other multilib. I can't select that as it will get
> TUNE_PKGARCH wrong in the 64 bit case since:
>
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>
> is overwritten. I guess we could do:
>
> TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"
ppc603e is the new option.. (lets say for argument it can run in 64-bit mode, in
reality it can't and is an invalid config....)
TUNEVALID[ppc603e] = "PowerPC 603e Optimization"
# Note the TUNE_NAME is used differently from the TUNE_FEATURES
TUNE_NAME ?= "ppc603e"
TUNE_FEATURES_ppc603e = "m32 ppc603e"
TUNE_FEATURES_ppc603e-64 = "m64 ppc603e"
The if you include the tune-ppc603e.inc the default is the 32-bit version (what
I'd consider the reasonable default...) If you wanted the 64-bit version
instead you'd simply change set the TUNE_NAME to "ppc603e-64" and the properly
tuned set of features is set for you.
TUNE_PKGARCH_ppc603e = "ppc603e"
TUNE_PKGARCH_ppc603e-64 = "ppc603e-64"
etc...
in the default (ppc603e) case, the TUNE_ARCH should always be "powerpc", and in
the ppc603e-64 case (if manually enabled), it would be "powerpc64"...
This is what was done in the ARM cases and I believe the core2 case in ia32.
--Mark
> ?
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 17:15 ` Mark Hatle
@ 2011-07-26 19:21 ` Richard Purdie
2011-07-26 20:28 ` Richard Purdie
0 siblings, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 19:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 12:15 -0500, Mark Hatle wrote:
> On 7/26/11 12:05 PM, Richard Purdie wrote:
> > On Tue, 2011-07-26 at 11:53 -0500, Mark Hatle wrote:
> >> On 7/26/11 11:36 AM, Richard Purdie wrote:
> >>> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
> >>>> On 7/26/11 7:44 AM, Richard Purdie wrote:
> >>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>>> ---
> >>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> >>>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> >>>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> >>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> index 17ace32..3f7befb 100644
> >>>>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
> >>>>> @@ -1,3 +1,44 @@
> >>>>> -TUNE_ARCH = "powerpc"
> >>>>> +# Power Architecture definition
> >>>>> +# Four defined ABIs, all combinations of:
> >>>>> +# *) Hard/Soft Floating Point
> >>>>> +# *) 32-bit/64-bit
> >>>>> +
> >>>>> +DEFAULTTUNE ?= "powerpc"
> >>>>> +
> >>>>> +TUNEVALID[m32] = "Power ELF32 standard ABI"
> >>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
> >>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m64] = "Power ELF64 standard ABI"
> >>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
> >>>>> +
> >>>>> +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
> >>>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
> >>>>
> >>>> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
> >>>> powerpc or powerpc64.
> >>>
> >>> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> >>> there was a reason.
> >>>
> >>> The missing piece is
> >>>
> >>> TUNE_PKGARCH ?= "${TUNE_ARCH}"
> >>>
> >>> and the trouble comes when a tune file wants to change this only when
> >>> its tune config is in action.
> >>>
> >>> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> >>> TUNE_PKGARCH needs to take on the values for both configs.
> >>
> >> As far as I can tell, in all cases m32 = powerpc and m64 = powerpc64.. There is
> >> no way to mix a build of ppc32 and ppc64 w/o using the multilib code.
> >>
> >> The m32/m64 is the ABI, so only one can be present in the TUNE_FEATURES.. and
> >> passed via gcc through the TUNE_CCARGS.
> >
> > Ok, say I use tune-ppcXXX and it sets TUNE_PKGARCH:
> >
> > TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
> >
> > and I want a multilib config using this as the m32 ABI and also have
> > powerpc64 as my other multilib. I can't select that as it will get
> > TUNE_PKGARCH wrong in the 64 bit case since:
> >
> > TUNE_PKGARCH ?= "${TUNE_ARCH}"
> >
> > is overwritten. I guess we could do:
> >
> > TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "${TUNE_ARCH}", d)}"
>
> ppc603e is the new option.. (lets say for argument it can run in 64-bit mode, in
> reality it can't and is an invalid config....)
>
> TUNEVALID[ppc603e] = "PowerPC 603e Optimization"
>
> # Note the TUNE_NAME is used differently from the TUNE_FEATURES
> TUNE_NAME ?= "ppc603e"
>
> TUNE_FEATURES_ppc603e = "m32 ppc603e"
> TUNE_FEATURES_ppc603e-64 = "m64 ppc603e"
>
> The if you include the tune-ppc603e.inc the default is the 32-bit version (what
> I'd consider the reasonable default...) If you wanted the 64-bit version
> instead you'd simply change set the TUNE_NAME to "ppc603e-64" and the properly
> tuned set of features is set for you.
>
> TUNE_PKGARCH_ppc603e = "ppc603e"
> TUNE_PKGARCH_ppc603e-64 = "ppc603e-64"
The thing is we don't' support the above syntax for TUNE_PKGARCH...
> etc...
>
> in the default (ppc603e) case, the TUNE_ARCH should always be "powerpc", and in
> the ppc603e-64 case (if manually enabled), it would be "powerpc64"...
>
> This is what was done in the ARM cases and I believe the core2 case in ia32.
which turns out to be broken :/.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=244e28
is what I'm considering to "fix" this. I guess the config could do:
TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e-64", "ppc603e-64", "ppc603e", d)}"
as per the x86 case but since this really limits the reuse of any of the
core variables as you might as well do:
AVAILTUNES = "ppc603e ppc603e-64"
after doing that since TUNE_PKGARCH will be wrong in any other case.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
2011-07-26 14:41 ` Mark Hatle
@ 2011-07-26 19:47 ` Khem Raj
2011-08-11 11:25 ` Phil Blundell
2 siblings, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-26 19:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, Jul 26, 2011 at 5:44 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/mips/arch-mips.inc | 64 +++++++++++++++++++++++++-
> meta/conf/machine/include/tune-mips32.inc | 10 +++-
> 2 files changed, 71 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
> index f7f4eed..071e6b5 100644
> --- a/meta/conf/machine/include/mips/arch-mips.inc
> +++ b/meta/conf/machine/include/mips/arch-mips.inc
> @@ -1 +1,63 @@
> -TUNE_ARCH = "mips"
> +# MIPS Architecture definition
> +# 12 defined ABIs, all combinations of:
> +# *) Big/Little Endian
> +# *) Hardware/Software Floating Point
> +# *) o32, n32, n64 ABI
> +
> +DEFAULTTUNE ?= "mips"
> +
> +# Endianess
> +TUNEVALID[bigendian] = "Enable big-endian mode"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d)}"
> +
> +# ABI flags
> +TUNEVALID[o32] = "MIPS o32 ABI"
> +TUNECONFLICT[o32] = "n32 n64"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "o32", "-mabi=32", "", d)}"
> +
> +TUNEVALID[n32] = "MIPS64 n32 ABI"
> +TUNECONFLICT[n32] = "o32 n64"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n32", "-mabi=n32", "", d)}"
> +
> +TUNEVALID[n64] = "MIPS64 n64 ABI"
> +TUNECONFLICT[n64] = "o32 n32"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-mabi=64", "", d)}"
> +
> +# Floating point
> +TUNEVALID[fpu-hard] = "Use hardware FPU"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
> +TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
> +
> +# Package naming
> +MIPSPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "", "el", d)}"
> +MIPSPKGSFX_BYTE = "${@bb.utils.contains("TUNE_FEATURES", "n64" , "64", "", d)}"
> +
> +TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
> +
> +# Base tunes
> +AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
may be nf should be called nofpu to make it a familiar term.
> +TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> +BASE_LIB_tune-mips = "lib"
> +TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> +BASE_LIB_tune-mips64-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> +BASE_LIB_tune-mips64 = "lib64"
> +TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> +BASE_LIB_tune-mipsel = "lib"
> +TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> +BASE_LIB_tune-mips64el-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> +BASE_LIB_tune-mips64el = "lib64"
> +TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> +BASE_LIB_tune-mips-nf = "lib"
> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> +BASE_LIB_tune-mips64-nf = "lib64"
> +TUNE_FEATURES_tune-mipsel-nf = "o32"
> +BASE_LIB_tune-mipsel-nf = "lib"
> +TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> +BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> +TUNE_FEATURES_tune-mips64el-nf = "n64"
> +BASE_LIB_tune-mips64el-nf = "lib64"
> +
> diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
> index 28b0047..1f913df 100644
> --- a/meta/conf/machine/include/tune-mips32.inc
> +++ b/meta/conf/machine/include/tune-mips32.inc
> @@ -1,4 +1,10 @@
> +DEFAULTTUNE ?= "mips32"
> +
> require conf/machine/include/mips/arch-mips.inc
>
> -TUNE_CCARGS = "-march=mips32"
> -TUNE_PKGARCH = "mips"
> +TUNEVALID[mips32] = "Enable mips32 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
> +
> +AVAILTUNES += "mips32"
> +TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
> +PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
> --
> 1.7.4.1
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 15:22 ` Kumar Gala
2011-07-26 16:18 ` Richard Purdie
@ 2011-07-26 20:03 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-26 20:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, Jul 26, 2011 at 8:22 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
>
>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>>
>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>> ---
>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>
>>> One thing I'm wondering about as we do this is the ability to pass
>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>>> & libs for a given target.
>>
>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
>> correct march and mtune options to the compiler at runtime through
>> CFLAGS and friends.
>
> Hmm, gcc still supports this:
>
> http://gcc.gnu.org/install/configure.html
>
> --with-cpu=cpu
> --with-cpu-32=cpu
> --with-cpu-64=cpu
> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
>
> http://gcc.gnu.org/install/specific.html
>
> powerpc-*-*
> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
thats only when you dont use -march -mtune -mcpu options but we use
them always so using this configure option is not needed so much
for us. Although I am not sure if the TARGET_CC_ARCH really makes into
gcc runtime especially libgcc in that case --with-cpu will do
things differently.
>
>> You're already found the way to pass configuration to *libc using values
>> in TARGET_FPU to pickup the right configuration.
>>
>> Is there a use case we're missing?
>
> Yes, for [e]glibc we have optimized libc functions for a given / specific PPC processor. So we need someway to tell configure this.
>
you need to use --with-cpu=CPU option at configure time. glibc
configury does not grok the -mtune options otherwise.
> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:36 ` Richard Purdie
2011-07-26 16:53 ` Mark Hatle
@ 2011-07-26 20:13 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-26 20:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, Jul 26, 2011 at 9:36 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2011-07-26 at 09:57 -0500, Mark Hatle wrote:
>> On 7/26/11 7:44 AM, Richard Purdie wrote:
>> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> > ---
>> > meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>> > meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>> > meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>> > meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>> > meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>> > meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>> > 6 files changed, 88 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > index 17ace32..3f7befb 100644
>> > --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
>> > @@ -1,3 +1,44 @@
>> > -TUNE_ARCH = "powerpc"
>> > +# Power Architecture definition
>> > +# Four defined ABIs, all combinations of:
>> > +# *) Hard/Soft Floating Point
>> > +# *) 32-bit/64-bit
>> > +
>> > +DEFAULTTUNE ?= "powerpc"
>> > +
>> > +TUNEVALID[m32] = "Power ELF32 standard ABI"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>> > +
>> > +TUNEVALID[m32-arch] = "Enable powerpc package architecture"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m32-arch" ], "powerpc", "", d)}"
>> > +
>> > +TUNEVALID[m64] = "Power ELF64 standard ABI"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-m64", "", d)}"
>> > +
>> > +TUNEVALID[m64-arch] = "Enable powerpc64 package architecture"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64-arch" ], "powerpc64", "", d)}"
>>
>> Why m32-arch and m64-arch? If m32 or m64 is selected then it should mean
>> powerpc or powerpc64.
>
> I've gotten confused here and mixed up TUNE_ARCH and TUNE_PKGARCH but
> there was a reason.
>
> The missing piece is
>
> TUNE_PKGARCH ?= "${TUNE_ARCH}"
>
> and the trouble comes when a tune file wants to change this only when
> its tune config is in action.
>
> I'm thinking ahead to trying a mixed ppc 32 and 64 bit build where
> TUNE_PKGARCH needs to take on the values for both configs.
>
>> > +TUNEVALID[fpu-hard] = "Use hardware FPU."
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
>> > +
>> > +TUNEVALID[fpu-soft] = "Use software FPU."
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
>> > +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
>>
>> Why specify both fpu-hard and fpu-soft? The "unusual" ABI is fpu-soft. It
>> would simplify it to only have to specify one, and you get the other automatically.
>
> The trouble is the spe pieces which seemed to imply TARGET_FPU should
> take on a value of other than "soft". Setting it to "soft" if fpu-hard
> isn't in TUNE_FEATURES therefore wasn't enough...
>
>> > +TUNEVALID[spe] = "Enable SPE ABI extensions"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}"
>> > +
>> > +ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
>>
>> SPE instructions are specific to certain processors and not generic across all
>> of PPC. I would move this to each of the tunes where it may be used.
>
> I guess this should be a feature file like thumb on arm?
>
>> Also I see the ABIEXTENSION, but where is it being set?
>
> I'm just migrating the existing code in that regard, I'm also puzzled as
> to where that is getting set currently.
>
>> > +# Basic tune definitions
>> > +AVAILTUNES += "powerpc powerpc-nf"
>> > +TUNE_FEATURES_tune-powerpc ?= "m32 m32-arch fpu-hard"
>> > +BASE_LIB_tune-powerpc = "lib"
>> > +TUNE_FEATURES_tune-powerpc-nf ?= "m32 m32-arch fpu-soft"
>> > +BASE_LIB_tune-powerpc-nf = "lib"
>> > +
>> > +AVAILTUNES += "powerpc64 powerpc64-nf"
>> > +TUNE_FEATURES_tune-powerpc64 ?= "m64 m64-arch fpu-hard"
>> > +BASE_LIB_tune-powerpc64 = "lib64"
>> > +TUNE_FEATURES_tune-powerpc64-nf ?= "m64 m64-arch fpu-soft"
>> > +BASE_LIB_tune-powerpc64-nf = "lib64"
>> >
>> > -ABIEXTENSION = "${@['','spe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"
>> > diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
>> > index 61c0669..6991ae0 100644
>> > --- a/meta/conf/machine/include/tune-ppc603e.inc
>> > +++ b/meta/conf/machine/include/tune-ppc603e.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppc603e"
>> > +
>> > require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=603e -mhard-float"
>> > -TUNE_PKGARCH = "ppc603e"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppc603e"
>> > +TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "ppc603e", "", d)}"
>> > +
>> > +AVAILTUNES += "ppc603e"
>> > +TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppc603e = "powerpc ppc603e"
>>
>> Going back to my original comment, the m32-arch is missing... or m32 should mean
>> "powerpc" (my suggestion).
>
> No, TUNE_ARCH should be TUNE_PKGARCH above, then this makes more
> sense...
>
>> > diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
>> > index a38e97c..652422f 100644
>> > --- a/meta/conf/machine/include/tune-ppce300c2.inc
>> > +++ b/meta/conf/machine/include/tune-ppce300c2.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce300"
>> > +
>> > require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=e300c2 -msoft-float"
>> > -TUNE_PKGARCH = "ppce300"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce300"
>> > +TUNEVALID[ppce300] = "Enable ppce300 specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "-mcpu=e300c2", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300", "ppce300", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce300"
>> > +TUNE_FEATURES_tune-ppce300 = "m32 fpu-soft ppce300"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce300 = "powerpc ppce300"
>>
>> There is also a ppce300 as well as the e300c2, so I'd change the option to be
>> fully qualified. (One has floating point one doesn't..)
>
> Fair enough.
>
>> > diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
>> > index 22208f0..fe62445 100644
>> > --- a/meta/conf/machine/include/tune-ppce500.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500.inc
>> > @@ -1,6 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500"
>> > +
>> > require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=8540"
>> > -BASE_PACKAGE_ARCH = "ppce500"
>> > -TUNE_PKGARCH = "ppce500"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500"
>> > +TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "ppce500", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500"
>> > +TUNE_FEATURES_tune-ppce500 = "m32 ppce500"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500 = "powerpc ppce500"
>>
>> This is the single precision e500 -- it should be specifying it's floating point
>> type.
>
> which is? :)
ppc-efs in oe terms
>
>> > diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
>> > index 182d019..0d3640f 100644
>> > --- a/meta/conf/machine/include/tune-ppce500mc.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500mc.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500mc"
>> > +
>> > require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=e500mc"
>> > -TUNE_PKGARCH = "ppce500mc"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
>> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "ppce500mc", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500mc"
>> > +TUNE_FEATURES_tune-ppce500mc = "m32 ppce500mc"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "powerpc ppce500mc"
>>
>> e500mc using the classic "hard-float" floating point unit.
>
> ok, so its hard-fpu...
>
>> > diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
>> > index daf2d58..e6b48a2 100644
>> > --- a/meta/conf/machine/include/tune-ppce500v2.inc
>> > +++ b/meta/conf/machine/include/tune-ppce500v2.inc
>> > @@ -1,5 +1,11 @@
>> > +DEFAULTTUNE ?= "ppce500v2"
>> > +
>> > require conf/machine/include/powerpc/arch-powerpc.inc
>> >
>> > -TUNE_CCARGS = "-mcpu=8548 -mabi=spe -mspe"
>> > -TUNE_PKGARCH = "ppce500v2"
>> > -PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
>> > +TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
>> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
>> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "ppce500v2", "", d)}"
>> > +
>> > +AVAILTUNES += "ppce500v2"
>> > +TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
>> > +PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "powerpc ppce500v2"
>>
>> This one is double precision.
>
> so hard-fpu?
no its spe with double precision which is ppc-efd
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 19:21 ` Richard Purdie
@ 2011-07-26 20:28 ` Richard Purdie
0 siblings, 0 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 20:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
I've taken various comments on board and a revised version of the PPC
version is:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=fa4a7b05bcfe397bb9243efb7138a6cc0a9d93fd
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:18 ` Richard Purdie
@ 2011-07-26 21:56 ` Kumar Gala
2011-07-26 22:02 ` Kumar Gala
2011-07-26 22:03 ` Kumar Gala
2 siblings, 0 replies; 92+ messages in thread
From: Kumar Gala @ 2011-07-26 21:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>>>
>>> You're already found the way to pass configuration to *libc using values
>>> in TARGET_FPU to pickup the right configuration.
>>>
>>> Is there a use case we're missing?
>>
>> Yes, for [e]glibc we have optimized libc functions for a given /
>> specific PPC processor. So we need someway to tell configure this.
>
> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> mentioned.
Are we thinking something like the following in e[glibc] recipes:
EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:18 ` Richard Purdie
2011-07-26 21:56 ` Kumar Gala
@ 2011-07-26 22:02 ` Kumar Gala
2011-07-26 22:29 ` Khem Raj
2011-07-26 22:52 ` Richard Purdie
2011-07-26 22:03 ` Kumar Gala
2 siblings, 2 replies; 92+ messages in thread
From: Kumar Gala @ 2011-07-26 22:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>>> You're already found the way to pass configuration to *libc using values
>>> in TARGET_FPU to pickup the right configuration.
>>>
>>> Is there a use case we're missing?
>>
>> Yes, for [e]glibc we have optimized libc functions for a given /
>> specific PPC processor. So we need someway to tell configure this.
>
> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> mentioned.
>
> Cheers,
>
> Richard
Are we thinking something like the following in e[glibc] recipes:
EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 16:18 ` Richard Purdie
2011-07-26 21:56 ` Kumar Gala
2011-07-26 22:02 ` Kumar Gala
@ 2011-07-26 22:03 ` Kumar Gala
2011-07-27 8:31 ` Richard Purdie
2 siblings, 1 reply; 92+ messages in thread
From: Kumar Gala @ 2011-07-26 22:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
>>
>>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
>>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
>>>>
>>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>>> ---
>>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
>>>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
>>>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
>>>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
>>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
>>>>
>>>> One thing I'm wondering about as we do this is the ability to pass
>>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
>>>> & libs for a given target.
>>>
>>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
>>> correct march and mtune options to the compiler at runtime through
>>> CFLAGS and friends.
>>
>> Hmm, gcc still supports this:
>>
>> http://gcc.gnu.org/install/configure.html
>>
>> --with-cpu=cpu
>> --with-cpu-32=cpu
>> --with-cpu-64=cpu
>> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
>>
>> http://gcc.gnu.org/install/specific.html
>>
>> powerpc-*-*
>> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
>
> I couldn't find that looking at the configure script :/.
>
> Anyhow, according to that page, its to "Specify which cpu variant the
> compiler should generate code for by default. cpu will be used as the
> default value of the -mcpu= switch". Since we always specify -mcpu when
> needed, I don't believe this is an issue for us as far as the build
> system goes.
>
> If you're talking about the gcc we build for the target, we should
> really encode all the cpu/tune options in there, not just part of the
> config so again, I don't think its appropriate to the way we use gcc.
What about tool chains produced as part of a ADT, wouldn't it be useful for such as case?
Seems like having ability to pass '--with-cpu' ends up being useful to set default for things like 32 vs 64-bit on multiple.
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 22:02 ` Kumar Gala
@ 2011-07-26 22:29 ` Khem Raj
2011-07-26 22:52 ` Richard Purdie
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-26 22:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, Jul 26, 2011 at 3:02 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>
>>>> You're already found the way to pass configuration to *libc using values
>>>> in TARGET_FPU to pickup the right configuration.
>>>>
>>>> Is there a use case we're missing?
>>>
>>> Yes, for [e]glibc we have optimized libc functions for a given /
>>> specific PPC processor. So we need someway to tell configure this.
>>
>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
>> mentioned.
>>
>> Cheers,
>>
>> Richard
>
> Are we thinking something like the following in e[glibc] recipes:
>
> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
>
I guess we can make a python function since most architectures can
benefit from --with-cpu
> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 22:02 ` Kumar Gala
2011-07-26 22:29 ` Khem Raj
@ 2011-07-26 22:52 ` Richard Purdie
2011-07-27 3:23 ` Kumar Gala
1 sibling, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-26 22:52 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>
> >>> You're already found the way to pass configuration to *libc using values
> >>> in TARGET_FPU to pickup the right configuration.
> >>>
> >>> Is there a use case we're missing?
> >>
> >> Yes, for [e]glibc we have optimized libc functions for a given /
> >> specific PPC processor. So we need someway to tell configure this.
> >
> > I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> > mentioned.
> >
> > Cheers,
> >
> > Richard
>
> Are we thinking something like the following in e[glibc] recipes:
>
> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
Could we glean this information from the TUNE_CCARGS variable and do
this automatically?
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 22:52 ` Richard Purdie
@ 2011-07-27 3:23 ` Kumar Gala
2011-07-27 8:36 ` Richard Purdie
0 siblings, 1 reply; 92+ messages in thread
From: Kumar Gala @ 2011-07-27 3:23 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Jul 26, 2011, at 5:52 PM, Richard Purdie wrote:
> On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
>> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>>
>>>>> You're already found the way to pass configuration to *libc using values
>>>>> in TARGET_FPU to pickup the right configuration.
>>>>>
>>>>> Is there a use case we're missing?
>>>>
>>>> Yes, for [e]glibc we have optimized libc functions for a given /
>>>> specific PPC processor. So we need someway to tell configure this.
>>>
>>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
>>> mentioned.
>>>
>>> Cheers,
>>>
>>> Richard
>>
>> Are we thinking something like the following in e[glibc] recipes:
>>
>> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
>
> Could we glean this information from the TUNE_CCARGS variable and do
> this automatically?
For PPC we'd have:
405
440
464
476
603e
e500
e500mc
e5500
970
a2
cell
power4
power5
power5+
power6
power6x
power7
There isn't always a clean mapping. For example ppce500 & ppce500v2 would want --with-cpu=e500. I believe ppc603e, ppce300c2 would want --with-cpu=603e.
If we want to just do it as a python function w/a mapping table we could easily handle it that way.
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-26 22:03 ` Kumar Gala
@ 2011-07-27 8:31 ` Richard Purdie
0 siblings, 0 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 8:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 17:03 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
>
> > On Tue, 2011-07-26 at 10:22 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 8:59 AM, Richard Purdie wrote:
> >>
> >>> On Tue, 2011-07-26 at 08:47 -0500, Kumar Gala wrote:
> >>>> On Jul 26, 2011, at 7:44 AM, Richard Purdie wrote:
> >>>>
> >>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>>> ---
> >>>>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 45 +++++++++++++++++++-
> >>>>> meta/conf/machine/include/tune-ppc603e.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce300c2.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500.inc | 13 ++++--
> >>>>> meta/conf/machine/include/tune-ppce500mc.inc | 12 ++++-
> >>>>> meta/conf/machine/include/tune-ppce500v2.inc | 12 ++++-
> >>>>> 6 files changed, 88 insertions(+), 18 deletions(-)
> >>>>
> >>>> One thing I'm wondering about as we do this is the ability to pass
> >>>> --with-cpu to gcc & [e]glibc configure to pickup proper optimized cfgs
> >>>> & libs for a given target.
> >>>
> >>> As far as I can tell, gcc 4.x has no --with-cpu option. We pass the
> >>> correct march and mtune options to the compiler at runtime through
> >>> CFLAGS and friends.
> >>
> >> Hmm, gcc still supports this:
> >>
> >> http://gcc.gnu.org/install/configure.html
> >>
> >> --with-cpu=cpu
> >> --with-cpu-32=cpu
> >> --with-cpu-64=cpu
> >> Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
> >>
> >> http://gcc.gnu.org/install/specific.html
> >>
> >> powerpc-*-*
> >> You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type.
> >
> > I couldn't find that looking at the configure script :/.
> >
> > Anyhow, according to that page, its to "Specify which cpu variant the
> > compiler should generate code for by default. cpu will be used as the
> > default value of the -mcpu= switch". Since we always specify -mcpu when
> > needed, I don't believe this is an issue for us as far as the build
> > system goes.
> >
> > If you're talking about the gcc we build for the target, we should
> > really encode all the cpu/tune options in there, not just part of the
> > config so again, I don't think its appropriate to the way we use gcc.
>
> What about tool chains produced as part of a ADT, wouldn't it be useful for such as case?
>
> Seems like having ability to pass '--with-cpu' ends up being useful to set default for things like 32 vs 64-bit on multiple.
ADT passes an environment script with all the appropriate flags
contained within including tunings which --with-cpu doesn't help with so
I'm not sure its so useful there.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-27 3:23 ` Kumar Gala
@ 2011-07-27 8:36 ` Richard Purdie
2011-07-27 8:44 ` Koen Kooi
0 siblings, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 8:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 22:23 -0500, Kumar Gala wrote:
> On Jul 26, 2011, at 5:52 PM, Richard Purdie wrote:
>
> > On Tue, 2011-07-26 at 17:02 -0500, Kumar Gala wrote:
> >> On Jul 26, 2011, at 11:18 AM, Richard Purdie wrote:
> >>
> >>>>> You're already found the way to pass configuration to *libc using values
> >>>>> in TARGET_FPU to pickup the right configuration.
> >>>>>
> >>>>> Is there a use case we're missing?
> >>>>
> >>>> Yes, for [e]glibc we have optimized libc functions for a given /
> >>>> specific PPC processor. So we need someway to tell configure this.
> >>>
> >>> I'd do this by looking for flags in TUNE_FEATURES as Mark has also
> >>> mentioned.
> >>>
> >>> Cheers,
> >>>
> >>> Richard
> >>
> >> Are we thinking something like the following in e[glibc] recipes:
> >>
> >> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-with-cpu=e500mc", "", d)}"
> >
> > Could we glean this information from the TUNE_CCARGS variable and do
> > this automatically?
>
> For PPC we'd have:
>
> 405
> 440
> 464
> 476
> 603e
> e500
> e500mc
> e5500
> 970
> a2
> cell
> power4
> power5
> power5+
> power6
> power6x
> power7
>
> There isn't always a clean mapping. For example ppce500 & ppce500v2 would want --with-cpu=e500. I believe ppc603e, ppce300c2 would want --with-cpu=603e.
>
> If we want to just do it as a python function w/a mapping table we could easily handle it that way.
We could also put:
GLIBC_EXTRA_OECONF = "--with-cpu=e500"
in the machine config files. When multilib gets involved we'd have to
become a little cleverer with this but there are options there...
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-27 8:36 ` Richard Purdie
@ 2011-07-27 8:44 ` Koen Kooi
2011-07-27 9:30 ` Richard Purdie
2011-07-27 9:35 ` [PATCH 3/3] Add basic PowerPC core tune config Phil Blundell
0 siblings, 2 replies; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 8:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:
> [..]
> We could also put:
>
> GLIBC_EXTRA_OECONF = "--with-cpu=e500"
>
> in the machine config files.
Note that that will make glibc 'machine' specific and by association all userspace. So if you're going that route, you need to touch TUNE_PKGARCH as well.
regards,
Koen
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-27 8:44 ` Koen Kooi
@ 2011-07-27 9:30 ` Richard Purdie
2011-07-28 5:25 ` Add basic PowerPC core tune config (bug?) Kumar Gala
2011-07-27 9:35 ` [PATCH 3/3] Add basic PowerPC core tune config Phil Blundell
1 sibling, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 9:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 10:44 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:
>
> > [..]
>
> > We could also put:
> >
> > GLIBC_EXTRA_OECONF = "--with-cpu=e500"
> >
> > in the machine config files.
>
> Note that that will make glibc 'machine' specific and by association
> all userspace. So if you're going that route, you need to touch
> TUNE_PKGARCH as well.
Right, I am making the assumption here that the optimisation chosen
would be appropriate to the TUNE_PKGARCH which is set. Certainly on PPC
there are some machines where this is already the case so it isn't a big
deal from what I've see of the tune files.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] Add basic PowerPC core tune config
2011-07-27 8:44 ` Koen Kooi
2011-07-27 9:30 ` Richard Purdie
@ 2011-07-27 9:35 ` Phil Blundell
1 sibling, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 9:35 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 10:44 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 10:36 heeft Richard Purdie het volgende geschreven:
>
> > [..]
>
> > We could also put:
> >
> > GLIBC_EXTRA_OECONF = "--with-cpu=e500"
> >
> > in the machine config files.
>
> Note that that will make glibc 'machine' specific and by association all userspace. So if you're going that route, you need to touch TUNE_PKGARCH as well.
That's true for glibc but it isn't entirely accurate to extend that to
"all userspace" since (AFAIK) none of the --with-cpu optimisations that
glibc does are ABI-changing. So, it's just eglibc itself that needs to
get a different package architecture, everything else can stay with the
generic value.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
2011-07-26 12:46 ` Koen Kooi
@ 2011-07-27 12:17 ` Phil Blundell
2011-07-27 13:33 ` Richard Purdie
2011-07-27 14:34 ` Phil Blundell
` (3 subsequent siblings)
5 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 12:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
This seems a bit backwards. Shouldn't TARGET_FPU be the primary
variable and then the package suffix be computed from that, rather than
vice versa?
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
This is wrong: ARMv6 doesn't imply Thumb-2.
> +# 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.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
This is only relevant for v4t, I guess. Interworking is basically
always on for v5 and later and (CeSI aside) it's impossible on v4, so
hardly anybody is going to be flipping this switch. I'm not sure it
really merits an OVERRIDE.
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
>
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
>
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
I guess that should be "_tune-xscale-be".
All in all it seems as though there's an awful lot of expanded cross
products in this set of patches and I can't help wondering whether a lot
of this stuff would be better computed programmatically. I wouldn't be
at all surprised if there are other copy-and-paste errors like the
xscale one lurking in that mass of overrides, but it's very hard to spot
them by eye. It seems particularly unfortunate that everything has to
be written out twice, once for big-endian and once for little-endian,
given that endianness is almost entirely orthogonal to all the other
"tuning" parameters.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 12:17 ` Phil Blundell
@ 2011-07-27 13:33 ` Richard Purdie
2011-07-27 14:27 ` Mark Hatle
2011-07-29 6:08 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 13:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>
> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
> variable and then the package suffix be computed from that, rather than
> vice versa?
It's been "fun" to use the rather limited constructs we have in these
variables to construct the end result. I suspect this way around, it was
the easiest way to get the right variables in the right places.
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>
> This is wrong: ARMv6 doesn't imply Thumb-2.
Ah, yes. I'll fix this.
> > +# 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.
> > +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> > +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>
> This is only relevant for v4t, I guess. Interworking is basically
> always on for v5 and later and (CeSI aside) it's impossible on v4, so
> hardly anybody is going to be flipping this switch. I'm not sure it
> really merits an OVERRIDE.
I'd be happy to remove this option if there are no objections. It was
left for compatibility with the existing tune-thumb file but as you say,
it likely doesn't make much sense.
> > --- a/meta/conf/machine/include/tune-xscale.inc
> > +++ b/meta/conf/machine/include/tune-xscale.inc
> > @@ -1,11 +1,17 @@
> > -require conf/machine/include/arm/arch-arm.inc
> > +DEFAULTTUNE ?= "xscale"
> >
> > -INHERIT += "siteinfo"
> > +require conf/machine/include/arm/arch-armv5-dsp.inc
> >
> > -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> > -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> > -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> > -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> > +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> > +
> > +AVAILTUNES += "xscale"
> > +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> > +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> > +
> > +AVAILTUNES += "xscale-be"
> > +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> > +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>
> I guess that should be "_tune-xscale-be".
Yes, I'll fix, well spotted.
> All in all it seems as though there's an awful lot of expanded cross
> products in this set of patches and I can't help wondering whether a lot
> of this stuff would be better computed programmatically. I wouldn't be
> at all surprised if there are other copy-and-paste errors like the
> xscale one lurking in that mass of overrides, but it's very hard to spot
> them by eye. It seems particularly unfortunate that everything has to
> be written out twice, once for big-endian and once for little-endian,
> given that endianness is almost entirely orthogonal to all the other
> "tuning" parameters.
At least three of us have now done a pass over this so hopefully we've
spotted the major ones but I agree its less than ideal.
The alternative is to post process the variables somehow, or turn it all
into anonymous python (which from a .conf file is not as easy as it
sounds).
I do like the fact that it allows some standardisation of the options
available in a given tune file as whether or not big endian was even
possible was previously hit and miss.
So I think its an improvement but likely not the finished end result.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 13:33 ` Richard Purdie
@ 2011-07-27 14:27 ` Mark Hatle
2011-07-27 14:33 ` Koen Kooi
` (2 more replies)
2011-07-29 6:08 ` Khem Raj
1 sibling, 3 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 14:27 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 8:33 AM, Richard Purdie wrote:
> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>
>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>> variable and then the package suffix be computed from that, rather than
>> vice versa?
>
> It's been "fun" to use the rather limited constructs we have in these
> variables to construct the end result. I suspect this way around, it was
> the easiest way to get the right variables in the right places.
>
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>
>> This is wrong: ARMv6 doesn't imply Thumb-2.
>
> Ah, yes. I'll fix this.
Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
were thumb(1). Note, not all ARMv6 processors contain thumb support.
>>> +# 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.
>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>
>> This is only relevant for v4t, I guess. Interworking is basically
>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>> hardly anybody is going to be flipping this switch. I'm not sure it
>> really merits an OVERRIDE.
>
> I'd be happy to remove this option if there are no objections. It was
> left for compatibility with the existing tune-thumb file but as you say,
> it likely doesn't make much sense.
>
>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>> @@ -1,11 +1,17 @@
>>> -require conf/machine/include/arm/arch-arm.inc
>>> +DEFAULTTUNE ?= "xscale"
>>>
>>> -INHERIT += "siteinfo"
>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>
>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>> +
>>> +AVAILTUNES += "xscale"
>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>> +
>>> +AVAILTUNES += "xscale-be"
>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>
>> I guess that should be "_tune-xscale-be".
>
> Yes, I'll fix, well spotted.
In the original work I did it was just tune-xscale (no be). AFAIK there is no
little endian version of xscale. (there was an iwmmxt that was similar to
xscale, but was slightly different.)
>> All in all it seems as though there's an awful lot of expanded cross
>> products in this set of patches and I can't help wondering whether a lot
>> of this stuff would be better computed programmatically. I wouldn't be
>> at all surprised if there are other copy-and-paste errors like the
>> xscale one lurking in that mass of overrides, but it's very hard to spot
>> them by eye. It seems particularly unfortunate that everything has to
>> be written out twice, once for big-endian and once for little-endian,
>> given that endianness is almost entirely orthogonal to all the other
>> "tuning" parameters.
>
> At least three of us have now done a pass over this so hopefully we've
> spotted the major ones but I agree its less than ideal.
>
> The alternative is to post process the variables somehow, or turn it all
> into anonymous python (which from a .conf file is not as easy as it
> sounds).
>
> I do like the fact that it allows some standardisation of the options
> available in a given tune file as whether or not big endian was even
> possible was previously hit and miss.
>
> So I think its an improvement but likely not the finished end result.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:27 ` Mark Hatle
@ 2011-07-27 14:33 ` Koen Kooi
2011-07-27 14:49 ` Mark Hatle
2011-07-27 14:34 ` Richard Purdie
2011-07-27 14:44 ` Phil Blundell
2 siblings, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 14:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
> On 7/27/11 8:33 AM, Richard Purdie wrote:
>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>
>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>> variable and then the package suffix be computed from that, rather than
>>> vice versa?
>>
>> It's been "fun" to use the rather limited constructs we have in these
>> variables to construct the end result. I suspect this way around, it was
>> the easiest way to get the right variables in the right places.
>>
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>
>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>
>> Ah, yes. I'll fix this.
>
> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
> were thumb(1). Note, not all ARMv6 processors contain thumb support.
As I understand it:
arm1136 doesn't have t2
arm1176 does have t2
both are armv6 :)
>
>>>> +# 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.
>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>
>>> This is only relevant for v4t, I guess. Interworking is basically
>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>> hardly anybody is going to be flipping this switch. I'm not sure it
>>> really merits an OVERRIDE.
>>
>> I'd be happy to remove this option if there are no objections. It was
>> left for compatibility with the existing tune-thumb file but as you say,
>> it likely doesn't make much sense.
>>
>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>> @@ -1,11 +1,17 @@
>>>> -require conf/machine/include/arm/arch-arm.inc
>>>> +DEFAULTTUNE ?= "xscale"
>>>>
>>>> -INHERIT += "siteinfo"
>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>>
>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>> +
>>>> +AVAILTUNES += "xscale"
>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>> +
>>>> +AVAILTUNES += "xscale-be"
>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>>
>>> I guess that should be "_tune-xscale-be".
>>
>> Yes, I'll fix, well spotted.
>
> In the original work I did it was just tune-xscale (no be). AFAIK there is no
> little endian version of xscale. (there was an iwmmxt that was similar to
> xscale, but was slightly different.)
pxa25x are LE xscales (e.g. Palm Treo)
pxa26x are LE xscales with some NAND builtin
pxa27x are LE xscales with iwmmxt as an extra
>
>>> All in all it seems as though there's an awful lot of expanded cross
>>> products in this set of patches and I can't help wondering whether a lot
>>> of this stuff would be better computed programmatically. I wouldn't be
>>> at all surprised if there are other copy-and-paste errors like the
>>> xscale one lurking in that mass of overrides, but it's very hard to spot
>>> them by eye. It seems particularly unfortunate that everything has to
>>> be written out twice, once for big-endian and once for little-endian,
>>> given that endianness is almost entirely orthogonal to all the other
>>> "tuning" parameters.
>>
>> At least three of us have now done a pass over this so hopefully we've
>> spotted the major ones but I agree its less than ideal.
>>
>> The alternative is to post process the variables somehow, or turn it all
>> into anonymous python (which from a .conf file is not as easy as it
>> sounds).
>>
>> I do like the fact that it allows some standardisation of the options
>> available in a given tune file as whether or not big endian was even
>> possible was previously hit and miss.
>>
>> So I think its an improvement but likely not the finished end result.
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
2011-07-26 12:46 ` Koen Kooi
2011-07-27 12:17 ` Phil Blundell
@ 2011-07-27 14:34 ` Phil Blundell
2011-07-27 14:58 ` Mark Hatle
2011-07-27 17:31 ` do_rootfs broken, was: " Koen Kooi
` (2 subsequent siblings)
5 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 14:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
I just looked at this again and here are a few more comments:
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
Otherwise you will get a mixture of big and little endian in there.
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
There seems to be some duplication of AVAILTUNES going on here.
Also, I think this v5 stuff is more complex than it needs to be because
it seems to be trying to cater for architecture combinations that are
possible in theory but don't actually exist in the wild. For example, I
can't immediately think of any ARMv5 implementations that lack Thumb or
the E instructions.
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
The comment doesn't seem to match the code here since this is the
section for chips without DSP. Incidentally, the name "dsp" for this
feature seems quite a bad one: maybe we should just call it "armv5e".
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:27 ` Mark Hatle
2011-07-27 14:33 ` Koen Kooi
@ 2011-07-27 14:34 ` Richard Purdie
2011-07-27 14:44 ` Phil Blundell
2 siblings, 0 replies; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 14:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
> On 7/27/11 8:33 AM, Richard Purdie wrote:
> > On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> >> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> >>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> >>
> >> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
> >> variable and then the package suffix be computed from that, rather than
> >> vice versa?
> >
> > It's been "fun" to use the rather limited constructs we have in these
> > variables to construct the end result. I suspect this way around, it was
> > the easiest way to get the right variables in the right places.
> >
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> >>
> >> This is wrong: ARMv6 doesn't imply Thumb-2.
> >
> > Ah, yes. I'll fix this.
>
> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
> were thumb(1). Note, not all ARMv6 processors contain thumb support.
I did quickly check up on this and I think Phil is right but I'll take
other evidence...
> >>> --- a/meta/conf/machine/include/tune-xscale.inc
> >>> +++ b/meta/conf/machine/include/tune-xscale.inc
> >>> @@ -1,11 +1,17 @@
> >>> -require conf/machine/include/arm/arch-arm.inc
> >>> +DEFAULTTUNE ?= "xscale"
> >>>
> >>> -INHERIT += "siteinfo"
> >>> +require conf/machine/include/arm/arch-armv5-dsp.inc
> >>>
> >>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> >>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> >>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> >>> +
> >>> +AVAILTUNES += "xscale"
> >>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> >>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> >>> +
> >>> +AVAILTUNES += "xscale-be"
> >>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> >>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> >>
> >> I guess that should be "_tune-xscale-be".
> >
> > Yes, I'll fix, well spotted.
>
> In the original work I did it was just tune-xscale (no be). AFAIK there is no
> little endian version of xscale. (there was an iwmmxt that was similar to
> xscale, but was slightly different.)
You can put most ARM processors including XScale into big or little
endian mode as far as I know. The infamous OE example is the NSLU2
(IXP4xx) which is xscale based and runs in BE by default. This is why
the original tune file supports both endians.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:27 ` Mark Hatle
2011-07-27 14:33 ` Koen Kooi
2011-07-27 14:34 ` Richard Purdie
@ 2011-07-27 14:44 ` Phil Blundell
2011-07-27 14:55 ` Mark Hatle
2011-07-29 6:18 ` Khem Raj
2 siblings, 2 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 14:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
> On 7/27/11 8:33 AM, Richard Purdie wrote:
> > On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> >> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> >>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> >>
> >> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
> >> variable and then the package suffix be computed from that, rather than
> >> vice versa?
> >
> > It's been "fun" to use the rather limited constructs we have in these
> > variables to construct the end result. I suspect this way around, it was
> > the easiest way to get the right variables in the right places.
> >
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> >>
> >> This is wrong: ARMv6 doesn't imply Thumb-2.
> >
> > Ah, yes. I'll fix this.
>
> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
> were thumb(1). Note, not all ARMv6 processors contain thumb support.
It is true that all ARMv4T and ARMv5T processors are only Thumb-1. It's
also true that Thumb-2 was first implemented in ARM1156, which is an
ARMv6 core. But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
and all three of those are Thumb-1 only. Given that nobody is likely to
target ARM1156 with OE, it's probably a reasonable approximation to say
that Thumb-2 correlates with ARMv7 and later.
Also, since there are no v5, v6 or v7 cores which don't support Thumb,
the "t" suffix serves no useful purpose here and might as well just be
omitted. That is, there is no CPU which can run "armv6" packages which
wouldn't also be able to run "armv6t".
> In the original work I did it was just tune-xscale (no be). AFAIK there is no
> little endian version of xscale.
No, that's incorrect. The PXA25x series and IXP420, at least, are
bi-endian (and I suspect most of the other XScales are too) and there
are certainly folks running them in little endian configurations.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:33 ` Koen Kooi
@ 2011-07-27 14:49 ` Mark Hatle
2011-07-27 14:57 ` Phil Blundell
2011-07-29 6:20 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 14:49 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 9:33 AM, Koen Kooi wrote:
>
> Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
>
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
>> were thumb(1). Note, not all ARMv6 processors contain thumb support.
>
> As I understand it:
>
> arm1136 doesn't have t2
> arm1176 does have t2
>
> both are armv6 :)
They also don't have "thumb" support either. So armv6 & thumb == t2.
>>
>>>>> +# 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.
>>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>>
>>>> This is only relevant for v4t, I guess. Interworking is basically
>>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>>> hardly anybody is going to be flipping this switch. I'm not sure it
>>>> really merits an OVERRIDE.
>>>
>>> I'd be happy to remove this option if there are no objections. It was
>>> left for compatibility with the existing tune-thumb file but as you say,
>>> it likely doesn't make much sense.
>>>
>>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>>> @@ -1,11 +1,17 @@
>>>>> -require conf/machine/include/arm/arch-arm.inc
>>>>> +DEFAULTTUNE ?= "xscale"
>>>>>
>>>>> -INHERIT += "siteinfo"
>>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>>>
>>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>>> +
>>>>> +AVAILTUNES += "xscale"
>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>>> +
>>>>> +AVAILTUNES += "xscale-be"
>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>>>
>>>> I guess that should be "_tune-xscale-be".
>>>
>>> Yes, I'll fix, well spotted.
>>
>> In the original work I did it was just tune-xscale (no be). AFAIK there is no
>> little endian version of xscale. (there was an iwmmxt that was similar to
>> xscale, but was slightly different.)
>
> pxa25x are LE xscales (e.g. Palm Treo)
> pxa26x are LE xscales with some NAND builtin
> pxa27x are LE xscales with iwmmxt as an extra
All thought all of those were considered to me iwmmxt cores. The whole PXA
series naming is very confusing to say the least.
>
>>
>>>> All in all it seems as though there's an awful lot of expanded cross
>>>> products in this set of patches and I can't help wondering whether a lot
>>>> of this stuff would be better computed programmatically. I wouldn't be
>>>> at all surprised if there are other copy-and-paste errors like the
>>>> xscale one lurking in that mass of overrides, but it's very hard to spot
>>>> them by eye. It seems particularly unfortunate that everything has to
>>>> be written out twice, once for big-endian and once for little-endian,
>>>> given that endianness is almost entirely orthogonal to all the other
>>>> "tuning" parameters.
>>>
>>> At least three of us have now done a pass over this so hopefully we've
>>> spotted the major ones but I agree its less than ideal.
>>>
>>> The alternative is to post process the variables somehow, or turn it all
>>> into anonymous python (which from a .conf file is not as easy as it
>>> sounds).
>>>
>>> I do like the fact that it allows some standardisation of the options
>>> available in a given tune file as whether or not big endian was even
>>> possible was previously hit and miss.
>>>
>>> So I think its an improvement but likely not the finished end result.
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:44 ` Phil Blundell
@ 2011-07-27 14:55 ` Mark Hatle
2011-07-29 6:18 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 14:55 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 9:44 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
>> were thumb(1). Note, not all ARMv6 processors contain thumb support.
>
> It is true that all ARMv4T and ARMv5T processors are only Thumb-1. It's
> also true that Thumb-2 was first implemented in ARM1156, which is an
> ARMv6 core. But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
> and all three of those are Thumb-1 only. Given that nobody is likely to
> target ARM1156 with OE, it's probably a reasonable approximation to say
> that Thumb-2 correlates with ARMv7 and later.
If all of the other ARMv6 cores w/ thumb support are thumb1. Then it's easily
enough to change it back to 't'. If someone does add tunings for the 1156 then
they can easily augment it to t2 within that tuning file. I didn't realize not
all of armv6 (that supported thumb) wasn't thumb2 (or no thumb).
> Also, since there are no v5, v6 or v7 cores which don't support Thumb,
> the "t" suffix serves no useful purpose here and might as well just be
> omitted. That is, there is no CPU which can run "armv6" packages which
> wouldn't also be able to run "armv6t".
There are definitely chips that are v5, 6 and 7 that do not have thumb support.
I'm not sure any of them were mass-market chips though.
>> In the original work I did it was just tune-xscale (no be). AFAIK there is no
>> little endian version of xscale.
>
> No, that's incorrect. The PXA25x series and IXP420, at least, are
> bi-endian (and I suspect most of the other XScales are too) and there
> are certainly folks running them in little endian configurations.
Ok.
--Mark
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:49 ` Mark Hatle
@ 2011-07-27 14:57 ` Phil Blundell
2011-07-27 15:01 ` Koen Kooi
2011-07-29 6:20 ` Khem Raj
1 sibling, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 14:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 09:49 -0500, Mark Hatle wrote:
> On 7/27/11 9:33 AM, Koen Kooi wrote:
> > As I understand it:
> >
> > arm1136 doesn't have t2
> > arm1176 does have t2
> >
> > both are armv6 :)
>
> They also don't have "thumb" support either. So armv6 & thumb == t2.
No, that's incorrect. Both ARM1136 and ARM1176 do have Thumb-1 and, as
I wrote in my last mail, I can't think of any plausible target processor
for OE that has both ARMv6 and Thumb-2. So, for all current intents and
purposes, (armv6 && thumb) == thumb-1.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:34 ` Phil Blundell
@ 2011-07-27 14:58 ` Mark Hatle
2011-07-27 15:25 ` Phil Blundell
2011-07-29 6:27 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 14:58 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 9:34 AM, Phil Blundell wrote:
> I just looked at this again and here are a few more comments:
>
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
>
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will get a mixture of big and little endian in there.
>
>> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
>> @@ -0,0 +1,40 @@
>> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
>> +
>> +require conf/machine/include/arm/arch-armv5.inc
>> +
>> +# Little Endian
>> +AVAILTUNES += "armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
>> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
>> +
>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
>> new file mode 100644
>> index 0000000..55cbe03
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
>> @@ -0,0 +1,51 @@
>> +# Little Endian
>> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5 ?= "armv5"
>> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
>
> There seems to be some duplication of AVAILTUNES going on here.
>
> Also, I think this v5 stuff is more complex than it needs to be because
> it seems to be trying to cater for architecture combinations that are
> possible in theory but don't actually exist in the wild. For example, I
> can't immediately think of any ARMv5 implementations that lack Thumb or
> the E instructions.
For the tune names.. armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.
So armv5 and armv5t are distinct in the contents of the tunings.
There were armv5's without thumb support.. but that doesn't matter much. A
machine with thumb is compatible (run-time) with one that does not. A machine
w/o thumb is not necessarily compatible with thumb executables.
>> +# Little Endian + VFP/DSP
>> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
>
> The comment doesn't seem to match the code here since this is the
> section for chips without DSP. Incidentally, the name "dsp" for this
> feature seems quite a bad one: maybe we should just call it "armv5e".
Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
the "dsp" capabilities actually change any of the code or support generated. If
not then we can ignore it.
For armv5 this gives us:
armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
EABI...
--Mark
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:57 ` Phil Blundell
@ 2011-07-27 15:01 ` Koen Kooi
2011-07-27 15:08 ` Phil Blundell
0 siblings, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 15:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 jul. 2011, om 16:57 heeft Phil Blundell het volgende geschreven:
> On Wed, 2011-07-27 at 09:49 -0500, Mark Hatle wrote:
>> On 7/27/11 9:33 AM, Koen Kooi wrote:
>>> As I understand it:
>>>
>>> arm1136 doesn't have t2
>>> arm1176 does have t2
>>>
>>> both are armv6 :)
>>
>> They also don't have "thumb" support either. So armv6 & thumb == t2.
>
> No, that's incorrect. Both ARM1136 and ARM1176 do have Thumb-1 and, as
> I wrote in my last mail, I can't think of any plausible target processor
> for OE that has both ARMv6 and Thumb-2. So, for all current intents and
> purposes, (armv6 && thumb) == thumb-1.
the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:01 ` Koen Kooi
@ 2011-07-27 15:08 ` Phil Blundell
2011-07-27 15:13 ` Koen Kooi
2011-07-29 6:31 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 15:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
> the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
What makes you think that ARM1176 has T2? I haven't actually tried
executing Thumb-2 on one, but my recollection is definitely that it was
Thumb-1 only.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:08 ` Phil Blundell
@ 2011-07-27 15:13 ` Koen Kooi
2011-07-27 15:17 ` Phil Blundell
2011-07-29 6:31 ` Khem Raj
1 sibling, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 15:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 jul. 2011, om 17:08 heeft Phil Blundell het volgende geschreven:
> On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
>> the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
>
> What makes you think that ARM1176 has T2? I haven't actually tried
> executing Thumb-2 on one, but my recollection is definitely that it was
> Thumb-1 only.
In this case it's (yes, you may start making fun of me at this point) wikipedia: http://en.wikipedia.org/wiki/ARM#Thumb-2
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:13 ` Koen Kooi
@ 2011-07-27 15:17 ` Phil Blundell
0 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 15:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 17:13 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 17:08 heeft Phil Blundell het volgende geschreven:
>
> > On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
> >> the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
> >
> > What makes you think that ARM1176 has T2? I haven't actually tried
> > executing Thumb-2 on one, but my recollection is definitely that it was
> > Thumb-1 only.
>
> In this case it's (yes, you may start making fun of me at this point) wikipedia: http://en.wikipedia.org/wiki/ARM#Thumb-2
I couldn't immediately see anything on that page which referred to the
ARM1176 specifically. There is a slightly vague sentence which talks
about "[o]ther chips in the Cortex and ARM11 series", which I guess
could be construed as "all other chips", but apart from that it doesn't
seem to be saying much about what implementation goes with which ISA.
Anyway, the ARM1176 spec and reference manual are available on the web
and I think this is probably a more reliable source than wikipedia :-)
http://www.arm.com/products/processors/classic/arm11/arm1176.php
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:58 ` Mark Hatle
@ 2011-07-27 15:25 ` Phil Blundell
2011-07-27 15:29 ` Richard Purdie
` (2 more replies)
2011-07-29 6:27 ` Khem Raj
1 sibling, 3 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 15:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> means I was thumb instructions.
>
> So armv5 and armv5t are distinct in the contents of the tunings.
Ah, I see. Does that go for v4t too? I can imagine cases where you
would want to say "select the v4T ISA but generate ARM code not Thumb".
> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
> the "dsp" capabilities actually change any of the code or support generated. If
> not then we can ignore it.
Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
will affect any code which uses __builtin_prefetch(). I don't think GCC
will ever open-code the saturating arithmetic instructions, but it does
expose the v5/v5e distinction through preprocessor macros and source
code might use that to select asm() statements which use those opcodes.
> For armv5 this gives us:
>
> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> EABI...
Does anybody really want the hardfloat abi on armv5? I guess it doesn't
hurt all that much to offer it, but anything that makes that monstrous
set of .inc files bigger seems like a bad thing.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:25 ` Phil Blundell
@ 2011-07-27 15:29 ` Richard Purdie
2011-07-27 15:49 ` Phil Blundell
2011-07-27 17:19 ` Mark Hatle
2011-07-29 6:38 ` Khem Raj
2 siblings, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-07-27 15:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 16:25 +0100, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> > For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> > means I was thumb instructions.
> >
> > So armv5 and armv5t are distinct in the contents of the tunings.
>
> Ah, I see. Does that go for v4t too? I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> > Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
> > the "dsp" capabilities actually change any of the code or support generated. If
> > not then we can ignore it.
>
> Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch(). I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.
>
> > For armv5 this gives us:
> >
> > armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> > EABI...
>
> Does anybody really want the hardfloat abi on armv5? I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.
Just to summarise where we're at with this, I thought comments had died
down from anyone likely to comment so I merged the patches since there
was a done depending upon them. Comments then picked up again.
The code is now as it stands, I'll take patches to improve/fix things as
usual...
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:29 ` Richard Purdie
@ 2011-07-27 15:49 ` Phil Blundell
0 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 15:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 16:29 +0100, Richard Purdie wrote:
> Just to summarise where we're at with this, I thought comments had died
> down from anyone likely to comment so I merged the patches since there
> was a done depending upon them. Comments then picked up again.
Fair enough, though I think this was perhaps a bit premature. It is/was
a big and complicated patch and you only posted it for review yesterday
afternoon. In future it would be nice to have a bit more time for
reviewing this sort of thing.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:25 ` Phil Blundell
2011-07-27 15:29 ` Richard Purdie
@ 2011-07-27 17:19 ` Mark Hatle
2011-07-27 19:31 ` Phil Blundell
` (2 more replies)
2011-07-29 6:38 ` Khem Raj
2 siblings, 3 replies; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 17:19 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 10:25 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
>> means I was thumb instructions.
>>
>> So armv5 and armv5t are distinct in the contents of the tunings.
>
> Ah, I see. Does that go for v4t too? I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".
Yes, for all of them, the TUNENAME selects the features that you want to use to
compile, and suggests the other information like compatible architectures.
In the case where you want to build primarily one, and optionally the other the
tunename makes it easy..
Say you want all of your system thumb, except for a few specific programs..
TUNENAME = "armv4t"
TUNENAME_pn-mysql = "armv4"
In the opposite case, where you want everything ARM, except for a few thumb:
TUNENAME = "armv7"
TUNENAME_pn-bash = "armv7t"
PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}
Second line ensures that the base armv7 tune inherits the "more complete" set of
compatible machines.
(Note, in most cases I would expect a machine/BSP configuration to do most of
this inheriting... or if someone was being tricky they can do it manually.)
>> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
>> the "dsp" capabilities actually change any of the code or support generated. If
>> not then we can ignore it.
>
> Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch(). I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.
So then the question is.. with OE-core and core based distros.. are there enough
armv5 (w/ or w/o e) left to justify having both? If not.. then we select the
one with the 'e' since it's more common.
>> For armv5 this gives us:
>>
>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>> EABI...
>
> Does anybody really want the hardfloat abi on armv5? I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.
I was surprised anyone wanted the hardfloat ABI at all.. :P ...but anyway... if
it'll work on armv5 (and the previous question about is armv5 relevant answered)
we can choose it or not.. It was there to be complete in the original
version... (also armv5 w/ VFP is the lowest compatible machine for a HF
implementation.)
--Mark
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* do_rootfs broken, was: Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
` (2 preceding siblings ...)
2011-07-27 14:34 ` Phil Blundell
@ 2011-07-27 17:31 ` Koen Kooi
2011-07-27 18:19 ` Koen Kooi
2011-07-28 11:39 ` Phil Blundell
2011-07-29 5:59 ` Khem Raj
5 siblings, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 17:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
<snip patch>
It looks like PACKAGE_*_ARCHS is broken in the rootfs class:
cat /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/efl-nodm-image-1.0-r0/opkg.conf:
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch beagleboard 21
But the one in the opkg config package is correct:
koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ dpkg-deb -x ipk/beagleboard/opkg-config-base_1.0-r0_beagleboard.ipk tmp/
koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ cat tmp/etc/opkg/arch.conf
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armv4 21
arch armv4t 26
arch armv5te 31
arch armv6 36
arch armv7 41
arch armv7a 46
arch beagleboard 51
koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: do_rootfs broken, was: Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 17:31 ` do_rootfs broken, was: " Koen Kooi
@ 2011-07-27 18:19 ` Koen Kooi
0 siblings, 0 replies; 92+ messages in thread
From: Koen Kooi @ 2011-07-27 18:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 jul. 2011, om 19:31 heeft Koen Kooi het volgende geschreven:
> <snip patch>
>
> It looks like PACKAGE_*_ARCHS is broken in the rootfs class:
>
> cat /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/efl-nodm-image-1.0-r0/opkg.conf:
> arch all 1
> arch any 6
> arch noarch 11
> arch arm 16
> arch beagleboard 21
>
> But the one in the opkg config package is correct:
>
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ dpkg-deb -x ipk/beagleboard/opkg-config-base_1.0-r0_beagleboard.ipk tmp/
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ cat tmp/etc/opkg/arch.conf
> arch all 1
> arch any 6
> arch noarch 11
> arch arm 16
> arch armv4 21
> arch armv4t 26
> arch armv5te 31
> arch armv6 36
> arch armv7 41
> arch armv7a 46
> arch beagleboard 51
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$
bitbake -e:
# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon beagleboard"
bitbake -e some-image:
# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch arm beagleboard"
PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon="armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7hf-vfp armv7t2hf-vfp armv7hf-vfp-neon armv7at2hf-vfp-neon"
So it looks like all the tune-* overrides don't get expanded when building an image.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 17:19 ` Mark Hatle
@ 2011-07-27 19:31 ` Phil Blundell
2011-07-27 20:48 ` Mark Hatle
2011-07-28 7:24 ` Martin Jansa
2011-07-29 6:41 ` Khem Raj
2 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 19:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> >
> > Ah, I see. Does that go for v4t too? I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
>
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
>
> Say you want all of your system thumb, except for a few specific programs..
>
> TUNENAME = "armv4t"
>
> TUNENAME_pn-mysql = "armv4"
>
> In the opposite case, where you want everything ARM, except for a few thumb:
>
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
I'm not quite sure that this answers the question I was trying to ask.
The thing about v4/v4T is that, unlike later versions of the
architecture, plain v4 doesn't include the BX instruction. So, if you
want your code to be interworking-capable without requiring linker
shims, you need to specify -march=armv4t (and -mthumb-interwork) even
for CUs that you want to compile as ARM code.
If the architecture name implies the execution state then it doesn't
appear as though there is going to be any way to select -march=armv4t
without also selecting -mthumb, which would make it impossible to build
interworking-capable ARM-state code for v4T.
> So then the question is.. with OE-core and core based distros.. are there enough
> armv5 (w/ or w/o e) left to justify having both? If not.. then we select the
> one with the 'e' since it's more common.
I'm not aware of anybody using a non-e ARMv5 with OE at all. The two
most common v5-class implementations, by some margin I think, are the
ARM9x6 family and Xscale, and all of those are at least v5TE.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 19:31 ` Phil Blundell
@ 2011-07-27 20:48 ` Mark Hatle
2011-07-27 21:16 ` Phil Blundell
0 siblings, 1 reply; 92+ messages in thread
From: Mark Hatle @ 2011-07-27 20:48 UTC (permalink / raw)
To: openembedded-core
On 7/27/11 2:31 PM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
>> On 7/27/11 10:25 AM, Phil Blundell wrote:
>>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>>> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
>>>> means I was thumb instructions.
>>>>
>>>> So armv5 and armv5t are distinct in the contents of the tunings.
>>>
>>> Ah, I see. Does that go for v4t too? I can imagine cases where you
>>> would want to say "select the v4T ISA but generate ARM code not Thumb".
>>
>> Yes, for all of them, the TUNENAME selects the features that you want to use to
>> compile, and suggests the other information like compatible architectures.
>>
>> In the case where you want to build primarily one, and optionally the other the
>> tunename makes it easy..
>>
>> Say you want all of your system thumb, except for a few specific programs..
>>
>> TUNENAME = "armv4t"
>>
>> TUNENAME_pn-mysql = "armv4"
>>
>> In the opposite case, where you want everything ARM, except for a few thumb:
>>
>> TUNENAME = "armv7"
>> TUNENAME_pn-bash = "armv7t"
>
> I'm not quite sure that this answers the question I was trying to ask.
>
> The thing about v4/v4T is that, unlike later versions of the
> architecture, plain v4 doesn't include the BX instruction. So, if you
> want your code to be interworking-capable without requiring linker
> shims, you need to specify -march=armv4t (and -mthumb-interwork) even
> for CUs that you want to compile as ARM code.
>
> If the architecture name implies the execution state then it doesn't
> appear as though there is going to be any way to select -march=armv4t
> without also selecting -mthumb, which would make it impossible to build
> interworking-capable ARM-state code for v4T.
It was my understanding that interwork was always enabled these days. Does
interworking require a thumb compatible arm core?
--Mark
>> So then the question is.. with OE-core and core based distros.. are there enough
>> armv5 (w/ or w/o e) left to justify having both? If not.. then we select the
>> one with the 'e' since it's more common.
>
> I'm not aware of anybody using a non-e ARMv5 with OE at all. The two
> most common v5-class implementations, by some margin I think, are the
> ARM9x6 family and Xscale, and all of those are at least v5TE.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 20:48 ` Mark Hatle
@ 2011-07-27 21:16 ` Phil Blundell
2011-07-28 0:43 ` Khem Raj
0 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-27 21:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 15:48 -0500, Mark Hatle wrote:
> On 7/27/11 2:31 PM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
> >> On 7/27/11 10:25 AM, Phil Blundell wrote:
> >>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >>>> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> >>>> means I was thumb instructions.
> >>>>
> >>>> So armv5 and armv5t are distinct in the contents of the tunings.
> >>>
> >>> Ah, I see. Does that go for v4t too? I can imagine cases where you
> >>> would want to say "select the v4T ISA but generate ARM code not Thumb".
> >>
> >> Yes, for all of them, the TUNENAME selects the features that you want to use to
> >> compile, and suggests the other information like compatible architectures.
> >>
> >> In the case where you want to build primarily one, and optionally the other the
> >> tunename makes it easy..
> >>
> >> Say you want all of your system thumb, except for a few specific programs..
> >>
> >> TUNENAME = "armv4t"
> >>
> >> TUNENAME_pn-mysql = "armv4"
> >>
> >> In the opposite case, where you want everything ARM, except for a few thumb:
> >>
> >> TUNENAME = "armv7"
> >> TUNENAME_pn-bash = "armv7t"
> >
> > I'm not quite sure that this answers the question I was trying to ask.
> >
> > The thing about v4/v4T is that, unlike later versions of the
> > architecture, plain v4 doesn't include the BX instruction. So, if you
> > want your code to be interworking-capable without requiring linker
> > shims, you need to specify -march=armv4t (and -mthumb-interwork) even
> > for CUs that you want to compile as ARM code.
> >
> > If the architecture name implies the execution state then it doesn't
> > appear as though there is going to be any way to select -march=armv4t
> > without also selecting -mthumb, which would make it impossible to build
> > interworking-capable ARM-state code for v4T.
>
> It was my understanding that interwork was always enabled these days. Does
> interworking require a thumb compatible arm core?
Not for v5 and up, since the ARM-state BX instruction always exists
(even if it isn't capable of switching to Thumb-state), and pop {pc}
always changes state if necessary. The combination of these two things
means that interworking basically comes for free and there is no benefit
to turning it off.
But for v4T, the only instruction which is capable of a state change is
BX, and that instruction simply doesn't exist at all in the non-T v4
architecture. So, if you plan to run on a v4 core you must either build
with interworking off, or (more commonly nowadays) use the --fix-v4bx
linker option to convert BX back to MOV during final link.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 21:16 ` Phil Blundell
@ 2011-07-28 0:43 ` Khem Raj
0 siblings, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-28 0:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
> >
> > It was my understanding that interwork was always enabled these days. Does
> > interworking require a thumb compatible arm core?
>
> Not for v5 and up, since the ARM-state BX instruction always exists
> (even if it isn't capable of switching to Thumb-state), and pop {pc}
> always changes state if necessary. The combination of these two things
> means that interworking basically comes for free and there is no benefit
> to turning it off.
>
> But for v4T, the only instruction which is capable of a state change is
> BX, and that instruction simply doesn't exist at all in the non-T v4
> architecture. So, if you plan to run on a v4 core you must either build
> with interworking off, or (more commonly nowadays) use the --fix-v4bx
> linker option to convert BX back to MOV during final link.
We use --fix-v4bx in oe
--
-Khem
^ permalink raw reply [flat|nested] 92+ messages in thread
* Add basic PowerPC core tune config (bug?)
2011-07-27 9:30 ` Richard Purdie
@ 2011-07-28 5:25 ` Kumar Gala
2011-07-28 6:09 ` Saul Wold
0 siblings, 1 reply; 92+ messages in thread
From: Kumar Gala @ 2011-07-28 5:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
For some reason when I get to do_rootfs for core-image-sato when using rpms I run into an issue in that:
${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
Isn't expanding or taking the assignment in meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in meta/conf/bitbake.conf
the tune-ppcFOO.inc looks like:
DEFAULTTUNE ?= "ppce5500"
require conf/machine/include/powerpc/arch-powerpc64.inc
TUNEVALID[ppce5500] = "Enable ppce5500 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "-mcpu=e5500", "", d)}"
TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "ppce5500", "", d)}"
AVAILTUNES += "ppce5500"
TUNE_FEATURES_tune-ppce5500 = "m64 hard-fpu ppce5500"
PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "powerpc64 ppce5500"
any ideas?
- k
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 5:25 ` Add basic PowerPC core tune config (bug?) Kumar Gala
@ 2011-07-28 6:09 ` Saul Wold
2011-07-28 7:48 ` Cui, Dexuan
0 siblings, 1 reply; 92+ messages in thread
From: Saul Wold @ 2011-07-28 6:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On 07/27/2011 10:25 PM, Kumar Gala wrote:
> For some reason when I get to do_rootfs for core-image-sato when using rpms I run into an issue in that:
>
> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>
> Isn't expanding or taking the assignment in meta/conf/machine/include/tune-ppcFOO.inc but just using what it found in meta/conf/bitbake.conf
>
> the tune-ppcFOO.inc looks like:
>
> DEFAULTTUNE ?= "ppce5500"
>
> require conf/machine/include/powerpc/arch-powerpc64.inc
>
> TUNEVALID[ppce5500] = "Enable ppce5500 specific processor optimizations"
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "-mcpu=e5500", "", d)}"
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "ppce5500", "ppce5500", "", d)}"
>
> AVAILTUNES += "ppce5500"
> TUNE_FEATURES_tune-ppce5500 = "m64 hard-fpu ppce5500"
> PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "powerpc64 ppce5500"
>
> any ideas?
>
I believe that I am seeing this also with an atom-pc build, where the
PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
list of ARCHS that includes core2 (which atom-pc should be).
I am looking into this issue.
Sau!
> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 17:19 ` Mark Hatle
2011-07-27 19:31 ` Phil Blundell
@ 2011-07-28 7:24 ` Martin Jansa
2011-07-28 8:54 ` Phil Blundell
2011-07-29 6:41 ` Khem Raj
2 siblings, 1 reply; 92+ messages in thread
From: Martin Jansa @ 2011-07-28 7:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 5547 bytes --]
On Wed, Jul 27, 2011 at 12:19:22PM -0500, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> >
> > Ah, I see. Does that go for v4t too? I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
>
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
>
> Say you want all of your system thumb, except for a few specific programs..
>
> TUNENAME = "armv4t"
>
> TUNENAME_pn-mysql = "armv4"
>
> In the opposite case, where you want everything ARM, except for a few thumb:
>
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
>
> PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}
We've discussed this yesterday on #yocto and there is problem with this
Before tune-* overhaul we had ARM_INSTRUCTION_SET option to force arm
mode from recipe even for architectures supporting thumb (ie armv4t).
Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
switched to "armv4" only to indicate that.
But ARM_INSTRUCTION_SET worked for all ARM architectures, but now I
would need to set
TUNENAME_pn-eglibc = "armv4" in openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc
TUNENAME_pn-eglibc = "armv5" in openembedded-core/meta/conf/machine/include/arm/arch-armv5.inc
TUNENAME_pn-eglibc = "armv6" in openembedded-core/meta/conf/machine/include/arm/arch-armv6.inc
TUNENAME_pn-eglibc = "armv7" in openembedded-core/meta/conf/machine/include/arm/arch-armv7.inc
etc.. because I cannot disable thumb (while keeping thumb-interwork
enabled) from recipe globally for all as
openembedded-core/meta/conf/machine/include/tune-thumb.inc
does, but that's not used and
ARM_THUMB_M_OPT = "${@['-mno-thumb','-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
is not respected anymore in
openembedded-core/meta/conf/machine/include/arm/feature-arm-thumb.inc
ARM_INSTRUCTION_SET = "arm" is used in some recipes because with thumb
enabled it fails to build and maybe such recipes can be fixed
(ie eglibc now fails for armv4t and armv7a)
and for some recipes it's set because it's producing faster code (where
binary size was more important).
Another problem with setting TUNENAME_pn-foo for every arch is when
foo_1.0.bb is in some obscure layer somewhere and maintainer of that
layer would need to alter all arch-armv[4567]*.inc files to keep foo
from using thumb. Maybe something like this in recipe should work?
TUNENAME_pn-eglibc_armv4t = "armv4"
TUNENAME_pn-eglibc_armv5t = "armv5"
And scale of ARM_INSTRUCTION_SET now ignored with oe-core:
OE om-gta02@shr ~/shr-core/openembedded-core $ git grep ARM_INSTRUCTION_SET
meta/classes/qt4e.bbclass:ARM_INSTRUCTION_SET = "arm"
meta/classes/qt4x11.bbclass:ARM_INSTRUCTION_SET = "arm"
meta/conf/machine/include/tune-thumb.inc:ARM_INSTRUCTION_SET ?= "arm"
meta/conf/machine/include/tune-thumb.inc:OVERRIDE_THUMB = "${@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
meta/conf/machine/include/tune-thumb.inc:ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
meta/recipes-core/eglibc/eglibc.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glib-2.0/glib.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glibc/glibc.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glibc/glibc_2.10.1.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/uclibc/uclibc.inc: ${@["","s,.*COMPILE_IN_THUMB_MODE.*,COMPILE_IN_THUMB_MODE=y,;"][bb.data.getVar("ARM_INSTRUCTION_SET", d, 1) != "arm"]} \
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/tremor/tremor_20101121.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-qt/qt4/qt4_arch.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/boost/boost-36.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/gmp/gmp.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/libgcrypt/libgcrypt.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/liboil/liboil_0.3.17.bb:ARM_INSTRUCTION_SET = "arm"
OE om-gta02@shr ~/shr-core/meta-openembedded $ git grep ARM_INSTRUCTION_SET
meta-efl/classes/e-base.bbclass:ARM_INSTRUCTION_SET = "arm"
meta-efl/recipes-efl/webkit/webkit-efl_svn.bb:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-core/glib-2.0/glib.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-devtools/gcc/gcc-4.5.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-devtools/gcc/gcc-common-4.6.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-support/postgresql/postgresql.inc:ARM_INSTRUCTION_SET = "arm"
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 6:09 ` Saul Wold
@ 2011-07-28 7:48 ` Cui, Dexuan
2011-07-28 8:47 ` Paul Eggleton
0 siblings, 1 reply; 92+ messages in thread
From: Cui, Dexuan @ 2011-07-28 7:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Saul Wold wrote on 2011-07-28:
> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>> For some reason when I get to do_rootfs for core-image-sato when using
>> rpms I run into an issue in that:
>>
>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>>
>> Isn't expanding or taking the assignment in
>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>> found in meta/conf/bitbake.conf
>>
> I believe that I am seeing this also with an atom-pc build, where the
> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> list of ARCHS that includes core2 (which atom-pc should be).
Hi, I'm suffering from the exactly same issue... :-(
I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending yet.
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 7:48 ` Cui, Dexuan
@ 2011-07-28 8:47 ` Paul Eggleton
2011-07-28 8:57 ` Koen Kooi
0 siblings, 1 reply; 92+ messages in thread
From: Paul Eggleton @ 2011-07-28 8:47 UTC (permalink / raw)
To: openembedded-core
On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
> Saul Wold wrote on 2011-07-28:
> > On 07/27/2011 10:25 PM, Kumar Gala wrote:
> >> For some reason when I get to do_rootfs for core-image-sato when using
> >> rpms I run into an issue in that:
> >>
> >> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> >>
> >> Isn't expanding or taking the assignment in
> >> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
> >> found in meta/conf/bitbake.conf
> >
> > I believe that I am seeing this also with an atom-pc build, where the
> > PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> > list of ARCHS that includes core2 (which atom-pc should be).
>
> Hi, I'm suffering from the exactly same issue... :-(
> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
> yet.
It seems to me that ??= gets confused because the variable name needs
expanding. If you change the ${DEFAULTTUNE} reference to core2 in
PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I
don't know if that indicates a BitBake bug or whether we should try to work
around it.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-28 7:24 ` Martin Jansa
@ 2011-07-28 8:54 ` Phil Blundell
2011-07-28 18:17 ` Martin Jansa
0 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-28 8:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
> Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
> no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
> switched to "armv4" only to indicate that.
No, this is wrong. Even with ARM_INSTRUCTION_SET = "arm" you might have
BX instructions in the output, in which case "armv4t" is the correct
PACKAGE_ARCH. You can only set PACKAGE_ARCH = "armv4" if all the BXs
have been suppressed, which means that you lose the ability to do
interworking.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 8:47 ` Paul Eggleton
@ 2011-07-28 8:57 ` Koen Kooi
2011-07-28 9:20 ` Phil Blundell
0 siblings, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-28 8:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
> On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
>> Saul Wold wrote on 2011-07-28:
>>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>>>> For some reason when I get to do_rootfs for core-image-sato when using
>>>> rpms I run into an issue in that:
>>>>
>>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>>>>
>>>> Isn't expanding or taking the assignment in
>>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>>>> found in meta/conf/bitbake.conf
>>>
>>> I believe that I am seeing this also with an atom-pc build, where the
>>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
>>> list of ARCHS that includes core2 (which atom-pc should be).
>>
>> Hi, I'm suffering from the exactly same issue... :-(
>> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
>> yet.
>
> It seems to me that ??= gets confused because the variable name needs
> expanding. If you change the ${DEFAULTTUNE} reference to core2 in
> PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I
> don't know if that indicates a BitBake bug or whether we should try to work
> around it.
I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
# PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
PACKAGE_EXTRA_ARCHS="arm"
regards,
Koen
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 8:57 ` Koen Kooi
@ 2011-07-28 9:20 ` Phil Blundell
2011-07-28 10:00 ` Koen Kooi
0 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-28 9:20 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
>
> > On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
> >> Saul Wold wrote on 2011-07-28:
> >>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
> >>>> For some reason when I get to do_rootfs for core-image-sato when using
> >>>> rpms I run into an issue in that:
> >>>>
> >>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> >>>>
> >>>> Isn't expanding or taking the assignment in
> >>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
> >>>> found in meta/conf/bitbake.conf
> >>>
> >>> I believe that I am seeing this also with an atom-pc build, where the
> >>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
> >>> list of ARCHS that includes core2 (which atom-pc should be).
> >>
> >> Hi, I'm suffering from the exactly same issue... :-(
> >> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
> >> yet.
> >
> > It seems to me that ??= gets confused because the variable name needs
> > expanding. If you change the ${DEFAULTTUNE} reference to core2 in
> > PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I
> > don't know if that indicates a BitBake bug or whether we should try to work
> > around it.
>
> I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
>
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
>
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
> PACKAGE_EXTRA_ARCHS="arm"
No, I think Paul is right about the cause (though I don't agree with him
that it is a bug exactly). The timing of anonymous python oughtn't to
be different in those two cases so I don't think that will be making a
difference.
That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
bitbake.conf is just fundamentally bogus. As far as the bitbake parser
is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
both of them. Then, later, when the lvalues get expanded the latter
will be overwritten by the former which seems like it is exactly the
opposite to the effect that's wanted here.
This is long-standing bitbake behaviour and I'm not sure it would be
practical to change. I think the metadata just needs to be written to
work with the semantics that we have.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 9:20 ` Phil Blundell
@ 2011-07-28 10:00 ` Koen Kooi
2011-07-28 10:03 ` Phil Blundell
0 siblings, 1 reply; 92+ messages in thread
From: Koen Kooi @ 2011-07-28 10:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 28 jul. 2011, om 11:20 heeft Phil Blundell het volgende geschreven:
> On Thu, 2011-07-28 at 10:57 +0200, Koen Kooi wrote:
>> Op 28 jul. 2011, om 10:47 heeft Paul Eggleton het volgende geschreven:
>>
>>> On Thursday 28 July 2011 08:48:43 Cui, Dexuan wrote:
>>>> Saul Wold wrote on 2011-07-28:
>>>>> On 07/27/2011 10:25 PM, Kumar Gala wrote:
>>>>>> For some reason when I get to do_rootfs for core-image-sato when using
>>>>>> rpms I run into an issue in that:
>>>>>>
>>>>>> ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>>>>>>
>>>>>> Isn't expanding or taking the assignment in
>>>>>> meta/conf/machine/include/tune-ppcFOO.inc but just using what it
>>>>>> found in meta/conf/bitbake.conf
>>>>>
>>>>> I believe that I am seeing this also with an atom-pc build, where the
>>>>> PACKAGE_EXTRA_ARCHS seems OK, but ends up just being i586 instead of a
>>>>> list of ARCHS that includes core2 (which atom-pc should be).
>>>>
>>>> Hi, I'm suffering from the exactly same issue... :-(
>>>> I don't know why PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} isn't expending
>>>> yet.
>>>
>>> It seems to me that ??= gets confused because the variable name needs
>>> expanding. If you change the ${DEFAULTTUNE} reference to core2 in
>>> PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}" it all works. I
>>> don't know if that indicates a BitBake bug or whether we should try to work
>>> around it.
>>
>> I think it has to do with when the anonymous python runs. Try comparing 'bitbake -e' and and 'bitbake -e some-image':
>>
>> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e | grep PACKAGE_EXTRA_ARCHS\=
>> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>> PACKAGE_EXTRA_ARCHS="arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon"
>>
>> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ bitbake -e efl-nodm-image | grep PACKAGE_EXTRA_ARCHS\=
>> # PACKAGE_EXTRA_ARCHS=${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
>> PACKAGE_EXTRA_ARCHS="arm"
>
> No, I think Paul is right about the cause (though I don't agree with him
> that it is a bug exactly). The timing of anonymous python oughtn't to
> be different in those two cases so I don't think that will be making a
> difference.
>
> That assignment to PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in
> bitbake.conf is just fundamentally bogus. As far as the bitbake parser
> is concerned, PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} and
> PACKAGE_EXTRA_ARCHS_tune-arm926ejs are different variables (assuming
> DEFAULTTUNE=arm926ejs for the sake of an example) and it will create
> both of them. Then, later, when the lvalues get expanded the latter
> will be overwritten by the former which seems like it is exactly the
> opposite to the effect that's wanted here.
>
> This is long-standing bitbake behaviour and I'm not sure it would be
> practical to change. I think the metadata just needs to be written to
> work with the semantics that we have.
Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me again, is that an acceptable solution?
regards,
Koen
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: Add basic PowerPC core tune config (bug?)
2011-07-28 10:00 ` Koen Kooi
@ 2011-07-28 10:03 ` Phil Blundell
0 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-28 10:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 12:00 +0200, Koen Kooi wrote:
> Removing the PACKAGE_EXTRA_ARCHS line from bitbake.conf makes it work for me again, is that an acceptable solution?
Sounds about right to me. If ${TARGET_ARCH} really does need to go into
PACKAGE_EXTRA_ARCHS by default (which sounds implausible to me) then
we'll have to find some other way to achieve that.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
` (3 preceding siblings ...)
2011-07-27 17:31 ` do_rootfs broken, was: " Koen Kooi
@ 2011-07-28 11:39 ` Phil Blundell
2011-07-29 5:59 ` Khem Raj
5 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-28 11:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2011-07-27 at 15:34 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
>
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will get a mixture of big and little endian in there.
I think the equivalent big-endian definitions for v5 and v6 have this
problem too. For example:
PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
seems wrongish to me.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-28 8:54 ` Phil Blundell
@ 2011-07-28 18:17 ` Martin Jansa
0 siblings, 0 replies; 92+ messages in thread
From: Martin Jansa @ 2011-07-28 18:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Thu, Jul 28, 2011 at 09:54:06AM +0100, Phil Blundell wrote:
> On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
> > Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
> > no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
> > switched to "armv4" only to indicate that.
>
> No, this is wrong. Even with ARM_INSTRUCTION_SET = "arm" you might have
> BX instructions in the output, in which case "armv4t" is the correct
> PACKAGE_ARCH. You can only set PACKAGE_ARCH = "armv4" if all the BXs
> have been suppressed, which means that you lose the ability to do
> interworking.
Ah right, we cannot allow this to be in ie collie feed. So old behavior
was correct in this aspect too.
Thanks
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
` (4 preceding siblings ...)
2011-07-28 11:39 ` Phil Blundell
@ 2011-07-29 5:59 ` Khem Raj
2011-07-29 7:25 ` Phil Blundell
5 siblings, 1 reply; 92+ messages in thread
From: Khem Raj @ 2011-07-29 5:59 UTC (permalink / raw)
To: openembedded-core
Hi Mark,Richard
currently qemuarm does not build due to this patch forcing thumb mode
as default for all 't' architectures which could have worked if recipes
using ARM_INSTRUCTION_SET="arm" in them were somehow excluded from
building in thumb mode. Further comments are inline.
On 07/26/2011 05:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie<richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/arm/arch-arm.inc | 16 +++++-
> meta/conf/machine/include/arm/arch-armv4.inc | 24 +++++++++
> meta/conf/machine/include/arm/arch-armv5-dsp.inc | 40 ++++++++++++++
> meta/conf/machine/include/arm/arch-armv5.inc | 51 ++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv6.inc | 32 +++++++++++
> meta/conf/machine/include/arm/arch-armv7.inc | 55 ++++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv7a.inc | 54 +++++++++++++++++++
> meta/conf/machine/include/arm/feature-arm-neon.inc | 3 +
> .../conf/machine/include/arm/feature-arm-thumb.inc | 25 +++++++++
> meta/conf/machine/include/arm/feature-arm-vfp.inc | 6 ++
> meta/conf/machine/include/tune-arm1136jf-s.inc | 14 +++---
> meta/conf/machine/include/tune-arm920t.inc | 14 ++++--
> meta/conf/machine/include/tune-arm926ejs.inc | 18 ++++---
> meta/conf/machine/include/tune-arm9tdmi.inc | 14 ++++--
> meta/conf/machine/include/tune-armv7.inc | 8 +---
> meta/conf/machine/include/tune-cortexa8.inc | 21 ++++----
> meta/conf/machine/include/tune-cortexm1.inc | 13 ++++-
> meta/conf/machine/include/tune-cortexm3.inc | 18 +++++--
> meta/conf/machine/include/tune-cortexr4.inc | 18 +++++--
> meta/conf/machine/include/tune-ep9312.inc | 16 ++++--
> meta/conf/machine/include/tune-iwmmxt.inc | 18 +++++--
> meta/conf/machine/include/tune-strongarm1100.inc | 13 +++--
> meta/conf/machine/include/tune-xscale.inc | 18 ++++--
> 23 files changed, 435 insertions(+), 74 deletions(-)
> create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
> index c517df6..4ea8b2b 100644
> --- a/meta/conf/machine/include/arm/arch-arm.inc
> +++ b/meta/conf/machine/include/arm/arch-arm.inc
> @@ -1,3 +1,17 @@
> -TUNE_ARCH = "arm"
> +
> +TUNEVALID[bigendian] = "Enable big-endian mode."
> +
> +ARMPKGARCH ??= "arm"
> +ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
> +ARMPKGSFX_FPU ??= ""
> +ARMPKGSFX_DSP ??= ""
> +ARMPKGSFX_EABI ??= ""
> +ARMPKGSFX_THUMB ??= ""
> +
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
> +TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
>
> ABIEXTENSION = "eabi"
> +
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
> new file mode 100644
> index 0000000..c014d20
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> @@ -0,0 +1,24 @@
> +DEFAULTTUNE ?= "armv4"
> +
> +ARMPKGARCH ?= "armv4"
> +
> +TUNEVALID[armv4] = "Enable instructions for ARMv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
> +
> +require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/feature-arm-thumb.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv4 armv4t"
> +TUNE_FEATURES_tune-armv4 ?= "armv4"
> +TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
this here means we want to generate thumb code by default if one uses
ARMv4t core. Which is ok but find out all the recipes thats using
ARM_INSTRUCTION_SET = arm at present and we have to have a way to
exclude them. I think having them specified here with some override
is not good since it will mean that if some layer has a recipe which can
not be compiled in thumb mode has to have an entry here.
Is it possible to filter out a given TUNE_FEATURE inside a recipe ?
> +PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
> +PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
> +
> +# Big Endian
> +AVAILTUNES += "armv4b armv4tb"
> +TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
> +TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> new file mode 100644
> index 0000000..498a012
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
> +TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
> +TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
> +TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5eb armv5teb"
> +TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
> +TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
> +TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +DEFAULTTUNE ?= "armv5"
> +
> +ARMPKGARCH ?= "armv5"
> +
> +TUNEVALID[armv5] = "Enable instructions for ARMv5"
> +TUNE_CONFLICTS[armv5] = "armv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
> +
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +require conf/machine/include/arm/feature-arm-vfp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> +TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5b armv5tb"
> +TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
> +TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
> +TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
> +
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
> new file mode 100644
> index 0000000..20924c9
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> @@ -0,0 +1,32 @@
> +DEFAULTTUNE ?= "armv6"
> +
> +ARMPKGARCH ?= "armv6"
> +
> +TUNEVALID[armv6] = "Enable instructions for ARMv6"
> +TUNE_CONFLICTS[armv6] = "armv4 armv5"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
> +TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
> +TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
so it seems any achitecture that supports thumb we resport to thumb
intruction set. I dont think thats what we want. We should be able to
select the intruction set on architectures where choice is available
e.g. on armv5t we can use arm or thumb but on armv5 there is no choice
so we have to use arm. and cortex-m3 we have to use thumb2 there is no
other choice etc.
> +TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
> +TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
> +TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
> +TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
> new file mode 100644
> index 0000000..8bc8d10
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7.inc
> @@ -0,0 +1,55 @@
> +DEFAULTTUNE ?= "armv7"
> +
> +ARMPKGARCH ?= "armv7"
> +
> +TUNEVALID[armv7] = "Enable instructions for ARMv7"
> +TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv6.inc
> +require conf/machine/include/arm/feature-arm-neon.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
> +TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
> +TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
> +TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
> +TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
> +TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
> +TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
> +TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
> +TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
> +TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> new file mode 100644
> index 0000000..ce9cee5
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -0,0 +1,54 @@
> +DEFAULTTUNE ?= "armv7a"
> +
> +ARMPKGARCH ?= "armv7a"
> +
> +TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
> +TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv7.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
> +TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
> +TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
> +TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
> +TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
> +TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
> +TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
> +TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
> +TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
> +TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
> new file mode 100644
> index 0000000..a7dac03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
> @@ -0,0 +1,3 @@
> +TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> new file mode 100644
> index 0000000..9a607c6
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -0,0 +1,25 @@
> +# 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.
> +TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
it seems thumb being present in TUNE_FEATURES is meant for generating
thumb code. Which is fine however all packages currently can not be
compiled in thumb mode for various reasons. Most important of all is
eglibc/glibc. It can be compiled in thumb2 but not thumb1 so While we
would like to generate as much thumb as possible its not possible to
compile everything in thumb. So we had ARM_INSTRUCTION_SET which was
used to configure intruction set at recipe level. How do we do that with
this new tune infra ?
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
> +
> +# Note armv7 will hit on armv7a as well
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> +
> +# 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.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
> +
> +TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
> diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> new file mode 100644
> index 0000000..29a925c
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> @@ -0,0 +1,6 @@
> +TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
> +
> +TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
> index 953f0dd..4f4a2eb 100644
> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc
> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
> @@ -1,10 +1,10 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm1136jfs"
>
> -TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
> -TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
> -TUNE_PKGARCH = "armv6"
> +require conf/machine/include/arm/arch-armv6.inc
>
> -ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
> +TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
>
> -require conf/machine/include/tune-thumb.inc
> +AVAILTUNES += "arm1136jfs"
> +TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
> +PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
> index 6c87026..b7584ab 100644
> --- a/meta/conf/machine/include/tune-arm920t.inc
> +++ b/meta/conf/machine/include/tune-arm920t.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm920t"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
> +
> +AVAILTUNES += "arm920t"
here I guess we have to say AVAILTUNES += "arm920t arm920"
where arm920 is arm mode and 920t is thumb mode. but anyway I would
prefer that thumb is optionally added provided user asked for it
through DISTRO/MACHINE features then we should first make sure
that selected machine has thumb feature and if yes for both then we
should enable -mthumb compiler option which now it enable when thumb
appears in TUNE_FEATURES
> +TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
> +PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>
> -TUNE_PKGARCH = "armv4t"
> -TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
> index 543ab62..7f2cc4e 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -1,9 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> -TUNE_PKGARCH = "armv5te"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
> -# For gcc 3.x you need:
> -#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
> -# For gcc 4.x you need:
> -TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
> +DEFAULTTUNE ?= "arm926ejs"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
> +
> +AVAILTUNES += "arm926ejs"
> +TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>
> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
> index f1001ac..0dc5c26 100644
> --- a/meta/conf/machine/include/tune-arm9tdmi.inc
> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm9tdmi"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
> +
> +AVAILTUNES += "arm9tdmi"
> +TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
> +PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>
> -TUNE_PKGARCH = "armv4t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> -TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
> index 8a68c0a..664c24b 100644
> --- a/meta/conf/machine/include/tune-armv7.inc
> +++ b/meta/conf/machine/include/tune-armv7.inc
> @@ -1,8 +1,2 @@
> -require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/arch-armv7.inc
>
> -# 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
> -TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index ae50954..b07add4 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,15 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexa8-neon"
>
> +require conf/machine/include/arm/arch-armv7a.inc
>
> -# 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
> -# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
> +TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
>
> -TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
> +AVAILTUNES += "cortexa8 cortexa8t"
> +TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
> +TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
> +TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
>
> -# Other potentially useful options
> -#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
>
> -TUNE_PKGARCH = "armv7a"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
> diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
> index b944db4..493025d 100644
> --- a/meta/conf/machine/include/tune-cortexm1.inc
> +++ b/meta/conf/machine/include/tune-cortexm1.inc
> @@ -1,4 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm1"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
> +
> +AVAILTUNES += "cortexm1"
> +TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
>
> -TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv6"
> diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
> index a77cbdd..f774fa6 100644
> --- a/meta/conf/machine/include/tune-cortexm3.inc
> +++ b/meta/conf/machine/include/tune-cortexm3.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm3"
> +ARMPKGARCH ?= "armv7m"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
> +
> +TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexm3"
> +TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
>
> -# valid options for -march: `armv7', `armv7-m'
> -TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
> index c9193ca..738f5af 100644
> --- a/meta/conf/machine/include/tune-cortexr4.inc
> +++ b/meta/conf/machine/include/tune-cortexr4.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexr4"
> +ARMPKGARCH ?= "armv7r"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
> +
> +TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexr4"
> +TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
> +PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
>
> -# valid options for -march: `armv7', `armv7-r'
> -TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
> index e04a00a..f10123f 100644
> --- a/meta/conf/machine/include/tune-ep9312.inc
> +++ b/meta/conf/machine/include/tune-ep9312.inc
> @@ -1,9 +1,13 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "ep9312"
> +ARMPKGARCH ?= "ep9312"
>
> -TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
> -# add "-mfp=maverick" for newer gcc versions> 4.0
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
> +
> +AVAILTUNES += "ep9312"
> +TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
> +PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
>
> -#set arch to ep9312 for all generated packages
> -PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
> -TUNE_PKGARCH = "ep9312"
>
> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
> index 6bb76d5..14f5955 100644
> --- a/meta/conf/machine/include/tune-iwmmxt.inc
> +++ b/meta/conf/machine/include/tune-iwmmxt.inc
> @@ -1,8 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> # Configurations for the Intel PXA27x Appications Processor Family.
> # Please use tune-xscale for PXA255/PXA26x based processors.
> -TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
> -TUNE_PKGARCH = "iwmmxt"
> +
> +DEFAULTTUNE ?= "iwmmxt"
> +ARMPKGARCH ?= "iwmmxt"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
> +
> +AVAILTUNES += "iwmmxt"
> +TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
> +PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
> +
>
> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
> index 2b76069..66bab8e 100644
> --- a/meta/conf/machine/include/tune-strongarm1100.inc
> +++ b/meta/conf/machine/include/tune-strongarm1100.inc
> @@ -1,9 +1,12 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "strongarm"
>
> -TUNE_PKGARCH = "arm"
> +require conf/machine/include/arm/arch-armv4.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
> +TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
> +
> +AVAILTUNES += "strongarm"
> +TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
> +PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
>
> -TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
>
> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
> index 71dba5b..0303320 100644
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
>
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
>
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>
> # webkit-gtk has alignment issues with double instructions on armv5 so
> # disable them here
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 13:33 ` Richard Purdie
2011-07-27 14:27 ` Mark Hatle
@ 2011-07-29 6:08 ` Khem Raj
2011-07-29 6:47 ` Phil Blundell
2011-07-29 6:51 ` Khem Raj
1 sibling, 2 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:08 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 06:33 AM, Richard Purdie wrote:
> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>
>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>> variable and then the package suffix be computed from that, rather than
>> vice versa?
>
> It's been "fun" to use the rather limited constructs we have in these
> variables to construct the end result. I suspect this way around, it was
> the easiest way to get the right variables in the right places.
>
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>
>> This is wrong: ARMv6 doesn't imply Thumb-2.
>
> Ah, yes. I'll fix this.
>
>>> +# 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.
>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>
>> This is only relevant for v4t, I guess. Interworking is basically
>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>> hardly anybody is going to be flipping this switch. I'm not sure it
>> really merits an OVERRIDE.
>
> I'd be happy to remove this option if there are no objections. It was
> left for compatibility with the existing tune-thumb file but as you say,
> it likely doesn't make much sense.
I know SHR uses armv4t but I dont know of armv4 usecases. May be we
could may armv4t as oldest supported arm arch and leave armv4 out.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:44 ` Phil Blundell
2011-07-27 14:55 ` Mark Hatle
@ 2011-07-29 6:18 ` Khem Raj
2011-07-29 7:15 ` Phil Blundell
1 sibling, 1 reply; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:18 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 07:44 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
>> were thumb(1). Note, not all ARMv6 processors contain thumb support.
>
> It is true that all ARMv4T and ARMv5T processors are only Thumb-1. It's
> also true that Thumb-2 was first implemented in ARM1156, which is an
> ARMv6 core. But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
> and all three of those are Thumb-1 only. Given that nobody is likely to
> target ARM1156 with OE, it's probably a reasonable approximation to say
> that Thumb-2 correlates with ARMv7 and later.
>
> Also, since there are no v5, v6 or v7 cores which don't support Thumb,
cortex-m series supports only thumb2 intsruction set. I am not sure if
thumb2 alone is a superset of thumb1 iow thumb1 programs could be
executed on cortex-m series or not. Never had a cortex-m so I am not sure.
> the "t" suffix serves no useful purpose here and might as well just be
> omitted. That is, there is no CPU which can run "armv6" packages which
> wouldn't also be able to run "armv6t".
>
>> In the original work I did it was just tune-xscale (no be). AFAIK there is no
>> little endian version of xscale.
>
> No, that's incorrect. The PXA25x series and IXP420, at least, are
> bi-endian (and I suspect most of the other XScales are too) and there
> are certainly folks running them in little endian configurations.
nslu2 which uses xscale has both be and le versions of SlugOS
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:49 ` Mark Hatle
2011-07-27 14:57 ` Phil Blundell
@ 2011-07-29 6:20 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:20 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 07:49 AM, Mark Hatle wrote:
> On 7/27/11 9:33 AM, Koen Kooi wrote:
>>
>> Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
>>
>>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>>
>>>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>>>> variable and then the package suffix be computed from that, rather than
>>>>> vice versa?
>>>>
>>>> It's been "fun" to use the rather limited constructs we have in these
>>>> variables to construct the end result. I suspect this way around, it was
>>>> the easiest way to get the right variables in the right places.
>>>>
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>>
>>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>>
>>>> Ah, yes. I'll fix this.
>>>
>>> Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
>>> were thumb(1). Note, not all ARMv6 processors contain thumb support.
>>
>> As I understand it:
>>
>> arm1136 doesn't have t2
>> arm1176 does have t2
>>
>> both are armv6 :)
>
> They also don't have "thumb" support either. So armv6& thumb == t2.
>
>>>
>>>>>> +# 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.
>>>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>>>
>>>>> This is only relevant for v4t, I guess. Interworking is basically
>>>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>>>> hardly anybody is going to be flipping this switch. I'm not sure it
>>>>> really merits an OVERRIDE.
>>>>
>>>> I'd be happy to remove this option if there are no objections. It was
>>>> left for compatibility with the existing tune-thumb file but as you say,
>>>> it likely doesn't make much sense.
>>>>
>>>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>>>> @@ -1,11 +1,17 @@
>>>>>> -require conf/machine/include/arm/arch-arm.inc
>>>>>> +DEFAULTTUNE ?= "xscale"
>>>>>>
>>>>>> -INHERIT += "siteinfo"
>>>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>>>>
>>>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>>>> +
>>>>>> +AVAILTUNES += "xscale"
>>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>>>> +
>>>>>> +AVAILTUNES += "xscale-be"
>>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>>>>
>>>>> I guess that should be "_tune-xscale-be".
>>>>
>>>> Yes, I'll fix, well spotted.
>>>
>>> In the original work I did it was just tune-xscale (no be). AFAIK there is no
>>> little endian version of xscale. (there was an iwmmxt that was similar to
>>> xscale, but was slightly different.)
>>
>> pxa25x are LE xscales (e.g. Palm Treo)
>> pxa26x are LE xscales with some NAND builtin
>> pxa27x are LE xscales with iwmmxt as an extra
>
> All thought all of those were considered to me iwmmxt cores. The whole PXA
> series naming is very confusing to say the least.
>
arm cores support both endians equally well. Its the usecases we have on
OE are little endian.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 14:58 ` Mark Hatle
2011-07-27 15:25 ` Phil Blundell
@ 2011-07-29 6:27 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:27 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 07:58 AM, Mark Hatle wrote:
> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> means I was thumb instructions.
>
> So armv5 and armv5t are distinct in the contents of the tunings.
fwiw its confusing since armv5t will be confused with arm architecture
context where it means 'yes I have thumb and you can use it if you want'
but what you are saying here is that if its armv5t then it means 'arm
v5t and yes use thumb' It should be called something else probably to
make that distinction
>
> There were armv5's without thumb support.. but that doesn't matter much. A
> machine with thumb is compatible (run-time) with one that does not. A machine
> w/o thumb is not necessarily compatible with thumb executables.
>
>>> >> +# Little Endian + VFP/DSP
>>> >> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
>> >
>> > The comment doesn't seem to match the code here since this is the
>> > section for chips without DSP. Incidentally, the name "dsp" for this
>> > feature seems quite a bad one: maybe we should just call it "armv5e".
> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
> the "dsp" capabilities actually change any of the code or support generated. If
> not then we can ignore it.
>
> For armv5 this gives us:
>
> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> EABI...
>
> --Mark
>
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:08 ` Phil Blundell
2011-07-27 15:13 ` Koen Kooi
@ 2011-07-29 6:31 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:31 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 08:08 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
>> the s3c6410 is arm1176 which should support T2. Having said that, I'm not sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
>
> What makes you think that ARM1176 has T2? I haven't actually tried
> executing Thumb-2 on one, but my recollection is definitely that it was
> Thumb-1 only.
>
I recollect it was t1 only too.
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 15:25 ` Phil Blundell
2011-07-27 15:29 ` Richard Purdie
2011-07-27 17:19 ` Mark Hatle
@ 2011-07-29 6:38 ` Khem Raj
2011-07-29 7:13 ` Phil Blundell
2 siblings, 1 reply; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:38 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 08:25 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
>> means I was thumb instructions.
>>
>> So armv5 and armv5t are distinct in the contents of the tunings.
>
> Ah, I see. Does that go for v4t too? I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
>> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
>> the "dsp" capabilities actually change any of the code or support generated. If
>> not then we can ignore it.
>
> Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch(). I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.
LDRD/STRD which are armv5e only are used by gcc IIRC
>
>> For armv5 this gives us:
>>
>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>> EABI...
>
> Does anybody really want the hardfloat abi on armv5? I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-27 17:19 ` Mark Hatle
2011-07-27 19:31 ` Phil Blundell
2011-07-28 7:24 ` Martin Jansa
@ 2011-07-29 6:41 ` Khem Raj
2 siblings, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:41 UTC (permalink / raw)
To: openembedded-core
On 07/27/2011 10:19 AM, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
>>> means I was thumb instructions.
>>>
>>> So armv5 and armv5t are distinct in the contents of the tunings.
>>
>> Ah, I see. Does that go for v4t too? I can imagine cases where you
>> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
>
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
>
> Say you want all of your system thumb, except for a few specific programs..
>
> TUNENAME = "armv4t"
>
> TUNENAME_pn-mysql = "armv4"
>
> In the opposite case, where you want everything ARM, except for a few thumb:
>
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
>
> PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}
>
> Second line ensures that the base armv7 tune inherits the "more complete" set of
> compatible machines.
>
> (Note, in most cases I would expect a machine/BSP configuration to do most of
> this inheriting... or if someone was being tricky they can do it manually.)
>>> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
>>> the "dsp" capabilities actually change any of the code or support generated. If
>>> not then we can ignore it.
>>
>> Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
>> will affect any code which uses __builtin_prefetch(). I don't think GCC
>> will ever open-code the saturating arithmetic instructions, but it does
>> expose the v5/v5e distinction through preprocessor macros and source
>> code might use that to select asm() statements which use those opcodes.
>
> So then the question is.. with OE-core and core based distros.. are there enough
> armv5 (w/ or w/o e) left to justify having both? If not.. then we select the
> one with the 'e' since it's more common.
>
>>> For armv5 this gives us:
>>>
>>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>>> EABI...
>>
>> Does anybody really want the hardfloat abi on armv5? I guess it doesn't
>> hurt all that much to offer it, but anything that makes that monstrous
>> set of .inc files bigger seems like a bad thing.
>
> I was surprised anyone wanted the hardfloat ABI at all.. :P ...but anyway... if
> it'll work on armv5 (and the previous question about is armv5 relevant answered)
> we can choose it or not.. It was there to be complete in the original
> version... (also armv5 w/ VFP is the lowest compatible machine for a HF
> implementation.)
>
hardfloat ABI may not work with VFP implementation which is on the armv5
cores it was designed around vfpv3
> --Mark
>
>> p.
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 6:08 ` Khem Raj
@ 2011-07-29 6:47 ` Phil Blundell
2011-07-29 6:51 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-29 6:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 23:08 -0700, Khem Raj wrote:
> I know SHR uses armv4t but I dont know of armv4 usecases. May be we
> could may armv4t as oldest supported arm arch and leave armv4 out.
There are definitely still folks using OE with SA1100 machines. I think
armv4 support should be kept unless there is a really compelling reason
to leave it out.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 6:08 ` Khem Raj
2011-07-29 6:47 ` Phil Blundell
@ 2011-07-29 6:51 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-07-29 6:51 UTC (permalink / raw)
To: openembedded-core
On 07/28/2011 11:08 PM, Khem Raj wrote:
> On 07/27/2011 06:33 AM, Richard Purdie wrote:
>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or
>>>> 'soft'}"
>>>
>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>> variable and then the package suffix be computed from that, rather than
>>> vice versa?
>>
>> It's been "fun" to use the rather limited constructs we have in these
>> variables to construct the end result. I suspect this way around, it was
>> the easiest way to get the right variables in the right places.
>>
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv4", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv5", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv6", "thumb" ], "t2", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv7", "thumb" ], "t2", "", d)}"
>>>
>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>
>> Ah, yes. I'll fix this.
>>
>>>> +# 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.
>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM
>>>> functions"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES",
>>>> "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES",
>>>> "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>
>>> This is only relevant for v4t, I guess. Interworking is basically
>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>> hardly anybody is going to be flipping this switch. I'm not sure it
>>> really merits an OVERRIDE.
>>
>> I'd be happy to remove this option if there are no objections. It was
>> left for compatibility with the existing tune-thumb file but as you say,
>> it likely doesn't make much sense.
>
>
> I know SHR uses armv4t but I dont know of armv4 usecases. May be we
> could may armv4t as oldest supported arm arch and leave armv4 out.
oh well how did I forget strongARM so yes dropping armv4 may not be so easy
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 6:38 ` Khem Raj
@ 2011-07-29 7:13 ` Phil Blundell
0 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-29 7:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 23:38 -0700, Khem Raj wrote:
> On 07/27/2011 08:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names.. armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> >
> > Ah, I see. Does that go for v4t too? I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
> >
> >> Yes, the mention of DSP should be using the 'e'. What I'm not sure of is does
> >> the "dsp" capabilities actually change any of the code or support generated. If
> >> not then we can ignore it.
> >
> > Yes. PLD, for example, is only available in ARMv5E (not ARMv5) and this
> > will affect any code which uses __builtin_prefetch(). I don't think GCC
> > will ever open-code the saturating arithmetic instructions, but it does
> > expose the v5/v5e distinction through preprocessor macros and source
> > code might use that to select asm() statements which use those opcodes.
>
> LDRD/STRD which are armv5e only are used by gcc IIRC
Ah yes, you're right. Those too.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 6:18 ` Khem Raj
@ 2011-07-29 7:15 ` Phil Blundell
0 siblings, 0 replies; 92+ messages in thread
From: Phil Blundell @ 2011-07-29 7:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 23:18 -0700, Khem Raj wrote:
> On 07/27/2011 07:44 AM, Phil Blundell wrote:
> cortex-m series supports only thumb2 intsruction set. I am not sure if
> thumb2 alone is a superset of thumb1 iow thumb1 programs could be
> executed on cortex-m series or not. Never had a cortex-m so I am not sure.
Yes, I believe any thumb-1 program will run on a thumb-2 core.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 5:59 ` Khem Raj
@ 2011-07-29 7:25 ` Phil Blundell
2011-07-29 8:22 ` Koen Kooi
0 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-07-29 7:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
> here I guess we have to say AVAILTUNES += "arm920t arm920"
> where arm920 is arm mode and 920t is thumb mode. but anyway I would
> prefer that thumb is optionally added provided user asked for it
> through DISTRO/MACHINE features then we should first make sure
> that selected machine has thumb feature and if yes for both then we
> should enable -mthumb compiler option which now it enable when thumb
> appears in TUNE_FEATURES
I don't think we want to go down the road of inventing CPU names for
ARM-state variants of Thumb-capable cores. (In other words, we
shouldn't start putting things like "arm920" in AVAILTUNES when there
isn't actually a core named arm920.)
Fundamentally I think you're right that the choice between ARM-state and
Thumb-state (for t1 at least) ought to be under the control of the
DISTRO and not selected purely on the basis of the hardware
capabilities. For t2 it is a bit less of a clear-cut issue but, if
there are genuinely people making ARMv7 cores with the Thumb decoder
removed, I guess we need to have that same switch there as well.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle
2011-07-29 7:25 ` Phil Blundell
@ 2011-07-29 8:22 ` Koen Kooi
0 siblings, 0 replies; 92+ messages in thread
From: Koen Kooi @ 2011-07-29 8:22 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Patches and discussions about the oe-core layer
Op 29 jul. 2011 om 09:25 heeft Phil Blundell <philb@gnu.org> het volgende geschreven:
> On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
>> here I guess we have to say AVAILTUNES += "arm920t arm920"
>> where arm920 is arm mode and 920t is thumb mode. but anyway I would
>> prefer that thumb is optionally added provided user asked for it
>> through DISTRO/MACHINE features then we should first make sure
>> that selected machine has thumb feature and if yes for both then we
>> should enable -mthumb compiler option which now it enable when thumb
>> appears in TUNE_FEATURES
>
> I don't think we want to go down the road of inventing CPU names for
> ARM-state variants of Thumb-capable cores. (In other words, we
> shouldn't start putting things like "arm920" in AVAILTUNES when there
> isn't actually a core named arm920.)
>
> Fundamentally I think you're right that the choice between ARM-state and
> Thumb-state (for t1 at least) ought to be under the control of the
> DISTRO and not selected purely on the basis of the hardware
> capabilities. For t2 it is a bit less of a clear-cut issue but, if
> there are genuinely people making ARMv7 cores with the Thumb decoder
> removed, I guess we need to have that same switch there as well
Another issue is silicon bugs on early a8 revisions, but gcc and linux might have enough workarounds nowadays
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
2011-07-26 14:41 ` Mark Hatle
2011-07-26 19:47 ` Khem Raj
@ 2011-08-11 11:25 ` Phil Blundell
2011-08-11 12:08 ` Richard Purdie
2011-08-11 15:54 ` Mark Hatle
2 siblings, 2 replies; 92+ messages in thread
From: Phil Blundell @ 2011-08-11 11:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> +# MIPS Architecture definition
> +# 12 defined ABIs, all combinations of:
> +# *) Big/Little Endian
> +# *) Hardware/Software Floating Point
> +# *) o32, n32, n64 ABI
> +
> +DEFAULTTUNE ?= "mips"
> +
> +# Endianess
> +TUNEVALID[bigendian] = "Enable big-endian mode"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d
I've just been trying to do a mips build for the first time since these
patches were landed and I'm a little bit unclear about what the "right"
way to declare endianness is nowadays.
The new tuning system has introduced the idea of endianness as an ABI
tune parameter and, by implication, if I don't have "bigendian" in
TUNE_FEATURES then presumably this is meant to mean little-endian.
However, there seem to be at least some places in OE which are still
expecting endianness to be encoded into TARGET_ARCH, i.e. a
little-endian system would be TARGET_ARCH=mipsel rather than mips.
Right now, building a little-endian MIPS32 doesn't seem to work either
way around. If I set TARGET_ARCH=mips and exclude bigendian from
TUNE_FEATURES then (among other issues) uclibc-config.inc decides that
my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
OVERRIDES and I end up with the wrong uClibc.machine and associated
-mips1 lossage.
That latter failure is at least relatively easy to work around and so
that's what I'm doing at the moment. But I don't know whether this is
the "right" way to proceed or whether TARGET_ARCH is expected to be
endian-agnostic in this newly tuned-up world.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 11:25 ` Phil Blundell
@ 2011-08-11 12:08 ` Richard Purdie
2011-08-11 12:29 ` Phil Blundell
2011-08-11 15:54 ` Mark Hatle
1 sibling, 1 reply; 92+ messages in thread
From: Richard Purdie @ 2011-08-11 12:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-08-11 at 12:25 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +# MIPS Architecture definition
> > +# 12 defined ABIs, all combinations of:
> > +# *) Big/Little Endian
> > +# *) Hardware/Software Floating Point
> > +# *) o32, n32, n64 ABI
> > +
> > +DEFAULTTUNE ?= "mips"
> > +
> > +# Endianess
> > +TUNEVALID[bigendian] = "Enable big-endian mode"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d
>
> I've just been trying to do a mips build for the first time since these
> patches were landed and I'm a little bit unclear about what the "right"
> way to declare endianness is nowadays.
>
> The new tuning system has introduced the idea of endianness as an ABI
> tune parameter and, by implication, if I don't have "bigendian" in
> TUNE_FEATURES then presumably this is meant to mean little-endian.
> However, there seem to be at least some places in OE which are still
> expecting endianness to be encoded into TARGET_ARCH, i.e. a
> little-endian system would be TARGET_ARCH=mipsel rather than mips.
>
> Right now, building a little-endian MIPS32 doesn't seem to work either
> way around. If I set TARGET_ARCH=mips and exclude bigendian from
> TUNE_FEATURES then (among other issues) uclibc-config.inc decides that
> my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
> Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
> OVERRIDES and I end up with the wrong uClibc.machine and associated
> -mips1 lossage.
>
> That latter failure is at least relatively easy to work around and so
> that's what I'm doing at the moment. But I don't know whether this is
> the "right" way to proceed or whether TARGET_ARCH is expected to be
> endian-agnostic in this newly tuned-up world.
You sound like you're doing this backwards. Pick a tune that either sets
TUNE_FEATURES to either contain or not contain "bigendian". TARGET_ARCH
then should get set appropriately and things that look at TARGET_ARCH
should work as before.
Ultimately we might want to consider if things like siteconfig should
use TUNE_FEATURES rather than TARGET_ARCH but it should work as things
stand now...
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 12:08 ` Richard Purdie
@ 2011-08-11 12:29 ` Phil Blundell
2011-08-11 14:28 ` Richard Purdie
2011-08-11 14:49 ` Khem Raj
0 siblings, 2 replies; 92+ messages in thread
From: Phil Blundell @ 2011-08-11 12:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> On Thu, 2011-08-11 at 12:25 +0100, Phil Blundell wrote:
> > On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > > +# MIPS Architecture definition
> > > +# 12 defined ABIs, all combinations of:
> > > +# *) Big/Little Endian
> > > +# *) Hardware/Software Floating Point
> > > +# *) o32, n32, n64 ABI
> > > +
> > > +DEFAULTTUNE ?= "mips"
> > > +
> > > +# Endianess
> > > +TUNEVALID[bigendian] = "Enable big-endian mode"
> > > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d
> >
> > I've just been trying to do a mips build for the first time since these
> > patches were landed and I'm a little bit unclear about what the "right"
> > way to declare endianness is nowadays.
> >
> > The new tuning system has introduced the idea of endianness as an ABI
> > tune parameter and, by implication, if I don't have "bigendian" in
> > TUNE_FEATURES then presumably this is meant to mean little-endian.
> > However, there seem to be at least some places in OE which are still
> > expecting endianness to be encoded into TARGET_ARCH, i.e. a
> > little-endian system would be TARGET_ARCH=mipsel rather than mips.
> >
> > Right now, building a little-endian MIPS32 doesn't seem to work either
> > way around. If I set TARGET_ARCH=mips and exclude bigendian from
> > TUNE_FEATURES then (among other issues) uclibc-config.inc decides that
> > my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
> > Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
> > OVERRIDES and I end up with the wrong uClibc.machine and associated
> > -mips1 lossage.
> >
> > That latter failure is at least relatively easy to work around and so
> > that's what I'm doing at the moment. But I don't know whether this is
> > the "right" way to proceed or whether TARGET_ARCH is expected to be
> > endian-agnostic in this newly tuned-up world.
>
> You sound like you're doing this backwards. Pick a tune that either sets
> TUNE_FEATURES to either contain or not contain "bigendian". TARGET_ARCH
> then should get set appropriately and things that look at TARGET_ARCH
> should work as before.
>
> Ultimately we might want to consider if things like siteconfig should
> use TUNE_FEATURES rather than TARGET_ARCH but it should work as things
> stand now...
Okay. So, if I let arch-mips.inc set TARGET_ARCH for itself then it
picks "mipsel", which is the second case I mentioned above and leads to
the -mips1 failure. I guess this means that either uclibc's usage of
overrides needs fixing, or arch-mips ought to be putting "mips" into
${OVERRIDES}.
More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
probably going to be fairly useless if that value now includes all the
decorations for ABI features, since it is going to be hard/impossible to
get it to match reliably.
Does the new tune model provide any variable which represents the
underlying CPU architecture ("arm", "mips")? That seems to be what's
really wanted in almost all the cases where TARGET_ARCH is being used as
an OVERRIDE.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 12:29 ` Phil Blundell
@ 2011-08-11 14:28 ` Richard Purdie
2011-08-11 14:49 ` Khem Raj
1 sibling, 0 replies; 92+ messages in thread
From: Richard Purdie @ 2011-08-11 14:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-08-11 at 13:29 +0100, Phil Blundell wrote:
> On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> > You sound like you're doing this backwards. Pick a tune that either sets
> > TUNE_FEATURES to either contain or not contain "bigendian". TARGET_ARCH
> > then should get set appropriately and things that look at TARGET_ARCH
> > should work as before.
> >
> > Ultimately we might want to consider if things like siteconfig should
> > use TUNE_FEATURES rather than TARGET_ARCH but it should work as things
> > stand now...
>
> Okay. So, if I let arch-mips.inc set TARGET_ARCH for itself then it
> picks "mipsel", which is the second case I mentioned above and leads to
> the -mips1 failure. I guess this means that either uclibc's usage of
> overrides needs fixing, or arch-mips ought to be putting "mips" into
> ${OVERRIDES}.
>
> More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
> probably going to be fairly useless if that value now includes all the
> decorations for ABI features, since it is going to be hard/impossible to
> get it to match reliably.
I don't think this is a new problem, its just being brought to the
surface with these changes.
> Does the new tune model provide any variable which represents the
> underlying CPU architecture ("arm", "mips")? That seems to be what's
> really wanted in almost all the cases where TARGET_ARCH is being used as
> an OVERRIDE.
Not currently but this does sound like a good idea.
The old approach to this was always ugly (was it i586 or i686 or x86? or
i386/i486 for that matter?). The arch/tune files provide a good place to
try and clean this up, cleaning up OVERRIDES for an added bonus.
The problem is we'd traditionally had variables which get overloaded to
many different meanings. We're hopefully getting to grips with that and
this would make another good step in that direction.
Cheers,
Richard
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 12:29 ` Phil Blundell
2011-08-11 14:28 ` Richard Purdie
@ 2011-08-11 14:49 ` Khem Raj
2011-08-12 14:35 ` Phil Blundell
1 sibling, 1 reply; 92+ messages in thread
From: Khem Raj @ 2011-08-11 14:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thursday, August 11, 2011 01:29:38 PM Phil Blundell wrote:
> On Thu, 2011-08-11 at 13:08 +0100, Richard Purdie wrote:
> > On Thu, 2011-08-11 at 12:25 +0100, Phil Blundell wrote:
> > > On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > > > +# MIPS Architecture definition
> > > > +# 12 defined ABIs, all combinations of:
> > > > +# *) Big/Little Endian
> > > > +# *) Hardware/Software Floating Point
> > > > +# *) o32, n32, n64 ABI
> > > > +
> > > > +DEFAULTTUNE ?= "mips"
> > > > +
> > > > +# Endianess
> > > > +TUNEVALID[bigendian] = "Enable big-endian mode"
> > > > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES",
> > > > "bigendian", "-meb", "-mel", d> >
> > > I've just been trying to do a mips build for the first time since
> > > these
> > > patches were landed and I'm a little bit unclear about what the
> > > "right"
> > > way to declare endianness is nowadays.
> > >
> > > The new tuning system has introduced the idea of endianness as an
> > > ABI
> > > tune parameter and, by implication, if I don't have "bigendian" in
> > > TUNE_FEATURES then presumably this is meant to mean little-endian.
> > > However, there seem to be at least some places in OE which are still
> > > expecting endianness to be encoded into TARGET_ARCH, i.e. a
> > > little-endian system would be TARGET_ARCH=mipsel rather than mips.
> > >
> > > Right now, building a little-endian MIPS32 doesn't seem to work
> > > either
> > > way around. If I set TARGET_ARCH=mips and exclude bigendian from
> > > TUNE_FEATURES then (among other issues) uclibc-config.inc decides
> > > that
> > > my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
> > > Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
> > > OVERRIDES and I end up with the wrong uClibc.machine and associated
> > > -mips1 lossage.
> > >
> > > That latter failure is at least relatively easy to work around and
> > > so
> > > that's what I'm doing at the moment. But I don't know whether this
> > > is
> > > the "right" way to proceed or whether TARGET_ARCH is expected to be
> > > endian-agnostic in this newly tuned-up world.
> >
> > You sound like you're doing this backwards. Pick a tune that either sets
> > TUNE_FEATURES to either contain or not contain "bigendian". TARGET_ARCH
> > then should get set appropriately and things that look at TARGET_ARCH
> > should work as before.
> >
> > Ultimately we might want to consider if things like siteconfig should
> > use TUNE_FEATURES rather than TARGET_ARCH but it should work as things
> > stand now...
>
> Okay. So, if I let arch-mips.inc set TARGET_ARCH for itself then it
> picks "mipsel", which is the second case I mentioned above and leads to
> the -mips1 failure. I guess this means that either uclibc's usage of
> overrides needs fixing, or arch-mips ought to be putting "mips" into
> ${OVERRIDES}.
uclibc's configuration can now be simplified a bit with new tune files
right now it uses target arch heavily.
>
> More generally, it seems as though having TARGET_ARCH in ${OVERRIDES} is
> probably going to be fairly useless if that value now includes all the
> decorations for ABI features, since it is going to be hard/impossible to
> get it to match reliably.
>
> Does the new tune model provide any variable which represents the
> underlying CPU architecture ("arm", "mips")? That seems to be what's
> really wanted in almost all the cases where TARGET_ARCH is being used as
> an OVERRIDE.
yeah I think major cpu architecture would be nice to have in overrides
e.g. mips for mipseb and mipsel. We dont need endianness info since we
can deduce that from tune features in todays setup.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 11:25 ` Phil Blundell
2011-08-11 12:08 ` Richard Purdie
@ 2011-08-11 15:54 ` Mark Hatle
1 sibling, 0 replies; 92+ messages in thread
From: Mark Hatle @ 2011-08-11 15:54 UTC (permalink / raw)
To: openembedded-core
On 8/11/11 6:25 AM, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +# MIPS Architecture definition
>> +# 12 defined ABIs, all combinations of:
>> +# *) Big/Little Endian
>> +# *) Hardware/Software Floating Point
>> +# *) o32, n32, n64 ABI
>> +
>> +DEFAULTTUNE ?= "mips"
>> +
>> +# Endianess
>> +TUNEVALID[bigendian] = "Enable big-endian mode"
>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d
>
> I've just been trying to do a mips build for the first time since these
> patches were landed and I'm a little bit unclear about what the "right"
> way to declare endianness is nowadays.
>
> The new tuning system has introduced the idea of endianness as an ABI
> tune parameter and, by implication, if I don't have "bigendian" in
> TUNE_FEATURES then presumably this is meant to mean little-endian.
> However, there seem to be at least some places in OE which are still
> expecting endianness to be encoded into TARGET_ARCH, i.e. a
> little-endian system would be TARGET_ARCH=mipsel rather than mips.
My understanding of MIPS and how everything should have been configured.
canonical arch = mips = big endian -- mipsel = little endian. Anything else is
incorrect.
As for the CCARGS, the versions of gcc that I am used to, little endian is the
default tuning. But we still want to provide -mel to ensure we've got the right
one.
> Right now, building a little-endian MIPS32 doesn't seem to work either
> way around. If I set TARGET_ARCH=mips and exclude bigendian from
> TUNE_FEATURES then (among other issues) uclibc-config.inc decides that
> my system is bigendian and sticks -Wl,-EB back into LDFLAGS.
> Conversely, if I set TARGET_ARCH=mipsel then I don't get "mips" in
> OVERRIDES and I end up with the wrong uClibc.machine and associated
> -mips1 lossage.
The TUNE you should be using is "mipsel" instead of "mips". (The DEFAULTTUNE)
parameter. The TUNE_ARCH, made up of
"mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}", should result in mipsel.
> That latter failure is at least relatively easy to work around and so
> that's what I'm doing at the moment. But I don't know whether this is
> the "right" way to proceed or whether TARGET_ARCH is expected to be
> endian-agnostic in this newly tuned-up world.
TARGET_ARCH is results from TUNE_ARCH, which should be encoding the right values.
The default tune of mipsel sets the values of: TUNE_FEATURES_tune-mipsel = "o32
fpu-hard"
Which is expected to work, for mips, little endian, o32, with hard-float.
--Mark
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-11 14:49 ` Khem Raj
@ 2011-08-12 14:35 ` Phil Blundell
2011-08-12 15:28 ` Khem Raj
0 siblings, 1 reply; 92+ messages in thread
From: Phil Blundell @ 2011-08-12 14:35 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Thu, 2011-08-11 at 07:49 -0700, Khem Raj wrote:
> yeah I think major cpu architecture would be nice to have in overrides
> e.g. mips for mipseb and mipsel. We dont need endianness info since we
> can deduce that from tune features in todays setup.
I'm not entirely convinced it's wholesome for random recipes to start
poking around inside TUNE_FEATURES. SITEINFO_ENDIANNESS seems like the
cleanest way for recipes to get that information.
p.
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 2/3] Add basic Mips core tune config
2011-08-12 14:35 ` Phil Blundell
@ 2011-08-12 15:28 ` Khem Raj
0 siblings, 0 replies; 92+ messages in thread
From: Khem Raj @ 2011-08-12 15:28 UTC (permalink / raw)
To: openembedded-core
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/12/2011 07:35 AM, Phil Blundell wrote:
> On Thu, 2011-08-11 at 07:49 -0700, Khem Raj wrote:
>> yeah I think major cpu architecture would be nice to have in
>> overrides e.g. mips for mipseb and mipsel. We dont need endianness
>> info since we can deduce that from tune features in todays setup.
>
> I'm not entirely convinced it's wholesome for random recipes to
> start poking around inside TUNE_FEATURES. SITEINFO_ENDIANNESS seems
> like the cleanest way for recipes to get that information.
yes. for endianness thats better to get it from SITEINFO_ENDIANNESS so
far TARGET_ARCH was being used which should be improved.
>
> p.
>
>
>
> _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk5FRoMACgkQuwUzVZGdMxRoSACeLo3/aWiLbQn86+ZoxQDw4rXR
7zoAnA0TxTF7fDFQgLsgOWqji/KEz7hJ
=0IKr
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 92+ messages in thread
end of thread, other threads:[~2011-08-12 15:32 UTC | newest]
Thread overview: 92+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <cover.1311683981.git.richard.purdie@linuxfoundation.org>
2011-07-26 12:44 ` [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle Richard Purdie
2011-07-26 12:46 ` Koen Kooi
2011-07-27 12:17 ` Phil Blundell
2011-07-27 13:33 ` Richard Purdie
2011-07-27 14:27 ` Mark Hatle
2011-07-27 14:33 ` Koen Kooi
2011-07-27 14:49 ` Mark Hatle
2011-07-27 14:57 ` Phil Blundell
2011-07-27 15:01 ` Koen Kooi
2011-07-27 15:08 ` Phil Blundell
2011-07-27 15:13 ` Koen Kooi
2011-07-27 15:17 ` Phil Blundell
2011-07-29 6:31 ` Khem Raj
2011-07-29 6:20 ` Khem Raj
2011-07-27 14:34 ` Richard Purdie
2011-07-27 14:44 ` Phil Blundell
2011-07-27 14:55 ` Mark Hatle
2011-07-29 6:18 ` Khem Raj
2011-07-29 7:15 ` Phil Blundell
2011-07-29 6:08 ` Khem Raj
2011-07-29 6:47 ` Phil Blundell
2011-07-29 6:51 ` Khem Raj
2011-07-27 14:34 ` Phil Blundell
2011-07-27 14:58 ` Mark Hatle
2011-07-27 15:25 ` Phil Blundell
2011-07-27 15:29 ` Richard Purdie
2011-07-27 15:49 ` Phil Blundell
2011-07-27 17:19 ` Mark Hatle
2011-07-27 19:31 ` Phil Blundell
2011-07-27 20:48 ` Mark Hatle
2011-07-27 21:16 ` Phil Blundell
2011-07-28 0:43 ` Khem Raj
2011-07-28 7:24 ` Martin Jansa
2011-07-28 8:54 ` Phil Blundell
2011-07-28 18:17 ` Martin Jansa
2011-07-29 6:41 ` Khem Raj
2011-07-29 6:38 ` Khem Raj
2011-07-29 7:13 ` Phil Blundell
2011-07-29 6:27 ` Khem Raj
2011-07-27 17:31 ` do_rootfs broken, was: " Koen Kooi
2011-07-27 18:19 ` Koen Kooi
2011-07-28 11:39 ` Phil Blundell
2011-07-29 5:59 ` Khem Raj
2011-07-29 7:25 ` Phil Blundell
2011-07-29 8:22 ` Koen Kooi
2011-07-26 12:44 ` [PATCH 2/3] Add basic Mips core tune config Richard Purdie
2011-07-26 14:41 ` Mark Hatle
2011-07-26 16:51 ` Richard Purdie
2011-07-26 17:08 ` Mark Hatle
2011-07-26 19:47 ` Khem Raj
2011-08-11 11:25 ` Phil Blundell
2011-08-11 12:08 ` Richard Purdie
2011-08-11 12:29 ` Phil Blundell
2011-08-11 14:28 ` Richard Purdie
2011-08-11 14:49 ` Khem Raj
2011-08-12 14:35 ` Phil Blundell
2011-08-12 15:28 ` Khem Raj
2011-08-11 15:54 ` Mark Hatle
2011-07-26 12:44 ` [PATCH 3/3] Add basic PowerPC " Richard Purdie
2011-07-26 13:47 ` Kumar Gala
2011-07-26 13:59 ` Richard Purdie
2011-07-26 14:59 ` Mark Hatle
2011-07-26 15:22 ` Kumar Gala
2011-07-26 16:18 ` Richard Purdie
2011-07-26 21:56 ` Kumar Gala
2011-07-26 22:02 ` Kumar Gala
2011-07-26 22:29 ` Khem Raj
2011-07-26 22:52 ` Richard Purdie
2011-07-27 3:23 ` Kumar Gala
2011-07-27 8:36 ` Richard Purdie
2011-07-27 8:44 ` Koen Kooi
2011-07-27 9:30 ` Richard Purdie
2011-07-28 5:25 ` Add basic PowerPC core tune config (bug?) Kumar Gala
2011-07-28 6:09 ` Saul Wold
2011-07-28 7:48 ` Cui, Dexuan
2011-07-28 8:47 ` Paul Eggleton
2011-07-28 8:57 ` Koen Kooi
2011-07-28 9:20 ` Phil Blundell
2011-07-28 10:00 ` Koen Kooi
2011-07-28 10:03 ` Phil Blundell
2011-07-27 9:35 ` [PATCH 3/3] Add basic PowerPC core tune config Phil Blundell
2011-07-26 22:03 ` Kumar Gala
2011-07-27 8:31 ` Richard Purdie
2011-07-26 20:03 ` Khem Raj
2011-07-26 14:57 ` Mark Hatle
2011-07-26 16:36 ` Richard Purdie
2011-07-26 16:53 ` Mark Hatle
2011-07-26 17:05 ` Richard Purdie
2011-07-26 17:15 ` Mark Hatle
2011-07-26 19:21 ` Richard Purdie
2011-07-26 20:28 ` Richard Purdie
2011-07-26 20:13 ` Khem Raj
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.