I believe so. The base ISA is frozen. RV32IMAFDC and RV64IMAFDC have not changed in the last year. The userspace ABI is stable.
I believe the compiler has now been configured to output RVC compression by default, which means the target depends on the RVC extension.
There is the whole question of whether to target a sub architecture. e.g. RV32IMAC with soft float.
Note the ISA strings are passed lowercase to the toolchain and ABI defaults to hard float e.g.
This is 64-bit hard float ABI with compression (-mabi flag here is the default):
This is 32-bit soft float ABI with compression:
You’ll find the kernel config and HTIF console IO patch for bbl in the RISCVEMU patches directory. NOTE: RISCVEMU needs bbl to be patched. You also need the root kernel command line in Fabrice’s kernel config to set up Virtio.
There is a kernel and bbl build script below that I believe uses a similar VirtIO config and the branch tips are from the same December/January time frame that RISCVEMU was released. It puts busybox in the initramfs. You can point it at a fork of bbl repo with Fabrice’s config and the HTIF console IO patch applied (from the RISCVEMU patches directory).
Of course you need the linux toolchain from riscv-gnu-toolchain
You’ll need to change my bbl build scripts repo URLs because the bbl branch pointed to in the script uses UART for console which is not supported by RISCVEMU. I actually tested the boot.bin from RISCVEMU against my RISC-V interpreter, as I also implement the same HTIF console IO device, just the interpreter I am working on lacks VirtIO. Nevertheless you should be able to use my script and modify it to use upstream bbl with the HTIF console IO patch:
Eventually I’ll finishes adding JIT and VirtIO to the full system emulator I am working on so there will be a (potentially faster) alternative to QEMU. The RV64 -> x86_64 JIT engine I am working on operates at about 4-5 BIPS vs 100-200 MIPs for the interpreters. About 1/3rd native speed.
That is the architecture the bbl.bin and root.bin are built for.