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
