
The Mega Drive add-on has booted uClinux, launched BusyBox and reached an interactive shell despite having two 23MHz processors and only 256KB of main memory. The Sega Super 32X can now run Linux. That’s an impressive sentence on its own. The real story, though, is how much work it took to make it happen. The 32X isn’t a normal computer, or even a self-contained game console. It’s an add-on that plugs into the cartridge slot of the Sega Mega Drive and adds two 32-bit Hitachi SH-2 processors running at roughly 23MHz. Those chips work alongside the Mega Drive’s existing Motorola 68000 processor, creating a strange three-CPU system held together by shared memory, interrupts and hardware designed with games in mind. Linux doesn’t get an easy ride here.
Running Linux with almost no memory
The biggest problem is obvious: memory. The 32X has just 256KB of main RAM. The Mega Drive adds another 64KB, but that still leaves the system far below what even a heavily trimmed Linux setup would normally expect. So the port takes a clever route.
A compatible flash cartridge can map part of its storage into the system as writable memory. That gives Linux several extra megabytes to work with while leaving enough cartridge space available for the compressed kernel and initial filesystem.
It’s not exactly fast RAM, and it doesn’t remove every limitation. But it gives the kernel enough breathing room to boot, start userspace and keep running without immediately exhausting the machine. Everything still has to stay small. Very small.
The kernel configuration drops features that aren’t needed. BusyBox gets the same treatment, with only essential commands included. The filesystem contains just enough to bring the system up and provide an interactive environment.
You won’t be compiling software or running a desktop. That’s not the point. The achievement is getting a functional Linux userspace running on hardware with less memory than many modern web pages consume.
Making three processors work together
The 32X architecture creates another challenge: the two SH-2 processors can’t handle every part of the system on their own. The Mega Drive’s 68000 processor has to help.
It acts as a bridge for serial output, allowing the Linux kernel to print boot messages and provide a console. Without that link, debugging the port would become much harder because the SH-2 side lacks a convenient direct route for early text output. The 68000 also helps the two SH-2 chips communicate.
Linux normally expects proper hardware support for multiprocessor synchronisation. The 32X doesn’t provide it. There’s no cache coherency, and the SH-2 chips lack several atomic instructions that a typical Linux SMP system would rely on. That sounds like a dead end. It wasn’t.
The port handles critical locking in software, using a Peterson-style method with shared variables stored in uncached memory. It’s a practical workaround for hardware that was never designed to run a multiprocessor operating system.
Inter-processor interrupts need similar assistance. One SH-2 sends a request through the 68000, which then triggers the required interrupt on the other SH-2. The older processor effectively works as a traffic controller between the two 32-bit CPUs. Does it perform well? Not really.
Both SH-2 processors share access to the same buses, so running them together can create heavy contention. In some situations, enabling the second processor can make the system slower rather than faster. Still, Linux detects both CPUs and starts them successfully. That’s the milestone that matters.
Fixing problems far below the kernel
The work didn’t stop at writing a few device drivers. The port exposed issues in compiler-generated code, SH-2 architecture support and low-level assembly routines. Some arithmetic helper functions damaged registers during boot. Unsupported processor instructions had to be removed from the build. Timer support needed custom work so Linux could calibrate delays and keep track of time.
Early console code also had to be available before the normal system console started. Otherwise, the kernel could fail silently with almost no clue about what went wrong. Userspace required its own carefully chosen setup. The system uses an SH-2 big-endian toolchain, musl and ELF FDPIC, a format suited to processors that don’t have an MMU. Each piece solves a specific limitation. Together, they turn the 32X into a machine that can load Linux, start a shell and execute commands.
Retro console Linux ports are getting serious
Linux has appeared on unusual game hardware before, including the Atari Jaguar. The 32X port pushes the idea into even harsher territory. This isn’t just a kernel logo or a short boot demonstration. The system has a loader, memory management strategy, console, timer, userspace and working dual-processor support. It reaches the point where someone can sit at a shell and interact with Linux on the original hardware. It’s slow. Of course it is.
The architecture fights the operating system at nearly every step, and the available resources are tiny. But that’s exactly why the result stands out. The port doesn’t make the Super 32X practical as a computer. It proves that Linux can be adapted to one of Sega’s strangest and most restrictive hardware designs. The year’s retro-console Linux trend has found its toughest target yet.














