[HELP] New to this : trying to run it on qemu under wsl

[daniel-dlds]

Description

I am trying to load a build of nuttx using qemu-system-riscv64
I have built nuttx for star64 target
then I do :
/usr/bin/qemu-system-riscv64 -nographic --machine sifive_u -m 2 -kernel /m
nt/c/devtools/nuttxspace/nuttx/nuttx
qemu-system-riscv64: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.

The following two regions overlap (in the memory address space):
/usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080042c40)
fdt (addresses 0x0000000080000000 - 0x000000008000130b)
image is clashing with SBI in Qemu
tried loading it while relocating the nuttx image with but could not load
/usr/bin/qemu-system-riscv64 -nographic --machine sifive_u -m 2 -device guest-loader,kernel=/mnt/c/devtools/nuttxspace/nuttx/nuttx,addr=0x0000000080042c41
qemu-system-riscv64: -device guest-loader,kernel=/mnt/c/devtools/nuttxspace/nuttx/nuttx,addr=0x0000000080042c41: Cannot load specified image /mnt/c/devtools/nuttxspace/nuttx/nuttx
I could run qemu with the raw image, and it just stayed there running on the terminal with :
/usr/bin/qemu-system-riscv64 -nographic --machine sifive_u -m 2 -bios /mnt/c/devtools/nuttxspace/nuttx/nuttx
had to kill the qemu process

with this last command don't know if it was really executing anything. I suspect I have to run this with the Qemu SBI in order to acess the serial port on the nuttx side and get a prompt
I am new to all this. I need some pointers
and also qemu

Verification

• I have verified before submitting the report.

[arnavsharma990]

Hey!

I think this may be related to the platform/boot-image combination rather than the NuttX build itself.

You built NuttX for star64, but are running it with QEMU's sifive_u machine. These model different platforms: Star64 uses the StarFive JH7110, while sifive_u models the SiFive FU540.

The ROM overlap also appears to involve QEMU's OpenSBI image.

Could you share:

readelf -h nuttx | grep Entry
qemu-system-riscv64 --version

And the exact NuttX configuration, e.g.:

star64:nsh

[arnavsharma990]

also If the goal is to run Star64, I'd recommend following the NuttX Star64 boot flow instead of using:

-machine sifive_u

Alternatively, if the goal is simply to run NuttX with QEMU, try a NuttX RISC-V configuration specifically intended for QEMU. This avoids the platform mismatch and should make debugging much easier.

[daniel-dlds]

Hi, thanks for your replies.
The situation is that I am going to have a VisionFive2 SBC with a JH7110 CPU in it. I want to set up an emulated environment and am trying qemu. So qemu --machine option I am using is wrong. Is there a correct one for this kind of CPU ?

dlsa@nabunda:/mnt/c/devtools/nuttxspace/nuttx$ readelf -h nuttx | grep ntry Entry point address: 0x40200000

dlsa@nabunda:/mnt/c/devtools/nuttxspace/nuttx$ /usr/bin/qemu-system-riscv64 --version QEMU emulator version 10.0.11 (Debian 1:10.0.11+ds-0+deb13u1) Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers

[arnavsharma990]

Thanks, that clarifies the goal.

QEMU does not currently provide a machine model for the JH7110 / VisionFive 2, so there isn't a correct --machine option for directly emulating that board.

• If the goal is learning/testing NuttX under QEMU, I'd recommend using NuttX's rv-virt configuration and running it with -M virt. This is the documented QEMU path.
• If the goal is preparing for the actual VisionFive 2, QEMU won't reproduce the JH7110 hardware. However, the NuttX concepts you learn with rv-virt (NSH, Kconfig, drivers, etc.) still transfer to the real board.

So I'd avoid the sifive_u + star64 combination. The ROM overlap is consistent with using an image built for one hardware platform with a different QEMU machine model.

[daniel-dlds]

That clarifies it. I was hoping to use the emulator for development and testing it once in a while on the real hardware.
If I use the rv-virt route I can do that, it just won't be as close to the target system as it could be.
For now I will settle with that. I just starting so its ok.
Thanks for your help

[arnavsharma990]

I’ve also opened a feature request in QEMU for a JH7110 / VisionFive 2 machine model:

https://gitlab.com/qemu-project/qemu/-/work_items/4466

Hopefully, this can lead to proper JH7110/VisionFive 2 support in QEMU in the future!