Il est prévu de mettre fin à la prise en charge des anciens processeurs ARM dans le cœur. Linux

Arnd Bergmann, responsable des paquets du noyau chez SUSE, a publié un message sur la liste de diffusion des développeurs du noyau. Linux Un projet vise à supprimer du noyau basé sur GCC et des outils de compilation afin de prendre en charge les anciens processeurs ARM et leurs ABI, jeux d'instructions et fonctionnalités noyau associés. Ce projet est actuellement au stade de RFC (référence scientifique), ce qui signifie qu'il est ouvert aux commentaires de la communauté. S'il est approuvé, la suppression des anciens processeurs ARM devrait commencer au niveau du noyau. Linux La version 6.12, dont la sortie est prévue en décembre, cible en priorité les architectures ARMv4 (à l'exception d'ARMv4T), iWMMXt, BE32 et OABI.

La cessation de la prise en charge des anciens processeurs ARM dans le noyau coïncide avec la cessation de leur prise en charge dans GCC - certains des processeurs soumis pour suppression ne sont plus pris en charge dans les dernières branches GCC, et certains devraient être supprimés dans les versions futures, ce qui simplifiera la modernisation et la mise en œuvre de nouvelles fonctionnalités dans le compilateur. La suppression du support d'une architecture dans GCC nécessitera la suppression de son support du noyau si la version minimale de GCC prise en charge par le noyau est augmentée (actuellement, au moins la version 5.1 de GCC est requise pour construire le noyau).

Architectures, puces et extensions qu'il est proposé de supprimer du noyau :

• ARMv3 - n'est plus pris en charge dans GCC 9.
• L'architecture ARMv4 est utilisée pour les processeurs StrongARM et FA526, toujours en service, bien que les plus récents de ces puces datent d'une vingtaine d'années. La prise en charge d'ARMv4 a été abandonnée en [année manquante]. Debian 5.0. Il est proposé d'arrêter d'abord la prise en charge d'ARMv4 dans GCC, puis dans quelques années dans le noyau également.
• ARMv4T - Six familles de SoC utilisent les cœurs ARM720T, ARM920T et ARM922T, plus répandus que les SoC basés sur ARMv4. La prise en charge d'ARMv4T a été abandonnée en Debian 9.0. La prise en charge d'ARMv4T sera abandonnée dans le noyau, pas avant l'abandon de la prise en charge d'ARMv5.
• ARMv5 - utilisé sur environ 1/3 de toutes les plateformes prises en charge par le noyau, mais la plupart de ces plateformes approchent de la fin de leur cycle de vie. Debian Il continue de prendre en charge ARMv5, mais en raison de l'absence d'unité de calcul en virgule flottante et d'opérations atomiques, la maintenance de cette prise en charge devient de plus en plus difficile et sera probablement bientôt porté sur une autre architecture. Debian La version pour ARMv5 sera déplacée vers la liste non officielle.
• Générations initiales d'ARMv6 - utilisées dans les SoC tels que ARM1136r0p (NXP i.MX31) et OMAP24xx (Nokia N8xx), mais leur prise en charge nécessite des hacks pour fonctionner dans les cœurs avec SMP.
• ARMv6K - utilisé dans ARM1176 (Raspberry Pi 1, AST2500) et ARM1136r1. Il n'y a aucun obstacle à l'arrêt du support dans le noyau, mais des difficultés surviennent dans les distributions en raison du non-respect de l'ensemble standard armv7-a+vfpv3-d16.
• ARMv7-M - utilisé dans les microcontrôleurs basés sur Cortex-M3/M4/M7, qui restent les dernières puces prises en charge par le cœur sans unité de gestion de mémoire (MMU). Les travaux sur les noyaux sur les systèmes sans MMU ont cessé en 2017, suite au passage au développement RTOS pour des puces similaires telles que le Zephyr. Il est proposé de supprimer le support d'ARMv7-M en 2027, 10 ans après l'arrêt du développement, malgré le support continu dans GCC.
• iWMMXt - le noyau a déjà cessé de prendre en charge les processeurs ARMv7 PJ4 (MMP2, Berlin), après quoi il n'y a plus aucun système utilisé qui utilise cet ensemble d'instructions. iWMMXt est déjà obsolète dans Clang et il est proposé de le supprimer de GCC.
• BE32 (ARMv5 big-endian) - utilisé uniquement dans un seul SoC, l'Intel IXP4xx. Dans les versions plus anciennes. Debian Seul le mode little-endian était pris en charge, mais les pilotes présentent encore des problèmes non résolus. Il est proposé de supprimer la prise en charge de BE32 de GCC et du noyau, car personne n'a traité ces problèmes dans les pilotes depuis plusieurs années.
• BE8 (big-endian ARMv7) - de nombreux pilotes ont des problèmes, les tests se sont arrêtés et il n'y a aucune information sur les périphériques restant en cours d'utilisation. Le mode BE8 peut être intéressant pour tester les composants de l'espace utilisateur sur des systèmes big-endian, c'est pourquoi il est prévu que le support BE8 soit conservé dans le noyau et GCC pendant au moins quelques années avant qu'il ne commence à poser des problèmes.

Fonctionnalités du noyau proposées pour suppression Linux:

• La structure param_struct utilisée avant ATAGS (ARM Tag-Area) a été déclarée obsolète en 2001, mais est toujours utilisée dans le code des plateformes RiscPC et Footbridge.
• Fichiers avec des paramètres basés sur la structure ATAGS (utilisés pour transférer les informations de configuration vers l'arborescence des périphériques) - 29 fichiers restent dans le noyau associé à 10 plates-formes SoC utilisant ATAGS.
• OABI (Old ABI, old ABI pour l'architecture ARM) - EABI (Embedded ABI) est désormais utilisé presque partout. OABI est à l'origine de nombreuses erreurs car les développeurs de pilotes n'ont pas pris en compte certaines des fonctionnalités qui lui sont associées. La prise en charge d'OABI pour les builds en espace utilisateur a été interrompue dans GCC 4.8, mais l'indicateur du noyau "-mabi=apcs-gnu" a été conservé. Il est proposé de conserver l'OABI pour l'instant, mais de rendre son inclusion plus difficile en raison de la surveillance.
• Mode de compatibilité OABI (OABI_COMPAT) - Permet aux exécutables compilés pour OABI d'être exécutés à l'aide d'un noyau avec EABI. Certains problèmes surviennent dans les pilotes en raison d'une incompatibilité avec ioctl, mais la complexité de la maintenance de ce mode est nettement moindre que celle de la maintenance des noyaux avec OABI. Pour maintenir le support StrongARM, il serait raisonnable de conserver le support OABI ou OABI_COMPAT.
• NWFPE (No Floating Point Emulator) - des correctifs à supprimer ont été proposés il y a 11 ans, mais NWFPE est requis pour certains composants de l'espace utilisateur construits pour OABI, il est donc recommandé de maintenir le support NWFPE jusqu'à ce que le support OABI ou OABI_COMPAT reste dans le noyau.
• Highmem (utilisé pour la gestion de la mémoire dans les zones au-delà de 1 Go) - La plupart des systèmes ARM peuvent fonctionner sans highmem activé, ou peuvent utiliser CONFIG_VMSPLIT_2GB pour accéder aux 2 premiers Go de mémoire physique. Des travaux sont en cours pour donner accès à 4 Go de RAM sur les systèmes avec LPAE (Cortex-A7/A15), après quoi le support Highmem pourra être supprimé.
• Sparsemem - requis pour les systèmes nécessitant une mémoire élevée.

Plateformes proposées à la suppression :

• RiscPC est la plus ancienne plateforme supportée par le noyau. Non pris en charge dans GCC depuis 9.x en raison de la suppression du support ARMv3. Le responsable continue de tester le noyau sur cette plate-forme, mais il ne semble plus y avoir de véritables utilisateurs, le support peut donc être interrompu si le responsable se désintéresse.
• SA1100, Passerelle - quais vétustes, conservés uniquement pour des raisons de nostalgie. Presque tous les fichiers décrivant les cartes pour ces plates-formes ont été supprimés dans le noyau 6.3, ne laissant que la prise en charge des périphériques ipaq h3600, assabet, netwinder et ebsa285. La question de la suppression dépend des intentions du responsable.
• Gemini, Moxart - utilisez des processeurs basés sur ARMv4. Les puces ont été commercialisées il y a plus de 20 ans, mais leur prise en charge ne nécessite pas d'efforts de maintenance supplémentaires, il ne sert donc à rien de les supprimer avant de supprimer la plateforme StrongARM.
• Fichiers pour prendre en charge PXA - les plates-formes sont abandonnées et ne sont plus utilisées ; si l'intérêt pour elles ne revient pas, elles seront supprimées début 2025 ;
• OMAP1 - d'une part, reste la seule plate-forme basée sur ARMv4T/ARMv5 sans prise en charge de Device Tree et il n'y a aucun mouvement vers la transition vers Device Tree, mais d'autre part, la plate-forme a toujours des utilisateurs.
• Nspire, AT91RM9200, CLPS711X, EP93xx, iMX1 - utilisent des processeurs basés sur ARMv4T. Des travaux sont en cours pour transférer les descriptions des cartes vers l'arborescence des périphériques, mais il est logique de les prendre en charge uniquement tant que la prise en charge d'ARMv5 est maintenue.
• OMAP24xx est la seule plate-forme basée sur ARMv6 avec des utilisateurs actifs. Le maintien de la prise en charge dépend du maintien de la prise en charge du processeur arm1136r0.
• iMX31 - il n'y a aucune information sur la présence d'utilisateurs actifs, mais cela n'a aucun sens de supprimer avant OMAP2.
• S3C64xx (Cragganmore) est la seule plate-forme sans prise en charge de Device Tree, construite sur ARMv6K. La plate-forme continue d'être utilisée pour tester les codecs audio, la suppression est donc retardée jusqu'à ce que les tests puissent être déplacés vers une autre carte.
• Orion5x, mv78xx0 - la question de la suppression devrait être examinée au début de l'année prochaine.
• iMX35, WM8750, AST2500, BCM2835 - sont bien pris en charge et ont des utilisateurs actifs, il n'est pas encore prévu de les supprimer.
• stm32f4/f7/h7 - microcontrôleurs sans MMU, le support dans le noyau continue et il y a des utilisateurs actifs. La question du retrait devrait être examinée en 2026.

Source: opennet.ru