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

[Simon Sapin]

On 27/06/2022 07:40, Alistair Francis wrote:
> 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.

I agree that reading from the device tree as much as possible is good. We there’s 
still a need to get code running at all, and finding the device tree.

So it would be good to decide to make stable what’s needed to get there (like was 
apparently decided for ARM) and document it.

On principle maybe a firmware/bootloader could be entirely position-independent? But 
in what I’ve done/seen so far https://docs.rs/riscv-rt/latest/riscv_rt/ has address 
ranges hard-coded in a linker script for different regions, and when passing an ELF 
file to -kernel, QEMU maps it to those addresses but boots at 0x8000_0000 regardless.


> > * 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.

Passing with -drive? Should I use that instead of -kernel?


> > * 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

Should we document this convention as something guest code can rely on?

--
Simon Sapin