OK, something probably pretty basic with #QEMU I need to ask.

I have this command-line, which is generated by #Keystone #RISCV #TEE build:

/home/jarkkojs/work/keystone/qemu/build/riscv64-softmmu/qemu-system-riscv64 \
   $DEBUG \
   -m 2G \
   -nographic \
   -machine virt,rom=/home/jarkkojs/work/keystone/build/bootrom.build/bootrom.bin \
   -bios /home/jarkkojs/work/keystone/build/sm.build/platform/generic/firmware/fw_payload.bin \
    \
   -netdev user,id=net0,net=192.168.100.1/24,dhcpstart=192.168.100.128,hostfwd=tcp::${HOST_PORT}-:22 \
   -device virtio-net-device,netdev=net0 \
   -device virtio-rng-pci \
   -smp $SMP

QEMU has support for #Spike, which is #CVA6 emulation.

So when I do to the above command-line simply s/virt,/spike,/g, I get this error:

$ build/scripts/run-qemu.sh
**** Running QEMU SSH on port 3617 ****
qemu-system-riscv64: Property 'spike-machine.rom' not found

How do I end up to this error message? Why does it seek a filename like that? Without rom= I can run Spike emulation but I need that bootrom for the application.

@jarkko I don't know RISC-V but are you sure the rom= parameter has any effect on the "virt"machine type? I couldn't find code that uses that parameter in qemu.git/master.

The error message from the "spike" machine type is saying that rom= is not valid syntax. If you can make do with just -bios and/or -kernel, then you can use the "spike" machine type. Try dropping rom= from your command line?

@stefanha Thanks! This gave me some pointers. So what comes after machine type is specific to that machine.

The problem here is that bootrom is the first stage bootloader i.e. the whole power on starts from that code and it defines root of trust. I’ll need to study Spike documentation on how to do equivalent thing as with virt.

This helped anyway so that I don’t waste time on something useless. Thank you!

@palmer Maybe you can help Jarkko with this QEMU RISC-V question?

@stefanha the early boot stuff is all pretty board specific, so there's a decent chance you're going to need some code changes as well to make it work.
Spike doesn't look at all like any real systems, so the early boot stuff is going to be a bit clunky.

I'd just try and use the virt board in QEMU, it's much more realistic and widely used.