Nintendo WiiでMac OS X 10.0（Cheetah）の動作に成功
(bryankeller.github.io)- WiiのPowerPCベースのハードウェアを使い、**Mac OS X 10.0（Cheetah）**をネイティブで実行する移植プロジェクトを完成
- Darwin/XNUカーネルをWii向けに改修し、ブートローダー・デバイスツリー・ドライバーを自作してGUI環境までの起動に成功
- SDカード・フレームバッファ・USB入力デバイスをサポートするカスタムIOKitドライバーを実装し、完全なシステム動作を実現
- BAT設定の衝突修正、Hollywood SoC向けドライバー層の構築、RGB→YUV変換フレームバッファなど、Wii特有の構造を反映
- 10年以上にわたる試行の末、WiiでMac OS Xの完全起動と操作を実現し、一見不可能に思えるプロジェクトにも挑戦する価値があることを示した
WiiでMac OS Xを動かすプロジェクト概要
- Mac OS X 10.0（Cheetah）をNintendo Wiiでネイティブ動作させるための移植プロジェクトを実施
- WiiにはすでにLinux、NetBSD、Windows NTなどのOS移植事例があり、今回そこにMac OS Xが加わった
- WiiのPowerPCベースのハードウェアを活用してDarwin/XNUカーネルを動かし、必要なドライバーとブートローダーを自作
- 結果としてWiiでMac OS XのGUI環境まで完全に起動し、キーボード・マウス入力にも対応
実行可能性の調査
- WiiのPowerPC 750CL CPUは、G3 iMac/iBookで使われたPowerPC 750CXeの後継にあたり、CPU互換性の問題はない
- Wiiの88MB RAM（MEM1 24MB + MEM2 64MB）は公式要件の128MBより少ないが、QEMUテストにより64MBでも起動可能であることを確認
- 対応ハードウェアはUSB Gecko（シリアルデバッグ）、SDカード、割り込みコントローラー、フレームバッファ映像出力、USBポート
- Mac OS Xのオープンソースコアである**Darwin（XNUカーネル、IOKit）**をWii向けに調整すれば、上位のGUIレイヤーも動作可能
- WiiはHomebrew ChannelとBootMiiによって自作コードの実行が可能で、移植実験に適している
移植アプローチ
- 3つの起動戦略から選択:
- Open Firmwareの移植
- BootXの移植
- カスタムブートローダーの自作
- Wii専用のブートローダーを新規作成し、ハードウェア初期化、カーネル読み込み、デバイスツリー生成、カーネルへの制御移譲を実行
- カーネル実行後はブートローダーコードは不要となり、その後はカーネルパッチとドライバー作成が中心となった
ブートローダー作成
- ppcskelのサンプルコードを基に、Wiiの初期化とSDカード・フレームバッファ・USBデバッグ機能を実装
- Mach-O形式のXNUカーネルをメモリにロードし、指定されたエントリポイントへジャンプして実行
- カーネル実行確認のため、LED点滅パッチを挿入してカーネル突入段階を追跡
- カーネル実行経路を逆追跡した結果、device_tree.cの段階で300例外が発生していることを確認 → デバイスツリー受け渡しの必要性を認識
-
デバイスツリーの生成と受け渡し
- Wiiの固定ハードウェア構成を基に、ハードコードした最小ツリーを構成（
/cpus,/memory） boot_args構造体にデバイスツリーポインタを含めてカーネルへ渡す- その後、カーネルが正常にツリーを認識して起動が進行
- Wiiの固定ハードウェア構成を基に、ハードコードした最小ツリーを構成（
カーネルパッチ
- XNUの**BAT（Block Address Translation）**設定がWiiのメモリマップと衝突するため、カーネルソースの修正が必要
- **Mac OS X Cheetahゲスト（QEMU）**環境でカーネルビルド環境を構築
- BAT修正とUSB Geckoへのコンソール出力リダイレクトを追加し、デバッグを可能にした
- その後、仮想メモリ、IOKit、BSDサブシステムが正常に初期化
- 起動ログに「Still waiting for root device」というメッセージが出力 → SDカードドライバーの必要性を確認
ドライバー作成
-
IOKit構造の理解
- IOKitはC++ベースのカーネル拡張フレームワークで、**ドライバー-ナブ（nub）**構造を通じてハードウェア層を表現する
- 例:
IOPCIBridge→IOPCIDevice→SomeEthernetCard→IOEthernetInterface - Wiiは**PCIバスではなくSoC（Hollywood）**構成を使うため、IOPCIFamilyを置き換えるカスタムドライバーが必要
-
Hollywoodドライバー
NintendoWiiHollywoodドライバーを作成し、デバイスツリー内の「hollywood」ノードとマッチング- 下位ハードウェアを表現する**
NintendoWiiHollywoodDeviceナブ**を生成・登録 - これにより、SDカードなど下位デバイス用ドライバーを接続可能にした
-
SDカードドライバー
IOBlockStorageDeviceを継承してWiiのSDカードアクセスを実装- MINI（Starletコプロセッサ）のIPCコマンド（
IPC_SDMMC_SIZE,READ,WRITE）を使ってSDカードと通信 - キャッシュされたメモリに起因する問題を解決するため、非キャッシュメモリバッファを使用
- 成功裏に
IOMediaナブが生成され、ルートファイルシステム認識と完全起動が可能に - 起動ログで
BSD root: disk0s4を確認
-
フレームバッファドライバー
IOFramebufferを継承し、Wiiの**MEM1領域（0x01700000）**をフレームバッファに指定- 初期テキストコンソールとGUI切り替えのため、
isConsoleDevice()がtrueを返すよう設定 - Wiiの映像ハードウェアはYUVフォーマットを使うため、RGB→YUV変換用の二重フレームバッファを実装
- 変換ループによって60Hzで色変換を実行 → 正常な色でGUI表示に成功
-
USB入力対応
- WiiのOHCI USB 1.1コントローラーを動かすため、
AppleUSBOHCIの利用を試行 - 問題1: IOUSBFamilyのソース不在によりデバッグ不能
- 問題2: IOPCIDevice依存のため、Wii向けのダミー
NintendoWiiHollywoodPCIDeviceを作成 - 問題3: エンディアン不一致（Wiiはreversed-little-endian）のため、ソフトウェア側のバイトスワップを削除する必要があった
- IRC経由でMac OS X Cheetah向けIOUSBFamilyソースを入手し、修正・ビルドに成功
- 結果としてUSBキーボード・マウス入力が動作し、Wiiが完全なMac OS Xシステムとして機能
- WiiのOHCI USB 1.1コントローラーを動かすため、
ブートローダーおよびカーネルの改善
-
ブートローダー改善
- SDカードパーティション探索と起動メニューを追加し、**Apple Partition Map（APM）**の解析を実装
- **カーネル拡張（kext）**をブートローダーから読み込み、
/chosen/memory-mapノードに登録 - これにより、未改変のMac OS Xインストールイメージからの起動が可能になった
-
カーネルの簡素化
- Wii専用のカーネル修正を最小限に整理:
- BAT設定の修正
- 「hollywood」ノードベースのI/Oアドレス認識
- フレームバッファのキャッシュ整合性修正
- ドライバーをカーネル外へ分離し、ビルド効率と保守性を向上
まとめ
- 2013年の大学時代に構想したプロジェクトを、10年以上を経て完成
- Windows NTのWii移植事例に触発されて挑戦
- 結果としてWiiでMac OS X 10.0の完全起動とGUI操作を達成
- 「不可能に見えるプロジェクトほど挑戦する価値がある」という教訓を強調
3件のコメント
おいしい文章に、素敵な書き手ですね…。
オタクの中のオタクは、やはり海外オタクということか..
Hacker Newsのコメント
このプロジェクトは本当に驚異的な仕事だった。記事自体も引き込まれる内容で、最後まで夢中で読んだ
特に「WindowServer が不満を示し、これを解決するには自分で framebuffer ドライバを書く必要があった」というくだりが印象的だった
MacOS のI/O Kit 抽象化レイヤーが実際にきちんと機能しているのを見て驚いた。NeXT の開発者たちに拍手を送りたい
他のプラットフォームでドライバ開発をした経験がないので比較は難しいが、構造的にはかなり魅力的だった
以前 NetBSD の開発者たちが Mach/IOKit 互換レイヤーの上で PPC Darwin を動かし、Xquartz まで起動したこともあった。NetBSD が IOKit 呼び出しを翻訳していたという点が興味深い
Wii の上でこれほど多くの OS が動くというのはいまだに信じがたい
実際、良い抽象化と悪い抽象化の違いは、どれだけうまく説明されているかにかかっている
エンジニアリング自体もすごいが、筆者がエコノミークラスで開発していたという点が本当に印象的だった
（追記すると、最初の写真はバス、2枚目は飛行機だった）
私はNetBSD の Wii および Wii U 向けポートの作者として、このプロジェクトに心から祝意を送りたい
これからどんな問題をどう解決したのかを見るのが楽しみだ
昔は自分も筋金入りの Mac マニアで、リバースエンジニアリングで初期の非公式な「iOS アプリ」を作ったこともあった
だが今回のプロジェクトはそのすべてを上回っている。Wii で MacOS を動かしたことも驚きだが、記事自体があまりに精緻で面白い
Wii の RAM が88MBしかないと初めて知った。ゲームが電子ベースでなくてよかった
Vista の最小要件は 512MB だったが、当時のほとんどの PC はそれより少ないメモリしか積んでいなかった
今では 8GB が減って 16GB が標準になりつつあるのを見ると、時代は大きく変わったと感じる
プロジェクトを始める前に「そもそも可能なのか？」を確認したところ、2021 年の Reddit コメントに「可能性 0%」と書かれていた
それを見て逆にやる気が出た。そこで Wii のハードウェアを分析しながら始めた。本当に笑えた
人は「ほぼ不可能なこと」を絶対に起こらないことだと決めつけ、自分では原則ある懐疑主義者だと勘違いしてしまう
「本当か？」と思って UART ポートを再構成し、ESP32 をつないだ
無知な皮肉という概念がないのが問題だ
Wii でカーネルパニックをデバッグしながら飛行機のエコノミークラスに座っていたなんて、その集中力のレベルは想像もつかない
たいていの人は飛行機で本を 1 冊読むだけでも大変なのに
本当に素晴らしいプロジェクトだった。昔の低レベル開発の黄金時代を思い出す
昔は VGA を初期化してピクセルを打つのも簡単で、6502 のようなチップも扱いやすかった
だが今ではシステムが複雑になりすぎて、参入障壁が高くなった
そのうえ AI は開発を単純化しているように見せながら、かえってアクセスしにくくしている
自分も同じようにMac OS 9 を Wii U に移植しようと試みている
このプロジェクトを見て完全に感銘を受けたし、「不可能だ」と思うたびにまた勇気をもらえる
記事も素晴らしかったが、
.mov動画を<video>タグで埋め込んだのはブラウザ互換性の問題があるChrome や Firefox では再生されない