[RFC} arm architecture board/feature deprecation timeline

[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@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.

Re: [RFC} arm architecture board/feature deprecation timeline

[Aaro Koskinen]

Hi,

On Wed, Jul 31, 2024 at 07:29:29PM +0200, Arnd Bergmann wrote:
> === 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.

FWIW, I have been never able to boot N8x0 unless CONFIG_SMP was disabled
(but haven't tested recently if the situation has changed). And probably
nobody else is anymore even booting these with modern kernels. Common
distro kernel support for N8x0 would be unlikely anyway due to bootloader
and memory limitations.

These tablets are not very attractive for hobbyists anymore as the display
support got broken and eventually deleted due to bitrot. There has been
some out-of-tree patches/interest to regain display and other features,
but no major progress really in 10 years or so. The last major mainline
feature was adding Retu watchdog support that allowed the device to stay
on longer than 30 seconds after the boot (the hardware watchdog cannot
be disabled).

I guess in OMAP-land N8x0 is one of the least used/active boards, so if
it causes "a lot of pain" then maybe could be a candidate for deprecation.
But with custom kernel config, the board has been pretty stable overall
between the releases for limited use cases.

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

Here situation hasn't changed - all of the boards are equally
important/useful, at least from a maintainer point of view. The routine
I use to test/debug kernel releases relies on all of them.

A.

Re: [RFC} arm architecture board/feature deprecation timeline

[Krzysztof Kozlowski]

On 31/07/2024 19:29, Arnd Bergmann wrote:
> 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.

All this (and what was below the quote) looks reasonable to me,
including Samsung S3C64xx and keeping support for RPi 1 (I was using it
till ~3 years ago).

Best regards,
Krzysztof

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Wed, Jul 31, 2024, at 21:13, Aaro Koskinen wrote:
> On Wed, Jul 31, 2024 at 07:29:29PM +0200, Arnd Bergmann wrote:
>> === 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.
>
> FWIW, I have been never able to boot N8x0 unless CONFIG_SMP was disabled
> (but haven't tested recently if the situation has changed). And probably
> nobody else is anymore even booting these with modern kernels. Common
> distro kernel support for N8x0 would be unlikely anyway due to bootloader
> and memory limitations.

Thanks for your quick reply!

I don't think there were ever any distro kernels with support for
N8x0 and other hardware in the same binary, but I do recall Tony
testing the omap2plus_defconfig across omap2 through omap5
successfully in the past, which is the main reason we kept this
as a Kconfig option.

The combination has always been a bit odd, and aside from the
problems with atomics and barriers, there was also the odd
ARM11MPcore cache handling that got removed in 2560cffd2134
("ARM: Delete ARM11MPCore (ARM11 ARMv6K SMP) support")

> These tablets are not very attractive for hobbyists anymore as the display
> support got broken and eventually deleted due to bitrot. There has been
> some out-of-tree patches/interest to regain display and other features,
> but no major progress really in 10 years or so. The last major mainline
> feature was adding Retu watchdog support that allowed the device to stay
> on longer than 30 seconds after the boot (the hardware watchdog cannot
> be disabled).
>
> I guess in OMAP-land N8x0 is one of the least used/active boards, so if
> it causes "a lot of pain" then maybe could be a candidate for deprecation.
> But with custom kernel config, the board has been pretty stable overall
> between the releases for limited use cases.

Yes, I think it would help a lot to deprecate it, at least this
would save me the work of moving ARMv6 into an ARMv5 compatible
option (I have done the patches, but they are entirely untested
on real hardware and probably incorrect).

Would the timing make any difference to you? I.e. does it help
to keep another year or two, or would dropping it in early 2025
be the same?

We'd also want to coordinate this with the i.MX31 maintainers,
since dropping both together is the only way to remove
ARM1136r0 support.

>> === 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.
>
> Here situation hasn't changed - all of the boards are equally
> important/useful, at least from a maintainer point of view. The routine
> I use to test/debug kernel releases relies on all of them.

Ok, noted. Since you are doing the testing, that at least means
we have a chance of cleaning up the code gradually towards using
DT. Dmitry has started a migration of platform_data towards
DT compatible device properties, which can be done gradually
for the 22 platform drivers you use. This unfortunately still
leaves the nonstandard dmaengine interface (for UDC), but we
can deal with that later.

     Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Richard Earnshaw]

On 31/07/2024 18:29, Arnd Bergmann wrote:
> 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.

Thanks for putting this all together Arnd, it will be very useful for planning purposes.

I've added a few notes below.

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

Yes, this was due to architectural restrictions from the way the StrongArm CPU was plugged into the RiscPC system bus - the bus was designed before StrongArm and couldn't handle the half-word memory accesses that Armv4 introduced.

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

This is good to know.  The lack of Thumb (particularly the lack of BX) on these CPUs is a major wart we still have to handle in the compiler.

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

I don't expect Armv4T support to disappear any time soon.  But these days maintenance for CPUs this old is pretty minimal - we try to keep it working, but you might be better off with older tools.

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

We marked iWMMXt as deprecated in gcc-14 and will likely remove support in GCC-15.  We expect to continue supporting these as Armv5T cores, but not the iwmmxt (or other XScale) extensions.  

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

Gas 2.43 (finally) drops support for the FPA and Maverick.  gas 2.44 may well drop support for OABI binaries (arm-none-elf, as opposed to arm-none-eabi).  Support for these is probably buggy now and it is certainly making maintenance more difficult.

> 
> === 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 above re FPA removal from GAS.  GCC removed FPA support in 2012!

> 
> See the discussion at https://lore.kernel.org/linux-arm-kernel/20130410191206.GM14496@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.

Re: [RFC} arm architecture board/feature deprecation timeline

[Aaro Koskinen]

Hi,

On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote:
> > These tablets are not very attractive for hobbyists anymore as the display
> > support got broken and eventually deleted due to bitrot. There has been
> > some out-of-tree patches/interest to regain display and other features,
> > but no major progress really in 10 years or so. The last major mainline
> > feature was adding Retu watchdog support that allowed the device to stay
> > on longer than 30 seconds after the boot (the hardware watchdog cannot
> > be disabled).
> >
> > I guess in OMAP-land N8x0 is one of the least used/active boards, so if
> > it causes "a lot of pain" then maybe could be a candidate for deprecation.
> > But with custom kernel config, the board has been pretty stable overall
> > between the releases for limited use cases.
> 
> Yes, I think it would help a lot to deprecate it, at least this
> would save me the work of moving ARMv6 into an ARMv5 compatible
> option (I have done the patches, but they are entirely untested
> on real hardware and probably incorrect).
> 
> Would the timing make any difference to you? I.e. does it help
> to keep another year or two, or would dropping it in early 2025
> be the same?

Early 2025 could come too soon, but anyway during 2025 sounds OK. Let's
see if anyone else has comments. At least one more LTS release where it
has been tested would be nice.

> We'd also want to coordinate this with the i.MX31 maintainers,
> since dropping both together is the only way to remove
> ARM1136r0 support.
> 
> >> === 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.
> >
> > Here situation hasn't changed - all of the boards are equally
> > important/useful, at least from a maintainer point of view. The routine
> > I use to test/debug kernel releases relies on all of them.
> 
> Ok, noted. Since you are doing the testing, that at least means
> we have a chance of cleaning up the code gradually towards using
> DT. Dmitry has started a migration of platform_data towards
> DT compatible device properties, which can be done gradually
> for the 22 platform drivers you use. This unfortunately still
> leaves the nonstandard dmaengine interface (for UDC), but we
> can deal with that later.

I have some plans to work on that. There's a long-standing bug with 15xx
DMA, but I have gotten that working, just need send those fixes out. After
that the conversion to new dmaengine should be more straightforward,
as we have a working testable reference for both boards using the UDC.

A.

Re: [RFC} arm architecture board/feature deprecation timeline

[Linus Walleij]

On Wed, Jul 31, 2024 at 7:29 PM Arnd Bergmann <arnd@arndb.de> wrote:

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

I am actively using the Gemini as my NAS with OpenWrt and there
are several users of it in the OpenWrt community.

I don't know if there are enough of us to keep ARMv4 support in
GCC, but ARMv4 support has been added to CLANG (along
with ARMv4t), and I have tested to compile kernels for these
devices with CLANG (for testing CFI!) and they work fine, so if
GCC drops it, we can still build them with CLANG where it apparently
isn't a maintenance burden given that it was recently added.

Maybe CLANG has a more adaptive backend?

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

This is either really hard, or I'm a bad developer. But I keep
churning it.

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

Yeah we use these devices. I don't know what counts as big
enough community to be considered, it's at least not just
me.

Gemini builds are in the official OpenWrt repos:
https://downloads.openwrt.org/releases/23.05.4/targets/gemini/generic/

Yours,
Linus Walleij

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 1, 2024, at 20:23, Aaro Koskinen wrote:
> On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote:
>> 
>> Would the timing make any difference to you? I.e. does it help
>> to keep another year or two, or would dropping it in early 2025
>> be the same?
>
> Early 2025 could come too soon, but anyway during 2025 sounds OK. Let's
> see if anyone else has comments. At least one more LTS release where it
> has been tested would be nice.

To be clear: with "early 2025" I meant after the next LTS release
(6.12 as it seems), but one LTS later (early 2026) is still a
good outlook.

>> Ok, noted. Since you are doing the testing, that at least means
>> we have a chance of cleaning up the code gradually towards using
>> DT. Dmitry has started a migration of platform_data towards
>> DT compatible device properties, which can be done gradually
>> for the 22 platform drivers you use. This unfortunately still
>> leaves the nonstandard dmaengine interface (for UDC), but we
>> can deal with that later.
>
> I have some plans to work on that. There's a long-standing bug with 15xx
> DMA, but I have gotten that working, just need send those fixes out. After
> that the conversion to new dmaengine should be more straightforward,
> as we have a working testable reference for both boards using the UDC.

Nice, that does give a realistic hope of eventually doing a full
DT conversion then. If we manage to do both the DMA engine and
the device properties work, I would hope that writing an equivalent
dts file gets fairly easy.

     Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 1, 2024, at 21:53, Linus Walleij wrote:
> On Wed, Jul 31, 2024 at 7:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> 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.
>
> I am actively using the Gemini as my NAS with OpenWrt and there
> are several users of it in the OpenWrt community.
>
> I don't know if there are enough of us to keep ARMv4 support in
> GCC, but ARMv4 support has been added to CLANG (along
> with ARMv4t), and I have tested to compile kernels for these
> devices with CLANG (for testing CFI!) and they work fine, so if
> GCC drops it, we can still build them with CLANG where it apparently
> isn't a maintenance burden given that it was recently added.
>
> Maybe CLANG has a more adaptive backend?

It's certainly good to have a backup plan, but I also think that
if we expect ARMv4 support to be required past gcc-15, we should
ask the gcc developers to keep it for a bit longer. Ultimately
I think it is best to remove it from gcc, we just need to
optimize the timing. More on that below.

>> === 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.
>
> This is either really hard, or I'm a bad developer. But I keep
> churning it.

I do feel a little bad about this as well, because much
of this was my original idea and I'm just offloading it to
you.

On the other hand, the continued existence of highmem
keeps coming up as an issue and I feel we have to do
something about it, see this week's

https://lore.kernel.org/lkml/CAHk-=wjhQ-TTg40xSP5dP0a1_90LMbxhvX0bsVBdv3wpQN2xQQ@mail.gmail.com/

>> === 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.
>
> Yeah we use these devices. I don't know what counts as big
> enough community to be considered, it's at least not just
> me.
>
> Gemini builds are in the official OpenWrt repos:
> https://downloads.openwrt.org/releases/23.05.4/targets/gemini/generic/

Ok. From the kernel perspective, there is no benefit in
dropping support for gemini specifically as long as there
are any users left and we can build it with a version of gcc
or clang that has ARMv4 support. Here are my current
assumptions for the timeline of when that will happen,
please let me know about anything you disagree with:

- Gemini will be the last ARMv4 we want to support, all
  StrongARM and FA536 are already less useful and can be
  dropped earlier or together with Gemini when it gets to
  that.

- Gemini has no dependency on OABI or NWFPE, since all
  users with new kernels are on EABI softfloat userland.

- There are no remaining users on new kernels with
  anything other than OpenWRT.

- The most recent OpenWRT release is supported for two
  or more years and uses a one year old kernel at
  the time of release, as well as the four latest
  gcc releases.

- OpenWRT minimum recommended RAM historically doubles
  every five or six years and will go up from 128MB to
  256MB in one of the next four releases.

Marking ARMv4 as deprecated in gcc-15, and removing it
gcc-16 would make Openwrt-29.x the last release to have
an ARMv4 compiler, using the late-2027 kernel release.
The last security updates for that release would be
in 2031, +/- 2 years if OpenWRT policies change in the
meantime.

If you think there will still be enough users upgrading
OpenWRT on these in 2030, we can recommend that gcc drops
ARMv4 support later, but my feeling is that anything
past OpenWRT-29.x is already limited by both the memory
bloat problem and the half-life of 20 year old consumer
hardware.

      Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 1, 2024, at 16:15, Richard Earnshaw wrote:
> On 31/07/2024 18:29, Arnd Bergmann wrote:
>>   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.
>
> This is good to know.  The lack of Thumb (particularly the lack of BX) on these
> CPUs is a major wart we still have to handle in the compiler.

See also my (too long) reply to Linus Walleij. He thinks we may
want to support ARMv4 a little longer, but hopefully we can reach
a consensus about how long exactly.

>> === 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.
>
> We marked iWMMXt as deprecated in gcc-14 and will likely remove support 
> in GCC-15.  We expect to continue supporting these as Armv5T cores, but 
> not the iwmmxt (or other XScale) extensions.  

Ok, good to know. The kernel doesn't actually have a build
time dependency on gcc's xscale or iwmmxt support aside from the
one assembly file we build with gcc -march=xscale.

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

Do you have any comments on BE8 support? I would imagine
that having two (mostly) unused big-endian targets in
the compiler still complicates things a bit.

>> 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.
>
> Gas 2.43 (finally) drops support for the FPA and Maverick. gas 2.44 
> may well drop support for OABI binaries (arm-none-elf, as opposed to 
> arm-none-eabi).  Support for these is probably buggy now and it is 
> certainly making maintenance more difficult.

Ok. I can certainly confirm that we regularly run into
build problems with -mabi=apcs in the kernel, usually
because of the incompatible structure alignment rules.
If binutils are dropping support, that also means we will
eventually stop supporting it in the kernel.

>> === 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 above re FPA removal from GAS.  GCC removed FPA support in 2012!

Right, for us this is clearly only done for legacy user
binaries. It is still possible to run an OABI Debian-5.0
or older rootfs with a new kernel, but there are not a lot
of reasons to do so, other than ARMv4 (StrongARM)
hardware. The only times I ever tried using it were
to test kernel changes that impact OABI syscall handling.

       Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Linus Walleij]

On Fri, Aug 2, 2024 at 5:12 PM Arnd Bergmann <arnd@arndb.de> wrote:

> Right, for us this is clearly only done for legacy user
> binaries. It is still possible to run an OABI Debian-5.0
> or older rootfs with a new kernel, but there are not a lot
> of reasons to do so, other than ARMv4 (StrongARM)
> hardware. The only times I ever tried using it were
> to test kernel changes that impact OABI syscall handling.

I tried it with the old RedHat rootfs of the NetWinder. It "worked"
but you had to create e.g a sysfs directory for the thing to even
boot. Debian 5 got its last update 12 years or so ago.

Security-wise it must be strongly discouraged to connect
anything like that to a public network given the plethora of issues
in that old userspace, so I don't know if it can even be
useful for anything. The SSH agent will be refused by
contemporary servers. Maybe if you just have 1-2 old OABI
binaries without source code that you just have to keep running?
Is there any such system?

If people absolutely want to run these machines they should
probably port OpenWrt to them so they can run a modern
userspace, and OpenWrt uses EABI, albeit with a hack, but it's
the best I know of:
https://github.com/openwrt/openwrt/blob/main/toolchain/gcc/patches-14.x/840-armv4_pass_fix-v4bx_to_ld.patch

Yours,
Linus Walleij

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 1, 2024, at 10:59, Arnd Bergmann wrote:
> On Wed, Jul 31, 2024, at 21:13, Aaro Koskinen wrote:
>> On Wed, Jul 31, 2024 at 07:29:29PM +0200, Arnd Bergmann wrote:
>>> === 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.
>>
>> FWIW, I have been never able to boot N8x0 unless CONFIG_SMP was disabled
>> (but haven't tested recently if the situation has changed). And probably
>> nobody else is anymore even booting these with modern kernels. Common
>> distro kernel support for N8x0 would be unlikely anyway due to bootloader
>> and memory limitations.
>
> Thanks for your quick reply!
>
> I don't think there were ever any distro kernels with support for
> N8x0 and other hardware in the same binary, but I do recall Tony
> testing the omap2plus_defconfig across omap2 through omap5
> successfully in the past, which is the main reason we kept this
> as a Kconfig option.

Thinking about this some more, I wonder if we should just
change the Kconfig dependencies now (for 6.12, possibly backported)
and forbid ARM1136r0, i.e. OMAP2 and i.MX31, from being enabled
in combination with SMP.

This would immediately prevent the bug you are seeing and
allow the cleanups we've been wanting to do for a while,
and it would avoid the larger-scale rework that I had
planned (moving armv6 into an armv5 kernel).

The main reason we didn't do this in the past was that it broke
Tony's workflow of testing omap2plus_defconfig across all
platforms, but I assume this all changed with the new group
maintainership anyway.

The effect here would be that imx_v6_v7_defconfig would
only inlucde imx35 but not imx31, and that omap2plus_defconfig
would turn into effectively omap3plus.

I would still tentatively schedule both for removal in early
2026, but if we add the !SMP dependency it's not a big deal to
keep them around after that either. We can make that decision
next year.

       Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [240805 07:58]:
> Thinking about this some more, I wonder if we should just
> change the Kconfig dependencies now (for 6.12, possibly backported)
> and forbid ARM1136r0, i.e. OMAP2 and i.MX31, from being enabled
> in combination with SMP.
> 
> This would immediately prevent the bug you are seeing and
> allow the cleanups we've been wanting to do for a while,
> and it would avoid the larger-scale rework that I had
> planned (moving armv6 into an armv5 kernel).
> 
> The main reason we didn't do this in the past was that it broke
> Tony's workflow of testing omap2plus_defconfig across all
> platforms, but I assume this all changed with the new group
> maintainership anyway.

Yes please go ahead, no objection from me.

Also related, the 2430 support could be dropped as AFAIK there
are no active users for it. It's similar to the 2420 support
that n8x0 use, and only 2420 support should be kept.

> The effect here would be that imx_v6_v7_defconfig would
> only inlucde imx35 but not imx31, and that omap2plus_defconfig
> would turn into effectively omap3plus.

Yes that makes sense for the active devices. Note that
multi_v7_defconfig is too bloated to boot many of these devices..

> I would still tentatively schedule both for removal in early
> 2026, but if we add the !SMP dependency it's not a big deal to
> keep them around after that either. We can make that decision
> next year.

Makes sense and the SMP related change can be done now.

Regards,

Tony

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Mon, Aug 5, 2024, at 14:30, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [240805 07:58]:
>> Thinking about this some more, I wonder if we should just
>> change the Kconfig dependencies now (for 6.12, possibly backported)
>> and forbid ARM1136r0, i.e. OMAP2 and i.MX31, from being enabled
>> in combination with SMP.
>> 
>> This would immediately prevent the bug you are seeing and
>> allow the cleanups we've been wanting to do for a while,
>> and it would avoid the larger-scale rework that I had
>> planned (moving armv6 into an armv5 kernel).
>> 
>> The main reason we didn't do this in the past was that it broke
>> Tony's workflow of testing omap2plus_defconfig across all
>> platforms, but I assume this all changed with the new group
>> maintainership anyway.
>
> Yes please go ahead, no objection from me.
>
> Also related, the 2430 support could be dropped as AFAIK there
> are no active users for it. It's similar to the 2420 support
> that n8x0 use, and only 2420 support should be kept.

I've taken a look at this, and my feeling is that we would
not gain much dropping 2430 since it has very little unique
hardware, except for a few files in mach-omap2 and drivers/clk.

Keeping it around as long as 2420 seems to be less work
overall, so I won't send patches to drop this one. If anyone
else wants to remove it, please go ahead.

While looking at 2430 support, I did notice that musb support
got lost in the DT conversion, which you mentioned as being
incomplete at the time. This does mean it's almost certainly
not been used for over a decade with an upstream kernel.

      Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Matt Turner]

On 07/31, Arnd Bergmann wrote:
>=== 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.

pixman had [1][2] iwMMXt paths that I optimized for the XO 1.75 and
would occasionally test on a CuBox over the years.

I'm surprised to see that commit b9920fdd5a75 ("ARM: 9352/1: iwmmxt:
Remove support for PJ4/PJ4B cores") landed with the claim that "there is
no v6/v7 user space that actually makes use of this". A quick Google
search reveals evidence of usage [3]. It doesn't seem like this should
have been backported to the stable branches in any case.

I know that ffmpeg used to have iwMMXt paths as well, but I believe they
were removed a few years ago.

Anyway, I guess it's totally dead now.

[1] https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/108
[2] https://mattst88.com/blog/2012/07/06/My_time_optimizing_graphics_performance_on_the_OLPC_XO_1.75_laptop/
[3] https://www.phoronix.com/news/MTEzNDQ

Re: [RFC} arm architecture board/feature deprecation timeline

[jeremy]

For the Buffalo devices we still have a lot of folks using Marvell Kirkwood, 
Orion5x and MV78100 NAS devices. In a world where SATA provides the cheapest $ 
per TB storage and Gigabit Ethernet is still standard they end up being 
surprisingly relevant for hobbyists.  

The two pre-DTB device files that we're still using are:
mach-mv78xx0/buffalo-wxl-setup.c
mach-orion5x/terastation_pro2-setup.c

If those can stick around for the next LTS kernel that should give me sufficient 
time to try converting them to DTS like the other Orion5x/Kirkwood devices.

Thank you for your attention,
-Jeremy


On Wednesday, July 31, 2024 12:29:29 PM CDT Arnd Bergmann wrote:
> 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@n2100.arm.l
> inux.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.

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 15, 2024, at 20:24, Matt Turner wrote:
> On 07/31, Arnd Bergmann wrote:
>>=== 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.
>
> pixman had [1][2] iwMMXt paths that I optimized for the XO 1.75 and
> would occasionally test on a CuBox over the years.
>
> I'm surprised to see that commit b9920fdd5a75 ("ARM: 9352/1: iwmmxt:
> Remove support for PJ4/PJ4B cores") landed with the claim that "there is
> no v6/v7 user space that actually makes use of this". A quick Google
> search reveals evidence of usage [3]. It doesn't seem like this should
> have been backported to the stable branches in any case.

Sorry for missing this one, I'm sure I spend more than a quick
google search trying to find instances of this, but clearly didn't
see this, and I now see that pixman is the only package listed in
https://codesearch.debian.net that uses the compiler flags.

I'm still not sure how your version worked on ARMv7, was this before
or after the move to the hardfloat ABI? What I see on modern armhf
gcc targets is that they reject -march=iwmmxt{,2} because those
imply armv5 without vfp, while armhf toolchains require vfpv3d16
as the minimum fpu.

My guess is that the pixman code still works correctly for softfloat
toolchains, but the meson.build check would fall back to the vfpv3
version for armv7/hardfloat builds.

gcc also rejects "-march=iwmmxt2+vfpv3-d16". While it accepts
"-march=iwmmxt2 -mfpu=vfpv3-d16", I suspect that this combination
has not been tested well.

> I know that ffmpeg used to have iwMMXt paths as well, but I believe they
> were removed a few years ago.

Right, apparently this was in 2012:
https://gitlab.laihua.com/linshizhi/ffmpeg.wasm-core/commit/363bd1c62c1bcbac2dcb56f3dc47824f075888d2

   Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Thu, Aug 15, 2024, at 21:53, jeremy@jeremypeper.com wrote:
> For the Buffalo devices we still have a lot of folks using Marvell Kirkwood, 
> Orion5x and MV78100 NAS devices. In a world where SATA provides the cheapest $ 
> per TB storage and Gigabit Ethernet is still standard they end up being 
> surprisingly relevant for hobbyists.  
>
> The two pre-DTB device files that we're still using are:
> mach-mv78xx0/buffalo-wxl-setup.c
> mach-orion5x/terastation_pro2-setup.c
>
> If those can stick around for the next LTS kernel that should give me 
> sufficient 
> time to try converting them to DTS like the other Orion5x/Kirkwood 
> devices.

Right, the plan was always to keep them for this year's LTS kernel,
which is almost certainly going to be 6.12. This should be enough
for Debian Trixie.

I expect that the terastation pro2 is going to be fairly easy to
convert to DT as there is already support for similar Orion5x
machines. In this case I would just remove all the Orion5x board
files and you can add a dts file later on. The bit I'm unsure
about here is legacy PCI support. I see that the board file enables
both PCI and PCIe, but I don't know if both are actually used,
or if everything is on PCIe.

I have some old patches for separating orion legacy PCI from
PCIe support, as only the latter has a modern driver (shared
with kirkwood and armadaxp). If you can confirm that the machine
actually uses PCI, I can dig those out from my backups.

The WXL machine is going to be more work since there is currently
no DT support for mv78xx0, but everything except the pin controller
should at least have a driver since this SoC is somewhere between
Kirkwood and Dove. Having a hack for the pin controller similar
to what orion5x has is probably fine, especially if you only
need to support one machine.

Let me know if you need any help during the conversion.

    Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

Two small additions:

On Mon, Aug 19, 2024, at 11:17, Arnd Bergmann wrote:
> On Thu, Aug 15, 2024, at 21:53, jeremy@jeremypeper.com wrote:
> I expect that the terastation pro2 is going to be fairly easy to
> convert to DT as there is already support for similar Orion5x
> machines. In this case I would just remove all the Orion5x board
> files and you can add a dts file later on. The bit I'm unsure
> about here is legacy PCI support. I see that the board file enables
> both PCI and PCIe, but I don't know if both are actually used,
> or if everything is on PCIe.
>
> I have some old patches for separating orion legacy PCI from
> PCIe support, as only the latter has a modern driver (shared
> with kirkwood and armadaxp). If you can confirm that the machine
> actually uses PCI, I can dig those out from my backups.

I did find this myself later, the machine does use an on-board
PCI connected SATA controller, which is obviously required to
make the machine useful.

Doing a PCI host bridge driver with DT support correctly is
a lot of work, especially if there is only a single machine
using it. Since this uses the same drivers/ata/sata-mv.c
driver as the other orion/kirkwood machines, I wonder if we
can just pretend that this is a platform device and skip
all of the PCI probing. I think this only needs a few
small changes to the sata-mv.c driver, but it does require
that the PCI bus is left in a known state by the boot loader.

> The WXL machine is going to be more work since there is currently
> no DT support for mv78xx0, but everything except the pin controller
> should at least have a driver since this SoC is somewhere between
> Kirkwood and Dove. Having a hack for the pin controller similar
> to what orion5x has is probably fine, especially if you only
> need to support one machine.

The complication here is that removing the board file would
imply that all of the mv78xx0 code immediately becomes dead
code. I guess the next best idea is to remove the orion5x
and dove board files first and then move bits of plat-orion
that are actually used by the WXL machine into the mv78xx0
directory.

      Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Andrew Lunn]

On Mon, Aug 19, 2024 at 04:12:10PM +0200, Arnd Bergmann wrote:
> Two small additions:
> 
> On Mon, Aug 19, 2024, at 11:17, Arnd Bergmann wrote:
> > On Thu, Aug 15, 2024, at 21:53, jeremy@jeremypeper.com wrote:
> > I expect that the terastation pro2 is going to be fairly easy to
> > convert to DT as there is already support for similar Orion5x
> > machines. In this case I would just remove all the Orion5x board
> > files and you can add a dts file later on. The bit I'm unsure
> > about here is legacy PCI support. I see that the board file enables
> > both PCI and PCIe, but I don't know if both are actually used,
> > or if everything is on PCIe.
> >
> > I have some old patches for separating orion legacy PCI from
> > PCIe support, as only the latter has a modern driver (shared
> > with kirkwood and armadaxp). If you can confirm that the machine
> > actually uses PCI, I can dig those out from my backups.
> 
> I did find this myself later, the machine does use an on-board
> PCI connected SATA controller, which is obviously required to
> make the machine useful.
> 
> Doing a PCI host bridge driver with DT support correctly is
> a lot of work, especially if there is only a single machine
> using it. Since this uses the same drivers/ata/sata-mv.c
> driver as the other orion/kirkwood machines, I wonder if we
> can just pretend that this is a platform device and skip
> all of the PCI probing. I think this only needs a few
> small changes to the sata-mv.c driver, but it does require
> that the PCI bus is left in a known state by the boot loader.

It is a long time since i looked at Orion, so i could be wrong....

As far as i remember, it has a PCI controller and a PCIe
controller. They are slightly different. The PCIe part is i think
simpler to support, it follows the standards better. I _think_ the PCI
controller uses a GPIO for interrupt support, which causes a mess.

If only PCIe is needed, it should not be too hard to make work. I
would try to avoid the PCI controller is possible.

      Andrew

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Mon, Aug 19, 2024, at 16:23, Andrew Lunn wrote:
> On Mon, Aug 19, 2024 at 04:12:10PM +0200, Arnd Bergmann wrote:
>
> It is a long time since i looked at Orion, so i could be wrong....
>
> As far as i remember, it has a PCI controller and a PCIe
> controller. They are slightly different. The PCIe part is i think
> simpler to support, it follows the standards better. I _think_ the PCI
> controller uses a GPIO for interrupt support, which causes a mess.
>
> If only PCIe is needed, it should not be too hard to make work. I
> would try to avoid the PCI controller is possible.

This machine uses both PCIe (for ethernet) and PCI (for SATA).

The PCIe driver is arch/arm/plat-orion/pcie.c and is shared
with mach-dove and mach-mv78xx0, previously also with kirkwood
and presumably armadaxp, which now use the more modern
drivers/pci/controller/pci-mvebu.c.

I just looked at the other dts files for orion5x and see
that they still use the old pci/pcie driver without an
entry in the dts files.

This is clearly not where we want to be in the long run,
but doing the same thing for the terastation_pro2
is at least not going to make it worse.

       Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[jeremy]

On Monday, August 19, 2024 9:23:16 AM CDT Andrew Lunn wrote:
> On Mon, Aug 19, 2024 at 04:12:10PM +0200, Arnd Bergmann wrote:
> > Two small additions:
> > 
> > On Mon, Aug 19, 2024, at 11:17, Arnd Bergmann wrote:
> > > On Thu, Aug 15, 2024, at 21:53, jeremy@jeremypeper.com wrote:
> > > I expect that the terastation pro2 is going to be fairly easy to
> > > convert to DT as there is already support for similar Orion5x
> > > machines. In this case I would just remove all the Orion5x board
> > > files and you can add a dts file later on. The bit I'm unsure
> > > about here is legacy PCI support. I see that the board file enables
> > > both PCI and PCIe, but I don't know if both are actually used,
> > > or if everything is on PCIe.
> > > 
> > > I have some old patches for separating orion legacy PCI from
> > > PCIe support, as only the latter has a modern driver (shared
> > > with kirkwood and armadaxp). If you can confirm that the machine
> > > actually uses PCI, I can dig those out from my backups.
> > 
> > I did find this myself later, the machine does use an on-board
> > PCI connected SATA controller, which is obviously required to
> > make the machine useful.
> > 
> > Doing a PCI host bridge driver with DT support correctly is
> > a lot of work, especially if there is only a single machine
> > using it. Since this uses the same drivers/ata/sata-mv.c
> > driver as the other orion/kirkwood machines, I wonder if we
> > can just pretend that this is a platform device and skip
> > all of the PCI probing. I think this only needs a few
> > small changes to the sata-mv.c driver, but it does require
> > that the PCI bus is left in a known state by the boot loader.
> 
> It is a long time since i looked at Orion, so i could be wrong....
> 
> As far as i remember, it has a PCI controller and a PCIe
> controller. They are slightly different. The PCIe part is i think
> simpler to support, it follows the standards better. I _think_ the PCI
> controller uses a GPIO for interrupt support, which causes a mess.
> 
> If only PCIe is needed, it should not be too hard to make work. I
> would try to avoid the PCI controller is possible.
> 
>       Andrew

Looking at the ts2pro I think it's PCI rather than PCIe but I'm not certain:

0001:01:07.0 SCSI storage controller: Marvell Technology Group Ltd. 88SX6042 
PCI-X 4-Port SATA-II (rev 02)
        Subsystem: Marvell Technology Group Ltd. 88SX6042 PCI-X 4-Port SATA-II
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B+ DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 128, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 44
        Region 0: Memory at e8000000 (64-bit, non-prefetchable) [size=1M]
        Region 2: I/O ports at 10000 [size=256]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] PCI-X non-bridge device
                Command: DPERE- ERO- RBC=512 OST=4
                Status: Dev=01:07.0 64bit+ 133MHz+ SCD- USC- DC=simple 
DMMRBC=512 DMOST=4 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: sata_mv

root@ts2pro:~# dmesg | grep -i pcie
root@ts2pro:~# dmesg | grep -i pci | head
[   25.598898] PCI host bridge to bus 0000:00
[   25.598924] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[   25.598963] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[   25.598993] pci_bus 0000:00: No busn resource found for root bus, will use 
[bus 00-ff]
[   25.599019] pci_bus 0000:00: scanning bus
[   25.599082] pci 0000:00:00.0: [11ab:5281] type 00 class 0x058000
[   25.599127] pci 0000:00:00.0: reg 0x10: [mem 0xf1000000-0xf10fffff 64bit 
pref]
[   25.599166] pci 0000:00:00.0: reg 0x18: [mem 0x00000000-0x07ffffff]
[   25.599687] pci_bus 0000:00: fixups for bus
[   25.599711] PCI: bus0: Fast back to back transfers disabled

Re: [RFC} arm architecture board/feature deprecation timeline

[Richard Earnshaw]

On 02/08/2024 16:12, Arnd Bergmann wrote:
> On Thu, Aug 1, 2024, at 16:15, Richard Earnshaw wrote:
>> On 31/07/2024 18:29, Arnd Bergmann wrote:
>>>   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.
>>
>> This is good to know.  The lack of Thumb (particularly the lack of BX) on these
>> CPUs is a major wart we still have to handle in the compiler.
> 
> See also my (too long) reply to Linus Walleij. He thinks we may
> want to support ARMv4 a little longer, but hopefully we can reach
> a consensus about how long exactly.
> 
>>> === 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.
>>
>> We marked iWMMXt as deprecated in gcc-14 and will likely remove support 
>> in GCC-15.  We expect to continue supporting these as Armv5T cores, but 
>> not the iwmmxt (or other XScale) extensions.  
> 
> Ok, good to know. The kernel doesn't actually have a build
> time dependency on gcc's xscale or iwmmxt support aside from the
> one assembly file we build with gcc -march=xscale.

I think you mean -mcpu=xscale (-march=xscale isn't recognized), or perhaps you mean -march=iwmmxt?  Either way, if this is an assembly file, then you can just add the appropriate '.arch' (and/or .cpu) directives to the source file and then the command line options can be dropped.

> 
>>> === 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.
> 
> Do you have any comments on BE8 support? I would imagine
> that having two (mostly) unused big-endian targets in
> the compiler still complicates things a bit.

The compiler/assembler largely treat BE8 and BE32 the same; the linker then byte-swaps the BE8 instructions during linking to generate BE8 images (this is mostly why we need mapping symbols).  That won't really change if we drop BE32 support.  So I don't think we gain much from this.

> 
>>> 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.
>>
>> Gas 2.43 (finally) drops support for the FPA and Maverick. gas 2.44 
>> may well drop support for OABI binaries (arm-none-elf, as opposed to 
>> arm-none-eabi).  Support for these is probably buggy now and it is 
>> certainly making maintenance more difficult.
> 
> Ok. I can certainly confirm that we regularly run into
> build problems with -mabi=apcs in the kernel, usually
> because of the incompatible structure alignment rules.
> If binutils are dropping support, that also means we will
> eventually stop supporting it in the kernel.

This is primarily about the arm-elf (as opposed to arm-eabi) object file format, -mabi=apcs doesn't change that.  There are some options in gcc relating to the old APCS that I'd really like to get rid of (in particular -mapcs-frame (aka -mapcs)), but that's a separate issue.

> 
>>> === 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 above re FPA removal from GAS.  GCC removed FPA support in 2012!
> 
> Right, for us this is clearly only done for legacy user
> binaries. It is still possible to run an OABI Debian-5.0
> or older rootfs with a new kernel, but there are not a lot
> of reasons to do so, other than ARMv4 (StrongARM)
> hardware. The only times I ever tried using it were
> to test kernel changes that impact OABI syscall handling.
> 

That's what I'd expect by this point.  The main difficulty would come in reconstructing test-cases for this (if you have any), since the tools will no-longer be able to do that.

R.

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Tue, Aug 20, 2024, at 16:58, Richard Earnshaw wrote:
> On 02/08/2024 16:12, Arnd Bergmann wrote:
>>>> === 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.
>>>
>>> We marked iWMMXt as deprecated in gcc-14 and will likely remove support 
>>> in GCC-15.  We expect to continue supporting these as Armv5T cores, but 
>>> not the iwmmxt (or other XScale) extensions.  
>> 
>> Ok, good to know. The kernel doesn't actually have a build
>> time dependency on gcc's xscale or iwmmxt support aside from the
>> one assembly file we build with gcc -march=xscale.
>
> I think you mean -mcpu=xscale (-march=xscale isn't recognized), or 
> perhaps you mean -march=iwmmxt? 

We currently use "-Wa,-mcpu=iwmmxt", sorry for the mixup.

>>>> === 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.
>> 
>> Do you have any comments on BE8 support? I would imagine
>> that having two (mostly) unused big-endian targets in
>> the compiler still complicates things a bit.
>
> The compiler/assembler largely treat BE8 and BE32 the same; the linker 
> then byte-swaps the BE8 instructions during linking to generate BE8 
> images (this is mostly why we need mapping symbols).  That won't really 
> change if we drop BE32 support.  So I don't think we gain much from 
> this.

Right, makes sense. I can never remember the way this is
actually implemented

>> Ok. I can certainly confirm that we regularly run into
>> build problems with -mabi=apcs in the kernel, usually
>> because of the incompatible structure alignment rules.
>> If binutils are dropping support, that also means we will
>> eventually stop supporting it in the kernel.
>
> This is primarily about the arm-elf (as opposed to arm-eabi) object 
> file format, -mabi=apcs doesn't change that.  There are some options in 
> gcc relating to the old APCS that I'd really like to get rid of (in 
> particular -mapcs-frame (aka -mapcs)), but that's a separate issue.

I think I mixed this up as well, what we use for OABI kernels
is "-mabi=apcs-gnu", which creates an "ELF 32-bit LSB relocatable,
ARM, version 1 (ARM)" OABI  file instead of "ELF 32-bit LSB
relocatable, ARM, EABI5 version 1 (SYSV)".

We still use "-mapcs-frame" whenever we enable CONFIG_FRAME_POINTER
(aka -fno-omit-frame-pointer). Frame pointers used to be required
for a number of things in the kernel, now there are only two
places that don't work with the modern unwinder:

- CONFIG_ARCH_CORRECT_STACKTRACE_ON_KRETPROBE -- this should
  be on someone's TODO list, no idea why the implementation was
  never completed for this.

- OABI (-mabi=apcs-gnu) kernels, for the in-kernel stack unwinder

Neither of those is particularly important I think, so deprecating
-mapcs-frame along with -mabi=apcs-gnu for new gcc versions should
be from the kernel perspective.

I'll also send a patch to make both OABI and OABI_COMPAT support
depend on StrongARM, based on the earlier discussion. That way
dropping StrongARM (but not armv4 or fa526) in the future will also
eliminate OABI and nwfpe.

       Arnd

Re: [RFC} arm architecture board/feature deprecation timeline

[Alexander Dahl]

Hello Arnd,

Am Wed, Jul 31, 2024 at 07:29:29PM +0200 schrieb Arnd Bergmann:
> === 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.

FWIW, these are not only replacements, but actually new boards are
designed with SAM9X60 for example.

Not all have .dts files in mainline kernel, though.  Would that
improve or change things with regard to long term platform support, if
the .dts files were upstream?

Greets
Alex

Re: [RFC} arm architecture board/feature deprecation timeline

[Arnd Bergmann]

On Wed, Aug 21, 2024, at 06:15, Alexander Dahl wrote:
> Am Wed, Jul 31, 2024 at 07:29:29PM +0200 schrieb Arnd Bergmann:
>> === 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.
>
> FWIW, these are not only replacements, but actually new boards are
> designed with SAM9X60 for example.

Right, but I would assume that most of those board
designs using it are done because someone needs an
ARMv5 design in order to run a certain piece of
software, or because they are already invested in
Microchip's SAM9 ecosystem in other products.

For someone starting from scratch, there would be few
reasons to pick a SAM9 over e.g. an STM32MP1 with a
Cortex-A7 that is more capable in most ways but half
the cost.

> Not all have .dts files in mainline kernel, though.  Would that
> improve or change things with regard to long term platform support, if
> the .dts files were upstream?

I think upstreaming the dts files is mostly an advantage for
maintaining the specific boards, as it allows easier
integration into CI test environments and lets developers
see which drivers are used by a platform. Having at
least a couple of products with full dts files in addition
to the reference boards does help though.

For the at91 platform support itself in the kernel,
I don't see a real risk at the moment. There are a few
areas that make ARMv5 support risky in the long run:

- Debian support for the softfloat "armel" port will
  likely be moved into an inofficial port in the future,
  which in turn makes it harder for average kernel
  developers to test things. 

- There are discussions about making SMP support
  mandatory for all architectures in the kernel.
  If it gets to this, ARMv4T and ARMv5 support may
  need to end, unlike ARMv6K and up.

- Even longer in the future, all 32-bit kernel
  support will end. I don't expect this to happen
  for another 15 years, but the writing is on the
  wall.

      Arnd