[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Booting bare-metal RISC-V virt (Was: [PATCH] Add some documentation for
Booting bare-metal RISC-V virt (Was: [PATCH] Add some documentation for "dtb" devices tree blobs)
Sun, 26 Jun 2022 01:03:30 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
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
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 but it wasn’t easy.
In comparison, the docs for Arm virt have a very helpful section 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 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 and in OpenSBI