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
