[back to collection]

Silicon Graphics O2

(last updated: 17-May-2017)

Operational Status

Configuration

1600SW 17.3" wide-screen LCD monitor

Charcoal keyboard

Charcoal mouse

The current configuration is in its original 'as acquired' condition, except that I have swapped the original 9GB drive with an 18GB drive, then that with a 73GB drive.

Major Events

Still To Do

Description

Acquisition

28-Feb-2008

I investigated BYU's computer surplus sale, and came away with several things, in my case, this SGI O2 system. I was very fortunate to be able to get a complete system, the main chassis, a very nice widescreen LCD monitor (19" maybe, resolution unknown at this point), and both an official SGI keyboard and mouse.

Woohoo! My first UNIX-based graphics workstation!

Cleanup

28-Feb-2008

The system looks to be fairly fresh, though it is 8 years old. The keyboard is very clean with only a hint of wear on the space bar. All other keys are pristine. The main unit and the monitor both show a few very minor scuffs, no doubt a result of the surplus sale preparations. Nothing is broken case-wise. The mouse looks great too.

I cleaned everything in my usual way, wiping the thing down with Windex, disassembling to a reasonable degree and just making sure that the dust is gone, and any accumulated lint is cleaned out. This system was so clean (it looks to have been on very lightly used in it's lifetime) that I didn't bother to even vacuum it first. I simply wiped all the external surfaces, and then removed the major subystems individually, and cleaned them up one at a time.

As I was disassembling the case plastics, I accidentally broke the long locking tab on the case's plastic top. I have super-glued it back together and hope that it will be usable again. Otherwise, the case top will simply fall off if tilted too far from vertical.

During this cleanup process, I took a general inventory. Though I have absolutely no prior experience with SGI gear, it turns out to be fairly straight forward.

Initial Powerup

28-Feb-2008

After a slight, but sufficient (I hoped!), online education, I felt ready to power the system. I plugged in the keyboard, mouse, and LCD Monitor video cable, and AC power cable. I powered up. I was pleased to see the system light up the LCD screen.

The keyboard is responsive as is the mouse. That's good! The LCD screen has only two pixel defects, one always-on blue, the other always-on red. These are only noticable on a black screen. When the background is white or grey, they will not be visible, so I'm not at all concerned and feel very lucky to have snagged this beautiful monitor today.

I let ths system try to boot from the hard disk. Alas, it complains of not finding a 'volume header' on the HDD, so I guess that means the disk has been wiped clean. Argh!

System Software

28-Feb-2008

I was so hoping to have a live OS installed. This system is proprietary, so my OS options are limited. I can try to scrounge up a copy of IRIX (SGI's highly customized UNIX), or try to buy one on eBay. Or, I learned that NetBSD has been ported, but doesn't support the O2's graphics subsystem, but it will work via serial terminal. Or, lastly, I can install Debian, which is reported to support the graphics subsystem.

Well, I sure would like to have the 'official' and appropriate OS for this system, so I'm going to monitor eBay and try P2P sources. There is presently a Canadian seller with a complete IRIX 6.5.28 16-CD distribution on auction. I might try for it, though the opening bid is set at $100!

Operating System Woes

06-Mar-2008

I have scoured the 'net looking for an operating system that I can use, until/unless I can get my hands on IRIX.

In any case, I have learned that there are at least three other OS alternatives for SGI gear: Linux (Debian), OpenBSD, and NetBSD. Unfortunately, both Linux and NetBSD appear to NOT support R10000 (and R12000) based systems, only supporting the R5000 and derivitives CPUs. My R12k (an R10k derivitive) won't work with those, but the OpenBSD folks claim that the OS runs fine with OpenBSD/sgi. Unfortunately, again, none of these system, including OpenBSD, support the onboard graphical video system, and so if I do use OpenBSD, I'll be relegated to using a serial terminal as the console.

Well, I've downloaded the OpenBSD/sgi 4.1 distribution which includes a small mini-root .ISO CD image to boot from. I've burned that image to a CDRW disk, and will give it a go.

According to information in the INSTALL.SGI file, I must change a NVRAM setting to force the console to the serial port. Before I go monkeying with the NVRAM environment variables, here's a list of them as received from BYU:

So, here we are. I can't do a direct boot from the CD, but further reading in the installation how-to (should pay attention!) says to select 'Installation', then specify the CD drive, and viola! It booted!

System Maintenance Menu


1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor


Option? 2


Installing System Software...


Press  to return to the menu.


1) Remote Tape  2) Remote Directory  3)[Local CD-ROM]  X) Local Tape  


*a) Local SCSI CD-ROM drive 4


Enter 1-4 to select source type, a to select the source,  to quit,


or  to start: 


Insert the installation CD-ROM, then press : 


arg 0: pci(0)scsi(0)cdrom(4)partition(8)sashARCS
arg 1: OSLoadOptions=mini
arg 2: ConsoleIn=serial(0)
arg 3: ConsoleOut=serial(0)
arg 4: SystemPartition=pci(0)scsi(0)disk(2)rdisk(0)partition(8)
arg 5: OSLoader=sash
arg 6: OSLoadPartition=pci(0)scsi(0)disk(2)rdisk(0)partition(0)
arg 7: OSLoadFilename=/unix


OpenBSD/sgi Arcbios boot
Boot: pci(0)scsi(0)cdrom(4)partition(0)/bsd.rd
Loading ELF64 file
0xffffffff80100000:0x5db0d0, Start at 0xffffffff80100000
ARCS32 Firmware Version 1.10
SR=34050080
Found SGI-IP32, setting up.
Initial setup done, switching console.
NOTE: TLB code too large, using trampolines
[ using 174576 bytes of bsd ELF symbol table ]


Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California.  All rights reserved.


Copyright (c) 1995-2007 OpenBSD. All rights reserved.  http://www.OpenBSD.org


OpenBSD 4.1 (RAMDISK) #261: Sun Mar 11 06:11:39 MDT 2007
    deraadt@sgi.openbsd.org:/sys/arch/sgi/compile/RAMDISK


real mem = 134217728
rsvd mem = 7020544
avail mem = 106229760
using 1638 buffers containing 6709248 bytes of memory
mainbus0 (root)
cpu0 at mainbus0: MIPS R12000 CPU rev 2.3 270 MHz with R10000 FPU rev 0.0
cpu0: cache L1-I 32KB D 32KB 2 way, L2 1024KB 2 way
macebus0 at mainbus0: crime rev 10.1
clock0 at macebus0: TOD with DS1687, ticker on int5 using count register
macepcibr0 at macebus0: mace rev 1, host system O2
pci0 at macepcibr0 bus 0
ahc0 at pci0 dev 1 function 0 "Adaptec AIC-7880" rev 0x00: irq 9
ahc0: Host Adapter Bios disabled.  Using default SCSI device parameters
scsibus0 at ahc0: 16 targets
sd0 at scsibus0 targ 2 lun 0:  SCSI3 0/direct fixed
sd0: 8682MB, 11474 cyl, 5 head, 309 sec, 512 bytes/sec, 17781520 sec total
cd0 at scsibus0 targ 4 lun 0:  SCSI2 5/cdrom removable
ahc1 at pci0 dev 2 function 0 "Adaptec AIC-7880" rev 0x00: irq 10
ahc1: Host Adapter Bios disabled.  Using default SCSI device parameters
scsibus1 at ahc1: 16 targets
com0 at macebus0: ns16550a, 16 byte fifo
com0: console
com1 at macebus0: ns16550a, 16 byte fifo
mec0 at macebus0: MAC-110 rev 1, address ff:ff:ff:ff:ff:ff
nsphy0 at mec0 phy 8: DP83840 10/100 PHY, rev. 1
rd0: fixed, 8192 blocks
rootdev=0x800 rrootdev=0x1600 rawdev=0x1602
erase ^?, werase ^W, kill ^U, intr ^C, status ^T
(I)nstall, (U)pgrade or (S)hell? s
#

I first exited to the shell prompt so that I could do some poking around on the hard disk. I wanted to confirm whether or not the drive was erased completely, or was just the first sector damaged, or was the drive alive at all. So, I fired up a spare Linux box (Aero-2) did an nfs-mount to it, hoping to dd the sgi's drive contents to a file that I could examine. Here's what I did:

# ifconfig
lo0: flags=8008 mtu 33192
        groups: lo
mec0: flags=8802 mtu 1500
        lladdr 00:fe:e1:ba:d0:a7
        media: Ethernet autoselect
# ifconfig mec0 192.168.1.90
# mount 192.168.1.30:/mnt/windows/DropZone /mnt
# dd if=/dev/sd0c of=/mnt/sgi.dsk

Intersting how the MAC now seems valid! Anyway, the dd command worked for a bit, then the system hung. On the linux system I could see that about 21MB had been transferred before the SGI hung. Using od I scanned the contents:

# od -Ax -h sgi.dsk
00000000 0000 0000 0000 0000 0000 0000 0000 0000 0000
*
1474800
#

So, the disk has been wiped. It's just full of 0s! Well, so be it then. At least it clears up the mystery about why the system won't boot. I guess those BYU techs figured they'd best wipe the disk before selling it to me!

Given that this is the case, there's no reason I shouldn't proceed with an OpenBSD installation, for the fun of it.

OpenBSD Installation

06-Mar-2008

I reset the system and rebooted into the OpenBSD mini-root kernel for installation. I proceeded, using the installation guide, to create the disklabel partitions and install the distribution sets (all but the X stuff), which went fine. Then I rebooted.

The system couldn't load the correct file. Oh yes, I have to change another NVRAM environment variable (from sash to boot):

> setenv OSLoader boot

That worked fine, and the loader starts up, but then complains with some kind of panic. So a no go for now.

Further review of the online sites for OpenBSD (and NetBSD and Linux) indicate that none of these OSs support the R10k/R12k MIPS CPU, so I'm out of luck.

IRIX Installation

16-Mar-2008

Today, I received my package from eBay seller 'acronym1' which included a new 18GB HDD with IRIX 6.5.16 (was supposed to be 6.5.28) already installed, and a set of 12 CDs that should give me the ability to install from scratch again, should I ever need to do that. The CDs are IRIX 6.5.23.

Since the system already has a 'blank' 9GB drive installed, I decided to install from CDs first, before swapping HDDs. After a couple of quaintly frustrating attempts to load up the first INSTALLATION CD on my own, I searched the 'net and found helpful documents at:

http://www.futuretech.blinkenlights.nl/6.5inst.html
http://software.majix.org/irix/install-start.shtml

which shows how to initialize a disk and install IRIX 6.5.x onto just about any SGI system.

Worked like a charm, so I now have a basic IRIX installation. So far, looks like I'm good to go.

Hard disk swap

19-Mar-2008

Today I replaced the original 9GB drive having my own installation of IRIX 6.5.23 with the 18GB drive from the eBay seller. It was supposed to have IRIX 6.5.28 on it, but as it turns out, it is installed with 6.5.16. But since it has all of the IRIX Freeware and other stuff installed, I'm going to keep it in the box.

System troubles

17-Sep-2008

Today, while giving a small demonstration to my friend Kirk, I discovered that the real-time clock had forgotten what the date and time were, and even worse, the system was showing an ethernet address of FF:FF:FF:FF:FF:FF, which prevents the system from connecting to the local area network.

So, I have some problems. I don't know if the Ethernet address will magically come back with a RTC replacement or if they are entirely unrelated. Thinking back to when I first brought the machine home, there were a few times when the ethernet address was read correctly on startup and a few times when it was not. The RTC was clearly losing it at that time, and now all these months later, it's completely gone. The RTC chip is a Dallas DS1687-5 which integrates a 10-year lithium battery. The date code on the chip is 9949, which puts it at about 9 years old. And my guess is that this system has sat unused a good portion of its life, which puts more drain on the RTC battery. So, I'm not surprised that it has failed. According to what I learned doing an internet search, the ethernet address is stored in a Dallas DS2502 which is on the PCI riser card. I just hope that the ethernet address will return with a new RTC chip.

Lost Ethernet MAC

11-Nov-2008

Every once in a while, I turn on the system to see if I can get the Ethernet address read correctly, but no luck. There was just one instance when I did get the address to show, but I was busy trying to clean the connector on the hard disk sled (the disk wasn't spinning up always, now fixed), and so didn't bother to work with it. Since then, in several dozen attempts, I have not been successful. I wonder if the PCI slot/extender, which has the DS2502 ROM on it. is dirty or not making good contact, or if the ROM itself is going bad. I'm considering trying to read the ROM outside of the 02 on some kind of lash-up breadboard. Still thinking that through.

Ethernet revived

24-Dec-2008

I didn't do anything special, except to keep trying once every few days, but the ethernet address is now correctly read on each boot. I've successfully booted up and had a valid ethernet MAC in a every attempt over about a dozen boots. I wonder if it might be due to a good charge on the clock, now that the system has been powered for some time.

73GB hard disk / NetBSD installation

06-Jan-2014

While I have enjoyed using this system from time to time, I have always been concerned about the relatively small size of the hard disk, 18GB. More than half of that disk is already consumed.

While scrounging at the local Deseret Industries thrift store, I came across a pile of 73GB drives still mounted in their storage trays from some kind of data center. I snagged one for just $3.00, and today installed it in the system for a quick look-see. I first want to see what may be on the disk already, and then work out a method to move my 18GB image to this bigger drive, or maybe install from scratch (which requires that I then install all of the various freeware items that are already on the 18GB drive).

I downloaded and burned the latest NetBSD image (6.1.2) for the SGI MIPS machines, which is claimed to now work on the O2 with R10000 processor and also support the CRIME video frame buffer. If this is true, I'll be able to boot to a CD and go from there.

Yes, it's true. I booted with the CD and it utilizes the framebuffer just fine. I followed the instructions in the NetBSD INSTALL notes.

Turns out the new 73GB disk is wiped, just full of 0's, so I can do a couple of things: 1) go ahead and set up the disk for IRIX and move the other disk contents over via an intermediary storage system, OR 2) I can go ahead and install NetBSD, at least for a while, for fun, seeing how it performs on the O2.

I booted the NetBSD 6.1.2 CD and installed the system. Then I made the following changes to the PROM environment:

OSLoadFilename=netbsd (from =/unix)
OSLoader=boot (from =sash)

which allowed the system to auto boot NetBSD.

09-Jan-2014

Over the past couple of days I have been working with NetBSD on this system. Once installed, I occassionaly see messages like:

crime: memory error address 36e94680 status 2040000
crime: cpu error 4 at address 48c09dc

at various addresses. A little web searching suggests it's not serious, just the CPU doing some pre-fetches, which aren't fatal problems. However, just when I start to do something interesting with the machine, like preparing to do some pkgsrc installations or logging in from a remote node, the system will simply freeze, just hang up solid, reboot required.

I'm now convinced that these freezes are related to as-yet unknown issues with the R10000/R12000 processor, which this system has. For all I know, this release of NetBSD may work just great on a R4000/R5000 processor. Maybe I'll try it sometime in one of my Indys.

10-Jan-2014

Given that NetBSD is unreliable on this system, I blanked the hard disk using dd on NetBSD and installed IRIS 6.5.30, using a newly acquired set of overlays.

First, I restored the two PROM variables that I had changed for NetBSD:

OSLoadFilename=unix
OSLoader=sash

Then, I worked through the installation using the 6.5.30 Installation and Overlays, Development Libs, Applications, More Applications CDs. It took me two tries to get the combination of original 6.5 and 6.5.30 update CDs to do the job, but it worked pretty well, and quickly.

Nekoware from nekochan.net

20-Jan-2014

For the past few days I have been toying with various bits of SGI Freeware and Nekochan Freeware. After downloading and installing a handful of items from both sources, I downloaded the whole current set of Nekochan Nekoware and burned it onto 9 CDs. I have plenty of room to hold all of this on the new 73GB drive, so I moved all the .tardist files to /root/nekochan and then learned that if they are all untar'd together, IRIX's Software Manager can manage all of the dependencies more easily.

With that setup in hand, I've been installing a few things here and there. Unfortunately, I'm seeing some installs work then complain upon execution that a lib can't be found, yet the library is in the standard nekoware location, i.e., /usr/nekoware/lib. More experimentation may resolve this.

BTW, during this recent period of activity, the system's ethernet MAC address is still flaky. I have found that if the systems shows ff:ff:ff:ff:ff:ff for the MAC, if I let the system remain powered for some 5 or 10 minutes, it will then often work. I generally press F5 at the powerup prompt and check in the PROM monitor with PRINTENV. If the address is all f's, I wait then just restart the system with the command REBOOT. Repeat as necessary until a good MAC is shown.

Preparing new disk for IRIX

22-Jan-2014

After all of my adventures in the past couple of weeks, I have more or less made a mess of my system configuration, and the contents of the drive. I'm now better educated and am ready to start afresh with a brand spanking new installation of IRIX. And for the experience, I want to first install the base 6.5, then do the upgrade to 6.5.30.

This proved harder than I expected. Whereas before, using the IRIX 6.5.30 cd-set, simply selecting the PROM option INSTALL SOFTWARE would auto-detect that the drive had no disklabel and, more or less, automate the process of it's creation, not so with the earlier install tools from 6.5.

I learned the following, using the base set of 6.5 CDs, after a few false starts:

1) I must initialize the hard disk using some standalone tools:

1-1) Enter PROM command window and start the disk utility with:

> boot -f scsi(0)disk(4)rdisk(0)partition(8)sashARCS scsi(0)disk(4)rdisk(0)partition(7)/stand/fx.ARCS
 [or the shorthand method works too:]
> boot -f dksc(0,4,8)sashARCS dksc(0,4,7)/stand/fx.ARCS

If necessary (since I've seen funny behavior with a previously disklabel'd drive), wipe the drive, at least partially, once fx.ARCS is running, using:

fx> exeercise
fx/exercise> sequential
fx/exercise/sequential: modifier = (rd-only) wr-o
fx/exercise/sequential: starting block# = (0)
fx/exercise/sequential: nblocks = (nnnnnnnnnnn) 143374650 [for 73GB drive]
fx/exercise/sequential: nscans = (1)
 * * * * * * WARNING * * * * * *
about to destroy data on disk dksc(0,2,0)! ok? yes
sequential pass 1: scanning [0, 143374650] (143374650 blocks)
0%....[and so on]

CTRL-C will terminate the exercise early, if desired.

With the disklabel (and potentially all the data) wiped from the drive, I can start with a fresh drive:

1-2) While still running fx.ARCS create the disklabel:

fx/exercise> ..
fx> repartition
fx/repartition> rootdrive
fx/repartition/rootdrive: type of data partition = (xfs)
Warning: you will need to re-install all software and restore user data
from backups after changing the partition layout.  Changing partitions
will cause all data on the drive to be lost.  Be sure you have the drive
backed up if it contains any user data.  Continue? yes
...
fx/repartition> ..
fx> label
fs/label> sync
...
fx/label> ..
fx> exit

Fresh installation of IRIX 6 .5 .30

24-Jan-2014

2) Make sure to have the correct Cds

After the return to the PROM menu, select "Install System Software" and it will show the "Copying installation tools to disk" dialog.

For some reason, after the copy is complete, the screen blacks out and the system does nothing. A reboot will result in a cannot boot message. I wonder if the wide-screen 1600SW monitor is the trouble. Perhaps this old 6.5 doesn't know how to deal with that, and is showing outpout to the built-in VGA port. Something to check out. No, it is not that, I tried it with a VGA monitor and see the same behavior.

Next, I tried my set of 6.5.23 CDs and they boot into inst just fine. Hmmm...this O2 doesn't work with the older version for some reason.

Anyway, I started the installation of 6.5.23. But once inst started, I just put in the 6.5 CDs and it worked!

On this first installation I loaded the first five CDs: - Install Tools - Foundation 1 - Foundation 2 - Applications - ONC3/NFS

Then I entered the following:

inst> keep *
inst> install standard
inst> install prereqs
inst> go

and away it went. I fed the CDs as requested.

Well, it didn't work. After installation is finished, I quit and rebooted the system. I comes up with an 'Autoboot failed' message:

pci(0)scsi(0)disk(2)rdisk(0)partition(0)/unix: media not loaded
Hit Enter to continue.

and the system reboots to the PROM menu. That's it.

I'm convinced that this particular system is too new for the original 6.5 release of IRIX, and a little web serching confirms this. I'm still not exactly sure what release first supported the R12K O2, but I do know that 6.5.16 and above work.

[NOTE: later experimentation shows that the original 6.5 WILL install on an R4600PC Indy without trouble.]

So, I ended up going back to the idea of just installing 6.5.30 on this new, large drive and be done with it. That's what I did. I used the following CDs from my IRIX collection:

- 6.5.30 Installation Tools and Overlays 1
- 6.5.30 Overlays 2
- 6.5.30 Overlays 3
- 6.5.30 Applications
- 6.5.30 Complimentary Applications
- 6.5 Foundation 1
- 6.5 Foundation 2
- 6.5 Development Libraries
- 6.5 Applications

Adding commands to system startup

19-Jan-2016

IRIX 6.5 doesn't offer an 'rc.local' facility, so the way to start processes at startup is done with init.d scripts, and then adding a reference to the 'chkconfig' data dir.

I needed to add a command that would start nekoware_rsync as a daemon at startup. There are four files that need to be created:

/etc/init.d/neko_rsyncd
/var/config/neko_rsyncd
/etc/rc0.d/K09neko_rsyncd
/etc/rc2.d/S95neko_rsyncd

For the first, I copied the already existing 'neko_samba' and edited it to execute rsync instead.

For the second, I simply echoed 'on' to '/var/config/neko_rsyncd' and now I could use chkconfig to enable or disable the automatic startup of neko_rsync at boot.

For the third and fourth, I created symlinks to '../init.d/neko_rsyncd'.

Ethernet address woes

12-Feb-2016

For the past few hours I have been attempting to boot this system, but the Ethernet address is not being read at system startup. I keep seeing FF:FF:FF:FF:FF:FF which could indicate a bad ROM. On this O2 system, I am unsure if the Dallas real-time-clock (RTC) chip has any effect on this. I am starting to see time being lost whenever I re-power the system.

I shutdown after a while and removed the system module from the chassis. Then I disassembled the system module to the point that I could remove the PCI riser board. To to this, I removed 5 short black screws from the back panel and 2 longer black screws from each end of the triangular 'base', allowing the plastic cover the be lifted and 'snapped' off of the metal. Then I removed two steel screws holding the PCI riser card, and removed it from it's slot.

At location U1 on the PCI riser card, is the Dallas ROM (looks like a 3-lead transistor in a TO-92 package) which contains the systems Ethernet Address. The markings on this unit are:

DALLAS
DS2502
9826B6
154AE

Everything looks fine. There is no dust or lint in the PCI riser slot on the system module and the little ROM looks okay.

On the system board, the Dallas RTC chip has these markings:

DALLAS
DS1687-5
REAL TIME
9949B2 115334

To get to the Dallas RTC chip, the CPU module must be removed. Remove four screws around the perimeter of the heat-sink, and lift the CPU module straight up, off of the main board.

After re-assembly, what do you know!, the Ethernet address was back, 08:00:69:0E:A9:71.

[back to collection] [top]

Copyright © 2006-2025 Jared Blaser. All rights reserved.