Rapport d’avancement d’Asahi Linux 7.1

• Avec Linux 7.1 comme référence, Asahi Linux avance simultanément sur l’élargissement de la prise en charge des M3, la compatibilité avec la bêta de macOS 27, le décodage vidéo AVD et les changements de m1n1 1.6.0
• Dans la bêta développeur de macOS 27 Golden Gate, l’entrée de démarrage Asahi a disparu de Startup Disk et du sélecteur de démarrage, mais les partitions et les données étaient toujours présentes, et il est possible de la restaurer en définissant le drapeau de démarrage APFS
• Un changement du firmware SMC a modifié la valeur de retour de la gestion de batterie, provoquant dans certaines conditions un arrêt d’urgence ; à partir du noyau downstream 7.0.12, les deux ABI de firmware sont prises en charge
• Sur la famille M3, l’audio, le changement de fréquence CPU, l’ordonnancement big.LITTLE, les capteurs SMC, PCIe, le WiFi, le Bluetooth, NVMe, le clavier et le trackpad fonctionnent sous Linux, mais ce n’est pas encore au stade de la prise en charge par l’Asahi Installer
• AVD a progressé vers le décodage matériel AVC avec un firmware propre et un pilote V4L2 au lieu du firmware Apple, tandis que m1n1 1.6.0 exige Rust pour les builds stage 2, avec un impact important pour les distributions

---

L’entrée de démarrage Asahi disparue dans macOS 27

• L’entrée Asahi visible dans le sélecteur de démarrage, ouvert en maintenant le bouton d’alimentation d’un Mac, ou dans l’app Startup Disk, n’est pas une véritable partition de système d’exploitation
• Comme les outils de démarrage d’Apple ne gèrent que les « installations macOS valides » dans un conteneur APFS, l’Asahi Installer crée un conteneur APFS de 2,5 Go et utilise une configuration macOS minimale dans laquelle m1n1 est placé comme un noyau
• Cette méthode a fonctionné sans changement de macOS 12 à macOS 26, et Apple a aussi corrigé une partie des bugs d’outils qui n’apparaissaient que lors du démarrage d’un binaire brut au lieu d’un véritable noyau XNU
• Après la bêta développeur de macOS 27 Golden Gate, certains utilisateurs ont constaté que l’entrée Asahi disparaissait de Startup Disk et du sélecteur de démarrage
  • La vérification avec diskutil a montré que les partitions liées à Asahi étaient toujours présentes sur le disque et qu’il n’y avait eu aucune perte de données
  • Sur la même machine, en utilisant les outils de démarrage de macOS 26, Asahi pouvait toujours démarrer
• macOS Installer définit des métadonnées APFS avant le redémarrage ; une investigation plus poussée a montré que cette valeur était un drapeau marquant le volume comme amorçable
  • Les outils de démarrage antérieurs à macOS 27 ignoraient ce drapeau
  • En définissant manuellement ce drapeau sur le conteneur APFS d’Asahi, celui-ci réapparaît dans le sélecteur de démarrage de macOS 27
• Pour les nouvelles installations d’Asahi, l’Asahi Installer définit automatiquement ce drapeau
• Un mode d’installation a aussi été ajouté pour corriger les installations existantes
  • Si vous n’avez plus accès à Asahi après l’installation de la bêta développeur de macOS 27, relancez l’installer et utilisez l’option « Fix macOS 27 boot picker compatibility »
• Un programme permettant de corriger le problème depuis Linux a aussi été créé, mais davantage de données de test sont nécessaires avant sa distribution automatique
  • Pour tester, clonez le dépôt asahi-fix27 avant de passer à macOS 27, puis compilez-le et exécutez-le sous Linux
  • Si le volume Asahi peut ensuite être sélectionné comme cible de démarrage dans macOS, c’est que cela a fonctionné
  • Les résultats et les problèmes peuvent être partagés sur les canaux communautaires d’Asahi

Changement du firmware SMC et arrêt d’urgence du pilote de batterie

• macOS 27 inclut des mises à jour de firmware pour tous les périphériques utilisant un firmware global, y compris le SMC
• Le SMC est chargé de la gestion de la batterie, et le pilote Linux power supply communique avec lui pour obtenir l’état de charge, la tension, le temps restant avant décharge et l’état de santé de la batterie
• Ce même pilote définit aussi les seuils de début et d’arrêt de charge via l’interface du firmware SMC afin de prolonger la durée de vie de la batterie
• Le firmware SMC de macOS 27 a fait passer l’une des interfaces de gestion de batterie d’un retour entier 32 bits à un retour sur 1 octet
• À cause de ce changement, le pilote Asahi a interprété certaines conditions comme une défaillance de batterie et a déclenché un arrêt d’urgence pour protéger le système
• Le noyau downstream contient déjà le correctif, et depuis la version 7.0.12, le pilote power supply gère les deux ABI de firmware

Avertissement concernant l’installation des bêtas développeur

• Les deux problèmes apparus avec macOS 27 montrent que les bêtas développeur sont vraiment des bêtas développeur
• Il n’est pas recommandé d’installer une bêta développeur sur une machine de production
• Les deux problèmes rencontrés jusqu’ici ont heureusement été mineurs, mais rien ne garantit que tous les futurs problèmes le seront
• Les mises à jour de firmware global sont en pratique permanentes, et revenir en arrière nécessite une restauration DFU de la machine
• Côté Asahi, des machines sacrifiables dédiées aux tests sont utilisées ; il n’est donc pas jugé nécessaire que les utilisateurs mettent en danger du matériel coûteux et des données importantes

Progrès de la prise en charge de la famille M3

• Les plateformes informatiques ainsi que la conception et la validation de circuits intégrés coûtent cher et prennent beaucoup de temps ; modifier inutilement une conception existante n’est donc pas rationnel
• Le projet Asahi s’est appuyé sur l’hypothèse qu’Apple ne casserait pas continuellement les choses au niveau des plateformes et des circuits intégrés, et cela s’est globalement vérifié, à l’exception des gros blocs de SoC susceptibles de changer à chaque génération, comme le GPU

• Sortie audio

  • L’audio des ordinateurs portables Apple Silicon utilise plusieurs circuits intégrés et blocs de SoC
  • Le standard de fait de l’industrie pour les circuits audio est I2S, un bus basé sur I2C optimisé pour les données audio
  • Le contrôleur I2S d’Apple et l’Apple NCO, source d’horloge stable, n’ont pas changé depuis le M1
  • Apple utilise les mêmes puces d’amplification pour haut-parleurs et casques sur presque toutes les machines Apple Silicon
  • Pour ajouter la prise en charge des haut-parleurs et de la prise casque sur les machines M3, le travail nécessaire a surtout consisté en de petits ajouts Devicetree et en fichiers de configuration asahi-audio et speakersafetyd
  • Les machines M3 prennent en charge une sortie audio de haute qualité dans Asahi Linux

• Fréquence CPU et ordonnancement big.LITTLE

  • Les machines M3 prennent aussi désormais en charge le changement de fréquence CPU et un ordonnancement des tâches big.LITTLE approprié
  • Apple n’a pas changé la façon de modifier la fréquence CPU depuis le M2 de base
  • Les SoC M3, M3 Pro, M3 Max et M3 Ultra fonctionnent avec le pilote cpufreq existant moyennant de simples changements Devicetree
  • Les tâches sont placées plus intelligemment sur les cœurs d’efficacité ou de performance selon les besoins, et les cœurs CPU augmentent ou baissent leur fréquence en fonction de la charge
  • Ce changement apporte à la fois des économies d’énergie et de meilleures performances

• Capteurs et périphériques essentiels

  • Le firmware SMC variant peu d’une machine à l’autre, la prise en charge des capteurs matériels SMC n’a elle aussi nécessité que quelques changements Devicetree
  • Sur les machines de la famille M3, les pilotes PCIe, WiFi, Bluetooth, NVMe, clavier, trackpad et autres blocs SoC essentiels fonctionnent également sous Linux
  • Une grande partie de ce travail a été réalisée par Yureka, qui a travaillé sur m1n1 et Linux avec des machines de la famille M3
  • Il reste encore du travail avant d’activer la prise en charge des machines M3 dans l’Asahi Installer, mais les progrès sont rapides

Décodage vidéo AVD et firmware propre

• La plupart des matériels complexes de la plateforme Apple Silicon utilisent des blobs de firmware complexes
• Beaucoup de firmwares reposent sur RTKit, un framework de type RTOS utilisé par Apple pour fournir une interface largement standardisée entre le noyau et différents blocs matériels
• Certains blocs, comme DCP et AOP, reposent sur RTKit tout en ajoutant une abstraction supplémentaire appelée EPIC
• Il existe aussi des cas utilisant des firmwares tiers qu’Apple ne contrôle pas directement, comme les chipsets WiFi/Bluetooth Broadcom
• Apple Video Decoder, ou AVD, utilise un firmware à l’architecture distincte, qui n’est ni RTKit ni EPIC

• Architecture d’AVD et problèmes de l’approche existante

  • Le matériel AVD est proche d’un ARM Cortex-M3 qui contrôle des unités matérielles à fonction fixe décodant des trames vidéo AVC (H.264), HEVC (H.265), VP9 et, sur les SoC récents, AV1
  • Le Cortex-M3 fournit une interface permettant à XNU de pointer vers les données vidéo et exécute un blob de firmware qui configure le matériel de décodage réel
  • Apple place le firmware AVD et les données de configuration dans le kext AVD
  • Chaque SoC utilisant une variante AVD légèrement différente, cela crée un problème logistique : l’Asahi Installer doit constamment suivre et mettre à jour les changements d’offset des données de firmware dans le kext

• Approche par firmware propre

  • Le firmware AVD chargé par XNU n’est pas vérifié sur le Cortex-M3
  • Lorsqu’il reçoit le signal, il s’exécute à partir du vecteur de reset ; en pratique, il exécute donc le code réellement présent, quel qu’il soit
  • Le rôle du firmware étant essentiellement d’abstraire le matériel de décodage vidéo, il suffit d’installer les gestionnaires d’interruptions de chaque bloc matériel pour pouvoir le programmer directement depuis le pilote Linux
  • Comme il s’agit de code Cortex-M3 standard, le firmware AVD peut être exécuté dans un émulateur
  • QEMU permet l’exécution pas à pas et l’inspection des opérations sur le bus et les registres
  • Jamie, R et Eileen avaient précédemment rétroconçu ensemble les commandes et formats de données nécessaires aux décodeurs AVC et VP9
  • Le kext XNU applique aussi des réglages tunable propres à chaque révision AVD
  • Le rôle exact de ces valeurs n’est pas totalement certain
  • Leur application ressemble à une relecture des écritures MMIO de XNU
  • Il faut suivre chaque révision AVD, chaque ensemble de tunables et les révisions cibles auxquelles ils s’appliquent
  • Comme cela serait difficile à maintenir proprement dans un pilote upstream du noyau Linux, il est aussi préférable de placer cette partie dans le firmware

• Pilote V4L2 AVC

  • Un nouveau contributeur, sofus, a créé un firmware AVD custom de base qui installe les gestionnaires d’interruptions et applique les tunables de chaque variante
  • Sur cette base, il a écrit un pilote V4L2 fonctionnel pour le matériel AVC
  • Le matériel peut décoder des vidéos encodées en AVC 10 bits jusqu’à la 4K
  • Il fonctionne bien avec les logiciels implémentant la V4L2 Request API
  • Garder le firmware simple et sans état, tout en laissant l’espace utilisateur et le noyau analyser les données vidéo et programmer le décodeur, facilitera aussi la prise en charge future d’autres API d’accélération vidéo comme VA-API ou Vulkan Video
  • Il reste encore du travail pour proposer la prise en charge AVD aux utilisateurs
  • AVD prend aussi en charge VP9, HEVC et, sur certains SoC, AV1, mais cela n’est pas encore implémenté
  • Les particularités de certains appareils doivent aussi être testées et intégrées au pilote
  • Une forme distribuable est visée dans un avenir pas trop lointain

Sortie de m1n1 1.6.0

• m1n1 1.6.0 a été tagué, et c’est une version à fort impact pour les distributions
• Cette version exige pour la première fois Rust pour les builds stage 2
• Auparavant, Rust n’était utilisé que lors des builds avec prise en charge du chainloading
• Le stage 1 de m1n1 remplace le noyau XNU dans les outils de démarrage Apple ; il ne sert qu’à monter l’EFI System Partition puis à y chainloader le stage 2 de m1n1
• Le déplacement de l’initialisation GPU dans m1n1 a supprimé la nécessité pour le pilote noyau de manipuler les valeurs en virgule flottante présentes dans les données d’initialisation matérielle d’Apple, et a aussi fortement simplifié le binding Devicetree
• La future version du pilote GPU qui sera soumise à la Linux Kernel Mailing List reposera sur l’hypothèse que m1n1 effectue cette initialisation
• Le code de parsing de l’Apple Device Tree a aussi été porté en Rust, et il est utilisé dans presque toutes les autres parties de m1n1

• Build et cible

  • m1n1 étant en pratique un firmware, il utilise Rust no_std et cible aarch64-none-softfloat
  • Pour éviter d’importer des dépendances inutiles, il est possible de passer BUILDSTD=1 à make afin de compiler core et alloc sans installer toute la toolchain softfloat

• Préparation pour M3, M4 et A18 Pro

  • La version 1.6.0 inclut aussi plusieurs améliorations pour la prise en charge de la famille M3
  • Prise en charge du contrôleur SPMI
  • Prise en charge de l’initialisation PCIe
  • Prise en charge du tunneling direct DebugUSB vers l’UART matériel du SoC via kisd
  • Le tunneling UART DebugUSB peut fournir des fonctionnalités presque équivalentes à Central Scrutiniser
  • Une grande partie de ce travail est aussi une contribution de Yureka
  • Le travail de fond pour la prise en charge de M4 et A18 Pro, c’est-à-dire MacBook Neo, est également en cours
  • Le mode de démarrage non-macOS d’Apple est mieux géré
  • Les nouvelles métadonnées de power domain présentes dans l’Apple Device Tree sont prises en charge

Soutien et contributeurs

• Asahi Linux remercie ses soutiens sur GitHub Sponsors et Open Collective
• Grâce à ces soutiens, le projet peut continuer à travailler sur les fonctionnalités M1 et M2 inachevées, la prise en charge des M3, M4 et A18 Pro, ainsi que l’accompagnement de nouveaux contributeurs

[GN⁺]

Avis de Hacker News

• La formulation « le standard de fait de l’industrie pour les circuits intégrés audio est I²S, un bus basé sur I²C optimisé pour les données audio » n’est pas exacte. I²S n’a rien à voir avec I²C.
  La plupart des puces I²S ont bien une interface I²C, mais c’est parce qu’I²S ne transporte que des données audio brutes et ne prévoit pas de signaux annexes comme le contrôle du volume ou la configuration de l’horloge.
  Mais c’est une interface séparée, et ce pourrait aussi être du SPI à la place d’I²C. En réalité, SPI est plus proche d’I²S que ne l’est I²C.

  • Exact, I²S est beaucoup plus proche de SPI.
    La raison pour laquelle les deux suivent une nomenclature similaire est que Philips Semiconductor (aujourd’hui NXP) les a créés tous les deux.
  • I²S est d’une conception étonnamment simple. Il n’y a pas de handshake de protocole, seulement du PCM brut qui circule.
    J’aime le fait qu’il ait été conçu pour éviter les problèmes de compatibilité même si l’émetteur et le récepteur utilisent des profondeurs de bits d’échantillon différentes dans les deux sens.
    https://web.archive.org/web/20070102004400/http://www.nxp.co...

• C’est vraiment fascinant de voir un petit nombre de personnes motivées résoudre ce genre de problèmes.

  • Beaucoup de problèmes ne sont pas du tout résolus. Par exemple, l’interface de gestion de l’alimentation PSCI d’Apple Silicon reste un mystère.
    D’autres device trees Linux contiennent du code PSCI, mais personne ne sait comment Apple l’a implémenté. Les utilisateurs d’Asahi s’appuient donc depuis près de cinq ans sur un hack pour empêcher la batterie de se vider en permanence, et à ma connaissance il n’y a toujours pas de solution prometteuse.
    C’est le clair-obscur de la rétro-ingénierie. C’est formidable que ces machines disposent désormais de pilotes Vulkan 1.2 natifs, mais il a fallu des années pour en arriver là. Sept ans après le lancement d’Apple Silicon, il reste encore des problèmes non résolus, et la plupart du matériel récent n’est globalement pas pris en charge. Au bout du compte, on revient à la leçon que les utilisateurs de Linux répètent depuis toujours : les pilotes propriétaires, ce n’est pas terrible.

• Le fait que le CM3 ne vérifie pas le firmware chargé par XNU et, lorsqu’il reçoit un signal, commence l’exécution au vecteur de reset quel que soit son contenu réel, est particulièrement inquiétant.
  La prouesse que représente l’écriture d’un firmware personnalisé face à une cible propriétaire et en évolution constante est difficile à surestimer. Mais, au-delà de l’espoir qu’Apple ne casse pas volontairement les systèmes d’exploitation tiers, il ne semble pas improbable qu’ils introduisent une signature matérielle pour les blobs de firmware ou les données fournies au matériel lors de sa programmation à l’exécution. Du point de vue d’Apple, cela pourrait être une préoccupation de sécurité raisonnable. J’espère malgré tout que ce pari réussira.

• Je me demande si cela restera éternellement un « remix » Fedora. Est-ce qu’un jour il y aura une prise en charge upstream permettant de faire tourner une distribution basée sur Debian ?
  La dernière fois que j’ai utilisé une distribution basée sur RPM remonte à près de 20 ans, je crois.

  • Les correctifs sont envoyés upstream, donc les pilotes nécessaires finiront par arriver dans Linux upstream.
    Bien sûr, le fork du noyau est aussi open source, donc rien n’empêche de prendre une racine Debian aarch64 et de compiler soi-même le noyau Asahi, ou de récupérer la build Fedora, pour configurer Debian soi-même sur ces machines. Cela demande juste un peu de travail.
    Si Ubuntu te convient, il existe aussi Ubuntu Asahi : https://ubuntuasahi.org/
    En cherchant, il y a aussi cette page wiki : https://wiki.debian.org/InstallingDebianOn/Apple/M1
  • Ce commentaire m’a fait rire, parce que mes goûts sont à l’opposé. Je préfère les distributions basées sur RPM et j’utilise principalement Fedora presque partout. J’utilise Fedora Asahi Remix aussi sur un Mac Studio M1 Ultra, et seulement parfois Ubuntu et Debian sur quelques instances cloud.
    Je comprends donc l’envie de rester sur une distribution précise que l’on connaît déjà. Il y a moins de travail, et moins de différences subtiles d’architecture à retenir. Cela dit, quand j’ai dû utiliser une nouvelle distribution, par exemple à l’époque où Asahi n’était initialement disponible que pour Arch Linux ARM, je n’ai jamais regretté les petits apprentissages que j’en ai tirés.
  • Arch reste utilisable, et il y a aussi Ubuntu Asahi.
    Le travail upstream avance activement précisément pour que toutes les distributions puissent être portées plus facilement.
    https://ubuntuasahi.org/
  • La Bananas Team travaille à faire fonctionner Debian standard sur Apple Silicon, et il existe aussi une méthode pour l’installer dès maintenant en ajoutant un dépôt non officiel : https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
    Je ne l’ai pas encore installé moi-même.
  • linux-asahi est aussi disponible sur Void Linux.
    https://voidlinux.org/download/#arm%20platforms
    C’est un paquet Linux ordinaire dans la distribution : https://github.com/void-linux/void-packages/tree/master/srcp...

• C’est encourageant de voir que la prise en charge du M3 progresse bien.
  La première mention du début des travaux pour ajouter la prise en charge du M3 remonte à février.
  « Depuis un bon moment, m1n1 dispose d’une prise en charge de base des appareils de la série M3. Ce qui manquait, c’étaient les device trees propres à chaque machine, ainsi que les correctifs des pilotes du noyau Linux nécessaires pour prendre en charge les caractéristiques matérielles et changements propres au M3 par rapport au M2. L’intention a toujours été de concrétiser ce travail une fois le jeu de correctifs existant devenu plus facile à gérer. »
  https://asahilinux.org/2026/02/progress-report-6-19/

• C’est enthousiasmant de voir qu’ils travaillent sur le pilote AVD.

• Sur les Mac M1 et ultérieurs, est-ce que ffmpeg ou VLC utilisent AVD ?

• Asahi peut être une alternative viable, mais avec ce niveau de financement et une équipe aussi réduite, il semble inévitable que le développement avance très lentement.
  Comme le dit l’article, il existe déjà un travail de base en place et des résultats, mais au final de nouveaux Mac sortent chaque année avec de nouvelles puces, quantité de microcontrôleurs et des changements de GPU : impossible de suivre. C’est pour cela que l’équipe Asahi se concentre davantage sur les modèles M1 et M2.
  Pourtant, même aujourd’hui, les deux ont encore des problèmes de gestion de l’énergie au repos et d’implémentation d’Alt-DP, ce qui empêche beaucoup de gens de basculer. Quand ces problèmes seront enfin peaufinés, la valeur des machines aura aussi beaucoup baissé.
  Que si peu de personnes aient accompli autant relève du miracle, mais malgré une large couverture médiatique, l’enthousiasme et la motivation de l’équipe semblent finalement avoir diminué, et on a l’impression que même le M1 Air ne sera jamais terminé.

  • Plutôt que de dire que « le développement ne peut qu’être très lent », la nouvelle équipe dirigeante a annoncé, lorsqu’elle est arrivée, qu’elle donnerait la priorité à l’upstream du travail existant plutôt qu’à l’ajout de la prise en charge du matériel le plus récent.
    L’upstream des changements dans le noyau a pris du temps.
    Ils ont maintenant annoncé en février avoir commencé le travail sur M3, et les progrès semblent bons.
    « En plus de ce qui précède, sur les machines de la série M3, PCIe, WiFi, Bluetooth, NVMe, le clavier, le trackpad ainsi que d’autres pilotes de blocs SoC essentiels fonctionnent aussi sous Linux. La majeure partie de ce travail a été réalisée par Yureka, qui bidouille très activement m1n1 et Linux sur des machines M3 depuis un certain temps. Il reste encore du chemin avant que l’Asahi Installer ne commence à prendre en charge ces machines, mais les progrès sont rapides, alors restez à l’écoute ! »
    Cela ressemble moins à une catastrophe annoncée qu’à des personnes talentueuses qui accomplissent un travail méticuleux.
  • Si, toutes les quelques années, ils peuvent cibler un seul modèle et le faire fonctionner correctement, c’est bien mieux que de n’avoir aucune alternative.
    La prise en charge du M1 est aujourd’hui plutôt utilisable, et au moins une partie du travail semble devoir se répercuter sur les machines futures. Tout n’est pas rose, mais ce n’est pas non plus un projet voué à l’échec.

• Ce serait vraiment bien qu’Apple finance une petite équipe pour publier une partie de la documentation et des pilotes en open source, et aider Asahi.
  Bien sûr, je sais qu’ils ne le feront pas, mais on peut rêver. Pour Apple, ce serait une broutille, et cela renforcerait encore son matériel comme standard de fait chez les ingénieurs de la Silicon Valley.

  • Le framework Hypervisor d’Apple lui-même s’en rapproche pas mal : j’utilise l’app UTM pour faire tourner des builds Fedora et Arch Linux. Je la configure pour utiliser la virtualisation Apple Silicon plutôt que l’émulation, et UTM est un wrapper autour de ce framework.
    C’est tellement excellent que cela m’a fait supprimer Asahi et reformater il y a quelques années.
    https://developer.apple.com/documentation/hypervisor
    https://docs.getutm.app/installation/macos/

• Je me demande dans quelle mesure ils ont récemment utilisé les grands modèles de langage pour Asahi. C’est un outil vraiment puissant pour la rétro-ingénierie ; ont-ils déjà écrit quelque chose à ce sujet ?

  • Leur usage est interdit.
    https://asahilinux.org/docs/project/policies/slop/

• Je me demande à quoi ressemble le processus de développement/CI de ce projet.
  Au final, est-ce qu’ils chargent manuellement les builds sur un matériel précis à chaque fois, ou y a-t-il une étape où un certain niveau d’automatisation est possible ?

  • m1n1 fait pas mal de choses très intéressantes à ce niveau : https://asahilinux.org/docs/sw/tethered-boot/
    Il place une couche très fine entre le matériel réel et le noyau, sans affecter le comportement des entrées/sorties matérielles, tout en permettant de contrôler et d’automatiser à distance le chargement du noyau et le débogage.