I tried following the wiki to setup a Risc-V system using -CURRENT under Qemu-devel.
As far as things goes it does boot, and big hat tip for that.
Two issues however:
Two phenomena points to some timer interrupts not happening.
1) Ping(1) reports "inf ms":
root@qemu:/tmp # ping 192.168.60.1
PING 192.168.60.1 (192.168.60.1): 56 data bytes
64 bytes from 192.168.60.1: icmp_seq=0 ttl=64 time=inf ms
64 bytes from 192.168.60.1: icmp_seq=1 ttl=64 time=inf ms
64 bytes from 192.168.60.1: icmp_seq=2 ttl=64 time=inf ms
2) Things run faster i CTRL-T is repeatedly pressed in the console.
I think this may also be why any attempt to ssh into the instance times out.
The other problem is that the installed compiler does not work, compiling the canonical hello.c fails with:
ld: error: a.c:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax
cc: error: linker command failed with exit code 1 (use -v to see invocation)
https://reviews.freebsd.org/D25210 will fix the compiler issue. Unless anyone objects to it I'll commit it early next week.
I have no immediate idea as to what's causing your timer interrupt issues.
I can reproduce it in my own qemu machine, but not in the qemu that emulates a piece of riscv hardware I'm working on now. Those are two different qemu versions, so it's not immediately obvious to me if this is a qemu issue or a FreeBSD issue.
If I pass '-smp 1' to qemu, the boot sequence is much (4-5x) faster, but shortly after getting to multiuser, it slows to a crawl again.
(In reply to Poul-Henning Kamp from comment #2)
Seems to be a qemu-devel issue.
With the qemu package the interrupt problem seems gone.
(In reply to Poul-Henning Kamp from comment #3)
Hmm, it only seems to work with the qemu port with a single CPU.
If I give -smp N for N>1 the symtoms of interrupt-trouble comes back.
There have been a couple of interrupt related commits that have gone in over the last few months. I have encountered the ping(1) issue you reported before, but on a recent HEAD with -smp 2, I no longer see it.
If you have the chance, could you try again with a newer kernel and confirm whether or not the issue is still present?
(In reply to Mitchell Horne from comment #5)
I should specify that I used devel/qemu50 for my test. This version contains an important bugfix for the interrupt controller implementation.
Closing this as both issues are believed to be fixed. Please re-open if this is not the case.