qemu FreeBSD/RISC-V down in QEMU on both amd64/Linux and ARM/macOS

[cracauer@]

Both of my RISC-V FreeBSD installs are down. They run in QEMU, one on a Linux/amd64 host, one on a M4 Mac.

Is anybody successfully running something like that right now?

I didn't use them for a year or so and have to track down whether it's a QEMU change or what that took them down.

 

[_martin]

Nothing from risc but I do have both Linux/amd64 and m3 mba. If you share your command I can test.

 

[cracauer@]

Risc-v:

qemu-system-riscv64 \
  -M virt \
  -smp 10 \
  -m 6G \
  -nographic \
  -bios fw_jump.elf \
  -kernel u-boot.bin \
  -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0,if=none \
  -device virtio-blk-device,drive=hd0 \
  -nographic \
  -netdev user,id=net0,ipv6=off,hostfwd=tcp::3235-:22 \
  -device virtio-net-device,netdev=net0 \
  -device virtio-rng-pci

Hangs in kernel boot after:

pcib0: <Generic PCI host controller> mem 0x30000000-0x3fffffff on simplebus1    
pci0: <PCI bus> on pcib0
virtio_pci0: <VirtIO PCI (legacy) Entropy adapter> port 0x1000-0x101f mem 0x40000000-0x40000fff,0x40004000-0x40007fff irq 50 at device 1.0 on pci0

 

[cracauer@]

Amd64:

qemu-system-riscv64 \
  -M virt \
  -smp 8 \
  -m 32G \
  -nographic \
  -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
  -kernel u-boot.bin \
  -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -nographic \
  -netdev user,id=net0,ipv6=off,hostfwd=tcp::3235-:22 \
  -device virtio-net-device,netdev=net0 \
  -device virtio-rng-pci

Qemu startup fails with:

qemu-system-riscv64: -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0: Drive 'hd0' is already in use because it has been automatically connected to another device (did you need 'if=none' in the drive options?)

Using a different hd<n> does not help.
Specifying if=none does not help, leads to:

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/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000271e0)
  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)

 

[_martin]

I can replicate this on 14.0 image on my mba. Used qemu @11.1.2, opensbi 1.6-1 from debian, u-boot from some random search on internet.
Didn't get any wiser from verbose boot.

But I was able to boot 14.5-RELEASE just fine:

root@freebsd:~ # uname -a
FreeBSD freebsd 14.5-RELEASE FreeBSD 14.5-RELEASE releng/14.5-n274872-4099b5c82880 GENERIC riscv
root@freebsd:~ #

 

[cracauer@]

OK, will update the FreeBSD inside.

Thank you.

 

[cracauer@]

Repaired the boot on x86/Linux:

qemu-system-riscv64 \
  -M virt \
  -smp 8 \
  -m 8G \
  -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.bin \
  -kernel u-boot.bin \
  -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,index=0,media=disk \
  -nographic \
  -netdev user,id=net0,ipv6=off,hostfwd=tcp::3235-:22 \
  -device virtio-net-device,netdev=net0 \
  -device virtio-rng-pci

The ELF firmware version doesn't workanymore since it is position indepedent and defaults to address NULL for QEMU.