Plan zur Einstellung der Unterstützung für alte ARM-Prozessoren im Linux-Kernel

Arnd Bergmann, zuständig für die Kernel-Pakete bei SUSE, hat in der Mailingliste der Linux-Kernel-Entwickler einen Plan veröffentlicht, der vorsieht, dass der Kernel und die auf GCC basierenden Build-Tools von Code zur Unterstützung alter ARM-CPUs sowie deren ABI, Befehlssätze und Kernel-Funktionen befreit werden. Der Plan befindet sich derzeit in der RFC-Phase, das heißt, er ist zur Diskussion innerhalb der Gemeinschaft gestellt. Bei Genehmigung des Plans wird vorgeschlagen, die alten ARM-Prozessoren mit Kernel 6.12 zu entfernen, dessen Veröffentlichung für Dezember erwartet wird. Die ersten Kandidaten für die Entfernung sind ARMv4 (ohne Entfernung von ARMv4T), iWMMXt, BE32 und OABI.

Die Einstellung der Unterstützung alter ARM-CPUs im Kernel überschneidet sich mit der Einstellung ihrer Unterstützung in GCC — einige der zum Entfernen angebotenen CPUs werden bereits nicht mehr in den aktuellen GCC-Zweigen unterstützt, während andere in künftigen Versionen entfernt werden sollen, was die Modernisierung und Implementierung neuer Funktionen im Compiler erleichtern wird. Die Entfernung der Architekturunterstützung in GCC erfordert auch die Entfernung ihrer Unterstützung im Kernel, wenn die minimal unterstützte Version von GCC (momentan ist mindestens Version 5.1 für den Kernel-Bau erforderlich) erhöht wird.

Architekturen, Chips und Erweiterungen, die aus dem Kernel entfernt werden sollen:

• ARMv3 — die Unterstützung wurde bereits in GCC 9 eingestellt.
• ARMv4 — wird für immer noch verwendete Prozessoren wie StrongARM und FA526 eingesetzt, wobei die neuesten dieser Chips vor etwa 20 Jahren veröffentlicht wurden. Die Unterstützung für ARMv4 wurde in Debian 5.0 eingestellt. Es wird vorgeschlagen, zunächst die Unterstützung von ARMv4 in GCC einzustellen und einige Jahre später auch im Kernel.
• ARMv4T — es gibt 6 SoC-Familien mit ARM720T-, ARM920T- und ARM922T-Kernen, die verbreiteter sind als SoC auf ARMv4-Basis. Die Unterstützung für ARMv4T wurde in Debian 9.0 eingestellt. Im Kernel wird die Unterstützung von ARMv4T geplant, jedoch nicht vor der Einstellung der Unterstützung für ARMv5.
• ARMv5 — wird auf etwa 1/3 aller unterstützten Plattformen im Kernel verwendet, aber die meisten dieser Plattformen befinden sich am Ende ihres Lebenszyklus. Debian unterstützt ARMv5 weiterhin, aber aufgrund des Fehlens von FPU und atomaren Operationen wird es immer schwieriger, die Unterstützung aufrechtzuerhalten, und wahrscheinlich wird der Debian-Port für ARMv5 bald als inoffiziell eingestuft.
• Frühe Generationen von ARMv6 — werden in SoCs wie ARM1136r0p (NXP i.MX31) und OMAP24xx (Nokia N8xx) verwendet, aber ihre Unterstützung erfordert Hacks, um in SMP-Kernen zu funktionieren.
• ARMv6K — wird im ARM1176 (Raspberry Pi 1, AST2500) und ARM1136r1 verwendet. Im Kernel gibt es keine Hindernisse für die Einstellung der Unterstützung, aber in den Distributionen gibt es Schwierigkeiten aufgrund der Unvereinbarkeit mit dem Standardarmv7-a+vfpv3-d16.
• ARMv7-M — wird in Mikrocontrollern auf Basis von Cortex-M3/M4/M7 verwendet, die die letzten unterstützten Chips im Kernel ohne Speicherverwaltungsblock (MMU) bleiben. Die Entwicklung von Kernen für Systeme ohne MMU wurde 2017 eingestellt, nachdem auf die Entwicklung von RTOS wie Zephyr umgeschaltet wurde. Es wird vorgeschlagen, die Unterstützung für ARMv7-M im Jahr 2027, zehn Jahre nach der Einstellung der Entwicklung, trotz fortdauernder Unterstützung in GCC zu entfernen.
• iWMMXt — die Unterstützung für die CPU ARMv7 PJ4 (MMP2, Berlin) wurde im Kernel bereits eingestellt, sodass keine verbreiteten Systeme mehr existieren, die diesen Befehlssatz verwenden. Die Unterstützung für iWMMXt wurde bereits in Clang eingestellt und wird zur Entfernung aus GCC vorgeschlagen.
• BE32 (big endian ARMv5) — wird nur in einem SoC Intel IXP4xx verwendet. In älteren Versionen von Debian wurde nur der Little-Endian-Modus unterstützt, aber in den Treibern bleiben ungelöste Probleme. Es wird vorgeschlagen, die Unterstützung für BE32 aus GCC und dem Kernel zu entfernen, da in den Treibern in mehreren Jahren niemand versucht hat, die Probleme zu beheben.
• BE8 (big-endian ARMv7) — in vielen Treibern gibt es Probleme, die Tests wurden eingestellt und es liegen keine Informationen über verbleibende verbreitete Geräte vor. Der BE8-Modus könnte für das Testen von Benutzerspace-Komponenten auf Big-Endian-Systemen von Interesse sein, weshalb die Unterstützung für BE8 im Kernel und GCC für mindestens mehrere Jahre erhalten bleiben soll, bevor Probleme auftreten.

Vorgeschlagene Möglichkeiten zur Entfernung im Linux-Kernel:

• Die Struktur param_struct, die bis zu ATAGS (ARM Tag-Area) verwendet wird — wurde bereits 2001 als veraltet erklärt, wird aber nach wie vor im Code für die RiscPC- und Footbridge-Plattformen verwendet.
• Dateien mit Parametern basierend auf der Struktur ATAGS (verwendet zur Übertragung von Konfigurationsinformationen vor dem Device Tree) — im Kernel verbleiben 29 Dateien, die mit 10 SoC-Plattformen verbunden sind, die ATAGS verwenden.
• OABI (Old ABI, das alte ABI für die ARM-Architektur) wird mittlerweile fast überall durch EABI (Embedded ABI) ersetzt. OABI verursacht viele Fehler, da die Treiberentwickler einige damit verbundene Besonderheiten nicht mehr berücksichtigt haben. Die Unterstützung von OABI beim Erstellen von Benutzerraums-Komponenten wurde in GCC 4.8 eingestellt, jedoch bleibt für den Kernel die Option „-mabi=apcs-gnu“. Es wird empfohlen, OABI vorerst beizubehalten, jedoch die Aktivierung durch Nachlässigkeit zu erschweren.
• Der OABI-Kompatibilitätsmodus (OABI_COMPAT) ermöglicht die Ausführung von ausführbaren Dateien, die für OABI erstellt wurden, unter Verwendung eines Kernels mit EABI. Es treten einige Probleme in Treibern aufgrund von Inkompatibilitäten mit ioctl auf, aber der Wartungsaufwand für diesen Modus ist deutlich geringer als der für Kernels mit OABI. Um die Unterstützung von StrongARM aufrechtzuerhalten, wäre es sinnvoll, die Unterstützung für OABI oder OABI_COMPAT beizubehalten.
• NWFPE (No Floating Point Emulator, Emulator für Fließkommaoperationen) – Patches zu dessen Entfernung wurden bereits vor 11 Jahren vorgeschlagen, aber NWFPE wird für den Betrieb einiger Benutzerraum-Komponenten benötigt, die für OABI erstellt wurden, sodass es empfohlen wird, die Unterstützung von NWFPE so lange aufrechtzuerhalten, wie im Kernel die Unterstützung für OABI oder OABI_COMPAT besteht.
• Highmem (wird zur Verwaltung von Speicherbereichen über 1 GB verwendet) – die meisten ARM-Systeme können ohne Aktivierung von highmem arbeiten oder können CONFIG_VMSPLIT_2GB verwenden, um auf die ersten 2 GB physischen Speichers zuzugreifen. Es wird an einem Zugang zu 4 GB RAM in Systemen mit LPAE (Cortex-A7/A15) gearbeitet; nach Abschluss dessen könnte die Unterstützung von Highmem entfernt werden.
• Sparsemem – ist erforderlich für Systeme, die highmem benötigen.

Vorgeschlagene Plattformen zur Entfernung:

• RiscPC – die älteste unterstützte Plattform im Kernel. Wird in GCC ab der Version 9.x nicht mehr unterstützt, aufgrund der Entfernung der Unterstützung für ARMv3. Der Betreuer testet weiterhin die Funktionsweise des Kernels auf dieser Plattform, aber es scheint keine realen Benutzer mehr zu geben, daher könnte die Unterstützung eingestellt werden, falls das Interesse des Betreuers nachlässt.
• SA1100, Footbridge – veraltete Plattformen, die nur aus nostalgischen Gründen erhalten bleiben. Fast alle Platinenbeschreibungsdateien für diese Plattformen wurden im Kernel 6.3 entfernt, es bleibt nur die Unterstützung für die Geräte ipaq h3600, assabet, netwinder und ebsa285. Die Entscheidung über die Entfernung hängt von den Absichten des Betreuers ab.
• Gemini, Moxart — verwenden CPUs auf Basis von ARMv4. Die Chips wurden vor über 20 Jahren hergestellt, aber ihre Unterstützung erfordert keine zusätzlichen Anstrengungen, daher macht es keinen Sinn, sie vor der Abschaltung der StrongARM-Plattform zu entfernen.
• Die Dateien zur Unterstützung der PXA-Plattform sind veraltet und haben den Gebrauch verloren. Sollte kein Interesse daran zurückkehren, ist geplant, sie Anfang 2025 zu entfernen.
• OMAP1 — bleibt einerseits die einzige Plattform auf Basis von ARMv4T/ARMv5 ohne Unterstützung des Device Tree, es gibt jedoch keine Anzeichen für einen Wechsel zu Device Tree. Andererseits hat die Plattform noch Nutzer.
• Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 — verwenden CPUs auf Basis von ARMv4T. Es wird an der Konvertierung der Plattformbeschreibungen zum Device Tree gearbeitet, aber die Unterstützung bleibt nur solange sinnvoll, solange ARMv5 unterstützt wird.
• OMAP24xx — ist die einzige Plattform auf Basis von ARMv6 mit aktiven Nutzern. Die Unterstützung hängt von der fortdauernden Unterstützung des CPUs arm1136r0 ab.
• iMX31 — es gibt keine Informationen über aktive Nutzer, aber es macht keinen Sinn, es vor OMAP2 zu entfernen.
• S3C64xx (Cragganmore) — ist die einzige Plattform ohne Unterstützung des Device Tree, die auf ARMv6K basiert. Die Plattform wird weiterhin für Tests von Audio-Codecs verwendet, daher ist die Entfernung aufgeschoben, bis die Tests auf ein anderes Board übertragen werden.
• Orion5x, mv78xx0 — die Frage der Entfernung wird Anfang nächsten Jahres geprüft.
• iMX35, WM8750, AST2500, BCM2835 — werden gut unterstützt und haben aktive Nutzer, eine Entfernung ist derzeit nicht geplant.
• stm32f4/f7/h7 — Mikrocontroller ohne MMU, die Unterstützung im Kernel wird fortgesetzt und es gibt aktive Nutzer. Die Frage der Entfernung wird 2026 geprüft.

Quelle: opennet.ru