(GUIDE) 10.11 full speed USB (series 8/9) keeping vanilla SLE

[randomusername00]

May not, but still worth to read the whole guide carefully, skipping things does not help.

Personally i'm not seeing this "revelation" of which you speak, but glad it works well for you. 

 

I totally see why you're skeptical on the kext patching - but even so, I think the technique has merit at least as a way for people to do all the port discovery work on El Capitan. No need for multiple installs, or hoping to get things 100% right on Yosemite before the jump happens, or a secondary/primary Windows install lurking around.

 

Long-term, I actually envision a model where someone could just set things up this way, launch a tool, and plug/unplug a device from each port - the tool would then automatically craft a proper port injection kext.

 

Again, I am seeing proper behavior with the Clover patch (+ ID injection kext), but even if it turns out I am missing something, the technique is at least good enough as a bootstrapping mechanism.

Can anyone help me use colver's kext patch to replace 0x8c318086 with 0x8cb18086. Tried with data and plist patching, but i guess i missed something. Dummy kext works fine for the device injection.

 

TIA

 

That is not what the Clover kext patch is for. The Clover kext patch is for removing the 15 port limit. Arix98 posted a Clover config.plist change that you should be able to copy&paste verbatim. That will remove the port limit for you.

 

Now, if you have the same Series9 XHCI controller that I do, you will still need a mini-injector whose sole purpose is to tell OS X which driver to use for your controller. For that purpose, you should take the injection kexts posted in this thread, and just replace the Info.plist with the one I posted, then install the kext as you usually would (in Clover or in SLE, both should work).

 

Hope this helps.

[WinstonAce]

I didn't mean the port limit patch, I want to modify the device id instead of using injector.

[randomusername00]

Everyone else's mileage may vary, and the issue most likely exists between keyboard and chair, but the DSDT patching seemed to nuke working sleep for me.

 

Instead, kext injection allows proper sleep.

 

Again, most likely user error as this was my first time working on DSDTs, but wanted to report the data point in case anyone else finds it useful.

 

I tried again, and, again same result

 

This is the DSDT patch I applied to _SB.PCI0.XHC:

           Method (_DSM, 4, NotSerialized)            {
                If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
                Return (Package()
                {
                    "AAPL,clock-id", Buffer() { 0x02 },
                    "built-in", Buffer() { 0x00 },
                    "subsystem-id", Buffer() { 0x31, 0x8c, 0x00, 0x00 },
                    "subsystem-vendor-id", Buffer() { 0x86, 0x80, 0x00, 0x00 },
                    "AAPL,current-available", 2100,
                    "AAPL,current-extra", 2200,
                    "AAPL,current-extra-in-sleep", 1600,
                    "AAPL,device-internal", 0x02,
                    "AAPL,max-port-current-in-sleep", 2100,
                })
            }

And this is the wake message:

10/10/15 4:17:23.000 PM kernel[0]: Wake reason: GLAN EHC1 EHC2 XHC HDEF (Network)

 

I can just keep going with the mini-injector, but I am curious if anyone can see an obvious issue with my patch.

I didn't mean the port limit patch, I want to modify the device id instead of using injector.

 

Oh, I see

 

Well, that isn't working for me. I just posted about it. Hopefully someone has a solution that can make both you and me happy here.

[WinstonAce]

Thank you for the replay

i'll use your "mini-injector" for now   

[arix98]

Just learned that we can also patch  XHCI id via Clover.

 

In Clover Configurator, Patch AppleUSBXHCIPCI, find <string>0x9cb18086</string> replace with <string>0x8cb18086</string> Select the "InfoPlistPatch" check and change the Type/Key to "DATA".

 

this replaces the 0x9cb18086(device id for mobile 9 series) with 0x8cb18086(desktop 9 series). 

 

Useful for port limit removal or DSDT port nuke method.

 

                        <dict>
                                <key>Comment</key>
                                <string>patch for desktop 9 series</string>
                                <key>Find</key>
                                <data>
                                PHN0cmluZz4weDljYjE4MDg2PC9zdHJpbmc+
                                </data>
                                <key>InfoPlistPatch</key>
                                <true/>
                                <key>Name</key>
                                <string>AppleUSBXHCIPCI</string>
                                <key>Replace</key>
                                <data>
                                PHN0cmluZz4weDhjYjE4MDg2PC9zdHJpbmc+
                                </data>
                        </dict>

[WinstonAce]

Thank you, thats what I wanted

BTW - what are you using in bios:

XHCI Mode - Smart Auto?

XHCI hand off - Enabled?

EHCI hand off - Disabled?

[randomusername00]

BTW you can very easily inject the Series 8 USB3 ID into your DSDT for Series 9.

 

This I would really love to hear about. As you can see from my post above, I tried and failed twice.

[randomusername00]

So you mean something like this:

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

plus the DTGP patch?

 

What is the difference between "compatible" and "device-id"?

 

Thanks for helping out. I figure it's high time for me to learn something about DSDT...

[randomusername00]

You need to try it to see. I don't have my z97 setup right now to test it.

 

Seems to have worked:

  PCI Device ID: 0x8c31 

  PCI Revision ID: 0x0000 

  PCI Vendor ID: 0x8086 

 

My devices are properly hooked to the USB3 bus, speed confirmed - and sleep also works

 

Thanks for getting me on the right track. Much appreciated!

[randomusername00]

No prob, glad to help. I would advise adding the USB power fixes too in same DSM

 

Power fixes uh?

Where can I find these?

 

And, they sound like the kind of fixes that would - say - allow my iPad to charge when plugged into my computer?

[randomusername00]

Have you ever looked at my repos?

 

And yes exactly that.

 

PJALM ASUS: http://pjalm.com/repos/asus

PJALM Gigabyte: http://pjalm.com/repos/gigabyte

PJALM ASRock: http://pjalm.com/repos/asrock

PJALM MSI: http://pjalm.com/repos/msi

PJALM Zotac: http://pjalm.com/repos/zotac

PJALM General: http://pjalm.com/repos/general

PJALM Graphics: http://pjalm.com/repos/graphics

PJALM Intel 6: http://pjalm.com/repos/intel6

PJALM Intel 7: http://pjalm.com/repos/intel7

PJALM Intel 8: http://pjalm.com/repos/intel8

PJALM Intel 9: http://pjalm.com/repos/intel9

 

I had an old sourceforge copy of those repos in MaciASL - not the new one

 

Alright, I am going to guess this is the changeset you want me to try:

# Maintained by: PJALM (help@pjalm.com) for: http://pjalm.com/repos/

# These patches are the registered property of PJALM.COM and can not be
# redistributed or modified without the written consent of PJALM.COM.
# Links to these patches are allowed. All material is protected under the DMCA.


# Last Updated  : 10/10/2015
# Patch Name    : USB Power
# Patch Version : 1.0


# Patches the Intel USB3 on Intel 9 Series chipsets to allow more power output
#Fix EHC1
into method label _DSM parent_label EHC1 remove_entry;
into device label EHC1 insert begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package (0x15) {\n
"AAPL,slot-name", "Built In",\n
"name", "Intel EHCI Controller",\n
"model", Buffer(0x3E) {"Intel 9 Series Chipset Family USB Enhanced Host Controller #1"},\n
"device_type", Buffer (0x0E) {"USB Controller"},\n
"AAPL,current-available", 0x0834,\n
"AAPL,current-extra", 0x0A8C,\n    
"AAPL,current-in-sleep", 0x03E8,\n
"AAPL,current-extra-in-sleep", 0x0834,\n
"AAPL,max-port-current-in-sleep", 0x0A8C,\n
"AAPL,device-internal", 0x02,\n
Buffer (One) {0x00}\n
}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}
end;


#Fix EHC2
into method label _DSM parent_label EHC2 remove_entry;
into device label EHC2 insert begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package (0x15) {\n
"AAPL,slot-name", "Built In",\n
"name", "Intel EHCI Controller",\n
"model", Buffer (0x3E) {"Intel 9 Series Chipset Family USB Enhanced Host Controller #2"},\n
"device_type", Buffer (0x0E) {"USB Controller"},\n
"AAPL,current-available", 0x0834,\n
"AAPL,current-extra", 0x0A8C,\n
"AAPL,current-in-sleep", 0x03E8,\n
"AAPL,current-extra-in-sleep", 0x0834,\n
"AAPL,max-port-current-in-sleep", 0x0A8C,\n
"AAPL,device-internal", 0x02,\n
Buffer (One) {0x00}\n
}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}
end;


#Fix XHC1
into device label XHC set_label begin XHC1 end;
into_all all code_regex XHC(?=\W) replaceall_matched begin XHC1 end;
into method label P_CS code_regex \\_SB\.PCI0\.XHC1\.DUAM replaceall_matched begin \\_SB.PCI0.XHC.DUAM end;
into method label _DSM parent_label XHC1 remove_entry;
into device label XHC1 insert begin
Method (_DSM, 4, NotSerialized)\n
{\n
Store (Package (0x15) {\n
"AAPL,slot-name", "Built In",\n
"name", "Intel XHCI Controller",\n
"model", Buffer (0x37) {"Intel 9 Series Chipset Family USB xHCI Host Controller"},\n
"device_type", Buffer (0x0E) {"USB Controller"},\n
"AAPL,current-available", 0x0834,\n
"AAPL,current-extra", 0x0A8C,\n
"AAPL,current-in-sleep", 0x03E8,\n
"AAPL,current-extra-in-sleep", 0x0834,\n
"AAPL,max-port-current-in-sleep", 0x0A8C,\n
"AAPL,device-internal", 0x02,\n
Buffer (One) {0x00}\n
}, Local0)\n
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
Return (Local0)\n
}
end;

Will give it a shot and let you know!

[randomusername00]

just add the missing info for XHC to yours, you don't need the rest.

 

Alright, about to reboot with these changes to XHC

           Method (_DSM, 4, NotSerialized)            {
                Store (Package (0x17) {
                    "AAPL,slot-name", "Built In",
                    "name", "Intel XHCI Controller",
                    "model", Buffer (0x37) {"Intel 9 Series Chipset Family USB xHCI Host Controller"},
                    "device-id",Buffer () {0x31,0x8c,0x00,0x00},
                    "device_type", Buffer (0x0E) {"USB Controller"},
                    "AAPL,current-available", 0x0834,
                    "AAPL,current-extra", 0x0A8C,
                    "AAPL,current-in-sleep", 0x03E8,
                    "AAPL,current-extra-in-sleep", 0x0834,
                    "AAPL,max-port-current-in-sleep", 0x0A8C,
                    "AAPL,device-internal", 0x02,
                    Buffer (One) {0x00}
                }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }

Results to follow

[randomusername00]

Looks Good

 

And works good too 

 

I just discovered that my front USB ports will not charge iPads regardless because of a stupid ASM107x hub(?) sitting between the port and the controller - but with your patch, the rear ports charge my iPad just fine!

Also, sleep works, the PCI ID is properly injected, and speeds look good in System Profiler

 

Well, so many thanks to you. It's been one productive evening!

 

EDIT: In looking at System Profiler, this is the difference between iPad charging (rear USB port):

 Location ID: 0x14a00000 / 11

  Current Available (mA): 1000

  Current Required (mA): 500

  Extra Operating Current (mA): 500

  Sleep current (mA): 1000

 

and iPad not charging (front USB port):

 Location ID: 0x14130000 / 12

  Current Available (mA): 1000

  Current Required (mA): 500

  Extra Operating Current (mA): 0

  Sleep current (mA): 500

 

As well as the info for the ASM107x:

ASM107x:

 

  Product ID: 0x2074

  Vendor ID: 0x174c  (ASMedia Technology Inc.)

  Version: 1.00

  Speed: Up to 480 Mb/sec

  Manufacturer: ASUS Tek.

  Location ID: 0x14100000 / 3

  Current Available (mA): 1000

  Current Required (mA): 100

  Extra Operating Current (mA): 0

[wegface]

I totally see why you're skeptical on the kext patching - but even so, I think the technique has merit at least as a way for people to do all the port discovery work on El Capitan. No need for multiple installs, or hoping to get things 100% right on Yosemite before the jump happens, or a secondary/primary Windows install lurking around.

 

Long-term, I actually envision a model where someone could just set things up this way, launch a tool, and plug/unplug a device from each port - the tool would then automatically craft a proper port injection kext.

 

Again, I am seeing proper behavior with the Clover patch (+ ID injection kext), but even if it turns out I am missing something, the technique is at least good enough as a bootstrapping mechanism.

 

That is not what the Clover kext patch is for. The Clover kext patch is for removing the 15 port limit. Arix98 posted a Clover config.plist change that you should be able to copy&paste verbatim. That will remove the port limit for you.

 

Now, if you have the same Series9 XHCI controller that I do, you will still need a mini-injector whose sole purpose is to tell OS X which driver to use for your controller. For that purpose, you should take the injection kexts posted in this thread, and just replace the Info.plist with the one I posted, then install the kext as you usually would (in Clover or in SLE, both should work).

 

Hope this helps.

 

In theory i agree also, but to be honest- there are not many users without windows. I am also of the opinion that anyone upgrading o.s in a rush without reading the problems that will occur, should probably consider changing habits.

To do this on a temp basis just to map the ports would seem to cause no problems, but maybe, users will be users and leave it like this forever. Let the dust settle, let some people test how things go, that is my entire point. Its not about me being skeptical, its about having responsibility to ensure people following my guide, dont bork their installs or data. 

 

 

No explaination of how the windows app replaces your method and how to use it and how it correlates. After many people saying that your method for finding the ports in Yosemite doesn't work including me, you have not addressed that in the guide.

 

Rehabman already agreed that the ARIX98 method was a great way to get the port addresses if your already in El Capitan. I saw no such comment from PJALM about bypassing the limit and it's unknowns.

 

Not sure why your being so defensive either. First it was a sarcastic response to test the new method with valuable data. Now it's there are no revelations besides just the Windows app and that's just not true. Someone asks a question about your method but instead of helping him your attacking me for basically tell him that there are some other options and he should read them.

As i said in my first post regarding this USBView, i don't have windows, so cannot test it, nor can i explain the differences, but as several people used it with no trouble, it seemed to be pretty easy. I am not willing to endorse potentially dangerous and perhaps dirty hacks in my guide, the forum is large enough to post these elsewhere. I dont want to be responsible for unknown results on people's valuable data. 

[wrk73]

I have remove some unused 2.0 port, but it still load and override 3.0 port. Anyone have idea to this problem?

[magnifico]

Have you ever looked at my repos?

 

And yes exactly that.

 

PJALM ASUS: http://pjalm.com/repos/asus

PJALM Gigabyte: http://pjalm.com/repos/gigabyte

PJALM ASRock: http://pjalm.com/repos/asrock

PJALM MSI: http://pjalm.com/repos/msi

PJALM Zotac: http://pjalm.com/repos/zotac

PJALM General: http://pjalm.com/repos/general

PJALM Graphics: http://pjalm.com/repos/graphics

PJALM Intel 6: http://pjalm.com/repos/intel6

PJALM Intel 7: http://pjalm.com/repos/intel7

PJALM Intel 8: http://pjalm.com/repos/intel8

PJALM Intel 9: http://pjalm.com/repos/intel9

Pj this is a new?

[StrangeNoises]

Just catching up...

 

As a user "being a user" and finding the ARIX98 method appears to work and hoping I can get away with leaving it like that forever ...

 

I also have a preference for the simplest option. So far I've got away without having to do DSDT stuff and long may that continue, the learning curve is *steep* at the start!

 

So for what it's worth, one data point on this Z87 mobo (Asus Z87I-Pro) SMBIOS-identified as iMac14,2:

 

I had briefly thought that the two ASMedia ports this mobo has on the back were working, and I could live with that without making any changes (already having as many ports there as I have in my real Macbook Pro), but that turned out to be unstable, with some odd effects.

 

The ARIX98 method seems to be working well so far in enabling the remaining six Intel USB3 ports. Everything is behaving as it should. That said, it's not getting very heavily tested here. The fastest USB3 device I have is a WD My Passport Ultra¹, and connected to a USB3 hub (in a Dell monitor) to a backpanel USB3 port (SSP3, enabled by ARIX98's method), and with the drive connected directly to a front-panel USB3 socket (SSP5 also enabled by the ARIX98 method), it appears to be stable, and the speeds are basically the same as those I get with the drive plugged directly to a real recent Macbook Pro also running El Cap. That speed isn't that spectacular, but it *is* the same on a real mac, and it exceeds the USB2 theoretical maximum, so it looks like it's working to me.

 

The only instability I got was when I ran IOJones *while* a transfer was taking place; then that drive kept spontaneously disconnecting and reconnecting and the transfer failed. As soon as I quit IOJones everything was stable again. Also running IOJones while that drive is quiescent seems OK, there was only a problem running it while trying to transfer data.

 

This is what IOJones sees then (nodes expanded far enough to see individual real-world devices):

 

 

HS03 and SSP3 are the same USB3 socket on the back, connected via USB3 cable to a Dell P2715Q's internal USB3 hub. Therefore that hub appears to be showing up as both USB2134B@14300000 (USB2) and USB5534B@15100000 (USB3) which I thought might be odd enough to mention, but maybe that's normal for USB3 hubs (this is the only one I have).

 

This is what I see in system report. Unlike the above, this screenshot was taken with the WD My Passport Ultra connected to SSP5, the front-panel port, not into the Dell hub. The top-right pane looks correct, but the big bottom-right pane looks like items are nested incorrectly, like the hierarchy is wrong with a spurious duplication of the "Volumes" section from the My Passport, that apparently seems to contain all the other devices. I would guess this is just a display bug in the system report app. I also note that here it shows the USB 3 bus selected as having the host controller driver AppleUSBXHCILPTH. Does the LPTH mean anything we should be concerned about?

 

 

[1] Ironically I'd have got a faster USB3 device if I'd failed to get the Hackintosh back in commission after the upgrade; as I'd have got a UASP-capable enclosure for the shiny new big SSD I bought for the hackintosh for the El Cap upgrade, to instead use with my Macbook Pro along with a Thunderbolt2 docking station... but in such an eventuality I wouldn't have had a hackintosh to test its speed on!

 

It's good to have some sense of responsibility that you're not just leading people into trashing their systems and data, but only up to a point. I think anyone trying to run a hackintosh must accept from the outset that they're always going to be a bit out on the ragged edge, and should learn to be phlegmatic when things go wrong. If you want the benefits and stability of a vendor-supported platform, buy one. If you can't afford that but want that platform stability, use Linux, which will install *much* more easily, with fully-supported hardware, on just about any hardware anyone's trying to hackintosh. (Certainly you shouldn't get yourself platform-bound to the apple ecosystem if your only mac is a hackintosh!) Choosing to go hackintosh means implicitly accepting some risks for being a cheapskate and not buying the equivalent or better mac!

 

So the ARIX98 method seems to be working for me, but I'm reporting what I see, and I'm following the thread in case something does turn up to say this really is wrong, and of course I'll report it if something bad happens here.

[wegface]

Just catching up...

 

As a user "being a user" and finding the ARIX98 method appears to work and hoping I can get away with leaving it like that forever ...

 

I also have a preference for the simplest option. So far I've got away without having to do DSDT stuff and long may that continue, the learning curve is *steep* at the start!

 

So for what it's worth, one data point on this Z87 mobo (Asus Z87I-Pro) SMBIOS-identified as iMac14,2:

 

 

 

 

Pjalm loves asus, why not speak with him to create an all-in-one dsdt patch for your exact board.

You shouldn't be afraid of DSDT patching, it is the "proper" way to make things work in hackintosh.

 

As i said many times, each user can do as they please i have no issue with that at all, but motivation of guide was keeping things "apple like" as much as possible.

 

Just to note, i do use real macs much more than i use a hack, and was an avid linux user for over a decade. 

 

Very strange that IOJones made an issue while a transfer was taking place, but remember as told by rehabman- the "easy" method makes a mess of the IOReg. 

 

I would say, people wishing to follow a diff method from this guide, should start a new thread, a new guide, and use that thread to discuss that method rather than this. Same way i did not post my method onto pokens thread. Make new, keep things tidy.

[mickeyd453]

Hi guys - sorry if this sounds like i am being dumb but this whole thread has me lost about the best route forward for me - Can anyone offer advice as to the best route forward for someone who does not have a DSDT, i cant actually get one to compile, and has an older mobo with Intel USB2. I am booting with Enoch Chameleon,

 

I am guessing i go down the kext route and construct one to match my USB2 ports but how do i get the information in the first place in order to begin? - I would prefer the DSDT route i think to avoid messing with the install with potentially unusual results going forward but if i cant get one to compile i am a bit stuck. IOJones does not seem to show what other screenshots have shown so i am a bit lost. I cam edit kexts by hand via the cli no problem but any initial pointers, or information i can provide to get me running would be great.

 

thanks guys

[wegface]

I have remove some unused 2.0 port, but it still load and override 3.0 port. Anyone have idea to this problem?

 

Your ioreg shows XH01 and injector is XHC1/XHC. They should match

[fminus]

I am trying to use USBviewer to map the USB2/USB ports. What am I supposed to make a note of when I load the app?

[joe75]

FYI, dsdt edits aren't the "proper" way to fix anything.. ACPI is never intended to be user edited. The "Apple" way has always been to make a kext. I know thats above most peoples capabilities but you guys shouldn't push your ways as being official or how Apple would do something.

 

Might be best to say dsdt patching is the most "convenient"

[wegface]

In my time hackintoshing the single most important thing i learned was to patch my dsdt. After that things worked better. The proper way is of course to buy a mac, but thanks for your input joe

[StrangeNoises]

 

 

Pjalm loves asus, why not speak with him to create an all-in-one dsdt patch for your exact board.

You shouldn't be afraid of DSDT patching, it is the "proper" way to make things work in hackintosh.

 

Well it's discouraging to fire up MaciASL, try to compile the system DSDT before even *making* any changes, and have it fail with pages of syntax errors (reduced to six when I selected ACPI 5.0 in prefs, but still, I have no clue what to do about those six). That's before I even try making any changes.

 

(That was actually in pursuit of getting my bluetooth dongle to work by killing the internal usb interface that the motherboard's Atheros bluetooth/wifi controller is on, as I think it's getting in the way. OTOH I wonder if now that OSX on its own is actually recognising that atheros I should instead be trying to make that work instead.)

[wegface]

Well it's discouraging to fire up MaciASL, try to compile the system DSDT before even *making* any changes, and have it fail with pages of syntax errors (reduced to six when I selected ACPI 5.0 in prefs, but still, I have no clue what to do about those six). That's before I even try making any changes.

 

Thats normal btw. Discouraging yes, but normal