Plan zur Einstellung der Unterstützung von älteren ARM-Prozessoren im Linux-Kernel

Arnd Bergmann, der für die Kernel-Pakete bei SUSE verantwortlich ist, hat in der Entwicklermailingliste des Linux-Kernels einen Plan zur Eliminierung des Kernel- und Build-Tools-Codes zur Unterstützung alter ARM-CPUs und der damit verbundenen ABIs, Befehlssätze und Kernfunktionen veröffentlicht. Der Plan befindet sich derzeit im RFC-Stadium, d.h. er ist zur Diskussion in der Community ausgestellt. Bei Genehmigung des Plans soll die Entfernung alter ARM-Prozessoren im Linux-Kernel 6.12 beginnen, dessen Veröffentlichung für Dezember geplant ist. Die ersten Kandidaten für die Entfernung sind ARMv4 (ohne ARMv4T), iWMMXt, BE32 und OABI.

Die Einstellung der Unterstützung alter ARM-CPUs im Kern überschneidet sich mit der Einstellung ihrer Unterstützung in GCC – einige der zum Entfernen vorgeschlagenen CPUs werden bereits in den aktuellen GCC-Zweigen nicht mehr unterstützt, während andere in zukünftigen Versionen entfernt werden sollen, was die Aktualisierung und Implementierung neuer Funktionen im Compiler erleichtert. Die Entfernung der Unterstützung für die Architektur in GCC erfordert auch deren Entfernung aus dem Kern, falls die minimal unterstützte GCC-Version, die der Kernel benötigt (aktuell wird mindestens GCC 5.1 für den Kernel-Bau benötigt), erhöht wird.

Architekturen, Chips und Erweiterungen, deren Entfernung aus dem Kern vorgeschlagen wird:

• ARMv3 – die Unterstützung wurde bereits in GCC 9 eingestellt.
• ARMv4 – wird für noch verbreitete Prozessoren wie StrongARM und FA526 verwendet, wobei die neuesten dieser Chips vor etwa 20 Jahren veröffentlicht wurden. Die Unterstützung für ARMv4 wurde in Debian 5.0 eingestellt. Zunächst wird empfohlen, die Unterstützung für ARMv4 in GCC einzustellen und einige Jahre später auch im Kern.
• ARMv4T – es gibt 6 SoC-Familien mit den Kernen ARM720T, ARM920T und ARM922T, die häufiger anzutreffen sind als SoCs auf ARMv4-Basis. Die Unterstützung für ARMv4T wurde in Debian 9.0 eingestellt. Die Unterstützung von ARMv4T im Kern wird angestrebt, jedoch nicht bevor die Unterstützung für ARMv5 eingestellt wird.
• ARMv5 – wird auf etwa 1/3 aller unterstützten Plattformen im Kern verwendet, doch die meisten dieser Plattformen befinden sich am Ende ihres Lebenszyklus. Debian unterstützt ARMv5 weiterhin, jedoch wird die Aufrechterhaltung der Unterstützung aufgrund des Fehlens von FPU und atomaren Operationen immer schwieriger und wahrscheinlich wird der Debian-Port für ARMv5 bald in den Status nicht-offiziell versetzt.
• Frühe Generationen von ARMv6 – werden in SoCs wie ARM1136r0p (NXP i.MX31) und OMAP24xx (Nokia N8xx) verwendet, jedoch erfordert ihre Unterstützung 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 Inkompatibilität mit dem standardisierten ARMv7-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 Memory Management Unit (MMU) bleiben. Die Arbeit an Kernen für Systeme ohne MMU wurde 2017 eingestellt, nachdem auf die Entwicklung von RTOS wie Zephyr umgestiegen wurde. Es wird vorgeschlagen, die Unterstützung für ARMv7-M im Jahr 2027 zu entfernen, zehn Jahre nach der Einstellung der Entwicklung, trotz der fortgesetzten Unterstützung in GCC.
• iWMMXt — im Kernel wurde bereits die Unterstützung für die CPU ARMv7 PJ4 (MMP2, Berlin) eingestellt, danach gab es keine noch gängigen Systeme, die diesen Befehlssatz verwenden. Die Unterstützung für iWMMXt wurde bereits in Clang eingestellt und wird für die 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 über mehrere Jahre hinweg niemand die Probleme behoben hat.
• BE8 (big-endian ARMv7) — in vielen Treibern gibt es Probleme, die Arbeit wurde eingestellt und es liegen keine Informationen über verbleibende Geräte vor. Der BE8-Modus könnte für Tests von Komponenten im Benutzerspeicherbereich auf big-endian-Systemen von Interesse sein, daher wird die Unterstützung von BE8 im Kernel und GCC voraussichtlich noch mehrere Jahre fortbestehen, bevor sie zu Problemen führt.

Vorgeschlagene Kernel-Funktionen zur Entfernung:

• Die param_struct-Struktur, die bis zu ATAGS (ARM Tag-Area) verwendet wurde — wurde bereits 2001 als veraltet erklärt, wird jedoch weiterhin im Code für RiscPC- und Footbridge-Plattformen verwendet.
• Dateien mit Parametern basierend auf der ATAGS-Struktur (die zur Übertragung von Konfigurationsinformationen vor dem Device Tree verwendet wurde) — im Kernel verbleiben 29 Dateien, die mit 10 SoC-Plattformen, die ATAGS verwenden, verbunden sind.
• OABI (Old ABI, alte ABI für die ARM-Architektur) — wird jetzt fast überall EABI (Embedded ABI) verwendet. OABI ist die Ursache vieler Fehler, da Treiberentwickler bestimmte zugehörige Besonderheiten nicht mehr beachten. Die Unterstützung von OABI beim Kompilieren von Benutzerraumschnittstellen wurde in GCC 4.8 eingestellt, aber für den Kernel bleibt das Flag „-mabi=apcs-gnu“ bestehen. Es wird empfohlen, OABI vorerst beizubehalten, aber die Aktivierung durch Nachlässigkeit zu erschweren.
• Der OABI-Kompatibilitätsmodus (OABI_COMPAT) — erlaubt die Ausführung von ausführbaren Dateien, die für OABI erstellt wurden, unter Verwendung des EABI-Kernels. Es treten besondere Probleme bei den Treibern aufgrund der Inkompatibilität mit ioctl auf, aber der Wartungsaufwand für diesen Modus ist deutlich geringer als der für Kerne mit OABI. Um die Unterstützung von StrongARM aufrechtzuerhalten, ist es sinnvoll, die Unterstützung von OABI oder OABI_COMPAT beizubehalten.
• NWFPE (No Floating Point Emulator, Emulator für Fließkommaoperationen) — Patches zur Entfernung wurden bereits vor 11 Jahren vorgeschlagen, aber NWFPE wird für den Betrieb bestimmter Benutzerraumkomponenten benötigt, die für OABI erstellt wurden, daher wird empfohlen, die Unterstützung von NWFPE bis zur Beibehaltung der Unterstützung von OABI oder OABI_COMPAT im Kernel aufrechtzuerhalten.
• Highmem (wird zur Verwaltung des Speichers in Bereichen über 1 GB verwendet) – die meisten ARM-Systeme können ohne Aktivierung von Highmem arbeiten oder CONFIG_VMSPLIT_2GB nutzen, um auf die ersten 2 GB physischen Speicher zuzugreifen. Es wird daran gearbeitet, den Zugang zu 4 GB RAM auf Systemen mit LPAE (Cortex-A7/A15) zu ermöglichen; nach Abschluss dieser Arbeiten könnte die Highmem-Unterstützung entfernt werden.
• Sparsemem – erforderlich für Systeme, die Highmem benötigen.

Bereits zur Entfernung vorgeschlagene Plattformen:

• RiscPC – die älteste der im Kernel unterstützten Plattformen. Wird in GCC seit der Version 9.x nicht mehr unterstützt, da die Unterstützung für ARMv3 entfernt wurde. Der Betreuer testet weiterhin die Funktionalität des Kernels auf dieser Plattform, aber echte Benutzer scheinen nicht mehr vorhanden zu sein, daher könnte die Unterstützung eingestellt werden, wenn das Interesse des Betreuers nachlässt.
• SA1100, Footbridge – veraltete Plattformen, die aus Nostalgiegründen erhalten bleiben. Fast alle Dateien mit Beschreibungen der Boards 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 Frage der Entfernung hängt von den Absichten des Betreuers ab.
• Gemini, Moxart — nutzen CPUs auf Basis von ARMv4. Die Chips wurden vor über 20 Jahren hergestellt, jedoch erfordert deren Unterstützung keinerlei zusätzlichen Aufwand, weshalb es keinen Sinn macht, sie vor der Abschaltung der StrongARM-Plattform zu entfernen.
• Die Dateien zur Unterstützung der PXA-Plattform befinden sich in einem veralteten Zustand und sind nicht mehr in Gebrauch; sollte das Interesse nicht zurückkehren, sollen sie Anfang 2025 entfernt werden.
• OMAP1 bleibt einerseits die einzige Plattform auf Basis von ARMv4T/ARMv5 ohne Unterstützung für Device Tree, und es sind keine Bewegungen zur Einführung von Device Tree zu beobachten; andererseits gibt es jedoch weiterhin Nutzer der Plattform.
• Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 — nutzen CPUs auf Basis von ARMv4T. Es wird an der Übertragung der Platformbeschreibungen auf Device Tree gearbeitet, aber der Sinn einer Unterstützung bleibt nur so lange bestehen, wie die Unterstützung für ARMv5 erhalten bleibt.
• OMAP24xx ist die einzige Plattform auf Basis von ARMv6, die aktive Nutzer hat. Die Beibehaltung der Unterstützung hängt von der Fortführung der Unterstützung des CPUs arm1136r0 ab.
• iMX31 — es sind keine Informationen über aktive Nutzer verfügbar, jedoch macht es keinen Sinn, sie vor OMAP2 zu entfernen.
• S3C64xx (Cragganmore) — die einzige Plattform ohne Unterstützung für Device Tree, basierend auf ARMv6K. Die Plattform wird weiterhin zur Testung von Audiocodecs verwendet, daher ist die Entfernung bis zur Übertragung der Tests auf eine andere Karte verschoben.
• Orion5x, mv78xx0 — die Frage der Entfernung wird Anfang nächsten Jahres erörtert.
• 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 für 2026 geprüft.

Quelle: opennet.ru