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