While I still have the the O350 2UPX PCI Expansion Module (an O350 chassis minus the processor node board), I thought do a little experimenting with the possibility of running PCI-based Radeon graphics using the
ported-for-the-Onyx4/UltimateVision IRIX version of xFree86. An admitted long shot, but if it works it'd mean Origin 300/350/3k0 users could run a graphics head, much like the MGRAS graphics hack did for 02k users.
So I managed to come up with two PCI-interfaced ATI Radeon X1300 graphics boards. (Very) loosely following slot assignments used by the (AGP-sloted) Onyx4 G2N module, I installed both of the X1300s in the 2UPX, one in PCI bus 1 slot 2, the other in PCI bus 2 slot 2.
Even with the ATI boards installed, the 'hardware' command from the 'Admin' menu of a PROM install saw the O350 as an O350 server:
EDIT: It is likely that the Onyx4 UltimateVision inst machinetype info is derived from the presence (or absence) of the AGP riser. In retrospect this seems more like then just the presence of the ATI FireGL boards used in the Onyx4. The AGP riser was custom designed by SGI and includes the I2C circuity needed to be identified by the system and appear in an L1 "serial all", an hinv and to inst's get hardware inventory routine. The FireGL boards used in the Onyx4 are reported to have been standard off-the-shelf ATI hardware that don't appear directly in an L1 'serial all', an hinv or (probably) the inst get hardware routine. This would have left the use of the inst "-m" switch (install for alternative hardware) as the most likely method to install the subsystems needed to drive an ATI graphics board with a PCI bus. Unfortunately, even when the Onyx4/Voyager/ATI FGLRX software is installed, IRIX refuses to acknowledge the presence of an an ATI graphics board installed in any of the PCI slots. I suspect the software may also be coded to expect the presence of an AGP bus.
Code:
CPUARCH=R10000
IP35
CPUBOARD=IP35
MODE=64bit
SUBGR=SERVER
GFXBOARD=SERVER
MACHINE=Origin
SASHNAME=sash64
TARGOS=1289662620
DISTOS=-1
Didn't look too good, but since the ATI boards are probably initialized by a virtual BIOS routine loaded by IRIX, I booted the system and as IRIX loaded got the following warnings:
Code:
WARNING: pciio_ppb: Host PCI slot /hw/module/001c01/PXbrick/xtalk/10/pci-x/0/2
does not support having multiple dma masters downstream.
No devices behind that slot are being initialized. This behavior
can be overridden by setting the kernel mtune pciio_multimaster_override.
WARNING: pciio_ppb: Host PCI slot /hw/module/001c01/PXbrick/xtalk/10/pci-x/1/2
does not support having multiple dma masters downstream.
No devices behind that slot are being initialized. This behavior
can be overridden by setting the kernel mtune pciio_multimaster_override.
And there was nothing in an hinv to indicate the ATI boards were there.
So I added the pciio_multimaster_override setting
Code:
# systune io
group: io (statically changeable)
pciio_multimaster_override = 1 (0x1) <<<<-here-<<<<
pcibr_pioerr_dump = 1 (0x1)
pciba_broken_le_be_compat = 0 (0x0)
io_init_async = 1 (0x1)
io_init_node_threads = 0 (0x0)
graph_vertex_per_group = 128 (0x80)
xxl_hwgraph_num_dev = 262144 (0x40000)
hwgraph_num_dev = 262144 (0x40000)
and the next time around the boot-time warning changed to:
Code:
WARNING: *** ppb IO base/limit conflict
WARNING: *** ppb IO base/limit conflict
Now the ATI boards appeared in the PCI Adapter ID section of an hinv -vm:
Code:
PCI Adapter ID (vendor 0x10b5, device 0x8111) PCI slot 2
PCI Adapter ID (vendor 0x1002, device 0x7146) PCI slot 0
PCI Adapter ID (vendor 0x1002, device 0x7166) PCI slot 0
PCI Adapter ID (vendor 0x10b5, device 0x8111) PCI slot 2
PCI Adapter ID (vendor 0x1002, device 0x7146) PCI slot 0
PCI Adapter ID (vendor 0x1002, device 0x7166) PCI slot 0
Which translates to:
Vendor ID 0x10b5 = PLX Technologies, device 0x8111 = PCI-E to PCI bridge
Vendor ID 0x1002 = ATI, device 0x7146 = ATI Radeon X1300 Series
Vendor ID 0x1002 = ATI, device 0x7146 = ATI Radeon X1300 Series Secondary
In comparison, the ATI FireGL boards in the PCI section of
this Onyx4 hinv post appear as:
Code:
PCI Adapter ID (vendor 0x1002, device 0x4e47) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e67) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e47) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e67) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e47) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e67) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e47) PCI slot 1
PCI Adapter ID (vendor 0x1002, device 0x4e67) PCI slot 1
Which in turn translate to:
Vendor ID 0x1002 = ATI, device 0x4E47 = ATI FireGL X1
Vendor ID 0x1002 = ATI, device 0x4E47 = ATI FireGL X1 Secondary
Slightly more interesting is the next Onyx4 PCI device - just past the Radeons entries - tho I'm gonna guess something got misaligned or left out of the PCI Device Database:
PCI Adapter ID (vendor 0x10a9, device 0x100a) PCI slot 1, which translates to:
Vendor ID 0x10A9 = SGI, device 0x100A = Hewlett-Packard VisualizeFX Series Video
Regardless of their eventual appearance of the X1300s into the PCI section of an hinv, both the miniroot and IRIX versions of inst still return "GFXBOARD=SERVER".
There are still lots of other potential problems. I can find references to SGI using the ATI R300/350/420 graphics processor in the Onyx4, the X1300s have the Radeon R520 graphics engine (I couldn't find any R300/350/420 boards with a PCI interface for less than way-stupid money). That might have less of an impact than it appears. SGI used a port of ATI's FGLRX driver, and google indicates the fglrx of the period supported Radeon hardware from R100 through R600. If present, the IRIX driver module can be found as
/var/sysgen/boot/fglrx.o (for a little additional background, read the contents of
/var/sysgen/master.d/fglrx)
Fglrx issues aside, the PCI-Express bridge chip used in the X1300 is likely be the bigger issue - either because there's no IRIX support or because of the pbb io base/limit conflict (or both).
The next (less than) logical step would be trying an install. Though it would be nice if I knew a little bit more about how an Onyx4 identifies itself to the inst hardware command. How IRIX or the PROM initialize the FireGL boards in the Onyx4 would be another useful bit of information. If all else fails there's always room for another long shot by doing an
inst -m -r at the miniroot and specifying
GFXBOARD=VOYAGER man inst (1M) wrote:
-m hardware=value
The software distribution for some software products contains
several hardware-specific copies of the same file. By default inst
installs the copy that is appropriate for the type of workstation
you are installing on. The -m option is useful when you are
installing software on a disk that will be transferred to a
different type of workstation or when you are extracting files from
a software distribution for a different type of workstation. In
both these cases you would probably also use the -r option. The
inst command admin hardware can be used to view the current hardware
variables in effect.
Acceptable arguments are:
CPUBOARD=cpu
GFXBOARD=gfxboard
MODE=mode
SUBGR=subgr
default
The default keyword substitutes all of the hardware values for the
current system. Refer to your /var/inst/machfile for an example of
the various combinations of hardware configurations currently
defined. The first section of /var/inst/machfile is a mapping from
the data returned by getinvent(1M) to the strings used by the -m
option.
If anyone has a PCI-based Radeon (that isn't bridged from another bus architecture) and an O3x0/O3k, I'd be glad to share notes if you'd like to give it a go.
Login
Register
FAQ
Search
33mhz R3k/48mb/XS24 
150mhz R4400/256mb/XL24 
600mhz R14kA/2gb/V10 
8x1.4ghz Itanium 2/8GB 
32x600mhz R14kA/24GB 
4x700mhz R16k/8GB/V12/DCD/SAS/FC/DM5 
2x700mhz R16k/4GB
(single-CM)
Forgot I bought it a while back to throw into my Cobalt Cube 3, but could never get it to work right in there.
