Tips & Tidbits

by MacTech Staff

Headache Free PCI Driver Development

I have been involved in the development of a couple of PCI driver for the new PowerPC Macintoshes and would like to share a back and time saver.

Unlike your standard system extensions that you can disable by holding down the shift key, you cannot disable PCI driver extensions from loading. This can cause problems if you have tweaked some driver code that causes you to crash and thereby forcing you to bend over your machine and extract the PCI card from the slot, reboot, fix the bug, shutdown, reinstall the PCI card, ... you get the picture. Now Apple may have a way of doing this that I don’t know yet, but in case my hunch is correct, here is a surefire way of disabling the loading of your driver.

A little PowerPC shared library knowledge is required here, so here is a $.05 lesson. When a shared library is being prepared for execution by the code fragment manager, it first calls the initalization routine (if one has been specified) of the shared library. The prototype for that function is:

OSErr CFMInit( CFragInitBlockPtr initBlkPtr );

If the shared library returns anything other than noErr (0) to the code fragment manager, then the execution of the library is terminated and nothing gets loaded. This is the hook we will use to provide the mechanism for disabling a driver on startup.

Here is an example initialization routine:

extern “C” OSErr CFMInitialize( CFragInitBlockPtr /*initBlkPtr*/ ) 
{
 DriverGlobal *globals = GetDriverGlobals();
 OSErr  err = 0x1234;

    // Initialize global data.

 ...

    // Test for on demand disabling...

 if( Button() ) 
 {
 DebugStr( “\p In CFMInitialize...Mouse button down.” );       
 if( err == 0x1234 ) err = noErr; 
 } 
 else err = noErr;

return( err );

}

If the mouse button is held down after MacsBug is loaded (NOTE! Wait until MacsBug is loaded because it uses a similar mechanism to disable loading,) then we will drop into the debugger.

I have set ‘err’ to 0x1234 because it is easy to spot in the register list, which is where the compiler will most likely store it before assigning it to R3 which is will hold the return value. What we do now is set the register holding 0x1234 to something different. This can be done with the following command within MacsBug:

r30 = FFFF

Where r30 is the register holding 0x1234 (NOTE! This will most likely be different on you Mac). When you type Command-G to get out of the debugger, the lines just after the DebugStr will be executed. If you didn’t modify ‘err’ then it will still be 0x1234 and we need to set it to noErr to ensure the shared library gets loaded. Otherwise we fall thru and the shared library will not be loaded. You can then fix your bug, replace the driver in the System Folder, and restart.

Now if for some reason the compiler has stored the ‘err’ value onto the stack then you will need to step through the code, one line at a time, (Command-S will do this) until you get to the ‘blr’ instruction. It will look something like this:

0442FF1Cblr
|4E800020

At this instruction simply execute the command:

r3 = FFFF

...and Command-G to go.

Now you may ask why not just disable the driver if the mouse button is down. You could do that, but you may have multiple drivers that use the same disabling sequence and that would cause all of them to become disabled, plus you can verify which driver is acting up.

- Chris Rudolph