Before reporting a bug please make sure the answer to your problem isn't already in this document. You may also want to use the search engine at http://www.linux-mips.org/archives/linux-mips to search the mailing list archives for references to your problem.
If this all didn't turn up anything, it seems time to write a bug report. Inexperienced kernel bug reporters should read REPORTING-BUGS (since Linux 2.1 this file ships as part of the kernel) to ensure the bug report contains all the information needed. In particular the step of decoding Ooops messages is important; without it's hard if possible at all to make sense from the numbers in the register dump. For most problems it's important to know exactly what system you're using. Remember a system consists of more than just a processor and MIPS systems tend to differ much more than Intel systems. In general you should not post large files such as System.map or others until you've been explicitly asked to. Even if you think you've discovered a generic kernel bug you may still want to cc linux-mips@linux-mips.org, just in case.
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.
Not all machines supported by Linux/MIPS are equally well maintained; in general those that are used by more users experience more scrutiny and therefore are better maintained.
Kernels downloaded from kernel.org in general don't have uptodate MIPS support so they may not compile at all or work as well as those from linux-mips.org - where optimal MIPS support is the only focus.
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: <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
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
>> 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.
IP22 uses the Dallas DS1286 RTC chip to store time and firmware variables. This chip contains a builtin battery for ten years but by now this decade is almost over and experience has shown that some of these RTC batteries have a much shorter battery life, so the RTCs start becoming forgetful. Software may also accidentally have overwritten the RTC's content.
If you have determined that a defective RTC chip is the cause of the problem you can get a new RTC from http://www.maxim-ic.com/ or other sources. Be paranoid, make sure you don't get a part that has been sitting on a shelf for long years.
This is how to reprogram the RTC chip. Assuming your ethernet address is aa:bb:cc:dd:ee:ff
fill -w -v 0xaa 0xbfbe04e8
fill -w -v 0xbb 0xbfbe04ec
fill -w -v 0xcc 0xbfbe04f0
fill -w -v 0xdd 0xbfbe04f4
fill -w -v 0xee 0xbfbe04f8
fill -w -v 0xff 0xbfbe04fc
With this command you can verify the content of the chip's NVRAM:
dump -w -x 0xbfbe04e8
Note this will print each byte of the MAC address repeated four times; this is normal an due to the way the chip is used in the Indy.
The MAC address is also the system's serial number, so software licenses under IRIX might be bound to it. Also the ethernet standards specify certain meanings for certain values of the 48-bit address. Therefore you should reprogramm the old ethernet address. You may find the MAC address on the sticker on the machine. Below a bar code this sticker only contains a 12 digit hexadecimal number; it's typically located on the backside between the parallel port and and SCSI connectors on the left side and the power supply on the right side. In case this sticker has been lost, you probably also have the number somewhere in the bootmessages of Linux archived by syslogd or maybe a bootpd or dhcpd config file.
If you need to reprogram the ethernet address you will almost certainly have lost all other NVRAM settings, use the PROM shell's setenv -p command for that.
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 Ralf Bächle (ralf@gnu.org).
collect2: ld terminated with signal 6 [Aborted]
This is a known bug in older binutils versions. You will have to upgrade to
at least binutils 2.8.1 plus very current patches.
Old IP22 PROM versions don't know about the ELF binary format which the Linux kernel normally uses, so Linux cannot boot directly. This results in error messages similar to this one:
>> 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.
>>
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.
This problem affects the ARC firmware on SNI RM200 and SGI IP22.
The boot client is replying to the BOOTP packets (may be verified using a packet sniffer like tcpdump or ethereal), but doesn't download the kernel from your BOOTP server. This happens if your boot server is running a kernel of the 2.3 series or higher. The problem may be circumvented by doing a "echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc" as root on the boot server.
This may happen if the TFTP server is using a local port number of 32768 or higher which usually happens if the TFTP server is running Linux 2.3 or higher. This problem may be circumvented by doing a "echo 2048 32767 > /proc/sys/net/ipv4/ip_local_port_range" on the server.
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 or GNU Parted. 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.
_gp_disp is a magic symbol used with PIC code on MIPS. Be happy, this error message saved you from crashing your system. You should use the same compiler options to compile a kernel module as the kernel makefiles do. In particular the options -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 Challenge S 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: <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
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.
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''.
The need for Milo has been eliminated for all ARC platforms except the RM200C due to it's unusual firmware behavior. On all other platforms an ECOFF or often on more modern firmware also an ELF kernel can be started directly without the need for Milo or an equivalent. On the RM200C Milo 0.27.1 is still required to boot the kernel.
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.
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.
The easiest way to setup a cross-compiler is to just download the binaries from ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/. Serious, over the 8 years of Linux/MIPS history this has been shown to be biggest problem many users have been facing with Linux/MIPS. For Linux/i386 hosts and big endian targets, these are the packages:
binutils-mips-linux-2.13.2.1-1.i386.rpm
egcs-c++-mips-linux-1.1.2-4.i386.rpm
egcs-g77-mips-linux-1.1.2-4.i386.rpm
egcs-libstdc++-mips-linux-2.9.0-4.i386.rpm
egcs-mips-linux-1.1.2-4.i386.rpm
egcs-objc-mips-linux-1.1.2-4.i386.rpm
And this is the list of packages for little endian targets:
binutils-mipsel-linux-2.13.2.1-1.i386.rpm
egcs-c++-mipsel-linux-1.1.2-4.i386.rpm
egcs-g77-mipsel-linux-1.1.2-4.i386.rpm
egcs-libstdc++-mipsel-linux-2.9.0-4.i386.rpm
egcs-mipsel-linux-1.1.2-4.i386.rpm
egcs-objc-mipsel-linux-1.1.2-4.i386.rpm
For 64-bit MIPS kernels, there are only two packages available right now:
egcs-mips64-linux-1.1.2-4.i386.rpm
and for little endian 64-bit systems:
egcs-mips64el-linux-1.1.2-4.i386.rpm
It's not necessary that you install all of these packages as most people can just omit the C++, Objective C and Fortran 77 compilers. The Intel binaries have been linked against GNU libc 2.2, so you may have to install that as well when upgrading.
The recommended version is binutils 2.13.2.1.
For Linux 2.4 kernels before 2003-05-16 the minimum gcc version required is egcs 1.1.2; later 2.4, 2.5 and 2.6 require gcc 2.95.3 or newer. Using a too old compiler may result in compiler core dumps or silently misscompiled kernels. The better code generation of later tools has little impact on performance of the generated kernel however more recent tools tend to be dramatically slower at generating code, so some people like the maintainer of the MIPS port tend to continue using old compilers in spite of their age.
For compilation of userspace applications and libraries you probably want a much newer compiler; generally 2.95.3 is considered very stable and at the same time reasonably fast. Due to the evolution of the C++ language and ABI C++ users probably may have special constraints in selection of their compiler version; a very recent compiler such as gcc 3.2 is probably a good choice.
Note there is no need to use the same compilers for kernel and userspace libraries and applications. You only want to use the same compiler version for all C++ code.
This document still documents how to build glibc 2.0.6 however this version is no longer recommended for new projects. Users who are looking into glibc 2.0.6 due to binary size considerations may want to ucLibc instead. Installing glibc into a crosscompiler environment is not necessary if you only want to build compilers.
uClibc is a very small libc replacement available at http://www.uclibc.org. The MIPS bits can be found at ftp://ftp.realitydiluted.com/linux/MIPS/toolchains.
First of all, go and download the following source packages:
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 <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.
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.
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 Hardware Platforms 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 <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 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 <target>.
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-<version>.tar.gz | tar xf -
cd binutils-<version>
patch -p1 < ../binutils-<version>-mips.patch
./configure --prefix=<prefix> --target=<target>
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.13.2.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 <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.
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.
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-<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"
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 < ../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
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 <somedir>
from which we'll move the parts we need for cross-compilation into the
actual target directory:
make install_root=<somedir> install
Now cd into <somedir> and finally install GNU libc manually:
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
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 <prefix>/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-<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"
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 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.
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++.
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.
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.
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.
For these processors just select the R3000 option. A kernel built for this option will not run on any other processors than R2000 and R3000 family members.
With the exception of the Nevada family these processors are all fully compatible with rescpect to the kernel. Choose the option which matches your processor best for optimal performance.
Linux currently doesn't support the R6000 so this paragraph is entirely theoretical. The R6000 has it's own, rather unique if not odd cache and MMU architecture; it also requires alot of workarounds as it's a quite broken piece of silicon. Therefore a R6000 kernel will not work on any other processor nor will a kernel for another processor work on the R6000.
The Nevada nickname stands for the QED 5230, 5231, R5260, R5261, R5270 etc. family of CPUs. It enables the use of additional instructions which are not supported on other processors therefore you only should choose this opition if you indeed have one of these processors. If you're not sure configure for R4x00 or R5000 (see above) which will result in a kernel which will run on Navada family processors too but not use certain optimizations specific to these processors.
Choose this option only for the Sibyte SB1 processor. A kernel built for this processor will not work on any other processor type nor vice versa.
Choose this option if you want to run Linux on a R10000, R12000 or R14000 system. A kernel built with this option will not work on R4000 or R5000 family processors.
Choose this option if you want to run Linux on a member of the MIPS32 family.
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 CROSS_COMPILE=<target>- (note the trailing dash) as an additional argument to your make invocations where you choose one of mips-linux, mipsel-linux, mips64-linux or mips64el-linux depending if your target is big or little endian, 32-bit or 64-bit.
An alternate and probably easier way is setting the CONFIG_CROSSCOMPILE configuration option. The kernel will then automatically choose the right value for CROSS_COMPILE which will keep make command lines a bit simpler.
By default the Linux/MIPS kernel source tree is configured to build a 32-bit target. If you want to build a 64-bit 2.4.x kernel you'll have pass the additional ARCH=mips64 argument to all you make invocations. In 2.6.x this has become a normal config option.