Jump to content

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


  • Please log in to reply
365 replies to this topic

#1
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male
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:
Attached File  IORegistryExplorer_UHCI.png   149.3KB   7980 downloads

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.
Attached File  sleep_wake.php.zip   1.51KB   1051 downloads

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.

#2
kizwan

kizwan

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 1,422 posts
Very interesting. :wacko: 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

#3
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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.

#4
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male
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...

#5
BlackCH

BlackCH

    InsanelyMac Deity

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,617 posts
  • Gender:Male
  • Location:BCN
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

#6
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

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).

#7
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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 :D

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.

#8
downlord

downlord

    InsanelyMac Greek

  • Members
  • PipPipPip
  • 143 posts
  • Gender:Male
  • Location:Lisboa
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.

#9
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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.

#10
coconup

coconup

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 190 posts
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 :D

#11
kulos

kulos

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
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

#12
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

...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

#13
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

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.

#14
sama7896

sama7896

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 440 posts
  • Gender:Male
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

#15
kulos

kulos

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts

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!

#16
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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 :D

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

#17
Aranius

Aranius

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 143 posts
  • Location:Germany
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

#18
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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.

#19
BlackCH

BlackCH

    InsanelyMac Deity

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,617 posts
  • Gender:Male
  • Location:BCN

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

#20
zhell

zhell

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 125 posts
  • Gender:Male

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.





3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy