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

wundorn
wundorn
Posted
Posted

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

Ah, now I see. The changes to XHC are not so obvious, but they exist.

 

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.

This is the same SSDT-HACK as in OS-X-USB-Inject-All-master? Let me see if I understand this...

 

Is it correct that _OSI is a method provided by firmware, by which the OS can ID itself to the firmware? I'm less clear on this: Does this then allow the firmware to behave differently in other ACPI methods? For example, ports that are USB3 reporting as USB2 for compatibility with older OSes that don't grok USB3?

 

I had the _OSI->XOSI patch in my config.plist when I first put in the patches for EHC1/EHC2, and the machine wouldn't boot. I'm guessing that that's because the OS called the firmware with _OSI, it got rewritten to XOSI, and there was nothing to handle that since I didn't have the SSDT-HACK in place?

 

Lastly... given all this, and my slowly growing understanding of the underlying issues, why:

- does the very first disk/flash I plug in run at 5gbps, attached to SSPx, though nothing else does?

- does my gigabit ethernet always attach to SSPx correctly, even though my disks don't?

 

The second of those two might be less inexplicable - it's a device with a builtin USB3 hub, and that too always runs at 5gbps, so I imagine the way that hubs get attached avoids the whole SSP vs. HSP thing, and then the Ethernet attached to new hub. Testing this and looking with ioreg... Hm, I'm half right. The ethernet does attach to the new hub. But... that hub is attached to SSP2. So the second question then becomes:

- Why does my USB3 hub always attach to SSPx? (Not that I mind!)

 

In any case, that first-attach-after-boot-runs-at-5gbps thing seems very mysterious.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

This is the same SSDT-HACK as in OS-X-USB-Inject-All-master?

Yes.

 

Is it correct that _OSI is a method provided by firmware, by which the OS can ID itself to the firmware?

No. _OSI is provided by the ACPI host (eg. OS X, Windows, Linux, etc).

 

It is called from ACPI code provided by the OEM to determine which OS it is running on.

 

I'm less clear on this: Does this then allow the firmware to behave differently in other ACPI methods?

Yes.

 

For example, ports that are USB3 reporting as USB2 for compatibility with older OSes that don't grok USB3?

More than reporting. For an old system, DSDT can disable USB3 ports, and route all USB2 ports to EHCI (via chipset configuration). It allows backward compatibility with a system that has no XCHI drivers as you'd still be able to plug in a USB3 device into a USB3 port and have it recognized as USB2 as if there was no XHCI controller and only EHCI.

 

I had the _OSI->XOSI patch in my config.plist when I first put in the patches for EHC1/EHC2, and the machine wouldn't boot.

When you use _OSI->XOSI, you also *must* include the SSDT that defines XOSI. Otherwise, calls to _OSI cause an APCI abort (as the XOSI method doesn't exist).

 

I'm guessing that that's because the OS called the firmware with _OSI, it got rewritten to XOSI, and there was nothing to handle that since I didn't have the SSDT-HACK in place?

Yes.

 

Lastly... given all this, and my slowly growing understanding of the underlying issues, why:

- does the very first disk/flash I plug in run at 5gbps, attached to SSPx, though nothing else does?

Maybe the other SSPx ports are not injected. You didn't specify what 'x' is and I don't see an ioreg demonstrating.

 

- does my gigabit ethernet always attach to SSPx correctly, even though my disks don't?

Would need to see ioreg.

 

The second of those two might be less inexplicable - it's a device with a builtin USB3 hub, and that too always runs at 5gbps, so I imagine the way that hubs get attached avoids the whole SSP vs. HSP thing,

A hub is just a USB device... it also has a driver... just like any other USB device.

 

and then the Ethernet attached to new hub. Testing this and looking with ioreg... Hm, I'm half right. The ethernet does attach to the new hub. But... that hub is attached to SSP2. So the second question then becomes:

- Why does my USB3 hub always attach to SSPx? (Not that I mind!)

USB3 device properly connecting to a USB3 port.

  • Like 1
Link to comment
Share on other sites
Gogeta5026
Gogeta5026
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 possible dummy port) afaik but should be OK to set it to 0xFF...

 

 

Thats all. No other change necessary  :lol:

 

Is there a way to use this method with Chamleon or Enoch???

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

has this been worked out for series 6?

TIA

R.

Same concepts for 6-series, 5-series, etc. Although before 7-series, no Intel USB3, and therefore limited support due to non-Intel USB3.

Link to comment
Share on other sites
PoisonApple666
PoisonApple666
Posted
Posted

Same concepts for 6-series, 5-series, etc. Although before 7-series, no Intel USB3, and therefore limited support due to non-Intel USB3.

Thanks for the quick response .... but I'm still confused.  If this doesn't support non-Intel USB3 then how is the concept the same?  Will the same sort of edits to the dsdt allow things to be read as USB2?  I assume that there would be no injectors useful for the non-Intel USB3?  I really am effing confused .... sorry....

 

TIA

R.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Thanks for the quick response .... but I'm still confused.  If this doesn't support non-Intel USB3 then how is the concept the same?

Same for Intel USB2 (eg. port injector, EHCx->EH0x rename to avoid native injectors, etc.)

 

Will the same sort of edits to the dsdt allow things to be read as USB2?  I assume that there would be no injectors useful for the non-Intel USB3?  I really am effing confused .... sorry....

USB3 for non-Intel USB3 controllers will depend on support for said USB3 chipsets (in the kexts) and/or patches to provide support where it doesn't exist.

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

Same for Intel USB2 (eg. port injector, EHCx->EH0x rename to avoid native injectors, etc.)

 

 

USB3 for non-Intel USB3 controllers will depend on support for said USB3 chipsets (in the kexts) and/or patches to provide support where it doesn't exist.

clear and concise ... thanks .... Is there a list somewhere that I could read up on which would tell me the chipsets supported?  Or would I need to open up the contents of the individual kexts and poke around inside?

Thanks.

R.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

clear and concise ... thanks .... Is there a list somewhere that I could read up on which would tell me the chipsets supported?  Or would I need to open up the contents of the individual kexts and poke around inside?

Thanks.

R.

I'm using an Inateck KTU3FR-5O2I (FL1100 chipset) on my 6-series desktop. It is supported OOB.

 

Note: Disabled the onboard NEC/Renesas USB3 controller as I'm not using it anymore.

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

Hi All,

 

I've just migrate to El Capitan, my motherboard is an "b75m-d3h".

What should I do to have full USB2/USB3 on this motherboard ? (DSDT edit, kext,...), I'm a little lost in this topic (I see some dst edit but are they for serie 7 chipset ?, I also see RehabMan kext, the clover patch).

 

Regards,

Barnum

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

@ RehabMan

 

Hi can I use USBInjectAll.kext for my GA-Z87-UD5H. I know this motherboards using Renesas Chipset. But my Corsair Case using 2 intel USB port this kext work with that?

I don't know why an 8-series board would use Renesas instead of Intel XHCI.

USBInjectAll supports Intel XHC/EHCI.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

If you are not using EHC1 (eg. everything on XHCI), you can disable the controller completely.

 

For just EHCI#1, this code can go in an SSDT or DSDT (SSDT shown):

DefinitionBlock ("SSDT-NO-EH01.aml", "SSDT", 1, "hack", "hack", 0x00003000)
{
    External(_SB.PCI0, DeviceObj)
    External(_SB.PCI0.LPCB, DeviceObj)
    External(_SB.PCI0.EH01, DeviceObj)

    Scope(_SB.PCI0)
    {
        // registers needed for disabling EHC#1
        Scope(EH01)
        {
            OperationRegion(PSTS, PCI_Config, 0x54, 2)
            Field(PSTS, WordAcc, NoLock, Preserve)
            {
                PSTE, 2  // bits 2:0 are power state
            }
        }
        Scope(LPCB)
        {
            OperationRegion(RMLP, PCI_Config, 0xF0, 4)
            Field(RMLP, DWordAcc, NoLock, Preserve)
            {
                RCB1, 32, // Root Complex Base Address
            }
            // address is in bits 31:14
            OperationRegion(FDM1, SystemMemory, Add(And(RCB1,Not(Subtract(ShiftLeft(1,14),1))),0x3418), 4)
            Field(FDM1, DWordAcc, NoLock, Preserve)
            {
                ,15,    // skip first 15 bits
                FDE1,1, // should be bit 15 (0-based) (FD EHCI#1)
            }
        }
        Device(RMD1)
        {
            //Name(_ADR, 0)
            Name(_HID, "RMD10000")
            Method(_INI)
            {
                // disable EHCI#1
                // put EHCI#1 in D3hot (sleep mode)
                Store(3, ^^EH01.PSTE)
                // disable EHCI#1 PCI space
                Store(1, ^^LPCB.FDE1)
            }
        }
    }
}
//EOF
For both EHCI#1 and EHCI#2:

DefinitionBlock ("SSDT-NO-EH01.aml", "SSDT", 1, "hack", "hack", 0x00003000)
{
    External(_SB.PCI0, DeviceObj)
    External(_SB.PCI0.LPCB, DeviceObj)
    External(_SB.PCI0.EH01, DeviceObj)
    External(_SB.PCI0.EH02, DeviceObj)

    Scope(_SB.PCI0)
    {
        // registers needed for disabling EHC#1
        Scope(EH01)
        {
            OperationRegion(PSTS, PCI_Config, 0x54, 2)
            Field(PSTS, WordAcc, NoLock, Preserve)
            {
                PSTE, 2  // bits 2:0 are power state
            }
        }
        // registers needed for disabling EHC#1
        Scope(EH02)
        {
            OperationRegion(PSTS, PCI_Config, 0x54, 2)
            Field(PSTS, WordAcc, NoLock, Preserve)
            {
                PSTE, 2  // bits 2:0 are power state
            }
        }
        Scope(LPCB)
        {
            OperationRegion(RMLP, PCI_Config, 0xF0, 4)
            Field(RMLP, DWordAcc, NoLock, Preserve)
            {
                RCB1, 32, // Root Complex Base Address
            }
            // address is in bits 31:14
            OperationRegion(FDM1, SystemMemory, Add(And(RCB1,Not(Subtract(ShiftLeft(1,14),1))),0x3418), 4)
            Field(FDM1, DWordAcc, NoLock, Preserve)
            {
                ,13,    // skip first 13 bits
                FDE2,1, // should be bit 13 (0-based) (FD EHCI#2)
                ,1,
                FDE1,1, // should be bit 15 (0-based) (FD EHCI#1)
            }
        }
        Device(RMD1)
        {
            //Name(_ADR, 0)
            Name(_HID, "RMD10000")
            Method(_INI)
            {
                // disable EHCI#1
                // put EHCI#1 in D3hot (sleep mode)
                Store(3, ^^EH01.PSTE)
                // disable EHCI#1 PCI space
                Store(1, ^^LPCB.FDE1)

                // disable EHCI#2
                // put EHCI#2 in D3hot (sleep mode)
                Store(3, ^^EH02.PSTE)
                // disable EHCI#2 PCI space
                Store(1, ^^LPCB.FDE2)
            }
        }
    }
}
//EOF
If successful, you'll notice EH01/EHC1 (and EH02/EHC2) disappears from ioreg.

 

Statement of the obvious: Don't use it if you're actually routing USB2 on XHC to EHCI with FakePCIID_XHCIMux.

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
blazinsmokey
blazinsmokey
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 possible dummy port) afaik but should be OK to set it to 0xFF...

 

 

Thats all. No other change necessary  :lol:

 

Been running this for ~2months, all transfers have been safe for me without issues. Still works on 10.11.2MRh7MjM.png

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