3 ms·

I verified it by personally buying RISC-V boards and trying to make something out of them. This is not FUD. The boot process isn’t better than on Arm, which is

I verified it by personally buying RISC-V boards and trying to make something out of them. 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.

snvzz 2y ago
Nice way to misdirect, equivocate and double down on the FUD, while failing to provide 0 or 1.
- fellowmartian 2y ago
  Alright, Allwinner D1 - still requires vendor-provided components for almost everything, and its pre-ratified vector extension[1] required special compilers until very recently. [1] https://github.com/riscv/riscv-v-spec/issues/667 https://github.com/riscv/riscv-v-spec/issues/667
  - snvzz 2y ago
    Unsurprisingly, brucehoult was right (somewhat). Based on "bleeding edge", pre-2019 specs. This one is a low end chip (single core, slow, based on the early 2017 specs) aimed at custom, embedded devices where the whole software stack (firmware image) is built from a single Makefile by the vendor. I have a development board with one of them (only 512MB RAM, I managed to run a web browser on it at one point); I do indeed own too many RISC-V trinkets; this was the second RISC-V board I got. Allwinner, same situation as their ARM chips (e.g. the A64 used in Pine64 I also own, or the A10 in the Cubieboard I also own). Most upstreaming work is done by linux-sunxi[0] instead of Allwinner themselves, which does not seem to care. Not great in terms of already upstreamed drivers, which is why it is perceived as a pain. The hardware is also pretty limited, being a design that predates the base 2019 RISC-V specifications. But it can run Linux. The earlier Kendrite K210 (my and many people's first RISC-V chip) can run Linux too, but as an academic exercise. That one only has the builtin 8MB SRAM and its implemented privileged spec predates the first ratified one with significant differences. Otherwise, standard RISC-V boot flow (i.e. "0" does not apply). In that sense, much better than its ARM counterparts, but you'll want to ensure you have the latest boot firmware in any event, not the early shipped one. This is a fairly early design too, so note the boot specs that were available at the time are far less reaching than what is available today, and were not even ratified yet. Despite this, the firmware has advanced somewhat, alongside the specs. Runs generic RVA20 gcc compiled code just fine (i.e. "1" does not apply either) because the unprivileged spec ratified in 2019 didn't really chance since 2017. It does also have a pre-1.0 vector extension, which was very useful at the time to play with vector before the final version was available. GCC has support for this extension. Obviously, it is considered a "custom extension", and thus code using it will only work on processors implementing it. TL;DR: One of the earliest designs, based on specs earlier than 2019, predating any ratified spec. Despite this, it manages to not meet 0 nor 1. Irrespective of all the FUD, RISC-V is doing great. 0. https://linux-sunxi.org/Linux_mainlining_effort https://linux-sunxi.org/Linux_mainlining_effort
    - brucehoult 2y ago
      I believe for the K210 Kendryte/Canaan simply grabbed the latest Berkeley Rocket commit, didn't change a thing, and simply added peripherals (including an NPU) around it to make a complete chip. And, yes, that latest commit at the time was priv spec draft 1.9.1, which is quite different to what eventually got ratified. For a while people trying to use the K210 thought the MMU was broken but it's not -- it's just an older spec. Good luck cutting down any modern Linux kernel to boot in 8 MB RAM! Being able to do that might even predate Linux working on anything other than x86. xv6 works fine though. Edit: I was a little bit off. Linux 2.0 required 4 MB, recommended 8+, and already worked on Alpha, SPARC, MIPS, PowerPC, ARM, 68k. Linux 2.2 (1999) required 8 MB, recommended 16+.
brucehoult 2y ago
That's just being on the bleeding edge. Of anything. 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.

snvzz 2y ago

Nice way to misdirect, equivocate and double down on the FUD, while failing to provide 0 or 1.

fellowmartian 2y ago
Alright, Allwinner D1 - still requires vendor-provided components for almost everything, and its pre-ratified vector extension[1] required special compilers until very recently. [1] https://github.com/riscv/riscv-v-spec/issues/667 https://github.com/riscv/riscv-v-spec/issues/667
- snvzz 2y ago
  Unsurprisingly, brucehoult was right (somewhat). Based on "bleeding edge", pre-2019 specs. This one is a low end chip (single core, slow, based on the early 2017 specs) aimed at custom, embedded devices where the whole software stack (firmware image) is built from a single Makefile by the vendor. I have a development board with one of them (only 512MB RAM, I managed to run a web browser on it at one point); I do indeed own too many RISC-V trinkets; this was the second RISC-V board I got. Allwinner, same situation as their ARM chips (e.g. the A64 used in Pine64 I also own, or the A10 in the Cubieboard I also own). Most upstreaming work is done by linux-sunxi[0] instead of Allwinner themselves, which does not seem to care. Not great in terms of already upstreamed drivers, which is why it is perceived as a pain. The hardware is also pretty limited, being a design that predates the base 2019 RISC-V specifications. But it can run Linux. The earlier Kendrite K210 (my and many people's first RISC-V chip) can run Linux too, but as an academic exercise. That one only has the builtin 8MB SRAM and its implemented privileged spec predates the first ratified one with significant differences. Otherwise, standard RISC-V boot flow (i.e. "0" does not apply). In that sense, much better than its ARM counterparts, but you'll want to ensure you have the latest boot firmware in any event, not the early shipped one. This is a fairly early design too, so note the boot specs that were available at the time are far less reaching than what is available today, and were not even ratified yet. Despite this, the firmware has advanced somewhat, alongside the specs. Runs generic RVA20 gcc compiled code just fine (i.e. "1" does not apply either) because the unprivileged spec ratified in 2019 didn't really chance since 2017. It does also have a pre-1.0 vector extension, which was very useful at the time to play with vector before the final version was available. GCC has support for this extension. Obviously, it is considered a "custom extension", and thus code using it will only work on processors implementing it. TL;DR: One of the earliest designs, based on specs earlier than 2019, predating any ratified spec. Despite this, it manages to not meet 0 nor 1. Irrespective of all the FUD, RISC-V is doing great. 0. https://linux-sunxi.org/Linux_mainlining_effort https://linux-sunxi.org/Linux_mainlining_effort
  - brucehoult 2y ago
    I believe for the K210 Kendryte/Canaan simply grabbed the latest Berkeley Rocket commit, didn't change a thing, and simply added peripherals (including an NPU) around it to make a complete chip. And, yes, that latest commit at the time was priv spec draft 1.9.1, which is quite different to what eventually got ratified. For a while people trying to use the K210 thought the MMU was broken but it's not -- it's just an older spec. Good luck cutting down any modern Linux kernel to boot in 8 MB RAM! Being able to do that might even predate Linux working on anything other than x86. xv6 works fine though. Edit: I was a little bit off. Linux 2.0 required 4 MB, recommended 8+, and already worked on Alpha, SPARC, MIPS, PowerPC, ARM, 68k. Linux 2.2 (1999) required 8 MB, recommended 16+.

brucehoult 2y ago

That's just being on the bleeding edge. Of anything. 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.