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

polyzargone
polyzargone
Posted
Posted

Thanks Maniac10 but the config.plist does this ;) :

			<key>Name</key>
			<string>DSDT.aml</string>
			<key>Patches</key>
			<array>
				<dict>
					<key>Comment</key>
					<string>EHC2 to EH02</string>
					<key>Find</key>
					<data>
					RUhDMg==
					</data>
					<key>Replace</key>
					<data>
					RUgwMg==
					</data>
				</dict>
				<dict>
					<key>Comment</key>
					<string>EHC1 to EH01</string>
					<key>Find</key>
					<data>
					RUhDMQ==
					</data>
					<key>Replace</key>
					<data>
					RUgwMQ==
					</data>
				</dict>

Or :

 

 

9f44308a-2504-423a-a2e4-5f9c0667a01d.jpg

 

And it works :

 

post-1163891-0-27496600-1445469457_thumb.png

MacBookPro.ioreg.zip

Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted (edited)

No problem ;).
 
I already tried to set HighCurrent but it makes no difference.
 
The two USB connector in EH01 are :
 
fd100000
PortNum 0x1
 
and
 
fd200000
PortNum 0x2
 
And both have Low Power Displayed = False according to IOREG in Yosemite (see IOREG attached).
 
So I guess thay match with CH00 & CH01 port in DSDT :

Device (EHC1)
            {
                Name (_ADR, 0x001D0007)
                Name (_S1D, 0x02)
                Name (_S3D, 0x02)
                Method (_DSM, 4, NotSerialized)
                {
                    Store (Package (0x0B)
                        {
                            "AAPL,clock-id",
                            Buffer (One)
                            {
                                0x01
                            },

                            "device_type",
                            Buffer (0x05)
                            {
                                "EHC1"
                            },

                            "AAPL,current-available",
                            0x04B0,
                            "AAPL,current-extra",
                            0x02BC,
                            "AAPL,current-in-sleep",
                            0x03E8,
                            Buffer (One)
                            {
                                0x00
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }

                Method (_PRW, 0, NotSerialized)
                {
                    Store (UPRW (Zero, 0x07), Local0)
                    If (LEqual (Local0, 0x03))
                    {
                        Return (Package (0x02)
                        {
                            0x0D,
                            0x03
                        })
                    }

                    If (LEqual (Local0, One))
                    {
                        Return (Package (0x02)
                        {
                            0x0D,
                            One
                        })
                    }

                    Return (Package (0x02)
                    {
                        0x0D,
                        Zero
                    })
                }

                Method (_PSW, 1, NotSerialized)
                {
                    UPSW (Arg0, 0x07)
                }

                Device (HUB7)
                {
                    Name (_ADR, Zero)
                    Device (CH00)
                    {
                        Name (_ADR, One)
                    }

                    Device (CH01)
                    {
                        Name (_ADR, 0x02)
                    }

UPDATE :

 

Strangely, the problem only occurs when the device is connected after the OS has booted. If I connect the device before, there's no problem :wacko:…

MacBookPro_Yos.ioreg.zip

Edited by polyzargone
Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Messing with my DSDT I found a way to solve the USB port problem of El Capitan which doesn't require any injector kexts. Only a DSDT edit is required although I must admit that you need advanced DSDT editing skills to apply the patch. It's derived from a retina iMac's DSDT so that I have to thank the Apple engineers for the inspiration.  :thumbsup_anim:

 

All external ports (including the front USB ports) on my Asrock H97M Pro4 are fully working with USB 3.0 and USB 2.0 devices. There is only one limitation: you can't have more than 15 ports which seems to be much but you have to take into account that USB 3.0 ports count double, e.g. with 6 USB 3.0 ports you already have 12 ports. Well, it depends on your board if this is a limitation. I tested the patch with the latest version of El Capitan, 10.11.1 and haven't discovered any problems.

 

Unfortunately I don't have time to write a tutorial, I'm just posting my DSDT, but I will happily provide more detailed information about the patch if someone is interested in testing or writing a tutorial.

 

With exception of a few power management methods which had to be adapted in order to cope with the changes I made, only device XHC needs to be changed. See for yourself...

 

Good luck hacking!

 

Mieze

DSDT-Asrock-H97m-Pro4 -200.aml.zip

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

Messing with my DSDT I found a way to solve the USB port problem of El Capitan which doesn't require any injector kexts. Only a DSDT edit is required although I must admit that you need advanced DSDT editing skills to apply the patch. It's derived from a retina iMac's DSDT so that I have to thank the Apple engineers for the inspiration.  :thumbsup_anim:

 

All external ports (including the front USB ports) on my Asrock H97M Pro4 are fully working with USB 3.0 and USB 2.0 devices. There is only one limitation: you can't have more than 15 ports which seems to be much but you have to take into account that USB 3.0 ports count double, e.g. with 6 USB 3.0 ports you already have 12 ports. Well, it depends on your board if this is a limitation. I tested the patch with the latest version of El Capitan, 10.11.1 and haven't discovered any problems.

 

Unfortunately I don't have time to write a tutorial, I'm just posting my DSDT, but I will happily provide more detailed information about the patch if someone is interested in testing or writing a tutorial.

 

With exception of a few power management methods which had to be adapted in order to cope with the changes I made, only device XHC needs to be changed. See for yourself...

 

Good luck hacking!

 

Mieze

Could you post native DSDT? Or even better, patched DSDT without the USB edits? It would be easy then to use diff.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Thanks... so, took a quick look. Looks like a wholesale replacement of XHC related code...

 

Yes, as I already mentioned the code was inspired by Apple's code of device XHC1 in a Retina iMac's DSDT. By the way, it is crucial that device XHC1 is renamed to XHC for the patch to work properly, in case it doesn't have that name. I don't know if other names work too, but XHC1 definitely doesn't work.

 

I took only the methods _PRW, _PS0 and _PS3 as well as device RHUB and the operational regions / fields from the original DSDT. The rest of the code is more or less derived from Apple's code.

 

Mieze

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

What about arix98's idea to unlimit USB ports number?

 

I might work but this would involve kext patching. Provided you are using only the USB ports on the I/O shield plus the two on the front panel the limit shouldn't be problem.

 

Mieze

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Yes, as I already mentioned the code was inspired by Apple's code of device XHC1 in a Retina iMac's DSDT. By the way, it is crucial that device XHC1 is renamed to XHC for the patch to work properly, in case it doesn't have that name. I don't know if other names work too, but XHC1 definitely doesn't work.

XHC1 is probably causing you to pick up a port injector, which then ignores DSDT...

 

I took only the methods _PRW, _PS0 and _PS3 as well as device RHUB and the operational regions / fields from the original DSDT. The rest of the code is more or less derived from Apple's code.

A more surgical fix involving just fixing _UPC would probably also work.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

XHC1 is probably causing you to pick up a port injector, which then ignores DSDT...

Correct!

A more surgical fix involving just fixing _UPC would probably also work.

 

No, because you have to provide the code which performs the switch between USB 2.0 and 3.0 mode.

 

Mieze

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

No, because you have to provide the code which performs the switch between USB 2.0 and 3.0 mode.

I find it is not needed. I just force USB2 from XHC to EHC using FakePCIID_XHCIMux.kext.

 

Not sure why Apple wants to make it so complex.

 

Note: It is possible to do the routing (Apple's way) with surgical patches.

  • Like 1
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Why not use a SSDT for this? Something like:

    ...
    External (\_SB_.PCI0, DeviceObj)
    External (\_SB_.PCI0.XHC, DeviceObj)
    External (\_SB_.PCI0.XHC._STA, MethodObj)

    Scope (\_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            Store (Zero, \_SB.PCI0.XHC._STA)
        }
    }
    Device (XHC)
    {
        Name (_ADR, 0x00140000)
        ...
    }
Wouldn't that be a lot cleaner? Just an idea of course ;)
  • Like 1
Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

Why not use a SSDT for this? Something like:

Wouldn't that be a lot cleaner? Just an idea of course

 

I like his idea.

 

The device limit will likely be a problem for anyone with several devices unless you're really selective in how you implement them — anyone with USB 3 hub devices that have more than 4 ports have probably encountered this since USB 3 was a thing on Macs — I have one in particular that is actually three hub devices in one device and it ends up causing all sorts of problems for every other USB device I have and the OS barfs messages to syslog about being unable to enumerate additional devices, etc -- first time it got me was when I was using a pair of JBODs, really uncool.

 

I found an interesting write-up/explanation at the time that may be interesting to some — 

http://apple.stackexchange.com/questions/120777/2012-macbook-air-usb-hardware-ran-out-of-device-slots

the tl;dr was to use 4-port hubs only because 7-port hubs are two in a chain. Some other interesting USB-related shenanigans were discussed as well.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Why not use a SSDT for this? Something like:

    ...
    External (\_SB_.PCI0, DeviceObj)
    External (\_SB_.PCI0.XHC, DeviceObj)
    External (\_SB_.PCI0.XHC._STA, MethodObj)

    Scope (\_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            Store (Zero, \_SB.PCI0.XHC._STA)
        }
    }
    Device (XHC)
    {
        Name (_ADR, 0x00140000)
        ...
    }
Wouldn't that be a lot cleaner? Just an idea of course ;)

 

To address what specific problem?

 

I think you're saying use the _ADR=0 trick as a way to disconnect the original APCI identity from the PCI device, and then provide the "wholesale replacement" (as in Mieze's example) under a new name (likely not XHC). The problem is it can get quite tricky as there may be methods in other scopes that call into the original, and that code, if it accesses PCI config, or items connected to PCI config (SystemMemory based on BAR regions, for example) will fail. Such failures may or may not be desireable. Requires comprehensive code review.

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

To address what specific problem?

 

I think you're saying use the _ADR=0 trick as a way to disconnect the original APCI identity from the PCI device, and then provide the "wholesale replacement" (as in Mieze's example) under a new name (likely not XHC). The problem is it can get quite tricky as there may be methods in other scopes that call into the original, and that code, if it accesses PCI config, or items connected to PCI config (SystemMemory based on BAR regions, for example) will fail. Such failures may or may not be desireable. Requires comprehensive code review.

It's not addressing a specific problem, but it could make it easier for people to implement (what Mieze did). And it will require some work, but I think that it can be done.
Link to comment
Share on other sites
wegface
wegface
Posted
  • Author
Posted

I mentioned this 2 days after thread was made that only a simple dsdt edit was needed, just remove unneeded/unused ports nothing more. No special methods or fields required, no special hacking involving anything from a 'real' mac dsdt. Just delete the extra ports.

Yes correct, was never added to first post as i wanted people to test it, and instead the thread became a "debate".  :w00t:

Maybe i will do it now, before another "debate" distracts from topic.  :hysterical:

Link to comment
Share on other sites
ganxiao
ganxiao
Posted
Posted

Problem finally solved.

  • Mapped the ASRock Z87E-ITX USB ports as reported here 

attachicon.gifASRock Z87E ITX USB mappature.jpg

  • Applied DSDT patch to rename EHC1 to EH01, EHC2 to EH02 and XHC1 to XHC 
    # Rename USB devices for OSX 10.11 GM support (remember to use injector with this)
into device label EHC1 set_label begin EH01 end;
into device label EHC2 set_label begin EH02 end;
into device label XHC1 set_label begin XHC end;
into_all all code_regex EHC1 replaceall_matched begin EH01 end;
into_all all code_regex EHC2 replaceall_matched begin EH02 end;
into_all all code_regex XHC1 replaceall_matched begin XHC end
  • Applied arix98's Clover patch in config.plist\Kernel and Kext Patches to remove the limit of 15 usb
  • Edited PJALM's USB_Series8_Injector.kext (see attachment for my own edits based on the USB board mappature) to make ALL of the USB 2.0 and 3.0 working properly
  • Located Bluetooth USB Host Controller In EHC2 (now renamed EH02 by the previous patch) as shown in IOReg 10.10.5 here 

attachicon.gifBT location 10.10.5.png

  • Applied RehabMan's DSDT patch 
    into device name_adr 0x001A0000 code_regex Name.*_ADR.* replace_matched begin Name(_ADR,0) end

    to make the ACPI identity "disconnected" from the PCIe identity in EH02. The system cannot match the two as matching is done based on the value of _ADR as stated here or here, to avoid instant wake from sleep caused by the the native Mac BCM94360CD (WiFi) + BCM94331CD (Bluetooth) combo card plugged into mini-PCI Express slot

  • Rebooted and checked every USB + Sleep + AutoSleep

attachicon.gif10.11 USB OK.png

 

Hi, giacomoleopardo

 

Your combo card is actually BCM4360 (WiFi) + BCM20702(Bluetooth), model name is BCM94360CD, and BCM94331CD is old 802.11n+bt combo card used in old macs.

 

I have similar shutdown issue since 10.11, but sleep works fine, probably because BCM20702 was connected to XHC, not EH02 like you.

 

With this card, system will power on after powered off 2-3 seconds,

Without this card, system will shutdown, but if any key or mouse pressed, system would power on.

 

So i think there must be something wrong in ACPI related configs with 10.11.

I checked bios settings, and pretty sure that power on by keyboard/mouse were not enabled.

After googled a while, found turn off wake-on-lan in bios settings could fix this, but wake-on-lan never works any more.

 

As metioned in your earlier post, this can be solved with FixShutdown + SlpSmiAtWake options in config.plist/Acpi section,

Do you still use this method?

 

BRs

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted (edited)

I mentioned this 2 days after thread was made that only a simple dsdt edit was needed, just remove unneeded/unused ports nothing more. No special methods or fields required, no special hacking involving anything from a 'real' mac dsdt. Just delete the extra ports.

This used to work for me under 10.11 too, but after I installed the 10.11.1 update, most of the USB ports stopped working. All USB 2.0 ports and 4 of the 6 USB 3.0 ports were dead and simply removing some ports from device RHUB wasn't enough to restore full operation. While ports HS01/SSP1 and HS02/SSP2 were fully operational, the other USB 3.0 ports still refused to work with USB 2.0 devices until I added the XHCx and EHCx methods, which implement the switch between both operation modes when a device is connected, as well as the MUXS and the XHCP name properties to the corresponding ports. The strange thing is that these methods aren't required for HS01/SSP1 and HS02/SSP2.

 

By the way, the replaced XHC code seems to have resolved a stability issue too. Before the patch the machine sometimes rebooted when it went to sleep but now it's running absolutely stable for 16 hours with dozens of sleep / wake cycles in between.

 

Mieze

Edited by Mieze
Link to comment
Share on other sites
giacomoleopardo
giacomoleopardo
Posted
Posted

Hi, giacomoleopardo

 

Your combo card is actually BCM4360 (WiFi) + BCM20702(Bluetooth), model name is BCM94360CD, and BCM94331CD is old 802.11n+bt combo card used in old macs.

 

I have similar shutdown issue since 10.11, but sleep works fine, probably because BCM20702 was connected to XHC, not EH02 like you.

 

With this card, system will power on after powered off 2-3 seconds,

Without this card, system will shutdown, but if any key or mouse pressed, system would power on.

 

So i think there must be something wrong in ACPI related configs with 10.11.

I checked bios settings, and pretty sure that power on by keyboard/mouse were not enabled.

After googled a while, found turn off wake-on-lan in bios settings could fix this, but wake-on-lan never works any more.

 

As metioned in your earlier post, this can be solved with FixShutdown + SlpSmiAtWake options in config.plist/Acpi section,

Do you still use this method?

 

BRs

Yes, nothing better until now. Also, removing Devices EHC1 and EHC2 from DSDT make sleep working properly. wake  from sleep either, except wake from BT wireless keyboard or magic mouse, that's, of course, because in ACPI Bluetooh device is now dissociated from EHCx device, and appears like PCI0@0/AppleACPIPCI/pci8086,8c2d@1A... I wonder if some kind of DSDT patch can re-direct Bluetooth under XHC\HSxx. Maybe that would give us proper behavior just like in Yosemite under EHCx 

Link to comment
Share on other sites
wegface
wegface
Posted
  • Author
Posted

This used to work for me under 10.11 too, but after I installed the 10.11.1 update, most of the USB ports stopped working. All USB 2.0 ports and 4 of the 6 USB 3.0 ports were dead and simply removing some ports from device RHUB wasn't enough to restore full operation. While ports HS01/SSP1 and HS02/SSP2 were fully operational, the other USB 3.0 ports still refused to work with USB 2.0 devices until I added the XHCx and EHCx methods, which implement the switch between both operation modes when a device is connected, as well as the MUXS and the XHCP name properties to the corresponding ports. The strange thing is that these methods aren't required for HS01/SSP1 and HS02/SSP2.

 

By the way, the replaced XHC code seems to have resolved a stability issue too. Before the patch the machine sometimes rebooted when it went to sleep but now it's running absolutely stable for 16 hours with dozens of sleep / wake cycles in between.

 

Mieze

Dont you just adore apple's "finals" and "golden masters" for capitan! :lol: Every update, something big changes, they really need to test things more before releasing. Naughty apple!

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

Removing enough ports from just the XHC in my DSDT to keep it to 15 or under was enough for my z87 and z97 mobos so not sure why u need more then that for yours, in fact i totally remove all EHC1/EHC2 from mine as its not used in series 8/9

It might depend on the system definition too.

 

Mieze

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