riscv-sbi-doc VS riscv-platform-specs

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.

For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0].

0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

>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

For the record the RISC-V foundation already has a working group developing platform standards. Currently they have OS-A Server for servers, OS-A Embedded for small boards and the M platform for Zephyr/Linux NOMMU size systems. https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.pdf

The SBI console stuff are deprecated with no replacements. And if you checkout https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc, OS kernels really are expected to just find a 8250 or 16550 in the device tree, or as mentioned in a few other comments, use UEFI.

Platforms: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

There’s no indication of when the next iteration of the “Un” board will be, but it would be interesting to see if they’re targeting today’s tech, or something that’s around the corner such as the upcoming platform spec https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc

If you're building a chip for a server, workstation, cellphone you'll want to adhere to the platform spec.

RVA22[0] is the first one, and among other important things which go a long way to ease cross-vendor software compatibility, it does specify a set of extensions which are required.

[0]: https://github.com/riscv/riscv-platform-specs/blob/main/risc...

You’ll find the current RISC-V platform specification here.