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.