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 of 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. The 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 was derived from Linux/MIPS 2.1.56, 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 that 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 porting the Linux/MIPS code to this platform is a good idea.
This machine is very similar to the Indy, the differences are that it doesn't have a keyboard or graphics card, but has an additional SCSI WD33C95-based adapter. This WD33C95 hostadapter is currently not supported.
This machine is only being mentioned here because people have occasionally confused it with Indys or the Indigo 2. The Indigo is a different R3000-based architecture however, and is not yet unsupported.
This machine is the successor to the Indigo and is very similar to the Indy. It is now supported, but is lacking in several areas. You will have to use serial console. If you have an 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, a.k.a. ``XL'' graphics. The Indy is available with a large number of CPU options at various clock rates, all of which are supported. There is 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 runs at snail-like speeds, but it seems to work quite well. 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 more.
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 PROM to a newer version, or go back to an older CPU version (usually R4000SC or R4400SC modules should work). Just to be clear, this is a problem which is unrelated to Linux, it is 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, so Linux cannot boot directly. The preferable solution for this is of course a PROM upgrade. Alternatively, you can use Sash for 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, and 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 built-in 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, writing Linux support for the graphics hardware has not yet been done. Aside from 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 even exist anymore, and the hardware is weird. In short, the chances that Linux will ever run on them are approximating zero. Not that we want to discourage any takers ...
Make sure that 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 the console.
If you have the problem that all kernel messages appear on the serial console on boot-up, 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 which is 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, is 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 an interest in running Linux on this system.
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 unsupported.
Algorithmics ( http://www.algor.co.uk/) make a series of single-board computers for MIPS prototyping, and maintain Linux kernels for all of them:
All the boards have common I/O plus ethernet and disk interfaces onboard, with spare PCI slots for adding different controllers. They're highly configurable, so will run with either byte order. All are suitable targets for 64-bit kernels, but (so far) all the Linux work we've done has been using 32-bit code.
They're available, supported and documented with PDF manuals available online, like http://www.algor.co.uk/ftp/pub/doc/p6032-user.pdf for the P-6032.
At the time of writing (November 2000) we are using a 2.2.x kernel; kernel code is shared with the ports being done by people from MIPS Technologies, Inc.). Algorithmics wrote the floating point trap handler and emulator used in this kernel - essential for MIPS CPUs to run floating point operations reliably and correctly.
Algorithmics' kernels and a link to the MIPS userland can be found from a jump page at http://www.algor.co.uk/algor/info/linux.html
You can contact us at Algorithmics.
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 the 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 them 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 ever happen unless the VAXLinux port comes back to 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 the OS. MIPS Computer Systems, Inc. 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 the 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 example, the R3000 is a 100% compatible redesign of the R2000 which is 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 all integrated onto 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 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, then you're reading the wrong document.
The R6000 is currently not supported. It is a 32-bit MIPS ISA 2 processor; 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 using 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 supported as well.
Not supported are the R4000MC and R4400MC CPUs (that is multiprocessor systems), as well as R5000 systems with a CPU-controlled second level cache. This means that the cache is controlled by the R5000 itself, in contrast to some 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, and 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 will probably be some time until we support this processor in such systems. As of today, these systems are the SGI O2 and Indigo
For embedded purposes, there are special derivates of the above CPU available which often lack a full TLB. We don't support those types nor should you ever expect such support to be added.
Hackers may want to take a look at a Linux subset named Microcontroller Linux, or short, ucLinux. This would be supportable on TLB-less processors. Given the litte difference between CPU types with and without TLB, we still recommend that you choose a processor with TLB. It's going to save you a lot of engineering.
In theory, these processors are supportable, especially when applications don't rely on the presence of a FPU. We, however, don't support that yet.
As the name says, these are IBM machines which are based on the RS6000 processor series, and, as such, they're not the subject of the Linux/MIPS project. People frequently confuse the IBM RS6000 with the MIPS R6000 architecture. However, the Linux/PPC project might support these machines. 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. There is some limited Linux support available for the older Visual Workstations. The current series of Visual Workstations is an officially supported SGI product. Please see http://oss.sgi.com and http://www.sgi.com for more information.
These are very old machines, probably more than ten years old by now. As these machines are not based on MIPS processors, and therefore not supported by the Linux/MIPS project, this document is the wrong place to search for information.