Not dropping RISC-V support after all, maybe | Hacker News Reader

Not dropping RISC-V support after all, maybe

chimera-linux.org

64 pointstodsacerdoti37 comments

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.

Whilst not exactly easy to come across quite yet, there are some signs of growing public availability for RISC-V:

https://frame.work/fr/en/products/deep-computing-risc-v-main...

https://store.deepcomputing.io/products/dc-roma-riscv-laptop...

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.

Milk-V Pioneer has been the go to build machine for RISC-V (which was used here) which is much faster than a Raspberry Pi 3 for obvious reasons.

Felix Yan uses the same machine for building Archlinux on RISC-V.

> The public doesn't have access to RISC-V hardware and it won't have access anytime soon.

I do! I have a Milk-V Meles and I had a Milk-V Oasis on pre-order before it's cancellation. Been considering buying the Milk-V Megrez.

> The public doesn't have access to RISC-V hardware and it won't have access anytime soon.

There's plenty of RISC-V hardware around, and anyone can buy it. eg. [1]

[1] https://wiki.gentoo.org/wiki/RISC-V_hardware_list

He mean "desktop grade" hardware. Something that you might compile an entire distro on.

Those are all SBCs, and slow ones at that. Nobody is compiling an entire Linux distro on something like a Raspberry Pi 3.

> 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.

Yeah but it is 2025 and adoption means using it

Yes, but the Linux they were compiling on in the 90s was a lot smaller & simpler than the Linux they would compile now.

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).

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.

You don't need to compile on the same hardware, cross-compilation is a viable option

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.

I am not sure what your comment has to do with mine?

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.

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.

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.

[1]: https://pine64.com/product/pinetab-v-10-1-8gb-128gb-risc-v-b...

[2]: https://pine64.com/product/star64-model-a-8gb-single-board-c...

Just adjust your expectations. x86-64 is the architecture of yesterday, ARM64 is for today, RISC-V looks like the future.

Saw this thread and thought back to that thread as I hadn't heard of Chimera Linux before you mentioned them.

Glad to see that they're not dropping RISC-V support for the moment - not that I'm a RISC-V user yet, but I agree that it's the future.

Before you get too excited..

> nowhere near my original idea of being similar to Cortex-A72; the cores are more comparable to Cortex-A55 in practical performance

Once RISC-V has a performance/price ratio of an RK3588 or N100 we can start talking about the future

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.

>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.

You can go to Scaleway and provision an RISC-V instance

https://labs.scaleway.com/en/em-rv1/

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.

Odd that there are two with Chimera in the name:

https://chimeraos.org/ https://chimera-linux.org/

> 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.

" (maybe)"

Good news for their huge userbase (3 people around the globe)

I am very tempted to install solely so I could say "Ah, ah, ah: it's not GNU/Linux, it's Linux." The distro is a Linux kernel with BSD userland.

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.

There's also Alpine Linux, using openrc, musl, and busybox.

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.

Reply on news.ycombinator.com