• 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

DBJ314

Member
I wonder if these numbers represent the IDSel(ect) lines on the client chips. If so, it would be possible to determine them with an ohmmeter, rather than inserting the card in another machine. It's probably easier just to insert and read, but it makes me wonder.

IDSEL is how PCI determines which slot is which. Every slot has an IDSEL pin and each IDSEL pin (at a given level of bridges) must be tied to a unique address line in the PCI bus.

At boot time the host polls each PCI address bit one at time and checks IDSEL lines to see who responds.

All with a big IIRC.

Great work, with nice details on how to implement.

Those numbers are indeed IDSEL. The PCI Bus Binding to Open Firmware says so.

The IDSEL is also the "Device Number" field of each entry in the "reg" and "assigned-addresses" properties.
 

cheesestraws

Well-known member
I suspected as much but I must have skipped that bit in the PCI bus binding. The fact I didn't really understand what I was reading probably didn't help :). Either way, though, it's going to be easier to extract them from OF output than it is to trace them on the card, under nearly all circumstances
 

trag

Well-known member
On a regular PCI card it would actually be easier/faster to check them with an ohmmeter, assuming you had one handy and didn't have to hunt for it, set it up, etc. You'd just put one probe on the IDSEL pin of the PCI card edge connector and strum the other probe down the address pins.

But, on these combo cards, you'd need the pinout for the PCI-PCI Bridge in front of you, and you'd be probing from the IDSEL pins on the PCI-PCI bridge to the address pins. And you'd need to figure which IDSEL goes with which downstream device on the card.

It actually wouldn't be that hard, once you were familiar with the pinouts, but I read some of your comments about you and hardware in another thread, so to each his own. :)
 

cheesestraws

Well-known member
Hardware certainly doesn't come naturally to me the way it does to some lucky souls :). But in this case we want to get more information out of Open Firmware anyway—for these simple cards, just the vendor and device ID, sure, but for more complicated cards I suspect we're going to need more stuff from OF. We are, after all, trying to mimic the process that OF itself would use to set up the cards if it were working properly, so using the data OF on another machine gives us as ground truth is probably reasonable, I think. Plus it puts all the information one needs in the same place, so the information-gathering is only one process not several. But, as you say, each to their own—there are several ways to get this information, and I'm sure that there are people out there who could do the software side of this better than me too :). But they're not doing it, so you all are stuck with me ;-)
 

DBJ314

Member
You could of course directly alter the process OF uses to probe PCI cards.

The PCI probe process usually happens after the NVRAM script is loaded. It's just that line at the front of your script that does the loading right then and there. All the code and data in Open Firmware is in ram and can be modified by the script.
Code:
probe-all install-console banner

If we knew where the bug(s) actually occured, a script could patch them out before they were run.
 

cheesestraws

Well-known member
We discussed this upthread. It would be a fine way to do it, but I do not have the knowledge to do that. If you have the time and the knowledge, please feel free to do so: I cannot, so I am sticking with a simple approach that is known to more or less work.
 

cheesestraws

Well-known member
Oh, yup, I don't feel got at or anything, I just want to manage expectations that I am not a PCI guru, so you almost certainly won't end up with the "right" answer, though with luck we will end up with one that works...

@Knez I haven't forgotten you, I just haven't had time to knock up another patch yet (got a friend visiting)
 

trag

Well-known member
Oh, yup, I don't feel got at or anything, I just want to manage expectations that I am not a PCI guru, so you almost certainly won't end up with the "right" answer, though with luck we will end up with one that works...

Also, all the progress you make is information that can be built upon if someone decides to take the topic up again later.

Figuring out what it takes to make something work it almost always useful as an example.
 

LightBulbFun

Well-known member
one thing ill punt out there to keep in mind

is that if you install OS 9 on a mac without a USB card installed, then by default it wont install USB drivers, so installing a PCI USB card after install time wont work OOB on any old world Mac

I found this out the hard way back in the day when I had G3 beige but no ADB keyboard/mice!

so you either have to install the drivers manually, or at install time (ie while installing from the CD) make sure to manually check them as an option or have the USB card installed so it knows to install them


just something to keep in mind for those trying to test out the PCI patch etc

make sure you do have the USB drivers installed!
 

cheesestraws

Well-known member
FWIW, someone selling a bunch of the 2.0 cards on eBay US...

That's the person I got my testing one from. They even opened one up for me to check that the board in the box was the same one as pictured on the outside. Those are indeed the right ones.
 

cheesestraws

Well-known member
Hi, @Knez, can you try this one for me? Same as the last, install this patch then drop to open firmware, run 'qqq' and show me the results?
 

Attachments

  • kalea-crunched-test.txt
    1.9 KB · Views: 6

ried

Well-known member
OK, if anyone wants to have a go at either of these: I've tested these on my TAM here, but I can't test it on any other Gazelleish machines.

These are self-applying applications: the second should apply the patch to make the second-revision Tango 2.0 work; the first should enable Firewire and USB on the ST-200 available from Kalea (and a couple of other places).

If it tells you you have an invalid nvram checksum, do not apply the patch! And please let me know what you're installing it on.

I purchased one of the Tango 2.0 USB/FireWire cards from eBay last month and installed it in my TAM, which also has a Sonnet Crescendo G3 500 installed, running Mac OS 9.2.2. All of the relevant USB and FireWire drivers are installed.

I downloaded the patch, ran it (no invalid checksum error) and typed "y" + return twice. Rebooted and found that my TAM crashed during reboot with an interesting little bomb cursor. It was trying to load the first extension (Ethernet card) when the bomb appeared and the boot sequence stopped. Power button did not power it down, so I pulled the plug, zapped the PRAM and all is working again. Still no joy on the Tango 2.0's PCI-Bridge in System Profiler, of course.

Will keep an eye on this thread with great interest. Thanks for all your hard work on this!

7pCpaTt.jpg

Wr7oQUs.jpg
 

ried

Well-known member
I've never seen one before, either. It happened again, though. Even after zapping the PRAM, successfully booting and then shutting down the computer as normal. A bomb during the subsequent reboot. Strange!

I do have some good news to report, however. I once again zapped the PRAM, rebooted and then plugged a FAT32-formatted USB thumb drive into the Tango 2.0's USB port. To my surprise, it mounted on the desktop!

I expected it to be attached to the PCI-Bridge, but it's not. That's progress.

f7G1Ls1.jpg
 

cheesestraws

Well-known member
I expected it to be attached to the PCI-Bridge, but it's not.

That's expected: With the "old" Tango 2.0 and Sonnet's official patch, it still happens. I don't know what metadata System Profiler is looking for but it isn't there. As far as I can see that's just cosmetic though...

So, am I right to sum up where you are as "card seems to be behaving but it took a couple of PRAM resets to get there"?
 

ried

Well-known member
Yep. Can confirm both USB and FireWire are working. Hard drives mounted on the desktop from both.

FireWire is not showing up in Apple System Profiler yet, though.

q5cbthQ.jpg

ESRwfSI.jpg
 
Top