Many machines are available with a number of different CPU options of which not all are currently supported. Please check section Processor Types to make sure your CPU type is supported. This is a listing of machines that are running Linux/MIPS, systems to which Linux/MIPS could be ported or systems that people have an interest in running Linux/MIPS.
The Acer PICA is derived from the Mips Magnum 4000 design. It has a R4400PC CPU running at 133Mhz or optionally 150Mhz plus a 512kb (optionally 2mb) second level cache; the Magnum's G364 gfx card was replaced with a S3 968 based one. The system is supported with the exception of the X server.
The Baget series includes several boxes which have R3000 processors: Baget 23, Baget 63, and Baget 83. Baget 23 and 63 have BT23-201 or BT23-202 motherboards with R3500A (which is basically a R3000A chip) at 25 MHz and R3081E at 50 MHz respectively. The BT23-201 board has VME bus and VIC068, VAC068 chips as system controllers. The BT23-202 board has PCI as internal bus and VME as internal. Support for BT23-201 board has been done by Gleb Raiko (rajko@mech.math.msu.su) and Vladimir Roganov (vroganov@msiu.ru) with a bit help from Serguei Zimin (zimin@msiu.ru). Support for BT23-202 is under development along with Baget 23B which consists of 3 BT23-201 boards with shared VME bus.
Baget 83 is mentioned here for completeness only. It has only 2mb RAM and it's too small to run Linux. The Baget/MIPS code has been merged with the DECstation port; source for both is available at http://decstation.unix-ag.org/.
The Cobalt Qube product series are low cost headless server systems based on a IDT R5230. Cobalt has developed its own Linux/MIPS variant to fit the special requirements of the Qube as well as possible. Basically the Qube kernel has been derived from Linux/MIPS 2.1.56, then backported to 2.0.30 for stability's sake, then optimized. Cobalt kernels are available from Cobalt's ftp site http://www.cobaltnet.com. The Cobalt Qube support has never been integrated into the official Linux/MIPS 2.1.x kernels.
The NEC uniprocessor machines are OEM Acer PICA systems, see that section for details. The SMP systems are different from that. The Linux/MIPS developers have no technical documentation as necessary to write an OS. As long as this does not change this will pretty much stay a show stopper preventing a port to NEC's SMP systems.
The Linux VR project is porting Linux to devices based on the NEC VR41xx microprocessors. Many of these devices were originally designed to run Windows CE. The project has produced working kernels with basic drivers for the Vadem Clio, Casio E-105, Everex Freestyle, and more. For more information please see http://linux-vr.org/.
Similar to the VR41xx, devices with these processors were originally intended for running Windows CE. However, there are working kernels with basic drivers for Sharp Mobilon and the Compaq C-Series. Support for more devices is under construction. The code is part of the Linux VR project and as such more information can be found at http://linux-vr.org/.
The Netpower 100 is apparently an Acer PICA in disguise. It should therefore be supported but this is untested. If there is a problem then it is probably the machine detection.
The Nintendo 64 is R4300 based game console with 4mb RAM. Its graphics chips were developed by Silicon Graphics for Nintendo. Right now this port has pipe dream status and will continue to be in that state until Nintendo decides to publish the necessary technical information. The question remains as to whether this is a good idea.
This machine is very similar to the Indy; the difference is that it doesn't have a keyboard and a GFX card but has an additional SCSI WD33C95 based adapter. This WD33C95 hostadapter is currently not supported.
This machine is only being mentioned here because occasionally people have confused it with Indys or the Indigo 2. The Indigo is a different, R3000 based architecture however and not yet unsupported.
This machine is the successor to the Indigo and is very similar to the Indy. It is now supported, however it is lacking in several areas. You will have to use serial console. If you have a Indigo2 and still want to run Linux on it, contact either Florian Lohoff (flo@rfc822.org) or Klaus Naumann (spock@mgnet.de) .
The Indy is currently the only (mostly) supported Silicon Graphics machine. The only supported graphics card is the Newport card aka ``XL'' graphics. The Indy is available with a large number of CPU options at various clock rates all of which are supported. There's also a X server available now written by Guido Guenther (guido.guenther@gmx.net). If you're able to use the Newport console on your Indy it should be possible to also use this X server. It's based on XFree86 4.0 and currently running at snail speed but seems to work quite ok. If you want to try it take a look at http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/ .
On bootup the kernel on the Indy will report available memory with a message like
Memory: 27976k/163372k available (1220k kernel code, 2324k data)The large difference between the first pair of numbers is caused by a 128mb area in the Indy's memory address space which mirrors up to the first 128mb of memory. The difference between the two numbers will always be about 128mb and does not indicate a problem of any kind. Kernels since 2.3.23 don't count this 128mb gap any longer.
Several people have reported these problems with their machines after upgrading them typically from surplus parts. There are several PROM versions for the Indy available. Machines with old PROM versions which have been upgraded to newer CPU variants like a R4600SC or R5000SC module can crash during the self test with an error message like
Exception: <vector=Normal> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> Cause register: 0x4000<CE=0,IP7,EXC=INT> Exception PC: 0xbfc0b598 Interrupt exception CPU Parity Error Interrupt Local I/O interrupt register 1: 0x80 <VR/GIO2> CPU parity error register: 0x80b<B0,B1,B3,SYSAD_PAR> CPU parity error: address: 0x1fc0b598 NESTED EXCEPTION #1 at EPC: 9fc3df00; first exception at PC: bfc0b598In that case you'll have to upgrade your machine's PROMs to a newer version or go back to an older CPU version. Usually R4000SC or R4400SC modules should work in that case. Just to be clear, this is a problem which is unrelated to Linux. It's only mentioned here because several Linux users have asked about it.
Old PROM versions don't know about the ELF binary format which the Linux kernel uses, that is can't boot Linux directly. The preferable solution for this is of course a PROM upgrade. Alternatively you can use Sash of IRIX 5 or newer to boot the kernel. Sash knows how to load ELF binaries and doesn't care if it's an IRIX or Linux kernel. Simply type ``Sash'' to the prom monitor. You should get another shell prompt, this time from Sash. Now launch Linux as usual.
Sash can read EFS or XFS filesystems or read the kernel from bootp / tftp. That means if you intend to use Sash for booting the kernel from local disk you'll still have to have a minimal IRIX installation on your system.
On bootup the `Memory: ...' message on an Indy says that there is 128mb of RAM reserved. That is ok; just like the PC architecture has a gap in its memory address space between 640kb and 1024kb, the Indy has a 128mb-sized area in its memory map where the first 128mb of its memory is mirrored. Linux knows about it and just ignores that memory, thus this message.
Ralf Bächle (ralf@gnu.org) and a team of SGI employees are currently working on a port to the Origin 200. While still in it's early stages it's running in uniprocessor and multiprocessor mode and has drivers for the builtin IOC3 Ethernet and SCSI hostadapters. The code is available in the Linux/MIPS CVS tree.
The Onyx 2 is basically an Origin 2000 with additional graphics hardware. As of now about Linux support for the graphics hardware has not yet been decided. Aside of that Linux should run just as well as on a normal headless Origin 2000 configuration.
This is a very old series of R3000 SMP systems. There is no hardware documentation for these machines, few of them exist anymore, the hardware is weird. In short, chances that Linux will ever run on them are approximating zero. Not that we want to discourage takers ...
Make sure the kernel you're using includes the appropriate driver for a serial interface and serial console. Set the console ARC environment variable to either the value d1 or d2 for Indy and Challenge S depending on which serial interface you're going to use as console.
If you have the problem that all kernel messages appear on the serial console on bootup but everything is missing from the point when init starts, then you probably have the wrong setup for your /dev/console. You can find more information about this in the Linux kernel source documentation; it's in /usr/src/linux/Documentation/serial-console.txt if you have the kernel source installed.
At this time no other Silicon Graphics machine is supported. This also applies to the very old Motorola 68k based systems.
The Sony Playstation is based on an R3000 derivative and uses a set of graphics chips developed by Sony themselves. While the machine in theory would be capable of running Linux, a port is difficult, since Sony so far hasn't provided the necessary technical information. This still leaves the question of whether the port would be worthwhile. So in short, nothing has happened yet even though many people have shown their interest in trying Linux on a Playstation so far.
In contrast to the RM200 (see below) this machine has EISA and PCI slots. The RM200 is supported with the exception of the availability of the onboard NCR53c810A SCSI controller.
If your machine has both EISA and PCI slots, then it is an RM200C; please see above. Due to the slight architectural differences of the RM200 and the RM200C this machine isn't currently supported in the official sources. Michael Engel (engel@numerik.math.uni-siegen.de) has managed to get his RM200 working partially but the patches haven't yet been included in the official Linux/MIPS sources.
The RM300 is technically very similar to the RM200C. It should be supported by the current Linux kernel, but we haven't yet received any reports.
The RM400 isn't supported.
This machine is a OEM variant of the SGI Indigo and therefore also still unsupported.
The Algorithmics P4032 port is at the time of this writing still running Linux 2.1.36.
The P5064 is basically an R5000-based 64bit variant of the P4032. A port is ongoing.
During the late 80's and the early 90's Digital (now Compaq) built MIPS based Workstations named DECstation resp. DECsystem. Other x86 and Alpha based machines were sold under the name DECstation, but these are obviously not subject of this FAQ. Support for DECstations is still under development, started by Paul M. Antoine. These days most of the work is done by Harald Koerfgen (Harald.Koerfgen@home.ivm.de) and others. On the Internet, DECstation-related information can be found at http://decstation.unix-ag.org/.
The DECstation family ranges from the DECstation 2100 with an R2000/R2010 chipset at 12 Mhz to the DECstation 5000/260 with a 60 MHz R4400SC.
The following DECstation models are actively supported:
These DECstation models are orphaned because nobody is working on them, but support for these should be relatively easy to achieve.
The other members of the DECstation family, besides the x86 based ones, should be considered as VAXen with the CPU replaced by a MIPS CPU. There is absolutely no information available about these machines and support for them is unlikely to happen ever unless the VAXLinux port comes to a new life. These are:
These two machines are almost completely identical. Back during the ACE initiative Olivetti licensed the Jazz design and marketed the machine with Windows NT as OS. MIPS Computer Systems, Inc. itself bought the Jazz design and marketed it as the MIPS Magnum 4000 series of machines. Magnum 4000 systems were marketed with Windows NT and RISC/os as operating systems.
The firmware on the machine depended on the operating system which was installed. Linux/MIPS supports only the little endian firmware on these two types of machines. Since the M700-10 was only marketed as an NT machine all M700-10 machines have this firmware installed. The MIPS Magnum case is somewhat more complex. If your machine has been configured big endian for RISC/os then you need to reload the little endian firmware. This firmware was originally included on a floppy with the delivery of every Magnum. If you don't have the floppy anymore you can download it via anonymous ftp from ftp://ftp.fnet.fr.
It is possible to reconfigure the M700 for headless operation by setting the firmware environment variables ConsoleIn and ConsoleOut to multi()serial(0)term(). Also try the command listdev which will show the available ARC devices.
In some cases, like where the G364 graphics card is missing but the console is still configured to use normal graphics it will be necessary to set the configuration jumper JP2 on the board. After the next reset the machine will reboot with the console on COM2.
The Mips Magnum 4000SC is the same as a Magnum 4000 (see above) with the exception that it uses an R4000SC CPU.
The R2000 is the original MIPS processor. It's a 32 bit processor which was clocked at 8MHz back in '85 when the first MIPS processors came to the market. Later versions were clocked faster: for instance, the R3000 is a 100% compatible redesign of the R2000, just clocked faster. Because of their high compatibility, where this document mentions the R3000, in most cases the same facts also apply to the R2000. The R3000A is basically an R2000 plus an R3010 FPU and 64k cache running at up to 40Mhz and integrated into the same chip.
Harald Koerfgen (Harald.Koerfgen@home.ivm.de) and Gleb O. Raiko (raiko@niisi.msk.ru) have both independently worked on patches for R3000 processors. The work has been merged and is integrated into the official Linux/MIPS sources since July 1999. Actually Linux supports R3000 processors including some derivatives like the R3081 and the TMPR3912/PR31700
Sometimes people confuse the R6000, a MIPS processor, with RS6000, a series of workstations made by IBM. So if you're reading this in hope of finding out more about Linux on IBM machines you're reading the wrong document.
The R6000 is currently not supported. It is a 32-bit MIPS ISA 2 processor and a pretty interesting and weird piece of silicon. It was developed and produced by a company named BIT Technology. Later NEC took over the semiconductor production. It was built in ECL technology, the same technology that was and still is being used to build extremely fast chips like those used in some Cray computers. The processor had its TLB implemented as part of the last couple of lines of the external primary cache, a technology called TLB slice. That means its MMU is substantially different from those of the R3000 or R4000 series, which is also one of the reasons why the processor isn't supported.
Linux supports many of the members of the R4000 family. Currently these are R4000PC, R4400PC, R4300, R4600, R4700, R5000, R5230, R5260. Many others are probably working as well.
Not supported are R4000MC and R4400MC CPUs (that is multiprocessor systems) as well as R5000 systems with a CPU controlled second level cache. This means where the cache is controlled by the R5000 itself in contrast to some external external cache controller. The difference is important because, unlike other systems, especially PCs, on MIPS the cache is architecturally visible and needs to be controlled by software.
Special credit goes to Ulf Carlsson (ulfc@engr.sgi.com) who provided the CPU module for debugging the R4000SC / R4400SC support.
The R8000 is currently unsupported partly because this processor is relatively rare and has only been used in a few SGI machines, partly because the Linux/MIPS developers don't have such a machine.
The R8000 is a pretty interesting piece of silicon. Unlike the other members of the MIPS family it is a set of seven chips. It's cache and TLB architecture are pretty different from the other members of the MIPS family. It was born as a quick hack to get the floating point crown back to Silicon Graphics before the R10000 is finished.
The R10000 is supported as part of the mips64 kernel which currently is supported on the IP22 (SGI Indy, Challenge S and Indigo 2) and Origin.
Due to the very hard to handle way this processor works in non-cachecoherent systems it's probably still taking some time until we support this processor in such systems. As of today these systems are the SGI O2 and Indigo
As the name say these are IBM machines which are based on the RS6000 processor series and as such they're not subject of the Linux/MIPS project. People frequently confuse the IBM RS6000 with the MIPS R6000 architecture. However the Linux/PPC project might do so. Checkout http://www.linuxppc.org/ for further information.
As the name already implies this machine is a member of Digital Equipment's VAX family. It's mentioned here because people often confuse it with Digital's MIPS based DECstation family due to the similar type numbers. These two families of architectures share little technical similarities. Unfortunately the VaxStation, like the entire VAX family, is currently unsupported.
This is actually an x86 based system, therefore not covered by this FAQ. But to make your search for answers simple, here it is. Ken Klingman (kck@mailbox.esd.sgi.com) posted on January 17, 1999 to SGI's Linux mailing list:
We are working on it. We're actually close to getting the base level system support into the 2.2 release. Software-only X and OpenGL should follow relatively shortly, but hardware-accelerated OpenGL is still some time off. See www.precisioninsight.com for news about hardware-accelerated OpenGL.For more information see the Documentation/ of Linux kernel versions from 2.2.0 and newer. There is additional information available on the web on http://oss.sgi.com/. Note that the SGI/MIPS and SGI/Intel people are working independently of each other, therefore the sources in the anonymous CVS on oss.sgi.com may or may not work for Intel machines; we don't test this.
These are very old machines, probably more than ten years old by now. As these machines are not based on MIPS processors this document is the wrong place to search for information. However, in order to make things easy, these machines are currently not supported.