Greetings! This is a half-reference, half-journey through my efforts to take the expansion chassis out from my O350 rack and turn it into a NUMAlink-capable processor module without losing any of its original functionality. While this guide will be centered around carrying out modifications to a graphics brick, the same procedure should work for any Origin 350 chassis that contains a full baseboard, such as an MPX brick.
Section 1: Original Configuration
Discord regulars may have seen occasional mention of a system called 'Octodad' in passing mention: here it is as it was originally configured. Purchased in September 2018 from eBay user and SGI guru mopar5150, the system has been running nearly non-stop as a remotely accessible build server, test system, and Quake 3 machine ever since. The processor brick contains four 800mhz R16000's with 8 gigabytes of RAM. The PCI slots are populated by sound devices, an IO9 board, and a USB card. Attached to it is a G2 brick, originally from an Onyx4 system: the G2 brick connects over the XIO port and provides an enclosure with two ATI FireGL X1 graphics cards for native four-monitor video output and synchronization. It's by far my fastest IRIX machine, to the point where it's essentially daily-drivable in a pinch.
Section 2: Closer Look At The G2 Brick
Opening the G2 brick is straightforward: roughly a dozen Philips-head screws hold the lid to the rest of the chassis, which swings vertically open once freed. The interior of the unit is very similar to that of a compute brick, with a few exceptions (that will prove troublesome later on).
From the top: the power supply is standard fare for an O350, as is the single exhaust blower at the top left of the image above. The aft center of the system is taken up by the ImageSync connector panel: on a normal Origin 350 compute brick, this spot is normally taken up by a second exhaust fan. The dual-AGP Pro riser board is exclusive to the G2 and G2N bricks, and sits in place of the normal PCI-X riser. An additional GPU-facing fan sits where the SCSI backplane would normally be attached.
There is also a metal divider sitting where the processor board is normally mounted: thankfully it's only held in place with two Torx T20 screws and slides out of the chassis once they're removed. All of the factory stand-offs for mounting a CPU board are present, and the press-fit connectors at the center of the baseboard are populated by default.
Section 3: Installation
The IP53 processor board itself was a complete assembly that I had purchased in January (thanks, 3ddoc!). It has four 700mhz R16000's, and came pre-loaded with 4 gigabytes of additional memory.
No physical modifications are needed to connect the processor board to the G2 brick's baseboard, though the physical installation can be slightly perilous. Unplugging the ImageSync cables from the AGP riser helps to clear some space in the center of the chassis. I found it best to hold the front-facing end of the processor board with one hand and the 'handle' over the CPU heat spreader with the other, making sure to keep the board as level as possible. Be gentle, use the position of the chassis' screw stand-offs as an alignment guide, don't apply much pressure or side-to-side movements, and the board will eventually find a spot where it can seat firmly onto the connectors.
The processor board appears to use 8-32 thread screws in order to mount to the chassis. I didn't have any of those on hand, but I did have a bag of NAS1801-08-06 aircraft bolts! They worked perfectly, keeping a good ground connection and lining things up snug and secure throughout.
Even without an IO9 board, an expansion chassis set up like this will still have an L1 controller accessible via the serial console port at the back of the unit. Connect a null modem serial cable set to 38400, 8, N, 1, with RTS/CTS flow control and plug the chassis in to start the L1 controller. The system can be tested in this state, but I'd instead opted to connect the G2 brick back to my original C-brick. Since the system now requires CPU to CPU communication, the two bricks have to be connected over their NUMAlink ports instead of the XIO ports: the same cable can be used without any modification.
Typing * pwr up in the compute brick's L1 controller automatically initializes both sides of the system. From there, I'd booted IRIX from the main unit as usual -- and, success!
At this point, the system is fully functional for short-term testing, but there's still a few issues that need some extra attention. One bank of RAM on my new processor board appears to be faulty (hence why hinv is reporting 11gb instead of 12gb), and the system starts hitting the advisory temperature threshold after about half an hour of usage. My next post will describe the O350's cooling system in more detail, as well as some of the things I've tried to solve the problems involved with such a mod.
Section 1: Original Configuration
Discord regulars may have seen occasional mention of a system called 'Octodad' in passing mention: here it is as it was originally configured. Purchased in September 2018 from eBay user and SGI guru mopar5150, the system has been running nearly non-stop as a remotely accessible build server, test system, and Quake 3 machine ever since. The processor brick contains four 800mhz R16000's with 8 gigabytes of RAM. The PCI slots are populated by sound devices, an IO9 board, and a USB card. Attached to it is a G2 brick, originally from an Onyx4 system: the G2 brick connects over the XIO port and provides an enclosure with two ATI FireGL X1 graphics cards for native four-monitor video output and synchronization. It's by far my fastest IRIX machine, to the point where it's essentially daily-drivable in a pinch.
Section 2: Closer Look At The G2 Brick
Opening the G2 brick is straightforward: roughly a dozen Philips-head screws hold the lid to the rest of the chassis, which swings vertically open once freed. The interior of the unit is very similar to that of a compute brick, with a few exceptions (that will prove troublesome later on).
From the top: the power supply is standard fare for an O350, as is the single exhaust blower at the top left of the image above. The aft center of the system is taken up by the ImageSync connector panel: on a normal Origin 350 compute brick, this spot is normally taken up by a second exhaust fan. The dual-AGP Pro riser board is exclusive to the G2 and G2N bricks, and sits in place of the normal PCI-X riser. An additional GPU-facing fan sits where the SCSI backplane would normally be attached.
There is also a metal divider sitting where the processor board is normally mounted: thankfully it's only held in place with two Torx T20 screws and slides out of the chassis once they're removed. All of the factory stand-offs for mounting a CPU board are present, and the press-fit connectors at the center of the baseboard are populated by default.
Section 3: Installation
The IP53 processor board itself was a complete assembly that I had purchased in January (thanks, 3ddoc!). It has four 700mhz R16000's, and came pre-loaded with 4 gigabytes of additional memory.
No physical modifications are needed to connect the processor board to the G2 brick's baseboard, though the physical installation can be slightly perilous. Unplugging the ImageSync cables from the AGP riser helps to clear some space in the center of the chassis. I found it best to hold the front-facing end of the processor board with one hand and the 'handle' over the CPU heat spreader with the other, making sure to keep the board as level as possible. Be gentle, use the position of the chassis' screw stand-offs as an alignment guide, don't apply much pressure or side-to-side movements, and the board will eventually find a spot where it can seat firmly onto the connectors.
The processor board appears to use 8-32 thread screws in order to mount to the chassis. I didn't have any of those on hand, but I did have a bag of NAS1801-08-06 aircraft bolts! They worked perfectly, keeping a good ground connection and lining things up snug and secure throughout.
Even without an IO9 board, an expansion chassis set up like this will still have an L1 controller accessible via the serial console port at the back of the unit. Connect a null modem serial cable set to 38400, 8, N, 1, with RTS/CTS flow control and plug the chassis in to start the L1 controller. The system can be tested in this state, but I'd instead opted to connect the G2 brick back to my original C-brick. Since the system now requires CPU to CPU communication, the two bricks have to be connected over their NUMAlink ports instead of the XIO ports: the same cable can be used without any modification.
Typing * pwr up in the compute brick's L1 controller automatically initializes both sides of the system. From there, I'd booted IRIX from the main unit as usual -- and, success!
Code:
OCTODAD% hinv
Processor 0: 800 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.2
FPU: MIPS R16010 Floating Point Chip Revision: 2.2
Processor 1: 800 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.2
FPU: MIPS R16010 Floating Point Chip Revision: 2.2
Processor 2: 800 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.2
FPU: MIPS R16010 Floating Point Chip Revision: 2.2
Processor 3: 800 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.2
FPU: MIPS R16010 Floating Point Chip Revision: 2.2
Processor 4: 700 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.1
FPU: MIPS R16010 Floating Point Chip Revision: 2.1
Processor 5: 700 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.1
FPU: MIPS R16010 Floating Point Chip Revision: 2.1
Processor 6: 700 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.1
FPU: MIPS R16010 Floating Point Chip Revision: 2.1
Processor 7: 700 MHZ IP35
CPU: MIPS R16000 Processor Chip Revision: 2.1
FPU: MIPS R16010 Floating Point Chip Revision: 2.1
Main memory size: 11264 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 4 Mbytes
Secondary unified instruction/data cache size: 4 Mbytes
Secondary unified instruction/data cache size: 4 Mbytes
Secondary unified instruction/data cache size: 4 Mbytes
Secondary unified instruction/data cache size: 8 Mbytes
Secondary unified instruction/data cache size: 8 Mbytes
Secondary unified instruction/data cache size: 8 Mbytes
Secondary unified instruction/data cache size: 8 Mbytes
Integral SCSI controller 2: Version IDE (ATA/ATAPI) IOC4
CDROM: unit 0 on SCSI controller 2
Integral SCSI controller 0: Version QL12160, low voltage differential
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 1: Version QL12160, low voltage differential
IOC3/IOC4 serial port: tty3
IOC3/IOC4 serial port: tty4
IOC3/IOC4 serial port: tty5
IOC3/IOC4 serial port: tty6
Graphics board: SG2
Graphics board: SG2
Integral Gigabit Ethernet: tg0, module 001c01, PCI bus 1 slot 4
Iris Audio Processor: version EMU revision A4, number 1
IOC3/IOC4 external interrupts: 1
USB controller: type OHCI
USB controller: type OHCI
At this point, the system is fully functional for short-term testing, but there's still a few issues that need some extra attention. One bank of RAM on my new processor board appears to be faulty (hence why hinv is reporting 11gb instead of 12gb), and the system starts hitting the advisory temperature threshold after about half an hour of usage. My next post will describe the O350's cooling system in more detail, as well as some of the things I've tried to solve the problems involved with such a mod.