From LinuxMIPS
Revision as of 00:48, 4 November 2004 by Ralf (talk | contribs)
Jump to: navigation, search

IP22 is Silicon Graphic's software archicture name for the hardware sold as Indy, Indigo 2 and Challenge S. Modulo peripherals these systems are all very similar. Various Linux distributions will easily install on IP22, among them the Debian MIPS port.

Processor Options

Over the years Indy systems have been equipped with a variety of MIPS processor starting with the 100MHz R4000PC over R4000SC, R4400PC, R4400SC, R4600PC, R4600SC, R5000PC and R5000SC. Indigo 2 systems use the same system board as Indys but have only been been made with R4000SC and R4400SC processor modules.

The POWER Indigo 2 is based on the IP26 system board and comes with the R8000 processor. The R8000 is in many ways a unique MIPS processor and currently only partially supported by Linux.

The architecturally very similar Indigo 2 R10000 is based on the IP28 system board and has a MIPS R10000 processor. This system represent a very special case and therefore isn't supported yet by Linux.


IP22 boards have two memory banks; each bank consists of 4 memory modules and if populated must be fully populated with fast page mode 36-bit wide PS/2 style memory modules from 4MB to 32MB size. Memory configurations between 16MB and 256MB are support.

The board in the Indigo 2 is similar but has third memory bank, therefore it's maximum memory configuration is 384MB.

IP26 and IP28 boards also have 3 memory banks each 4 modules but support 64MB memory modules also increasing the maximum memory capacity to 768MB.

Support of more than 384MB memory requieres a 64-bit Linux kernel.

Graphics Options

The Indy comes with the entry level XL graphics which exists in 8-bit and 24-bit variants. The Indigo 2 and Indigo 2 R10000 are equipped with the XZ graphics which is also knows under the name Impact and which isn't Linux supported. Finally the Challenge S which is a headless compact server system.

Storage Options

Challenge S, Indy, Indigo 2 and Indigo 2 R10000 are all equipped with an on-board WD33C93 SCSI controller. In addition to that the Challenge S has a second SCSI hostadapter supporting fast and wide SCSI, the WD33C95. Linux supports the WD33C93 but not he WD33C95.

Networking Options

All IP22 systems come with an onboard Seeq 8003 network controller. The Challenge S being a server system comes with a second 8003.

Booting the kernel fails with PROM error messages

  >> boot bootp()/vmlinux
  73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960
  Setting $netaddres to (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. The elf2ecoff utility which is part of the kernel source allows conversion of an ELF kernel binary into a bootable ECOFF binary as the bootfile. There is also the arcboot utility which is shipping with recent Indy distributions and which as first stage bootloader is able to boot an ELF kernel of an ext2 or ext3 filesystem. Usually arcboot is the preferable solution.

IP22 has forgotten it's ethernet address

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.