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 and with a bit help from . 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 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.
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 is currently no X server available for the Indy; is working on one.
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.
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.
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. The Indigo series is a different architecture however and therefore yet unsupported. announced a university project to port Linux to the Indigo on January 2, 1999.
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.
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.
This is actually an x86 based system, therefore not covered by this FAQ. But to make your search for answers simple, here it is. 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://www.linux.sgi.com/intel/. Note that the SGI/MIPS and SGI/Intel people are working independently of each other, therefore the sources in the anonymous CVS on linus.linux.sgi.com may or may not work for Intel machines; we don't test this.
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 happend 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. 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.
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. It's not yet supported but a Linux port will be quite easy.
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 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:
The R2000/R3000 support in the Linux/MIPS kernel is a merge of the DECstation and Baget/MIPS code and isn't yet integrated into the official Linux/MIPS source tree.
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.
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.
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. Support for the R3000 processor is currently in the works by various people. and have both independently worked on patches which haven't yet been integrated into the official Linux/MIPS sources.
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 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. Its cache and TLB architecture is pretty different from the other members of the MIPS family. It was born as a hack to get the floating point crown back to Silicon Graphics before the R10000 is finished.
The R10000 is currently unsupported because the Linux/MIPS developers don't have an R10000 machine.
  |