Help me understand how RISC-V solves these problems? It doesn’t offer a standard way to enumerate hardware in the SoC, so you still need device trees; it’d not a GPU, so you still need to deal with proprietary GPU drivers; it doesn’t standardize clocking or DRAM controllers, so you still need uboot or some other first stage boot loader; AFAIK, it doesn’t standardize power management, so you still need secure firmware or equivalent. The need to PXE boot comes from only having one boot device supported by the board, which isn’t solved by RISC-V
PCs (partially) solve these problems because the BIOS plays the role of secure firmware and first stage boot loader. Hardware enumeration is solved by having most things be PCI-attached and the bios providing ACPI to enumerate the rest.
I was talking about non proprietary boards on the whole, not just the CPU. Also if everything is documented it's not a big deal to customize your bootloader to do all the needed stuff. Of course standards would be very welcome, but at least you wouldn't need some arcane knowledge to get things running
I don't think access to SoC documentation would have solved very many of the problems described in the article. The author still would have had to fiddle with device trees, secure firmware, u-boot, pxeboot, and getting a kernel with the right drivers built in.
RISC-V also doesn't solve SoC documentation access. Most of Arm's CPU documentation is freely available, its all the other stuff SoC vendors bolt on that's hard to get access to. I don't see RISC-V changing that.
PCs (partially) solve these problems because the BIOS plays the role of secure firmware and first stage boot loader. Hardware enumeration is solved by having most things be PCI-attached and the bios providing ACPI to enumerate the rest.