summaryrefslogtreecommitdiffstats
path: root/scripts/runqemu
Commit message (Collapse)AuthorAgeFilesLines
* runqemu: Add workaround for APIC hang on pre 4.15 kernels on qemux86Richard Purdie2018-01-021-0/+5
| | | | | | | | | | | | On pre 4.15 host kernels, an APIC window emulation bug can cause qemu to hang. On 64 bit we can use the x2apic, for 32 bit, we just have to disable the other timer sources and rely on kvm-clock. [YOCTO #12301] (From OE-Core rev: 82e67b82ea8e12aa0b7b9db1d84fec0436dec71b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Allow the user to override the device tree optionAlistair Francis2017-12-021-1/+14
| | | | | | | | | | | | | | | | Update the runqemu script to allow the user to specify a device tree to boot when calling runqemu. This involves creating a seperate check_dtb() function incase the user has specified 'none' for the kernel but still wants a device tree. (From OE-Core rev: 867ac1370b294bfd1ee31f94abb63688f77081a1) Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Ben Levinsky <ben.levinsky@xilinx.com> Cc: Ben Levinsky <ben.levinsky@xilinx.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Allow the user to override the Kernel optionAlistair Francis2017-12-021-1/+5
| | | | | | | | | | | | Update the runqemu script to allow the user to specify a Kernel to boot when calling runqemu. (From OE-Core rev: eaf2793a98cb27d82561da0f8993f2b4b304ecc2) Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Cc: Ben Levinsky <ben.levinsky@xilinx.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: print command search result when not foundRobert Yang2017-11-301-0/+3
| | | | | | | | | | This makes debug easier. (From OE-Core rev: a453639e19fb2a9f9fb63fddd0b3ee26c0116d91) 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>
* runqemu: Also specialcase resolution of '.' to the file's locationRichard Purdie2017-11-211-0/+2
| | | | | | | | | Similarly to handling "../", handle "." to resovle to the qemuconf file's current directory. (From OE-Core rev: 33418ed064fe9cff5b4803f09135a81d9170c189) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Improve relative path handling in qemuconf filesRichard Purdie2017-11-211-0/+2
| | | | | | | | | | | If a variable starts with "../", its likely its a path and we want to set it to an absolute path relative to the qemuconf file. This means we don't have to use bitbake as often to figure out variables. (From OE-Core rev: dfc7940900d798aa47716288338107e1d46a3972) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Ensure we process all tap devicesRichard Purdie2017-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | The regexp in the script misses some tap devices, e.g. we see output like: runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap25.lock failed: [Errno 11] Resource temporarily unavailable runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap26.lock failed: [Errno 11] Resource temporarily unavailable runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap27.lock failed: [Errno 11] Resource temporarily unavailable runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap28.lock failed: [Errno 11] Resource temporarily unavailable runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap40.lock failed: [Errno 11] Resource temporarily unavailable runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap41.lock failed: [Errno 11] Resource temporarily unavailable What happened to tap29 to tap39? The issue is was we were missing devices with '0' in the number, like "10:" and so on in the output from "ip link". (From OE-Core rev: 6447697a48e3b693ee38806bc2ba07c2a65c2bc8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: correct rootfs setup to boot an ide hddimgThomas Perrot2017-11-071-1/+1
| | | | | | | | | vm_drive variable is malformed when the drive type is an ide device. (From OE-Core rev: 88d7b17871fe8340ab7fd5c901d3a535ae098c3e) Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Add riscv support for qemu machinesKhem Raj2017-11-051-0/+4
| | | | | | | | (From OE-Core rev: bfdebfdfc974220fa2893eddbfc966bbc0761d4c) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: Don't print error messages about tap file locksRichard Purdie2017-08-301-3/+7
| | | | | | | | | | | | Errors like: runqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable are not really fatal errors. Change these to info messages instead so people look later in the log for the real errors. (From OE-Core rev: fac12de72bda1e864e71538be07d6c6f6e987498) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Use virtio to mount cdrom drivesRichard Purdie2017-08-231-1/+1
| | | | | | | | | | The IDE driver in the kernel is fragile and in 4.12 is causing backtraces. To unblock 4.12 kernel merging use the virtio CD driver instead to mount iso images which should be faster and more stable. (From OE-Core rev: f59e729f98ef9b506b0cfdc415567e03ec87f2a9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD typesTom Rini2017-07-301-3/+6
| | | | | | | | | | | | | | | | | The vmdk/vdi/qcow2 IMAGE_FSTYPEs predate wic. As such, they provide some similar underlying functionality in order to produce a "disk" image that in turn can be converted into different formats that various hypervisor types work with. They do not however provide the ability for other disk image types to be converted into these same output types. Furthermore, they are less flexible than what wic does provide. This drops the old style vmdk/vdi/qcow2 types and re-introduces them under the CONVERSION_CMD framework. The equivalent of vmdk is now wic.vmdk and so forth for the other types. (From OE-Core rev: 929ba563f1bc7195c4981b8e139c432b2cc388ea) Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: chmod 0o777 for lockdirRobert Yang2017-07-271-0/+1
| | | | | | | | | | | | | Multi-users may run qemu on the same host, all of them should be able to create or remove lock in lockdir, so set lockdir's mode to 0o777. Note, os.mkdir()'s mode is default to 0o777, but the current umask value is first masked out, so use os.chmod() to set it. (From OE-Core rev: 4a5d21dbdc88982c2c90e660811b84983eaebeb7) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: validate combosRobert Yang2017-07-271-0/+6
| | | | | | | | | | | | | | | Error out ealier if the combos is invalid, e.g.: $ runqemu tmp/deploy/images/qemux86/bzImage-qemux86.bin tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic This will fail at kernel panic, no we check and error out early. We can add other checkings in the future. [YOCTO #11286] (From OE-Core rev: 8c6f253dfb4899324e91dd5d082190909e2bd25d) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: check tar.bz2 and .tar.gzRobert Yang2017-07-271-1/+4
| | | | | | | | | | | | Handle them as nfs, so that cmd like the following can be boot: $ runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.tar.bz2 [YOCTO #11286] (From OE-Core rev: 552093d1f60ca335d95bcfc9d6070ec551ebe6c0) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: check qbconfload before running bitbakeRobert Yang2017-07-271-1/+1
| | | | | | | | | | If qbconfload (.qemuboot.conf is found) is present, we can get DEPLOY_DIR_IMAGE from it rather than "bitbake -e". (From OE-Core rev: 89e97033a8a27a695567c321ed0ebf17f23f8d9b) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add --debug and --quietRobert Yang2017-07-271-19/+31
| | | | | | | | | | | | | | | And move some debug info into logger.debug(), this can make it easy to read key messages like errors or warnings. I checked meta/lib/oeqa/ they don't depend on these messages. And I have run "oe-selftest -a", it doesn't break anything. [YOCTO #10474] (From OE-Core rev: e696425e7627edada128b40304fddc84d8d56ba7) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: check exit code of 'ls -t'Ed Bartosh2017-07-171-1/+4
| | | | | | | | | | | | | | | Used check_output instead of Popen as it raises CalledProcessError exception when command exits with non-zero exit code. Catched the exception to produce user-friendly output. [YOCTO #11719] (From OE-Core rev: dac68d2323b0b630c019ce4d5256ed567eaf00da) 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>
* runqemu: reworked exception handlingEd Bartosh2017-07-171-57/+56
| | | | | | | | | | | | | | | | | | | | | | | Introduced custom RunQemuException that script raises on known errors. This exception is handled in one place and prints error output without printing Python traceback. This shoud make error output less scary for the end user. Handling of unknown errors has not been changed - both error and traceback will be printed. Reimplemented OEPathError exception code to handle it similarly to RunQemuException. Moved exception handling code into main() to keep it in one place. [YOCTO #11719] (From OE-Core rev: a779a382b66e7b43ac53286758b4370dc14b193b) 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>
* runqemu: drop RPC portsRobert Yang2017-06-281-6/+2
| | | | | | | | | | | | | | | | | | | The following commit has removed rpc ports from runqemu-export-rootfs, so runqemu should also remove them, otherwise "runqemu nfs" doesn't work. And use abspath for nfsroot, otherwise it doesn't work when it is a relative path. commit 6bb9860ef7ba9c84fe9bd3a81aa6555f67ebd38e Author: Cody P Schafer <dev@codyps.com> Date: Tue Jun 6 18:30:49 2017 -0400 runqemu-export-rootfs: don't change RPC ports [YOCTO #11687] (From OE-Core rev: d7c5c9344de6974997c39097a7767ec338c3cca3) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: change terminal settings for valid tty'sMikko Ylinen2017-06-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | runqemu uses stty to change terminal settings to give users better control to qemu. However, stty does not work when runqemu is run directly or indirectly via oe-selftest in a Docker container (presumably some problems with Docker's pseudo-tty implementation). The error reported is: stty: 'standard input': Inappropriate ioctl for device As runqemu recently moved to subprocess.check_call() for stty calls we now get thrown an error and all runqemu runs fail. sys.stdin.isatty() does proper job in detecting if the stty calls can work so we use that check before running the stty subprocess operations. (From OE-Core rev: 06742ed59092530aedf03f65c3c9542c24ff7ac3) Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: Fix return value checks from subprocess.call()'sMikko Rapeli2017-06-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Python function subprocess.call() returns the return value of the executed process. If return values are not checked, errors may go unnoticed and bad things can happen. Change all callers of subprocess.call() which do not check for the return value to use subprocess.check_call() which raises CalledProcessError if the subprocess returns with non-zero value. https://docs.python.org/2/library/subprocess.html#using-the-subprocess-module All users of the function were found with: $ git grep "subprocess\.call" | \ egrep -v 'if.*subprocess\.call|=\ +subprocess\.call|return.*subprocess\.call' Tested similar patch on top of yocto jethro. Only compile tested core-image-minimal on poky master branch. (From OE-Core rev: 031cf9c7834cd1cba8b03832673a3e3cfcbfae7c) Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: output qemu-system errorsEd Bartosh2017-05-291-3/+4
| | | | | | | | | | | | Included error output from qemu-system into the runqemu error message. Made error output more visible by printing new line before it. [YOCTO #11542] (From OE-Core rev: 7fe5f5c29ca271ab718bbd1383e596f2ae61554c) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Automatically add a TFTP directory for slirp bootAlistair Francis2017-05-161-1/+1
| | | | | | | | | | | When booting QEMU with slirp networking we want to use QEMUs TFTP server to make the images in deploy accessible to the guest. (From OE-Core rev: a6bef2fa065f8bb74d0084e44dd0ca47d7859113) Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support virtio drive typePatrick Ohly2017-04-291-6/+9
| | | | | | | | | | | | | Setting QB_DRIVE_TYPE=/dev/vd selects virtio without triggering any warnings. Previously, that was only possible by setting an unknown value and relying on the fallback to virtio, which caused some warnings to be printed. (From OE-Core rev: 5cbf102662dde6f706a19fa133cfd1e7475eb8c1) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix incorrect calls to get variable valuesPaul Eggleton2017-04-191-2/+2
| | | | | | | | | | | We were specifying a default parameter; the get() function defined here does not take such a parameter. I appears this code had not been tested. This fixes runqemu erroring out immediately when used within the eSDK. (From OE-Core rev: e4548531112c824653ae42b9bcc335a7ca8588e0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: use bindir_native property to run ifup/down scriptsEd Bartosh2017-04-131-2/+2
| | | | | | | | | | | | | Used self.bindir_native to point out to the native sysroot when running runqemu-ifup and runqemu-ifdown scripts. [YOCTO #11266] [YOCTO #11193] (From OE-Core rev: cc5513bf7a6114e14bb307acb88a44e9cf0aed8a) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add bindir_native propertyEd Bartosh2017-04-131-13/+24
| | | | | | | | | | | | | Isolated logic of getting path to native bin directory in new bindir_native property method. This property is going to be used to obtain location of qemu-sytem and tunctl. (From OE-Core rev: 26e97f7ebb7e3302e3d3c6646fb58baf395d62be) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: get qemu from qemu-helper-native sysrootEd Bartosh2017-04-131-1/+12
| | | | | | | | | | | | | If rm_work is enabled image native sysroot can be removed. This makes runqemu to fail trying to find qemu binary. Used native sysroot of qemu-helper-native to find system qemu binary. (From OE-Core rev: d42c02caaa4d6fb47681aa7ffe8b27fa38141e6a) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: use self.rootfs to replace self.nfs_dirRobert Yang2017-04-121-15/+13
| | | | | | | | | | | We can use self.rootfs as self.nfs_dir when self.fstype is nfs, this can reduce the code's complexity and we can re-use the code of checking ROOTFS conflictions. (From OE-Core rev: 1aafa13ae6faf620acac7338c42a8838e75da6b9) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: do not rely on grepping imagesRobert Yang2017-04-121-8/+11
| | | | | | | | | | | | | Fixed when the image is large and not enough memory: grep: memory exhausted Aborted [YOCTO #11073] (From OE-Core rev: a99deb30a0138594147ae28aab016fe4b74b8959) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: run without argumentsRobert Yang2017-04-121-2/+2
| | | | | | | | | | Since we can get MACHINE and others from env vars and "bitbake -e", "runqemu" can work without any arguments. (From OE-Core rev: 9ebcb2b6f41420ae3686afad03bb26a68cfacf95) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support env vars explicitlyRobert Yang2017-04-121-29/+42
| | | | | | | | | | | | | Use self.env_vars to support get vars from environment explicity. The MACHINE, ROOTFS and KERNEL was supported by shell based runqemu, and the help text says support them from env vars, so add them back. [YOCTO #11141] (From OE-Core rev: 20008d0bfe2cacecba77e11b0a0faf3d959eaf1e) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: use realpath for imgdirRobert Yang2017-04-101-2/+2
| | | | | | | | | | | The DEPLOY_DIR_IMAGE maybe relative or absolute path since it can be read from env vars, so use realpath for both imgdir and DEPLOY_DIR_IMAGE when compare. (From OE-Core rev: dad9f27278850d0d3818344fea877835632576cb) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix 2 typosRobert Yang2017-04-101-2/+2
| | | | | | | | | | * "is it" -> "it is" * Remove "<image>.qemuboot.conf =" in the error message which looked strange. (From OE-Core rev: a6152dd9f6f4e17855548ceffa8d864855a67f5c) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: output network configurationEd Bartosh2017-03-221-1/+3
| | | | | | | | | | | | | | | | | | | | runqemu adds network configuration parameters to the kernel command line to configure guest networking. This works only for the images that run with external kernel using qemu -kernel parameter. It doesn't work for the images that use bootloader to boot kernel as -kernel parameter is not used and network configuration is not possible to get. Added host and guest ip addresses and netmask of tap link to the runqemu output. This should allow external programs that execute runqemu to get network configuration. [YOCTO #10833] (From OE-Core rev: cf66a1850677548aa63a54276fa4917f40259daf) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: only boot ramfs when specifiedRobert Yang2017-03-171-1/+9
| | | | | | | | | | | | | | | | This can fix a problem: IMAGE_FSTYPES += "iso" $ bitbake core-image-minimal $ runqemu qemux86 It may boot core-image-minimal-initramfs rather than core-image-minimal, this is not what we want usually. This patch makes it avoid booting ramfs when there are other choices, or when it is specified, for example, "runqemu qemux86 ramfs" (From OE-Core rev: 614bde6774f4dfd414066bbaf75ed422943e37ab) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add -h and --helpRobert Yang2017-03-161-2/+3
| | | | | | | | | | | | | | | | Fixed: $ runqemu -h runqemu - INFO - Assuming MACHINE = -h runqemu - INFO - Running MACHINE=-h bitbake -e... [snip] Exception: FSTYPE is NULL! [YOCTO #10941] (From OE-Core rev: 6b9dd7a589537b12da648be50298cf7d36461797) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: improve when no machine specifiedRobert Yang2017-03-161-0/+6
| | | | | | | | | | | | | | | | | Fixed: $ runqemu core-image-minimal [snip] Exception: FSTYPE is NULL! [snip] Get DEPLOY_DIR_IMAGE from "bitbake -e" to make it work. [YOCTO #10471] (From OE-Core rev: ca551b72a020782f164703765b97156000b908d2) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: independent network and rootfs setupJuro Bystricky2017-03-161-0/+4
| | | | | | | | | | | | | Presently, runqemu sets up rootfs as part of network setup. In case there is no network desired we will end up without rootfs as well. This patch sets up network and rootfs independently. It is also possible to bypass setup of rootfs if QB_ROOTFS is set to "none". (From OE-Core rev: 006ab8c6bcfe9d065c215cab15289357cefc9259) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: avoid overridden user input for bootparamsDmitry Rozhkov2017-03-041-2/+5
| | | | | | | | | | | | | | | | | | | | | Currently runqemu hardcodes the "ip=" kernel boot parameter when configuring QEMU to use tap or slirp networking. This makes the guest system to have a network interface pre-configured by kernel and causes systemd to fail renaming the interface to whatever pleases it: Feb 21 10:10:20 intel-corei7-64 systemd-udevd[201]: Error changing net interface name 'eth0' to 'enp0s3': Device or resource busy, Always append user input for kernel boot params after the ones added by the script. This way user input has priority over runqemu's default params. (From OE-Core rev: 3f68b5c8d24b52aed5bb3ed970dd8f779b65b1b3) Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: Add always ttyS1 when no serial options are specifiedAníbal Limón2017-03-041-0/+11
| | | | | | | | | | | | | | | | | | We always wants ttyS0 and ttyS1 in qemu machines (see SERIAL_CONSOLES), if not serial or serialtcp options was specified only ttyS0 is created and sysvinit shows an error trying to enable ttyS1: INIT: Id "S1" respawning too fast: disabled for 5 minutes [YOCTO #10491] (From OE-Core rev: 3a0efbbe6bb5a7f0fb3df0f6052b11e56788405f) (From OE-Core rev: ab8d1a73ad5285dbc86352813b24db2adb3c6367) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support UEFI with OVMF firmwarePatrick Ohly2017-03-011-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the simplest case, "runqemu qemux86 <some-image> qcow2 ovmf" for an EFI-enabled image in the qcow2 format will locate the ovmf.qcow2 firmware file deployed by the ovmf recipe in the image deploy directory, override the graphics hardware with "-vga std" because that is all that OVMF supports, and boot with UEFI enabled. ovmf is not built by default. Either do it explicitly ("bitbake ovmf") or make it a part of the normal build ("MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = ' ovmf'"). The firmware file is activated as a flash drive instead of using the qemu BIOS parameters, because that is the recommended method (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it allows storing UEFI variables in the file. Instead of just "ovmf", a full path to an existing file can also be used, just as with the rootfs. That may be useful when making a permanent copy of the virtual machine data files. It is possible to specify "ovmf*" parameters more than once, then each parameter creates a separate flash drive. This way it is possible to use separate flash drives for firmware code and variables: $ runqemu qemux86 <some-image> qcow2 ovmf.code ovmf.vars" Note that rebuilding ovmf will overwrite the ovmf.vars.qcow2 file in the image deploy directory. So when the goal is to update the firmware while keeping variables, make a copy of the variable file and use that: $ mkdir my-machine $ cp tmp/deploy/images/qemux86/ovmf.vars.qcow2 my-machine/ $ runqemu qemux86 <some-image> qcow2 ovmf.code my-machine/ovmf.vars.qcow2 When Secure Boot was enabled in ovmf, one can pick that instead of the non-Secure-Boot enabled ovmf.code: $ runqemu qemux86 <some-image> qcow2 ovmf.secboot.code my-machine/ovmf.vars.qcow2 (From OE-Core rev: b91fc0893651b9e3069893e36439de0b4e70ad13) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: also accept -image suffix for rootfs parameterPatrick Ohly2017-03-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | The magic detection of the rootfs parameter only worked for image recipes which embedd the "image" string in the middle, as in "core-image-minimal". Sometimes it is more natural to call an image "something-image". To get such an image detected by runqemu, "-image" at the end of a parameter must also cause that parameter to be treated as the rootfs parameter. Inside the image directory, "something-image" has an -<arch> suffix and thus no change is needed for those usages of re.search('-image-'). However, while at it also enhance those string searches a bit (no need for re; any()+map() a bit closer to the intended logic). (From OE-Core rev: ca0fad3ad9d75d4198388b2a3133326267fc58db) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix undefined variable reference in check_arg_path()Patrick Ohly2017-03-011-1/+1
| | | | | | | | | | | | | | | | 'arg' isn't defined, the right name there is 'p'. This fixes a rather obscure error message when that code path ends up being taken: $ runqemu some/existing-file-name runqemu - ERROR - name 'arg' is not defined runqemu - ERROR - Try 'runqemu help' on how to use it (From OE-Core rev: 3f11e4cbb36fc65ff92296065e5f0a508b210ac7) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: fix a typoMing Liu2017-02-021-1/+1
| | | | | | | | (From OE-Core rev: c72d5acb9c2f4a7d4dfe0e78aae832b10aec4429) Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: allow bypassing of network setupJuro Bystricky2017-01-311-0/+2
| | | | | | | | | | | | | | | | | | At present it is silently assumed all QEMU machines support networking. As a consequence, one cannot run QEMUs without network emulation using "runqemu". This patch allows bypassing any network setup providing the qemuboot.conf file contains: qb_net = none [YOCTO#10661] (From OE-Core rev: 6a9454027ced4efbb401a23df94f711b8253c8fa) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: more verbose error message about missing qemuboot.confPatrick Ohly2017-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When invoking "runqemu" with a mistyped image or architecture name, the resulting error message is about the missing qemuboot.conf, without any indication about the root cause: $ runqemu core-image-mimimal ext4 intel-corei7-64 runqemu - INFO - Assuming MACHINE = intel-corei7-64 runqemu - INFO - Running MACHINE=intel-corei7-64 bitbake -e... runqemu - INFO - MACHINE: intel-corei7-64 runqemu - INFO - DEPLOY_DIR_IMAGE: /fast/build/refkit/intel-corei7-64/tmp-glibc/deploy/images/intel-corei7-64 Traceback (most recent call last): File "/work/openembedded-core/scripts/runqemu", line 1095, in <module> ret = main() File "/work/openembedded-core/scripts/runqemu", line 1082, in main config.read_qemuboot() File "/work/openembedded-core/scripts/runqemu", line 643, in read_qemuboot raise Exception("Failed to find <image>.qemuboot.conf!") Exception: Failed to find <image>.qemuboot.conf! Including the name of the actual file the scripts expects to find plus adding some hints what to check for might help. The error now is: $ runqemu core-image-mimimal ext4 intel-corei7-64 ... Exception: Failed to find <image>.qemuboot.conf = .../tmp-glibc/deploy/images/intel-corei7-64/core-image-mimimal-intel-corei7-64.qemuboot.conf (wrong image name or BSP does not support running under qemu?). The comment about the BSP is included because that would be the real reason why the file might be missing. (From OE-Core rev: 946c4558f6c2726d0f12e48974568188a4ffef0d) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fixes for slirp, network device and hostfwdRobert Yang2017-01-231-7/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* runqemu: support multiple qemus running when nfsRobert Yang2017-01-231-19/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed: * In build1: $ runqemu nfs qemux86-64 In build2: $ runqemu nfs qemux86-64 It would fail before since the port numerbs and conf files are conflicted, now make runqemu-export-rootfs work together with runqemu to fix the problem. * And we don't need export PSEUDO_LOCALSTATEDIR in runqemu, the runqemu-export-rootfs can handle it well based on NFS_EXPORT_DIR. * Remove "async" option from unfsd to fix warning in syslog: Warning: unknown exports option `async' ignored * Fixed typos Both slirp and tap can work. (From OE-Core rev: 84b2281595bbdb497daa42640e3ee4658bf0bed8) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-16 09:07:46 +0000