We removed a lot of the unused board files at the beginning of 2023, and I'd like to plan ahead for other hardware and feature support that can be removed after the next stable kernel (linux-6.12).
TL;DR: I think we can deprecate toolchain support for ARMv4 (pre-thumb), iWMMXt, BE32 and OABI (-mabi=apcs-gnu) *if* that helps gcc-15, as we'll likely not need those any more after gcc-14 will be too old to build new kernels (ca. 2030). I hope we can keep reducing the number of non-DT board files a lot further, but I still expect this to take several more years before it is DT-only. Please reply here if you are using any of them so we can spare them once more. == Architectural features == These are features that require support from gcc, which in turn may benefit from dropping it. === ARMv3 === This was removed in gcc-9, so it will eventually get removed from the kernel as we raise the minimum compiler versions. Only RiscPC relies on building with -march=armv3, despite using an ARMv4 StrongARM CPU. === ARMv4 === This is used for both StrongARM and FA526 CPUs, which are still used on a small number of boards. Even the newest chips (moxa art, ) are close to 20 years olds but were still in use a few years ago. The last Debian release for these was Lenny (5.0). Dropping compiler support now would be appropriate IMHO, and we can drop kernel support in a few years. === ARMv4T === We still support six SoC families with ARMv4T cores (ARM720T, ARM920T and ARM922T). These are equally old to the ARMv4 ones, but have more users and developers working on them than the ARMv4 ones. Debian Stretch (9.0) last supported these. EP93xx in particular is used in some products with long support cycles, so we may end up supporting these in the kernel as long as ARMv5. === ARMv5 === About one third of all supported platforms use ARMv5, but most of these are near their end of support. Notably there are still new SAM9 variants from Microchip that are meant as backward-compatible replacements for their older variants. Debian still supports these, but the lack of FPU and atomics makes this harder, so I expect this to become an unofficial port in the future. === early ARMv6 === This is the ARM1136r0p in NXP i.MX31 and OMAP24xx, which in practice means just the Nokia N8xx tablet. It causes a lot of pain to support in the kernel since it requires special hacks to support in SMP-enabled kernels. I have a patch series that moves ARMv6 from being ARMv7 compatible to being ARMv5 compatible inside the kernel, which should help, but that needs more work. === ARMv6K === We dropped ARM11MPcore support last year, but still support ARM1176 (Raspberry Pi 1, AST2500) and ARM1136r1. These are easy to keep supporting in the kernel. Distro support is getting harder since they are slightly too old for the common armv7-a+vfpv3-d16 level. === ARMv7-M === Cortex-M3/M4/M7 are the only cores we support without an MMU, currently on 5 microcontroller platforms. Upstream work on NOMMU kernels has pretty much stopped in 2017 when everyone moved to open-source RTOS variants like Zephyr. I expect that we can drop support ten years later in 2027, but gcc will still have to support them on other operating systems. === iWMMXt === I'm not aware of any remaining users for iWMMXt, and we dropped support for ARMv7 PJ4 CPUs (MMP2, Berlin) already, so the only supported hardware that even has this is Intel/Marvell PXA and MMP1. Dropping support from gcc is probably a good idea now, it is already unsupported in clang. === big endian ARMv5 (BE32) kernel === There is one SoC that uses this, the Intel IXP4xx. Older versions of Debian supported this chip in little-endian mode, but the device drivers are known to be broken for LE now and would require someone to spend time on fixing them. I would suggest dropping support from gcc, which still gives us a few years to fix the ixp4xx support, or drop it when gcc-14 support is dropped from the kernel. Curiously, support was added in clang not long ago. === big-endian ARMv7 (BE8) kernel === This is very different from BE32 mode in making more sense from a kernel point of view. In theory any ARMv7 hardware should work, though a lot of drivers are buggy. I am not aware of any actual use cases, though in theory it can be helpful for testing big-endian userspace when one has access to Arm hardware but no other big-endian machine. We should probably keep this a few more years in both toolchain and kernel, unless it starts causing actual problems. I don't think anyone is testing it any more though. Side-note: netbsd has a armv7+be8 variant, so clang will likely keep supporting be8 even if gcc ends up dropping it in the future. == Kernel features == === pre-ATAGS param_struct === This was deprecated in 2001, to be removed in "5 years from now", which was a while ago. We can probably remove it now, or keep it around until the two platforms using it (RiscPC and Footbridge) are gone. === ATAGS based board files === After the previous cleanup, there are board 29 files in 10 SoC platforms remaining. I would hope we can reduce this significantly again, but need to go through the platforms individually. ep93xx is getting converted to DT, but the others have made no progress towards that. === OABI kernels === Practically everyone uses EABI today, and OABI support was dropped as a userspace target in gcc-4.8. The kernel still however allows being built as OABI by passing "-mabi=apcs-gnu", and this is used as the default for armv4/armv5 kernels. This is a frequent source for bugs as driver writers are unaware of the unusual struct padding, alignment and enum usage. I've stopped testing it in my randconfig builds a while ago because of random bugs. I would propose to leave the feature in the kernel but make it harder to enable by accident, changing the default for all targets to EABI and adding a dependency on 'CPU_32v4 || EXPERT'. For the compiler, I think removing support for -mabi=apcs makes sense, unless there are non-Linux targets that still use this. === OABI compat mode === This is the other way of running OABI binaries, using a normal EABI kernel. It suffers from a different set of bugs, as the kernel itself is fine, but driver specific structure layouts with user interfaces (usually ioctl) may be incompatible. The maintenance cost in the kernel is much lower than native OABI kernels, but I suspect there are even fewer users. Since there was never an EABI desktop distro for ARMv4, we probably want to keep at least one of the two (OABI or OABI_COMPAT) around as long as we support StrongARM machines. === NWFPE === Russell had a patch set to remove this 11 years ago, but ended up keeping it. This is fundamentally tied to OABI userland, so we'll likely need to keep it for as long as either OABI or OABI_COMPAT remains. See the discussion at https://lore.kernel.org/linux-arm-kernel/20130410191206.gm14...@n2100.arm.linux.org.uk/ === Highmem === Most Arm machines are fine without highmem support and can use something like CONFIG_VMSPLIT_2GB to address up to 2GB of physical memory. Machines larger than only popped up around the time of the Cortex-A15 in 2012 and for the most part got replaced by 64-bit chips within a short time. In addition, there are also a handful of Cortex-A9 and Marvell CPU based machines that have either more than 2GB of RAM or a very sparse memory map that requires highmem support. Linus Walleij has done some work towards being able to use up to 4GB of RAM with LPAE (Cortex-A7/A15 and later) machines, which I think still needs to be finished before we can remove support for highmem. === Sparsemem === There is a new discussion about removing support for traditional sparsemem support, see https://lwn.net/Articles/974517/. This also relates to machines that currently need highmem support in order to use all of their RAM even if the total size would fit into the lowmem area, e.g. on Renesas R-Car SoCs. In theory it should be possible to move the indirection layer from __page_to_pfn() to __pfn_to_phys() and support discontiguous lowmem that way, but I don't think anyone is working on that, and I don't know if that addresses the concerns with today's sparsemem implementation. == Platform support == === RiscPC === This is the oldest supported platform, and it will eventually have to get removed as it no longer works with gcc-9 or higher because of the ARMv3 removal. As far as I know, nobody aside from Russell has booted this machine in many years, so if he's stops upgrading his kernels, we could also remove it earlier. === SA1100, Footbridge === These are the other StrongARM based platforms, which like RiscPC are only relevant for nostalgia. When we removed the board files for 6.3, a couple of StrongARM machines were left that someone said they were interested in getting working again, and converting to DT. I don't think there has been any progress on this, so it seems unlikely to happen in the future. The last StrongARM machine that got added and that is still supported was the ipaq h3600 in linux-2.4.13. There are also machines that Russell is (was?) using: sa1100/assabet, footbridge/netwinder and footbridge/ebsa285. Being able to remove these would get rid of a lot of complexity both from the hardware being unusual and from them not using DT. Need input from Russell. === Gemini, Moxart === These both use the Faraday FA526 CPU core that like StrongARM implements ARMv4 rather than ARMv4T with thumb. The chips are also over 20 years old, but the kernel code has been updated and is not a maintenance burden by itself, so there is no value in removing these machines until StrongARM is also gone. On the other hand, removing both FA526 and StrongARM platforms means we can probably remove ARMv4 (non-T), OABI and NWFPE support more quickly if we want, or we can wait until a few years after gcc drops ARMv4. OpenWRT lists the gemini platform as supported in https://openwrt.org/docs/techref/targets/gemini, but none of the individual machines have builds for the current release. Need input from Linus Walleij. === PXA board files === There are two board files left in the PXA code that we did not remove two years ago, in the hope that this would help the DT conversion. Nothing happened since then, though qemu removed support for their releases. Unless someone has specific plans to work on them, I would remove these in early 2025. There is also DT support for some PXA boards, which would likely stay around. === OMAP1 === This is now the only ARMv4T/ARMv5 platform with no DT support, making it a target for removal at some point. Unlike PXA, there are still users, but it seems there are no current plans for a DT conversion. I would suggest going through the five boards individually to see which ones we can remove in 2025 and keep the remaining ones for the moment. === Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 === These are the other ARMv4T targets. Nikita is in the process of finishing up the DT support for EP93xx, after that these are very cheap to maintain in the kernel since the platform code is all up to date. Unless there is a specific reason to drop these, I expect them to stay around as long as ARMv5, probably to the end of this decade. === OMAP24xx === This is the one ARMv6 (non-K) platform that has active users. The platform support is fine, so it depends on what we do with arm1136r0 CPU support. If my patch for armv6 support in the armv5 kernel works out, we can treat it as a v5 variant and keep it as long as v5 itself, otherwise it would be nice to remove the kernel complexity by dropping arm1136r0 support like we did with arm11mpcore. === iMX31, realview/integrator with 1136r0 === I'm not aware of any users, but these don't get in the way as long as OMAP2 is there. Whatever we do with OMAP2 can also happen with these. === S3C64xx (Cragganmore) === This is the only ARMv6K board without devicetree support, and the board file contains about a similar amount of complexity as all other board files combined. arch/arm/mach-s3c/Kconfig.s3c64xx lists it as scheduled for removal early next year, which would allow a large amount of cleanup in platform and driver infrastructure. However, Mark Brown is actively using this machine as a testbed for audio codecs, which is what it was designed for by Wolfson (now Cirrus). There is no satisfying outcome of this that I see, my best idea is to delay the removal until Mark has moved on to something else. TODO: find out if Cirrus have a replacement that Mark can migrate to. === Orion5x, mv78xx0, dove board files === Like PXA, these were left behind in the hope that there would be progress towards DT conversion, but none of that happened aside from a small set of mv78xx0 bugfixes. On the contrary, Debian has now dropped the orion5x kernel binary citing lack of users, so it seems much less likely to ever complete. Out of the machines about half the orion5x ones have DT support, mv78xx0 has none, and dove DT support exists but is less complete than the board file. There is still a community around running Debian on some of these devices at https://github.com/1000001101000/Debian_on_Buffalo/wiki I would suggest removing all these board files in early 2025 to still allow building a 3rd-party kernel using the Debian 13 release sources. The orion5x DT support can get merged into mach-mvebu then. === iMX35, WM8750, AST2500, BCM2835 === These four are all ARMv6K platforms and fairly well supported, though only AST2500 and BCM2835 have an active user base. Support for ARMv6K is likely to stay around at last as long as ARMv5, so there are no plans for removing these. Most distros that had Raspberry Pi 1 armv6k-hardfloat support have dropped that now, but some minor ones still exist, while Debian and others runs ARMv5-softfloat userspace on them. === stm32f4/f7/h7 microcontrollers === These are the only MMU-less Arm chips that see any continued development, as ST keeps supporting their existing customers. There are also newer MCUs based on Cortex-M33 and up, but those don't run Linux as far as I know. Let's keep until at least 2026 before we start discussing deprecation. All other MCUs (IMXRT, SAMV7, LPC18xx, MPS2) are used much less than STM32F and can probably follow the same path once they get in the way of dropping v7m support.
