* be aware that this -march value is available only in gcc-4.9 and
newer:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907
* -mcpu=cortex15 and -mcpu=cortexa7 conflict with -march=armv7a
We either have to stop putting -march in default CCARGS or at
least set it compatible one like this patch does.
(From OE-Core rev: 35392025f3236f5e5393f9cf0857732da9a2e503)
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>
* 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>
* 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>
Interworking is required for ARM EABI, so attempting to disable it
via a tuning feature no longer makes sense (support for ARM OABI was
deprecated in gcc 4.7). We can drop '-mthumb-interwork' from
TUNE_CCARGS for the same reason.
(From OE-Core rev: d942f94de8966c839209e8c9a632351d108852c4)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake over-rides for _thumb and _thumb-interwork are undocumented
and are not used anywhere in oe-core or meta-oe. The logic setting up
the thumb-interwork over-ride even seems to be reversed and nobody
noticed, so it seems safe to assume that these over-rides are not
used.
(From OE-Core rev: 351443d71eb246a946b41f12b54d57b36fe1574e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Comments are old and specific to thumb1. Since oe-core CPU tuning
files aren't really the right place to fully document ARM -vs- thumb,
drop the comments instead of trying to update them.
(From OE-Core rev: 06225600d4d3041da0d28c79058e5b8ceb4874bf)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* my previous thumb related commit:
commit 3e760031f91fb87c3e2f62b77a117eb41164f259
Author: Martin Jansa <martin.jansa@gmail.com>
Date: Wed Feb 18 15:40:35 2015 +0100
feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb
suffix
unfortunately removed conditional on "thumb" in TUNE_FEATURES, when
setting ARMPKGSFX_THUMB
* in case we have MACHINE without "thumb" in TUNE_FEATURES and distro
setting ARM_INSTRUCTION_SET to "thumb" we end with:
ARM_INSTRUCTION_SET="thumb"
ARM_THUMB_OPT="thumb"
ARM_M_OPT="thumb"
# TUNE_CCARGS correctly not adding -mthumb
TUNE_CCARGS=" -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon"
# but ARMPKGSFX_THUMB and TUNE_PKGARCH including "t2":
ARMPKGSFX_THUMB="t2"
TUNE_PKGARCH="armv7at2-vfp-neon"
# causing following error:
Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv7at2-vfp-neon).
(From OE-Core rev: 951200673af27538beaef647a33308b4f15d1fb0)
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>
* this means that recipes with ARM_INSTRUCTION_SET explicitly changed
to arm will be built in feed without thumb suffix, the same does apply
for workdir, e.g. after "bitbake glib-2.0" you can see:
tmp-glibc/work/armv5e-oe-linux-gnueabi:
glib-2.0 glibc glibc-initial
tmp-glibc/work/armv5te-oe-linux-gnueabi:
acl db gdk-pixbuf kmod ....
and
tmp-glibc/deploy/ipk:
all armv5e armv5te qemuarm
* feed config should be ok, because all default DEFAULTTUNEs always
include "arm" variants of all supported PACKAGE_ARCHs
* for more details see
http://lists.openembedded.org/pipermail/openembedded-core/2014-April/091960.html
the toolchain path issues were resolved in 1.8
* add ARM_INSTRUCTION_SET = "arm" to glibc-collateral.inc and comment in
glibc.inc to fix glibc-locale and glibc-scripts build
(From OE-Core rev: 3e760031f91fb87c3e2f62b77a117eb41164f259)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The extra space makes the overrides look like "foo:bar: thumb:foobar".
This may prevent thumb from working properly, and the space was never
intended in the original fix.
(From OE-Core rev: 330119da319a08c13ca3350270a95d66d18ffb94)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-arm64 is the base tune file for aarch64. Update this to allow the
system to work with both aarch32 and aarch64 (multilib).
arch-armv8 is for compatibility, it simply uses the base config for now.
feature-arm-thumb was updated, since aarch64 mode does NOT have thumb support.
We should only be processing warnings and additional arguments if thumb
support is enabled on the processor core.
(From OE-Core rev: 03d2f5646485b565cc14a0009b7d5224ab298f4c)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add machine qemuarm64. The configure files are derived from linaro.
Update:
* rename genericarmv8 to qemuarm64 for coordination in oe-core
* include qemu.inc then remove common part of config
* disable using autoserial
* move arch-armv8.inc from machine/include/arm64 to machine/include/arm
[YOCTO #6487]
(From OE-Core rev: d7314c3bc804b7bcc921b0a6c5b63d71ca2e73db)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* there is issue for TUNE_PKGARCH missing in PACKAGE_ARCHS for machines
without thumb enabled, it was reported by Jacob Kroon on IRC
(From OE-Core rev: 1e1b42f687b5cd34623fe2682218958e1947eb92)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe does not explicitly set ARM_INSTRUCTION_SET, then there is no
need to throw a warning:
WARNING: Recipe 'foobar' selects ARM_INSTRUCTION_SET to be 'None',
but tune configuration overrides it to 'arm'
(From OE-Core rev: e457d71641af8802e47eb4854072e3cfb957b001)
Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
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>
* unfortunatelly that note about armv7 matching also armv7a is no
longer valid since armv7 include in armv7 was replaced with
armv6+neon in this commit:
commit 75b8adbc042e0f65fb1286bc550d02becd3b6aea
Author: Khem Raj <raj.khem@gmail.com>
Date: Tue Mar 27 18:37:45 2012 -0700
tune/armv7: Delete
since then thumb and arm feeds had the same architecture
* be aware that this will rename lots of feeds
(From OE-Core rev: 8e8839215032b57763a07363a560c3fd9d6f8e01)
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>
Using CORTEX_ID variable reference in the tuning overrides did not work.
This reverts those changes, and adds a tuning file for the cortex-a5.
Revert "tune-cortexa5.inc: Add tune file for cortex-a5"
Revert "tune-cortexa.inc: create a common include for cortex-a armv7a tuning"
(From OE-Core rev: 74158c2e99c6d8631800ae80025d1cc9f19336d2)
Signed-off-by: Andy Voltz <andy.voltz@timesys.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The tuning files for the cortex-a* processors are mostly identical for
the A7,A8,A9,A15 processors. Rework these files to use a CORTEX_ID
variable to setup the tuning for each specific processor.
(From OE-Core rev: 3e4f4a1cf07ff7cf4c71566492385f8fbf581789)
Signed-off-by: Andy Voltz <andy.voltz@timesys.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>
This work was made by Victor Enriquez and then modified by Denis Carikli
who was helped by Mark Hatle comments. And in the end modified by Martin
Jansa to support different ARMPKGARCH and removed explicit -novfp suffix.
The changes are for adding support to armv6-novfp, for building binaries
for armv6 machines without vfp, for example the htc dream.
(From OE-Core rev: 0733e2f8ad82b426c8c40ef753adb9431fa3c359)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Víctor Enríquez <victor.quicksilver@gmail.com>
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>
* without this patch it does apply --fix-v4bx not only to armv4, but
also all higher (because they also have armv4 in TUNE_FEATURES)
* it causes SIGILL on armv4t
http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-November/042298.html
* someone please test on armv4 device (I tested only bitbake -e output
that it's correctly applied with DEFAULTTUNE == armv4
* maybe we can should fix this in binutils instead (both 2.22 and 2.23
are affected)
(From OE-Core rev: efe03fc00fc051bede69ced6643a8f25d02eabde)
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>
* 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>
Using "1" with getVar is bad coding style and "True" is preferred.
This patch is a sed over the meta directory of the form:
sed \
-e 's:\(\.getVar([^,()]*, \)1 *):\1True):g' \
-e 's:\(\.getVarFlag([^,()]*, [^,()]*, \)1 *):\1True):g' \
-i `grep -ril getVar *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent versions of the GCC reject the -mno-thumb option. In order to prevent
the compiler from generating code for the Thumb instruction set the -marm
switch should be used instead. For details see GNU bug #47930.
(From OE-Core rev: 72dc73f5a647ccd38145fd888c109a144f202963)
Signed-off-by: Ken Werner <ken.werner@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
