* 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>
* some tunes were using weak assignment for TUNE_FEATURES, unify
all tunes to use normal assignment so it behaves consistently
(From OE-Core rev: 0a52bd3ed23e66200401d0836aad783095e7c7a0)
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>
* indent the assignments, so that it's easier to see the algoritm how these
values are modified and do less errors, see fixes in next commit
(From OE-Core rev: f774b44fa007a2a756ada892ede832b1251d940c)
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>
* the section bellow the comment adds only HF variants, VFP is already
mixed in the softfp sections above (unlike armv5, armv6 tune files
where it really was above VFP/DSP section)
(From OE-Core rev: 0c60d744f6ec3b77f044ac7d66e30c00d00fea81)
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>
* each DEFAULTTUNE with thumb enabled should list it's arm variants in
PACKAGE_EXTRA_ARCHS, otherwise packages which force arm ISA won't be
found in do_rootfs
* armv7athf-neon-vfpv4 was missing its own PACKAGE_ARCH and also the arm
variant
(From OE-Core rev: fd7f3cd9affbfb9ce483a5a1d6054da2365fcb0e)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it will be inherited by most DEFAULTTUNEs, except few exceptions which
support only thumb and not arm
* respect missing "arm" in TUNE_FEATURES in feature-arm-thumb.inc, so
when recipe asks for "arm" and MACHINE supports only "thumb" ignore
recipe and try to build with "thumb"
* show warning when overriding ARM_INSTRUCTION_SET set by recipe from tune
config
(From OE-Core rev: 1250d3e009363d20f15bbfaced622c5912a7fb93)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* number of TUNE_CCARGS conditionals is important if we add
extra space with each one in "else" branch
I'm building for 2 MACHINEs one is cortexa9, second is cortexa8
few months ago we added TUNE_CCARGS[vardepvalue] in bitbake.conf
http://git.openembedded.org/openembedded-core/commit/?id=03f1e34ea3ce80931e9c3cd2ab22824f28a7233b
which fixed some cases (like mentioned tune-xscale and tune-arm926ejs)
where both had unused TUNE_CCARGS when common DEFAULTTUNE was used.
with cortexa[89] it's different, because cortexa9 has one extra TUNE_CCARGS
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex-a9", "", d)}"
which adds extra *space* even when not used because of '+=' and as result:
$ bitbake-diffsigs tmp-eglibc/sstate-diff/1366797730/*/armv7*/adapterbase/*do_configure*
basehash changed from f986789fb8fb3579ed6a3492cc8a8d10 to c851b5f838d945ee13072e9ad6725dca
Variable TUNE_CCARGS value changed from
' -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon '
to
' -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon '
Hash for dependent task gcc-runtime_4.7.bb.do_populate_sysroot changed from bdeabf7a86958b9110b566344b7916de to 2be5618e6bc8c57ec9db5659bf217915
Hash for dependent task eglibc_2.17.bb.do_populate_sysroot changed from b4f40fc62dde684acd0a574532a55360 to 97fcb426603d4a1c1099c0504d2ebf7d
Hash for dependent task glib-2.0_2.34.3.bb.do_populate_sysroot changed from fd2f90b83098c34e88d649d70f6ea4f5 to ebd740bb94ea3eb0a914efda6fc82c4a
(From OE-Core rev: b7430ff83760ac29079d20dc7c62f498a0a9d55d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OVERRIDES reads from left to right, least to most specific. We were
appending to MACHINEOVERRIDES when we should have been prepending so
the ordering of qemuall verses qemuxxx was incorrect, as was the x86
override and several of the arm overrides. This patch is a batch cleanup
of the various issues to correct the order from least to most specific.
The include order does matter and we needed to tweak some of that in this
patch too.
[YOCTO #4090]
(From OE-Core rev: bdc1b214431c9c93a929b547b9a61e7b87fbd366)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* that we always use TUNE_FEATURES_tune-arm* variable and add only one TUNE_FEATURE to it
* for bigendian always use littleendian counterpart and append bigendian TUNE_FEATURE
(From OE-Core rev: 1bc205f895c8143e0bde3c4ba0e699cc0b2f0de8)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.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>
This cleans up and/or corrects a few values from machine includes
for consistency with future toolchain sanity checks, and also adds
the TUNEVALID and TUNECONFLICTS to documentation.conf.
(From OE-Core rev: 6ffe53c721a80cf156b44f59b564f2e899c6af50)
Signed-off-by: Peter Seebach <peter.seebach@windriver.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>
armv7 is least common denominator of armv7-a
armv7-m and armv7-r and armv7-m does not support
ARM instructions but only thumb2 instruction set
which means armv7 when chosen will complain if
code is compiled in arm mode which is default
in OE if not specified other wise
if we chose this tuning errors like below pop up
error: target CPU does not support ARM mode
This tuning seems theoretical and base tune
for armv7 would be one of armv7-a, armv7-m or
armv7-r
(From OE-Core rev: 75b8adbc042e0f65fb1286bc550d02becd3b6aea)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
