Linux kernel developers move to purge legacy 32-bit Arm platform code as modernization efforts accelerate

The Linux kernel development community has initiated a significant technical housekeeping effort, with a new series of thirteen patches submitted to the kernel mailing lists marking the beginning of a systematic removal of legacy 32-bit Arm platform code. This initiative, spearheaded by kernel maintainer Arnd Bergmann, seeks to prune obsolete architectural support that has been flagged as deprecated during the Linux 7.3 development cycle. While the patches remain under review and have yet to be merged into the mainline tree, the proposal represents the most concrete progress to date in a multi-year effort to streamline the kernel’s codebase by shedding support for hardware that has long since passed its commercial and industrial relevance.

The Scope of the Cleanup

The current proposal targets the removal of specific board-support files located within the arch/arm/mach-* directory, along with their associated Kconfig configuration dependencies. This cleanup is substantial, encompassing approximately 300 patches in total, reflecting the massive footprint that legacy hardware support occupies in the kernel’s source tree.

Among the platforms slated for removal are systems that defined the early era of Arm-based computing in the late 1990s and early 2000s. The list includes the SA1100 boards, the Acorn RiscPC, Footbridge, and legacy PXA board files. Additionally, the purge extends to the Orion, Dove, and MV78xx0 boards, as well as various microcontrollers and system-on-chips (SoCs) including OMAP24xx, i.MX31, and non-MMU i.MX variants. Other notable targets include the LPC18xx and Axxia platforms, several STM32 series microcontrollers (F4, F7, and H7), the Versatile MPS2, and the AT91 SAMV7.

Chronology of the Modernization Effort

The push to deprecate and eventually remove these platforms did not emerge overnight. It is the culmination of a long-term strategy designed to reduce the maintenance burden on kernel developers. Arnd Bergmann, who has acted as a primary driver of this initiative, acknowledged the delays in his July 2026 mailing list thread, offering an apology for the two-year period of stagnation that allowed the initial deprecation efforts to languish.

The original roadmap for this cleanup had initially targeted 2025 or 2026 for the final removal of the code, contingent upon the release of a matching Long Term Support (LTS) kernel. Following the current trajectory, the plan is to formalize these removals in the Linux 7.4 release, which is expected to arrive between late December 2026 and early January 2027. If this timeline holds, the actual CPU support code for these legacy platforms would be fully excised in the release immediately following 7.4.

Technical Rationale and Maintenance Burden

From a software engineering perspective, maintaining support for obsolete hardware creates a "technical debt" that hinders the evolution of the Linux kernel. Every line of code that remains in the tree must be audited, tested, and potentially refactored whenever global changes to kernel APIs or infrastructure occur. When a platform reaches a point where it is no longer being actively used by a significant user base, the cost of maintaining that code begins to outweigh the utility it provides.

Linus Torvalds, the creator and lead maintainer of the Linux kernel, has consistently supported this "clean-slate" philosophy. His stance is rooted in the belief that the kernel should not be burdened by the ghosts of hardware past. This was clearly evidenced in 2022, when he questioned the continued necessity of the i486 CPU series, following the removal of i386 support in 2012. By 2025, the consensus among core maintainers was that no justifiable reason remained to allocate developer resources to such platforms. The current Arm cleanup follows this established precedent, treating the maintenance of ancient board files as an inefficient use of limited human capital.

The Impact on Legacy Infrastructure

It is essential to clarify the operational implications of this change: the removal of this code does not cause existing devices to experience an immediate hardware failure. Instead, it defines a "version ceiling" for these devices. Any hardware listed in the removal scope will be unable to run a mainline Linux kernel version 7.4 or higher.

For organizations or hobbyists relying on these specific platforms, the path forward involves either staying on a previous, long-term supported (LTS) version of the kernel that still contains the necessary board-specific code, or transitioning to specialized, niche distributions that may choose to backport or maintain the drivers independently. However, for the majority of the global technology ecosystem, these platforms represent obsolete hardware that has been supplanted by vastly more capable, power-efficient, and secure architectures.

The Shifting Landscape of Arm Development

The removal of this legacy support occurs simultaneously with an aggressive expansion of Arm support elsewhere in the kernel. The Linux 7.3 cycle has seen the introduction of support for modern, high-performance Arm-based silicon, including Apple’s M3 Pro, Max, and Ultra chips, as well as Samsung’s Exynos 1580 and Qualcomm’s latest offerings.

This juxtaposition illustrates the fundamental duality of the Linux kernel: it is a living, breathing entity that must constantly adapt to the cutting edge of semiconductor innovation while simultaneously pruning the dead weight of the past. The ability to pivot from supporting 20-year-old microcontrollers to cutting-edge 3nm processors in the same codebase is a testament to the flexibility of the kernel’s modular design.

Institutional and Community Response

The response from the wider kernel community has been largely supportive, though there remains a channel for dissent. Bergmann has explicitly left the window open for arguments against the removal of specific platforms, acknowledging that some enterprises may still maintain these systems in industrial or embedded environments.

However, the bar for keeping such code in the main tree is high. To prevent removal, a stakeholder must demonstrate that there is active, ongoing development or significant user interest that justifies the continued expenditure of community resources. Without such evidence, it is highly probable that the current proposal will be accepted by the maintainers and incorporated into the 7.4 cycle.

Future Implications for Embedded Systems

The ongoing purge of legacy 32-bit Arm code serves as a reminder to the embedded systems industry regarding the risks of long-term software reliance on proprietary or legacy board support. As the Linux kernel continues to modernize, the gap between "mainline" support and "legacy" hardware will only widen.

For companies developing hardware today, the lesson is clear: reliance on custom, highly specific board files that do not conform to modern, standardized frameworks (such as Device Tree or Generic Kernel Interfaces) risks eventual abandonment by the mainline community. As the industry moves toward more standardized, abstracted hardware interfaces, the need for the kind of board-specific "mach" code currently being deleted will decrease, hopefully preventing similar mass-removal events in the future.

Conclusion

The move to delete legacy 32-bit Arm code is a necessary step in the evolution of the Linux kernel. While the loss of support for devices like the Acorn RiscPC or the early i.MX chips may evoke nostalgia among tech enthusiasts, it is a pragmatic necessity for the world’s most ubiquitous operating system. By shedding the weight of the past, the kernel team ensures that the Linux ecosystem remains agile, secure, and ready to support the next generation of computing hardware. The transition to 7.4 and beyond marks not just the end of a line of code, but a continued commitment to the future of high-performance, maintainable software engineering.