Asahi Linux 7.1: Fortschrittsbericht

 (asahilinux.org)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Auf Basis von Linux 7.1 arbeitet Asahi Linux gleichzeitig an erweiterter M3-Unterstützung, Kompatibilität mit der macOS-27-Beta, AVD-Videodekodierung und Änderungen in m1n1 1.6.0
  • In der Entwickler-Beta von macOS 27 Golden Gate verschwand der Asahi-Boot-Eintrag aus Startup Disk und dem Boot Picker; Partitionen und Daten blieben jedoch erhalten und ließen sich durch Setzen eines APFS-Boot-Flags wiederherstellen
  • Eine Änderung der SMC-Firmware veränderte Rückgabewerte der Batterieverwaltung und löste unter bestimmten Bedingungen eine Notabschaltung aus; der Downstream-Kernel verarbeitet seit 7.0.12 beide Firmware-ABIs
  • Auf der M3-Familie funktionieren Audio, CPU-Frequenzwechsel, big.LITTLE-Scheduling, SMC-Sensoren, PCIe, WiFi, Bluetooth, NVMe, Tastatur und Trackpad unter Linux, sie ist aber noch nicht auf dem Stand der Asahi-Installer-Unterstützung
  • AVD machte mit eigener Firmware und einem V4L2-Treiber statt Apple-Firmware Fortschritte in Richtung Hardware-Dekodierung von AVC; m1n1 1.6.0 verlangt für Stage-2-Builds Rust, was erhebliche Auswirkungen auf Distributionen hat

Verschwundener Asahi-Boot-Eintrag in macOS 27

  • Der Asahi-Eintrag, der auf dem Mac im Boot Picker beim langen Drücken des Power-Buttons oder in der App Startup Disk erscheint, ist keine tatsächliche Betriebssystem-Partition
  • Apples Boot-Werkzeuge behandeln nur „gültige macOS-Installationen“ innerhalb eines APFS-Containers; deshalb erstellt der Asahi Installer einen 2,5-GB-APFS-Container und nutzt eine minimale macOS-Konfiguration, in der m1n1 wie ein Kernel abgelegt wird
  • Diese Methode funktionierte von macOS 12 bis macOS 26 unverändert, und Apple hat auch einige Tool-Bugs behoben, die nur beim Booten eines Raw Binary statt eines echten XNU-Kernels auftraten
  • Seit der Entwickler-Beta von macOS 27 Golden Gate erlebten einige Nutzer, dass der Asahi-Eintrag aus Startup Disk und dem Boot Picker verschwand
    • Eine Prüfung mit diskutil zeigte, dass die Asahi-bezogenen Partitionen weiterhin auf dem Datenträger vorhanden waren und kein Datenverlust vorlag
    • Wenn auf derselben Maschine die Boot-Werkzeuge von macOS 26 verwendet wurden, ließ sich Asahi weiterhin booten
  • Der macOS Installer setzt vor dem Neustart APFS-Metadaten; weitere Untersuchungen ergaben, dass dieser Wert ein Flag ist, das ein Volume als bootfähig markiert
    • Boot-Werkzeuge vor macOS 27 ignorierten dieses Flag
    • Wird das Flag im Asahi-APFS-Container manuell gesetzt, erscheint er wieder im Boot Picker von macOS 27
  • Bei neuen Asahi-Installationen setzt der Asahi Installer dieses Flag automatisch
  • Außerdem wurde ein Installationsmodus hinzugefügt, um bestehende Installationen zu reparieren
    • Wer nach der Installation der macOS-27-Entwickler-Beta nicht mehr auf Asahi zugreifen kann, sollte den Installer erneut ausführen und die Option „Fix macOS 27 boot picker compatibility“ verwenden
  • Es wurde auch ein Programm erstellt, das das Problem unter Linux behebt; vor einer automatischen Verteilung werden aber mehr Testdaten benötigt
    • Zum Testen sollte man vor dem Upgrade auf macOS 27 das Repository asahi-fix27 klonen und es unter Linux bauen und ausführen
    • Wenn das Asahi-Volume danach unter macOS als Boot-Ziel auswählbar ist, hat es funktioniert
    • Ergebnisse und Probleme können in den Asahi-Community-Kanälen geteilt werden

SMC-Firmware-Änderung und Notabschaltung des Batterietreibers

  • macOS 27 enthält Firmware-Updates für alle Peripheriegeräte, die Global Firmware verwenden, einschließlich SMC
  • Das SMC ist für die Batterieverwaltung zuständig; der Linux-Power-Supply-Treiber kommuniziert mit dem SMC, um Informationen zu Ladezustand, Spannung, verbleibender Zeit bis zur Entladung und Batteriezustand zu erhalten
  • Derselbe Treiber setzt über die SMC-Firmware-Schnittstelle auch Schwellenwerte für Ladebeginn und Ladestopp, um die Batterielebensdauer zu verlängern
  • Die SMC-Firmware von macOS 27 änderte eine Batterieverwaltungsschnittstelle von einer 32-Bit-Integer-Rückgabe auf eine 1-Byte-Rückgabe
  • Durch diese Änderung interpretierte der Asahi-Treiber unter bestimmten Bedingungen den Zustand als Batteriefehler und startete zum Schutz des Systems eine Notabschaltung
  • Im Downstream-Kernel ist bereits ein Patch enthalten; seit 7.0.12 verarbeitet der Power-Supply-Treiber beide Firmware-ABIs

Warnung zur Installation von Entwickler-Betas

  • Die beiden unter macOS 27 aufgetretenen Probleme zeigen, dass eine Entwickler-Beta tatsächlich eine Entwickler-Beta ist
  • Es wird nicht empfohlen, Entwickler-Betas auf Produktionsmaschinen zu installieren
  • Die beiden bisher aufgetretenen Probleme waren glücklicherweise klein, aber es gibt keine Garantie, dass künftige Probleme ebenfalls klein bleiben
  • Global-Firmware-Updates sind praktisch dauerhaft; zum Zurücksetzen muss die Maschine per DFU restore wiederhergestellt werden
  • Auf Asahi-Seite werden Opfermaschinen zum Testen verwendet, daher sieht man keinen Grund, dass Nutzer teure Hardware und wichtige Daten riskieren müssen

Fortschritte bei der Unterstützung der M3-Familie

  • Computerplattformen sowie IC-Design und -Verifikation sind teuer und zeitaufwendig, daher sind unnötige Änderungen an bestehenden Designs nicht sinnvoll
  • Das Asahi-Projekt setzte darauf, dass Apple keine fortlaufend inkompatiblen Änderungen an Plattform und ICs vornehmen würde; abgesehen von großen SoC-Blöcken wie der GPU, die sich leicht von Generation zu Generation ändern, hat sich diese Annahme weitgehend bestätigt

  • Audioausgabe

    • Audio in Apple-Silicon-Notebooks nutzt mehrere ICs und SoC-Blöcke
    • Der faktische Industriestandard für Audio-ICs ist I2S, ein I2C-basierter Bus, der für Audiodaten optimiert ist
    • Apples I2S-Controller und Apple NCO als stabile Taktquelle haben sich seit M1 nicht geändert
    • Apple verwendet in fast allen Apple-Silicon-Maschinen denselben Lautsprecher- und Headset-Verstärkerchip
    • Um Lautsprecher- und Kopfhörerbuchsen-Unterstützung auf M3-Maschinen hinzuzufügen, waren hauptsächlich kleinere Devicetree-Ergänzungen sowie Konfigurationsdateien für asahi-audio und speakersafetyd nötig
    • M3-Maschinen unterstützen unter Asahi Linux hochwertige Audioausgabe

  • CPU-Frequenz und big.LITTLE-Scheduling

    • M3-Maschinen unterstützen inzwischen auch CPU-Frequenzwechsel und korrektes big.LITTLE-Task-Scheduling
    • Apple hat die Methode für CPU-Frequenzwechsel seit dem Basis-M2 nicht geändert
    • Die SoCs M3, M3 Pro, M3 Max und M3 Ultra funktionieren mit dem bestehenden cpufreq-Treiber allein durch Devicetree-Änderungen
    • Aufgaben werden je nach Anforderungen intelligenter auf Effizienz- oder Performance-Kerne verteilt, und CPU-Kerne takten je nach Last hoch und herunter
    • Diese Änderung bringt sowohl Energieeinsparungen als auch Leistungsverbesserungen

  • Sensoren und Kernkomponenten

    • Da sich die SMC-Firmware zwischen Maschinen nicht stark unterscheidet, waren auch für die Unterstützung von SMC-Hardwaresensoren nur einige Devicetree-Änderungen nötig
    • Auf Maschinen der M3-Familie funktionieren auch PCIe, WiFi, Bluetooth, NVMe, Tastatur, Trackpad und weitere zentrale SoC-Blocktreiber unter Linux
    • Ein großer Teil dieser Arbeit wurde von Yureka geleistet, die an m1n1 und Linux auf Maschinen der M3-Familie gearbeitet hat
    • Um die Asahi-Installer-Unterstützung für M3-Maschinen zu aktivieren, ist noch mehr Arbeit nötig, aber das Tempo ist hoch

AVD-Videodekodierung und eigene Firmware

  • Der Großteil der komplexen Hardware der Apple-Silicon-Plattform nutzt komplexe Firmware-Blobs
  • Viele Firmware-Komponenten basieren auf RTKit, einem RTOS-ähnlichen Framework, das Apple verwendet, um eine weitgehend standardisierte Schnittstelle zwischen Kernel und verschiedenen Hardwareblöcken bereitzustellen
  • Einige Blöcke wie DCP und AOP basieren auf RTKit und legen darüber eine zusätzliche Abstraktion namens EPIC
  • In manchen Fällen wird auch Drittanbieter-Firmware verwendet, die Apple nicht direkt kontrolliert, etwa bei Broadcom-WiFi/Bluetooth-Chipsätzen
  • Der Apple Video Decoder, kurz AVD, verwendet eine Firmware mit eigener Struktur, die weder RTKit noch EPIC ist

  • AVD-Struktur und Probleme des bisherigen Ansatzes

    • Die AVD-Hardware ähnelt einem ARM Cortex-M3, der Fixed-Function-Hardwareeinheiten steuert, die Videoframes in AVC (H.264), HEVC (H.265), VP9 und auf neueren SoCs AV1 dekodieren
    • Der Cortex-M3 führt einen Firmware-Blob aus, der eine Schnittstelle bereitstellt, über die XNU auf Videodaten verweist, und der die eigentliche Decoder-Hardware konfiguriert
    • Apple legt AVD-Firmware und Konfigurationsdaten gemeinsam innerhalb der AVD-kext ab
    • Da jeder SoC eine leicht andere AVD-Variante verwendet, entsteht das logistische Problem, dass der Asahi Installer Änderungen der Firmware-Daten-Offsets innerhalb der kext fortlaufend verfolgen und aktualisieren muss

  • Ansatz mit eigener Firmware

    • Die von XNU geladene AVD-Firmware wird auf dem Cortex-M3 nicht verifiziert
    • Sobald ein Signal empfangen wird, wird ab dem Reset Vector ausgeführt, sodass tatsächlich jeder darin enthaltene Code läuft
    • Die Aufgabe der Firmware besteht im Wesentlichen darin, die Video-Decoder-Hardware zu abstrahieren; installiert man nur die Interrupt-Handler für die einzelnen Hardwareblöcke, kann der Linux-Treiber sie direkt programmieren
    • Da es sich um standardmäßigen Cortex-M3-Code handelt, kann AVD-Firmware in einem Emulator ausgeführt werden
    • QEMU unterstützt Single-Step-Ausführung sowie die Untersuchung von Bus- und Registeroperationen
    • Jamie, R und Eileen haben in früherer Zusammenarbeit die für AVC- und VP9-Decoder nötigen Befehle und Datenformate reverse-engineert
    • Die XNU-kext wendet außerdem pro AVD-Revision eigene Tunables an
    • Es ist nicht vollständig sicher, was diese Werte genau bewirken
    • Die Anwendung entspricht in etwa dem Wiedergeben von MMIO-Writes aus XNU
    • Jede AVD-Revision, jede Tunable-Sammlung und die jeweiligen Zielrevisionen müssen nachverfolgt werden
    • Da dies in einem Upstream-Linux-Kernel-Treiber nur schwer zufriedenstellend zu pflegen wäre, ist es sinnvoll, auch diesen Teil in die Firmware zu legen

  • V4L2-AVC-Treiber

    • Der neue Contributor sofus hat eine grundlegende Custom-AVD-Firmware erstellt, die Interrupt-Handler installiert und die Tunables der einzelnen Varianten anwendet
    • Darauf aufbauend schrieb er einen funktionierenden V4L2-Treiber für die AVC-Hardware
    • Die Hardware kann 10-Bit-AVC-kodiertes Video bis 4K dekodieren
    • Sie funktioniert gut mit Software, die die V4L2 Request API implementiert
    • Wenn die Firmware einfach und zustandslos bleibt und Userspace sowie Kernel das Parsen der Videodaten und die Programmierung des Decoders übernehmen, wird künftig auch die Unterstützung anderer Video-Beschleunigungs-APIs wie VA-API oder Vulkan Video einfacher
    • Bis AVD-Unterstützung bei Nutzern ankommt, bleibt noch Arbeit
    • AVD unterstützt auch VP9, HEVC und auf einigen SoCs AV1, diese sind aber noch nicht implementiert
    • Auch Quirks einiger Geräte müssen getestet und im Treiber berücksichtigt werden
    • Eine auslieferbare Form wird für eine nicht allzu ferne Zukunft angestrebt

m1n1 1.6.0 veröffentlicht

  • m1n1 1.6.0 wurde getaggt und ist aus Sicht von Distributionen ein Release mit großen Auswirkungen
  • Diese Version verlangt erstmals Rust für Stage-2-Builds
  • Bisher wurde Rust nur verwendet, wenn Chainloading-Unterstützung mitgebaut wurde
  • Stage-1-m1n1 ersetzt für Apples Boot-Werkzeuge den XNU-Kernel und dient nur dazu, die EFI System Partition zu mounten und daraus Stage-2-m1n1 per Chainload zu starten
  • Durch die Verlagerung der GPU-Initialisierung nach m1n1 muss der Kernel-Treiber keine Gleitkommawerte aus Apples Hardware-Initialisierungsdaten mehr verarbeiten, und auch das Devicetree-Binding wird stark vereinfacht
  • Die künftig an die Linux Kernel Mailing List eingereichte Version des GPU-Treibers wird darauf aufbauen, dass m1n1 diese Initialisierung übernimmt
  • Auch der Parser für den Apple Device Tree wurde nach Rust portiert und wird in fast allen anderen Teilen von m1n1 verwendet

  • Build und Ziele

    • Da m1n1 faktisch Firmware ist, nutzt es no_std-Rust und zielt auf aarch64-none-softfloat
    • Um keine unnötigen Abhängigkeiten hereinzuziehen, kann man make BUILDSTD=1 übergeben, um core und alloc ohne Installation der vollständigen softfloat-Toolchain zu bauen

  • Vorbereitung für M3, M4 und A18 Pro

    • 1.6.0 enthält außerdem mehrere Verbesserungen zur Unterstützung der M3-Familie
    • Unterstützung für SPMI-Controller
    • Unterstützung für PCIe-Initialisierung
    • Unterstützung für direktes DebugUSB-Tunneling des SoC-Hardware-UART über kisd
    • DebugUSB-UART-Tunneling kann nahezu dieselbe Funktionalität wie Central Scrutiniser bieten
    • Auch ein erheblicher Teil dieser Arbeit stammt von Yureka
    • Grundlagenarbeit für die Unterstützung von M4 und A18 Pro, also MacBook Neo, läuft ebenfalls
    • Apples non-macOS boot mode wird besser behandelt
    • Neue Power-Domain-Metadaten im Apple Device Tree werden unterstützt

Sponsoring und Beitragende

  • Asahi Linux bedankt sich bei den Sponsoren auf GitHub Sponsors und Open Collective
  • Dank der Unterstützung kann die Arbeit an unfertigen M1-/M2-Funktionen, M3-/M4-/A18-Pro-Unterstützung und der Unterstützung neuer Beitragender fortgesetzt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Meinungen

  • Die Formulierung „der De-facto-Branchenstandard für Audio-ICs ist I²S, ein auf I²C basierender Bus, der für Audiodaten optimiert ist“ ist nicht korrekt. I²S hat nichts mit I²C zu tun
    Zwar haben die meisten I²S-Chips eine I²C-Schnittstelle, aber I²S transportiert nur rohe Audiodaten und hat keine zusätzlichen Signale wie Lautstärkeregelung oder Clock-Konfiguration
    Das ist jedoch eine separate Schnittstelle und könnte statt I²C auch SPI sein. Tatsächlich ist SPI näher an I²S als I²C

    • Stimmt, I²S ist SPI deutlich näher
      Der Grund, warum beide einem ähnlichen Namensschema folgen, ist, dass Philips Semiconductor (heute NXP) beide entwickelt hat
    • I²S ist ein erstaunlich schlichtes Design. Es gibt kein Protokoll-Handshake, es fließt einfach nur rohes PCM
      Mir gefällt, dass es so ausgelegt ist, dass es keine Kompatibilitätsprobleme gibt, selbst wenn Sender und Empfänger bidirektional unterschiedliche Sample-Bittiefen verwenden
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • Es ist wirklich erstaunlich, dass eine kleine Gruppe motivierter Leute solche Probleme löst

    • Viele Probleme sind überhaupt nicht gelöst. Zum Beispiel ist Apples PSCI-Power-Management-Schnittstelle für Apple Silicon immer noch ein Rätsel
      In anderen Linux-Device-Trees gibt es PSCI-Code, aber niemand weiß, wie Apple das implementiert hat. Deshalb verlassen sich Asahi-Nutzer seit fast fünf Jahren auf Hacks, die verhindern, dass der Akku ständig leerläuft, und soweit ich weiß, gibt es noch keine vielversprechende Lösung
      Das sind Licht und Schatten des Reverse Engineerings. Es ist großartig, dass diese Geräte native Vulkan-1.2-Treiber bekommen haben, aber bis dahin hat es Jahre gedauert. Auch sieben Jahre nach der Einführung von Apple Silicon gibt es noch ungelöste Probleme, und die meiste aktuelle Hardware wird insgesamt nicht unterstützt. Am Ende landet man wieder bei der Lektion, die Linux-Nutzer immer wieder betonen: proprietäre Treiber sind nicht besonders gut

  • Besonders beunruhigend finde ich die Stelle, dass der CM3 die von XNU geladene Firmware nicht verifiziert und bei einem Signal einfach ab dem Reset-Vektor mit der Ausführung beginnt, egal was der tatsächliche Inhalt ist
    Die Leistung, Custom-Firmware für ein proprietäres und sich ständig veränderndes Ziel zu schreiben, ist kaum hoch genug zu würdigen. Unabhängig davon, dass man hoffen muss, dass Apple Drittanbieter-Betriebssysteme nicht absichtlich weiter kaputtmacht, scheint es aber nicht unwahrscheinlich, dass Apple Hardware-Signaturen für Firmware-Blobs oder für Daten einführt, die zur Laufzeit an die Hardware-Programmierung übergeben werden. Aus Apples Sicht könnte das ein nachvollziehbares Sicherheitsanliegen sein. Trotzdem hoffe ich, dass diese Wette aufgeht

  • Ich frage mich, ob das für immer nur ein Fedora-„Remix“ bleiben wird. Wird es irgendwann Upstream-Support geben, sodass man eine Debian-basierte Distribution nutzen kann?
    Ich glaube, das letzte Mal, dass ich eine RPM-basierte Distribution verwendet habe, ist fast 20 Jahre her

    • Die Patches werden upstream eingereicht, also werden die nötigen Treiber letztlich in Upstream-Linux landen
      Natürlich ist auch der Kernel-Fork Open Source, daher hindert einen nichts daran, ein Debian-aarch64-Root zu nehmen und den Asahi-Kernel selbst zu bauen oder den Fedora-Build zu verwenden, um Debian auf diesen Geräten selbst einzurichten. Es ist nur etwas Handarbeit
      Falls Ubuntu in Ordnung ist, gibt es auch Ubuntu Asahi: https://ubuntuasahi.org/
      Beim Suchen habe ich außerdem diese Wiki-Seite gefunden: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • Ich musste über diesen Kommentar lachen, weil mein Geschmack genau entgegengesetzt ist. Ich bevorzuge RPM-basierte Distributionen und nutze fast überall hauptsächlich Fedora. Auf meinem M1 Ultra Mac Studio verwende ich ebenfalls Fedora Asahi Remix, und nur auf einigen Cloud-Instanzen gelegentlich Ubuntu und Debian
      Daher verstehe ich den Wunsch, bei einer bestimmten Distribution zu bleiben, mit der man bereits vertraut ist. Es macht weniger Arbeit, und man muss sich weniger subtile Unterschiede in der Struktur merken. Trotzdem habe ich die kleinen Lerneffekte nie bereut, wenn ich zwangsläufig eine neue Distribution verwenden musste, etwa als Asahi anfangs nur für Arch Linux ARM verfügbar war
    • Arch kann man weiterhin verwenden, und es gibt auch Ubuntu Asahi
      Genau aus diesem Grund wird intensiv an Upstream-Arbeit gearbeitet, damit alle Distributionen leichter portiert werden können
      https://ubuntuasahi.org/
    • Das Bananas-Team arbeitet daran, Standard-Debian auf Apple Silicon zum Laufen zu bringen, und es gibt auch eine Möglichkeit, es schon jetzt durch Hinzufügen eines inoffiziellen Repositories zu installieren: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      Ich habe es selbst noch nicht installiert
    • linux-asahi ist auch für Void Linux verfügbar
      https://voidlinux.org/download/#arm%20platforms
      Es ist ein normales Linux-Paket innerhalb der Distribution: https://github.com/void-linux/void-packages/tree/master/srcp...

  • Schön zu sehen, dass die M3-Unterstützung gut vorankommt
    Im Februar wurde erstmals erwähnt, dass die Arbeit an der M3-Unterstützung beginnt
    „Schon seit geraumer Zeit hatte m1n1 grundlegende Unterstützung für Geräte der M3-Serie. Was fehlte, waren die Device-Trees für die einzelnen Geräte sowie Linux-Kernel-Treiber-Patches zur Unterstützung der M3-spezifischen Hardwareeigenschaften und Änderungen gegenüber M2. Es war immer geplant, diese Arbeit zu konkretisieren, sobald das bestehende Patchset besser wartbar geworden ist“
    https://asahilinux.org/2026/02/progress-report-6-19/

  • Ich freue mich, dass am AVD-Treiber gearbeitet wird

  • Nutzt man auf Macs ab M1 mit ffmpeg oder VLC AVD?

  • Asahi kann eine praktikable Alternative sein, aber bei dieser Finanzierung und der kleinen Teamgröße scheint die Entwicklung zwangsläufig zu langsam voranzukommen.
    Wie im Artikel erwähnt, gibt es bereits gelegte Grundlagenarbeit und auch Ergebnisse daraus, aber letztlich kommen jedes Jahr neue Macs mit neuen Chips, zahllosen Mikrocontrollern und GPU-Änderungen heraus – da mitzuhalten ist unmöglich. Deshalb konzentriert sich das Asahi-Team auch stärker auf M1- und M2-Modelle.
    Trotzdem gibt es bei beiden bis heute offene Probleme mit dem Idle-Power-Management und der Alt-DP-Implementierung, weshalb viele nicht umsteigen können. Bis diese Probleme ausgereift sind, dürfte der Gerätewert bereits deutlich gefallen sein.
    Dass so wenige Leute so viel geschafft haben, ist ein Wunder, aber trotz der breiten Medienberichterstattung scheinen Leidenschaft und Motivation des Teams letztlich nachgelassen zu haben, und es wirkt, als würde nicht einmal der M1 Air fertig werden.

    • Statt „die Entwicklung muss zwangsläufig zu langsam sein“ trifft es eher zu, dass das neue Führungsteam angekündigt hat, bestehende Arbeit upstream zu bringen, statt zuerst Unterstützung für neueste Hardware hinzuzufügen.
      Es hat Zeit gekostet, die Änderungen in den Kernel upstream zu bringen.
      Jetzt wurde angekündigt, dass die Arbeit am M3 im Februar begonnen hat, und der Fortschritt sieht gut aus.
      „Zusätzlich zu dem oben Genannten funktionieren auf Geräten der M3-Serie auch PCIe, WiFi, Bluetooth, NVMe, Tastatur, Trackpad sowie weitere zentrale SoC-Block-Treiber unter Linux. Den Großteil dieser Arbeit hat Yureka übernommen; sie hackt seit einiger Zeit sehr aktiv sowohl an m1n1 als auch an Linux auf Geräten der M3-Serie. Bis diese Geräte im Asahi Installer unterstützt werden, ist noch einiges zu tun, aber der Fortschritt ist schnell – bleibt dran!“
      Das wirkt weniger wie Untergang, sondern eher wie talentierte Leute, die sorgfältige Arbeit leisten.
    • Wenn man es schafft, alle paar Jahre nur ein Modell anzupeilen und es wirklich gut zum Laufen zu bringen, ist das viel besser als gar keine Alternative.
      M1-Unterstützung ist heutzutage ziemlich brauchbar, und zumindest ein Teil der Arbeit dürfte auch auf künftige Geräte übertragbar sein. Es ist nicht alles rosig, aber es ist auch kein Projekt, dessen Scheitern feststeht.

  • Es wäre wirklich schön, wenn Apple ein kleines Team finanzieren, Dokumentation und einige Treiber als Open Source veröffentlichen und Asahi unterstützen würde.
    Natürlich weiß ich, dass sie das nicht tun werden, aber man darf ja träumen. Für Apple wäre das Kleingeld, und es würde die eigene Hardware noch stärker als De-facto-Standard für Ingenieure im Silicon Valley verankern.

  • Ich frage mich, wie stark Asahi in letzter Zeit Large Language Models genutzt hat. Für Reverse Engineering sind sie wirklich mächtige Werkzeuge – haben sie dazu jemals etwas geschrieben?

  • Mich würde interessieren, wie der Entwicklungs-/CI-Prozess dieses Projekts aussieht.
    Lädt man am Ende jedes Mal Builds manuell auf bestimmte Hardware, oder gibt es Phasen, in denen ein gewisses Maß an Automatisierung möglich ist?

    • m1n1 macht hier ziemlich viele interessante Dinge: https://asahilinux.org/docs/sw/tethered-boot/
      Es legt eine sehr dünne Schicht zwischen reale Hardware und Kernel, ohne das I/O-Verhalten der Hardware zu beeinflussen, und ermöglicht dadurch Remote-Steuerung und Automatisierung von Kernel-Loading und Debugging.