mirror of https://github.com/tLDP/LDP
1652 lines
76 KiB
Plaintext
1652 lines
76 KiB
Plaintext
<!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 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 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>
|