mirror of https://github.com/tLDP/LDP
1159 lines
56 KiB
Plaintext
1159 lines
56 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<!-- $Id$ -->
|
|
|
|
<article>
|
|
|
|
<title>Linux/MIPS HOWTO
|
|
<author>Ralf Bächle, <tt/ralf@gnu.org/
|
|
<date>January 8, 2001
|
|
<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>What is Linux/MIPS?<p>
|
|
Linux/MIPS is a port of the widespread UNIX clone Linux to the MIPS
|
|
architecture. Linux/MIPS is running on a large number of technically very
|
|
different systems ranging from small embedded systems and servers to large
|
|
desktop machines and servers that, at least at the time when they were
|
|
introduced into the market, were the best of their class.<p>
|
|
|
|
Linux/MIPS advantages over other operating systems at this time are
|
|
<itemize>
|
|
<item>The entire Linux system consists only of Free Software.
|
|
<item>Excellent Price/Performance ratio.
|
|
<item>Availability of large amounts of software of which a large part
|
|
again is Free Software.
|
|
<item>Binary compatibility across a growing number of platforms.
|
|
<item>Small footprint making Linux/MIPS suitable for many embedded systems.
|
|
</itemize>
|
|
|
|
In short, Linux has been designed and ships with Fahrvergnügen.
|
|
However, as usual your mileage may vary and you should examine the
|
|
suitability of Linux for your task - something which we hope this document
|
|
helps you to accomplish.<p>
|
|
|
|
<sect>Getting this FAQ<p>
|
|
You can download this document in various formats:
|
|
|
|
<itemize>
|
|
<item>The HTML version
|
|
<url url="http://oss.sgi.com/mips/mips-howto.html">
|
|
<item>The text version
|
|
<url url="http://oss.sgi.com/mips/mips-howto.txt">
|
|
<item>The Postscript version
|
|
<url url="http://oss.sgi.com/mips/mips-howto.ps">
|
|
<item>The Linux-Doc SGML version.
|
|
<url url="http://oss.sgi.com/mips/mips-howto.sgml">
|
|
</itemize>
|
|
|
|
This FAQ is also available as SGML source code via anonymous CVS from
|
|
oss.sgi.com. 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.
|
|
|
|
<sect>What hardware does Linux/MIPS support?
|
|
<sect1>Hardware Platforms<p>
|
|
<label id="hardware-platforms">
|
|
<p>
|
|
Many machines are available with a number of different CPU options of which
|
|
not all are currently supported. Please check section
|
|
<ref id="supported-cpus" name="Processor Types"> to make sure your CPU type
|
|
is supported. This is a listing of machines that are running
|
|
Linux/MIPS, systems to which Linux/MIPS could be ported, or systems that
|
|
people have an interest in running Linux/MIPS.
|
|
|
|
<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>Cobalt Qube and Raq<p>
|
|
The Cobalt Qube product series are low cost headless server systems
|
|
based on a IDT R5230. Cobalt has developed its own Linux/MIPS
|
|
variant to fit the special requirements of the Qube as well as possible.
|
|
Basically, the Qube kernel was derived from Linux/MIPS 2.1.56,
|
|
backported to 2.0.30 for stability's sake, then optimized. Cobalt kernels
|
|
are available from Cobalt's ftp site <url url="http://www.cobaltnet.com">.
|
|
The Cobalt Qube support has never been integrated into the official
|
|
Linux/MIPS 2.1.x kernels.
|
|
|
|
<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>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. For more
|
|
information please see <url url="http://linux-vr.org/">.
|
|
|
|
<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>. Support for more devices
|
|
is under construction. The code is part of the Linux VR project and as such
|
|
more information can be found at <url url="http://linux-vr.org/">.
|
|
|
|
<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>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 not 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)"> or <htmlurl
|
|
url="mailto:spock@mgnet.de" name="Klaus Naumann (spock@mgnet.de)"> .
|
|
|
|
<sect2>Silicon Graphics Indy<p>
|
|
The Indy is currently the only (mostly) supported Silicon Graphics
|
|
machine. The only supported graphics card is the Newport card, a.k.a.
|
|
``XL'' graphics. The Indy is available with a large number of
|
|
CPU options at various clock rates, all of which are supported.
|
|
There is also a X server available, now written by
|
|
<htmlurl url="mailto:guido.guenther@gmx.net"
|
|
name="Guido Guenther (guido.guenther@gmx.net)">.
|
|
If you're able to use the Newport console on your Indy it should be
|
|
possible to also use this X server. It's based on XFree86 4.0 and
|
|
currently runs at snail-like speeds, but it seems to work quite well.
|
|
If you want to try it, take a look at
|
|
<url url="http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/"> .
|
|
|
|
<sect3>Strange amounts of available memory<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.
|
|
|
|
<sect3>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>
|
|
|
|
<sect3>ELF support in old PROM versions<p>
|
|
Old PROM versions don't know about the ELF binary format which the Linux
|
|
kernel uses, so Linux cannot boot directly. The preferable solution
|
|
for this is of course a PROM upgrade. Alternatively, you can use Sash for
|
|
IRIX 5 or newer to boot the kernel. Sash knows how to load ELF binaries
|
|
and doesn't care if it's an IRIX or Linux kernel. Simply type
|
|
``Sash'' to the PROM monitor. You should get another shell
|
|
prompt, this time from Sash. Now launch Linux as usual.<p> Sash can read
|
|
EFS or XFS filesystems or read the kernel from bootp / tftp. That means
|
|
if you intend to use Sash for booting the kernel from local disk, you'll
|
|
still have to have a minimal IRIX installation on your system.
|
|
|
|
<sect3>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>
|
|
|
|
<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. The code is available in the
|
|
Linux/MIPS CVS tree.<p>
|
|
|
|
<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>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>Other Silicon Graphics machines<p>
|
|
At this time, no other Silicon Graphics machine is supported. This also
|
|
applies to the <sl>very</sl> old Motorola 68k-based systems.
|
|
|
|
<sect2>Sony Playstation<p>
|
|
The Sony Playstation is based on an R3000 derivative and uses a set of
|
|
graphics chips developed by Sony themselves. While the machine, in theory,
|
|
is capable of running Linux, a port is difficult since Sony so far
|
|
hasn't provided the necessary technical information. This still leaves the
|
|
question of whether the port would be worthwhile. So in short, nothing has
|
|
happened yet even though many people have shown an interest in running Linux
|
|
on this system.
|
|
|
|
<sect2>SNI RM200C<p>
|
|
In contrast to the RM200 (see below), this machine has EISA and PCI slots.
|
|
The RM200 is supported with the exception of the availability of the onboard
|
|
NCR53c810A SCSI controller.
|
|
|
|
<sect2>SNI RM200<p>
|
|
If your machine has both EISA and PCI slots, then it is an RM200C (please
|
|
see above). Due to the slight architectural differences of the RM200 and
|
|
the RM200C, this machine isn't currently supported in the official sources.
|
|
<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 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>Algorithmics P-4032, P-5064, P-6032<p>
|
|
Algorithmics (<url url="http://www.algor.co.uk/">) make a series of
|
|
single-board computers for MIPS prototyping, and maintain Linux kernels
|
|
for all of them:
|
|
<itemize>
|
|
<item>P-6032 is a new board for CPUs with 32-bit buses (QED
|
|
RM5231, NEC Vr43x0, NEC Vr5432, IDT 64x74)
|
|
<item>P-4032 is an older board obsoleted by P-6032.
|
|
<item>P-5064 is for CPUs with 64-bit buses, notably QED's RM70xx
|
|
and RM52xx series.
|
|
</itemize>
|
|
|
|
All the boards have common I/O plus ethernet and disk interfaces onboard,
|
|
with spare PCI slots for adding different controllers. They're highly
|
|
configurable, so will run with either byte order. All are suitable targets
|
|
for 64-bit kernels, but (so far) all the Linux work we've done has been using
|
|
32-bit code.
|
|
|
|
They're available, supported and documented with PDF manuals available
|
|
online, like <url url="http://www.algor.co.uk/ftp/pub/doc/p6032-user.pdf">
|
|
for the P-6032.
|
|
|
|
At the time of writing (November 2000) we are using a 2.2.x kernel; kernel
|
|
code is shared with the ports being done by people from <htmlurl
|
|
url="http://www.mips.com" name="MIPS Technologies, Inc.">).
|
|
Algorithmics wrote the floating point trap handler and emulator used in this
|
|
kernel - essential for MIPS CPUs to run floating point operations reliably
|
|
and correctly.
|
|
|
|
Algorithmics' kernels and a link to the MIPS userland can be found from a
|
|
jump page at <url url="http://www.algor.co.uk/algor/info/linux.html">
|
|
|
|
You can contact us at <htmlurl url="mailto:ask@algor.co.uk"
|
|
name="Algorithmics">.
|
|
|
|
<sect2>DECstation series<p>
|
|
During the late 80's and the early 90's, Digital (now Compaq) built MIPS-based
|
|
Workstations named DECstation resp. DECsystem. Other x86 and Alpha-based
|
|
machines were sold under the name DECstation, but these are obviously not the
|
|
subject of this FAQ. Support for DECstations is still under development,
|
|
started by Paul M. Antoine. These days, most of the work is done by
|
|
<htmlurl url="mailto:Harald.Koerfgen@home.ivm.de"
|
|
name="Harald Koerfgen (Harald.Koerfgen@home.ivm.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.
|
|
|
|
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 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.fnet.fr">.<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.
|
|
|
|
<sect1>Processor types
|
|
<label id="supported-cpus">
|
|
<sect2>R2000, R3000 family<p>
|
|
The R2000 is the original MIPS processor. It's a 32 bit processor which
|
|
was clocked at 8MHz back in '85 when the first MIPS processors came to the
|
|
market. Later versions were clocked faster, for example,
|
|
the R3000 is a 100% compatible redesign of the R2000 which is just clocked
|
|
faster. Because of their high compatibility, where this document mentions
|
|
the R3000, in most cases the same facts also apply to the R2000.
|
|
The R3000A is basically an R2000, plus an R3010 FPU,
|
|
and 64K cache running at up to 40MHz all integrated onto the same chip.<p>
|
|
|
|
<htmlurl url="mailto:Harald.Koerfgen@home.ivm.de"
|
|
name="Harald Koerfgen (Harald.Koerfgen@home.ivm.de)"> and <htmlurl
|
|
url="mailto:raiko@niisi.msk.ru" name="Gleb O. Raiko (raiko@niisi.msk.ru)">
|
|
have both independently worked on patches for R3000 processors.
|
|
The work has been merged and integrated into the official Linux/MIPS
|
|
sources since July 1999. Actually, Linux supports R3000 processors including
|
|
some derivatives like the R3081 and the TMPR3912/PR31700<p>
|
|
|
|
<sect2>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;
|
|
a pretty 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.
|
|
|
|
<sect2>R4000 and R5000 family<p>
|
|
Linux supports many of the members of the R4000 family. Currently, these
|
|
are: R4000PC, R4400PC, R4300, R4600, R4700, R5000, R5230, R5260. Many
|
|
others are probably supported as well.<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.
|
|
|
|
<sect2>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.
|
|
|
|
<sect2>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>
|
|
|
|
<sect2>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 litte difference between CPU types with and without TLB, we
|
|
still recommend that you choose a processor with TLB. It's going to save you
|
|
a lot of engineering.
|
|
|
|
<sect2>Processors with partial or no FPU<p>
|
|
In theory, these processors are supportable, especially when applications
|
|
don't rely on the presence of a FPU. We, however, don't support that yet.
|
|
|
|
<sect1>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.linuxppc.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.
|
|
Unfortunately, the VaxStation, like the entire VAX family, is currently
|
|
unsupported.
|
|
|
|
<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 like the Iris 3000<p>
|
|
These are <sl>very</sl> old machines, probably more than ten years old by
|
|
now. As these machines are not based on MIPS processors, and therefore not
|
|
supported by the Linux/MIPS project, this document is the wrong place to
|
|
search for information.
|
|
|
|
<sect>Linux distributions.<p>
|
|
<sect1>RedHat<p>
|
|
For MIPSeb, there's Rough Cuts Linux, previously known as Hard Hat Linux,
|
|
which is most of RedHat Linux 5.1 ported for MIPSeb. You can get this at
|
|
<url url="ftp://oss.sgi.com/pub/linux/mips/redhat">.<p>
|
|
|
|
It is bundled along with M68k, UltraSparc, and PowerPC in a package called
|
|
"Rough Cuts" pressed by RedHat, and available wherever RedHat products are
|
|
sold. This is a very convenient way to get it without having to download
|
|
280MB. Redhat is no longer offering this product but if you're lucky you
|
|
may still find the CD in some shops or somewhere on the net.
|
|
|
|
A distribution based on Red Hat 5.2 that's targeting the Cobalt Qubes. Those
|
|
binaries will work perfectly on other MIPSel architectures and are available
|
|
at <url url="ftp://intel.cleveland.lug.net/pub/Mipsel">.
|
|
<url url="ftp://bolug.uni-bonn.de/mips"> has various rpm packages from
|
|
Redhat 6.0, 6.1 and 6.2.
|
|
|
|
<sect1>Debian<p>
|
|
A Debian port is underway. Current efforts are being bootstrapped using
|
|
SGI/Linux as a base, and dpkg compiles natively with few changes. In
|
|
addition to the SGI version, some interest has been shown in little endian
|
|
platforms. Keep an eye on the Debian-MIPS Port page,
|
|
<url url="http://www.debian.org/ports/mips/"> for developments.
|
|
|
|
<sect1>Simple<p>
|
|
This distribution is for big-endian systems only so far. It's highly
|
|
experimental, intended for developers' use in testing the latest versions
|
|
of gcc, binutils, glibc, and the kernel. This is the only glibc 2.2-based
|
|
distribution available for MIPS. You can always get the latest version of
|
|
this distribution and accompanying release notes at <url
|
|
url="ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple">. Also available
|
|
is a cross-compiler system to aid in development.
|
|
|
|
<sect1>Other<p>
|
|
Kevin Kissel of MIPS, Inc. has put together a compilation of the
|
|
RedHat 5.2 mipsel distribution that includes the all the packages
|
|
from the Cleveland LUG site
|
|
<url url="ftp://intel.cleveland.lug.net/pub/Mipsel">, plus quite a few
|
|
others from elsewhere that are either newer than, or missing from, the
|
|
Cleveland LUG distribution. This compilation can be found via HTML at
|
|
<url url="http://www.paralogos.com/mipslinux"> or directly by FTP at
|
|
<url url="ftp://ftp.paralogos.com/pub/linux/mips/RPMS/mipsel">.<p>
|
|
|
|
<sect>Linux/MIPS net resources.<p>
|
|
<sect1>Anonymous FTP servers.<p>
|
|
The two primary anonymous FTP servers for Linux/MIPS are
|
|
<descrip>
|
|
<tag><htmlurl url="ftp://oss.sgi.com" name="oss.sgi.com"><p>
|
|
This server should satisfy almost all of your Linux/MIPS related ftp desires.
|
|
Really.<p>
|
|
<tag><htmlurl url="ftp://ftp.fnet.fr" name="ftp.fnet.fr"><p>
|
|
This server is currently pretty outdated. It's included here mostly for
|
|
completeness, and for people with interest in prehistoric software.
|
|
</descrip>
|
|
On all of these ftp servers, there is a list of mirror sites you may
|
|
want to use for faster access.<p>
|
|
|
|
Another source for little endian MIPS binaries is
|
|
<htmlurl url="ftp://intel.cleveland.lug.net/pub/Mipsel"
|
|
name="ftp://intel.cleveland.lug.net/pub/Mipsel">, which carries mostly newer
|
|
versions of binaries for the RedHat flavour shipping with the Cobalts.<p>
|
|
|
|
<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@oss.sgi.com:/cvs login
|
|
(Only needed the first time you use anonymous CVS, the password is "cvs")
|
|
cvs -d :pserver:cvs@oss.sgi.com:/cvs co <repository>
|
|
</verb>
|
|
where you insert linux, libc, gdb or faq for <repository>.
|
|
|
|
The other important CVS archive of the Linux community is vger.kernel.org,
|
|
where a lot of code is being collected before being sent to Linus for
|
|
distribution. Although vger itself no longer offers anonymous access, there
|
|
are mirror sites which do provide anonymous access. For details on how to access
|
|
them, see <url url="http://cvs.on.openprojects.net/">. The modules which are
|
|
of interest are: ``linux'', ``modutils'', ``pciutils'', and ``netutils''.
|
|
|
|
<sect1>Web servers.<p>
|
|
The two primary web servers for Linux/MIPS are
|
|
<descrip>
|
|
<tag><url url="http://oss.sgi.com/mips"><p>
|
|
This server covers most of Linux/MIPS. It's somewhat SGI-centric, but since
|
|
Linux/MIPS tries to be the same on every platform, most of its information
|
|
is of interest to all users.
|
|
<tag><url url="http://www.linux-mips.org"><p>
|
|
Quite new site which one day will hopefully become the main Linux/MIPS
|
|
site.
|
|
<tag><url url="http://lena.fnet.fr"><p>
|
|
This server is currently pretty outdated. It's included here mostly for
|
|
completeness.
|
|
</descrip>
|
|
All of these servers have mirrors scattered all over the world - you may want to
|
|
use one for best performance.
|
|
|
|
<sect1>Web CVS server.<p>
|
|
Via <url url="http://oss.sgi.com/mips/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.
|
|
|
|
<sect1>Mailing lists.<p>
|
|
There are three Linux/MIPS-oriented mailing lists:
|
|
<descrip>
|
|
<tag><htmlurl url="mailto:linux-mips@fnet.fr" name="linux-mips@fnet.fr"><p>
|
|
This mailing list is used for most all non-SGI related communication.
|
|
Subscription is handled by a human, and you can send your subscription
|
|
requests to <htmlurl url="mailto:linux-mips-request@fnet.fr"
|
|
name="linux-mips-request@fnet.fr">. You can unsubscribe from this mailing
|
|
list by sending <em>unsubscribe <your-email-address></em> to the same
|
|
address. <em>Only subscribers are allowed to post to this list</em>.
|
|
|
|
<tag><htmlurl url="mailto:linux-mips@oss.sgi.com"
|
|
name="linux-mips@oss.sgi.com"><p> This mailing list currently has the most
|
|
traffic. It's somewhat SGI-centric but is nevertheless of interest
|
|
especially to developers as a good number of SGI engineers are subscribed
|
|
to this list. Subscription to this list is handled via
|
|
<htmlurl url="mailto:majordomo@oss.sgi.com"
|
|
name="Majordomo (majordomo@oss.sgi.com)">, just send an email with the
|
|
words <em>subscribe linux-mips</em>. In order to unsubscribe, send
|
|
<em>unsubscribe linux-mips</em>. For more, information see also
|
|
<url url="http://oss.sgi.com/mips/email.html">.
|
|
</descrip>
|
|
|
|
<sect1>IRC channel.<p>
|
|
There is an IRC channel named #mipslinux for Linux/MIPS which may be found on
|
|
irc.openprojects.net.
|
|
|
|
<sect>Installation of Linux/MIPS and common problems.<p>
|
|
|
|
<sect1>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>
|
|
|
|
<sect1>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>
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>Where can I get the little endian firmware for my SNI?<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)">.
|
|
|
|
<sect1>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
|
|
binutils 2.8.1 plus very current patches.
|
|
|
|
<sect1>My machine doesn't download the kernel when I try to netboot<p>
|
|
|
|
Your machine is replying to the BOOTP packets (you may verify this
|
|
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 your
|
|
boot server.
|
|
|
|
<sect1>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.
|
|
|
|
<sect>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>
|
|
Plans are to remove the need for Milo in the near future.<p>
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect>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.
|
|
|
|
<sect>How do I set up a cross-compiler?<p>
|
|
<sect1>Available binaries<p>
|
|
The easiest way to setup a cross-compiler is to just download the binaries.
|
|
For Linux/i386 hosts and big endian targets, these are the packages:
|
|
<verb>
|
|
binutils-mips-linux-2.8.1-1.i386.rpm
|
|
egcs-c++-mips-linux-1.1.2-2.i386.rpm
|
|
egcs-g77-mips-linux-1.1.2-2.i386.rpm
|
|
egcs-libstdc++-mips-linux-2.9.0-2.i386.rpm
|
|
egcs-mips-linux-1.1.2-2.i386.rpm
|
|
egcs-objc-mips-linux-1.1.2-2.i386.rpm
|
|
</verb>
|
|
|
|
And this is the list of packages for little endian targets:
|
|
<verb>
|
|
binutils-mipsel-linux-2.8.1-1.i386.rpm
|
|
egcs-c++-mipsel-linux-1.1.2-2.i386.rpm
|
|
egcs-g77-mipsel-linux-1.1.2-2.i386.rpm
|
|
egcs-libstdc++-mipsel-linux-2.9.0-2.i386.rpm
|
|
egcs-mipsel-linux-1.1.2-2.i386.rpm
|
|
egcs-objc-mipsel-linux-1.1.2-2.i386.rpm
|
|
</verb>
|
|
|
|
For 64-bit MIPS kernels, there is only one package available right
|
|
now:
|
|
<verb>
|
|
egcs-mips64-linux-1.1.2-2.i386.rpm
|
|
</verb>
|
|
|
|
This compiler is only available in the big endian flavor as there currently
|
|
is no little endian machine supported by the 64-bit kernel. A little endian
|
|
version of the compiler will be provided as soon as there is demand for one.
|
|
|
|
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.1, so you may have
|
|
to install that as well when upgrading.
|
|
|
|
<sect1>Recommended compiler versions<p>
|
|
Compilers older than egcs 1.1.2 are no longer supported for compiling kernels
|
|
due to bugs in the generated code. At this time, we still recommend
|
|
binutils 2.8.1 despite their age.
|
|
|
|
<sect1>Building your own cross-compiler<p>
|
|
First of all, go and download the following source packages:
|
|
<itemize>
|
|
<item>binutils-2.8.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://oss.sgi.com" name="oss.sgi.com">. Furthermore, you'll
|
|
need patches. The unbundled patch files aren't always up-to-date and addional,
|
|
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://oss.sgi.com" name="oss.sgi.com">.
|
|
|
|
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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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>.
|
|
|
|
<sect1>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.8.1 or better.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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.
|
|
|
|
<sect1>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++.
|
|
|
|
<sect1>How about float.h?<p>
|
|
The installation of float.h is no longer necessary. Since about egcs 1.0.3a,
|
|
a proper float.h header file will automatically be generated and installed.
|
|
|
|
<sect1>Known problem when cross-compiling<p>
|
|
<sect2>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. Further reports that help to isolate
|
|
the problematic configuration are welcome.
|
|
|
|
<sect2>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.
|
|
|
|
<sect1>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 -->
|
|
|
|
<sect>Related Literature<p>
|
|
<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><url url="http://www.algor.co.uk/algor/info/seemipsrun.html"> (europe)
|
|
<item><url url="http://www.mkp.com/books_catalog/1-55860-410-3.asp"> (US)
|
|
</itemize>
|
|
|
|
and from good bookshops anywhere. It's 512 pages and costs around
|
|
$50 in the US, £39.95 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>UNIX System V ABI MIPS Processor Supplement<p>
|
|
By Prentice Hall, Published 05/1991, ISBN 0-13880-170-3.
|
|
This book defines many of the MIPS specific technical standards like calling
|
|
conventions, ELF properties, and much more that is being used by Linux/MIPS.
|
|
Unfortunately it's out of print. Similarly, the site
|
|
<em>"http://www.mipsabi.org/"</em> is offline.
|
|
|
|
<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.
|
|
|
|
<sect1>The NEC site<p>
|
|
NEC Electronics (<url url="http://www.necel.com"> includes complete manuals
|
|
about their VR41xx processors.
|
|
|
|
</article>
|