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

[Alistair Francis]

On Mon, Jun 27, 2022 at 4:15 PM Simon Sapin <simon.sapin@exyr.org> wrote:
>
> 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.

Yeah, we are working towards that

>
> On principle maybe a firmware/bootloader could be entirely 
> position-independent? But

I don't link the RISC-V toolchains suppor fully position independent code

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

Yeah, I suspect we will keep the 0x8000_0000 as that's pretty standard

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

If you want to pass a drive then yes, that's the better option

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

We probably should at some point

Alistair

>
> --
> Simon Sapin