Jump to content
42 posts in this topic

Recommended Posts

I am in Yosemite so that the experts can see what Yosemite reports for USB 3.0

On Board Graphics disabled.

 

they show as follows in Yosemite.

 

USB 3.0 Hi-Speed Bus

   Hub  Product ID: 0x0209  Vendor ID: 0x045B  (Renesas Electronics Corp.)  Location ID: 0x14900000 / 2

      keyboard - back

      mouse - back

      Iphone - front

   Hub  Product ID: 0x0209  Vendor ID: 0x045B  (Renesas Electronics Corp.)  Location ID: 0x14A00000 / 1

      Traktor Audio 2

USB 3.0 Super-Speed Bus

   Hub - Product ID: 0x0210 Vendor ID: 0x045B (Reneses Electronic Corp)  Location ID: 0x15600000 / 4

   Hub - Product ID: 0x0210 Vendor ID: 0x045B (Reneses Electronic Corp)  Location ID: 0x15500000 / 3

USB 3.0 Hi-Speed Bus

   Hub - Product ID: 0x8008  Vendor ID: 0x8087  (Intel Corporation) Location ID: 0x1A100000 / 2

USB 3.0 Hi-Speed Bus

   Hub - Product ID: 0x8008  Vendor ID: 0x8087  (Intel Corporation) Location ID: 0x1D100000 / 2

 

How they are shown in El Capitan

 

USB 2.0 Bus - Host Controller Driver: AppleUSBEHCIPCI PCI Device ID: 0x8c2d PCI Revision ID: 0x0005 PCI Vendor ID: 0x8086 

   Hub - Product ID: 0x8008  Vendor ID: 0x8087  (Intel Corporation) Location ID: 0x1A100000 / 1

USB 2.0 Bus

   Hub - Product ID: 0x8008  Vendor ID: 0x8087  (Intel Corporation) Location ID: 0x1D100000 / 1

XHC Host Controller Driver: AppleUSBXHCILPTH PCI Device ID: 0x8C31 PCI revision ID: 0x0005 PCI Vendor ID: 0x8086

   Hub - Hub  Product ID: 0x0209  Vendor ID: 0x045B  (Renesas Electronics Corp.)  Location ID: 0x14A00000 / 2

    USB keyboard

    USB mouse

    iPhone

  Hub - Hub  Product ID: 0x0209  Vendor ID: 0x045B  (Renesas Electronics Corp.)  Location ID: 0x14900000 / 2

 
Not using a DSDT Since Yosemite does not need one.
What is the best way to get USB 3.0 working on dev beta 3
 
I did get it to recognize a USB 3.0 thumb drive a couple of times, one time each after a reboot. rest of my devices are 2.0 
 
 
 
 
Link to comment
https://www.insanelymac.com/forum/topic/307091-usb-30-issue-in-el-capitan/
Share on other sites

hello

 

take a look here

 

     [GUIDE] USB Fix El Capitan 10.11    

 

and here

 

with fakepci 

 

 

  •  

  • FakePCIID_XHCIMux.kext This kext will attach to 8086:1e31, 8086:9c31, 8086:9cb1, 8086:9c31, and 8086:8cb1 This injector is a bit of an extension to normal FakePCIID duties. It doesn't actually fake any PCI IDs. Rather, it forces certain values to XUSB2PR (PCI config offset 0xD0) on the Intel XHCI USB3 controller. The effect is to route any USB2 devices attached to the USB2 pins on the XHC ports to EHC1. In other words, handle USB2 devices with the USB2 drivers instead of the USB3 drivers (AppleUSBEHCI vs. AppleUSBXHCI).

So normally what is a complex "multiplex" DSDT patch (that is not well understood), is a simple kext install.

Configuration properties and their defaults: RM,pr2-force . By default forces all XHCI ports to route USB2 devices to EHC1. RM,pr2-init . Will write RM,pr2-force value at startup if non-zero. RM,pr2-block . Will block writes to XUSB2PR if non-zero. RM,pr2m-block . No evidence that OS X drivers attempt to write XUSB2PRM (offset 0xD4), but since this kext relies on a valid value here (as provided by the BIOS), writes to it are blocked if non-zero. RM,pr2-honor-pr2m : Changes to XUSB2PR will be masked by XUSB2PRM if this is non-zero. RM,pr2-chipset-mask: Writes to XUSB2PR are masked by this value. This is defined by the chipset documentation. Default value depends on chipset.

Refer to Intel 7/8/9-series chipset data sheet for more info.

 

 

 
 
good hack

@VCH8888

 

I tried each dummy kext by itself but not together (didn't realize I needed both) and didn't know about the dummyXHC-6 ports kext

Installed all three now it works but has 2 issues:

The USB 3.0 flash drive works and can insert and remove it (after ejecting) but when I open system profiler it shows the hub that it is plugged into with the down arrow but line that would say flash drive or such is blank in system profiler but the details are shown in lower window

 

The other thing I thought FakePCIID_XHCIMux would eliminate any usb 2.0 ports being listed and the listed usb 2.0 ports and hubs are actually USB 3.0

 

 

System Profiler USB 3.0.tiff

@VCH8888

 

I tried each dummy kext by itself but not together (didn't realize I needed both) and didn't know about the dummyXHC-6 ports kext

Installed all three now it works but has 2 issues:

The USB 3.0 flash drive works and can insert and remove it (after ejecting) but when I open system profiler it shows the hub that it is plugged into with the down arrow but line that would say flash drive or such is blank in system profiler but the details are shown in lower window

 

The other thing I thought FakePCIID_XHCIMux would eliminate any usb 2.0 ports being listed and the listed usb 2.0 ports and hubs are actually USB 3.0

 

 

attachicon.gifSystem Profiler USB 3.0.tiff

XHCIMux simply routes USB2 ports on XHC to EHC1.

 

XHC ports are actually two ports in one. USB3 and USB2. The question is what to do with the USB2 part of an XHC port...

I wonder if El Capitan splits the USB 2.0 and 3.0 into separate lists and just places all USB 2.0/1.1 devices into USB 2.0 lists and any USB 3.0 device into the USB 3.0 lists. That is what it looks like to me.

 

No matter where I plug my USB 3.0 memory stick (a MicroCenter branded 

Looks like I have editing to do but not sure what or where

the ports on the back of the motherboard are all listed as usb 2.0

 

I rather not have to mess with a DSDT if I don't need to 

Also can't figure how I would use Mac Mini 7,1 as shown clover has not made it available as a predefined SMBIOS yet.

Currently using MacPro 6,1

This is what I do...

 

Rename in DSDT: EHC1->EH01, EHC2->EH02, leave XHC as XHC, but if it is already XHC1, rename XHC1->XHC.

 

Now you have control over the ports because Apple uses EHC1/EHC2/XHC1.

 

Then build a custom port injector kext for your EH01/EH02/XHC ports (simple injector, not "dummy" kext).

 

Also, DSDT code plays a role. Because some DSDTs manipulate XHC registers (especially as it relates to XHC->EHC1 routing), and XHCIMux cannot stop it (ACPI doesn't go through the IOPCIDevice interface), DSDT code can manipulate the registers in way the XHC driver in OS X doesn't expect, resulting in USB not working after sleep. The fix in this case is to disable/delete the code in DSDT responsible (commonly XWAK, XSEL, ESEL).

I use clover to create the DSDT (F4 at OS selection)

Also never done a custom injector before, except a utility that would create a hex injection into chameleon for nVidia 8400GS can't remember what it was called.

 

The one from clover won't even recompile

 

I am getting 3 errors

 

Line       Code    Error

7100      6126    syntax error, unexpected PARSE_ZERO

11440    6126    syntax error, unexpected '}'

14759    6126    syntax error, unexpected $end and premature End-Of-File

 

lines from DSDT.dsl

 

Line         text

 

7100        Zero

 

11434      Method (ADBG, 1, Serialized)
11435      {
11436            If (CondRefOf (MDBG))
11437                      {
11438                                Return (MDBG) /* External reference */
11439                                Arg0
11440                        }
11441
11442                       Return (Zero)
11443      }
 
14758      }
14759 

DSDT.zip

I use clover to create the DSDT (F4 at OS selection)

Also never done a custom injector before, except a utility that would create a hex injection into chameleon for nVidia 8400GS can't remember what it was called.

 

The one from clover won't even recompile

 

I am getting 3 errors

 

Line       Code    Error

7100      6126    syntax error, unexpected PARSE_ZERO

11440    6126    syntax error, unexpected '}'

14759    6126    syntax error, unexpected $end and premature End-Of-File

 

lines from DSDT.dsl

 

Line         text

 

7100        Zero

 

11434      Method (ADBG, 1, Serialized)

11435      {

11436            If (CondRefOf (MDBG))

11437                      {

11438                                Return (MDBG) /* External reference */

11439                                Arg0

11440                        }

11441

11442                       Return (Zero)

11443      }

 

14758      }

14759

From here: https://github.com/RehabMan/Laptop-DSDT-Patch

 

Apply:

"Fix ADBG Error"

"Fix PARSEOP_ZERO Error"

"Fix *pnp/pnp lower case Error"

 

Remove the remaining lines causing errors (83-86).

@ foster

 

Did you try to use FakePCIID.kext + FakePCIID_XHCIMux.kext for 10.10 & 10.11 and DummyHXCI-6ports for 10.11?

 

attachicon.gifinfo.jpg

 

Edit XHC to XHC1 in dsdt.

 

You should get all working ports. 

 

from (naiclub's) Z87X-UD3H & 10.11

attachicon.gifZ87X-UD3H.jpg

 

Thanks VCH888 it's working nicely with FakePCIID.kext + FakePCIID_XHCIMux.kext. Any chance you could add a multiplexing patch for FL1100 USB 3.0 chipset to the XHCIMux.kext? 

 

I really appreciate the information you make available on the forum, thanks for sharing your knowledge!

 

(Thanks also to all other great people such as Rehabman who make it possible for us to run this great OS on our machines).

 

/CS

Thanks VCH888 it's working nicely with FakePCIID.kext + FakePCIID_XHCIMux.kext. Any chance you could add a multiplexing patch for FL1100 USB 3.0 chipset to the XHCIMux.kext?

Is there support in 10.11 for FL1100?

Do you have a datasheet?

 

Since the USB2 routing feature of Intel XHC involves both the XHC and EHC controllers (both by Intel), it would seem unlikely the same mechanism could be present with a non-Intel XHC chipset.

Went back to DSDT that works without any naming edits and just renamed XHC to XHC1, leaving EHC1 and EHC2 unchanged to fix the invalid naming in System Profiler

 

Okay figured no matter how much I mess with EHC in DSDT, OS X is going to assign some ports to it.

 

I just tried to edit EHC! and EHC2 from DSDT, OS X renamed USB 2.0 Bus in the USB Tree to AppleUSBEHCIPCI

 

Should I try particular SMBIOS and work in it or figure out how the ports are labeled in DSDT and translate to the Info.plist section for MacPro 6,1

 

RHUB has HS01 to HS15 and SSP1 to SSP6

 

This is what I figured out by experimenting depending on what port is being used by particular USB device (1.1/2.0 or 3.0) it will place the device in the 2.0 or 3.0 portion of the tree. Example no matter where my AZIO Gaming keyboard (blue switches and white backlit) and Gigabyte Force M7 Mouse are plugged in they are always under USB 2.0 and when I connect a USB 3.0 drive it always under 3.0, it did glitch one time and not init the USB 3.0 drive as 3.0 and placed under 2.0 but that was only one time.

DSDT.aml.zip

IOReg.txt.zip

Went back to DSDT that works without any naming edits and just renamed XHC to XHC1, leaving EHC1 and EHC2 unchanged to fix the invalid naming in System Profiler

 

Okay figured no matter how much I mess with EHC in DSDT, OS X is going to assign some ports to it.

 

I just tried to edit EHC! and EHC2 from DSDT, OS X renamed USB 2.0 Bus in the USB Tree to AppleUSBEHCIPCI

 

Should I try particular SMBIOS and work in it or figure out how the ports are labeled in DSDT and translate to the Info.plist section for MacPro 6,1

 

RHUB has HS01 to HS15 and SSP1 to SSP6

 

This is what I figured out by experimenting depending on what port is being used by particular USB device (1.1/2.0 or 3.0) it will place the device in the 2.0 or 3.0 portion of the tree. Example no matter where my AZIO Gaming keyboard (blue switches and white backlit) and Gigabyte Force M7 Mouse are plugged in they are always under USB 2.0 and when I connect a USB 3.0 drive it always under 3.0, it did glitch one time and not init the USB 3.0 drive as 3.0 and placed under 2.0 but that was only one time.

By renaming EHC1->EH01, EHC2->EH02, and keeping XHC, you can take control of the ports available with your own port injector kext.

 

It is the best way.

I rename ECH1 to EC01 and ECH2 to EC02, then AppleUSBECHIPCI just names them EC01 and EC02 in USB Tree instead of USB 2.0

AppleUSBECHIPCI is going to find them no matter what due to Vendor and Product ID matching

 

I need to know exactly what to edit and how to match my system other than DSDT (which I have to change ECH in 6-8 places or no compile)

That is why I included DSDT and IOReg

The more details the better

 

I don't know how my ports are enumerated (my DSDT does not look anything like the examples) 

I rename ECH1 to EC01 and ECH2 to EC02, then AppleUSBECHIPCI just names them EC01 and EC02 in USB Tree instead of USB 2.0

AppleUSBECHIPCI is going to find them no matter what due to Vendor and Product ID matching

Renaming avoids them matching against an existing port injector for real Macs.

 

I need to know exactly what to edit and how to match my system other than DSDT (which I have to change ECH in 6-8 places or no compile)

That is why I included DSDT and IOReg

The more details the better

 

I don't know how my ports are enumerated (my DSDT does not look anything like the examples)

I see nothing atypical in your DSDT.

 

For port injector examples, refer to my u430 and Probook repos:

 

https://github.com/RehabMan/Lenovo-U430-Touch-DSDT-Patch

 

https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch

 

Also, envy/y50 repos:

 

https://github.com/RehabMan/HP-Envy-K-DSDT-Patch

 

https://github.com/RehabMan/HP-Envy-DSDT-Patch

 

https://github.com/RehabMan/Lenovo-Y50-DSDT-Patch

 

You can get a rough idea as to which ports are active by looking in ioreg IOACPIPlane.

Re-edited DSDT so that XHC1 > XHC, EHC1 > EH01, EHC2 > EH02

XHC shows as XHC1 in IOReg, why?

 

Edited the Info.plist for AppleUSBEHCIPCI  IOKitProperties/MacPro6,1/IOProviderMergerProperties/port-count=0

Since it was acting like the dummy kext injection was not working, direct editing has no effect either.

A port-count=0 should mean no ports to be assigned to ECHI kexts.

 

So why is AppleUSBECHIPCI kext still grabbing ports and assigning them to USB 2.0 bus (now named EH01 and EH02 on my system),

i have double checked my SMBIOS is set to MacPro6,1

×
×
  • Create New...