Jump to content

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
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

  • 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
Posted (edited)

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
Posted (edited)
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
  • 68kMLA Supporter

Hopefully we can get this working and be able to support more cards going forward.

 

I’ll continue working on this (in whatever way that might be) tonight. Thanks for all your work so far @Daniël :-)

Link to post
Share on other sites
  • 68kMLA Supporter

This afternoon I've started looking at one of the other word definitions in the patch, "make-nodes".  This is the core of the patch, and although I don't know all of what is going on in it yet, the broad strokes are fairly obvious.

 

The tl;dr is that of course, the patch does not enable enumeration behind PCI bridges on OF.  Instead, they've gone with the sensible low-effort approach of faking it instead of making it; the patch essentially constructs the devices that would have been discovered in enumeration.

 

Here it is split into rough functional blocks:

 

: make-nodes 
	" assigned-addresses" delete-property
	my-space dup 18 + 10100 swap config-l! 
	4 + dup config-l@ h# FFFFFFF4 and 2 or swap config-l! 
	
	new-device 
	0 0 " 0,0" set-args 
	my-make-properties 
	0 100000 20 claim-real swap drop dup dup 100000 " map-range" $call-parent
	dup my-space h# 10 + config-l! 
	dup 0 my-space h# 82 d# 24 << or h# 10 + encode-3ints 1000 0 encode-2ints encode+ " assigned-addresses" property 
	finish-device 
	
	new-device 
	0 0 " 1,0" set-args 
	my-make-properties 
	dup 1000 + my-space h# 10 + config-l! 
	dup 1000 + 0 my-space h# 82 d# 24 << or h# 10 + encode-3ints 1000 0 encode-2ints encode+ " assigned-addresses" property 
	finish-device 
	
	dup dup h# 10 >> or my-space h# 20 + config-l! 
	my-space h# 3c + dup config-l@ h# 800000 or swap config-l! 
	" ranges" delete-property dup 0 h# 82000000 encode-3ints rot 0 h# 82000000 encode-3ints h# 100000 0 encode-2ints encode+ encode+ " ranges" property my-space h# 18 + config-l@ dup 8 >> h# ff and swap d# 16 >> h# ff and encode-2ints " bus-range" property ; 

 

The first block here essentially enables access to the bridge and tells it what its PCI bus IDs are.  Not interesting, except that it demonstrates that naming is hard, because it was a bit surprising to find this in make-nodes :-).

 

The second and third blocks are bracketed by new-device and finish-device calls which create new devices in the device tree "under" the current one.  I haven't entirely worked out what the property setting is doing in detail yet, but it looks like it's faking the address allocations.

 

So, good news and bad news:

  1. The bad news: just changing the IDs in this will probably only fix things if everything else on the card is the same.
  2. The good news: We may be able to adopt the same approach for other such bridged cards by just "transplanting" the device tree nodes for it, like they have done here (if I'm understanding this right).

I have posted in the Trading Post looking for a non-TAM compatible card and if I can get hold of one I will have a go.  Otherwise, is there any chance one of you two, @Daniël or @Knez, can send me the subtree of the device tree corresponding to the card that you have with properties? (Or—what is this card?)

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

I have posted in the Trading Post looking for a non-TAM compatible card and if I can get hold of one I will have a go.  Otherwise, is there any chance one of you two, @Daniël or @Knez, can send me the subtree of the device tree corresponding to the card that you have with properties? (Or—what is this card?)

 

Once again, thanks for the analysis :)

 

I've provided the device tree readout, as well as the properties for the pci-bridge device, from the 6400's Open Firmware here: https://imgur.com/a/RnxrAnl

 

The card we both have is one of these, with the SATA BIOS ROM IC exchanged for a larger ROM IC, containing the SeriTek 1S2 firmware that allows the SiI3112 chipset to function as a SCSI device under Classic Mac OS: https://www.amazon.co.uk/KALEA-INFORMATIQUE-contrôleur-Professionnelle-COMPOSANTS-Préinstallés/dp/B01NA6UKA8/

Link to post
Share on other sites
  • 68kMLA Supporter

Thanks for the link and the detail :-) if you see another of these for sale anywhere will you let me know?  I'm slightly at the point where I can't do much more without actual hardware.  And while I don't want to "take over" your project, it would be fun to have a go at getting one of these working :-)

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

Thanks for the link and the detail :-) if you see another of these for sale anywhere will you let me know?  I'm slightly at the point where I can't do much more without actual hardware.  And while I don't want to "take over" your project, it would be fun to have a go at getting one of these working :-)

 

Apparently Kalea just moved over from Amazon to France, the price is mostly the same as it was on eBay: https://www.ebay.com/itm/291966252541

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

Apparently Kalea just moved over from Amazon to France, the price is mostly the same as it was on eBay: https://www.ebay.com/itm/291966252541

 

Aaaaand ordered.

 

I might bug you for details on how to do the Seritek goodness at some point, but for now I'm just going to poke the bridge chip...

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

 

Aaaaand ordered.

 

I might bug you for details on how to do the Seritek goodness at some point, but for now I'm just going to poke the bridge chip...

 

No worries, I'll write it up right now so I don't forget :)

 

The SeriTek ROM is too large to fit on the IC that these cards are fitted with due to the complexity of the Classic Mac OS support, and it also has some sort of ROM IC check. It will only work with MX29LV040, AM29LV040(B), or the PM39LV040. If a different 040-size ROM is used, it will not properly initialize the firmware.

 

Now, the LV in the part numbers indicate these chips run at 3.3V, rather than 5V. On the generic SiI3112 cards out of China, it's prudent to check whether the original ROM runs at 3.3V, or 5V. There's often a resistor populated, with unpopulated pads for another one, near the voltage regulator. One position is for 5V, the other for 3.3V. In the case of these Kalea cards, both the one I prepared for @Knez as well as mine, had an Atmel AT49BV512 installed, which is a 3.3V part too, so no resistor swapping is necessary.

 

It's simply a matter of desoldering the old ROM, then soldering the new one in place. I don't know if the usual flashing methods apply for these as for other SiI3112 cards, as I personally just flash the IC with my TL866II programmer prior to soldering it on.

This thread details flashing the ROM in a PC with Flashrom on a bootable DOS disk, it has a ZIP with the SeriTek ROM as well:

 

 

 

Once flashed and installed, the SATA will be treated as SCSI under Classic Mac OS, and as ATA under OS X. It works with any version of the Classic Mac OS capable of running on a PCI-based system, without any drivers, while bypassing any IDE controller limits and such. Even on regular SiI3112 cards, it's a pretty cool and handy thing to have, and I prefer it over IDE-to-SATA where possible.

Link to post
Share on other sites
  • 68kMLA Supporter

I managed to dump the .properties from my 5500 with its OrangeLink USB/FW PCI card. 

 

I ran the dump twice, first with the PRAM freshly reset (no USB/FW devices mount) and again after applying the patch and verifying simultaneous mount of USB and FW volumes.

 

PM5500 OrangeLinkPCI

Hopefully this helps...

 

For some reason my TAM outright refuses to enter Open Firmware (CMD+OPT+O+F is ignored entirely, proceeding to happy mac.) Any info on this? I can provide the same for the Tango 2.0 with that working...

Link to post
Share on other sites
  • 68kMLA Supporter
14 hours ago, jeremywork said:

I ran the dump twice, first with the PRAM freshly reset (no USB/FW devices mount) and again after applying the patch and verifying simultaneous mount of USB and FW volumes.

 

Thankyou!

 

When you get a chance, would you mind dumping the .properties of the devices behind the PCI bridge once the patch is applied and working?

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

 

Thankyou!

 

When you get a chance, would you mind dumping the .properties of the devices behind the PCI bridge once the patch is applied and working?

Certainly! 

 

5500 PCI Sub

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

@Daniël When you get a moment, could you dump the .properties of both the PCI bridge and the devices behind it on that card you have on a working machine?

 

Here is an Imgur album of all but the SeriTek's .properties listings: https://imgur.com/a/FYI4FIa

 

The SeriTek dumps two large chunks of info on the ROM (one part about the Classic support, the other about OS X support), causing the requested info to be scrolled out of view, so I'd have to get a serial setup to be able to dump the whole thing as a text file.

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

I'd have to get a serial setup to be able to dump the whole thing as a text file.

FWIW, I had success using Microphone II (3.0 was already on my system) with a standard Apple Serial Printer cable from Modem port of the target and these settings:

 

740558615_Picture1.png.3a2b69059c09e3713dca01c8245474db.png

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

And you saved me some googling just as I was about to do it.  Many thanks! :D

Glad to assist! The link Daniël included in the first post helped me a lot:

 

On 5/4/2021 at 2:28 PM, Daniël said:

The relevant settings for the serial terminal are found here.

 

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...