• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

The Great Gazelle PCI Hack Thread, Part 2

joevt

Well-known member
Wow, I didn’t even think of doing that... That’ll surely make the script WAY smaller.

As for the 6500 info, I can get you that once I grab my machine in a couple weeks. I can even dump the entire system ROM for you, if that’d be of use (which I wanted to do anyways to patch in support for PPC740 CPU).
The information would be greatly appreciated. There might be some difficulty with emulating the PSX+ memory/PCI controller (no documentation?) so I don't know when or if I'll be able to get beyond that.

As for the ROM, I have the 4MB rom 6e92fe08 (md5 670f3d04b8844cf89aae4391398d4b5c) from Macintosh Garden. Let me know if your's is different.

I don't think the script is small enough to include the nvramrc script for OS X (if running OS X is a thing people want to do with the 6500? I read it has issues with OS X?). One of the other previously discussed methods for storing and executing a larger script would still be required.

My plan with dingusppc was to figure out how Open Firmware fails with the emulated PCI card (with pci-bridge and multifunction devices) then go from there. But that can be done with a real Mac. Figure out what the nvramrc script is doing, find what part of Open Firmware is supposed to do that (using the Open Firmware listings from my DumpMacRom.sh script), then create some code to call that part of Open Firmware. Maybe try to trace the Open Firmware code using my Trace for OpenFirmware script.
 

CircuitBored

Well-known member
This is all very cool to see developing. One thing I'm curious about is whether or not this sort of patching could be applied to the ROM of the SuperMac S900 ("Storm Surge"?). As far as I know, the issue faced by the S900 is that four of its six PCI slots are behind a PCI-PCI bridge and because of this the ROM does not identify many installed cards correctly. PCI cards that themselves have PCI-PCI bridges do not work at all, AFAIK. Are these similar issues or am I barking up the wrong tree?
 

Phipli

Well-known member
@dosdude1 @joevt @cheesestraws

I double checked a load of the data on my 8600. Here is a description of my card for reference (excuse it being a photo, I'm lazy) :
IMG_20221216_154701.jpg
So, FireWire works, USB doesn't (but I haven't made sure everything OS wise is right yet, so I'm not saying therevis an issue, and SATA doesn't mount the disk. Investigating in OpenFirmware, I can see all 5 devices and sub devices are registered, but the SATA disk is not attached to the SATA chipset.
6500:
IMG_20221216_155047.jpg
This is what the same card looks like loades on my 8600 :
IMG_20221216_155314.jpg
Interestingly it hasn't picked up the device name either, but seems to be showing the PID instead (which they have joyfully given as "3112" same as the chip model).

Thoughts welcome.

I added the stuff to set the openfirmware i/o to keyboard/monitor to the last of the three scripts and loaded it into an application. I'll share it here shortly in case anyone else wants to experiment?
 

dosdude1

Well-known member
@dosdude1 @joevt @cheesestraws

I double checked a load of the data on my 8600. Here is a description of my card for reference (excuse it being a photo, I'm lazy) :
View attachment 50232
So, FireWire works, USB doesn't (but I haven't made sure everything OS wise is right yet, so I'm not saying therevis an issue, and SATA doesn't mount the disk. Investigating in OpenFirmware, I can see all 5 devices and sub devices are registered, but the SATA disk is not attached to the SATA chipset.
6500:
View attachment 50233
This is what the same card looks like loades on my 8600 :
View attachment 50234
Interestingly it hasn't picked up the device name either, but seems to be showing the PID instead (which they have joyfully given as "3112" same as the chip model).

Thoughts welcome.

I added the stuff to set the openfirmware i/o to keyboard/monitor to the last of the three scripts and loaded it into an application. I'll share it here shortly in case anyone else wants to experiment?
This is what I was afraid of... It’s not executing the option ROM for the SATA portion of the card. But you said you had SATA working before with your scripts? That’s very odd if so, as that’s what I based this script off of. Maybe try changing the ordering in which each device is initialized, and see if that makes any difference.
 

Phipli

Well-known member
This is what I was afraid of... It’s not executing the option ROM for the SATA portion of the card. But you said you had SATA working before with your scripts? That’s very odd if so, as that’s what I based this script off of. Maybe try changing the ordering in which each device is initialized, and see if that makes any difference.
Really sorry, but this will be my memory rather than a change. Family visited (I had to hide my weird hobbies and pretend I didn't have a stack of 4 beige macs in the diningroom window) and I never came back to it or documented what I had. I know I had USB working (2/3s, plus FW), but seeing this reminds me that I've seen and discussed the issue before, but got no further l between struggling with no knowledge of forth, lack of script space and not knowing how to attach the drive.

Is there any way to rerun the code that runs the option ROM?
 

Phipli

Well-known member
Also spotted the machine flashes "Can't open device" on the screen before loading the half tone background during boot. If it is of interest.
 

Phipli

Well-known member
This is what I have loaded into the 6500 atm. joevt's script, with the cpokes needed to get the video and keyboard working in OpenFirmware.

I recommend someone else gives it a try in case my 6500 is playing up.
 

Attachments

  • 6500 Combo Enable alt vdu.zip
    25.7 KB · Views: 4
Last edited:

joevt

Well-known member
@dosdude1 @joevt @cheesestraws

I double checked a load of the data on my 8600. Here is a description of my card for reference (excuse it being a photo, I'm lazy) :
View attachment 50232
So, FireWire works, USB doesn't (but I haven't made sure everything OS wise is right yet, so I'm not saying therevis an issue, and SATA doesn't mount the disk. Investigating in OpenFirmware, I can see all 5 devices and sub devices are registered, but the SATA disk is not attached to the SATA chipset.
6500:
View attachment 50233
This is what the same card looks like loades on my 8600 :
View attachment 50234
Interestingly it hasn't picked up the device name either, but seems to be showing the PID instead (which they have joyfully given as "3112" same as the chip model).

Thoughts welcome.

I added the stuff to set the openfirmware i/o to keyboard/monitor to the last of the three scripts and loaded it into an application. I'll share it here shortly in case anyone else wants to experiment?
Debugging Open Firmware is much easier with a serial port connection to another computer.

Is the 6500 screenshot with or without the nvramrc script? If the SATA device is not visible before the nvramrc script, then of course it won't have the sata disk or device name which require the fcode from the expansion rom that gets executed by probe-all but probe-all is executed in the nvramrc script before the patching stuff. Moving the patching stuff isn't going to help since it depends on probe-all to at least do the pci-bridge. What we have to find is why probe-all isn't probing the devices behind the pci-bridge.
 

Phipli

Well-known member
Debugging Open Firmware is much easier with a serial port connection to another computer.

Is the 6500 screenshot with or without the nvramrc script? If the SATA device is not visible before the nvramrc script, then of course it won't have the sata disk or device name which require the fcode from the expansion rom that gets executed by probe-all but probe-all is executed in the nvramrc script before the patching stuff. Moving the patching stuff isn't going to help since it depends on probe-all to at least do the pci-bridge. What we have to find is why probe-all isn't probing the devices behind the pci-bridge.
The 6500 photo is with your nvramrc script. Without it you only get the pci-bridge and no more.

I realise it is probably more handy when you're srt up, but using the screen and keyboard suits me better because I don't have to run two computers. I'll switch if it becomes inconvenient - I have limited space, I'm ballanced in the corner of the dining room.

I've confirmed there is an something squiffy going on with USB in the current proposed script, it crashes when the driver loads. The old 2xUSB+FW script didn't. I have no understanding why (better at mechanics than poking firmware). Sorry I'm not more help, I'm more persistence than skill.
 

dosdude1

Well-known member
Really sorry, but this will be my memory rather than a change. Family visited (I had to hide my weird hobbies and pretend I didn't have a stack of 4 beige macs in the diningroom window) and I never came back to it or documented what I had. I know I had USB working (2/3s, plus FW), but seeing this reminds me that I've seen and discussed the issue before, but got no further l between struggling with no knowledge of forth, lack of script space and not knowing how to attach the drive.

Is there any way to rerun the code that runs the option ROM?
Could you display the .properties of the SATA device in the device tree in the 6500?
 

joevt

Well-known member
I did some testing with Open Firmware 1.0.5 in dingusppc. It seems that it will not probe devices connected to a nested pci-pridge (which has been suggested earlier in the thread). This might be the same problem as the 6500 but I'm not sure. Can someone show dev / ls and .properties of bandit and pci-bridge without the patch and no PCI cards? Then again with a PCI card but still no patch?
 

Phipli

Well-known member
I did some testing with Open Firmware 1.0.5 in dingusppc. It seems that it will not probe devices connected to a nested pci-pridge (which has been suggested earlier in the thread). This might be the same problem as the 6500 but I'm not sure. Can someone show dev / ls and .properties of bandit and pci-bridge without the patch and no PCI cards? Then again with a PCI card but still no patch?
Yeah, I think the 6500 etc have a bridge built in - they have an ATI Rage IIc (if I remember correctly) connected to PCI on the logic board or riser.

The item "pci-bridge" is the combo card, I can't detach cards from it, they're the same thing.
 

Phipli

Well-known member
Hum. Can't see an actual integrated bridge showing up in the tree, so it may not be true.

Without script :
IMG_20221217_152208.jpg
IMG_20221217_152252.jpg
IMG_20221217_152638.jpg
As mentioned, I can't give you .properties of pci-bridge with it removed, so I've left the cards in.
 

Phipli

Well-known member
And you didn't ask, but the same on an 8600 where the card works just fine.
IMG_20221216_130937.jpg
IMG_20221216_131107.jpg

I don't have a photo for bandit itself , I wasn't looking that far down the tree yesterday.
 

joevt

Well-known member
Hum. Can't see an actual integrated bridge showing up in the tree, so it may not be true.

Yeah, there was a bug in my emulation code so I was wrong about OF 1.0.5 not probing a nested bridge. But I still see a limit: it won't probe a doubly nested bridge.
Code:
FF831B60: /bandit@F2000000
FF83F048:   /pci-bridge@E
FF83FCB0:     /pci-bridge@0
FF8408F0:       /pci-bridge@0
FF841558:       /pci16b8,12@1
FF841830:     /pci16b8,12@1
You see pci1/@E and pci1/@E/@0 have attached devices but the devices I attached to pci1/@E/@0/@0 are not probed so they don't appear in that list and the pci1/@E/@0/@0 bridge does not get it's primary, secondary, and subordinate bus numbers modified.
 

joevt

Well-known member
Also, I noticed that all the versions of Open Firmware (including my Quad G5) only probe device numbers 0 to 15 (@F) for a pci-bridge even though it should be possible to have device numbers up to 31 (@1F).
 
Top