Mac OS X 10.0 (Cheetah) exécuté avec succès sur une Nintendo Wii

 (bryankeller.github.io)
10 points par GN⁺ 2026-04-09 | 3 commentaires | Partager sur WhatsApp
  • Un projet de portage a abouti à l’exécution native de Mac OS X 10.0 (Cheetah) sur le matériel PowerPC de la Wii
  • Le noyau Darwin/XNU a été adapté à la Wii, avec écriture manuelle du bootloader, de l’arbre de périphériques et des pilotes, jusqu’au démarrage réussi de l’environnement graphique
  • Des pilotes IOKit sur mesure prenant en charge la carte SD, le framebuffer et les périphériques d’entrée USB ont permis d’obtenir un système entièrement fonctionnel
  • Le projet prend en compte les spécificités de la Wii, comme la correction des conflits de configuration BAT, la mise en place d’une couche de pilotes pour le SoC Hollywood et un framebuffer avec conversion RGB→YUV
  • Après plus de dix ans de tentatives, il a permis un démarrage complet et une utilisation effective de Mac OS X sur Wii, démontrant l’intérêt de relever même les projets qui paraissent impossibles

Aperçu du projet d’exécution de Mac OS X sur Wii

  • Un projet de portage a été mené pour exécuter nativement Mac OS X 10.0 (Cheetah) sur une Nintendo Wii
  • La Wii avait déjà connu des portages de Linux, NetBSD et Windows NT ; Mac OS X s’ajoute désormais à cette liste
  • En exploitant le matériel PowerPC de la Wii, le projet fait tourner le noyau Darwin/XNU et s’accompagne de l’écriture des pilotes et du bootloader nécessaires
  • Résultat : démarrage complet de l’interface graphique de Mac OS X sur Wii, avec prise en charge du clavier et de la souris

Étude de faisabilité

  • Le CPU PowerPC 750CL de la Wii succède au PowerPC 750CXe utilisé dans les G3 iMac/iBook, sans problème de compatibilité processeur
  • Les 88 Mo de RAM de la Wii (MEM1 24 Mo + MEM2 64 Mo) sont inférieurs à la configuration requise officielle (128 Mo), mais des tests sous QEMU ont confirmé qu’un démarrage restait possible avec 64 Mo
  • Le matériel pris en charge comprend USB Gecko (débogage série), la carte SD, le contrôleur d’interruptions, la sortie vidéo framebuffer et les ports USB
  • En adaptant à la Wii le cœur open source de Mac OS X, Darwin (noyau XNU, IOKit), les couches graphiques supérieures peuvent elles aussi fonctionner
  • La Wii permet l’exécution de code personnalisé via Homebrew Channel et BootMii, ce qui en fait une bonne plateforme pour ce type d’expérimentation

Approche de portage

  • Trois stratégies de démarrage étaient envisageables :
    1. Portage d’Open Firmware
    2. Portage de BootX
    3. Écriture directe d’un bootloader personnalisé
  • Un nouveau bootloader dédié à la Wii a été développé pour assurer l’initialisation matérielle, le chargement du noyau, la création de l’arbre de périphériques et le transfert du contrôle au noyau
  • Une fois le noyau lancé, le code du bootloader n’était plus nécessaire, et la suite du travail s’est concentrée sur les patches noyau et l’écriture de pilotes

Écriture du bootloader

  • Les fonctions d’initialisation de la Wii ainsi que la prise en charge de la carte SD, du framebuffer et du débogage USB ont été implémentées à partir de l’exemple ppcskel
  • Le noyau XNU au format Mach-O est chargé en mémoire puis exécuté via le point d’entrée spécifié
  • Pour vérifier l’exécution effective du noyau, un patch de clignotement de LED a été inséré afin de suivre l’étape d’entrée dans le noyau
  • En retraçant le chemin d’exécution du noyau, une exception 300 a été identifiée à l’étape device_tree.c → d’où la nécessité de transmettre un arbre de périphériques

  • Création et transmission de l’arbre de périphériques

    • Un arbre minimal codé en dur a été construit à partir de la structure matérielle fixe de la Wii (/cpus, /memory)
    • Un pointeur vers l’arbre de périphériques a été inclus dans la structure boot_args puis transmis au noyau
    • Le noyau a ensuite reconnu correctement l’arbre et le démarrage a pu se poursuivre

Patches noyau

  • La configuration BAT (Block Address Translation) de XNU entrait en conflit avec la carte mémoire de la Wii, nécessitant une modification du code source du noyau
  • L’environnement de build du noyau a été mis en place dans une machine invitée Mac OS X Cheetah (QEMU)
  • La correction du BAT et l’ajout d’une redirection de la sortie console vers USB Gecko ont permis le débogage
  • Par la suite, la mémoire virtuelle, IOKit et le sous-système BSD se sont initialisés correctement
  • Le message de démarrage « Still waiting for root device » est alors apparu → confirmant la nécessité d’un pilote de carte SD

Écriture des pilotes

  • Compréhension de l’architecture IOKit

    • IOKit est un framework d’extensions noyau en C++, qui représente les couches matérielles via une structure driver-nub
    • Exemple : IOPCIBridge → IOPCIDevice → SomeEthernetCard → IOEthernetInterface
    • La Wii n’utilise pas un bus PCI mais une architecture SoC (Hollywood), d’où la nécessité d’un pilote personnalisé remplaçant IOPCIFamily

  • Pilote Hollywood

    • Un pilote NintendoWiiHollywood a été écrit pour correspondre au nœud « hollywood » de l’arbre de périphériques
    • Il crée et enregistre des nub NintendoWiiHollywoodDevice représentant le matériel sous-jacent
    • Cela permet ensuite aux pilotes des périphériques enfants, comme la carte SD, de s’y rattacher

  • Pilote de carte SD

    • L’accès à la carte SD de la Wii a été implémenté en héritant de IOBlockStorageDevice
    • La communication avec la carte SD s’appuie sur les commandes IPC de MINI (coprocesseur Starlet) : IPC_SDMMC_SIZE, READ, WRITE
    • Pour résoudre les problèmes liés à la mémoire cache, des buffers de mémoire non cacheable ont été utilisés
    • Un nub IOMedia a été créé avec succès, permettant la reconnaissance du système de fichiers racine et un démarrage complet
    • Le log de démarrage affiche BSD root: disk0s4

  • Pilote framebuffer

    • En héritant de IOFramebuffer, la zone MEM1 (0x01700000) de la Wii a été définie comme framebuffer
    • Pour permettre la transition entre console texte initiale et interface graphique, isConsoleDevice() renvoie true
    • Le matériel vidéo de la Wii utilisant le format YUV, un double framebuffer avec conversion RGB→YUV a été implémenté
    • Une boucle de conversion effectue cette transformation à 60 Hz → aboutissant à un affichage GUI aux couleurs correctes

  • Prise en charge des entrées USB

    • Une tentative a été faite avec AppleUSBOHCI pour piloter le contrôleur USB 1.1 OHCI de la Wii
    • Problème 1 : absence des sources de IOUSBFamily, empêchant le débogage
    • Problème 2 : dépendance à IOPCIDevice, contournée via l’écriture d’un faux NintendoWiiHollywoodPCIDevice pour la Wii
    • Problème 3 : incohérence d’endianness (la Wii est en reversed-little-endian), nécessitant la suppression du byte swap logiciel
    • Après obtention des sources de IOUSBFamily pour Mac OS X Cheetah via IRC, la modification et la compilation ont abouti
    • Au final, le clavier et la souris USB fonctionnent, transformant la Wii en véritable système Mac OS X complet

Améliorations du bootloader et du noyau

  • Améliorations du bootloader

    • Ajout de la détection des partitions de carte SD et d’un menu de démarrage, avec implémentation du parsing de Apple Partition Map (APM)
    • Les extensions noyau (kext) sont chargées par le bootloader puis enregistrées dans le nœud /chosen/memory-map
    • Cela permet de démarrer à partir d’une image d’installation Mac OS X non modifiée

  • Simplification du noyau

    • Les modifications spécifiques à la Wii ont été réduites au minimum :
    • correction de la configuration BAT
    • reconnaissance des adresses d’E/S à partir du nœud « hollywood »
    • correction de la cohérence du cache du framebuffer
    • externalisation des pilotes hors du noyau pour améliorer l’efficacité de build et la maintenabilité

Conclusion

  • Un projet imaginé à l’université en 2013 a finalement été achevé plus de dix ans plus tard
  • Le défi a été inspiré par un portage de Windows NT sur Wii
  • Au final, le projet a permis un démarrage complet de Mac OS X 10.0 sur Wii et son utilisation en interface graphique
  • Il souligne la leçon suivante : « plus un projet semble impossible, plus il vaut la peine d’être tenté »

À lire aussi

3 commentaires

 
ffdd270 2026-04-09

Quel texte délicieux, avec un auteur formidable….
 
jjpark78 2026-04-09

Le geek parmi les geeks, c’est décidément le geek occidental...
 
GN⁺ 2026-04-09
Réactions sur Hacker News

  • Ce projet était vraiment un travail stupéfiant. L’article lui-même était captivant, je suis resté absorbé jusqu’au bout
    J’ai particulièrement été marqué par le passage disant que « WindowServer manifestait son mécontentement et qu’il a fallu écrire soi-même un pilote de framebuffer pour résoudre le problème »
    J’ai été surpris de voir que la couche d’abstraction I/O Kit de macOS faisait réellement son travail. Chapeau aux développeurs de NeXT

    • J’ai ressenti la même chose. Comme c’était ma première expérience d’écriture de pilote, la courbe d’apprentissage était raide, mais voir le système prendre vie m’a permis de comprendre l’approche d’IOKit
      Je n’ai pas d’expérience en développement de pilotes sur d’autres plateformes, donc c’est difficile de comparer, mais structurellement c’était assez séduisant
    • Il me semble qu’IOKit a été conçu de zéro pour OS X, et qu’à l’époque de NeXT ils utilisaient un autre modèle appelé DriverKit
      Autrefois, des développeurs NetBSD avaient même réussi à faire tourner Darwin PPC au-dessus d’une couche de compatibilité Mach/IOKit, jusqu’à lancer Xquartz. Le fait que NetBSD traduisait les appels IOKit est fascinant
    • Il y a aussi beaucoup de similitudes avec la pile Linux, donc je compte regarder le projet Linux on Wii pour comparer la façon dont ils ont géré les problèmes de framebuffer
      J’ai encore du mal à croire qu’autant d’OS puissent tourner sur Wii
    • L’expérience acquise depuis l’époque d’OPENSTEP, en ciblant plusieurs architectures et systèmes d’exploitation, a probablement aidé pour ce genre d’abstraction
    • Je suis d’accord avec l’idée qu’« il est étonnant de voir à quel point macOS est bien abstrait »
      En réalité, la différence entre une bonne abstraction et une mauvaise abstraction dépend de la qualité de son explication

  • L’ingénierie en elle-même est impressionnante, mais ce qui m’a vraiment marqué, c’est que l’auteur développait en classe économique

    • Déjà, moi j’ai du mal à utiliser correctement un ordinateur portable en classe économique, alors le brancher à une Wii pour déboguer, c’est inimaginable
    • Apple avait déjà fait une pub sur le montage vidéo dans un avion (lien YouTube)
    • La personne assise à côté devait sûrement se demander « mais c’est quoi ce truc ? » tout en restant sur son téléphone. À sa place, je n’aurais pas pu m’empêcher de poser la question
    • En regardant la photo, on dirait à moitié un bus, à moitié un avion. Quoi qu’il en soit, développer en déplacement avec une Wii, c’est la preuve d’une concentration et d’un dévouement énormes
      (Après vérification, la première photo était dans un bus, la deuxième dans un avion)
    • Le fait de pouvoir se plonger dans un projet aussi complexe en déplacement est impressionnant. En regardant à nouveau la photo, ça pourrait aussi bien être un train ou un bus. Quoi qu’il en soit, c’est un sacré flex

  • En tant qu’auteur du port NetBSD pour Wii et Wii U, je tiens à adresser mes sincères félicitations pour ce projet
    J’ai hâte de voir quels problèmes ont été résolus et comment

    • Ton port a été une grande source d’inspiration. Merci pour toutes tes contributions dans ce domaine

  • J’étais moi aussi autrefois un fan hardcore de Mac, et j’avais même créé par rétro-ingénierie une des premières « apps iOS » non officielles
    Mais ce projet dépasse tout cela. Le fait de faire tourner macOS sur Wii est déjà incroyable, mais l’article lui-même est d’une précision et d’un intérêt remarquables

    • Merci pour ces mots chaleureux :)

  • Je découvre seulement maintenant que la Wii n’avait que 88 Mo de RAM. Heureusement que ses jeux n’étaient pas basés sur Electron

    • Petit fait historique intéressant : Windows Vista est aussi sorti en Amérique du Nord le même mois que la Wii
      La configuration minimale de Vista demandait 512 Mo, alors que la plupart des PC de l’époque avaient moins de mémoire que cela
      Aujourd’hui, on voit les 8 Go reculer et les 16 Go devenir la norme, le monde a bien changé
    • Le fait que le menu de configuration de la Wii soit composé de pages web HTML est assez drôle. Même une console de 2006 n’a pas échappé à l’emprise du web

  • Avant de commencer le projet, j’ai d’abord vérifié si c’était seulement possible, et dans un commentaire Reddit de 2021 quelqu’un affirmait qu’il y avait « 0 % de chances »
    Au contraire, ça m’a motivé. C’est comme ça que j’ai commencé à analyser le matériel de la Wii. C’était vraiment drôle

    • La valeur de ce genre de projet, c’est de figer pour l’éternité ce type d’affirmation du style « absolument impossible »
      Les gens prennent souvent des choses « presque impossibles » pour des choses absolument inenvisageables, tout en se croyant sceptiques de manière principielle
    • Ça me rappelle une vieille blague sur Linux. Au lieu de demander « comment faire X sous Linux ? », il suffisait de dire « X est impossible sous Linux » pour que quelqu’un montre immédiatement comment faire
    • Moi aussi, j’ai lancé un projet après avoir lu dans la documentation du MacroPad d’Adafruit qu’on ne pouvait pas y ajouter de BLE ni de Wi‑Fi
      Je me suis dit « vraiment ? » et j’ai reconfiguré le port UART pour y brancher un ESP32
    • La scène de débogage où « tout est magenta » était aussi très drôle
    • Beaucoup de commentateurs sur Internet prennent le cynisme pour de la perspicacité de cette manière
      Le problème, c’est qu’ils n’ont même pas la notion de cynisme ignorant

  • Déboguer un kernel panic sur Wii en étant assis en classe économique dans un avion… ce niveau de concentration est difficile à imaginer
    La plupart des gens ont déjà du mal à lire un livre entier en avion

  • C’était vraiment un super projet. Ça m’a rappelé l’âge d’or du développement bas niveau
    Avant, initialiser le VGA et dessiner des pixels était simple, et des puces comme le 6502 étaient facilement accessibles
    Mais aujourd’hui, les systèmes sont devenus tellement complexes que la barrière à l’entrée a fortement augmenté
    Et l’IA, au lieu de simplifier le développement, donne parfois l’impression de rendre l’accès encore plus difficile

  • Moi aussi, j’essaie actuellement de porter Mac OS 9 sur Wii U
    En voyant ce projet, j’ai été complètement impressionné, et chaque fois que je me dis que c’est « impossible », ça me redonne du courage

    • Vraiment génial. Mac OS 9 étant propriétaire, ça a l’air d’être un défi encore plus difficile
    • L’absence des sources de XNU ou de Darwin est un désavantage, mais ça peut être compensé avec des outils comme les sources fuitées de System 7.1, Ghidra et MCP. Bonne chance

  • L’article était excellent, mais intégrer une vidéo .mov avec une balise <video> pose des problèmes de compatibilité navigateur
    Ça ne se lit ni dans Chrome ni dans Firefox

    • Si ça ne fonctionne ni dans Chrome ni dans Firefox, on peut considérer que ça ne marche pratiquement dans aucun navigateur
    • Merci ! C’est déjà corrigé