Debugging ATI drivers for Mac Mini

[ssp3]

What would be the best way to catch what's wrong with last versions of ATI RockHopper drivers from OSX 10.3.9 and up?
MacsBug? The Mini hangs at the moment whet ATI extensions start to load.

To clarify. By last versions I ment these three:

ATY,RockHopper2-1.0.1f75.pef
ATY,RockHopper2-1.0.1f89.pef
ATY,RockHopper2-1.0.1f100.pef

I've made my own drivers for OS9 with them.

FYI. v9 ROM file for Mini contains this one, the only real RockHopper2 driver that works in OS9
ATY,RockHopper2-1.0.1f63.pef

[Knezzen]

Hangs as in a total freeze (no mouse movement)?

[ssp3]

Yes, total freeze, mouse can't be moved.
At this very moment.

[ssp3]

If I look inside the ATI drivers with PEF Viewer, there in one interesting 'Untitled Data Section'. Apparently, it is compressed, but I am not sure what I'm seeing there when I look at it. What is it? FCode? I don't recognize any of the code.
Anyone? Joevt?

1.0.1f100 driver on the left, 1.0.1f63 on the right.

[joevt]

Data section is where constants and strings are stored and maybe variables. It's stored in the PEF as a sequence of opcodes and data (the compressed info) which is decompressed when loaded.

Do other binary formats like mach-o not compress their data sections? I think they have a loader section that tells how the other sections are to be loaded (section opcodes?) but I don't think they have opcodes like the PEF data section has.

An ndrv never contains fcode since the Open Firmware environment is long gone by the time the ndrv is loaded.

8 byte numbers like 3ff66666 66666666 where the first 12 bits look different from the remaining 52 bits are probably 64 bit floating-point numbers. The MSB is a sign bit (0 = positive). the next 11 bits are the exponent (3ff = 1 or 0 - I forget which) and the remaining 52 bits are the mantissa.

Many of the strings in the data appear to be device-tree node paths or property names. The device-tree originates from the Open Firmware device tree and Mac OS 9 uses that to build the Name Registry and Mac OS X uses it to build the IO Registry.

[ssp3]

Thanks, joevt, for your insight.
What do you think, what kind of compression is used here? Any idea how to decompress it, manipulate and then compress it back? I'm not a programmer, so I'm a bit lost here.

As I said before, f100 driver hangs the machine. At first I thought that since it was written for OSX, some symbols (or whatever they're called in OS9) might be missing, but no, everything seems to be present. Most imports are from Carbon Lib. One interesting export caught my attention, though - device description. Maybe that's the place to start digging?

Anyone want to join?

[joevt]

The compression is exactly defined by the PEF opcodes. I suppose PEF Viewer being a viewer means it doesn't have an option to edit? The only method I tried was to convert the disassembly of a PEF to an assembly file to be compiled by MPW or CodeWarrior PowerPC assembler into a new PEF.

I used Jasik's The Debugger for disassembly and used a script to convert that to assembly. I also used DumpPEF and a script to convert that to assembly. I don't remember how well they work. Jasik's the Debugger produces inconsistent results between the two formats it creates: .list and .asm. list includes hex data and offsets for each line so it might be more useful since you can check the offsets for all the labels to find the bugs.

Other options I haven't tried:
NationalSecurityAgency/ghidra
DBJ314/dePEF-and-disarm

The MPW DumpPEF command calls the compressed data "pidata"
The pidata opcodes are listed in IOGraphics-305.14/IONDRVSupport/IOPEFInternals.h

Code: [Select]

    kPEFPkDataZero              = 0,                            /* Zero fill "count" bytes. */
    kPEFPkDataBlock             = 1,                            /* Block copy "count" bytes. */
    kPEFPkDataRepeat            = 2,                            /* Repeat "count" bytes "count2"+1 times. */
    kPEFPkDataRepeatBlock       = 3,                            /* Interleaved repeated and unique data. */
    kPEFPkDataRepeatZero        = 4                             /* Interleaved zero and unique data. */

To be Mac OS X compatible, an ndrv must import only from a specific set of libraries. CarbonLib is definitely not one of them. Does it say CarbonLib somewhere in the ndrv? Maybe you could post a link to the ndrv so we know what you're looking at.
See IOGraphics-305.14/IONDRVSupport/IONDRVLibraries.cpp for the list of libraries and functions from each library.
Drivers should only use: PCILib, VideoServicesLib, NameRegistryLib, and DriverServicesLib
Apple also allowed some functions from InterfaceLib and PrivateInterfaceLib to make some of its ndrv's compatible with OS X.
Actually, IOGraphics-305.14 is for 10.5.8. If you look at IOGraphics-179.2.1 (for 10.4.11), then you see there's also some functions from the AtiUtils library which is used by the Beige G3's GPU.
XPostFacto may have some kexts that define some other libraries and functions to allow some other ndrv's to be usable. I added some libraries and functions to make my modified sixty6 ndrv usable (for video out of Power Mac 8600).

I'm not sure it's possible to create a ndrv that is compatible with OS X but not Mac OS 9?

An ndrv is suppose to have two exports:
TheDriverDescription - data
DoDriverIO - code

https://developer.apple.com/library/archive/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/Designing_PCI_Cards_Drivers.pdf

[ssp3]

Thanks for your input, joevt!

Maybe you could post a link to the ndrv so we know what you're looking at.

First attachment - drivers (extensions) for OS9 made out of OSX ndrvs. f63 is working in OS9, f100 is not.
Second attachment - OSX ndrvs f63 and f100 as extracted from OSX parts by ELN. From his GitHub repo.
Third attachment - PEF Viewer for OSX that I made to work standalone. Works on PPC and Intel under Rosetta.
Fourth attachment - asm and lst files of both PEFs, f63 and f100.

[joevt]

What disassembler did you use? IDA? Which version?

The assembly listings show the imported libraries and functions as expected:
VideoServicesLib, NameRegistryLib, PCILib, DriverServicesLib

No unsupported libraries appear to be included. version f100 adds AbsoluteDeltaToDuration but that's not a problem since CIncludes shows that API as going back to Mac OS 8.6.

I don't see a device description, just "TheDriverDescription" as expected. The only difference in TheDriverDescription is the version number changed from 63 to 100.

Comparing the assembly listings would require renaming all the unnamed labels since they have different offsets or positions between version f63 and f100. In MPW you could create scripted menu items with command key short cuts to do the renaming of each label for you. It would work like this: select the label on the left and the label on the right. Choose a new common name for the labels. Have it verify that the new name is unused in both files, then have it rename all occurrences in the old version and the new version and re-compare. I did that with Open Firmware drivers. Open Firmware is different since the labels are order based (1,2,3,4...), rather than offset based, so that when renaming a label in Open Firmware, you could have it automatically rename all labels after that by incrementing there order number that is included in the label name thus greatly reducing the number of renames required.

Is there a modern utility to do a similar compare/rename? Does IDA have a compare binaries option? Can you change the assembly format to use order based names instead of offset based names? I suppose one could easily create a script to rename offset based labels as order based labels.

[joevt]

Did you say why you wanted to use a version other than f63 with OS 9?

What does "v9 ROM file for Mini" mean?

Is there an ndrv in Open Firmware? If so, what if you remove it before booting OS 9? Or replace it with a newer version before booting OS 9?

[ssp3]

Did you say why you wanted to use a version other than f63 with OS 9?

In the hope that it will correctly enable graphic acceleration on "silent upgrade" G4 Minis (1,33 and 1,5 GHz models) and permit using larger displays with them.
Since ELN and darthNvader haven't been seen here for about a year, someone has to pick up the torch

If you haven't followed this topic, which is scattered across several threads, here are a couple of links to get you up to date:

Starting from this post:
http://macos9lives.com/smforum/index.php?topic=7048.msg54332#msg54332

This thread:
http://macos9lives.com/smforum/index.php?topic=4987.0

What does "v9 ROM file for Mini" mean?

Is there an ndrv in Open Firmware? If so, what if you remove it before booting OS 9? Or replace it with a newer version before booting OS 9?

This post by ELN explains everything:
http://macos9lives.com/smforum/index.php?topic=2408.msg37482#msg37482

[ssp3]

Re. disassembler - check PM.
Whether it can compare binaries, I don't think so, i.e. I don't see such option in the menus. It can produce dif file, but that one is probably based on changes one makes to the disassembled binary. I also have to admit that I only scratched the surface of this monster.

There is a VisualDiffer for OSX, but I don't think that the way it compares binaries is useful here. See attachment with both asms compared.
Then there's Araxis Merge, but that's not much better either.

Can you change the assembly format to use order based names instead of offset based names?

I don't see that option.

MPW - never ever used it, don't have it installed. (I'm not a programmer).

I suppose one could easily create a script to rename offset based labels as order based labels.

The disassembler does support Python 2.7 ..

[joevt]

What mode is the graphics card trying to use when the display goes black?

Some things to try:
- A modern display that isn't limited to 1920x1080 60Hz. I have a Acer XV273K 4K display which can accept anything up to 5K60 or 8K30 via DisplayPort. Not sure about HDMI/DVI though.
- Connect two displays - one display that is known to work so that you can see what timing is being attempted on the display that doesn't work.
- If you can't get two displays, then maybe a screen sharing app, so you can use another Mac to see what's happening when the display goes black on the first Mac.
- A custom EDID adapter like Dr HDMI 8K.
- A scan converter that can take an input and convert it to a different timing that is acceptable by the display.
- A HDMI capture device (USB or PCIe) - maybe it can accept what ever is being output.
- SwitchRes - I don't remember if the OS 9 version has custom timing options? Maybe it can at least disable modes that don't work with your display.

Regarding DVI to HDMI adapters : they are all single link even if they say dual link.

Noname VGA to HDMI USB-Powered Active Converter are terrible. They only work with some modes, produce blurry results, and loose some lines of pixels.

Nvidia 7800 or Nvidia Quadro FX4500 should be able to do 1440p60 or 4K30 using Dual Link DVI to DisplayPort adapter.

In the post by ELN that you linked, he mentions his PEF viewer and assembler python scripts. He said:
"To achieve this, I got sidetracked and wrote a single-file PowerPC assembler script (ppcasm.py) and PEF dump/rebuild script (cfmtool.py):"
 https://github.com/elliotnunn/tbxi-patches/
I haven't tried them to verify that the disassemble -> assemble steps are deterministic/reversible, such that you can disassemble the assembled product to get an assembly that matches the first assembly (for example, my DumpPCIRom -> toke utilities can recreate the Open Firmware PCI option ROM from the Forth code generated by the original Open Firmware PCI option ROM). If they work, then that might be the simplest way to go. The labels generated by cfmtool could be altered to be order based instead of position based if they are not already.

A python script to rename all the labels in IDA is another option. Hopper can also do PEF but it's buggy.

[ssp3]

What mode is the graphics card trying to use when the display goes black?

I have no idea.

Some things to try:
- A modern display that isn't limited to 1920x1080 60Hz. I have a Acer XV273K 4K display which can accept anything up to 5K60 or 8K30 via DisplayPort. Not sure about HDMI/DVI though.

G4 Mini is limited to 1920x1200 on DVI and 1920x1080 on VGA. That's about it.

- Connect two displays - one display that is known to work so that you can see what timing is being attempted on the display that doesn't work.

There is no provision to connect two displays to G4 Mini.

- If you can't get two displays, then maybe a screen sharing app, so you can use another Mac to see what's happening when the display goes black on the first Mac.

Never used anything like that in OS9 and have no idea if such app exists.

These three are beyond the point

- A custom EDID adapter like Dr HDMI 8K.
- A scan converter that can take an input and convert it to a different timing that is acceptable by the display.
- A HDMI capture device (USB or PCIe) - maybe it can accept what ever is being output.

- SwitchRes - I don't remember if the OS 9 version has custom timing options? Maybe it can at least disable modes that don't work with your display.

It doesn't help, because computer freezes at the moment when ATI extensions load!

But, its not about my particular display, it is about latest version of ATI driver not working with ANY display.

[IIO]

G4 Mini is limited to 1920x1200 on DVI and 1920x1080 on VGA. That's about it.

VGA is working fine here with WUXGA - unlike on the stupid coreduo minis.

[ssp3]

G4 Mini is limited to 1920x1200 on DVI and 1920x1080 on VGA. That's about it.

VGA is working fine here with WUXGA - unlike on the stupid coreduo minis.

You're right, of course. See what happens when you carelessly quote Everymac com. Even I myself was running 1920x1200 on VGA in my ATI tests. Doh! 

[ssp3]

An update.
I now think that ATI Resource Manager also plays a role here. I've changed back to 3.1.6 Resource Manager as an experiment and now the Mini hangs at start-up with previously working f63 ATI driver in a similar way it does with f100 ATI driver and 3.2.1 Resource Manager