Booting bare-metal RISC-V virt (Was: [PATCH] Add some documentation for "dtb" devices tree blobs)

[Simon Sapin]

On 26/06/2022 00:34, Simon Sapin wrote:
> +On startup, the dtb is memory-mapped and its address is passed to the guest
> +in a target-specific way:
> +
> +* Arm: :ref:`arm-baremetal`
> +* **TODO**: document other targets

Hello,

My current interest is playing with bare-metal / freestanding RISC-V, using QEMU as a 
reference emulator. Based on various blog posts, reading QEMU source code, and lots 
of trial-and-error I’ve managed to get something running[1] but it wasn’t easy.

In comparison, the docs for Arm virt have a very helpful section[2] for this 
scenario. I would like to contribute similar docs for RISC-V virt but I’d need 
confirmation of the information to put in it:

* Through `dumpdtb` I see that flash memory starts at address 0x2_000_0000, and RAM 
at 0x8_000_0000. Is this information that guest code can rely on and hard-code? What 
details can or cannot be similarly relied on?

* With `qemu-system-riscv32 -machine virt -bios none -kernel something.elf -s -S`, 
GDB shows that execution starts at the lowest address of RAM, not of flash like I 
expected. Then what is emulated flash for?

* What’s the difference between a bios and a kernel? The previous command is based on 
a blog post but I don’t fully quite the details.

* I see in source code[3] that QEMU passes some arguments to the firmware. Register 
a0 gets the hart ID, a1 is the dtb address, but what’s in a2?

* To what extent is the above calling convention standardized? I found similar things 
in coreboot[4] and in OpenSBI[5]


[1] https://github.com/SimonSapin/riscv-qemu-demo

[2] 
https://www.qemu.org/docs/master/system/arm/virt.html#hardware-configuration-information-for-bare-metal-programming

[3] https://gitlab.com/qemu-project/qemu/-/blob/v7.0.0/hw/riscv/boot.c#L297-317

[4] https://doc.coreboot.org/arch/riscv/index.html#stage-handoff-protocol

[5] 
https://github.com/riscv-software-src/opensbi/blob/v1.1/platform/generic/platform.c#L59-L75


Thanks!
--
Simon Sapin