| Age | Commit message (Collapse) | Author |
|---|
|
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.
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.
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
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.
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
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.
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
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Beautify the machine config files by making the names and descriptions
more uniform and verbose
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
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.
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.
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.
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
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
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>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
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.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Fixed:
$ runqemu qemuarm64 (without -nographics)
There is no output in qemu console without this fix.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
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).
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Robert Yang <liezhi.yang@windriver.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).
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
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.
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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]
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Khem Raj
Ross Burton
Sakib Sajal
Trevor Gamblin
Alexander Kanavin
Richard Purdie
Jon Mason
Bruce Ashfield
Hongxu Jia
Robert Yang
Chen Qi
Nathan Rossi
Andre McCurdy
Randy Witt
Kai Kang