Or is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board.
Or is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board.
It's not quite complete yet (e.g. lacks drivers for hdmi display and usb), but it boots Linux.
The simpler u-boot SPL --> opensbi --> u-boot flow is mature, and patches have been submitted upstream.
UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by some RISC-V platforms, and there's PLIC and APLIC for interrupts. Undoubtedly there are more things that I'm not thinking of, but I think that's a good start, as those are two things that were in fact NOT standard on many ARM SBCs.
No?
VF2's is early (boots Linux, but only from mmc. No NVMe, USB or display yet), but being worked on by StarFive themselves.
In the future, with OS-A Platform spec, you can expect RISC-V computers to be no different than PCs from a user perspective.
Under the hood, the platform is modern, and carries none of the legacy x86 PCs do. The scope of standardization is also broader: It's not just interrupts, timers or memory map, but also things like the interfaces for Watchdogs, GPIOs are being standardized.
No. Instead, RISC-V standardized the boot process early on, avoiding that situation.
One obstacle is that some people are resisting upstreaming support for the THead C906 and C910 cores "non standard" physical memory attributes and vector implementation into the toolchain and kernel. Both those things were 2 1/2 years away from standardisation in mid 2019 when THead designed their cores, and it takes 3 1/2 to 4 years to get a new core into cheap mass production SoCs and on to boards, so they really could not have done better (other than to simply not implement that kind of feature at all).
Note that newer SBCs have efforts implementing UEFI spec[0], and RISC-V is working on OS-A Platform spec[1], which further reduces basic peripheral and memory map differences.
0. https://github.com/riscv-non-isa/riscv-uefi/releases
1. https://github.com/riscv/riscv-platform-specs/blob/main/risc...
0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...