5 ms·

lots of talk in this space, but not much action

Pet_Ant 2y ago
Sorry, but what more action would you like to reasonable see right? Sure, we'd all like the currently in stock on store shelves, but these things take time. There have been various RISC-V CPUs shipped. There is a cyberdeck mentioned yesterday shipping [1], there is a tablet [2]. Pi-level-ish boards have been shipped. These things time and progress has been steady. This seems more like a chirp than a substantive criticism. [1] https://www.clockworkpi.com/product-page/devterm-kit-r01 https://www.clockworkpi.com/product-page/devterm-kit-r01 [2] https://pine64.com/product/pinetab-v-10-1-8gb-128gb-risc-v-based-linux-tablet-with-detached-backlit-keyboard/ https://pine64.com/product/pinetab-v-10-1-8gb-128gb-risc-v-b...
- fellowmartian 2y ago
  Fragmentation is killing RISC-V. It’s bad enough to need a bespoke boot and bring up for each CPU and board on Arm, but with RISC-V you still need that as well, but with a custom compiler on top. I’d love for RISC-V to succeed, but with the way things are going it seems unlikely.
  - yjftsjthsd-h 2y ago
    > but with a custom compiler on top What RISC-V board is on the open market and not supported by vanilla gcc/clang?
  - Pet_Ant 2y ago
    > It’s bad enough to need a bespoke boot and bring up for each CPU and board on Arm, but with RISC-V you still need that as well 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.
  - jandrese 2y ago
    To this day I still don't understand why these SBC manufacturers can't agree on a boot standard to avoid this mess. It can't be simply that they never support their products and thus never have the headaches of maintaining so many different environments right? I get that ARM came from a legacy of cell phones and other embedded devices, but with RISC-V it seems like there was a golden opportunity to nail it down right from the start and it was squandered. Plus, the ARM folks should have solved this problem over a decade ago. For comparison, this problem was solved 40 years ago on PCs.
    - snvzz 2y ago
      >can't agree 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.
  - mort96 2y ago
    Since when do you need a custom compiler??? Both GCC and clang can build Linux RISC-V binaries with no problem. 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).
  - snvzz 2y ago
    Please give at least one (1) example of RISC-V SoC that requires either: 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.
    - fellowmartian 2y ago
      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

Sorry, but what more action would you like to reasonable see right? Sure, we'd all like the currently in stock on store shelves, but these things take time. There have been various RISC-V CPUs shipped. There is a cyberdeck mentioned yesterday shipping [1], there is a tablet [2]. Pi-level-ish boards have been shipped. These things time and progress has been steady. This seems more like a chirp than a substantive criticism. [1] https://www.clockworkpi.com/product-page/devterm-kit-r01 https://www.clockworkpi.com/product-page/devterm-kit-r01 [2] https://pine64.com/product/pinetab-v-10-1-8gb-128gb-risc-v-based-linux-tablet-with-detached-backlit-keyboard/ https://pine64.com/product/pinetab-v-10-1-8gb-128gb-risc-v-b...

fellowmartian 2y ago
Fragmentation is killing RISC-V. It’s bad enough to need a bespoke boot and bring up for each CPU and board on Arm, but with RISC-V you still need that as well, but with a custom compiler on top. I’d love for RISC-V to succeed, but with the way things are going it seems unlikely.
- yjftsjthsd-h 2y ago
  > but with a custom compiler on top What RISC-V board is on the open market and not supported by vanilla gcc/clang?
- Pet_Ant 2y ago
  > It’s bad enough to need a bespoke boot and bring up for each CPU and board on Arm, but with RISC-V you still need that as well 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.
- jandrese 2y ago
  To this day I still don't understand why these SBC manufacturers can't agree on a boot standard to avoid this mess. It can't be simply that they never support their products and thus never have the headaches of maintaining so many different environments right? I get that ARM came from a legacy of cell phones and other embedded devices, but with RISC-V it seems like there was a golden opportunity to nail it down right from the start and it was squandered. Plus, the ARM folks should have solved this problem over a decade ago. For comparison, this problem was solved 40 years ago on PCs.
  - snvzz 2y ago
    >can't agree 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.
- mort96 2y ago
  Since when do you need a custom compiler??? Both GCC and clang can build Linux RISC-V binaries with no problem. 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).
- snvzz 2y ago
  Please give at least one (1) example of RISC-V SoC that requires either: 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.
  - fellowmartian 2y ago
    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