summaryrefslogtreecommitdiffstats
path: root/meta/conf/machine/include/qemuboot-x86.inc
AgeCommit message (Collapse)Author
2020-09-24qemuboot: Add QB_RNG variableKhem Raj
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>
2020-06-23qemu: uprev v4.2.0 -> v5.0.0Sakib Sajal
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>
2020-02-18qemux86: drop resolution setting via uvesafbAlexander Kanavin
I am not sure if this has ever worked, but uvesafb is a really outdated (VBE from the 1990s), awkward (needs v86d) and limited (no support for high resolutions) way to do it. The specific reason 640x480-32 was introduced (ages ago) was to force 32 bit mode with vmware driver, as 16bit had rendering issues. The modern, supported option is video=... kernel parameter documented here: https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst which can be passed directly to runqemu and doesn't require special kernel modules. Sato under X will continue to use 640x480 as that is hardcoded into xorg.conf under qemu. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-02-18qemux86: do not add vga=0 to kernel parametersAlexander Kanavin
This was added ages ago to enable GL passthrough with vmware driver, and is no longer relevant, as std or virgl is used instead nowadays. Original commit: commit 072545b1111c5efb66289a4866897429f5fcd969 Author: Richard Purdie <rpurdie@linux.intel.com> Date: Wed Jan 21 17:40:51 2009 +0000 scripts/poky-qemu-internal: Add support for GL passthrough in qemux86 images Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-08-30qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mipsAlexander Kanavin
This is the qemu default since qemu 2.2, is generally supported better, and is recommended by upstream. It also has already been in use for arm/risc and ovmf. Additional information: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466 https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ '-vga virtio' emulated hardware remains in use when virgl is enabled via a runqemu override. Also, adjust the error whitelist, as there is a number of new messages coming from the drivers that are not actual errors. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-08-07qemuboot-x86: move QB_SYSTEM_NAME to corresponding confChangqing Li
Configrations: MACHINE: qemux86-64 require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" Reproduce steps: bitbake lib32-core-image-minimal runqemu qemux86-64 nographic lib32-core-image-minimal Errors: qemu cannot bootup since: Booting from ROM... This kernel requires an x86-64 CPU, but only detected an i686 CPU. Unable to boot - please use a kernel appropriate for your CPU. QEMU: Terminated For lib32 image, override has x86, so the qemubin set to qemu-system-i386, fix by move QB_SYSTEM_NAME to corresponding conf, don't use the override Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-17qemux86: use a Core 2 Duo CPU instead of the original circa-1993 PentiumAlexander Kanavin
This matches what the qemux86_64 is currently using, and will allow testing the instructions added in the meantime; particularly various SSE extensions are now enabled. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-11-13machine/qemu*: fix kernel finish crng init more and more slowlyHongxu Jia
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>
2017-09-13qemu conf: Fix kernel module autoloading for uvesafb on genericx86Alejandro Hernandez
After commit e8b1c653946ef921b65d47e52aea0dc530ef4286, 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: 6af89812e8a9931ffed63768ed85367519bf7aef 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) 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>
2017-08-19qemu conf: replace deprecated option with new optionChen Qi
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 Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-28v86d, qemuboot-x86.inc: use KERNEL_MODULE_AUTOLOAD+KERNEL_MODULE_PROBECONF ↵Martin Jansa
for uvesafb instead of fbsetup init script * 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. Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-06-23qemuboot.conf: make cpus match built artifactsMartin Kelly
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. 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>
2017-01-23runqemu: fixes for slirp, network device and hostfwdRobert Yang
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>
2016-11-06runqemu: add user mode (SLIRP) support to x86 QEMU targetsTodor Minchev
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" Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-09-27machine/qemu*: Add comment regarding the reason for virtio-rng-pciNathan Rossi
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>
2016-09-23runqemu: Move virtio RNG to machine configurationNathan Rossi
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>
2016-09-16qemuboot-x86: Add task_timeout = -1 to uvesafbSaul Wold
This causes the default timeout to be set to infinity, it will still report out every 5000 milliseconds Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-09qemux86.conf/qemux86-64.conf: set vars for runqemuRobert Yang
Add qemuboot-x86.inc to reduce duplicated code, the x86/x86_64 bsps which can be boot by runqemu can require qemuboot-x86.inc. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-06-05 16:34:29 +0000