Algorithmics () make a series of single-board computers for MIPS prototyping, and maintain Linux kernels for all of them: P-6032 is a board for CPUs with 32-bit buses (PMC-Sierra RM5231, NEC Vr43x0, NEC Vr5432, IDT 64x74)P-6064 is for CPUs with 64-bit buses, notably QED's RM70xx and NEC's Vr5500.P-4032 is an older board obsoleted by P-6032; P-5064 is obsoleted by P-6064. Linux kernels for both are probably available, but not up to date.

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 for the P-6032.

An evaluation board for the SiByteTM BCM1250 dual processor SOC (system on chip) and is implemented in the standard ATX form factor. A high performance board. See for details.

The MIPS Technologies Malta board and all its CPU options are supported. See the Developers pages under .

The CobaltentQube product series are low cost headless server systems based on a IDTentR5230. Cobalt has developed its own Linux/MIPS variant to fit the special requirements of the Qube as well as possible. Cobalt kernels are available from Cobalt's ftp site .

The following DECstation models are actively supported: 2100, codename PMAX5000/xx (PersonalentDECstation), codename MAXine5000/1xx, codename 3MIN5000/200, codename 3MAX5000/2x0, codename 3MAX+5900/2x0 (identical to the 3MAX+). These days, most of the work is done by and others. On the Internet, DECstation-related information can be found at .

The DECstation family ranges from the DECstation 2100 with an R2000/R2010 chipset at 12 MHz, to the DECstation 5000/260 with a 60 MHz R4400SC. See the section on Legacy Platforms below for other DEC machines. Note: Other x86 and Alpha-based machines were also sold under the name DECstation.

The Indy is currently the best supported Silicon Graphics machine.

and a team of SGI employees are currently working on a port to the Originent200. 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 Sony Playstation 2 has a Japanese-only port which can be found at .

The older Sony Playstation is based on an R3000 derivative and uses a set of graphics chips developed by Sony themselves. There is no support for this machine.

The Acer PICA is derived from the Mips Magnum 4000 design. It has a R4400PC CPU running at 133MHz or optionally 150MHz plus a 512KB (optionally 2MB) second level cache; the Magnum's G364 gfx card was replaced with a S3 968 based one. The system is supported with the exception of the X server.

The Baget series includes several boxes which have R3000 processors: Baget 23, Baget 63, and Baget 83. Baget 23 and 63 have BT23-201 or BT23-202 motherboards with R3500A (which is basically a R3000A chip) at 25 MHz and R3081E at 50 MHz respectively. The BT23-201 board has VME bus and VIC068, VAC068 chips as system controllers. The BT23-202 board has PCI as internal bus and VME as internal. Support for BT23-201 board has been done by and with a bit of help from . Support for BT23-202 is under development along with Baget 23B which consists of 3 BT23-201 boards with shared VME bus.

Baget 83 is mentioned here for completeness only. It has only 2MB RAM and it's too small to run Linux. The Baget/MIPS code has been merged with the DECstation port. The source for both is available at .

These DECstation models are orphaned because nobody is working on them, but support for them should be relatively easy to achieve. 3100, identical to the 2100 except the R2000A/R2010A @ 16 MHz 5100, codename MIPSMATE, almost identical to the 2100 but with an R3000/R3010 chipset.

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: 5400, codename MIPSFAIR5500, codename MIPSFAIR25800, codename ISIS

These two machines are almost completely identical. Back during the ACE initiative, Olivetti licensed the Jazz design and marketed the machine with WindowsentNT 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 WindowsentNT and RISC/os as the operating systems.

The firmware on the machine depended on the operating system which was installed. Linux/MIPS supports only the little endian firmware on these two types of machines. Since the M700-10 was only marketed as an NT machine, all M700-10 machines have this firmware installed. The MIPS Magnum case is somewhat more complex. If your machine has been configured big endian for RISC/os, then you need to reload the little endian firmware. This firmware was originally included on a floppy with the delivery of every Magnum. If you don't have the floppy anymore you can download it via anonymous ftp from .

It is possible to reconfigure the M700 for headless operation by setting the firmware environment variables ConsoleIn and ConsoleOut to multi()serial(0)term(). Also, try the command listdev which will show the available ARC devices.

In some cases, like where the G364 graphics card is missing but the console is still configured to use normal graphics, it will be necessary to set the configuration jumper JP2 on the board. After the next reset, the machine will reboot with the console on COM2.

The MIPS Magnum 4000SC is the same as a Magnum 4000 (see above) with the exception that it uses an R4000SC CPU.

The NEC uniprocessor machines are OEM Acer PICA systems, see that section for details. The SMP systems are different from that. The Linux/MIPS developers have no technical documentation as necessary to write an OS. As long as that does not change, this will pretty much stay a show- stopper, preventing a port to NEC's SMP systems.

The Netpower 100 is apparently an Acer PICA in disguise. It should therefore be supported but this is untested. If there is a problem then it is probably the machine detection.

The Nintendo 64 is R4300-based game console with 4MB RAM. Its graphics chips were developed by Silicon Graphics for Nintendo. Right now this port has pipe dream status and will continue to be in that state until Nintendo decides to publish the necessary technical information. The question remains as to whether porting the Linux/MIPS code to this platform is a good idea.

This machine is very similar to the Indy, the differences are that it doesn't have a keyboard or graphics card, but has an additional SCSI WD33C95-based adapter. This WD33C95 hostadapter is currently not supported.

This machine is only being mentioned here because people have occasionally confused it with Indys or the Indigoent2. The Indigo is a different R3000-based architecture however, and is yet unsupported.

This machine is the successor to the Indigo and is very similar to the Indy. It is now supported, but is lacking in several areas. You will have to use serial console. If you have an Indigo2 and still want to run Linux on it, contact either or .

The Onyxent2 is basically an Originent2000 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 Originent2000 configuration.

This is a very old series of R3000 SMP systems. There is no hardware documentation for these machines, few of them even exist anymore, and the hardware is weird. In short, the chances that Linux will ever run on them are approximating zero. Not that we want to discourage any takersent...

In contrast to the RM200 (see below), this machine has EISA and PCI slots. The RM200 is supported with the exception of the availability of the onboard NCR53c810A SCSI controller.

If your machine has both EISA and PCI slots, then it is an RM200C (please see above). Due to the slight architectural differences of the RM200 and the RM200C, this machine isn't currently supported in the official sources. has managed to get his RM200 working partially, but the patches haven't yet been included in the official Linux/MIPS sources.

The RM300 is technically very similar to the RM200C. It should be supported by the current Linux kernel, but we haven't yet received any reports.

The RM400 isn't supported.

This machine is a OEM variant of the SGI Indigo and therefore also unsupported.

The Linux VR project is porting Linux to devices based on the NEC VR41xx microprocessors. Many of these devices were originally designed to run WindowsentCE. 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 .

Similar to the VR41xx, devices with these processors were originally intended for running WindowsentCE. However, there are working kernels with basic drivers for Sharp Mobilon and the Compaq C-Series. Support for more devices is under construction. The code is part of the Linux VR project and as such more information can be found at .

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 for further information.

As the name already implies, this machine is a member of Digital Equipment's VAX family. It's mentioned here because people often confuse it with Digital's MIPS-based DECstation family due to the similar type numbers. These two families of architectures share little technical similarities. Unfortunately, the VaxStation, like the entire VAX family, is currently unsupported.

This is actually an x86-based system, therefore not covered by this FAQ. There is some limited Linux support available for the older Visual Workstations. The current series of Visual Workstations is an officially supported SGI product. Please see and for more information.

These are very old machines, 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.

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.

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.

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):

Exception: entvector=UTLB Missent Status register: 0x300004803entCU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IEent Cause register: 0x8008entCE=0,IP8,EXC=RMISSent Exception PC: 0x881385cc, Exception RA: 0x88002614 exception, bad address: 0x47c4 Local I/O interrupt register 1: 0x80 entVR/GIO2ent Saved user regs in hex (entgpda 0xa8740e48, ent_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

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:

LINKFLAGS = -static -N

to:

LINKFLAGS = -static

entent 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.

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.

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 WindowsentNT.

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 .

collect2: ld terminated with signal 6 [Aborted] This is a known bug in older binutils versions. You will have to upgrade to binutils 2.8.1 plus very current patches.

Old PROM versions don't know about the ELF binary format which the Linux kernel normally uses, so Linux cannot boot directly. This results in error messages similar to this one: entent boot -f linux root=/dev/sda1 Cannot load scsi(0)disk(1)rdisk(0)partition(8)/linux. Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC. Unable to load linux: ``linux'' is not a valid file to boot. entent

The preferable solution for this is of course a PROM upgrade but that isn't available for all systems.

For systems which still have the sash of IRIX 5 installed it is alternativly possible use Sash to boot the kernel. Sash knows how to load ELF binaries and doesn't care if it's an IRIX or Linux kernel. Simply type ``Sash'' to the PROM monitor. You'll get another shell prompt, this time from Sash. Now launch Linux as usual.

Sash can read EFS or XFS filesystems or read the kernel from BOOTP / TFTP.

Using the elf2ecoff tool that is shipping with the kernel source you can convert an ELF binary into ECOFF. Or when building a kernel just run the ``make vmlinux.ecoff'' which will produce an ECOFF kernel.

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 ent /proc/sys/net/ipv4/ipentnoentpmtuentdisc" as root on your boot server.

This may happen if the TFTP server is using a local port number of 32768 or higher which usually happens if the TFTP server is running Linux 2.3 or higher. This problem may be circumvented by doing a "echo 2048 32767 ent /proc/sys/net/ipv4/ipentlocalentportentrange" on the server.

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.

This problem has two possible solutions. First make sure you actually have a driver for the console of your system configured. If this is the case and the problem persists you probably got victim of a widespread bug in Linux distributions and root filesystems out there. The console of a Linux systems should be a character device of major id 5, minor 1 with permissions of 622 and owned by user and group root. If that's not the case, cd to the root of the filesystem and execute the following commands as root: rm -f dev/console mknod --mode=622 dev/console You can also do this on a NFS root filesystem, even on the NFS server itself. However note that the major and minor ids are changed by NFS, therefore you must do this from a Linux system even if it's only a NFS client or the major / minor ID might be wrong when your Linux client boots from it.

Various descriptions of the installation procedure use IRIX in order to partition disks. This was required at the time of their writing as there were no native partiting tools available. Now disks can be partitioned using the IRIX disklabel mode which can be selected in the expert menu of newer fdisk versions. The volume header can be manipulated using dvhtool. Note dvhtool usage is different from IRIX.

IRIX as secondary operating systems can still be handy as it may reduce the need to fiddle with ramdisks or nfs-root during installation. Just one word of warning though: Be careful to not point IRIX fx(8) to disks that don't don't contain an IRIX disklabel if you want to retain the content - IRIX may damage the content of that disk without asking!

Yes. Just make sure you read the warning about IRIX's fx(8) in above paragraph.

entgpentdisp is a magic symbol used with PIC code on MIPS. Be happy, this error message saved you from crashing your system. You should use the same compiler options to compile a kernel module as the kernel makefiles do. In particular the options -mno-pic -mno-abicalls -G 0 are important.

Make sure that the kernel you're using includes the appropriate driver for a serial interface and serial console. Set the console ARC environment variable to either the value d1, or d2 for Indy and ChallengeentS depending on which serial interface you're going to use as the console.

If you have the problem that all kernel messages appear on the serial console on boot-up, but everything is missing from the point when init starts, then you probably have the wrong setup for your /dev/console. You can find more information about this in the Linux kernel source documentation which is in /usr/src/linux/Documentation/serial-console.txt if you have the kernel source installed.

On bootup, the kernel on the Indy will report available memory with a message like: Memory: 27976k/163372k available (1220k kernel code, 2324k data) The large difference between the first pair of numbers is caused by a 128MB area in the Indy's memory address space which mirrors up to the first 128MB of memory. The difference between the two numbers will always be about 128MB and does not indicate a problem of any kind. Kernels since 2.3.23 don't count this 128MB gap any more.

Several people have reported these problems with their machines after upgrading them typically from surplus parts. There are several PROM versions for the Indy available. Machines with old PROM versions which have been upgraded to newer CPU variants, like a R4600SC or R5000SC module, can crash during the self test with an error message like: Exception: entvector=Normalent Status register: 0x30004803entCU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IEent Cause register: 0x4000entCE=0,IP7,EXC=INTent Exception PC: 0xbfc0b598 Interrupt exception CPU Parity Error Interrupt Local I/O interrupt register 1: 0x80 entVR/GIO2ent CPU parity error register: 0x80bentB0,B1,B3,SYSAD_PARent CPU parity error: address: 0x1fc0b598 NESTED EXCEPTION #1 at EPC: 9fc3df00; first exception at PC: bfc0b598 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.

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.

The building procedure of Milo is described, in detail, in the README files in the Milo package. Since Milo has some dependencies to kernel header files which have changed over time, Milo often cannot be built easily. However, the Milo distribution includes binaries for both Milo and Pandora. Building Milo is not trivial; unless you want to modify Milo yourself the urgent recommendation is to use the binaries shipping in the Milo tarball.

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.

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: 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

And this is the list of packages for little endian targets: 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

For 64-bit MIPS kernels, there is only one package available right now: egcs-mips64-linux-1.1.2-2.i386.rpm

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++, ObjectiveentC and Fortranent77 compilers. The Intel binaries have been linked against GNU libc 2.1, so you may have to install that as well when upgrading.

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.

First of all, go and download the following source packages: binutils-2.8.1.tar.gzegcs-1.1.2.tar.gzglibc-2.0.6.tar.gzglibc-crypt-2.0.6.tar.gzglibc-localedata-2.0.6.tar.gzglibc-linuxthreads-2.0.6.tar.gz You can obtain these files from your favorite GNU archive or . Furthermore, you'll need patches. The unbundled patch files aren't always up-to-date and additional, not MIPS-specific, patches may be required for building. Note that the unbundled patch files also use a different revision numbering and it is therefore recommended that you obtain the source and patches from the RPM packages distributed on .

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 will fail.

For the installation, you'll have to choose a directory where the files will be installed. I'll refer to that directory below with entprefixent. To avoid a particular problem, it's best to use the same value for entprefixent as your native gcc. For example, if your gcc is installed in /usr/bin/gcc, then choose /usr for entprefixent. You must use the same entprefixent value for all the packages that you're going to install.

During compilation, you'll need about 31MB disk space for binutils. For installation, you'll need 7MB disk space on entprefixent'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.

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.

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 for your machine's byte order.

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 entcpuent-entcompanyent-entosent, or even entcpuent-entcompanyent-entkernelent-entosent. 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 must 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.

I'll refer to the target configuration name below with enttargetent.

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: gzip -cd binutils-entversionent.tar.gz | tar xf - cd binutils-entversionent patch -p1 ent ../binutils-entversionent-mips.patch ./configure --prefix=entprefixent --target=enttargetent make CFLAGS=-O2 make install

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.

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 entprefixent/enttargetent/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.

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 CONFIGentCROSSCOMPILE 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 entprefixent/enttargetent/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.

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: gzip -cd egcs-1.1.2.tar.gz | tar xf - cd egcs-entversionent patch -p1 ent ../egcs-1.1.2-mips.patch ./configure --prefix=entprefixent --with-newlib --target=enttargetent make SUBDIRS="libiberty texinfo gcc" ALL_TARGET_MODULES= \ CONFIGURE_TARGET_MODULES= INSTALL_TARGET_MODULES= LANGUAGES="c"

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: make SUBDIRS="libiberty texinfo gcc" INSTALL_TARGET_MODULES= \ LANGUAGES="c" install

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.

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.

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. With this warning given, here's the recipe: 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 ent ../glibc-2.0.6-mips.patch mkdir build cd build CC=enttargetent-gcc BUILD_CC=gcc AR=enttargetent-ar RANLIB=enttargetent-ranlib \ ../configure --prefix=/usr --host=enttargetent \ --enable-add-ons=crypt,linuxthreads,localedata --enable-profile make You now have a compiled GNU libc which still needs to be installed. Do not 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 entsomedirent from which we'll move the parts we need for cross-compilation into the actual target directory: make install_root=entsomedirent install Now cd into entsomedirent and finally install GNU libc manually: cd usr/include find . -print | cpio -pumd entprefixent/enttargetent/include cd ../../lib find . -print | cpio -pumd entprefixent/enttargetent/lib cd ../usr/lib find . -print | cpio -pumd entprefixent/enttargetent/lib 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: cd ../info gzip -9 *.info* find . -name \*.info\* -print | cpio -pumd entprefixent/info If you're not bootstrapping, your installation is now finished.

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: gzip -cd egcs-entversionent.tar.gz | tar xf - cd egcs-entversionent patch -p1 ent ../egcs-1.1.2-mips.patch ./configure --prefix=entprefixent --target=enttargetent make LANGUAGES="c c++ objective-c f77" 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: make LANGUAGES="c c++ objective-c f77" install You're almost finished. If you think you don't need the ObjectiveentC or F77 compilers, you can omit them from above commands. Each will save you about 3MB. Do not build gcov, protoize, or unprotoize.

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 ObjectiveentC and F77 compilers. You must, however, build the C++ compiler, because building the libraries included with the egcs distribution requires C++.

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.

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.

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.

The kernel configuration process doesn't make a too strong attempt at making wrong configuration impossible. So for example an SGI Indy may never have a framebuffer, yet it's possible to enable it which later on will result in a compile error. This situation will improve in the future when CML2 will be the standard kernel configuration language; for 2.2 and 2.4 you still will have to care of your steps yourself.

The kernel has been carefully developped to ensure crosscompilation on a non-MIPS system is possible. Once you've managed to get around the cliff of setting up a crosscompiler crosscompiling is easy. To do so you have two options. First you can pass CROSSentCOMPILE=enttargetent- (note the trailing dash) as an additional argument to your make invocations where you choose one of mips-linux, mipsel-linux, mips64-linux or mips64el-linux depending if your target is big or little endian, 32-bit or 64-bit. An alternate way is setting the CONFIGentCROSSCOMPILE configuration option. The kernel will then automatically choose the right value for CROSSentCOMPILE which will keep make command lines a bit simpler.

By default the Linux/MIPS kernel source tree is configured to build a 32-bit target. If you want to build a 64-bit kernel you'll have pass the additional ARCH=mips64 argument to all you make invocations.