Message-ID: <5c7f9469-78ad-4092-8e93-bfb41028ca34@arm.com>
Date: Tue, 20 Aug 2024 15:58:51 +0100
From: Richard Earnshaw <Richard.Earnshaw@....com>
To: Arnd Bergmann <arnd@...db.de>, <linux-arm-kernel@...ts.infradead.org>
CC: <linux-kernel@...r.kernel.org>, Russell King <linux@...linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>, 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 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.

Powered by blists - more mailing lists