* 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>
* PACKAGE_ARCHS were missing TUNE_PKGARCH armv7rt2-vfp because thumb is enabled
in TUNE_FEATURES
(From OE-Core rev: 51a99e28d0d15e227fc05f43974f54f6d8e62ef5)
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>
* The Xorg server needs to load the GLX extension in order to
enable proper OpenGL support.
* Before this patch, glxinfo aborted with:
root@qemux86:~# glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
* After this patch, it works as expected:
root@qemux86:~# glxinfo | grep " render"
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
(From OE-Core rev: 8f33627684755899c5b1fd7eeefdd89c42e68fec)
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
changed upper case "X" to lower case "x"
(From OE-Core rev: ff8bf4907ff3b1a9c479fe158c31607da07f9b55)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provide BASE_LIB settings for octeon* tunes that follow the practice of
mips64/mips64-n32 tunes (lib64 for N64 ABI, lib32 for N32 ABI).
(From OE-Core rev: 2b52312174e52886b0a978ece41f66b4fb455604)
(From OE-Core rev: 9531dbe2106d5ba5a9e7d66b3c640a98e4fb6ec4)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Octeon II/III binaries can contain instructions that are not compatible
with MIPS64 processors. Thus Octeon II/III packages should go to
separate directories. Set MIPSPKGSFX_VARIANT_tune-* to Octeon-specific
values and update PACKAGE_EXTRA_ARCHS_tune-* accordingly.
(From OE-Core rev: 69798449a8c1049728674dd352cf828063974cd0)
(From OE-Core rev: 3f16f76868105aae7c82ae33831d3317903b58ac)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently MIPS64 N32 is broken. There is internal disagreement
between TARGET_ARCH (which doesn't contain ABIEXTENSION) and
TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already
encoded into the TARGET_OS. ARM tunes in the same situation override
neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop
this override.
(From OE-Core rev: 3ee5c9ad302bc05c75badbe29dd983a043a114c2)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use i686 as TARGET_ARCH for 32bit core2 (and corei7 and atom) builds.
In most cases, i586 and i686 are equivalent values for TARGET_ARCH, however
one important exception is glibc. When configured for i686, glibc enables
optimised string functions (SSE, SSE2, etc), which are not used when
building for i586.
The benefits of i686 optimised string functions vary depending on the
application and the CPU, however in some cases the improvements are
significant. In one test, a 50% increase in FPS was seen when running the
'smashcat' benchmark [1] in a qtwebkit browser on an Intel Atom based SoC.
The gain seems to comes from a 3x improvement in memcpy performance when
copying graphics buffer lines (5120 bytes, or 1280 x 4 bytes/pixel), from
the CPU to GPU. Note that very large memcpy's (e.g. 32MB) on the same
machine show no particular performance increase between i586 and i686.
[1] http://www.smashcat.org/av/canvas_test/
Warning: The change in TARGET_ARCH means that _i586 architecture specific
over-rides will no longer take effect. Both oe-core and meta-oe have been
updated to replace _i586 over-rides with _x86, however other layers may
still need review and updating.
(From OE-Core rev: dd09fab685de2eaf04aa5ab60f8220b89c1deae9)
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>
This tune file is needed to enable a GAS option specific to this cpu family
in order to disable the usage of lock prefix instructions.
(From OE-Core rev: 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise, if MACHINEOVERRIDES is expanded before SOC_FAMILY is set
(which may happen as MACHINEOVERRIDES is included in OVERRIDES) we can
see:
ExpansionError: Failure expanding variable MACHINEOVERRIDES, expression was
${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}p1022ds
which triggered exception SyntaxError: EOL while scanning string literal (MACHINEOVERRIDES, line 1)
To avoid this, give SOC_FAMILY a default empty value so it doesn't
get read as None.
(From OE-Core rev: dee005b6e1bc353230f9f27a469b2054a644e542)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no good reason not to use ext4 at this point, it has advantages
and few drawbacks. Therefore switch the qemu machines over (and the default
runqemu script options).
(From OE-Core rev: 430b9ae71b1aa76f8421127d17e0e0723d4818d3)
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>
[YOCTO #7230]
In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.
This will cause SDKs to fail to generate properly.
Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well. This effectively defines a new class of overrides for the 'n32'.
The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.
(From OE-Core rev: 4b3a2b703b20583bd107f00a297d972e9bfb514a)
Signed-off-by: Mark Hatle <mark.hatle@windriver.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>
[YOCTO #7143]
When the system is configured for a multilib SDK, such as:
require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
DEFAULTTUNE = "mips32r2"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
Only one of the mips64-n32 or mips64 toolchains is built. Causing the
other to be unavailable. This is due to both recipes ending up with the
same PN.
The toolchain uses the TRANSLATED_TARGET_ARCH in it's name, however the
target for mips64 and mips64 n32 were the same, causing the conflict.
Avoid this conflict by adding the ABIEXTENSION to the name.
(From OE-Core rev: 0bcc01121e928d0be7a0550e500425852c63cf98)
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>
Without this, you are not able to use mips32r2 on a mips64 based tune.
We want to be able to do a tri-lib system of mips64, mips64-n32 and mips32r2.
(From OE-Core rev: ccacfd3460b47494f687c696ff985b7c1c6ca1cd)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.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>
The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.
(From OE-Core rev: d83b16dbf0862be387f84228710cb165c6d2b03b)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The tuning file for PowerPC e300c3 is soft-float. In OE-classic it was hard-
float and it should be as the c3 has an fpu. I have modified the tuning file
to include both a hard-float version (using the existing ppce300c3 name) and
an optional soft-float version (called ppce300c3-nf).
The following patch also passes a "--with-cpu=e300c3" argument to GLIBC.
For this to have any effect the sqrt/sqrtf implementations added by the
"glibc.fix_sqrt2.patch" are required and also an additional "Implies" file
(added to the mentioned patch as a separate patch for eglibc_2.19).
Tested with eglibc 2.19 on PowerPC MPC5125.
(From OE-Core rev: 9d502ca8551fd461f869395b1b7e62d6dcf59a84)
Signed-off-by: Mats Karrman <mats.karrman@tritech.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch fixes a typo in the tune config file for ppc64 e6500
where the cpu type is a wrong one.
(From OE-Core rev: 168d57f594f559d8f0cb5a9298055b62ff192f27)
Signed-off-by: Valentin Cobelea <valentin.cobelea@enea.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>
