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

[MexicoMatt]

What version of OS X?

 

For certain XHC, it matters 10.11 vs. 10.11.1+. It is covered in the USBInjectAll README.

10.11.0. Actually, i was curios if i now update to 10.11.1 will it mess up my now working USBs?? (or the audio for that matter). Heavily believe in 

"If its not broken, don't fix it!"

[RehabMan]

10.11.0. Actually, i was curios if i now update to 10.11.1 will it mess up my now working USBs?? (or the audio for that matter). Heavily believe in 

"If its not broken, don't fix it!"

For 10.11.0, installing USBInjectAll.kext is not enough. It is covered in the README.

 

It is the same reason the 9series injector from post #1 helped you and why 8series didn't.

 

The 9series injector in post #1 does not include all ports, so, unmodified it is not a good way to try and make all your ports work (so you can determine which ones are actually needed). Try USBInjectAll... and read the README. Carefully.

 

Oh... no one can predict the future.

[RehabMan]

Just to clear things up, that pic is 10.10 not 10.11.

10.10 did not use that ioreg structure. Post ioreg (or iojones, if you prefer).

[MexicoMatt]

@RehabMan I just found another link for the USBInjectAll, because (don't know where i got it from as i have spent a week doing this now) but the file i had was 

RehabMan-USBInjectAll-2015-1025, which only had two folders "Debug" and "Release" both of which had a copy of the same USBInjectAll.kext (i guess they are different "inside",

i think i used the Release one), there was no README file, maybe thats the wrong one. I now have another one i downloaded OS-X-USB-Inject-All-Master, which has a bunch of files (plists / plist.sh / dsl ??), 

no ".kext" file however, but does have a README.md file, is that the one you want me to read carefully? 

 

My question, if the Series 9 Injector makes all my ports work the "speed" they should, apart form one, which i can plug my Apple Keyboard into anyway, why is it not a "good" way

to resolve my problem? Is there something i am missing, or have not thought of, genuine question, not trying to be sarcastic.

 

Cheers, Matt 

 

EDIT: Not trying to change the subject, as i believe it is USB related, but now like i mentioned above, my bluetooth says not available, I am pretty sure i read somewhere that 

the integrated Bluetooth / Wi-Fi on my MB (ASUS Z87-Pro) is NOT compatible with El Capitan, is that the case, if it is am i righting thinking if i now buy a Card / PCI-E Adapter combo

then i can get them working, or is there a way to get it "natively" working. 

 

Again, thank you to everyone who is helping. 

[RehabMan]

@RehabMan I just found another link for the USBInjectAll, because (don't know where i got it from as i have spent a week doing this now) but the file i had was 

RehabMan-USBInjectAll-2015-1025, which only had two folders "Debug" and "Release" both of which had a copy of the same USBInjectAll.kext (i guess they are different "inside",

i think i used the Release one), there was no README file, maybe thats the wrong one. I now have another one i downloaded OS-X-USB-Inject-All-Master, which has a bunch of files (plists / plist.sh / dsl ??), 

no ".kext" file however, but does have a README.md file, is that the one you want me to read carefully? 

USBInjectAll: https://github.com/RehabMan/OS-X-USB-Inject-All

 

Download location is linked from the README.

 

My question, if the Series 9 Injector makes all my ports work the "speed" they should, apart form one, which i can plug my Apple Keyboard into anyway, why is it not a "good" way

to resolve my problem? Is there something i am missing, or have not thought of, genuine question, not trying to be sarcastic.

The 9-series injector in post #1 does not include all possible ports. It is not generic. It appears to be created for a specific computer.

 

USBInjectAll, on the other hand, will inject all possible ports. It is a good tool to learn which ports your computer actually uses.

 

But to use it on certain 9-series XHC + 10.11.0, you need the "device injector kext" (in the old repo, linked by the README). And you need the kext patch that increases the port limit. It is all covered in the README. The "device injector kext" is not needed on 10.11.1.

 

After determining which ports are used by your computer, you can use the 9-series injector kext in post #1 as a template to build a correct one for your computer. on 10.11.1, you would base it on the 8-series injector in post #1, because there is code in the 9-series injector that is not needed on 10.11.1. You could also just delete the problem section upon upgrading to 10.11.1. After creating your custom injector, you can eliminate USBInjectAll and the port limit patch.

 

As discussed elsewhere in this thread, the port limit patch is probably not a good idea for long term use. So... if you have more than 15-ports and can't live with just ignoring some of them, you'll have to either keep the port limit patch, or use FakePCIID_XHCIMux to move some of those ports to EHC (requires more port injector work and likely a trip back to USBInjectAll to determine where the moved ports go).

[RehabMan]

You are assuming all IOReg are made alike, your wrong.

Not assuming anything. Just asked you to provide ioreg that proves the pic in post #1.

 

I have six(6) machines running 10.10 here (and 10.11), Intel generations (Sandy->Haswell). None show what is presented in post #1 on 10.10.

Also I never said the injector was made to just install and all work,

I never said you did. My reply was to explain to MexicoMatt why the injector from post #1 might not make all the ports work.

 

it clearly says it's an example and must be customized.

As we both know, users often do not read carefully.

 

Anyhow, this issue is old and solutions are already out there that work so no need to advertise even more here.

Not "advertising." Just trying to help with a question. Not sure why you take offense.

 

That port limit patch is bad and we all know it so use at your own risk,

While I agree, it is useful for short term use in order to determine which ports are active in a single session.

For long term use of >15 ports, I would use FakePCIID_XHCIMux to move USB2 ports on XHCI to EHCI.

 

At this point, I have no hardware with that many ports.

[dramsey]

I'm in San Jose now and dropped by Fry's. Hey, look, a Gigabyte Z97N Gaming 5 mITX motherboard. (Z97 mobos are actually rather thin on the ground these days.)

 

So rather than go through what seems to be Infinite Thrash getting USB ports working on my Z87,  I just bought that and am hoping-- hope is free, remember-- that it Will Just Work with 10.11.1. We shall see.

[MexicoMatt]

@RehabMan Again thanks for your feedback. and the link, and yes that was the README file that i have read, to be honest still confused. I understand what you are saying that the injector doesn't include all possible ports, but again, if all MY ports are working, and i do not intend to add anymore (If i get the bluetooth PCI-e card I believe that connects to a USB header on the MB,  I have two that i am not using right now, that I tested and they work with the injector, so i assume i could connect to one of them.)  Also i thought my MB was a series 8 (Z87) not series 9. 

 

@PJALM Thanks for your feedback too, two comments,

1)I have not used the patch to remove the 15 port limit, as the general view i get form here and you is that it is not a great fix anyway, and could have issues. 

2) This is all new to me, we are not all experts in this like you obviously are, and I don't think it is "polite" of you to be referring to people (me) who are beginners asking for help as 

"dumb" because they don't understand something and do it in a way that you think is wrong. 

 

I have said before and will say again, sorry for any "stupid" questions, and thank you to everyone that is helping the people that do not quite "get it". 

Cheers. 

[RehabMan]

@RehabMan Again thanks for your feedback. and the link, and yes that was the README file that i have read, to be honest still confused. I understand what you are saying that the injector doesn't include all possible ports, but again, if all MY ports are working, and i do not intend to add anymore (If i get the bluetooth PCI-e card I believe that connects to a USB header on the MB,  I have two that i am not using right now, that I tested and they work with the injector, so i assume i could connect to one of them.)  Also i thought my MB was a series 8 (Z87) not series 9.

You wrote "apart form ONE USB3 port on the back not recognising USB3, only USB2," ... Then you you write here "all MY ports are working".

Seems like a contradiction.

 

Not sure if that means you fixed the one USB3 not working properly or if you forgot about it when you wrote this latest post.

The reason that port is not working as USB3 is probably due to a missing SSPx port in your injector or a port that is in the injector but is eliminated due to the 15-port limit (the SSPx ports at the end are generally the ones eliminated).

 

If you want to fix that port, you certainly can, if you follow the advice here and elsewhere.

[MexicoMatt]

You wrote "apart form ONE USB3 port on the back not recognising USB3, only USB2," ... Then you you write here "all MY ports are working".

Seems like a contradiction.

 

Not sure if that means you fixed the one USB3 not working properly or if you forgot about it when you wrote this latest post.

The reason that port is not working as USB3 is probably due to a missing SSPx port in your injector or a port that is in the injector but is eliminated due to the 15-port limit (the SSPx ports at the end are generally the ones eliminated).

 

If you want to fix that port, you certainly can, if you follow the advice here and elsewhere.

@RehabMan, you are 100% correct, i did write both those statements.

 

Let me clarify. i dod not fix it, nor did i forget about it, however for my setup from all my ports on the back of my Hack (all USB3) i need to connect one to USB 2 hub, to which is connected my Apple Wired Keyboard. So yes ONE USB3 only recognises USB2, but that works perfect for my scenario, as that is the port i will / am using for my hub / keyboard. 

 

I understand the point you (and @PJALM) are making that the injector i am musing is not completely customised to my machine, which ideally it should be, but after the last week and half of reading through the posts here ,and trying Yosemite and Windows to "map" the ports, and not being able to make head nor tale of how to relate them to the HS / SSP numbers, I am relieved that right now i have things working in a way that works for me, even though it may not be the "ideal" way. Once i have a clear had, and some spare hours, i will try to as you say use the 9 injector as a base and work form there to customise it to my hack.

 

Again, if there are any potential issues / problems / dangers that i might incur using the injector in this way that i have missed, i would appreciate it if you would let me know.

 

Again Thank-you.

MexicoMatt.  

[dramsey]

...but after the last week and half of reading through the posts here ,and trying Yosemite and Windows to "map" the ports, and not being able to make head nor tale of how to relate them to the HS / SSP numbers, I am relieved that right now i have things working in a way that works for me, even though it may not be the "ideal" way.

 

I am extremely sympathetic to this point of view. 

[wundorn]

I'm running a Gigabyte Z77-DS3H with 10.11.1. Trying to get my ports working, I installed USBInjectAll.kext, along with the clover patch to AppleUSBXHCIPCI to increase max ports.

 

No joy, nothing changed at all. I can, exactly as before, see both HSP1-4 and SSP1-4 under XHC, but any device I attach shows up under HSP. Argh!

@RehabMan, having read your "README.md" carefully, I noticed that for the 7-series chipset, it says:

XHC, 7-series chipset (8086:1e31): 4-USB2 ports HS01-HS04, 4-USB3 ports SSP5-SSP8.

 

Now, I'm not sure what I'm doing here, but ISTM that that's wrong, at least for my MB. The ports are SSP1-4. So just for kicks, I changed the SSP5-8 (in the 8086_1e31 section) in the info.plist of your kext to SSP1-4 instead.

 

It still doesn't work - though oddly, with AND without your kext, with AND without the EHC1/2 rename it works *once* after rebooting (confirmed with ioreg and empirical testing). The port count patch is in, though I imagine that's irrelevant.

 

I checked, USBInjectAll.kext is loading.

 

So, any idea what's going on? I'm happy to post ioreg output, etc., I'm just not sure what's interesting.

 

Thanks!

[RehabMan]

@RehabMan, having read your "README.md" carefully, I noticed that for the 7-series chipset, it says:

XHC, 7-series chipset (8086:1e31): 4-USB2 ports HS01-HS04, 4-USB3 ports SSP5-SSP8.

 

Now, I'm not sure what I'm doing here, but ISTM that that's wrong, at least for my MB. The ports are SSP1-4. So just for kicks, I changed the SSP5-8 (in the 8086_1e31 section) in the info.plist of your kext to SSP1-4 instead.

You're forgetting about the USB2 component of each USB3 port (when XHC->EHC port routing not in effect).

 

The labels of the ports do not matter, only the port address. In this case the port labels are named after their address, as is common in 7-series DSDT.

 

So, any idea what's going on? I'm happy to post ioreg output, etc., I'm just not sure what's interesting.

No idea without ioreg. And EFI/Clover folder (or better: "patchmatic -extract" output)

[Mieze]

I have reason to believe that the UsbConnector value is derived from the _UPC object (second value) in the ACPI tables, and in case you want to correct this value, then you can do that with help of a tiny bit of SSDT coding:

        Scope (\_SB.PCI0.XHC.RHUB.HS01)
        {
            Store (0x3, Index (_UPC, 1))
        }

 

The ACPI 5.0 spec defines the meaning of the second byte of the _UPC return package in this way:

Specifies the host connector type. It is ignored by OSPM if the port is not user visible:
0x00: Type ‘A’ connector
0x01: Mini-AB connector
0x02: ExpressCard
0x03: USB 3 Standard-A connector
0x04: USB 3 Standard-B connector
0x05: USB 3 Micro-B connector
0x06: USB 3 Micro-AB connector
0x07: USB 3 Power-B connector
0x08 – 0xFE: Reserved
0xFF: Proprietary connector

Mieze

[LockDown]

So... if you have more than 15-ports and can't live with just ignoring some of them, you'll have to either keep the port limit patch, or use FakePCIID_XHCIMux

Which "port limit patch" were you referring to?

[wundorn]

No idea without ioreg. And EFI/Clover folder (or better: "patchmatic -extract" output)

 

OK... iojones zipped and attached. The Clover folder is 24MB, so I doubt you want the whole thing. I'm attaching the config though. It's fairly vanilla, except:

EHC1/2 renamed

XHC not renamed, it came that way

port limit patched

 

Let me know if you need anything else.

 

Thanks for any help you can offer.

 

 

[RehabMan]

Which "port limit patch" were you referring to?

It is in this thread, linked from the USBInjectAll README.

OK... iojones zipped and attached. The Clover folder is 24MB, so I doubt you want the whole thing. I'm attaching the config though. It's fairly vanilla, except:

EHC1/2 renamed

XHC not renamed, it came that way

port limit patched

 

Let me know if you need anything else.

 

Thanks for any help you can offer.

 

wundorn.zipconfig.plist.zip

I looked at ioreg. No evidence that USBInjectAll is installed.

[LockDown]

It is in this thread, linked from the USBInjectAll README

Why is "port limit patch" not a long term solution?

[RehabMan]

Why is "port limit patch" not a long term solution?

Read the posts that follow the introduction of the patch in this thread.

[wundorn]

I looked at ioreg. No evidence that USBInjectAll is installed.

Sorry, I didn't realize you wanted the ioreg from when booted with USBInjectAll. Included here.

 

BTW, about why it's a bad idea to use USBInjectAll and the port limit patch long term - there are over 450 posts in this thread. Any chance you could link the relevant one (or even just give us a page number)?

 

Thanks again.

 

[RehabMan]

Sorry, I didn't realize you wanted the ioreg from when booted with USBInjectAll. Included here.

USBInjectAll is doing what is expected. And just as expected the port addresses injected match IOACPIPlane.

 

All devices are shown on EHC. It is likely you neglected to simulate an appropriate version of Windows when running under "Darwin" such that DSDT will enable your USB3 ports.

 

BTW, about why it's a bad idea to use USBInjectAll and the port limit patch long term - there are over 450 posts in this thread. Any chance you could link the relevant one (or even just give us a page number)?

The post for the patch in this thread is directly linked from USBInjectAll readme. From there it is simply a matter of reading the responses (from myself and others) that follow.

[wastez]

The ACPI 5.0 spec defines the meaning of the second byte of the _UPC return package in this way:

Specifies the host connector type. It is ignored by OSPM if the port is not user visible:
0x00: Type ‘A’ connector
0x01: Mini-AB connector
0x02: ExpressCard
0x03: USB 3 Standard-A connector
0x04: USB 3 Standard-B connector
0x05: USB 3 Micro-B connector
0x06: USB 3 Micro-AB connector
0x07: USB 3 Power-B connector
0x08 – 0xFE: Reserved
0xFF: Proprietary connector

Mieze

I also think for a longer duration of time that the 2nd Byte of UPC defines the USB-Connector Number but until now i didn´t find somebody who aggrees this thought.

But in the most configurations all xhc values are defined as 0x03 even if the second byte is a other one.

 

So it should be changed in the kext to the 2nd byte of the UPC value to be correct, i´m right?

 

@mieze and pikeralpha

What do you mean? 

[Mieze]

So it should be changed in the kext to the 2nd byte of the UPC value to be correct, i´m right?

 

 

Provided this theory is correct, the second byte should be 0x03 for USB 3.0 ports (including the multiplexed USB 2.0 ports), 0x00 for USB 2.0 ports and 0xFF for internal USB-Ports but of course this still needs to be verified in real life.

 

Mieze

[wundorn]

USBInjectAll is doing what is expected. And just as expected the port addresses injected match IOACPIPlane.

 

All devices are shown on EHC.

What are you looking at in the ioreg to see this?

 

It is likely you neglected to simulate an appropriate version of Windows when running under "Darwin" such that DSDT will enable your USB3 ports.

OK, I read about this already - I think it was an explanation you wrote about what the different options were (different Windows versions) and why they matter. But I don't remember where I saw it. :-( Also, the Clover Wiki doesn't say much about this, except a brief mention of the "FixDarwin_0002 bit" which doesn't seem right. Is there a way I can change this in clover's config.plist? I'm running without a DSDT so far and would prefer to stay that way if possible, though if it isn't I guess I'll suck it up... If not, can you point me to something that explains how to do this?

 

The post for the patch in this thread is directly linked from USBInjectAll readme. From there it is simply a matter of reading the responses (from myself and others) that follow.

Ah... I had read that post, but not the followups. I see your point about a possibly fixed-size table. Well, one thing at a time...

 

Thank you!

[RehabMan]

Provided this theory is correct, the second byte should be 0x03 for USB 3.0 ports (including the multiplexed USB 2.0 ports), 0x00 for USB 2.0 ports and 0xFF for internal USB-Ports but of course this still needs to be verified in real life.

 

Mieze

It follows so far, although 0x3 seems to be used for USB2 component of USB3 ports (eg. HSxx associated with SSPx). It makes a bit of sense...

 

I find most (laptop) DSDTs are wrong. They are all over the map, like the programmers didn't even try... Testing in order to find the association and then fixing them is needed (either DSDT or in an injector).

What are you looking at in the ioreg to see this?

I'm looking at the USB driver nodes (EH01/EH02/XHC) and branches under each...

 

OK, I read about this already - I think it was an explanation you wrote about what the different options were (different Windows versions) and why they matter. But I don't remember where I saw it. :-(

:-)

 

Also, the Clover Wiki doesn't say much about this, except a brief mention of the "FixDarwin_0002 bit" which doesn't seem right. Is there a way I can change this in clover's config.plist? I'm running without a DSDT so far and would prefer to stay that way if possible, though if it isn't I guess I'll suck it up... If not, can you point me to something that explains how to do this?

The Clover option doesn't help much here as it is fixed to "Windows 2001" (eg. old Windows).

 

For this stuff to work we usually need to simulate newer versions of Windows. Look at the very flexible approach (_OSI->XOSI) I use in my BRIX repo: https://github.com/RehabMan/Gigabyte-BRIX-s-DSDT-Patch. With minor changes to SSDT-HACK, you can simulate any version you wish.