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 - 2025 Red Hat, Inc.