Mac OS X 10.0 (Cheetah) erfolgreich auf der Nintendo Wii ausgeführt

 (bryankeller.github.io)
10 Punkte von GN⁺ 23 일 전 | 3 Kommentare | Auf WhatsApp teilen
  • Ein Portierungsprojekt wurde abgeschlossen, das Mac OS X 10.0 (Cheetah) nativ auf der PowerPC-basierten Hardware der Wii ausführt
  • Der Darwin/XNU-Kernel wurde an die Wii angepasst, und Bootloader, Device Tree und Treiber wurden direkt geschrieben, wodurch sogar der Start bis in die GUI-Umgebung gelang
  • Durch die Implementierung angepasster IOKit-Treiber mit Unterstützung für SD-Karte, Framebuffer und USB-Eingabegeräte wurde ein vollständig funktionierendes System erreicht
  • Berücksichtigt wurden auch Wii-spezifische Strukturen wie die Behebung von BAT-Konflikten, der Aufbau einer Treiberschicht für das Hollywood-SoC sowie ein RGB→YUV-konvertierender Framebuffer
  • Nach über zehn Jahren an Versuchen wurde auf der Wii ein vollständiger Start und die Bedienung von Mac OS X realisiert und damit der Wert eines scheinbar unmöglichen Projekts bewiesen

Überblick über das Projekt, Mac OS X auf der Wii auszuführen

  • Es wurde ein Portierungsprojekt durchgeführt, um Mac OS X 10.0 (Cheetah) nativ auf der Nintendo Wii auszuführen
  • Für die Wii gab es bereits Portierungen von Betriebssystemen wie Linux, NetBSD und Windows NT; nun kommt Mac OS X hinzu
  • Unter Nutzung der PowerPC-basierten Hardware der Wii wurde der Darwin/XNU-Kernel zum Laufen gebracht, während die nötigen Treiber und der Bootloader direkt selbst geschrieben wurden
  • Das Ergebnis: ein vollständiger Start der Mac-OS-X-GUI-Umgebung auf der Wii, inklusive Unterstützung für Tastatur- und Mauseingaben

Untersuchung der Machbarkeit

  • Die PowerPC-750CL-CPU der Wii ist der Nachfolger des PowerPC 750CXe, der in G3-iMacs und -iBooks verwendet wurde, daher bestehen keine CPU-Kompatibilitätsprobleme
  • Die 88 MB RAM der Wii (MEM1 24 MB + MEM2 64 MB) liegen zwar unter den offiziellen Anforderungen von 128 MB, aber QEMU-Tests bestätigten, dass ein Start auch mit 64 MB möglich ist
  • Unterstützte Hardware umfasst USB Gecko (serielles Debugging), SD-Karte, Interrupt-Controller, Framebuffer-Videoausgabe und USB-Ports
  • Wird der Open-Source-Kern von Mac OS X, Darwin (XNU-Kernel, IOKit), an die Wii angepasst, kann auch die darüberliegende GUI-Schicht funktionieren
  • Die Wii eignet sich für Portierungsexperimente, da sie über Homebrew Channel und BootMii die Ausführung eigenen Codes erlaubt

Portierungsansatz

  • Auswahl zwischen drei Boot-Strategien:
    1. Open-Firmware-Portierung
    2. BootX-Portierung
    3. Direktes Schreiben eines eigenen Bootloaders
  • Es wurde ein neuer Wii-spezifischer Bootloader geschrieben, der Hardware initialisiert, den Kernel lädt, den Device Tree erzeugt und die Kontrolle an den Kernel übergibt
  • Nach dem Start des Kernels wurde der Bootloader-Code überflüssig; die weiteren Arbeiten konzentrierten sich dann auf Kernel-Patches und das Schreiben von Treibern

Schreiben des Bootloaders

  • Auf Basis des Beispielcodes ppcskel wurden Wii-Initialisierung sowie Funktionen für SD-Karte, Framebuffer und USB-Debugging implementiert
  • Der XNU-Kernel im Mach-O-Format wurde in den Speicher geladen und durch Sprung zum angegebenen Entry Point ausgeführt
  • Um die Kernel-Ausführung zu prüfen, wurde ein LED-Blink-Patch eingefügt, um den Eintritt in den Kernel nachzuverfolgen
  • Durch Rückverfolgung des Kernel-Ausführungspfads wurde festgestellt, dass in der Phase device_tree.c eine 300-Ausnahme auftrat → daraus wurde die Notwendigkeit der Übergabe eines Device Tree erkannt

  • Erzeugung und Übergabe des Device Tree

    • Auf Basis der festen Hardware-Struktur der Wii wurde ein hartkodierter Minimalbaum mit (/cpus, /memory) aufgebaut
    • In die Struktur boot_args wurde ein Zeiger auf den Device Tree aufgenommen und an den Kernel übergeben
    • Danach erkannte der Kernel den Baum korrekt und der Bootvorgang lief weiter

Kernel-Patches

  • Die BAT-(Block Address Translation)-Einstellungen von XNU kollidierten mit dem Speicherlayout der Wii, weshalb Änderungen am Kernel-Quellcode nötig waren
  • In einer Mac-OS-X-Cheetah-Gastumgebung (QEMU) wurde ein Build-System für den Kernel eingerichtet
  • Durch BAT-Anpassungen und eine Umleitung der Konsolenausgabe auf USB Gecko wurde Debugging möglich
  • Danach wurden virtueller Speicher, IOKit und das BSD-Subsystem korrekt initialisiert
  • Im Boot-Log erschien die Meldung „Still waiting for root device“ → damit war klar, dass ein SD-Karten-Treiber benötigt wird

Schreiben der Treiber

  • Verständnis der IOKit-Struktur

    • IOKit ist ein C++-basiertes Framework für Kernel-Erweiterungen, das Hardware-Schichten über eine Treiber-Nub-Struktur darstellt
    • Beispiel: IOPCIBridge → IOPCIDevice → SomeEthernetCard → IOEthernetInterface
    • Da die Wii keinen PCI-Bus, sondern eine SoC-Struktur (Hollywood) nutzt, war ein eigener Treiber als Ersatz für IOPCIFamily nötig

  • Hollywood-Treiber

    • Der Treiber NintendoWiiHollywood wurde geschrieben und mit dem „hollywood“-Knoten im Device Tree abgeglichen
    • Er erstellt und registriert das Nub NintendoWiiHollywoodDevice, das die untergeordnete Hardware repräsentiert
    • Dadurch können Treiber für untergeordnete Geräte wie die SD-Karte angebunden werden

  • SD-Karten-Treiber

    • Durch Ableitung von IOBlockStorageDevice wurde der Zugriff auf die Wii-SD-Karte implementiert
    • Die Kommunikation mit der SD-Karte erfolgt über IPC-Befehle (IPC_SDMMC_SIZE, READ, WRITE) von MINI (dem Starlet-Coprozessor)
    • Zur Behebung von Problemen mit gecachtem Speicher wurden nicht gecachte Speicherpuffer verwendet
    • Erfolgreich wurde ein IOMedia-Nub erzeugt, wodurch das Root-Dateisystem erkannt und ein vollständiger Boot möglich wurde
    • Im Boot-Log wurde BSD root: disk0s4 bestätigt

  • Framebuffer-Treiber

    • Durch Ableitung von IOFramebuffer wurde der MEM1-Bereich (0x01700000) der Wii als Framebuffer festgelegt
    • Für den Wechsel zwischen anfänglicher Textkonsole und GUI gibt isConsoleDevice() den Wert true zurück
    • Da die Video-Hardware der Wii das YUV-Format nutzt, wurde ein doppelter Framebuffer zur RGB→YUV-Konvertierung implementiert
    • Über eine Konvertierungsschleife wurde die Farbumwandlung mit 60 Hz durchgeführt → korrekte GUI-Ausgabe in den richtigen Farben gelang

  • USB-Eingabeunterstützung

    • Um den OHCI-USB-1.1-Controller der Wii anzusteuern, wurde der Einsatz von AppleUSBOHCI versucht
    • Problem 1: fehlender IOUSBFamily-Quellcode, daher war Debugging zunächst unmöglich
    • Problem 2: Abhängigkeit von IOPCIDevice, daher wurde für die Wii ein Platzhalter NintendoWiiHollywoodPCIDevice geschrieben
    • Problem 3: Endianness-Konflikt (die Wii nutzt reversed-little-endian), daher musste das softwareseitige Byte-Swapping entfernt werden
    • Über IRC wurde schließlich der IOUSBFamily-Quellcode für Mac OS X Cheetah beschafft; danach gelangen Anpassung und Build
    • Im Ergebnis funktionierten USB-Tastatur und -Maus, wodurch die Wii als vollständiges Mac-OS-X-System nutzbar wurde

Verbesserungen an Bootloader und Kernel

  • Verbesserungen am Bootloader

    • Suche nach SD-Karten-Partitionen und ein Boot-Menü wurden ergänzt, ebenso die Implementierung des Apple Partition Map (APM)-Parsings
    • Kernel-Erweiterungen (kexts) wurden im Bootloader geladen und im Knoten /chosen/memory-map registriert
    • Dadurch wurde der Start mit einem unveränderten Mac-OS-X-Installations-Image möglich

  • Vereinfachung des Kernels

    • Die Wii-spezifischen Kernel-Anpassungen wurden auf ein Minimum reduziert:
    • Anpassung der BAT-Einstellungen
    • Erkennung von I/O-Adressen auf Basis des „hollywood“-Knotens
    • Behebung der Cache-Konsistenz des Framebuffers
    • Durch die Auslagerung der Treiber aus dem Kernel verbesserten sich Build-Effizienz und Wartbarkeit

Abschluss

  • Ein Projekt, das während der Studienzeit 2013 konzipiert wurde, wurde nach über zehn Jahren vollendet
  • Die Herausforderung war von einem Windows-NT-Port auf die Wii inspiriert
  • Am Ende wurde ein vollständiger Start von Mac OS X 10.0 samt GUI-Bedienung auf der Wii erreicht
  • Hervorgehoben wird die Lehre: Je unmöglicher ein Projekt erscheint, desto lohnender ist es, es anzugehen

Verwandte Beiträge

3 Kommentare

 
ffdd270 23 일 전

Ein köstlicher Beitrag und ein großartiger Autor dazu….
 
jjpark78 23 일 전

Von Verrückten unter den Verrückten sind es wohl die westlichen Nerds..
 
GN⁺ 23 일 전
Hacker-News-Kommentare

  • Dieses Projekt war wirklich erstaunliche Arbeit. Auch der Artikel selbst war so fesselnd, dass ich bis zum Ende drangeblieben bin
    Besonders der Teil „WindowServer hat sich beschwert, und um das zu beheben, musste ich den Framebuffer-Treiber selbst schreiben“ ist mir im Gedächtnis geblieben
    Ich war überrascht zu sehen, dass die I/O-Kit-Abstraktionsschicht von MacOS tatsächlich genau das tut, was sie soll. Applaus für die NeXT-Entwickler

    • Ging mir ähnlich. Als jemand, der zum ersten Mal einen Treiber geschrieben hat, war die Lernkurve steil, aber als ich gesehen habe, wie das System zum Leben erwachte, habe ich den Ansatz von IOKit verstanden
      Ich habe keine Erfahrung mit Treiberentwicklung auf anderen Plattformen, daher fällt mir ein Vergleich schwer, aber strukturell wirkte es ziemlich attraktiv
    • Soweit ich weiß, wurde IOKit für OS X komplett neu entwickelt, und zu NeXT-Zeiten gab es mit DriverKit ein anderes Modell
      Früher haben NetBSD-Entwickler PPC Darwin auf einer Mach/IOKit-Kompatibilitätsschicht zum Laufen gebracht und sogar Xquartz gestartet. Dass NetBSD die IOKit-Aufrufe übersetzt hat, finde ich spannend
    • Es gibt auch viele Ähnlichkeiten zum Linux-Stack, daher will ich mir das Linux-on-Wii-Projekt ansehen und vergleichen, wie dort das Framebuffer-Problem gelöst wurde
      Ich kann immer noch kaum glauben, wie viele Betriebssysteme auf der Wii laufen
    • Wahrscheinlich hat die Erfahrung aus der OPENSTEP-Zeit, als man auf verschiedene Architekturen und Betriebssysteme zielte, bei solchen Abstraktionen geholfen
    • Ich stimme der Aussage zu, dass „MacOS erstaunlich gut abstrahiert ist“
      Eigentlich hängt der Unterschied zwischen guter und schlechter Abstraktion davon ab, wie gut sie erklärt wird

  • Die Ingenieursleistung an sich ist schon beeindruckend, aber dass der Autor in der Economy Class entwickelt hat, war wirklich bemerkenswert

    • Ich finde es schon schwer genug, in der Economy Class einen Laptop vernünftig zu benutzen, geschweige denn eine Wii anzuschließen und damit zu debuggen
    • Apple hat früher einmal eine Werbung darüber gemacht, im Flugzeug zu schneiden (YouTube-Link)
    • Die Person auf dem Nebensitz hat wahrscheinlich nur auf ihr Handy geschaut und sich gedacht: „Was ist das denn?“ Ich hätte wohl nicht widerstehen können und nachgefragt
    • Auf den Fotos sah es erst wie ein Bus, dann wie ein Flugzeug aus. So oder so ist es ein Beleg für enorme Konzentration und Hingabe, unterwegs mit einer Wii zu entwickeln
      (Nach erneutem Hinsehen war das erste Foto ein Bus, das zweite ein Flugzeug)
    • Es erstaunt mich, dass man sich unterwegs so sehr in ein derart komplexes Projekt vertiefen kann. Ich habe mir die Bilder noch einmal angesehen; es könnte auch ein Zug oder Bus sein. So oder so ein gewaltiger Flex

  • Als Autor des NetBSD-Ports für Wii und Wii U gratuliere ich von Herzen zu diesem Projekt
    Ich freue mich darauf zu sehen, welche Probleme als Nächstes wie gelöst werden

    • Dein Port war eine große Inspiration. Danke für deine vielen Beiträge in diesem Bereich

  • Früher war ich selbst ein Hardcore-Mac-Fan und habe per Reverse Engineering sogar frühe inoffizielle „iOS-Apps“ gebaut
    Aber dieses Projekt übertrifft das alles. Schon MacOS auf einer Wii laufen zu lassen ist erstaunlich, aber der Artikel selbst ist auch noch so präzise und spannend

    • Danke für die netten Worte :)

  • Heute habe ich zum ersten Mal erfahren, dass die Wii nur 88 MB RAM hat. Zum Glück bestehen Spiele nicht aus Elektronen

    • Eine interessante historische Randnotiz: Im selben Monat, in dem die Wii erschien, kam in Nordamerika auch Windows Vista heraus
      Die Mindestanforderung von Vista lag bei 512 MB, aber die meisten PCs hatten weniger Speicher als das
      Wenn man sieht, dass heute 8 GB verschwinden und 16 GB zum Standard werden, merkt man, wie sehr sich die Welt verändert hat
    • Ich finde es witzig, dass das Einstellungsmenü der Wii aus HTML-Webseiten bestand. Selbst Konsolen von 2006 entkamen dem Griff des Webs nicht

  • Bevor ich mit dem Projekt angefangen habe, wollte ich erst prüfen: „Ist das überhaupt möglich?“ Dann fand ich einen Reddit-Kommentar von 2021, der von „0 % Wahrscheinlichkeit“ sprach
    Das hat mich eher motiviert. Also habe ich angefangen, die Hardware der Wii zu analysieren. Wirklich urkomisch

    • Der Wert solcher Projekte liegt auch darin, solche Aussagen vom Typ „absolut unmöglich“ für immer zu konservieren
      Menschen erklären Dinge, die nur fast unmöglich sind, kurzerhand für völlig ausgeschlossen und halten sich dabei für prinzipientreue Skeptiker
    • Das erinnert mich an einen alten Linux-Witz. Frag nicht „Wie macht man X unter Linux?“, sondern sag „X ist unter Linux unmöglich“, und sofort zeigt dir jemand, wie es geht
    • Ich habe auch ein Projekt gestartet, nachdem ich in der Adafruit-MacroPad-Dokumentation den Satz gesehen hatte, dass man „BLE oder WiFi nicht hinzufügen kann“
      Da dachte ich: „Wirklich?“ und habe den UART-Port umkonfiguriert und ein ESP32 angeschlossen
    • Die Debugging-Szene mit „Alles ist magentafarben“ war auch lustig
    • Viele Kommentatoren im Internet verwechseln auf diese Weise Zynismus mit Scharfsinn
      Das Problem ist, dass es als Konzept keinen Platz für ahnungslosen Zynismus zu geben scheint

  • Beim Debuggen eines Kernel Panic auf der Wii in der Economy Class eines Flugzeugs zu sitzen – dieses Niveau an Konzentration kann ich mir kaum vorstellen
    Die meisten schaffen es im Flugzeug kaum, ein einziges Buch zu lesen

  • Wirklich ein großartiges Projekt. Es erinnert an das frühere goldene Zeitalter der Low-Level-Entwicklung
    Damals war es leicht, VGA zu initialisieren und Pixel zu setzen, und auch Chips wie der 6502 waren gut zugänglich
    Heute sind Systeme aber so komplex geworden, dass die Einstiegshürde hoch ist
    Dazu kommt, dass KI so tut, als würde sie Entwicklung vereinfachen, dabei aber die Zugänglichkeit weiter verringert

  • Ich versuche ebenfalls, Mac OS 9 auf die Wii U zu portieren
    Dieses Projekt hat mich tief beeindruckt, und immer wenn ich denke, „das ist unmöglich“, gibt es mir neuen Mut

    • Wirklich cool. Mac OS 9 ist Closed Source, daher dürfte das eine noch schwierigere Herausforderung sein
    • Dass es keinen XNU- oder Darwin-Sourcecode gibt, ist ein Nachteil, aber mit Tools wie dem geleakten System-7.1-Sourcecode, Ghidra und MCP lässt sich das vielleicht ausgleichen. Viel Glück

  • Der Artikel war großartig, aber die Einbindung des .mov-Videos per <video>-Tag hat ein Problem mit der Browser-Kompatibilität
    In Chrome oder Firefox wird es nicht abgespielt

    • Wenn es in Chrome und Firefox nicht funktioniert, kann man im Grunde sagen, dass es in fast allen Browsern nicht funktioniert
    • Danke! Ist bereits korrigiert