DSDT: trick retail drivers by changing "device-id" (e.g USB)

[zhell]

Patch DSDT to Enable Apple Drivers for non-Apple Hardware

 

Some KEXTs use the "device-id" of devices attached to the PCI bus to decide (i) whether to start and (ii) to tweak their behavior depending on the specific device.

This allows some but far from all KEXTs to be tricked into believing that you have hardware that is used by Apple and thus enjoying support from Apple's drivers.

 

In this tutorial, I will show how to get boards with USB from the Intel ICH9/-R chip (Intel P35 chipset) to sleep properly by leading the USB KEXTs into believing that it is actually an ICH10-R, which is used in the MacPro4,1. This fix requires Mac OS X 10.5.7.

Note: Automatic sleep after an idle period is not enabled by this fix. This problem is not necessarily even related to USB but might be caused by your DVD drive.

 

If your computer goes to sleep properly (i.e. all disks and fans completely switched off) but has trouble waking up, this fix may unfortunately not help.

 

If you have Mac OS X 10.5.5 or earlier, the fix won't change anything. Using it with Mac OS X 10.5.6 is not recommended.

If your computer has an ICH9/-R and can only sleep with slice's USB kexts, this fix should allow you to get sleep with the stock USB drivers from 10.5.7.

What the fix does is it lets the USB kext "recognize" the UHCI devices and enables the proper work-arounds for their quirks (see the "Errata" property of "AppleUSBUHCI" devices in IORegistryExplorer: if it is 0x0, the driver has probably not recognized the device).

To understand what is going on, you may want to install the USB Debug Kit from Apple. Using the supplied KEXTs, you will see at boot that the device is not supported and therefore power manangement is turned off. This results in the well-known behavior of the computer going to sleep only half-way and then requiring a hard reset to get back to life.

 

Thanks to CycloneFr and THe KiNG for beta testing!

 

Note: You are using this at your own risk. Tricking drivers into believing the hardware is something it isn't may seriously damage your computer.

The fix itself is quite simple for DSDT standards. However, I assume you are fairly experienced modding the DSDT. Otherwise, you should get your feet wet with some other tutorial.

Using the widely-used patch method "DTGP", we will add a property "device-id" to the UHCI devices in the DSDT. This property will be chosen to match that of the corresponding devices of the ICH10-R used in MacPro4,1.

 

Note: Do not set the model of your machine to MacPro4,1, as this will cause a kernel panic with 10.5.7. Just set it to MacPro3,1 or leave it at whatever you have used before.

 

Method DTGP

Ensure you have method DTGP defined somewhere in your DSDT.dsl. You might want to use the DSDT patcher to insert this method by applying one of its many fixes. This tutorial does not cover this. The end result is that you need to have the following code in the right place:

   Method (DTGP, 5, NotSerialized)
   {
       If (LEqual (Arg0, Buffer (0x10)
               {
                   /* 0000 */    0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, 
                   /* 0008 */    0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
               }))
       {
           If (LEqual (Arg1, One))
           {
               If (LEqual (Arg2, Zero))
               {
                   Store (Buffer (One)
                       {
                           0x03
                       }, Arg4)
                   Return (One)
               }

               If (LEqual (Arg2, One))
               {
                   Return (One)
               }
           }
       }

       Store (Buffer (One)
           {
               0x00
           }, Arg4)
       Return (Zero)
   }

Once you are done with this step and your DSDT.dsl still compiles without errors and warnings (or at least not more than before you touched it), you may proceed identifying the devices we will patch.

 

Identifying Your UHCI Devices

The UHCI devices may be called anything. However, we can identify them based on their addresses, which are given by the line that begins with "Name (_ADR, 0x...). My second UHCI device, called "UHC2", begins like this:

	  Device (UHC2)
  {
	Name (_ADR, 0x001D0001)
  ...

From this value "0x001D0001", you may strip leading zeroes of every block of four figures and obtain "1D,1", which then corresponds to the addresses shown in IORegistryExplorer to the right of the "@" sign, such as "UHC2@1D,1". (IORegistryExplorer is part of XCode Tools, download from developer.apple.com). Limit the view by searching for "UHCI" and you should see something like this:

 

This way, you should be able to spot the six UHCI devices. Note that there may be more devices in the DSDT that look like UHCI devices (often there are seven), but only six are shown in IORegistryExplorer. Those are the ones we are going to patch.

 

The corresponding lines from "lspci" are:

00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #1 [8086:2934] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #2 [8086:2935] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #3 [8086:2936] (rev 03)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #4 [8086:2937] (rev 03)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #5 [8086:2938] (rev 03)
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
 USB UHCI Controller #6 [8086:2939] (rev 03)

In the second pair of brackets, you can see the PCI vendor id (8086 for Intel) and the device-id (2934..2939).

For the ICH9/-R, devices UHCI 1...UHCI 6 have the following addresses and device IDs:

UHCI 1: 1D	2934
UHCI 2: 1D,1  2935
UHCI 3: 1D,2  2936
UHCI 4: 1A	2937
UHCI 5: 1A,1  2938
UHCI 6: 1A,2  2939

Do not change the names of your devices as the DSDT won't compile anymore if you do.

Only proceed to patching if the addresses of all six UHCI devices match exactly.

 

Patching the "device-id" of the UHCI Devices

Now, we just add a call to the DTGP method by inserting a few lines of code into every single one of the 6 UHCI devices. The arguments we pass are "device-id", which is the property we want to patch, and then a four-byte buffer that contains the value to assign to the "device-id" property. These buffers are written "back-wards", i.e. the device-id for the UHC2 device of the ICH10-R, which is "3a35", is written as "0x35, 0x3A, 0x00, 0x00"

The code to add to the UHC2 device is:

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x35, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }

The device-ids for the six UHCI devices on the ICH10-R are:

UHCI 1: 1D	3a34
UHCI 2: 1D,1  3a35
UHCI 3: 1D,2  3a36
UHCI 4: 1A	3a37
UHCI 5: 1A,1  3a38
UHCI 6: 1A,2  3a39

The end result of the UHCI devices should look as follows:

           Device (UHC1)
           {
               Name (_ADR, 0x001D0000)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x34, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

           Device (UHC2)
           {
               Name (_ADR, 0x001D0001)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x35, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

           Device (UHC3)
           {
               Name (_ADR, 0x001D0002)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x36, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

           Device (UHC4)
           {
               Name (_ADR, 0x001A0000)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x37, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

           Device (UHC5)
           {
               Name (_ADR, 0x001A0001)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x38, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

           Device (UHC6)
           {
               Name (_ADR, 0x001A0002)
               [...]

               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x39, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }
           }

Have fun patching.

 

Verifying the Reliability of Sleep

You need to be aware that if your machine has never slept before, you may encounter surprises when using sleep now that it works. In order to be able to attribute any issues you may experience to sleep, I strongly recommend a thorough burn-in procedure.

 

First, unplug all USB devices that you do not need, in particular any storage devices.

Then, in all the applications you typically use, open a few documents and leave them open.

 

Now put the machine to sleep at least a hundred times and wake it up afterwards.

 

This sounds like a big hassle, but if you have a second computer that is capable of doing all the work, it's not that bad. Using the PHP script below allows you to remotely sleep and wake up your machine any number of times without human intervention.

sleep_wake.php.zip

 

You need to edit the variables "$target", "$hwaddr" and "$login". Run the script with one argument, e.g.

/path/to/sleep-wake.php 100

will sleep and wake up your machine 100 times.

Note that for wake-up to work, UDP port 9 must be open. For sleep to work, SSH needs to be enabled and you need a public key installed on the target in order to allow automatic login. How to achieve this is outside the scope of this tutorial.

[zhell]

Very interesting. Do you know any other Intel chipset that supported by (10.5.7) vanilla kext? I have ICH7 chipset, maybe I can try this trick to get sleep working.

Thanks for your interest.

Are you sure the problem of your board is related to USB? ICH7 is supported by Apple's drivers. It could be that your chip has different device-ids, though. To check this, just verify that the "Errata" value is 0x0 in IORegistryExplorer, which indicates that the chip was not recognized.

The device-ids that Apple uses for ICH7 are 27C8-27CC. For ICH8, the device-ids are 2830-2835.

[kizwan]

Very interesting. Do you know any other Intel chipset that supported by (10.5.7) vanilla kext? I have ICH7 chipset, maybe I can try this trick to get sleep working.

 

kizwan

[Master Chief]

Okay... so first we had a patched kext (IOUSBFamily.kext) and now this. Seems like time for EFI strings and a plist only kext. I mean two out of four is better than nothing, but not everyone want to use this – especially for people new to DSTD compiling. Nice work BTW

 

Oh, and what about reboot and shutdown? Do they also work?

 

Have you tried to set the "Card Type" to "Built-in" and "Errata" to say 0xe800? I mean instead of changing the device id's...

[BlackCH]

Looks good!

I tryed it on a P5K-VM (ICH9). It goes to sleep but it wakes up right after and then USB keyboard/mouse must be re-pluged to be working again.... 10.5.7 stock kernel/stock USB kexts

[Master Chief]

Looks good!

I tryed it on a P5K-VM (ICH9). It goes to sleep but it wakes up right after and then USB keyboard/mouse must be re-pluged to be working again.... 10.5.7 stock kernel/stock USB kexts

Interesting, I mean I usually have to repair my permissions when that happens.

 

p.s. I am working on a new EFI string, and I'm almost done (will finish this after the coffee break).

[zhell]

Okay... so first we had a patched kext (IOUSBFamily.kext) and now this.

Yes; patched KEXTs do not seem to work for Intel boards (kernel panic or no change to vanilla).

Seems like time for EFI strings and a plist only kext.

EFI strings should work, but plist-only KEXT cannot help here because the device-ids are hard-coded in the source code of IOUSFamily.kext

I mean two out of four is better than nothing, but not everyone want to use this – especially for people new to DSTD compiling.

That's for sure. People should post their fixed DSDT.aml files here :-)

 

Nice work BTW

 

Oh, and what about reboot and shutdown? Do they also work?

With the DP35DP, this has always worked thanks to OpenHaltRestart.kext.

Have you tried to set the "Card Type" to "Built-in" and "Errata" to say 0xe800? I mean instead of changing the device id's...

No, I have not tried this. But from the source code, it looks like it would not work. What slice does is: he copies the code that matches on the ICH8 device-ids and replaces the device-id with that of ICH9 (among a few other things, like getting the code to actually compile).

Hence, I would say setting these properties would rather not have an effect.

[downlord]

Looks very promising. Will have a try ASA I upgrade to 10.5.7

Sleep never worked here but shutdown/restart works 100% with openhalrestart or superhai's voodoopower.

Thanks for your work and the good explanation of the phenomenon.

[zhell]

Looks good!

I tryed it on a P5K-VM (ICH9). It goes to sleep but it wakes up right after and then USB keyboard/mouse must be re-pluged to be working again.... 10.5.7 stock kernel/stock USB kexts

Hmm, this "immediate restart thing" is well known behavior for some boards; I have never experienced this myself, though.

Could be that it is fixed by enabling "Restart automatically after power failure". This option should be present in the "Energy Saver" preferences pane. Otherwise, "man pmset" should help as well.

[coconup]

indeed I solved every sleep issue related to usb by brutally deleting all the usb devices in my dsdt. now they are recognized as 'external slot' instead of 'built in' but everything works including sleep

[kulos]

Hi

 

Tried your method on my GA-EP35-DS4. It didn't solve my problem, which is failure to enter automatic sleep ("manual sleep" works fine even without your DSDT fix)

 

I reinstalled OSX before upgrading to 10.5.7. The old 10.5.6 install went into automatic sleep without issues. After installation of 10.5.7 it never worked again. Any clue??

 

I get these messages when starting up:

USBF: 0.348 AppleUSBOHCI[0x61d5000]::CheckSleepCapability - controller will be unloaded across sleep

USBF: 0.348 AppleUSBOHCI[0x61e0800]::CheckSleepCapability - controller will be unloaded across sleep

 

Only USB devices are a Logitech G5 laser mouse and a cheap USB logitech keyboard (both same as before 10.5.7)

 

 

Setup:

Install by boot-132 from retail DVD.

 

Chameleon 2RC1 (into EFI partition)

 

/Extra/ (EFI partition)

boot.plist (EFI string for 8800GTX)

smbios.plist

DSDT.aml

mkext

(AppleDecrypt.kext

Disabler.kext

AHCIPortInjector.kext

IOAHCIBlockStorageInjector.kext

ATAPortInjector.kext

OpenHaltRestart.kext)

 

 

/S/L/E/

R1000.kext

AppleHDA.kext patched

 

Some help/thoughts/ideas would be highly appreciated!

 

kulos

[Master Chief]

...EFI strings should work, but plist-only KEXT cannot help here because the device-ids are hard-coded in the source code of IOUSFamily.kext

 

I already have it working – seems like we all (you, slice me and that other guys, what's his name pcb355?) are all working on the same thing

[Master Chief]

Hi

 

Tried your method on my GA-EP35-DS4. It didn't solve my problem, which is failure to enter automatic sleep ("manual sleep" works fine even without your DSDT fix)

 

I reinstalled OSX before upgrading to 10.5.7. The old 10.5.6 install went into automatic sleep without issues. After installation of 10.5.7 it never worked again. Any clue??

 

Same here (no auto sleep) – there appears to be some sort of activity on my DVD drive, every 40 seconds or so, and that after it should sleep!

 

Edit: I just noticed that inserting a DVD makes automatic sleep work – let's go do some hunting.

[sama7896]

Any chance this can be applied to a atheros 5006 wifi card?

I can't try because i don't have (any) experience on tweaking dsdt

[kulos]

Same here (no auto sleep) – there appears to be some sort of activity on my DVD drive, every 40 seconds or so, and that after it should sleep!

 

Have the same experience!

[zhell]

indeed I solved every sleep issue related to usb by brutally deleting all the usb devices in my dsdt. now they are recognized as 'external slot' instead of 'built in' but everything works including sleep

Wow, that's an interesting approach. Great to hear it works for you. Congratulations on your out-of-the-box thinking

[Aranius]

Could hthis possibly be working with ICH9M Chipsets by Notebooks?

 

Another thing: I need an plist-only kext for my Yukon2 Ethernet, can this be solved in the dsdt too?

 

Thanks in advance,

Aranius

[zhell]

Could hthis possibly be working with ICH9M Chipsets by Notebooks?

 

Another thing: I need an plist-only kext for my Yukon2 Ethernet, can this be solved in the dsdt too?

It could work with ICH9M, but you would need to find out the addresses of the UHCI devices on your own. Further, there would no longer be a 1:1 correspondence to the ICH10-R devices because ICH9M likely has fewer UHCI devices than ICH9/-R.

 

Regarding the Yukon2 driver, I have no experience. You could certainly give it a try and report about it here. I'm sure other users of the plist-only kext would be interested to know.

[BlackCH]

Another thing: I need an plist-only kext for my Yukon2 Ethernet, can this be solved in the dsdt too?

 

I've tried inserting the ID from the yukon 8055 (to fake my 8056) on my DSDT but even though DPCIManager is reading it OK, in the Network prefpane the device is recognized as a Serial Port device (modem) instead of ethernet adapter, and it does not work. But maybe is possible to get it working with more tweaking

[zhell]

I've tried inserting the ID from the yukon 8055 (to fake my 8056) on my DSDT but even though DPCIManager is reading it OK, in the Network prefpane the device is recognized as a Serial Port device (modem) instead of ethernet adapter, and it does not work. But maybe is possible to get it working with more tweaking

Thanks for reporting. This seems rather strange to me. What do you see in IORegistryExplorer as compared to when you use the plist-only KEXT?

 

However, changing device-ids in DSDT does not keep the driver from asking the device itself for its device-id via the PCIE bus.

[BlackCH]

With the modded plist (inserted 8056 id):

 

With the DSDT:

 

As you can see in the last shot there is no kext attached to the device. This time I also removed the 8056 ID from the plist and the device wasnt seen at all on the Network prefpane.

[CPT_MAC]

Hi,

same problem no automatic sleep. But since I used slice's kext systems does wake up by USB keyboard. Good improvement!

 

I am not an expert, but during boot in -v mode I can see a lot of, missing... not found...can't read....and so on

 

In my case, the CPU Intel 7200 is not recogniced correct the ram speed not correct as well.

 

Modelname: Mac Serialnumber: SOMESRLNMBR

 

Something like Intel cpupowermanagment...... not found. If it helps, I can take pictures during boot and post.

 

One more thing, my timemachine was not working. After installing IOnetworking fix, time machine works for backup, but when I open the backup by the timemachine icon in dock, one screen goes black and on the main screen I have two open windows in finder showing the desktop.

 

Also my logitch quickcam 4000pro does not work. It worked before on other hackintosh. Anyhow for testing I disconnected all USB devices except the wireless USB Keyboard.

 

just some thoughts

10_5_7_loaded_kext.rtf

[Master Chief]

I seem to be using the same network adapter (built-in) but without the "AAPL,slot-name", "acpi-device" and "acpi-path" properties showing up in the IORegistryExplorer, and thus now I wonder what you did to get these?!? Are these part of your modified Info.plist?

[BlackCH]

I seem to be using the same network adapter (built-in) but without the "AAPL,slot-name", "acpi-device" and "acpi-path" properties showing up in the IORegistryExplorer, and thus now I wonder what you did to get these?!? Are these part of your modified Info.plist?

 

Those parameters are injected via custom DSDT table. Also all devices names has been modified to match a macpro DSDT.

Furthermore I have injected the necessary data for my 7600GT to work OOTB without NVkush, NVInject, or any other extra kext.

DSDT has a lot of posibilities

 

Nevertheless device ID injection for this network adapter (or any) doesnt seem to work.

[kizwan]

Thanks for your interest.

Are you sure the problem of your board is related to USB? ICH7 is supported by Apple's drivers. It could be that your chip has different device-ids, though. To check this, just verify that the "Errata" value is 0x0 in IORegistryExplorer, which indicates that the chip was not recognized.

The device-ids that Apple uses for ICH7 are 27C8-27CC. For ICH8, the device-ids are 2830-2835.

You're right, my ICH7 was supported; device-ids 27C8-27CB (UHCI - Errata 0xe800) & 27CC (EHCI - Errata 0x5800). It only able to hibernate (mode 5) not sleep because USB will cause it to wake immediately.

 

There is one USB device not listed or recognized in OS X. Attached to it is built-in bluetooth device & I unable to turn it on since the button handle it not functioning in OS X.

 

kizwan