LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/linuxdoc/MIPS-HOWTO.sgml

1141 lines
53 KiB
Plaintext
Raw Blame History

<!doctype linuxdoc system>
<!-- $Id$ -->
<article>
<title>Linux/MIPS HOWTO
<author>Ralf B&auml;chle, <tt/ralf@gnu.org/
<date>v0.1, 31 March 1999
<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 a little 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 little 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&uuml;gen.
However as usual your mileage may vary and you should examine Linux's
suitability for your purpose which purpose this document tries to serve.<p>
<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 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; source for both is available at
<url url="http://decstation.unix-ag.org/">.
<sect2>Cobalt Qube and Raq<p>
The Cobalt&nbsp;Qube product series are low cost headless server systems
based on a IDT&nbsp;R5230. Cobalt has developed its own Linux/MIPS
variant to fit the special requirements of the Qube as well as possible.
Basically the Qube kernel has been derived from Linux/MIPS 2.1.56, then
backported to 2.0.30 for stability's sake, then optimized. Cobalt kernels
are available from Cobalt's ftp site <url url="http://www.cobaltnet.com">.
The Cobalt Qube support has never been integrated into the official
Linux/MIPS 2.1.x kernels.
<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 this is a good idea.
<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 aka
&ldquo;XL&rdquo; graphics. The Indy is available with a large number of
CPU options at various clock rates all of which are supported. There is
currently no X server available for the Indy; <htmlurl
url="mailto:alan@lxorguk.ukuu.org.uk" name="Alan Cox
(alan@lxorguk.ukuu.org.uk)"> is working on one.
<sect3>Strange numbers 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.
<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 PROMs to a newer version
or go back to an older CPU version. Usually R4000SC or R4400SC modules
should work in that case. Just to be clear, this is a problem which
is unrelated to Linux. It's only mentioned here because several Linux
users have asked about it.<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, that is can't boot Linux directly. The preferable solution
for this is of course a PROM upgrade. Alternatively you can use Sash of
IRIX 5 or newer to boot the kernel. Sash knows how to load ELF binaries
and doesn't care if it's an IRIX or Linux kernel. Simply type
&ldquo;Sash&rdquo; 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, thus this message.<p>
<sect2>Silicon Graphics Challenge S<p>
This machine is very similar to the Indy; the difference is that it doesn't
have a keyboard and a GFX card but has an additional SCSI WD33C95 based adapter.
This WD33C95 hostadapter is currently not supported.
<sect2>Silicon Graphics Indigo<p>
This machine is only being mentioned here because occasionally people
have confused it with Indys. The Indigo series is a different architecture
however and therefore yet unsupported.
<htmlurl url="mailto:andrewb@uab.edu"
name="Andrew R. Baker (andrewb@uab.edu)"> announced
a university project to port Linux to the Indigo on January&nbsp;2, 1999.
<sect2>Serial console on SGI machines<p>
Make sure 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&nbsp;S depending on which serial interface you're
going to use as console.<p>
If you have the problem that all kernel messages appear on the serial
console on bootup but everything is missing from the point when init starts,
then you probably have the wrong setup for your /dev/console.
You can find more information about this in the Linux kernel source
documentation; it's in /usr/src/linux/Documentation/serial-console.txt if
you have the kernel source installed.
<sect2>Motorola 68k based machines like the Iris&nbsp;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 this document is
the wrong place to search for information. However, in order to make things
easy, these machines are currently not supported.
<sect2>SGI VisPC<p>
This is actually an x86 based system, therefore not covered by this FAQ.
But to make your search for answers simple, here it is.
<htmlurl url="mailto:kck@mailbox.esd.sgi.com"
name="Ken Klingman (kck@mailbox.esd.sgi.com)">
posted on January&nbsp;17, 1999 to SGI's Linux mailing list:
<verb>
We are working on it. We're actually close to getting
the base level system support into the 2.2 release.
Software-only X and OpenGL should follow relatively
shortly, but hardware-accelerated OpenGL is still
some time off. See www.precisioninsight.com for
news about hardware-accelerated OpenGL.
</verb>
For more information see the Documentation/ of Linux kernel versions from
2.2.0 and newer. There is additional information available on the web on
<url url="http://www.linux.sgi.com/intel/">. Note that the SGI/MIPS and
SGI/Intel people are working independently of each other, therefore the
sources in the anonymous CVS on linus.linux.sgi.com may or may not work
for Intel machines; we don't test this.
<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 would be
capable of running Linux, a port is difficult, since Sony so far hasn't provided
the necessary technical information. This still leaves the question of
whether the port would be worthwhile. So in short,
nothing has happend yet even though many people have shown their interest
in trying Linux on a Playstation so far.
<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>Algorithmics P4032<p>
The Algorithmics P4032 port is at the time of this writing still running
Linux 2.1.36.
<sect2>Algorithmics P5064<p>
The P5064 is basically an R5000-based 64bit variant of the P4032. It's not
yet supported but a Linux port will be quite easy.
<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
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&nbsp;DECstation), codename MAXine
<item>5000/1xx, codename 3MIN
<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 these 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.
<item>5000/200, codename 3MAX
</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 happen ever unless the VAXLinux port comes to a new
life. These are:
<itemize>
<item>5400, codename MIPSFAIR
<item>5500, codename MIPSFAIR2
<item>5800, codename ISIS
</itemize>
The R2000/R3000 support in the Linux/MIPS kernel is a merge of the
DECstation and Baget/MIPS code and isn't yet integrated into the official
Linux/MIPS source tree.
<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&nbsp;NT as OS. MIPS Computer Systems, Inc. itself bought the
Jazz design and marketed it as the MIPS Magnum 4000 series of machines.
Magnum 4000 systems were marketed with Windows&nbsp;NT and RISC/os as
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.
<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.
<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 instance,
the R3000 is a 100% compatible redesign of the R2000, just clocked
faster. Because of their high compatibility, where this document mentions
the R3000, in most cases the same facts also apply to the R2000.<p>
The R3000A is basically an R2000 plus an R3010 FPU
and 64k cache running at up to 40Mhz and integrated into the same chip.
Support for the R3000 processor is currently in the works by various
people. <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 which haven't yet been integrated
into the official Linux/MIPS sources.
<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 you're reading the wrong document.<p>
The R6000 is currently not supported. It is a 32-bit MIPS ISA 2 processor
and a pretty interesting and weird piece of silicon. It was developed
and produced by a company named <sl>BIT Technology</sl>. Later NEC took
over the semiconductor production. It was built in ECL technology, the
same technology that was and still is being used to build extremely fast
chips like those used in some Cray computers. The processor had its
TLB implemented as part of the last couple of lines of the external
primary cache, a technology called <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 working as well.<p>
Not supported are R4000MC and R4400MC CPUs (that is multiprocessor systems)
as well as R5000 systems with a CPU controlled second level cache. This
means where the cache is controlled by the R5000 itself in contrast to some
external external cache controller. The difference is important because,
unlike other systems, especially PCs, on MIPS the cache is architecturally
visible and needs to be controlled by software.<p>
Special credit goes to <htmlurl url="mailto:grim@zigzegv.ml.org"
name="Ulf Carlsson (grim@zigzegv.ml.org)"> 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,
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. Its cache and
TLB architecture is pretty different from the other members of the MIPS
family. It was born as a hack to get the floating point crown
back to Silicon Graphics before the R10000 is finished.
<sect2>R10000<p>
The R10000 is currently unsupported because the Linux/MIPS developers
don't have an R10000 machine.
<sect>Linux distributions.<p>
<sect1>RedHat<p>
For MIPSeb, there's Rough Cuts Linux, previously known as Hard Hat Linux,
which is most of Red Hat Linux 5.1 ported for MIPSeb. You can get this at
<url url="ftp://ftp.linux.sgi.com/pub/hardhat">.
It is also bundled along with M68k, UltraSparc and PowerPC in a package
called "Rough Cuts" pressed by Red Hat, and available wherever Red Hat
products are sold. This is a very convenient way to get it without having
to download 280MB. You can order Rough Cuts directly from Red Hat at
<url url="http://www.redhat.com/product.phtml/RC1000">.
As well, there's a distribution based on Red Hat 5.2 that's targetting the
Cobalt Qubes; those binaries will work perfectly on other MIPSel
architectures available at
<url url="ftp://intel.cleveland.lug.net/pub/Mipsel">.
<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.
<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://ftp.linux.sgi.com" name="ftp.linux.sgi.com"><p>
This server should satisfy almost all your Linux/MIPS related ftp desires.
Really.
<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 these ftp servers there is a list of mirror sites you may
want to use for faster access.
<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@linus.linux.sgi.com:/cvs login
(Only needed the first time you use anonymous CVS, the password is "cvs")
cvs -d :pserver:cvs@linus.linux.sgi.com:/cvs co <repository>
</verb>
where you insert linux, libc, or gdb for &lt;repository>.
The other important CVS archive of the Linux community is vger.rutgers.edu
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 how to access
them see <url url="http://cvs.on.openprojects.net/">. The modules
which are of interest are &ldquo;linux&rdquo;, &ldquo;modutils&rdquo;,
&ldquo;pciutils&rdquo;, &ldquo;netutils&rdquo;.
<sect1>Web servers.<p>
The two primary anonymous web servers for Linux/MIPS are
<descrip>
<tag><htmlurl url="ftp://www.linux.sgi.com" name="www.linux.sgi.com"><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><htmlurl url="ftp://lena.fnet.fr" name="lena.fnet.fr"><p>
This server is currently pretty outdated; it's included here mostly for
completeness.
</descrip>
All these servers have mirrors scattered all over the world; you may want to
use one for best performance.
<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 non-SGI related communication of all
kinds. Subscription is handled by a human; send your subscription requests
to <htmlurl url="mailto:linux-mips-request@fnet.fr"
name="linux-mips-mips@fnet.fr">. You can unsubscribe from this mailing
list by sending <em>unsubscribe &lt;your-email-address&gt;</em> to the same
address.
<tag><htmlurl url="mailto:linux@engr.sgi.com"
name="linux@engr.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@engr.sgi.com"
name="Majordomo (majordomo@engr.sgi.com)">; just send an email with the
words <em>subscribe linux-mips</em>. In order to unsubscribe send
<em>unsubscribe linux-mips</em>. Note that you have to be subscribed if you
want to post; the growth of spam forced us into that policy.
<tag><htmlurl url="mailto:linux-mips@vger.rutgers.edu"
name="linux-mips@vger.rutgers.edu"><p>
This mailing list has only very low traffic as most people tend to use one
of the above mailing lists. Subscription is handled via
<htmlurl url="mailto:majordomo@vger.rutgers.edu"
name="Majordomo (majordomo@vger.rutgers.edu)">; just send an email
with the words <em>subscribe linux-mips</em>. In order to unsubscribe send
<em>unsubscribe linux-mips</em>.
</descrip>
<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 (&amp;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 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 relativly easy. Interested hackers should contact
<htmlurl url="mailto:ralf@gnu.org" name="Ralf B&auml;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.
<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&nbsp;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. It has been primarily developed in order
to analyze undocumented systems. Pandora includes a dissassembler,
memory dump functions and more. If you only want to use Linux there is
no need to install Pandora. It's small though.
<sect>Loadable Modules<p>
Using modules on Linux/MIPS is quite easy; it should work as expected for people who have used
it 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 setup a crosscompiler?<p>
First of all go and download the following source packages:
<itemize>
<item>binutils-2.8.1.tar.gz
<item>egcs-1.0.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>
These 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; we don't care. When installing please install things in the
order binutils, egcs, then glibc. Unless you have older versions
already installed, changing the order <sl>will</sl> fail. The installation
description below mentions a number of patches which you can get from the
respective SRPM packages on <htmlurl url="ftp://ftp.linux.sgi.com"
name="ftp.linux.sgi.com">. However since these SRPM packages are intended
to be compiled natively it's not possible to just rebuild them.
<sect1>Diskspace requirements<p>
For the installation you'll have to choose a directory for installation.
I'll refer to that directory below with &lt;prefix>. To avoid a certain
problem it's best to use the same value for &lt;prefix> as your native gcc. For
example if your gcc is installed in /usr/bin/gcc then choose /usr for
&lt;prefix>. You must use the same &lt;prefix> value for all the packages
that you're going to install.<p>
During compilation you'll need about 31mb diskspace for binutils; for
installation you'll need 7mb diskspace for on &lt;prefix>'s
partition. Building egcs requires 71mb and installation 14mb. GNU libc
requires 149mb diskspace during compilation and 33mb for installation.
Note these numbers are just a guideline and may differ significantly for
different processor and operating system architectures.
<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 crosscompiler correctly you have to know the byte
order of the crosscompiler target. If you don't already know, check
the section <ref id="hardware-platforms" name="Hardware Platforms"> for your
machine's byteorder.
<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 &lt;cpu>-&lt;company>-&lt;os>
or even &lt;cpu>-&lt;company>-&lt;kernel>-&lt;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 crosscompilation 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'd
otherwise have to be changed for crosscompilation.<p>
I'll refer to the target configuration name below with &lt;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 very easily. On certain machines using GCC 2.7.x as
compiler is known to dump core. This is a known bug in GCC and can be fixed
by upgrading to GCC 2.8.1 or egcs.
<sect1>Assert.h<p>
Some people have an old assert.h headerfile installed, probably a leftover
from an old crosscompiler installation. This file may cause autoconf
scripts to fail silently; it was never necessary and was only installed
because of a bug in older GCC versions. Check to see if the file
&lt;prefix>/&lt;target>/include/assert.h exists in your installation. If
so, just delete the it: it should never have been installed.
<sect1>First installation of egcs<p>
Now the not-so-funny part begins: there is a so-called bootstrap problem.
In our case that means the installation process of egcs needs an already-
installed glibc, but we cannot compile glibc because we don't have a
working crosscompiler yet. Luckily you'll only have to go through this
once when you install a crosscompiler for the first time. Later when you
already have glibc installed things will be much smoother. So now do:
<verb>
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 -d < ../$i; done
./configure --prefix=<prefix> --with-newlib --target=<target>
cd gcc
make LANGUAGES="c"
</verb>
Note that we deliberately don't build gcov, protoize, unprotoize and the
libraries. Gcov doesn't make sense in a crosscompiler 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 LANGUAGES="c" install
</verb>
<sect1>float.h<p>
Another bootstrap problem is that building GCC requires running programs
on the machine for which GCC will generate code, but since a crosscompiler
is running on a different type of machine this cannot work. When building
GCC this happens for the header file float.h. Luckily there is a simple
solution: download the header file from one of the Linux/MIPS ftp servers
or rip it from one of the native Linux/MIPS binary packages. Later when
recompiling or upgrading egcs usually the already-installed float.h file
will do because float.h changes rarely. Install it with:
<verb>
cp float.h <prefix>/<target/<version>/include/float.h
</verb>
where &lt;version> is the internal version number of the egcs version you're
using. For egcs 1.0.2 for example you would use egcs-2.90.27 for
&lt;version>. If not sure - ls is your friend.<p>
<sect1>Installing the kernel sources<p>
Installing the kernel sources is simple. Just place them into some
directory of your choice and configure them
such that some files which are generated by the procedure will be
installed. This works the same as you're used to when configuring the
kernel sources for native compilation. 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. When
configuring you should answer the question ``Are you using a
crosscompiler'', that is the option CONFIG_CROSSCOMPILE, with ``yes''.
When you're done with configuring type make clean; make depend; make.
The last make command will generate the header file &lt;linux/version.h>
which compiling some programs depends on. This file is
generated right at the beginning of the make command, so if
you're not interested in actually building a kernel you may interrupt
the compilation after this file has been built. It may be a good idea,
however, to compile the kernel as a test for your newly-built crosscompiler.
If you only want the crosscompiler for building the kernel, you're done.
Crosscompiling libc is only required to be able to compile user
applications.
<sect1>Installing GNU libc<p>
Do:
<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 &lt;somedir>
from which we'll move the parts we need for crosscompilation into the
actual target directory:
<verb>
make install_root=<somedir> install
</verb>
Now cd into &lt;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 systems 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 crosscompiler installation can be:
<verb>
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 < ../$i; done
./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. All you have left to do now is to reinstall
float.h, which has been overwritten by the last make install command.
You'll have to do this every time you reinstall egcs as a crosscompiler.
If you think you don't need the Objective&nbsp;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&nbsp;C or F77 compilers?<p>
The answer to this question largely depends on your use of your crosscompiler
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&nbsp;C and
F77 compilers. You must, however, build the C++ compiler, because building
the libraries included with the egcs distribution requires C++.
<sect1>GDB<p>
Building GDB as crossdebugger 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 serial. 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, published 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 tried to write a readable and comprehensive explanation
and account of the wide range of MIPS CPUs available, and should be very
helpful for anyone programming MIPS who isn't insulated by someone else's
operating system. And 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: &ldquo; ... this book is the best combination of
completeness and readability of any book on the MIPS architecture
...&rdquo;
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
&dollar;50 in the US, &pound;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, published by Morgan Kaufmann,
ISBN&nbsp;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
&ldquo;embedded&rdquo; products this book was meant to partner.
<sect1>Computer Architecture - A Quantitative Approach<p>
authors Hennessy & Patterson, published Morgan Kaufmann,
ISBN&nbsp;1-58860-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.
<sect>Linux/MIPS news<p>
Some of this chapter is pretty historic ...
<descrip>
<tag>04-Dec-98<p>
Ariel Faigon announces that SGI has joined Linux International.
<tag>13-Oct-98<p>
Ralf B&auml;chle fixes the support for R4000SC / R4400SC CPUs.
<tag>12-Oct-98<p>
Vladimir Roganov reports that his R3000 system is now stable enough to
compile GDB.
<tag>03-Oct-98<p>
Harald K&ouml;rfgen reports that his DECstation 5000/133 is now running
single user. Congratulations!
<tag>29-Sep-98<p>
Ralf starts rewriting this FAQ to fit with reality.
<tag>10-Jun-98<p>
ftp.linux.sgi.com now offers anonymous CVS access.
<tag>01-Feb-98<p>
First commercial Linux/MIPS based product accounced.
<tag>26-Jan-98<p>
One more timewarp in this list because the maintainer is lazy^H^H^H^H
busy coding. The driver for the NCR53c8xx has been modified and has been
successfully tested with several machines, most notably the SNI RM200. Even
better, the initial version seems to be reliable.<p>
Already some time ago Thomas Bogend&ouml;rfer implemented the necessary
changes to the NCR53C9x driver aka ESP driver, so there is now SCSI support
for the builtin hostadapters in the Mips Magnum 4000, Olivetti M700-10 and
Acer PICA.
<tag>28-Nov-97<p>
First public release of X11 client binaries.
<tag>30-Aug-97<p>
Duh, time warp in this page once again. A lot has happend in the meantime
and the maintainer of this pages is a lazy person that rather prefers to
code and hack than write docs...<p>
SGI now has its own Linux/MIPS server reachable as http://www.linux.sgi.com,
with lots of SGI specific information and many links. The server is also reachable
under ftp.linux.sgi.com. In addition to binaries, sources and docs specific
to Silicon Graphic machines this server also has all the other Linux/MIPS
stuff in stock. Only available on this server is the developers' cvs archive
for download. Sorry, no anonymous CVS yet.<p> Silicon Graphics has supported
some of the Linux key developers' work on Linux/MIPS with hardware. As a
result the work is now advancing more quickly and Ralf is no longer the lone
workhorse ...<p> Already available for some time the Indy port is now in
the standard kernel source tree.<p> Long missing, but finally there: Thomas
Bogendoerfer contributed patches to the NCR53C9x driver for Mips Magnum 4000,
Olivetti M700 and Acer PICA.<p> Many more packages of a RedHat port to MIPS
are now available for ftp download. Installing is still more a thing for
experts ... but we're working on it!<p> Eeecmacs lovers will be pleased to
hear that this FAQ has been edited by Emacs running on a Linux/MIPS machine.
<tag>6-May-97<p>
David Monro releases version 1.01 of bfsd. bfsd is a daemon that can be
used to boot the machines built by Mips Computersystems, Inc. over a
network.
<tag>10-Jun-96<p>
Release of Linux/MIPS kernel 2.0.4. This release features a partially
rewritten signal handler that should match POSIX.1.
<tag>3-Jun-96<p>
First release of shared libraries for Linux/MIPS based on GNU libc snapshot
960619.<p>
Release of Linux/MIPS kernel 2.0.1.<p>
<tag>25-May-96<p>
David S. Miller starts working on SGI support at Silicon Graphics.<p>
<tag>20-May-96<p>
Release 1.3.98 of the kernel adds support for the SNI RM200 PCI.<p>
<tag>27-Mar-96<p>
Linux/MIPS works as NFS server. <p>
The IDE CD driver now also supports Linux/MIPS.
<tag>24-Mar-96<p>
Added reference to literature available online form SGI to the FAQ.<p>
<tag>23-Mar-96<p>
New chapter in the FAQ about the ARC standard.
<tag>27-Jan-96<p>
Release of Milo 0.26 and a kernel patch to use it. This release passes
parameters to the kernel in a completly different way that makes porting
Linux/MIPS to another architecture a lot easier.
<tag>24-Jan-96<p>
Release of crosscompiler binaries based on the FSF's Binutils version 2.6.
This release brings lots of new features and many bugfixes.
<tag>21-Jan-96<p>
Warner Losh started working on a port of Linux/MIPS to Deskstation rPC44.
<tag>20-Jan-96<p>
Linux/MIPS kernel updated to version 1.3.58.<p>
Patch gcc-2.7.2-1.diffs.gz has been released.<p>
Patch binutils-2.6-1.diffs.gz has been released. This patch contains lots of
bugfixes. The Linux kernel Makefiles will automatically detect whether
Binutils 2.6 or an older version is installed and use the new features
resulting in a much smaller kernel executable which is especially useful for
bootdisks.<p>
<tag>15-Jan-96<p>
Release of a complete root and /usr filesystem that can be NFS mounted to use
a Linux/MIPS system as a diskless client. A native development kit based on
GCC 2.7.2, Binutils 2.6 and GNU libc snapshot 951218 is included as well as
many of the standard utilities.
<P>
<tag>25-Dec-95<p>
Linux/MIPS boots off an NFS filesystem as a diskless client. This also means
that the rest of Linux/MIPS networking is operational now.
<tag>7-Jan-95<p>
Soft-N-Hard GMBH and SNI sign a contract. SNI will loan an RM200
to Soft-N-Hard for porting Linux/MIPS to it.
<tag>22-Sep-95<p>
The Linux/MIPS FTP archive and mailing list have been moved to fnet.fr.
(There is much more news I currently have no time to document)
<tag>18-Jul-95<p>
New crossdevelopment tools released. GCC-2.6.3-2 and Binutils-2.5.2-2 for
Linux/i386 need kernels with ELF support and libc-5.0.9 installed. The new
crossdev tools are required for Linux/MIPS kernels above 1.2.9. A.out
versions of the crossdev tools will follow soon.
<tag>14-Jul-95<p>
We have a working shell!
<tag>12-Jul-95<p>
Patches 2.6.3-2 for Linux/MIPS GCC released. This compiler better complies
with the MIPS standard of symbol names.
<tag>10-Jul-95<p>
Linux/MIPS kernel 1.2.9 released.
<tag>9-Jun-95<p>
Milo 0.24 released. This version features improved machine type detection and
many cleanups and bugfixes.
<tag>24-May-95<p>
Linux/MIPS kernel 1.2.8 released. This version features many bugfixes and has
the Magnum 4000 specific changes from Linux-1.2.7 integrated.<p>
Milo 0.23 released. This version features built-in support for Olivetti M700
machines. Milo is now split into two binaries: A simple bootloader and a
standalone debugger/monitor with boot capability.<p>
<tag>23-5-95<p>
Linux/MIPS kernel 1.2.7 on Olivetti M700 mounts root file system.<p>
<tag>22-May-95<p>
Linux/MIPS kernel 1.2.7 on Mips Magnum 4000 mounts root file system.<p>
Added NEC RiscStation and RiscServer to target list.<p>
Milo 0.22 successfully tested on NEC RiscStation and RiscServer.
<tag>18-May-95<p>
Linux/MIPS kernel 1.2.7 released. This release features initial
Magnum&nbsp;4000 support and tons of bugfixes.<p>
<tag>12-May-95<p>
Milo 0.22 released. This version contains some cleanups and several
bugfixes.
<tag>5-May-95<p>
The Linux/MIPS archive is now also available from
ftp://ftp.mcc.ac.uk/pub/linux/MIPS.
<tag>3-May-95<p>
Milo 0.21 released. This version features more built-in debugger/monitor
commands and contains some important bug fixes.
<tag>30-Apr-95<p>
Milo 0.20 released. This version features a built-in debugger/monitor
and a lot of new library functions.<p>
Port to Olivetti M700 started.<p>
<tag>26-Apr-95<p>
Linux/MIPS kernel 1.2.6 released.
<tag>13-Apr-95<p>
Milo 0.19 released. This version includes some minor fixes plus initial
support for kernels in ELF format.
<tag>13-Apr-95<p>
Milo 0.18b released.
This version includes support for Mips Magnum 4000. Port to
Mips&nbsp;Magnum&nbsp;4000 started.
<tag>27-Mar-95<p>
Linux/MIPS kernel 1.2.2 released. Kernel now mounts its root file system.
<tag>22-Mar-95<p>
Milo 0.18 released. This version includes support for Deskstation rPC44
systems.<p>
Port to DeskStation rPC44 started.<p>
</descrip>
</article>
View Git Blame Copy Permalink