riscv-sbi-doc VS riscv-bringup

The SBI spec[0] is not a long read.

0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases

>What does matter is standardization. For example a booting process.

Truth.

This is why RISC-V put a lot of effort on this, and put it early.

Relevant specs include but isn't limited to SBI[0], UEFI protocol[1] and the ongoing platform specification[2].

0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases

1. https://github.com/riscv-non-isa/riscv-uefi/releases/tag/1.0...

2. https://github.com/riscv/riscv-platform-specs

Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot).

The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv-non-isa/riscv-sbi-doc)

The SBI (Supervisor-Binary Interface) is the API used by S-mode software (your operating system) to communicate with M-mode, and abstract away some hardware-specific details. It handles things like communicating between harts, power management, and performance monitoring. On real hardware, it is implemented by M-mode software. For VMs, it is typically implemented by the hypervisor. It's roughly analogous to the PSCI in ARM. For more information, have a look at the spec.

Nothing forces it to be in ROM. See for example https://github.com/carlosedp/riscv-bringup/blob/master/unlea... where DRAM init seems to be in the FSBL part which is loaded from the SD card.