[RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

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.GM14496@xxxxxxxxxxxxxxxxxxxxxx/

=== 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.