Linux on the Atari Jaguar. No, really. - cakehonolulu's blog

What in the tarnation is an Atari Jaguar?

Released in North America in November of 1993, the Atari Jaguar promised to be the new cool kid in the block thanks to it's (Highly debated) 64 bits of pure power.

The Atari Jaguar

The console itself ended up being a commercial disaster, even after the release of the CD addon, the Jaguar CD; which managed to sell even less units in a desperate attempt to try and compete with the Sony Playstation and the Sega Saturn.

The Atari Jaguar CD Add-on

Why in the tarnation Linux of all things?

Interestingly enough, to this day, Linux has architecture code for the 68000-family of processors. 68040, 68030, 68010... and even the original base 68000 processor. All neatly structured under arch/m68k/.

As a refresher, the Motorola 68000 was a CISC processor with mixed 16-32 bit capabilities (It's usually described as being 32-bit internally due to the register width length and 16-bit because the data bus was 16-bit, so 2-byte transfers at a time).

It had a 24-bit address bus, 2 to the power 24; thereabout a maximum of 16MBs of addressable memory.

It was released on 1979 to compete with the soon-to-be-released 16-bit CPUs of the era.

The Motorola 68000

Overall, it got lots of traction commercially; it ended up being incoporated in lots of popular commercial hardware. Biggest contenders are the original Macintosh (And Apple Lisa), the Commodore Amiga series of computers (With varying generations of the 68000), the Sega Genesis/Megadrive, the Neo-Geo AES, Plexus workstations... and the Jaguar.

Let's now address the elephant in the room, why Linux.

Well, it's easy; because we can (-ish).

jmp _linux?

Doing a bringup for a new 68000-based Linux port should be easy... right? Well... you're in for a good time.

As you may know (Or not), there's an extended thought that Linux requires an MMU to run (You know, being able to use virtual memory is a good thing if we want to run software w/o having day-long headaches).

Technically you are kind of right, but there's uClinux; which precisely makes this feasible. At some point it stopped being a downstream fork of Linux to become part of it; thankfully it's baked in for m68k (And well, the flat memory model and the rest of requirements you can imagine that an MMU-less system has).

Okay so, we enable all the required configuration flags on the Linux menuconfig (To basically tell it not to use an MMU and use the Flat Memory model), we compile and it should run right? Well yes... but no.

What actually jmp _linux involves

The Jaguar has 2 megabytes of RAM (Mapped at 0x000000), (up to) 6 megabytes of ROM (The cartridge, basically) mapped at 0x80000 and 2 custom ICs (Tom & Jerry, a "GPU" and a DSP) which are also memory-mapped.

The main hurdle we have is the memory footprint; while it's true that it's a good amount, it's still not infinite (We're talking megabytes, not gigabytes).

We basically need to find a way to try and optimize our RAM usage. We can do the easy things first, removing features from the kernel, disabling debug... the usual suspects; but we'll still probably have the issue where we can't load the kernel to RAM w/o going OOM (Heck, we're not even considering an initramfs at this point, which are also bulky).

Thankfully, Linux is smart enough to let us "split" the kernel in 2 separate memory regions. One can take advantage of the fact that we can store the read-only sections of it (Think, .rodata or .text) on the cartidge (The ROM) and the dynamic sections (.data or .bss) in RAM (Think, XIP; eXecute-In-Place).

Fortunately for us, it's a matter of telling it where we have the RAM, and where we have the ROM and it (Liunx) handles the relocations for us.

Cool, we can now fit Linux on the Jaguar and it should be able to execute... right? Well sure, you can try specifying the base of the kernel (Remember, non-PIC code) and loading it there and just doing a jmp $80000... but how do we know what is happening under the hood?

What Linux needs to boot

In the context of booting Linux, we need 2 things (At least, when doing the bringup):

Any type of output so we can see kernel messages

Any way to tick the system (A timer, basically)

The first requisite usually involves ye' good ol' UART. The Jaguar's DSP (Jerry) has TXD & RXD pins that (At least for booting Linux) can be repurposed to do serial output (If we ignore anything that has to do with sound). Writing a small console driver that bitbangs the pins is enough to start seeing some earlyprintk messages.

The second one, is a bit tougher. But we can basically use any of the 2 timers that the Jerry IC has; commercial games & software use them for sound-related tasks but we'll use them to basically enable Linux to calibrate and setup the scheduler and the systems that also depend on a PIT. It's useful that they can both trigger an interrupt on the Jerry itself but also on the 68000. We can basically override...