The Great Gazelle PCI Hack Thread, Part 2

[joevt]

nvramrc scripts like the ones originating from Apple which are included in XPostFacto (like PowerSurge.of) make small patches to Open Firmware before probe-all is executed.

After executing nvramrc, the firmware calls probe-all, install-console, and banner. Anything output to console before install-console is buffered and and not displayed until after install-console. If you include banner in nvramrc, then the firmware doesn't call probe-all and install-console. You can install-console (or (install-console) for beige G3) before probe-all and banner in the nvramrc so that your PCI fcode option ROMs can output to console immediately which is useful for debugging.

BootX (also included in XPostFacto) on the otherhand, can override all the code of a package or device. For example, it includes a replacement for packages/mac-parts as fcode and a replacement for chaos/control (the built-in graphics of a Power Mac 8600 and similar Power Macs) as forth code and it adds a sl_words package and it overrides specific words (in InitDisplay) of the chosen graphics output device.

Given all that, I wonder if it would be possible for BootX to execute without probe-all being called (from a hard disk that doesn't require probe-all), modify big chunks of the PCI probing code, then call probe-all and banner and continue to boot Mac OS X or switch to booting Mac OS 9? This can be easily tested without the modifying part. ci.c in BootX has the Enter() service that can return to the Open Firmware user interface console. The modifying part could do other interesting things such as load an fcode option rom to be executed by probe-all by hooking into the PCI fcode option rom reading function and trapping attempts to read fcode from a PCI device with a specific vendor and device id.

Of course, before probe-all there can be no graphics output device, so the console would need to be serial port until then.

If there's a limit on how big BootX can be, maybe it can load extra code from files. It does have HFS+ file system code (it's C code, not fcode or forth code) for reading kernel extensions or Extensions.mkext.

 

[dosdude1]

I didn't think anyone had got three subsystems working have I missed a post?

I was trying but ran out of space in the available patch memory.

Could you post a copy of the patch with the modifications you've made? I'd like to see if there may be some way to optimize it slightly. Also, with regard to the SATA portion of it, was the machine able to load and execute the necessary option ROM?

 

[Phipli]

Could you post a copy of the patch with the modifications you've made? I'd like to see if there may be some way to optimize it slightly. Also, with regard to the SATA portion of it, was the machine able to load and execute the necessary option ROM?

I'll dig out the 6500 - its packed away at them moment.

I think I had multiple saved patches (99% cheesestraws' hard work) that loaded up various combinations of two devices. On my card I think I remember the USB registered as two or three devices, so I picked the most accessible ports. Not promising it is a good implementation or fully correct, I didn't reach the finish line and ended up putting a different card in the 6500 and using the three way card in a beige G3.

Interestingly my card wasn't wired as RAID, it just needed the firmware switching.

@dosdude1 what was the symptom when you tried to boot the computer before disabling RAID?

 

[dosdude1]

I'll dig out the 6500 - its packed away at them moment.

I think I had multiple saved patches (99% cheesestraws' hard work) that loaded up various combinations of two devices. On my card I think I remember the USB registered as two or three devices, so I picked the most accessible ports. Not promising it is a good implementation or fully correct, I didn't reach the finish line and ended up putting a different card in the 6500 and using the three way card in a beige G3.

Interestingly my card wasn't wired as RAID, it just needed the firmware switching.

@dosdude1 what was the symptom when you tried to boot the computer before disabling RAID?

When in RAID mode, the option ROM would just not initialize at all, leaving it as “pci1095,3112” in Open Firmware. When switching it into Mass Storage mode, the option ROM initialized properly and the device then showed as “SeriTek 1S2...” in Open Firmware, and of course worked properly as well. This is in a G4, so no issue with PCI like on the 6500. I was just curious if you were able to get the SATA working properly/option ROM to load on the 6500.

I don’t have my 6500 on hand either at the moment to test, but I’ll grab it in a couple weeks.

 

[joevt]

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.

 

[treellama]

I just picked up a couple working Gazelles. I should have time after Christmas to dump this stuff.

 

[ried]

Would this be of interest (especially for TAM users)?

Yes, absolutely. Count me in for two.

I tried this originally with the Sonnet OEM patch and it behaved just like its cousin Tango 2.0 (the one with unpopulated ATA connectors.) USB and Firewire both worked, but ATA didn't.

Confirmed. Seeing the same on my TAM with a Tempo Trio (Sonnet Tango Trio Patch 1.3 applied).

 

[Phipli]

When in RAID mode, the option ROM would just not initialize at all, leaving it as “pci1095,3112” in Open Firmware. When switching it into Mass Storage mode, the option ROM initialized properly and the device then showed as “SeriTek 1S2...” in Open Firmware, and of course worked properly as well. This is in a G4, so no issue with PCI like on the 6500. I was just curious if you were able to get the SATA working properly/option ROM to load on the 6500.

I don’t have my 6500 on hand either at the moment to test, but I’ll grab it in a couple weeks.

Sorry for the delay.

These are absolutely janky hacking and I never even verified addresses or checked things because I didn't solve the "enough room" issue. But... they work to enable all of the various parts of my card (SATA, USB and FW) within different patches.

If I remember, the scripts are held in a resource within the applications (sorry, I didn't keep the text file versions organised enough to know which is which).

Note that my card treats the USB as basically three cards, so I was enabling them individually - hence one application is named for two USB + FW. I never ran all USB ports at once, because I wanted USB+somethingElse and didn't have room.

I think the scripts also enable the openfirmware to display on the video and use the keyboard instead of serial.

My card isn't visually identical to yours, but is fairly similar. I suspect different board revisions.

Please forgive the mess... I wasn't expecting to share these and hadn't got to the point of tidying up.

Applications were compiled using cheesestraws project files for CodeWarrior.

 

[cheesestraws]

If I remember, the scripts are held in a resource within the applications (sorry, I didn't keep the text file versions organised enough to know which is which).

If it's my patcher, the nvramrc is in the NVRM 128 resource.

 

[joevt]

Sorry for the delay.

These are absolutely janky hacking and I never even verified addresses or checked things because I didn't solve the "enough room" issue. But... they work to enable all of the various parts of my card (SATA, USB and FW) within different patches.

If I remember, the scripts are held in a resource within the applications (sorry, I didn't keep the text file versions organised enough to know which is which).

Note that my card treats the USB as basically three cards, so I was enabling them individually - hence one application is named for two USB + FW. I never ran all USB ports at once, because I wanted USB+somethingElse and didn't have room.

I think the scripts also enable the openfirmware to display on the video and use the keyboard instead of serial.

My card isn't visually identical to yours, but is fairly similar. I suspect different board revisions.

Please forgive the mess... I wasn't expecting to share these and hadn't got to the point of tidying up.

Applications were compiled using cheesestraws project files for CodeWarrior.

What zip program did you use? On a modern Mac, the resource forks are separated into a folder called XtraStuf.mac
There's four scripts between 1798 and 1872 bytes.

find /Volumes/Storage/Downloads/Test\ Firmware\ Patches/XtraStuf.mac -type f
/Volumes/Storage/Downloads/Test Firmware Patches/XtraStuf.mac/pitcher fwsata
/Volumes/Storage/Downloads/Test Firmware Patches/XtraStuf.mac/pitcher fwusb
/Volumes/Storage/Downloads/Test Firmware Patches/XtraStuf.mac/pitcher usbfwsata nope
/Volumes/Storage/Downloads/Test Firmware Patches/XtraStuf.mac/pitcher2usbfw

This will extract the NVRM resources as text and remove the trailing null character.

for thefile in "/Volumes/Storage/Downloads/Test Firmware Patches/XtraStuf.mac/"*; do
    echo '\ ============================================================================='
    echo '\' "$(basename "$thefile")"
    echo
    derez -useDF -only NVRM "$thefile" | perl -nE 'if (/^\s+\$"([0-9A-F ]+)/) { print $1; }' | xxd -p -r | tr -d '\0'
    echo
    echo
done

An nvramrc doesn't need to be a single line of text. Since a carriage return (ASCII 13 = 0x0d) takes the same amount of bytes as a space character (ASCII 32 = 0x20), you can put the text of the nvramrc on multiple lines without taking more bytes in nvramrc.

 

[Phipli]

What zip program did you use?

MacZip because it saves the forks.

 

[dosdude1]

Sorry for the delay.

These are absolutely janky hacking and I never even verified addresses or checked things because I didn't solve the "enough room" issue. But... they work to enable all of the various parts of my card (SATA, USB and FW) within different patches.

If I remember, the scripts are held in a resource within the applications (sorry, I didn't keep the text file versions organised enough to know which is which).

Note that my card treats the USB as basically three cards, so I was enabling them individually - hence one application is named for two USB + FW. I never ran all USB ports at once, because I wanted USB+somethingElse and didn't have room.

I think the scripts also enable the openfirmware to display on the video and use the keyboard instead of serial.

My card isn't visually identical to yours, but is fairly similar. I suspect different board revisions.

Please forgive the mess... I wasn't expecting to share these and hadn't got to the point of tidying up.

Applications were compiled using cheesestraws project files for CodeWarrior.

Awesome, thanks a ton. Going to mess around with this in a couple weeks, when I get a chance to grab my PowerMac 6500.

 

[cheesestraws]

An nvramrc doesn't need to be a single line of text. Since a carriage return (ASCII 13 = 0x0d) takes the same amount of bytes as a space character (ASCII 32 = 0x20), you can put the text of the nvramrc on multiple lines without taking more bytes in nvramrc.

There was some reason why I did them all as single-line and I cannot for the life of me remember what it was. It probably wasn't important or I would have remembered it!

 

[Phipli]

There was some reason why I did them all as single-line and I cannot for the life of me remember what it was. It probably wasn't important or I would have remembered it!

I think there was a bug where it didn't work if you didn't ... because gazelle openfirmware implementation.

But I also can't remember. It might be in this thread somewhere... or our emails.

 

[dosdude1]

I think I got it!! After a bit of analysis, I believe I have crafted a working NVRAMRC script, that not only should enable ALL the devices on the combo card (all USB ports, FireWire and SATA), but is ALSO even smaller than the original script! I have attached an expanded, easy-to-read version, and a "minified" (no newlines) version for use in NVRAMRC (if that's even necessary). Unfortunately I don't have a machine with me to test this on at the moment, but if someone could test and let me know the results, that'd be great. The script of course can also be easily edited for other cards, just add/remove/modify the "new-dev" lines with the PCI bridge location IDs to match your card.

 

[Byrd]

Yeah! To the uninitiated, Tango 2.0 in TAM ready to go, how do you apply this patch? Thanks for spending the time to sort things out.

 

[dosdude1]

Yeah! To the uninitiated, Tango 2.0 in TAM ready to go, how do you apply this patch? Thanks for spending the time to sort things out.

This patch is more meant for the SIIG USB/FireWire/SATA combo card, but the patch made by @cheesestraws for the Tango 2.0 should work, as far as I'm aware.

 

[joevt]

I think I got it!! After a bit of analysis, I believe I have crafted a working NVRAMRC script, that not only should enable ALL the devices on the combo card (all USB ports, FireWire and SATA), but is ALSO even smaller than the original script! I have attached an expanded, easy-to-read version, and a "minified" (no newlines) version for use in NVRAMRC (if that's even necessary). Unfortunately I don't have a machine with me to test this on at the moment, but if someone could test and let me know the results, that'd be great. The script of course can also be easily edited for other cards, just add/remove/modify the "new-dev" lines with the PCI bridge location IDs to match your card.

You should take some inspiration from Apple's Open Firmware patches (such as PowerSurge.of at #178 ) which reduce the size by converting common words to two characters.

This version reduces the nvramrc script from 1755 to 1390 characters.

hex probe-all install-console banner
: cp $call-parent ;
: p! " config-l!" cp ;
: p@ " config-l@" cp ;
: m$ my-space ;
: a$ " assigned-addresses" ;
: d$ new-device 0 0 ;
: o2 encode-2ints ;
: o3 encode-3ints ;
: o+ encode+ ;
: p% property ;
: e$ encode-cat ;
: n$ m$ p@ dup d# 16 >> swap 0000FFFF and m$ d# 8 + p@ d# 8 >> 60400 = swap 3388 = and swap 21 = and ;
: p$ make-properties 0 alloc-here 0 " pci" e$ m$ 2c + p@ -rot 2 pick FFFF and (u.) e$ " ," e$ rot d# 16 >> (u.) e$ 2dup swap 3 + swap bounds do i c@ 40 > if i c@ 20 + i c! then loop device-name 0 0 o2 " power-consumption" p% 0 0 m$ o3 0 0 o2 o+ 0 0 m$ 2 d# 24 << or 10 + o3 1000 0 o2 o+ o+ " reg" p% ;
: c$ set-args p$ dup 1000 + m$ 10 + p! dup 1000 + 0 m$ 82 d# 24 << or 10 + o3 1000 0 o2 o+ a$ p% finish-device ;
: $n a$ delete-property m$ dup 18 + 10100 swap p! 4 + dup p@ FFFFFFF4 and 2 or swap p!
d$ " 8,0" set-args p$ 0 100000 20 claim-real swap drop dup dup 100000 " map-range" cp dup m$ 10 + p! dup 0 m$ 82 d# 24 << or 10 + o3 1000 0 o2 o+ a$ p% finish-device
d$ " 8,1" c$
d$ " 8,2" c$
d$ " 9,0" c$
d$ " a,0" c$
dup dup 10 >> or m$ 20 + p! m$ 3c + dup p@ 800000 or swap p! " ranges" delete-property dup 0 82000000 o3 rot 0 82000000 o3 100000 0 o2 o+ o+ " ranges" p% m$ 18 + p@ dup 8 >> ff and swap d# 16 >> ff and o2 " bus-range" p% ;
: x ['] select-dev catch if 2drop else n$ if $n then then ;
" pci1/@d" x " pci1/@e" x

Yeah! To the uninitiated, Tango 2.0 in TAM ready to go, how do you apply this patch? Thanks for spending the time to sort things out.

Since the meat of this script is executed after probe-all, it means you can test it without loading it into nvramrc (using a serial port connection, copy everything starting after banner). If it works (check using 7fffffff to lines/page " printenv" evaluate dev / ls unselect-dev dump-device-tree words 16 to lines/page, then you can load it into nvramrc using nvedit or a modified patcher app (NVRM 128 resource) #188 or a modified XPostFacto (OFpt 137 resource for Gazelle).

This patch is more meant for the SIIG USB/FireWire/SATA combo card, but the patch made by @cheesestraws for the Tango 2.0 should work, as far as I'm aware.

I still think it may be possible to create a general solution, depending on what is missing from the Open Firmware of the 6500/TAM. I've finished adding support for pci bridges and multifunction PCI cards in dingusppc and my emulated Tempo Trio works for the Open Firmware of the 7500 (at least as far as being detected - I did not add code to emulate the functionality of the PCI devices). dingusppc doesn't currently have a machine description for the 6500/TAM so I can't test that version of Open Firmware. The information I asked for in #185 might contain the information needed to create the machine description but you need a serial port connection to to another computer to capture the info. I don't know of any other emulators that let you work in Apple's Open Firmware but I haven't really checked.

 

[dosdude1]

You should take some inspiration from Apple's Open Firmware patches (such as PowerSurge.of at #178 ) which reduce the size by converting common words to two characters.

This version reduces the nvramrc script from 1755 to 1390 characters.

hex probe-all install-console banner
: cp $call-parent ;
: p! " config-l!" cp ;
: p@ " config-l@" cp ;
: m$ my-space ;
: a$ " assigned-addresses" ;
: d$ new-device 0 0 ;
: o2 encode-2ints ;
: o3 encode-3ints ;
: o+ encode+ ;
: p% property ;
: e$ encode-cat ;
: n$ m$ p@ dup d# 16 >> swap 0000FFFF and m$ d# 8 + p@ d# 8 >> 60400 = swap 3388 = and swap 21 = and ;
: p$ make-properties 0 alloc-here 0 " pci" e$ m$ 2c + p@ -rot 2 pick FFFF and (u.) e$ " ," e$ rot d# 16 >> (u.) e$ 2dup swap 3 + swap bounds do i c@ 40 > if i c@ 20 + i c! then loop device-name 0 0 o2 " power-consumption" p% 0 0 m$ o3 0 0 o2 o+ 0 0 m$ 2 d# 24 << or 10 + o3 1000 0 o2 o+ o+ " reg" p% ;
: c$ set-args p$ dup 1000 + m$ 10 + p! dup 1000 + 0 m$ 82 d# 24 << or 10 + o3 1000 0 o2 o+ a$ p% finish-device ;
: $n a$ delete-property m$ dup 18 + 10100 swap p! 4 + dup p@ FFFFFFF4 and 2 or swap p!
d$ " 8,0" set-args p$ 0 100000 20 claim-real swap drop dup dup 100000 " map-range" cp dup m$ 10 + p! dup 0 m$ 82 d# 24 << or 10 + o3 1000 0 o2 o+ a$ p% finish-device
d$ " 8,1" c$
d$ " 8,2" c$
d$ " 9,0" c$
d$ " a,0" c$
dup dup 10 >> or m$ 20 + p! m$ 3c + dup p@ 800000 or swap p! " ranges" delete-property dup 0 82000000 o3 rot 0 82000000 o3 100000 0 o2 o+ o+ " ranges" p% m$ 18 + p@ dup 8 >> ff and swap d# 16 >> ff and o2 " bus-range" p% ;
: x ['] select-dev catch if 2drop else n$ if $n then then ;
" pci1/@d" x " pci1/@e" x

Since the meat of this script is executed after probe-all, it means you can test it without loading it into nvramrc (using a serial port connection, copy everything starting after banner). If it works (check using 7fffffff to lines/page " printenv" evaluate dev / ls unselect-dev dump-device-tree words 16 to lines/page, then you can load it into nvramrc using nvedit or a modified patcher app (NVRM 128 resource) #188 or a modified XPostFacto (OFpt 137 resource for Gazelle).



I still think it may be possible to create a general solution, depending on what is missing from the Open Firmware of the 6500/TAM. I've finished adding support for pci bridges and multifunction PCI cards in dingusppc and my emulated Tempo Trio works for the Open Firmware of the 7500 (at least as far as being detected - I did not add code to emulate the functionality of the PCI devices). dingusppc doesn't currently have a machine description for the 6500/TAM so I can't test that version of Open Firmware. The information I asked for in #185 might contain the information needed to create the machine description but you need a serial port connection to to another computer to capture the info. I don't know of any other emulators that let you work in Apple's Open Firmware but I haven't really checked.

Wow, I didn’t even think of doing that... That’ll surely make the script WAY smaller.

As for the 6500 info, I can get you that once I grab my machine in a couple weeks. I can even dump the entire system ROM for you, if that’d be of use (which I wanted to do anyways to patch in support for PPC740 CPU).

 

[cheesestraws]

Oh, very well done @dosdude1 and @joevt. I'm glad to see people who actually know Forth having a bash at this—this is the first Forth code I ever hacked on, so it's not surprising that it could have been a lot shorter!

I don't have a USB/Firewire/SATA combo to test with, unfortunately, so I'll have to let other people try this one out (The remaining card I couldn't get working was a SiiG USB/FW/Ethernet combo).