Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too;
I've tested it after extracting the kernel, initrd, and kernel command
line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this
type of boot, because at least historically, fw_cfg kernel boot was
implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/RiscVVirt/README.md | 33 +++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/RiscVVirt/README.md b/OvmfPkg/RiscVVirt/README.md
index 1dba1a26af2d..47b97dd64a2f 100644
--- a/OvmfPkg/RiscVVirt/README.md
+++ b/OvmfPkg/RiscVVirt/README.md
@@ -75,8 +75,39 @@ Below example shows how to boot openSUSE Tumbleweed E20.
Currently, `acpi=off` is recommended unless you are developing ACPI support
yourself.
+3) Running QEMU with direct kernel boot
+
+ The following example boots the same guest, but loads the kernel image and
+ the initial RAM disk (which were extracted from
+ `openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw`) from the host filesystem.
+ It also sets the guest kernel command line on the QEMU command line.
+
+ CMDLINE=(root=UUID=76d9b92d-09e9-4df0-8262-c1a7a466f2bc
+ systemd.show_status=1
+ ignore_loglevel
+ console=ttyS0
+ earlycon=uart8250,mmio,0x10000000)
+
+ qemu-system-riscv64 \
+ -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
+ -m 4096 -smp 2 \
+ -serial mon:stdio \
+ -device virtio-gpu-pci -full-screen \
+ -device qemu-xhci \
+ -device usb-kbd \
+ -device virtio-rng-pci \
+ -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
+ -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
+ -netdev user,id=net0 \
+ -device virtio-net-pci,netdev=net0 \
+ -device virtio-blk-device,drive=hd0 \
+ -drive file=openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw,format=raw,id=hd0 \
+ -kernel Image-6.5.2-1-default \
+ -initrd initrd-6.5.2-1-default \
+ -append "${CMDLINE[*]}"
+
## Test with your own OpenSBI binary
-Using the above QEMU command line, **RISCV_VIRT_CODE.fd** is launched by the
+Using the above QEMU command lines, **RISCV_VIRT_CODE.fd** is launched by the
OpenSBI binary that is bundled with QEMU. You can build your own OpenSBI binary
as well:
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108578): https://edk2.groups.io/g/devel/message/108578
Mute This Topic: https://groups.io/mt/101334266/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Wed, Sep 13, 2023 at 12:55:51PM +0200, Laszlo Ersek wrote:
> Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too;
> I've tested it after extracting the kernel, initrd, and kernel command
> line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this
> type of boot, because at least historically, fw_cfg kernel boot was
> implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil.
>
> Cc: Andrei Warkentin <andrei.warkentin@intel.com>
> Cc: Andrew Jones <ajones@ventanamicro.com>
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> OvmfPkg/RiscVVirt/README.md | 33 +++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/RiscVVirt/README.md b/OvmfPkg/RiscVVirt/README.md
> index 1dba1a26af2d..47b97dd64a2f 100644
> --- a/OvmfPkg/RiscVVirt/README.md
> +++ b/OvmfPkg/RiscVVirt/README.md
> @@ -75,8 +75,39 @@ Below example shows how to boot openSUSE Tumbleweed E20.
> Currently, `acpi=off` is recommended unless you are developing ACPI support
> yourself.
>
> +3) Running QEMU with direct kernel boot
> +
> + The following example boots the same guest, but loads the kernel image and
> + the initial RAM disk (which were extracted from
> + `openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw`) from the host filesystem.
> + It also sets the guest kernel command line on the QEMU command line.
> +
> + CMDLINE=(root=UUID=76d9b92d-09e9-4df0-8262-c1a7a466f2bc
> + systemd.show_status=1
> + ignore_loglevel
> + console=ttyS0
> + earlycon=uart8250,mmio,0x10000000)
> +
> + qemu-system-riscv64 \
> + -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
> + -m 4096 -smp 2 \
> + -serial mon:stdio \
> + -device virtio-gpu-pci -full-screen \
> + -device qemu-xhci \
> + -device usb-kbd \
> + -device virtio-rng-pci \
> + -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
> + -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
> + -netdev user,id=net0 \
> + -device virtio-net-pci,netdev=net0 \
> + -device virtio-blk-device,drive=hd0 \
> + -drive file=openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw,format=raw,id=hd0 \
> + -kernel Image-6.5.2-1-default \
> + -initrd initrd-6.5.2-1-default \
> + -append "${CMDLINE[*]}"
> +
> ## Test with your own OpenSBI binary
> -Using the above QEMU command line, **RISCV_VIRT_CODE.fd** is launched by the
> +Using the above QEMU command lines, **RISCV_VIRT_CODE.fd** is launched by the
> OpenSBI binary that is bundled with QEMU. You can build your own OpenSBI binary
> as well:
>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108639): https://edk2.groups.io/g/devel/message/108639
Mute This Topic: https://groups.io/mt/101334266/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2026 Red Hat, Inc.