I'm not sure I would buy a RISC-V board yet. In particular it is still in the stage where knowledge about the platform has to be hard coded rather than probed at runtime. For example the location of MMIO devices like CLINT (time/interrupt controller) and physical memory attributes. The spec says something like "the platform must provide a method for software to discover this" but it doesn't specify how and as far as I know the current method is that it should read the manual!
There is a placeholder CSR mconfigptr that I believe is intended to fix this by pointing to a DeviceTree blob which would solve this (someone correct me if I'm wrong) but none of that is standardised yet.
I work on RISC-V and I think it's great and ARM should be very very worried but if you buy this you're on the bleeding edge and don't expect the software experience you'd get on x86 or even RPi. Give it a few years and I expect the story will be very different.
> ACPI is the unprofessional, hackish attempt of bios and board vendors to solve a small subset of the problems that DT already solved long ago.
> In November 2003, Linus Torvalds—author of the Linux kernel—described ACPI as "a complete design disaster in every way".
I'm not sure Linus has the best design sense but it doesn't sound like he is wrong here:
> Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode. A reference AML interpreter implementation is provided by the ACPI Component Architecture (ACPICA). At the BIOS development time, AML bytecode is compiled from the ASL (ACPI Source Language) code.
I'm still learning about this stuff to be honest, but I don't really understand what problems would need bytecode in the first place? What is implemented in ACPI in bytecode?
There is a placeholder CSR mconfigptr that I believe is intended to fix this by pointing to a DeviceTree blob which would solve this (someone correct me if I'm wrong) but none of that is standardised yet.
I work on RISC-V and I think it's great and ARM should be very very worried but if you buy this you're on the bleeding edge and don't expect the software experience you'd get on x86 or even RPi. Give it a few years and I expect the story will be very different.