summaryrefslogtreecommitdiffstats
path: root/scripts/runqemu
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* scripts/runqemu: fix checking for <file>.cpio.gzRobert Yang2017-01-191-6/+16
| | | | | | | | | | | | When "runqemu /path/to/<file>.cpio.gz", it used the last suffix "gz" as the fstype which was wrong. Check filename against self.fstypes firstly can fix the problem. (From OE-Core rev: 68c7589b67a83977331a04356b53aa51680a1d9d) 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: Allow the user to specity no kernel or rootFSAlistair Francis2017-01-161-1/+8
| | | | | | | | | | | | | | | In some cirsumstances the user doesn't want to supply a kernel, rootFS or DTB to QEMU. This will occur more now that QEMU supports loading images using a '-device loader' method. Allow users to specify 'none' for QB_DEFAULT_FSTYPE or QB_DEFAULT_KERNEL to avoid supplying these options to QEMU. (From OE-Core rev: 2cc01c4e46b05b7ffcc8a11e7ebde6c43256c3c3) 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 command line parameters override defaultsPatrick Ohly2017-01-051-1/+1
| | | | | | | | | | | | | | | | It may be necessary to override the parameters gathered for the qemu invocation. For example, the qemux86 machine configuration sets "-vga vmware", but when using OVMF as BIOS, only "-vga std" is supported. By putting the parameters derived from custom runqemu parameters like "qemuparams" after the parameters derived from the machine configuration the user gets the possibility to override those. (From OE-Core rev: b6feb7578d60289c8b6e376cfaac8a3ee45e72f9) 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>
* scripts/runqemu: Allow to use qemu from host.Mariano Lopez2016-12-161-0/+15
| | | | | | | | | | | | | | | This will add support to use qemu from the running host, with this is possible to put qemu-native in ASSUME_PROVIDED variable. By default it will try to get qemu from the build sysroot, and only if it fails will try to use the host's qemu. (From OE-Core rev: fe7fd2cd3a9c4fb5b31bd3cab81c96a3b81cb540) Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Split out the base name of QB_DEFAULT_KERNELAlistair Francis2016-11-151-1/+4
| | | | | | | | | | | | The function write_qemuboot_conf() in qemuboot.bbclass always inserts the full path into QB_DEFAULT_KERNEL. Remove this path before using the variable. (From OE-Core rev: 7c0fdfa1316011b856a795d8e42c36ac8b5638b2) 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 user mode (SLIRP) support to x86 QEMU targetsTodor Minchev2016-11-061-1/+2
| | | | | | | | | | | | | | | | 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" (From OE-Core rev: 80e6fc678f3dcd774d9376cdf2a6afcba2cd0b09) Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: Add little endian variations for MIPSZubair Lutfullah Kakakhel2016-10-011-1/+5
| | | | | | | | | | Add mipsel and mips64el as an option. (From OE-Core rev: 072dd5b3b164ca7a5fd9dc969c991c15adeb0cbe) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqemu: explicitly set image formatEd Bartosh2016-09-301-4/+7
| | | | | | | | | | | | | | | | | | QEMU produces a warning if drive format is not specified: WARNING: Image format was not specified for 'tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.wic' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. Set image format to 'vmdk', 'qcow2' or 'vdi' for correspondent image types. Set it to 'raw' for the rest of image types. (From OE-Core rev: 5100bb36502ef7c81220a3c4809eb1b3ac83801f) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: provide better error message on runqemu ifup failStephano Cetola2016-09-241-0/+3
| | | | | | | | | | | | | If runqemu-ifup fails hen running testimage, a rather cryptic error regarding "no tty present" is displayed. If this step fails, we should at least point the user at runqemu-gen-tapdevs. A quick search of this term in the manual will lead them to "Enabling Runtime Tests on QEMU" which should give them all the info they need. (From OE-Core rev: 3b6494fad2b8b65e0d52cda0cdf500e93c72823a) Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-13 21:56:30 +0000