• 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
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.
Actually, there was a second bug in my code. Fixing that allows results like the following for OF 1.0.5:
Code:
FF831B60: /bandit@F2000000
FF83EE98:   /pci106b,1@B
FF83F048:   /pci-bridge@E
FF83FCB0:     /pci-bridge@0
FF8408F0:       /pci-bridge@0
FF841530:         /pci-bridge@0
FF842170:           /pci-bridge@0
FF842DB0:             /pci-bridge@0
FF8439F0:               /pci-bridge@0
FF844630:                 /pci-bridge@0
FF845298:                 /pci16b8,12@1
FF845598:               /pci16b8,12@1
FF845898:             /pci16b8,12@1
FF845B98:           /pci16b8,12@1
FF845E98:         /pci16b8,12@1
FF846198:       /pci16b8,12@1
FF846498:     /pci16b8,12@1
Seems like there's no limit to the nesting level of pci bridges in OF 1.0.5.

Just checking you've seen the 6500 is OF 2.0.3? Not sure how much difference it makes.
Yes, but I don't have a 6500 and I'm waiting for anyone to dump the info I asked for which might help get OF 2.0.3 running in the emulator. In the mean time, now that we know OF 1.0.5 doesn't have a limit, we might be able to find the problem by comparing the forth code.
 

dosdude1

Well-known member
I've added what I believe should be able to access and execute the option ROM of the SATA portion of the card, though I don't think it will work at this time, as I don't think the script produces some of the necessary "reg" properties that are needed to load the option ROM (also it is probably now too large to fit in NVRAMRC). This will probably be my last update for now, as there's not much more I can do until I get my 6500 for actual testing in a couple weeks.

Though of course, the optimal solution for all of this would be to just find and fix the actual issue with Open Firmware on these machines in the first place, as @joevt is working on.
 

Attachments

  • all-enabled-test.txt
    1.9 KB · Views: 6

joevt

Well-known member
Attached is a listing of Open Firmware 2.0.3 from the 6500. It includes a comparison of the fcode part with OF 2.4 (from beige G3 v3) where the names from OF 2.4 have been applied to OF 2.0.3 and some words in OF 2.4 were moved to more closely match the location of the same words in OF 2.0.3 for better comparing. The naming and rearranging is a manual process so hopefully there aren't any mistakes.

I chose OF 2.4 instead of OF 1.0.5 since OF 2.4 includes all the names. Bandit in OF 2.0.3 should be compared with Bandit in OF 1.0.5 since it doesn't exist in OF 2.4.

Anyway, perhaps there's a difference that might be a cause of the problem.

How I think it should work:
- `probe-all`
- `probe-pci`
- `probe-slots` (in bandit). It adds `pci106b,1`. Then it should probe `@12`, `@0d`, `@0e`, `@0f``, `@11` if we're dealing with `gazelle`. `zanzibar` has a special handling of a pci-brdige that is pci1011,21 but OF 2.0.3 doesn't have an fcode image for device [1011:0021] with class code [060400]. It does have the generic pci-bridge fcode image for the class code though.
- `?probe-slot` for each slot. Creates `slot-name` which is a letter `(bridge#-1) * 3 + (device#-0x0d) + 'A'` followed by a number `bridge#`.
- `probe-slot` (in main)
- `probe-device` If a device has a vendor/device id that is not -1, then a `new-device` is called. `standard-props` creates the standard properties (`vendor-id`, `device-id`, `revision-id`, `class-code`, `interrupts`, `min-grant`, `max-latency`, `subsystem-vendor-id`, `subsystem-id`, `devsel-speed`, `fast-back-to-back`, `aapl,slot-name` (from the generated `slot-name`). class-code `[060400]` loads the pci-bridge fcode image. There's also an image for `[106b:0003]`, `[106b:0004]`. If the device is none of those, then it will use `probe-fcode` to get fcode from the ROM (checks the ROM bar, checks the PCI header, checks for an Open Firmware fcode image, etc). If there's no fcode, it will use `byte-load-file?` to check if Open Firmware has a rom image matching the class-code. If there's no fcode from that, then the device is given a standard `pciV,D` name based on vendor/device id and the `reg` property is build from base address registers. For a multi-function device, `probe-device` loops from function number `,0` to function number `,7`.

In the case of a pci-bridge, the pci-bridge fcode image should now be executed by `probe-device`.

`pci-pci-config` (from pci bridge) Sets up the pci-bridge. Then calls `probe-device` for device numbers 0 to 15 (@0 - @F). Addresses ranges are setup based on the devices that are found. I don't know why it doesn't try detecting device numbers @10 - @1F.

The developers of dingusppc say that they might be able to get it executing beyond HWInit (occurs before entering Open Firmware) with the 6500 ROM in the next few days. Then we might be able to trace the Open Firmware code to see why it doesn't do `probe-device` for the pci bridge. Unless someone with a Power Mac 6500, a printer serial cable, and another Mac wants to give it a try.
 

Attachments

  • OF PM 6500 and TAM.zip
    439.2 KB · Views: 3

Phipli

Well-known member
Unless someone with a Power Mac 6500, a printer serial cable, and another Mac wants to give it a try.
I'm wired in from my linux laptop now - doing it from another old mac is a pain because to move files / scripts about, I have to run an ethernet cable straight through the middle of the dining room and very much in the way.

I am unlikely to be much help because I don't know forth, OF, PPC assembly or just about anything that might be useful.
 

Attachments

  • IMG_20221220_151957.jpg
    IMG_20221220_151957.jpg
    3.6 MB · Views: 45

Phipli

Well-known member
Anyone with a Gazelle based Mac have a serial cable and another computer to dump some info? I want to see how difficult it would be to add a working emulation (at least enough to get into Open Firmware) to dingusppc so that patches to the Open Firmware environment can be tested without using a real machine.

Read the Open Firmware stuff at #1 Skip to "Open Firmware Tools". Follow the links for "lspci for Open Firmware" to get that from my dropbox.

Read the "Connecting to Open Firmware" section. Get into Open Firmware, set input/output to serial port. Connect another computer to the Power Mac. Run this command from that computer:
7fffffff to lines/page " printenv" evaluate dev / ls unselect-dev dump-device-tree words 16 to lines/page

Paste the lspci text (first use unselect-dev to make sure no devices are selected; the latest version of lspci for Open Firmware can work from the main list of words) . Then select the pci root device (it may have a pci or pci1 dev alias so use that like this dev pci). Type lspci. Do the same for any other pci roots (a Power Mac 9500 has pci2; for a Power Mac 8600, use lsvci for vci0 since lspci doesn't work well with that pci bus).

Then copy all the results from your serial terminal app into a text file, zip it, and post here as an attachment. Maybe the info in the device tree and from pci config can be used to get the gazelle machine in dingusppc to boot into Open Firmware. Then virtual pci bridges could be added to see how Open Firmware handles them.
Can you clarify where I would find the "lspci text" mentioned?

I've attached the output from the first command you mentioned.
 

Attachments

  • 6500OF_20221220.zip
    8.8 KB · Views: 6

joevt

Well-known member
I'm wired in from my linux laptop now - doing it from another old mac is a pain because to move files / scripts about, I have to run an ethernet cable straight through the middle of the dining room and very much in the way.
I use a modern Mac with a USB to serial adapter. Serial.app has built-in drivers for the Keyspan USA-28 and USA-28X and probably other Keyspan adapters (the tripp-lite website has support documentation for the adapters).

I am unlikely to be much help because I don't know forth, OF, PPC assembly or just about anything that might be useful.
Not a problem if you can follow instructions.

I've attached the output from the first command you mentioned.
Thanks for this. I forgot to add devalias to the list of commands, but I think the aliases node has all the aliases?
Code:
pci1                    /bandit@F2000000
fd                      /bandit/ohare/swim3
kbd                     /bandit/ohare/via-cuda/adb/keyboard
mouse                   /bandit/ohare/via-cuda/adb/mouse
screen                  /bandit/ATY,264GT
ttya                    /bandit/ohare/escc/ch-a
ttyb                    /bandit/ohare/escc/ch-b
scsi                    /bandit/ohare/mesh
scsi-int                /bandit/ohare/mesh
ata                     /bandit/ohare/ata
ata-int                 /bandit/ohare/ata

Can you clarify where I would find the "lspci text" mentioned?
Post #1 has links for "lspci for Open Firmware". The first links are how it was developed - you don't need to get anything from those except a sense of why it exists or how to use it. The last one contains a link to the dropbox download #565 . Let me know if the link works. If not, I've attached a copy.

To use it, do the following:
  • unselect-dev \ to make sure the lspci command is added to the main Open Firmware word list instead of the word list of a device.
  • Paste the contents of "lspci for paste OpenFirmware.txt" into open firmware. Depending on your terminal app, you may need to add some delay to the text pacing. You might need to find a proper terminal app that has text pacing options. For example, in Serial.app on macOS, I use 0.008 seconds for line delay and 0.004 seconds for character delay but it may depend on the baud rate. Alternatively, you can paste one line at a time. Once it has been pasted successfully (no errors returned), then you can use the commands.
  • dev pci1 \ to select the pci root that you want to lspci from. It appears the 6500 only has one pci root which is pci1
  • lspci \ to scan for pci devices, capture all their pci config registers, and test their BAR sizes.

Repeat the commands with a problematic PCI card installed so we can see if its devices can be detected by lspci without the Sonnet nvramrc patch. The output from lspci and from dump-device-tree will show how far probe-all gets in setting up the pci bridge of the problematic PCI card.
 

Attachments

  • lspci for OpenFirmware.zip
    6.3 KB · Views: 3

joevt

Well-known member
Repeat the commands with a problematic PCI card installed so we can see if its devices can be detected by lspci without the Sonnet nvramrc patch. The output from lspci and from dump-device-tree will show how far probe-all gets in setting up the pci bridge of the problematic PCI card.
Oh wait nvmd. Your dump has the problematic PCI card already. Just need the lspci.

The pci-bridge doesn't have a bus-range property which means pci-pci-config might not have completed but it did add the pci-bridge device name which means pci-pci-config must have started. Also, bandit has a bus-range that ends at bus 01 which I think is provided by the pci-bridge. The lspci command will show bus numbers of devices it can detect. Detecting devices behind the pci-bridge requires that it's secondary and subordinate bus numbers be set correctly, which happens at the end of pci-pci-config after bus-ranges is set so it might not have happened. Except we see that a ranges property was added to the pci-bridge and we see in the code for pci-pci-config that after an empty ranges property is added, it immediately sets the secondary bus to the next available bus number (probably 1) and the subordinate bus number is set to FF. The bus range 01-FF is a wide open range for enumerating an unknown number of pci devices behind the bridge. Once all the devices are found, the subordinate bus number is reduced to the max bus number that was required for all the nested devices (probably 01 in this case since there's only one level of pci bridges). The output from lspci will show if the bus range is not set [00], wide open [01-FF], or finished [01].
 
Last edited:

ried

Well-known member
Dumb question: Is any of this jiggery pokery going to enable the Sonnet Tempo Trio's FW + USB + ATA-133 on the TAM? Or is it geared specifically toward the SATA combo card?
 

Phipli

Well-known member
Dumb question: Is any of this jiggery pokery going to enable the Sonnet Tempo Trio's FW + USB + ATA-133 on the TAM? Or is it geared specifically toward the SATA combo card?
The TAM is effectively identical to the 6500/5500, so yes. Depending on if the ROM is patched, or a script is made to manually add the card, some details from the card might be needed.

Also, that isn't a dumb question :)
 

joevt

Well-known member
The TAM is effectively identical to the 6500/5500, so yes. Depending on if the ROM is patched, or a script is made to manually add the card, some details from the card might be needed.
I have a Sonnet Tempo Trio in my 8600 so I have all the info I need from that. I've attached Open Firmware lspci for pci1 and the parsed output (using latest pciutils). Not included is lsvci for vci0 which we don't care about here.

These are the Sonnet Tempo Trio devices:
Code:
00:0e.0 PCI bridge [0604]: Actiontec Electronics Inc Mini-PCI bridge [1668:0100] (rev 11) (prog-if 00 [Normal decode])
01:00.0 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 41) (prog-if 10 [OHCI])
01:00.1 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 41) (prog-if 10 [OHCI])
01:00.2 USB controller [0c03]: NEC Corporation uPD72010x USB 2.0 Controller [1033:00e0] (rev 02) (prog-if 20 [EHCI])
01:01.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW322/323 [TrueFire] 1394a Controller [11c1:5811] (rev 04) (prog-if 10 [OHCI])
01:02.0 Mass storage controller [0180]: Promise Technology, Inc. 20269 [105a:4d69] (rev 02) (prog-if 85)

They appear like this in dev / ls:
Code:
FF864048:   /pci-bridge@E
FF864CB0:     /pci16b8,12@0
FF864F20:     /pci16b8,12@0,1
FF865190:     /pci16b8,21@0,2
FF865400:     /pci16b8,1@1
FF865698:     /Ultra-Tek133P@2
FF88F820:       /sd@0,0
It appears that Open Firmware prefers to use the subsystem IDs for the device names of devices that don't have a ROM.

The developer of dingusppc was able to boot Open Firmware 2.0.3 so I'll be able to test it with my emulated Sonnet Tempo Trio devices when the code is uploaded. The emulated devices don't do anything except get detected. Sonnet Firmtek fcode ROM for the Promise 20269 doesn't like that the emulated device doesn't have properly responding registers, but the fcode does complete and set the device name and add the sd SCSI disk device. The device name is slightly wrong Ultra-Tek133P+ because the device registers don't properly respond and the fcode takes a long time waiting for a proper response. Anyway, it should be good enough to debug the OF 2.0.3 problem.
 

Attachments

  • lspci from 8600 with Tempo Trio, PCIe bridge, NVMe.zip
    5.5 KB · Views: 1

dosdude1

Well-known member
I have a Sonnet Tempo Trio in my 8600 so I have all the info I need from that. I've attached Open Firmware lspci for pci1 and the parsed output (using latest pciutils). Not included is lsvci for vci0 which we don't care about here.

These are the Sonnet Tempo Trio devices:
Code:
00:0e.0 PCI bridge [0604]: Actiontec Electronics Inc Mini-PCI bridge [1668:0100] (rev 11) (prog-if 00 [Normal decode])
01:00.0 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 41) (prog-if 10 [OHCI])
01:00.1 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 41) (prog-if 10 [OHCI])
01:00.2 USB controller [0c03]: NEC Corporation uPD72010x USB 2.0 Controller [1033:00e0] (rev 02) (prog-if 20 [EHCI])
01:01.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW322/323 [TrueFire] 1394a Controller [11c1:5811] (rev 04) (prog-if 10 [OHCI])
01:02.0 Mass storage controller [0180]: Promise Technology, Inc. 20269 [105a:4d69] (rev 02) (prog-if 85)

They appear like this in dev / ls:
Code:
FF864048:   /pci-bridge@E
FF864CB0:     /pci16b8,12@0
FF864F20:     /pci16b8,12@0,1
FF865190:     /pci16b8,21@0,2
FF865400:     /pci16b8,1@1
FF865698:     /Ultra-Tek133P@2
FF88F820:       /sd@0,0
It appears that Open Firmware prefers to use the subsystem IDs for the device names of devices that don't have a ROM.

The developer of dingusppc was able to boot Open Firmware 2.0.3 so I'll be able to test it with my emulated Sonnet Tempo Trio devices when the code is uploaded. The emulated devices don't do anything except get detected. Sonnet Firmtek fcode ROM for the Promise 20269 doesn't like that the emulated device doesn't have properly responding registers, but the fcode does complete and set the device name and add the sd SCSI disk device. The device name is slightly wrong Ultra-Tek133P+ because the device registers don't properly respond and the fcode takes a long time waiting for a proper response. Anyway, it should be good enough to debug the OF 2.0.3 problem.
Finally got to grab my PowerMac 6500, I have now gotten the information you have requested, using your LSPCI script. Output is attached.
 

Attachments

  • PM6500-SATACOMBO-LSPCI.txt
    4.4 KB · Views: 9

joevt

Well-known member
Finally got to grab my PowerMac 6500, I have now gotten the information you have requested, using your LSPCI script. Output is attached.
Thanks for this. The result shows the bridge did not get probed:
00:0D.0-[00] - the secondary and subordinate bus numbers are 0.

The developer of dingusppc is working on improving PSX (memory controller) emulation before committing 6500 machine initialization code but I was able to get into Open Firmware 2.0.3 with the stuff that he already commited by making my own 6500 machine initialization code.

When I ran dingusppc with the new code, I didn't see any problems. All my pci-bridges and USB and FireWire devices were added and there was no limit on PCI bridge nesting, just like in OF 1.0.5, 2.0f1, and 2.4.

Code:
Open Firmware, 2.0.3
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /pci-bridge@E
FF83C1D0:     /pci16b8,12@0
FF83C440:     /pci16b8,12@0,1
FF83C6B0:     /pci16b8,21@0,2
FF83C920:     /pci16b8,1@1
FF83CBB8:     /pci105a,ad69@2

But I compared the emulated device tree with the real device trees that you guys posted and noticed the ATI GPU was missing so I added that to the dingusppc 6500 machine initialization code. Then my pci-bridge devices didn't get added:
Code:
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /ATY,264GT-B@12
FF840C88:   /pci-bridge@E

So there could be a problem with the ATY,264GT-B fcode. We could try tracking down that problem. Or maybe just changing the order that the devices are probed might help. Lots of things to try.

As a quickie we'll try the latter now:
probe-slots has the probe order info. It looks like this as Forth code (from the comparison I posted earlier):
Code:
        ?gazelle if
            12 18 -1 ?probe-slot
            0d 17 -1 ?probe-slot
            0e 19 -1 ?probe-slot
            0f 1c -1 ?probe-slot
            11 16 -1 ?probe-slot
        else
The see probe-slots command shows that as this:
Code:
    ^-7D84B8  if
      12 18 -1 ^-7CED20
       D 17 -1 ^-7CED20
       E 19 -1 ^-7CED20
       F 1C -1 ^-7CED20
      11 16 -1 ^-7CED20
      else
Where the numbers preceded by ^ are execution tokens - basically an address to a Forth word because OF 2.0.3 doesn't have names for those words. -7D84B8 is FF827B48 (just add 4GB) for ?gazelle and -7CED20 is FF8312E0 for ?probe-slot
Code:
0 > -7D84B8 u. FF827B48  ok
0 > -7CED20 u. FF8312E0  ok
We need to find where in probe-slots that code is at to patch it. You can try doing that with one of these:
' probe-slots 638 dump
' probe-slots dis
but they don't provide much context. xsee in OF 2.4 does a better job. But for the most info, I dump all the bytes of the dictionary, convert the text to binary, then use my DumpMacRom.sh script and OpenBIOSStuff tools:
Code:
FF831405: b(:) \ [0x0b7] 0xa3d probe-slots
FF831418: 967E FFFC                       stwu     r19,-4(r30)                            
FF83141C: 7E68 02A6                       mflr     r19                                    
FF831420: 4BFF F381     FF8307A0          bl       mac_rom_value_A1E_80000000             
FF831424: 4BFD A735     FF80BB58          bl       0=                                     
...
FF831690: 4BFF 64B9     FF827B48          bl       mac_rom_value_98E_FFFFFFFF             
FF831694: 4BFD 88CD     FF809F60          bl       mac_rom_code_465                       
FF831698: 4800 0080     FF831718          b        $+128                                  
FF83169C: 4BFD 7CB5     FF809350          bl       b<lit>                                 
FF8316A0: 0000 0012                       dc.l     0x12                                   
FF8316A4: 4BFD 7CAD     FF809350          bl       b<lit>                                 
FF8316A8: 0000 0018                       dc.l     0x18                                   
FF8316AC: 4BFD 9D25     FF80B3D0          bl       -1                                     
FF8316B0: 4BFF FC31     FF8312E0          bl       mac_rom_colon_A3B                      
FF8316B4: 4BFD 7C9D     FF809350          bl       b<lit>                                 
FF8316B8: 0000 000D                       dc.l     0xD                                    
FF8316BC: 4BFD 7C95     FF809350          bl       b<lit>                                 
FF8316C0: 0000 0017                       dc.l     0x17                                   
FF8316C4: 4BFD 9D0D     FF80B3D0          bl       -1                                     
FF8316C8: 4BFF FC19     FF8312E0          bl       mac_rom_colon_A3B                      
FF8316CC: 4BFD 7C85     FF809350          bl       b<lit>                                 
FF8316D0: 0000 000E                       dc.l     0xE                                    
FF8316D4: 4BFD 7C7D     FF809350          bl       b<lit>                                 
FF8316D8: 0000 0019                       dc.l     0x19                                   
FF8316DC: 4BFD 9CF5     FF80B3D0          bl       -1                                     
FF8316E0: 4BFF FC01     FF8312E0          bl       mac_rom_colon_A3B                      
FF8316E4: 4BFD 7C6D     FF809350          bl       b<lit>                                 
FF8316E8: 0000 000F                       dc.l     0xF                                    
FF8316EC: 4BFD 7C65     FF809350          bl       b<lit>                                 
FF8316F0: 0000 001C                       dc.l     0x1C                                   
FF8316F4: 4BFD 9CDD     FF80B3D0          bl       -1                                     
FF8316F8: 4BFF FBE9     FF8312E0          bl       mac_rom_colon_A3B                      
FF8316FC: 4BFD 7C55     FF809350          bl       b<lit>                                 
FF831700: 0000 0011                       dc.l     0x11                                   
FF831704: 4BFD 7C4D     FF809350          bl       b<lit>                                 
FF831708: 0000 0016                       dc.l     0x16                                   
FF83170C: 4BFD 9CC5     FF80B3D0          bl       -1                                     
FF831710: 4BFF FBD1     FF8312E0          bl       mac_rom_colon_A3B                      
FF831714: 4800 0220     FF831934          b        $+544
FF831405 is the header for the probe-slots compiled word. The header includes flags (such as if the word is named or an instance or is named but hidden) the name of the word (if the flags say it has a name), the fcode token number (0xa3d), some flags, and the type of the word (in this case, it's a colon definition function).
FF831418 is the execution token of probe-slots.
FF827B48 is the address of the code (execution token) for the ?gazelle value flag. A3B is the fcode token number of the unnamed ?probe-slot word at FF8312E0.

Our patch can't use fixed execution tokens because they are not guaranteed to be the same for every boot. Our patch will reference ?probe-slot by the fcode number using get-token. The thing about fcode numbers is that they get reused by subsequent fcode images that are loaded afterward. a3b get-token will work before probe-all loads other fcode images which is when we want our patch to be applied.

Our patch will start at FF83169C which is ' probe-slots 284 +. After the patch is executed, it will jump to FF831714 (probe-slots + 0x2FC) to skip everything in that if / else.

This is what we'll put in the nvramrc:
Code:
dev pci1
defer ?p
a3b get-token drop to ?p
: ps
0d 17 -1 ?p
0e 19 -1 ?p
0f 1c -1 ?p
11 16 -1 ?p
12 18 -1 ?p
;
' probe-slots dup
284 + ' ps blpatch
dup 288 + swap 2FC + brpatch
unselect-dev
The behaviour of the ?p defer word is set to the execution token of the a3b fcode token (?probe-slot). ps has the same code that we're replacing except device @12 (for the ATI gpu) is probed last instead of first.
blpatch makes probe-slots + 0x284 call ps (like a subroutine call). ps will return to probe-slots at the next instruction which is at offset 0x288. brpatch makes probe-slots + 0x288 goto + 0x2FC (it's a branch instruction).

Hopefully whatever happened with the GPU fcode won't happen with the Sonnet fcode or whatever you have getting probed before the GPU. There might have been a reason for Apple to probe the ATI GPU first.
 

dosdude1

Well-known member
Thanks for this. The result shows the bridge did not get probed:
00:0D.0-[00] - the secondary and subordinate bus numbers are 0.

The developer of dingusppc is working on improving PSX (memory controller) emulation before committing 6500 machine initialization code but I was able to get into Open Firmware 2.0.3 with the stuff that he already commited by making my own 6500 machine initialization code.

When I ran dingusppc with the new code, I didn't see any problems. All my pci-bridges and USB and FireWire devices were added and there was no limit on PCI bridge nesting, just like in OF 1.0.5, 2.0f1, and 2.4.

Code:
Open Firmware, 2.0.3
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /pci-bridge@E
FF83C1D0:     /pci16b8,12@0
FF83C440:     /pci16b8,12@0,1
FF83C6B0:     /pci16b8,21@0,2
FF83C920:     /pci16b8,1@1
FF83CBB8:     /pci105a,ad69@2

But I compared the emulated device tree with the real device trees that you guys posted and noticed the ATI GPU was missing so I added that to the dingusppc 6500 machine initialization code. Then my pci-bridge devices didn't get added:
Code:
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /ATY,264GT-B@12
FF840C88:   /pci-bridge@E

So there could be a problem with the ATY,264GT-B fcode. We could try tracking down that problem. Or maybe just changing the order that the devices are probed might help. Lots of things to try.

As a quickie we'll try the latter now:
probe-slots has the probe order info. It looks like this as Forth code (from the comparison I posted earlier):
Code:
        ?gazelle if
            12 18 -1 ?probe-slot
            0d 17 -1 ?probe-slot
            0e 19 -1 ?probe-slot
            0f 1c -1 ?probe-slot
            11 16 -1 ?probe-slot
        else
The see probe-slots command shows that as this:
Code:
    ^-7D84B8  if
      12 18 -1 ^-7CED20
       D 17 -1 ^-7CED20
       E 19 -1 ^-7CED20
       F 1C -1 ^-7CED20
      11 16 -1 ^-7CED20
      else
Where the numbers preceded by ^ are execution tokens - basically an address to a Forth word because OF 2.0.3 doesn't have names for those words. -7D84B8 is FF827B48 (just add 4GB) for ?gazelle and -7CED20 is FF8312E0 for ?probe-slot
Code:
0 > -7D84B8 u. FF827B48  ok
0 > -7CED20 u. FF8312E0  ok
We need to find where in probe-slots that code is at to patch it. You can try doing that with one of these:
' probe-slots 638 dump
' probe-slots dis
but they don't provide much context. xsee in OF 2.4 does a better job. But for the most info, I dump all the bytes of the dictionary, convert the text to binary, then use my DumpMacRom.sh script and OpenBIOSStuff tools:
Code:
FF831405: b(:) \ [0x0b7] 0xa3d probe-slots
FF831418: 967E FFFC                       stwu     r19,-4(r30)                          
FF83141C: 7E68 02A6                       mflr     r19                                  
FF831420: 4BFF F381     FF8307A0          bl       mac_rom_value_A1E_80000000           
FF831424: 4BFD A735     FF80BB58          bl       0=                                   
...
FF831690: 4BFF 64B9     FF827B48          bl       mac_rom_value_98E_FFFFFFFF           
FF831694: 4BFD 88CD     FF809F60          bl       mac_rom_code_465                     
FF831698: 4800 0080     FF831718          b        $+128                                
FF83169C: 4BFD 7CB5     FF809350          bl       b<lit>                               
FF8316A0: 0000 0012                       dc.l     0x12                                 
FF8316A4: 4BFD 7CAD     FF809350          bl       b<lit>                               
FF8316A8: 0000 0018                       dc.l     0x18                                 
FF8316AC: 4BFD 9D25     FF80B3D0          bl       -1                                   
FF8316B0: 4BFF FC31     FF8312E0          bl       mac_rom_colon_A3B                    
FF8316B4: 4BFD 7C9D     FF809350          bl       b<lit>                               
FF8316B8: 0000 000D                       dc.l     0xD                                  
FF8316BC: 4BFD 7C95     FF809350          bl       b<lit>                               
FF8316C0: 0000 0017                       dc.l     0x17                                 
FF8316C4: 4BFD 9D0D     FF80B3D0          bl       -1                                   
FF8316C8: 4BFF FC19     FF8312E0          bl       mac_rom_colon_A3B                    
FF8316CC: 4BFD 7C85     FF809350          bl       b<lit>                               
FF8316D0: 0000 000E                       dc.l     0xE                                  
FF8316D4: 4BFD 7C7D     FF809350          bl       b<lit>                               
FF8316D8: 0000 0019                       dc.l     0x19                                 
FF8316DC: 4BFD 9CF5     FF80B3D0          bl       -1                                   
FF8316E0: 4BFF FC01     FF8312E0          bl       mac_rom_colon_A3B                    
FF8316E4: 4BFD 7C6D     FF809350          bl       b<lit>                               
FF8316E8: 0000 000F                       dc.l     0xF                                  
FF8316EC: 4BFD 7C65     FF809350          bl       b<lit>                               
FF8316F0: 0000 001C                       dc.l     0x1C                                 
FF8316F4: 4BFD 9CDD     FF80B3D0          bl       -1                                   
FF8316F8: 4BFF FBE9     FF8312E0          bl       mac_rom_colon_A3B                    
FF8316FC: 4BFD 7C55     FF809350          bl       b<lit>                               
FF831700: 0000 0011                       dc.l     0x11                                 
FF831704: 4BFD 7C4D     FF809350          bl       b<lit>                               
FF831708: 0000 0016                       dc.l     0x16                                 
FF83170C: 4BFD 9CC5     FF80B3D0          bl       -1                                   
FF831710: 4BFF FBD1     FF8312E0          bl       mac_rom_colon_A3B                    
FF831714: 4800 0220     FF831934          b        $+544
FF831405 is the header for the probe-slots compiled word. The header includes flags (such as if the word is named or an instance or is named but hidden) the name of the word (if the flags say it has a name), the fcode token number (0xa3d), some flags, and the type of the word (in this case, it's a colon definition function).
FF831418 is the execution token of probe-slots.
FF827B48 is the address of the code (execution token) for the ?gazelle value flag. A3B is the fcode token number of the unnamed ?probe-slot word at FF8312E0.

Our patch can't use fixed execution tokens because they are not guaranteed to be the same for every boot. Our patch will reference ?probe-slot by the fcode number using get-token. The thing about fcode numbers is that they get reused by subsequent fcode images that are loaded afterward. a3b get-token will work before probe-all loads other fcode images which is when we want our patch to be applied.

Our patch will start at FF83169C which is ' probe-slots 284 +. After the patch is executed, it will jump to FF831714 (probe-slots + 0x2FC) to skip everything in that if / else.

This is what we'll put in the nvramrc:
Code:
dev pci1
defer ?p
a3b get-token drop to ?p
: ps
0d 17 -1 ?p
0e 19 -1 ?p
0f 1c -1 ?p
11 16 -1 ?p
12 18 -1 ?p
;
' probe-slots dup
284 + ' ps blpatch
dup 288 + swap 2FC + brpatch
unselect-dev
The behaviour of the ?p defer word is set to the execution token of the a3b fcode token (?probe-slot). ps has the same code that we're replacing except device @12 (for the ATI gpu) is probed last instead of first.
blpatch makes probe-slots + 0x284 call ps (like a subroutine call). ps will return to probe-slots at the next instruction which is at offset 0x288. brpatch makes probe-slots + 0x288 goto + 0x2FC (it's a branch instruction).

Hopefully whatever happened with the GPU fcode won't happen with the Sonnet fcode or whatever you have getting probed before the GPU. There might have been a reason for Apple to probe the ATI GPU first.
No way, that seemed to have worked!!! Onboard video still working as well! Going to test further now.

Code:
0 > dev / ls
FF828518: /PowerPC,603@0
FF828D90: /chosen@0
FF828F68: /memory@0
FF8290B0: /openprom@0
FF829170: /AAPL,ROM@FFC00000
FF829388: /options@0
FF8298E0: /aliases@0
FF829B78: /packages@0
FF829C00:   /deblocker@0,0
FF82A328:   /disk-label@0,0
FF82A8A0:   /obp-tftp@0,0
FF82CB10:   /mac-files@0,0
FF82D230:   /mac-parts@0,0
FF82D990:   /aix-boot@0,0
FF82DDE0:   /fat-files@0,0
FF82F3F8:   /iso-9660-files@0,0
FF82FD60:   /xcoff-loader@0,0
FF830618:   /terminal-emulator@0,0
FF8306B0: /bandit@F2000000
FF831CA0:   /ohare@10
FF832530:     /mesh@10000
FF834058:       /sd@0,0
FF834C40:       /st@0,0
FF8358B8:     /escc@13000
FF835A10:       /ch-a@13020
FF836050:       /ch-b@13000
FF836690:     /awacs@14000
FF836778:     /swim3@15000
FF8378D8:     /nvram@60000
FF8379A8:     /ata@20000
FF838FC8:     /via-cuda@16000
FF839BF8:       /adb@0,0
FF839CE8:         /keyboard@0,0
FF83A528:         /mouse@1,0
FF83A7E8:       /pram@0,0
FF83A898:       /rtc@0,0
FF83AD38:       /power-mgt@0,0
FF83B4E8:   /pci106b,1@B
FF83B6C0:   /pci-bridge@D
FF83C328:     /pci14db,35@8
FF83C598:     /pci14db,35@8,1
FF83C808:     /pci14db,e0@8,2
FF83CA78:     /pci14db,3044@9
FF83CD08:     /Seri-Tek1S2@A
FF8427B8:       /sd@0,0
FF8619B0:   /pci1011,14@E
FF861C70:   /pci1011,14@11
FF861F30:   /ATY,264GT-B@12
 ok
0 >
 

Phipli

Well-known member
Thanks for this. The result shows the bridge did not get probed:
00:0D.0-[00] - the secondary and subordinate bus numbers are 0.

The developer of dingusppc is working on improving PSX (memory controller) emulation before committing 6500 machine initialization code but I was able to get into Open Firmware 2.0.3 with the stuff that he already commited by making my own 6500 machine initialization code.

When I ran dingusppc with the new code, I didn't see any problems. All my pci-bridges and USB and FireWire devices were added and there was no limit on PCI bridge nesting, just like in OF 1.0.5, 2.0f1, and 2.4.

Code:
Open Firmware, 2.0.3
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /pci-bridge@E
FF83C1D0:     /pci16b8,12@0
FF83C440:     /pci16b8,12@0,1
FF83C6B0:     /pci16b8,21@0,2
FF83C920:     /pci16b8,1@1
FF83CBB8:     /pci105a,ad69@2

But I compared the emulated device tree with the real device trees that you guys posted and noticed the ATI GPU was missing so I added that to the dingusppc 6500 machine initialization code. Then my pci-bridge devices didn't get added:
Code:
...
FF83B3B8:   /pci106b,1@B
FF83B568:   /ATY,264GT-B@12
FF840C88:   /pci-bridge@E

So there could be a problem with the ATY,264GT-B fcode. We could try tracking down that problem. Or maybe just changing the order that the devices are probed might help. Lots of things to try.

As a quickie we'll try the latter now:
probe-slots has the probe order info. It looks like this as Forth code (from the comparison I posted earlier):
Code:
        ?gazelle if
            12 18 -1 ?probe-slot
            0d 17 -1 ?probe-slot
            0e 19 -1 ?probe-slot
            0f 1c -1 ?probe-slot
            11 16 -1 ?probe-slot
        else
The see probe-slots command shows that as this:
Code:
    ^-7D84B8  if
      12 18 -1 ^-7CED20
       D 17 -1 ^-7CED20
       E 19 -1 ^-7CED20
       F 1C -1 ^-7CED20
      11 16 -1 ^-7CED20
      else
Where the numbers preceded by ^ are execution tokens - basically an address to a Forth word because OF 2.0.3 doesn't have names for those words. -7D84B8 is FF827B48 (just add 4GB) for ?gazelle and -7CED20 is FF8312E0 for ?probe-slot
Code:
0 > -7D84B8 u. FF827B48  ok
0 > -7CED20 u. FF8312E0  ok
We need to find where in probe-slots that code is at to patch it. You can try doing that with one of these:
' probe-slots 638 dump
' probe-slots dis
but they don't provide much context. xsee in OF 2.4 does a better job. But for the most info, I dump all the bytes of the dictionary, convert the text to binary, then use my DumpMacRom.sh script and OpenBIOSStuff tools:
Code:
FF831405: b(:) \ [0x0b7] 0xa3d probe-slots
FF831418: 967E FFFC                       stwu     r19,-4(r30)                           
FF83141C: 7E68 02A6                       mflr     r19                                   
FF831420: 4BFF F381     FF8307A0          bl       mac_rom_value_A1E_80000000            
FF831424: 4BFD A735     FF80BB58          bl       0=                                    
...
FF831690: 4BFF 64B9     FF827B48          bl       mac_rom_value_98E_FFFFFFFF            
FF831694: 4BFD 88CD     FF809F60          bl       mac_rom_code_465                      
FF831698: 4800 0080     FF831718          b        $+128                                 
FF83169C: 4BFD 7CB5     FF809350          bl       b<lit>                                
FF8316A0: 0000 0012                       dc.l     0x12                                  
FF8316A4: 4BFD 7CAD     FF809350          bl       b<lit>                                
FF8316A8: 0000 0018                       dc.l     0x18                                  
FF8316AC: 4BFD 9D25     FF80B3D0          bl       -1                                    
FF8316B0: 4BFF FC31     FF8312E0          bl       mac_rom_colon_A3B                     
FF8316B4: 4BFD 7C9D     FF809350          bl       b<lit>                                
FF8316B8: 0000 000D                       dc.l     0xD                                   
FF8316BC: 4BFD 7C95     FF809350          bl       b<lit>                                
FF8316C0: 0000 0017                       dc.l     0x17                                  
FF8316C4: 4BFD 9D0D     FF80B3D0          bl       -1                                    
FF8316C8: 4BFF FC19     FF8312E0          bl       mac_rom_colon_A3B                     
FF8316CC: 4BFD 7C85     FF809350          bl       b<lit>                                
FF8316D0: 0000 000E                       dc.l     0xE                                   
FF8316D4: 4BFD 7C7D     FF809350          bl       b<lit>                                
FF8316D8: 0000 0019                       dc.l     0x19                                  
FF8316DC: 4BFD 9CF5     FF80B3D0          bl       -1                                    
FF8316E0: 4BFF FC01     FF8312E0          bl       mac_rom_colon_A3B                     
FF8316E4: 4BFD 7C6D     FF809350          bl       b<lit>                                
FF8316E8: 0000 000F                       dc.l     0xF                                   
FF8316EC: 4BFD 7C65     FF809350          bl       b<lit>                                
FF8316F0: 0000 001C                       dc.l     0x1C                                  
FF8316F4: 4BFD 9CDD     FF80B3D0          bl       -1                                    
FF8316F8: 4BFF FBE9     FF8312E0          bl       mac_rom_colon_A3B                     
FF8316FC: 4BFD 7C55     FF809350          bl       b<lit>                                
FF831700: 0000 0011                       dc.l     0x11                                  
FF831704: 4BFD 7C4D     FF809350          bl       b<lit>                                
FF831708: 0000 0016                       dc.l     0x16                                  
FF83170C: 4BFD 9CC5     FF80B3D0          bl       -1                                    
FF831710: 4BFF FBD1     FF8312E0          bl       mac_rom_colon_A3B                     
FF831714: 4800 0220     FF831934          b        $+544
FF831405 is the header for the probe-slots compiled word. The header includes flags (such as if the word is named or an instance or is named but hidden) the name of the word (if the flags say it has a name), the fcode token number (0xa3d), some flags, and the type of the word (in this case, it's a colon definition function).
FF831418 is the execution token of probe-slots.
FF827B48 is the address of the code (execution token) for the ?gazelle value flag. A3B is the fcode token number of the unnamed ?probe-slot word at FF8312E0.

Our patch can't use fixed execution tokens because they are not guaranteed to be the same for every boot. Our patch will reference ?probe-slot by the fcode number using get-token. The thing about fcode numbers is that they get reused by subsequent fcode images that are loaded afterward. a3b get-token will work before probe-all loads other fcode images which is when we want our patch to be applied.

Our patch will start at FF83169C which is ' probe-slots 284 +. After the patch is executed, it will jump to FF831714 (probe-slots + 0x2FC) to skip everything in that if / else.

This is what we'll put in the nvramrc:
Code:
dev pci1
defer ?p
a3b get-token drop to ?p
: ps
0d 17 -1 ?p
0e 19 -1 ?p
0f 1c -1 ?p
11 16 -1 ?p
12 18 -1 ?p
;
' probe-slots dup
284 + ' ps blpatch
dup 288 + swap 2FC + brpatch
unselect-dev
The behaviour of the ?p defer word is set to the execution token of the a3b fcode token (?probe-slot). ps has the same code that we're replacing except device @12 (for the ATI gpu) is probed last instead of first.
blpatch makes probe-slots + 0x284 call ps (like a subroutine call). ps will return to probe-slots at the next instruction which is at offset 0x288. brpatch makes probe-slots + 0x288 goto + 0x2FC (it's a branch instruction).

Hopefully whatever happened with the GPU fcode won't happen with the Sonnet fcode or whatever you have getting probed before the GPU. There might have been a reason for Apple to probe the ATI GPU first.
Further verified!

IMG_20221222_203946.jpg
You, are an absolute genius. I take my hat off to you.

I've wrapped the patch into @cheesestraws application. I'll try fishing it off the machine.
 

Phipli

Well-known member
Here we go... find attached an application (using joevt's nvramrc script and cheesestraw's patch application) which loads it in. The file needs decompressing on the classic Mac OS machine using the program "MacZip", available from macintosh garden.
 

Attachments

  • 6500 Bridge FW Patch.zip
    25.1 KB · Views: 52

Daniël

Well-known member
Awesome to see this working so well :D

I wonder, could you roll this and the OS X patch into a single Option ROM? If so, there are what appear to be some unpopulated PLCC pads for a ROM underneath the battery velcro strip, in close proximity to the ATi 3D RAGE II+DVD GPU. It would be a 32 pin PLCC ROM, which is also what some dedicated PCI cards with the same GPU used for their Option ROM. Would be neat if that could just be dedicated to a permanent ROM patch, negating the need for NVRAMRC patching in the event it is wiped.
 
Top