What?
Over the past while, I’ve worked on-and-off in my free time patching the arm64 Linux kernel to run Nintendo Switch games natively, i.e. by taking many of the Switch’s “Horizon” OS
system calls and implementing their behavior using Linux’s existing facilities for memory management, scheduling, synchronization, etc.
Why?
Well my original thought was merely that I wanted to run Switch games on my MacBook—given that they’re powered by the same arm64 architecture, you
should be able to run a Switch game’s machine code right on the CPU, no x86 translation layer needed. I was hoping to be able to achieve this entirely in user-space by attaching (via ptrace) to a process executing the Switch game’s code, and trapping any system calls to the tracer process. But if I recall, this quickly proved infeasible without OS support for various reasons to do with a Switch program’s use of system registers. If I’d have to poke around the OS anyway, I figured I might as well just handle everything within the kernel—then I’d just virtualize said OS under macOS.
Patching arm64 Linux means that you get Linux’s vast hardware driver support for free, so not only can it be virtualized on Apple silicon Macs, but it can run bare-metal on any arm64 hardware which supports Linux—even on lower-end hardware, given that there’s no need to emulate the CPU. This should offer a good deal of flexibility in the future for running Switch games, and hopefully will prove a useful option for game preservation.
Note that this is
not an attempt to accurately recreate the Horizon OS, nor is it particularly intended to run on an actual Switch, as (I believe) is the case is for the
Mesosphere project (though you probably could, I’m aware that the Switch can run Android at least). Rather, Horizon Linux is my attempt to enable Switch games to run on any arm64 hardware.
How?
In addition to OS support in handling Horizon system calls, a Switch program needs to be able to communicate with a number of
system services that handle things like input, audio, graphics, etc. Rather than reinvent the wheel, I figured the easiest approach would be to take the open-source
yuzu emulator and gut out the things I didn’t need (namely, kernel / CPU emulation), essentially keeping only the system services, GPU emulation, and app loader. This necessitated a custom system call interface to interface with kernel, and a custom Linux binary format for the loader to work with. I also decided (perhaps unnecessarily) to deviate from yuzu’s model and have each system service run persistently in it’s own thread, which made my reorganization considerably more involved.
The custom Linux kernel is called “Horizon Linux”, and the yuzu hack-job is called “mizu”. Mizu is intended to run as a systemd service under Horizon Linux.
@
Quincy:
@
K3Nv2:
@
BigOnYa:
@
Psionic Roshambo:
