Since commit 972b4fc (feature-arm-neon.inc: restore vfpv3-d16 support)
we're replacing _all_ dashes (-) in ARMPKGSFX_FPU, which is causing
problems for all legitimate uses of the dash as TUNE_PKGARCH doesn't
have the right value anymore:
E.g. on raspberrypi2:
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Error, the PACKAGE_ARCHS variable (all any noarch armv5hf-vfp armv5thf-vfp
armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp
armv7at2hf-vfp armv7vehf-vfp armv7vet2hf-vfp armv7vehf-neon armv7vet2hf-neon
armv7vehf-neon-vfpv4 armv7vet2hf-neon-vfpv4 cortexa7hf-vfp cortexa7hf-neon
cortexa7hf-neon-vfpv4 cortexa7t2hf-vfp cortexa7t2hf-neon
cortexa7t2hf-neon-vfpv4 raspberrypi3) for DEFAULTTUNE (cortexa7thf-neon-vfpv4)
does not contain TUNE_PKGARCH (cortexa7hf-neonvfpv4).
Fix this by being more explicit about what we're modifying.
Reported-by: Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: cf82db2ba732031f392760e4f363e8b608e6fae3)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 6661718 (feature-arm-{neon,vfp}.inc: refactor and fix issues)
effectively changed the gcc -mfpu= option from -mfpu=vfpv3-d16 to
-mfpu=vfpv3d16, which gcc doesn't understand.
Restore the original value.
After doing that, we also need to adjust ARMPKGSFX_FPU which should
contain the same value without dash '-' as it is used that way
throughout.
(From OE-Core rev: 972b4fc459258572eeaad8af91e48ee9f0acade7)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It simply does not work at all:
https://lists.yoctoproject.org/pipermail/yocto/2016-April/029698.html
(From OE-Core rev: d044743cdc415745e68f3e26a3a7e2c94caecd93)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armv7a is a subset of armv7ve:
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
-march=armv7ve is the armv7-a architecture with virtualization extensions.
By inheriting armv7a from armv7ve it's possible for e.g. Cortex-A15 machines
to include tune-cortexa15.inc and have a full range of optimizations, but
set DEFAULTTUNE as "armv7a" to produce binaries compatible with Cortex-A8
machines, etc.
(From OE-Core rev: 5bf5e68e540dc4e034288702094d306ebd19fef9)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new value is more general and better reflects what having the feature really means.
Introspection data, then, is built only if 'gobject-introspection-data' is in
DISTRO_FEATURES and 'qemu-usermode' is in MACHINE_FEATURES.
(From OE-Core rev: 9927a3d72e2272d8e3dc4785ba02e27802ee1c6c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use latest 4.x kernel instead of 3.x version
(From OE-Core rev: 138a03308fb24936466beb082b350d872ad423a6)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When enabling tune for arm926ejs, poky optionally appends suffixes for
thumb and dsp support. Since sometimes arm926ejse (ARM code) and sometime
arm926ejste (thumb code) is used in PACKAGE_ARCH, allow both.
(From OE-Core rev: dbd7fd1cbbc3e7003a48542642acdc80dca3f514)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Accept the default MACHINE_FEATURES from qemu.inc (qemuarm64
shouldn't need to be a special case).
(From OE-Core rev: e26718f8c048315e2ab819bc60566061f6ced420)
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>
x32 isn't supported by user mode qemu so we can't build
gobject-introspection-data, so disable it in this case.
(From OE-Core rev: 4ee1eb8ddd3fbe144fbaeb32e07b66e191aa7548)
(From OE-Core rev: 04ecebd4a79f80c5bb054a8b21df6f555631ed8b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change the name to core2-32 from core2.
There's no AVAILTUNES with the name core2. Make sure that we specify
the correct TUNE name so PACKAGE_EXTRA_ARCHS is expanded correctly.
[ YOCTO #9197 ]
(From OE-Core rev: 0903d6f0098f112d4263812df109e0c44c166db8)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Anuj Mittal <anujx.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apply the same sort of changes to the Cortex-A17 tune as were done in commit
35392025f3236f5e5393f9cf0857732da9a2e503.
(From OE-Core rev: fb981f1a5be2277ae4966527fdebe196022d3826)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the quotes in the bb.utils.contains feature check so that the call
results in a boolean value instead of a string, which allows the warning
check to occur.
(From OE-Core rev: aac3919f538a5608ffcc3af5bd8f121e3c2c3469)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds rng-tools to MACHINE_EXTRA_RRECOMMENDS so that can be
used to provide the additional entropy to prevent hangs in getrandom()
for qemu images
[YOCTO #8681]
[YOCTO #8816]
(From OE-Core rev: cb512c0c189f5a1196da233042113a708243daa0)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If tune-corei7 is in use then the target binaries may contain instructions that
qemu-x86-64 can't execute by default, resulting in errors on rootfs construction:
NOTE: Running intercept scripts:
NOTE: > Executing update_font_cache intercept ...
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
In this case the instruction is popcnt, part of SSE4.2, so tell Qemu to emulate
the CPU that the tune targets (in this case, Nehalem). Also pass check=false as
the Nehalem machine supports VME but user-space qemu doesn't, which produces a
warning unless CPUID checking is disabled.
[ YOCTO #8888 ]
(From OE-Core rev: fef106b9b97ec48bad2b9a084357b884f653d6c8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Cortex M1, M3 and R4 CPU tuning files are poorly tested (if at
all). They have no obvious users either inside or outside oe-core.
Until OE officially gains support for CPUs without an MMU, these
tuning files are probably better maintained outside of oe-core (e.g.
in a separate meta-nommu layer).
(From OE-Core rev: 7a1445c55de904115b950c8e50432a9f11f02208)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
G4 does not have SPE, so we make that explicit in the tune files and
since we emulate G4 when building Qemu, we ensure it for qemuppc as
well.
GCC config for powerpc-linux is made to include SPE by default which is
equivalent if the tripet was powerpc-linux*spe, this forces gcc to
configure assembler to enable -mspe by default, when we do that then the
kernel fails to compile with binutils 2.26, since newer assembler is
smart to detect the tlbia instructions are not compatible with SPE and
hence the kernel build breaks rightly. We configure the kernel for G4 as
well where it enables tlbia instrucitons rightly so because it thinks
its being configured for power4. So we keep the options but do not force
-mspe down to assembler as default.
(From OE-Core rev: 7a51776a830167e43cbd185505f62f328704e271)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* since:
commit cffda9a821a3b83a8529d643c567859e091c6846
Author: Martin Jansa <Martin.Jansa@gmail.com>
Date: Tue Sep 11 17:05:45 2012 +0000
arch-arm: define different ARMPKGARCH when different CCARGS are used
we don't need to worry about e.g. cortexa7 device upgrading
binary package from armv7a feed which would be built with
-mcpu=cortexa15, so we can use -mcpu instead of -mtune, because
we won't share the binary feed with MACHINEs built with different
tune.
(From OE-Core rev: f7bb2d4cf18ca8d2a90b4b3b5c6c48dad106ca28)
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>
* 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>
* it was added only to hf cortexa7 in:
commit e97d152ca13556b41a236c1a4cfb11e77ff857d7
Author: Kristof Robot <krirobo@gmail.com>
Date: Sun Jan 26 10:03:56 2014 +0100
Add Cortex A7 support for NEONv2 & FPv4
* add it to softfp cortexa7 and both versions for cortexa15 and
cortexa17 tunes
(From OE-Core rev: 109c26d99b6324c1412f440fef85f090518f6da0)
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>
* both belong and already are in arch-armv5-dsp.inc
(From OE-Core rev: 791f52d3b58ce1fd4bfd159deb83a1917d6267f2)
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>
* 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>
Since the qemu for aarch64 must use a virtual console for the second
serial port rather than emulating actual hardware, make sure the correct
device is specified so that a tty is actually started.
(From OE-Core rev: 5b720a69f0d181ab2de6032a6e3f5a0ee4a14302)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemu can freeze and stop responding if the socket buffer connected to a tcp
serial connection fills up. This happens of course when the reader of
the serial data doesn't actually read it.
This happened in the qemurunner code, because after checking for the
"login:" sentinel, data was never again read from the serial connection.
This patch solves the potential freeze by adding a thread to continuously
read the data from the console and log it. So it also will give a full log
of the console, rather than just up to the login prompt.
To simplify this patch, another serial port was also added to use for the
sole purpose of watching for the sentinel as well as being the interactive
serial port. This will also prevent the possibility of lots of debug
data on the console preventing the sentinel value from being seen due to
interleaved text.
(From OE-Core rev: 2da3fee6b6d9f4dd4c4cb529f4ba393c20aa0f13)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.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>
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware,
and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86-64 image,
the image can be made to launch an X server on when cirrus and std are chosen,
in addition to just vmware. (The build of QEMU in OE-Core appears to have QXL
disabled, meaning a driver for it is unnecessary.)
The runqemu script now allows the choice of emulated VGA adapter to be
specified manually, so it's important that qemux86-64 supports any configuration
the user might choose without requiring the image to be rebuilt.
(From OE-Core rev: 1216de77a7f23fa10e34aee1ebe27fcc6a6589c0)
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QEMU is capable of emulating four different VGA adapters: cirrus, std, vmware,
and QXL. By adding the cirrus and fbdev X.Org drivers to the qemux86 image,
the image can be made to launch an X server on when cirrus and std are chosen,
in addition to just vmware. (The build of QEMU in OE-Core appears to have QXL
disabled, meaning a driver for it is unnecessary.)
The runqemu script now allows the choice of emulated VGA adapter to be
specified manually, so it's important that qemux86 supports any configuration
the user might choose without requiring the image to be rebuilt.
(From OE-Core rev: 9e4ca6739d65716fcb0a1b7d635749083da98c52)
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The MIPS emulation for qemumips actually supports
mips32r2:
isa : mips1 mips2 mips32r1 mips32r2
We should probably use that tuning file.
This implicitly changes the default value of DEFAULTTUNE to
mips32r2.
(From OE-Core rev: 5d64516d81750e4e0d65792a3215568d652bec6c)
Signed-off-by: Peter Seebach <peter.seebach@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>
Kernel and initramfs built and tested on GCW Zero (jz4770)
(From OE-Core rev: 149885560e2fbc91c7f60226d015ba9842373e26)
Signed-off-by: Andrea Adami <andrea.adami@gmail.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>
As x86_64 has been "demoted" to an ABI definition rather than a concrete
tune file, replace it with core2-64 for the qemux86-64 machine.
(From OE-Core rev: 65c1ba225a410d2ee1913d55c6f986db9f54cc8e)
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>
No new content, just correcting a few typographical errors.
(From OE-Core rev: 8df13f5013d92954ee76943dad58db75704c3cc5)
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>
Describe the expected usage of base architecture tune files and
arch-specific files, specifically the stacking of generations.
(From OE-Core rev: 282735d7c8fcbd7e354f544c45461b095700fb77)
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>
Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.
(From OE-Core rev: 112e291c14ce4c3b8d074b71e63500dce609784e)
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>
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>
corei7 offers a significant advancement since the previous core2
cpu-type described in the tune-core2 file.
From the GCC(1):
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
This offers optimizations for Nehalem and Silvermont (e.g. Bay Trail)
CPUs (and beyond).
(From OE-Core rev: 21f8ce2a4b94034284eb74b9c3b4c9cc638511d6)
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>
Inherit the PACKAGE_EXTRA_ARCHS from i586 and only explicitly add core2
here.
(From OE-Core rev: 2a10d570560c37eb1d23cf853c0e541bc08a2878)
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>
The generic x86 build supports i586 by default, so this specific tune
file technically doesn't add any specific ARCHes to PACKAGE_EXTRA_ARCHS.
For consistency, append the current tune to PACKAGE_EXTRA_ARCHS.
Since we do not have specific tune files for i386 and i486, just drop
them.
These could be added to tune-x86 version if there is a need to
maintain them, but they really do not belong here.
(From OE-Core rev: 1ff914118bdfb19d7f3d794a92ba3735c06ab97b)
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>
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term "x86" fits this used better
without resorting to using the term "Intel" which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
(From OE-Core rev: f5e0a574d87b7dc6466bfe01593fab5aa13464ff)
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>
We shouldn't bring this in unconditionally for all ia32 machines.
(From OE-Core rev: d573d424788d56c6fee02c1ee0cdeb96fe610b85)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
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>
We use mac99 as platform for qemuppc
lets choose a tuning thats appropriate for it
(From OE-Core rev: 9b5572b8014f23747f18a7e0ca30c7094c524920)
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>
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>
André Draszik
André Draszik
Alexander Kanavin
Denys Dmytriyenko
Maxin B. John
Jens Rehsack
Andre McCurdy
Richard Purdie
Chang Rebecca Swee Fun
Trevor Woerner
Nathan Rossi
Richard Tollerton
Saul Wold
Ross Burton
Khem Raj
Martin Jansa
Carlos Alberto Lopez Perez
Armin Kuster
Dmitry Eremin-Solenikov
Randy Witt
Mark Hatle
Kai Kang
Armin Kuster
Max Eliaser
Peter Seebach
Andrea Adami
Jacob Kroon
Otavio Salvador
Mats Kärrman
Valentin Cobelea
Kristof Robot
Darren Hart
Paul Eggleton
Andy Voltz