| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC has the ability to pass extensions to the march parameter, which
expand the funcationality of the march. For example
"-march=armv7ve+simd" adds SIMD to ARMv7. Currently, there is no way to
expand the march setting without modifying each instance, as you can't
guarantee the ordering when using the existing TUNE_CCARGS. By
introducing two new variables, TUNE_CCARGS_MARCH and
TUNE_CCARGS_MARCH_OPT, we can enforce that these two go together.
Also, expand existing and create new feature files that use these
variables to expand the functionality.
(From OE-Core rev: 794eb617bfd1997e7a3498812c63a20c58a10554)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* add TUNE_CCARGS_MFLOAT variable which is used to set -mfloat-abi
parameter as well as ARMPKGSFX_EABI suffix in TUNE_PKGARCH and
TARGET_FPU
* TARGET_FPU was using ARMPKGSFX_FPU, but in most cases we use it
only to distinguish between hard and soft abi, not various -mfpu
variants which can appear in ARMPKGSFX_FPU
(From OE-Core rev: 10bece310ca6e0bbae28665f873f907d751d1057)
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>
|
| |
|
|
|
|
|
|
| |
(From OE-Core rev: 924ccf202a6d89de32fc34a140bf9e35e8e43b4e)
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* tune-foo is not valid override, for it to work I had to add
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
but that doesn't work without value defined for every supported
DEFAULTTUNE value, otherwise it's expanded like this
TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).
(From OE-Core rev: 31e4f2dee990ee7f5d7491b65565e71d7d580209)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup the ARM tunings to match the new tunings README file.
The ARM tunings define TUNE_PKGARCH in a way that only one main
arm architecture, i.e. armv6, may be defined at the same time. We
may have to revise these settings in the future, as well as figure
out a way to better differentiate various optimize tunings in the
package arch. (This was not done, to preserve existing behavior!)
Fix a number of minor issues w/ the armv5 tunings where DSP variants
were referenced but not defined.
Fix incorrect armv7 entries in armv7a.
Fix PACKAGE_EXTRA_ARCHS definitions inside of tune-cortexm3 and tune-cortexr4.
(From OE-Core rev: 0e71abea5458122188d5eddef2c17147f61ff895)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
(From OE-Core rev: 789dcb8e68a2ab9784ac10ab36815010c61af2fc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
| |
(From OE-Core rev: f10a3457cdfbb4a94978da998d178d4254632fa7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
files and tune features
These changes revolve around the idea of tune features. These are represented by
'flag' strings that are included in the TUNE_FEATURES variable.
Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so
we can know which flags are available in TUNE_FEATURES and have documentation about
what the flags do. We will add sanity code to error if flags are listed in
TUNE_FEATURES but are not documented in TUNEVALID.
A given tune configuration will want to define one or more predetermined sets of
_FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>.
For defined tune configuation, <name> should be added to the AVAILTUNE list so that
we can determine what tune configurations are available. Flags cannot be used in this
case as with TUNEVALID since its useful to be able to build up tune lists from other
TUNE_FEATURES_tune-yyy options.
A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and
BASE_LIB_tune-<name> to control the multilib location. All options can be overridden
by the distro or local user configuration.
(From OE-Core rev: 5f9d56bd64997b93ed7e46c117851002a0556654)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
