runqemu/runqemu-internal: refactor it
cover runqemu/runqemu-internal: refactor it
Hello,
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such as QEMU_SYSTEM_OPTIONS and QEMU_SECOND_SERIAL_OPT
* More testing
=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but runqemu can't, and we need edit runqemu/runqemu-internal a lot to support boot it.
* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or "0"), and how to boot it, so we leave these settings in the machine's configuration.
- qemu-boot.bbclass will write machine's info to
${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it. - We need use "runqemu -m <machine>" rather than "runqemu <machine>" since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's extension.
- I have updated all the machine's configuration except qemush4, since I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot by new runqemu without any changes.
- Added help info for supported options such as slirp and audio.
* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir
-t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg, hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
-V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable CPU required) -v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required) -a, support audio
-s, enable a serial console on /dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU
-b <bootparams> - specify custom kernel parameters during boot
-p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.
Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"
// Robert
The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:
test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/runqemu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu
Robert Yang (8):
qemu-boot.bbclass: add it for runqemu
qemu.inc: set QEMU_BOOT_SUPPORTED to 1
qemuarm.conf: set vars for runqemu
arch-arm64.inc: set vars for runqemu
arch-x86.inc: set vars for runqemu
arch-mips.inc: set vars for runqemu
arch-powerpc.inc: set vars for runqemu
runqemu/runqemu-internal: refactor it
meta/classes/image.bbclass | 3 + meta/classes/qemu-boot.bbclass | 39 ++ meta/conf/bitbake.conf | 3 + meta/conf/machine/include/arm/arch-arm64.inc | 7 + meta/conf/machine/include/arm/arch-armv6.inc | 2 + meta/conf/machine/include/mips/arch-mips.inc | 5 + meta/conf/machine/include/powerpc/arch-powerpc.inc | 5 + meta/conf/machine/include/qemu.inc | 2 + meta/conf/machine/include/tune-cortexa8.inc | 2 + meta/conf/machine/include/x86/arch-x86.inc | 6 + meta/conf/machine/qemuarm.conf | 3 + scripts/runqemu | 603 +++++++----------- scripts/runqemu-internal | 678 +++++++-------------- 13 files changed, 505 insertions(+), 853 deletions(-) create mode 100644 meta/classes/qemu-boot.bbclass
Signature · 1 line
2.7.4
RFC PATCH 1/8 qemu-boot.bbclass: add it for runqemu
It saves vars in ${DEPLOY_DIR_IMAGE}/qemu-boot, and scritps/runqemu will invoke it, so that runqemu can work easier.
The class will be inherited when QEMU_BOOT_SUPPORTED = "1", default 0 which is set in bitbake.conf.
--- meta/classes/image.bbclass | 3 +++ meta/classes/qemu-boot.bbclass | 39 +++++++++++++++++++++++++++++++++++++++ meta/conf/bitbake.conf | 3 +++ 3 files changed, 45 insertions(+) create mode 100644 meta/classes/qemu-boot.bbclass
meta/classes/image.bbclass +3 -0
@@ -22,6 +22,9 @@ INHIBIT_DEFAULT_DEPS = "1" TESTIMAGECLASS = "${@base_conditional('TEST_IMAGE', '1', 'testimage-auto', '', d)}" inherit ${TESTIMAGECLASS} +QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot', '', d)}" +inherit ${QEMU_BOOT_CLASS} + # IMAGE_FEATURES may contain any available package group IMAGE_FEATURES ?= "" IMAGE_FEATURES[type] = "list"
meta/classes/qemu-boot.bbclass new file +39 -0
@@ -0,0 +1,39 @@ +QEMU_NAME ?= "" +QEMU_MAHINE_SUBTYPE ?= "" +QEMU_CPU_SUBTYPE ?= "" +QEMU_CPU_SUBTYPE_KVM ?= "" +QEMU_MEM ?= "-m 256" +QEMU_SYSTEM_OPTIONS ?= "" +QEMU_SECOND_SERIAL_OPT ?= "-serial mon:stdio -serial null" +QEMU_KERNEL_OPTIONS ?= "" +QEMU_DEFAULT_KERNEL ?= "${KERNEL_IMAGETYPE}-${MACHINE}.bin" +QEMU_DEFAULT_FSTYPE ?= "ext4" +QEMU_DTB ?= "" +QEMU_UI_OPTIONS ?= "-show-cursor -usb -usbdevice tablet" + +QEMU_OPTIONS ?= "${QEMU_SYSTEM_OPTIONS} ${QEMU_MEM} ${QEMU_MAHINE_SUBTYPE}" + +do_qemu_vars[dirs] = "${DEPLOY_DIR_IMAGE}" +do_qemu_vars() { +cat > ${DEPLOY_DIR_IMAGE}/qemu-boot <<_EOF +QEMU_NAME="${QEMU_NAME}" +QEMU_OPTIONS="${QEMU_OPTIONS}" +TUNE_ARCH="${TUNE_ARCH}" +QEMU_DEFAULT_KERNEL="${QEMU_DEFAULT_KERNEL}" +QEMU_DEFAULT_FSTYPE="${QEMU_DEFAULT_FSTYPE}" +QEMU_MEM="${QEMU_MEM}" +QEMU_CPU_SUBTYPE="${QEMU_CPU_SUBTYPE}" +QEMU_CPU_SUBTYPE_KVM="${QEMU_CPU_SUBTYPE_KVM}" +QEMU_SECOND_SERIAL_OPT="${QEMU_SECOND_SERIAL_OPT}" +QEMU_KERNEL_OPTIONS="${QEMU_KERNEL_OPTIONS}" +DEPLOY_DIR_IMAGE="${DEPLOY_DIR_IMAGE}" +MACHINE="${MACHINE}" +STAGING_DIR_NATIVE="${STAGING_DIR_NATIVE}" +STAGING_BINDIR_NATIVE="${STAGING_BINDIR_NATIVE}" +STAGING_DIR_HOST="${STAGING_DIR_HOST}" +QEMU_DTB="${QEMU_DTB}" +QEMU_UI_OPTIONS="${QEMU_UI_OPTIONS}" +_EOF +} + +addtask do_qemu_vars before do_build
meta/conf/bitbake.conf +3 -0
@@ -818,3 +818,6 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \ MLPREFIX ??= "" MULTILIB_VARIANTS ??= "" + +# Supported run by qemu or not +QEMU_BOOT_SUPPORTED ?= "0"
Signature · 1 line
2.7.4
Re: [RFC PATCH 1/8] qemu-boot.bbclass: add it for runqemu
Hello Robert,
meta/classes/qemu-boot.bbclass line 2
Quoted 5 lines · Robert Yang
meta/classes/qemu-boot.bbclass new file +2
-0@@ -0,0 +1,39 @@ +QEMU_NAME ?= "" +QEMU_MAHINE_SUBTYPE ?= ""
typo: QEMU_MACHINE_SUBTYPE (here and in some of the .inc files).
Maybe you should use "??=", so "?=" may be used in the arch specific .inc files, in order to let a machine override it more easily.
Regards,
Andreas
Re: [RFC PATCH 1/8] qemu-boot.bbclass: add it for runqemu
Quoted 10 lines · Andreas Oberritter
Hello Robert,
meta/classes/qemu-boot.bbclass line 2
Quoted 5 lines · Robert Yang
meta/classes/qemu-boot.bbclass new file +2
-0@@ -0,0 +1,39 @@ +QEMU_NAME ?= "" +QEMU_MAHINE_SUBTYPE ?= ""typo:
QEMU_MACHINE_SUBTYPE(here and in some of the .inc files).
Yes, thanks, RP also pointed out this:-).
Quoted 3 lines
Maybe you should use "??=", so "?=" may be used in the arch specific .inc files, in order to let a machine override it more easily.
Make sense, thanks.
// Robert
Quoted 4 lines
Regards,
Andreas
RFC PATCH 2/8 qemu.inc: set QEMU_BOOT_SUPPORTED to 1
In reply to Robert YangAll the qemu boards should be able to boot by runqemu.
--- meta/conf/machine/include/qemu.inc | 2 ++ 1 file changed, 2 insertions(+)
meta/conf/machine/include/qemu.inc +2 -0
@@ -29,3 +29,5 @@ EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native" KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc" MACHINE_EXTRA_RRECOMMENDS += "rng-tools" + +QEMU_BOOT_SUPPORTED = "1"
Signature · 1 line
2.7.4
RFC PATCH 3/8 qemuarm.conf: set vars for runqemu
In reply to Robert Yang--- meta/conf/machine/include/arm/arch-armv6.inc | 2 ++ meta/conf/machine/include/tune-cortexa8.inc | 2 ++ meta/conf/machine/qemuarm.conf | 3 +++ 3 files changed, 7 insertions(+)
meta/conf/machine/include/arm/arch-armv6.inc +2 -0
@@ -48,3 +48,5 @@ PACKAGE_EXTRA_ARCHS_tune-armv6b = "${PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp PACKAGE_EXTRA_ARCHS_tune-armv6tb = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp} armv6b armv6tb armv6b-vfp armv6tb-vfp" PACKAGE_EXTRA_ARCHS_tune-armv6hfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp} armv6hfb-vfp" PACKAGE_EXTRA_ARCHS_tune-armv6thfb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp" + +QEMU_CPU_SUBTYPE = "-cpu arm1136"
meta/conf/machine/include/tune-cortexa8.inc +2 -0
@@ -34,3 +34,5 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa8hf = "${PACKAGE_EXTRA_ARCHS_tune-ar PACKAGE_EXTRA_ARCHS_tune-cortexa8thf = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} cortexa8hf-vfp cortexa8t2hf-vfp" PACKAGE_EXTRA_ARCHS_tune-cortexa8hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon} cortexa8hf-vfp cortexa8hf-neon" PACKAGE_EXTRA_ARCHS_tune-cortexa8thf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon} cortexa8hf-vfp cortexa8hf-neon cortexa8t2hf-vfp cortexa8t2hf-neon" + +QEMU_CPU_SUBTYPE = "-cpu cortex-a8"
meta/conf/machine/qemuarm.conf +3 -0
@@ -10,3 +10,6 @@ KERNEL_IMAGETYPE = "zImage" SERIAL_CONSOLES = "115200;ttyAMA0 115200;ttyAMA1" +QEMU_MAHINE_SUBTYPE = "-machine versatilepb" +QEMU_SYSTEM_OPTIONS = "-no-reboot" +QEMU_KERNEL_OPTIONS = "console=ttyAMA0,115200 console=tty"
Signature · 1 line
2.7.4
RFC PATCH 4/8 arch-arm64.inc: set vars for runqemu
In reply to Robert YangThese vars will be used when QEMU_BOOT_SUPPORTED = "1", and has no impact when "0".
--- meta/conf/machine/include/arm/arch-arm64.inc | 7 +++++++ 1 file changed, 7 insertions(+)
meta/conf/machine/include/arm/arch-arm64.inc +7 -0
@@ -34,3 +34,10 @@ TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_ARCH_64}', TUNE_PKGARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}" ABIEXTENSION = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${ABIEXTENSION_64}', '${ABIEXTENSION_32}' ,d)}" TARGET_FPU = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TARGET_FPU_64}', '${TARGET_FPU_32}' ,d)}" + +QEMU_MEM = "-m 512" +QEMU_MAHINE_SUBTYPE = "-machine virt" +QEMU_CPU_SUBTYPE = "-cpu cortex-a57" +QEMU_SECOND_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon" +QEMU_KERNEL_OPTIONS = "console=ttyAMA0,38400" +QEMU_UI_OPTIONS = ""
Signature · 1 line
2.7.4
RFC PATCH 5/8 arch-x86.inc: set vars for runqemu
In reply to Robert YangThese vars will be used when QEMU_BOOT_SUPPORTED = "1", and has no impact when "0".
--- meta/conf/machine/include/x86/arch-x86.inc | 6 ++++++ 1 file changed, 6 insertions(+)
meta/conf/machine/include/x86/arch-x86.inc +6 -0
@@ -51,3 +51,9 @@ TUNE_FEATURES_tune-x86-64-x32 = "mx32" BASE_LIB_tune-x86-64-x32 = "libx32" TUNE_PKGARCH_tune-x86-64-x32 = "x86_64_x32" PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "${TUNE_PKGARCH_tune-x86-64-x32}" + +QEMU_CPU_SUBTYPE = "${@bb.utils.contains('TUNE_FEATURES', 'm64', '-cpu core2duo', '', d)}" +QEMU_CPU_SUBTYPE_KVM = "${@bb.utils.contains('TUNE_FEATURES', 'm64', '-cpu kvm64', '', d)}" + +QEMU_CPU_SUBTYPE .= "${@bb.utils.contains('TUNE_FEATURES', 'm32', '-cpu qemu32', '', d)}" +QEMU_CPU_SUBTYPE_KVM .= "${@bb.utils.contains('TUNE_FEATURES', 'm32', '-cpu kvm32', '', d)}"
Signature · 1 line
2.7.4
RFC PATCH 6/8 arch-mips.inc: set vars for runqemu
In reply to Robert YangThese vars will be used when QEMU_BOOT_SUPPORTED = "1", and has no impact when "0".
--- meta/conf/machine/include/mips/arch-mips.inc | 5 +++++ 1 file changed, 5 insertions(+)
meta/conf/machine/include/mips/arch-mips.inc +5 -0
@@ -100,3 +100,8 @@ TUNE_FEATURES_tune-mips64el-nf = "n64" BASE_LIB_tune-mips64el-nf = "lib64" MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}" PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf" + +QEMU_MEM = "-m 256" +QEMU_MAHINE_SUBTYPE = "-machine malta" +QEMU_SYSTEM_OPTIONS = "-no-reboot" +QEMU_KERNEL_OPTIONS = "console=ttyS0 console=tty"
Signature · 1 line
2.7.4
RFC PATCH 7/8 arch-powerpc.inc: set vars for runqemu
In reply to Robert YangThese vars will be used when QEMU_BOOT_SUPPORTED = "1", and has no impact when "0".
--- meta/conf/machine/include/powerpc/arch-powerpc.inc | 5 +++++ 1 file changed, 5 insertions(+)
meta/conf/machine/include/powerpc/arch-powerpc.inc +5 -0
@@ -32,3 +32,8 @@ TUNE_FEATURES_tune-powerpc = "m32 fpu-hard" BASE_LIB_tune-powerpc = "lib" TUNE_PKGARCH_tune-powerpc = "powerpc" PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc" + +QEMU_MAHINE_SUBTYPE = "-machine mac99" +QEMU_CPU_SUBTYPE = "-cpu G4" +QEMU_SYSTEM_OPTIONS = "-no-reboot" +QEMU_KERNEL_OPTIONS = "console=ttyS0 console=tty"
Signature · 1 line
2.7.4
RFC PATCH 8/8 runqemu/runqemu-internal: refactor it
In reply to Robert Yang* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but runqemu can't, and we need edit runqemu/runqemu-internal a lot to support boot it.
* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED = "1" or "0"), and how to boot it, so we leave these settings in the machine's configuration.
- qemu-boot.bbclass will write machine's info to
${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it. - We need use "runqemu -m <machine>" rather than "runqemu <machine>" since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's extension.
- I have updated all the machine's configuration except qemush4, since I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot by new runqemu without any changes.
* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir
-t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg, hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
-V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable CPU required) -v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required) -a, support audio
-s, enable a serial console on /dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU
-b <bootparams> - specify custom kernel parameters during boot
-p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.
Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"
[YOCTO #4827]
--- scripts/runqemu | 603 ++++++++++++++--------------------------- scripts/runqemu-internal | 678 ++++++++++++++++------------------------------- 2 files changed, 428 insertions(+), 853 deletions(-)
scripts/runqemu +204 -399
@@ -2,7 +2,7 @@ # # Handle running OE images standalone with QEMU # -# Copyright (C) 2006-2011 Linux Foundation +# Copyright (C) 2006-2016 Linux Foundation # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License version 2 as
@@ -18,33 +18,35 @@ # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. usage() { - MYNAME=`basename $0` cat <<_EOF - -Usage: you can run this script with any valid combination -of the following environment variables (in any order): - KERNEL - the kernel image file to use - ROOTFS - the rootfs image file or nfsroot directory to use - MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified) - Simplified QEMU command-line options can be passed with: - nographic - disables video console - serial - enables a serial console on /dev/ttyS0 - kvm - enables KVM when running qemux86/qemux86-64 (VT-capable CPU required) - kvm-vhost - enables KVM with vhost support when running qemux86/qemux86-64 (VT-capable CPU required) - publicvnc - enable a VNC server open to all hosts - qemuparams="xyz" - specify custom parameters to QEMU - bootparams="xyz" - specify custom kernel parameters during boot +Usage: runqemu <options> + -m <machine>, specify machine + -k <kernel>, specify kernel + -r <rootfs>, specify disk image, rootfs or nfs dir + -t <fstype>, specify fstypes, supported types: + ext[234], jffs2, btrfs, cpio.gz(ramfs), cpio, hddimg, + hdddirect, vmdk, wic, qcow2, vdi + -n, nographic, disables video console + -K, enable KVM when running x86 and x86-64 (VT-capable CPU required) + -V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable CPU required) + -v, publicvnc - enable a VNC server open to all hosts + -u, slirp mode, use user mode networking (no root privilege is required) + -a, support audio + -s, enable a serial console on /dev/ttyS0 + -q <qemuparams> - specify custom parameters to QEMU + -b <bootparams> - specify custom kernel parameters during boot + -p <portnum>, tcp serial port number + -B <biosdir>, bios directory + -F <biosfilename>, bios filename. Examples: - $MYNAME qemuarm - $MYNAME qemux86-64 core-image-sato ext4 - $MYNAME qemux86-64 wic-image-minimal wic - $MYNAME path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial - $MYNAME qemux86 iso/hddimg/vmdk/qcow2/vdi/ramfs/cpio.gz... - $MYNAME qemux86 qemuparams="-m 256" - $MYNAME qemux86 bootparams="psplash=false" - $MYNAME path/to/<image>-<machine>.vmdk - $MYNAME path/to/<image>-<machine>.wic + runqemu -m qemuarm -n + runqemu -m qemuarm -t ext4 + runqemu -m qemux86-64 -r core-image-sato -t ext4 + runqemu -m qemux86 -r path/to/nfsrootdir/ + runqemu -r path/to/deploy/dir/image/file.vmdk + runqemu -m qemumips -q "-m 256" + runqemu -m qemuppc -b "psplash=false" _EOF exit 1 }
@@ -53,232 +55,192 @@ if [ "x$1" = "x" ]; then usage fi -error() { +error_help() { echo "Error: "$* usage } -MACHINE=${MACHINE:=""} -KERNEL=${KERNEL:=""} -ROOTFS=${ROOTFS:=""} -FSTYPE=${FSTYPE:=""} +error_exit() { + echo "Error: "$* + exit 1 +} + LAZY_ROOTFS="" SCRIPT_QEMU_OPT="" SCRIPT_QEMU_EXTRA_OPT="" SCRIPT_KERNEL_OPT="" SERIALSTDIO="" +SLIRP_ENABLED="" TCPSERIAL_PORTNUM="" -KVM_ENABLED="no" -KVM_ACTIVE="no" -VHOST_ENABLED="no" -VHOST_ACTIVE="no" -IS_VM="false" - -# Determine whether the file is a kernel or QEMU image, and set the -# appropriate variables -process_filename() { - filename=$1 - - # Extract the filename extension - EXT=`echo $filename | awk -F . '{ print \$NF }'` - case /$EXT/ in - /bin/) - # A file ending in .bin is a kernel - [ -z "$KERNEL" ] && KERNEL=$filename || \ - error "conflicting KERNEL args [$KERNEL] and [$filename]" - ;; - /ext[234]/|/jffs2/|/btrfs/) - # A file ending in a supportted fs type is a rootfs image - if [ -z "$FSTYPE" -o "$FSTYPE" = "$EXT" ]; then - FSTYPE=$EXT - ROOTFS=$filename - else - error "conflicting FSTYPE types [$FSTYPE] and [$EXT]" - fi - ;; - /hddimg/|/hdddirect/|/vmdk/|/wic/|/qcow2/|/vdi/) - FSTYPE=$EXT - VM=$filename - ROOTFS=$filename - IS_VM="true" - ;; - *) - error "unknown file arg [$filename]" - ;; +KVM_ENABLED="" +KVM_ACTIVE="" +VHOST_ENABLED="" +VHOST_ACTIVE="" +IS_VM="no" +# Export for qemu-system-foo +export QEMU_AUDIO_DRV="none" + +# Check whether it is a supported fstype. +check_fstype() { + case /$1/ in + /ext[234]/|/jffs2/|/btrfs/|/cpio.gz/|/cpio/) + : + ;; + /ramfs/) + FSTYPE="cpio.gz" + ;; + /hddimg/|/hdddirect/|/vmdk/|/wic/|/qcow2/|/vdi/|/iso/) + IS_VM="yes" + ;; + *) + error_exit "Unknown FSTYPE: $1" + ;; esac } -check_fstype_conflicts() { - if [ -z "$FSTYPE" -o "$FSTYPE" = "$1" ]; then - FSTYPE=$1 - else - error "conflicting FSTYPE types [$FSTYPE] and [$1]" - fi -} -# Parse command line args without requiring specific ordering. It's a -# bit more complex, but offers a great user experience. -while true; do - arg=${1} - case "$arg" in - "qemux86" | "qemux86-64" | "qemuarm" | "qemuarm64" | "qemumips" | "qemumipsel" | \ - "qemumips64" | "qemush4" | "qemuppc" | "qemumicroblaze" | "qemuzynq") - [ -z "$MACHINE" -o "$MACHINE" = "$arg" ] && MACHINE=$arg || \ - error "conflicting MACHINE types [$MACHINE] and [$arg]" - ;; - "ext"[234] | "jffs2" | "nfs" | "btrfs") - check_fstype_conflicts $arg - ;; - "hddimg" | "hdddirect" | "wic" | "vmdk" | "qcow2" | "vdi" | "iso") - check_fstype_conflicts $arg - IS_VM="true" - ;; - "ramfs" | "cpio.gz") - FSTYPE=cpio.gz - ;; - "nographic") - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -nographic" - SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0" - ;; - "serial") - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -serial stdio" - SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0" - SERIALSTDIO="1" - ;; - "tcpserial="*) - TCPSERIAL_PORTNUM=${arg##tcpserial=} - ;; - "biosdir="*) - CUSTOMBIOSDIR="${arg##biosdir=}" - ;; - "biosfilename="*) - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -bios ${arg##biosfilename=}" - ;; - "qemuparams="*) - SCRIPT_QEMU_EXTRA_OPT="${arg##qemuparams=}" - - # Warn user if they try to specify serial or kvm options - # to use simplified options instead - serial_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-serial\)'` - kvm_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-enable-kvm\)'` - vga_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-vga\)'` - [ ! -z "$serial_option" -o ! -z "$kvm_option" ] && \ - echo "Please use simplified serial or kvm options instead" - ;; - "bootparams="*) - SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT ${arg##bootparams=}" - ;; - "audio") - if [ "x$MACHINE" = "xqemux86" -o "x$MACHINE" = "xqemux86-64" ]; then - echo "Enabling audio in qemu." - echo "Please install snd_intel8x0 or snd_ens1370 driver in linux guest." - QEMU_AUDIO_DRV="alsa" - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -soundhw ac97,es1370" - fi - ;; - "kvm") - KVM_ENABLED="yes" - KVM_CAPABLE=`grep -q 'vmx\|svm' /proc/cpuinfo && echo 1` - ;; - "kvm-vhost") - KVM_ENABLED="yes" - KVM_CAPABLE=`grep -q 'vmx\|svm' /proc/cpuinfo && echo 1` - VHOST_ENABLED="yes" - ;; - "slirp") - SLIRP_ENABLED="yes" - ;; - "publicvnc") - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -vnc :0" - ;; - *-image*) - [ -z "$ROOTFS" ] || \ - error "conflicting ROOTFS args [$ROOTFS] and [$arg]" - if [ -f "$arg" ]; then - process_filename $arg - elif [ -d "$arg" ]; then - # Handle the case where the nfsroot dir has -image- - # in the pathname - echo "Assuming $arg is an nfs rootfs" - FSTYPE=nfs - ROOTFS=$arg - else - ROOTFS=$arg - LAZY_ROOTFS="true" - fi - ;; - "") break ;; - *) - # A directory name is an nfs rootfs - if [ -d "$arg" ]; then - echo "Assuming $arg is an nfs rootfs" - if [ -z "$FSTYPE" -o "$FSTYPE" = "nfs" ]; then - FSTYPE=nfs - else - error "conflicting FSTYPE types [$arg] and nfs" - fi - - if [ -z "$ROOTFS" ]; then - ROOTFS=$arg - else - error "conflicting ROOTFS args [$ROOTFS] and [$arg]" - fi - elif [ -f "$arg" ]; then - process_filename $arg - else - error "unable to classify arg [$arg]" - fi - ;; +while getopts "m:t:k:aKVhvsnuq:b:r:p:B:F:" OPT; do + case $OPT in + m) + MACHINE="$OPTARG" + ;; + k) + KERNEL="$OPTARG" + if [ ! -e "$KERNEL" ]; then + error_exit "kernel: \"$KERNEL\" not found!" + fi + ;; + t) + FSTYPE="$OPTARG" + check_fstype $FSTYPE + ;; + K|V) + KVM_ENABLED="yes" + KVM_CAPABLE=`grep -q 'vmx\|svm' /proc/cpuinfo && echo 1` + [ "$OPT" = "V" ] && VHOST_ENABLED="yes" + ;; + s) + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -nographic -serial stdio" + SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0" + SERIALSTDIO="1" + ;; + n) + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -nographic" + SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT console=ttyS0" + ;; + q) + SCRIPT_QEMU_EXTRA_OPT="$OPTARG" + # Warn user if they try to specify serial or kvm options + # to use simplified options instead + serial_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-serial\)'` + kvm_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-enable-kvm\)'` + vga_option=`expr "$SCRIPT_QEMU_EXTRA_OPT" : '.*\(-vga\)'` + [ ! -z "$serial_option" -o ! -z "$kvm_option" ] && \ + echo "Please use simplified -s or -K options instead" + ;; + b) + SCRIPT_KERNEL_OPT="$SCRIPT_KERNEL_OPT $OPTARG" + ;; + v) + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -vnc :0" + ;; + r) + if [ -d "$OPTARG" ]; then + echo "Assuming $OPTARG is an nfs rootfs" + FSTYPE=nfs + elif [ -e "$OPTARG" ]; then + # Extract the extension + EXT=`echo $OPTARG | awk -F . '{ print \$NF }'` + FSTYPE=$EXT + check_fstype $FSTYPE + else + LAZY_ROOTFS="yes" + fi + ROOTFS="$OPTARG" + ;; + u) + SLIRP_ENABLED="yes" + ;; + p) + TCPSERIAL_PORTNUM="$OPTARG" + ;; + a) + export QEMU_AUDIO_DRV="alsa" + ;; + B) + CUSTOMBIOSDIR="$OPTARG" + ;; + F) + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -bios $OPTARG" + ;; + *) + usage + ;; esac - shift done -if [ ! -c /dev/net/tun ] ; then - echo "TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)" - exit 1 -elif [ ! -w /dev/net/tun ] ; then - echo "TUN control device /dev/net/tun is not writable, please fix (e.g. sudo chmod 666 /dev/net/tun)" - exit 1 +if [ ! -z "$MACHINE" ]; then + if [ -z "$DEPLOY_DIR_IMAGE" ]; then + eval `MACHINE=$MACHINE bitbake -e | grep -m 1 '^DEPLOY_DIR_IMAGE="'` + fi + runqemu_file=$DEPLOY_DIR_IMAGE/qemu-boot +elif [ -e "$KERNEL" ]; then + runqemu_file=$(dirname $KERNEL)/qemu-boot +elif [ -e "$ROOTFS" -a ! -d "$ROOTFS" ]; then + runqemu_file=$(dirname $ROOTFS)/qemu-boot fi -# Report errors for missing combinations of options -if [ -z "$MACHINE" -a -z "$KERNEL" -a -z "$VM" -a "$FSTYPE" != "wic" ]; then - error "you must specify at least a MACHINE or KERNEL argument" +if [ -z "$runqemu_file" ]; then + echo "Need one of -m, -k or -r!" fi -if [ "$FSTYPE" = "nfs" -a -z "$ROOTFS" ]; then - error "NFS booting without an explicit ROOTFS path is not yet supported" + +if [ ! -e "$runqemu_file" ]; then + error_exit "$runqemu_file is not found, make sure you have built the image, and the machine is supported by qemu." fi -if [ -z "$MACHINE" ]; then - if [ "$IS_VM" = "true" ]; then - [ "x$FSTYPE" = "xwic" ] && filename=$ROOTFS || filename=$VM - MACHINE=`basename $filename | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'` - if [ -z "$MACHINE" ]; then - error "Unable to set MACHINE from image filename [$VM]" - fi - echo "Set MACHINE to [$MACHINE] based on image [$VM]" +. $runqemu_file || exit 1 + +KERNEL=${KERNEL:=$DEPLOY_DIR_IMAGE/$QEMU_DEFAULT_KERNEL} +FSTYPE=${FSTYPE:=$QEMU_DEFAULT_FSTYPE} + +if [ "$QEMU_AUDIO_DRV" = "alsa" ]; then + if [ "$TUNE_ARCH" = "x86" -o "$TUNE_ARCH" = "x86_64" ]; then + echo "Enabling audio in qemu." + echo "Please install snd_intel8x0 or snd_ens1370 driver in linux guest." + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -soundhw ac97,es1370" else - MACHINE=`basename $KERNEL | sed -n 's/.*\(qemux86-64\|qemux86\|qemuarm64\|qemuarm\|qemumips64\|qemumips\|qemuppc\|qemush4\).*/\1/p'` - if [ -z "$MACHINE" ]; then - error "Unable to set MACHINE from kernel filename [$KERNEL]" - fi - echo "Set MACHINE to [$MACHINE] based on kernel [$KERNEL]" + error_exit "$TUNE_ARCH doesn't support audio" fi fi +# Report errors for missing combinations of options +if [ "$FSTYPE" = "nfs" -a -z "$ROOTFS" ]; then + error_exit "NFS booting without an explicit ROOTFS path is not yet supported" +fi + +if [ ! -c /dev/net/tun ] ; then + error_exit "TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)" +elif [ ! -w /dev/net/tun ] ; then + error_exit "TUN control device /dev/net/tun is not writable, please fix (e.g. sudo chmod 666 /dev/net/tun)" +fi + YOCTO_KVM_WIKI="https://wiki.yoctoproject.org/wiki/How_to_enable_KVM_for_Poky_qemu" YOCTO_PARAVIRT_KVM_WIKI="https://wiki.yoctoproject.org/wiki/Running_an_x86_Yocto_Linux_image_under_QEMU_KVM" # Detect KVM configuration if [ "x$KVM_ENABLED" = "xyes" ]; then if [ -z "$KVM_CAPABLE" ]; then echo "You are trying to enable KVM on a cpu without VT support." - echo "Remove kvm from the command-line, or refer" + echo "Remove -K from the command-line, or refer" echo "$YOCTO_KVM_WIKI"; exit 1; fi - if [ "x$MACHINE" != "xqemux86" -a "x$MACHINE" != "xqemux86-64" ]; then - echo "KVM only support x86 & x86-64. Remove kvm from the command-line"; - exit 1; - fi + case $TUNE_ARCH in + x86|i[3456]86|x86_64) + echo "Enabling KVM support" + ;; + *) + error_exit "KVM only support x86 & x86-64. Remove -K from the command-line"; + ;; + esac if [ ! -e /dev/kvm ]; then echo "Missing KVM device. Have you inserted kvm modules?" echo "For further help see:"
@@ -313,228 +275,71 @@ if [ "x$KVM_ENABLED" = "xyes" ]; then fi fi -machine2=`echo $MACHINE | tr 'a-z' 'A-Z' | sed 's/-/_/'` -# MACHINE is now set for all cases - -# Defaults used when these vars need to be inferred -QEMUX86_DEFAULT_KERNEL=bzImage-qemux86.bin -QEMUX86_DEFAULT_FSTYPE=ext4 - -QEMUX86_64_DEFAULT_KERNEL=bzImage-qemux86-64.bin -QEMUX86_64_DEFAULT_FSTYPE=ext4 - -QEMUARM_DEFAULT_KERNEL=zImage-qemuarm.bin -QEMUARM_DEFAULT_FSTYPE=ext4 - -QEMUARM64_DEFAULT_KERNEL=Image-qemuarm64.bin -QEMUARM64_DEFAULT_FSTYPE=ext4 - -QEMUMIPS_DEFAULT_KERNEL=vmlinux-qemumips.bin -QEMUMIPS_DEFAULT_FSTYPE=ext4 - -QEMUMIPSEL_DEFAULT_KERNEL=vmlinux-qemumipsel.bin -QEMUMIPSEL_DEFAULT_FSTYPE=ext4 - -QEMUMIPS64_DEFAULT_KERNEL=vmlinux-qemumips64.bin -QEMUMIPS64_DEFAULT_FSTYPE=ext4 - -QEMUSH4_DEFAULT_KERNEL=vmlinux-qemumips.bin -QEMUSH4_DEFAULT_FSTYPE=ext4 - -QEMUPPC_DEFAULT_KERNEL=vmlinux-qemuppc.bin -QEMUPPC_DEFAULT_FSTYPE=ext4 - -QEMUMICROBLAZE_DEFAULT_KERNEL=linux.bin.ub -QEMUMICROBLAZE_DEFAULT_FSTYPE=cpio - -QEMUZYNQ_DEFAULT_KERNEL=uImage -QEMUZYNQ_DEFAULT_FSTYPE=cpio - -setup_path_vars() { - if [ -z "$OE_TMPDIR" ] ; then - PATHS_REQUIRED=true - elif [ "$1" = "1" -a -z "$DEPLOY_DIR_IMAGE" ] ; then - PATHS_REQUIRED=true - else - PATHS_REQUIRED=false - fi - - if [ "$PATHS_REQUIRED" = "true" ]; then - # Try to get the variable values from bitbake - type -P bitbake &>/dev/null || { - echo "In order for this script to dynamically infer paths"; - echo "to kernels or filesystem images, you either need"; - echo "bitbake in your PATH or to source oe-init-build-env"; - echo "before running this script" >&2; - exit 1; } - - # We have bitbake in PATH, get the variable values from bitbake - BITBAKE_ENV_TMPFILE=`mktemp --tmpdir runqemu.XXXXXXXXXX` - if [ "$?" != "0" ] ; then - echo "Error: mktemp failed for bitbake environment output" - exit 1 - fi - - MACHINE=$MACHINE bitbake -e > $BITBAKE_ENV_TMPFILE - if [ -z "$OE_TMPDIR" ] ; then - OE_TMPDIR=`sed -n 's/^TMPDIR=\"\(.*\)\"/\1/p' $BITBAKE_ENV_TMPFILE` - fi - if [ -z "$DEPLOY_DIR_IMAGE" ] ; then - DEPLOY_DIR_IMAGE=`sed -n 's/^DEPLOY_DIR_IMAGE=\"\(.*\)\"/\1/p' $BITBAKE_ENV_TMPFILE` - fi - if [ -z "$OE_TMPDIR" ]; then - # Check for errors from bitbake that the user needs to know about - BITBAKE_OUTPUT=`cat $BITBAKE_ENV_TMPFILE | wc -l` - if [ "$BITBAKE_OUTPUT" -eq "0" ]; then - echo "Error: this script needs to be run from your build directory, or you need" - echo "to explicitly set OE_TMPDIR and DEPLOY_DIR_IMAGE in your environment" - else - echo "There was an error running bitbake to determine TMPDIR" - echo "Here is the output from 'bitbake -e':" - cat $BITBAKE_ENV_TMPFILE - fi - rm $BITBAKE_ENV_TMPFILE - exit 1 - fi - rm $BITBAKE_ENV_TMPFILE - fi -} - -setup_sysroot() { - # Toolchain installs set up $OECORE_NATIVE_SYSROOT in their - # environment script. If that variable isn't set, we're - # either in an in-tree build scenario or the environment - # script wasn't source'd. - if [ -z "$OECORE_NATIVE_SYSROOT" ]; then - setup_path_vars - BUILD_ARCH=`uname -m` - BUILD_OS=`uname | tr '[A-Z]' '[a-z]'` - BUILD_SYS="$BUILD_ARCH-$BUILD_OS" - - OECORE_NATIVE_SYSROOT=$OE_TMPDIR/sysroots/$BUILD_SYS - fi - - # Some recipes store the BIOS under $OE_TMPDIR/sysroots/$MACHINE, - # now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching - # BIOS, VGA BIOS and keymaps. - if [ -z "$OECORE_MACHINE_SYSROOT" ]; then - OECORE_MACHINE_SYSROOT=$OE_TMPDIR/sysroots/$MACHINE - fi -} - # Locate a rootfs image to boot which matches our expected # machine and fstype. findimage() { - where=$1 - machine=$2 - extension=$3 + machine=$1 + ext=$2 # Sort rootfs candidates by modification time - the most # recently created one is the one we most likely want to boot. - filename=`ls -t1 $where/*-image*$machine.$extension 2>/dev/null | head -n1` + filename=`ls -t1 $DEPLOY_DIR_IMAGE/*-image*$machine.$ext 2>/dev/null | head -n1` if [ "x$filename" != "x" ]; then ROOTFS=$filename return fi - echo "Couldn't find a $machine rootfs image in $where." - exit 1 + error_exit "Couldn't find a $ext rootfs image in $DEPLOY_DIR_IMAGE" } -if [ -e "$ROOTFS" -a -z "$FSTYPE" ]; then - # Extract the filename extension - EXT=`echo $ROOTFS | awk -F . '{ print \$NF }'` - if [ "x$EXT" = "xext2" -o "x$EXT" = "xext3" -o \ - "x$EXT" = "xjffs2" -o "x$EXT" = "xbtrfs" -o \ - "x$EXT" = "xext4" ]; then - FSTYPE=$EXT - else - echo "Note: Unable to determine filesystem extension for $ROOTFS" - echo "We will use the default FSTYPE for $MACHINE" - # ...which is done further below... - fi -fi - -if [ -z "$KERNEL" -a "$IS_VM" = "false" ]; then \ - setup_path_vars 1 - eval kernel_file=\$${machine2}_DEFAULT_KERNEL - KERNEL=$DEPLOY_DIR_IMAGE/$kernel_file - - if [ -z "$KERNEL" ]; then - error "Unable to determine default kernel for MACHINE [$MACHINE]" - fi -fi -# KERNEL is now set for all cases - -if [ -z "$FSTYPE" ]; then - eval FSTYPE=\$${machine2}_DEFAULT_FSTYPE - - if [ -z "$FSTYPE" ]; then - error "Unable to determine default fstype for MACHINE [$MACHINE]" - fi -fi - -# FSTYPE is now set for all cases - # Handle cases where a ROOTFS type is given instead of a filename, e.g. # core-image-sato -if [ "$LAZY_ROOTFS" = "true" ]; then - setup_path_vars 1 +if [ "$LAZY_ROOTFS" = "yes" ]; then echo "Assuming $ROOTFS really means $DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE" - if [ "$IS_VM" = "true" ]; then - VM=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE - else - ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE - fi + ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE fi - if [ -z "$ROOTFS" ]; then - setup_path_vars 1 - T=$DEPLOY_DIR_IMAGE - eval rootfs_list=\$${machine2}_DEFAULT_ROOTFS - findimage $T $MACHINE $FSTYPE - + findimage $MACHINE $FSTYPE if [ -z "$ROOTFS" ]; then - error "Unable to determine default rootfs for MACHINE [$MACHINE]" - elif [ "$IS_VM" = "true" ]; then - VM=$ROOTFS + error_help "Unable to determine default rootfs for MACHINE [$MACHINE]" fi fi # ROOTFS is now set for all cases, now expand it to be an absolute path, it should exist at this point - ROOTFS=`readlink -f $ROOTFS` +if [ ! -e "$ROOTFS" ]; then + error_exit "Error: Image file $ROOTFS doesn't exist" +fi echo "" echo "Continuing with the following parameters:" -if [ "$IS_VM" = "false" ]; then +if [ "$IS_VM" = "no" ]; then + if [ ! -f "$KERNEL" ]; then + error_exit "Error: Kernel image file $KERNEL doesn't exist" + fi echo "KERNEL: [$KERNEL]" echo "ROOTFS: [$ROOTFS]" else - echo "VM: [$VM]" + echo "VM: [$ROOTFS]" fi -echo "FSTYPE: [$FSTYPE]" - -setup_sysroot -# OECORE_NATIVE_SYSROOT and OECORE_MACHINE_SYSROOT are now set for all cases INTERNAL_SCRIPT="$0-internal" if [ ! -f "$INTERNAL_SCRIPT" -o ! -r "$INTERNAL_SCRIPT" ]; then -INTERNAL_SCRIPT=`which runqemu-internal` + INTERNAL_SCRIPT=`which runqemu-internal` fi # Specify directory for BIOS, VGA BIOS and keymaps if [ ! -z "$CUSTOMBIOSDIR" ]; then - if [ -d "$OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" ]; then - echo "Assuming biosdir is $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" - elif [ -d "$OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" ]; then - echo "Assuming biosdir is $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" - SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" + if [ -d "$STAGING_DIR_NATIVE/$CUSTOMBIOSDIR" ]; then + echo "Assuming biosdir is $STAGING_DIR_NATIVE/$CUSTOMBIOSDIR" + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $STAGING_DIR_NATIVE/$CUSTOMBIOSDIR" + elif [ -d "$STAGING_DIR_HOST/$CUSTOMBIOSDIR" ]; then + echo "Assuming biosdir is $STAGING_DIR_HOST/$CUSTOMBIOSDIR" + SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $STAGING_DIR_HOST/$CUSTOMBIOSDIR" else if [ ! -d "$CUSTOMBIOSDIR" ]; then echo "Custom BIOS directory not found. Tried: $CUSTOMBIOSDIR" - echo "and $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" - echo "and $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" + echo "and $STAGING_DIR_NATIVE/$CUSTOMBIOSDIR" + echo "and $STAGING_DIR_HOST/$CUSTOMBIOSDIR" exit 1; fi echo "Assuming biosdir is $CUSTOMBIOSDIR"
scripts/runqemu-internal +224 -454
837 lines not on this page · raw message
Signature · 1 line
2.7.4
Quoted 4 lines · Robert Yang
Hello,
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
Hi Robert,
This is great! So I went ahead and tested out converting the qemumicroblaze and qemuzynq machines to work with these changes, as well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.
Everything seems to work well, I was able to boot all the meta-xilinx QEMU machines. Although there were a couple of things that I noticed when getting these machines going:
QEMU_DTB, should probably be named QEMU_DTB_OPTIONS or alternatively can just be included as part of QEMU_OPTIONS from within the bitbake environment. But it would be nice to be able to just define the name of the DTB and the runqemu scripts do the finding (like for kernel and rootfs).
The "-s" and the "-n" runqemu options add "console=ttyS0" to the kernel options regardless of target. For qemuzynq you might have noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).
It is probably worth pulling in serial kernel options from a bitbake variable.
Regards,
Nathan
Quoted 108 lines
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such asQEMU_SYSTEM_OPTIONSandQEMU_SECOND_SERIAL_OPT
* More testing=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but runqemu can't, and we need edit runqemu/runqemu-internal a lot to support boot it.* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED= "1" or "0"), and how to boot it, so we leave these settings in the machine's configuration.
- qemu-boot.bbclass will write machine's info to${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.- We need use "runqemu -m <machine>" rather than "runqemu <machine>" since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's extension.
- I have updated all the machine's configuration except qemush4, since I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot by new runqemu without any changes.
- Added help info for supported options such as slirp and audio.* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir
-t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs,cpio.gz(ramfs), cpio, hddimg, hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
-V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable CPU required) -v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required) -a, support audio
-s, enable a serial console on/dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU
-b <bootparams> - specify custom kernel parameters during boot
-p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"// Robert
The following changes since commit
ece101be5158beee709cdfbb85ecdbdc8d9fb864:test-empty-image: Fix
LIC_FILES_CHKSUMtypo (2016-05-06 10:47:59 +0100)are available in the git repository at:
git://git.openembedded.org/openembedded-core-contribrbt/runqemu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemuRobert Yang (8):
qemu-boot.bbclass: add it for runqemu
qemu.inc: setQEMU_BOOT_SUPPORTEDto 1
qemuarm.conf: set vars for runqemu
arch-arm64.inc: set vars for runqemu
arch-x86.inc: set vars for runqemu
arch-mips.inc: set vars for runqemu
arch-powerpc.inc: set vars for runqemu
runqemu/runqemu-internal: refactor itmeta/classes/image.bbclass | 3 + meta/classes/qemu-boot.bbclass | 39 ++ meta/conf/bitbake.conf | 3 + meta/conf/machine/include/arm/arch-arm64.inc | 7 + meta/conf/machine/include/arm/arch-armv6.inc | 2 + meta/conf/machine/include/mips/arch-mips.inc | 5 + meta/conf/machine/include/powerpc/arch-powerpc.inc | 5 + meta/conf/machine/include/qemu.inc | 2 + meta/conf/machine/include/tune-cortexa8.inc | 2 + meta/conf/machine/include/x86/arch-x86.inc | 6 + meta/conf/machine/qemuarm.conf | 3 + scripts/runqemu | 603 +++++++----------- scripts/runqemu-internal | 678 +++++++-------------- 13 files changed, 505 insertions(+), 853 deletions(-) create mode 100644 meta/classes/qemu-boot.bbclass--
2.7.4--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Hi Nathan,
Thanks, but I'm sorry to say that this is only a RFC, we may change it a lot, I will talk with RP, and let you when we have progresses.
// Robert
Quoted 143 lines · Nathan Rossi
Quoted 4 lines · Robert Yang
Hello,
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
Hi Robert,
This is great! So I went ahead and tested out converting the qemumicroblaze and qemuzynq machines to work with these changes, as well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.Everything seems to work well, I was able to boot all the meta-xilinx QEMU machines. Although there were a couple of things that I noticed when getting these machines going:
QEMU_DTB, should probably be namedQEMU_DTB_OPTIONSor alternatively can just be included as part ofQEMU_OPTIONSfrom within the bitbake environment. But it would be nice to be able to just define the name of the DTB and the runqemu scripts do the finding (like for kernel and rootfs).The "-s" and the "-n" runqemu options add "console=ttyS0" to the kernel options regardless of target. For qemuzynq you might have noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).
It is probably worth pulling in serial kernel options from a bitbake variable.Regards,
NathanQuoted 108 lines
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such asQEMU_SYSTEM_OPTIONSandQEMU_SECOND_SERIAL_OPT
* More testing=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but runqemu can't, and we need edit runqemu/runqemu-internal a lot to support boot it.* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED= "1" or "0"), and how to boot it, so we leave these settings in the machine's configuration.
- qemu-boot.bbclass will write machine's info to${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.- We need use "runqemu -m <machine>" rather than "runqemu <machine>" since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's extension.
- I have updated all the machine's configuration except qemush4, since I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot by new runqemu without any changes.
- Added help info for supported options such as slirp and audio.* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir
-t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs,cpio.gz(ramfs), cpio, hddimg, hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required)
-V, enables KVM with VHOST support when running x86 and x86-64 (VT-capable CPU required) -v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required) -a, support audio
-s, enable a serial console on/dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU
-b <bootparams> - specify custom kernel parameters during boot
-p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"// Robert
The following changes since commit
ece101be5158beee709cdfbb85ecdbdc8d9fb864:test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)are available in the git repository at:
git://git.openembedded.org/openembedded-core-contribrbt/runqemu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemuRobert Yang (8):
qemu-boot.bbclass: add it for runqemu
qemu.inc: setQEMU_BOOT_SUPPORTEDto 1
qemuarm.conf: set vars for runqemu
arch-arm64.inc: set vars for runqemu
arch-x86.inc: set vars for runqemu
arch-mips.inc: set vars for runqemu
arch-powerpc.inc: set vars for runqemu
runqemu/runqemu-internal: refactor itmeta/classes/image.bbclass | 3 + meta/classes/qemu-boot.bbclass | 39 ++ meta/conf/bitbake.conf | 3 + meta/conf/machine/include/arm/arch-arm64.inc | 7 + meta/conf/machine/include/arm/arch-armv6.inc | 2 + meta/conf/machine/include/mips/arch-mips.inc | 5 + meta/conf/machine/include/powerpc/arch-powerpc.inc | 5 + meta/conf/machine/include/qemu.inc | 2 + meta/conf/machine/include/tune-cortexa8.inc | 2 + meta/conf/machine/include/x86/arch-x86.inc | 6 + meta/conf/machine/qemuarm.conf | 3 + scripts/runqemu | 603 +++++++----------- scripts/runqemu-internal | 678 +++++++-------------- 13 files changed, 505 insertions(+), 853 deletions(-)create mode 100644 meta/classes/qemu-boot.bbclass
--
2.7.4--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 4 lines · Robert Yang
Hi Nathan,
Thanks, but I'm sorry to say that this is only a RFC, we may change it a lot, I will talk with RP, and let you when we have progresses.
Oonce we change it a lot, for example, change runqemu to use python rather than shell script, your current work based on these patches may not work:-(, I will let you know once we have final decisions.
// Robert
Quoted 151 lines
// Robert
Quoted 147 lines · Nathan Rossi
Quoted 4 lines · Robert Yang
Hello,
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
Hi Robert,
This is great! So I went ahead and tested out converting the qemumicroblaze and qemuzynq machines to work with these changes, as well as some additional machines. Here is a meta-xilinx branch
(https://github.com/nathanrossi/meta-xilinx/tree/nrossi/runqemu-rfc)
with these changes for anyone who is curious.Everything seems to work well, I was able to boot all the meta-xilinx QEMU machines. Although there were a couple of things that I noticed when getting these machines going:
QEMU_DTB, should probably be namedQEMU_DTB_OPTIONSor alternatively can just be included as part ofQEMU_OPTIONSfrom within the bitbake environment. But it would be nice to be able to just define the name of the DTB and the runqemu scripts do the finding (like for kernel and rootfs).The "-s" and the "-n" runqemu options add "console=ttyS0" to the kernel options regardless of target. For qemuzynq you might have noticed the sed expression that overrides it previously
(http://git.openembedded.org/openembedded-core/tree/scripts/runqemu-internal#n494).It is probably worth pulling in serial kernel options from a bitbake variable.
Regards,
NathanQuoted 111 lines
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such asQEMU_SYSTEM_OPTIONSandQEMU_SECOND_SERIAL_OPT
* More testing=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but runqemu can't, and we need edit runqemu/runqemu-internal a lot to support boot it.* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED= "1" or "0"), and how to boot it, so we leave these settings in the machine's configuration.
- qemu-boot.bbclass will write machine's info to${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.- We need use "runqemu -m <machine>" rather than "runqemu <machine>" since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's extension.
- I have updated all the machine's configuration except qemush4, since I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot by new runqemu without any changes.
- Added help info for supported options such as slirp and audio.* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir
-t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs,cpio.gz(ramfs), cpio, hddimg, hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU required) -V, enables KVM with VHOST support when running x86 and x86-64
(VT-capable CPU required)
-v, publicvnc - enable a VNC server open to all hosts
-u, slirp mode, use user mode networking (no root privilege is required) -a, support audio
-s, enable a serial console on/dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU
-b <bootparams> - specify custom kernel parameters during boot -p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"// Robert
The following changes since commit
ece101be5158beee709cdfbb85ecdbdc8d9fb864:test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)are available in the git repository at:
git://git.openembedded.org/openembedded-core-contribrbt/runqemuhttp://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/runqemu
Robert Yang (8):
qemu-boot.bbclass: add it for runqemu
qemu.inc: setQEMU_BOOT_SUPPORTEDto 1
qemuarm.conf: set vars for runqemu
arch-arm64.inc: set vars for runqemu
arch-x86.inc: set vars for runqemu
arch-mips.inc: set vars for runqemu
arch-powerpc.inc: set vars for runqemu
runqemu/runqemu-internal: refactor itmeta/classes/image.bbclass | 3 + meta/classes/qemu-boot.bbclass | 39 ++ meta/conf/bitbake.conf | 3 + meta/conf/machine/include/arm/arch-arm64.inc | 7 + meta/conf/machine/include/arm/arch-armv6.inc | 2 + meta/conf/machine/include/mips/arch-mips.inc | 5 + meta/conf/machine/include/powerpc/arch-powerpc.inc | 5 + meta/conf/machine/include/qemu.inc | 2 + meta/conf/machine/include/tune-cortexa8.inc | 2 + meta/conf/machine/include/x86/arch-x86.inc | 6 + meta/conf/machine/qemuarm.conf | 3 + scripts/runqemu | 603 +++++++----------- scripts/runqemu-internal | 678 +++++++-------------- 13 files changed, 505 insertions(+), 853 deletions(-)create mode 100644 meta/classes/qemu-boot.bbclass
--
2.7.4--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 10 lines · Robert Yang
Quoted 5 lines · Robert Yang
Hi Nathan,
Thanks, but I'm sorry to say that this is only a RFC, we may change it a lot, I will talk with RP, and let you when we have progresses.
Oonce we change it a lot, for example, change runqemu to use python rather than shell script, your current work based on these patches may not work:-(, I will let you know once we have final decisions.
Any word on what direction these patches will take? I'm also looking to make use of them in the near future, but will hold off if they will change so significantly.
Cheers,
Andrew
Hi Robert,
Quoted 68 lines · Robert Yang
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such asQEMU_SYSTEM_OPTIONSandQEMU_SECOND_SERIAL_OPT
* More testing=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but
runqemu
can't, and we need edit runqemu/runqemu-internal a lot to support
boot
it.* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED= "1"
or
"0"), and how to boot it, so we leave these settings in the
machine's
configuration.
- qemu-boot.bbclass will write machine's info to${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.- We need use "runqemu -m <machine>" rather than "runqemu
<machine>"
since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's
extension.
- I have updated all the machine's configuration except qemush4,
since
I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot
by
new runqemu without any changes.
- Added help info for supported options such as slirp and audio.* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir -t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs,cpio.gz(ramfs), cpio,
hddimg,
hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU
required)
-V, enables KVM with VHOST support when running x86 and x86-64
(VT-capable CPU required)
-v, publicvnc - enable a VNC server open to all hosts -u, slirp mode, use user mode networking (no root privilege is
required)
-a, support audio
-s, enable a serial console on/dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU -b <bootparams> - specify custom kernel parameters during boot -p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.
Quoted 8 lines
Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"
Sorry about not responding to this before now. My concerns:
a) The commandline structure is changing and I'm not sure I like the new one or believe its an improvement. This is particularly problematic from a documentation perspective. Is there a way to preserve the existing syntax?
b) The question of python verses shell. I'm leaning towards making this a python script rather than shell at this point. It would mean you'd need python to run the scripts but we already need that for a variety of other tools so in general I think I prefer that. We do need to make sure the new python version supports what the current shell script does though.
c) I don't think qemu-boot should be added be hardcoded into image.bbclass, we need to find a better way to do this.
d) I think we need to document the new API/variables somewhere so that we don't just have a random ever changing set of variables but some kind of standard we're trying to encourage.
Cheers,
Richard
Quoted 80 lines · Richard Purdie
Hi Robert,
Quoted 68 lines · Robert Yang
This is still WIP, I send this out to make sure that I won't walk on wrong way too far. Please feel free to give any comments.
TODO:
* Update the one which uses runqemu, such as oeqa
* Boot EFI image
* Boot multilib image such as lib32-foo
* Change the vars name such asQEMU_SYSTEM_OPTIONSandQEMU_SECOND_SERIAL_OPT
* More testing=== Taken from patch 8/8's commit message:
* Why refactor
The old runqemu had hardcoded machine knowledge, which limited its usage, for example, qemu-system-foo can boot the target, but
runqemu
can't, and we need edit runqemu/runqemu-internal a lot to support
boot
it.* Brief introduction on implemention
The basic thought is that, machine/bsp developer knows clearly on whether qemu can boot the target or not (QEMU_BOOT_SUPPORTED= "1"
or
"0"), and how to boot it, so we leave these settings in the
machine's
configuration.
- qemu-boot.bbclass will write machine's info to${DEPLOY_DIR_IMAGE}/qemu-boot, and runqemu will invoke it.- We need use "runqemu -m <machine>" rather than "runqemu
<machine>"
since the scripts knows nothing about machine any more, and the similar to other old options, this is good for future's
extension.
- I have updated all the machine's configuration except qemush4,
since
I can't find this machine anywhere.
- Several machines such as genericx86 and genericx86-64 can be boot
by
new runqemu without any changes.
- Added help info for supported options such as slirp and audio.* Usage
Usage: runqemu <options>
-m <machine>, specify machine
-k <kernel>, specify kernel
-r <rootfs>, specify disk image, rootfs or nfs dir -t <fstype>, specify fstypes, supported types:
ext[234], jffs2, btrfs,cpio.gz(ramfs), cpio,
hddimg,
hdddirect, vmdk, wic, qcow2, vdi
-n, nographic, disables video console
-K, enable KVM when running x86 and x86-64 (VT-capable CPU
required)
-V, enables KVM with VHOST support when running x86 and x86-64
(VT-capable CPU required)
-v, publicvnc - enable a VNC server open to all hosts -u, slirp mode, use user mode networking (no root privilege is
required)
-a, support audio
-s, enable a serial console on/dev/ttyS0
-q <qemuparams> - specify custom parameters to QEMU -b <bootparams> - specify custom kernel parameters during boot -p <portnum>, tcp serial port number
-B <biosdir>, bios directory
-F <biosfilename>, bios filename.Quoted 8 lines
Examples:
runqemu -m qemuarm -n
runqemu -m qemuarm -t ext4
runqemu -m qemux86-64 -r core-image-sato -t ext4 runqemu -m qemux86 -r path/to/nfsrootdir/ runqemu -r path/to/deploy/dir/image/file.vmdk runqemu -m qemumips -q "-m 256"
runqemu -m qemuppc -b "psplash=false"
Quoted 6 lines
Sorry about not responding to this before now. My concerns:
a) The commandline structure is changing and I'm not sure I like the new one or believe its an improvement. This is particularly problematic from a documentation perspective. Is there a way to preserve the existing syntax?
I did like to preserve the existing command, but the main problem is that then we had to hardcode the MACHINE knowledge into the code, for example, when we run:
runqemu qemux86-64 core-image-sato
The qemux86-64 should be hardcoded into the code, otherwise it doesn't know this is a machine arg or typo.
I will think about if we can use a general database (e.g., tmp/runqemu_data) to save MACHINE after build, then maybe we don't have to hardcode MACHINE into the script.
Quoted 7 lines
b) The question of python verses shell. I'm leaning towards making this a python script rather than shell at this point. It would mean you'd need python to run the scripts but we already need that for a variety of other tools so in general I think I prefer that. We do need to make sure the new python version supports what the current shell script does though.
This sounds good to me.
Quoted 3 lines
c) I don't think qemu-boot should be added be hardcoded into image.bbclass, we need to find a better way to do this.
Sorry, I don't quite understand this, the code inside image.bbclass is:
+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot', '', d)}" +inherit ${QEMU_BOOT_CLASS}
It doesn't look like a hardcode ?
Quoted 4 lines
d) I think we need to document the new API/variables somewhere so that we don't just have a random ever changing set of variables but some kind of standard we're trying to encourage.
Sounds, good.
// Robert
Quoted 5 lines
Cheers,
Richard
Quoted 11 lines · Robert Yang
Quoted 9 lines · Richard Purdie
On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
Sorry about not responding to this before now. My concerns:a) The commandline structure is changing and I'm not sure I like the
new one or believe its an improvement. This is particularly problematic
from a documentation perspective. Is there a way to preserve the existing syntax?
Quoted 7 lines
I did like to preserve the existing command, but the main problem is that then we had to hardcode the MACHINE knowledge into the code, for example, when we run:
runqemu qemux86-64 core-image-satoThe qemux86-64 should be hardcoded into the code, otherwise it doesn't know this is a machine arg or typo.
If we use python code, we can ask bitbake if "qemux86-64" is a valid MACHINE or not?
We could assume that images are in DEPLOY_DIR/MACHINE and at least try looking to see if such a qemu-boot file exists? We could then error and simply inform them that there didn't appear to be any data for "qemu86 -64" available. DEPLOY_DIR could come from bitbake -e.
We could add in functionality to make it take an argument of a path to the qemu-boot directory so that if the first option looks like a relative/absolute PATH, try to see if a qemu-boot file exists there. If it doesn't, it can then fall back to slower ops?
Quoted 6 lines
Quoted 2 lines
c) I don't think qemu-boot should be added be hardcoded into image.bbclass, we need to find a better way to do this.
Sorry, I don't quite understand this, the code inside image.bbclass is:
Quoted 6 lines
+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot',
'', d)}"
+inherit ${QEMU_BOOT_CLASS}It doesn't look like a hardcode ?
Imagine that qemu.inc does:
IMAGE_CLASSES += "qemu-boot"
You then shouldn't need to change image.bbclass at all, its much cleaner. I don't like much of the way image.bbclass deals with all its subclasses at the moment and don't want to make it worse.
Cheers,
Richard
Hi RP,
Thanks, clear enough, here are the summary. For anyone who cares about runqemu, please free to give your comments, I will start working on it sooner.
1) Use python to replace of shell
2) Preserve the current command line options
3) Remove any machine knowledges out of runqemu scripts
4) I'm not sure whether we should remove arch knowledges out of runqemu, I'd like to keep them, this can make bsp add runqemu support easier.
5) Add qemu-boot.bbclass to help create boot files during build.
6) Use python3.
// Robert
Quoted 58 lines · Richard Purdie
Quoted 11 lines · Robert Yang
Quoted 9 lines · Richard Purdie
On Tue, 2016-05-10 at 01:13 -0700, Robert Yang wrote:
Sorry about not responding to this before now. My concerns:a) The commandline structure is changing and I'm not sure I like the
new one or believe its an improvement. This is particularly problematic
from a documentation perspective. Is there a way to preserve the existing syntax?Quoted 7 lines
I did like to preserve the existing command, but the main problem is that then we had to hardcode the MACHINE knowledge into the code, for example, when we run:
runqemu qemux86-64 core-image-satoThe qemux86-64 should be hardcoded into the code, otherwise it doesn't know this is a machine arg or typo.
If we use python code, we can ask bitbake if "qemux86-64" is a valid MACHINE or not?
We could assume that images are in DEPLOY_DIR/MACHINE and at least try looking to see if such a qemu-boot file exists? We could then error and simply inform them that there didn't appear to be any data for "qemu86 -64" available.
DEPLOY_DIRcould come from bitbake -e.We could add in functionality to make it take an argument of a path to the qemu-boot directory so that if the first option looks like a relative/absolute PATH, try to see if a qemu-boot file exists there. If it doesn't, it can then fall back to slower ops?
Quoted 6 lines
Quoted 2 lines
c) I don't think qemu-boot should be added be hardcoded into image.bbclass, we need to find a better way to do this.
Sorry, I don't quite understand this, the code inside image.bbclass is:
Quoted 6 lines
+QEMU_BOOT_CLASS = "${@base_conditional('QEMU_BOOT_SUPPORTED', '1', 'qemu-boot',
'', d)}"
+inherit ${QEMU_BOOT_CLASS}It doesn't look like a hardcode ?
Imagine that qemu.inc does:
IMAGE_CLASSES+= "qemu-boot"You then shouldn't need to change image.bbclass at all, its much cleaner. I don't like much of the way image.bbclass deals with all its subclasses at the moment and don't want to make it worse.
Cheers,
Richard