mfc88 Posted January 19, 2017 Share Posted January 19, 2017 One more question regarding the warnings in the log.... Can I ignore those or could it be they will have an influence on the result? Should be ok. Link to comment Share on other sites More sharing options...
thenightflyer Posted January 19, 2017 Share Posted January 19, 2017 Try the EFI folder first (graphics should work, USBs are a question mark, and didn't touch Thunderbolt)... only if it doesn't work, swap the DSDT.aml in the zip below inside EFI-CLOVER-ACPI->patched and try again. Ok...finally i find time to test. With the first solution, TNF-EFI i've working graphics card renamed, working USB2 ports but front and read USB 3.0 and USB 3.1 don't work. So i tried the second DSDT as you suggested and i've the same problem. Only USB2.0 ports work. Any suggestion? Thanks anyway for your work. Link to comment Share on other sites More sharing options...
mfc88 Posted January 19, 2017 Share Posted January 19, 2017 Ok...finally i find time to test. With the first solution, TNF-EFI i've working graphics card renamed, working USB2 ports but front and read USB 3.0 and USB 3.1 don't work. So i tried the second DSDT as you suggested and i've the same problem. Only USB2.0 ports work. Any suggestion? Thanks anyway for your work. Send me an IOreg dump. Link to comment Share on other sites More sharing options...
mfc88 Posted January 19, 2017 Share Posted January 19, 2017 I attach here ioregdump without your DSDT (with usb injector kext enabled) and another with your DSDT in patched folder. Looks like the port injection system is a bit wonky. On my setup, using X99 Injector USB 3.kext, some ports are correctly identified as 3.0 and as 3.1 and while some show up as 2.0 (front panel), which is incorrect. When using the SSDT injection, 3.0 becomes invalid and never used, 3.1 works, and everything is lumped into 2.0 ports. Will have to ping nmano for more information. 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 19, 2017 Share Posted January 19, 2017 SSDT Work without X99 USB 3_Injector I tried to do this a long time ago but today I finally got a breakthrough. Just drop SSDT-XHC2.AML into EFI folder and add port limit patch in config.plist. Happy New Year to you all and don’t forget to like my post! Enjoy! This SSDT is not valid for all X99 motherboards. The USB mapping is incorrect!!!! When using the SSDT injection, USB 3.0 is never used, 3.1 works OK, and all other ports are lumped into 2.0 ports. The X99 Injector USB 3.kext is incorrect as well. For some reason it lumps my front panel ports into a USB 2.0 hub and lumps all my back panel 2.0 ports into a 3.0 Bus (while none of the 2.0 Buses are used)... Link to comment Share on other sites More sharing options...
NeXtor Posted January 19, 2017 Share Posted January 19, 2017 This SSDT is not valid for all X99 motherboards. The USB mapping is incorrect!!!! When using the SSDT injection, USB 3.0 is never used, 3.1 works OK, and all other ports are lumped into 2.0 ports. The X99 Injector USB 3.kext is very close to correct mapping, but for some reason lumps my front panel ports into a USB 2.0 hub... indeed, I also tried it and I had the same problems, I had to go back and I'm still looking for a final solution... Currently I'm having some problems during system boot... The system starts but the screen doesn't show anything, then restart and the system starts well. It seems as if not properly inject the GFX1 device Link to comment Share on other sites More sharing options...
mfc88 Posted January 20, 2017 Share Posted January 20, 2017 What system information and IOReg shows MIGHT be cosmetic... I'll have to look into it more... Looks like the ports are jumbled together. For example, _.SB.EH01.PR01 has both 2.0 ports and 3.0 ports. Not sure if this by design or by mistake. For now, I'd recommend X99 Injector USB 3.kext. 1 Link to comment Share on other sites More sharing options...
nmano Posted January 20, 2017 Author Share Posted January 20, 2017 I made SSDT_USB3 for some motherboard please test and report. #Test without any injector. SSDT_USB3_ASUS_GIgabyte.zip 2 Link to comment Share on other sites More sharing options...
Fergarth Posted January 20, 2017 Share Posted January 20, 2017 I made SSDT_USB3 for some motherboard please test and report. #Test without any injector. I'm curious to try this, but I have a question! The Patch for port limit is needed in Clover, right nmamo? By the way, what USB configuration do you recommend in Bios? I use smart auto, enable, enable, enable. Should I keep like this or change anything?Thank you friend. Link to comment Share on other sites More sharing options...
thenightflyer Posted January 20, 2017 Share Posted January 20, 2017 I made SSDT_USB3 for some motherboard please test and report. #Test without any injector. Dear friend, i tried but USB3 still doesn't work... This SSDT is not valid for all X99 motherboards. The USB mapping is incorrect!!!! When using the SSDT injection, USB 3.0 is never used, 3.1 works OK, and all other ports are lumped into 2.0 ports. The X99 Injector USB 3.kext is incorrect as well. For some reason it lumps my front panel ports into a USB 2.0 hub and lumps all my back panel 2.0 ports into a 3.0 Bus (while none of the 2.0 Buses are used)... Strange behaviour...maybe it's so but i don't know....if i put both your DSDT and SSDT-BR2A graphic card is renamed...if i put only SSDT-BR2A graphics card is no more renamed and seen as BR2A device in ioreg...must DSDT and SSDT be placed together to have my GPU renamed? 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 20, 2017 Share Posted January 20, 2017 Strange behaviour...maybe it's so but i don't know....if i put both your DSDT and SSDT-BR2A graphic card is renamed...if i put only SSDT-BR2A graphics card is no more renamed and seen as BR2A device in ioreg...must DSDT and SSDT be placed together to have my GPU renamed? The SSDT-BR2A.aml is working in conjunction with the modified DSDT.aml. For example, if your manufacturer already has a _DSM method at that particular location, it'll overwrite the SSDT (not the case here). However, in the case of Mac 6,1, it'll unload BR2A.H000(GFX0) (hence the black screen at boot up as your GPU will be unloaded). By renaming it to BR2A.GFX1, it'll unload GFX0 (which doesn't exist in the modified DSDT.aml), then load GFX1. The part that is renaming your particular GPU is in SSDT-BR2A.aml: "model", Buffer (0x34) { "NVIDIA GeForce GTX 680" }, For me, in the DSDT.aml at _SB.PCI0.BR3A, we've renamed devices H000 and H001 to H00Y(GFX1) and HDA1(HDAU) (this allows us to set up a placeholder in the DSDT for an SSDT injection): Device (H00Y) { Name (_ADR, Zero) Method (_SUN, 0, NotSerialized) { Return (SNUM ()) } } Device (HDA1) { Name (_ADR, One) Method (_SUN, 0, NotSerialized) { Return (SNUM ()) } } We'll also change the second location (DSDT._GPE._L01 -- or whatever is scoped to BR2A/BR3A/BR1A...etc) to match the above (you can do a search for "BR3A.H000" and it should return 2 results; the second result should show something similar to this): If (LNotEqual (Local0, 0xFF)) { Store (0x07, Local1) Notify (\_SB.PCI0.BR3A.H00Y, Local0) // changed from H000 to H00Y Notify (\_SB.PCI0.BR3A.HDA1, Local0) // changed from H001 to HDA1 Notify (\_SB.PCI0.BR3A.H002, Local0) Notify (\_SB.PCI0.BR3A.H003, Local0) Notify (\_SB.PCI0.BR3A.H004, Local0) Notify (\_SB.PCI0.BR3A.H005, Local0) Notify (\_SB.PCI0.BR3A.H006, Local0) Notify (\_SB.PCI0.BR3A.H007, Local0) } Then we hook H00Y and HDA1 (and remove the D07C device) and add our device info via SSDT-xxxx.aml : DefinitionBlock ("", "SSDT", 1, "mfc88", "ami99hdm", 0x00003000) { External (_SB_.PCI0.BR3A, DeviceObj) // GPU Tree Location External (_SB_.PCI0.BR3A.H00Y, DeviceObj) // DSDT H00Y (GPU Leaf Node) External (_SB_.PCI0.BR3A.HDA1, DeviceObj) // DSDT HDA1 (Audio Leaf Node) External (_SB_.PCI0.BR3A.D07C, DeviceObj) // DSDT device that needs to be removed External (DTGP, MethodObj) Scope (\_SB.PCI0.BR3A.H00Y) { Name (_STA, Zero) // _STA: Status } Scope (\_SB.PCI0.BR3A.HDA1) { Name (_STA, Zero) // _STA: Status } Scope (\_SB.PCI0.BR3A.D07C) { Name (_STA, Zero) // _STA: Status } Scope (\_SB.PCI0.BR3A) { Device (GFX1) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x28) { "hda-gfx", Buffer (0x0A) { "onboard-2" }, "AAPL,slot-name", Buffer (0x07) { "Slot-1" }, "@2,AAPL,boot-display", Buffer (One) { 0x02 }, "device-id", Buffer (0x04) { 0xC8, 0x17, 0x00, 0x00 }, "@0,name", Buffer (0x13) { "NVDA,Display-A" }, "@1,name", Buffer (0x13) { "NVDA,Display-B" }, "@2,name", Buffer (0x13) { "NVDA,Display-C" }, "@3,name", Buffer (0x13) { "NVDA,Display-D" }, "@4,name", Buffer (0x13) { "NVDA,Display-E" }, "@5,name", Buffer (0x13) { "NVDA,Display-F" }, "@0,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@1,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@2,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@3,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@4,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@5,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "rom-revision", Buffer (0x0F) { "84.06.2f.00.52" }, "model", Buffer (0x34) { "NVIDIA GeForce GTX 980 Ti" }, "name", Buffer (0x08) { "display" }, "reg-ltrovr", Buffer (0x08) { 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Device (HDAU) { Name (_ADR, One) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x0E) { "built-in", Buffer (One) { 0x00 }, "name", Buffer (0x05) { "HDAU" }, "AAPL,slot-name", Buffer (0x07) { "Slot-1" }, "device_type", Buffer (0x06) { "AUDIO" }, "name", Buffer (0x05) { "HDAU" }, "hda-gfx", Buffer (0x0A) { "onboard-2" }, "reg-ltrovr", Buffer (0x08) { 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } } So yes, you'll want it. 1 Link to comment Share on other sites More sharing options...
nmano Posted January 20, 2017 Author Share Posted January 20, 2017 I'm curious to try this, but I have a question! The Patch for port limit is needed in Clover, right nmamo? By the way, what USB configuration do you recommend in Bios? I use smart auto, enable, enable, enable. Should I keep like this or change anything? Thank you friend. just test with port limit patch and bios xhci enabled if your boot loader is usb3 if not smart auto. 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 21, 2017 Share Posted January 21, 2017 Just some more notes... SSDT-XHC2.aml only works when you set Intel xHCI Mode to Smart Auto/Auto. Setting this to Enabled, results in only USB 3.0s working. The rest of the options: eHCI Handoff, xHCI Handoff, Legacy eHCI Support are irrelevant because Smart Auto/Auto overrides their settings and provides xHCI/eHCI handoff to EH01/EH02 regardless of their BIOS settings. The problem with this is that all the USB ports (with the exception of the two 3.1 ports, since they're mapped to RP05.D082--away from EH01 and EH02) are lumped inside 2.0 Buses (the USB 3.0 Bus (XHCI) is never utilized). Through testing, this unfortunately... is not cosmetic, and sets all ports to 2.0 speed (for example, the "Flash Drive DUO" is a usb 3.0 that is forced to run at 2.0 speeds): As you can see here, the XHCI ports are not utilized (if it was, you'd see a device plugged into it), and instead all ports have been handed off to EH01/EH02 (you can't see from this screenshot, but all my USB devices are mapped inside these locations): X99 Injector USBHowever, I found a work-around. By removing any _DSM methods that were added to EH01, EH02, and XHCI in the DSDT.aml (for most of you, you probably won't have any in there to begin with), and as well as setting Intel xHCI mode to "Enabled" in the BIOS (the rest of the options will be: Disabled), we can achieve 3.0 speeds by bypassing xHCI/eHCI handoff and by setting all XHCI ports to 3.0 ports*** (this is done via X99_Injector USB 3.kext): ***2.0 ports will still function as is and will still be limited to 2.0 speeds. DSDT.aml may need ALL XHC/XHC1 devices, methods, scopes, etc to be renamed to XHCI (depends on which board you're using). Assuming you don't have a modified DSDT.aml, and if your USB ports aren't named XHCI, then you can use these DSDT Patches in your config.plist->ACPI->DSDT Patch (table at the top): Comment: Change XHC to XHCI Find: 5848435F Replace: 58484349 Comment: Change XHC1 to XHCI Find: 58484331 Replace: 58484349 Comment: Rename _DSM to XDSM Find: 5F44534D Replace: 5844534D You'll also need this in Kernel and KextsToPatch->KextsToPatch -- regardless of DSDT edit method: Name: AppleUSBXHCIPCI Find: 83BD74FFFFFF10 Replace: 83BD74FFFFFF16 Comment: Change 15 Port Limit To 22 in XHCI Kext 10.12(99-series) Or, if you do have a modified DSDT.aml... decompile your DSDT.aml, edit the decompiled DSDT.dsl, rename all "XHC" or "XHC1" ACPI locations to "XHCI", find any _DSMs scoped to XHC/XCH1 (if there are any) and rename them to XDSM, and then compile and save it as...Name: DSDT.amlLocation: DesktopFormat: ACPI Machine Language Binary Bypassing handoff (no more EH01/EH02) and utilizing XHCI ports: You should also notice quicker USB recognition (1-2 seconds max versus 5-10 seconds for the USB icon to show up on the desktop). X99_Injector USB 3.kext-XHCI.zip 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Boring videos showing the difference between SSDT-XHC2.aml port injection versus X99 Injector USB 3.kext port injection... SSDT-XHC2 (USB 2.0 Bus): https://youtu.be/OItPTY_nXpE X99 Injector USB 3 (USB 3.0 Bus): https://youtu.be/E0ic5Yip45s 2 Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Hi mfc88 thank you for your testing In my opinion also in USB3 video you have no thebest result you can achieve If you can try to test in both situation your usbdevice with black magic disk speed test (it is free) In my case I have a value for usb 2 of about 35/40 mb/s for usb3 a value of about 115/120 Mb/s and this are in my case a correct value You may be right... 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Ok now it is right I see you changed attached pictures Those number are correct imho Running USB 3.0... should be 120 megabytes, no? Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 So it looks like I'm still getting USB 2.0 speeds. Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Yes if you look in write speed , read is fine What are you using to inject USB 3.0 ports? Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Only USB inject all kext No dsdt no other patches only 15 to 30 port limits This with rampage v With dual asus z10 pe..no usb inject kext needed Installed via Clover or S/L/E or L/E? Installed via Clover... Same issue -- most likely a compatibility issue with ASmedia: USB 3.0 in USB 3.0 slot: USB 3.0 in USB 2.0 slot: USB 2.0 in USB 3.0 slot: USB 2.0 in USB 2.0 slot: Link to comment Share on other sites More sharing options...
nmano Posted January 22, 2017 Author Share Posted January 22, 2017 DSDT Work without X99 USB 3_Injector FIND Device (RHUB) { Name (_ADR, Zero) // _ADR: Address Replace Device (RHUB) { Name (_ADR, 0x14000000) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x06) { "name", Buffer (0x05) { "XHCI" }, "model", Buffer (0x0A) { "MacPro6,1" }, "port-count", Buffer (0x04) { 0x15, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } #test with port limit patch. 2 Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 maybe it is not relevant but you can try in bios to set smartauto/enabled or viceversa I have asmedia chipset too but i have not that behaviour No difference. Same slow write speeds. Edit: Should have just read the specs on the USB drive. Looks like it's only rated for 45 Mb/s writes... so much for "USB 3.0". Link to comment Share on other sites More sharing options...
Brumbaer Posted January 22, 2017 Share Posted January 22, 2017 Everything is in order. The stick is not better than that. USB devices will not switch from SuperSpeed (USB 3.0) to HighSpeed (2.0) or vice versa while operating. If it reads using SS it will write using SS as well. Using USB 3.0 does not mean that the device must be fast. Driving a slow car on a high way doesn't make it faster, the high way only allows a faster car to use it's faster speed. That's what you are seeing. The stick reads fast and writes slow. If you want higher write speeds buy a more modern, higher capacity stick. Sadly manufacturers don't specify sustained write speeds anymore, but only peak speeds. The stick will write up to 130MB/s, but only if it's write cache is empty. As soon as the cache is full the speeds will drop in this case to 30MB/s. 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 22, 2017 Share Posted January 22, 2017 Everything is in order. The stick is not better than that. USB devices will not switch from SuperSpeed (USB 3.0) to HighSpeed (2.0) or vice versa while operating. If it reads using SS it will write using SS as well. Using USB 3.0 does not mean that the device must be fast. Driving a slow car on a high way doesn't make it faster, the high way only allows a faster car to use it's faster speed. That's what you are seeing. The stick reads fast and writes slow. If you want higher write speeds buy a more modern, higher capacity stick. Sadly manufacturers don't specify sustained write speeds anymore, but only peak speeds. The stick will write up to 130MB/s, but only if it's write cache is empty. As soon as the cache is full the speeds will drop in this case to 30MB/s. Thanks for the follow up! I took a look at some random Amazon 3.0 drives and most were tested to be within a sustained 30-45 megaBYTE max write range. I guess I suspected higher write speeds in the SSD age... oh well, I'll be looking for another flash drive soon... Link to comment Share on other sites More sharing options...
nmano Posted January 23, 2017 Author Share Posted January 23, 2017 Its worked without any patches. with adappter. SM951: Name: AHCI Type: AHCI Controller Driver Installed: Yes MSI: Yes Bus: PCI Slot: PCI Slot 4 Vendor ID: 0x144d Device ID: 0xa801 Subsystem Vendor ID: 0x144d Subsystem ID: 0xa801 Revision ID: 0x0001 Link Width: x4 Link Speed: 8.0 GT/s 1 Link to comment Share on other sites More sharing options...
mfc88 Posted January 23, 2017 Share Posted January 23, 2017 Just a small update: Currently using Rehabman's USBInjectAll.kext + XHCI-x99-injector.kext with a custom SSDT-UIAC.aml. This way, I no longer need the AppleUSBXHCIPCI 15 to 22/27/31 limit port patch. Instead of injecting all ports spread across EH01/EH02/XHCI, which most of these ports aren't used at all, instead I only have 12 ports injected into XHC. I highly recommend this method as it's more precise to which ports will be in use and whether or not the port is 2.0, 3.0 or internal (since 10.12, USB 3.1 ports should be natively supported). I've included a starter kit: Kexts that you need to install to EFI->CLOVER->Kexts->10.12, a SSDT-UIAC.dsl template, and IORegistry Explorer 2.1, which you can use in conjunction with this brief guide OR Rehabman's in-depth SSDT for USBInjectAll.kext guide Requirements:- Set up your BIOS Under Advanced / USB Configuration: Intel XHCI Mode - Enable EHCI Legacy Support - Disabled XHCI Hand-off - Disabled EHCI Hand-off - Disabled - DSDT.aml => XHCI/XHC1 must be named XHC (for most of you, you'll probably need to use one of the patches below OR if you have a custom DSDT.aml, then rename the device and any references from XHC1/XHCI to XHC by hand)*** Note 1: If you're curious to know exactly which Clover DSDT patch for your config.plist that you'll need, simply start up your computer, while at the Clover Boot Manager screen, press F4 to dump your ACPI tables. Wait 5 seconds, then boot into your OS. Next, mount your primary SSD drive (the one you just booted into) with Clover Configurator then click "Open Partition". Find and open this file with MaciASL: EFI->CLOVER->ACPI->origin->DSDT.aml. In MaciASL, Press ⌘ + F, then type "XHC". Hit the ">" to scroll through the results until it stops on "Device (XHC_)". Then you'll know which patch to use: For example, device XHCI and corresponding config.plist DSDT patch config.plist DSDT patches: Comment: Change XHCI to XHC Find: 58484349 Replace: 5848435F Comment: Change XHC1 to XHC Find: 58484331 Replace: 5848435F - You will also need an AppleUSBXHCIPCI 15 to xx port limit patch in your config.plist (under KextsToPatch): Note 2: You can find out which patch you'll need by using MaciASL and searching in your DSDT.aml for "RHUB", then counting the HSxx + SSxx + USxx ports (add 1 extra port since port address "0x0F" aka port #15 is not used): ExampleNote 3: Where to add the USB port limit patch to your config.plist: Example Name: AppleUSBXHCIPCI Find: 83BD74FFFFFF10 Replace: 83BD74FFFFFF16 Comment: Change 15 Port Limit To 22 in XHCI 10.12 OR if your board has more than 22: Name: AppleUSBXHCIPCI Find: 83BD74FFFFFF10 Replace: 83BD74FFFFFF1B Comment: Change 15 Port Limit To 27 in XHCI 10.12 OR if your board has more than 27: Name: AppleUSBXHCIPCI Find: 83BD74FFFFFF10 Replace: 83BD74FFFFFF1F Comment: Change 15 Port Limit To 31 in XHCI 10.12 -IORegistry Explorer 2.1 (provided in Starter Kit) Summary:1.) With USBInjectAll and XHCI-x99-injector.kext loaded in EFI->CLOVER->kexts->10.12 or System/Library/Extensions via Kext Utility, and with the USB port limit patch already in your config.plist (requires an OS reboot to take affect), load up IOReg 2.1 2.) Do a search for "usb" 3.) You'll notice you'll have HS01 to SSP6 (or something similar) injected into XHC; however, now comes the task of narrowing down which ones your motherboard/computer case USBs are mapped to. 4.) Plug in a USB 3.0 device into a USB 3.0 port, find that mapped location by looking for the device in IOReg, then eject it. Write down the location (SSxx). Next, plug in a USB 2.0 device and find the other mapped location by looking for that device. Write down the location (HSxx). USB 3.0 ports will have two locations: a SSxx location and a HSxx location AND both locations will also have a connector value of 3 regardless of the device that is plugged in! Note 4: If you have trouble locating where the device is mapped, click the Apple Icon on the top left, select "About This Mac", click "System Report", click on the "USB" tab, look at the "Location ID" (eg. 0x14400000) and in IOReg look for that same address (in this case, the m9xx device is mapped to HS06 @ 0x14400000):5.) Rinse and repeat until you've eliminated all possible USB mapped locations Note: USB 2.0 ports will only be mapped to one HSxx location, so no need to test 3.0 devices in a 2.0 port, and will have a connector value of 0 regardless of the device that is plugged in! Note: USB "Hubs" that come packaged with the motherboard should have a connector value of 255 regardless of the device. Note: USB "Hubs" external to the motherboard should have a connector value of 0 or 3. Note: Make sure you include external devices that are already plugged in to the motherboard. Like your keyboard, mouse, DAC, ... etc. Any external devices mapped to a port location will need to be included and should have a connector value of 0 or 3. Also include devices that internal devices like: WIFI, bluetooth, thunderbolt devices or USB 2.0 or USB 3.0 HUBS (as mentioned above, anything that is packaged/included in the motherboard will have a connector value of 255 regardless). 6.) After you've eliminated all possible USB mapped locations, open up the provided SSDT-UIAC.dsl with MaciASL (to set up MaciASL, follow this guide up to step 6). Note 5: I've included a "USB-Mapped-Ports" text file that gives you a basic idea of my particular USB layout. I'd recommend you do something similar to make your life easier and to keep track of everything 7.) Using the provided SSDT-UIAC.dsl as a template, input XHC's PCI compatible ID (see note below for how to find it), the injected port count (RHUB+1), the USB mapped location (for example, HS01,HS02, HS03...etc), the connector value (connector values will be: 3 for USB 3.0; 0 for USB 2.0; and 255 for built-in), and the port number's hex address (it'll correspond to the port in hex). Note 6: You can find XHC's PCI compatible ID by using IOReg: Example (note that in our SSDT-UIAC.dsl that we remove "pci" and use a _ (underscore) instead of a , (comma). You don't have to use the PCI compatible ID!! You can use "XHC" instead, but I prefer the ID.Note 7: My injected port count is 21 ports (or 15 hex), which is what I've used in the SSDT-UIAC.dsl's "port-count" (you can count how many you have by counting how many are listed in RHUB + 1). The actual ports in use for my setup is 14 ports (12 in XHC and 2 in RP05 -- RP05 ports are the USB 3.1 ports natively supported by Sierra). If you have more than 15 ports mapped that are in use in XHC, then you may have to utilize EHCI, and/or you may have to keep the 22/27/31 port limit patch in use, which is beyond the scope of this brief summary.Note 8: You can find the port's hex address by using IOReg or (if applicable) by using the list below: Example Here's a port hex list (may or may not apply to your particular board)... =============================== Port | Hex | Decimal =============================== HS01 === 0x01 | (1) HS02 === 0x02 | (2) HS03 === 0x03 | (3) HS04 === 0x04 | (4) HS05 === 0x05 | (5) HS06 === 0x06 | (6) HS07 === 0x07 | (7) HS08 === 0x08 | (8) HS09 === 0x09 | (9) HS10 === 0x0A | (10) HS11 === 0x0B | (11) HS12 === 0x0C | (12) HS13 === 0x0D | (13) HS14 === 0x0E | (14) XXXX === 0x0F | (15) -- NOT USED SSP1 === 0x10 | (16) SSP2 === 0x11 | (17) SSP3 === 0x12 | (18) SSP4 === 0x13 | (19) SSP5 === 0x14 | (20) SSP6 === 0x15 | (21) ------------------ 0x15 = 21 ports (15 in hexadecimal => 21 in decimal -- note: port hex address 0x0F is not used! ) =============================== Port | Hex | Decimal =============================== HS01 === 0x01 | (1) HS02 === 0x02 | (2) HS03 === 0x03 | (3) HS04 === 0x04 | (4) HS05 === 0x05 | (5) HS06 === 0x06 | (6) HS07 === 0x07 | (7) HS08 === 0x08 | (8) HS09 === 0x09 | (9) HS10 === 0x0A | (10) HS11 === 0x0B | (11) HS12 === 0x0C | (12) HS13 === 0x0D | (13) HS14 === 0x0E | (14) XXXX === 0x0F | (15) -- NOT USED USR1 === 0x10 | (16) USR2 === 0x11 | (17) SS01 === 0x12 | (18) SS02 === 0x13 | (19) SS03 === 0x14 | (20) SS04 === 0x15 | (21) SS05 === 0x16 | (22) SS06 === 0x17 | (23) SS07 === 0x18 | (24) SS08 === 0x19 | (25) SS09 === 0x1A | (26) SS10 === 0x1B | (27) ------------------ 0x1B = 27 ports (1B in hexadecimal => 27 in decimal -- note: port hex address 0x0F is not used!) An example of HS01 injected as a 3.0 USB port (notice that the UsbConnector is 3 and the port (in hex) is 0x01): "HS01", Package() { "UsbConnector", 3, "port", Buffer() { 0x01, 0, 0, 0 }, }, An example of HS14 injected as a USB 2.0 port (notice that the UsbConnector is 0 (USB 2.0) and the port (in hex) is 0x0E): "HS14", Package() { "UsbConnector", 0, "port", Buffer() { 0x0E, 0, 0, 0 }, }, An example of SS06 injected as an internal USB port (notice that the UsbConnector is 255 and the port (in hex) is 0x15): "SS06", Package() { "UsbConnector", 255, "port", Buffer() { 0x15, 0, 0, 0 }, }, Here's what my complete SSDT-UAIC.aml looks like: DefinitionBlock ("", "SSDT", 2, "hack", "UIAC", 0x00000000) { Device (UIAC) { Name (_HID, "UIA00000") // _HID: Hardware ID (leave this as-is) Name (RMCF, Package (0x02) { "8086_8d31", // PCI compatible ID Package (0x04) { "port-count", Buffer (0x04) { 0x15, 0x00, 0x00, 0x00 // The amount of ports RHUB+1 has }, "ports", // where we begin to inject our mapped ports Package () { "HS01", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 } }, "HS02", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x02, 0x00, 0x00, 0x00 } }, "HS05", Package (0x04) { "UsbConnector", Zero, "port", Buffer (0x04) { 0x05, 0x00, 0x00, 0x00 } }, "HS06", Package (0x04) { "UsbConnector", 0, "port", Buffer (0x04) { 0x06, 0x00, 0x00, 0x00 } }, "HS09", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x09, 0x00, 0x00, 0x00 } }, "HS10", Package (0x04) { "UsbConnector", 255, "port", Buffer (0x04) { 0x0A, 0x00, 0x00, 0x00 } }, "HS11", Package (0x04) { "UsbConnector", 255, "port", Buffer (0x04) { 0x0B, 0x00, 0x00, 0x00 } }, "HS13", Package (0x04) { "UsbConnector", Zero, "port", Buffer (0x04) { 0x0D, 0x00, 0x00, 0x00 } }, "HS14", Package (0x04) { "UsbConnector", Zero, "port", Buffer (0x04) { 0x0E, 0x00, 0x00, 0x00 } }, "SSP1", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x10, 0x00, 0x00, 0x00 } }, "SSP2", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x11, 0x00, 0x00, 0x00 } }, "SSP5", Package (0x04) { "UsbConnector", 0x03, "port", Buffer (0x04) { 0x14, 0x00, 0x00, 0x00 } }, "SSP6", Package (0x04) { "UsbConnector", 255, "port", Buffer (0x04) { 0x15, 0x00, 0x00, 0x00 } } } } }) } } 8.) Once you've added all mapped ports that are in use (exclude ports that are NOT used) in the .dsl, compile it and make sure you don't have any errors. Now save it:Save as: SSDT-UIAC.amlWhere: DesktopFile Format: ACPI Machine Language Binary 9.) Add this SSDT into EFI->CLOVER->ACPI->patched (if you're using sorted tables, you'll need to add this SSDT to the sorted list in your config.plist) 10.) Open your config.plist and disable the AppleUSBXHCIPCI 15 to 22/27/31 port limit patch. Now, reboot and boot back into your OS. Open up IOReg 2.1, search for usb, and now your tree should look condensed to the ports you've specified in the SSDT: 11.) Now that you have your USBs mapped and injected, you'll now need to add power options to them, so that you can use them for charging your USB devices. We'll be adding power options via a SSDT-XHC.aml (I've included a SSDT-XHC.dsl for you to compile): Note 9: If you're not using an x99 motherboard, then you'll need to change the "device-id" (necessary) and you may want rename the "model" to your USB xHC Host Controller (optional as this just for show). Note 10: You can find XHC's device id by using IOReg: Example Note 11: For "AAPL,device-internal," make sure you specify how many devices are internal in your SSDT-UIAC.aml DefinitionBlock ("", "SSDT", 2, "mfc88", "XHC", 0x00000000) { External (_SB_.PCI0.XHC_, DeviceObj) // (from opcode) Method (_SB.PCI0.XHC._DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LNot (Arg2)) { Return (Buffer (One) { 0x03 }) } Return (Package () { "device-id", Buffer (0x04) { 0x31, 0x8D, 0x00, 0x00 // make sure this matches XHC's device ID }, "name", Buffer () { "Intel XHC Controller" }, "model", Buffer () { "Intel 99 Series Chipset Family USB xHC Host Controller" // optional: rename to your motherboard's xHC Host Controller name }, "AAPL,current-available", 0x0834, "AAPL,current-extra", 0x0A8C, "AAPL,current-in-sleep", 0x0A8C, "AAPL,max-port-current-in-sleep", 0x0834, "AAPL,device-internal", 0x00, Buffer (One) { 0x00 }, "AAPL,clock-id", Buffer (One) { 0x01 } }) } } When done correctly (injected ports with power options): *** Note if you plan on using eHCI locations (in the example above, I'm not), you'll need to rename EHC1 to EH01 and EHC2 to EH02 via DSDT.aml edit or Clover DSDT patches (that way it'll work in conjunction with the UsbInjectAll kext). You'll also need use: Fake_PCIID.kext + FakePCIID_XHCIMux.kext (together these two kexts map HSxx (usb 2.0) ports from XHC to EH01/EH02), which you download together from: here (Important: Only use the two Fake kexts mentioned above in conjunction with USBInjectAll and XHCI-x99-injector!!) Lastly, you may need to need to adjust your BIOS for proper xHCI handoff to eHCI. Check Rehabman's guide for more information. USB Injection Starter Kit.zip 4 Link to comment Share on other sites More sharing options...
Recommended Posts