Jump to content

The PCI Bridge Gazelle board problem - Patching the patcher?


Recommended Posts

  • 68kMLA Supporter

Recently, I traded a SATA, FireWire and USB 2.0 combo PCI Card with @Knez, with the SATA ROM flashed to the SeriTek 1S2 firmware, so he could use it with his Power Macintosh 5500, which is a single PCI slot machine, where such a card would be very useful. However, it turns out the Gazelle board PCI bridge patch did not alleviate the enumeration bug in combination with this card. The Gazelle board, used in the Power Macintosh 5500 and 6500, as well as the Twentieth Anniversary Macintosh, has an unfortunate Open Firmware bug that causes PCI-PCI Bridge based cards to not enumerate beyond the PCI bridge chip itself, rendering the card useless.

 

I've decided to dig a little deeper. The following thread by @EvilCapitalist provided some insights, as he meticulously went through several cards to test them for functionality:

 

 

Now, I did discover that the patch itself seemingly looks for the Device ID and Vendor ID, and maybe some more IDs that I cannot reference. In screenshots on the Macintosh Garden, it was shown that the Sonnet card that did work had a Vendor ID shown in System Profiler of 1668. Now, looking up that Vendor ID on Device Hunt brings up Actiontec Electronics Inc., with a singular Device ID of 0100, for a "Mini PCI Bridge". 

 

On the card I sent Knez, which I have one myself of, the Vendor ID is 3388, with Device ID 0021. This does lead to an HB6 HiNT PCI Bridge. The chip on our cards is the PLX PCI6410, which its datasheet also refers to as HB1. Now, according to Wikipedia, in 2003, PLX bought out HiNT, so this chip is essentially just the HB1 from HiNT, rebranded. Its datasheet confirms that its VID is 3388, and DID 0021. It also mentions these values are Read Only, these can't be written to.

 

This is important, as digging into the patch code (raw dump here), the values "1668" and "100" can be found closeby. Now, the full OF value strings contain eight characters, for the of the PLX bridge the VID is 00003388 and the DID 00000021. So, I am presuming the zeros ahead of the values in the code are left out, meaning it is likely pointing to the VID 1668, and DID 0100. There is also the 60400 value, which correlates to the HB1's Class Code Register of 060400, as per the datasheet.

 

devicehunt.com's result for VID 1668 only delivers one result, a "Mini PCI Bridge" by Actiontec Electronics Inc., with DID 0100. It correlates, but it doesn't make sense, since this appears to be a different chip entirely.

 

Me and Knez did try various hex edited patches, initially just editing 1668 to 3388, and then editing 100 to 021, and later  21 (space ahead of the 21, as removing a character breaks the patcher). These however did not change the problem.

 

However, I am at doubt why the supported Sonnet card has different, and seemingly wrong VID and DID. I am also wondering if other IDs might have been changed, which the patcher might also have in its code, which I think (but due to lack of programming knowledge, can't confirm) it looks for so it applies the patch to the appropriate PCI device. Clearly the changed IDs don't change Gazelle compatibility, at least not entirely, as the patch is required. I also wonder how the IDs are changed, because as mentioned, the relevant registers in the HB1 are Read Only.

 

Currently, I am looking for several things that might allow me to edit the patch to allow for more HB1, and potentially even more PCI bridge chip based cards, to work on Gazelle boards.

 

  • .properties OF shots of known-to-work-in-Gazelle-boards HB1 cards
  • People with knowledge of these ICs
  • People with Open Firmware and/or Forth knowledge

 

The .properties shots would help tremendously with showing all the values and comparing them to non-working cards. To do this, you must go into OF, dev into the device (dev /pci/@d/pci-bridge@2 for example, this might be different on your system, look in "dev / ls" what the pci-bridge exactly is listed at, and devalias to find the PCI locations), and type .properties if OF returns ok after the dev command. One problem is that the TAM, 6500 and 5500, much like earlier OWR Macs, will always go into OF in Serial mode. The easier thing would be to do this on a NWR PowerPC Mac with PCI slots, if you have them. Knez and I had trouble with the serial mode producing garbage, but maybe you have better luck. The relevant settings for the serial terminal are found here.

 

People with knowledge of these ICs speaks for itself of course, as perhaps someone with more knowledge knows about the ID discrepancies. 

 

And people with Open Firmware and/or Forth knowledge might be able to tell exactly what the code is doing with those values. Again, I theorize it looks for them to find the device to apply the rest of the patch code to, but it is just a slightly-educated guess.

 

Any help with this mystery is very much appreciated! Be sure to ask for any info I might have that can help you help us :)

Link to post
Share on other sites
  • 68kMLA Supporter
56 minutes ago, Daniël said:

This is important, as digging into the patch code (raw dump here), the values "1668" and "100" can be found closeby. Now, the full OF value strings contain eight characters, for the of the PLX bridge the VID is 00003388 and the DID 00000021. So, I am presuming the zeros ahead of the values in the code are left out, meaning it is likely pointing to the VID 1668, and DID 0100. There is also the 60400 value, which correlates to the HB1's Class Code Register of 060400, as per the datasheet.

 

Initial dump:

 

(This post will be terse, I'm tired.  Also may well be wrong, I haven't written Forth in years and my open firmware knowledge is minimal.)

 

Before we start, here's a map of the PCI configuration space.  It will be useful:

 

https://en.wikipedia.org/wiki/PCI_configuration_space#/media/File:Pci-config-space.svg

 

Now, here's the check-node routine from the patch, rudimentarily pretty-printed:

 

: check-node 
	my-space " config-l@" $call-parent 
 	dup
 	d# 16 >> 
	swap h# 0000FFFF and 
	my-space d# 8 + " config-l@" $call-parent d# 8 >> 
	h# 60400 = swap h# 1668 = and swap h# 100 = and ; 

 

Lines 1 and 5 of this routine do similar things.  Let's look at line 1 to start with.  my-space pushes the address of the configuration space for the card onto the stack, and the " config-l@" $call-parent reads one 32-bit value from the configuration space pointed to by the top item on the stack.  The first 32-bit word of the PCI configuration space contains both the device ID and the vendor ID (see the map linked to earlier).  We then duplicate this word (dup) and we shift the top copy right by 16 bits (the d# means "interpret next number as decimal), giving the device ID. 

 

Then the top two are swapped and we mask the other copy (now on the top) with 0xFFFF (h# means "interpret next number as hex"), which is essentially "give us the lower 16 bits".  This is the vendor ID.  So, after line 4, our stack looks like this:

 

[device id] [vendor id] <-- TOP OF STACK

 

Now we hit line 5, and we do something similar, but we add 8 to the initial my-space value.  This, according to the PCI config map, is the device class code and a revision ID.  We then shift right to get rid of the revision ID.  So, after line 5, the stack looks like:

 

[device-id] [vendor-id] [class-code] <-- TOP OF STACK

 

The last line compares these, in order, as you intuited, @Daniël.  60400 is the class code for "PCI-to-PCI bridge", and then we check the VID to be 0x1668 and the DID to be 0x0100.

 

This means that if you were to change those two literals, check-node should indeed "return" truthiness for this new bridge chip, but there's likely more rummaging needed later in the code.

 

This is as far as I can go tonight and was less useful than I had hoped.  Oh well.

 

Here's a useful link.  This is the PCI bus binding for open firmware: https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf

Link to post
Share on other sites
  • 68kMLA Supporter

You're both in deeper on this than I've gotten yet, though I'll mention the OrangeLink patch as a second example of this theory at work. Perhaps having two discreet examples will be helpful?

 

https://www.macintoshrepository.org/6859-orange-micro-orangelink-pci-firewire-usb-combo-card-software

 

Edit: corresponding card looks like this

668654490_ScreenShot2021-05-04at4_12_06PM.thumb.png.884161305933e3077dbb1fc25443ad41.png

Edited by jeremywork
Link to post
Share on other sites
  • 68kMLA Supporter
15 minutes ago, jeremywork said:

Perhaps having two discreet examples will be helpful?

 

A quick look here suggests that not only are the VID/DID identical in this case, in fact the whole OF script is very nearly identical.  So it might not get us very much further.

 

I'm really going to bed now, I promise...

Link to post
Share on other sites
  • 68kMLA Supporter
25 minutes ago, cheesestraws said:

 

A quick look here suggests that not only are the VID/DID identical in this case, in fact the whole OF script is very nearly identical.  So it might not get us very much further.

 

I'm really going to bed now, I promise...

 

Interesting... so whatever's in that script has been known to work in all three of these designs, each Hint HB1 (or later PLX) it seems.

 

I'm away from my 5500 and TAM until next week, but they have an OrangeLink 1.0 and Tango 2.0 respectively. I'll try to get their OF .properties dumped.

 

 

892856411_ScreenShot2021-05-04at4_30_28PM.thumb.png.db68f19cf461f10877722c3028393072.png

 

Edited by jeremywork
Link to post
Share on other sites
  • 68kMLA Supporter
8 hours ago, cheesestraws said:

This is as far as I can go tonight and was less useful than I had hoped.  Oh well.

 

It was still very useful! Knowing that that piece of the code indeed compares the VID, DID and CCR numbers with those of the PCI cards is a good starting point.

 

I'm still mulling over how the specific cards "fake" their IDs, the datecodes shown for the HB1 chips on working cards are in the same ranges as those on non-working cards, so it's not some change early in production that might have changed those.

Link to post
Share on other sites
  • 68kMLA Supporter

Yes.  I am very curious.

 

I only have a working card to play with, "unfortunately", so I can't compare stuff.  I'll see whether I can get a working serial terminal on OF today if I have time/energy and dump properties from the working card, though...  Anyone want to lend me a dud one? :-p

Link to post
Share on other sites
  • 68kMLA Supporter

I have ordered a bunch of boards from eBay, including two Gazelle boards. So I should relatively soon be able to also start tinkering with it locally, which is helpful.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...