RISC-V XIP Support Removed From Linux Kernel After Years of Instability

The Linux kernel's RISC-V Execute In Place (XIP) support is being removed after years of instability and lack of adoption. Introduced in Linux 5.13 back in 2021, the XIP feature allowed RISC-V systems to execute the kernel directly from non-volatile storage like NOR flash, reducing RAM usage by eliminating the need to copy the kernel image into memory at boot time.

A Pattern of Breakage

The feature's removal comes after a troubling pattern of extended downtime. According to developer Nam Cao, who authored the removal patch, XIP has been broken for significant periods:

• 18 months in 2023 before being fixed
• 4 months in 2024
• Currently broken for 10 months since commit a44fb5722199

This recurring instability has led developers to conclude that the feature simply isn't being used or tested adequately. As Cao noted in the patch description: "These are clear signs that XIP feature is not being used. I occasionally looked after XIP, but mostly because I was bored and had nothing better to do."

Technical Context

XIP was designed for embedded systems where RAM is at a premium. By allowing the kernel to run directly from ROM or flash memory, it could theoretically reduce the memory footprint of RISC-V systems. This is particularly relevant for IoT devices, industrial controllers, and other embedded applications where every kilobyte of RAM matters.

However, the feature's complexity and the challenges of maintaining compatibility with evolving kernel infrastructure appear to have outweighed its benefits. The current breakage stems from changes related to "runtime constant support" in the RISC-V architecture code.

Industry Implications

Interestingly, the removal comes at a time when RAM constraints are becoming more pressing across the industry, not less. With memory prices remaining volatile and the push toward more efficient computing continuing, one might expect features that reduce memory requirements to be more valuable than ever.

The decision suggests that either:

1. The target use cases for XIP simply aren't materializing in the RISC-V ecosystem
2. Alternative approaches to memory optimization are proving more practical
3. The complexity of maintaining XIP outweighs its benefits even in memory-constrained scenarios

Future Prospects

The patch is queued in RISC-V's "for-next" branch and will likely be part of Linux 7.1. However, the door isn't completely closed. Cao's patch includes the note: "Revert is possible if someone shows up complaining."

This pragmatic approach allows the kernel maintainers to clean up unused, problematic code while leaving the option open for revival if actual use cases emerge. It's a common pattern in kernel development where features that aren't actively maintained or used are removed to reduce the maintenance burden.

Broader RISC-V Ecosystem Impact

For developers working on RISC-V embedded systems, this removal means they'll need to rely on traditional kernel loading methods that require copying the kernel into RAM at boot time. While this increases memory requirements, it also provides the stability and testing coverage that comes with widely-used kernel paths.

The removal of XIP support highlights the challenges facing the RISC-V ecosystem as it matures. Features that look promising on paper may not survive the realities of maintenance overhead and actual usage patterns. It's a reminder that in open-source development, code that isn't actively used and maintained often becomes a liability rather than an asset.

The RISC-V community will be watching to see if any developers step forward to complain about the removal, which would signal genuine interest in the feature and potentially lead to its restoration with better maintenance practices in place.