{"id":118783,"date":"2024-08-01T15:43:01","date_gmt":"2024-08-01T13:43:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux"},"modified":"2024-08-01T15:43:01","modified_gmt":"2024-08-01T13:43:01","slug":"plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/plan-prekrashheniya-podderzhki-staryh-proczessorov-arm-v-yadre-linux","title":{"rendered":"Plan de fin de prise en charge des anciens processeurs ARM dans le noyau Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Arnd Bergmann, responsable des paquets du noyau chez SUSE, a publi\u00e9 sur la liste de diffusion des d\u00e9veloppeurs du noyau Linux un plan visant \u00e0 \u00e9liminer le code de support pour les anciens CPU ARM et les ABI, jeux d'instructions et fonctionnalit\u00e9s associ\u00e9es dans le noyau et les outils de construction bas\u00e9s sur GCC. Le plan est pour l'instant en phase RFC, c'est-\u00e0-dire ouvert \u00e0 la discussion au sein de la communaut\u00e9. En cas d'approbation du plan, la suppression des anciens processeurs ARM est pr\u00e9vue pour le noyau Linux 6.12, dont la sortie est attendue en d\u00e9cembre. Les premiers candidats \u00e0 la suppression sont ARMv4 (sans retirer ARMv4T), iWMMXt, BE32 et OABI. <\/p>\n
La fin du support pour les anciens CPU ARM dans le noyau co\u00efncide avec l'arr\u00eat de leur prise en charge dans GCC \u2014 certains des CPU propos\u00e9s pour suppression ne sont d\u00e9j\u00e0 plus support\u00e9s dans les derni\u00e8res branches de GCC, tandis que d'autres sont pr\u00e9vus pour \u00eatre supprim\u00e9s dans de futures versions, ce qui simplifiera la modernisation et l'impl\u00e9mentation de nouvelles fonctionnalit\u00e9s dans le compilateur. La suppression du support d'architecture dans GCC n\u00e9cessitera la suppression de son support dans le noyau en cas d'augmentation de la version minimale de GCC support\u00e9e par le noyau (actuellement, une version de GCC 5.1 est requise au minimum pour construire le noyau). <\/p>\n
Architectures, puces et extensions qui sont propos\u00e9es pour suppression du noyau : <\/p>\n
\n
ARMv3 \u2014 le support a d\u00e9j\u00e0 \u00e9t\u00e9 arr\u00eat\u00e9 dans GCC 9.\n
ARMv4 \u2014 utilis\u00e9 pour les processeurs StrongARM et FA526 encore en circulation, les plus r\u00e9cents de ces puces ayant \u00e9t\u00e9 lanc\u00e9s il y a environ 20 ans. Le support ARMv4 a \u00e9t\u00e9 interrompu dans Debian 5.0. Il est propos\u00e9 de d'abord arr\u00eater le support ARMv4 dans GCC, puis dans le noyau dans quelques ann\u00e9es.\n
ARMv4T \u2014 on trouve 6 familles de SoC avec des c\u0153urs ARM720T, ARM920T et ARM922T, qui sont plus r\u00e9pandues que les SoC bas\u00e9s sur ARMv4. Le support ARMv4T a \u00e9t\u00e9 interrompu dans Debian 9.0. Dans le noyau, il est pr\u00e9vu d'arr\u00eater le support ARMv4T, pas avant l'arr\u00eat du support ARMv5.\n
ARMv5 \u2014 utilis\u00e9 sur environ 1\/3 de toutes les plateformes prises en charge dans le noyau, mais la plupart de ces plateformes approchent de la fin de leur cycle de vie. Debian continue de prendre en charge ARMv5, mais en raison de l'absence de FPU et d'op\u00e9rations atomiques, maintenir le support devient de plus en plus difficile et, probablement bient\u00f4t, le port Debian pour ARMv5 sera transf\u00e9r\u00e9 au statut non officiel.\n
Les premi\u00e8res g\u00e9n\u00e9rations de ARMv6 \u2014 utilis\u00e9es dans des SoC tels que ARM1136r0p (NXP i.MX31) et OMAP24xx (Nokia N8xx), mais leur support n\u00e9cessite des hacks pour fonctionner dans des noyaux avec SMP.\n
ARMv6K \u2014 utilis\u00e9 dans ARM1176 (Raspberry Pi 1, AST2500) et ARM1136r1. Le noyau ne pose pas de probl\u00e8mes pour arr\u00eater le support, mais des difficult\u00e9s surviennent dans les distributions en raison d'incompatibilit\u00e9s avec le jeu de types standard armv7-a+vfpv3-d16.\n
ARMv7-M \u2014 utilis\u00e9 dans des microcontr\u00f4leurs bas\u00e9s sur Cortex-M3\/M4\/M7, qui demeurent les derniers chipsets support\u00e9s par le noyau sans unit\u00e9 de gestion de la m\u00e9moire (MMU). Le travail sur des noyaux pour des syst\u00e8mes sans MMU a cess\u00e9 en 2017, apr\u00e8s le passage au d\u00e9veloppement de RTOS, comme Zephyr, pour ces chipsets. Il est propos\u00e9 de retirer le support pour ARMv7-M en 2027, 10 ans apr\u00e8s l'arr\u00eat du d\u00e9veloppement, bien que le support dans GCC soit maintenu.\n
iWMMXt \u2014 le support du CPU ARMv7 PJ4 (MMP2, Berlin) a d\u00e9j\u00e0 \u00e9t\u00e9 interrompu dans le noyau, laissant sans solutions les syst\u00e8mes utilisant cet ensemble d'instructions. Le support d'iWMMXt a d\u00e9j\u00e0 \u00e9t\u00e9 arr\u00eat\u00e9 dans Clang et est propos\u00e9 pour suppression dans GCC.\n
BE32 (big endian ARMv5) \u2014 n'est utilis\u00e9 que dans un seul SoC Intel IXP4xx. Dans les anciennes versions de Debian, seul le mode little-endian \u00e9tait pris en charge, mais des probl\u00e8mes non r\u00e9solus subsistent dans les pilotes. Il est propos\u00e9 de supprimer le support de BE32 de GCC et du noyau, car personne n'a tent\u00e9 de r\u00e9soudre les probl\u00e8mes li\u00e9s aux pilotes depuis plusieurs ann\u00e9es.\n
BE8 (big-endian ARMv7) \u2014 de nombreux pilotes ont des probl\u00e8mes, le test de fonctionnement a \u00e9t\u00e9 interrompu et il n'y a pas d'informations sur les appareils encore en circulation. Le mode BE8 peut \u00eatre int\u00e9ressant pour tester des composants de l'espace utilisateur sur des syst\u00e8mes big-endian, c'est pourquoi il est pr\u00e9vu de maintenir le support de BE8 dans le noyau et GCC pendant au moins quelques ann\u00e9es avant qu'il ne commence \u00e0 poser des probl\u00e8mes. <\/ul>\n
Fonctionnalit\u00e9s du noyau Linux propos\u00e9es pour suppression : <\/p>\n
\n
La structure param_struct, utilis\u00e9e jusqu'aux ATAGS (ARM Tag-Area) \u2014 a \u00e9t\u00e9 d\u00e9clar\u00e9e obsol\u00e8te en 2001, mais est encore utilis\u00e9e dans le code pour les plates-formes RiscPC et Footbridge.\n
Les fichiers bas\u00e9s sur la structure ATAGS (utilis\u00e9e pour transmettre des informations de configuration au Device Tree) \u2014 le noyau maintient 29 fichiers li\u00e9s \u00e0 10 plates-formes SoC utilisant ATAGS.\n
OABI (Old ABI, ancien ABI pour l'architecture ARM) \u2014 presque partout maintenant EABI (Embedded ABI) est utilis\u00e9. OABI est \u00e0 l'origine de nombreuses erreurs, car les d\u00e9veloppeurs de pilotes ont cess\u00e9 de prendre en compte certaines des particularit\u00e9s qui lui sont associ\u00e9es. Le support d'OABI lors de la compilation des composants pour l'espace utilisateur a \u00e9t\u00e9 interrompu dans GCC 4.8, mais un drapeau \u00ab -mabi=apcs-gnu \u00bb a \u00e9t\u00e9 conserv\u00e9 pour le noyau. Il est propos\u00e9 de conserver OABI pour le moment, mais d'en compliquer l'inclusion par inadvertance.\n
Le mode de compatibilit\u00e9 avec OABI (OABI_COMPAT) \u2014 permet d'ex\u00e9cuter des fichiers ex\u00e9cutables compil\u00e9s pour OABI en utilisant un noyau avec EABI. Des probl\u00e8mes particuliers dans les pilotes apparaissent en raison de l'incompatibilit\u00e9 avec ioctl, mais la charge d'entretien de ce mode est nettement inf\u00e9rieure \u00e0 celle de l'entretien des noyaux avec OABI. Pour maintenir le support de StrongARM, il serait raisonnable de conserver le support d'OABI ou d'OABI_COMPAT.\n
NWFPE (No Floating Point Emulator, un \u00e9mulateur pour ex\u00e9cuter des op\u00e9rations \u00e0 virgule flottante) \u2014 des correctifs pour la suppression ont \u00e9t\u00e9 propos\u00e9s il y a 11 ans, mais NWFPE est n\u00e9cessaire au fonctionnement de certains composants de l'espace utilisateur, mis en \u0153uvre pour OABI. Il est recommand\u00e9 de conserver le support de NWFPE tant que le noyau maintient la prise en charge d'OABI ou d'OABI_COMPAT.\n
Highmem (utilis\u00e9 pour g\u00e9rer la m\u00e9moire dans les zones au-del\u00e0 de 1 Go) \u2014 la plupart des syst\u00e8mes ARM peuvent fonctionner sans activer highmem ou peuvent utiliser CONFIG_VMSPLIT_2GB pour acc\u00e9der aux 2 Go de m\u00e9moire physique. Des travaux sont en cours pour organiser l'acc\u00e8s \u00e0 4 Go de RAM sur les syst\u00e8mes avec LPAE (Cortex-A7\/A15), apr\u00e8s quoi le support de Highmem pourrait \u00eatre supprim\u00e9.\n
Sparsemem \u2014 n\u00e9cessaire pour les syst\u00e8mes qui n\u00e9cessitent highmem. <\/ul>\n
Plateformes propos\u00e9es pour suppression : <\/p>\n
\n
RiscPC \u2014 la plus ancienne des plateformes prises en charge par le noyau. Non support\u00e9e dans GCC depuis la branche 9.x en raison de la suppression de la prise en charge d'ARMv3. Le mainteneur continue de tester le fonctionnement du noyau sur cette plateforme, mais il semble n'y avoir plus d'utilisateurs r\u00e9els, donc le support pourrait \u00eatre abandonn\u00e9 si l'int\u00e9r\u00eat du mainteneur diminue.\n
SA1100, Footbridge \u2014 plateformes obsol\u00e8tes, conserv\u00e9es uniquement par nostalgie. Presque tous les fichiers d\u00e9crivant les cartes pour ces plateformes ont \u00e9t\u00e9 supprim\u00e9s dans le noyau 6.3, il ne reste que le support des dispositifs ipaq h3600, assabet, netwinder et ebsa285. La question de la suppression d\u00e9pend des intentions du mainteneur.\n
Gemini, Moxart \u2014 utilisent un CPU bas\u00e9 sur ARMv4. Les puces ont \u00e9t\u00e9 produites il y a plus de 20 ans, mais leur support ne n\u00e9cessite pas d'efforts suppl\u00e9mentaires en maintenance, donc il n'y a pas de raison de les supprimer tant que la plateforme StrongARM est encore support\u00e9e.\n
Les fichiers pour le support de PXA \u2014 la plateforme est \u00e0 l'abandon et est devenue obsol\u00e8te, si l'int\u00e9r\u00eat pour elle ne revient pas, elle devrait \u00eatre supprim\u00e9e d\u00e9but 2025.\n
OMAP1 \u2014 d'une part, reste la seule plateforme bas\u00e9e sur ARMv4T\/ARMv5 sans support Device Tree, et aucune initiative de transition vers Device Tree n'est observ\u00e9e, mais d'autre part, cette plateforme a encore des utilisateurs.\n
Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 \u2014 utilisent un CPU bas\u00e9 sur ARMv4T. Des travaux sont en cours pour transf\u00e9rer les descriptions de cartes vers Device Tree, mais la logique de maintien de leur support reste uniquement tant que la prise en charge de ARMv5 est active.\n
OMAP24xx \u2014 la seule plateforme bas\u00e9e sur ARMv6 ayant des utilisateurs actifs. Le maintien du support d\u00e9pend du maintien du support du CPU arm1136r0.\n
iMX31 \u2014 aucune information sur la pr\u00e9sence d'utilisateurs actifs, mais il n'est pas n\u00e9cessaire de retirer OMAP2 trop t\u00f4t.\n
S3C64xx (Cragganmore) \u2014 la seule plateforme sans support de Device Tree, construite sur ARMv6K. La plateforme continue d'\u00eatre utilis\u00e9e pour tester des codecs audio, donc le retrait est diff\u00e9r\u00e9 jusqu'\u00e0 ce que les tests soient transf\u00e9r\u00e9s sur une autre carte.\n
Orion5x, mv78xx0 \u2014 la question du retrait est pr\u00e9vue \u00e0 \u00eatre examin\u00e9e au d\u00e9but de l'ann\u00e9e prochaine.\n
iMX35, WM8750, AST2500, BCM2835 \u2014 sont bien support\u00e9s et ont des utilisateurs actifs, le retrait n'est pas pr\u00e9vu pour l'instant.\n
stm32f4\/f7\/h7 \u2014 des microcontr\u00f4leurs sans MMU, le support dans le noyau se poursuit et il y a des utilisateurs actifs. La question du retrait est pr\u00e9vue \u00e0 \u00eatre examin\u00e9e en 2026. <\/ul>\n