<!doctype linuxdoc system>
<!-- $Id: MIPS-HOWTO.sgml,v 1.1 2005/01/18 13:37:51 gferg Exp $ -->
<article>
<title>Linux/MIPS HOWTO
<author>Ralf Bächle, <tt/ralf@gnu.org/
<date>May 12, 2004
<abstract>
This FAQ describes the MIPS port of the Linux operating system, common
problems and their solutions, availability and more. It also tries to
be helpful to other people who might read this FAQ in an attempt to
find information that actually should be covered elsewhere.
</abstract>
<toc>
<sect>The home of the Linux MIPS port<p>
Linux/MIPS is a port of the widespread UNIX clone Linux to the MIPS
architecture. Linux/MIPS runs on a large number of technically very
different systems ranging from small embedded systems to large
desktop machines and servers from SGI and DEC.<p>
Here you will find links to all the resources you need
to work with Linux on MIPS, whether you are starting out getting
Linux running on your own platform, or developing an end user
application or product based on a Linux/MIPS system.
If you are looking for a commercial Linux product with associated
support, take a look at the <ref id="commercial" name="Commercial Linux"> page.
If you have input regarding the contents of these pages, see the
<ref id=documentation name="Documentation"> page for contact info. Webserver
contact is <htmlurl url="mailto:webmaster@linux-mips.org"
name="webmaster@linux-mips.org">.
<p>
<sect>Mailing lists and other net resources<p>
<sect1>Mailing lists<p>
There are two Linux/MIPS-oriented mailing lists:
<descrip>
<tag><em>linux-mips@linux-mips.org</em><p>
This mailing list currently has the most traffic. It is especially of
interest as a good number of active developers are subscribed to this list.
<tag><em>linux-cvs@linux-mips.org</em><p>
This is an announcement only mailing list to which a message for every CVS
commit into linux-mips.org's, CVS archive of the Linux/MIPS community, is
being sent. This allows following the development as it happens.
</descrip>
Subscription to this lists is handled via <htmlurl
url="mailto:ecartis@linux-mips.org" name="Ecartis (ecartis@linux-mips.org)">,
just send an email with the words <em>subscribe <list-name></em>. In
order to unsubscribe, send <em>unsubscribe linux-mips</em>.
Sending the word help will reveal further secrets about the advanced use of
Ecartis. At <url url="http://www.linux-mips.org/ecartis"> you'll also find
a web-based interface to Ecartis.
Note linux-mips.org is using the ECN TCP extension as described in
RFC 3168. The bug is known for years yet still defective firewalls
that are dropping TCP SYN packets with ECN bits set are in use. If you
can reach linux-mips.org yet don't receive any email from any of the
linux-mips.org mailing lists you may have this problem.<p>
<p>The archives for these two lists in UNIX mbox format are located on
ftp.linux-mips.org in /pub/linux/mips/archives. A fully searchable archive
in HTML format of the above lists and some Linux/MIPS related historic
lists can be found at <url url="http://www.linux-mips.org/archives/">.
<sect1>IRC channel.<p>
There is an IRC channel named #mipslinux for Linux/MIPS which may be found on
irc.freenode.net.
<sect>Kernel<p>
The current version of the Linux kernel can be found on
<url url="http://www.kernel.org" name="kernel.org"> and will tend to be
somewhat ahead of the MIPS/Linux version (see CVS below) but behind in some
MIPS-specific regards. Older and more stable versions of the kernel for MIPS
are available for download - see the section on <ref id="distributions"
name="Distributions"> for locations.
<sect1>Anonymous CVS servers.<p>
For those who always want to stay on the bleeding edge, and want to avoid
having to download patch files or full tarballs, we also have an anonymous
CVS server. Using CVS, you can checkout the Linux/MIPS source tree with
the following commands:<p>
<verb>
cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login
(Only needed the first time you use anonymous CVS, the password is "cvs")
cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co <repository>
</verb>
where you insert linux, libc, gdb or faq for <repository>.
There is a mailing list for information on what gets committed to this
repository.
<sect1>Web CVS server.<p>
Via <url url="http://www.linux-mips.org/cvsweb">, you have
direct access to the new Linux/MIPS kernel sources, and a few other projects
hosted in the same CVS archive. The intuitive interface allows you to
follow the development at the click of your mouse.
<sect><label id="distributions">Distributions.<p>
A distribution is a complete collection of kernel, user programs, toolchain
and libraries necessary to get a system up and running. It may include an
install procedure to get the files copied correctly onto the target storage
device. See the READMEs on the links below for more information.
<sect1>Commercial Embedded<p> See the section on <ref id="commercial"
name="commercial"> distributions.
<sect1>RedHat 7.1 based<p> A complete distribution based on RedHat's 7.1,
ported by H.J. Lu, can be found at <url
url="ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.1/">.
<sect1>Maciej W. Rozycki<p> A little-endian only distribution is maintained
by <htmlurl url="mailto:macro@ds2.pg.gda.pl" name="Maciej"> at <url
url="ftp://ftp.ds2.pg.gda.pl/pub/macro/"> or the <url
url="ftp://ftp.rfc822.org/pub/mirror/ftp.ds2.pg.gda.pl/pub/macro/"
name="mirror">.
<sect1>MIPS Technologies<p>
MIPS maintain a version of the above, including complete installable CD-ROM
images, at <url
url="ftp://ftp.mips.com/pub/linux/mips/installation/redhat7.1/">.
<sect1>Debian<p>
A Debian distribution for both little and big endian machines can be found at
<url url="http://www.debian.org/ports/mips/">.
At the time of writing (January 2002) we are using a 2.4 kernel; kernel
code is shared with the ports being done by people from <htmlurl
url="http://www.mips.com" name="MIPS Technologies, Inc.">).
<sect1>MIPS Technologies UK (formerly Algorithmics)<p>
Algorithmics is now part of MIPS Technologies and their Linux work is
now merged with MIPS Technologies (above). The group
wrote the floating point trap handler and emulator used in this
kernel - essential for MIPS CPUs to run floating point operations
reliably and correctly.<p>
MIPS Technologies UK also maintain a GNU <ref id="algorithmics-gcc"
name="toolchain"> and provide both free snapshots and a commercially
supported version - worth thinking about for commercial Linux
developments. You can download the free subset (subject to
registration) from <url
url="http://www.mips.com/products/software_products.html">.
<p>
You can contact the compiler group at <url url="mailto:sde@mips.com">.
<sect>Toolchains<p>
A toolchain is a complete collection of compiler and binutils programs and
can be run either as a cross-compiler, or native on the target (if
performance allows).
<sect1><label id="algorithmics-gcc">MIPS SDE<p>
Not a complete distribution, just a Linux toolchain. But it's a toolchain
built and maintained for MIPS with commercial support available, and free
snapshots.<p>
MIPS Technologies UK maintain their own source tree for the
toolchain components. They resynchronize infrequently with
mainstream GNU releases (which inevitably have bugs for minor
architectures such as MIPS) and focus on providing the most
reliable, best-performing compiler for the largest range of MIPS
CPUs.<p>
This is the same compiler which is at the heart of our
MIPS SDE embedded toolkit. You can now get it in RPM format:
<p>
Native big-endian <url
url="ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.01-1.mips.rpm">;
native little-endian <url url="ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.01-1.mipsel.rpm">;
Linux/386 cross for big-endian target <url url="ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.01-4eb.i386.rpm">;
and Linux/386 cross for little-endian target <url url="ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.01-4.i386.rpm">.
<p>
MTUK would like to hear how well it worked, so contact them on <htmlurl url="mailto:sde@mips.com">.
<sect1>Commercial Embedded<p>
See the section on <ref id="commercial" name="commercial"> distributions -
these all include appropriate toolchain deliverables.
<sect1>H.J. Lu<p>
<htmlurl url="mailto:hjl@lucon.org" name ="H.J. Lu"> distributes a toolchain
as part of his Red Hat 7.1 port. It can be found at <url
url="ftp://ftp.linux-mips.org/linux/mips/redhat/7.1/">.
<sect1>Maciej W. Rozycki<p>
A stable set of toolchain components provided by <htmlurl
url="mailto:macro@ds2.pg.gda.pl" name="Maciej"> can be downloaded from <url
url="ftp://ftp.ds2.pg.gda.pl/pub/macro/"> or the <url
url="ftp://ftp.rfc822.org/pub/mirror/ftp.ds2.pg.gda.pl/pub/macro/"
name="mirror">. This is based on gcc 2.95.3 (patched) and up-to-date
binutils.
<sect1>Dan Kegel<p>
Dan Kegel has a page at <url url="http://kegel.com/crosstool/"> with a
nice script to automatize the build procedure.
<sect>Commercial Linux<p>
<label id="commercial">The following companies provide commercial, supported
Linux/MIPS solutions for the embedded market, on a number of different
platforms.
<itemize>
<item><url url="http://www.mvista.com/" name="MontaVista">
<item><url url="http://www.redhat.com/" name="Red Hat">
<item><url url="http://www.lineo.com/" name="Lineo">
<item><url url="http://www.lynuxworks.com/" name="LynuxWorks">
<item><url url="http://www.timesys.com/" name="TimeSys">
<item><url url="http://www.elinos.com/" name="ELinOS">
</itemize>
<sect>Web resources<p>
<sect1>Webservers<p>
The following webservers are relevant for Linux/MIPS developers.
<descrip>
<tag><url url="http://www.linux-mips.org/"><p>
This server covers most of Linux/MIPS. If you need something chances are
it's already there.<p>
<tag><url url="http://www.mips.com/content/Products/SoftwareTools/"><p>
This sites has MIPS own version of Linux/MIPS based distributions and tools
for their processors and evaluation boards.<p>
<tag><url url="http://www.debian.org/ports/mips/"><p>
This is Debian's MIPS/Linux site.<p>
<tag><url url="http://www.playstation2-linux.com"><p>
This is Sony's Linux/MIPS server for the Playstation 2.
Also in <url url="http://www.ps2linux.com/" name="Japanese">.<p>
<tag><url url="http://www.ltc.com/~brad/mips/mips-cross-toolchain/"><p>
Bradley D. LaRonde's HowTo on building a cross toolchain for MIPS/Linux.<p>
<tag><url url="http://linux.junsun.net/porting-howto/"><p>
Jun Sun's porting guide has some useful information and tips for porting to
new platforms.<p>
</descrip>
<sect1>Anonymous FTP servers.<p>
The primary anonymous FTP servers for Linux/MIPS are
<descrip>
<tag><url url="ftp://ftp.linux-mips.org"><p>
This server should satisfy almost all of your Linux/MIPS related ftp
desires. Really.<p>
<tag><url url="ftp://ftp.mips.com/pub/linux"><p>
This is the server of MIPS, Inc. itself. Among other things it offers a
recent Redhat-based distribution and a support area for MIPS' evaluation
boards.<p>
<tag><url url="ftp://ftp.ds2.pg.gda.pl/pub/macro/"><p>
Maciej W. Rozycki's FTP server.<p>
</descrip>
<sect1>The Linux-VR project<p>
<label id="linux-vr">
The Linux VR project has worked on support for a variety of NEC VR41xx,
Toshiba TMPR39xx and Philips PR3170-based systems. Most of this code has
been merged into the Linux/MIPS CVS tree. The projects web pages which
used to be at <em>www.linux-vr.org</em> are now archived at
<url url="http://www.linux-mips.org/linux-vr/">.<p>
The Linux-VR CVS archive is at
<url url="http://www.linux-mips.org/cvsweb/linux-vr">; it can also be
checked out by CVS.
<sect>Supported Hardware platforms
<label id="hardware-platforms">
<p>Check also the section on <ref id="cpus" name="Supported CPUs"> for which
processor types are supported,
if you are using a platform for which multiple CPU options exist.
<p>See below for the following categories of platforms
<itemize>
<item><ref id="activedev" name="Actively supported development boards">
<item><ref id="active" name="Actively supported workstations">
<item><ref id="legacy" name="Legacy only / unsupported">
<item><ref id="never" name="Never to be supported">
</itemize>
<sect1><label id="activedev">Actively supported development boards<p>
The following list covers development boards for which there is active
support for the port, and which are maintained continuously. Expect these
ports to work reliably. Refer also the the section on <ref id="commercial"
name="commercial Linux ports"> - these companies may provide additional
hardware support.
<sect2>Broadcom BCM91250A
<p>An evaluation board for the SiByteTM BCM1250 dual processor SOC (system on
chip) and is implemented in the standard ATX form factor. A high performance
board. See <url url="http://www.broadcom.com/"> for details.
<sect2>MIPS Malta<p>
The MIPS Technologies Malta board and all its CPU options are supported. See
the Developers pages under <url url="http://www.mips.com/"
name="www.mips.com">.
<sect1><label id="active">Actively supported workstations<p>
<p>
The following list covers machines for which there is active support for
the port, and which are maintained continuously. Expect these ports to work
reliably.
<sect2>Cobalt Qube and Raq<p>
The Cobalt Qube product series are low cost headless server systems
based on a IDT R5230. Sun has announced the end of life for the MIPS
based Qube and Raq systems but other Linux distributions are supported.
Biggest problem with this port is a limit of about 700kB for the size of
the boot image. This is a limitation of the firmware and is beginning to
seriously bite until somebody develops a workaround.
<sect2>DECstation series<p>
The following DECstation models are actively supported:
<itemize>
<item>2100, codename PMAX
<item>5000/xx (Personal DECstation), codename MAXine
<item>5000/1xx, codename 3MIN
<item>5000/200, codename 3MAX
<item>5000/2x0, codename 3MAX+
<item>5900/2x0 (identical to the 3MAX+).
</itemize>
These days, most of the work is done by
<htmlurl url="mailto:hkoerfg@web.de"
name="Harald Koerfgen (hkoerfg@web.de)"> and others. On the
Internet, DECstation-related information can be found at
<url url="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. See the
section on Legacy Platforms below for other DEC machines. Note: Other x86 and
Alpha-based machines were also sold under the name DECstation.
<sect2>Silicon Graphics Indy<p>
The Indy is currently the best supported Silicon Graphics machine.
<sect2>Silicon Graphics Origin 200 and 2000<p>
<htmlurl url="mailto:ralf@gnu.org" name="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.<p>
<sect2>Sony Playstation and Playstation 2<p>
Sony Computer Entertainment have produced a port of Linux for the
PlayStation 2 which was released in 2002. For further details and
information about obtaining Linux for PlayStation 2, please visit
<url url="http://playstation2-linux.com">.
Another site in Japanese can be found at <url url="http://www.ps2linux.com">.
The older Sony Playstation is based on an R3000 derivative and uses a set of
graphics chips developed by Sony themselves. Sony doesn't support Linux for
this system but apparently a Russian group has released a Linux port on
www.runix.ru, now <url url="http://www.runix.biz/">.
<sect1><label id="legacy">Unsupported / Legacy support only<p>
The platforms listed here may once have been supported, but there may not have
been active maintenance for them. Expect problems with these platforms, and
consult the mailing list for information on them.
<sect2>Acer PICA<p>
The <em>Acer PICA</em> is derived from the <em>Mips Magnum 4000</em> 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.
<sect2>Baget/MIPS series<p>
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
<htmlurl url="mailto:rajko@mech.math.msu.su" name="Gleb Raiko
(rajko@mech.math.msu.su)"> and
<htmlurl url="mailto:vroganov@msiu.ru"
name="Vladimir Roganov (vroganov@msiu.ru)">
with a bit of help from <htmlurl url="mailto:zimin@msiu.ru"
name="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.<p>
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 <url
url="http://decstation.unix-ag.org/">.
<sect2>DECstation
<p>These DECstation models are orphaned because nobody is working on them,
but support for them should be relatively easy to achieve.
<itemize>
<item>3100, identical to the 2100 except the R2000A/R2010A @ 16 MHz
<item>5100, codename MIPSMATE, almost identical to the 2100 but with an
R3000/R3010 chipset.
</itemize>
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:
<itemize>
<item>5400, codename MIPSFAIR
<item>5500, codename MIPSFAIR2
<item>5800, codename ISIS
</itemize>
<sect2>MIPS Magnum 4000 / Olivetti M700-10<p>
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.<p>
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
<url url="ftp://ftp.linux-mips.org/pub/linux/mips/misc/magnum-4000">.<p>
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 <sl>listdev</sl> 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.
<sect2>MIPS Magnum 4000SC<p>
The MIPS Magnum 4000SC is the same as a Magnum 4000 (see above) with
the exception that it uses an R4000SC CPU.
<sect2>NEC machines<p>
The NEC uniprocessor machines are OEM <em>Acer PICA</em> 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.
<sect2>Netpower 100<p>
The <em>Netpower 100</em> is apparently an <em>Acer PICA</em> in disguise.
It should therefore be supported but this is untested. If there is a
problem then it is probably the machine detection.
<sect2>Nintendo 64<p>
The <em>Nintendo 64</em> 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.
<sect2>Phillips Nino<p>
Linux 2.4 supports the Nino. Support was removed from 2.5 at the request
of it's maintainer who does not want to maintain it anymore.
<sect2>Silicon Graphics Challenge S<p>
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.
<sect2>Silicon Graphics Indigo<p>
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 yet unsupported.
<sect2>Silicon Graphics Indigo2<p>
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 <htmlurl url="mailto:flo@rfc822.org"
name="Florian Lohoff (flo@rfc822.org)">.
<sect2>Silicon Graphics Onyx 2<p>
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.<p>
<sect2>Silicon Graphics Power Series<p>
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 ...
<sect2>SNI RM200<p>
If your machine has both EISA and PCI slots, then it is an RM200C (please
see below). Due to the slight architectural differences of the RM200 and
the RM200C, this machine isn't currently supported in the official sources.
<htmlurl url="mailto:engel@numerik.math.uni-siegen.de"
name="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.
<sect2>SNI RM200C<p>
In contrast to the RM200 (see above), this machine has EISA and PCI slots.
This machine was somewhat supported in 2.0 and 2.1, then nobody took care of
this port for a long time until recently. So it's not usable in 2.2 and
2.4 but works again in 2.6.
<sect2>SNI RM300C<p>
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.
<sect2>SNI RM400<p>
The RM400 isn't supported.
<sect2>SNI RW320<p>
This machine is a OEM variant of the SGI Indigo and therefore also
unsupported.
<sect2>NEC VR41xx-based platforms<p>
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. The
<ref id="linux-vr" name="Linux-VR"> has developped support for these
systems.
<sect2>Toshiba TMPR39xx/Philips PR31700 platforms<p>
Similar to the VR41xx, devices with these processors were originally
intended for running Windows CE. However, there are working kernels
with basic drivers for <em>Sharp Mobilon</em> and the <em>Compaq
C-Series</em>. The <ref id="linux-vr" name="Linux-VR"> has developped
support for these systems.
<sect1><label id="never">Hardware we're never going to support<p>
<sect2>IBM RS6000<p>
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 <url url="http://www.penguinppc.org/"> for further information.
<sect2>VaxStation<p>
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. These
systems are subject of the Linux/VAX project at
<url url="http://www.linux-vax.org/">.
<sect2>SGI VisPC<p>
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 <url url="http://oss.sgi.com"> and
<url url="http://www.sgi.com"> for more information.
<sect2>Motorola 68k-based machines<p>
Examples are the SGI Iris 1000, Iris 2000 and Iris 3000
series. As these machines are not based on MIPS processors, and therefore
not subject of the Linux/MIPS project. In other words if you're looking into
this document for more information you're lookin at the wrong place. Also
these are <sl>very</sl> old machines, much more than ten years old by now.
As such chances for the to ever be supported a small. For more on Linux on
Motorola 68000 based systems see <url url="http://www.linux-m68k.org">.
<sect><label id="cpus">Supported CPUs<p>
<label id="supported-cpus">
<sect1>MIPS32 architecture<p>
All CPUs and cores that conform to the MIPS32 specification, including the
MIPS 4K series, Alchemy Au1000/1500.
<sect1>MIPS64 architecture<p>
All CPUs and cores that conform to the MIPS64 specification, including the
MIPS 5K and 10K series, Sibyte SB1 core / SB1250 SOC.
<sect1>R2000, R3000 family<p>
Linux supports the R2000, R3000 family and many processors that were derived
from these the two original MIPS processors such as the R3081.
<sect1>R4000 family<p>
Linux supports many of the members of the R4000 family. Currently, these
are: R4000PC, R4400PC, R4300, R4600, R4700.<p>
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.<p>
Special credit goes to <htmlurl url="mailto:grim@zigzegv.ml.org"
name="Ulf Carlsson (ulfc@engr.sgi.com)"> who provided the CPU module for
debugging the R4000SC / R4400SC support.
There is some confusion about version numbering of R4000 and R4400 CPUs
on SGI systems. These two processor types are basically identical with the
main difference being the R4000 only having primary caches of each 8kb
while the R4400 has twice that. Consequently these two processors do
identify themselves both as type 4 in the c0_PrId register but a different
version number while marketing decieded to market the somewhat improved
R4400 as a great and new product. R4000 processors have version numbers upto
3.0; R4400 processors do identify themselves as version 4.0 and newer.
As a consequence of the R4400 being sold as new product they also started
counting the marketing version numbers again at 1.0. The IRIX <em>hinv</em>
command uses the hardware version numbers while Linux in the hope to minimize
the confusion is using marketing's version numbers that is the Linux version
numbers are consistent with those used by the the MIPS literature such as
processor errata.
<sect1>R5000 family<p>
The R5000 and many similar family members such R5230 and R5260 are supported
by Linux. Support include support for the internal second level cache
controller as well as the external cache controllers used by the SGI IP22.
<sect1>R6000<p>
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.<p>
The R6000 is currently not supported. It is a 32-bit MIPS ISA 2 processor;
apretty interesting and weird piece of silicon. It was developed and
produced by a company named <sl>BIT Technology</sl>. 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 <sl>TLB slice</sl>. 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.
<sect1>RM7000 family<p>
The RM7000 and some similar family members are supported by Linux
including support for tertiary caches.
<sect1>R8000<p>
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.<p>
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.
<sect1>R10000<p>
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.<p>
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 <p>
<sect1>Processors without TLB<p>
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.<p>
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 little 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.
<sect1>Processors with partial or no FPU<p>
Linux/MIPS version 2.4 and later feature a full FPU emulation and therefore
can support these processors while maintaining the full binary compatibility
to fpu-full versions.
<sect>Technical FAQ
<sect1>Reporting bugs<p>
Before reporting a bug please make sure the answer to your problem isn't
already in this document. You may also want to use the search engine at
<url url="http://www.linux-mips.org/archives/linux-mips"> to search the
mailing list archives for references to your problem.<p>
If this all didn't turn up anything, it seems time to write a bug report.
Inexperienced kernel bug reporters should read
<htmlurl name="REPORTING-BUGS"
url="http://www.linux-mips.org/cvsweb/~checkout~/linux/REPORTING-BUGS">
(since Linux 2.1 this file ships as part of the kernel) to ensure the bug
report contains all the information needed. In particular the step of
decoding Ooops messages is important; without it's hard if possible at all to
make sense from the numbers in the register dump. For most problems it's
important to know exactly what system you're using. Remember a system
consists of more than just a processor and MIPS systems tend to differ much
more than Intel systems. In general you should not post large files such
as System.map or others until you've been explicitly asked to. Even
if you think you've discovered a generic kernel bug you may still want to
cc linux-mips@linux-mips.org, just in case.
<sect1>Installation of Linux/MIPS and common problems.<p>
<sect2>NFS booting fails.<p>
Usually, the reason for this is that people have unpacked the tar archive
under IRIX, not Linux. Since the representation of device files over NFS is
not standardized between various Unices, this fails. The symptom is that
the system dies with the error message ``Warning: unable to open an initial
console.'' right after mounting the NFS filesystem.<p>
For now, the workaround is to use a Linux system (doesn't need to be MIPS)
to unpack the installation archive onto the NFS server. The NFS server
itself may be any type of UNIX.<p>
<sect2>Kernel doesn't compile.<p>
Not all machines supported by Linux/MIPS are equally well maintained; in
general those that are used by more users experience more scrutiny and
therefore are better maintained.<p>
Kernels downloaded from kernel.org in general don't have uptodate MIPS
support so they may not compile at all or work as well as those from
linux-mips.org - where optimal MIPS support is the only focus.<p>
<sect2>Self-compiled kernels crash when booting.<p>
When I build my own kernel, it crashes. On an Indy the crash message looks
like the following (the same problem hits other machines as well but may
look completely different):
<verb>
Exception: <vector=UTLB Miss>
Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x881385cc, Exception RA: 0x88002614
exception, bad address: 0x47c4
Local I/O interrupt register 1: 0x80 <VR/GIO2>
Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
arg: 7 8bfff938 8bfffc4d 880025dc
tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614
PANIC: Unexpected exception
</verb>
This problem is caused by a still unfixed bug in Binutils newer than
version 2.7. As a workaround, change the following line in
arch/mips/Makefile from:
<verb>
LINKFLAGS = -static -N
</verb>
to:
<verb>
LINKFLAGS = -static
</verb>
<sect2>Booting the kernel on the Indy fails with PROM error messages<p>
<verb>
>> boot bootp()/vmlinux
73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960
Setting $netaddres to 192.168.1.5 (from server deadmoon)
Obtaining /vmlinux from server deadmoon
Cannot load bootp()/vmlinux
Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.
</verb>
This problem only happens for Indys with very old PROM versions which cannot
handle the ELF binary format which Linux uses. A solution for this problem
is in the works.
<sect2>IP22 has forgotten it's ethernet address<p>
IP22 uses the Dallas DS1286 RTC chip to store time and firmware variables.
This chip contains a builtin battery for ten years but by now this decade
is almost over and experience has shown that some of these RTC batteries
have a much shorter battery life, so the RTCs start becoming forgetful.
Software may also accidentally have overwritten the RTC's content.
If you have determined that a defective RTC chip is the cause of the
problem you can get a new RTC from <url url="http://www.maxim-ic.com/"> or
other sources. Be paranoid, make sure you don't get a part that has been
sitting on a shelf for long years.
This is how to reprogram the RTC chip. Assuming your ethernet address is
aa:bb:cc:dd:ee:ff
<verb>
fill -w -v 0xaa 0xbfbe04e8
fill -w -v 0xbb 0xbfbe04ec
fill -w -v 0xcc 0xbfbe04f0
fill -w -v 0xdd 0xbfbe04f4
fill -w -v 0xee 0xbfbe04f8
fill -w -v 0xff 0xbfbe04fc
</verb>
With this command you can verify the content of the chip's NVRAM:
<verb>
dump -w -x 0xbfbe04e8
</verb>
Note this will print each byte of the MAC address repeated four times; this
is normal an due to the way the chip is used in the Indy.
The MAC address is also the system's serial number, so software licenses
under IRIX might be bound to it. Also the ethernet standards specify
certain meanings for certain values of the 48-bit address. Therefore you
should reprogramm the old ethernet address. You may find the MAC address
on the sticker on the machine. Below a bar code this sticker only contains
a 12 digit hexadecimal number; it's typically located on the backside
between the parallel port and and SCSI connectors on the left side and the
power supply on the right side. In case this sticker has been lost, you
probably also have the number somewhere in the bootmessages of Linux
archived by syslogd or maybe a bootpd or dhcpd config file.
If you need to reprogram the ethernet address you will almost certainly
have lost all other NVRAM settings, use the PROM shell's setenv -p command
for that.
<sect2>Where can I get the little endian firmware for my RM200 C?<p>
SNI's system can be operated in both big and little endian modes. At this
time, Linux/MIPS only supports the little endian firmware. This is somewhat
unlucky since SNI hasn't shipped that firmware for quite some time, since
they dropped Windows NT.
When running in big endian mode, the firmware looks similar to an SGI Indy
which is already supported, therefore fixing the SNI support will be
relatively easy. Interested hackers should contact <htmlurl
url="mailto:ralf@gnu.org" name="Ralf Bächle (ralf@gnu.org)">.
<sect2>ld dies with signal 6<p>
<verb>
collect2: ld terminated with signal 6 [Aborted]
</verb>
This is a known bug in older binutils versions. You will have to upgrade to
at least binutils 2.8.1 plus very current patches.
<sect2>Missing ELF support in some PROM versions<p>
Old IP22 PROM versions don't know about the ELF binary format which the Linux
kernel normally uses, so Linux cannot boot directly. This results in error
messages similar to this one:
<verb>
>> boot -f linux root=/dev/sda1
Cannot load scsi(0)disk(1)rdisk(0)partition(8)/linux.
Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.
Unable to load linux: ``linux'' is not a valid file to boot.
>>
</verb>
The preferable solution for this is of course a PROM upgrade but that isn't
available for all systems.<p>
For systems which still have the sash of IRIX 5 installed it is alternativly
possible use Sash 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'll get another shell prompt, this time from Sash.
Now launch Linux as usual.<p> Sash can read EFS or XFS filesystems or read
the kernel from BOOTP / TFTP.<p>
Using the elf2ecoff tool that is shipping with the kernel source you can
convert an ELF binary into ECOFF. Or when building a kernel just run the
``make vmlinux.ecoff'' which will produce an ECOFF kernel.
<sect2>My machine doesn't download the kernel when I try to netboot<p>
This problem affects the ARC firmware on SNI RM200 and SGI IP22.<p>
The boot client is replying to the BOOTP packets (may be verified using a
packet sniffer like tcpdump or ethereal), but doesn't download the kernel
from your BOOTP server. This happens if your boot server is running a kernel
of the 2.3 series or higher. The problem may be circumvented by doing a
"echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc" as root on the boot server.
<sect2>The kernel download from the TFTP server stops and times out<p>
This may happen if the TFTP server is using a local port number of 32768 or
higher which usually happens if the TFTP server is running Linux 2.3 or
higher. This problem may be circumvented by doing a "echo 2048 32767 >
/proc/sys/net/ipv4/ip_local_port_range" on the server.
<sect2>Bug in DHCP version 2<p>
When using DHCP version 2 you might see the following problem: Your machines
receives it's BOOTP reply 3 times but refuses to start TFTP. You can fix
this by doing a "unsetenv netaddr" in the PROM command monitor before you
boot your system. DHCP version 3 fixes that problem.
<sect2>When booting I get: Warning: unable to open an initial console.<p>
This problem has two possible solutions. First make sure you actually have
a driver for the console of your system configured. If this is the case and
the problem persists you probably got victim of a widespread bug in Linux
distributions and root filesystems out there. The console of a Linux
systems should be a character device of major id 5, minor 1 with permissions
of 622 and owned by user and group root. If that's not the case, cd to the
root of the filesystem and execute the following commands as root:
<verb>
rm -f dev/console
mknod --mode=622 dev/console
</verb>
You can also do this on a NFS root filesystem, even on the NFS server
itself. However note that the major and minor ids are changed by NFS,
therefore you must do this from a Linux system even if it's only a NFS
client or the major / minor ID might be wrong when your Linux client boots
from it.
<sect2>Is IRIX required for installation on SGI systems?<p>
Various descriptions of the installation procedure use IRIX in order to
partition disks. This was required at the time of their writing as there
were no native partiting tools available. Now disks can be partitioned
using the IRIX disklabel mode which can be selected in the expert menu of
newer fdisk versions or GNU Parted. The volume header can be manipulated
using dvhtool. Note dvhtool usage is different from IRIX.<p>
IRIX as secondary operating systems can still be handy as it may reduce the
need to fiddle with ramdisks or nfs-root during installation. Just one word
of warning though: Be careful to not point IRIX fx(8) to disks that don't
don't contain an IRIX disklabel if you want to retain the content - IRIX may
<em>damage</em> the content of that disk without asking!
<sect2>Can IRIX and Linux be installed on the same system<p>
Yes. Just make sure you read the warning about IRIX's fx(8) in above
paragraph.
<sect2>Insmod complains about the _gp_disp symbol being undefined<p>
_gp_disp is a magic symbol used with PIC code on MIPS. Be happy, this error
message saved you from crashing your system. You should use the same
compiler options to compile a kernel module as the kernel makefiles do. In
particular the options <em>-mno-pic -mno-abicalls -G 0</em> are important.
<sect2>Serial console on SGI machines<p>
Make sure that the kernel you're using includes the appropriate driver for a
serial interface and serial console. Set the <em>console</em> ARC
environment variable to either the value <em>d1</em>, or <em>d2</em> for
Indy and Challenge S depending on which serial interface you're going
to use as the console.<p>
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.
<sect2>Strange amounts of available memory on SGI<p>
On bootup, the kernel on the Indy will report available memory with a
message like:
<verb>
Memory: 27976k/163372k available (1220k kernel code, 2324k data)
</verb>
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.
<sect2>Indy PROM related problems<p>
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:
<verb>
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: bfc0b598
</verb>
In 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.<p>
<sect2>Why is so much memory reserved on my Indy?<p>
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.<p>
<sect1>Milo<p>
Milo is the boot loader used to boot the little endian MIPS systems with ARC
firmware, currently the Jazz family and the SNI RM 200. While Milo uses
the same name and has a similar purpose to the Alpha version of Milo, these
two Milos have nothing else in common. They were developed by different
people, don't share any code, and work on different hardware platforms. The
fact that both have the same name is just a kind of historic ``accident''.<p>
The need for Milo has been eliminated for all ARC platforms except the RM200C
due to it's unusual firmware behavior. On all other platforms an ECOFF or
often on more modern firmware also an ELF kernel can be started directly
without the need for Milo or an equivalent. On the RM200C Milo 0.27.1 is
still required to boot the kernel.<p>
<sect2>Building Milo<p>
The building procedure of Milo is described, in detail, in the README files
in the Milo package. Since Milo has some dependencies to kernel header
files which have changed over time, Milo often cannot be built easily.
However, the Milo distribution includes binaries for both Milo and Pandora.
Building Milo is not trivial; unless you want to modify Milo yourself the
urgent recommendation is to use the binaries shipping in the Milo
tarball.<p>
<sect2>Pandora<p>
Pandora is a simple debugger which was primarily developed in order to
analyze undocumented systems. Pandora includes a disassembler, memory dump
functions, and more. If you only want to use Linux, then there is no need
to install Pandora, despite its small size.
<sect1>Loadable Modules<p>
Using modules on Linux/MIPS is quite easy. It should work as expected for
people who have used the feature on other Linux systems. If you want to run
a module-based system, then you should have at least kernel version 980919,
and modutils newer than version 2.1.121 installed. Older versions won't
work.
<sect1>How do I set up a cross-compiler?<p>
<sect2>Available binaries<p>
The easiest way to setup a cross-compiler is to just download the binaries
from <url url="ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/">.
Serious, over the 8 years of Linux/MIPS history this has been shown to be
biggest problem many users have been facing with Linux/MIPS.
For Linux/i386 hosts and big endian targets, these are the packages:
<verb>
binutils-mips-linux-2.13.2.1-1.i386.rpm
egcs-c++-mips-linux-1.1.2-4.i386.rpm
egcs-g77-mips-linux-1.1.2-4.i386.rpm
egcs-libstdc++-mips-linux-2.9.0-4.i386.rpm
egcs-mips-linux-1.1.2-4.i386.rpm
egcs-objc-mips-linux-1.1.2-4.i386.rpm
</verb>
And this is the list of packages for little endian targets:
<verb>
binutils-mipsel-linux-2.13.2.1-1.i386.rpm
egcs-c++-mipsel-linux-1.1.2-4.i386.rpm
egcs-g77-mipsel-linux-1.1.2-4.i386.rpm
egcs-libstdc++-mipsel-linux-2.9.0-4.i386.rpm
egcs-mipsel-linux-1.1.2-4.i386.rpm
egcs-objc-mipsel-linux-1.1.2-4.i386.rpm
</verb>
For 64-bit MIPS kernels, there are only two packages available right now:
<verb>
egcs-mips64-linux-1.1.2-4.i386.rpm
</verb>
and for little endian 64-bit systems:
<verb>
egcs-mips64el-linux-1.1.2-4.i386.rpm
</verb>
It's not necessary that you install all of these packages as most people can
just omit the C++, Objective C and Fortran 77 compilers. The
Intel binaries have been linked against GNU libc 2.2, so you may have to
install that as well when upgrading.
<sect2>Recommended compiler versions<p>
<sect3>Binutils<p>
The recommended version is binutils 2.13.2.1.
<sect3>gcc<p>
For Linux 2.4 kernels before 2003-05-16 the minimum gcc version required is
egcs 1.1.2; later 2.4, 2.5 and 2.6 require gcc 2.95.3 or newer. Using a
too old compiler may result in compiler core dumps or silently misscompiled
kernels. The better code generation of later tools has little impact on
performance of the generated kernel however more recent tools tend to be
dramatically slower at generating code, so some people like the maintainer
of the MIPS port tend to continue using old compilers in spite of their age.
For compilation of userspace applications and libraries you probably want a
much newer compiler; generally 2.95.3 is considered very stable and at the
same time reasonably fast. Due to the evolution of the C++ language and
ABI C++ users probably may have special constraints in selection of their
compiler version; a very recent compiler such as gcc 3.2 is probably a good
choice.
Note there is no need to use the same compilers for kernel and userspace
libraries and applications. You only want to use the same compiler version
for all C++ code.
<sect3>glibc<p>
This document still documents how to build glibc 2.0.6 however this version
is no longer recommended for new projects. Users who are looking into
glibc 2.0.6 due to binary size considerations may want to ucLibc instead.
Installing glibc into a crosscompiler environment is not necessary if you
only want to build compilers.
<sect3>uClibc<p>
uClibc is a very small libc replacement available at
<url url="http://www.uclibc.org">. The MIPS bits can be found at
<url url="ftp://ftp.realitydiluted.com/linux/MIPS/toolchains">.
<sect2>Building your own cross-compiler<p>
First of all, go and download the following source packages:
<itemize>
<item>binutils-2.13.2.1.tar.gz
<item>egcs-1.1.2.tar.gz
<item>glibc-2.0.6.tar.gz
<item>glibc-crypt-2.0.6.tar.gz
<item>glibc-localedata-2.0.6.tar.gz
<item>glibc-linuxthreads-2.0.6.tar.gz
</itemize>
You can obtain these files from your favorite GNU archive or <htmlurl
url="ftp://ftp.linux-mips.org" name="ftp.linux-mips.org">. Furthermore,
you'll need patches. The unbundled patch files aren't always up-to-date and
additional, not MIPS-specific, patches may be required for building. Note
that the unbundled patch files also use a different revision numbering and
it is therefore recommended that you obtain the source and patches from the
RPM packages distributed on <htmlurl url="ftp://ftp.linux-mips.org"
name="ftp.linux-mips.org">.
Those are the currently recommended versions. Older versions may or may not
be working. If you're trying to use older versions, please don't send bug
reports because we don't care. When installing, please install things in
the order of binutils, egcs, then glibc. Unless you have older versions
already installed, changing the order <sl>will</sl> fail.
<sect2>Disk space requirements<p>
For the installation, you'll have to choose a directory where the files will
be installed. I'll refer to that directory below with <prefix>. To avoid
a particular problem, it's best to use the same value for <prefix> as
your native gcc. For example, if your gcc is installed in /usr/bin/gcc,
then choose /usr for <prefix>. You must use the same <prefix> value
for all the packages that you're going to install.<p> During compilation,
you'll need about 31MB disk space for binutils. For installation, you'll
need 7MB disk space on <prefix>'s partition. Building egcs requires
71MB, and installation 14MB. GNU libc requires 149MB disk space during
compilation, and 33MB for installation. Note, these numbers are just a
guideline and may differ significantly for different processor and operating
system architectures or compiler options.
<sect2>Byte order<p>
One of the special features of the MIPS architecture is that all processors
except the R8000 can be configured to run either in big or in little endian
mode. Byte order means the way the processor stores multibyte numbers in
memory. Big endian machines store the byte with the highest value digits at
the lowest address while little endian machines store it at the highest
address. Think of it as writing multi-digit numbers from left to right or
vice versa.<p> In order to setup your cross-compiler correctly, you have to
know the byte order of the cross-compiler target. If you don't already
know, check the section <ref id="hardware-platforms" name="Hardware
Platforms"> for your machine's byte order.
<sect2>Configuration names<p>
Many of the packages based on autoconf support many different architectures
and operating systems. In order to differentiate between these many
configurations, names are constructed with <cpu>-<company>-<os>, or
even <cpu>-<company>-<kernel>-<os>. Expressed this way, the
configuration names of Linux/MIPS are: mips-unknown-linux-gnu for big endian
targets, or mipsel-unknown-linux-gnu for little endian targets. These names
are a bit long and are allowed to be abbreviated to mips-linux or
mipsel-linux. You <sl>must</sl> use the same configuration name for all
packages that comprise your cross-compilation environment. Also, while
other names, like mips-sni-linux or mipsel-sni-linux, are legal
configuration names, use mips-linux or mipsel-linux instead. These are the
configuration names known to other packages, like the Linux kernel sources,
and they would otherwise have to be changed for cross-compilation.<p>
I'll refer to the target configuration name below with <target>.
<sect2>Installation of GNU Binutils.<p>
This is the first and simplest part (at least as long as you're trying to
install on any halfway-sane UNIX flavour). Just cd into a directory with
enough free space and do the following:
<verb>
gzip -cd binutils-<version>.tar.gz | tar xf -
cd binutils-<version>
patch -p1 < ../binutils-<version>-mips.patch
./configure --prefix=<prefix> --target=<target>
make CFLAGS=-O2
make install
</verb>
This usually works correctly. However, certain machines using GCC 2.7.x as
compiler are known to dump core. This is a known bug in GCC and can be
fixed by upgrading the host compiler to GCC 2.13.2.1 or better.
<sect2>Assert.h<p>
Some people have an old assert.h header file installed, probably leftover
from an old cross-compiler installation. This file may cause autoconf
scripts to fail silently. Assert.h was never necessary and was only
installed because of a bug in older GCC versions. Check to see if the file
<prefix>/<target>/include/assert.h exists in your installation. If
so, just delete the it - it should never have been installed for any version
of the cross-compiler and will cause trouble.
<sect2>Installing the kernel sources<p>
Installing the kernel sources is simple. Just place them into some
directory of your choice and configure them. Configuring them is necessary
so that files which are generated by the procedure will be installed. Make
sure you enable CONFIG_CROSSCOMPILE near the end of the configuration
process. The only problem you may run into is that you may need to install
some required GNU programs like bash or have to override the
manufacturer-provided versions of programs by placing the GNU versions
earlier in the PATH variable. Now, go to the directory
<prefix>/<target>/include and create two symbolic links named asm and
linux pointing to include/asm rsp. include/linux within your just installed
and configured kernel sources. These are necessary such that the necessary
header files will be found during the next step.
<sect2>First installation of egcs<p>
Now the pain begins. There is a so-called bootstrap problem. In our case,
this means that the installation process of egcs needs an already installed
glibc, but we cannot compile glibc because we don't have a working
cross-compiler yet. Luckily, you'll only have to go through this once when
you install a cross-compiler for the first time. Later, when you already
have glibc installed, things will be much smoother. So now do:
<verb>
gzip -cd egcs-1.1.2.tar.gz | tar xf -
cd egcs-<version>
patch -p1 < ../egcs-1.1.2-mips.patch
./configure --prefix=<prefix> --with-newlib --target=<target>
make SUBDIRS="libiberty texinfo gcc" ALL_TARGET_MODULES= \
CONFIGURE_TARGET_MODULES= INSTALL_TARGET_MODULES= LANGUAGES="c"
</verb>
Note that we deliberately don't build gcov, protoize, unprotoize, and the
libraries. Gcov doesn't make sense in a cross-compiler environment, and
protoize and unprotoize might even overwrite your native programs - this is
a bug in the gcc makefiles. Finally, we cannot build the libraries because
we don't have glibc installed yet. If everything went successfully, install
with:
<verb>
make SUBDIRS="libiberty texinfo gcc" INSTALL_TARGET_MODULES= \
LANGUAGES="c" install
</verb>
If you only want the cross-compiler for building the kernel, you're done.
Cross-compiling libc is only required to be able to compile user
applications.
<sect2>Test what you've done so far<p>
Just to make sure that what you've done so far is actually working, you may
now try to compile the kernel. Cd to the MIPS kernel's sources and type
``make clean; make dep; make''. If everything went ok do ``make clean''
once more to clean the sources.
<sect2>Installing GNU libc<p>
<sl>Note: Building glibc 2.0.6 using a compiler newer than egcs 1.0.3a is
not recommended due to binary compatibility problems which may hit certain
software. It's recommended that you either use egcs 1.0.3a or use the files
from a published binary package. Crosscompiling GNU libc is always only the
second best solution as certain parts of it will not be compiled when
crosscompiling. A proper solution will be documented here as soon as it is
available and believed to be stable.</sl> With this warning given, here's
the recipe:
<verb>
gzip -cd glibc-2.0.6.tar.gz | tar xf -
cd glibc-2.0.6
gzip -cd glibc-crypt-2.0.6.tar.gz | tar xf -
gzip -cd glibc-localedata-2.0.6.tar.gz | tar xf -
gzip -cd glibc-linuxthreads-2.0.6.tar.gz | tar xf -
patch -p1 < ../glibc-2.0.6-mips.patch
mkdir build
cd build
CC=<target>-gcc BUILD_CC=gcc AR=<target>-ar RANLIB=<target>-ranlib \
../configure --prefix=/usr --host=<target> \
--enable-add-ons=crypt,linuxthreads,localedata --enable-profile
make
</verb>
You now have a compiled GNU libc which still needs to be installed. Do
<sl>not</sl> just type make install. That would overwrite your host
system's files with Linux/MIPS-specific files with disastrous effects.
Instead, install GNU libc into some other arbitrary directory <somedir>
from which we'll move the parts we need for cross-compilation into the
actual target directory:
<verb>
make install_root=<somedir> install
</verb>
Now cd into <somedir> and finally install GNU libc manually:
<verb>
cd usr/include
find . -print | cpio -pumd <prefix>/<target>/include
cd ../../lib
find . -print | cpio -pumd <prefix>/<target>/lib
cd ../usr/lib
find . -print | cpio -pumd <prefix>/<target>/lib
</verb>
GNU libc also contains extensive online documentation. Your system might
already have a version of this documentation installed, so if you don't
want to install the info pages, which will save you a less than a
megabyte, or already have them installed, skip the next step:
<verb>
cd ../info
gzip -9 *.info*
find . -name \*.info\* -print | cpio -pumd <prefix>/info
</verb>
If you're not bootstrapping, your installation is now finished.
<sect2>Building egcs again<p>
The first attempt of building egcs was stopped by lack of a GNU libc. Since
we now have libc installed we can rebuild egcs but this time as complete as
a cross-compiler installation can be:
<verb>
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
patch -p1 < ../egcs-1.1.2-mips.patch
./configure --prefix=<prefix> --target=<target>
make LANGUAGES="c c++ objective-c f77"
</verb>
As you can see, the procedure is the same as the first time, with the
exception that we dropped the --with-newlib option. This option was
necessary to avoid the libgcc build breaking due to the lack of libc. Now
install with:
<verb>
make LANGUAGES="c c++ objective-c f77" install
</verb>
You're almost finished. If you think you don't need the Objective C or
F77 compilers, you can omit them from above commands. Each will save you
about 3MB. Do not build gcov, protoize, or unprotoize.
<sect2>Should I build the C++, Objective C or F77 compilers?<p>
The answer to this question largely depends on your use of your
cross-compiler environment. If you only intend to rebuild the Linux kernel,
then you have no need for the full blown setup and can safely omit the
Objective C and F77 compilers. You must, however, build the C++
compiler, because building the libraries included with the egcs distribution
requires C++.
<sect2>Known problem when cross-compiling<p>
<sect3>IRIX crashes<p>
Origin 200 running IRIX 6.5.1 may crash when running ``make depend''
on the Linux kernel sources. IRIX 6.5 on Indy and IRIX 6.5.4 on
Origin 200 are known to work.
<sect3>Resource limits on System V based hosts<p>
Typical System V-based Unices, like IRIX or Solaris, have limits for
the maximum number of arguments to be passed to a child process which may
be exceeded when cross-compiling some software like the Linux kernel or GNU
libc. For IRIX systems, the maximum length of the argument list defaults
to 20KB, while Linux defaults to at least 128KB. This size can be modified
by the command ``systune ncargs 131072'' as root.
<sect2>GDB<p>
Building GDB as cross-debugger is only of interest to kernel developers. For
them, GDB may be a life saver. Such a remote debugging setup always consists
of two parts: the remote debugger GDB running on one machine, and the target
machine running the Linux/MIPS kernel being debugged. The machines are
typically interconnected with a serial line. The target machine's kernel
needs to be equipped with a ``debugging stub'' which communicates with the
GDB host machine using the remote serial protocol.<p>
Depending on the target's architecture, you may have to implement the
debugging stub yourself. In general, you'll only have to write very simple
routines for the serial line. The task is further simplified by the fact
that most machines are using similar serial hardware, typically based on the
8250, 16450 or derivatives.<p>
<!-- Write something about building GDB -->
<sect1>Compiling the kernel<p>
<sect2>Choosing a processor type<p>
<sect3>R2000, R3000 family<p>
For these processors just select the R3000 option. A kernel built for this
option will not run on any other processors than R2000 and R3000 family
members.<p>
<sect3>R4000, R5000 family<p>
With the exception of the Nevada family these processors are all fully
compatible with rescpect to the kernel. Choose the option which matches
your processor best for optimal performance.<p>
<sect3>R6000<p>
Linux currently doesn't support the R6000 so this paragraph is entirely
theoretical. The R6000 has it's own, rather unique if not odd cache and
MMU architecture; it also requires alot of workarounds as it's a quite
broken piece of silicon. Therefore a R6000 kernel will not work on any
other processor nor will a kernel for another processor work on the
R6000.<p>
<sect3>Nevada<p>
The Nevada nickname stands for the QED 5230, 5231, R5260, R5261, R5270 etc.
family of CPUs. It enables the use of additional instructions which are
not supported on other processors therefore you only should choose this
opition if you indeed have one of these processors. If you're not sure
configure for R4x00 or R5000 (see above) which will result in a kernel
which will run on Navada family processors too but not use certain
optimizations specific to these processors.<p>
<sect3>SB1<p>
Choose this option only for the Sibyte SB1 processor. A kernel built for
this processor will not work on any other processor type nor vice versa.
<sect3>R10000<p>
Choose this option if you want to run Linux on a R10000, R12000 or R14000
system. A kernel built with this option will not work on R4000 or R5000
family processors.
<sect3>MIPS32<p>
Choose this option if you want to run Linux on a member of the MIPS32
family.<p>
<sect2>Compatible options<p>
The kernel configuration process doesn't make a too strong attempt at making
wrong configuration impossible. So for example an SGI Indy may never have a
framebuffer, yet it's possible to enable it which later on will result in a
compile error. This situation will improve in the future when CML2 will be
the standard kernel configuration language; for 2.2 and 2.4 you still will
have to care of your steps yourself.
<sect2>Crosscompilation<p>
The kernel has been carefully developped to ensure crosscompilation on a
non-MIPS system is possible. Once you've managed to get around the cliff of
setting up a crosscompiler crosscompiling is easy. To do so you have two
options. First you can pass CROSS_COMPILE=<target>- (note the trailing
dash) as an additional argument to your make invocations where you choose
one of mips-linux, mipsel-linux, mips64-linux or mips64el-linux depending if
your target is big or little endian, 32-bit or 64-bit.<p>
An alternate and probably easier way is setting the CONFIG_CROSSCOMPILE
configuration option. The kernel will then automatically choose the right
value for CROSS_COMPILE which will keep make command lines a bit simpler.
<sect2>32-bit vs. 64-bit<p>
By default the Linux/MIPS kernel source tree is configured to build a 32-bit
target. If you want to build a 64-bit 2.4.x kernel you'll have pass the
additional ARCH=mips64 argument to all you make invocations. In 2.6.x
this has become a normal config option.
<sect>Documentation<p>
<label id=documentation>
<sect1>Getting this information as a single document<p>
You can download this document in various formats:
<itemize>
<item>The HTML version
<url url="http://howto.linux-mips.org/mips-howto.html">
<item>The text version
<url url="http://howto.linux-mips.org/mips-howto.txt">
<item>The Postscript version
<url url="http://howto.linux-mips.org/mips-howto.ps">
<item>The Linux-Doc SGML version.
<url url="http://howto.linux-mips.org/mips-howto.sgml">
</itemize>
This FAQ is also available as SGML source code via anonymous CVS from
ftp.linux-mips.org. The archive also has a Makefile which will translate it
into various formats. An ASCII version is regularly being posted via
<em>comp.os.linux.answers</em> and the other Linux HOWTO channels.
Updates for this document should be sent as unified diffs against the
SGML version to <htmlurl url="mailto:ralf@gnu.org"
name="Ralf Bächle (ralf@gnu.org)">. Please don't updates in any
other form as that will make maintenance significantly more difficult.
<sect1>See MIPS Run<p>
Author Dominic Sweetman, Publisher Morgan Kaufmann, ISBN 1-55860-410-3.
This is intended as a pretty comprehensive guide to programming MIPS,
wherever it's different from programming any other 32-bit CPU. It's the
first time anyone has tried to write a readable, and comprehensive,
explanation and account of the wide range of MIPS CPUs available. It should
be very helpful for anyone programming MIPS who isn't insulated by someone
else's operating system. Also, the author is a free-unix enthusiast who
subscribes to the Linux/MIPS mailing list!
John Hennessey, father of the MIPS architecture, was kind enough to write
in the foreword: ``... this book is the best combination of completeness
and readability of any book on the MIPS architecture ...'';
It includes some context about RISC CPUs, a description of the
architecture and instruction set, including the "co-processor 0"
instructions used for CPU control; sections on caches, exceptions, memory
management, and floating point. There's a detailed assembly language
guide, some stuff about porting, and some fairly heavy-duty software
examples.
Available from:
<itemize>
<item><htmlurl
url="http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-410-3"
name="Morgan Kaufmann"> (US)
<item><htmlurl
url="http://www.amazon.com/exec/obidos/ASIN/1558604103/algorithmicsltd"
name="Amazon USA">
<item><htmlurl
url="http://www.amazon.co.uk/exec/obidos/ASIN/1558604103/algorithmicsltd"
name="Amazon UK">
</itemize>
and from good bookshops anywhere. It's 512 pages and costs around
$50 in the US, £34 in the UK.
I'd be inclined to list two other books too, both from Morgan Kaufmann and
available from www.mkp.com or any good bookshop:
<sect1>The MIPS Programmer's Handbook<p>
Authors Farquhar and Bunce, Publisher Morgan Kaufmann,
ISBN 1-55860-297-6.
A readable introduction to the practice of programming MIPS at the low
level, by the author of PMON. Strengths: lots of examples; weakness:
leaves out some big pieces of the architecture (such as memory management,
floating point and advanced caches) because they didn't feature in the LSI
``embedded'' products this book was meant to partner.
<sect1>Computer Architecture - A Quantitative Approach<p>
Authors Hennessy & Patterson, Publisher Morgan Kaufmann,
ISBN 1-55860-329-8.
The bible of modern computer architecture and a must-read if you want
to understand what makes programs run slow or fast. Is it about MIPS?
Well, it's mostly about something very <em>like</em> MIPS... Its sole
defect is its size and weight - but unlike most big books it's worth
every page.
<sect1>MIPS ABI documentation<p>
The documentation to be found at <url
url="ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/"> defines many of the
MIPS specific technical standards like calling conventions, ELF properties,
and much more that is being used by Linux/MIPS, including the N32 standard.
<sect1>The mips.com site<p>
Under <url url="http://www.mips.com/publications"> there are various PDF
documents and data sheets about individual processors and cores.
<sect1>The NEC site<p>
NEC Electronics (<url url="http://www.necel.com"> includes complete manuals
about their VR41xx processors.
<sect1>techpubs.sgi.com<p>
While being very SGI centric <url url="http://techpubs.sgi.com"> has a number
of ABI related documents online that also apply to Linux/MIPS.
<sect>Legal Notices
<sect1>Copyright<p>
Except where otherwise specified, the information in this documentation or
website is copyright (c) 1998,1999,2000,2001,2002 Ralf Bächle.<p>
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.1 or any later
version published by the Free Software Foundation; with the Invariant
Sections being Copyright, with no Front-Cover Texts and with no Back-Cover
Texts.<p>
A copy of the GNU Free Documentation License is available on the World Wide
Web at <url url="http://www.gnu.org/copyleft/fdl.html"> You can also obtain
it by writing to the
<verb>
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307
USA
</verb>
<sect1>Software Use<p>
Any software contained in or linked to by this documentation (the "Software")
is copyrighted work. To use the Software you must comply with the terms of
the Software's license agreement. SOFTWARE IS WARRANTED, IF AT ALL, IN
ACCORDANCE WITH THE TERMS OF THE LICENSE AGREEMENT. EXCEPT AS SET FORTH IN
THE LICENSE AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT
THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. <sect1>Links to
websites <p>
This documentation may contain links to websites which are not under our
control. We are not responsible for the content of those sites. The links are
available only as a convenience, and the inclusion of any link to such sites
does not imply endorsement of those sites.
<sect1>Trademarks <p>
Linux is a Registered Trademark of Linus Torvalds. <p>
MIPS is a Registered Trademark of MIPS Technologies, Inc.
<sect1>Disclaimer<p>
Note that, as provided in the License, the software on this website is
distributed on an "AS IS" basis, with ALL EXPRESS AND IMPLIED WARRANTIES AND
CONDITIONS DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES
AND CONDITIONS OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A
PARTICULAR PURPOSE, AND NON-INFRINGEMENT. <sect1>Limitation of liability<p>
THE AUTHORS OF THIS WEB SITE SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED AS
A RESULT OF USING, MODIFYING, CONTRIBUTING, COPYING, DISTRIBUTING, OR
DOWNLOADING THE MATERIALS ON THIS WEBSITE. IN NO EVENT SHALL WE BE LIABLE FOR
ANY INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGE
(INCLUDING LOSS OF BUSINESS, REVENUE, PROFITS, USE, DATA OR OTHER ECONOMIC
ADVANTAGE) HOWEVER IT ARISES, WHETHER FOR BREACH OR IN TORT, EVEN IF WE HAVE
BEEN PREVIOUSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
YOU HAVE SOLE RESPONSIBILITY FOR ADEQUATE PROTECTION AND BACKUP OF DATA
AND/OR EQUIPMENT USED IN CONNECTION WITH THE WEBSITE AND WILL NOT MAKE A
CLAIM AGAINST THIS WEB SITE OR ITS AUTHORS FOR LOST DATA, RE-RUN TIME,
INACCURATE OUTPUT, WORK DELAYS OR LOST PROFITS RESULTING FROM THE USE OF THE
MATERIALS. YOU AGREE TO HOLD US HARMLESS FROM, AND YOU COVENANT NOT TO SUE US
FOR, ANY CLAIMS BASED ON USING THE WEBSITE.
</article>
