The virtio PCI devices seemed to be required for this machine for some
versions of qemu (based on errors from running qemu saying that the
devices don't exist). Changes to the entries here is all that is needed
to get it working.
(From OE-Core rev: 291940f12c319e74351ff97811919c8c03477c27)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 217deeb43036d1a046d6c5ea2c1ccdb94d3d605a)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch to using virtio graphics for the Arm QEMU machines. You will
noticed the difference in the dmesg by seeing:
[ 2.693337] [drm] pci: virtio-gpu-pci detected at 0000:00:10.0
(From OE-Core rev: 961158653170f53de58672e474c41f1533f469fc)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move all of the tune files found in conf/machine/include into their
respective architecture directories in that same location. All
references to these will need to be updated. So, change the relevant
ones for this tree in this commit as well.
For the ARM tunes, nest them one further into armv8a, armv8m, etc. and
rename some to make them uniform with the rest of the tunes.
(From OE-Core rev: b6f15209bcfff953cce69da97a93f9ddff141ced)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only qemux86* and qemuarm* support SMP with our current configurations so
rework qemu SMP enabling to account for that and only use it on the architectures
where it works.
(From OE-Core rev: ee371325ce651cc113e43bdeb5d8986d5b84a3f4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some platforms do not use ttyS* for their serial consoles (e.g., qemuarm
and qemuarm64). The hardcoding of this can cause issues. Modify
runqemu to use the serial consoles defined in SERIAL_CONSOLES instead of
hardcoding.
(From OE-Core rev: 9dea4cd2f9f46ab3a75562639a22d8f56b4d26af)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I746d56de5669c955c5e29d3ded70c0a4d3171f17
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new runqemu field for VGA devices. Currently, these are being set
in QB_OPT_APPEND, which can make them difficult to override if importing
the config file into another one.
(From OE-Core rev: 695c98b6522be4373806c154a2999eaeef205556)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I8cb9527954c5b06c083c42fe2466cb3338584b7d
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RNG passthru has been enabled on all qemu machines but its being added
to each one of them, with this patch its turned into QB variables which
defaults to host passthru, yet it can be overridden if needed via
machine or config metadata if needed.
(From OE-Core rev: 26dd24506ef36088e17f999ce5489dc4b72194e8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These machines support booting U-Boot, so set the machine appropriately.
(From OE-Core rev: 7dd4100bf00fca0b98b762bb3815b8055f1201f2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Major update after v4.2.
Changes:
- os_find_datadir() was changed after the v4.2 release
causing v5.0 to not find the bios and not boot the
image. Fix is sent to upstream qemu.
See: qemu/find_datadir.patch
- v5.0 binary had host contamination for dynamically linked
libraries, "--extra-ldflags='${LDFLAGS}'" in EXTRA_OECONF
resolved the issue
- bluetooth code was removed: qemu.git$ git show 1d4ffe8dc7
hence removed PACKAGECONFIG[bluez]
- -show-cursor qemu option is now deprecated, updated
scripts/runqemu to use updated option instead
- added PACKAGECONFIG definitions
- added qemu-ptest to conf/distro/include/ptest-packagelists.inc
- increased support for ARM architecture, cpu and board
- removed patches merged upstream and refreshed
existing ones
Testing:
Build core-image-minimal against the machines in
openembedded-core/meta/conf/machine and succesfully
booted with qemu v5.0
Ran qemu-ptest on x86-64 and arm64 with identical results:
PASS: 1166
SKIP: 0
FAIL: 0
(From OE-Core rev: ee9ec9e344541c1ccd9b9b8e3b8c1e00d008ad85)
Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Note that this patch affects qemuarm AND qemuarm64.
When booting a VM and during operation, the following message
periodically appears:
INIT: Id "hvc0" respawning too fast: disabled for 5 minutes
This is because hvc0 is specified in SERIAL_CONSOLES in qemuarm.conf
and qemuarm64.conf, but it is not in /proc/consoles and
SERIAL_CONSOLES_CHECK is not specified, leaving getty to attempt to
enable hvc0. Add SERIAL_CONSOLES_CHECK to both conf files so that
hvc0 isn't enabled if it hasn't been set there or in local.conf.
(From OE-Core rev: 982b7f98b8423236cc986346379b1bde3694f131)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is more appropriate for the machine we are emulating
(From OE-Core rev: b9499c39697593cc392bba47b35f721f5885310c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuarm64 on aarch64 host errors out when using kvm
qemu-system-aarch64: PMU: KVM_SET_DEVICE_ATTR: Invalid argument
qemu-system-aarch64: failed to set irq for PMU
Aborted
machines with GICv3 that don’t support GICv2 guests you must have ‘-machine gic-version=3’ on the QEMU command line.
(From OE-Core rev: 17e93c6464184d137b9590f17bfa879ae79d0cfc)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a discussion about what amount of RAM is appropriate for a
default; the outcome was that for now it is still 256M. Some qemu machine
definitions have however set this to 512M so for the sake of
treating all architectures fairly, they are reset back to 256M.
Also runqemu is adjusted to use 256M if QB_MEM is not set at all.
http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285900.html
(From OE-Core rev: 04c01b6cc5be3e6d45d0e04571640648a5655a8b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows kvm acceleration on arm systems that support it. "host" is the
best option I can find right now to attempt to use the acceleration. It
potentially might not be correct but arm systems are sensitive to the
correct values and I don't want to encode the autobuilders CPU type here.
(From OE-Core rev: f13788541f64774a586971ed57699e4397b38b32)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Beautify the machine config files by making the names and descriptions
more uniform and verbose
(From OE-Core rev: 1108a24e2c58794163c8cf35154f8be5c1d06c29)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure we turn on edid for the VGA display which fixes a hang with the
5.0 kernel for qemuarm64.
Thanks to Jon Mason for the fix.
(From OE-Core rev: c112be9643f9031964be4068feeb5e2f8528c107)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the necessary parts to qemuarm64.conf for graphics to be shown in
the SDL window, and USB so that it is possible to interact with it.
(From OE-Core rev: 7098a0e9115416b2cc1234e86893f8b9337e7849)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add comments describing what is going on, remove an unnecessary space,
remove a duplicate comment, and increase the serial speed.
(From OE-Core rev: d1071579e3896f68b1e4970c1fc9a97b043091e9)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
arch-armv8 does not have many real-world implementations
(From OE-Core rev: 6719de403620dded075dc74f2976669d95bffd7a)
Signed-off-by: Khem Raj <raj.khem@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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
