Mar.
Click the blue text to follow us
2025.03
Source: Content compiled from The Register, thank you.
The creator of the unique Chimera Linux distribution is abandoning support for RISC-V, as the suite built on the open instruction set architecture is not fast enough, hindering the development process.
Chimera Linux (not to be confused with ChimeraOS, which focuses on gaming) is a very unusual Linux distribution. Firstly, it does not include GNU. For a small project that has not yet reached version 1.0, it has an exceptionally broad platform support: x86-64, Arm64, little-endian and big-endian PowerPC, and RISC-V. Or at least it did until now with RISC-V.
We looked at this new distribution over two years ago. It had some ambitious goals. Most of the user space of Chimera Linux comes from FreeBSD. Notably, it is not related to Alpine Linux, although it does use the apk packaging tool from that distribution and the same musl C library. Given its release status, the platform support is particularly impressive—it only entered the testing phase at the end of last year.
A week ago, the project lead asked on Mastodon: “If I really drop support for riscv64, would anyone be upset?” The next day, they released an announcement titled “Abandoning Support for RISC-V,” which stated:
I received a SiFive HiFive Unmatched board in October 2021, but it turned out to be useless for building, as the performance of that board is similar to that of a Raspberry Pi 3.
The post listed the available RISC-V hardware they had evaluated and highlighted one piece of hardware that might be suitable for their builds:
The Milk-V Pioneer is a board with 64 out-of-order cores; it is the only one of its kind, with cores reportedly similar to ARM Cortex-A72.
If you are attracted by that specification, be prepared to click the “Buy Now” link, and you will be tempted. Only one of the three websites indicates that the hardware is available—even then, it is only for pre-order. Subsequently, another Mastodon post stated that they now have remote access to one of them, but it is still quite tricky.
In discussions on Lobsters regarding this move, there was more discussion about performance issues, including how to build micro build farms (for reference, “Q66” is Chimera developer Nina Kolesa).
Their assessment of the availability of reasonably performing RISC-V suites aligns with our assessment of the Reg FOSS desk mentioned in 2022. Affordable hardware is slow, while faster hardware is not cheap, and even then, it is hard to obtain. At the end of last year, when we tried to use a RISC-V board in the Framework laptop, our assessment was similar. It felt akin to a Raspberry Pi 3—usable if you have patience, but still slow.
In this post and elsewhere, one of the staunch advocates for RISC-V is Bruce Hoult, a long-time commentator for The Register, who pointed out the issues brought about by U.S. sanctions, as reported by The Register in January. He told us:
Sophgo is about to release the SG2380, which features 16 SiFive P670 cores (equivalent to Arm A78) and eight SiFive X280 cores (dual-issue but with 512-bit vector high-performance vector units) as an NPU.
If it weren’t for the sanctions, Sophgo would almost certainly have had test chips long ago and might now be close to mass production.
This seems to be a significant missed opportunity, but major shifts are happening globally, and worse things than CPUs not being released have already occurred. The Register has previously explored Linux distributions from China, some aspects of which are commendable. It will be interesting to see if this situation extends to CPUs as well.
Click follow and star with non-network eefocus
Scan to reply with the keyword “risc-v” for industry groups and to receive reports
Chimera Linux has suspended support for RISC-V.
This is a good example of a small Linux distribution helping each other, as Zach van Rijn, a co-developer of Adélie Linux, which is also based on musl-libc, granted the Chimera developers remote access to the Milk-V Pioneer machine:
The performance is acceptable, but far from the level I initially thought was similar to Cortex-A72; the actual performance of these cores is closer to Cortex-A55, especially since we had to disable vectors. However, with 64 cores, the build speed for most large projects is quite fast (however, any code written in Rust builds very slowly).
According to a recent Mastodon post, it runs Fedora 38 and has encountered some issues, but Kolesa is now running the version.
Announcement: Abandoning Support for RISC-V
The initial pipeline for RISC-V was added to the distribution in July 2021 and added to the repository later that year, meaning it has been present almost from the beginning. During this time, builds have been supported on x86_64 machines with qemu-userbinfmt emulation and transparent support from cbuild.
The reason for this is that we have no hardware available to use for performance reasons; I received a SiFive HiFive Unmatched board in October 2021, but it turned out to be useless for building, as the performance of that board is similar to that of a Raspberry Pi 3. Other boards have appeared since then, but none have shown significant improvements in this regard.
This is expected to be a temporary situation that will resolve itself in 2-3 years; now it is the first quarter of 2025, and the options are as follows:
-
The recently released HiFive P550 has performance similar to that of a Raspberry Pi 4, which is not suitable for this task; this board was supposed to be released years ago as part of a collaboration between SiFive and Intel (Horse Creek), but is now being released with a Chinese SoC;
-
The Milk-V Pioneer is a board with 64 out-of-order cores; it is the only one of its kind, with cores reportedly similar to ARM Cortex-A72. Theoretically, this should be sufficient, but these boards are hard to come by (especially since Sophgo is encountering difficulties, the U.S. has implemented new sanctions, and Mouser has removed all Milk-V products), and from what I know, it is quite unstable, has little support, and has various hardware issues;
-
Products based on Spacemit K1 (such as Milk-V Jupiter) have an 8-core SoC, which is technically an out-of-order design, but reportedly has worse per-core performance than JH7110, making it unsuitable;
-
Boards based on JH7110 (such as VisionFive 2, new framework boards, etc.) use 4 U74 cores (the same configuration as my HiFive), which are simple in-order designs, thus unsuitable (similar to RPi3);
My HiFive Unmatched is in the same situation as the above.
-
Other available cores are generally much worse than any of the above;
-
The promising option released in 2023 (Milk-V Oasis with 16 SiFive P670 cores) was ultimately canceled due to issues with the SoC supplier, and no one has seen a production chip, let alone a board. To my knowledge, there are no other options.
The current situation of relying on emulators is unsustainable. There are many issues with this approach:
We can never actually test the packages being built because the emulator is unreliable and leads to false positives. Conditionally disabling things for RISC-V is not a viable option, as they are not RISC-V issues, and this always happens in emulation, so all RISC-V packages are built without testing.
It is very slow, being the slowest builder in our queue so far. But it is still several times faster than builders like JH7110. Performance is actually quite unstable; things that can parallelize well run at a reasonably good speed due to being able to generate many emulators, while single-threaded and heavily forking things like configuration scripts run very slowly. Overall, it is much slower than any other builder, even though RISC-V is the only architecture without LTO before the launch of LoongArch64.
Most importantly, it is unreliable. The qemu emulator is prone to hanging during various workloads, and the emulator can go to sleep and stay that way indefinitely. When this happens, builds must be manually canceled and restarted (it is not deterministic). Before some fixes were implemented, this was even worse, but even with the latest version of the emulator, this still happens, especially during Go builds (as we rebuild every Go program when the toolchain updates secfixes, any such rebuild can require multiple manual cancellations and restarts).
Since it fully loads a powerful x86 machine, it is slow and power-hungry, which I am very dissatisfied with.
At this point, to have a relatively sustainable foundation, we need a board that is at least as powerful as a Raspberry Pi 5. This will still be the slowest builder in the fleet, but it may be faster and more reliable than the current emulation setup.
However, the industry seems uninterested in producing such machines, with most efforts focused on embedded (low-end) and things completely unrelated to distributions (AI/NPU, etc.), which do not help at all; at this point, I think we can no longer wait, especially since no remedies have been announced.
We have not encountered such issues on other architectures; clearly, x86 and ARM are currently mainstream, which is not surprising, but even architectures like LoongArch have completely acceptable hardware (not the fastest, but not a bottleneck), with reliable performance.
Of course, if acceptable build hardware is released and we can reasonably use it, support for this architecture will be reintroduced.
If this happens, the repository will be rebuilt from scratch, like a new architecture, with a process similar to what was recently done for LoongArch64. It will be a secondary architecture, with mandatory testing, no LTO, just like LoongArch64.
However, since such hardware does not yet exist and no announcements have been made, whether or when this will happen remains unknown.
Support for other architectures will not change. The new tier list will be:
-
Tier 1 for aarch64, ppc64le, and x86_64
-
Tier 2 for loongarch64
-
Tier 3 for ppc64
There is also a possibility that 32-bit ARMv7 and ARMv6 repositories will be launched in the coming months, as we may migrate all ARM versions to super-large Ampere Altra machines (currently AArch64 is served by Hetzner Cloud VM, which can no longer bear any load). However, this is not yet conclusive.
They later updated: After all, the current architecture will not be abandoned. For more details, see the newer article.
The next set of images will abandon support for RISC-V. The builders are still running, but they will stop in the coming days, and the repository will remain in place but in a frozen state.
There will be no changes in packaging (build configuration files will be retained, existing template support will be retained, cross-toolchain will be retained), but there will be no updates to the repo in the foreseeable future.
Reference link
https://www.theregister.com/2025/03/19/chimera_linux_riscv/
END
Welcome to leave comments and exchange in the comment area!
Industry Community
