Cleanup and document tuning files
cover Cleanup and document tuning files
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
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.
--- 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
meta/conf/bitbake.conf +0 -1
@@ -96,7 +96,6 @@ TUNE_CCARGS ??= "" TUNE_LDARGS ??= "" TUNE_ASARGS ??= "" TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" -TUNE_PKGARCH ??= "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}" LIBCEXTENSION ??= "" ABIEXTENSION ??= ""
meta/conf/machine/include/README new file +77 -0
77 lines not on this page · raw message
Signature · 1 line
1.7.1
Re: [PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings
Quoted 11 lines · 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_PKGARCHsetting in bitbake.conf. This was done to ensure an error occurs if an invalid tuning is defined.Signed-off-by Mark Hatle <[email protected]>
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.
Signature · 1 line
Christopher Larson
Re: [PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings
In reply to Mark HatleOn Tue, Apr 3, 2012 at 16:47, Mark Hatle <[email protected]> wrote:
...
meta/conf/machine/include/README line 52
Quoted 5 lines
meta/conf/machine/include/README new file +5
-0+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/ ...
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH 2/7 conf/machine/include: Cleanup IA tunings to match README
In reply to Mark HatleWe 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.
--- 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
meta/conf/machine/include/ia32/README new file +24 -0
@@ -0,0 +1,24 @@ +2012/03/30 - Mark Hatle <[email protected]> + - 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'.
meta/conf/machine/include/ia32/arch-ia32.inc +14 -12
@@ -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}"
meta/conf/machine/include/tune-c3.inc +9 -3
@@ -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"
meta/conf/machine/include/tune-core2.inc +9 -7
@@ -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"
meta/conf/machine/include/tune-i586.inc +3 -5
@@ -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" -
Signature · 1 line
1.7.1
PATCH 3/7 conf/machine/include: Cleanup MIPS tunings to match README
In reply to Mark HatleCleanup 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.
--- 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
meta/conf/machine/include/mips/README new file +36 -0
@@ -0,0 +1,36 @@ +2012/03/30 - Mark Hatle <[email protected]> + - 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.
meta/conf/machine/include/mips/arch-mips.inc +36 -2
@@ -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"
meta/conf/machine/include/tune-mips32.inc +12 -5
@@ -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"
Signature · 1 line
1.7.1
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
meta/conf/machine/include/mips/README line 32
Quoted 2 lines · Mark Hatle
meta/conf/machine/include/mips/README new file +2
-0+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
Quoted 5 lines · Phil Blundell
meta/conf/machine/include/mips/README line 32
Quoted 2 lines · Mark Hatle
meta/conf/machine/include/mips/README new file +2
-0+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
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
In reply to Mark HatleQuoted 5 lines · 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.
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
Quoted 6 lines · Andreas Oberritter
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
Quoted 6 lines · Khem Raj
Quoted 5 lines · Andreas Oberritter
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.
Quoted 7 lines
Quoted 1 line
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
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
Quoted 34 lines · Mark Hatle
Quoted 9 lines · Khem Raj
Quoted 6 lines · Andreas Oberritter
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.
Quoted 8 lines
Quoted 1 line
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 normIf 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.
Quoted 6 lines
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
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
Quoted 49 lines · Khem Raj
Quoted 34 lines · Mark Hatle
Quoted 9 lines · Khem Raj
Quoted 6 lines · Andreas Oberritter
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.
Quoted 8 lines
Quoted 1 line
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 normIf 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.
Quoted 6 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
Quoted 20 lines · 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
Quoted 8 lines
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!
Quoted 4 lines
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
Quoted 25 lines · Andreas Oberritter
Quoted 24 lines · 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-selinuxThe system is correctly setting the target to "mips-oe-linux".
I checked and bash is the same way.
Quoted 8 lines
Quoted 4 lines
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:
meta/conf/machine/include/tune-mips32.inc +4 -4
@@ -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
Quoted 9 lines
Quoted 4 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:
Quoted 31 lines · Andreas Oberritter
Quoted 30 lines · Mark Hatle
Quoted 28 lines
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-selinuxThe 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.)
Quoted 7 lines
Quoted 3 lines
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
Quoted 38 lines · Koen Kooi
Op 9 apr. 2012, om 17:17 heeft Mark Hatle het volgende geschreven:
Quoted 35 lines · Andreas Oberritter
Quoted 33 lines · Mark Hatle
Quoted 20 lines
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-selinuxQuoted 8 lines
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!
Quoted 5 lines
Quoted 3 lines
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
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
In reply to Mark HatleQuoted 38 lines · Mark Hatle
Quoted 28 lines · Andreas Oberritter
Quoted 27 lines · 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.
Quoted 8 lines
Quoted 4 lines
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!
Quoted 7 lines
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.
Quoted 10 lines
To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:meta/conf/machine/include/tune-mips32.inc +0
-0@@ -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"
meta/conf/machine/include/tune-mips32.inc TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32" · line 17
Quoted 8 lines
meta/conf/machine/include/tune-mips32.inc +2
-2-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.
Quoted 10 lines
TUNE_FEATURES_tune-mips32-nf = "${TUNE_FEATURES_tune-mips-nf} mips32"
meta/conf/machine/include/tune-mips32.inc +2
-2-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"
Quoted 6 lines
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.
Quoted 3 lines
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
Quoted 6 lines · Andreas Oberritter
Quoted 5 lines · Mark Hatle
Quoted 4 lines · Andreas Oberritter
Quoted 3 lines · Mark Hatle
Just ran a local build with the qemumips machine, this is a standard mips32 target.
...
Quoted 23 lines
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
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!
Quoted 7 lines
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.
Quoted 3 lines
To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:
...
Quoted 8 lines
meta/conf/machine/include/tune-mips32.inc TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32" · line 17
Quoted 4 lines
TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"meta/conf/machine/include/tune-mips32.inc +1
-1-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.
...
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 2 lines
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' andmips64r2'. 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.
Quoted 9 lines
Quoted 3 lines
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_mipseletc.? 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.
Quoted 4 lines
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
Quoted 7 lines
Regards,
Andreas_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
Quoted 142 lines · Mark Hatle
Quoted 6 lines · Andreas Oberritter
Quoted 5 lines · Mark Hatle
Quoted 4 lines · Andreas Oberritter
Quoted 3 lines · Mark Hatle
Just ran a local build with the qemumips machine, this is a standard mips32 target.
...
Quoted 25 lines
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
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!
Quoted 7 lines
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.
Quoted 3 lines
To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:...
Quoted 8 lines
meta/conf/machine/include/tune-mips32.inc TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32" · line 17
Quoted 4 lines
TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"meta/conf/machine/include/tune-mips32.inc +1
-1-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.
...
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 2 lines
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' andmips64r2'. 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.
Quoted 9 lines
Quoted 3 lines
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_mipseletc.? 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_ARCHwhere neededTRANSLATED_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 theTARGET_ARCH, via theTRANSLATED_TARGET_ARCH.Quoted 4 lines
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.
Quoted 6 lines
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
In reply to Mark HatleQuoted 71 lines · Mark Hatle
Quoted 6 lines · Andreas Oberritter
Quoted 5 lines · Mark Hatle
Quoted 4 lines · Andreas Oberritter
Quoted 3 lines · Mark Hatle
Just ran a local build with the qemumips machine, this is a standard mips32 target.
...
Quoted 23 lines
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
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!
Quoted 7 lines
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.
Quoted 3 lines
To revert to the previous behavior, in the
meta/conf/machine/include/tune-mips.inc:...
Quoted 8 lines
meta/conf/machine/include/tune-mips32.inc TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mips32" · line 17
Quoted 4 lines
TUNE_FEATURES_tune-mips32el = "${TUNE_FEATURES_tune-mipsel} mips32"meta/conf/machine/include/tune-mips32.inc +1
-1-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.
...
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 2 lines
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' andmips64r2'. 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.
Quoted 4 lines
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.
Quoted 81 lines
Quoted 9 lines
Quoted 3 lines
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_mipseletc.? 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_ARCHwhere neededTRANSLATED_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 theTARGET_ARCH, via theTRANSLATED_TARGET_ARCH.Quoted 4 lines
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
Quoted 7 lines
Regards,
Andreas_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
In reply to Mark HatleQuoted 3 lines · Mark Hatle
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
Quoted 11 lines · Phil Blundell
Quoted 3 lines · Mark Hatle
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_ARCHvalue has, traditionally, been concerned purely with ISA and ABI (i.e. answering the question "can I execute this code?") rather than optimisations.
Quoted 8 lines
For example, the tune-arm926ejs.inc and tune-xscale.inc files in current oe-core both end up setting
PACKAGE_ARCHto "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 thePACKAGE_ARCHmust uniquely identify one set of binaries then obviously each of these tunings (and probably all the ARM cpu-specific tunings) would need to setPACKAGE_ARCHto 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
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
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
Quoted 3 lines · Mark Hatle
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.
Quoted 2 lines
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
Quoted 5 lines · Phil Blundell
Quoted 3 lines · Mark Hatle
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.)
Quoted 8 lines
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!
Quoted 13 lines
Quoted 2 lines
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 intoPACKAGE_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
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
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
Quoted 11 lines · Mark Hatle
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
Quoted 13 lines · Phil Blundell
Quoted 11 lines · Mark Hatle
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!
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
But, all that aside, it seems ultimately that the exact way the
PACKAGE_ARCHsare 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
Quoted 7 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
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
Quoted 5 lines · Mark Hatle
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.
Quoted 3 lines
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.
Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
In reply to Mark HatleQuoted 7 lines · Mark Hatle
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?)
Quoted 5 lines
*) 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.
Quoted 10 lines
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.)
PATCH 4/7 conf/machine/include: Cleanup PowerPC tunings to match README
In reply to Mark HatleCleanup 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.
--- 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
meta/conf/machine/include/powerpc/README new file +17 -0
@@ -0,0 +1,17 @@ +2012/03/30 - Mark Hatle <[email protected]> + - 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>. +
meta/conf/machine/include/powerpc/arch-powerpc.inc +8 -7
@@ -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"
meta/conf/machine/include/powerpc/arch-powerpc64.inc +1 -0
@@ -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"
meta/conf/machine/include/tune-ppc603e.inc +2 -2
@@ -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)
meta/conf/machine/include/tune-ppce300c2.inc +1 -1
@@ -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"
meta/conf/machine/include/tune-ppce500.inc +7 -3
@@ -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"
meta/conf/machine/include/tune-ppce500mc.inc +2 -2
@@ -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)
meta/conf/machine/include/tune-ppce500v2.inc +7 -3
@@ -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"
meta/conf/machine/include/tune-ppce5500.inc +2 -2
@@ -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)}"
Signature · 1 line
1.7.1
Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README
meta/conf/machine/include/tune-ppce500.inc require conf/machine/include/powerpc/arch-powerpc.inc · line 20
Quoted 6 lines · Mark Hatle
meta/conf/machine/include/tune-ppce500.inc +2
-0+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
Quoted 13 lines · Matthew McClintock
meta/conf/machine/include/tune-ppce500.inc require conf/machine/include/powerpc/arch-powerpc.inc · line 20
Quoted 6 lines · Mark Hatle
meta/conf/machine/include/tune-ppce500.inc +2
-0+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"
Quoted 1 line
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
Quoted 6 lines
-M
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 4/7] conf/machine/include: Cleanup PowerPC tunings to match README
In reply to Mark Hatlemeta/conf/machine/include/tune-ppce500.inc require conf/machine/include/powerpc/arch-powerpc.inc · line 10
Quoted 12 lines · Mark Hatle
meta/conf/machine/include/tune-ppce500.inc +2
-2@@ -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
Quoted 9 lines · Matthew McClintock
Quoted 8 lines · Mark Hatle
meta/conf/machine/include/tune-ppce500.inc +0
-1@@ -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"
Quoted 10 lines
meta/conf/machine/include/tune-ppce500.inc require conf/machine/include/powerpc/arch-powerpc.inc · line 10
Quoted 4 lines
meta/conf/machine/include/tune-ppce500.inc +2
-1TUNEVALID[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_FPUabove andTUNE_FEATURESin 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
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
PATCH 5/7 conf/machine/include: Cleanup ARM tunings to match README
In reply to Mark HatleCleanup 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.
--- 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
meta/conf/machine/include/arm/README new file +40 -0
@@ -0,0 +1,40 @@ +2012/03/30 - Mark Hatle <[email protected]> + - 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.
meta/conf/machine/include/arm/arch-arm.inc +1 -1
@@ -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"
meta/conf/machine/include/arm/arch-armv5.inc +1 -1
@@ -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"
meta/conf/machine/include/arm/arch-armv7a.inc +3 -3
@@ -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"
meta/conf/machine/include/tune-cortexm3.inc +1 -1
@@ -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"
meta/conf/machine/include/tune-cortexr4.inc +1 -1
@@ -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"
Signature · 1 line
1.7.1
PATCH 6/7 conf/machine/include: Update SH tunings to match README
In reply to Mark HatleUpdate the experimental SH tunings to match the tunings README.
These tunings have not been tested, and are experimental!
--- 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
meta/conf/machine/include/sh/README new file +11 -0
@@ -0,0 +1,11 @@ +2012/03/30 - Mark Hatle <[email protected]> + - 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}}. +
meta/conf/machine/include/sh/arch-sh.inc new file +9 -0
@@ -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)}"
meta/conf/machine/include/tune-sh3.inc +16 -3
@@ -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"
meta/conf/machine/include/tune-sh4.inc +29 -3
@@ -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"
Signature · 1 line
1.7.1
PATCH 7/7 binutils: Inform binutils that armv5e really is valid!
In reply to Mark HatleA 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.
--- .../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
meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch new file +20 -0
@@ -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 <[email protected]> + +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},
meta/recipes-devtools/binutils/binutils_2.22.bb +2 -1
@@ -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"
Signature · 1 line
1.7.1
Re: [PATCH 7/7] binutils: Inform binutils that armv5e really is valid!
Quoted 5 lines · 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.
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
Quoted 62 lines
Signed-off-by Mark Hatle <[email protected]>---
.../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.patchmeta/recipes-devtools/binutils/binutils/binutils-armv5e.patch new file +20
-0@@ -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 <[email protected]> + +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},meta/recipes-devtools/binutils/binutils_2.22.bb +0
-0@@ -1,6 +1,6 @@require binutils.inc
meta/recipes-devtools/binutils/binutils_2.22.bb +1
-1-PR = "r5" +PR = "r6"LIC_FILES_CHKSUM="\
file://src-release;endline=17;md5=4830a9ef968f3b18dd5e9f2c00db2d35\meta/recipes-devtools/binutils/binutils_2.22.bb +1
-0@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Saul Wold
AppliedQuoted 104 lines · Mark Hatle
(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.patchsh*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-contribmhatle/tunings
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/tuningsMark 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(-)
Quoted 9 lines
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 100644meta/recipes-devtools/binutils/binutils/binutils-armv5e.patch
Merged into OE-Core
Thanks
Sau!
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core