For multilib to work correctly, BASE_LIB overrides must be provided.
(From OE-Core rev: b32ec63e48a3552f2e7f3cc5caf61432af716283)
Signed-off-by: teven Hung (洪于玉) <Steven.Hung@mediatek.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For multilib to work correctly, BASE_LIB overrides must be provided for
each new tune added in this file.
(From OE-Core rev: e39c5ec90ebbc37064c9cd59eba12603317740cd)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some ARM Cortex devices have the VFPv4-D16, but no NEON.
(From OE-Core rev: 594f8584268d5179c18512beada2bae4a21325de)
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I am not familiar with the big endian, so I don't update it.
I don't have much information about the Cavium ThunderX,
it looks like it supports all the ARM instructions.
(From OE-Core rev: b6c6fa72bdffd5d8995058e8e0e21d5561cc16c6)
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some addtional instructions apart from bare armv8,
also there is armv8.1, armv8.2.
Most the processor would support crc, except X-gene 1.
(From OE-Core rev: d1db78b0e284e1a1f370e71183ded0cbdc1475db)
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tune files which inherit the arch definitions already define appropriate
-mcpu option, which is equivalent of right -march and -mtune combination
and is preferred since gcc is getting stricter and stricter with option
check semantics and can now find incompatible -march and -mcpu options
better with every release. It does internal feature consistency check
and if it finds out discrepency between what -mcpu would expand to as
compared to -march it will flag the options to be incompatible, for
naked eye it sounds wrong but gcc would translate -mcpu to a given
-march internally and it might not match to what we set in these arch
files.
The effects are quite subtle, where this can result in configure test
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.
e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ ends up
disabled due to configure check failures e.g. size_t size, ptrdiff_t
sizes, which inturn results in compiling libstdc++ with unwanted
disabled features.
(From OE-Core rev: ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-march=armv5't'e means that CPU can execute thumb ISA, we do not need to
tie this to exclusively generating thumb ISA, this change means that
when we have thumb in tune features then it can use 't' in -march
options irrespective of ISA being thumb or arm.
This fixes derivative of armv5 tunes and paves way for gcc9 where e.g.
armv5e is dropped and minimum arch supported is armv5te
(From OE-Core rev: 49bc3eab2897307a92b538a045e3d4dce245b0e0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Historically first PowerPC ABI was big-endian only (elfv1 currently). It
is standard ABI for both 32-bit ppc and 64-bit ppc64 architectures.
With PowerPC little-endian support new ABI was introduced (elfv2) and it
is used primarily with ppc64le target only. While it has support for
big-endian it is not commonly used and elfv1 still preferred.
Musl does support only elfv2 ABI for both LE and BE and does not have
any plans to support elfv1.
Since then to build for powerpc64 with musl new ABI should be used. As
expected it is not compatible with elfv1 but that isn't problem as long
as there is no binary distributed software or assembly code written for
elfv1 ABI.
(From OE-Core rev: 68c9641855199f34aabe1050e863c21830116fe1)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The QEMU usermode fails with invalid instruction error when
used with those tunes.
(From OE-Core rev: c1c881ef7f4faf94f385ae742030382122ee5816)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is ppcpX, not ppcprX, where X is 6 or 7. While there select 32bit
tune for P5 machine to bring it inline with P6 and P7.
(From OE-Core rev: 220eee184a4f510cdf7c55e2aed00330abee1553)
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just adding `-device virtio-rng-pci' to the QEMU invocation will
add the device with a default host backend. As of QEMU 1.3+,
the default backend is to use the host's /dev/random as a
source of entropy. [1]
When the entropy pool is empty, reads from /dev/random will
block until additional environmental noise is gathered. [2]
For Yocto, if call runqemu frequently, it will consume lots
of host's /dev/random, and kernel finish crng init in guest get
more and more slowly.
Here are 4 times runqemu boot test:
[ 3.464432] random: crng init done
[ 20.874030] random: crng init done
[ 23.583589] random: crng init done
[ 23.858945] random: crng init done
Modify entropy source to /dev/urandom device on the host which
returns random bytes using a pseudorandom number generator seeded
from the entropy pool. Reads from this device do not block and
kernel finish crng init in guest will not delay.
Of course, the side effect is obviously, we lost the quality of
randomness, but the modification is only on runqemu script
rather than real embedded device, and it benefits oeqa efficiency
in which many cases call runqemu especially multiple oeqa builds
on one host.
After apply the fix:
[ 3.364670] random: crng init done
[ 4.619061] random: crng init done
[ 3.403897] random: crng init done
[ 3.450717] random: crng init done
[1] https://wiki.qemu.org/Features/VirtIORNG
[2] http://man7.org/linux/man-pages/man4/random.4.html
(From OE-Core rev: 853644f82eb3205ef3efc1ea3959c7225dfacf61)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
*The PowerPC SPE support is split off to a separate powerpcspe port
(From OE-Core rev: c67bc9bdcbcf46ed54dfbafd1bb6e405ed77f86a)
Signed-off-by: Chunrong Guo <chunrong.guo@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
4.18 is replacing 4.15 as the latest kernel in the upcoming
release, so we update our preferred versions to match.
(From OE-Core rev: e12f9e7ede7eea408d6a97233c7c8df97e8bfb26)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SERIAL_CONSOLE was already deprecated in 2013, yet still some
machine configuration files were using it. This patch replaces
it with SERIAL_CONSOLES, which is the successor.
The default value in systemd-serialgetty.bb can also be safely
transitioned from SERIAL_CONSOLE to SERIAL_CONSOLES, as this
recipe already uses SERIAL_CONSOLES within do_install().
The documentation seems to be already up do date.
beaglebone-yocto.conf in the bsp-guide already uses
SERIAL_CONSOLES. The ref-manual redirects from SERIAL_CONSOLE
to SERIAL_CONSOLES.
[YOCTO #12653]
(From OE-Core rev: e5bde3d466869df9fce559e49842ac245153d045)
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemumips,qemumips64 and x86 based machines include kernel-modules by
default. Remove the kernel modules from RRECOMMENDS to make it consistent
across the machines.
Tested using core-image-sato on qemumips, qemumips64, qemux86 and
qemux86-64
[YOCTO #12383]
(From OE-Core rev: 1c4d9f46d5d94ea15d0c0d68c412ec05b9f51820)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although there may still be specific cases which can benefit from the
ARM instruction set, the Thumb2 instruction set is generally a better
default for armv7a class CPUs. Distros such as Debian and Fedora have
been targeting Thumb2 by default for some time.
Note that setting ARM_INSTRUCTION_SET has no effect unless
TUNE_FEATURES contains "thumb" (which is controlled by the "t" suffix
in DEFAULTTUNE, e.g. armv7vehf-neon -vs- armv7vethf-neon, etc) so out
of tree machine configs may need to update their DEFAULTTUNE to take
advantage of this change.
(From OE-Core rev: c88304a78e528596ca481cabe273749c286c352a)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The logic can be improved and the historical NOISO/NOHDD variables
moved into the class and out of common code.
The variables are also then removed in favour of directly controlling
the behaviour from IMAGE_FSTYPES in line with all the other image types.
(From OE-Core rev: a052caed563a09a01f5a3ea1f0477f379c05bee0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently we have local.conf included before qemu.inc, and ${DISTRO}.conf
after qemu.inc. They both possibly specify their expected kernel providers.
To let other config files override it in real use, this commit changes
kernel provider assignment to ??= .
(From OE-Core rev: 07e06abeb6b7ae5047c4b70818cd8873302e4940)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc "corei7" CPU type was last documented in gcc 4.8.x and has
been undocumented from gcc 4.9.x onwards:
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html
Although it still seems to be accepted by gcc 7.x, it's likely to be
deprecated and removed at some point. To preempt that, switch the
corei7 TUNE_CCARGS -march CPU type to "nehalem", which is the closest
replacement (and matches the CPU type already being passed to qemu).
Since the tune-corei7.inc include file is intended to cover a range
of CPUs from Nehalem onwards, switch the TUNE_CCARGS -mtune option
from "corei7" to "generic", which instructs gcc to produce code
optimized for the most common IA32/AMD64/EM64T processors.
(From OE-Core rev: 8d2f51e9b8d5b27fc61d148a6dd5f6ef5715d6e6)
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>
Define cpu type for Qemu in QEMU_EXTRAOPTIONS.
Otherways Qemu will emulate some virtual qemu32/64 processor,
which has very basic set of features, and programs built
for later CPU may crash, due to lack of new features (e.g. SSSE3).
(From OE-Core rev: 11f4fdcafed1383e5b6c2e634c670d19124e537a)
Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There isn't currently any tune available for i686 x86 optimizations.
The tune for i586 doesn't enable i686 specific optimizations, and the
one for core2 enables things that won't work on a i686 CPU (like SSE3).
Make the tune for core2 inherits from this one and move there the
setting of X86ARCH32.
(From OE-Core rev: c08f76ba0654e43074b6b964f728765918dbfb09)
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel class now sets RDEPENDS_${KERNEL_PACKAGE_NAME}-base so this include
needs to do the same, otherwise bitbake emits a warning and the kernel isn't
removed.
(From OE-Core rev: a408236b6302273a5a45bcfe5eb3a8f2713ec3fa)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add architecture and tune includes for MicroBlaze. This covers
architecture configuration as well as tune configuration and features.
The Xilinx MicroBlaze architecture is a soft-core CPU architecture
designed for implementation on Xilinx FPGAs. Because the CPU is a
soft-core it can be configured differently depending on resource and
performance constraints which affect the ABI and supported instructions.
The architecture is also used in other Xilinx products where the core is
implemented as part of fixed silicon (e.g. Xilinx ZynqMP).
The default tune include 'tune-microblaze.inc' provides the baseline (no
features enabled) tune configuration for a target machine. This is
similar to other architectures such that the machine.conf includes a
tune-*.inc. However due to the customizability configuration is
specifically handled on a per machine basis. A machine should configure
the available tune features by setting the available features directly
by appending to the 'TUNE_FEATURES_tune-microblaze' variable.
This tune configuration approach is preferred to avoid the definition of
an otherwise large set of possible tune configurations for the available
features (14 CPU versions and 11 feature configurations), which would
otherwise require >1024 predefined tune configurations.
(From OE-Core rev: 295a99a31ca147a271c0c76538c4fb27dbecab27)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was included to allow hwrng to feed data to /dev/random. Since the
kernel does this itself (confirmed by the recent kernel Kconfig text change
, code inspection and local testing), we can drop rng-tools from these
images.
(From OE-Core rev: d4b17e841b497f0ee4d31a8c967b5ce1b76157e4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The trailing space added to TUNE_CCARGS when appending -mfpu=XXX is
unnecessary and leads to a double space in the final value.
(From OE-Core rev: 4fde0110321b04d1f3418f05e61a2eb0b3ec8625)
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>
This is needed as an x32 more generic x32 override later in the
OVERRIDES, currently linux-gnux32 is the first override, but we
need a stronger (later in the list) x32 override to deal with some
needed x32 dependency overrides.
(From OE-Core rev: 364b3698b78e9fea59d24e3a3a5f4476be95f6d1)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit e8b1c65394, we started seeing
errors like the following during boot on genericx86 machines:
uvesafb: failed to execute /sbin/v86d
uvesafb: probe of uvesafb.0 failed with error -22
uvesafb: vbe_init() failed with -22
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
These were caused because the uvesa module was being loaded during boot,
when it is only meant to be loaded on qemu according to:
6af89812e8
Since genericx86-common.inc includes qemuboot-x86, the module also tries
to be loaded on genericx86 machines, this patch removes the instruction from
qemuboot-x86 and adds it in specific to both qemux86 machines confs so
it is correctly loaded only on those.
[YOCTO #11879]
(From OE-Core rev: 261f9c382121c73b72556a151fdd4c7938b32a92)
(From OE-Core rev: 554903483acb4af402feaba013366388db89e36b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not all the qemu machines carry default kernel specifications.
While we could drop these references, we'll bump them to 4.12
to pick up the latest and remove them in future commits.
(From OE-Core rev: c58df63d88a07d3275e7337f7d284b0a50db82cc)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace the deprecated '-usbdevice' option with '-device usb-xx' option.
This would fix runqemu boot error like below.
'-usbdevice' is deprecated, please use '-device usb-...' instead
(From OE-Core rev: 2f1f3480d344f8521e01f456d2dcd6c4e989ec59)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
live image type was replaced by hddimg recently. This made
NOHDD and NOISO options ineffective as they only influence
live builds. It also causes image building failure for
image sizes >4Gb
Returned back live image type and disabled building iso image.
This doesn't change result (hddimg is built), but it makes
NOHDD and NOISO working as expected.
[YOCTO #11842]
(From OE-Core rev: c787dcdd55bc55c6c64dec21b251706615114fe7)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* also add UVESA_MODE variable for easier change of resolution and respect it in QB_KERNEL_CMDLINE_APPEND
as well
* don't use init script just to call modprobe
* I wasn't able to test this all the way with runqemu, because runqemu
doesn't work on my system, but I've verified that the right params
appear there and that I can easily change UVESA_MODE from
conf/local.conf, the modules.d and modprobe.d files look OK:
OE qemux86@ ~/build/oe-core/tmp-glibc/deploy/images/qemux86/core-image-sato-qemux86-20170427212613.rootfs
$ cat etc/modules-load.d/uvesafb.conf
uvesafb
OE qemux86@ ~/build/oe-core/tmp-glibc/deploy/images/qemux86/core-image-sato-qemux86-20170427212613.rootfs
$ cat etc/modprobe.d/uvesafb.conf
options uvesafb mode_option=1600x1200-32
so I'll be able to drop this KERNEL_MODULE_AUTOLOAD +
KERNEL_MODULE_PROBECONF from my DISTRO conf.
(From OE-Core rev: f7ba5b5f76bb5678ca3e6ad51586f25871f7a9fb)
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>
Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:
Incompatible processor. This Qt build requires the following features:
ssse3
We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.
Fix this by making the qemu -cpu arguments match the built artifacts.
(From OE-Core rev: 20b3574749420a1fef2cb2e0579584453dd4c5c5)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
No functional changes, just use a consistent set of comments to
separate hard and soft float tuning options.
(From OE-Core rev: 4aa6cdfe9f069ecd976c1257702fe8ff28c57f07)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 4.8 version was removed in:
commit 466e6e45ca04a07ebe1b1f52de747f077b362d54
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Tue Mar 28 08:58:07 2017 -0400
linux-yocto: drop 4.8 recipes
We have 4.1 (LTSI), 4.4 (LTS), 4.9 (LTS/LTSI) and 4.10 available in
master. 4.8 is no longer required, so we drop the recipe to keep
the version selection under control.
* causing each build to start with 188 lines of this stuff:
NOTE: preferred version 4.8% of linux-yocto not available (for item virtual/kernel)
NOTE: versions of linux-yocto available: 4.1.38+gitAUTOINC+7140ddb86e_4d2c95e78c 4.10.5+gitAUTOINC+01f18cba44_b97dcd4f06 4.4.56+gitAUTOINC+271b0c8d51_01aaede0a2 4.9.17+gitAUTOINC+8b97a445fa_3ff3760c2a
NOTE: preferred version 4.8% of linux-yocto not available (for item kernel-module-raid456)
NOTE: versions of linux-yocto available: 4.1.38+gitAUTOINC+7140ddb86e_4d2c95e78c 4.10.5+gitAUTOINC+01f18cba44_b97dcd4f06 4.4.56+gitAUTOINC+271b0c8d51_01aaede0a2 4.9.17+gitAUTOINC+8b97a445fa_3ff3760c2a
(From OE-Core rev: 57357d4e7f5d256a5cc657798f955f1ac8416665)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
