linux/poky.git/meta/conf/machine/include/qemuboot-mips.inc, branch 3.5_M2

conf/machine: move tune files to architecture directories

2021-08-18T16:01:06+00:00

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 Signed-off-by: Richard Purdie

runqemu: add QB_GRAPHICS

2021-03-11T14:00:36+00:00

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 Change-Id: I8cb9527954c5b06c083c42fe2466cb3338584b7d Signed-off-by: Richard Purdie

qemuboot: Add QB_RNG variable

2020-09-24T21:32:49+00:00

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 Signed-off-by: Richard Purdie

qemu: uprev v4.2.0 -> v5.0.0

2020-06-23T11:31:03+00:00

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 Signed-off-by: Joe Slater Signed-off-by: Richard Purdie

qemumips: use std vga instead of cirrus vga

2020-02-21T09:39:00+00:00

This is what the upstream recommends nowadays: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ I have verified that both X and weston continue to boot and look right; however xorg.conf file needs to be removed as it is cirrus specific and doesn't work and isn't needed with std vga. (From OE-Core rev: 96e6434239268fd0fc021bda9c8fedd998597097) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemuboot-mips: Enable cirrus VGA device

2020-01-16T22:33:08+00:00

This helps in booting weston images ( core-image-weston ) with fbdev backend, without this westons initialization of fbdev backend fails because it does not get correct frame buffer settings and exits pre-maturely (From OE-Core rev: d95b03ae45b36a9b127ef639322e61b21c328d87) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mips

2019-09-01T21:33:07+00:00

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. (From OE-Core rev: 73cb104f3307736f4922f2e0c9648f9b2d3b3b6b) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemu: set default RAM to 256M for all machines

2019-08-30T16:10:28+00:00

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 Signed-off-by: Richard Purdie

qemumips/qemumips64: move QB_SYSTEM_NAME to corresponding conf

2019-08-22T21:48:26+00:00

Configuration: MACHINE = qemumips64 bitbake lib32-core-image-minimal runqemu slirp nographic qemumips64 ext4 Error: ERROR - Failed to run qemu: qemu-system-mips: unable to find CPU model 'MIPS64R2-generic' Fixed by moving QB_SYSTEM_NAME to Respective configuration file (From OE-Core rev: e724e8836ed614ff8eaa0d0d9c51d22ee62576b3) Signed-off-by: Changqing Li Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

machine/qemu*: fix kernel finish crng init more and more slowly

2018-11-14T11:14:40+00:00

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 Signed-off-by: Richard Purdie