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>
The tune-x86_64.inc file is conceptually flawed. x86_64 is more akin to
the x86 and x86-32 ABIs defined in arch-x86.inc than it is a concrete
tune file, such as i586 or core2 - to the extent that everything but the
default tune is defined in the arch-x86.inc file. This becomes very
apparant when attempting to include tune-x86_64.inc in the x86 tune
hierarchy.
Remove the tune-x86_64.inc tune file in favor of it being an ABI
definition in arch-x86.inc and relying on the linear hierarchy of
concrete cpu-types in tune-i586, tune-core2, and tune-corei7.
core2_64 should suffice in lieu of x86_64 for all but a couple esoteric
corner cases involving older pre-core2 CPUs. In these cases, if they
exist at all, the BSP can replace the include tune-x86_64.inc with
arch-x86.inc and set the default tune to x86_64.
(From OE-Core rev: d8884649b2b3e76519bc10f5908f98d940a9c0cb)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@intel.com>
Cc: Tom Zanussi <tom.zanussi@intel.com>
Cc: Nitin Kamble <nitin.a.kamble@intel.com>
Cc: Mark Hatle <mark.hatle@windriver.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume "corei7" meant 64 bit.
Rather than carrying forward an implicit 32b mode and rather than
changing the naming scheme part way through the architecture hiearchy,
make the 32b and 64b variant explicit in the tune name by changing core2
to core2-32. This patch also standardises on using '-' in the names.
(From OE-Core rev: 69e6395b8d11e2940892a6293ecbbe645c2a478b)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@intel.com>
Cc: Tom Zanussi <tom.zanussi@intel.com>
Cc: Nitin Kamble <nitin.a.kamble@intel.com>
Cc: Mark Hatle <mark.hatle@windriver.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type specific ISA, but order the instructions
generically. While the -mtune is implied by -march, gcc does not verify
it is using -mtune=core2 with:
gcc -Q -march=core2 --help=target
Explicitly specify -mtune=core2 to be sure.
Add a comment header describing the CPUs targeted by this tune file.
(From OE-Core rev: 4cd33193b2db6c281275db2fb5cc169181955217)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@intel.com>
Cc: Tom Zanussi <tom.zanussi@intel.com>
Cc: Nitin Kamble <nitin.a.kamble@intel.com>
Cc: Mark Hatle <mark.hatle@windriver.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On real IA hardware, neither the ext3 or cpio images are particularly useful
or used. cpio is legacy from initramfs and that specific image now overrides
FSTYPES accordingly. The size difference in filesystems makes ext3 as a file
format less useful, mainly being useful in the qemu case.
When needed users can still override the default FSTYPES so having
saner defaults makes sense. This improves build times and uses less
network bandwidth for builds and releases.
(From OE-Core rev: 42484d72ed52a1a6f9d3f5b4bf46a72fbfbc490e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QEMU machines don't have virtual IrDA or PCMCIA hardware, so don't claim to
support them.
(From OE-Core rev: 694ca965eea971077e135cda4e54fa1cb0243233)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-i9xx and the GLX X module have to be conditional in the ia32 machine
defintion too.
(From OE-Core rev: 8b5c07e6c3b492f56ce9c5f99a732793403d6b36)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-swrast has to be conditional in the QEMU machine defintions too.
(From OE-Core rev: 9951e1da6a755f9a46d3a595aa4c2f975aee8f46)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
APM is not only obsolete, but requires a kernel config enabled and is meaningless for QEMU VM
[YOCTO #5121]
(From OE-Core rev: b0f8c47b1e808421f03308527beb8bde15644acd)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is appropriate tune for mac99/g4 platform
that we use for emulating qemuppc
(From OE-Core rev: af10ecb57a5eb12c65975043d419f7506ef89b99)
Signed-off-by: Khem Raj <raj.khem@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>
In the current releases, not all linux-yocto derived kernels have NFS
support, or NFS support fragments availble. To ensure that derived
kernels like linux-yocto-cutom continue to work against poky-lsb,
we can make the KERNEL_FEATURE append more specific to the linux-yocto
recipe.
(From OE-Core rev: 799f53e8844748a930a9cbc7a4cf1056f19bb037)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will ensure that qemu images that include the nfs-server package have the kernel
feature correctly enabled
(From OE-Core rev: 57c718c6288f2a2538173cdd3d401d70f939a40a)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no good reason for ia32 machines to have hard dependency on grub,
as there are other bootloaders available for ia32 platforms.
(From OE-Core rev: d03c0c24704c6ab6d2cfcf9bf705f6ace2a247cc)
Signed-off-by: Tomas Frydrych <tomas@sleepfive.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
