Fixed:
- Add QB_NETWORK_DEVICE to set network device, it will be used by both
slirp and tap.
- Set QB_NETWORK_DEVICE to "-device virtio-net-pci" in qemuboot.bbclass
but runqemu will default to "-device e1000" when QB_NETWORK_DEVICE is
not set, this is because oe-core's qemu targets support
virtio-net-pci, but the one outside of oe-core may not,
"-device e1000" is more common.
- Set hostfwd by default: 2222 -> 22, 2323 -> 23, and it will choose a
usable port when the one like 222 is being used. This can avoid
conflicts when multilib slirp qemus are running. We can forward more
ports by default if needed, and bsp.conf can custom it.
- Use different mac sections for slirp and tap to fix conflicts when
running both of them on the same host.
[YOCTO #7887]
CC: Nathan Rossi <nathan@nathanrossi.com>
CC: Randy Witt <randy.e.witt@linux.intel.com>
(From OE-Core rev: 7dddd090806914a62d977730440d803e48f44763)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A follow-up of a fix introduced in
1b32c6ed02 (selftest: wic: fix test_qemu).
Wic test_qemu fails on qemux86 due to a direct assignment of WKS_FILE in machine
configuration. Using default assignment allows WKS_FILE to be overwritten in
test setup.
(From OE-Core rev: 9afaeadb37b2b2fab935755ab570cf4b1f3195f4)
Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use weak assignment for SERIAL_CONSOLES in qemu configuration files so that
the value could serve as a default value and could be easily overridden in
configuration files like local.conf.
When using the default value for SERIAL_CONSOLES in qemux86-64,we would have
annoying messages on console complaining about respawning getty on ttyS1.
Although the value is set by purpose, at least we need to provide an easy way
to override it.
(From OE-Core rev: 5f060b66162c41a295995947b918253450870117)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting WKS_FILE variable in qemux86-64 made wic test to
use wrong wks file to produce an image and resulted in
test_qemu failure.
Used conditional assignment in qemux86-64 and explicitly
set WKS_FILE in wic testing suite to make the suite to use
wic-image-minimal.wsk. This should fix test_qemu failure.
(From OE-Core rev: 3bca4d18c2712e3b154bacfb917f0a749ebaddeb)
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>
While I couldn't find explicit documentation, it appears
that the list of MACHINEOVERRIDES should be sorted from
less specific to more specific left to right, so that
more specific overrides take precedence.
(From OE-Core rev: 59c724db5628775e77fa090183897c6ae0fdf9a8)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set directdisk.wks as default wks to use for qemux86 machines.
Set requried dependeincies to build directdisk image.
This should simplify building wic images for qemux86* machines.
It should be enough to add wic to the list of IMAGE_FSTYPES to get
the images built.
[YOCTO #10637, YOCTO #8719]
(From OE-Core rev: 8716b8b9be05e3f140bfa426a8e0d4eeaa2edcbe)
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>
Fixed:
$ runqemu qemuarm64 (without -nographics)
There is no output in qemu console without this fix.
(From OE-Core rev: 40a64e64b2ff41661ff254d0836c5f60120c6795)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some cases, each MIPS variant in a recipe requires a duplicate
line. Even if the passed flag is the same.
Add global MACHINEOVERRIDES variables for the following
* mipsarch : All MIPS
* mipsarch{eb,el} : All MIPS Big/Little Endian
* mipsarchr6 : All MIPS R6
* mipsarcho32 : All MIPS o32 Endian Independent
* mipsarchn32 : All MIPS n32 Endian Independent
* mipsarchn64 : All MIPS n64 Endian Independent
* mipsarcho32{eb,el} : All MIPS o32 Big/Little Endian
* mipsarchn32{eb,el} : All MIPS n32 Big/Little Endian
* mipsarchn64{eb,el} : All MIPS n64 Big/Little Endian
This is intended to reduce duplications in recipes
[YOCTO #10404]
(From OE-Core rev: 0d2205f26e5ece089630f72af2bd5f0931e851c3)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using 'slirp' as a command line option to runqemu will start QEMU
with user mode networking instead of creating tun/tap devices.
SLIRP does not require root access. By default port 2222 on the
host will be mapped to port 22 in the guest. The default port
mapping can be overwritten with the QB_SLIRP_OPT variable e.g.
QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
(From OE-Core rev: 80e6fc678f3dcd774d9376cdf2a6afcba2cd0b09)
Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't install legacy X input drivers for any machines by default,
RRECOMMEND xf86-input-libinput instead.
This is the setup suggested by upstream: install only libinput by
default, but let niche legacy drivers sort higher in configuration
so they get chosen if installed. So the order is:
evdev < libinput < (synaptics|vmmouse|...)
This also removes vmmouse X driver from the qemu config. If a VMware
virtual mouse device really needs to be supported, we should enable
CONFIG_MOUSE_PS2_VMMOUSE in kernel instead: that is directly supported
by the libinput X driver.
Fixes [YOCTO #10195].
(From OE-Core rev: 2d005faff6341a81a2afae28860101ba9db51ae8)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
MACHINE = "qemumips64"
DEFAULTTUNE = "mips64-o32"
$ bitbake linux-yocto
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 contains duplicates. The following archs are listed more than once: mips64-o32
(From OE-Core rev: e57d70e6803c63823ae3a7c7971fc06db3748b68)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This update will avoid confusion with other parts of OE-Core that
set the kernel version to 4.8 for qemux86* and genericx86*.
(From OE-Core rev: 7f8c36d8aa00da109e842c790c6a0ab7a849de72)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS Release 6 ISA and the various tune
configurations.
This patch adds the tunes for 32r6 and 64r6 n64 and not the n32
variants at the moment.
Release 6 onwards, the tuples are now
- mipsisa32r6-linux-gnu
- mipsisa32r6el-linux-gnu
- mipsisa64r6-linux-gnuabi64
- mipsisa64r6el-linux-gnuabi64
- mipsisa64r6-linux-gnuabin32
- mipsisa64r6el-linux-gnuabin32
For more details, check https://wiki.debian.org/Multiarch/Tuples
(From OE-Core rev: 6b2e0c60c3222a13b33284f258d5c340222d759f)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bring across the comment that was in runqemu regarding why the
virtio-rng-pci device was needed. This comment is added to each location
where the virtio-rng-pci device is added.
(From OE-Core rev: bc5d1fdea674e842e4b0c45b38782930ec133051)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The QEMU usermode fails with invalid instruction error when used with those tunes.
The issue is being tracked in [YOCTO: #10304].
(From OE-Core rev: f9fd1a7fdf03ade9735e137a526a54e723d03dc6)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not all QEMU machines (outside of those available in OE-Core) are
capable of using the virtio-rng-pci device due to various machine models
not having a pci/virtio bus. This makes it such that the use of the
'-device virtio-rng-pci' flag to QEMU is machine specific.
This patch removes the general addition of the flag to all runqemu
targets and adds the flag into the QB_OPT_APPEND for all the qemu*
machines in OE-Core that support its use (which is all of them).
(From OE-Core rev: e890c05e66a21702e9e8ccce794b74cb7f5518ed)
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 causes the default timeout to be set to infinity, it will still report out
every 5000 milliseconds
(From OE-Core rev: fd9e1ba8f70402bd3c4b873d349057f96f5bcb19)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current qemu instances all share the same MAC address. This shouldn't be an
issue as they are all on separate network interfaces, however on the slight
chance this is causing problems, its easy enough to ensure we use unique
MAC addresses based on the IP numbers we assign.
(From OE-Core rev: c01962bf88786dd84ad83cc1d315297607d29f7c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuppc can use virtio networking and we may as well do so for better
prformance as we do under the other emulated hardware.
(From OE-Core rev: 8a82ded799be79eacb64cf313b6f2799a4f5ffab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add qemuboot-mips.inc to reduce duplicated code, the various mips bsps
which can be boot by runqemu can require qemuboot-mips.inc
(From OE-Core rev: cb28128477e98ed7dc7a90dd197f6dd04cf75be0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add qemuboot-x86.inc to reduce duplicated code, the x86/x86_64 bsps
which can be boot by runqemu can require qemuboot-x86.inc.
(From OE-Core rev: b5ff3dda2a576ba7e5d68198ea6c6eb49cf80eb8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base_version_less_or_equal() will raise errors if
PREFERRED_VERSION_linux-yocto is None. For example, when we build
DISTRO = "nodistro", PREFERRED_VERSION_linux-yocto is not be defined
since it is defined in poky.conf, and then bitbake will
choose the higher version which is 4.8 currently, so set
PREFERRED_VERSION_linux-yocto to 4.8, otherwise, runqemu can't boot it.
(From OE-Core rev: fd31e30f97ee9bd128d5b7b748987b0a6427b279)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For kernels after 4.7, we need to ensure the DTB file for the kernel is
used by runqemu. Doing this conditionally based upon the kernel verison
being built seems to be the only way forward for this.
(From OE-Core rev: 4615764509234bfb206ffe4cd430653b88d46ec3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QEMU usermode doesn't support n32 binaries, erroring with "Invalid
ELF image for this architecture".
(From OE-Core rev: 66aa39a959bd41f7063fe64a9225eb9fd6c3293b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The core emulated by default by qemu-mips(el) just crashes with
illegal instruction when encountering DSP and/or MIPS16e
instructions - we have to specify a CPU that supports the extra
instructions.
This is an issue when generating a rootfs and e.g. running some
of the package postinstall scriptlets.
The patch to qemu to add 24KEc as a CPU has been accepted
upstream, so let's use that CPU here as well as needed.
(From OE-Core rev: 8af17075f56241dd8f3ea86c609adbd73f248218)
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>
Currently the -mcpu parameter is not passed to cross gcc when assembling
kernel .S file, the implicit -mcpu option that defaults to the latest
server cpu might casuse incorrect assembling.
A existent case is that wait instruction of ppce500mc is incorrectly assembled
to power9 version with default -mcpu setting, accordingly kernel boot calltrace
happend when wait instruction is executed on ppce500mc targets.
(From OE-Core rev: b17f91ed06a604e3d356fe17756bfe2ca61594b7)
Signed-off-by: Zhenhua Luo <zhenhua.luo@nxp.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- add 24kc big and little endian, which is based on mips32r2 w/o FPU
- add 24kec which is 24kc + DSP
- both can have the MIPS16e ASE enabled in their tunes
(From OE-Core rev: cccd8b09523d8f0c1df97d08181737681db13f37)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The MIPS16e instruction set still has to be enabled by setting
MIPS_INSTRUCTION_SET = 'mips16e'
in e.g. distro.conf and can be disabled on a per-recipe basis as
needed.
This is a similar approach as is available on ARM for Thumb support.
Note that contrary to the ARM Thumb support in OE, we do add a new
OVERRIDE (mips16e), as there are some recipes in OE that need to be
compiled slightly differently if mips16e mode is requested.
(From OE-Core rev: e9d8b02a42eb08802e202770409cb5378b79b281)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
