Asahi Linux est sur le point de prendre en charge officiellement les Mac équipés des puces M3 d'Apple
Asahi Linux est sur le point de prendre en charge officiellement les Mac équipés des puces M3 d'Apple, et les travaux sur les modèles M4 et M5, plus récents, sont déjà en cours
Asahi Linux est sur le point d’assurer une prise en charge officielle des Mac équipés des puces Apple M3. Après des mois passés à procéder à la rétro-ingénierie du matériel d'Apple, le projet intègre désormais une prise en charge des webcams, des microphones, de l’USB 3.0, du Thunderbolt, ainsi que des écrans, dont la prise en charge est presque équivalente à celle des systèmes M1/M2. Ces progrès permettent ainsi au projet d'être suffisamment abouti pour une sortie officielle. Parallèlement, les développeurs ont déjà commencé à travailler sur les systèmes équipés des puces M4 et M5, en activant la prise en charge du stockage NVMe et la détection des périphériques PCIe, et en corrigeant un bug lié aux processeurs multicœurs. Aucune de ces nouvelles puces n’est toutefois encore prête pour une utilisation quotidienne sous Linux : la plupart des matériels ne fonctionnent pas encore et aucun des deux modèles ne peut être installé via l'Asahi Installer.
Asahi Linux est un projet lancé par Hector Martin visant à porter le noyau Linux et les logiciels associés sur les Mac équipés d'Apple Silicon. Pour ce faire, il procède à une rétro-ingénierie des SoC, pour lesquels il n'existe aucune documentation officielle mise à la disposition du public par Apple.
Selon un communiqué publié le 26 août dernier, Asahi Linux est sur le point de prendre officiellement en charge les Mac équipés des puces M3 d'Apple, et les travaux concernant les modèles plus récents, les M4 et M5, sont déjà en cours.
La prise en charge complète de la webcam est désormais disponible pour tous les Mac de la série M3 équipés d’une caméra intégrée. Le matériel est globalement identique à celui d’avant, mais le M3 Max a nécessité une légère modification du pilote pour fonctionner correctement.
Les microphones intégrés fonctionnent maintenant sur toute la gamme M3. Apple ayant modifié le matériel audio pour cette génération, l'équipe a dû effectuer un travail supplémentaire de rétro-ingénierie avant que Linux puisse l'utiliser correctement. Les ports USB 3.0 et Thunderbolt fonctionnent également sur tous les Mac M3.
La prise en charge des écrans sur les Mac M3 est presque aussi complète que celle des systèmes M1 et M2. Asahi affirme que la prise en charge du contrôleur d’affichage M3 est pratiquement équivalente à celle disponible pour les anciens modèles Apple Silicon. Grâce à tous ces progrès récents, le projet est désormais suffisamment abouti pour une sortie officielle.
Les travaux vont également au-delà de la génération M3. Les développeurs d’Asahi ont activé le stockage NVMe sur les systèmes M4 et les premiers modèles M5 en adaptant Linux et l’environnement de démarrage m1n1 au micrologiciel mis à jour du contrôleur de stockage d’Apple.
La prise en charge du PCIe a été améliorée, ce qui permet désormais à Linux de détecter les périphériques présents sur le bus. L'équipe a également corrigé un bug qui provoquait le plantage de Linux après le démarrage lorsque plusieurs cœurs de processeur étaient activés.
Cependant, les Mac M4 et M5 ne sont pas encore prêts pour une utilisation quotidienne sous Linux. Asahi précise que la plupart des composants matériels ne fonctionnent toujours pas et qu'aucun des deux modèles ne peut être installé via l'Asahi Installer. Néanmoins, la prise en charge du stockage, du PCIe et des processeurs multicœurs constitue une première étape importante.
L'équipe progresse par ailleurs dans le domaine du décodage vidéo accéléré par le matériel. La prise en charge du décodeur vidéo d'Apple permet désormais un décodage fiable des formats H.264, H.265 et VP9 sur les machines compatibles. Les Mac équipés d'un processeur M3 ou plus récent prennent également en charge le décodage AV1.
Enfin, l'équipe s'attaque à l'un des aspects les moins visibles mais particulièrement importants de l'exécution de Linux sur Apple Silicon : la gestion de l'alimentation du processeur. Les processeurs Apple gèrent différemment les états de faible consommation du CPU ; c'est pourquoi Asahi a utilisé jusqu'à présent un pilote Linux spécifique à Apple. Selon les développeurs, cela fonctionne, mais ils ne peuvent pas l'intégrer au code principal de Linux car les mainteneurs d'ARM64 exigent l'utilisation de l'interface standard de coordination des états d'alimentation (Power State Coordination Interface, ou PSCI).
Cette évolution d’Asahi Linux intervient toutefois dans un contexte de tensions internes qui ont récemment marqué le projet et son rapport au développement du noyau Linux. En février 2025, Hector Martin, mainteneur principal d’Asahi Linux, a annoncé sa démission après un conflit autour de l’intégration de Rust dans Linux, reprochant notamment à Linus Torvalds un manque de soutien. Le désaccord portait sur un correctif permettant aux pilotes écrits en Rust d’utiliser l’API DMA du noyau, principalement développé en C. Certains observateurs estiment que ces tensions entre défenseurs du C et du Rust auraient pu être évitées si Linux avait opté pour la conversion du code C du kernel vers du C++ moderne.
L'extrait du communiqué d'Asahi Linux, présenté ci-dessous, fournit des détails supplémentaires :
Encore des progrès sur la M3 !
Les travaux visant à porter Asahi Linux sur les appareils de la série M3 avancent.
Le processeur de signal d'image de la webcam est resté pratiquement inchangé, à l'exception d'un seul message d'initialisation ignoré sur le M3 Max en particulier. chaos_princess a ajouté la prise en charge de ce message au pilote Linux, ce qui a permis d'activer la prise en charge complète de la webcam sur tous les appareils de la série M3 équipés d'une webcam intégrée.
Les microphones intégrés ont également subi quelques modifications. Les appareils de la série M3 intègrent désormais un décimateur « haute fréquence » qui nécessite un nouvel ensemble de coefficients et un message d'initialisation beaucoup plus volumineux. Une fois de plus, chaos_princess a réussi à résoudre ce problème en un clin d'œil, permettant ainsi la prise en charge des microphones sur tous les appareils de la série M3 qui en sont équipés.
ATCPHY — le bloc matériel chargé de négocier les connexions USB 3, DisplayPort et Thunderbolt via les ports USB Type-C — a également subi de légères modifications, nécessitant une nouvelle séquence de paramètres réglables lors de l'initialisation en raison du passage au nœud de fabrication N3 de TSMC.
Même si notre hypothèse selon laquelle Apple éviterait d'apporter des changements architecturaux radicaux juste pour le plaisir s'est globalement vérifiée, nous avons bien sûr constaté quelques changements de ce type…
Tous les appareils de la série M1 à la série M3 de base utilisaient un contrôleur de port USB Texas Instruments spécifique à Apple, appelé CD3217 (ou ACE2). Celui-ci est connecté au bus I2C et négocie avec les périphériques USB lorsqu’ils sont branchés. À partir des modèles M3 Pro/Max, Apple est passé à l’ACE3. L’ACE3 utilise quant à lui le bus SPMI, ce qui a nécessité un peu plus de rétro-ingénierie. Grâce aux efforts conjoints de mildsunrise et chaos_princess, nous avons découvert que l’ACE3 dispose pratiquement du même jeu de registres que le CD3217, mais encapsulé dans une interface SPMI au lieu d’être adressé via I2C. L’interface SPMI et l’ACE3 lui-même fonctionnent désormais sous Asahi Linux, apportant ainsi la prise en charge de l’USB 3.0 et du Thunderbolt à tous les appareils de la série M3.
Un changement majeur auquel nous nous attendions concernait l’ABI du micrologiciel, tant pour le GPU que pour le contrôleur d’affichage. Étant donné que les micrologiciels de l’AGX et du DCP sont associés à une version spécifique de macOS, Apple n’a pas à se soucier de maintenir la stabilité de l’interface d’une version à l’autre. C’est l’une des principales raisons pour lesquelles nous « ciblons » des versions spécifiques de macOS pour chaque génération de matériel. Les machines de la série M3 cibleront l’ABI de macOS 14.8.3, et la prise en charge du DCP est désormais presque équivalente à celle de l’ABI existante de macOS 13.5 que nous utilisons pour les M1 et M2 !
Compte tenu de tous ces progrès, qui viennent s'ajouter aux étapes déjà franchies sur la version M3, nous sommes ravis d'annoncer que nous sommes sur le point de lancer une version officielle !
N'oubliez pas non plus les M4 et M5 !
Non content de contribuer uniquement au développement du M3, Yureka a également travaillé sur le M4 et même sur les premières étapes de mise en service du M5. Outre le problème de WFI sur le M4, ces SoC ont été affectés par un changement majeur dans le firmware du contrôleur NVMe d’Apple, inclus dans le pack de firmware macOS 15.x. Yureka et Sven ont collaboré pour analyser ces modifications et les implémenter à la fois sur m1n1 et sous Linux. Nous disposons donc désormais d’un NVMe fonctionnel sur les M4 et M5 !
Yureka a également réussi à rendre le PCIe fonctionnel au point que les périphériques présents sur le bus puissent être détectés par Linux, et a corrigé un problème qui provoquait le plantage de Linux peu après le démarrage lorsque plusieurs cœurs de processeur étaient activés. Peu d’autres fonctionnalités fonctionnent pour l’instant sur les M4 et M5 ; nous ne sommes donc pas encore tout à fait prêts à les activer dans l’Asahi Installer, mais comme toujours, nous vous en dirons plus en temps voulu.
La vidéo sur bureau est compliquée
La dernière fois, nous avions annoncé une prise en charge préliminaire du décodeur vidéo Apple (Apple Video Decoder, ou AVD). Ce bloc matériel accélère le décodage vidéo H.264 (AVC), H.265 (HEVC) et VP9 sur les puces M1 et M2, ainsi que le décodage AV1 sur les machines équipées d’une puce M3 ou supérieure. Depuis lors, la prise en charge de l’AVD a été encore affinée par sofus, et les formats AVC, HEVC et VP9 fonctionnent désormais de manière globalement fiable sur toutes les machines prises en charge par Asahi Linux ! Nous en sommes désormais au stade où nous envisageons l’intégration au bureau, et c’est là que les choses commencent à se compliquer…
Le matériel AVD est fondamentalement « sans état », ce qui signifie qu’il se contente de prendre une image encodée et de la transformer en tampon vidéo. Le matériel n'effectue aucune analyse du flux binaire, aucun suivi des sessions de décodage, ni aucune autre gestion du pipeline de décodage. Cela s'accorde parfaitement avec l'API V4L2 Stateless, conçue spécialement pour ce type de décodeurs. Bien que cette API ait fait son apparition dans le noyau en amont il y a plus de 10 ans, son adoption dans l'espace utilisateur a été lente en dehors des logiciels spécialisés destinés aux appareils embarqués. GStreamer offre une prise en charge de base de V4L2 Stateless, mais FFmpeg (et tout ce qui l'utilise) ne le prend pas en charge sans correctifs hors arborescence. Les logiciels de bureau, tels que les navigateurs web, se sont historiquement concentrés sur VA-API, NVDEC et VDPAU. Plus récemment, les efforts sur les ordinateurs de bureau ont commencé à s'orienter vers Vulkan Video. Cela a conduit à l'abandon effectif de V4L2 Stateless avant même qu'il ne soit véritablement adopté par les logiciels de bureau.
Tout espoir n'est toutefois pas perdu. La VA-API est désormais quasi universellement présente dans les logiciels destinés aux ordinateurs de bureau, grâce à son adoption par AMD et Intel pour leurs composants matériels d'accélération vidéo. Afin d'éviter que le matériel V4L2 Stateless ne soit incompatible avec ces logiciels, Bootlin a développé une couche de traduction entre la VA-API et le V4L2 Stateless. Malheureusement, ce projet a été abandonné depuis un certain temps et ne peut plus être compilé sans correctifs. Une version plus récente développée par megi fonctionne cependant, et sofus en a créé un fork qu’il a rendu opérationnel pour AVD. Une fois cette couche de traduction installée et une variable d’environnement définie pour la session de connexion, les logiciels prenant en charge VA-API peuvent désormais utiliser AVD pour accélérer le décodage vidéo ! Cette fonctionnalité n’est pas encore intégrée par défaut dans Fedora Asahi Remix et ne fonctionnera pas avec le bac à sable de décodage vidéo de Firefox ; nous espérons toutefois pouvoir proposer une version utilisable très prochainement.
« Think Different »… encore une fois
L'infrastructure de gestion de l'alimentation de la plateforme Apple Silicon est complexe. Les responsabilités sont réparties entre plusieurs blocs matériels, notamment le SMC, le PMGR et le PMP. Bien que la prise en charge de ces blocs soit importante pour la consommation d'énergie, l'un des principaux obstacles à l'amélioration de l'autonomie de la batterie réside dans les cœurs d'application eux-mêmes.
Il existe plusieurs façons de « mettre en veille » un cœur de processeur, et chacune doit être utilisée dans un contexte spécifique. La méthode la plus simple pour mettre un cœur de processeur ARM en veille consiste à utiliser l’instruction Wait For Interrupt (WFI). Celle-ci ordonne au cœur de cesser toute activité jusqu’à ce qu’il soit réveillé par une interruption provenant d’une source d’interruption. Bien que cela permette d’économiser de l’énergie en empêchant le cœur d’exécuter du code, celui-ci reste sous tension et conserve suffisamment d’informations d’état pour reprendre son travail très rapidement. De ce fait, l’instruction WFI n’est généralement utilisée que pour mettre un cœur en veille sur un système en fonctionnement. Les cœurs Apple intègrent un mode WFI « profond », qui met hors tension une plus grande partie du cœur au prix de la perte de son état. Notre pilote cpuidle en aval fonctionne en configurant la WFI dans ce mode, en sauvegardant l’état du cœur, puis en lançant une boucle WFI.
Ce genre d'anomalies liées à la gestion de l'alimentation, propres à certains fabricants, est assez courant. Heureusement pour les mainteneurs du noyau, il existe une méthode standard pour y remédier : l'interface PSCI (Power State Coordination Interface). La PSCI définit une interface standard qui permet à un système d'exploitation d'appeler un ensemble défini de fonctions de gestion de l'alimentation des cœurs de processeur mises en œuvre par le micrologiciel du système, notamment pour les préparer à la mise en veille.
Afin d'éviter la prolifération de solutions de gestion de l'alimentation spécifiques à certains fabricants au sein du noyau Linux, les responsables du code spécifique à l'architecture arm64 ont imposé que tout le matériel en amont utilise PSCI pour la gestion de l'alimentation. De ce fait, nous ne pouvons pas intégrer notre pilote cpuidle spécifique à Apple dans le code en amont. Pourquoi continuons-nous alors à l'utiliser ?
PSCI définit les « canaux » par lesquels les appels au micrologiciel doivent être acheminés depuis le noyau. Les deux conduits actuellement pris en charge par le noyau sont les instructions SMC (Secure Monitor Call) et HVC (Hypervisor Call), qui servent à céder l'exécution à un niveau d'exception supérieur. Le noyau Linux est censé fonctionner au niveau EL2, ce qui signifie que ses appels PSCI doivent céder la place au micrologiciel s'exécutant au niveau EL3. Sauf que les processeurs Apple n'implémentent pas le niveau EL3…
Le noyau fonctionnant déjà en EL2 et aucun micrologiciel n’étant exécuté en EL3 avec lequel communiquer, nous sommes un peu dans l’impasse. Linux ne peut pas émettre d’instructions SMC ou HVC puisqu’il n’y a pas d’EL3 auquel céder l’exécution, ce qui signifie que nous ne pouvons pas utiliser PSCI. Il est essentiel de pouvoir gérer correctement l’alimentation des cœurs du processeur pour garantir l’autonomie et l’efficacité de la batterie ; le statu quo n’est donc tout simplement pas acceptable. Une solution rapide et approximative consisterait à faire en sorte que m1n1 charge le noyau en EL1 et héberge une implémentation de PSCI en EL2. Bien que cela puisse théoriquement fonctionner, cela compromettrait également de nombreuses fonctionnalités architecturales, telles que la virtualisation. Il doit bien y avoir autre chose que nous puissions faire…
Quand on y réfléchit, m1n1 s'apparente presque à notre propre micrologiciel pour Apple Silicon. mBoot (anciennement iBoot) le lance en mode EL2, il effectue sa tâche, puis passe à la charge utile qui lui est associée. m1n1 ne réserve aucune mémoire pour lui-même et ne contient aucun code devant rester résident ; sa charge utile est donc libre de récupérer et de réécrire cette mémoire.
Sur les systèmes Asahi Linux en production, m1n1 charge U-Boot plutôt que le noyau directement. Nous procédons ainsi afin de tirer parti de l’implémentation UEFI d’U-Boot, ce qui permet aux distributions et aux utilisateurs d’utiliser le chargeur d’amorçage UEFI standard de leur choix (GRUB, systemd-boot, etc.). L’UEFI offre également une autre fonctionnalité : les services d’exécution (Runtime Services). À l’instar des interruptions du BIOS d’autrefois, les services d’exécution UEFI permettent au système d’exploitation d’accéder au code provenant du micrologiciel du système.
À la lecture de la norme PSCI telle que publiée par Arm, on constate qu’elle définit délibérément l’API sans faire référence à aucun conduit spécifique, et ne cite que le SMC et le HVC à titre d’exemples. Si l’on adopte une interprétation large de ce point, on pourrait en conclure que la spécification autorise d’autres conduits…
À cette fin, Sven travaille à la mise en œuvre d’un conduit PSCI basé sur le service d’exécution UEFI. La région mémoire de m1n1 étant délimitée comme les autres régions du firmware, cela permettra au noyau de s'y reconnecter pour bénéficier des services PSCI, même s'il s'exécute au même niveau d'exception. Sven a déjà modifié m1n1 pour réserver sa mémoire et y intégrer une implémentation PSCI, et les correctifs du noyau permettant son utilisation sont déjà disponibles sur la liste de diffusion sous forme de RFC.
Source : Annonce d'Asahi Linux
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Partager