Mac OS X를 닌텐도 Wii에 포팅한 이야기 — 부트로더부터 USB 드라이버까지

• Mac OS X 10.0 Cheetah를 닌텐도 Wii에서 네이티브로 돌렸다 — Linux, NetBSD, Windows NT에 이어 Wii에 포팅된 네 번째 OS. 2013년 대학교 2학년 때 아이디어만 품고 10년 넘게 묵혔다가 드디어 완성
  • 2021년 Reddit 댓글: "이게 될 확률은 0%다" → 오히려 동기부여가 됐다고 함

하드웨어 호환성 분석

• Wii의 CPU는 PowerPC 750CL — G3 iBook/iMac에 쓰인 PowerPC 750CXe의 진화형이라 CPU 자체는 호환 가능성 높았음
• RAM이 문제였음: Wii는 88MB인데 MEM1(24MB 1T-SRAM) + MEM2(64MB GDDR3)로 분리된 특이한 구조
  • Mac OS X Cheetah 공식 요구사항은 128MB지만, 비공식으로 더 적은 메모리에서도 부팅 가능
  • QEMU로 64MB RAM에서 Cheetah 부팅 테스트 → 문제없이 동작 확인

부트로더를 밑바닥부터 작성

• 실제 맥은 Open Firmware → BootX → XNU 커널 순서로 부팅하는데, XNU가 돌기 시작하면 앞의 두 단계는 더 이상 필요 없음
  • Open Firmware나 BootX를 포팅하는 건 불필요한 삽질이라고 판단, Wii Linux 프로젝트처럼 커스텀 부트로더를 처음부터 작성
• 부트로더가 해야 할 일: Wii 하드웨어 초기화 → SD 카드에서 커널 로드 → 디바이스 트리 생성 → 커널에 제어 넘기기
• Mach-O 바이너리 포맷으로 된 XNU 커널을 메모리에 올리는 로더를 구현하고, 커널 진입점 주소로 점프하는 방식

커널 패치와 빌드 환경

• XNU는 Wii의 메모리 레이아웃(MEM1: 0x00000000, MEM2: 0x10000000)과 호환 안 되는 BAT(Block Address Translation) 설정을 함
  • 커널 소스를 직접 수정해서 Wii 메모리 레이아웃에 맞춤
• 25년 된 OS 커널을 빌드하기 위한 개발환경이 꽤 기발함:
  • 모던 macOS 호스트에서 QEMU로 Mac OS X Cheetah 게스트를 돌림 (헤드리스)
  • NFS로 소스 코드 공유, SSH로 게스트 제어, 호스트에서 편집 → 게스트에서 빌드
• BAT 패치 + USB Gecko로 콘솔 출력 리다이렉트 후, 가상 메모리·IOKit·BSD 서브시스템 모두 초기화 성공 — "Still waiting for root device"까지 도달

IOKit 드라이버 작성 — Hollywood SoC 대응

• Wii는 PCI 버스가 아니라 Hollywood라는 커스텀 SoC를 사용함 → IOPCIFamily를 그대로 쓸 수 없어서 Hollywood용 드라이버를 직접 구현
  • Hollywood 드라이버가 디바이스 트리의 하위 노드를 순회하면서 nub(연결점)을 생성·발행
• SD 카드 드라이버: IOBlockStorageDevice를 서브클래싱
  • Wii의 ARM 코프로세서(Starlet)에서 돌아가는 MINI와 IPC로 통신하여 SD 카드 읽기/쓰기 구현
  • 캐시된 메모리 버그가 까다로웠음 — ARM CPU가 RAM에 쓴 데이터를 PowerPC CPU가 캐시에서 읽어 stale 데이터를 받는 문제 → uncached 메모리 사용으로 해결
• 프레임버퍼 드라이버: Wii의 비디오 하드웨어는 YUV 16bit를 기대하는데 Mac OS X는 RGB를 씀
  • Wii Linux 프로젝트에서 영감받아 듀얼 프레임버퍼 전략 적용: RGB 프레임버퍼(OS용) + YUV 프레임버퍼(디스플레이용), 초당 60회 변환

USB 지원 — 소스 코드 없는 디버깅의 고통

• AppleUSBOHCI 드라이버를 쓰려 했는데 3가지 장벽:

  • Apple이 Cheetah/Puma용 IOUSBFamily 소스를 공개하지 않음 (다른 건 다 있는데!)
  • AppleUSBOHCI가 IOPCIDevice에만 붙게 되어 있어서, Wii의 Hollywood nub에 매칭 안 됨 → IOPCIDevice를 상속한 가짜 PCI nub을 만들어 우회
  • Wii는 하드웨어에서 바이트 스왑(reversed-little-endian)을 하는데, IOUSBFamily는 소프트웨어에서도 스왑 → 이중 스왑 문제 발생

• Ghidra로 바이트 스왑 명령어를 수동 패치하려 했으나 실패 (비행기에서 몇 시간 삽질...)

  • 결국 IRC에서 옛날 CVS 레포를 구해서 IOUSBFamily를 소스에서 빌드 → USB 키보드/마우스 동작 성공

• 최종 결과: Mac OS X Cheetah가 Wii에서 풀 데스크톱으로 부팅되고 USB 키보드/마우스로 조작 가능 — 하와이 여행 중에 Wii를 가져가서 마일스톤을 찍었다는 게 진짜 집념

---

기술 맥락

• 이 프로젝트가 가능했던 핵심 이유는 Darwin/XNU가 오픈소스라는 거예요. 커널과 IOKit 드라이버 모델이 공개되어 있으니까, 하드웨어만 비슷하면 포팅 시도라도 해볼 수 있는 거거든요. 반대로 Quartz나 Finder 같은 GUI 계층은 닫혀 있지만, 커널만 돌아가면 그 위에 얹히는 구조라 별도 패치 없이 동작해요.
• IOKit의 provider-client 모델이 이 프로젝트에서 핵심적인 역할을 했어요. 드라이버가 nub을 통해 체인처럼 연결되는 구조라, Hollywood SoC용 드라이버만 제대로 만들면 그 위에 SD 카드, USB 등을 쌓아올릴 수 있었거든요. PCI가 없는 환경에서 IOPCIDevice를 상속한 가짜 nub을 만든 건 꽤 창의적인 해킹이에요.
• Wii의 reversed-little-endian 바이트 오더링 문제는 크로스 플랫폼 하드웨어 개발에서 자주 만나는 함정이에요. 하드웨어가 이미 엔디안 변환을 해주는데 소프트웨어도 변환하면 이중 스왑이 되는 건데, 소스 코드 없이 바이너리만으로 이걸 고치려다 실패한 게 오히려 교훈적이에요. 결국 소스 코드의 가치를 증명한 셈이죠.
• 25년 된 커널을 빌드하기 위해 QEMU + NFS + SSH를 조합한 크로스 컴파일 환경 구성도 흥미로워요. 레거시 소프트웨어 빌드 환경을 재현하는 건 실무에서도 종종 마주치는 문제인데, 가상화로 당시 OS를 그대로 올리는 게 가장 확실한 방법이에요.