summaryrefslogtreecommitdiffstats
path: root/scripts/runqemu
Commit message (Collapse)AuthorAgeFilesLines
...
* scripts/runqemu: Using a cpio* rootfs has no special networkNathan Rossi2016-09-231-1/+0
| | | | | | | | | | | | | When booting a system with the rootfs being of cpio* type the networking setup should still work the same as for all other root filesystem types. This change removes the clearing of the NETWORK_CMD variable allowing for the slirp/tap setup to be provided to QEMU. (From OE-Core rev: 7d01a9c80de0cdbac3831301dd996c7b61754c74) 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>
* runqemu: Move virtio RNG to machine configurationNathan Rossi2016-09-231-3/+0
| | | | | | | | | | | | | | | | | 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>
* runqemu: don't fail during check_arg_machine()Joshua Lock2016-09-211-1/+1
| | | | | | | | | | | If DEPLOY_DIR_IMAGE doesn't exist during check_arg_machine() we will attempt to guess a suitable value later when check_and_set() calls validate_paths(), therefore this shouldn't raise an exception (From OE-Core rev: ed8d6f391c567048bd50dc3234804915f8212cef) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: don't try and invoke bitbake when running in a toolchain envJoshua Lock2016-09-211-2/+7
| | | | | | | | | | | If a MACHINE value is passed we can't validate it by running bitbake as the toolchain environment doesn't include the build system, we must assume that the passed value for MACHINE is correct. (From OE-Core rev: 2c569678566c49b3ea237ef2de0fbae782263449) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: try and guess qemu-system binary when MACHINE isn't setJoshua Lock2016-09-211-0/+36
| | | | | | | | | | | Emulate some logic from the prior, shell based, version of runqemu to try and infer the correct setting for MACHINE from the kernel and rootfs filenames. (From OE-Core rev: a5adabe1414061d6864c5913dd5e66a4527838f1) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: validate paths and attempt to infer unset pathsJoshua Lock2016-09-211-0/+3
| | | | | | | | | | | | We need to validate and ensure all paths are set regardless of whether runqemu was invoked with a .qemuboot.conf file or otherwise. Split this logic out into a separate method called during check_and_set() (From OE-Core rev: e843b2d49a151c1fe0d2a7ba00c41d2a35775736) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: improve finding of rootfs, kernel and dtbRobert Yang2016-09-201-31/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | * Search rootfs in the following order: - IMAGE_NAME*.FSTYPE - IMAGE_LINK_NAME*.FSTYPE * Search kernel in the following order: - QB_DEFAULT_KERNEL - KERNEL_IMAGETYPE - KERNEL_IMAGETYPE* * Search dtb in the following order: - QB_DTB - QB_DTB* - *.dtb * Fix DTB, it should only work with "-kernel" option. [YOCTO #10265] (From OE-Core rev: 32ff0974ed06f797c6b7d9092a8dc9ae50e9a572) 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: use OECORE_NATIVE_SYSROOT from sdkRobert Yang2016-09-201-4/+11
| | | | | | | | | | There is no STAGING_DIR_NATIVE or bitbake in a extracted sdk, so check OECORE_NATIVE_SYSROOT and use it. (From OE-Core rev: 93649edc034f2540ff55dc9b41638797209cfb9c) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: work even if a *.qemuboot.conf isn't foundJoshua Lock2016-09-201-1/+7
| | | | | | | | | | | | | | | A qemuboot conf file is a convenience but it should still be possible to invoke runqemu without them, especially for examples such as using the SDK with an extracted rootfs via NFS. As read_qemuboot() is always called we need to be sure that function can return cleanly, without throwing Exceptions, even if a qemuboot conf file isn't found. (From OE-Core rev: 3541c21f1976b517b79a19882240a8f36b970292) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: try symlinks when kernel or rootfs can't be foundJoshua Lock2016-09-201-3/+13
| | | | | | | | | | | | | | | If the kernel or rootfs names written to the qemuboot.conf can't be found, try and find the symlinked variant of the filename. This will help usability of runqemu, for example where a user downloads an image and associated files as the symlinked names yet the qemuboot.conf variables point to the full, non-linked, file names. (From OE-Core rev: ca5a686c6e165a51f95cb6a834cd53f6f66d42d4) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: clarify an INFO messageJoshua Lock2016-09-201-1/+1
| | | | | | | | | | Make it clearer that we are looking for a file which ends with qemuboot.conf (From OE-Core rev: 2579e05269a14b53a54232a8bf4414ac2dfe6472) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add guidance to resolve issues with missing filesJoshua Lock2016-09-201-3/+16
| | | | | | | | | | | When a required binary cannot be found print some guidance pointing to using a sourced OE build environment or a qemuboot.conf file, based on a similar message from the previous shell-based runqemu. (From OE-Core rev: 87cfb5165490cd4e7a8c2570ef5a62898db8395e) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: acquire_lock() should fail when failed to open the fileRobert Yang2016-09-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The open(self.lock, 'w') may fail when the lock is created by other users, return false for this case to let it try other devices. Fixed: runqemu - INFO - Running /sbin/ip link... runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... Traceback (most recent call last): File "/buildarea/lyang1/poky/scripts/runqemu", line 972, in <module> ret = main() File "/buildarea/lyang1/poky/scripts/runqemu", line 963, in main config.setup_network() File "/buildarea/lyang1/poky/scripts/runqemu", line 810, in setup_network self.setup_tap() File "/buildarea/lyang1/poky/scripts/runqemu", line 761, in setup_tap if self.acquire_lock(): File "/buildarea/lyang1/poky/scripts/runqemu", line 182, in acquire_lock lock_descriptor = open(self.lock, 'w') PermissionError: [Errno 13] Permission denied: '/tmp/qemu-tap-locks/tap0.lock' (From OE-Core rev: f364f773a0381a75b5992c8c8a1d63a81dbd4422) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix a race issue on lockdirRobert Yang2016-09-141-1/+6
| | | | | | | | | | | | | | | | | | | | There might be a race issue when multi runqemu processess are running at the same time: | Traceback (most recent call last): | File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/scripts/runqemu", line 920, in <module> | ret = main() | File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/scripts/runqemu", line 911, in main | config.setup_network() | File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/scripts/runqemu", line 760, in setup_network | self.setup_tap() | File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ipk/build/scripts/runqemu", line 697, in setup_tap | os.mkdir(lockdir) | FileExistsError: [Errno 17] File exists: '/tmp/qemu-tap-locks' (From OE-Core rev: ec33043477a0b915b0911f7d7eacb24361e4aaa8) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: Add snapshot supportRichard Purdie2016-09-091-0/+6
| | | | | | | | | Allow access to the snapshot option of qemu to simplify some of our runtime testing to avoid copying images. (From OE-Core rev: 8fec4a5a004f0e99734f8c0820c66522d08f213e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Enable virtio RNG for all platformsRichard Purdie2016-09-091-0/+3
| | | | | | | | | | | | | | | | | We have problems where systems simply stop booting and hang. This is due to a lack of entropy which means ssh keys and networking can't be brought up. Adding in the virtio-rng passthrough support allows host entropy to pass into the guess and avoids these hangs. This is particularly problematic after the gnutls upgrade which starts using /dev/random instead of /dev/urandom but was an issue we'd occasionally seem before that. It particualrly affected x86 and ppc machines for some reason. (From OE-Core rev: 51b001909f1856c45cf87091d6e4446c266d5786) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Update to modern prefrerred net syntaxRichard Purdie2016-09-091-1/+1
| | | | | | (From OE-Core rev: 5e61766d976b6d036946c1b4e4ac742a33a03815) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Allow unique network interface MAC addressesRichard Purdie2016-09-091-2/+3
| | | | | | | | | | | 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>
* runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGEJoshua Lock2016-09-091-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | testimage.bbclass uses runqemu to execute runtime tests on a qemu target, this means that bitbake is already running and `bitbake -e` can't be called to obtain bitbake variables. runqemu tries to work around being unable to read values for bitbake variables by inferring the MACHINE from the DEPLOY_DIR_IMAGE setting, however if a user sets that variable in a manner which doesn't follow the systems expectations (i.e. if running `bitbake -c testimage` against a directory of pre-generated images in a user-specified path) the inferring of the MACHINE name from the DEPLOY_DIR_IMAGE location will fail. It's possible that check_arg_machine() shouldn't cause runqemu to fail and that runqemu should proceed with the user-supplied value even if it can't be verified. This patch simply ensures that a workflow where the user sets DEPLOY_DIR_IMAGE continues to work without changing too much of the runqemu code. [YOCTO #10238] (From OE-Core rev: f94ac02f459e2ea0fc471463966997814a67e0ca) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fixes for when invoked during a bitbake runJoshua Lock2016-09-091-6/+22
| | | | | | | | | | | | | | | | | When runqemu is invoked from a running bitbake instance it will be unable to call `bitbake -e` due to the lock held by the calling bitbake instance. Our test code sets an OE_TMPDIR environment variable from which we can infer/guess paths. Add code to do so when self.bitbake_e can't be set, much as the sh version of runqemu did. [YOCTO #10240] (From OE-Core rev: 1e8165ea2f19aecdc03ccd102ee44ef0544f0f39) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: better handle running on a host with different pathsJoshua Lock2016-09-091-0/+39
| | | | | | | | | | | If the STAGING_*_NATIVE directories from the config file don't exist and we're in a sourced OE build directory try to extract the paths from `bitbake -e` (From OE-Core rev: 9326af1c20636320c70caecebd47aedafb3f2d25) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: assume artefacts are relative to *.qemuboot.confJoshua Lock2016-09-091-1/+14
| | | | | | | | | | | When runqemu is started with a *.qemuboot.conf arg assume that image artefacts are relative to that file, rather than in whatever directory the DEPLOY_DIR_IMAGE variable in the conf file points to. (From OE-Core rev: a6448371b87f754def669adfdc01b07d18003405) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: refactor it and remove machine knowledgeRobert Yang2016-09-091-525/+807
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, runqemu had hard coded machine knowledge, which limited its usage, for example, qemu can boot genericx86, but runqemu can't, we need edit runqemu/runqemu-internal a lot if we want to boot genericx86. Now bsp conf files can set vars to make it can be boot by runqemu, and qemuboot.bbclass will save these info to DEPLOY_DIR_IMAGE/qemuboot.conf. Please see qemuboot.bbclass' comments on how to set the vars. * Re-write it in python3, which can reduce lines from 1239 to about 750 lines * All the machine knowledges are gone * All of the TUN_ARCH knowledge are gone * All the previous options are preserved, and there is a new way to run runqemu: (it doesn't need run "bitake -e" in such a case) $ runqemu tmp/deploy/images/qemux86 or: $ runqemu tmp/deploy/images/qemuarm/<image>.ext4 or: $ runqemu tmp/deploy/images/qemuarm/qemuboot.conf * Fixed audio support, not limited on x86 or x86_64 * Fix SLIRP mode, add help message, avoid mixing with tap * Fix NFS boot, it will extract <image>.tar.bz2 or tar.gz to DEPLOY_DIR_IMAGE/<image>-nfsroot when no NFS_DIR, and remove it after stop. * More bsps can be boot, such as genericx86 and genericx86-64. * The patch for qemuzynq, qemuzynqmp, qemumicroblaze has been sent to meta-xilinx' mailing list. * I can't find any qemush4 bsp or how to build it, so it is not considered atm. [YOCTO #1018] [YOCTO #4827] [YOCTO #7459] [YOCTO #7887] (From OE-Core rev: 60ca8a8d899b90a4693fd62b6ec97d0c76a9f6c5) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: qemuzynqmp: Add Linux boot supportAlistair Francis2016-08-101-2/+1
| | | | | | | | | | Add support to direct boot Linux instead of just booting u-boot. (From OE-Core rev: e5c6a78db46192800669f1b392351f6b52f3e20c) 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: Add suport for qemuzynqmpAlistair Francis2016-06-121-1/+8
| | | | | | | | (From OE-Core rev: d2a7c1db9bff6ae3844e3d017e94f29d1501bf57) 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: let ramfs equal to cpio.gzRobert Yang2016-04-141-2/+2
| | | | | | | | | | | | For example, support both: $ runqemu qemux86-64 ramfs $ runqemu qemux86-64 cpio.gz (new) (From OE-Core rev: 6529264776701d4f5a1e4a8336ac2e01a6ddea85) 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: fix for isoRobert Yang2016-03-291-2/+2
| | | | | | | | | It should be the similar type as hddimg, rather than ext234 or btrfs. (From OE-Core rev: d5ddc5ec1628c94bd5edc45bc821da1ce616e80f) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu-internal: cleanup unsed codeRobert Yang2016-03-251-6/+0
| | | | | | | | | | | | | | | | | | | * remove akita and spitz related code They are not supported by runqemu anymore: $ runqemu spitz Error: unable to classify arg [spitz] So remove related code. * Remove checking of 256M for qemuarm, qemu can check it, for example: $ runqemu qemuarm qemuparams="-m 1024" [snip] qemu: Too much memory for this machine: 1024 MB, maximum 256 MB [snip] (From OE-Core rev: 36fb785bf8cd2f387c91d52f597602a5dbc3948b) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: simplify checking for iso and ramfsRobert Yang2016-03-251-6/+1
| | | | | | | (From OE-Core rev: 69a1fca4374797dea56035ce56a17441a2ca9280) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add support for qcow2 and vdiRobert Yang2016-03-251-4/+3
| | | | | | | | | [YOCTO #9168] (From OE-Core rev: 0f8306c77b4ebed1ff127b0786b7109abf0d57cd) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: remove ISO and RAMFS from help textRobert Yang2016-03-251-2/+0
| | | | | | | | | They don't work, and the script can check the type correctly. (From OE-Core rev: b5cc1e70dbd5df160ddedcaa40d0ab714a307561) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: simplify the checking for vm imagesRobert Yang2016-03-251-11/+23
| | | | | | | | | | * So that we can add more image support easliy. * I think that wic should be vm images. (From OE-Core rev: 82d0014a0e1526ffa1ff7c8ea3903aeae31bada4) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix ROOTFS for vmdkRobert Yang2016-03-251-37/+40
| | | | | | | | | | | | | | | | | | | | * Make it can boot scsi and virtio block drive such as root=/dev/sdX and /dev/vdX. * Drop VM from help info, id doesn't work, and the script can check whether it is a vm disk or not. * Make it can be run by: $ runqemu tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.vmdk or: $ runqemu qemux86-64 vmdk [YOCTO #9170] (From OE-Core rev: 88c081b10902ec52928be78ad320c474bb918e01) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support path/to/<image>-<machine>.wicEd Bartosh2016-02-151-4/+6
| | | | | | | | | | | | | | Supported providing wic image path to runqemu: runquemu path/to/<image>-<machine>.wic [YOCTO #8691] (From OE-Core rev: 58a3bfb1e4b493200820cdf0bf3fc79e31e792de) (From OE-Core rev: e6150971ea4eea49b802a12aea5ab733e894c92d) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: don't set KERNEL for wic imagesEd Bartosh2016-02-151-1/+1
| | | | | | | | | | | | | | | | Wic images should be boot as is, without pointing qemu to the kernel binary. Current code doesn't use kernel, but sets KERNEL variable and shows kernel path in the console output. This can confuse users. Changed runqemu and runqemu-internal code to avoid setting KERNEL variable and show kernel path. (From OE-Core rev: 474caa7ed5ff05caa5d49d270b283882fa616ed1) (From OE-Core rev: 35e776e00cce25f2c9c45500612fb66022ec4739) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add support for wic imagesEd Bartosh2016-02-151-1/+2
| | | | | | | | | | | | | | Quemu should be able to run wic images this way: runqemu <machine> <image recipe> wic Tested with 'runqemu qemux86-64 wic-image-minimal wic' (From OE-Core rev: 8716be799949cb8bde7fa49cbea61312a3a93bb7) (From OE-Core rev: dd42931bf99b8bbd4ad452b3941d957f41b81796) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: runqemu: remove QEMUARCH from help messageRuslan Bilovol2015-11-161-1/+0
| | | | | | | | | | | | | The QEMUARCH env variable is not used since commit "d469c92 classes/imagetest-qemu: remove old image testing class". Remove it from help message so it will not confuse other people (From OE-Core rev: f2f2fa61e2c331409f20c999f93d78ef752b4fd2) Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: don't specify IP when starting a VNC serverRoss Burton2015-11-161-1/+1
| | | | | | | | | | Whilst qemu doesn't appear to support opening sockets on IPv6 yet, future-proof the script by just specifying a port and letting qemu work out the rest. (From OE-Core rev: abf8975bce4bf5d05dbb186d5089f0c3fe07eefb) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Enable support for kvm without vhost in x86 and x86_64Aníbal Limón2015-10-271-10/+21
| | | | | | | | | | | | | | | | | KVM can be used without vhost so add a new option to runqemu for use kvm with vhost. Example, runqemu qemux86 core-image-minimal kvm # kvm without vhost runqemu qemux86 core-image-minimal kvm-vhost # kvm with vhost [YOCTO #7443] (From OE-Core rev: 7f5f8f87a4180a2b05188047c6a05da5571f94e2) 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: don't complain about conflicting machines if they are equalPascal Bach2015-09-281-1/+1
| | | | | | | | | | | | | | | | | When the MACHINE variable was set as an environment variable, via "export MACHINE=qemuarm" and runqemu was executed as "runqemu qemuarm" The confusing error message appears: Error: conflicting MACHINE types [qemuarm] and [qemuarm] This checks if the two values are equal, in that case there is no problem and execution can continue. (From OE-Core rev: 6615a21d578ba9ab053ba0b3deab26ebf88e577b) Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: avoid image file name mismatchesPatrick Ohly2015-09-121-16/+16
| | | | | | | | | | | | | | | | | Giving anything with -image in it as bootparams or in qemuparams (for example, an additional -drive parameter with an image file or an "-initrd .../core-image-minimal-initramfs-qemux86.cpio.gz") caused runqemu to treat these parameters as names of the rootfs image file. Matching *-image) after checking the current argument for more specific cases like bootparams and qemuparams avoids this misinterpretation of the command line parameters. (From OE-Core rev: 29e0aaa7345ca823bb4af2d4a870e98ac75e04e7) 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: Define OECORE_MACHINE_SYSROOT on setup_sysrootLeonardo Sandoval2015-09-121-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching BIOS, VGA BIOS and keymaps. As a example, to boot a OVFM BIOS, one can run the following command: $ runqemu qemux86-64 core-image-minimal \ biosdir=usr/share/ovmf \ biosfilename=bios.bin \ nographic Note the bios* parameters: these two are needed to specify the subfolder (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it, it picks a BIOS named bios-256k.bin). [YOCTO #5654] (From OE-Core rev: bded344a464bb854db3935da1f6a3320e5aa01e5) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: support full-disk imagesPatrick Ohly2015-09-061-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes it possible to boot images with multiple partitions (the ones ending in .hddimg or .hdddirect) in several ways: runqemu qemux86 core-image-minimal hddimg runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg VM=tmp-glibc/deploy/images/qemux86/iot-os-image-qemux86.hddimg FSTYPE=hddimg runqemu Same for hdddirect. This is useful for testing initramfs scripts, secure boot (when switching to UEFI), or boot loaders like syslinux. For testing the content of the rootfs, the ext4 image is better because that approach is faster (no need to create another large image during build, rootfs can be read directly instead of reading boot.img through loop device). When booting a live image, the kernel, initramfs (if any) and kernel parameters are taken from the image by the virtual machine's BIOS, so any additional kernel parameters given to runqemu are ignored. This can be avoided (already without this change) in a slightly hacky runqemu setup: ROOTFS=tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg \ FSTYPE=ext4 \ KERNEL=tmp/deploy/images/qemux86/bzImage-initramfs-qemux86.bin \ MACHINE=qemux86 \ runqemu serial kvm nographic 'bootparams=root=/dev/ram0' The additional bzImage-initramfs-qemux86.bin kernel here was created by adding this to local.conf: INITRAMFS_IMAGE = "core-image-minimal-initramfs" INITRAMFS_IMAGE_BUNDLE = "1" In the code, the new FSTYPE=hddimg resp. hdddirect behaves almost exactly like the older vmdk FSTYPE. New types were chosen because it seemed cleaner than using FSTYPE=vmdk when the actual image pointed to by VM is not in that format. The downside is that several checks for FSTYPE=vmdk had to be duplicated for FSTYPE=hddimg. The VM variable now gets interpreted as "virtual machine disk image" instead of "vmdk image". (From OE-Core rev: 37741c539f5d3021e59828b49e968cd42b89a368) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Add a tcpserial optionRandy Witt2015-08-241-0/+4
| | | | | | | | | | | | | | | | | | | The option was added so that the qemurunner could start a second tcp serial port without adding machine conditional logic to qemurunner. The issue that made this necessary was that when "virt" is passed to qemu-system-aarch64, the normal mechanism for specifying a tcp serial port does not work. This is because the hardware for the "virt" machine is hardcoded in the device tree blob and the addition devices must be virtio devices. So runqemu can specify virtio for qemuarm64 whereas it seems all other qemu machines work with the "-serial tcp*" option. (From OE-Core rev: 849d65d55e4df5fa443b2cb7b4cee23913fc9d5a) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: fix MACHINE being detected as qemuarm for qemuarm64 kernel imageJagadeesh Krishnanjanappa2015-06-231-2/+2
| | | | | | | | | | | | | | Basically, runqemu script autodetects MACHINE type based on the kernel image name; if MACHINE name is not specified. Since 'qemuarm' string is common in both qemuarm amnd qemuarm64 kernel image names, the MACHINE type is considered as 'qemuarm' even when qemuarm64 kernel image name is given in command line. (From OE-Core rev: 388b243668a5c28fb69b760ce9be5adbc85352d8) Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: Allow FSTYPE to be changed from the environmentRichard Purdie2015-03-201-1/+1
| | | | | | | | | | | | Currently its not possible to change FSTYPE from the environment but it would be useful to do so where multiple image types have been generated. This adds that possibility. (From OE-Core rev: c210430c24af6717aa955efe1afe9fc4d2d3f2a9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: clarify help textBernhard Reutner-Fischer2015-03-091-1/+1
| | | | | | | (From OE-Core rev: 0542472969d0eb28fd44da97e4e01d69d864d157) Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machine/qemu: Switch from ext3 to ext4Richard Purdie2015-02-211-10/+10
| | | | | | | | | | There is no good reason not to use ext4 at this point, it has advantages and few drawbacks. Therefore switch the qemu machines over (and the default runqemu script options). (From OE-Core rev: 430b9ae71b1aa76f8421127d17e0e0723d4818d3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Add option for BIOS binary filenameRicardo Neri2015-02-141-0/+3
| | | | | | | | | | | | | | If we intend to use a custom BIOS binary file, it would be good to be able to specify the name of the binary via the -bios option of qemu. The name of the custom binary could be different from the default name used by qemu. For instance, it was bios.bin in qemu 1.5.0 and changed to bios-256k.bin for 2.1.0. (From OE-Core rev: 29c9e6f44541b7f8731e21e9d1a0adca9da28e37) Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: add qemuarm64 support.Kai Kang2014-12-231-1/+4
| | | | | | | | | | Update scripts runqemu and runqemu-internal to support to boot qemuarm64. (From OE-Core rev: 2f020b53bdb8c262e432bc4df35101fa990c460c) Signed-off-by: Kai Kang <kai.kang@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-05-02 06:58:53 +0000