Contribute
Register

The New Beginner's Guide to USB Port Configuration

I should have clarified the point about the USB2 ports:

The only ones that need to be set as USB2 are the Physical USB2 ports on the rear I/O plate, i.e. those with the Black tab.

Any USB2 (virtual) ports served from a physical USB3 port should be set with the connector type USB3, i.e. those with the Blue tab.

Your motherboard has 2 x USB2 physical ports on the rear I/O plate:
1000.png
So you need to amend the configuration again, my apologies for not clarifying this in my previous post.
 
Sorry if I come in with a different USB topic: Is it possible to deactivate Wake up by Mouse or Keyboard in OS? I'm using 10.9.5 on my Gigabyte GA-Z77-DS3H.

I had a old logitech wireless mouse/keyboard combo, one of these with a large blue translucent receiver with one USB and one PS/2 connector. I've changed the keyboard to a blacklit Logitech G610 keyboard, still no problems. The mouse was the same battery-eating thing before. I now have a mouse from Jelly Comb with a mini USB receiver. Since I have this mouse the system wakes up from sleep at the slightest mouse movement, but also on every keypress. In the BIOS keyboard/mouse power-on is disabled. The mouse receiver is connected to USB 2.0.

Actually I have to switch off the mouse immediately after selecting sleep mode, otherwise the computer wakes up at the slightest movement. The same is for keypresses. This is rather annoying. It's also only happening on this computer, and not with the old Logitech mouse. Is there a system setting via terminal to switch off this function?
 
Edhawk said:
I should have clarified the point about the USB2 ports:

The only ones that need to be set as USB2 are the Physical USB2 ports on the rear I/O plate, i.e. those with the Black tab.

Any USB2 (virtual) ports served from a physical USB3 port should be set with the connector type USB3, i.e. those with the Blue tab.

Your motherboard has 2 x USB2 physical ports on the rear I/O plate:
View attachment 520397
So you need to amend the configuration again, my apologies for not clarifying this in my previous post.
Click to expand...

Thx for the clarification. I know the above. I have tried many methods. This is the only way "for me" IMHO.

(The above is my board but I have 2 more USB 3.0 and 2 more USB 2.0 on the case in front.)

Consider this: There are 6 physical USB 3.0 ports (4 at the rear and 2 at the front of the casing via an onboard USB 3.0 header) and 2 x USB 2.0 ports at the rear and 2 at the front via an on board USB 2.0 header. The Wifi/BT card takes another USB 2.0 header.

The 6 physical USB 3.0 ports would have taken the count to 12 and there is NO WAY to fit another 4 USB 2.0 into 3! (Apart from using the brilliant FakePCIID_XHCIMux.kext to reroute the USB 2 to EHCI01/02). That is the reason using any other methods commonly described will result in either 1 or 2 ports MIA.



(BTW, if hackintool is showing the above, can be SSDT/kext file generated be used instead of USBMap? - not worth crashing my system just to accomplish the same thing).
 
Feartech said:
won't brick it, the limit patch won't function
Click to expand...
UtterDisbelief said:
Drat! Beat me to it ... Again!! :lol:

No. It won't brick your system. But why use one ....
Click to expand...
OK, no I didn't brick my system, yet! As you've mentioned, good luck applying any PLRP's to 10.14.6 if recent security updates have been applied. I'm determined to see if I can salvage the work done to-date on my build. Not quite ready yet to move to OC. Anyway, I applied the PLRP's from the Mojave Support page and used USBInjectAll.kext (0.7.3) per the Guide. After reboot and "refreshing" the Hackintool USB screen, I believe all ports are now visible. This is different from last year when I went thru this exercise (using the old Guide), only to realize that SS07 and SS08 were not showing up for mapping. They are now, but not sure if I'll reach the end process successfully. To summarize, I have 4 USB 3.1 (blue) ports on the back of the hack. HS01, HS02, HS07, HS08, SS01 & SS02 were visible during my previous attempt (they are in my current USBPorts.kext). Now SS07 and SS08 also appear. Is there anyway you can determine if the applied PLRP has indeed done its job? I have yet to begin remapping, just wanting to know if the process is moot. Attached Hackintool screen showing all visible ports, as well as the IOReg screen.

Update: @UtterDisbelief Following your guide, when comparing your Hackintool screen to mine, it appears all my ports might be visible, based on my controller. I reckon this is the result of USBInjextAll. The real test is if the PLRP's worked? The Guide doesn't mention how to verify this, other than to complete the port discovery task. Based on info I had collected, I attempted two different PLRP's, with each attempt starting anew. The Hackintool USB results were the same in both; but somewhere, something has to be different? Are there any clues using IOReg to see if the PLRP's worked as intended, not sure I'd understand, but willing to give it a try.

I have a suspicion that things aren't correct, and I may be stuck using my partially correct USBPorts.kext until I change course. Learning as I go, but not looking to brick my system, yet!

Thanks in advance for any counsel.
 

Attachments

  • PLRP-1a.png
    PLRP-1a.png
    199 KB · Views: 48
  • PLRP-1b.png
    PLRP-1b.png
    264.7 KB · Views: 49
Last edited:
Hey MadDan,

thanks for the guide but I've got this weird problem now with Big Sur 11.4.
I had everything working correctly and then edited my OC config.plist(again) to make some change and when the system rebooted I had no USB devices working. So I went back to using usbinjectall etc but that didn't work either? So I tried booting my other HDD installation of Big Sur 11.2.2 and that worked! So i redid all the port mapping but that didn't make any difference.
I had a USB Big Sur install USB so I tried booting from that and everything is working in 11.4?? I copied the usb efi folder over to the SDD(11.4 is on it) but nothing worked??
So I completely redid the SSD to start afresh with a new EFI directory but that didn't do any good. It's like the USBports and/or injectall methods are being ignored, which is really weird.
I've even tried an old clover efi but it's the same results: 11.4=No usb and 11.2.2=all is fine. I've also reset NVRAM in OC and in recovery mode with nvram -c ..

Any thoughts would be useful about now ... ;)

thanks
 
odwoh said:
Hey MadDan,

thanks for the guide but I've got this weird problem now with Big Sur 11.4.
I had everything working correctly and then edited my OC config.plist(again) to make some change and when the system rebooted I had no USB devices working. So I went back to using usbinjectall etc but that didn't work either? So I tried booting my other HDD installation of Big Sur 11.2.2 and that worked! So i redid all the port mapping but that didn't make any difference.
I had a USB Big Sur install USB so I tried booting from that and everything is working in 11.4?? I copied the usb efi folder over to the SDD(11.4 is on it) but nothing worked??
So I completely redid the SSD to start afresh with a new EFI directory but that didn't do any good. It's like the USBports and/or injectall methods are being ignored, which is really weird.
I've even tried an old clover efi but it's the same results: 11.4=No usb and 11.2.2=all is fine. I've also reset NVRAM in OC and in recovery mode with nvram -c ..

Any thoughts would be useful about now ... ;)

thanks
Click to expand...
I've been trying some more things to get this resolved and I have found an easy workaround!

I have this MyBookWD external drive that I put and EFI partition sometime ago but the folder was empty, so I copied my known 11.2.2 working EFI folder to it. This folder uses usbports.kext and when I rebooted my SSD 11.4 was working again!! As a test I tried booting from the 11.4 drive and it wasn't working.

At this point I don't want to mess with things any further but I never realized that whatever shows up on top in your BIOS when selecting a boot drive is the default one. If that changes then it may throw off your expectations when making changes.
 
odwoh said:
I've been trying some more things to get this resolved and I have found an easy workaround!

I have this MyBookWD external drive that I put and EFI partition sometime ago but the folder was empty, so I copied my known 11.2.2 working EFI folder to it. This folder uses usbports.kext and when I rebooted my SSD 11.4 was working again!! As a test I tried booting from the 11.4 drive and it wasn't working.

At this point I don't want to mess with things any further but I never realized that whatever shows up on top in your BIOS when selecting a boot drive is the default one. If that changes then it may throw off your expectations when making changes.
Click to expand...
Aha ... I got it working correctly now. From my original post "I never realized that whatever shows up on top in your BIOS when selecting a boot drive is the default one. If that changes then it may throw off your expectations when making changes."

It seems something I did changed the boot drive and so the one that became the default wasn't correct. I changed the order in BIOS and now 11.4 works with my usbports.kext just fine :)

I had thought there might be some sort of bug but no .... just the usual user getting things wrong ;)
 
@RehabMan - is he still around? Got a couple of questions to ask regarding FakePCIID_Mux.kext

I know this is an oldie but it is still a goodie as I am running a series 9 chipset (Gigabyte Z97) and I can get all my USB ports (17!, including onboard Wifi/BT) working as a result of the "quirk" of the series 7/8/9 chipsets.

I was wondering if a similar way to how the FakePCIID_Mux works can be duplicated using SSDT?

Thanks
 
lms said:
@RehabMan - is he still around? Got a couple of questions to ask regarding FakePCIID_Mux.kext

I know this is an oldie but it is still a goodie as I am running a series 9 chipset (Gigabyte Z97) and I can get all my USB ports (17!, including onboard Wifi/BT) working as a result of the "quirk" of the series 7/8/9 chipsets.

I was wondering if a similar way to how the FakePCIID_Mux works can be duplicated using SSDT?

Thanks
Click to expand...
Screenshot 2021-06-15 130423.jpg
 
lms said:
@RehabMan - is he still around? Got a couple of questions to ask regarding FakePCIID_Mux.kext

I know this is an oldie but it is still a goodie as I am running a series 9 chipset (Gigabyte Z97) and I can get all my USB ports (17!, including onboard Wifi/BT) working as a result of the "quirk" of the series 7/8/9 chipsets.

I was wondering if a similar way to how the FakePCIID_Mux works can be duplicated using SSDT?

Thanks
Click to expand...

No. You are not able to replicate this using an SSDT. I can give you technical reasons if you'd like but it might be boring.

I can see why you might think so, because we do create an embedded controller with SSDT-EC.aml etc. The difference is with EHCI and XHCI we are rerouting already existing controllers.

Basically there are very specific use cases for FakePCIID_XHCIMux.kext.

Remember you also need FakePCIID.kext to create and attach the new device you are going to spoof.

What is the "quirk" with 7/8/9 chipsets you are referring to?

Just use Hackintool as per the guide and maybe read the older one which does cover mixed controller setups etc.

:)
 
Last edited:
UtterDisbelief 2020
Z390 M GAMING |  i5 9600K |  Radeon Other
UtterDisbelief CL
Z370M-DS3H |  i3 8350K |  Radeon Other
UtterDisbelief KL
GA-Z270-Gaming K3 |  i3 7320 |  GeForce GTX 1050 OC
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top