[PATCH 0/7] Cleanup and document tuning files

[PATCH 0/7] Cleanup and document tuning files

[Mark Hatle]

This is a documentation and cleanup of the tuning files.  Every tuning listed
in AVAILTUNES was built for core-image-minimal!  The following is a list of
failure conditions with explanations:

ep9312 - binutils - gas fails to recognize -march=ep9312 as valid
         (see binutils armv5e note below)

cortexm3 - gcc reports the target CPU does not support ARM mode
cortexr4 - gcc reports the target CPU does not support ARM mode

mips64* - These are not yet supported by the OE compilers

(SH is new and experimental, based on the existing tunings)
sh3* - These are missing a patch in the compiler: 
       sh3-installfix-fixheaders.patch

sh*eb - Big endian varieties are defined, but not supported

x32 ABI variants for core2-64 and x86-64 - needs x32 layer


Multilibs verified to work:

x86-64 & x86

ppce5500 & ppc64e5500

---

Note armv5e & binutils-gas:

Finally there is a small patch to binutils gas that adds armv5e as a valid
architecture, otherwise all of the armv5e* tunings fail, even though gcc
says they are valid architectures.

---

Future work:

I'm still not completely happy with the ARM tunings, but it's too disruptive
to change them at this time.  I'd like to move to something closer to how
MIPS is configured.  Define various "variants" for the various tunings,
instead of simply defining the ARMPKGARCH.  The current method prevents us
from having a single build that can build packages optimized for armv5te and
armv7a.  While this is not likely to be a huge problem for the time being,
it may lead to problems for feed based systems that can support multiple
ARM architecture families.

The following changes since commit 38ee88e3b32b7444d7f1eb64f1b4f69a48fe0458:

  gdb: build with expat, add missing RRECOMMENDS_gdbserver (2012-04-03 14:10:44 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib mhatle/tunings
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/tunings

Mark Hatle (7):
  conf/machine/include/README: Add readme to explain cpu tunings
  conf/machine/include: Cleanup IA tunings to match README
  conf/machine/include: Cleanup MIPS tunings to match README
  conf/machine/include: Cleanup PowerPC tunings to match README
  conf/machine/include: Cleanup ARM tunings to match README
  conf/machine/include: Update SH tunings to match README
  binutils: Inform binutils that armv5e really is valid!

 meta/conf/bitbake.conf                             |    1 -
 meta/conf/machine/include/README                   |   77 ++++++++++++++++++++
 meta/conf/machine/include/arm/README               |   40 ++++++++++
 meta/conf/machine/include/arm/arch-arm.inc         |    2 +-
 meta/conf/machine/include/arm/arch-armv5.inc       |    2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc      |    6 +-
 meta/conf/machine/include/ia32/README              |   24 ++++++
 meta/conf/machine/include/ia32/arch-ia32.inc       |   26 ++++---
 meta/conf/machine/include/mips/README              |   36 +++++++++
 meta/conf/machine/include/mips/arch-mips.inc       |   38 +++++++++-
 meta/conf/machine/include/powerpc/README           |   17 +++++
 meta/conf/machine/include/powerpc/arch-powerpc.inc |   15 ++--
 .../machine/include/powerpc/arch-powerpc64.inc     |    1 +
 meta/conf/machine/include/sh/README                |   11 +++
 meta/conf/machine/include/sh/arch-sh.inc           |    9 +++
 meta/conf/machine/include/tune-c3.inc              |   12 +++-
 meta/conf/machine/include/tune-core2.inc           |   16 +++--
 meta/conf/machine/include/tune-cortexm3.inc        |    2 +-
 meta/conf/machine/include/tune-cortexr4.inc        |    2 +-
 meta/conf/machine/include/tune-i586.inc            |    8 +--
 meta/conf/machine/include/tune-mips32.inc          |   17 +++--
 meta/conf/machine/include/tune-ppc603e.inc         |    4 +-
 meta/conf/machine/include/tune-ppce300c2.inc       |    2 +-
 meta/conf/machine/include/tune-ppce500.inc         |   10 ++-
 meta/conf/machine/include/tune-ppce500mc.inc       |    4 +-
 meta/conf/machine/include/tune-ppce500v2.inc       |   10 ++-
 meta/conf/machine/include/tune-ppce5500.inc        |    4 +-
 meta/conf/machine/include/tune-sh3.inc             |   19 ++++-
 meta/conf/machine/include/tune-sh4.inc             |   32 ++++++++-
 .../binutils/binutils/binutils-armv5e.patch        |   20 +++++
 meta/recipes-devtools/binutils/binutils_2.22.bb    |    3 +-
 31 files changed, 401 insertions(+), 69 deletions(-)
 create mode 100644 meta/conf/machine/include/README
 create mode 100644 meta/conf/machine/include/arm/README
 create mode 100644 meta/conf/machine/include/ia32/README
 create mode 100644 meta/conf/machine/include/mips/README
 create mode 100644 meta/conf/machine/include/powerpc/README
 create mode 100644 meta/conf/machine/include/sh/README
 create mode 100644 meta/conf/machine/include/sh/arch-sh.inc
 create mode 100644 meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch

[PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings

[Mark Hatle]

Add a new README that covers the basic items used with various cpu
tunings.  The goal is to better help people understand the various
settings and where things should or should not be defined.

Corresponding architecture README files will also be generated to
explain the particulars of architectural tunings.

Also remove the default TUNE_PKGARCH setting in bitbake.conf.  This
was done to ensure an error occurs if an invalid tuning is defined.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/bitbake.conf           |    1 -
 meta/conf/machine/include/README |   77 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 meta/conf/machine/include/README

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 824ef04..b4669d3 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -96,7 +96,6 @@ TUNE_CCARGS ??= ""
 TUNE_LDARGS ??= ""
 TUNE_ASARGS ??= ""
 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
-TUNE_PKGARCH ??= "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
 LIBCEXTENSION ??= ""
 ABIEXTENSION ??= ""
 
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
new file mode 100644
index 0000000..6a3a63d
--- /dev/null
+++ b/meta/conf/machine/include/README
@@ -0,0 +1,77 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+ - Initial Revision
+
+The individual CPU, and ABI tunings are contained in this directory.  A 
+number of local and global variables are used to control the way the 
+tunings are setup and how they work together to specify an optimized 
+configuration.
+
+The following is brief summary of the generic components that are used 
+in these tunings.
+
+AVAILTUNES - This is a list of all of the tuning definitions currently 
+available in the system.  Not all tunes in this list may be compatible 
+with the machine configuration, or each other in a multilib 
+configuration.  Each tuning file can add to this list using "+=", but 
+should never replace the list using "=".
+
+DEFAULTTUNE - This specifies the tune to use for a particular build.  
+Each tune should specify a reasonable default, which can be overriden by 
+a machine or multilib configuration.  The specified tune must be listed 
+in the AVAILTUNES.
+
+TUNEVALID[feature] - The <feature> is defined with a human readable 
+explanation for what it does.  All architectural, cpu, abi, etc tuning 
+features must be defined using TUNEVALID.
+
+TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-<tune>.
+See TUNE_FEATURES_tune-<tune> for more information.
+
+TUNE_FEATURES_tune-<tune> - Specify the features used to describe a 
+specific tune.  This is a list of features that a tune support, each 
+feature must be in the TUNEVALID list.  Note: the tune and a given 
+feature name may be the same, but they have different purposes.  Only 
+features may be used to change behavior, while tunes are used to 
+describe an overall set of features.
+
+ABIEXTENSION - An ABI extension may be specified by a specific feature 
+or other tuning setting, such as TARGET_FPU.  Any ABI extensions either 
+need to be defined in the architectures base arch file, i.e.  
+ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune 
+files with a ".=".  Spaces are not allowed in this variable.
+
+TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.  
+These should be additive when defined using "+=".  All items in this 
+list should be dynamic! i.e. 
+${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)}
+
+TUNE_ARCH - The GNU canonical arch for a specific architecture.  i.e. 
+arm, armeb, mips, mips64, etc.  This value is by bitbake to setup 
+configure. TUNE_ARCH definitions are specific to a given architecture.  
+They may be a single static definitions, or may be dynamically adjusted.  
+See each architectures README for details for that CPU family.
+
+TUNE_PKGARCH - The package architecture used by the packaging systems to 
+define the architecture, abi and tuning of a particular package.  
+Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to 
+each architecture. See each architectures README for details for that 
+CPU family.
+
+PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package 
+architectures.  By default this is equal to 
+PACKAGE_EXTRA_ARCHS_tune-<tune>.  If an architecture deviates from the 
+default it will be listed in the architecture README.
+
+PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures 
+that are compatible with this specific tune.  The package arch of this 
+tune must be in the list.
+
+TARGET_FPU - The FPU setting for a given tune, hard (generate floating 
+point instructions), soft (generate internal gcc calls), "other" 
+architecture specific floating point.  This is synchronized with the 
+compiler and other toolchain items.  This should be dynamically 
+configured in the same way that TUNE_CCARGS is.
+
+BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI.  This is 
+used in a multilib configuration to place the libraries in the correct, 
+non-conflicting locations.
-- 
1.7.1

[PATCH 2/7] conf/machine/include: Cleanup IA tunings to match README

[Mark Hatle]

We perform a basic cleanup of the IA32 architecture and related
tunings in order to match the rules and descriptions within the
new tuning README file.

A number of small issues were corrected in the "c3" tuning to
bring it inline with the README.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/machine/include/ia32/README        |   24 ++++++++++++++++++++++++
 meta/conf/machine/include/ia32/arch-ia32.inc |   26 ++++++++++++++------------
 meta/conf/machine/include/tune-c3.inc        |   12 +++++++++---
 meta/conf/machine/include/tune-core2.inc     |   16 +++++++++-------
 meta/conf/machine/include/tune-i586.inc      |    8 +++-----
 5 files changed, 59 insertions(+), 27 deletions(-)
 create mode 100644 meta/conf/machine/include/ia32/README

diff --git a/meta/conf/machine/include/ia32/README b/meta/conf/machine/include/ia32/README
new file mode 100644
index 0000000..8f80a5b
--- /dev/null
+++ b/meta/conf/machine/include/ia32/README
@@ -0,0 +1,24 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+ - Initial version
+
+Most of the items for the IA architecture are defined in the single 
+arch-ia32 file.
+
+Three ABIs are define, m32, mx32 and m64.
+
+The following is the list of ia32 specific variables:
+
+X86ARCH32 - This is the 32-bit architecture GNU canonical arch, TUNE_ARCH.
+
+X86ARCH64 - This is the 64-bit architecture GNU canonical arch, TUNE_ARCH.
+
+The TUNE_PKGARCH is defined as follows:
+
+TUNE_PKGARCH = ${TUNE_PKGARCH_tune-${DEFAULTTUNE}}
+
+The package architecture for 32-bit targets is historical and generally
+set to to match the core compatible processor type, i.e. i386.
+
+For 64-bit architectures, the architecture is expected to end in '_64'.
+
+If the x32 ABI is used, then the _64 is further extended with a '_x32'.
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc b/meta/conf/machine/include/ia32/arch-ia32.inc
index 0931c26..a5dae88 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -7,6 +7,8 @@ TARGET_FPU ?= ""
 X86ARCH32 ?= "i586"
 X86ARCH64 ?= "x86_64"
 
+TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
+
 # ELF32 ABI
 TUNEVALID[m32] = "IA32 ELF32 standard ABI"
 TUNECONFLICTS[m32] = "m64 mx32"
@@ -29,21 +31,21 @@ TUNECONFLICT[m64] = "m32 mx32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"
 
-TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}"
-
 # Default Tune configurations
 AVAILTUNES += "x86"
-TUNE_FEATURES_tune-x86 ?= "m32"
-BASE_LIB_tune-x86 ?= "lib"
-PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
+TUNE_FEATURES_tune-x86 = "m32"
+BASE_LIB_tune-x86 = "lib"
+TUNE_PKGARCH_tune-x86 = "x86"
+PACKAGE_EXTRA_ARCHS_tune-x86 = "${TUNE_PKGARCH_tune-x86}"
 
 AVAILTUNES += "x86-64"
-TUNE_FEATURES_tune-x86-64 ?= "m64"
-BASE_LIB_tune-x86-64 ?= "lib64"
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
+TUNE_FEATURES_tune-x86-64 = "m64"
+BASE_LIB_tune-x86-64 = "lib64"
+TUNE_PKGARCH_tune-x86-64 = "x86_64"
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = "${TUNE_PKGARCH_tune-x86-64}"
 
 AVAILTUNES += "x86-64-x32"
-TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
-BASE_LIB_tune-x86-64-x32 ?= "libx32"
-PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64_x32"
-TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "_x32", "", d)}"
+TUNE_FEATURES_tune-x86-64-x32 = "mx32"
+BASE_LIB_tune-x86-64-x32 = "libx32"
+TUNE_PKGARCH_tune-x86-64-x32 = "x86_64_x32"
+PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "${TUNE_PKGARCH_tune-x86-64-x32}"
diff --git a/meta/conf/machine/include/tune-c3.inc b/meta/conf/machine/include/tune-c3.inc
index e1569f5..06fac8f 100644
--- a/meta/conf/machine/include/tune-c3.inc
+++ b/meta/conf/machine/include/tune-c3.inc
@@ -1,6 +1,12 @@
 require conf/machine/include/ia32/arch-ia32.inc
 
-TUNE_PKGARCH = "i586"
+TUNEVALID[c3] = "VIA Cyrix III or VIA C3 specific optimizations"
+TUNECONFLICT[c3] = "m64 mx32"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "c3", "-march=c3 -mtune=c3", "", d)}"
 
-TUNE_CCARGS = "-march=c3 -mtune=c3"
-PACKAGE_EXTRA_ARCHS = "i386 i486 i586"
+AVAILTUNES += "c3"
+TUNE_FEATURES_tune-c3 = "${TUNE_FEATURES_tune-x86} c3"
+BASE_LIBS_tune-c3 = "${BASE_LIB_tune-x86}"
+# The following should likely be something other then i586...
+TUNE_PKGARCH_tune-c3 = "i586"
+PACKAGE_EXTRA_ARCHS_tune-c3 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486 i586"
diff --git a/meta/conf/machine/include/tune-core2.inc b/meta/conf/machine/include/tune-core2.inc
index 7cde511..338ba73 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -1,5 +1,4 @@
 DEFAULTTUNE ?= "core2"
-TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "core2", "core2_64", d)}"
 
 require conf/machine/include/tune-i586.inc
 
@@ -9,16 +8,19 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "core2", "-march=core2 -ms
 
 # Extra tune selections
 AVAILTUNES += "core2"
-TUNE_FEATURES_tune-core2 ?= "${TUNE_FEATURES_tune-x86} core2"
-BASE_LIB_tune-core2 ?= "lib"
+TUNE_FEATURES_tune-core2 = "${TUNE_FEATURES_tune-x86} core2"
+BASE_LIB_tune-core2 = "lib"
+TUNE_PKGARCH_tune-core2 = "core2"
 PACKAGE_EXTRA_ARCHS_tune-core2 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486 i586 i686 core2"
 
 AVAILTUNES += "core2-64"
-TUNE_FEATURES_tune-core2-64 ?= "${TUNE_FEATURES_tune-x86-64} core2"
-BASE_LIB_tune-core2-64 ?= "lib64"
+TUNE_FEATURES_tune-core2-64 = "${TUNE_FEATURES_tune-x86-64} core2"
+BASE_LIB_tune-core2-64 = "lib64"
+TUNE_PKGARCH_tune-core2-64 = "core2_64"
 PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2_64"
 
 AVAILTUNES += "core2-64-x32"
-TUNE_FEATURES_tune-core2-64-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32} core2"
-BASE_LIB_tune-core2-64-x32 ?= "libx32"
+TUNE_FEATURES_tune-core2-64-x32 = "${TUNE_FEATURES_tune-x86-64-x32} core2"
+BASE_LIB_tune-core2-64-x32 = "libx32"
+TUNE_PKGARCH_tune-core2-64-x32 = "core2_64_x32"
 PACKAGE_EXTRA_ARCHS_tune-core2-64-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2_64_x32"
diff --git a/meta/conf/machine/include/tune-i586.inc b/meta/conf/machine/include/tune-i586.inc
index a40ce18..afa9c92 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,6 +1,4 @@
 DEFAULTTUNE ?= "i586"
-TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}"
-TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i586", "i586", TUNE_PKGARCH_TMP, d)}"
 
 require conf/machine/include/ia32/arch-ia32.inc
 
@@ -10,7 +8,7 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i586", "-march=i586", "",
 
 # Extra tune selections
 AVAILTUNES += "i586"
-TUNE_FEATURES_tune-i586 ?= "${TUNE_FEATURES_tune-x86} i586"
-BASE_LIB_tune-i586 ?= "lib"
+TUNE_FEATURES_tune-i586 = "${TUNE_FEATURES_tune-x86} i586"
+BASE_LIB_tune-i586 = "lib"
+TUNE_PKGARCH_tune-i586 = "i586"
 PACKAGE_EXTRA_ARCHS_tune-i586 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486 i586"
-
-- 
1.7.1

[PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

Cleanup the MIPS tunings to match the new tuning README file.  Also
add a MIPS specific README file to explain the MIPS specifical
architectural issues.

Finally correct the variant configurations within the tune-mips32.inc.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/machine/include/mips/README        |   36 ++++++++++++++++++++++++
 meta/conf/machine/include/mips/arch-mips.inc |   38 ++++++++++++++++++++++++-
 meta/conf/machine/include/tune-mips32.inc    |   17 ++++++++---
 3 files changed, 84 insertions(+), 7 deletions(-)
 create mode 100644 meta/conf/machine/include/mips/README

diff --git a/meta/conf/machine/include/mips/README b/meta/conf/machine/include/mips/README
new file mode 100644
index 0000000..6a22739
--- /dev/null
+++ b/meta/conf/machine/include/mips/README
@@ -0,0 +1,36 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+  - Initial Version
+
+MIPS currently defines 12 ABIs.  Combinations of:
+ *) Big/Little Endian
+ *) Hardware/Software Floating Point
+ *) o32, n32, n64 ABI
+
+TUNE_ARCH, the GNU canonical arch, is defined as:
+
+mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}
+
+The package arch is defined in such a way to generated a standard naming
+scheme.  The scheme is: <mips variant>[-nf][-n32]
+
+TUNE_PKGARCH is defined as:
+
+${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}
+
+The following is a list of MIPS specific variables:
+
+MIPSPKGSFX_BYTE - This is defined as either blank and "64" for MIPS64 CPUs.
+
+MIPSPKGSFX_ENDIAN - For bigendian hardware this is blank, otherwise it's
+defined as "el".
+
+MIPSPKGSFX_VARIANT_tune-<tune> - In the default tunings it is set to the
+same value as TUNE_ARCH.  In custom, optimized tunings, the value should
+be modified to more precisely describe the tuning.
+
+MIPSPKGSFX_FPU - This defines if the floating point hardware is used by
+this tuning.  A "-nf" is added to the PKGARCH in this case.
+
+MIPSPKGSFX_ABI - This is used to specify an alternative ABI when the previous
+values are not enough to distringuish the package.  "-n32" is added when
+building for N32 ABI.
diff --git a/meta/conf/machine/include/mips/arch-mips.inc b/meta/conf/machine/include/mips/arch-mips.inc
index b7ded76..8758ecd 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -36,32 +36,66 @@ MIPSPKGSFX_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard" , "", "-nf",
 MIPSPKGSFX_ABI = "${@bb.utils.contains("TUNE_FEATURES", "n32", "-n32", "", d)}"
 
 TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
-TUNE_PKGARCH ?= "${TUNE_ARCH}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}"
+TUNE_PKGARCH = "${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}"
 
 # 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"
+MIPSPKGSFX_VARIANT_tune-mips = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips = "mips"
+
 TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
 BASE_LIB_tune-mips64-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-n32 = "mips64-n32"
+
 TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
 BASE_LIB_tune-mips64 = "lib64"
+MIPSPKGSFX_VARIANT_tune-mips64 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64 = "mips64"
+
 TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
 BASE_LIB_tune-mipsel = "lib"
+MIPSPKGSFX_VARIANT_tune-mipsel = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mipsel = "mipsel"
+
 TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
 BASE_LIB_tune-mips64el-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64el-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-n32 = "mips64el-n32"
+
 TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
 BASE_LIB_tune-mips64el = "lib64"
+MIPSPKGSFX_VARIANT_tune-mips64el = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el = "mips64el"
+
 TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
 BASE_LIB_tune-mips-nf = "lib"
+MIPSPKGSFX_VARIANT_tune-mips-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips-nf = "mips-nf"
+
 TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
 BASE_LIB_tune-mips64-nf-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"
+
 TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
 BASE_LIB_tune-mips64-nf = "lib64"
+MIPSPKGSFX_VARIANT_tune-mips64-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-nf = "mips64-nf"
+
 TUNE_FEATURES_tune-mipsel-nf = "o32"
 BASE_LIB_tune-mipsel-nf = "lib"
+MIPSPKGSFX_VARIANT_tune-mipsel-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mipsel-nf = "mipsel-nf"
+
 TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
 BASE_LIB_tune-mips64el-nf-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64el-nf-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-n32 = "mips64el-nf-n32"
+
 TUNE_FEATURES_tune-mips64el-nf = "n64"
 BASE_LIB_tune-mips64el-nf = "lib64"
-
+MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf"
diff --git a/meta/conf/machine/include/tune-mips32.inc b/meta/conf/machine/include/tune-mips32.inc
index 45d865e..93ed5ee 100644
--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -7,12 +7,19 @@ TUNE_CONFLICTS[mips32] = "n64 n32"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32", "-march=mips32", "", d)}"
 
 AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
+
 TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
-PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips"
+MIPSPKGSFX_VARIANT_tune-mips32 = "mips32"
+PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips mips32"
+
 TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
-PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel"
+MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
+PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"
+
 TUNE_FEATURES_tune-mips32-nf = "${TUNE_FEATURES_tune-mips-nf} mips32"
-PACKAGE_EXTRA_ARCHS_tune-mips32-nf = "mips-nf"
-TUNE_FEATURES_tune-mips32el-nf = "${TUNE_FEATURES_tune-mipsel-nf} mips32"
-PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = "mipsel-nf"
+MIPSPKGSFX_VARIANT_tune-mips32-nf = "mips32"
+PACKAGE_EXTRA_ARCHS_tune-mips32-nf = "mips-nf mips32-nf"
 
+TUNE_FEATURES_tune-mips32el-nf = "${TUNE_FEATURES_tune-mipsel-nf} mips32"
+MIPSPKGSFX_VARIANT_tune-mips32el-nf = "mips32el"
+PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = "mipsel-nf mips32el-nf"
-- 
1.7.1

[PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README

[Mark Hatle]

Cleanup the PowerPC tunings to match the new tuning README file.

Default PowerPC to using TUNE_PKGARCH = ${TUNE_PKGARCH_tune-<tune>}

Fix AVAILTUNE settings in ppc603e, and ppce500mc to be addative.

Correct potentially overlapping "spe" definitions in ppce500 and ppce500v2.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/machine/include/powerpc/README           |   17 +++++++++++++++++
 meta/conf/machine/include/powerpc/arch-powerpc.inc |   15 ++++++++-------
 .../machine/include/powerpc/arch-powerpc64.inc     |    1 +
 meta/conf/machine/include/tune-ppc603e.inc         |    4 ++--
 meta/conf/machine/include/tune-ppce300c2.inc       |    2 +-
 meta/conf/machine/include/tune-ppce500.inc         |   10 +++++++---
 meta/conf/machine/include/tune-ppce500mc.inc       |    4 ++--
 meta/conf/machine/include/tune-ppce500v2.inc       |   10 +++++++---
 meta/conf/machine/include/tune-ppce5500.inc        |    4 ++--
 9 files changed, 47 insertions(+), 20 deletions(-)
 create mode 100644 meta/conf/machine/include/powerpc/README

diff --git a/meta/conf/machine/include/powerpc/README b/meta/conf/machine/include/powerpc/README
new file mode 100644
index 0000000..e87fb50
--- /dev/null
+++ b/meta/conf/machine/include/powerpc/README
@@ -0,0 +1,17 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+  - Initial revision
+
+There are 4 primary PowerPC ABIs.
+# *) Hard/Soft Floating Point
+# *) 32-bit/64-bit
+
+TUNE_ARCH is defined as either "powerpc" or "powerpc64" based on the m32 
+or m64 feature.
+
+May of the PowerPC package archictures are based on legacy Linux names.
+However, a general naming scheme should be similar to: ppc[64][<family>][-nf].
+(Note: the default package architectures are "powerpc" and "powerpc64".)
+
+TUNE_PKGARCH is defined as TUNE_PKGARCH_tune-${DEFAULTTUNE}.  All 
+PowerPC tunings are required to define TUNE_PKGARCH_tune-<tune>.
+
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc
index c5fd6b7..12909d9 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc
@@ -5,6 +5,9 @@
 
 DEFAULTTUNE ?= "powerpc"
 
+TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
+ABIEXTENSION ?= ""
+
 TUNEVALID[m32] = "Power ELF32 standard ABI"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "powerpc", "", d)}"
@@ -16,16 +19,14 @@ 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)}"
 
-ABIEXTENSION = "${@['','spe'][d.getVar('TARGET_FPU', True) in ['ppc-efd', 'ppc-efs']]}"
-
-PPCPKGSFX_FPU = "${@['', '-nf'][d.getVar('TARGET_FPU', True) in ['fpu-soft']]}"
-TUNE_PKGARCH_append = "${PPCPKGSFX_FPU}"
-
 # Basic tune definitions
 AVAILTUNES += "powerpc powerpc-nf" 
-TUNE_FEATURES_tune-powerpc-nf ?= "m32 fpu-soft"
+TUNE_FEATURES_tune-powerpc-nf = "m32 fpu-soft"
 BASE_LIB_tune-powerpc-nf = "lib"
+TUNE_PKGARCH_tune-powerpc-nf = "powerpc-nf"
 PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf"
-TUNE_FEATURES_tune-powerpc ?= "m32 fpu-hard"
+
+TUNE_FEATURES_tune-powerpc = "m32 fpu-hard"
 BASE_LIB_tune-powerpc = "lib"
+TUNE_PKGARCH_tune-powerpc = "powerpc"
 PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc"
diff --git a/meta/conf/machine/include/powerpc/arch-powerpc64.inc b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
index 48cd08e..a5e9755 100644
--- a/meta/conf/machine/include/powerpc/arch-powerpc64.inc
+++ b/meta/conf/machine/include/powerpc/arch-powerpc64.inc
@@ -10,4 +10,5 @@ TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64" ], "powerpc64", "",
 AVAILTUNES += "powerpc64"
 TUNE_FEATURES_tune-powerpc64 ?= "m64 fpu-hard"
 BASE_LIB_tune-powerpc64 = "lib64"
+TUNE_PKGARCH_tune-powerpc64 = "powerpc64"
 PACKAGE_EXTRA_ARCHS_tune-powerpc64 = "powerpc64"
diff --git a/meta/conf/machine/include/tune-ppc603e.inc b/meta/conf/machine/include/tune-ppc603e.inc
index 02cebe7..6557c1d 100644
--- a/meta/conf/machine/include/tune-ppc603e.inc
+++ b/meta/conf/machine/include/tune-ppc603e.inc
@@ -4,10 +4,10 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppc603e] = "Enable ppc603e specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", "-mcpu=603e", "", d)}"
-TUNE_PKGARCH_tune-ppc603e = "ppc603e"
 
-AVAILTUNES = "ppc603e"
+AVAILTUNES += "ppc603e"
 TUNE_FEATURES_tune-ppc603e = "m32 fpu-hard ppc603e"
+TUNE_PKGARCH_tune-ppc603e = "ppc603e"
 PACKAGE_EXTRA_ARCHS_tune-ppc603e = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppc603e"
 
 # glibc configure options to get 603e specific library (for sqrt)
diff --git a/meta/conf/machine/include/tune-ppce300c2.inc b/meta/conf/machine/include/tune-ppce300c2.inc
index 27ef4a8..aae8ac0 100644
--- a/meta/conf/machine/include/tune-ppce300c2.inc
+++ b/meta/conf/machine/include/tune-ppce300c2.inc
@@ -4,8 +4,8 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce300c2] = "Enable ppce300c2 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c2", "-mcpu=e300c2", "", d)}"
-TUNE_PKGARCH_tune-ppce300c2 = "ppce300c2"
 
 AVAILTUNES += "ppce300c2"
 TUNE_FEATURES_tune-ppce300c2 = "m32 fpu-soft ppce300c2"
+TUNE_PKGARCH_tune-ppce300c2 = "ppce300c2"
 PACKAGE_EXTRA_ARCHS_tune-ppce300c2 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppce300c2"
diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc
index feb1967..be43722 100644
--- a/meta/conf/machine/include/tune-ppce500.inc
+++ b/meta/conf/machine/include/tune-ppce500.inc
@@ -4,13 +4,17 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
-TUNE_PKGARCH_tune-ppce500 = "ppce500"
 
 TUNEVALID[spe] = "Enable SPE ABI extensions"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500", "spe" ], "-mabi=spe -mspe -mfloat-gprs=single", "", d)}"
+TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500" , "spe" ], "ppc-efs", "", d)}"
 
-TARGET_FPU = "ppc-efs"
+# spe is defined potentially in two places, so we want to be sure it will
+# only write spe once to the ABIEXTENSIONS field.
+SPEABIEXTENSION = "${@bb.utils.contains("TUNE_FEATURES", "spe", "spe", "", d)}"
+ABIEXTENSION .= "${SPEABIEXTENSION}"
 
 AVAILTUNES += "ppce500"
 TUNE_FEATURES_tune-ppce500 = "m32 spe ppce500"
+TUNE_PKGARCH_tune-ppce500 = "ppce500"
 PACKAGE_EXTRA_ARCHS_tune-ppce500 = "ppce500"
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
index 51e6f53..0e09384 100644
--- a/meta/conf/machine/include/tune-ppce500mc.inc
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -4,10 +4,10 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce500mc] = "Enable ppce500mc specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=e500mc", "", d)}"
-TUNE_PKGARCH_tune-ppce500mc = "ppce500mc"
 
-AVAILTUNES = "ppce500mc"
+AVAILTUNES += "ppce500mc"
 TUNE_FEATURES_tune-ppce500mc = "m32 fpu-hard ppce500mc"
+TUNE_PKGARCH_tune-ppce500mc = "ppce500mc"
 PACKAGE_EXTRA_ARCHS_tune-ppce500mc = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce500mc"
 
 # glibc configure options to get e500mc specific library (for sqrt)
diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
index f0158d0..3fe47da 100644
--- a/meta/conf/machine/include/tune-ppce500v2.inc
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -4,13 +4,17 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[ppce500v2] = "Enable ppce500v2 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", "", d)}"
-TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2"
 
 TUNEVALID[spe] = "Enable SPE ABI extensions"
-TUNE_CCARGS += '${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}'
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500v2", "spe" ], "-mabi=spe -mspe -mfloat-gprs=double", "", d)}"
+TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500v2" , "spe" ], "ppc-efd", "", d)}"
 
-TARGET_FPU = "ppc-efd"
+# spe is defined potentially in two places, so we want to be sure it will
+# only write spe once to the ABIEXTENSIONS field.
+SPEABIEXTENSION = "${@bb.utils.contains("TUNE_FEATURES", "spe", "spe", "", d)}"
+ABIEXTENSION .= "${SPEABIEXTENSION}"
 
 AVAILTUNES += "ppce500v2"
 TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
+TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2"
 PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "ppce500v2"
diff --git a/meta/conf/machine/include/tune-ppce5500.inc b/meta/conf/machine/include/tune-ppce5500.inc
index fe8d79d..8ab0fc5 100644
--- a/meta/conf/machine/include/tune-ppce5500.inc
+++ b/meta/conf/machine/include/tune-ppce5500.inc
@@ -7,14 +7,14 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "e5500", "-mcpu=e5500", ""
 
 AVAILTUNES += "ppce5500 ppc64e5500"
 TUNE_FEATURES_tune-ppce5500 = "m32 fpu-hard e5500"
-PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce5500"
 BASE_LIB_tune-ppce5500 = "lib"
 TUNE_PKGARCH_tune-ppce5500 = "ppce5500"
+PACKAGE_EXTRA_ARCHS_tune-ppce5500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce5500"
 
 TUNE_FEATURES_tune-ppc64e5500 = "m64 fpu-hard e5500"
-PACKAGE_EXTRA_ARCHS_tune-ppc64e5500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc64} ppc64e5500"
 BASE_LIB_tune-ppc64e5500 = "lib64"
 TUNE_PKGARCH_tune-ppc64e5500 = "ppc64e5500"
+PACKAGE_EXTRA_ARCHS_tune-ppc64e5500 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc64} ppc64e5500"
 
 # glibc configure options to get e5500 specific library (for sqrt)
 GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "e5500", "--with-cpu=e5500", "", d)}"
-- 
1.7.1

[PATCH 5/7] conf/machine/include: Cleanup ARM tunings to match README

[Mark Hatle]

Cleanup the ARM tunings to match the new tunings README file.

The ARM tunings define TUNE_PKGARCH in a way that only one main
arm architecture, i.e. armv6, may be defined at the same time.  We
may have to revise these settings in the future, as well as figure
out a way to better differentiate various optimize tunings in the
package arch.  (This was not done, to preserve existing behavior!)

Fix a number of minor issues w/ the armv5 tunings where DSP variants
were referenced but not defined.

Fix incorrect armv7 entries in armv7a.

Fix PACKAGE_EXTRA_ARCHS definitions inside of tune-cortexm3 and tune-cortexr4.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/machine/include/arm/README          |   40 +++++++++++++++++++++++++
 meta/conf/machine/include/arm/arch-arm.inc    |    2 +-
 meta/conf/machine/include/arm/arch-armv5.inc  |    2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc |    6 ++--
 meta/conf/machine/include/tune-cortexm3.inc   |    2 +-
 meta/conf/machine/include/tune-cortexr4.inc   |    2 +-
 6 files changed, 47 insertions(+), 7 deletions(-)
 create mode 100644 meta/conf/machine/include/arm/README

diff --git a/meta/conf/machine/include/arm/README b/meta/conf/machine/include/arm/README
new file mode 100644
index 0000000..a1beb75
--- /dev/null
+++ b/meta/conf/machine/include/arm/README
@@ -0,0 +1,40 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+ - Initial Revision
+
+The ARM architecture definitions are split among a number of files.
+The primary definitions for the variables are handled by the core
+arch-arm.inc file.
+
+TUNE_ARCH is set to either "arm" or "armeb" depending on the value
+of the existence of the "bigendian" feature in a given tune.
+
+A small set of ARM specific variables have been defined to allow 
+TUNE_PKGARCH to be automatically defined.  Optimized tunings must NOT 
+change the definiton of TUNE_PKGARCH.  TUNE_PKGACH_tune-<tune> will be 
+ignored.  The format of the package arch is enforced by the TUNE_PKGARCH
+default.  The format must be of the form:
+<armversion>[t][e][hf][b][-vfp][-neon]
+
+TUNE_PKGARCH is defined as:
+${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}
+
+ARMPKGARCH - This is the core package arch component specified by each 
+tuning.  This is the primary identifier of a tuning.  Usual values are:
+arm, armv4, armv5, armv6, armv7a, etc.
+
+ARMPKGSFX_THUMB - This is the thumb specific suffix.  Curently it is 
+defined in feature-arm-thumb.inc.
+
+ARMPKGSFX_DSP - This is the DSP specific suffix.  Currently this is set 
+to 'e' when on armv5 and the dsp feature is enabled.
+
+ARMPKGSFX_EABI - This is the eabi specific suffix.  There are currently 
+two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.  
+When the callconvention-hard is enabled, "hf" is specified, otherwise it 
+is blank.
+
+ARMPKGSFX_ENDIAN - This is the endian specific suffix.  It is defined in 
+the core arch-arm.inc file.
+
+ARMPKGSFX_FPU - This is the FPU specific suffix.  The suffix indicates 
+specific FPU optimizations.  'vfp' and 'neon' are both defined.
diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index 4ea8b2b..da51044 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -9,7 +9,7 @@ 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}"
+TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
 ABIEXTENSION = "eabi"
 
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
index fd3490f..4a75530 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -13,7 +13,7 @@ require conf/machine/include/arm/arch-armv4.inc
 require conf/machine/include/arm/feature-arm-vfp.inc
 
 # Little Endian
-AVAILTUNES += "armv5 armv5t armv5e armv5te"
+AVAILTUNES += "armv5 armv5t"
 TUNE_FEATURES_tune-armv5 ?= "armv5"
 TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
 PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
index 2542f45..629960d 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -22,11 +22,11 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7a ar
 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"
+AVAILTUNES += "armv7ahf armv7athf armv7ahf-neon armv7athf-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"
+TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} callconvention-hard"
 PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7ahf-vfp"
 PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7ahf-vfp armv7at2hf-vfp"
 PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
@@ -48,7 +48,7 @@ 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"
+TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune-armv7atb-neon} callconvention-hard"
 PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7ahfb-vfp"
 PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7ahfb-vfp armv7at2hfb-vfp"
 PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
index 85408eb..20a3c65 100644
--- a/meta/conf/machine/include/tune-cortexm3.inc
+++ b/meta/conf/machine/include/tune-cortexm3.inc
@@ -11,5 +11,5 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m"
 
 AVAILTUNES += "cortexm3"
 TUNE_FEATURES_tune-cortexm3 = "armv7m vfp cortexm3"
-PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
+PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m-vfp"
 
diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
index 8d2459f..d1fc607 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -11,4 +11,4 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m"
 
 AVAILTUNES += "cortexr4"
 TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4"
-PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
+PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r-vfp"
-- 
1.7.1

[PATCH 6/7] conf/machine/include: Update SH tunings to match README

[Mark Hatle]

Update the experimental SH tunings to match the tunings README.

These tunings have not been tested, and are experimental!

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/conf/machine/include/sh/README      |   11 ++++++++++
 meta/conf/machine/include/sh/arch-sh.inc |    9 ++++++++
 meta/conf/machine/include/tune-sh3.inc   |   19 +++++++++++++++--
 meta/conf/machine/include/tune-sh4.inc   |   32 +++++++++++++++++++++++++++--
 4 files changed, 65 insertions(+), 6 deletions(-)
 create mode 100644 meta/conf/machine/include/sh/README
 create mode 100644 meta/conf/machine/include/sh/arch-sh.inc

diff --git a/meta/conf/machine/include/sh/README b/meta/conf/machine/include/sh/README
new file mode 100644
index 0000000..b351acd
--- /dev/null
+++ b/meta/conf/machine/include/sh/README
@@ -0,0 +1,11 @@
+2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
+ - Initial Revision
+
+Both big endian and little endian are defined for SH.
+
+Experimental -- SH tunings have not been validated.
+
+The TUNE_ARCH is defined as ${TUNE_ARCH_tune-${DEFAULTTUNE}}.
+
+The TUNE_PKGARCH is defind as ${TUNE_PKGARCH_tune-${DEFAULTTUNE}}.
+
diff --git a/meta/conf/machine/include/sh/arch-sh.inc b/meta/conf/machine/include/sh/arch-sh.inc
new file mode 100644
index 0000000..cde59fe
--- /dev/null
+++ b/meta/conf/machine/include/sh/arch-sh.inc
@@ -0,0 +1,9 @@
+# SH Architecture definition
+
+DEFAULTTUNE ?= "sh"
+
+TUNE_ARCH = "${TUNE_ARCH_tune-${DEFAULTTUNE}}"
+TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
+
+TUNEVALID[bigendian] = "Enabled big-endian mode."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-mb", "-ml", d)}"
diff --git a/meta/conf/machine/include/tune-sh3.inc b/meta/conf/machine/include/tune-sh3.inc
index dd12cd4..816c9c4 100644
--- a/meta/conf/machine/include/tune-sh3.inc
+++ b/meta/conf/machine/include/tune-sh3.inc
@@ -1,4 +1,17 @@
-TUNE_ARCH = "sh3"
+DEFAULTTUNE ?= "sh3"
 
-TUNE_CCARGS = "-ml -m3"
-TUNE_PKGARCH = "sh3"
+require conf/machine/include/sh/arch-sh.inc
+
+TUNEVALID[sh3] = "Enable SH3 optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "sh3", "-m3", "", d)}"
+
+AVAILTUNES += "sh3 sh3eb"
+TUNE_FEATURES_tune-sh3 = "sh3"
+TUNE_ARCH_tune-sh3 = "sh3"
+TUNE_PKGARCH_tune-sh3 = "sh3"
+PACKAGE_EXTRA_ARCHS_tune-sh3 = "sh sh3"
+
+TUNE_FEATURES_tune-sh3eb = "sh3eb"
+TUNE_ARCH_tune-sh3eb = "sh3eb"
+TUNE_PKGARCH_tune-sh3eb = "sh3eb"
+PACKAGE_EXTRA_ARCHS_tune-sh3eb = "sheb sh3eb"
diff --git a/meta/conf/machine/include/tune-sh4.inc b/meta/conf/machine/include/tune-sh4.inc
index 473122c..f971f23 100644
--- a/meta/conf/machine/include/tune-sh4.inc
+++ b/meta/conf/machine/include/tune-sh4.inc
@@ -1,8 +1,34 @@
-TUNE_ARCH = "sh4"
+DEFAULTTUNE ?= "sh4"
+
+# Pull in sh4 for compatibility...
+require conf/machine/include/sh/arch-sh.inc
+
+TUNEVALID[sh4] = "Enable SH4 optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "sh4", "-m4", "", d)}"
 
 # NOTE: If you want to optimize to sh4a, conf/machine/include/tune-sh4a.inc.
 # But it is not compatible for sh4.
 # The binary optimized by m4a doesn't operate on sh4. It works on sh4a only.
+TUNEVALID[sh4a] = "Enable SH4a optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "sh4a", "-m4a", "", d)}"
+
+AVAILTUNES += "sh4 sh4eb sh4a sh4aeb"
+TUNE_FEATURES_tune-sh4 = "sh4"
+TUNE_ARCH_tune-sh4 = "sh4"
+TUNE_PKGARCH_tune-sh4 = "sh4"
+PACKAGE_EXTRA_ARCHS_tune-sh4 = "sh sh4"
+
+TUNE_FEATURES_tune-sh4eb = "sh4eb"
+TUNE_ARCH_tune-sh4eb = "sh4eb"
+TUNE_PKGARCH_tune-sh4eb = "sh4eb"
+PACKAGE_EXTRA_ARCHS_tune-sh4eb = "sheb sh4eb"
+
+TUNE_FEATURES_tune-sh4a = "sh4a"
+TUNE_ARCH_tune-sh4a = "sh4"
+TUNE_PKGARCH_tune-sh4a = "sh4a"
+PACKAGE_EXTRA_ARCHS_tune-sh4a = "sh sh4 sh4a"
 
-TUNE_CCARGS = "-ml -m4"
-TUNE_PKGARCH = "sh4"
+TUNE_FEATURES_tune-sh4aeb = "sh4aeb"
+TUNE_ARCH_tune-sh4aeb = "sh4eb"
+TUNE_PKGARCH_tune-sh4aeb = "sh4aeb"
+PACKAGE_EXTRA_ARCHS_tune-sh4aeb = "sheb sh4eb sh4aeb"
-- 
1.7.1

[PATCH 7/7] binutils: Inform binutils that armv5e really is valid!

[Mark Hatle]

A comment in the binutils sources indicate that it should support all of the
-march= parameters that gcc supports.  The tune validations noted that
gas failed on -march=armv5e.

It is not yet clear to me if this patch belongs upstream or not.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 .../binutils/binutils/binutils-armv5e.patch        |   20 ++++++++++++++++++++
 meta/recipes-devtools/binutils/binutils_2.22.bb    |    3 ++-
 2 files changed, 22 insertions(+), 1 deletions(-)
 create mode 100644 meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch

diff --git a/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch b/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
new file mode 100644
index 0000000..4ac1a9c
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
@@ -0,0 +1,20 @@
+Add the armv5e architecture to binutils
+
+Binutils has a comment that indicates it is supposed to match gcc for all of
+the support "-march=" settings, but it was lacking the armv5e setting.  This
+was a simple way to add it, as thumb instructions shouldn't be generated by
+the compiler anyway.
+
+Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
+
+diff -urN binutils-2.22.orig/gas/config/tc-arm.c binutils-2.22/gas/config/tc-arm.c
+--- binutils-2.22.orig/gas/config/tc-arm.c	2011-11-21 03:29:31.000000000 -0600
++++ binutils-2.22/gas/config/tc-arm.c	2012-04-03 12:07:42.230158760 -0500
+@@ -22990,6 +22990,7 @@
+   {"armv4t",		ARM_ARCH_V4T,	 FPU_ARCH_FPA},
+   {"armv4txm",		ARM_ARCH_V4TxM,	 FPU_ARCH_FPA},
+   {"armv5",		ARM_ARCH_V5,	 FPU_ARCH_VFP},
++  {"armv5e",		ARM_ARCH_V5TE,	 FPU_ARCH_VFP},
+   {"armv5t",		ARM_ARCH_V5T,	 FPU_ARCH_VFP},
+   {"armv5txm",		ARM_ARCH_V5TxM,	 FPU_ARCH_VFP},
+   {"armv5te",		ARM_ARCH_V5TE,	 FPU_ARCH_VFP},
diff --git a/meta/recipes-devtools/binutils/binutils_2.22.bb b/meta/recipes-devtools/binutils/binutils_2.22.bb
index 8b058fe..d6d19a1 100644
--- a/meta/recipes-devtools/binutils/binutils_2.22.bb
+++ b/meta/recipes-devtools/binutils/binutils_2.22.bb
@@ -1,6 +1,6 @@
 require binutils.inc
 
-PR = "r5"
+PR = "r6"
 
 LIC_FILES_CHKSUM="\
     file://src-release;endline=17;md5=4830a9ef968f3b18dd5e9f2c00db2d35\
@@ -30,6 +30,7 @@ SRC_URI = "\
      file://libtool-rpath-fix.patch \
      file://clone-shadow.patch \
      file://binutils-powerpc-e5500.patch \
+     file://binutils-armv5e.patch \
      "
 
 SRC_URI[md5sum] = "ee0f10756c84979622b992a4a61ea3f5"
-- 
1.7.1

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell]

On Tue, 2012-04-03 at 14:47 -0500, Mark Hatle wrote:
> +MIPSPKGSFX_FPU - This defines if the floating point hardware is used by
> +this tuning.  A "-nf" is added to the PKGARCH in this case.

That's backwards, surely?

p.

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/3/12 2:51 PM, Phil Blundell wrote:
> On Tue, 2012-04-03 at 14:47 -0500, Mark Hatle wrote:
>> +MIPSPKGSFX_FPU - This defines if the floating point hardware is used by
>> +this tuning.  A "-nf" is added to the PKGARCH in this case.
>
> That's backwards, surely?

I can restate it to be more clear.. but we only add "-nf" if soft-float is 
defined.  If floating point hardware is enabled we set it to "".

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings

[Chris Larson]

On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> Add a new README that covers the basic items used with various cpu
> tunings.  The goal is to better help people understand the various
> settings and where things should or should not be defined.
>
> Corresponding architecture README files will also be generated to
> explain the particulars of architectural tunings.
>
> Also remove the default TUNE_PKGARCH setting in bitbake.conf.  This
> was done to ensure an error occurs if an invalid tuning is defined.
>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

This looks great, nice work on all of this. One question I have, which
isn't answered in the documentation you add, is when/where
ABIEXTENSION is utilized.
-- 
Christopher Larson

Re: [PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings

[Otavio Salvador]

On Tue, Apr 3, 2012 at 16:47, Mark Hatle <mark.hatle@windriver.com> wrote:
...
> +TUNE_ARCH - The GNU canonical arch for a specific architecture.  i.e.
> +arm, armeb, mips, mips64, etc.  This value is by bitbake to setup
> +configure. TUNE_ARCH definitions are specific to a given architecture.
> +They may be a single static definitions, or may be dynamically adjusted.
> +See each architectures README for details for that CPU family.

... This value /is used by bitbake/ ...

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 0/7 v2] Cleanup and document tuning files

[Saul Wold]

On 04/03/2012 01:07 PM, Mark Hatle wrote:
> (v2 only MIPS changed -- slight revision in the README to resolve comments
> from Phil Blundell)
>
> Also this fixes Yocto bugzilla # 2234.
>
> ----
>
> This is a documentation and cleanup of the tuning files.  Every tuning listed
> in AVAILTUNES was built for core-image-minimal!  The following is a list of
> failure conditions with explanations:
>
> ep9312 - binutils - gas fails to recognize -march=ep9312 as valid
>           (see binutils armv5e note below)
>
> cortexm3 - gcc reports the target CPU does not support ARM mode
> cortexr4 - gcc reports the target CPU does not support ARM mode
>
> mips64* - These are not yet supported by the OE compilers
>
> (SH is new and experimental, based on the existing tunings)
> sh3* - These are missing a patch in the compiler:
>         sh3-installfix-fixheaders.patch
>
> sh*eb - Big endian varieties are defined, but not supported
>
> x32 ABI variants for core2-64 and x86-64 - needs x32 layer
>
>
> Multilibs verified to work:
>
> x86-64&  x86
>
> ppce5500&  ppc64e5500
>
> ---
>
> Note armv5e&  binutils-gas:
>
> Finally there is a small patch to binutils gas that adds armv5e as a valid
> architecture, otherwise all of the armv5e* tunings fail, even though gcc
> says they are valid architectures.
>
> ---
>
> Future work:
>
> I'm still not completely happy with the ARM tunings, but it's too disruptive
> to change them at this time.  I'd like to move to something closer to how
> MIPS is configured.  Define various "variants" for the various tunings,
> instead of simply defining the ARMPKGARCH.  The current method prevents us
> from having a single build that can build packages optimized for armv5te and
> armv7a.  While this is not likely to be a huge problem for the time being,
> it may lead to problems for feed based systems that can support multiple
> ARM architecture families.
>
> The following changes since commit 38ee88e3b32b7444d7f1eb64f1b4f69a48fe0458:
>
>    gdb: build with expat, add missing RRECOMMENDS_gdbserver (2012-04-03 14:10:44 +0100)
>
> are available in the git repository at:
>    git://git.pokylinux.org/poky-contrib mhatle/tunings
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/tunings
>
> Mark Hatle (7):
>    conf/machine/include/README: Add readme to explain cpu tunings
>    conf/machine/include: Cleanup IA tunings to match README
>    conf/machine/include: Cleanup MIPS tunings to match README
>    conf/machine/include: Cleanup PowerPC tunings to match README
>    conf/machine/include: Cleanup ARM tunings to match README
>    conf/machine/include: Update SH tunings to match README
>    binutils: Inform binutils that armv5e really is valid!
>
>   meta/conf/bitbake.conf                             |    1 -
>   meta/conf/machine/include/README                   |   77 ++++++++++++++++++++
>   meta/conf/machine/include/arm/README               |   40 ++++++++++
>   meta/conf/machine/include/arm/arch-arm.inc         |    2 +-
>   meta/conf/machine/include/arm/arch-armv5.inc       |    2 +-
>   meta/conf/machine/include/arm/arch-armv7a.inc      |    6 +-
>   meta/conf/machine/include/ia32/README              |   24 ++++++
>   meta/conf/machine/include/ia32/arch-ia32.inc       |   26 ++++---
>   meta/conf/machine/include/mips/README              |   36 +++++++++
>   meta/conf/machine/include/mips/arch-mips.inc       |   38 +++++++++-
>   meta/conf/machine/include/powerpc/README           |   17 +++++
>   meta/conf/machine/include/powerpc/arch-powerpc.inc |   15 ++--
>   .../machine/include/powerpc/arch-powerpc64.inc     |    1 +
>   meta/conf/machine/include/sh/README                |   11 +++
>   meta/conf/machine/include/sh/arch-sh.inc           |    9 +++
>   meta/conf/machine/include/tune-c3.inc              |   12 +++-
>   meta/conf/machine/include/tune-core2.inc           |   16 +++--
>   meta/conf/machine/include/tune-cortexm3.inc        |    2 +-
>   meta/conf/machine/include/tune-cortexr4.inc        |    2 +-
>   meta/conf/machine/include/tune-i586.inc            |    8 +--
>   meta/conf/machine/include/tune-mips32.inc          |   17 +++--
>   meta/conf/machine/include/tune-ppc603e.inc         |    4 +-
>   meta/conf/machine/include/tune-ppce300c2.inc       |    2 +-
>   meta/conf/machine/include/tune-ppce500.inc         |   10 ++-
>   meta/conf/machine/include/tune-ppce500mc.inc       |    4 +-
>   meta/conf/machine/include/tune-ppce500v2.inc       |   10 ++-
>   meta/conf/machine/include/tune-ppce5500.inc        |    4 +-
>   meta/conf/machine/include/tune-sh3.inc             |   19 ++++-
>   meta/conf/machine/include/tune-sh4.inc             |   32 ++++++++-
>   .../binutils/binutils/binutils-armv5e.patch        |   20 +++++
>   meta/recipes-devtools/binutils/binutils_2.22.bb    |    3 +-
>   31 files changed, 401 insertions(+), 69 deletions(-)
>   create mode 100644 meta/conf/machine/include/README
>   create mode 100644 meta/conf/machine/include/arm/README
>   create mode 100644 meta/conf/machine/include/ia32/README
>   create mode 100644 meta/conf/machine/include/mips/README
>   create mode 100644 meta/conf/machine/include/powerpc/README
>   create mode 100644 meta/conf/machine/include/sh/README
>   create mode 100644 meta/conf/machine/include/sh/arch-sh.inc
>   create mode 100644 meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
>
Merged into OE-Core

Thanks
	Sau!

>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README

[Matthew McClintock]

On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> +ABIEXTENSION .= "${SPEABIEXTENSION}"
>
>  AVAILTUNES += "ppce500"
>  TUNE_FEATURES_tune-ppce500 = "m32 spe ppce500"
> +TUNE_PKGARCH_tune-ppce500 = "ppce500"
>  PACKAGE_EXTRA_ARCHS_tune-ppce500 = "ppce500"

meta/conf/machine/include/tune-ppce500.inc:PACKAGE_EXTRA_ARCHS_tune-ppce500
= "ppce500"
meta/conf/machine/include/tune-ppce500v2.inc:PACKAGE_EXTRA_ARCHS_tune-ppce500v2
= "ppce500v2"

Should these have ${PACKAGE_EXTRA_ARCHS_tune-powerpc} as well?

-M

Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README

[Matthew McClintock]

On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> --- a/meta/conf/machine/include/tune-ppce500.inc
> +++ b/meta/conf/machine/include/tune-ppce500.inc
> @@ -4,13 +4,17 @@ require conf/machine/include/powerpc/arch-powerpc.inc
>
>  TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
> -TUNE_PKGARCH_tune-ppce500 = "ppce500"
>
>  TUNEVALID[spe] = "Enable SPE ABI extensions"
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500", "spe" ], "-mabi=spe -mspe -mfloat-gprs=single", "", d)}"
> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500" , "spe" ], "ppc-efs", "", d)}"

Should these TARGET_FPU's be in a common file? Maybe some of these
other bits could be moved to a common file too? Setting this
TARGET_FPU above and TUNE_FEATURES in the same file seems redundant?
Or maybe this is for the multilib scenario and I'm missing
something...

Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README

[Mark Hatle]

On 4/4/12 1:02 PM, Matthew McClintock wrote:
> On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle<mark.hatle@windriver.com>  wrote:
>> +ABIEXTENSION .= "${SPEABIEXTENSION}"
>>
>>   AVAILTUNES += "ppce500"
>>   TUNE_FEATURES_tune-ppce500 = "m32 spe ppce500"
>> +TUNE_PKGARCH_tune-ppce500 = "ppce500"
>>   PACKAGE_EXTRA_ARCHS_tune-ppce500 = "ppce500"
>
> meta/conf/machine/include/tune-ppce500.inc:PACKAGE_EXTRA_ARCHS_tune-ppce500
> = "ppce500"
> meta/conf/machine/include/tune-ppce500v2.inc:PACKAGE_EXTRA_ARCHS_tune-ppce500v2
> = "ppce500v2"
>
> Should these have ${PACKAGE_EXTRA_ARCHS_tune-powerpc} as well?

No, the tunes for ppce500 and ppce500v2 are NOT compatible w/ powerpc or any 
other tunes (due to the SPE ABI interactions).

--Mark

> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README

[Mark Hatle]

On 4/4/12 1:03 PM, Matthew McClintock wrote:
> On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle<mark.hatle@windriver.com>  wrote:
>> --- a/meta/conf/machine/include/tune-ppce500.inc
>> +++ b/meta/conf/machine/include/tune-ppce500.inc
>> @@ -4,13 +4,17 @@ require conf/machine/include/powerpc/arch-powerpc.inc
>>
>>   TUNEVALID[ppce500] = "Enable ppce500 specific processor optimizations"
>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", "", d)}"
>> -TUNE_PKGARCH_tune-ppce500 = "ppce500"
>>
>>   TUNEVALID[spe] = "Enable SPE ABI extensions"
>> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}"
>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500", "spe" ], "-mabi=spe -mspe -mfloat-gprs=single", "", d)}"
>> +TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", [ "ppce500" , "spe" ], "ppc-efs", "", d)}"
>
> Should these TARGET_FPU's be in a common file? Maybe some of these
> other bits could be moved to a common file too? Setting this
> TARGET_FPU above and TUNE_FEATURES in the same file seems redundant?
> Or maybe this is for the multilib scenario and I'm missing
> something...

Normally I'd say yes, but the SPE settings are a bit unique for the ppce500[v2] 
series of CPUs.  Duplicating it shouldn't cause any unique problems to occur. 
(If future CPUs were to include the e500 or e500v2 SPE unit, we could consider 
moving the code.. or more likely renaming the spe element is to "spe-single" and 
"spe-double"...)

But at this point I believe they are dead ends....

--Mark

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Andreas Oberritter]

On 03.04.2012 21:47, Mark Hatle wrote:
> Cleanup the MIPS tunings to match the new tuning README file.  Also
> add a MIPS specific README file to explain the MIPS specifical
> architectural issues.
> 
> Finally correct the variant configurations within the tune-mips32.inc.

What was mipsel-oe-linux before now became mips32el-oe-linux, i.e.
tmp/work/mipsel-oe-linux now is tmp/work/mips32el-oe-linux. I'm not sure
what else broke.

Was this intentional?

Regards,
Andreas

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Khem Raj]

On Wed, Apr 4, 2012 at 3:10 PM, Andreas Oberritter <obi@opendreambox.org> wrote:
>
> What was mipsel-oe-linux before now became mips32el-oe-linux, i.e.
> tmp/work/mipsel-oe-linux now is tmp/work/mips32el-oe-linux. I'm not sure
> what else broke.
>
> Was this intentional?

I dont think so. mips-*-* in general indicates 32bit BE mips and
mipsel-*-* indicates
32bit LE mips so devicing mips32 and mips32el may be more explicit but
is not widely
used norm

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/4/12 11:17 PM, Khem Raj wrote:
> On Wed, Apr 4, 2012 at 3:10 PM, Andreas Oberritter<obi@opendreambox.org>  wrote:
>>
>> What was mipsel-oe-linux before now became mips32el-oe-linux, i.e.
>> tmp/work/mipsel-oe-linux now is tmp/work/mips32el-oe-linux. I'm not sure
>> what else broke.
>>
>> Was this intentional?
>
> I dont think so. mips-*-* in general indicates 32bit BE mips and
> mipsel-*-* indicates
> 32bit LE mips so devicing mips32 and mips32el may be more explicit but
> is not widely
> used norm

If that has changed it was certainly not intentional.  As Khem said the expected 
GNU canonical archs are:

mips-*-*
mipsel-*-*
mips64-*-*
mips64el-*-*

mips32 should work, but it was not expected to have changed.

Looking through, the GNU canonical arch should only match the above.  The 
namings in the tmp/work directory are strictly following the -package arch- 
namings, which don't affect system configuration.

I checked the logs from my test builds, and the mips32* reused the mips* builds 
because the canonical arch of the configuration and such were the same.

(Looked at config.log in a couple of packages...)  if you see mips32-* in the 
config.log, let me know.

--Mark

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Khem Raj]

On Fri, Apr 6, 2012 at 10:33 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 4/4/12 11:17 PM, Khem Raj wrote:
>>
>> On Wed, Apr 4, 2012 at 3:10 PM, Andreas Oberritter<obi@opendreambox.org>
>>  wrote:
>>>
>>>
>>> What was mipsel-oe-linux before now became mips32el-oe-linux, i.e.
>>> tmp/work/mipsel-oe-linux now is tmp/work/mips32el-oe-linux. I'm not sure
>>> what else broke.
>>>
>>> Was this intentional?
>>
>>
>> I dont think so. mips-*-* in general indicates 32bit BE mips and
>> mipsel-*-* indicates
>> 32bit LE mips so devicing mips32 and mips32el may be more explicit but
>> is not widely
>> used norm
>
>
> If that has changed it was certainly not intentional.  As Khem said the
> expected GNU canonical archs are:
>
> mips-*-*
> mipsel-*-*
> mips64-*-*
> mips64el-*-*
>
> mips32 should work, but it was not expected to have changed.
>
> Looking through, the GNU canonical arch should only match the above.  The
> namings in the tmp/work directory are strictly following the -package arch-
> namings, which don't affect system configuration.
>
> I checked the logs from my test builds, and the mips32* reused the mips*
> builds because the canonical arch of the configuration and such were the
> same.
>
> (Looked at config.log in a couple of packages...)  if you see mips32-* in
> the config.log, let me know.

see angstrom buildhistory its all filled with changes from mips -> mips32
its unwanted.

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

Just ran a local build with the qemumips machine, this is a standard mips32 target.

 From the configure line for eglibc:

/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure 
--build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux --prefix=/usr 
--exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc 
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib 
--includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info 
--mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking 
--with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips 
--enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug 
--without-gd --enable-clocale=gnu --enable-add-ons=ports,nptl,libidn,ports 
--with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include 
--without-selinux

The system is correctly setting the target to "mips-oe-linux".

I checked and bash is the same way.

So the canonical arch is correct, the mips32 is only the packaging arch.  It was 
always intended that the packaging arch be used in full on MIPS.  (This will 
allow us to specify mips32r2, mipsiii, mipsiv, etc as necessary if we expand the 
mips tunings.)

So right now, I don't see any failure conditions with an oe-core build.  (This 
is oe-core as of earlier today.)

--Mark

On 4/6/12 4:30 PM, Khem Raj wrote:
> On Fri, Apr 6, 2012 at 10:33 AM, Mark Hatle<mark.hatle@windriver.com>  wrote:
>> On 4/4/12 11:17 PM, Khem Raj wrote:
>>>
>>> On Wed, Apr 4, 2012 at 3:10 PM, Andreas Oberritter<obi@opendreambox.org>
>>>   wrote:
>>>>
>>>>
>>>> What was mipsel-oe-linux before now became mips32el-oe-linux, i.e.
>>>> tmp/work/mipsel-oe-linux now is tmp/work/mips32el-oe-linux. I'm not sure
>>>> what else broke.
>>>>
>>>> Was this intentional?
>>>
>>>
>>> I dont think so. mips-*-* in general indicates 32bit BE mips and
>>> mipsel-*-* indicates
>>> 32bit LE mips so devicing mips32 and mips32el may be more explicit but
>>> is not widely
>>> used norm
>>
>>
>> If that has changed it was certainly not intentional.  As Khem said the
>> expected GNU canonical archs are:
>>
>> mips-*-*
>> mipsel-*-*
>> mips64-*-*
>> mips64el-*-*
>>
>> mips32 should work, but it was not expected to have changed.
>>
>> Looking through, the GNU canonical arch should only match the above.  The
>> namings in the tmp/work directory are strictly following the -package arch-
>> namings, which don't affect system configuration.
>>
>> I checked the logs from my test builds, and the mips32* reused the mips*
>> builds because the canonical arch of the configuration and such were the
>> same.
>>
>> (Looked at config.log in a couple of packages...)  if you see mips32-* in
>> the config.log, let me know.
>
> see angstrom buildhistory its all filled with changes from mips ->  mips32
> its unwanted.
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 7/7] binutils: Inform binutils that armv5e really is valid!

[Khem Raj]

On Tue, Apr 3, 2012 at 12:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> A comment in the binutils sources indicate that it should support all of the
> -march= parameters that gcc supports.  The tune validations noted that
> gas failed on -march=armv5e.
>
> It is not yet clear to me if this patch belongs upstream or not.

We should fix gcc instead so it emits -march=armv5te if gcc was given
-march=armv5e when calling out assembler. -marmv5e is deprecated in
gas. This wont fly


>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>  .../binutils/binutils/binutils-armv5e.patch        |   20 ++++++++++++++++++++
>  meta/recipes-devtools/binutils/binutils_2.22.bb    |    3 ++-
>  2 files changed, 22 insertions(+), 1 deletions(-)
>  create mode 100644 meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
>
> diff --git a/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch b/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
> new file mode 100644
> index 0000000..4ac1a9c
> --- /dev/null
> +++ b/meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
> @@ -0,0 +1,20 @@
> +Add the armv5e architecture to binutils
> +
> +Binutils has a comment that indicates it is supposed to match gcc for all of
> +the support "-march=" settings, but it was lacking the armv5e setting.  This
> +was a simple way to add it, as thumb instructions shouldn't be generated by
> +the compiler anyway.
> +
> +Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> +
> +diff -urN binutils-2.22.orig/gas/config/tc-arm.c binutils-2.22/gas/config/tc-arm.c
> +--- binutils-2.22.orig/gas/config/tc-arm.c     2011-11-21 03:29:31.000000000 -0600
> ++++ binutils-2.22/gas/config/tc-arm.c  2012-04-03 12:07:42.230158760 -0500
> +@@ -22990,6 +22990,7 @@
> +   {"armv4t",          ARM_ARCH_V4T,    FPU_ARCH_FPA},
> +   {"armv4txm",                ARM_ARCH_V4TxM,  FPU_ARCH_FPA},
> +   {"armv5",           ARM_ARCH_V5,     FPU_ARCH_VFP},
> ++  {"armv5e",          ARM_ARCH_V5TE,   FPU_ARCH_VFP},
> +   {"armv5t",          ARM_ARCH_V5T,    FPU_ARCH_VFP},
> +   {"armv5txm",                ARM_ARCH_V5TxM,  FPU_ARCH_VFP},
> +   {"armv5te",         ARM_ARCH_V5TE,   FPU_ARCH_VFP},
> diff --git a/meta/recipes-devtools/binutils/binutils_2.22.bb b/meta/recipes-devtools/binutils/binutils_2.22.bb
> index 8b058fe..d6d19a1 100644
> --- a/meta/recipes-devtools/binutils/binutils_2.22.bb
> +++ b/meta/recipes-devtools/binutils/binutils_2.22.bb
> @@ -1,6 +1,6 @@
>  require binutils.inc
>
> -PR = "r5"
> +PR = "r6"
>
>  LIC_FILES_CHKSUM="\
>     file://src-release;endline=17;md5=4830a9ef968f3b18dd5e9f2c00db2d35\
> @@ -30,6 +30,7 @@ SRC_URI = "\
>      file://libtool-rpath-fix.patch \
>      file://clone-shadow.patch \
>      file://binutils-powerpc-e5500.patch \
> +     file://binutils-armv5e.patch \
>      "
>
>  SRC_URI[md5sum] = "ee0f10756c84979622b992a4a61ea3f5"
> --
> 1.7.1
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Andreas Oberritter]

On 07.04.2012 02:10, Mark Hatle wrote:
> Just ran a local build with the qemumips machine, this is a standard
> mips32 target.
> 
> From the configure line for eglibc:
> 
> /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
> --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
> --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
> --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
> --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
> --includedir=/usr/include --oldincludedir=/usr/include
> --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
> --disable-dependency-tracking
> --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
> --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
> --without-gd --enable-clocale=gnu
> --enable-add-ons=ports,nptl,libidn,ports
> --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
> --without-selinux
> 
> The system is correctly setting the target to "mips-oe-linux".
> 
> I checked and bash is the same way.
> 
> So the canonical arch is correct, the mips32 is only the packaging
> arch.  It was always intended that the packaging arch be used in full on
> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
> necessary if we expand the mips tunings.)

I don't think such a change should be done only few days before a
release. Until this patch was applied, the packaging arch has always
been mipsel, not mips32el. Please, revert or fix this!

> So right now, I don't see any failure conditions with an oe-core build. 
> (This is oe-core as of earlier today.)
> 
> --Mark

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/8/12 4:34 PM, Andreas Oberritter wrote:
> On 07.04.2012 02:10, Mark Hatle wrote:
>> Just ran a local build with the qemumips machine, this is a standard
>> mips32 target.
>>
>>  From the configure line for eglibc:
>>
>> /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
>> --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
>> --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
>> --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
>> --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
>> --includedir=/usr/include --oldincludedir=/usr/include
>> --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
>> --disable-dependency-tracking
>> --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
>> --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
>> --without-gd --enable-clocale=gnu
>> --enable-add-ons=ports,nptl,libidn,ports
>> --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
>> --without-selinux
>>
>> The system is correctly setting the target to "mips-oe-linux".
>>
>> I checked and bash is the same way.
>>
>> So the canonical arch is correct, the mips32 is only the packaging
>> arch.  It was always intended that the packaging arch be used in full on
>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>> necessary if we expand the mips tunings.)
>
> I don't think such a change should be done only few days before a
> release. Until this patch was applied, the packaging arch has always
> been mipsel, not mips32el. Please, revert or fix this!

This is easy to change to the previous behavior...  however it was a bug in the 
original implementation.

But again, I stress nothing changed except for the packaging arch... the way the 
packages are configured, compiled, installed remain the same, only the package 
arch has changed.  The only place that may be affected by this is the package 
feed mechanism.

To revert to the previous behavior, in the meta/conf/machine/include/tune-mips.inc:

--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -9,17 +9,17 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32"
  AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"

  TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
-MIPSPKGSFX_VARIANT_tune-mips32 = "mips32"
+MIPSPKGSFX_VARIANT_tune-mips32 = "mips"
  PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips mips32"

  TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
-MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
+MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"
  PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"

  TUNE_FEATURES_tune-mips32-nf = "${TUNE_FEATURES_tune-mips-nf} mips32"
-MIPSPKGSFX_VARIANT_tune-mips32-nf = "mips32"
+MIPSPKGSFX_VARIANT_tune-mips32-nf = "mips"
  PACKAGE_EXTRA_ARCHS_tune-mips32-nf = "mips-nf mips32-nf"

  TUNE_FEATURES_tune-mips32el-nf = "${TUNE_FEATURES_tune-mipsel-nf} mips32"
-MIPSPKGSFX_VARIANT_tune-mips32el-nf = "mips32el"
+MIPSPKGSFX_VARIANT_tune-mips32el-nf = "mipsel"
  PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = "mipsel-nf mips32el-nf"

Before I submit this patch though, I would like others to weigh in on the issue. 
  This was a mistake in the earlier version of the code.  The "variant" wasn't 
be set as it should have been.

The problem is that if you set the tune to "mips", you get the default compiler 
behavior.  However, if you set the tune to mips32, you get "-march=mips32" added 
to your CCARGS.  This will produce slightly different binaries, thus "mips" and 
mips32" are not equal.

--Mark

>> So right now, I don't see any failure conditions with an oe-core build.
>> (This is oe-core as of earlier today.)
>>
>> --Mark
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Koen Kooi]

Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:

> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>> On 07.04.2012 02:10, Mark Hatle wrote:
>>> Just ran a local build with the qemumips machine, this is a standard
>>> mips32 target.
>>> 
>>> From the configure line for eglibc:
>>> 
>>> /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
>>> --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
>>> --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
>>> --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
>>> --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
>>> --includedir=/usr/include --oldincludedir=/usr/include
>>> --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
>>> --disable-dependency-tracking
>>> --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
>>> --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
>>> --without-gd --enable-clocale=gnu
>>> --enable-add-ons=ports,nptl,libidn,ports
>>> --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
>>> --without-selinux
>>> 
>>> The system is correctly setting the target to "mips-oe-linux".
>>> 
>>> I checked and bash is the same way.
>>> 
>>> So the canonical arch is correct, the mips32 is only the packaging
>>> arch.  It was always intended that the packaging arch be used in full on
>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>>> necessary if we expand the mips tunings.)
>> 
>> I don't think such a change should be done only few days before a
>> release. Until this patch was applied, the packaging arch has always
>> been mipsel, not mips32el. Please, revert or fix this!
> 
> This is easy to change to the previous behavior...  however it was a bug in the original implementation.
> 
> But again, I stress nothing changed except for the packaging arch... the way the packages are configured, compiled, installed remain the same, only the package arch has changed. 

"only"

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 10:56 AM, Koen Kooi wrote:
>
> Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:
>
>> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>>> On 07.04.2012 02:10, Mark Hatle wrote:
>>>> Just ran a local build with the qemumips machine, this is a standard
>>>> mips32 target.
>>>>
>>>>  From the configure line for eglibc:
>>>>
>>>> /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
>>>> --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
>>>> --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
>>>> --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
>>>> --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
>>>> --includedir=/usr/include --oldincludedir=/usr/include
>>>> --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
>>>> --disable-dependency-tracking
>>>> --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
>>>> --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
>>>> --without-gd --enable-clocale=gnu
>>>> --enable-add-ons=ports,nptl,libidn,ports
>>>> --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
>>>> --without-selinux
>>>>
>>>> The system is correctly setting the target to "mips-oe-linux".
>>>>
>>>> I checked and bash is the same way.
>>>>
>>>> So the canonical arch is correct, the mips32 is only the packaging
>>>> arch.  It was always intended that the packaging arch be used in full on
>>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>>>> necessary if we expand the mips tunings.)
>>>
>>> I don't think such a change should be done only few days before a
>>> release. Until this patch was applied, the packaging arch has always
>>> been mipsel, not mips32el. Please, revert or fix this!
>>
>> This is easy to change to the previous behavior...  however it was a bug in the original implementation.
>>
>> But again, I stress nothing changed except for the packaging arch... the way the packages are configured, compiled, installed remain the same, only the package arch has changed.
>
> "only"

Yes, only.  The package arch is used by the feed system and the build of the 
images.  I verified the images were still being generated corrected.  I did not 
verify anything within external package feeds, as I have no way to easily do this.

If anything else in the system is using the package arch as a key, then it's 
broken.  The configure arch, the tuning, and similar are all reasonable things 
to use, but the package arch is arbitrary.  We may have a fairly defined, 
defacto set, but they really are arbitrary and should not affect any software -- 
other then those directly working with the package feeds.

--Mark

>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Andreas Oberritter]

On 09.04.2012 17:17, Mark Hatle wrote:
> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>> On 07.04.2012 02:10, Mark Hatle wrote:
>>> Just ran a local build with the qemumips machine, this is a standard
>>> mips32 target.
>>>
>>>  From the configure line for eglibc:
>>>
>>> /msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/work/mips32-oe-linux/eglibc-2.13-r23+svnr15508/eglibc-2_13/libc/configure
>>>
>>> --build=x86_64-linux --host=mips-oe-linux --target=mips-oe-linux
>>> --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
>>> --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
>>> --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
>>> --includedir=/usr/include --oldincludedir=/usr/include
>>> --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
>>> --disable-dependency-tracking
>>> --with-libtool-sysroot=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips
>>>
>>> --enable-kernel=2.6.16 --without-cvs --disable-profile --disable-debug
>>> --without-gd --enable-clocale=gnu
>>> --enable-add-ons=ports,nptl,libidn,ports
>>> --with-headers=/msp-lpggp1/mhatle/git/oe-core/build-mips32/tmp-eglibc/sysroots/qemumips/usr/include
>>>
>>> --without-selinux
>>>
>>> The system is correctly setting the target to "mips-oe-linux".
>>>
>>> I checked and bash is the same way.
>>>
>>> So the canonical arch is correct, the mips32 is only the packaging
>>> arch.  It was always intended that the packaging arch be used in full on
>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>>> necessary if we expand the mips tunings.)
>>
>> I don't think such a change should be done only few days before a
>> release. Until this patch was applied, the packaging arch has always
>> been mipsel, not mips32el. Please, revert or fix this!
> 
> This is easy to change to the previous behavior...  however it was a bug
> in the original implementation.
> 
> But again, I stress nothing changed except for the packaging arch... the
> way the packages are configured, compiled, installed remain the same,
> only the package arch has changed.  The only place that may be affected
> by this is the package feed mechanism.

I think breaking package feeds in such a way is one of the worst things
to do in OE.

> To revert to the previous behavior, in the
> meta/conf/machine/include/tune-mips.inc:
> 
> --- a/meta/conf/machine/include/tune-mips32.inc
> +++ b/meta/conf/machine/include/tune-mips32.inc
> @@ -9,17 +9,17 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES",
> "mips32"
>  AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
> 
>  TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
> -MIPSPKGSFX_VARIANT_tune-mips32 = "mips32"
> +MIPSPKGSFX_VARIANT_tune-mips32 = "mips"
>  PACKAGE_EXTRA_ARCHS_tune-mips32 = "mips mips32"
> 
>  TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
> -MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
> +MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"
>  PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"
                                               ^^^^^^^^
I don't think this is correct, in all four cases, because no packages
will have that arch.

>  TUNE_FEATURES_tune-mips32-nf = "${TUNE_FEATURES_tune-mips-nf} mips32"
> -MIPSPKGSFX_VARIANT_tune-mips32-nf = "mips32"
> +MIPSPKGSFX_VARIANT_tune-mips32-nf = "mips"
>  PACKAGE_EXTRA_ARCHS_tune-mips32-nf = "mips-nf mips32-nf"
> 
>  TUNE_FEATURES_tune-mips32el-nf = "${TUNE_FEATURES_tune-mipsel-nf} mips32"
> -MIPSPKGSFX_VARIANT_tune-mips32el-nf = "mips32el"
> +MIPSPKGSFX_VARIANT_tune-mips32el-nf = "mipsel"
>  PACKAGE_EXTRA_ARCHS_tune-mips32el-nf = "mipsel-nf mips32el-nf"
> 
> Before I submit this patch though, I would like others to weigh in on
> the issue.  This was a mistake in the earlier version of the code.  The
> "variant" wasn't be set as it should have been.
> 
> The problem is that if you set the tune to "mips", you get the default
> compiler behavior.

According to the gcc docs, there is no "mips" ISA name. Valid names are:
`mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
`mips64r2'. Therefore I don't understand why "mips" should default to
anything else, if it was an alias for mips32 before.

>  However, if you set the tune to mips32, you get
> "-march=mips32" added to your CCARGS.  This will produce slightly
> different binaries, thus "mips" and mips32" are not equal.

Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
mips32el, so this probably broke, too.
meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
work, e.g. EXTRA_OECONF_mipsel etc.? How about
meta/recipes-qt/qt4/qt4_arch.inc?

Whatever the answers are, the most important point is that it's the
worst point in time to do such a change. We should rather discuss it
after the release, if at all.

Regards,
Andreas

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 3:06 PM, Andreas Oberritter wrote:
> On 09.04.2012 17:17, Mark Hatle wrote:
>> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>>> On 07.04.2012 02:10, Mark Hatle wrote:
>>>> Just ran a local build with the qemumips machine, this is a standard
>>>> mips32 target.
>>>>

...

>>>> So the canonical arch is correct, the mips32 is only the packaging
>>>> arch.  It was always intended that the packaging arch be used in full on
>>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>>>> necessary if we expand the mips tunings.)
>>>
>>> I don't think such a change should be done only few days before a
>>> release. Until this patch was applied, the packaging arch has always
>>> been mipsel, not mips32el. Please, revert or fix this!
>>
>> This is easy to change to the previous behavior...  however it was a bug
>> in the original implementation.
>>
>> But again, I stress nothing changed except for the packaging arch... the
>> way the packages are configured, compiled, installed remain the same,
>> only the package arch has changed.  The only place that may be affected
>> by this is the package feed mechanism.
>
> I think breaking package feeds in such a way is one of the worst things
> to do in OE.
>
>> To revert to the previous behavior, in the
>> meta/conf/machine/include/tune-mips.inc:
>>

...

>>   TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
>> -MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
>> +MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"
>>   PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"
>                                                 ^^^^^^^^
> I don't think this is correct, in all four cases, because no packages
> will have that arch.
>

...

>> Before I submit this patch though, I would like others to weigh in on
>> the issue.  This was a mistake in the earlier version of the code.  The
>> "variant" wasn't be set as it should have been.
>>
>> The problem is that if you set the tune to "mips", you get the default
>> compiler behavior.
>
> According to the gcc docs, there is no "mips" ISA name. Valid names are:
> `mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
> `mips64r2'. Therefore I don't understand why "mips" should default to
> anything else, if it was an alias for mips32 before.
>

We have two sets of available tunings:

"mips" and "mips32" tunings.. (add el and -nf variants)

These are -different- tunings and today the only way to notice the difference is 
based on the package arch.  The package arch is NOT the target ISA.  It's an 
arbitrary string "we" have come up with to let people know the architecture, ABI 
and optimizations used in producing specific software.  "mips" indicates that 
it's using the default mips compiler options, whatever those may be.  While 
mips32 says it is specifically tuned to the mips32 architecture settings.

I honestly have no idea what the default compiler settings for mips are, but the 
point is the tunings are different.  If you want the "MIPS" tune, you may not be 
able to run the items compiled with the -march=mips32 option.  We have to have a 
way to reconcile this.

>>   However, if you set the tune to mips32, you get
>> "-march=mips32" added to your CCARGS.  This will produce slightly
>> different binaries, thus "mips" and mips32" are not equal.
>
> Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
> mips32el, so this probably broke, too.
> meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
> work, e.g. EXTRA_OECONF_mipsel etc.? How about
> meta/recipes-qt/qt4/qt4_arch.inc?

Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is the 
case then "mips" or "mipsel" is the canonical arch.  Again, we do NOT use the 
package arch for these settings!

Below are the overrides and related elements from the bitbake.conf file:

OVERRIDES = 
"${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
DISTROOVERRIDES ?= "${@d.getVar('DISTRO', True) or ''}"
MACHINEOVERRIDES ?= "${MACHINE}"

# Used by canadian-cross to handle string conversions on TARGET_ARCH where needed
TRANSLATED_TARGET_ARCH ??= "${@d.getVar('TARGET_ARCH', True).replace("_", "-")}"

TARGET_ARCH = "${TUNE_ARCH}"

So my reading of this is that, unless overriden somewhere outside of 
bitbake.conf, the override does include the TUNE_ARCH, via the TARGET_ARCH, via 
the TRANSLATED_TARGET_ARCH.

>
> Whatever the answers are, the most important point is that it's the
> worst point in time to do such a change. We should rather discuss it
> after the release, if at all.

In order to resolve this consider the following:

We have two tunes, "mips" and "mips32", the difference being the -march=mips32 
in the later case.

In order to support both tunes, we need to have a way to differentiate between 
them on a package arch basis or we end up in a situation where we have two 
packages with different contents and no way to tell them apart.

In order to reconcile the above, the three primary options are see are:

*) Define only mips or mips32 tune, but not both -- producing "mips" as the 
package arch.  (But then what do we do in the future about mips1, mips2, mips3, 
mips4, mips32r2?)

*) Revert the behavior and have two tunes that produce the identical filename 
package with different contents and deal with this in the future.

*) Keep it as it is now and produce mips and mips32 packages based on the 
specific tunings defined by the user

We have a bug, I believe we need to fix it.. first or third options "fix" the 
bug.. the second option retains the bug to be fixed in the future.

If you have an alternative to the above, I'm interested -- I just really don't 
like the "leave the bug" option.

And just to be extra clear, I consider it a defect if we can produce a package 
with the same name for two different tune settings.. (the exception being the 
hell that is ARM and thumb namings.)

--Mark

> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Andreas Oberritter]

On 09.04.2012 22:25, Mark Hatle wrote:
> On 4/9/12 3:06 PM, Andreas Oberritter wrote:
>> On 09.04.2012 17:17, Mark Hatle wrote:
>>> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>>>> On 07.04.2012 02:10, Mark Hatle wrote:
>>>>> Just ran a local build with the qemumips machine, this is a standard
>>>>> mips32 target.
>>>>>
> 
> ...
> 
>>>>> So the canonical arch is correct, the mips32 is only the packaging
>>>>> arch.  It was always intended that the packaging arch be used in
>>>>> full on
>>>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv,
>>>>> etc as
>>>>> necessary if we expand the mips tunings.)
>>>>
>>>> I don't think such a change should be done only few days before a
>>>> release. Until this patch was applied, the packaging arch has always
>>>> been mipsel, not mips32el. Please, revert or fix this!
>>>
>>> This is easy to change to the previous behavior...  however it was a bug
>>> in the original implementation.
>>>
>>> But again, I stress nothing changed except for the packaging arch... the
>>> way the packages are configured, compiled, installed remain the same,
>>> only the package arch has changed.  The only place that may be affected
>>> by this is the package feed mechanism.
>>
>> I think breaking package feeds in such a way is one of the worst things
>> to do in OE.
>>
>>> To revert to the previous behavior, in the
>>> meta/conf/machine/include/tune-mips.inc:
>>>
> 
> ...
> 
>>>   TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
>>> -MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
>>> +MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"
>>>   PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"
>>                                                 ^^^^^^^^
>> I don't think this is correct, in all four cases, because no packages
>> will have that arch.
>>
> 
> ...
> 
>>> Before I submit this patch though, I would like others to weigh in on
>>> the issue.  This was a mistake in the earlier version of the code.  The
>>> "variant" wasn't be set as it should have been.
>>>
>>> The problem is that if you set the tune to "mips", you get the default
>>> compiler behavior.
>>
>> According to the gcc docs, there is no "mips" ISA name. Valid names are:
>> `mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
>> `mips64r2'. Therefore I don't understand why "mips" should default to
>> anything else, if it was an alias for mips32 before.
>>
> 
> We have two sets of available tunings:
> 
> "mips" and "mips32" tunings.. (add el and -nf variants)
> 
> These are -different- tunings and today the only way to notice the
> difference is based on the package arch.  The package arch is NOT the
> target ISA.  It's an arbitrary string "we" have come up with to let
> people know the architecture, ABI and optimizations used in producing
> specific software.  "mips" indicates that it's using the default mips
> compiler options, whatever those may be.  While mips32 says it is
> specifically tuned to the mips32 architecture settings.
> 
> I honestly have no idea what the default compiler settings for mips are,
> but the point is the tunings are different.  If you want the "MIPS"
> tune, you may not be able to run the items compiled with the
> -march=mips32 option.  We have to have a way to reconcile this.
> 
>>>   However, if you set the tune to mips32, you get
>>> "-march=mips32" added to your CCARGS.  This will produce slightly
>>> different binaries, thus "mips" and mips32" are not equal.
>>
>> Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
>> mips32el, so this probably broke, too.
>> meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
>> work, e.g. EXTRA_OECONF_mipsel etc.? How about
>> meta/recipes-qt/qt4/qt4_arch.inc?
> 
> Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is
> the case then "mips" or "mipsel" is the canonical arch.  Again, we do
> NOT use the package arch for these settings!
> 
> Below are the overrides and related elements from the bitbake.conf file:
> 
> OVERRIDES =
> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
> 
> DISTROOVERRIDES ?= "${@d.getVar('DISTRO', True) or ''}"
> MACHINEOVERRIDES ?= "${MACHINE}"
> 
> # Used by canadian-cross to handle string conversions on TARGET_ARCH
> where needed
> TRANSLATED_TARGET_ARCH ??= "${@d.getVar('TARGET_ARCH',
> True).replace("_", "-")}"
> 
> TARGET_ARCH = "${TUNE_ARCH}"
> 
> So my reading of this is that, unless overriden somewhere outside of
> bitbake.conf, the override does include the TUNE_ARCH, via the
> TARGET_ARCH, via the TRANSLATED_TARGET_ARCH.
> 
>>
>> Whatever the answers are, the most important point is that it's the
>> worst point in time to do such a change. We should rather discuss it
>> after the release, if at all.
> 
> In order to resolve this consider the following:
> 
> We have two tunes, "mips" and "mips32", the difference being the
> -march=mips32 in the later case.
> 
> In order to support both tunes, we need to have a way to differentiate
> between them on a package arch basis or we end up in a situation where
> we have two packages with different contents and no way to tell them apart.
> 
> In order to reconcile the above, the three primary options are see are:
> 
> *) Define only mips or mips32 tune, but not both -- producing "mips" as
> the package arch.  (But then what do we do in the future about mips1,
> mips2, mips3, mips4, mips32r2?)
> 
> *) Revert the behavior and have two tunes that produce the identical
> filename package with different contents and deal with this in the future.
> 
> *) Keep it as it is now and produce mips and mips32 packages based on
> the specific tunings defined by the user
> 
> We have a bug, I believe we need to fix it.. first or third options
> "fix" the bug.. the second option retains the bug to be fixed in the
> future.
> 
> If you have an alternative to the above, I'm interested -- I just really
> don't like the "leave the bug" option.
> 
> And just to be extra clear, I consider it a defect if we can produce a
> package with the same name for two different tune settings.. (the
> exception being the hell that is ARM and thumb namings.)

qemumips uses "mips32", so let's drop the "mips" tune for now and defer
any other changes until after the release.

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 3:25 PM, Mark Hatle wrote:
> On 4/9/12 3:06 PM, Andreas Oberritter wrote:
>> On 09.04.2012 17:17, Mark Hatle wrote:
>>> On 4/8/12 4:34 PM, Andreas Oberritter wrote:
>>>> On 07.04.2012 02:10, Mark Hatle wrote:
>>>>> Just ran a local build with the qemumips machine, this is a standard
>>>>> mips32 target.
>>>>>
>
> ...
>
>>>>> So the canonical arch is correct, the mips32 is only the packaging
>>>>> arch.  It was always intended that the packaging arch be used in full on
>>>>> MIPS.  (This will allow us to specify mips32r2, mipsiii, mipsiv, etc as
>>>>> necessary if we expand the mips tunings.)
>>>>
>>>> I don't think such a change should be done only few days before a
>>>> release. Until this patch was applied, the packaging arch has always
>>>> been mipsel, not mips32el. Please, revert or fix this!
>>>
>>> This is easy to change to the previous behavior...  however it was a bug
>>> in the original implementation.
>>>
>>> But again, I stress nothing changed except for the packaging arch... the
>>> way the packages are configured, compiled, installed remain the same,
>>> only the package arch has changed.  The only place that may be affected
>>> by this is the package feed mechanism.
>>
>> I think breaking package feeds in such a way is one of the worst things
>> to do in OE.
>>
>>> To revert to the previous behavior, in the
>>> meta/conf/machine/include/tune-mips.inc:
>>>
>
> ...
>
>>>    TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"
>>> -MIPSPKGSFX_VARIANT_tune-mips32el = "mips32el"
>>> +MIPSPKGSFX_VARIANT_tune-mips32el = "mipsel"
>>>    PACKAGE_EXTRA_ARCHS_tune-mips32el = "mipsel mips32el"
>>                                                  ^^^^^^^^
>> I don't think this is correct, in all four cases, because no packages
>> will have that arch.
>>
>
> ...
>
>>> Before I submit this patch though, I would like others to weigh in on
>>> the issue.  This was a mistake in the earlier version of the code.  The
>>> "variant" wasn't be set as it should have been.
>>>
>>> The problem is that if you set the tune to "mips", you get the default
>>> compiler behavior.
>>
>> According to the gcc docs, there is no "mips" ISA name. Valid names are:
>> `mips1', `mips2', `mips3', `mips4', `mips32', `mips32r2', `mips64' and
>> `mips64r2'. Therefore I don't understand why "mips" should default to
>> anything else, if it was an alias for mips32 before.
>>
>
> We have two sets of available tunings:
>
> "mips" and "mips32" tunings.. (add el and -nf variants)
>
> These are -different- tunings and today the only way to notice the difference is
> based on the package arch.  The package arch is NOT the target ISA.  It's an
> arbitrary string "we" have come up with to let people know the architecture, ABI
> and optimizations used in producing specific software.  "mips" indicates that
> it's using the default mips compiler options, whatever those may be.  While
> mips32 says it is specifically tuned to the mips32 architecture settings.
>
> I honestly have no idea what the default compiler settings for mips are, but the
> point is the tunings are different.  If you want the "MIPS" tune, you may not be
> able to run the items compiled with the -march=mips32 option.  We have to have a
> way to reconcile this.

I did some further digging into the GCC configuration.

The default configuration is defined in the various defines:

#define _R3000 1
#define __mips_fpr 32
#define _MIPS_ARCH_MIPS1 1
#define _MIPS_ARCH "mips1"
#define _MIPS_TUNE_MIPS1 1
#define _MIPS_TUNE "mips1"
#define __mips 1
#define _MIPS_ISA _MIPS_ISA_MIPS1

The default is defined for the MIPS1 architecture.

The -march=mips32 changes the above to:

#define __mips__ 1
#define _mips 1
#define mips 1
#define __R3000 1
#define __R3000__ 1
#define R3000 1
#define _R3000 1
#define __mips_fpr 32
#define _MIPS_ARCH_MIPS32 1
#define _MIPS_ARCH "mips32"
#define _MIPS_TUNE_MIPS32 1
#define _MIPS_TUNE "mips32"
#define __mips 32
#define __mips_isa_rev 1
#define _MIPS_ISA _MIPS_ISA_MIPS32

Internally in gcc the different between the two is processor optimizations 
change from the R3000 to the MIPS 4Kc, and PTF_AVOID_BRANCHLIKELY is defined.

    PTF_AVOID_BRANCHLIKELY
         Set if it is usually not profitable to use branch-likely instructions
         for this target, typically because the branches are always predicted
         taken and so incur a large overhead when not taken.

So there will in fact be a difference in the generated binaries.

>>>    However, if you set the tune to mips32, you get
>>> "-march=mips32" added to your CCARGS.  This will produce slightly
>>> different binaries, thus "mips" and mips32" are not equal.
>>
>> Btw, meta/recipes-core/eglibc/eglibc-ld.inc doesn't know about mips32 or
>> mips32el, so this probably broke, too.
>> meta/recipes-devtools/gdb/gdb-common.inc likewise. Do overrides still
>> work, e.g. EXTRA_OECONF_mipsel etc.? How about
>> meta/recipes-qt/qt4/qt4_arch.inc?
>
> Overrides are on the GNU canonical arch (TUNE_ARCH) correct?  If that is the
> case then "mips" or "mipsel" is the canonical arch.  Again, we do NOT use the
> package arch for these settings!
>
> Below are the overrides and related elements from the bitbake.conf file:
>
> OVERRIDES =
> "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
> DISTROOVERRIDES ?= "${@d.getVar('DISTRO', True) or ''}"
> MACHINEOVERRIDES ?= "${MACHINE}"
>
> # Used by canadian-cross to handle string conversions on TARGET_ARCH where needed
> TRANSLATED_TARGET_ARCH ??= "${@d.getVar('TARGET_ARCH', True).replace("_", "-")}"
>
> TARGET_ARCH = "${TUNE_ARCH}"
>
> So my reading of this is that, unless overriden somewhere outside of
> bitbake.conf, the override does include the TUNE_ARCH, via the TARGET_ARCH, via
> the TRANSLATED_TARGET_ARCH.
>
>>
>> Whatever the answers are, the most important point is that it's the
>> worst point in time to do such a change. We should rather discuss it
>> after the release, if at all.
>
> In order to resolve this consider the following:
>
> We have two tunes, "mips" and "mips32", the difference being the -march=mips32
> in the later case.
>
> In order to support both tunes, we need to have a way to differentiate between
> them on a package arch basis or we end up in a situation where we have two
> packages with different contents and no way to tell them apart.
>
> In order to reconcile the above, the three primary options are see are:
>
> *) Define only mips or mips32 tune, but not both -- producing "mips" as the
> package arch.  (But then what do we do in the future about mips1, mips2, mips3,
> mips4, mips32r2?)
>
> *) Revert the behavior and have two tunes that produce the identical filename
> package with different contents and deal with this in the future.
>
> *) Keep it as it is now and produce mips and mips32 packages based on the
> specific tunings defined by the user
>
> We have a bug, I believe we need to fix it.. first or third options "fix" the
> bug.. the second option retains the bug to be fixed in the future.
>
> If you have an alternative to the above, I'm interested -- I just really don't
> like the "leave the bug" option.
>
> And just to be extra clear, I consider it a defect if we can produce a package
> with the same name for two different tune settings.. (the exception being the
> hell that is ARM and thumb namings.)
>
> --Mark
>
>> Regards,
>> Andreas
>>
>> _______________________________________________
>> 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

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell]

On Mon, 2012-04-09 at 15:25 -0500, Mark Hatle wrote:
> And just to be extra clear, I consider it a defect if we can produce a package 
> with the same name for two different tune settings.. (the exception being the 
> hell that is ARM and thumb namings.)

While you might consider that a defect (and it probably is a defensible
position to do so), it hasn't historically been considered such in OE.
The PACKAGE_ARCH value has, traditionally, been concerned purely with
ISA and ABI (i.e. answering the question "can I execute this code?")
rather than optimisations.

For example, the tune-arm926ejs.inc and tune-xscale.inc files in current
oe-core both end up setting PACKAGE_ARCH to "armv5tte" (sic).  But those
are quite different processors and have different tuning requirements,
so the binaries you get are unlikely to be the same.  If you were to
take the view that the PACKAGE_ARCH must uniquely identify one set of
binaries then obviously each of these tunings (and probably all the ARM
cpu-specific tunings) would need to set PACKAGE_ARCH to some unique
value.

p.

ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 4:03 PM, Phil Blundell wrote:
> On Mon, 2012-04-09 at 15:25 -0500, Mark Hatle wrote:
>> And just to be extra clear, I consider it a defect if we can produce a package
>> with the same name for two different tune settings.. (the exception being the
>> hell that is ARM and thumb namings.)
>
> While you might consider that a defect (and it probably is a defensible
> position to do so), it hasn't historically been considered such in OE.
> The PACKAGE_ARCH value has, traditionally, been concerned purely with
> ISA and ABI (i.e. answering the question "can I execute this code?")
> rather than optimisations.
>
> For example, the tune-arm926ejs.inc and tune-xscale.inc files in current
> oe-core both end up setting PACKAGE_ARCH to "armv5tte" (sic).  But those
> are quite different processors and have different tuning requirements,
> so the binaries you get are unlikely to be the same.  If you were to
> take the view that the PACKAGE_ARCH must uniquely identify one set of
> binaries then obviously each of these tunings (and probably all the ARM
> cpu-specific tunings) would need to set PACKAGE_ARCH to some unique
> value.

I do, and thus the hell that is ARM.  I could not currently generate a single 
package feed that work would on a variety of devices (like a traditional 
workstaton/server Linux OS would.)  While this isn't a big issue in the embedded 
space where we should hopefully be aware of the tunings and configuration were 
are using, it is still a problem.  As the systems get larger, the requirement 
for common pages feeds increases, leading to the problem being, well a problem. 
  (ARM is starting to be considered for Carrier Grade systems, many of which 
have very common requirements to traditional server Linux.  A set of established 
binaries and the vendors just want to drop in optimized applications.)

On ARM what we currently have defined is:
(tune) - (package arch)

arm1136jfs - armv6-vfp
arm920t - armv4t
arm926ejs - armv5te
arm9tdmi - armv4t
armv4b - armv4b
armv4tb - armv4tb
armv4 - armv4
armv4t - armv4t
armv5b - armv5b
armv5b-vfp - armv5b-vfp
armv5eb - armv5eb
armv5eb-vfp - armv5eb-vfp
armv5ehfb-vfp - armv5ehfb-vfp
armv5ehf-vfp - armv5ehf-vfp
armv5e-vfp - armv5e-vfp
armv5hfb-vfp - armv5hfb-vfp
armv5hf-vfp - armv5hf-vfp
armv5tb - armv5tb
armv5tb-vfp - armv5b-vfp
armv5teb - armv5teb
armv5teb-vfp - armv5teb-vfp
armv5tehfb-vfp - armv5tehfb-vfp
armv5tehf-vfp - armv5tehf-vfp
armv5te - armv5te
armv5te-vfp - armv5te-vfp
armv5thfb-vfp - armv5hfb-vfp
armv5thf-vfp - armv5hf-vfp
armv5 - armv5
armv5t - armv5t
armv5t-vfp - armv5-vfp
armv5-vfp - armv5-vfp
armv6b - armv6b-vfp
armv6hfb - armv6hfb-vfp
armv6hf - armv6hf-vfp
armv6tb - armv6tb-vfp
armv6thfb - armv6thfb-vfp
armv6thf - armv6thf-vfp
armv6 - armv6-vfp
armv6t - armv6t-vfp
armv7ab-neon - armv7ab-vfp-neon
armv7ab - armv7ab-vfp
armv7ahfb-neon - armv7ahfb-vfp-neon
armv7ahfb - armv7ahfb-vfp
armv7ahf-neon - armv7ahf-vfp-neon
armv7ahf - armv7ahf-vfp
armv7a-neon - armv7a-vfp-neon
armv7atb-neon - armv7ab-vfp-neon
armv7atb - armv7ab-vfp
armv7athfb - armv7ahfb-vfp
armv7athf-neon - armv7ahf-vfp-neon
armv7athf - armv7ahf-vfp
armv7a - armv7a-vfp
armv7at-neon - armv7a-vfp-neon
armv7at - armv7a-vfp
cortexa8hf-neon - armv7ahf-vfp-neon
cortexa8hf - armv7ahf-vfp
cortexa8-neon - armv7a-vfp-neon
cortexa8thf - armv7ahf-vfp
cortexa8 - armv7a-vfp
cortexa8t - armv7a-vfp
cortexa9hf-neon - armv7ahf-vfp-neon
cortexa9hf - armv7ahf-vfp
cortexa9-neon - armv7a-vfp-neon
cortexa9thf - armv7ahf-vfp
cortexa9 - armv7a-vfp
cortexa9t - armv7a-vfp
cortexm1 - armv7a-vfp
cortexm3 - armv7m-vfp
cortexr4 - armv7r-vfp
ep9312 - ep9312
iwmmxt - iwmmxt
strongarm - armv4

Add in to that one of the tunings -- not indicated by the package arch of thumb 
enabled or not, and its difficult to know exactly what is in a package without 
extracting and examining it.  But I consider this to be a quirk of the ARM 
architecture as implemented in OE.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell]

On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:
> I do, and thus the hell that is ARM.  I could not currently generate a single 
> package feed that work would on a variety of devices (like a traditional 
> workstaton/server Linux OS would.) 

Well, actually, you could in fact do exactly that.  What you couldn't
necessarily do with the tunings as they exist right now is generate a
package feed which is optimised for (as opposed to "works on") all those
devices.  But it isn't clear to me that you could do that with a
"traditional workstaton/server" kind of distribution either.  In the x86
world, for example, the majority of the big distros do not bother to
ship individually-tuned binaries for different processor types,
certainly not for the entire distribution.

>Add in to that one of the tunings -- not indicated by the package arch
>of thumb enabled or not

There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
Firstly, it's irrelevant: on v5T or newer, the question of whether a
given package is using Thumb-state or not has no ABI impact and there is
no reason for anyone to care at a compatibility level.  Second, it may
be unpredictable: the compiler is at liberty (although current versions
of gcc don't exploit this latitude) to switch arbitrarily between
ARM-state and Thumb-state as it sees fit to get the best performance.
And thirdly, it's just another piece of distro policy in the same way as
compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
is.

p.

Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/9/12 4:30 PM, Phil Blundell wrote:
> On Mon, 2012-04-09 at 16:21 -0500, Mark Hatle wrote:
>> I do, and thus the hell that is ARM.  I could not currently generate a single
>> package feed that work would on a variety of devices (like a traditional
>> workstaton/server Linux OS would.)
>
> Well, actually, you could in fact do exactly that.  What you couldn't
> necessarily do with the tunings as they exist right now is generate a
> package feed which is optimised for (as opposed to "works on") all those
> devices.  But it isn't clear to me that you could do that with a
> "traditional workstaton/server" kind of distribution either.  In the x86
> world, for example, the majority of the big distros do not bother to
> ship individually-tuned binaries for different processor types,
> certainly not for the entire distribution.

Depends on the distribution and reasons for these feeds.  What is typical is 
that a base distribution will be generated for a common compatible (reasonable) 
architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl, 
etc) for the target arch, i.e. armv7a.  Then you have a couple of packages 
hand-tuned for size, speed, or other that define or not thumb and add even a 
higher level of optimization.  It's possible, folks do it today.. but it's not 
always obvious.  (I have existing customers today that run a mix like I 
described through their own package feed like system.  They really don't care at 
all that the core system is tuned for a given processor -- they only care that 
their specific applications and certain areas are specifically tuned to their 
use-cases.)  Note, this is not what I would consider a typical use-case!

>> Add in to that one of the tunings -- not indicated by the package arch
>> of thumb enabled or not
>
> There are multiple reasons why this isn't indicated by the PACKAGE_ARCH.
> Firstly, it's irrelevant: on v5T or newer, the question of whether a
> given package is using Thumb-state or not has no ABI impact and there is
> no reason for anyone to care at a compatibility level.  Second, it may
> be unpredictable: the compiler is at liberty (although current versions
> of gcc don't exploit this latitude) to switch arbitrarily between
> ARM-state and Thumb-state as it sees fit to get the best performance.
> And thirdly, it's just another piece of distro policy in the same way as
> compiling for -O2 vs -Os (which we also don't encode into PACKAGE_ARCH)
> is.

I agree, on ARM the tunings and optimizations between regular and thumb do not 
impact the ABI what-so-ever.  And so far compilers have to be explicitly set to 
do thumb or tranditional ARM mode.. so in the end developers are looking into 
the performance and size impacts of each of these configuration and making 
changes as they see fit to best meet their needs.  These are unique cases 
though, the majority of the software built for the core OS uses a single policy 
-- it's when something needs to be further optimized that this comes into play.

At this point, I'd "like" to better differentiate the ARM package arches..  I 
don't care so much about the thumb enabled or not.. but the other tune settings 
are things I do care about.  I started to change that for the last update and 
decided it was a rat-hole I was not willing to go down at this point.  At some 
point in the future, I will look at, and document the differences in the tunings 
according to GCC configurations -- to get a good idea of what is and isn't 
producing the same binaries based on various arch and tune settings.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Khem Raj]

On Mon, Apr 9, 2012 at 1:25 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>
> In order to reconcile the above, the three primary options are see are:
>
> *) Define only mips or mips32 tune, but not both -- producing "mips" as the
> package arch.  (But then what do we do in the future about mips1, mips2,
> mips3, mips4, mips32r2?)
>
> *) Revert the behavior and have two tunes that produce the identical
> filename package with different contents and deal with this in the future.
>
> *) Keep it as it is now and produce mips and mips32 packages based on the
> specific tunings defined by the user

I think situation is not something I like but

I would think that 1st option is better. Any machine that has been using
mips32 tuning accidently could now use mips tune files and get same PKG_ARCH
and we move mips32 tune into mips tune and hereon say that mips 32bit in OE
defaults to -march=mips32

we could also change compiler defaults to use -march=mips32 to match
the baseconfig and since qemumips has been using mips32 anyway that sort
of is base mips arch.

>
> We have a bug, I believe we need to fix it.. first or third options "fix"
> the bug.. the second option retains the bug to be fixed in the future.
>
> If you have an alternative to the above, I'm interested -- I just really
> don't like the "leave the bug" option.
>
> And just to be extra clear, I consider it a defect if we can produce a
> package with the same name for two different tune settings.. (the exception
> being the hell that is ARM and thumb namings.)

Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell]

On Mon, 2012-04-09 at 16:44 -0500, Mark Hatle wrote:
> Depends on the distribution and reasons for these feeds.  What is typical is 
> that a base distribution will be generated for a common compatible (reasonable) 
> architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl, 
> etc) for the target arch, i.e. armv7a.  Then you have a couple of packages 
> hand-tuned for size, speed, or other that define or not thumb and add even a 
> higher level of optimization.  It's possible, folks do it today.. but it's not 
> always obvious.  (I have existing customers today that run a mix like I 
> described through their own package feed like system.  They really don't care at 
> all that the core system is tuned for a given processor -- they only care that 
> their specific applications and certain areas are specifically tuned to their 
> use-cases.)  Note, this is not what I would consider a typical use-case!

Sorry, I'm not quite sure I understand what point you're trying to make
here.  Are you describing what your customers are currently doing with
OE, or are you saying that this is something that they would like to do
with OE but don't feel they are able to at present, or something else?

I'm still not entirely clear on what you feel is broken about the
current state of the ARM tunings.  What exactly is the scenario that
works with the "traditional workstaton/server Linux OS" and can't be
replicated with OE?

But, all that aside, it seems ultimately that the exact way the
PACKAGE_ARCHs are structured ought to be a DISTRO policy decision and
not something that's mandated by the underlying infrastructure.  That
would perhaps remove some of the need for tinkering with these things in
oe-core itself.

p.

Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Mark Hatle]

On 4/10/12 4:23 AM, Phil Blundell wrote:
> On Mon, 2012-04-09 at 16:44 -0500, Mark Hatle wrote:
>> Depends on the distribution and reasons for these feeds.  What is typical is
>> that a base distribution will be generated for a common compatible (reasonable)
>> architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl,
>> etc) for the target arch, i.e. armv7a.  Then you have a couple of packages
>> hand-tuned for size, speed, or other that define or not thumb and add even a
>> higher level of optimization.  It's possible, folks do it today.. but it's not
>> always obvious.  (I have existing customers today that run a mix like I
>> described through their own package feed like system.  They really don't care at
>> all that the core system is tuned for a given processor -- they only care that
>> their specific applications and certain areas are specifically tuned to their
>> use-cases.)  Note, this is not what I would consider a typical use-case!

> Sorry, I'm not quite sure I understand what point you're trying to make
> here.  Are you describing what your customers are currently doing with
> OE, or are you saying that this is something that they would like to do
> with OE but don't feel they are able to at present, or something else?


The company I work for has an existing product that does not use OE.  The 
customers using this have requested from us packages tagged with different 
package architectures to indicate the tuning and optimization information so 
that they can create multiple boards with the same software running on them. 
(This is closer to the traditional workstation/server model in my experience.) 
The multiple boards have a common set of OS applications that run on them. 
ARMv5 for the most part.  The customers then have optimized applications with or 
without thumb, and optimized for a variety of different ARM parts.  They then 
use the binary packages to assemble the filesystems, and perform field upgrades, 
on these boards as they are put into use.  The installation system uses a best 
to least best match when doing assembly actions.  So if the part is an ARMv7a, 
it will first look for ARMv7a w/ thumb, vfp and neon, not finding that, ARMv7a 
w/ thumb and vfp, then ARMv7a w/ thumb, then ARMv5 w/ thumb and vfp, then ARMv5 
w/ thumb, and finally fall back to the ARMv5 binaries.

> I'm still not entirely clear on what you feel is broken about the
> current state of the ARM tunings.  What exactly is the scenario that
> works with the "traditional workstaton/server Linux OS" and can't be
> replicated with OE?

With the current implementation, there is no package differentiation between 
thumb and non-thumb binaries.  I accept why this is in OE-core and I can live 
with that.  However, there are other binaries that are theoretically optimized 
from specific Cortex models to the more generic ARMv7a tunings.  Currently they 
all use the same package arch, which means I can't tell which CPU they're really 
for -- and this model (above) of best to least best match doesn't work.

On a pure embedded model, I doubt anyone would do this.  Thus it is a fairly 
unique embedded use-case, but a common Workstation/Server use case that is being 
replicated.

> But, all that aside, it seems ultimately that the exact way the
> PACKAGE_ARCHs are structured ought to be a DISTRO policy decision and
> not something that's mandated by the underlying infrastructure.  That
> would perhaps remove some of the need for tinkering with these things in
> oe-core itself.

I intend, after this release, to propose changes to differentiate the models in 
oe-core.  If the oe-core folks do not feel this is necessary, they I will 
maintain them on my own as I feel necessary to cover the above use-case.

I can very much understand that in OE, for ARM specifically the package arch is 
simply indicating basic compatibility and not ABI & ISA & Optimization like it 
is on other architectures.

--Mark

> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell]

On Tue, 2012-04-10 at 12:39 -0500, Mark Hatle wrote:
> The installation system uses a best 
> to least best match when doing assembly actions.  So if the part is an ARMv7a, 
> it will first look for ARMv7a w/ thumb, vfp and neon, not finding that, ARMv7a 
> w/ thumb and vfp, then ARMv7a w/ thumb, then ARMv5 w/ thumb and vfp, then ARMv5 
> w/ thumb, and finally fall back to the ARMv5 binaries.

This sounds like exactly the behaviour you would get with the current
ARM tunings (except the Thumb bit which, as previously discussed, I
think is somewhat misguided in the first place).  The existing ARM
tunings do seem to correctly encode VFP and Neon-ness.  

Which part isn't working for you?  Maybe you could give a concrete
example of where exactly it falls down.

> I can very much understand that in OE, for ARM specifically the package arch is 
> simply indicating basic compatibility and not ABI & ISA & Optimization like it 
> is on other architectures.

Well, I would consider "ABI & ISA" to be a fairly big part of "basic
compatibility".  It is true that we don't currently encode
optimisations, but as I previously mentioned I don't think many (perhaps
any) other distributions do that either, and it's perhaps debatable
whether it would be a very useful thing to do in the general case.  For
individual packages you can obviously force the issue in your DISTRO
configuration anyway.

p.