Patchwork [1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

login
register
mail settings
Submitter Richard Purdie
Date July 26, 2011, 12:44 p.m.
Message ID <346abefc87d21d0cc111ef87a6e48f40c5b6cb0b.1311683981.git.richard.purdie@linuxfoundation.org>
Download mbox | patch
Permalink /patch/8557/
State New, archived
Headers show

Comments

Richard Purdie - July 26, 2011, 12:44 p.m.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/conf/machine/include/arm/arch-arm.inc         |   16 +++++-
 meta/conf/machine/include/arm/arch-armv4.inc       |   24 +++++++++
 meta/conf/machine/include/arm/arch-armv5-dsp.inc   |   40 ++++++++++++++
 meta/conf/machine/include/arm/arch-armv5.inc       |   51 ++++++++++++++++++
 meta/conf/machine/include/arm/arch-armv6.inc       |   32 +++++++++++
 meta/conf/machine/include/arm/arch-armv7.inc       |   55 ++++++++++++++++++++
 meta/conf/machine/include/arm/arch-armv7a.inc      |   54 +++++++++++++++++++
 meta/conf/machine/include/arm/feature-arm-neon.inc |    3 +
 .../conf/machine/include/arm/feature-arm-thumb.inc |   25 +++++++++
 meta/conf/machine/include/arm/feature-arm-vfp.inc  |    6 ++
 meta/conf/machine/include/tune-arm1136jf-s.inc     |   14 +++---
 meta/conf/machine/include/tune-arm920t.inc         |   14 ++++--
 meta/conf/machine/include/tune-arm926ejs.inc       |   18 ++++---
 meta/conf/machine/include/tune-arm9tdmi.inc        |   14 ++++--
 meta/conf/machine/include/tune-armv7.inc           |    8 +---
 meta/conf/machine/include/tune-cortexa8.inc        |   21 ++++----
 meta/conf/machine/include/tune-cortexm1.inc        |   13 ++++-
 meta/conf/machine/include/tune-cortexm3.inc        |   18 +++++--
 meta/conf/machine/include/tune-cortexr4.inc        |   18 +++++--
 meta/conf/machine/include/tune-ep9312.inc          |   16 ++++--
 meta/conf/machine/include/tune-iwmmxt.inc          |   18 +++++--
 meta/conf/machine/include/tune-strongarm1100.inc   |   13 +++--
 meta/conf/machine/include/tune-xscale.inc          |   18 ++++--
 23 files changed, 435 insertions(+), 74 deletions(-)
 create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
 create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
 create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
 create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
 create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
Koen Kooi - July 26, 2011, 12:46 p.m.
Doing a build with this one applied now, will report back later

Op 26 jul. 2011, om 14:44 heeft Richard Purdie het volgende geschreven:

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/arm/arch-arm.inc         |   16 +++++-
> meta/conf/machine/include/arm/arch-armv4.inc       |   24 +++++++++
> meta/conf/machine/include/arm/arch-armv5-dsp.inc   |   40 ++++++++++++++
> meta/conf/machine/include/arm/arch-armv5.inc       |   51 ++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv6.inc       |   32 +++++++++++
> meta/conf/machine/include/arm/arch-armv7.inc       |   55 ++++++++++++++++++++
> meta/conf/machine/include/arm/arch-armv7a.inc      |   54 +++++++++++++++++++
> meta/conf/machine/include/arm/feature-arm-neon.inc |    3 +
> .../conf/machine/include/arm/feature-arm-thumb.inc |   25 +++++++++
> meta/conf/machine/include/arm/feature-arm-vfp.inc  |    6 ++
> meta/conf/machine/include/tune-arm1136jf-s.inc     |   14 +++---
> meta/conf/machine/include/tune-arm920t.inc         |   14 ++++--
> meta/conf/machine/include/tune-arm926ejs.inc       |   18 ++++---
> meta/conf/machine/include/tune-arm9tdmi.inc        |   14 ++++--
> meta/conf/machine/include/tune-armv7.inc           |    8 +---
> meta/conf/machine/include/tune-cortexa8.inc        |   21 ++++----
> meta/conf/machine/include/tune-cortexm1.inc        |   13 ++++-
> meta/conf/machine/include/tune-cortexm3.inc        |   18 +++++--
> meta/conf/machine/include/tune-cortexr4.inc        |   18 +++++--
> meta/conf/machine/include/tune-ep9312.inc          |   16 ++++--
> meta/conf/machine/include/tune-iwmmxt.inc          |   18 +++++--
> meta/conf/machine/include/tune-strongarm1100.inc   |   13 +++--
> meta/conf/machine/include/tune-xscale.inc          |   18 ++++--
> 23 files changed, 435 insertions(+), 74 deletions(-)
> create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
> create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
> 
> diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
> index c517df6..4ea8b2b 100644
> --- a/meta/conf/machine/include/arm/arch-arm.inc
> +++ b/meta/conf/machine/include/arm/arch-arm.inc
> @@ -1,3 +1,17 @@
> -TUNE_ARCH = "arm"
> +
> +TUNEVALID[bigendian] = "Enable big-endian mode."
> +
> +ARMPKGARCH ??= "arm"
> +ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
> +ARMPKGSFX_FPU ??= ""
> +ARMPKGSFX_DSP ??= ""
> +ARMPKGSFX_EABI ??= ""
> +ARMPKGSFX_THUMB ??= ""
> +
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
> +TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
> 
> ABIEXTENSION = "eabi"
> +
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
> new file mode 100644
> index 0000000..c014d20
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> @@ -0,0 +1,24 @@
> +DEFAULTTUNE ?= "armv4"
> +
> +ARMPKGARCH ?= "armv4"
> +
> +TUNEVALID[armv4] = "Enable instructions for ARMv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
> +
> +require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/feature-arm-thumb.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv4 armv4t"
> +TUNE_FEATURES_tune-armv4 ?= "armv4"
> +TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
> +PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
> +
> +# Big Endian
> +AVAILTUNES += "armv4b armv4tb"
> +TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
> +TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> new file mode 100644
> index 0000000..498a012
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
> +TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
> +TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
> +TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5eb armv5teb"
> +TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
> +TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
> +TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +DEFAULTTUNE ?= "armv5"
> +
> +ARMPKGARCH ?= "armv5"
> +
> +TUNEVALID[armv5] = "Enable instructions for ARMv5"
> +TUNE_CONFLICTS[armv5] = "armv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
> +
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +require conf/machine/include/arm/feature-arm-vfp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> +TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5b armv5tb"
> +TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
> +TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
> +TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
> +
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
> new file mode 100644
> index 0000000..20924c9
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> @@ -0,0 +1,32 @@
> +DEFAULTTUNE ?= "armv6"
> +
> +ARMPKGARCH ?= "armv6"
> +
> +TUNEVALID[armv6] = "Enable instructions for ARMv6"
> +TUNE_CONFLICTS[armv6] = "armv4 armv5"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
> +TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
> +TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
> +TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
> +TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
> +TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
> +TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
> new file mode 100644
> index 0000000..8bc8d10
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7.inc
> @@ -0,0 +1,55 @@
> +DEFAULTTUNE ?= "armv7"
> +
> +ARMPKGARCH ?= "armv7"
> +
> +TUNEVALID[armv7] = "Enable instructions for ARMv7"
> +TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv6.inc
> +require conf/machine/include/arm/feature-arm-neon.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
> +TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
> +TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
> +TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
> +TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
> +TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
> +TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
> +TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
> +TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
> +TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> new file mode 100644
> index 0000000..ce9cee5
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -0,0 +1,54 @@
> +DEFAULTTUNE ?= "armv7a"
> +
> +ARMPKGARCH ?= "armv7a"
> +
> +TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
> +TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv7.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
> +TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
> +TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
> +TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
> +TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
> +TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
> +TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
> +TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
> +TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
> +TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
> new file mode 100644
> index 0000000..a7dac03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
> @@ -0,0 +1,3 @@
> +TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> new file mode 100644
> index 0000000..9a607c6
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -0,0 +1,25 @@
> +# The instruction set the compiler should use when generating application
> +# code. The kernel is always compiled with arm code at present. arm code
> +# is the original 32 bit ARM instruction set, thumb code is the 16 bit
> +# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
> +# but requires more instructions (140% for 70% smaller code) so may be
> +# slower.
> +TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
> +
> +# Note armv7 will hit on armv7a as well
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> +
> +# Whether to compile with code to allow interworking between the two
> +# instruction sets. This allows thumb code to be executed on a primarily
> +# arm system and vice versa. It is strongly recommended that DISTROs not
> +# turn this off - the actual cost is very small.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
> +
> +TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
> diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> new file mode 100644
> index 0000000..29a925c
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> @@ -0,0 +1,6 @@
> +TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
> +
> +TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
> index 953f0dd..4f4a2eb 100644
> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc
> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
> @@ -1,10 +1,10 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm1136jfs"
> 
> -TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
> -TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
> -TUNE_PKGARCH = "armv6"
> +require conf/machine/include/arm/arch-armv6.inc
> 
> -ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
> +TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
> 
> -require conf/machine/include/tune-thumb.inc
> +AVAILTUNES += "arm1136jfs"
> +TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
> +PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
> index 6c87026..b7584ab 100644
> --- a/meta/conf/machine/include/tune-arm920t.inc
> +++ b/meta/conf/machine/include/tune-arm920t.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm920t"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
> +
> +AVAILTUNES += "arm920t"
> +TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
> +PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
> 
> -TUNE_PKGARCH = "armv4t"
> -TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
> index 543ab62..7f2cc4e 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -1,9 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> -TUNE_PKGARCH = "armv5te"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
> -# For gcc 3.x you need:
> -#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
> -# For gcc 4.x you need:
> -TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
> +DEFAULTTUNE ?= "arm926ejs"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
> +
> +AVAILTUNES += "arm926ejs"
> +TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> 
> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
> index f1001ac..0dc5c26 100644
> --- a/meta/conf/machine/include/tune-arm9tdmi.inc
> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm9tdmi"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
> +
> +AVAILTUNES += "arm9tdmi"
> +TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
> +PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
> 
> -TUNE_PKGARCH = "armv4t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> -TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
> index 8a68c0a..664c24b 100644
> --- a/meta/conf/machine/include/tune-armv7.inc
> +++ b/meta/conf/machine/include/tune-armv7.inc
> @@ -1,8 +1,2 @@
> -require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/arch-armv7.inc
> 
> -# valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
> -# valid option for -mtune: `cortex-a8', `cortex-r4', `cortex-m3', `cortex-m1'
> -# This will NOT compile programs in 'ARM' mode, which is what you really want
> -TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index ae50954..b07add4 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,15 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexa8-neon"
> 
> +require conf/machine/include/arm/arch-armv7a.inc
> 
> -# Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3]
> -# [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
> -# [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html 
> -# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
> +TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
> 
> -TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
> +AVAILTUNES += "cortexa8 cortexa8t"
> +TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
> +TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
> +TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
> 
> -# Other potentially useful options
> -#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
> 
> -TUNE_PKGARCH = "armv7a"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
> diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
> index b944db4..493025d 100644
> --- a/meta/conf/machine/include/tune-cortexm1.inc
> +++ b/meta/conf/machine/include/tune-cortexm1.inc
> @@ -1,4 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm1"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
> +
> +AVAILTUNES += "cortexm1"
> +TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> 
> -TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv6"
> diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
> index a77cbdd..f774fa6 100644
> --- a/meta/conf/machine/include/tune-cortexm3.inc
> +++ b/meta/conf/machine/include/tune-cortexm3.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm3"
> +ARMPKGARCH ?= "armv7m"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
> +
> +TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexm3"
> +TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
> 
> -# valid options for -march: `armv7', `armv7-m'
> -TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
> index c9193ca..738f5af 100644
> --- a/meta/conf/machine/include/tune-cortexr4.inc
> +++ b/meta/conf/machine/include/tune-cortexr4.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexr4"
> +ARMPKGARCH ?= "armv7r"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
> +
> +TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexr4"
> +TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
> +PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
> 
> -# valid options for -march: `armv7', `armv7-r'
> -TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
> index e04a00a..f10123f 100644
> --- a/meta/conf/machine/include/tune-ep9312.inc
> +++ b/meta/conf/machine/include/tune-ep9312.inc
> @@ -1,9 +1,13 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "ep9312"
> +ARMPKGARCH ?= "ep9312"
> 
> -TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
> -# add "-mfp=maverick" for newer gcc versions > 4.0
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
> +
> +AVAILTUNES += "ep9312"
> +TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
> +PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
> 
> -#set arch to ep9312 for all generated packages
> -PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
> -TUNE_PKGARCH = "ep9312"
> 
> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
> index 6bb76d5..14f5955 100644
> --- a/meta/conf/machine/include/tune-iwmmxt.inc
> +++ b/meta/conf/machine/include/tune-iwmmxt.inc
> @@ -1,8 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> # Configurations for the Intel PXA27x Appications Processor Family. 
> # Please use tune-xscale for PXA255/PXA26x based processors.
> -TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
> -TUNE_PKGARCH = "iwmmxt"
> +
> +DEFAULTTUNE ?= "iwmmxt"
> +ARMPKGARCH ?= "iwmmxt"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
> +
> +AVAILTUNES += "iwmmxt"
> +TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
> +PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
> +
> 
> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
> index 2b76069..66bab8e 100644
> --- a/meta/conf/machine/include/tune-strongarm1100.inc
> +++ b/meta/conf/machine/include/tune-strongarm1100.inc
> @@ -1,9 +1,12 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "strongarm"
> 
> -TUNE_PKGARCH = "arm"
> +require conf/machine/include/arm/arch-armv4.inc
> 
> -# This machine lists common configuration options for Strongarm 1100 devices
> -# NOTE: The Zaurus Collie also has a Strongarm processor, but uses the 1110 type
> +TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
> +
> +AVAILTUNES += "strongarm"
> +TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
> +PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
> 
> -TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
> 
> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
> index 71dba5b..0303320 100644
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
> 
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> 
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> 
> # webkit-gtk has alignment issues with double instructions on armv5 so
> # disable them here
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 27, 2011, 12:17 p.m.
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"

This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
variable and then the package suffix be computed from that, rather than
vice versa?

> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"

This is wrong: ARMv6 doesn't imply Thumb-2.

> +# Whether to compile with code to allow interworking between the two
> +# instruction sets. This allows thumb code to be executed on a primarily
> +# arm system and vice versa. It is strongly recommended that DISTROs not
> +# turn this off - the actual cost is very small.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"

This is only relevant for v4t, I guess.  Interworking is basically
always on for v5 and later and (CeSI aside) it's impossible on v4, so
hardly anybody is going to be flipping this switch.  I'm not sure it
really merits an OVERRIDE.

> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
>  
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
>  
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"

I guess that should be "_tune-xscale-be".

All in all it seems as though there's an awful lot of expanded cross
products in this set of patches and I can't help wondering whether a lot
of this stuff would be better computed programmatically.  I wouldn't be
at all surprised if there are other copy-and-paste errors like the
xscale one lurking in that mass of overrides, but it's very hard to spot
them by eye.  It seems particularly unfortunate that everything has to
be written out twice, once for big-endian and once for little-endian,
given that endianness is almost entirely orthogonal to all the other
"tuning" parameters.

p.
Richard Purdie - July 27, 2011, 1:33 p.m.
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> 
> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
> variable and then the package suffix be computed from that, rather than
> vice versa?

It's been "fun" to use the rather limited constructs we have in these
variables to construct the end result. I suspect this way around, it was
the easiest way to get the right variables in the right places.

> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> > +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> 
> This is wrong: ARMv6 doesn't imply Thumb-2.

Ah, yes. I'll fix this.

> > +# Whether to compile with code to allow interworking between the two
> > +# instruction sets. This allows thumb code to be executed on a primarily
> > +# arm system and vice versa. It is strongly recommended that DISTROs not
> > +# turn this off - the actual cost is very small.
> > +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> > +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
> 
> This is only relevant for v4t, I guess.  Interworking is basically
> always on for v5 and later and (CeSI aside) it's impossible on v4, so
> hardly anybody is going to be flipping this switch.  I'm not sure it
> really merits an OVERRIDE.

I'd be happy to remove this option if there are no objections. It was
left for compatibility with the existing tune-thumb file but as you say,
it likely doesn't make much sense.

> > --- a/meta/conf/machine/include/tune-xscale.inc
> > +++ b/meta/conf/machine/include/tune-xscale.inc
> > @@ -1,11 +1,17 @@
> > -require conf/machine/include/arm/arch-arm.inc
> > +DEFAULTTUNE ?= "xscale"
> >  
> > -INHERIT += "siteinfo"
> > +require conf/machine/include/arm/arch-armv5-dsp.inc
> >  
> > -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> > -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> > -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> > -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> > +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> > +
> > +AVAILTUNES += "xscale"
> > +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> > +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> > +
> > +AVAILTUNES += "xscale-be"
> > +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> > +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> 
> I guess that should be "_tune-xscale-be".

Yes, I'll fix, well spotted.

> All in all it seems as though there's an awful lot of expanded cross
> products in this set of patches and I can't help wondering whether a lot
> of this stuff would be better computed programmatically.  I wouldn't be
> at all surprised if there are other copy-and-paste errors like the
> xscale one lurking in that mass of overrides, but it's very hard to spot
> them by eye.  It seems particularly unfortunate that everything has to
> be written out twice, once for big-endian and once for little-endian,
> given that endianness is almost entirely orthogonal to all the other
> "tuning" parameters.

At least three of us have now done a pass over this so hopefully we've
spotted the major ones but I agree its less than ideal.

The alternative is to post process the variables somehow, or turn it all
into anonymous python (which from a .conf file is not as easy as it
sounds).

I do like the fact that it allows some standardisation of the options
available in a given tune file as whether or not big endian was even
possible was previously hit and miss.

So I think its an improvement but likely not the finished end result.

Cheers,

Richard
Mark Hatle - July 27, 2011, 2:27 p.m.
On 7/27/11 8:33 AM, Richard Purdie wrote:
> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>
>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>> variable and then the package suffix be computed from that, rather than
>> vice versa?
> 
> It's been "fun" to use the rather limited constructs we have in these
> variables to construct the end result. I suspect this way around, it was
> the easiest way to get the right variables in the right places.
> 
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>
>> This is wrong: ARMv6 doesn't imply Thumb-2.
> 
> Ah, yes. I'll fix this.

Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
were thumb(1).  Note, not all ARMv6 processors contain thumb support.

>>> +# Whether to compile with code to allow interworking between the two
>>> +# instruction sets. This allows thumb code to be executed on a primarily
>>> +# arm system and vice versa. It is strongly recommended that DISTROs not
>>> +# turn this off - the actual cost is very small.
>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>
>> This is only relevant for v4t, I guess.  Interworking is basically
>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>> hardly anybody is going to be flipping this switch.  I'm not sure it
>> really merits an OVERRIDE.
> 
> I'd be happy to remove this option if there are no objections. It was
> left for compatibility with the existing tune-thumb file but as you say,
> it likely doesn't make much sense.
> 
>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>> @@ -1,11 +1,17 @@
>>> -require conf/machine/include/arm/arch-arm.inc
>>> +DEFAULTTUNE ?= "xscale"
>>>  
>>> -INHERIT += "siteinfo"
>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>  
>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>> +
>>> +AVAILTUNES += "xscale"
>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>> +
>>> +AVAILTUNES += "xscale-be"
>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>
>> I guess that should be "_tune-xscale-be".
> 
> Yes, I'll fix, well spotted.

In the original work I did it was just tune-xscale (no be).  AFAIK there is no
little endian version of xscale.  (there was an iwmmxt that was similar to
xscale, but was slightly different.)

>> All in all it seems as though there's an awful lot of expanded cross
>> products in this set of patches and I can't help wondering whether a lot
>> of this stuff would be better computed programmatically.  I wouldn't be
>> at all surprised if there are other copy-and-paste errors like the
>> xscale one lurking in that mass of overrides, but it's very hard to spot
>> them by eye.  It seems particularly unfortunate that everything has to
>> be written out twice, once for big-endian and once for little-endian,
>> given that endianness is almost entirely orthogonal to all the other
>> "tuning" parameters.
> 
> At least three of us have now done a pass over this so hopefully we've
> spotted the major ones but I agree its less than ideal.
> 
> The alternative is to post process the variables somehow, or turn it all
> into anonymous python (which from a .conf file is not as easy as it
> sounds).
> 
> I do like the fact that it allows some standardisation of the options
> available in a given tune file as whether or not big endian was even
> possible was previously hit and miss.
> 
> So I think its an improvement but likely not the finished end result.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - July 27, 2011, 2:33 p.m.
Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:

> On 7/27/11 8:33 AM, Richard Purdie wrote:
>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>> 
>>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>>> variable and then the package suffix be computed from that, rather than
>>> vice versa?
>> 
>> It's been "fun" to use the rather limited constructs we have in these
>> variables to construct the end result. I suspect this way around, it was
>> the easiest way to get the right variables in the right places.
>> 
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>> 
>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>> 
>> Ah, yes. I'll fix this.
> 
> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
> were thumb(1).  Note, not all ARMv6 processors contain thumb support.

As I understand it:

arm1136 doesn't have t2
arm1176 does have t2

both are armv6 :)

> 
>>>> +# Whether to compile with code to allow interworking between the two
>>>> +# instruction sets. This allows thumb code to be executed on a primarily
>>>> +# arm system and vice versa. It is strongly recommended that DISTROs not
>>>> +# turn this off - the actual cost is very small.
>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>> 
>>> This is only relevant for v4t, I guess.  Interworking is basically
>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>> hardly anybody is going to be flipping this switch.  I'm not sure it
>>> really merits an OVERRIDE.
>> 
>> I'd be happy to remove this option if there are no objections. It was
>> left for compatibility with the existing tune-thumb file but as you say,
>> it likely doesn't make much sense.
>> 
>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>> @@ -1,11 +1,17 @@
>>>> -require conf/machine/include/arm/arch-arm.inc
>>>> +DEFAULTTUNE ?= "xscale"
>>>> 
>>>> -INHERIT += "siteinfo"
>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>> 
>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>> +
>>>> +AVAILTUNES += "xscale"
>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>> +
>>>> +AVAILTUNES += "xscale-be"
>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>> 
>>> I guess that should be "_tune-xscale-be".
>> 
>> Yes, I'll fix, well spotted.
> 
> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
> little endian version of xscale.  (there was an iwmmxt that was similar to
> xscale, but was slightly different.)

pxa25x are LE xscales (e.g. Palm Treo)
pxa26x are LE xscales with some NAND builtin
pxa27x are LE xscales with iwmmxt as an extra


> 
>>> All in all it seems as though there's an awful lot of expanded cross
>>> products in this set of patches and I can't help wondering whether a lot
>>> of this stuff would be better computed programmatically.  I wouldn't be
>>> at all surprised if there are other copy-and-paste errors like the
>>> xscale one lurking in that mass of overrides, but it's very hard to spot
>>> them by eye.  It seems particularly unfortunate that everything has to
>>> be written out twice, once for big-endian and once for little-endian,
>>> given that endianness is almost entirely orthogonal to all the other
>>> "tuning" parameters.
>> 
>> At least three of us have now done a pass over this so hopefully we've
>> spotted the major ones but I agree its less than ideal.
>> 
>> The alternative is to post process the variables somehow, or turn it all
>> into anonymous python (which from a .conf file is not as easy as it
>> sounds).
>> 
>> I do like the fact that it allows some standardisation of the options
>> available in a given tune file as whether or not big endian was even
>> possible was previously hit and miss.
>> 
>> So I think its an improvement but likely not the finished end result.
>> 
>> Cheers,
>> 
>> Richard
>> 
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 27, 2011, 2:34 p.m.
I just looked at this again and here are a few more comments:

On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"

That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
Otherwise you will get a mixture of big and little endian in there.

> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"

There seems to be some duplication of AVAILTUNES going on here.

Also, I think this v5 stuff is more complex than it needs to be because
it seems to be trying to cater for architecture combinations that are
possible in theory but don't actually exist in the wild.  For example, I
can't immediately think of any ARMv5 implementations that lack Thumb or
the E instructions.

> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"

The comment doesn't seem to match the code here since this is the
section for chips without DSP.  Incidentally, the name "dsp" for this
feature seems quite a bad one: maybe we should just call it "armv5e".

p.
Richard Purdie - July 27, 2011, 2:34 p.m.
On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
> On 7/27/11 8:33 AM, Richard Purdie wrote:
> > On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> >> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> >>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> >>
> >> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
> >> variable and then the package suffix be computed from that, rather than
> >> vice versa?
> > 
> > It's been "fun" to use the rather limited constructs we have in these
> > variables to construct the end result. I suspect this way around, it was
> > the easiest way to get the right variables in the right places.
> > 
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> >>
> >> This is wrong: ARMv6 doesn't imply Thumb-2.
> > 
> > Ah, yes. I'll fix this.
> 
> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
> were thumb(1).  Note, not all ARMv6 processors contain thumb support.

I did quickly check up on this and I think Phil is right but I'll take
other evidence...

> >>> --- a/meta/conf/machine/include/tune-xscale.inc
> >>> +++ b/meta/conf/machine/include/tune-xscale.inc
> >>> @@ -1,11 +1,17 @@
> >>> -require conf/machine/include/arm/arch-arm.inc
> >>> +DEFAULTTUNE ?= "xscale"
> >>>  
> >>> -INHERIT += "siteinfo"
> >>> +require conf/machine/include/arm/arch-armv5-dsp.inc
> >>>  
> >>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> >>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> >>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> >>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> >>> +
> >>> +AVAILTUNES += "xscale"
> >>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> >>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> >>> +
> >>> +AVAILTUNES += "xscale-be"
> >>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> >>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> >>
> >> I guess that should be "_tune-xscale-be".
> > 
> > Yes, I'll fix, well spotted.
> 
> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
> little endian version of xscale.  (there was an iwmmxt that was similar to
> xscale, but was slightly different.)

You can put most ARM processors including XScale into big or little
endian mode as far as I know. The infamous OE example is the NSLU2
(IXP4xx) which is xscale based and runs in BE by default. This is why
the original tune file supports both endians.

Cheers,

Richard
Phil Blundell - July 27, 2011, 2:44 p.m.
On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
> On 7/27/11 8:33 AM, Richard Purdie wrote:
> > On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
> >> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> >>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> >>
> >> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
> >> variable and then the package suffix be computed from that, rather than
> >> vice versa?
> > 
> > It's been "fun" to use the rather limited constructs we have in these
> > variables to construct the end result. I suspect this way around, it was
> > the easiest way to get the right variables in the right places.
> > 
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> >>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> >>
> >> This is wrong: ARMv6 doesn't imply Thumb-2.
> > 
> > Ah, yes. I'll fix this.
> 
> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
> were thumb(1).  Note, not all ARMv6 processors contain thumb support.

It is true that all ARMv4T and ARMv5T processors are only Thumb-1.  It's
also true that Thumb-2 was first implemented in ARM1156, which is an
ARMv6 core.  But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
and all three of those are Thumb-1 only.  Given that nobody is likely to
target ARM1156 with OE, it's probably a reasonable approximation to say
that Thumb-2 correlates with ARMv7 and later.

Also, since there are no v5, v6 or v7 cores which don't support Thumb,
the "t" suffix serves no useful purpose here and might as well just be
omitted.  That is, there is no CPU which can run "armv6" packages which
wouldn't also be able to run "armv6t".

> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
> little endian version of xscale.

No, that's incorrect.  The PXA25x series and IXP420, at least, are
bi-endian (and I suspect most of the other XScales are too) and there
are certainly folks running them in little endian configurations.

p.
Mark Hatle - July 27, 2011, 2:49 p.m.
On 7/27/11 9:33 AM, Koen Kooi wrote:
> 
> Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
> 
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
>> were thumb(1).  Note, not all ARMv6 processors contain thumb support.
> 
> As I understand it:
> 
> arm1136 doesn't have t2
> arm1176 does have t2
> 
> both are armv6 :)

They also don't have "thumb" support either.  So armv6 & thumb == t2.

>>
>>>>> +# Whether to compile with code to allow interworking between the two
>>>>> +# instruction sets. This allows thumb code to be executed on a primarily
>>>>> +# arm system and vice versa. It is strongly recommended that DISTROs not
>>>>> +# turn this off - the actual cost is very small.
>>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>>
>>>> This is only relevant for v4t, I guess.  Interworking is basically
>>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>>> hardly anybody is going to be flipping this switch.  I'm not sure it
>>>> really merits an OVERRIDE.
>>>
>>> I'd be happy to remove this option if there are no objections. It was
>>> left for compatibility with the existing tune-thumb file but as you say,
>>> it likely doesn't make much sense.
>>>
>>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>>> @@ -1,11 +1,17 @@
>>>>> -require conf/machine/include/arm/arch-arm.inc
>>>>> +DEFAULTTUNE ?= "xscale"
>>>>>
>>>>> -INHERIT += "siteinfo"
>>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>>>
>>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>>> +
>>>>> +AVAILTUNES += "xscale"
>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>>> +
>>>>> +AVAILTUNES += "xscale-be"
>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>>>
>>>> I guess that should be "_tune-xscale-be".
>>>
>>> Yes, I'll fix, well spotted.
>>
>> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
>> little endian version of xscale.  (there was an iwmmxt that was similar to
>> xscale, but was slightly different.)
> 
> pxa25x are LE xscales (e.g. Palm Treo)
> pxa26x are LE xscales with some NAND builtin
> pxa27x are LE xscales with iwmmxt as an extra

All thought all of those were considered to me iwmmxt cores.  The whole PXA
series naming is very confusing to say the least.

> 
>>
>>>> All in all it seems as though there's an awful lot of expanded cross
>>>> products in this set of patches and I can't help wondering whether a lot
>>>> of this stuff would be better computed programmatically.  I wouldn't be
>>>> at all surprised if there are other copy-and-paste errors like the
>>>> xscale one lurking in that mass of overrides, but it's very hard to spot
>>>> them by eye.  It seems particularly unfortunate that everything has to
>>>> be written out twice, once for big-endian and once for little-endian,
>>>> given that endianness is almost entirely orthogonal to all the other
>>>> "tuning" parameters.
>>>
>>> At least three of us have now done a pass over this so hopefully we've
>>> spotted the major ones but I agree its less than ideal.
>>>
>>> The alternative is to post process the variables somehow, or turn it all
>>> into anonymous python (which from a .conf file is not as easy as it
>>> sounds).
>>>
>>> I do like the fact that it allows some standardisation of the options
>>> available in a given tune file as whether or not big endian was even
>>> possible was previously hit and miss.
>>>
>>> So I think its an improvement but likely not the finished end result.
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - July 27, 2011, 2:55 p.m.
On 7/27/11 9:44 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
>> were thumb(1).  Note, not all ARMv6 processors contain thumb support.
> 
> It is true that all ARMv4T and ARMv5T processors are only Thumb-1.  It's
> also true that Thumb-2 was first implemented in ARM1156, which is an
> ARMv6 core.  But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
> and all three of those are Thumb-1 only.  Given that nobody is likely to
> target ARM1156 with OE, it's probably a reasonable approximation to say
> that Thumb-2 correlates with ARMv7 and later.

If all of the other ARMv6 cores w/ thumb support are thumb1.  Then it's easily
enough to change it back to 't'.  If someone does add tunings for the 1156 then
they can easily augment it to t2 within that tuning file.  I didn't realize not
all of armv6 (that supported thumb) wasn't thumb2 (or no thumb).

> Also, since there are no v5, v6 or v7 cores which don't support Thumb,
> the "t" suffix serves no useful purpose here and might as well just be
> omitted.  That is, there is no CPU which can run "armv6" packages which
> wouldn't also be able to run "armv6t".

There are definitely chips that are v5, 6 and 7 that do not have thumb support.
 I'm not sure any of them were mass-market chips though.

>> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
>> little endian version of xscale.
> 
> No, that's incorrect.  The PXA25x series and IXP420, at least, are
> bi-endian (and I suspect most of the other XScales are too) and there
> are certainly folks running them in little endian configurations.

Ok.

--Mark

> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 27, 2011, 2:57 p.m.
On Wed, 2011-07-27 at 09:49 -0500, Mark Hatle wrote:
> On 7/27/11 9:33 AM, Koen Kooi wrote:
> > As I understand it:
> > 
> > arm1136 doesn't have t2
> > arm1176 does have t2
> > 
> > both are armv6 :)
> 
> They also don't have "thumb" support either.  So armv6 & thumb == t2.

No, that's incorrect.  Both ARM1136 and ARM1176 do have Thumb-1 and, as
I wrote in my last mail, I can't think of any plausible target processor
for OE that has both ARMv6 and Thumb-2.  So, for all current intents and
purposes, (armv6 && thumb) == thumb-1.

p.
Mark Hatle - July 27, 2011, 2:58 p.m.
On 7/27/11 9:34 AM, Phil Blundell wrote:
> I just looked at this again and here are a few more comments:
> 
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> 
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will get a mixture of big and little endian in there.
> 
>> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
>> @@ -0,0 +1,40 @@
>> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
>> +
>> +require conf/machine/include/arm/arch-armv5.inc
>> +
>> +# Little Endian
>> +AVAILTUNES += "armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
>> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
>> +
>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
>> new file mode 100644
>> index 0000000..55cbe03
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
>> @@ -0,0 +1,51 @@
>> +# Little Endian
>> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5 ?= "armv5"
>> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> 
> There seems to be some duplication of AVAILTUNES going on here.
> 
> Also, I think this v5 stuff is more complex than it needs to be because
> it seems to be trying to cater for architecture combinations that are
> possible in theory but don't actually exist in the wild.  For example, I
> can't immediately think of any ARMv5 implementations that lack Thumb or
> the E instructions.

For the tune names..  armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.

So armv5 and armv5t are distinct in the contents of the tunings.

There were armv5's without thumb support.. but that doesn't matter much.  A
machine with thumb is compatible (run-time) with one that does not.  A machine
w/o thumb is not necessarily compatible with thumb executables.

>> +# Little Endian + VFP/DSP
>> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> 
> The comment doesn't seem to match the code here since this is the
> section for chips without DSP.  Incidentally, the name "dsp" for this
> feature seems quite a bad one: maybe we should just call it "armv5e".

Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
the "dsp" capabilities actually change any of the code or support generated.  If
not then we can ignore it.

For armv5 this gives us:

armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
EABI...

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - July 27, 2011, 3:01 p.m.
Op 27 jul. 2011, om 16:57 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-07-27 at 09:49 -0500, Mark Hatle wrote:
>> On 7/27/11 9:33 AM, Koen Kooi wrote:
>>> As I understand it:
>>> 
>>> arm1136 doesn't have t2
>>> arm1176 does have t2
>>> 
>>> both are armv6 :)
>> 
>> They also don't have "thumb" support either.  So armv6 & thumb == t2.
> 
> No, that's incorrect.  Both ARM1136 and ARM1176 do have Thumb-1 and, as
> I wrote in my last mail, I can't think of any plausible target processor
> for OE that has both ARMv6 and Thumb-2.  So, for all current intents and
> purposes, (armv6 && thumb) == thumb-1.

the s3c6410 is arm1176 which should support T2. Having said that, I'm not  sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
Phil Blundell - July 27, 2011, 3:08 p.m.
On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
> the s3c6410 is arm1176 which should support T2. Having said that, I'm not  sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.

What makes you think that ARM1176 has T2?  I haven't actually tried
executing Thumb-2 on one, but my recollection is definitely that it was
Thumb-1 only.

p.
Koen Kooi - July 27, 2011, 3:13 p.m.
Op 27 jul. 2011, om 17:08 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
>> the s3c6410 is arm1176 which should support T2. Having said that, I'm not  sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
> 
> What makes you think that ARM1176 has T2?  I haven't actually tried
> executing Thumb-2 on one, but my recollection is definitely that it was
> Thumb-1 only.

In this case it's (yes, you may start making fun of me at this point) wikipedia: http://en.wikipedia.org/wiki/ARM#Thumb-2
Phil Blundell - July 27, 2011, 3:17 p.m.
On Wed, 2011-07-27 at 17:13 +0200, Koen Kooi wrote:
> Op 27 jul. 2011, om 17:08 heeft Phil Blundell het volgende geschreven:
> 
> > On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
> >> the s3c6410 is arm1176 which should support T2. Having said that, I'm not  sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
> > 
> > What makes you think that ARM1176 has T2?  I haven't actually tried
> > executing Thumb-2 on one, but my recollection is definitely that it was
> > Thumb-1 only.
> 
> In this case it's (yes, you may start making fun of me at this point) wikipedia: http://en.wikipedia.org/wiki/ARM#Thumb-2

I couldn't immediately see anything on that page which referred to the
ARM1176 specifically.  There is a slightly vague sentence which talks
about "[o]ther chips in the Cortex and ARM11 series", which I guess
could be construed as "all other chips", but apart from that it doesn't
seem to be saying much about what implementation goes with which ISA.

Anyway, the ARM1176 spec and reference manual are available on the web
and I think this is probably a more reliable source than wikipedia :-)

http://www.arm.com/products/processors/classic/arm11/arm1176.php

p.
Phil Blundell - July 27, 2011, 3:25 p.m.
On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> means I was thumb instructions.
> 
> So armv5 and armv5t are distinct in the contents of the tunings.

Ah, I see.  Does that go for v4t too?  I can imagine cases where you
would want to say "select the v4T ISA but generate ARM code not Thumb".

> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
> the "dsp" capabilities actually change any of the code or support generated.  If
> not then we can ignore it.

Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
will affect any code which uses __builtin_prefetch().  I don't think GCC
will ever open-code the saturating arithmetic instructions, but it does
expose the v5/v5e distinction through preprocessor macros and source
code might use that to select asm() statements which use those opcodes.

> For armv5 this gives us:
> 
> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> EABI...

Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
hurt all that much to offer it, but anything that makes that monstrous
set of .inc files bigger seems like a bad thing.

p.
Richard Purdie - July 27, 2011, 3:29 p.m.
On Wed, 2011-07-27 at 16:25 +0100, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> > For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> > means I was thumb instructions.
> > 
> > So armv5 and armv5t are distinct in the contents of the tunings.
> 
> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".
> 
> > Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
> > the "dsp" capabilities actually change any of the code or support generated.  If
> > not then we can ignore it.
> 
> Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch().  I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.
> 
> > For armv5 this gives us:
> > 
> > armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> > EABI...
> 
> Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.

Just to summarise where we're at with this, I thought comments had died
down from anyone likely to comment so I merged the patches since there
was a done depending upon them. Comments then picked up again.

The code is now as it stands, I'll take patches to improve/fix things as
usual...

Cheers,

Richard
Phil Blundell - July 27, 2011, 3:49 p.m.
On Wed, 2011-07-27 at 16:29 +0100, Richard Purdie wrote:
> Just to summarise where we're at with this, I thought comments had died
> down from anyone likely to comment so I merged the patches since there
> was a done depending upon them. Comments then picked up again.

Fair enough, though I think this was perhaps a bit premature.  It is/was
a big and complicated patch and you only posted it for review yesterday
afternoon.  In future it would be nice to have a bit more time for
reviewing this sort of thing.

p.
Mark Hatle - July 27, 2011, 5:19 p.m.
On 7/27/11 10:25 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
>> means I was thumb instructions.
>>
>> So armv5 and armv5t are distinct in the contents of the tunings.
> 
> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".

Yes, for all of them, the TUNENAME selects the features that you want to use to
compile, and suggests the other information like compatible architectures.

In the case where you want to build primarily one, and optionally the other the
tunename makes it easy..

Say you want all of your system thumb, except for a few specific programs..

TUNENAME = "armv4t"

TUNENAME_pn-mysql = "armv4"

In the opposite case, where you want everything ARM, except for a few thumb:

TUNENAME = "armv7"
TUNENAME_pn-bash = "armv7t"

PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}

Second line ensures that the base armv7 tune inherits the "more complete" set of
compatible machines.

(Note, in most cases I would expect a machine/BSP configuration to do most of
this inheriting... or if someone was being tricky they can do it manually.)
>> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
>> the "dsp" capabilities actually change any of the code or support generated.  If
>> not then we can ignore it.
> 
> Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch().  I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.

So then the question is.. with OE-core and core based distros.. are there enough
armv5 (w/ or w/o e) left to justify having both?  If not.. then we select the
one with the 'e' since it's more common.

>> For armv5 this gives us:
>>
>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>> EABI...
> 
> Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.

I was surprised anyone wanted the hardfloat ABI at all.. :P ...but anyway... if
it'll work on armv5 (and the previous question about is armv5 relevant answered)
we can choose it or not..  It was there to be complete in the original
version...  (also armv5 w/ VFP is the lowest compatible machine for a HF
implementation.)

--Mark

> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - July 27, 2011, 5:31 p.m.
<snip patch>

It looks like PACKAGE_*_ARCHS is broken in the rootfs class:

cat /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/efl-nodm-image-1.0-r0/opkg.conf:
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch beagleboard 21

But the one in the opkg config package is correct:

koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ dpkg-deb -x ipk/beagleboard/opkg-config-base_1.0-r0_beagleboard.ipk tmp/
koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ cat tmp/etc/opkg/arch.conf 
arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armv4 21
arch armv4t 26
arch armv5te 31
arch armv6 36
arch armv7 41
arch armv7a 46
arch beagleboard 51
koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$
Koen Kooi - July 27, 2011, 6:19 p.m.
Op 27 jul. 2011, om 19:31 heeft Koen Kooi het volgende geschreven:

> <snip patch>
> 
> It looks like PACKAGE_*_ARCHS is broken in the rootfs class:
> 
> cat /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/efl-nodm-image-1.0-r0/opkg.conf:
> arch all 1
> arch any 6
> arch noarch 11
> arch arm 16
> arch beagleboard 21
> 
> But the one in the opkg config package is correct:
> 
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ dpkg-deb -x ipk/beagleboard/opkg-config-base_1.0-r0_beagleboard.ipk tmp/
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ cat tmp/etc/opkg/arch.conf 
> arch all 1
> arch any 6
> arch noarch 11
> arch arm 16
> arch armv4 21
> arch armv4t 26
> arch armv5te 31
> arch armv6 36
> arch armv7 41
> arch armv7a 46
> arch beagleboard 51
> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/deploy$ 

bitbake -e:

# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch arm armv4 armv4t armv5 armv5t armv5-vfp armv5t-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv6-vfp armv6t-vfp armv7-vfp armv7t2-vfp armv7a-vfp armv7at2-vfp armv7a-vfp-neon armv7at2-vfp-neon beagleboard"

bitbake -e some-image:

# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch arm beagleboard"
PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon="armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7hf-vfp armv7t2hf-vfp armv7hf-vfp-neon armv7at2hf-vfp-neon"

So it looks like all the tune-* overrides don't get expanded when building an image.
Phil Blundell - July 27, 2011, 7:31 p.m.
On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> > 
> > Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
> 
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
> 
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
> 
> Say you want all of your system thumb, except for a few specific programs..
> 
> TUNENAME = "armv4t"
> 
> TUNENAME_pn-mysql = "armv4"
> 
> In the opposite case, where you want everything ARM, except for a few thumb:
> 
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"

I'm not quite sure that this answers the question I was trying to ask.

The thing about v4/v4T is that, unlike later versions of the
architecture, plain v4 doesn't include the BX instruction.  So, if you
want your code to be interworking-capable without requiring linker
shims, you need to specify -march=armv4t (and -mthumb-interwork) even
for CUs that you want to compile as ARM code.

If the architecture name implies the execution state then it doesn't
appear as though there is going to be any way to select -march=armv4t
without also selecting -mthumb, which would make it impossible to build
interworking-capable ARM-state code for v4T.

> So then the question is.. with OE-core and core based distros.. are there enough
> armv5 (w/ or w/o e) left to justify having both?  If not.. then we select the
> one with the 'e' since it's more common.

I'm not aware of anybody using a non-e ARMv5 with OE at all.  The two
most common v5-class implementations, by some margin I think, are the
ARM9x6 family and Xscale, and all of those are at least v5TE. 

p.
Mark Hatle - July 27, 2011, 8:48 p.m.
On 7/27/11 2:31 PM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
>> On 7/27/11 10:25 AM, Phil Blundell wrote:
>>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
>>>> means I was thumb instructions.
>>>>
>>>> So armv5 and armv5t are distinct in the contents of the tunings.
>>>
>>> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
>>> would want to say "select the v4T ISA but generate ARM code not Thumb".
>>
>> Yes, for all of them, the TUNENAME selects the features that you want to use to
>> compile, and suggests the other information like compatible architectures.
>>
>> In the case where you want to build primarily one, and optionally the other the
>> tunename makes it easy..
>>
>> Say you want all of your system thumb, except for a few specific programs..
>>
>> TUNENAME = "armv4t"
>>
>> TUNENAME_pn-mysql = "armv4"
>>
>> In the opposite case, where you want everything ARM, except for a few thumb:
>>
>> TUNENAME = "armv7"
>> TUNENAME_pn-bash = "armv7t"
> 
> I'm not quite sure that this answers the question I was trying to ask.
> 
> The thing about v4/v4T is that, unlike later versions of the
> architecture, plain v4 doesn't include the BX instruction.  So, if you
> want your code to be interworking-capable without requiring linker
> shims, you need to specify -march=armv4t (and -mthumb-interwork) even
> for CUs that you want to compile as ARM code.
> 
> If the architecture name implies the execution state then it doesn't
> appear as though there is going to be any way to select -march=armv4t
> without also selecting -mthumb, which would make it impossible to build
> interworking-capable ARM-state code for v4T.

It was my understanding that interwork was always enabled these days.  Does
interworking require a thumb compatible arm core?

--Mark

>> So then the question is.. with OE-core and core based distros.. are there enough
>> armv5 (w/ or w/o e) left to justify having both?  If not.. then we select the
>> one with the 'e' since it's more common.
> 
> I'm not aware of anybody using a non-e ARMv5 with OE at all.  The two
> most common v5-class implementations, by some margin I think, are the
> ARM9x6 family and Xscale, and all of those are at least v5TE. 
> 
> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 27, 2011, 9:16 p.m.
On Wed, 2011-07-27 at 15:48 -0500, Mark Hatle wrote:
> On 7/27/11 2:31 PM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 12:19 -0500, Mark Hatle wrote:
> >> On 7/27/11 10:25 AM, Phil Blundell wrote:
> >>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >>>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> >>>> means I was thumb instructions.
> >>>>
> >>>> So armv5 and armv5t are distinct in the contents of the tunings.
> >>>
> >>> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> >>> would want to say "select the v4T ISA but generate ARM code not Thumb".
> >>
> >> Yes, for all of them, the TUNENAME selects the features that you want to use to
> >> compile, and suggests the other information like compatible architectures.
> >>
> >> In the case where you want to build primarily one, and optionally the other the
> >> tunename makes it easy..
> >>
> >> Say you want all of your system thumb, except for a few specific programs..
> >>
> >> TUNENAME = "armv4t"
> >>
> >> TUNENAME_pn-mysql = "armv4"
> >>
> >> In the opposite case, where you want everything ARM, except for a few thumb:
> >>
> >> TUNENAME = "armv7"
> >> TUNENAME_pn-bash = "armv7t"
> > 
> > I'm not quite sure that this answers the question I was trying to ask.
> > 
> > The thing about v4/v4T is that, unlike later versions of the
> > architecture, plain v4 doesn't include the BX instruction.  So, if you
> > want your code to be interworking-capable without requiring linker
> > shims, you need to specify -march=armv4t (and -mthumb-interwork) even
> > for CUs that you want to compile as ARM code.
> > 
> > If the architecture name implies the execution state then it doesn't
> > appear as though there is going to be any way to select -march=armv4t
> > without also selecting -mthumb, which would make it impossible to build
> > interworking-capable ARM-state code for v4T.
> 
> It was my understanding that interwork was always enabled these days.  Does
> interworking require a thumb compatible arm core?

Not for v5 and up, since the ARM-state BX instruction always exists
(even if it isn't capable of switching to Thumb-state), and pop {pc}
always changes state if necessary.  The combination of these two things
means that interworking basically comes for free and there is no benefit
to turning it off.

But for v4T, the only instruction which is capable of a state change is
BX, and that instruction simply doesn't exist at all in the non-T v4
architecture.  So, if you plan to run on a v4 core you must either build
with interworking off, or (more commonly nowadays) use the --fix-v4bx
linker option to convert BX back to MOV during final link.

p.
Khem Raj - July 28, 2011, 12:43 a.m.
> > 
> > It was my understanding that interwork was always enabled these days.  Does
> > interworking require a thumb compatible arm core?
> 
> Not for v5 and up, since the ARM-state BX instruction always exists
> (even if it isn't capable of switching to Thumb-state), and pop {pc}
> always changes state if necessary.  The combination of these two things
> means that interworking basically comes for free and there is no benefit
> to turning it off.
> 
> But for v4T, the only instruction which is capable of a state change is
> BX, and that instruction simply doesn't exist at all in the non-T v4
> architecture.  So, if you plan to run on a v4 core you must either build
> with interworking off, or (more commonly nowadays) use the --fix-v4bx
> linker option to convert BX back to MOV during final link.

We use --fix-v4bx in oe
Martin Jansa - July 28, 2011, 7:24 a.m.
On Wed, Jul 27, 2011 at 12:19:22PM -0500, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> > 
> > Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
> 
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
> 
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
> 
> Say you want all of your system thumb, except for a few specific programs..
> 
> TUNENAME = "armv4t"
> 
> TUNENAME_pn-mysql = "armv4"
> 
> In the opposite case, where you want everything ARM, except for a few thumb:
> 
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
> 
> PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}

We've discussed this yesterday on #yocto and there is problem with this

Before tune-* overhaul we had ARM_INSTRUCTION_SET option to force arm
mode from recipe even for architectures supporting thumb (ie armv4t).

Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
switched to "armv4" only to indicate that.

But ARM_INSTRUCTION_SET worked for all ARM architectures, but now I
would need to set
TUNENAME_pn-eglibc = "armv4" in openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc
TUNENAME_pn-eglibc = "armv5" in openembedded-core/meta/conf/machine/include/arm/arch-armv5.inc
TUNENAME_pn-eglibc = "armv6" in openembedded-core/meta/conf/machine/include/arm/arch-armv6.inc
TUNENAME_pn-eglibc = "armv7" in openembedded-core/meta/conf/machine/include/arm/arch-armv7.inc
etc.. because I cannot disable thumb (while keeping thumb-interwork
enabled) from recipe globally for all as 
openembedded-core/meta/conf/machine/include/tune-thumb.inc
does, but that's not used and 
ARM_THUMB_M_OPT = "${@['-mno-thumb','-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
is not respected anymore in
openembedded-core/meta/conf/machine/include/arm/feature-arm-thumb.inc

ARM_INSTRUCTION_SET = "arm" is used in some recipes because with thumb
enabled it fails to build and maybe such recipes can be fixed
(ie eglibc now fails for armv4t and armv7a)
and for some recipes it's set because it's producing faster code (where
binary size was more important).

Another problem with setting TUNENAME_pn-foo for every arch is when
foo_1.0.bb is in some obscure layer somewhere and maintainer of that
layer would need to alter all arch-armv[4567]*.inc files to keep foo
from using thumb. Maybe something like this in recipe should work?
TUNENAME_pn-eglibc_armv4t = "armv4"
TUNENAME_pn-eglibc_armv5t = "armv5"

And scale of ARM_INSTRUCTION_SET now ignored with oe-core:
OE om-gta02@shr ~/shr-core/openembedded-core $ git grep ARM_INSTRUCTION_SET
meta/classes/qt4e.bbclass:ARM_INSTRUCTION_SET = "arm"
meta/classes/qt4x11.bbclass:ARM_INSTRUCTION_SET = "arm"
meta/conf/machine/include/tune-thumb.inc:ARM_INSTRUCTION_SET ?= "arm"
meta/conf/machine/include/tune-thumb.inc:OVERRIDE_THUMB = "${@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
meta/conf/machine/include/tune-thumb.inc:ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
meta/recipes-core/eglibc/eglibc.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glib-2.0/glib.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glibc/glibc.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/glibc/glibc_2.10.1.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-core/uclibc/uclibc.inc:                ${@["","s,.*COMPILE_IN_THUMB_MODE.*,COMPILE_IN_THUMB_MODE=y,;"][bb.data.getVar("ARM_INSTRUCTION_SET", d, 1) != "arm"]} \
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-multimedia/tremor/tremor_20101121.bb:ARM_INSTRUCTION_SET = "arm"
meta/recipes-qt/qt4/qt4_arch.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/boost/boost-36.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/gmp/gmp.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/libgcrypt/libgcrypt.inc:ARM_INSTRUCTION_SET = "arm"
meta/recipes-support/liboil/liboil_0.3.17.bb:ARM_INSTRUCTION_SET = "arm"

OE om-gta02@shr ~/shr-core/meta-openembedded $ git grep ARM_INSTRUCTION_SET
meta-efl/classes/e-base.bbclass:ARM_INSTRUCTION_SET = "arm"
meta-efl/recipes-efl/webkit/webkit-efl_svn.bb:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-core/glib-2.0/glib.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-devtools/gcc/gcc-4.5.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-devtools/gcc/gcc-common-4.6.inc:ARM_INSTRUCTION_SET = "arm"
meta-oe/recipes-support/postgresql/postgresql.inc:ARM_INSTRUCTION_SET = "arm"

Regards,
Phil Blundell - July 28, 2011, 8:54 a.m.
On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
> Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
> no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
> switched to "armv4" only to indicate that.

No, this is wrong.  Even with ARM_INSTRUCTION_SET = "arm" you might have
BX instructions in the output, in which case "armv4t" is the correct
PACKAGE_ARCH.  You can only set PACKAGE_ARCH = "armv4" if all the BXs
have been suppressed, which means that you lose the ability to do
interworking.

p.
Phil Blundell - July 28, 2011, 11:39 a.m.
On Wed, 2011-07-27 at 15:34 +0100, Phil Blundell wrote:
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
> > +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> 
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will get a mixture of big and little endian in there.

I think the equivalent big-endian definitions for v5 and v6 have this
problem too.  For example:

PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"

seems wrongish to me.  

p.
Martin Jansa - July 28, 2011, 6:17 p.m.
On Thu, Jul 28, 2011 at 09:54:06AM +0100, Phil Blundell wrote:
> On Thu, 2011-07-28 at 09:24 +0200, Martin Jansa wrote:
> > Mark is right that if we have PACKAGE_ARCH = "armv4t" and we force
> > no-thumb with ARM_INSTRUCTION_SET = "arm" then PACKAGE_ARCH should be
> > switched to "armv4" only to indicate that.
> 
> No, this is wrong.  Even with ARM_INSTRUCTION_SET = "arm" you might have
> BX instructions in the output, in which case "armv4t" is the correct
> PACKAGE_ARCH.  You can only set PACKAGE_ARCH = "armv4" if all the BXs
> have been suppressed, which means that you lose the ability to do
> interworking.

Ah right, we cannot allow this to be in ie collie feed. So old behavior
was correct in this aspect too.

Thanks
Khem Raj - July 29, 2011, 5:59 a.m.
Hi Mark,Richard

currently qemuarm does not build due to this patch forcing thumb mode
as default  for all 't' architectures which could have worked if recipes
using ARM_INSTRUCTION_SET="arm" in them were somehow excluded from 
building in thumb mode. Further comments are inline.

On 07/26/2011 05:44 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie<richard.purdie@linuxfoundation.org>
> ---
>   meta/conf/machine/include/arm/arch-arm.inc         |   16 +++++-
>   meta/conf/machine/include/arm/arch-armv4.inc       |   24 +++++++++
>   meta/conf/machine/include/arm/arch-armv5-dsp.inc   |   40 ++++++++++++++
>   meta/conf/machine/include/arm/arch-armv5.inc       |   51 ++++++++++++++++++
>   meta/conf/machine/include/arm/arch-armv6.inc       |   32 +++++++++++
>   meta/conf/machine/include/arm/arch-armv7.inc       |   55 ++++++++++++++++++++
>   meta/conf/machine/include/arm/arch-armv7a.inc      |   54 +++++++++++++++++++
>   meta/conf/machine/include/arm/feature-arm-neon.inc |    3 +
>   .../conf/machine/include/arm/feature-arm-thumb.inc |   25 +++++++++
>   meta/conf/machine/include/arm/feature-arm-vfp.inc  |    6 ++
>   meta/conf/machine/include/tune-arm1136jf-s.inc     |   14 +++---
>   meta/conf/machine/include/tune-arm920t.inc         |   14 ++++--
>   meta/conf/machine/include/tune-arm926ejs.inc       |   18 ++++---
>   meta/conf/machine/include/tune-arm9tdmi.inc        |   14 ++++--
>   meta/conf/machine/include/tune-armv7.inc           |    8 +---
>   meta/conf/machine/include/tune-cortexa8.inc        |   21 ++++----
>   meta/conf/machine/include/tune-cortexm1.inc        |   13 ++++-
>   meta/conf/machine/include/tune-cortexm3.inc        |   18 +++++--
>   meta/conf/machine/include/tune-cortexr4.inc        |   18 +++++--
>   meta/conf/machine/include/tune-ep9312.inc          |   16 ++++--
>   meta/conf/machine/include/tune-iwmmxt.inc          |   18 +++++--
>   meta/conf/machine/include/tune-strongarm1100.inc   |   13 +++--
>   meta/conf/machine/include/tune-xscale.inc          |   18 ++++--
>   23 files changed, 435 insertions(+), 74 deletions(-)
>   create mode 100644 meta/conf/machine/include/arm/arch-armv4.inc
>   create mode 100644 meta/conf/machine/include/arm/arch-armv5-dsp.inc
>   create mode 100644 meta/conf/machine/include/arm/arch-armv5.inc
>   create mode 100644 meta/conf/machine/include/arm/arch-armv6.inc
>   create mode 100644 meta/conf/machine/include/arm/arch-armv7.inc
>   create mode 100644 meta/conf/machine/include/arm/arch-armv7a.inc
>   create mode 100644 meta/conf/machine/include/arm/feature-arm-neon.inc
>   create mode 100644 meta/conf/machine/include/arm/feature-arm-thumb.inc
>   create mode 100644 meta/conf/machine/include/arm/feature-arm-vfp.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
> index c517df6..4ea8b2b 100644
> --- a/meta/conf/machine/include/arm/arch-arm.inc
> +++ b/meta/conf/machine/include/arm/arch-arm.inc
> @@ -1,3 +1,17 @@
> -TUNE_ARCH = "arm"
> +
> +TUNEVALID[bigendian] = "Enable big-endian mode."
> +
> +ARMPKGARCH ??= "arm"
> +ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
> +ARMPKGSFX_FPU ??= ""
> +ARMPKGSFX_DSP ??= ""
> +ARMPKGSFX_EABI ??= ""
> +ARMPKGSFX_THUMB ??= ""
> +
> +TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
> +TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
>
>   ABIEXTENSION = "eabi"
> +
> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
> new file mode 100644
> index 0000000..c014d20
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv4.inc
> @@ -0,0 +1,24 @@
> +DEFAULTTUNE ?= "armv4"
> +
> +ARMPKGARCH ?= "armv4"
> +
> +TUNEVALID[armv4] = "Enable instructions for ARMv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
> +
> +require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/feature-arm-thumb.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv4 armv4t"
> +TUNE_FEATURES_tune-armv4 ?= "armv4"
> +TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"

this here means we want to generate thumb code by default if one uses 
ARMv4t core. Which is ok but find out all the recipes thats using 
ARM_INSTRUCTION_SET = arm at present and we have to have a way to 
exclude them. I think having  them specified here with some override
is not good since it will mean that if some layer has a recipe which can
not be compiled in thumb mode has to have an entry here.

Is it possible to filter out a given TUNE_FEATURE inside a recipe ?

> +PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
> +PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
> +
> +# Big Endian
> +AVAILTUNES += "armv4b armv4tb"
> +TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
> +TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> new file mode 100644
> index 0000000..498a012
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> @@ -0,0 +1,40 @@
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5e armv5te"
> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
> +TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
> +TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
> +TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5eb armv5teb"
> +TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
> +TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
> +TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
> new file mode 100644
> index 0000000..55cbe03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
> @@ -0,0 +1,51 @@
> +DEFAULTTUNE ?= "armv5"
> +
> +ARMPKGARCH ?= "armv5"
> +
> +TUNEVALID[armv5] = "Enable instructions for ARMv5"
> +TUNE_CONFLICTS[armv5] = "armv4"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
> +
> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +require conf/machine/include/arm/feature-arm-vfp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
> +TUNE_FEATURES_tune-armv5 ?= "armv5"
> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> +
> +# Little Endian + VFP/DSP
> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> +TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
> +TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv5b armv5tb"
> +TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
> +TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
> +
> +# Big Endian + VFP/DSP
> +AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
> +TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
> +TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
> +TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
> +
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
> new file mode 100644
> index 0000000..20924c9
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv6.inc
> @@ -0,0 +1,32 @@
> +DEFAULTTUNE ?= "armv6"
> +
> +ARMPKGARCH ?= "armv6"
> +
> +TUNEVALID[armv6] = "Enable instructions for ARMv6"
> +TUNE_CONFLICTS[armv6] = "armv4 armv5"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +# Little Endian
> +AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
> +TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
> +TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"

so it seems any achitecture that supports thumb we resport to thumb 
intruction set. I dont think thats what we want. We should be able to 
select  the intruction set on architectures where choice is available 
e.g. on armv5t we can use arm or thumb but on armv5 there is no choice
so we have to use arm. and cortex-m3 we have to use thumb2 there is no 
other choice etc.

> +TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
> +
> +# Big Endian
> +AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
> +TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
> +TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
> +TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
> +TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
> new file mode 100644
> index 0000000..8bc8d10
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7.inc
> @@ -0,0 +1,55 @@
> +DEFAULTTUNE ?= "armv7"
> +
> +ARMPKGARCH ?= "armv7"
> +
> +TUNEVALID[armv7] = "Enable instructions for ARMv7"
> +TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv6.inc
> +require conf/machine/include/arm/feature-arm-neon.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
> +TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
> +TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
> +TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
> +TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
> +TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
> +TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
> +TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
> +TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
> +TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> new file mode 100644
> index 0000000..ce9cee5
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -0,0 +1,54 @@
> +DEFAULTTUNE ?= "armv7a"
> +
> +ARMPKGARCH ?= "armv7a"
> +
> +TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
> +TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
> +
> +require conf/machine/include/arm/arch-armv7.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
> +TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
> +TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
> +TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
> +TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
> +
> +# VFP Tunes
> +AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
> +TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
> +
> +# Big Endian
> +AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
> +TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
> +TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
> +TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
> +TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
> +
> +# Big Endian + VFP
> +AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
> +TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
> +TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
> +TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
> +PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
> +
> diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
> new file mode 100644
> index 0000000..a7dac03
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
> @@ -0,0 +1,3 @@
> +TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> new file mode 100644
> index 0000000..9a607c6
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -0,0 +1,25 @@
> +# The instruction set the compiler should use when generating application
> +# code. The kernel is always compiled with arm code at present. arm code
> +# is the original 32 bit ARM instruction set, thumb code is the 16 bit
> +# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
> +# but requires more instructions (140% for 70% smaller code) so may be
> +# slower.
> +TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"

it seems thumb being present in TUNE_FEATURES is meant for generating 
thumb code. Which is fine however all packages currently can not be 
compiled in thumb mode for various reasons. Most important of all is 
eglibc/glibc. It can be compiled in thumb2 but not thumb1 so While we 
would like to generate as much thumb as possible its not possible to 
compile everything in thumb. So we had ARM_INSTRUCTION_SET which was
used to configure intruction set at recipe level. How do we do that with
this new tune infra ?

> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
> +
> +# Note armv7 will hit on armv7a as well
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
> +
> +# Whether to compile with code to allow interworking between the two
> +# instruction sets. This allows thumb code to be executed on a primarily
> +# arm system and vice versa. It is strongly recommended that DISTROs not
> +# turn this off - the actual cost is very small.
> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
> +
> +TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
> diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> new file mode 100644
> index 0000000..29a925c
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> @@ -0,0 +1,6 @@
> +TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
> +
> +TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
> diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
> index 953f0dd..4f4a2eb 100644
> --- a/meta/conf/machine/include/tune-arm1136jf-s.inc
> +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
> @@ -1,10 +1,10 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm1136jfs"
>
> -TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
> -TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
> -TUNE_PKGARCH = "armv6"
> +require conf/machine/include/arm/arch-armv6.inc
>
> -ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
> +TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
>
> -require conf/machine/include/tune-thumb.inc
> +AVAILTUNES += "arm1136jfs"
> +TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
> +PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
> diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
> index 6c87026..b7584ab 100644
> --- a/meta/conf/machine/include/tune-arm920t.inc
> +++ b/meta/conf/machine/include/tune-arm920t.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm920t"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
> +
> +AVAILTUNES += "arm920t"

here I guess we have to say AVAILTUNES += "arm920t arm920"
where arm920 is arm mode and 920t is thumb mode. but anyway I would 
prefer that thumb is optionally added provided user asked for it
through DISTRO/MACHINE features then we should first make sure
that selected machine has thumb feature and if yes for both then we 
should enable -mthumb compiler option which now it enable when thumb 
appears in TUNE_FEATURES

> +TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
> +PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>


> -TUNE_PKGARCH = "armv4t"
> -TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
> index 543ab62..7f2cc4e 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -1,9 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
> -TUNE_PKGARCH = "armv5te"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
> -# For gcc 3.x you need:
> -#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
> -# For gcc 4.x you need:
> -TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
> +DEFAULTTUNE ?= "arm926ejs"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
> +
> +AVAILTUNES += "arm926ejs"
> +TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>
> diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
> index f1001ac..0dc5c26 100644
> --- a/meta/conf/machine/include/tune-arm9tdmi.inc
> +++ b/meta/conf/machine/include/tune-arm9tdmi.inc
> @@ -1,5 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "arm9tdmi"
> +
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
> +
> +AVAILTUNES += "arm9tdmi"
> +TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
> +PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
>
> -TUNE_PKGARCH = "armv4t"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
> -TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
> diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
> index 8a68c0a..664c24b 100644
> --- a/meta/conf/machine/include/tune-armv7.inc
> +++ b/meta/conf/machine/include/tune-armv7.inc
> @@ -1,8 +1,2 @@
> -require conf/machine/include/arm/arch-arm.inc
> +require conf/machine/include/arm/arch-armv7.inc
>
> -# valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
> -# valid option for -mtune: `cortex-a8', `cortex-r4', `cortex-m3', `cortex-m1'
> -# This will NOT compile programs in 'ARM' mode, which is what you really want
> -TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index ae50954..b07add4 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -1,15 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexa8-neon"
>
> +require conf/machine/include/arm/arch-armv7a.inc
>
> -# Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3]
> -# [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
> -# [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
> -# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
> +TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
>
> -TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
> +AVAILTUNES += "cortexa8 cortexa8t"
> +TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
> +TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
> +TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
>
> -# Other potentially useful options
> -#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
>
> -TUNE_PKGARCH = "armv7a"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
> diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
> index b944db4..493025d 100644
> --- a/meta/conf/machine/include/tune-cortexm1.inc
> +++ b/meta/conf/machine/include/tune-cortexm1.inc
> @@ -1,4 +1,11 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm1"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
> +
> +AVAILTUNES += "cortexm1"
> +TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
>
> -TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv6"
> diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
> index a77cbdd..f774fa6 100644
> --- a/meta/conf/machine/include/tune-cortexm3.inc
> +++ b/meta/conf/machine/include/tune-cortexm3.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexm3"
> +ARMPKGARCH ?= "armv7m"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
> +
> +TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexm3"
> +TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
> +PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
>
> -# valid options for -march: `armv7', `armv7-m'
> -TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
> index c9193ca..738f5af 100644
> --- a/meta/conf/machine/include/tune-cortexr4.inc
> +++ b/meta/conf/machine/include/tune-cortexr4.inc
> @@ -1,5 +1,15 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "cortexr4"
> +ARMPKGARCH ?= "armv7r"
> +
> +require conf/machine/include/arm/arch-armv7a.inc
> +
> +TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
> +
> +TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
> +
> +AVAILTUNES += "cortexr4"
> +TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
> +PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
>
> -# valid options for -march: `armv7', `armv7-r'
> -TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
> -TUNE_PKGARCH = "armv7"
> diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
> index e04a00a..f10123f 100644
> --- a/meta/conf/machine/include/tune-ep9312.inc
> +++ b/meta/conf/machine/include/tune-ep9312.inc
> @@ -1,9 +1,13 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "ep9312"
> +ARMPKGARCH ?= "ep9312"
>
> -TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
> -# add "-mfp=maverick" for newer gcc versions>  4.0
> +require conf/machine/include/arm/arch-armv4.inc
> +
> +TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
> +
> +AVAILTUNES += "ep9312"
> +TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
> +PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
>
> -#set arch to ep9312 for all generated packages
> -PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
> -TUNE_PKGARCH = "ep9312"
>
> diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
> index 6bb76d5..14f5955 100644
> --- a/meta/conf/machine/include/tune-iwmmxt.inc
> +++ b/meta/conf/machine/include/tune-iwmmxt.inc
> @@ -1,8 +1,16 @@
> -require conf/machine/include/arm/arch-arm.inc
> -
>   # Configurations for the Intel PXA27x Appications Processor Family.
>   # Please use tune-xscale for PXA255/PXA26x based processors.
> -TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
> -PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
> -TUNE_PKGARCH = "iwmmxt"
> +
> +DEFAULTTUNE ?= "iwmmxt"
> +ARMPKGARCH ?= "iwmmxt"
> +
> +require conf/machine/include/arm/arch-armv5-dsp.inc
> +
> +TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
> +
> +AVAILTUNES += "iwmmxt"
> +TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
> +PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
> +
>
> diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
> index 2b76069..66bab8e 100644
> --- a/meta/conf/machine/include/tune-strongarm1100.inc
> +++ b/meta/conf/machine/include/tune-strongarm1100.inc
> @@ -1,9 +1,12 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "strongarm"
>
> -TUNE_PKGARCH = "arm"
> +require conf/machine/include/arm/arch-armv4.inc
>
> -# This machine lists common configuration options for Strongarm 1100 devices
> -# NOTE: The Zaurus Collie also has a Strongarm processor, but uses the 1110 type
> +TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
> +
> +AVAILTUNES += "strongarm"
> +TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
> +PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
>
> -TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
>
> diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
> index 71dba5b..0303320 100644
> --- a/meta/conf/machine/include/tune-xscale.inc
> +++ b/meta/conf/machine/include/tune-xscale.inc
> @@ -1,11 +1,17 @@
> -require conf/machine/include/arm/arch-arm.inc
> +DEFAULTTUNE ?= "xscale"
>
> -INHERIT += "siteinfo"
> +require conf/machine/include/arm/arch-armv5-dsp.inc
>
> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
> +
> +AVAILTUNES += "xscale"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
> +
> +AVAILTUNES += "xscale-be"
> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>
>   # webkit-gtk has alignment issues with double instructions on armv5 so
>   # disable them here
Khem Raj - July 29, 2011, 6:08 a.m.
On 07/27/2011 06:33 AM, Richard Purdie wrote:
> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>
>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>> variable and then the package suffix be computed from that, rather than
>> vice versa?
>
> It's been "fun" to use the rather limited constructs we have in these
> variables to construct the end result. I suspect this way around, it was
> the easiest way to get the right variables in the right places.
>
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>
>> This is wrong: ARMv6 doesn't imply Thumb-2.
>
> Ah, yes. I'll fix this.
>
>>> +# Whether to compile with code to allow interworking between the two
>>> +# instruction sets. This allows thumb code to be executed on a primarily
>>> +# arm system and vice versa. It is strongly recommended that DISTROs not
>>> +# turn this off - the actual cost is very small.
>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>
>> This is only relevant for v4t, I guess.  Interworking is basically
>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>> hardly anybody is going to be flipping this switch.  I'm not sure it
>> really merits an OVERRIDE.
>
> I'd be happy to remove this option if there are no objections. It was
> left for compatibility with the existing tune-thumb file but as you say,
> it likely doesn't make much sense.


I know SHR uses armv4t but I dont know of armv4 usecases. May be we 
could may armv4t as oldest supported arm arch and leave armv4 out.
Khem Raj - July 29, 2011, 6:18 a.m.
On 07/27/2011 07:44 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:27 -0500, Mark Hatle wrote:
>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>
>>>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>>>> variable and then the package suffix be computed from that, rather than
>>>> vice versa?
>>>
>>> It's been "fun" to use the rather limited constructs we have in these
>>> variables to construct the end result. I suspect this way around, it was
>>> the easiest way to get the right variables in the right places.
>>>
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>
>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>
>>> Ah, yes. I'll fix this.
>>
>> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
>> were thumb(1).  Note, not all ARMv6 processors contain thumb support.
>
> It is true that all ARMv4T and ARMv5T processors are only Thumb-1.  It's
> also true that Thumb-2 was first implemented in ARM1156, which is an
> ARMv6 core.  But ARM1136, ARM1176 and ARM11MPCore are also ARMv6 cores
> and all three of those are Thumb-1 only.  Given that nobody is likely to
> target ARM1156 with OE, it's probably a reasonable approximation to say
> that Thumb-2 correlates with ARMv7 and later.
>
> Also, since there are no v5, v6 or v7 cores which don't support Thumb,

cortex-m series supports only thumb2 intsruction set. I am not sure if 
thumb2 alone is a superset of thumb1 iow thumb1 programs could be 
executed on cortex-m series or not. Never had a cortex-m so I am not sure.

> the "t" suffix serves no useful purpose here and might as well just be
> omitted.  That is, there is no CPU which can run "armv6" packages which
> wouldn't also be able to run "armv6t".
>
>> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
>> little endian version of xscale.
>
> No, that's incorrect.  The PXA25x series and IXP420, at least, are
> bi-endian (and I suspect most of the other XScales are too) and there
> are certainly folks running them in little endian configurations.

nslu2 which uses xscale has both be and le versions of SlugOS

>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - July 29, 2011, 6:20 a.m.
On 07/27/2011 07:49 AM, Mark Hatle wrote:
> On 7/27/11 9:33 AM, Koen Kooi wrote:
>>
>> Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
>>
>>> On 7/27/11 8:33 AM, Richard Purdie wrote:
>>>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
>>>>>
>>>>> This seems a bit backwards.  Shouldn't TARGET_FPU be the primary
>>>>> variable and then the package suffix be computed from that, rather than
>>>>> vice versa?
>>>>
>>>> It's been "fun" to use the rather limited constructs we have in these
>>>> variables to construct the end result. I suspect this way around, it was
>>>> the easiest way to get the right variables in the right places.
>>>>
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
>>>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
>>>>>
>>>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>>>
>>>> Ah, yes. I'll fix this.
>>>
>>> Are you sure?  I thought ARMv6 -was- the first to support Thumb-2.  And armv5/4
>>> were thumb(1).  Note, not all ARMv6 processors contain thumb support.
>>
>> As I understand it:
>>
>> arm1136 doesn't have t2
>> arm1176 does have t2
>>
>> both are armv6 :)
>
> They also don't have "thumb" support either.  So armv6&  thumb == t2.
>
>>>
>>>>>> +# Whether to compile with code to allow interworking between the two
>>>>>> +# instruction sets. This allows thumb code to be executed on a primarily
>>>>>> +# arm system and vice versa. It is strongly recommended that DISTROs not
>>>>>> +# turn this off - the actual cost is very small.
>>>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
>>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>>>
>>>>> This is only relevant for v4t, I guess.  Interworking is basically
>>>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>>>> hardly anybody is going to be flipping this switch.  I'm not sure it
>>>>> really merits an OVERRIDE.
>>>>
>>>> I'd be happy to remove this option if there are no objections. It was
>>>> left for compatibility with the existing tune-thumb file but as you say,
>>>> it likely doesn't make much sense.
>>>>
>>>>>> --- a/meta/conf/machine/include/tune-xscale.inc
>>>>>> +++ b/meta/conf/machine/include/tune-xscale.inc
>>>>>> @@ -1,11 +1,17 @@
>>>>>> -require conf/machine/include/arm/arch-arm.inc
>>>>>> +DEFAULTTUNE ?= "xscale"
>>>>>>
>>>>>> -INHERIT += "siteinfo"
>>>>>> +require conf/machine/include/arm/arch-armv5-dsp.inc
>>>>>>
>>>>>> -TUNE_CCARGS = "-march=armv5te -mtune=xscale"
>>>>>> -TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
>>>>>> -TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>> -PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
>>>>>> +TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
>>>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
>>>>>> +
>>>>>> +AVAILTUNES += "xscale"
>>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
>>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
>>>>>> +
>>>>>> +AVAILTUNES += "xscale-be"
>>>>>> +TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
>>>>>> +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
>>>>>
>>>>> I guess that should be "_tune-xscale-be".
>>>>
>>>> Yes, I'll fix, well spotted.
>>>
>>> In the original work I did it was just tune-xscale (no be).  AFAIK there is no
>>> little endian version of xscale.  (there was an iwmmxt that was similar to
>>> xscale, but was slightly different.)
>>
>> pxa25x are LE xscales (e.g. Palm Treo)
>> pxa26x are LE xscales with some NAND builtin
>> pxa27x are LE xscales with iwmmxt as an extra
>
> All thought all of those were considered to me iwmmxt cores.  The whole PXA
> series naming is very confusing to say the least.
>

arm cores support both endians equally well. Its the usecases we have on 
OE are little endian.
Khem Raj - July 29, 2011, 6:27 a.m.
On 07/27/2011 07:58 AM, Mark Hatle wrote:
> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> means I was thumb instructions.
>
> So armv5 and armv5t are distinct in the contents of the tunings.

fwiw its confusing since armv5t will be confused with arm architecture 
context where it means 'yes I have thumb and you can use it if you want'
but what you are saying here is that if its armv5t then it means 'arm 
v5t and yes use thumb' It should be called something else probably to 
make that distinction

>
> There were armv5's without thumb support.. but that doesn't matter much.  A
> machine with thumb is compatible (run-time) with one that does not.  A machine
> w/o thumb is not necessarily compatible with thumb executables.
>
>>> >>  +# Little Endian + VFP/DSP
>>> >>  +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
>> >
>> >  The comment doesn't seem to match the code here since this is the
>> >  section for chips without DSP.  Incidentally, the name "dsp" for this
>> >  feature seems quite a bad one: maybe we should just call it "armv5e".
> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
> the "dsp" capabilities actually change any of the code or support generated.  If
> not then we can ignore it.
>
> For armv5 this gives us:
>
> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
> EABI...
>
> --Mark
>
Khem Raj - July 29, 2011, 6:31 a.m.
On 07/27/2011 08:08 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 17:01 +0200, Koen Kooi wrote:
>> the s3c6410 is arm1176 which should support T2. Having said that, I'm not  sure if that actually works since T2 was broken in silicon for early cortex a8 revisions.
>
> What makes you think that ARM1176 has T2?  I haven't actually tried
> executing Thumb-2 on one, but my recollection is definitely that it was
> Thumb-1 only.
>

I recollect it was t1 only too.
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - July 29, 2011, 6:38 a.m.
On 07/27/2011 08:25 AM, Phil Blundell wrote:
> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
>> means I was thumb instructions.
>>
>> So armv5 and armv5t are distinct in the contents of the tunings.
>
> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
>> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
>> the "dsp" capabilities actually change any of the code or support generated.  If
>> not then we can ignore it.
>
> Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
> will affect any code which uses __builtin_prefetch().  I don't think GCC
> will ever open-code the saturating arithmetic instructions, but it does
> expose the v5/v5e distinction through preprocessor macros and source
> code might use that to select asm() statements which use those opcodes.

LDRD/STRD which are armv5e only are used by gcc IIRC

>
>> For armv5 this gives us:
>>
>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>> EABI...
>
> Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
> hurt all that much to offer it, but anything that makes that monstrous
> set of .inc files bigger seems like a bad thing.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - July 29, 2011, 6:41 a.m.
On 07/27/2011 10:19 AM, Mark Hatle wrote:
> On 7/27/11 10:25 AM, Phil Blundell wrote:
>> On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
>>> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
>>> means I was thumb instructions.
>>>
>>> So armv5 and armv5t are distinct in the contents of the tunings.
>>
>> Ah, I see.  Does that go for v4t too?  I can imagine cases where you
>> would want to say "select the v4T ISA but generate ARM code not Thumb".
>
> Yes, for all of them, the TUNENAME selects the features that you want to use to
> compile, and suggests the other information like compatible architectures.
>
> In the case where you want to build primarily one, and optionally the other the
> tunename makes it easy..
>
> Say you want all of your system thumb, except for a few specific programs..
>
> TUNENAME = "armv4t"
>
> TUNENAME_pn-mysql = "armv4"
>
> In the opposite case, where you want everything ARM, except for a few thumb:
>
> TUNENAME = "armv7"
> TUNENAME_pn-bash = "armv7t"
>
> PACKAGE_EXTRA_ARCHS_tune-armv7 = ${PACKAGE_EXTRA_ARCHS_tune-armv7t}
>
> Second line ensures that the base armv7 tune inherits the "more complete" set of
> compatible machines.
>
> (Note, in most cases I would expect a machine/BSP configuration to do most of
> this inheriting... or if someone was being tricky they can do it manually.)
>>> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
>>> the "dsp" capabilities actually change any of the code or support generated.  If
>>> not then we can ignore it.
>>
>> Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
>> will affect any code which uses __builtin_prefetch().  I don't think GCC
>> will ever open-code the saturating arithmetic instructions, but it does
>> expose the v5/v5e distinction through preprocessor macros and source
>> code might use that to select asm() statements which use those opcodes.
>
> So then the question is.. with OE-core and core based distros.. are there enough
> armv5 (w/ or w/o e) left to justify having both?  If not.. then we select the
> one with the 'e' since it's more common.
>
>>> For armv5 this gives us:
>>>
>>> armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
>>> EABI...
>>
>> Does anybody really want the hardfloat abi on armv5?  I guess it doesn't
>> hurt all that much to offer it, but anything that makes that monstrous
>> set of .inc files bigger seems like a bad thing.
>
> I was surprised anyone wanted the hardfloat ABI at all.. :P ...but anyway... if
> it'll work on armv5 (and the previous question about is armv5 relevant answered)
> we can choose it or not..  It was there to be complete in the original
> version...  (also armv5 w/ VFP is the lowest compatible machine for a HF
> implementation.)
>

hardfloat ABI may not work with VFP implementation which is on the armv5 
cores it was designed around vfpv3
> --Mark
>
>> p.
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 29, 2011, 6:47 a.m.
On Thu, 2011-07-28 at 23:08 -0700, Khem Raj wrote:
> I know SHR uses armv4t but I dont know of armv4 usecases. May be we 
> could may armv4t as oldest supported arm arch and leave armv4 out.

There are definitely still folks using OE with SA1100 machines.  I think
armv4 support should be kept unless there is a really compelling reason
to leave it out.

p.
Khem Raj - July 29, 2011, 6:51 a.m.
On 07/28/2011 11:08 PM, Khem Raj wrote:
> On 07/27/2011 06:33 AM, Richard Purdie wrote:
>> On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
>>> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>>>> +TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or
>>>> 'soft'}"
>>>
>>> This seems a bit backwards. Shouldn't TARGET_FPU be the primary
>>> variable and then the package suffix be computed from that, rather than
>>> vice versa?
>>
>> It's been "fun" to use the rather limited constructs we have in these
>> variables to construct the end result. I suspect this way around, it was
>> the easiest way to get the right variables in the right places.
>>
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv4", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv5", "thumb" ], "t", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv6", "thumb" ], "t2", "", d)}"
>>>> +ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [
>>>> "armv7", "thumb" ], "t2", "", d)}"
>>>
>>> This is wrong: ARMv6 doesn't imply Thumb-2.
>>
>> Ah, yes. I'll fix this.
>>
>>>> +# Whether to compile with code to allow interworking between the two
>>>> +# instruction sets. This allows thumb code to be executed on a
>>>> primarily
>>>> +# arm system and vice versa. It is strongly recommended that
>>>> DISTROs not
>>>> +# turn this off - the actual cost is very small.
>>>> +TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM
>>>> functions"
>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES",
>>>> "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
>>>> +OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES",
>>>> "no-thumb-interwork", ":thumb-interwork", "", d)}"
>>>
>>> This is only relevant for v4t, I guess. Interworking is basically
>>> always on for v5 and later and (CeSI aside) it's impossible on v4, so
>>> hardly anybody is going to be flipping this switch. I'm not sure it
>>> really merits an OVERRIDE.
>>
>> I'd be happy to remove this option if there are no objections. It was
>> left for compatibility with the existing tune-thumb file but as you say,
>> it likely doesn't make much sense.
>
>
> I know SHR uses armv4t but I dont know of armv4 usecases. May be we
> could may armv4t as oldest supported arm arch and leave armv4 out.

oh well how did I forget strongARM so yes dropping armv4 may not be so easy
Phil Blundell - July 29, 2011, 7:13 a.m.
On Thu, 2011-07-28 at 23:38 -0700, Khem Raj wrote:
> On 07/27/2011 08:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names..  armv5 means I want classic ARM instructions, while armv5t
> >> means I was thumb instructions.
> >>
> >> So armv5 and armv5t are distinct in the contents of the tunings.
> >
> > Ah, I see.  Does that go for v4t too?  I can imagine cases where you
> > would want to say "select the v4T ISA but generate ARM code not Thumb".
> >
> >> Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
> >> the "dsp" capabilities actually change any of the code or support generated.  If
> >> not then we can ignore it.
> >
> > Yes.  PLD, for example, is only available in ARMv5E (not ARMv5) and this
> > will affect any code which uses __builtin_prefetch().  I don't think GCC
> > will ever open-code the saturating arithmetic instructions, but it does
> > expose the v5/v5e distinction through preprocessor macros and source
> > code might use that to select asm() statements which use those opcodes.
> 
> LDRD/STRD which are armv5e only are used by gcc IIRC

Ah yes, you're right.  Those too.

p.
Phil Blundell - July 29, 2011, 7:15 a.m.
On Thu, 2011-07-28 at 23:18 -0700, Khem Raj wrote:
> On 07/27/2011 07:44 AM, Phil Blundell wrote:
> cortex-m series supports only thumb2 intsruction set. I am not sure if 
> thumb2 alone is a superset of thumb1 iow thumb1 programs could be 
> executed on cortex-m series or not. Never had a cortex-m so I am not sure.

Yes, I believe any thumb-1 program will run on a thumb-2 core. 

p.
Phil Blundell - July 29, 2011, 7:25 a.m.
On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
> here I guess we have to say AVAILTUNES += "arm920t arm920"
> where arm920 is arm mode and 920t is thumb mode. but anyway I would 
> prefer that thumb is optionally added provided user asked for it
> through DISTRO/MACHINE features then we should first make sure
> that selected machine has thumb feature and if yes for both then we 
> should enable -mthumb compiler option which now it enable when thumb 
> appears in TUNE_FEATURES

I don't think we want to go down the road of inventing CPU names for
ARM-state variants of Thumb-capable cores.  (In other words, we
shouldn't start putting things like "arm920" in AVAILTUNES when there
isn't actually a core named arm920.)

Fundamentally I think you're right that the choice between ARM-state and
Thumb-state (for t1 at least) ought to be under the control of the
DISTRO and not selected purely on the basis of the hardware
capabilities.  For t2 it is a bit less of a clear-cut issue but, if
there are genuinely people making ARMv7 cores with the Thumb decoder
removed, I guess we need to have that same switch there as well.

p.
Koen Kooi - July 29, 2011, 8:22 a.m.
Op 29 jul. 2011 om 09:25 heeft Phil Blundell <philb@gnu.org> het volgende geschreven:

> On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
>> here I guess we have to say AVAILTUNES += "arm920t arm920"
>> where arm920 is arm mode and 920t is thumb mode. but anyway I would 
>> prefer that thumb is optionally added provided user asked for it
>> through DISTRO/MACHINE features then we should first make sure
>> that selected machine has thumb feature and if yes for both then we 
>> should enable -mthumb compiler option which now it enable when thumb 
>> appears in TUNE_FEATURES
> 
> I don't think we want to go down the road of inventing CPU names for
> ARM-state variants of Thumb-capable cores.  (In other words, we
> shouldn't start putting things like "arm920" in AVAILTUNES when there
> isn't actually a core named arm920.)
> 
> Fundamentally I think you're right that the choice between ARM-state and
> Thumb-state (for t1 at least) ought to be under the control of the
> DISTRO and not selected purely on the basis of the hardware
> capabilities.  For t2 it is a bit less of a clear-cut issue but, if
> there are genuinely people making ARMv7 cores with the Thumb decoder
> removed, I guess we need to have that same switch there as well

Another issue is silicon bugs on early a8 revisions, but gcc and linux might have enough workarounds nowadays




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

Patch

diff --git a/meta/conf/machine/include/arm/arch-arm.inc b/meta/conf/machine/include/arm/arch-arm.inc
index c517df6..4ea8b2b 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -1,3 +1,17 @@ 
-TUNE_ARCH = "arm"
+
+TUNEVALID[bigendian] = "Enable big-endian mode."
+
+ARMPKGARCH ??= "arm"
+ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}"
+ARMPKGSFX_FPU ??= ""
+ARMPKGSFX_DSP ??= ""
+ARMPKGSFX_EABI ??= ""
+ARMPKGSFX_THUMB ??= ""
+
+TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}"
+TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
 ABIEXTENSION = "eabi"
+
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
+
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc b/meta/conf/machine/include/arm/arch-armv4.inc
new file mode 100644
index 0000000..c014d20
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -0,0 +1,24 @@ 
+DEFAULTTUNE ?= "armv4"
+
+ARMPKGARCH ?= "armv4"
+
+TUNEVALID[armv4] = "Enable instructions for ARMv4"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
+
+require conf/machine/include/arm/arch-arm.inc
+require conf/machine/include/arm/feature-arm-thumb.inc
+
+# Little Endian
+AVAILTUNES += "armv4 armv4t"
+TUNE_FEATURES_tune-armv4 ?= "armv4"
+TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
+PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
+
+# Big Endian
+AVAILTUNES += "armv4b armv4tb"
+TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
+TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
+PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
+
diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
new file mode 100644
index 0000000..498a012
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -0,0 +1,40 @@ 
+ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
+
+require conf/machine/include/arm/arch-armv5.inc
+
+# Little Endian
+AVAILTUNES += "armv5e armv5te"
+TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
+TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
+PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
+
+# Little Endian + VFP/DSP
+AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
+TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
+TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
+TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5tehf-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5e armv5e-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5e armv5te armv5e-vfp armv5te-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv5ehf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv5eb armv5teb"
+TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
+TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5eb"
+PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5eb armv5teb"
+
+# Big Endian + VFP/DSP
+AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
+TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
+TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian"
+TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5tehfb-vfp ?= "${TUNE_FEATURES_tune-armv5teb-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp} armv5eb armv5eb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp} armv5eb armv5teb armv5eb-vfp armv5teb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp} armv5ehfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp} armv5ehfb-vfp armv5tehfb-vfp"
+
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
new file mode 100644
index 0000000..55cbe03
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -0,0 +1,51 @@ 
+DEFAULTTUNE ?= "armv5"
+
+ARMPKGARCH ?= "armv5"
+
+TUNEVALID[armv5] = "Enable instructions for ARMv5"
+TUNE_CONFLICTS[armv5] = "armv4"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
+
+ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
+
+require conf/machine/include/arm/arch-armv4.inc
+require conf/machine/include/arm/feature-arm-vfp.inc
+
+# Little Endian
+AVAILTUNES += "armv5 armv5t armv5e armv5te"
+TUNE_FEATURES_tune-armv5 ?= "armv5"
+TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
+PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
+
+# Little Endian + VFP/DSP
+AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
+TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp"
+TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp"
+TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5thf-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5-vfp armv5t-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp = "armv5hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp = "armv5hf-vfp armv5thf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv5ehf-vfp armv5tehf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv5b armv5tb"
+TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian"
+TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
+PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b armv5tb"
+
+# Big Endian + VFP/DSP
+AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp"
+TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian"
+TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian"
+TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
+TUNE_FEATURES_tune-armv5thfb-vfp ?= "${TUNE_FEATURES_tune-armv5tb-vfp} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5tb-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5b-vfp armv5tb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5hfb-vfp = "armv5hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv5thfb-vfp = "armv5hfb-vfp armv5thfb-vfp"
+
+
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc b/meta/conf/machine/include/arm/arch-armv6.inc
new file mode 100644
index 0000000..20924c9
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -0,0 +1,32 @@ 
+DEFAULTTUNE ?= "armv6"
+
+ARMPKGARCH ?= "armv6"
+
+TUNEVALID[armv6] = "Enable instructions for ARMv6"
+TUNE_CONFLICTS[armv6] = "armv4 armv5"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+# Little Endian
+AVAILTUNES += "armv6 armv6t armv6hf armv6thf"
+TUNE_FEATURES_tune-armv6 ?= "armv6 vfp"
+TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb"
+TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
+TUNE_FEATURES_tune-armv6thf ?= "${TUNE_FEATURES_tune-armv6t} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp"
+
+# Big Endian
+AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb"
+TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian"
+TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian"
+TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
+TUNE_FEATURES_tune-armv6thfb ?= "${TUNE_FEATURES_tune-armv6tb} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6b-vfp armv6tb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp"
+
diff --git a/meta/conf/machine/include/arm/arch-armv7.inc b/meta/conf/machine/include/arm/arch-armv7.inc
new file mode 100644
index 0000000..8bc8d10
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv7.inc
@@ -0,0 +1,55 @@ 
+DEFAULTTUNE ?= "armv7"
+
+ARMPKGARCH ?= "armv7"
+
+TUNEVALID[armv7] = "Enable instructions for ARMv7"
+TUNE_CONFLICTS[armv7] = "armv4 armv5 armv6"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7", "-march=armv7", "", d)}"
+
+require conf/machine/include/arm/arch-armv6.inc
+require conf/machine/include/arm/feature-arm-neon.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv7 armv7t armv7-neon armv7t-neon"
+TUNE_FEATURES_tune-armv7 ?= "armv7 vfp"
+TUNE_FEATURES_tune-armv7t ?= "armv7 vfp thumb"
+TUNE_FEATURES_tune-armv7-neon ?= "armv7 vfp neon"
+TUNE_FEATURES_tune-armv7t-neon ?= "armv7 vfp neon thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv7 = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7t = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7-vfp armv7t2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7t-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7-vfp-neon armv7at2-vfp-neon"
+
+# VFP Tunes
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+TUNE_FEATURES_tune-armv7hf ?= "${TUNE_FEATURES_tune-armv7} callconvention-hard"
+TUNE_FEATURES_tune-armv7thf ?= "${TUNE_FEATURES_tune-armv7t} callconvention-hard"
+TUNE_FEATURES_tune-armv7hf-neon ?= "${TUNE_FEATURES_tune-armv7-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7thf-neon ?= "${TUNE_FEATURES_tune_armv7t-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7hf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} armv7hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7thf = "${PACKAGE_EXTRA_ARCHS_tune-armv6thf} armv7hf-vfp armv7t2hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7hf-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7hf-vfp-neon armv7at2hf-vfp-neon"
+
+# Big Endian
+AVAILTUNES += "armv7b armv7tb armv7b-neon armv7tb-neon"
+TUNE_FEATURES_tune-armv7b ?= "${TUNE_FEATURES_tune-armv7} bigendian"
+TUNE_FEATURES_tune-armv7tb ?= "${TUNE_FEATURES_tune-armv7t} bigendian"
+TUNE_FEATURES_tune-armv7b-neon ?= "${TUNE_FEATURES_tune-armv7-neon} bigendian"
+TUNE_FEATURES_tune-armv7tb-neon ?= "${TUNE_FEATURES_tune-armv7t-neon} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv7b = "${PACKAGE_EXTRA_ARCHS_tune-armv6} armv7b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7tb = "${PACKAGE_EXTRA_ARCHS_tune-armv6t} armv7b-vfp armv7t2b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7b-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7b-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7tb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7b-vfp-neon armv7at2b-vfp-neon"
+
+# Big Endian + VFP
+AVAILTUNES += "armv7hfb armv7thfb armv7hfb-neon armv7thfb-neon"
+TUNE_FEATURES_tune-armv7hfb ?= "${TUNE_FEATURES_tune-armv7b} callconvention-hard"
+TUNE_FEATURES_tune-armv7thfb ?= "${TUNE_FEATURES_tune-armv7tb} callconvention-hard"
+TUNE_FEATURES_tune-armv7hfb-neon ?= "${TUNE_FEATURES_tune-armv7b-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7thfb-neon ?= "${TUNE_FEATURES_tune_armv7tb-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6hfb} armv7hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv6thfb} armv7hfb-vfp armv7t2hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7hfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7hfb-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7thfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7hfb-vfp-neon armv7at2hfb-vfp-neon"
+
diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
new file mode 100644
index 0000000..ce9cee5
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -0,0 +1,54 @@ 
+DEFAULTTUNE ?= "armv7a"
+
+ARMPKGARCH ?= "armv7a"
+
+TUNEVALID[armv7-a] = "Enable instructions for ARMv7-a"
+TUNE_CONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a -fno-tree-vectorize", "", d)}"
+
+require conf/machine/include/arm/arch-armv7.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon"
+TUNE_FEATURES_tune-armv7a ?= "armv7a vfp"
+TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb"
+TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
+TUNE_FEATURES_tune-armv7at-neon ?= "armv7a vfp neon thumb"
+PACKAGE_EXTRA_ARCHS_tune-armv7a = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7a-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7a-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7a-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a-vfp armv7at2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
+
+# VFP Tunes
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
+TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
+TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7athf-neon ?= "${TUNE_FEATURES_tune_armv7at-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf = "${PACKAGE_EXTRA_ARCHS_tune-armv7hf} armv7ahf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf = "${PACKAGE_EXTRA_ARCHS_tune-armv7thf} armv7ahf-vfp armv7at2hf-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf} armv7ahf-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} armv7ahf-vfp-neon armv7at2hf-vfp-neon"
+
+# Big Endian
+AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon"
+TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian"
+TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian"
+TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
+TUNE_FEATURES_tune-armv7atb-neon ?= "${TUNE_FEATURES_tune-armv7at-neon} bigendian"
+PACKAGE_EXTRA_ARCHS_tune-armv7ab = "${PACKAGE_EXTRA_ARCHS_tune-armv7} armv7ab-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7atb = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7ab-vfp armv7at2b-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} armv7ab-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7ab-vfp-neon armv7at2b-vfp-neon"
+
+# Big Endian + VFP
+AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon"
+TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard"
+TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard"
+TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
+TUNE_FEATURES_tune-armv7athfb-neon ?= "${TUNE_FEATURES_tune_armv7atb-neon} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7hfb} armv7ahfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7athfb = "${PACKAGE_EXTRA_ARCHS_tune-armv7thfb} armv7ahfb-vfp armv7at2hfb-vfp"
+PACKAGE_EXTRA_ARCHS_tune-armv7ahfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahfb} armv7ahfb-vfp-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv7athfb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athfb} armv7ahfb-vfp-neon armv7at2hfb-vfp-neon"
+
diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
new file mode 100644
index 0000000..a7dac03
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
@@ -0,0 +1,3 @@ 
+TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
new file mode 100644
index 0000000..9a607c6
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -0,0 +1,25 @@ 
+# The instruction set the compiler should use when generating application
+# code. The kernel is always compiled with arm code at present. arm code
+# is the original 32 bit ARM instruction set, thumb code is the 16 bit
+# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
+# but requires more instructions (140% for 70% smaller code) so may be
+# slower.
+TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
+OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
+
+# Note armv7 will hit on armv7a as well
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2", "", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2", "", d)}"
+
+# Whether to compile with code to allow interworking between the two
+# instruction sets. This allows thumb code to be executed on a primarily
+# arm system and vice versa. It is strongly recommended that DISTROs not
+# turn this off - the actual cost is very small.
+TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
+OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
+
+TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
new file mode 100644
index 0000000..29a925c
--- /dev/null
+++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
@@ -0,0 +1,6 @@ 
+TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
+
+TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
+ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"
diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 953f0dd..4f4a2eb 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -1,10 +1,10 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm1136jfs"
 
-TUNE_CCARGS = "-march=armv6j -mtune=arm1136jf-s"
-TUNE_CCARGS += "${@['', '-mfloat-abi=softfp -mfpu=vfp'][(bb.data.getVar('TARGET_FPU', d, 1) == 'soft') and (bb.data.getVar('CPU_FEATURES', d, 1).find('vfp') != -1)]}"
-TUNE_PKGARCH = "armv6"
+require conf/machine/include/arm/arch-armv6.inc
 
-ARM_INSTRUCTION_SET = "${@['thumb','arm'][bb.data.getVar('CPU_FEATURES', d, 1).find('thumb') == -1]}"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6"
+TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
 
-require conf/machine/include/tune-thumb.inc
+AVAILTUNES += "arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
+PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc
index 6c87026..b7584ab 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -1,5 +1,11 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm920t"
+
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
+
+AVAILTUNES += "arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
+PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
 
-TUNE_PKGARCH = "armv4t"
-TUNE_CCARGS = "-march=armv4t -mtune=arm920t"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 543ab62..7f2cc4e 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,9 +1,11 @@ 
-require conf/machine/include/arm/arch-arm.inc
-
-TUNE_PKGARCH = "armv5te"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te"
-# For gcc 3.x you need:
-#TUNE_CCARGS = "-march=armv5te -mtune=arm926ejs"
-# For gcc 4.x you need:
-TUNE_CCARGS = "-march=armv5te -mtune=arm926ej-s"
+DEFAULTTUNE ?= "arm926ejs"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
+
+AVAILTUNES += "arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
+PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
 
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc
index f1001ac..0dc5c26 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -1,5 +1,11 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "arm9tdmi"
+
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
+
+AVAILTUNES += "arm9tdmi"
+TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
+PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
 
-TUNE_PKGARCH = "armv4t"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t"
-TUNE_CCARGS = "-mcpu=arm9tdmi -mtune=arm9tdmi"
diff --git a/meta/conf/machine/include/tune-armv7.inc b/meta/conf/machine/include/tune-armv7.inc
index 8a68c0a..664c24b 100644
--- a/meta/conf/machine/include/tune-armv7.inc
+++ b/meta/conf/machine/include/tune-armv7.inc
@@ -1,8 +1,2 @@ 
-require conf/machine/include/arm/arch-arm.inc
+require conf/machine/include/arm/arch-armv7.inc
 
-# valid options for -march: `armv7', `armv7-a', `armv7-r', `armv7-m'
-# valid option for -mtune: `cortex-a8', `cortex-r4', `cortex-m3', `cortex-m1'
-# This will NOT compile programs in 'ARM' mode, which is what you really want
-TUNE_CCARGS = "-march=armv7 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7"
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index ae50954..b07add4 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -1,15 +1,16 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexa8-neon"
 
+require conf/machine/include/arm/arch-armv7a.inc
 
-# Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3]
-# [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html
-# [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html 
-# [3] https://support.codesourcery.com/GNUToolchain/kbentry29
+TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
 
-TUNE_CCARGS = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize"
+AVAILTUNES += "cortexa8 cortexa8t"
+TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} coretexa8"
+TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} coretexa8"
+TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
 
-# Other potentially useful options
-#-ftree-vectorize -ffast-math -fno-omit-frame-pointer
+PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
 
-TUNE_PKGARCH = "armv7a"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te armv6 armv7 armv7a"
diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc
index b944db4..493025d 100644
--- a/meta/conf/machine/include/tune-cortexm1.inc
+++ b/meta/conf/machine/include/tune-cortexm1.inc
@@ -1,4 +1,11 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexm1"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
+
+AVAILTUNES += "cortexm1"
+TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} coretexm1"
+PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
 
-TUNE_CCARGS = "-march=armv7 -mtune=cortex-m1 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv6"
diff --git a/meta/conf/machine/include/tune-cortexm3.inc b/meta/conf/machine/include/tune-cortexm3.inc
index a77cbdd..f774fa6 100644
--- a/meta/conf/machine/include/tune-cortexm3.inc
+++ b/meta/conf/machine/include/tune-cortexm3.inc
@@ -1,5 +1,15 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexm3"
+ARMPKGARCH ?= "armv7m"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexm3] = "Enable Cortex-M3 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm3", "-mtune=cortex-m3", "", d)}"
+
+TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}"
+
+AVAILTUNES += "cortexm3"
+TUNE_FEATURES_tune-cortexm3 = "armv7m vfp coretexm3"
+PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m"
 
-# valid options for -march: `armv7', `armv7-m'
-TUNE_CCARGS = "-march=armv7-m -mtune=cortex-m3 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
diff --git a/meta/conf/machine/include/tune-cortexr4.inc b/meta/conf/machine/include/tune-cortexr4.inc
index c9193ca..738f5af 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -1,5 +1,15 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "cortexr4"
+ARMPKGARCH ?= "armv7r"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}"
+
+TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}"
+
+AVAILTUNES += "cortexr4"
+TUNE_FEATURES_tune-cortexr4 = "armv7r vfp coretexr4"
+PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r"
 
-# valid options for -march: `armv7', `armv7-r'
-TUNE_CCARGS = "-march=armv7-r -mtune=cortex-r4 -mfpu=vfp -mfloat-abi=softfp"
-TUNE_PKGARCH = "armv7"
diff --git a/meta/conf/machine/include/tune-ep9312.inc b/meta/conf/machine/include/tune-ep9312.inc
index e04a00a..f10123f 100644
--- a/meta/conf/machine/include/tune-ep9312.inc
+++ b/meta/conf/machine/include/tune-ep9312.inc
@@ -1,9 +1,13 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "ep9312"
+ARMPKGARCH ?= "ep9312"
 
-TUNE_CCARGS = "-march=ep9312 -mtune=ep9312 -mcpu=ep9312"
-# add "-mfp=maverick" for newer gcc versions > 4.0
+require conf/machine/include/arm/arch-armv4.inc
+
+TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}"
+
+AVAILTUNES += "ep9312"
+TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
+PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
 
-#set arch to ep9312 for all generated packages
-PACKAGE_EXTRA_ARCHS = "arm armv4t ep9312"
-TUNE_PKGARCH = "ep9312"
 
diff --git a/meta/conf/machine/include/tune-iwmmxt.inc b/meta/conf/machine/include/tune-iwmmxt.inc
index 6bb76d5..14f5955 100644
--- a/meta/conf/machine/include/tune-iwmmxt.inc
+++ b/meta/conf/machine/include/tune-iwmmxt.inc
@@ -1,8 +1,16 @@ 
-require conf/machine/include/arm/arch-arm.inc
-
 # Configurations for the Intel PXA27x Appications Processor Family. 
 # Please use tune-xscale for PXA255/PXA26x based processors.
-TUNE_CCARGS = "-march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt"
-PACKAGE_EXTRA_ARCHS = "arm armv4 armv4t armv5te iwmmxt"
-TUNE_PKGARCH = "iwmmxt"
+
+DEFAULTTUNE ?= "iwmmxt"
+ARMPKGARCH ?= "iwmmxt"
+
+require conf/machine/include/arm/arch-armv5-dsp.inc
+
+TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}"
+
+AVAILTUNES += "iwmmxt"
+TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt"
+PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt"
+
 
diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc
index 2b76069..66bab8e 100644
--- a/meta/conf/machine/include/tune-strongarm1100.inc
+++ b/meta/conf/machine/include/tune-strongarm1100.inc
@@ -1,9 +1,12 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "strongarm"
 
-TUNE_PKGARCH = "arm"
+require conf/machine/include/arm/arch-armv4.inc
 
-# This machine lists common configuration options for Strongarm 1100 devices
-# NOTE: The Zaurus Collie also has a Strongarm processor, but uses the 1110 type
+TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}"
+
+AVAILTUNES += "strongarm"
+TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm"
+PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
 
-TUNE_CCARGS = "-march=armv4 -mtune=strongarm1100"
 
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 71dba5b..0303320 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,11 +1,17 @@ 
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "xscale"
 
-INHERIT += "siteinfo"
+require conf/machine/include/arm/arch-armv5-dsp.inc
 
-TUNE_CCARGS = "-march=armv5te -mtune=xscale"
-TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
-TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
-PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
+TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}"
+
+AVAILTUNES += "xscale"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
+
+AVAILTUNES += "xscale-be"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
 
 # webkit-gtk has alignment issues with double instructions on armv5 so
 # disable them here