The effort to port Linux to the GameCube -- a longtime goal for many hackers -- finally came to fruition in December 2003 at the Chaos Communication Congress in Berlin, Germany. There and then, GameCube Linux came into being as members of the GameCube homebrew scene met with the Xbox Linux team over beers. "I think every member has a different reason why he wanted to participate. One of my reasons was that the GC is a PowerPC and I always wanted to learn the PPC architecture," says Stefan Esser, one of the programmers involved in the port.
"It is important to emphasize that the GameCube hacking and homebrew scene had existed for a long time," says Michael Steil, who started the project. "Unlike the Xbox Linux Project, which did a lot of reverse engineering on the Xbox themselves, the GameCube Linux Project was founded when a lot about the GameCube had already been known."
The GameCube port of Linux works by transferring the code to the console's hardware via an exploit in the game Phantasy Star Online. Another method involves a hardware hack to the console, replacing the GC's serial BIOS chip with an Complex Programmable Logic Device (CPLD), to allow users to start a binary through the network adapter.
The principal members of the GameCube Linux Project team spoke to ONLamp.com about the rapid, and ongoing, development of their port:
Michael Steil, 24, started this project to port Linux to the GameCube. He wrote the interrupt subsystem and most of the framebuffer driver for the port. He lives in Munich, Germany, and is studying computer science at a university.
The monikered "Costis" contributes his knowledge of the GameCube hardware to the project (gleaned from his personal experience in the GameCube demo programming scene). He reveals only that he is a student residing somewhere in the USA.
|Linux/Unix System Administration Certification -- Would you like to polish your system administration skills online and receive credit from the University of Illinois? Learn how to administer Linux/Unix systems and gain real experience with a root access account. The four-course series covers the Unix file system, networking, Unix services, and scripting. It's all at the O'Reilly Learning Lab.|
Felix Domke, 21, lives in Lbeck, Germany, and is studying computer science and electrical engineering at a university. He also works as a Linux programmer. He's the one who figured out how to get the Linux kernel to boot up on the GameCube.
Stefan Esser, 25, wrote drivers to test the functionality of the port's PowerPC IRQ subsystem. He resides in Cologne, Germany, where he is studying computer science and business at the University of Cologne.
What version or distribution of Linux did you choose to port, and why?
Stefan Esser: At the moment, we do not use any distribution. We have just taken a vanilla Linux 2.6.1 kernel.
Felix Domke: Mainly because this is experimental anyway; why not choose the bleeding-edge kernel? Long-time stability is really not an issue right now, so keeping up with the latest improvements, especially on embedded systems, is more important.
Give us a general idea of the steps that were required to port Linux to the GC.
FE: Well, the first thing is to get something, any binary, to run on the GameCube. This can either be done with a game exploit -- the "PSO method" -- or a replaced BIOS, which involves modifying the hardware.
The next step was to adjust the embedded loader to the special conditions on the startup. For example, the data cache must be left enabled. Currently, I'm investigating why, but leaving it on fixes the problem of corrupted data completely. The kernel initialized itself; the first part was done.
Now I started to write a platform file, which implemented platform-specific functions -- IRQ handling, bus speed initializing. Since the GameCube lacks a serial port, I implemented an early text console on the framebuffer. This really helped debugging.
The next thing was writing the driver layers. At first, the interrupt handling had to be rewritten, as the PIC is a non-standard controller specially designed to fit in the GameCube environment. Then another important part would be the EXI, the external interface bus handling, because the network adapter is attached on that bus.
Michael Steil: A port needs to take into account four things: the boot method, the CPU of the machine, the chipset, and its devices. The boot method has been provided by the homebrew scene -- especially by Costis. The CPU of the GameCube is a standard PowerPC, so Linux runs on it with only minor changes in the initial boot and initialization code. The chipset includes the interrupt controller, for which support is needed, so that drivers work. Then the actual drivers for the devices are needed, including drivers for buses, to which devices are connected. The GameCube has a very unique architecture, so most code has to be written for this part.
SE: At the moment we can boot the Linux kernel on the GameCube, have output through a GameCube framebuffer driver, are able to mount a ramdisk and execute
busybox. We have finished the IRQ support and wrote two simple example drivers that react on someone pressing the eject button and closing the DVD tray. Currently, we are developing a driver for the GameCube Broadband Adapter so that we can mount remote filesystems.
What have been the biggest technical challenges that had to be dealt with to get the port to work?
Costis: Porting the kernel was not difficult at all. We were able to do it in less than a week.
FE: The port was quite straightforward. A general problem on the GameCube is that you don't have real debugging possibilities -- no serial port, not even a simple LED. To display something, you first have to initialize the video interface. As the GameCube was never meant to be programmed by hackers, there's only very limited information about the low-level programming. But most of this stuff has been reversed. There are drivers for most of the [GameCube's] important hardware elements. They aren't written for Linux, but run without an operating system. The remaining task now is to port them to Linux.
MS: I think the work that had been done by the [GameCube] homebrew scene has been hardest. They had to find a way to make their own code run on the GameCube, and they had to reverse engineer the hardware. Now that we have this method, and lots of documentation, everything else is quite straightforward. That's why the project is progressing so quickly.
What interesting technical things about the GC itself have you discovered when porting Linux to it?
FE: The system is extremely well-designed. [Its] hardware elements might not be the fastest on the market, but they are optimized to fit in a game console exactly this way. The GameCube [has] only 24MB RAM, only a 486MHz main processor, but in a real game, the system is utilized nearly completely.
MS: What's most amazing is the extreme difference of the architectures of the GameCube and the Xbox. The Xbox is a PC, so it has all these legacy features and unneeded PC features -- like plug-n-play -- and is very complicated to program because the hardware interfaces are old and "patchy." Programming the GameCube reminds me more of programming a Commodore 64 or an Amiga: Very clean, minimal hardware interfaces, a perfectly optimized system.
How much control over the GameCube hardware does your Linux port give to the user? Graphics, sound, controllers?
Costis: A user program on the GameCube has full and complete control of the hardware. Unlike the Xbox, the GameCube does not have any BIOS calls. In fact, the GameCube's BIOS is just a normal program that serves to boot a game disk and is cleared out of memory when the game is ready to be executed. Therefore, we have full control of the GameCube hardware, such as graphics, sound, controllers, the network adapter, etc.
MS: Linux will be able to provide the standard interfaces to the applications, like DirectFB, X-Window, ALSA, SDL, and OpenGL.
FE: This is exactly a problem of a real operating system on a game console. Game consoles are made to be run without a real operating system. You never get the best performance with an operating system under your game. So while in the future there will be controller [and] sound support next to the existing framebuffer, it will be very difficult to make use of advanced features, like the audio DSP. The 3D hardware could be used with some OpenGL-styled port, but you'll never get performance you expect from games.
What practical uses do you think there could be for having Linux running on the GameCube? Could homebrew games be made for it easily?
FE: I don't see much practical use. Linux on the GameCube is just a fun project for me. Homebrew games might become easier to develop. But in my eyes, making a generic GameCube 3D engine, for use without Linux, would be more efficient.
Costis: It can be used as a thin client, a multimedia terminal, and a PowerPC-based server. Also, existing games for PPC Linux environments should also work once we have implemented enough drivers. The ability to run existing PPC Linux games on GameCube Linux will bring a huge amount of new homebrew games playable on the GameCube, which I find quite interesting.
MS: My personal motivation is to have a Linux runtime environment for games. I disagree to some point with Felix, because I think having a full operating system below a game is a good thing. Many games might not need it, but development can get a lot easier. The Xbox uses an almost full operating system as its standard runtime environment. Existing Linux multimedia applications and games will run on the GameCube with only few changes, if any.
Have you considered porting another operating system to the GameCube, like a variant of BSD, for example?
SE: Once the work is done to port Linux to GameCube, it should be trivial to port NetBSD. The only problem is we do not know it well enough.
FE: I thought about porting some real-time OS, like eCOS or KOS.
MS: It would be nice to run Mac-on-Linux on top of Linux, so we can run the Mac OS on the GameCube. Or the Amiga emulator UAE, so that the GameCube would finally be the PowerPC-based Amiga the world has been waiting for. But this is all on top of Linux. Linux does that because you can run anything inside Linux. You get most of this flexibility with BSD, too, certainly, but we're all most experienced in Linux.
Could you use some help from outsiders? If so, what kind of help?
MS: Certainly. You can help as a developer, as a beta tester, or just as someone that comments on what we're doing.
Costis: Sure, anyone is free to help with writing drivers and the code in general.
SE: In the open source world no one is an outsider. You just have to knock on our door and tell us that you want to help.
What advice do you have for those interested in porting Linux to other devices?
FE: Don't do it if you expect it to be of practical use. Do it only [for the] fun of programming and porting.
Costis: Only port it if you are going to have fun with it. On a system like the GameCube, which does not have any embedded hard drive, its use would be limited.
MS: It is a lot easier than you might think, with good C and Assembler skills, some knowledge on operating system principles, and some persistence. You won't need any documentation or even knowledge about the Linux kernel -- just look at the existing code, and use it as a template for your development. Learn by doing.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the LinuxDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.