Jump to content

Patched AppleUSBXHCI from OS 10.8.2


Zenith432
 Share

146 posts in this topic

Recommended Posts

I'm patched AppleUSBXHCI.kext from OS 10.8.2 to let it work with any USB 3.0 xhci chipset.

 

The kext should be placed in

/System/Library/Extensions/IOUSBFamily.kext/Contents/Plugins

 

and kernelcache should be rebuilt.

 

64-bit only.

 

I've tested it with the following xhci controllers:

  1. Renesas uPD720200A - works! Including checked that both high-speed and super-speed drives work at their maximum speeds.
     
  2. VMware virtual xhci controller - doesn't work. Hangs during boot trying to connect to the virtual USB hid devices on the controller.

Link To File

 

Edit [1/28/2013]: New patches for interrupt problems.

 

Edit [1/24/2013]: Replaced 4th patch with a different one. Removed disassembly (hex diff still present.) Moved discussion of the patches to this post.

 

Edit [12/27/2012]: Added 5th patch, moved file offsite.

 

Patch made (Hex Diff)

1363c1363
< 0005520: 755b 498b 0648 8d35 82fb 0000 4c89 f7ff u[i..H.5....L...
---
> 0005520: eb5b 498b 0648 8d35 82fb 0000 4c89 f7ff .[i..H.5....L...
1379c1379
< 0005620: e066 3d00 010f 82ec 0b00 0049 8b86 c002 .f=........I....
---
> 0005620: e066 3d00 000f 82ec 0b00 0049 8b86 c002 .f=........I....
1751c1751
< 0006d60: 8149 0800 0040 0041 81e4 ffff 0f00 4409 .I...@.A......D.
---
> 0006d60: 8149 0800 0000 0041 81e4 ffff 0f00 4409 .I.....A......D.
1999c1999
< 0007ce0: 410f 4ecf 41c7 4424 0800 0040 0080 bd67 A.N.A.D$...@...g
---
> 0007ce0: 410f 4ecf 41c7 4424 0800 0000 0080 bd67 A.N.A.D$.......g
2046c2046
< 0007fd0: 0040 0041 8b46 0c83 e001 3501 1c00 0080 .@.A.F....5.....
---
> 0007fd0: 0000 0041 8b46 0c83 e001 3501 1c00 0080 ...A.F....5.....
4098c4098
< 0010010: c800 0000 01c6 837f 3a02 0000 488b bbe8 ........:...H...
---
> 0010010: c800 0000 00c6 837f 3a02 0000 488b bbe8 ........:...H...
4102c4102
< 0010050: 0200 0048 85c0 7526 488b bbe8 0100 0048 ...H..u&H......H
---
> 0010050: 0200 0048 85c0 eb26 488b bbe8 0100 0048 ...H...&H......H

 

Description of patches and what they're good for

  1. (5520) Eliminates a check that xhci chip is either Intel Panther Point or Fresco Logic. If you have either of these, use original unpatched AppleUSBXHCI. This patch has the exact same effect as adding AllowAnyXHCI=true in Info.plist. If you feel more comfortable with Info.plist, go ahead.
  2. (5624) Eliminates a check that xhci version >= 1.0. If your xhci version is already >= 1.0, you don't need this. For uPD720200, it's reported as 0.96 which is why I added it.
  3. (6d65, 7ceb, 7fd1) Set of three patches to make the driver use a single interrupter to resolve problems with use of MSI or pin interrupts.
  4. (10014) This patch disables the sleep code that leaves the controller in non-working state after wake. Instead, IOUSBFamily will turn the controller off and restart after wake. Any connected drives will disconnect during sleep, but will be reattached after wake and return to function. Use this patch only if wake after sleep leaves your ports in unusable state.
  5. (10056) I added this to enable PCI power management in cases where the xhci controller is not listed in DSDT. For boards in which xhci is in DSDT, this isn't needed.

Edited by Zenith432
  • Like 10
Link to comment
Share on other sites

Hi,

Do you think it could be compatible with Snow Leopard 10.6.8 ? Actually there is no xHCI plugin inside the IOUSBfamily.kext

 

I struggle to make fully functionnal the xHCI (ASmedia AS1042 USB 3.0 ports (X2) on a Maximus V Formula

 

The best i managed to do so far is with PXHCD, but they are recognized work as 2.0 ports.

Link to comment
Share on other sites

Do you think it could be compatible with Snow Leopard 10.6.8 ?
There's nothing to stop you from trying...

AppleUSBXHCI inherits from IOUSBControllerV3, which exists in IOUSBFamily for OS 10.6.8. So you can try putting it there see if it works. Just make sure you have means to remove it if the system fails to boot, as it gets loaded in single-user mode too. If you can't remove a kext off an unbootable HFS partition, don't try it (!).

 

Also, it's 64-bit only. OS 10.6.8 can boot both 32 or 64-bit. So for sure it won't work in 32-bit

[Come to think of it, if system becomes unbootable in 64-bit mode, you can boot 32-bit mode to remove the kext!]

 

Other issues, the 10.6.8 may not be able to load the 64-bit kext either, as Apple added some new load commands in 10.8.

 

Other issues, IOUSBFamily support classes have changed between 10.6 and 10.8, so the base classes may not use AppleUSBXHCI from 10.8 the way to it expects to be used.

 

So to summarize - not likely - but try it if you know how to recover.

 

I struggle to make fully functionnal the xHCI (ASmedia AS1042 USB 3.0 ports (X2) on a Maximus V Formula

 

The best i managed to do so far is with PXHCD, but they are recognized as 2.0 ports.

Like I said in the other thread, that's all PXHCD can do :) Only other alternative is to write a XHCI driver from scratch. Apple doesn't release sources for AppleUSBXHCI. I believe PXHCD is based on AppleUSBEHCI (for which sources are public), but LaCie changed the underlying chip-driving code from EHCI to XHCI.
Link to comment
Share on other sites

For the record, I tested in my Vostro 3550 that has Texas Instruments TUSB7320/40 - It works until the system goes to sleep. The ports failed after wake up, then my hack won't sleep anymore.

 

Thanks at least the patch worked.

  • Like 1
Link to comment
Share on other sites

For the record, I tested in my Vostro 3550 that has Texas Instruments TUSB7320/40 - It works until the system goes to sleep. The ports failed after wake up, then my hack won't sleep anymore.

Ok. I haven't gotten around to the sleep code in the driver yet. If it doesn't work, the only recourse may be to patch it so it doesn't put controller or devices to sleep. Hopefully I'll get around to it.
Link to comment
Share on other sites

@Zenith432

With the patched kext, my system info has both Hi-speed and Superspeed for the same USB 3.0 chipset.

Confirmed works on uPD720200, but uPD720202, which is xHCI 1.0, still can't be used.

My system info has two Hi-speed for uPD720200 & uPD720202, and two Superspeed for PD720200 & uPD720202.

 

 

For uPD720200, works like USB 3.0, no more problem about speed stacks at 40mb/s at the beginning (which PXHCD.kext has).

 

But here is the problem:

First connection: Always works well. The USB 3.0 drive is showed connected under Superspeed in System info.

Second, third, forth.... connection: Sometimes speed stacks at 25~35mb/s and showed connected under Hi-speed in System info.

 

Images:

 

nCwdU.png

 

 

69SUH.png

 

 

OlEhN.jpg

 

 

yJKcG.png

 

 

 

These are the errors in kernel log:

12/24/12 12:40:38.000 AM kernel[0]: USBF: 522.370 The IOUSBFamily did not receive enough extra current for the SuperSpeed device (Backup+ Desk) at 0x3c900000, asked for 400mA but got 0 mA
12/24/12 12:40:38.000 AM kernel[0]: disk6s3: alignment error.

Link to comment
Share on other sites

For the record, I tested in my Vostro 3550 that has Texas Instruments TUSB7320/40 - It works until the system goes to sleep. The ports failed after wake up, then my hack won't sleep anymore.

Could you help me out - run a Terminal window, and type the command 'ioreg -xrc AppleUSBXHCI'. There should be a property "Card Type" which is either "Built-in" or "PCI". Could you tell me what you have?

 

I've gotten this to be both values.

- When it's Built-in, I get the same behaviour you describe, which is that after wake from sleep, drive is disconnected and ports become unusable. However, I can sleep again. (Ports remain unusable until reboot.)

- When it's PCI, after wake from sleep I get message that the drive was disconnected, but it reconnects again and the port is reusable. I can sleep again.

 

@shiecldk

I patched with a hex editor, not otool. Here's a hexdump of the diff [see post #1 for hexdump]

 

Don't know why the 720202 doesn't work. May be it needs message-signalled interrupts. It's the 3rd patch (at 5701), so you can try revert that. But if you, do the 720200 will stop working... (at least it does for me.)

 

I noticed a superspeed device sometimes randomly connects at high-speed as well. I'm looking at the power handling in the driver - so maybe I'll find something.

  • Like 1
Link to comment
Share on other sites

Could you help me out - run a Terminal window, and type the command 'ioreg -xrc AppleUSBXHCI'. There should be a property "Card Type" which is either "Built-in" or "PCI". Could you tell me what you have?

 

I think I got only 'built-in'. Here is the ioreg if it helped;

 

 

+-o AppleUSBXHCI <class AppleUSBXHCI, id 0x10000024a, registered, matched, active, busy 0 (277 ms), retain 11>
| {
| "IOClass" = "AppleUSBXHCI"
| "CFBundleIdentifier" = "com.apple.driver.AppleUSBXHCI"
| "IOProviderClass" = "IOPCIDevice"
| "Card Type" = "Built-in"
| "IOPCIClassMatch" = "0x0c033000"
| "IOUserClientClass" = "IOUSBControllerUserClient"
| "IOPowerManagement" = {"ChildrenPowerState"=0x3,"DevicePowerState"=0x3,"CurrentPowerState"=0x3,"MaxPowerState"=0x4,"DriverPowerState"=0x3}
| "IOProbeScore" = 0x0
| "IOPCITunnelCompatible" = Yes
| "this" = 0xffffff80f7f86000
| "IOMatchCategory" = "IODefaultMatchCategory"
| "ISTKeepAway" = 0x1
| }
|
+-o XHCI Root Hub SS Simulation@0 <class IOUSBRootHubDevice, id 0x100000250, registered, matched, active, busy 0 (2 ms), retain 9>
| +-o AppleUSBHub <class AppleUSBHub, id 0x100000252, registered, matched, active, busy 0 (0 ms), retain 7>
| +-o IOUSBInterface@0 <class IOUSBInterface, id 0x100000254, !registered, !matched, active, busy 0, retain 7>
+-o XHCI Root Hub USB 2.0 Simulation@0 <class IOUSBRootHubDevice, id 0x100000255, registered, matched, active, busy 0 (2 ms), retain 9>
+-o AppleUSBHub <class AppleUSBHub, id 0x100000257, registered, matched, active, busy 0 (0 ms), retain 7>
+-o IOUSBInterface@0 <class IOUSBInterface, id 0x100000259, !registered, !matched, active, busy 0, retain 7>

 

Thanks

  • Like 1
Link to comment
Share on other sites

I patched with a hex editor, not otool.

Can we compile the result which decompiled from otool with some tools?

I don't know how to convert them into hex codes.

 

I was using an IOUSBFamily.kext from 10.8.2 Build 12C3006. I want to try to patch it myself.

 

According to your method, these should be the patch for the AppleUSBXHCI.kext in Build 12C3006:

< 000000000000610a jne 0x00006167
---
> 000000000000610a jmp 0x00006167

< 000000000000621f cmpw $0x0100,%ax
---
> 000000000000621f cmpw $0x0000,%ax

< 00000000000062fb je 0x0000629e
---
> 00000000000062fb jmp 0x0000629e

< 000000000000f68c je 0x0000f6ce
---
> 000000000000f68c jmp 0x0000f6ce

 

The attachment are the USB drivers in Build 12C3006:

Build12C3006 USB Driver.zip

 

 

Don't know why the 720202 doesn't work. May be it needs message-signalled interrupts. It's the 3rd patch (at 5701), so you can try revert that. But if you, do the 720200 will stop working... (at least it does for me.)

I've tried removing the third patch, but uPD720202 still didn't work. (I've even tried to remove the other patche one by one, but still no luck, of course. :P)

Maybe there still needs some other hack the get the chipset work.

 

 

 

PS. I found out that Parallels Desktop can't boot any guest system after applying the patches.

Link to comment
Share on other sites

For the record, I tested in my Vostro 3550 that has Texas Instruments TUSB7320/40 - It works until the system goes to sleep. The ports failed after wake up, then my hack won't sleep anymore.

This happens to me with PXHCD as well. After wake from sleep, existing connected port becomes unusable. It doesn't show the device as disconnected, but hangs when trying to access the drive. When connecting new drives, they work.
Link to comment
Share on other sites

This happens to me with PXHCD as well. After wake from sleep, existing connected port becomes unusable. It doesn't show the device as disconnected, but hangs when trying to access the drive. When connecting new drives, they work.

Hi,I`ve tried patched kext on my asrock z68 pro3 with Ethron EJ168 usb 3.0 controller and experienced the same problems.I have more success with IOUSBFamily.kext extracted from 10.8.3 beta and edited info.plist in AppleUSBXHCI.kext ,as it was suggested in the other forum.

Add into info.plist: <key>AllowAnyXHCI</key>

<true/>

The only problem I can see is this message when system wakes

post-657244-0-98134500-1356455723_thumb.png

  • Like 2
Link to comment
Share on other sites

This happens to me with PXHCD as well. After wake from sleep, existing connected port becomes unusable. It doesn't show the device as disconnected, but hangs when trying to access the drive. When connecting new drives, they work.

IIRC, same was happened in my system with PXHCD. Meanwhile, CalDigit gives disk ejection error but continues working after 10-15 seconds.

 

I have more success with IOUSBFamily.kext extracted from 10.8.3 beta

Hi, would you mind sharing the original kext from 10.8.3. I would give it a test. Not worth to get the whole image since it's beta :)

Link to comment
Share on other sites

Hi,here you are

Could you upload IOUSBMassStorageClass.kext? I guess we need the match kext to get IOUSBFamily.kext work, don't we?

 

 

I applied oolll's patch in post #12 to the AppleUSBXHCI.kext from 10.8.2 Build 12C3006 and 10.8.3 Build 12D29.

 

Then it can't boot into OS X anymore but show this:

dkf2N.jpg

 

There is a line in the image said "could not get chip to halt within 100 ms."

 

However, I don't have such a problem when applying the "AllowAnyXHCI" patch to the AppleUSBXHCI.kext from original 10.8.2.

Link to comment
Share on other sites

Okay, so I figured out how Zenith432 patched AppleUSBXHCI.kext in hex code:

75 5B-->EB 5B
66 3D 00 01-->66 3D 00 00
74 A1-->EB A1
F6 00 02 74 40-->F6 00 02 EB 40 (This one is actually "74 40-->EB 40", but you'll find two "74 40".)

Here is the patched kext from 10.8.3 Build 12D44.

Don't know why my system became very LAG when using this patched kext. Could someone give it a try?

Link to comment
Share on other sites

Okay, so I figured out how Zenith432 patched AppleUSBXHCI.kext in hex code:

 

75 5B-->EB 5B

66 3D 00 01-->66 3D 00 00

74 A1-->EB A1

F6 00 02 74 40-->F6 00 02 EB 40 (This one is actually "74 40-->EB 40", but you'll find two "74 40".)

 

 

Here is the patched kext from 10.8.3 Build 12D44.

 

 

 

Don't know why my system became very LAG when using this patched kext. Could someone give it a try?

Hi,with that kext I have problems described in post 11.

Link to comment
Share on other sites

Hi,with that kext I have problems described in post 11.

 

Maybe you could try this DSDT to fix the problem: (add it under your USB3.0 device)

 

Method (_DSM, 4, NotSerialized)
			 {
				 Store (Package (0x15)
					 {
						 "device-id",
						 Buffer (0x04)
						 {
								 0x31, 0x1E, 0x00, 0x00
						 },
						 "vendor-id",
						 Buffer (0x04)
						 {
								 0x86, 0x80, 0x00, 0x00
						 },
						 "built-in",
						 Buffer (One)
						 {
								 0x00
						 },
						 "AAPL,clock-id",
						 Buffer (One)
						 {
								 0x01
						 },
						 "device_type",
						 Buffer (0x05)
						 {
							 "XHC"
						 },
						 "AAPL,current-available",
						 0x0834,
						 "AAPL,current-extra",
						 0x0898,
						 "AAPL,current-extra-in-sleep",
						 0x0640,
						 "AAPL,device-internal",
						 Zero,
						 "AAPL,max-port-current-in-sleep",
						 0x0834,
						 Buffer (One)
						 {
								 0x00
						 }
					 }, Local0)
				 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				 Return (Local0)
			 }

 

 

 

@Zenith432

Sorry, I think uPD720202 might be able to work with your patched kext. I just found out my card is broken. (Don't even work under Windows 8.)

 

But I don't know why your third patch makes my CPU performance drop in 10.8.3 Build 12D44. (Geekbench score: 11872-->5779)

Link to comment
Share on other sites

But I don't know why your third patch makes my CPU performance drop in 10.8.3 Build 12D44. (Geekbench score: 11872-->5779)

First, note I edited original post and added 5th patch.

[Discussion of the patches moved to post #1]

Last but not least - Wake from sleep still does not work. The ports are dead after wake. There is a considerable amount of sleep/wake oriented code in the driver and it's going to take some time to sort it out. Work in progress.

  • Like 1
Link to comment
Share on other sites

I have Panther USB host controller for USB 3 by tried either adding AllowAnyXhci or your patched filed without success. With the unpatched kext my USB 3.0 are detected as Superspeed USB 3.0 in system profiler, but as soon as i plug anything, the system freezes.

My lappy is an Asus G75VW-BH71-CB. Any ideas ?

Link to comment
Share on other sites

Update

 

I figured out why the wake code is leaving the ports unusable. AppleUSBXHCI uses nonconforming wake code that violates the xhci spec. It restores the command-ring address register after performing chip-internal restore. The spec says to restore all CPU-accessible registers first. Evidently, on Intel Panther Point this doesn't make any difference.

Anyhow, the misordered code leaves the chip in an error state. It then goes into incomplete recovery code, which never clears the error condition. So the chip remains in an error state, and nothing else works on it until reset.

Unfortunately, fixing this requires reordering a few lines of source code. Doing it as a binary patch, while possible, is a lot of work. Since this work will be obsolete as soon as 10.8.3 comes out, and it's unreasonable to keep up such a patch - I'm dropping it.

 

Update [1/24/2013]: Upon further investigation, the reordered code is not the reason chip-internal restore is failing. Apparently, some xhci chips simply don't support internal-restore, and will fail if this feature is used. The driver is expected to restart the chip, but the incomplete recovery code in AppleUSBXHCI from an SRE (save-restore error) leaves the chip in an unusable state. In the linux driver, the recovery code from SRE is complete, so it works.

 

I've also figured out why MSI interrupts don't always work. Again, AppleUSBXHCI uses noncomforming code. The spec allows for multiple interrupters. If pin interrupts are used, all events are channeled to one vector (since PCI only allows one pin interrupt per function.) If MSI (or MSI-X) is used, multiple interrupt vectors are allowed. The xhci spec says to connect each interrupter to a distinct MSI vector. AppleUSBXHCI enables 2 interrupters on the chip. However, Apple's PCI messaged interrupt controller only allows one MSI vector per PCI device (this is hardwired!). This is unlike Windows or Linux that do allow multiple MSI vectors. So AppleUSBXHCI tries to connect 2 interrupters to one enabled MSI vector. This is non-conforming. Again, on Intel Panther Point it just happens to work. Evidently it channels both interrupters to the single vector.

 

Sorry I couldn't bring better news.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Okay, Zenith432's 5th patched USBXHCI.kext worked perfectly on my MBP 2010 until I rebuild the system to use Fusion drive..... Now I got this error on startup and no drive can be recognize:

 

 

USBF: 43.130 AppleUSBHub[0xffffff803d0a9c00]::ConfigureHub(hub @ 0x7c000000) could not get hub descriptor (0xe00002c2)

 

USBF: 43.130 AppleUSBHub[0xffffff803d0a9c00]::ConfigureHubDriver Aborting startup for hub @ 0x7c000000, error 0xe00002c2 (invalid argument)

 

Any thought on this? Thank you guys :)

Link to comment
Share on other sites

Patch 3 for MSI does cut the cpu in half for whatever reason. I have an mbp 17" with expresscard, and tried with nec 720200, 720202a. Speed very similar, and faster than any of the third party kexts, but no sleep. No sleep is a deal breaker for me.

 

Also patched doesn't work on fresco fl1000, and unpatched doesn't either (native kext supposed to work with fl1100 and fl1009). System Info shows the high speed and super speed buses, and eventually shows usb 3 to sata bridges plugged in, but doesn't mount the drives?

 

Best solution I've found - allowanyxhci-true in info.plist of native kext, plus unlocked pxhcd 1.0.10. All three cards work with this combo, and it says they're running under pxhcd but they have the higher speeds of the patched apple kext, and sleep works.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...