Message-Id: <a87da38e-e7b6-464c-b2b4-384237861075@app.fastmail.com>
Date: Fri, 02 Aug 2024 16:52:28 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Walleij" <linus.walleij@...aro.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 "Russell King" <linux@...linux.org.uk>,
 "Richard Earnshaw" <richard.earnshaw@....com>,
 "Richard Sandiford" <richard.sandiford@....com>,
 "Ramana Radhakrishnan" <ramanara@...dia.com>,
 "Nicolas Pitre" <nico@...xnic.net>,
 "Krzysztof Kozlowski" <krzk@...nel.org>,
 "Mark Brown" <broonie@...nel.org>,
 "Kristoffer Ericson" <kristoffer.ericson@...il.com>,
 "Robert Jarzmik" <robert.jarzmik@...e.fr>,
 "Aaro Koskinen" <aaro.koskinen@....fi>,
 "Janusz Krzysztofik" <jmkrzyszt@...il.com>,
 "Tony Lindgren" <tony@...mide.com>,
 Linux-OMAP <linux-omap@...r.kernel.org>,
 "Nikita Shubin" <nikita.shubin@...uefel.me>,
 linux-samsung-soc@...r.kernel.org, "Andrew Lunn" <andrew@...n.ch>,
 "Sebastian Hesselbarth" <sebastian.hesselbarth@...il.com>,
 "Gregory Clement" <gregory.clement@...tlin.com>,
 "Jeremy J. Peper" <jeremy@...emypeper.com>, debian-arm@...ts.debian.org,
 "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
 "Alexandre Torgue" <alexandre.torgue@...s.st.com>
Subject: Re: [RFC} arm architecture board/feature deprecation timeline

On Thu, Aug 1, 2024, at 21:53, Linus Walleij wrote:
> On Wed, Jul 31, 2024 at 7:29 PM Arnd Bergmann <arnd@...db.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

Powered by blists - more mailing lists