Attempting to patch the SuperMac S900/Umax Pulsar's Open Firmware with "The Great Gazelle PCI Hack"

[CircuitBored]

Having finally revived my Umax Pulsar (SuperMac S900) I thought it was about time I had a poke around in Open Firmware and took a look at if and how this patch could be applied to it.

For context:
The S900 is quite strange. From a hardware perspective it is very similar to a Power Macintosh 9500 and most of the chipset is identical, however four of its six PCI slots sit behind a PCI bridge. As I understand it, the ROM is identical to the 9500's too. The S900's killer issue is that any PCI card that contains a PCI-PCI bridge installed into a bridged slot will cause the machine to hang when the OS starts to load extensions. This is most definitely a firmware issue, as @trag has experimented with replacing the onboard PCI bridge chip with a later revision to no avail.

Probing into Open Firmware, I found that devices behind a second PCI-PCI bridge are indeed not enumerated properly. Having read the Gazelle thread thoroughly, I was still quite confident that this patch would allow these cards to work, however...

As it stands the pitcher-patcher created by @cheesestraws does not work on the S900 for what I assumed was some arbitrary reason, perhaps due to the fact that this machine runs a buggy implementation of Open Firmware 1.0.5. The compiled patcher will load but returns a "Type 1" error when you actually try to apply the patch.

I attempted to patch nvramrc the hard way using nvedit but unfortunately a line length limit kicks in and "auto-returns", scuppering the whole procedure. If there's a smarter way to try this, please let me know.

Compiling and running the original patcher from the source appears to yield no errors, however it seems as though all is still not well. For some reason, every time the S900 boots to Mac OS, the following code is written to the nvramrc:

: '& get-token drop ;
: >& dup @ 6 << 6 >>a -4 and + ;
: & na+ >& ;
6ED '& execute

0 value mi

: mmr " map-range" mi if my-self $call-method else $call-parent then ;
89B '& ' mmr BRpatch

: mcm -1 to mi $call-method 0 to mi ;
8CB '& 1E na+ ' mcm BLpatch

: maa -1 to mi 1D swap ;
8C9 '& 5 na+ ' maa BLpatch
8C9 '& 134 + ' 1 BLpatch

8CD '& 184 + dup 14 + >& BRpatch

8C6 '& 7C + ' u< BLpatch

0 value yn
: y yn 0= if dup @ to yn then ;
8CB '& ' y BRpatch
' y 28 + 8CB '& 8 + BRpatch
: z yn ?dup if over ! 0 to yn then ;
8CC '& ' z BRpatch
' z 2C + 8CC '& 8 + BRpatch

After a bit of light debugging with @cheesestraws we quickly realised that the pitcher-patcher is trying to write the nvramrc to the wrong nvram address. In "bootvars.c" there is an interesting comment:

If it's a powerbase, we'll read 0 from nvram location 0.

This suggests that there is a degree of variety in how different machines address their vram, one that is properly accommodated for in the various utilities that can write to nvram e.g. netbsd boot variables control panel. Over the next couple of days I'll be doing a bit of cross-referencing to see how they're doing things differently. As of my writing this, I haven't a clue what the correct address for the S900 is.

Exactly what the above Forth code is doing or where it is coming from eludes me. I'm not sure that my copy of it is complete, as my outputs in Xterm are quite messy. At first I thought its source could be one of the control panels that are installed on my system disk, or even the oldworld Mac patcher for 9.2.2. Unfortunately, having removed those variables, I am still left with this script in nvramrc every time I boot 9.1 or 9.2.x.

Could it be a patch applied by a PCI card or even the Sonnet CPU? Sadly, it seems it's not that simple. A bit of trial and error has proven that it's likely something being done by the system software during the boot process. I deduced this by booting with blank nvram and observing that nvramrc has always been updated by the time the desktop loads. If anyone recognises the above script or has any insights they will be greatly valued. At the moment, my best hypothesis is that it is a patch made by Apple specific to the logic boards in the 9500 family. It could even be the case that this patch isn't quite right for the S900's niche hardware and the source of some of the PCI woes. That last part is pure speculation, mind.

Ignoring loading the script from the OS, it seems as though I could still be able to load it from the Open Firmware console by sending a Forth file over serial or by loading from a floppy disk (if I have understood the Gazelle hack thread correctly). I'm not sure that the Fcode cooked up by @joevt could be applied here as it seems to be focused on an issue with the Gazelle's internal graphics, whereas the S900 has no internal graphics at all. Sadly, it strikes me as a bit of wild goose chase to attempt forcing the patch into place before I actually know what is going on here. All of this is moot if whatever I write to nvram is overwritten by the system software starting up.

I am a novice when it comes to most forms of programming. My limited experience comes from tooling around with the firmware on Sun workstations, a lot of which is not very transferable, and fiddling with other people's Python and C to make it do what I want. Creating stuff from scratch is an intimidating challenge but I am hoping to learn a lot as I go. For now, I will simply attempt to accumulate as much information as possible here before grabbing the bull by the horns. Tomorrow I am going to attempt to run lspci for Open Firmware and will share the results accordingly. This may well shed some light on exactly what is going wrong with this frankly shambolic firmware.

This is somewhat of a nothingy post for now. I am mostly writing it here as a way to keep track of what I have tried so far but, as mentioned, it would be tremendous to have some external input too. Thanks in advance to anyone who gets involved.

 

[CircuitBored]

It turns out that I didn't even need to run lspci for open firmware in order to uncover something really quite strange.

As I understand it, the S900 has just one PCI root device, pci1, hence its use of a bridge chip for its lower four PCI slots. However, when I run devalias I am met with the following:

0> devalias
vci0                /chaos@F0000000
pci1                /bandit@F2000000
pci2                /bandit@F4000000
fd                  /bandit/gc/swim3
kbd                 /bandit/gc/via-cuda/adb/keyboard
ttya                /bandit/gc/escc/ch-a
ttyb                /bandit/gc/escc/ch-b
enet                /bandit/gc/mace
scsi                /bandit/gc/53c94
scsi-int            /bandit/gc/mesh
ok

Wait a minute. That's a second PCI root device, pci2. What's that doing there? Naturally, I attempted to select it to get more information.

0 > dev pci2 can't find device ok
0 > dev /bandit@F4000000 can't find device ok

Neither the devalias nor the "actual location" point to anything. There's nothing there, yet the firmware really seems to think that there is. Stranger still, the same thing is happening with vci0, which I presume to be where internal graphics chipsets live on other systems. Becoming increasingly curious, I took a closer look at the PCI root that was actually there.

.properties
name                    bandit
device_type             pci
model                   AAPL,343S1126
AAPL,interrupts         00000016
reg                     F2000000  02000000
#address-cells          00000003
#size-cells             00000002
clock-frequency         01FCA055
slot-names              0000E000 41310042 31004331 00
ranges                  02000000 00000000 F3000000  F3000000  00000000 01000000
                        01000000 00000000 00000000  F2000000  00000000 00800000
                        02000000 00000000 80000000  80000000  00000000 10000000
bus-range               00000000 00000001

 ok

What immediately stuck out to me was the model, 343S1126. This chip does not exist on the S900's logic board but it is there on the 9500. Instead, the S900 has a chip with model 343S1125, which is not present on the 9500. It could well be the case that these are just different revisions of the same chip but it is a bit odd nonetheless.

A web search unveiled another oddity. This is the devalias output from a Power Macintosh 7300, which I found on this page.

vci0                /chaos@F0000000
pci1                /bandit@F2000000
pci2                /bandit@F4000000
fd                  /bandit/gc/swim3
kbd                 /bandit/gc/via-cuda/adb/keyboard
ttya                /bandit/gc/escc/ch-a
ttyb                /bandit/gc/escc/ch-b
enet                /bandit/gc/mace
scsi                /bandit/gc/53c94
scsi-int            /bandit/gc/mesh

That's exactly the same as the S900's. I don't really know what to do with this information other than say "weird".

A logical next step would be to fire up a 9500 and see what its devalises look like. I'm not sure it will even have a vci0 root at all. I do have a 9500 logic board and all the parts needed to run it, except I am lacking a case. This is obviously a bit of a problem so I will have to do some fabricating before testing it.

It could simply be that the S900's extraneous devalises are superfluous and do not interfere with the one real PCI root device. Alternatively, this could be a big clue as to how and why PCI is so messy on this system. Can a PCI-PCI bridge be given a devalias? Could I set up the S900's bridge as pci2? This I will have to go and figure out.

I will have to do some more research in order to make more progress. Sadly, I have not been able to find any documentation on the bandit chipset yet. Reading the Open Firmware documentation would be a good starting point but digging up a good reference manual for version 1 has proven surprisingly difficult.

 

[Phipli]

A web search unveiled another oddity. This is the devalias output from a Power Macintosh 7300, which I found on this page.

The same ROM was used in a load of similar architecture machines :



There seem to be two versions. Guess they just put two bandits in the structure whatever the host machine was.

 

[CircuitBored]

The same ROM was used in a load of similar architecture machines :

View attachment 62763

There seem to be two versions. Guess they just put two bandits in the structure whatever the host machine was.

Ah, well I guess that explains that. I knew the same ROM was shared by a few systems but I rather stupidly hadn't made the connection that Open Firmware is inside the ROM, so of course it would have a variety of things in it which may be superfluous on certain systems.

 

[joevt]

Probing into Open Firmware, I found that devices behind a second PCI-PCI bridge are indeed not enumerated properly. Having read the Gazelle thread thoroughly, I was still quite confident that this patch would allow these cards to work, however...

The patch works for a specific ROM/machine which is different than the S900. Specifically, the patch refers to fcode number a3b for ?probe-slot. The ?probe-slot word has a different fcode number in other ROMs. The patch uses fixed offsets inside probe-slots for the changes. The code in other ROMs is different so the offsets will be wrong.

Anyway, the patch only changes the order that devices are probed. It's not an actual fix.

I attempted to patch nvramrc the hard way using nvedit but unfortunately a line length limit kicks in and "auto-returns", scuppering the whole procedure. If there's a smarter way to try this, please let me know.

Anywhere there's a space in the patch, can be replaced with a carriage return. All white space is treated the same (except for inside strings).

For some reason, every time the S900 boots to Mac OS, the following code is written to the nvramrc:

The code comes from a OFpt resources in the System. Each OFpt resource corresponds to a specific machine/firmware. The script fixes various issues such as allowing GPUs with 256MB VRAM (instead of just 128MB) to work with Open firmware 1.0.5.
https://68kmla.org/bb/index.php?threads/the-great-gazelle-pci-hack-thread-part-2.38360/post-467222
I have other fixes to allow GPUs with 512MB VRAM.
https://forums.macrumors.com/thread...l-work-in-a-beige-power-macintosh-g3.2303689/

Tomorrow I am going to attempt to run lspci for Open Firmware and will share the results accordingly.

To solve this issue, we need:
- SuperMac S900 model description.
- List of PCI cards that causes the problem. Is it just one PCI card with every other slot empty? That would be simplest.
- 4MB ROM dump.
- lspci and dump-device-tree with the broken PCI card in a bridge slot.
- lspci and dump-device-tree with the broken PCI card in a not-bridge slot.

Neither the devalias nor the "actual location" point to anything. There's nothing there, yet the firmware really seems to think that there is.

A devalias is a path to a possible device. The device doesn't actually have to exist. The devalias does nothing except act as a shortcut. The Power Mac 8600 and 9600 have the same dev aliases but the 8600 doesn't have pci2 and the 9600 doesn't have vci0 and it wouldn't
be possible for a machine to have both a vci0 and a pci2 since they use the same interrupt numbers.

What immediately stuck out to me was the model, 343S1126. This chip does not exist on the S900's logic board but it is there on the 9500. Instead, the S900 has a chip with model 343S1125, which is not present on the 9500.

343S1126 is bandit.
343S1125 is grandcentral.
They both exist in the 9500.
https://wiki.preterhuman.net/Apple_Computer_Custom_IC_Definitions

Can a PCI-PCI bridge be given a devalias? Could I set up the S900's bridge as pci2?

I think you can make dev aliases. but it won't fix any problems.

Sadly, I have not been able to find any documentation on the bandit chipset yet.

You could look at emulator source code. Here's bandit in DingusPPC:
https://github.com/dingusdev/dingusppc/tree/master/devices/common/pci

Main function of Bandit is as a PCI Host Bridge. Here's some info:
https://wiki.osdev.org/PCI

You can also try reading PCI specs:
PCI Local Bus Specification Revision 3.0 February 3, 2004
PCI-to-PCI Bridge Architecture Specification Revision 1.1 December 18, 1998.pdf

Reading the Open Firmware documentation would be a good starting point but digging up a good reference manual for version 1 has proven surprisingly difficult.

Open Firmware 1.0.5 is not all that different than later versions. Later versions add some minor features and fixes.

 

[CircuitBored]

@joevt Thank you so much for this reply. I am genuinely humbled. I'm going to read through all of this and will post the bits and pieces you mentioned accordingly. Can I dump the ROM from Open Firmware? It is allegedly the same as the 9500's ROM but it would be interesting to compare them anyway.

343S1126 is bandit.
343S1125 is grandcentral.
They both exist in the 9500.
https://wiki.preterhuman.net/Apple_Computer_Custom_IC_Definitions

I'm often the first to admit when I've been a bit thick. In this case, I was looking at a board that has been scavenged for parts rather than my other 9500 board, which has a complete chipset and, yes, does indeed feature a 343S1125 chip. D'oh.

SuperMac S900 model description.

What do you mean by this? A rundown of the chipset and general architecture?

List of PCI cards that causes the problem. Is it just one PCI card with every other slot empty? That would be simplest.

AIUI, the PCI issue arises with any PCI card that has a bridge on it. I've tested and confirmed this with two cards, an Adaptec AUA-3121 HBA (USB/FW combo, HiNT HB1 bridge chip) and card from an unknown vendor, model number ST200-00B (USB/FW/SATA combo, PLX PCI6140 bridge chip). The "fail" behaviour is that the OS will hang when it starts to load extensions. When the former card is installed in slot B1 (unbridge) it shows up as a "four port ethernet card", the latter card is listed as "pci bridge". Neither card actually works in any slot. I have confirmed that both these cards work properly in a beige G3. I don't have any bridged cards that work in the unbridged slots, although @trag may know of one, as he's messed with the S900 a fair bit himself.

I've finally managed to get lspci to run so I will post the results in due course.

 

[CircuitBored]

Here's my lspci output for the Adaptec card in slots B1, C1, and removed entirely. An ATI VGA card is present in slot A1 for all of these.

I am currently in the process of dumping the ROM.

 

[CircuitBored]

Here's a freshly extracted ROM and a dev-tree-dump for completeness' sake. Interestingly, it matches the second revision PM9500 ROM, rather than the first. I wonder if this is the case for all S900s, and what the differences from the first revision are.

I am slowly dragging myself through Forth bootcamp. What a strange language it is - quite fun though.

 

[joevt]

Can I dump the ROM from Open Firmware?

Yes. There are instructions in the first post of the MacRumors thread I posted. There may also be other methods such as apps run in Mac OS.

What do you mean by this? A rundown of the chipset and general architecture?

I think there were multiple S900 versions? So I was asking which version you have. Maybe they only differ by clock speed?

Your dump-device-tree has the following info:

bus speed: 45MHz (clock-frequency 02AEA540)

CPU: 604 (cpu-version 00090202 which is actually PowerPC 604e v2.2)

CPU speed: 195MHz (clock-frequency 0B9F76C0) I don't see a 195 MHz variant at https://lowendmac.com/1996/umax-supermac-s900/ . Is it supposed to say 200 MHz?

nvramrc: empty (you said Mac OS 9 fills this in? but you zapped it since then?)

AIUI, the PCI issue arises with any PCI card that has a bridge on it. I've tested and confirmed this with two cards, an Adaptec AUA-3121 HBA (USB/FW combo, HiNT HB1 bridge chip) and card from an unknown vendor, model number ST200-00B (USB/FW/SATA combo, PLX PCI6140 bridge chip). The "fail" behaviour is that the OS will hang when it starts to load extensions. When the former card is installed in slot B1 (unbridge) it shows up as a "four port ethernet card", the latter card is listed as "pci bridge". Neither card actually works in any slot. I have confirmed that both these cards work properly in a beige G3. I don't have any bridged cards that work in the unbridged slots, although @trag may know of one, as he's messed with the S900 a fair bit himself.

Hanging the OS before loading extensions is not the easiest problem to debug. It would be better if the problem were an issue that can be detected in Open Firmware. My idea would be to try to reproduce the problem in DPPC which does Open Firmware well, but currently doesn't fully boot an OS.

Here's a freshly extracted ROM and a dev-tree-dump for completeness' sake.

Which lspci does the dump-device-tree belong to? I think it must be the S900VGAONLY one.
There should be a dump-device-tree for each lspci.
The dump-device-tree has a PCI bridge in slot C1.
If C1 is the bridge for the other 4 slots, then how do you have Adaptec card in slot C1?
I think you read the slot name from System Profiler which gets the name from Open Firmware.
Open Firmware assigns slot name C1 to the bridge. Since it is a bridge, every PCI card connected to it will also show as slot C1.

The linked lowendmac page says the slots are numbered 3-6:

The J700 and S900 have a PCI bridge chip controlling all PCI slots except the first two, which use the normal Apple chip. As a result, only cards that are PCI 2.1 compliant can be installed in slots 3-6 (3-4 for J700). Problematic cards are usually older SCSI cards, and, for some reason, ixMicro cards such as Ultimate Rez (but not the older ixMicro Twin Turbo cards). There are claims that even ixMicro-branded cards have slot preference, and in a multiple-card setup at least one has to be in slot 1 or 2, while the other can be in slot 4 or 5.

By that logic, I think your Adaptec card must be PCI 2.1 compliant because it also has a bridge chip.

Here's my lspci output for the Adaptec card in slots B1, C1, and removed entirely. An ATI VGA card is present in slot A1 for all of these.

Which case is the problematic one? I think it must be the C1 case since that's the PCI bridge slot. I don't see a problem with the C1 case since it does show that the subordinate bus number of the bridge was set to 02 and has all the devices that the B1 case has. You didn't provide a dump-device-tree to show if the devices appear in the device tree.

The Adaptec card doesn't have a PCI option rom (no ROM BAR which would be at 0x30 like the ATI Rage 128 has) which means you can't boot from the Adaptec PCI card?

Interestingly, it matches the second revision PM9500 ROM, rather than the first. I wonder if this is the case for all S900s, and what the differences from the first revision are.

Yup, exact match. Which method did you use to extract the ROM?

cd the/directory/with/all/the/roms

romchecksum () {
	# Ben Boldt's Mac ROM Checksum Verifier
	# https://web.archive.org/web/20180217090913/https://www.d.umn.edu/~bold0070/projects/checksum/
	local therom="$1"
	perl -E '
		$ck = 0;
		$bytesRead = read (STDIN, $buffer, 4);
		$i = 4;
		while ($bytesRead = read (STDIN, $buffer, 2) && $i < 3145728) {
			$num = unpack 'n', $buffer;
		  	$ck += $num;
		  	$i += 2;
		} 
		printf("%08x\n", $ck & 0xffffffff);
	' < "$therom"
}

IFS=$'\n'
for therom in $(find . \( -size 1M -o -size 2M -o -size 3M -o -size 4M -o -size 5M -o -size 6M \) -not -path "*.src/*"); do
	echo $(
		romsize=$(stat -f "%z" "$therom")
		thebytes=$(dd if="$therom" bs=32 count=1 2> /dev/null | xxd -p)
		checksum="$(romchecksum "$therom")"
		printf "%s.%s %dMiB %s " "${thebytes:16:4}" "${thebytes:36:4}" $((romsize / 1024 / 1024)) "${thebytes:0:8}"
		[[ $checksum == ${thebytes:0:8} ]] && printf "         √ " || printf  "${checksum} x "
		md5 -q "$therom"
	) '"'"$therom"'"'
done | sort > romlist.txt

sed -nE '/4MiB/p' romlist.txt

077d.28f1 4MiB 96cd923d          √ dfebb8fdad4124e02608429d98bf349b "./ROM Apple/#1 mac-rom-archive-20110819/96CD923D - Power Mac 7200&7500&8500&9500 v1.ROM"
077d.28f2 4MiB 9630c68b          √ 2623a0c438045ea04d2cc67310c97743 "./ROM Apple/#1 mac-rom-archive-20110819/9630C68B - Power Mac 7200&7500&8500&9500 v2.ROM"
077d.28f2 4MiB 9630c68b          √ 2623a0c438045ea04d2cc67310c97743 "./ROM PowerPC Mac/ROM SuperMac S900/From CircuitBored/S900.rom.bin"
077d.34f2 4MiB 960e4be9          √ edcf3422d712f61f83c07efc2401cbb8 "./ROM Apple/#1 mac-rom-archive-20110819/960E4BE9 - Power Mac 7300 & 7600 & 8600 & 9600 (v1).ROM"

I usually work with the 8600 ROM since that's the one I have. All three have the same Open Firmware code. It's only the non-OpenFirmware parts that differs. I didn't check if the stuff that happens before Open Firmware is different, or the stuff that happens after, or both.

I've attached the result of parsing the lspci info from Open Firmware using the parseOFlspci command from ParselspciFromOpenFirmware.sh which requires pciutils.

You use the command like this:

# load the commands
source ParselspciFromOpenFirmware.sh 

# run the command
parseOFlspci S900ADAPTECINB1.txt

 

[trag]

Hmmm. A lot to comment on... Apologies if the order is poor. And let me say at the beginning that I am impressed by both of your efforts on this topic, and everyone involved in the Gazelle hack, of course.

Firmware/ROM: I use two items to identify ROMs. Perhaps @joevt can comment on whether this is a valid method.

The first item I use is the "Firmware Revision" reported in Apple System Profiler. The second item is the actual Apple part numbers written on the ROM chips themselves. Note, this is the Apple part number, not the mask ROM or EEPROM or Flash part number. I realize that different ROM revisions might contain the same Open Firmware version, but I've never correlated the two (ROM revision vs. OF version).

That said, the following ROM/firmware were used in the following machines, at least. Perhaps other machines as well, but definitely these. Also 341Snnnn - 341Smmmm indicates a set of four ROM chips with sequential numbers beginning with nnnn and ending with mmmm.

Physical ROM chip #s ASP Firmware Revision
1) 341S0106 - 341S0109 $77D.28F1

2) 341S0168 - 341S0171 $77D.28F2

3) 341S0280 - 341S0283 $77D.34F2

4) 341S0380 - 341S0383 $77D.34F5

These are all the ROMs I've found in the PowerSurge (x500, x600, 7300) family and the Catalyst (7200 and clones) family.

1) Found in a very few 7200s and early 7500, 8500 and 9500 machines. I've never seen it in a clone.

2) Found in the vast majority of 7200, 7500, 8500 and 9500 machines and all of the family clones, including the S900.

3) Found in the original (non-"Enhanced", non-Kansas) 8600 and 9600. Found in 7300, I think. The PM7600 keeps #2. Not found in clones.

4) Found only in the PM8600 Enhanced and PM9600 Enhanced, also known as the Kansas or Mach V machines.

The PowerSurge and Catalyst families are very similar in architecture. The primary (only?) difference is that the PowerSurge machines use the Hammerhead chip as the primary bus manager (CPU bus, memory manager, etc.) and the Catalyst machines use Platinum. PowerSurge machines equipped with built-in video use CHAOS/Control while Catalyst machines use Iridium.

Hammerhead part #: 343S1190
Bandit part #: 343S0020 -- I do not know why OF refers to Bandit as 1126 when they are all (AFAICT) marked 0020.
Grand Central part #: 343S1125
CURIO part #: AM79C950 -- Custom part from AMD, combines 85C30, 53C94/96 (53C80 successor) and ethernet.

I don't have the part number for Platinum handy.

Discussion #1: The PowerSurge architecture was meant to be extensible. The CPU bus, in theory, supports up to four devices beyond the CPU(s), presumably at F000 0000, F200 0000, F400 0000 and F600 0000. In practice the firmware is written to look for CHAOS/Control at F000 0000 on video equiped Macs and Bandits at F200 0000 and F400 0000. In theory one should be able to put four Bandits on there at all four addresses, with appropriate firmware modification.

But, back in the real world, we have the 7x00 and 8x00 machines which have CHAOS/control at F000 0000 and one Bandit at (?) F200 0000 and we have the 9x00 machines which have two Bandits, one at F200 0000 and one at F400 0000.

The S900 is an odd duck. It is similar to a 7x00 machine in that it only has a single Bandit at F200 0000. But it lacks built-in video (CHAOS/Control) like a 9x00.

Apple put four PCI devices on every PCI1 (Bandit at F200 0000), the Grand Central chip (343S1125) and three PCI slots. Apple put three PCI devices on every PCI2 (Bandit at F400 0000), three PCI slots.

However, Bandit can support at least six PCI devices, as it does so on the Apple Network Server.

The S900 loses one PCI slot from PCI1 by permanently installing a DEC 21052-AB PCI-PCI Bridge (PPB) in PCI slot C. This is why it has two "upper" or direct to Bandit slots, slots A1 and B1. There are four slots supported by the PPB. So A1 + B1 + four PPB slots = 6.

End Discussion #1

To solve this issue, we need:
- SuperMac S900 model description.
- List of PCI cards that causes the problem. Is it just one PCI card with every other slot empty? That would be simplest.
- 4MB ROM dump.

I'm not sure what you mean by "S900 model description", but I hope the above covers it. It's a PowerSurge machine with Hammerhead and DPATH chips, and a single Bandit and nothing else (other than CPU) on the CPU bus. It uses the exact same ROM as the 7500/8500/9500, $77D.28F2, 341S0168 - 341S0171.

List of PCI cards that cause problems. Unfortunately, it is not as simple as one PCI card. Generally, if one installs a single PCI card in the lower 4 slots, the machine will function properly, even though that one card is multi-function/has PPB.

Note that every PCI slot on the PowerSurge family has a single unique interrupt line which runs back to Grand Central. So the four lower PCI slots in the S900, behind the PPB, must share that single interrupt. I don't know, but I think this could be related to the problem. When there's just one card installed, the S900 seems to behave as if it's just installed in Slot C1 in a normal PowerMacintosh.

I really wish the SuperMacs LEMList archive was available, but I found a bunch of notes about experiments I did and I'll transcribe below. (Note, Slots 1 and 2 are A1, B1; slots 3 - 6 are PPB slots.):

1.
Slot 1: VST UltraTek-66
Slot 2: IxMicro Twin Turbo
Slot3:
Slot 4:
Slot 5: Adaptec 2940UW
Slot 6:
Normal operation
===========================
2.
Slot 1: Adaptec 2940UW
Slot 2: IxMicro Twin Turbo
Slot 3: VST UltraTek-66
Slot 4:
Slot 5:
Slot 6:
Normal operation
============================
3.
Slot 1:
Slot 2: IxMicro Twin Turbo
Slot 3: VST UltraTek-66
Slot 4:
Slot 5: Adaptec 2940UW
Slot 6:
Normal operation
==============================
4.
Slot 1:
Slot 2:
Slot 3: VST UltraTek-66
Slot 4: IxMicro Twin Turbo
Slot 5: Adaptec 2940UW
Slot 6:
Freeze at boot
========================= Suspects Twin Turbo
5.
Slot 1:
Slot 2: VST UltraTek-66
Slot 3:
Slot 4: IxMicro Twin Turbo
Slot 5: Adaptec 2940UW
Slot 6: Adaptec 3940U
Freeze at boot
=========================
6.
Slot 1: Adaptec 2940UW
Slot 2:
Slot 3: VST UltraTek-66
Slot 4: IxMicro Twin Turbo
Slot 5:
Slot 6:
Freeze at boot
=========================
7.
Slot 1: IxMicro Twin Turbo
Slot 2:
Slot 3: Adaptec 2940UW
Slot 4: VST UltraTek-66
Slot 5:
Slot 6:
Freeze at boot
========================= Maybe not the Twin Turbo
8.
Slot 1: IxMicro Twin Turbo
Slot 2:
Slot 3: VST UltraTek-66
Slot 4: Adaptec 2940UW
Slot 5:
Slot 6:
Normal operation
========================= Hmmm. Okay if 2940UW is below VST...see 3rd experiment above.
9.
Slot 1: IxMicro Twin Turbo
Slot 2:
Slot 3: VST UltraTek-66
Slot 4: Adaptec 2940UW
Slot 5:
Slot 6: IxMicro Ultimate Rez.
Freeze at boot
=========================
10.
Slot 1: IxMicro Twin Turbo
Slot 2: VST UltraTek-66
Slot 3:
Slot 4: Adaptec 2940UW
Slot 5:
Slot 6: IxMicro Ultimate Rez.
Normal operation
=========================
11.
Slot 1:
Slot 2:
Slot 3: IxMicro Twin Turbo
Slot 4: VST UltraTek-66
Slot 5:
Slot 6:
Freeze at boot
=========================

The following are older notes and not as complete. They often don't mention what is in slots 1 and 2. Probably a Twin Turbo card so I have video.

12.
Slot 1:
Slot 2:
Slot 3:
Slot 4: Adaptec 3940U
Slot 5:
Slot 6: Adaptec 3940U no EEPROM (firmware) installed on card.
Normal operation -- ASP only shows slot 6 (did I mean 4?) card.
=========================
13.
Slot 1:
Slot 2:
Slot 3:
Slot 4: Adaptec 3940U no EEPROM (firmware) installed on card.
Slot 5:
Slot 6: Adaptec 3940U
Normal operation -- ASP shows both cards as working. Firmware is loaded from 6 first and then 4?
=========================
14.

Notes mention multiple experiments showing that 3940U will work in slots 3 - 6 if alone. Installing another card in 3 - 6 causes freeze at boot.
=========================
15.
Slot 1:
Slot 2:
Slot 3:
Slot 4: Adaptec 3940U
Slot 5:
Slot 6: VST UltraTek-66 -- no hard drives connected
Normal operation
=========================
16.
Slot 1:
Slot 2:
Slot 3:
Slot 4: Adaptec 3940U
Slot 5:
Slot 6: VST UltraTek-66 -- with hard drives active/powered.
Freeze at boot
=========================

From memory: Anything that appears as a dual function card, VST Ultratek-66 (2 SCSI busses), 3940U or 3940UW, (2 SCSI busses), Radeon 7000 (two video cards) is problematical in the slots 3 - 6 of the S900. If it is the only card installed alone in slots 3 - 6 it will work. And in some cases they will coexist with a 2940UW, as long as the 2940UW is in a higher numbered (physically lower) slot.

As far as I know the 2940UW is the only card with the ability to function and coexist with multi-function cards in some circumstances. Although, at this later date, I now wonder if I had any hard drives connected to the 2940UW in every experiment. That seemed to make a difference for the VST.

Also, cards like ethernet, USB and Firewire can coexist in the lower slots, if they are not connected to anything, i.e. there's no reason for their drivers to load. Add a connected device and they will trigger the issue with a multi-function card.

If one sticks to single function cards in slots 3 - 6, operation is fine.

For the IxMicro Ultimate Rez card, while it will work in the lower slots, trying to change the color depth or screen resolution will cause the machine to freeze.

TLR:
1. Lower slot problems in the S900 are not just triggered by cards with physical PPBs on board. Multi-function cards like the VST UltraTek-66 and the Radeon 7000 also trigger the issue. Internal PPB or just something about multiple card functions and the drivers?

2. A multi-function card can work in the lower slots of the S900 as long as it is the only active card in slots 3 - 6.

3. In some circumstances the Adaptec 2940UW can coexist with a multifunction card in the lower slots.

4. The ixMicro Ultimate Rez video card will work in lower slots, but changing color depth or screen resolution triggers a freeze.

Discussion #2: I chased this problem all over the place in the years surrounding 2000. I tried changing the DEC 21052-AB chip with the Intel 21152-AB, Intel 21152-BA and the Hint something or other. They make or made a pin compatible PPB.

I also changed the ROMs in the S900 to the $77D.34F2 and $77D.34F5 versions without any change in the slot 3 - 6 behavior.

So the problem is probably not a bug in the design of PPB chips and Apple did not fix the problem in the three (four) ROM revisions that were used in the PowerSurge family.

Odds and Ends:


Patent Numbers (should let you download the patents from the US Patent Office):

Bandit: 5,692,137
Hammerhead: 5,592,631
DPATH chips/Interleaved memory?: 5,619,471

BTW, Bandit, by itself, is not a complete PCI controller, or more correctly, CPU bus to PCI bus bridge. PCI devices must request mastery of the bus and wait for it to be granted, and who currently has mastery is arbitrated by some logic. That logic does not live on Bandit. It lives in a little PLCC-28 chip labeled 343S0182.

Bandit itself can probably support up to 16 PCI devices logically. However, the number of devices that 343S0182 can arbitrate for is considerably more limited because you need a REQ and a GNT pin for each device. Bandit and 343S0182 do support at least six devices, because the Apple Network Server has 6 PCI devices on one Bandit (2 X 53C825, Cirus Logic GD54M30, Grand Central, 2 X PCI slots).

Most of a Bandit pin out: Bandit Pinout

 

[trag]

I think there were multiple S900 versions? So I was asking which version you have. Maybe they only differ by clock speed?

Yep, they're all identical physically and firmware-wise. Clock speed is controlled by which CPU card is installed.

 

[Phipli]

@trag

If the Bandit supports 6 slots, why did they use a bridge at all? At least with two Bandits there are meant to be speed benefits somehow.

 

[CircuitBored]

I think there were multiple S900 versions? So I was asking which version you have. Maybe they only differ by clock speed?

Your dump-device-tree has the following info:

bus speed: 45MHz (clock-frequency 02AEA540)

CPU: 604 (cpu-version 00090202 which is actually PowerPC 604e v2.2)

CPU speed: 195MHz (clock-frequency 0B9F76C0) I don't see a 195 MHz variant at https://lowendmac.com/1996/umax-supermac-s900/ . Is it supposed to say 200 MHz?

My logic board is labelled 9010042-0002 Rev. C, which I believe is the last revision. I think the bus speed is set dynamically, as installing a different speed CPU changes it. With a 400MHz G3 installed the bus runs at 50MHz. I reinstalled the original CPU for testing purposes as I wasn't certain that the Sonnet card wasn't messing with nvram, however further investigation indicates that it is the Sonnet driver installer that does nvram tweaking. The current 604e card is 225MHz. I indeed zapped the PRAM before running lspci.

Which lspci does the dump-device-tree belong to? I think it must be the S900VGAONLY one.
There should be a dump-device-tree for each lspci.
The dump-device-tree has a PCI bridge in slot C1.

Correct, that's dump-dev-tree with just the graphics card installed. I've attached dev-trees for the other combinations, and one with the problematic card in the fourth slot too (and a parsed lspci), considering @trag's comment shows there's an extra degree of complexity to this PCI oddness.

FYI: There was a syntax error on line 90 of parselspciFromOpenFirmware.sh

                if (( is64bit )) then # previous bar is beginning of 64 bit BAR

Adding a semicolon fixed it and it ran without error, allowing me to parse my own lspci output

                if (( is64bit )); then # previous bar is beginning of 64 bit BAR

To my eyes it looks as though OF is seeing everything in its right place.

If C1 is the bridge for the other 4 slots, then how do you have Adaptec card in slot C1?

That's just a mistake on my part. The slot is physically labelled 'C' so I was calling it C1, although that is not its logical name. Going forward I'll refer to the physical slots as A-F and append numbers for the logical slots, unless you think it would be less confusing to reference the physical slots numerically (i.e. slots 1-6).

Which case is the problematic one?

All of them. In slot B both the PCI cards that I mentioned are listed as "4-port ethernet card" in Apple System Profiler. Installed in any of the lower slots they cause the system to freeze on startup.

which means you can't boot from the Adaptec PCI card?

See above, the card is a total non-starter in this system but works perfectly in a beige G3.

Which method did you use to extract the ROM?

I wrote some Forth! It didn't work properly but figuring out how to fix it lead me to a comment of yours made over on the macrumors forums, here. Your code worked like a charm, unsurprisingly.

After getting some help from @tashtari to convert the hex to a binary (spoiler: it was some basic Python) I used the

diff

command in Mac OS to compare the ROMs. I wonder why it showed the 9500 v1 ROM as a mismatch but the v2 as a match.

This may be unrelated but it's another "S900 weird thing" that I have encountered so I'm throwing it on the pile. There are official installers for the S900 for Mac OS 7.5.5 and Mac OS 8, you can find images for them on macintoshgarden and macintoshrepository. When burned to a CD, neither of these images will boot, throwing up the "This disk is not for this system" (or words to that effect) error. If you run the installers from inside an OS then you get the same result when booting the disk you installed to. AFAIK there is no unique identifier for the S900. As far as the OS is concerned it is a 9500. If that is the case, then why would these installers not work? It's mildly baffling.

Is it possible that the

OFpt

resource is slightly different for the S900 installers? I might investigate that this afternoon.

 

[CircuitBored]

Bandit part #: 343S0020 -- I do not know why OF refers to Bandit as 1126 when they are all (AFAICT) marked 0020.

1126 and 0020 seem to universally coexist. The 9500 has two 0020s and two 1126s, the S900 has one of each. It's possible that they are two physical parts of the same logical thing.

 

[Arbee]

343S1126 is Bandit version 2 (and Bandit's official part number from its ERS), 343S0020 is Bandit version 3. I don't know what's different.

 

[joevt]

The first item I use is the "Firmware Revision" reported in Apple System Profiler.

That's a simple 32-bit number. Easy to type. I prefer the 33554432-bit number to be sure.

From your description of the problems, it seems like the solution might not be fixable in Open Firmware. It still would be interesting to see if a S900 created in DingusPPC emulator will have any of those problems (after DingusPPC can fully boot).

1126 and 0020 seem to universally coexist. The 9500 has two 0020s and two 1126s, the S900 has one of each. It's possible that they are two physical parts of the same logical thing.

I don't see a 1126 in the picture of the 9600 motherboard on wikipedia just 0020. The 9500 motherboards also seem to have 0020. Where are the 1126s?

however further investigation indicates that it is the Sonnet driver installer that does nvram tweaking.

We can use derez on classic or modern macOS to view the resources of the Sonnet driver to see if they have the nvramrc script.

Is it possible that the

OFpt

resource is slightly different for the S900 installers? I might investigate that this afternoon.

Possibly. You would need to find the different versions to compare. I don't think grep will search resource forks so you would have to derez or xattr them first.

FYI: There was a syntax error on line 90 of parselspciFromOpenFirmware.sh

                if (( is64bit )) then # previous bar is beginning of 64 bit BAR

Adding a semicolon fixed it and it ran without error, allowing me to parse my own lspci output

                if (( is64bit )); then # previous bar is beginning of 64 bit BAR

Good catch. I'm using zsh instead of bash. zsh is the default for current versions of macOS. Are you using bash? Doing some testing, it seems zsh doesn't care but bash does. I wonder why https://www.shellcheck.net doesn't complain about the missing semicolon even though it doesn't support zsh (you need to add #!/bin/bash for shellcheck).

I do have a fork of pciutils and directhw that should work in any version of Mac OS X so you can do lspci on Power Mac in Mac OS X 10.4 or Mac OS X 10.5. There is sufficient code to make it work on Apple Silicon Macs but I don't have an Apple Silicon Mac to test and I think it may cause a kernel panic - hopefully it's just a bug and doesn't mean that it can't work on Apple Silicon Macs.

lspci for Open Firmware has one advantage - it tests the size of each BAR. It's not safe to mess with BARs while the devices are in use by a driver but Open Firmware is a simple environment where there's not a lot of I/O happening all the time and lspci's test is only a few couple instructions long.

pciutils probably can't test BAR sizes safely while an OS is running. I suppose it could be modified to get the BAR size info from ioreg.

After getting some help from @tashtari to convert the hex to a binary (spoiler: it was some basic Python)

I use xxd -p -r to convert hex to binary.

I used the

diff

command in Mac OS to compare the ROMs. I wonder why it showed the 9500 v1 ROM as a mismatch but the v2 as a match.

The Open Firmware part of the v1 and v2 ROMs are identical. I didn't check which parts are different. You can use https://github.com/elliotnunn/tbxi to extract some other parts and then compare those.

Maybe the S900 was created after the v2 ROM was created so they used the v2 ROM.

I wrote some Forth! It didn't work properly but figuring out how to fix it lead me to a comment of yours made over on the macrumors forums, here. Your code worked like a charm, unsurprisingly.

There's some newer comments listed in the first post at
https://forums.macrumors.com/thread...l-work-in-a-beige-power-macintosh-g3.2303689/
Search for "rom dump" in the first post. Then there's some links in that paragraph. The last one to #682 has info about verifying the address translations. Check if the ROM is already mapped, and if it isn't, then map the ROM to a range that is not mapped. This is necessary for dumping New World ROMs. The example commands map the New World ROM (last 1 MB of physical memory) to address 0x40000000.

See above, the card is a total non-starter in this system but works perfectly in a beige G3.

The Adeptec card is USB and FireWire and Open Firmware 1.0.5 doesn't have code to boot from those, just like it doesn't have code to boot from third party SCSI controllers.

I've attached dev-trees for the other combinations, and one with the problematic card in the fourth slot too (and a parsed lspci)

Some minor issues with your lspci output:
- You have an out of date pciutils (misinterpreting the PM and B3 flags of the Power Management capabilities and not showing the bit size of behind bridge registers).
- You have an out of date pci.ids (not showing the device name for the USB and FireWire controllers).

There's a bug in the script for bash. It seems that printf in zsh will accept a register name in the parameter list while printf in bash does not. In this example: z=1234; printf "%x %x" "$z" "z" zsh will print 4d2 in both cases but bash will output 0 and an error in the second case because z is not a number. I've attached an update.

To my eyes it looks as though OF is seeing everything in its right place.

I also don't see a problem in Open Firmware.

All of them. In slot B both the PCI cards that I mentioned are listed as "4-port ethernet card" in Apple System Profiler.

And none of them are a 4-port ethernet card? I would like to see a screenshot or export from Apple System Profiler. Also output from Apple's DisplayNameRegistry or my DumpNameRegistry.

 

[Phipli]

I don't see a 1126 in the picture of the 9600 motherboard on wikipedia just 0020. The 9500 motherboards also seem to have 0020. Where are the 1126s?

Here is one on a 9500 (one of two)

 

[Phipli]

The Adeptec card is USB and FireWire and Open Firmware 1.0.5 doesn't have code to boot from those, just like it doesn't have code to boot from third party SCSI controllers.

They mean "doesn't work at all", they're not talking about booting from it

 

[joevt]

Here is one on a 9500 (one of two)

Right. @Arbee said they are different versions of the same chip but @CircuitBored said they coexist. Maybe @CircuitBored meant they exist in different Power Macs but not in the same Power Mac.

They mean "doesn't work at all", they're not talking about booting from it

What if it's a driver issue in Mac OS 9? Anyone tried Mac OS X using XPostFacto? Or Linux?

Regarding the Gazelle Hack, that worked by making the ATI GPU get probed last. To do that in the S900 or any Power Mac where the GPU is on a PCI card, you just need to move the GPU to a slot that gets probed later.

The order of probing with Open Firmware 1.0.5 is this:
/bandit/: @D (slot A1), @E (slot B1), @F (slot C1)
/chaos/: @B, @D, @E
/bandit@F4000000/: @D (slot D2), @E (slot E2), @F (slot F2)

So I would try the ATI gpu in slot B and the problem card in slot A. However, the problem in Gazelle was probably an old ATI fcode driver. The ATI Rage 128 is newer and probably doesn't have that problem.

Another thing to try is disabling slot C1 altogether. To do that, change pci-probe-list like this:
setenv pci-probe-list FFFFFF7F

Here's some pci-probe-list notes:

In IEEE-1275, pci-probe-list is defined as a string listing the slots in the order they should be probed.

On the 9600 and similar Macs, pci-probe-list is a 32 bit number that has the following format:

     bridge number: 7    6    5    4    3     pci2         pci1         vci0
 PCI device number: ---- ---- ---- ---- ----  F  E  D  B   F  E  D  B   -  E  D  B
         slot name:                           F2 E2 D2     C1 B1 A1        VCI
This format does not allow changing the order in which slots are probed.

The bridge number is the two bits 26,25 of the bridge device unit address:

devalias
vci0                /chaos@F0000000     // 0xF0000000 >> 25 & 3 = 0
pci1                /bandit@F2000000    // 0xF2000000 >> 25 & 3 = 1
pci2                /bandit@F4000000    // 0xF4000000 >> 25 & 3 = 2


For pci1 and pci2, device @B is a bandit pci device (with different reg properties for pci2):

/bandit@F2000000/pci106b,1@B
PROPERTIES:
name                    pci106b,1
vendor-id               0000106B
device-id               00000001
revision-id             00000003
class-code              00060000
min-grant               00000000
max-latency             00000000
devsel-speed            00000001
fast-back-to-back
reg                     00005800 00000000 00000000  00000000 00000000


For vci0, the slots are for the following built-in devices:

/control@B     // monitor out
/planb@D       // video in

device @E is for a VCI slot.


Examples:

To disable device @D (top slot - closest to processor) of pci1 use 
setenv pci-probe-list FFFFFFDF

To disable device @E (middle slot) of pci1 use
setenv pci-probe-list FFFFFFBF

To disable device @F (bottom slot) of pci1 use
setenv pci-probe-list FFFFFF7F

To disable device @B of vci0 use
setenv pci-probe-list FFFFFFFE

 

[CircuitBored]

Maybe @CircuitBored meant they exist in different Power Macs but not in the same Power Mac.

I think I'm just suffering from a small-scale version of the Mandela Effect. I could have sworn that the 9500 had 0020 and 1126 on it. Time to start going off notes and checking actual logic boards rather than my crusty memories.

What if it's a driver issue in Mac OS 9? Anyone tried Mac OS X using XPostFacto? Or Linux?

I just tried the card under OS X and... it works in the second PCI slot. In the lower PCI slots it causes OS X to hang at startup.