Martin Jansa e9b2ffc0fe feature-arm-{neon,vfp}.inc: refactor and fix issues
* respect all 4 vfp options ('vfp', 'vfpv3d16', 'vfpv3', 'vfpv4') when
  setting -mfloat-abi and ARMPKGSFX_EABI, without this change it wasn't
  possible to use call-convention hard together with vfpv4
* move 'vfpv3d16', 'vfpv3', 'vfpv4' support from
  feature-arm-vfp.inc
  to
  feature-arm-neon.inc
  the main difference is that feature-arm-vfp.inc is included in
  arch-armv5.inc while feature-arm-neon.inc only in armv7*.inc, so
  these options should be added to TUNEVALID also only for armv7*
  MACHINEs.
* support vfpv4 with or without neon
  when both vfpv4 and neon are in TUNE_FEATURES we want to set only one
  -mfpu parameter and to neon-vfpv4
* prevent multiple appends to ARMPKGSFX_FPU, we don't want to include
  e.g. -vfp as well as -vfpv4 when both "vfp" and "vfpv4" are in
  TUNE_FEATURES
* add -mfpu=vfp for tunes with "vfp" in TUNE_FEATURES - before that we
  were only adding -vfp to ARMPKGSFX_FPU
* add TUNE_CCARGS_MFPU variable which is used to set -mfpu parameter as
  well as ARMPKGSFX_FPU suffix in TUNE_PKGARCH, all enabled values are
  appended to it based on TUNE_FEATURES and then the last one is used
  in the actual param and suffix
* this prevents multiple -mfpu options in TUNE_CCARGS

* !!!
  This means we need to change TUNE_PKGARCH and PACKAGE_EXTRA_ARCHS for
  vfpv4, vfpv3d16, vfpv3 tunes, because the -vfp* isn't prependend
  multiple times. If you're using one of these new DEFAULTTUNES (which
  were at least partially broken anyway) and depend on working binary
  package feed upgrade-path, then don't forget to migrate PR service
  database to new TUNE_PKGARCH.

(From OE-Core rev: 6661718158f8fdcdf63b0d48e8fe72d3ac4778f2)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07 13:40:19 +00:00
..
2014-12-23 10:18:19 +00:00

2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
 - Initial Revision

The ARM architecture definitions are split among a number of files.
The primary definitions for the variables are handled by the core
arch-arm.inc file.

TUNE_ARCH is set to either "arm" or "armeb" depending on the value
of the existence of the "bigendian" feature in a given tune.

A small set of ARM specific variables have been defined to allow 
TUNE_PKGARCH to be automatically defined.  Optimized tunings must NOT 
change the definiton of TUNE_PKGARCH.  TUNE_PKGACH_tune-<tune> will be 
ignored.  The format of the package arch is enforced by the TUNE_PKGARCH
default.  The format must be of the form:
<armversion>[t][e][hf][b][-vfp][-neon]

TUNE_PKGARCH is defined as:
${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}

ARMPKGARCH - This is the core package arch component specified by each 
tuning.  This is the primary identifier of a tuning.  Usual values are:
arm, armv4, armv5, armv6, armv7a, etc.

ARMPKGSFX_THUMB - This is the thumb specific suffix.  Curently it is 
defined in feature-arm-thumb.inc.

ARMPKGSFX_DSP - This is the DSP specific suffix.  Currently this is set 
to 'e' when on armv5 and the dsp feature is enabled.

ARMPKGSFX_EABI - This is the eabi specific suffix.  There are currently 
two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.  
When the callconvention-hard is enabled, "hf" is specified, otherwise it 
is blank.

ARMPKGSFX_ENDIAN - This is the endian specific suffix.  It is defined in 
the core arch-arm.inc file.

ARMPKGSFX_FPU - This is the FPU specific suffix.  The suffix indicates 
specific FPU optimizations.  'vfp' and 'neon' are both defined.