e9b2ffc0fe
* 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>
2012/03/30 - Mark Hatle mark.hatle@windriver.com
- Initial Revision
Introduction
The individual CPU, and ABI tunings are contained in this directory. A number of local and global variables are used to control the way the tunings are setup and how they work together to specify an optimized configuration.
The following is brief summary of the generic components that are used in these tunings.
AVAILTUNES - This is a list of all of the tuning definitions currently available in the system. Not all tunes in this list may be compatible with the machine configuration, or each other in a multilib configuration. Each tuning file can add to this list using "+=", but should never replace the list using "=".
DEFAULTTUNE - This specifies the tune to use for a particular build. Each tune should specify a reasonable default, which can be overriden by a machine or multilib configuration. The specified tune must be listed in the AVAILTUNES.
TUNEVALID[feature] - The is defined with a human readable explanation for what it does. All architectural, cpu, abi, etc tuning features must be defined using TUNEVALID.
TUNECONFLICTS[feature] - A list of features which conflict with . New sanity checks will try to reject combinations in which a single tuning ends up with features which conflict with each other.
TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-. See TUNE_FEATURES_tune- for more information.
TUNE_FEATURES_tune- - Specify the features used to describe a specific tune. This is a list of features that a tune support, each feature must be in the TUNEVALID list. Note: the tune and a given feature name may be the same, but they have different purposes. Only features may be used to change behavior, while tunes are used to describe an overall set of features.
ABIEXTENSION - An ABI extension may be specified by a specific feature or other tuning setting, such as TARGET_FPU. Any ABI extensions either need to be defined in the architectures base arch file, i.e. ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune files with a ".=". Spaces are not allowed in this variable.
TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings. These should be additive when defined using "+=". All items in this list should be dynamic! i.e. ${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)}
TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e. arm, armeb, mips, mips64, etc. This value is used by bitbake to setup configure. TUNE_ARCH definitions are specific to a given architecture. They may be a single static definition, or may be dynamically adjusted. See each architecture's README for details for that CPU family.
TUNE_PKGARCH - The package architecture used by the packaging systems to define the architecture, abi and tuning of a particular package. Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to each architecture. See each architectures README for details for that CPU family.
PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package architectures. By default this is equal to PACKAGE_EXTRA_ARCHS_tune-. If an architecture deviates from the default it will be listed in the architecture README.
PACKAGE_EXTRA_ARCHS_tune- - List all of the package architectures that are compatible with this specific tune. The package arch of this tune must be in the list.
TARGET_FPU - The FPU setting for a given tune, hard (generate floating point instructions), soft (generate internal gcc calls), "other" architecture specific floating point. This is synchronized with the compiler and other toolchain items. This should be dynamically configured in the same way that TUNE_CCARGS is.
BASE_LIB_tune- - The "/lib" location for a specific ABI. This is used in a multilib configuration to place the libraries in the correct, non-conflicting locations.
Best Practice
The tune infrastructure is designed to be hierarchical. When writing a new tune file for a "fast-forward" CPU architecture (one that supports everything from a previous generation), it is recommended to require the previous generation tune file and specify PACKAGE_EXTRA_ARCHS using the previous generation's override and appending the new tune. Note that only one previous tune file should be included to avoid mutiple includes of the base arch which could lead to a broken configuration due to multiple prepend and append assignments.
For example, for x86, there is a common x86/arch-x86.inc which is included in the base i586 tune file. The core2 tune builds on that, and corei7 builds on core2.