subprocess.run() was introduced in Python 3.5. We currently support down to
Python 3.4 so I've replaced it with subprocess.check_call() which is available
in that version.
(From OE-Core rev: 3a09cee5994ce65079dab1042e47e5eed4540bb9)
Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its currently not possible to have a console available whilst using qemu in graphics
mode. This is causing some issues for testing autobuilder bringup so all a "serialstdio"
mode to runqemu to accomodate this.
The existing serialstdio internal variable is renamed to allow the new user visible option.
(From OE-Core rev: 101b70d3c6a0a5a022d96dfdd21500b757c8fada)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current handling of SIGTERM is incorrect as the process pid returned
by Popen call with shell setting to True is actualy the shell instead of
the qemu process. So use shlex to split cmd so that we can avoid using
shell=True. This ensures the child process is the actual qemu process.
Also, as we install a SIGTERM handler, we need handle the situation of
qemu terminated by SIGTERM, otherwise we will get ERROR message in such
case.
Besides, we have a problem that after running qemu, the terminal's behavior
is incorrect regarding long lines or long commands. Long commands or long
outputs should appear in multiple lines, but they appear in the same line,
overriding previous output. Use `tput smam' to fix this problem.
(From OE-Core rev: e8acef383767cfd1ef0c3d3c45d9d6eb1c83b3e7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The warn method is deprecated. We should use the documented warning instead.
Quoting from the python's official doc:
"""
Note: There is an obsolete method warn which is functionally identical to warning.
As warn is deprecated, please do not use it - use warning instead.
"""
(From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff801268c0>] clear_page+0x0/0x128
[ 0.000000] [<ffffffff80238158>] get_page_from_freelist+0xab8/0xc00
[ 0.000000] [<ffffffff80238964>] __alloc_pages_nodemask+0xdc/0xf68
[ 0.000000] [<ffffffff80239808>] __get_free_pages+0x18/0x70
[ 0.000000] [<ffffffff80122a4c>] setup_zero_pages+0x1c/0xb8
[ 0.000000] [<ffffffff80c7c998>] mem_init+0x54/0xa0
[ 0.000000] [<ffffffff80c74904>] start_kernel+0x204/0x4d8
[ 0.000000] [<ffffffff8091dfb0>] kernel_entry+0x0/0x40
[ 0.000000] Code: 02002025 1000f8d9 8e634d7c <34860f80> cc9e0000
cc9e0020 cc9e0040 cc9e0060 cc9e0080
[ 0.000000]
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
...
OE uses qemumips to simulate a Malta board by default.
As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x90000000 mem=1536M@0x20000000
...
But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed Nov 23 14:43:49 2016 +0100
MIPS: fix mem=X@Y commandline processing
...
So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.
Author: Hongxu Jia <hongxu.jia@windriver.com>
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
and make it support all mips cases ]
(From OE-Core rev: 0220cb34a91658ecc3782ec1a4700dcb5ece37d8)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add SIGTERM handler so that runqemu could clean things up correctly
when receving such signal.
This problem was originally observed when running testimage. On
some hosts, after running testimage task, the user has to manually
operate on the tap interface (e.g. `sudo ip link del tap0') in order
for the next runqemu command to launch successfully.
The problem is about runqemu, SIGTERM and network manager on the host.
In testimage task, the runqemu process will receive SIGTERM. In such
situation, its cleanup() function is not run, resulting in tap interface
not cleaned up. On some hosts, the network manager will bring down the
tap interface automatically, thus this problem. I saw this problem on
Fedora21.
I think we'd better just clean up the tap interface ourselves.
So this patch adds to runqemu a SIGTERM handler, in which the actual
qemu process is terminated and other things cleaned up.
(From OE-Core rev: 02709d4709c56f9b9095e3555da35b659b03a8a3)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 6bb9860ef7
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* "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 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>
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>
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>
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>
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>
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>
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>
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>
'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>
(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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
(From OE-Core rev: 69a1fca4374797dea56035ce56a17441a2ca9280)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[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>
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>
* 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>
* 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>
