Jump to content

Patched AppleUSBXHCI from OS 10.8.2


Zenith432
 Share

146 posts in this topic

Recommended Posts

I'm going to look at the 10.8.3 binary and see if the patches are applicable. Update: It looks very different to me.
Here.

1413c1413
< 0005840: 0200 0048 85c0 7526 488b bbe8 0100 0048 ...H..u&H......H
---
> 0005840: 0200 0048 85c0 eb26 488b bbe8 0100 0048 ...H...&H......H
3686c3686
< 000e650: 755b 498b 0748 8d35 d082 0000 4c89 ffff u[i..H.5....L...
---
> 000e650: eb5b 498b 0748 8d35 d082 0000 4c89 ffff .[i..H.5....L...
3703c3703
< 000e760: bdc7 0200 e066 3d00 010f 8255 0100 0049 .....f=....U...I
---
> 000e760: bdc7 0200 e066 3d00 000f 8255 0100 0049 .....f=....U...I
4099c4099
< 0010020: ffff fd89 0181 4908 0000 4000 4181 e4ff ......I...@.A...
---
> 0010020: ffff fd89 0181 4908 0000 0000 4181 e4ff ......I.....A...
4347c4347
< 0010fa0: 0800 0040 0080 bd67 ffff ff00 4c8b bd50 ...@...g....L..P
---
> 0010fa0: 0800 0000 0080 bd67 ffff ff00 4c8b bd50 .......g....L..P
4393c4393
< 0011280: 0000 0041 c746 0800 0040 0041 8b46 0c83 ...A.F...@.A.F..
---
> 0011280: 0000 0041 c746 0800 0000 0041 8b46 0c83 ...A.F.....A.F..

  1. 5846 - formerly at 10056
     
  2. e650 - formerly at 5520
     
  3. e768 - formerly at 5624
     
  4. 1002a, 10fa3, 11289 - formerly 6d65, 7ceb, 7fd1

I did not apply the patch formerly at 10014 (that makes it always use reset-on-resume), but if you want that one, change the byte at 5804 from 1 to 0.

 

Edit: Oddly, in 10.8.3, AppleUSBXHCI agrees to load on all Asmedia chips without "AllowAnyXHCI"/patch-at-e650, even though ASM 1042 doesn't work with it... So did Apple test asmedia chips or not???

Correction: It won't run on the ASM 1042, because that chip reports itself as v0.96 - which is blocked. Maybe they tested it with the newer asmedia 105x chip.

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

  • 2 weeks later...

Thank you. This works on Z68AP-D3 Etron EJ128 USB 3.0 port. It was mentioned in earlier post and I can confirm that.

However I notice everthing woke and works after sleep, but when I put the system to sleep second time and woke it up, it seemed it was waking up then it hung at deathe of spinning beach ball, however the mouse is working...... It wasn't doing that with 10.8.2 and didn't have this kext. had PXHCD.

Link to comment
Share on other sites

Yes, read post 76

 

I mean, has anyone patched the 10.8.3 kext and released it. If it works at least with the u720200(a) chipsets, at least it'd be worth trying out.

 

Also, since I haven't seen anyone SPECIFICALLY mention it......has anyone tried using a usb 3.0 hub connected to their USB 3.0 cards to see if you can plug in more than 1 external drive ? That's currently a limitation of the patched LaCie drivers, while they can see a USB 3.0 hub now, they won't enumerate drives connected to them.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Vostro 3560, all USB 3 ports

 

I can boot from ##### USB & during the setup external mouse/keyboard works.

 

But once ML is installed & reboots to setup, I can no longer get any mouse keyboard working (not internal, not external)

 

Error relates to AppleUSBXHCI

 

https://imageshack.us/scaled/large/826/20130502122948.jpg

 

I copied the patched kext to USB /extra folder, but seems to make no difference

 

Help appreciated

 

sebus

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

@Zenith432

I've gave OS X 10.9 DP1 a try and decompiled its AppleUSBXHCI with otool. I found out the AppleUSBXHCI's structure changed a lot.
I could still find each patch's location except the one checking whether xhci version >= 1.0. Could you give me a hand to find it?

Here is my current progress:

USB3.0 controllers Intel & Fresco Logic check:

0000000000015757 jne 0x157a4
75 4B 49 8B 07
--->
EB 4B 49 8B 07

This one is actually 75 4B--->EB 4B, but there are more than one 75 4B.

XHCI Version check:
(Can't find its location yet.)

Three MSI or pin interrupts patches:

00000000000180f0 orl $4194304, 8(%rbx)
81 4B 08 00 00 40 00
--->
81 4B 08 00 00 00 00

0000000000019a99 movl $4194304, 8(%r13)
41 C7 45 08 00 00 40 00
--->
41 C7 45 08 00 00 00 00

0000000000019e10 movl $4194304, 8(%r15)
41 C7 47 08 00 00 40 00
--->
41 C7 47 08 00 00 00 00

Sleep code patch:

0000000000007509 movb $1, 200(%rax)
C6 80 C8 00 00 00 01
--->
C6 80 C8 00 00 00 00

PCI power management:

0000000000007571 jne 0x75c0
75 4D 48 8B BB E8 01 00 00
--->
EB 4D 48 8B BB E8 01 00 00

This one is actually 75 4D--->EB 4D, but there are more than one 75 4D.



The attachment contains 10.9 DP1's IOUSBFamily.kext, AppleUSBXHCI decompiled text from otool and my current patched IOUSBFamily with all above patches:
10.9 DP1 AppleUSBXHCI.zip

 

PS. Please notice that XHCI 0.96 controllers, such as: µPD720200, ASM1042 and VL800, are not able to work with this kext currently until the XHCI Version Check Patch is done.

Link to comment
Share on other sites

@Zenith432

 

I've gave OS X 10.9 DP1 a try and decompiled its AppleUSBXHCI with otool. I found out the AppleUSBXHCI's structure changed a lot.

I could still found each patch's location except the one checking whether xhci version >= 1.0. Could you give me a hand to find it?

 

Here is my current progress:

 

USB3.0 controllers Intel & Fresco Logic check:

0000000000015757 jne 0x157a4
75 4B 49 8B 07
--->
EB 4B 49 8B 07

This one is actually 75 4B--->EB 4B, but there are more than one 75 4B.

 

XHCI Version check:

(Can't find its location yet.)

 

Three MSI or pin interrupts patches:

00000000000180f0 orl $4194304, 8(%rbx)
81 4B 08 00 00 40 00
--->
81 4B 08 00 00 00 00

0000000000019a99 movl $4194304, 8(%r13)
41 C7 45 08 00 00 40 00
--->
41 C7 45 08 00 00 00 00

0000000000019e10 movl $4194304, 8(%r15)
41 C7 47 08 00 00 40 00
--->
41 C7 47 08 00 00 00 00

 

Sleep code patch:

0000000000007509 movb $1, 200(%rax)
C6 80 C8 00 00 00 01
--->
C6 80 C8 00 00 00 00

 

PCI power management:

0000000000007571 jne 0x75c0
75 4D 48 8B BB E8 01 00 00
--->
EB 4D 48 8B BB E8 01 00 00

This one is actually 75 4D --->EB 4D, but there are more than one 75 4D.

 

 

The attachment contains 10.9 DP1's IOUSBFamily.kext, AppleUSBXHCI decompiled text from otool and my current patched IOUSBFamily with all above patches:

attachicon.gif10.9 DP1 AppleUSBXHCI.zip

Hi!

 

This kext work on my system 10.9 DP1 but only when start OSX in -f switch :( If pre linked start, kext no loaded, and no USB3 ports :(

Link to comment
Share on other sites

Hi! This kext work on my system 10.9 DP1 but only when start OSX in -f switch :( If pre linked start, kext no loaded, and no USB3 ports :(

Because you didn't rebuild kernelcache and repair permissions after installing the kext, did you?

Go download kextwizard to rebuild kernelcache and repair permissions.

Link to comment
Share on other sites

Hello, I installed the IOUSBFamily and GenericUSBXHCI and still have still: waiting for root device.

I think you can't use the AppleUSBXHCI patch and GenericUSBXHCI at the same time. But I'm not sure...

Try to eliminate GenericUSBXHCI when applying the patched IOUSBFamily or ask Zenith432 when he's back. :)

Link to comment
Share on other sites

Because you didn't rebuild kernelcache and repair permissions after installing the kext, did you?

Go download kextwizard to rebuild kernelcache and repair permissions.

Hi!

 

Permission and prelink OK! No error message, but USB3 works only when -f boot.... When i not use -f and pre linked boot works, no USB3 :( (Sorry my bad english...)

Link to comment
Share on other sites

I think you can't use the AppleUSBXHCI patch and GenericUSBXHCI at the same time. But I'm not sure...

Try to eliminate GenericUSBXHCI when applying the patched IOUSBFamily or ask Zenith432 when he's back. :)

 
Hello, deleted the GenericUSBXHCI and let the IOUSBFamily in S/L/E.
Go up the installation with -v -f but still continues still waiting for root device.
Link to comment
Share on other sites

Hello Zenith432! I installed maverick 10.9 DP 1 with kext IOUSBFamily from 10.8.4 12E55, this solved my problem with the still waiting for root device.

Now Maverick recognize my mouse usb 2.0 microsoft. It also recognizes my 1TB external hd usb 3.0 but does not recognize my USB 2.0 flash driver and other HD usb 2.0. What can it be?

Can you help me? Thanks in advanced!

Link to comment
Share on other sites

  • 2 weeks later...

I've resolved the Sleep issue on my system. Discovered that it was due to an error in the DSDT, not the xHC.

 

I've fixed the DSDT, eliminated the bottom two patches in the patch-list in post #1, and now sleep works, including being able to wake the system with a USB keyboard connected to the xHC (a.k.a. PME).

 

Hardware: Intel motherboard with H67 chipset, Renesas uPD720200F1 with most recent firmware (3.0.3.4).

  • First, just to set the record straight, the uPD720200 does support chip-internal restore, contrary to what I said in post #23. This is a mandatory feature in the xHC spec.
  • Topology-wise, Intel Panther-Point is integrated into the south-bridge (PCH), so it is connected directly to the PCIe host-bridge (root complex.) All other xHC chips, whether in a separate chip on the motherboard, or PCIe expansion card, are connected behind a PCIe root port (PCI2PCI bridge.) In other words, have one more-level of indirection in the data path to RAM/processor core.
  • The board's DSDT has a method called IOKS that wrecks power-management. It attempts to access the PS/2 keyboard and mouse, and goes into an infinite loop, because H67 doesn't have a PS/2 controller (!).
  • DSDT has a method call _PTS ("prepare to sleep") that is executed by AppleACPIPlatformExpert.kext before the system goes to sleep or shuts down.
  • _PTS calls IOKS to do something with PS/2 keyboard/mouse, and hangs.
  • AppleACPIPlatformExpert has a watchdog-timer on this ACPI method, and times out after 75 seconds, decides _PTS is in an infinite loop, aborts it, and proceeds to complete the sleep/shutdown sequence anyway.
  • In _PTS, after the code that calls IOKS, there is code to prepare the PCIe root ports for PME.
  • As a result of the abort of _PTS, the PCIe root ports are not properly prepared for sleep.
  • Since PME is not enabled on the root port, the xHC chip connected to the port does not receive Aux power during sleep. This causes the chip to lose all context, and come back from sleep as if it was just turned on from a power-off state.
So the result of the problem with IOKS was
  • Sleep and shutdown process would take 75 seconds...
  • PCIe devices on root ports were completely shut down during sleep and could not recover any state existing before the sleep.
It took quite a bit of work to figure this out...

 

P.S. The resolution was to eliminate IOKS and all calls to IOKS in the DSDT. I also removed the nonexistent PS/2 devices, along with non-existent sleep-button, floppy controller and LPT port.

 

You must have an Intel DH6xxx board.  I figured this IOKS thing Oct, 2012 while hacking my DH67GD, so I got a chuckle out of your description of the Intel DSDT talking to PS/2 ports that don't exist :-)

 

See: https://github.com/RehabMan/Intel-DH67XX-DSDT-Patch

Link to comment
Share on other sites

  • 2 weeks later...

I just updated to 10.8.4. And USB3.0 ports still work perfectly with these patches. (Haven't tested on sleeping because my Clover not allow me to sleep.)

The transfer speed seems to be a bit improved in 10.8.4. :thumbsup_anim:

 

Here is a patched 10.8.4 AppleUSBXHCI.kext if someone would like to give it a try.

attachicon.gif10.8.4_Patched AppleUSBXHCI.kext.zip

Try on my Zenbook UX31A, the USB Ethernet not work (worked great with GenericXHCI).

Link to comment
Share on other sites

 Share

×
×
  • Create New...