On Sun, Jun 26, 2022 at 9:04 AM Simon Sapin <simon.sa...@exyr.org> wrote: > > 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,
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. Written in Rust as well, nice! I'm sorry to hear that you had so much trouble getting started with RISC-V QEMU. We do try to make it easy, but everyone is busy and documentation usually ends up being the last thing we do. > > 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? Good question. So first up, you can see all of the memory mappings in the hw/riscv/virt.c file, if you find that easier than dumping device trees. We have previously kept the addresses backwards compatible. So that software for an older virt machine will work on a newer one. There is currently talks about changing the virt machine memory layout in a breaking way and versioning in the current one though. So I don't really have a good answer for you. I would recommend reading as much as possible from the device tree dynamically at boot. In general though we don't want to break people, we just might have to make changes in the future to allow for new functionality. > > * 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? If you supply a flash image we will start executing from flash automatically. > > * 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. For a bare metal setup like yours there isn't really a difference. We use -bios to specify the OpenSBI firmware and -kernel to specify a Linux kernel. For your use you can use `-bios none -kernel ...` > > * 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? a2 stores the "dynamic firmware info" which is used by OpenSBI. The riscv_rom_copy_firmware_info() copies the data to memory > > * To what extent is the above calling convention standardized? I found > similar things > in coreboot[4] and in OpenSBI[5] Good question. I don't think it's specified in a spec, but it is very common Alistair > > > [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 >
