Jump to content

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

wegface

By wegface,
in OSx86 10.11 (El Capitan)

 Share
497 posts in this topic

Recommended Posts

cba3145
cba3145
Posted
Posted

I was able to get all of my USB working by using PJALM/arix98's Guide. I booted into Windows and checked all my USB ports with USBviewer. Then I removed EHC1 and EHC2 from DSDT as well as the other unused ports. When using USBviewer make sure you use a USB2.0 in the USB3.0 (as well as a USB3.0 device) slot to get all numbers. USB2.0 in USB3.0 uses a separate port!

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Its not about physical USB ports, its about logical ports defined in DSDT.

Yes. I realize that. I have no such hardware that defines DSDT that way.

 

And... to clarify it is about ports which return non-zero from _STA. For example, my BRIX has more than 15 ports on XHC (HS01-HS15+SSP1-SSP6, total of 21), but only HS01-HS09+SSP1-SSP4 show up in IOACPIPlane because the others return Zero from _STA.

 

I tried your mod but it didn't do anything and my system reverted back to default status -- no USB3 so this doesn't help the 15 ports limit.

Did you get a warning about too many ports? I wouldn't mind seeing ioreg along with config.plist (I don't use CC).

Link to comment
Share on other sites
  • Popular Post
arix98
arix98
Posted
  • Popular Post
Posted

The Ultimate Solution

 

As I suspected earlier the 15 ports limit can be removed!!!

 

Did some assembly work and here is the result:

 

In Clover, use kext patch feature, patch AppleUSBXHCIPCI

 

Find                83BD8CFEFFFF10

Replace with  83BD8CFEFFFF16

                        <dict>
                                <key>Comment</key>
                                <string>remove usb limit</string>
                                <key>Find</key>
                                <data>
                                g72M/v//EA==
                                </data>
                                <key>Name</key>
                                <string>AppleUSBXHCIPCI</string>
                                <key>Replace</key>
                                <data>
                                g72M/v//Fg==
                                </data>
                        </dict>

the kext use >=0x10 to set the limit so with 0x10 we have 15 ports available.

Changing to 0x16 will give us 21 ports. I didn't go higher as 21 is the maximum amount for 8/9 series motherboard(8 USB2+6 USB3+1 possible dummy port) afaik but should be OK to set it to 0xFF...

 

 

Thats all. No other change necessary  :lol:

  • Like 24
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The Ultimate Solution

 

As I suspected earlier the 15 ports limit can be removed!!!

 

Did some assembly work and here is the result:

 

In Clover, use kext patch feature, patch AppleUSBXHCIPCI

 

Find                83BD8CFEFFFF10

Replace with  83BD8CFEFFFF16

                        <dict>
                                <key>Comment</key>
                                <string>remove usb limit</string>
                                <key>Find</key>
                                <data>
                                g72M/v//EA==
                                </data>
                                <key>Name</key>
                                <string>AppleUSBXHCIPCI</string>
                                <key>Replace</key>
                                <data>
                                g72M/v//Fg==
                                </data>
                        </dict>
the kext use >=0x10 to set the limit so with 0x10 we have 15 ports available.

Changing to 0x16 will give us 21 ports. I didn't go higher as 21 is the maximum amount for 8/9 series motherboard(8 USB2+6 USB3+1 dummy possible port) afaik but should be OK to set it to 0xFF...

 

 

Thats all. No other change necessary  :lol:

 

Nice. One thing to be concerned with though...

 

Did you check that there isn't some internal table that is fixed/limited to 15 entries? Probably not easy. Otherwise you may have memory corruption. I can see where it might not be unreasonable to have a fixed size array (15 entries), or even a fixed size bitfield (16 bits) for tracking state. If there is... things might get weird.

 

But good for short term use as you can inject all ports at once, in order to determine which ones are actually used.

 

And looking at the code around this patch, it seems there is a bit of a power management thing going on with "powering off unused ports". So there seems to be an advantage omitting unused ports from an injector, especially on a laptop, where battery life may be impacted.

  • Like 4
Link to comment
Share on other sites
wegface
wegface
Posted
  • Author
Posted

Yes, not ultimate solution, dangerous solution. This will cause unpredictable things to happen. That is not "marked solved". How can a guide be marked solved anyway, it wasnt a question!  :lol:  :lol:

  • Like 2
Link to comment
Share on other sites
blazinsmokey
blazinsmokey
Posted
Posted

The Ultimate Solution

 

SICK! Awesome, awesome find and great work man. I just tested.

post-1364638-0-14711500-1444432527_thumb.png

All ports found and mapped properly. No DSDT. Just your Kext patch added to my config.

Makes all the work I previously did look stupid :hysterical:

 

Edit: This method my boot time is what it should be from Clover. It hangs a bit when editing the DSDT. A bunch of reboots some test transfers on a couple ports and all is well.

 

Nice. One thing to be concerned with though...

 

Did you check that there isn't some internal table that is fixed/limited to 15 entries? Probably not easy. Otherwise you may have memory corruption. I can see where it might not be unreasonable to have a fixed size array (15 entries), or even a fixed size bitfield (16 bits) for tracking state. If there is... things might get weird.

 

But good for short term use as you can inject all ports at once, in order to determine which ones are actually used.

 

And looking at the code around this patch, it seems there is a bit of a power management thing going on with "powering off unused ports". So there seems to be an advantage omitting unused ports from an injector, especially on a laptop, where battery life may be impacted.

 

So you still believe removing the ports from DSDT to be the better way? I noticed my OSX boots much faster this way, I'm suspecting OSX is figuring out the missing ports and reassigning may cause some stalling on boot?

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

So you still believe removing the ports from DSDT to be the better way? I noticed my OSX boots much faster this way, I'm suspecting OSX is figuring out the missing ports and reassigning may cause some stalling on boot?

I think the best way is to determine which ports are actually used, then create/install a custom port injector kext that enables only those ports.

Link to comment
Share on other sites
arix98
arix98
Posted
Posted

Nice. One thing to be concerned with though...

 

Did you check that there isn't some internal table that is fixed/limited to 15 entries? Probably not easy. Otherwise you may have memory corruption. I can see where it might not be unreasonable to have a fixed size array (15 entries), or even a fixed size bitfield (16 bits) for tracking state. If there is... things might get weird.

 

But good for short term use as you can inject all ports at once, in order to determine which ones are actually used.

 

And looking at the code around this patch, it seems there is a bit of a power management thing going on with "powering off unused ports". So there seems to be an advantage omitting unused ports from an injector, especially on a laptop, where battery life may be impacted.

 

Its not a fixed array per my very limited knowledge and check, the powering off part is done before limitation check, and actual port creation is performed after these two. The port index# is used when creating the port -- I don't quite understand the detail though, as long as all ports working and no KP it looks OK for me.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Its not a fixed array per my very limited knowledge and check,

It would be very difficult to make certain.

 

But it is a useful patch for injecting everything just so you can determine which ports are actually used.

 

It will simplify writing a guide, as an injector kext can simply be provided along with this patch.

 

With instructions something like:

- rename objects as needed

- install the injector

- activate the patch

- reboot

- test USB ports, monitoring ioreg

- note each port used/not used

- edit the injector such that unused ports are deleted

- install new custom injector and test

 

 

the powering off part is done before limitation check,

As far as power management aspects, I'm saying it is another advantage to omitting ports that are unused. Not a big advantage on desktops, but probably some marginal power savings on laptops.

 

Also, this patch does not address the case that active ports are masked by incorrect DSDT _UPC methods.

 

The lazy way is to implement this fix and see what happens...

The best way is to use it as a tool to implement the correct solution (including only ports that are used).

 

IMO...

But if we do it the port injector way won't we be limited by the 15 port addresses still?

My understanding is the chipset limits you to 14. We are talking about declared ports in ACPI, not all of which are actually enabled/connected to hardware.

  • Like 1
Link to comment
Share on other sites
arix98
arix98
Posted
Posted

But if we do it the port injector way won't we be limited by the 15 port addresses still?

 

Sacrificing few ports is OK as its not a problem for laptop and perfectly acceptable for desktop, and some consider it safer.

 

My mod is easier and straightforward since its a "universal" solution, the additional ports is a side benefit, my preliminary test looks OK but might need more test/check.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Sacrificing few ports is OK as its not a problem for laptop and perfectly acceptable for desktop, and some consider it safer.

Especially when the ports aren't real and are instead a software artifact.

 

My mod is easier and straightforward since its a "universal" solution, the additional ports is a side benefit, my preliminary test looks OK but might need more test/check.

Question... you have more than 15 ports on XHC? Can you show an ioreg that demonstrates this? (red or green, doesn't matter)

 

Reading the chipset spec... it is a little vague on exactly what they mean by 14 ports. (in light of USB3 being USB2 pins + USB3 pins).

Link to comment
Share on other sites
arix98
arix98
Posted
Posted

Question... you have more than 15 ports on XHC? Can you show an ioreg that demonstrates this? (red or green, doesn't matter)

 

Reading the chipset spec... it is a little vague on exactly what they mean by 14 ports. (in light of USB3 being USB2 pins + USB3 pins).

 

A USB3 use HS port when connecting a USB2 device and SS port for USB3, so a physical USB3 port uses 2 XHC logical ports. You can check the screenshot by blazinsmokey at #184.

 

H87/Z87/H97/Z97/X99 all supports 8 USB2+6 USB3 so thats 14 physical ports, 20(8+6*2) logical ports total, obviously only 14 can be used at same time, 20 is required for all of them work properly. B85/H81 support less USB3 but BIOS may still list all 14 HS ports and 6 SS ports in DSDT.

Link to comment
Share on other sites
blazinsmokey
blazinsmokey
Posted
Posted

My understanding is the chipset limits you to 14. We are talking about declared ports in ACPI, not all of which are actually enabled/connected to hardware.

 

Went to look it up, you can see below. So 14x USB2.0 - 6 USB 3.0 would be 8 USB2 + 6 USB3, 14 physical ports.

My thought was the port address were different from USB3 and USB2 so a system like below would need 20 port addresses and OSX only assigns 15.

 

9series-9b.png

 

Sacrificing few ports is OK as its not a problem for laptop and perfectly acceptable for desktop, and some consider it safer.

 

My mod is easier and straightforward since its a "universal" solution, the additional ports is a side benefit, my preliminary test looks OK but might need more test/check.

I'm using it now as shown in my screen shot if you want help testing specifics, I'll see what I can do. Suddenly have no limits but realizing I don't have enough devices..... :rolleyes:

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

A USB3 use HS port when connecting a USB2 device and SS port for USB3, so a physical USB3 port uses 2 logical XHC logical ports. You can check the screenshot by blazinsmokey at #184.

Understand that. I was perhaps confused by PJALM's insistence that the limit is 14.

 

H87/Z87/H97/Z97/X99 all supports 8 USB2+6 USB3 so thats 20 logical ports total, obviously only 14 can be used at same time, 20 is required for all of them work properly. B85/H81 support less USB3 but BIOS may still list all 14 HS ports and 6 SS ports in DSDT.

OK. So limit is not 14 (statements in this thread regarding 14 port limit are false). Apple's limit is silly. Although can be worked around by XHC->EHC routing(mux).

 

To those that may be wondering about "obviously only 14 can be used at same time", it is because a single device plugged into a USB3 port will use only the USB2 pins or the USB3 pins, never both. So one "logical" port, either USB2 or USB3 will go unused there.

 

The image shows 15 16 (I missed the device that is connected[black]) ports... It would be nice to see more than that (all 20?).

 

Given it is not possible to verify the patch is 100% ok, I'd use FakePCIID_XHCIMux to move USB2 ports to EHCI rather than trying to increase the limit. But obviously, the patch is easier to grok for the person that doesn't understand this stuff.

  • Like 3
Link to comment
Share on other sites
blazinsmokey
blazinsmokey
Posted
Posted

Question... you have more than 15 ports on XHC? Can you show an ioreg that demonstrates this? (red or green, doesn't matter)

 

Reading the chipset spec... it is a little vague on exactly what they mean by 14 ports. (in light of USB3 being USB2 pins + USB3 pins).

 

Yea you can see it my post with the screen shot after testing new method, all under XHC.

post-1364638-0-11947500-1444435879_thumb.png

  • Like 1
Link to comment
Share on other sites
arix98
arix98
Posted
Posted

There is only 15 there. Several ports (HS07 HS08 HS11 HS13, did I miss one?) never had a device connected.

 

Threr're 20 ports there with the 4 you mentioned unused, so 16 ports total.

Manufacturers usually don't implement all USB2 ports due to limited space or making spaces for additional USB3 ports(from 3rd party controller)

 

My Z87 MB has 4 USB3 on back and another USB3 header on board, so 6 USB3 ports are all accessible.

 

And it has only 2 USB2 ports on back and 2 USB2 headers on board, so in theory there are 6 instead of 8 USB2 ports available and I use only 4, leaving another 4 completely unused/inaccessible, but the HS ports corresponding to unused USB2 ports are still listed under DSDT(with STA 0xf) thus use up the kext limit.

Link to comment
Share on other sites
randomusername00
randomusername00
Posted
Posted

This seems to be working for me on build 15B30a

Alright, I know I said this was working, but upon a further reboot I realized that - while all the ports under XHC were being recognized, the devices for some reason were actually all being connected to the USB2 bus, not the USB3

 

After a little bit of investigation, I remembered that my USB3 PCI ID is not one of the default that ship on Macs:

  PCI Device ID: 0x8cb1 

  PCI Revision ID: 0x0000 

  PCI Vendor ID: 0x8086 

 
So I tried the obvious thing, I made an injector kext that would only contain the binding for the PCI ID, and no ports listed:
 
$ cat /System/Library/Extensions/USB_Series9_Injector.kext/Contents/Info.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleIdentifier</key>
<string>com.pjalm.injector.USB</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>USB</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>IOKitPersonalities</key>
<dict>
<key>AppleUSBXHCILPTH</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.usb.AppleUSBXHCIPCI</string>
<key>IOClass</key>
<string>AppleUSBXHCILPTH</string>
<key>IOPCIPrimaryMatch</key>
<string>0x8cb18086</string>
<key>IOPCITunnelCompatible</key>
<true/>
<key>IOProbeScore</key>
<integer>1000</integer>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
</dict>
</dict>
<key>OSBundleRequired</key>
<string>Root</string>
</dict>
</plist>

Well, turns out, this does indeed do the right thing: http://imgur.com/86kLKBi

  • Like 1
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Threr're 20 ports there with the 4 you mentioned unused, so 16 ports total.

I was missing the device that was connected (easier to see the tiny red text than the tiny black text).

Ok, so 16 ports there (actually used).

 

Manufacturers usually don't implement all USB2 ports due to limited space or making spaces for additional USB3 ports(from 3rd party controller)

OEMs are supposed to mark unused ports as not connectable via _UPC. But they are lazy and don't test properly...

 

My Z87 MB has 4 USB3 on back and another USB3 header on board, so 6 USB3 ports are all accessible.

 

And it has only 2 USB2 ports on back and 2 USB2 headers on board, so in theory there are 6 instead of 8 USB2 ports available and I use only 4, leaving another 4 completely unused/inaccessible, but the HS ports corresponding to unused USB2 ports are still listed under DSDT(with STA 0xf) thus use up the kext limit.

So 12 ports used by USB3 (6*2), and 4 more for USB2only is 16. The other 4 should be marked not connectable, but probably are not.

 

But yes, you're going to hit the limit and need to either take the chance with your patch or use FakePCIID_XHCIMux to route them to EHCI.

 

But nice to see that there really are more than 14 ports on this chipset, as confirmation that Apple's decision is not helpful. Eventually, they'll need to bump the limit because 100-series gets rid of EHCI, so routing usb2 away from XHC won't work anymore.

Link to comment
Share on other sites
arix98
arix98
Posted
Posted

Alright, I know I said this was working, but upon a further reboot I realized that - while all the ports under XHC were being recognized, the devices for some reason were actually all being connected to the USB2 bus, not the USB3

 

After a little bit of investigation, I remembered that my USB3 PCI ID is not one of the default that ship on Macs:

  PCI Device ID: 0x8cb1 

  PCI Revision ID: 0x0000 

  PCI Vendor ID: 0x8086 

 
So I tried the obvious thing, I made an injector kext that would only contain the binding for the PCI ID, and no ports listed:
 
$ cat /System/Library/Extensions/USB_Series9_Injector.kext/Contents/Info.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleIdentifier</key>
<string>com.pjalm.injector.USB</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>USB</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>IOKitPersonalities</key>
<dict>
<key>AppleUSBXHCILPTH</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.usb.AppleUSBXHCIPCI</string>
<key>IOClass</key>
<string>AppleUSBXHCILPTH</string>
<key>IOPCIPrimaryMatch</key>
<string>0x8cb18086</string>
<key>IOPCITunnelCompatible</key>
<true/>
<key>IOProbeScore</key>
<integer>1000</integer>
<key>IOProviderClass</key>
<string>IOPCIDevice</string>
</dict>
</dict>
<key>OSBundleRequired</key>
<string>Root</string>
</dict>
</plist>

Well, turns out, this does indeed do the right thing: http://imgur.com/86kLKBi

 

Seems that only 4 Intel XHC IDs are in the original kext, if my google-fu is correct

 

8086 1e31 7 series

8086 8c31 8 series  <---thats mine and that's why I didn't notice the issue.

8086 9c31 mobile 8 series

8086 9cb1 mobile 9 series

 

so for desktop 9 series, 8086:8cb1 is not included. The kext injection in OP's guide takes care of this, so for 9-series, when the Clover mod or DSDT port removal mod is used, kext injection is still necessary to get the Apple XHCI driver loaded, except your kext can be used directly without further change, or maybe DSDT device id injection?

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...