When using GDB for debugging, if FW_TEXT_START is not set to 0x80000000
during compilation, the following error occurs:
Reading symbols from build/platform/generic/firmware/fw_payload.elf...
Remote debugging using localhost:1234
mips_warm_boot ()
at /home/zrmin/opensbi/platform/generic/mips/mips_warm_boot.S:11
11 j _start_warm
(gdb) b _start
Breakpoint 1 at 0x0: file /home/zrmin/opensbi/firmware/fw_base.S, line 50.
(gdb) c
Continuing.
Remote connection closed
(gdb)
With FW_TEXT_START=0x80000000, debugging works correctly:
Reading symbols from build/platform/generic/firmware/fw_payload.elf...
Remote debugging using localhost:1234
0x0000000000001000 in ?? ()
(gdb) b _start
Breakpoint 1 at 0x80000000: file /home/zrmin/opensbi/firmware/fw_base.S, line 50.
(gdb) c
Continuing.
Breakpoint 1, _start () at /home/zrmin/opensbi/firmware/fw_base.S:50
50 MOV_3R s0, a0, s1, a1, s2, a2
(gdb)
This is because QEMU loads OpenSBI at address 0x80000000. When
FW_TEXT_START does not match this address, the debug symbols are
incorrectly offset, causing GDB to fail to set breakpoints properly.
Signed-off-by: Zhang RunMin <runmin.zhang@ingenic.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260319125641.480161-1-runmin.zhang@ingenic.com
Signed-off-by: Anup Patel <anup@brainfault.org>
4.4 KiB
QEMU RISC-V Virt Machine Platform
The QEMU RISC-V Virt Machine is a virtual platform created for RISC-V software development and testing. It is also referred to as QEMU RISC-V VirtIO machine because it uses VirtIO devices for network, storage, and other types of IO.
To build the platform-specific library and firmware images, provide the
PLATFORM=generic parameter to the top level make command.
Platform Options
The QEMU RISC-V Virt Machine platform does not have any platform-specific options.
Execution on QEMU RISC-V 64-bit
No Payload Case
Build:
make PLATFORM=generic
Run:
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.bin
U-Boot Payload
Note: the command line examples here assume that U-Boot was compiled using
the qemu-riscv64_smode_defconfig configuration.
Build:
make PLATFORM=generic FW_PAYLOAD_PATH=<uboot_build_directory>/u-boot.bin
Run:
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.elf
or
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_jump.bin \
-kernel <uboot_build_directory>/u-boot.bin
Linux Kernel Payload
Note: We assume that the Linux kernel is compiled using
arch/riscv/configs/defconfig. The kernel must be a flattened image (a file
called Image) rather than an ELF (vmlinux).
Example of building a Linux kernel:
make ARCH=riscv CROSS_COMPILE=riscv64-linux- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-linux- Image
Build:
make PLATFORM=generic FW_PAYLOAD_PATH=<linux_build_directory>/arch/riscv/boot/Image
Run:
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.elf \
-drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0"
or
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_jump.bin \
-kernel <linux_build_directory>/arch/riscv/boot/Image \
-drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0"
Execution on QEMU RISC-V 32-bit
No Payload Case
Build:
make PLATFORM=generic PLATFORM_RISCV_XLEN=32
Run:
qemu-system-riscv32 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.bin
U-Boot Payload
Note: the command line examples here assume that U-Boot was compiled using
the qemu-riscv32_smode_defconfig configuration.
Build:
make PLATFORM=generic PLATFORM_RISCV_XLEN=32 FW_PAYLOAD_PATH=<uboot_build_directory>/u-boot.bin
Run:
qemu-system-riscv32 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.elf
or
qemu-system-riscv32 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_jump.bin \
-kernel <uboot_build_directory>/u-boot.bin
Linux Kernel Payload
Note: We assume that the Linux kernel is compiled using arch/riscv/configs/rv32_defconfig.
Build:
make PLATFORM=generic PLATFORM_RISCV_XLEN=32 FW_PAYLOAD_PATH=<linux_build_directory>/arch/riscv/boot/Image
Run:
qemu-system-riscv32 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.elf \
-drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0"
or
qemu-system-riscv32 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_jump.bin \
-kernel <linux_build_directory>/arch/riscv/boot/Image \
-drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0"
Debugging with GDB
Note: the command line examples here assume that OpenSBI was compiled using
the DEBUG=1 FW_TEXT_START=0x80000000 configuration.
In a first console start OpenSBI with QEMU:
qemu-system-riscv64 -M virt -m 256M -nographic \
-bios build/platform/generic/firmware/fw_payload.bin \
-gdb tcp::1234 \
-S
Parameter -gdb tcp::1234 specifies 1234 as the debug port. Parameter -S lets QEMU wait at the first instruction.
In a second console start GDB:
gdb build/platform/generic/firmware/fw_payload.elf \
-ex 'target remote localhost:1234'