They wanted to drop support because they didn't have the hardware. Now that they have access to the hardware and not dropping support, I am not sure if it matters much.
The public doesn't have access to RISC-V hardware and it won't have access anytime soon.
The problem to be solved seems availability of the hardware, not support from a small Linux distribution. It's not like we can go to Hetzner and rent a RISC-V server or go to AWS and provision a RISC-V VM.
And the availability will only improve if there is enough demand from the market to build such hardware. The EU and China wanting to be less dependant on US tech might help here.
Of course, RISC-V hardware should be on par on perf/price with x86 and ARM to tempt someone to switch.
I complained about hardware perf and viability in another thread.
However, there are enough options for enthusiasts / early adopters, including budget HW. I don't think e.g. PINETAB-V[1] is a desirable/useful general purpose tablet, but it's there if you want to bite. If you're going after an SBC, STAR64[2] also looks OK.
If it hadn't been for US sanctions preventing the SG2380 being sent to TSMC for manufacturing, we would have at least one RISC-V machine (Milk-V Oasis) competitive with RK3588 (but 16 A78-equivalent cores) right around now.
Also A55 and A72 are quite comparable in practical performance -- on real-world things such as building software, not just micro-benchmarks that only use L1 cache. The Arm SBC market has generally moved away from A74 boards to A55 board with more cores, as they are more energy efficient and cheaper to make too.
In the original post about dropping RISC-V support chimera Linux mentions that this existing hardware is too slow realistically use for build machines. They specifically mention the JH7110 which powers the framework board and the spacemit k1/m1 that powers the DC Roma laptop.
So yeah there is hardware available but expect raspberry pi 3 or lower levels of performance.
> Nobody is compiling an entire Linux distro on something like a Raspberry Pi 3.
The RISC-V mainboard for the Framework is 4-core 1.5 GHz with 8 GB of RAM. That's leagues better than the hardware that people were compiling Linux on in the 90s and early 2000s.
Unfortunately software has gotten so much worse that hardware improvements simply can't keep up. That's also why Linux doesn't enable certain mitigations by default.
The U74-MC on that board’s JH7110 SoC is two 64-bit dual-issue cores at 1.5 GHz, so it’s fair to compare it with the four 64-bit dual-issue cores at 1.2 or 1.4 GHz on the RPi3’s Cortex-A53, or for that matter with something like a 1.0 to 1.4 GHz dual-socket Pentium III system from the early oughts (which would use the P6 32-bit dual-issue microarchitecture from the Pentium Pro).
They're targeting them, though. I used to use the Rasberry Pi Zero line for embedding into projects, even though it is much, much more difficult to get than the Pi Pico, because the Zero series can run Linux, opening up a lot more software.
I've switched to SBCs based on the Bouffalo Lab BL808 and more recently Sophgo SG2000 SoCs, which are in the same form factor and price range as the Pi Pico, but run full Linux. They're nowhere near as fast or capable as a desktop, laptop, or even phone/tablet processor, but they're much faster than the RP2040 and much easier to port to. I even compile target applications on them, although not the Linux kernel itself.
I love my little $5 duos! 64 MB RAM is actually enough to run emacs and gcc right on the board itself for programs you write yourself -- it's as much RAM as we had on PCs and Macs, as standard, as recently as 1998 or so, and that was on 200 or 300 MHz machines, slower than a 1 GHz Duo (even allowing for them being mild superscalar/OoO). Not to mention my SPARC ELC and SGO Indy, both of which have 64 MB RAM (and 33 and 166 MHz CPUs respectively. Those used to be serious machines!
With the standard Buildroot image you need to statically link things, but you don't have to build specially in many cases .. for example just copy qemu-arm-static, qemu-x86_64-static etc over from a standard RISC-V distro and they run fine on the Duo.
In the early development phase, you'd compile the OS on a big non-RISCV desktop PC and target those little SBC boards, then flash it onto them and boot and test. In the prototype phase, you get the real hardware, but will probably still compile from something else. By the time the real hardware is ready to be released to the public, the OS for it will probably already be finished and ship with it.
Cross-compilation is much more hassle than native, especially with GCC. It's feasible for individual apps, but I would not want to set that up for an entire Linux distro.
Sure, but a new architecture is big risk reward. I expect the first companies to start selling consumer risc-v products will have a big budget to set up a datacenter, to remotely flash racks of their devices and run automated tests as their big team develops the risc-v linux distro it will run. Perhaps a nintendo switch 3? Samsung smartphone? Quallcomm smart toaster? Who knows. But it will probably be some big company on https://riscv.org/members/ who has an axe to grind with ARMs licencing fees, and is willing to go to this hassle.
Your comment seemed to be claiming that cross-compiling an entire operating system was infeasible. My comment was that it's exactly what big companies do.
RISC-V is commonly used in FPGA softcores when avoiding the more expensive tooling. You can find ~$100 FPGA dev boards capable of running a RISC-V Linux softcore on them right now.
While not traditional hardware, its very much available.
So much for the “RISC-V isn’t ready” crowd—this is exactly how niche architectures survive: stubborn devs, a loaned Milk-V box, and a middle finger to pragmatism. Honestly, dropping it now would’ve been a waste. If anything, this feels like a test run for how the indie Linux world will carry RISC-V until the big players stop waffling.
> stubborn devs, a loaned Milk-V box, and a middle finger to pragmatism.
That's not what's happening here though? With skepticism, they're willing to give it another try because someone loaned them the needed hardware. They're being pragmatic, and they're not stubborn about supporting RISC-V, as they indicate that if there are more problems they'll drop it again.
Similar situations have happened in various open-source projects, Ampere used to provide ARM instance access to builders, before being acquired by Softbank, now the world need more such Ampere's than ever.
OK, this one confused me. There is Chimera Linux, and also ChimeraOS - I believe they're unrelated but I had never heard of Chinera Linux and ChimeraOS is a gaming focusses distro.
> The system also has no relation to ChimeraOS, besides the unfortunate name similarity. ChimeraOS used to be called GamerOS and renamed itself to ChimeraOS later; however, at this point Chimera Linux was already in public development with its name in place.
I'm slightly hesitant to mention it for fear of a flamewar, but as someone with a niche usecase that procludes me from using systemd/glibc, I'm very grateful to Chimera as a modern take on non-GNU/Linux.
yeah I'm also taking great inspiration from Alpine, but I like to see diversity in the space.
as one example, musl values portability over performance (great for my usecase), which makes it often significantly slower than glibc. Alpine keeps their musl relatively close to upstream, where Chimera is patches theirs more heavily.
The public doesn't have access to RISC-V hardware and it won't have access anytime soon.
The problem to be solved seems availability of the hardware, not support from a small Linux distribution. It's not like we can go to Hetzner and rent a RISC-V server or go to AWS and provision a RISC-V VM.
And the availability will only improve if there is enough demand from the market to build such hardware. The EU and China wanting to be less dependant on US tech might help here.
Of course, RISC-V hardware should be on par on perf/price with x86 and ARM to tempt someone to switch.