0. bespoke boot process
1. a custom compiler
For the love of computer science, do not just repeat some FUD you heard somewhere. Always verify.
This is not FUD. The boot process isn’t better than on Arm, which is already terrible. End users need to find magic .isos, while developers need to search for magic vendor forks of everything: u-boot, kernel, OpenSBI.
Re compilers: Sure you can target RV64GC and everything more or less works, but your performance will likely be terrible. To squeeze more performance you might need magic or out of tree versions of GCC and/or Clang.
The Pi 4 is five years old and is well-supported. Now. It was pretty awful in 2019.
The HiFive Unmatched (shipped this time in 2021, still available new) is well sorted these days.
I see a lot of complaints about the RK3588 boards stability and they're now two years old.
If you don't want to bleed, don't live on the bleeding edge, use something a few years old. Don't give in to the temptation of that 50%+ annual improvement in price/performance.
It's not their job. RISC-V Foundation is the entity in charge of specs, not manufacturers.
Platform specs exist, which cover boot and the environment a kernel will expect, among other things.
The manufacturers simply follow these specs. So far, quite successfully at that.
Unlike the ARM situation.
What RISC-V board is on the open market and not supported by vanilla gcc/clang?
You didn't bring up extensions, but that's what people usually mean when they complain about fragmentation. It's not an issue in practice, just target RV64GC and you'll be fine. That describes the extensions which you can expect any general purpose computer style RISC-V CPU to implement.
I wish the booting story was better though, for both RISC-V and ARM. Manually editing device trees sucks. But that's more an issue due to the lack of UEFI on these SBC style platforms, not an inherent issue with ARM or RISC-V themselves (in fact, in the server world, ARM systems with UEFI is common).
Really? IANA-KD, but I have read and seen grumbling from ARM developers about RISC-V "overreaching" and standardising more to prevent that kind of issue. Now, maybe the Chinese board manufacturers have gone rogue and ignoring these suggestions, but this fragmentation is something that RISC-V leadership was acutely aware and conscientiously made effort to address. I mean, I could imagine that at the embedded level sacrifices had to be made, but I'd be surprised at anything strong enough to power a ChromeBook and up to have this as an issue... but if you are better informed please share.
