• 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

Byrd

Well-known member
Hi all,

I'm having a bit of trouble getting the nvram patch to "take" - this is on a stock TAM with Tango 2.0 card installed and a fresh install of Mac OS 9.1 with the USB and Firewire drivers installed.

With or without the patch installed, it continues to display 4 port Ethernet card and pci-bridge. I can charge off FW but not detect any devices - this includes a FW iPod and FW hard disk both working on another FW Mac.

See below, when patch is run nothing is displayed in the your current nvramc. I'm assuming something should be displayed here if the patch applied properly.

I've reset the PRAM, reset the CUDA and disconnected the power/battery for some hours.

Thanks

JB
 

Attachments

  • IMG_8740.jpeg
    IMG_8740.jpeg
    488.1 KB · Views: 10
  • IMG_8739.jpeg
    IMG_8739.jpeg
    283.3 KB · Views: 9
Last edited:

Phipli

Well-known member
Hi all,

I'm having a bit of trouble getting the nvram patch to "take" - this is on a stock TAM with Tango 2.0 card installed and a fresh install of Mac OS 9.1 with the USB and Firewire drivers installed.

With or without the patch installed, it continues to display 4 port Ethernet card and pci-bridge. I can charge off FW but not detect any devices - this includes a FW iPod and FW hard disk both working on another FW Mac.

See below, when patch is run nothing is displayed in the your current nvramc. I'm assuming something should be displayed here if the patch applied properly.

I've reset the PRAM, reset the CUDA and disconnected the power/battery for some hours.

Thanks

JB
Depending on what format newlines were used, it doesn't show. Apply the patch and restart. Don't worry about the current contents thing.
 

Phipli

Well-known member
I'm assuming something should be displayed here if the patch applied properly.
Note how "your current nvramrc" is 190 bytes? It just doesn't display correctly because of the newlines.

Firewire never shows correctly in System Profiler (just ignore system profiler, its awful at seeing hardware it doesn't expect), but drives should appear on the desktop. Do other devices you have need extra drivers that don't exist?
 

trag

Well-known member
Another idea I had was just to get rid of the PCI-PCI bridge altogether... Technically it shouldn't be necessary, as you can in theory just put all 3 devices (in this case SATA, FireWire and USB controller) all on the same PCI bus. That is if you don't end up reaching some sort of PCI device limitation on these machines.


I'm still about 6 pages from the end of this thread, so apologies if this has been discussed in the last couple of months....

Every PCI device requires a Bus Request and a Bus Grant signal. One of the functions of a PCI-PCI Bridge is to arbitrate (accept Bus Request, Send Bus Grant) to the sub-devices behind (downstream of) the bridge and then send the required Request and pass on the Grant from the host (upstream) bus.

Mounting the PCI devices in parallel, I guess just OR'ing the Bus manangement signals together would almost certainly be BAD.

All that said, I love the additional discussion of OF so far.

While I'm posting before reading further....

On the Macs I've looked at, the NVRAM physical storage is provided by an 8KB SRAM (static RAM) chip. It is pin compatible with 32KB SRAM chips. However, to be useful, Apple would have had to implement the extra 2 address lines. I have no idea how the system addresses NVRAM and/or if the assumption of 8KB is built into the system. But if one is hard coding addresses, it might be interesting to substitute in a 32KB SRAM chip and see if NVRAM space is expanded. I guess the extra space would also need to be in the machine's memory map for NVRAM.

I have installed 32KB SRAM chips, and the machines in question worked fine afterwards, but I didn't have the software chops to really explore whether the additional space was available. The utilities I tried to interrogate the size of NVRAM may just report what they expect.
 

trag

Well-known member
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.

In case this might be useful... I noted this earlier in the thread, but it was long, long ago.

While Gazelle has trouble with all PCI-PCI Bridge cards, PowerSurge (X500/X600) works properly with one level of PCI-PCI Bridge.

That is, in the PowerSurge machines, the issue is when you reach a second level of PCI Bridges. For example, the PowerSurge Clones made by Umax, the S900 and the J700, put all but 2 of the PCI slots behind a PCI-PCI Bridge. If one then installs a Bridged PCI card into one of those "lower" bridged slots, it will not function properly (with some interesting exceptions).

So, for example, an Adaptec 3940UW SCSI card which is two 2940UW cards behind a DEC 21052 bridge will work fine in an X500/X600 machine. In a Umax S900 or J700 it will work properly if it is installed in slot #1 or slot #2 (A or B). If it is installed in a lower slot it will be behind the PCI bridge when occupies slot C and it will not function as there is now a chain of two PCI-PCI bridges involved (motherboard PPB and card PPB).

I suspect, but do not know, that Apple did something in the Gazelle architecture that makes it act like the Gazelle PCI slots are already behind one bridge.

If that last sentence is true, then the PowerSurge and Gazelle problems are all symptoms of the same failure of Apple to properly deal with daisy chained PCI-PCI Bridges. OF will interrogate the first PCI-PCI bridge, but not any bridges behind that one.

Or so it seems....
 

trag

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?

Umax's S900 and J700 use the same ROM as the PM7500/8500/9500, so if a patch is developed for the X500/X600 families then it should work in the S900/J700.

However, there are four different revisions of ROM that might be found in the X500/X600 family. Only 2 of those revisions are present on the X500 (omitting later X600). Also, those two ROM revisions for the X500 family are also the ones used on the PM7200.
 

trag

Well-known member
Can confirm your patch works with all the combo cards I have here. Good stuff!

Ethernet on the three-way card doesn't work, but it's detected, and I'm apt to put that down to Realtek weirdness rather than Gazelle weirdness.

Do you have RealTek's driver for the 8139 cards? But it might need some kind of modification because of the bridge. IIRC, there's instructions in the 8169 driver regarding editing some parameters in the driver such as Vendor ID, depending on who used RealTek's chip in their product.
 

cheesestraws

Well-known member
Do you have RealTek's driver for the 8139 cards? But it might need some kind of modification because of the bridge. IIRC, there's instructions in the 8169 driver regarding editing some parameters in the driver such as Vendor ID, depending on who used RealTek's chip in their product.

I did - and I modified it according to the instructions. Didn't have any luck, than ran out of time to attempt to diagnose. I don't know really very much about this class of machine, alas...
 

trag

Well-known member
I did - and I modified it according to the instructions. Didn't have any luck, than ran out of time to attempt to diagnose. I don't know really very much about this class of machine, alas...

Thank you, Cheesestraws. It's also possible that RealTek's driver contains some flaw that prevents it from working when behind a PPB. I don't know enough about how drivers work to know if that is a possibility, though.
 

trag

Well-known member
@joevt I did fairly extensive (empirical) testing of the S900's behavior with various PCI cards a long time ago. I think I documented most of it in the LowEndMacs LEMlists "Supermacs". I think that's archived in Google groups.

I can remember some of the details. For one thing, it wasn't true that nothing worked when put behind 2 PPBs.

Background::

1) S900 has six PCI slots.
2) Slots 1 and 2 (A & B) are direct to Bandit. Upper slots.
3) Slot C is occupied by a DEC 21052.
4) Slots 3 - 6 are on the DEC 21052 PPB. Lower slots.

Observations:
1) Cards that work in PM9500 work fine in slots 1/2 of the S900.
2) A single PPB card in slots 3 - 6 will work. So, for example, if you install one PowerDomain 3940UW in a lower slot it will function properly as long as all the other slots are empty.
3) Add any other card to a another lower slot (with a 3940UW already installed) and the machine will freeze at the black screen during boot. IIRC, a little hazy on details.
4) Cards that don't load firmware from the card, such as FW, USB, ethernet, were less prone to cause problems.
5) Under certain circumstances, the ixMicro Twin Turbo can be installed in a lower slot and coexist with a PPB card. E.g., 3940UW in one lower slot, TT in another lower slot.
6) The VST UltraTek (SeriTek's Promise Ultra66 card) behaves as if it has a PPB on board. That is, will cause a freeze if installed in the lower slots and is not the only card. This is also true for most (all?) dual head video cards.

Anyway, I have a notebook around here with notes and might be able to hunt up the posts to the SuperMacs list (all from trag@io.com or trag@prismnet.com). I won't guarantee any kind of response time. I've been away from the list for most of the past year for various real life reasons.

ARRRRGGGHHH. Google Groups does not have any of hte SuperMacs posts before 2006. Grrrr. There's used to be a LEM archive somewhere.

Also I read a little of that MacRumors thread you referenced. I can manufacture Rev. A, B or C ROMs for the Beige G3,. I think. I know I have the Rev. C code. I have had the Rev. B code in the past but I'm not sure where I stored it. I may or may not have the A code, as no one ever really wanted Rev. A. I have a bunch of the blank circuit boards for hte ROM module on hand still from the pEX project.
 
Last edited:

trag

Well-known member
Does the S900 have an ATI chip? If not, then it's probably a different problem.

Are there any posts that describing the S900 issue?

No onboard video on the S900. The S900 uses the $77D.28F2 ROM Revision which Apple used in the X500 and 7200 machines. Chips physically labeled 341S0169 - 341S0172.

Because the same ROM is used on the 7500/8500 there will be code in there for CHAOS/CONTROL I don't know if that could be causing an issue similar to the ATI chip code in the Gazelle.
 
Top