An Operating System Abandons Support for RISC-V

关注、星标公众号,直达精彩内容

Source: Content compiled from theregister, thank you.

The creators of the unique Chimera Linux distribution are abandoning support for RISC-V due to the insufficient speed of the suite built on the open instruction set architecture, which hinders the development process.

Chimera Linux (not to be confused with the gaming-focused ChimeraOS) 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 is derived from FreeBSD. Notably, it is not related to Alpine Linux, although it does use the apk packaging tool and the same musl C library as that distribution. 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 leader asked on Mastodon, “Would anyone be upset if I really dropped support for riscv64?” The next day, they released an announcement titled “Abandoning Support for RISC-V,” which stated:

I obtained a SiFive HiFive Unmatched board in October 2021, but it turned out to be useless for building because its performance 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 products.

If you are attracted by the specifications, 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 the boards, 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 RISC-V suites with decent performance aligns with our assessment of the Reg FOSS desk mentioned in 2022. Affordable hardware is slow, and hardware that is relatively fast is not cheap, and even then, it is hard to buy. 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 like 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 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 (high-performance vector units with 512-bit vectors that can dual-issue).

If sanctions had not been implemented, 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 in China, some aspects of which are commendable. It will be interesting to see if this situation extends to CPUs as well.

Support for RISC-V in Chimera Linux has been suspended.

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 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 obtained a SiFive HiFive Unmatched board in October 2021, but it turned out to be useless for building because its performance 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 having trouble, 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 8-core SoCs that are technically out-of-order designs, but are reportedly worse per core than the JH7110, making them 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 and thus unsuitable (similar to RPi3);

My HiFive Unmatched is in the same situation as 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 SoC supplier issues, and no one has seen a production chip, let alone a board. As far as I know, 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 because 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. Either way, 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 forever. When this happens, builds must be manually canceled and restarted (it is not deterministic). Before some fixes were made, this was even worse, but even with the latest version of the emulator, this still happens, especially during Go builds (because 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 the 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 is currently 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

ARMv7 and ARMv6 32-bit repositories may also 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/

*Disclaimer:This article is compiled from the internet, and the copyright belongs to the original author. If there is any error in the source information or infringement of rights, please contact us for deletion or authorization matters.

‧ END

Recommended Reading:

ZYNQ Learning | Collection

FPGA Learning | Collection

IC Design Learning | Collection

Leave a Comment