Jump to content

How to get Intel 7 Series USB 3.0 fully working - Step by Step guide

giacomoleopardo

By giacomoleopardo,
in Guides

 Share
101 posts in this topic

Recommended Posts

carbo178
carbo178
Posted
Posted

Reporting from a Mieze's e-mail:

 

It's definitely not the chipset that is causing the trouble. The patch is compatible with all 7 series chipsets and has been verified to work on a number of mainboards from Asus, Asrock, MSI and Intel but I don't remember anyone who tried it with a Gigabyte board. As far as I know Gigabyte's BIOS has some USB 3.0 related settings. Maybe playing with those might help because I can't rule out that there is any interference between the BIOS and OS X with regard to the XHCI controller?

Second, mrengles found out that the patch doesn't work with system definition iMac12,1 and iMac12,2 while Macmini5,1, Macpro3,1 and all the system definitions of Ivy Bridge Macs are fine. I would recommend to add this information to the tutorial.

 

So, guys, let's double check BIOS settings and SysDef!

Please report results!

Thanks to everybody!

I confirm working with Sys Def iMac 13,1/13,2 and Mac Pro 5,1 (tested by myself)

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

Another thing is that a PC's DSDT is not adjusted for use with OS X. Throughout the DSDT you can find several places where the OSYS variable is checked to determine the OS that is being run, mostly for different Windows versions. According to the value, a different code path is chosen. Setting OSYS to 0x2710 will render these code paths unusable because there is simply no special condition for this value.

As you already mentioned they only check for different versions of Windows so that these code paths will never be taken when running OS X, no matter if you are using a DSDT with or without the patch. By the way there is a lot of code in the DSDT that is irrelevant to OS X.

 

Mieze

Link to comment
Share on other sites
k3nny
k3nny
Posted
Posted

As you already mentioned they only check for different versions of Windows so that these code paths will never be taken when running OS X, no matter if you are using a DSDT with or without the patch.

 

The initialization method for my board looks like this:

Method (_INI, 0, NotSerialized)  // _INI: Initialize
{
   Store (0x07D0, OSYS)
   If (CondRefOf (_OSI, Local0))
   {
       If (_OSI ("Windows 2001"))
       {
           Store (0x07D1, OSYS)
       }

       If (_OSI ("Windows 2001 SP1"))
       {
           Store (0x07D1, OSYS)
       }

       If (_OSI ("Windows 2001 SP2"))
       {
           Store (0x07D2, OSYS)
       }

       If (_OSI ("Windows 2001.1"))
       {
           Store (0x07D3, OSYS)
       }

       If (_OSI ("Windows 2006"))
       {
           Store (0x07D6, OSYS)
       }

       If (_OSI ("Windows 2009"))
       {
           Store (0x07D9, OSYS)
       }
   }
}

In this case OSYS will remain at 0x07D0, which is still a valid value in regard of the initial DSDT design.

 

By the way there is a lot of code in the DSDT that is irrelevant to OS X.

I know, I just want to keep it as clean as possible. However, I don't have any evidence this will influence anything in a good or bad way.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

In this case OSYS will remain at 0x07D0, which is still a valid value in regard of the initial DSDT design.

 

Technically speaking there are no valid or invalid values for OSYS. There are only values identifying a particular OS with 0x07D0 as a default for unknown operating systems.

 

Mieze

Link to comment
Share on other sites
k3nny
k3nny
Posted
Posted

Technically speaking there are no valid or invalid values for OSYS. There are only values identifying a particular OS with 0x07D0 as a default for unknown operating systems.

This is true. What I want to say, is that certain code will be executed when OSYS is set to 0x07D0 but will be left out if you set it to 0x2710.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

This is true. What I want to say, is that certain code will be executed when OSYS is set to 0x07D0 but will be left out if you set it to 0x2710.

Depending on the board this might be true or not but as of now I haven't found a single dependency with an impact on OS X. As a general rule it's always best to check the effects of your changes while you apply them.

 

Mieze

Link to comment
Share on other sites
theconnactic
theconnactic
Posted
Posted

So, guys, let's double check BIOS settings and SysDef!

Please report results!

Thanks to everybody!

 

It's the system definition here, with all certainty: iMac12,2! I have to decide if i really want to change that - for unrelated reasons, probably will do! - but it's very good to know it's not my motherboard's chipset. Thank you, Giacomo (and Mieze, by the way): all the best to you both!

 

UPDATE: changed to MacMini 6,2 and it's now working. And now with a plus: native IBPM is also working like a trait.

 

This topic is a real game changer for all Z77/H77 users: thank you, Giacomo! Thank you, Mieze!

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

It's the system definition here, with all certainty: iMac12,2! I have to decide if i really want to change that - for unrelated reasons, probably will do! - but it's very good to know it's not my motherboard's chipset. Thank you, Giacomo (and Mieze, by the way): all the best to you both!

 

UPDATE: changed to MacMini 6,2 and it's now working. And now with a plus: native IBPM is also working like a trait.

 

This topic is a real game changer for all Z77/H77 users: thank you, Giacomo! Thank you, Mieze!

Good the hear! I'm glad this helped!

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

Thank you Giacomo and Mieze. I do have time to test and definitely it fixes my issue regarding backward compatibility. Now they can be used with my 2.0 and 3.0 flash drive.. However here I got device ejection error after Wake and my flash drives don't get mounted again. Is it common with this patch?

 

Edit: at the same time I have set AllowAnyXHCI=True in generic XHCI kext to enable Etron controller.

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

However here I got device ejection error after Wake and my flash drives don't get mounted again. Is it common with this patch?

This usually happens when the board doesn't provide standby power to USB devices while in S3. Connect a USB device with a power LED to the port in question, send the machine to sleep and check if the LED goes off in order to find out if you are affected. On some boards USB standby can be enabled in the BIOS while on others you'll have to set a jumper.

 

Mieze

Link to comment
Share on other sites
fau7i
fau7i
Posted
Posted

This usually happens when the board doesn't provide standby power to USB devices while in S3. Connect a USB device with a power LED to the port in question, send the machine to sleep and check if the LED goes off in order to find out if you are affected. On some boards USB standby can be enabled in the BIOS while on others you'll have to set a jumper.

 

Mieze

 

Ok, thanks.

 

I've just tested again with 3 devices. When waking up;

 

1. Kingston 2.0 USB stick - Not mounted at all even its LED was blinking for few seconds.

2. Strontium 3.0 USB stick - Not even blinking, but it was mounted for about 10 seconds before disappeared.

3. Seagate GoFlex 2.0 ext HDD - It has power LED which is being OFF when Sleep. And it wakes just fine... :worried_anim:

 

Why they are different :wallbash:

Link to comment
Share on other sites
subxero
subxero
Posted
Posted

Is your bios AMI-EFI?

Try the attached dsdt (if your doesn't work) and change sysdef. Of course backup yours!

Let's see what happen

 

Ok then! Using the DSDT I patched according to your 1st post, I changed SMBios to 13,2 and USB 2.0 drives are now working on the USB3,0 ports. Did not have to change anything in BIOS. Thank you giacomoleopardo and of course a big thank you Mieze for this contribution. I may just start fine-tuning my entire system based on DSDT since USB, Graphics and Audio are injected. HDMI is still elusive, but since I have dusted off my old DSDT file, I may as well rise to the challenge.

 

PS: Sleep does not eject any drives connected to any of the USB ports. Their power LED's stay on while the machine is in sleep mode.

  • Like 1
Link to comment
Share on other sites
giacomoleopardo
giacomoleopardo
Posted
  • Author
Posted

Ok then! Using the DSDT I patched according to your 1st post, I changed SMBios to 13,2 and USB 2.0 drives are now working on the USB3,0 ports. Did not have to change anything in BIOS. Thank you giacomoleopardo and of course a big thank you Mieze for this contribution. I may just start fine-tuning my entire system based on DSDT since USB, Graphics and Audio are injected. HDMI is still elusive, but since I have dusted off my old DSDT file, I may as well rise to the challenge.

 

PS: Sleep does not eject any drives connected to any of the USB ports. Their power LED's stay on while the machine is in sleep mode.

Please, could you try dsdt I attached in post # 28? Just out of curiosity...

Link to comment
Share on other sites
Mieze
Mieze
Posted
Posted

3. Seagate GoFlex 2.0 ext HDD - It has power LED which is being OFF when Sleep. And it wakes just fine...

Is this drive self powered or bus powered?

 

Mieze

Link to comment
Share on other sites
carbo178
carbo178
Posted
Posted

Hi all,

I tested the last part of tutorial (GenericUSBXHCI.kext); this is the result of my test:

With or without DSDT edited for USB3 Intel and the kext GenericUSBXHCI the USB seem to work fine, but I have no USB3 devices to test the speed.

The generic kext does not replace the CalDigit, without these the doors are not detected, with or without DSDT (tested on P8Z77-V LE)

The generic kext detects very well the USB3 NEC / Renesas (tested on P5P55D), you can eliminate PXHCD (which in some cases creates problems and instability).

In any case without DSDT edited the doors work, but the system does not go to sleep (my Mobo ASUS, I do not know the others).

Sorry for my bad english

Regards

Marco

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

Hi all,

I tested the last part of tutorial (GenericUSBXHCI.kext); this is the result of my test:

With or without DSDT edited for USB3 Intel and the kext GenericUSBXHCI the USB seem to work fine, but I have no USB3 devices to test the speed.

The generic kext does not replace the CalDigit, without these the doors are not detected, with or without DSDT (tested on P8Z77-V LE)

The generic kext detects very well the USB3 NEC / Renesas (tested on P5P55D), you can eliminate PXHCD (which in some cases creates problems and instability).

In any case without DSDT edited the doors work, but the system does not go to sleep (my Mobo ASUS, I do not know the others).

Sorry for my bad english

Regards

Marco

Ciao Marco, thanks for testing and response reporting. It's a bit strange, though. Have you tried generic kext based on a fresh install? Furthermore: have you reported this to Zenith432? Maybe he could add some extra features to the next binary release.

Link to comment
Share on other sites
carbo178
carbo178
Posted
Posted

Ciao Giovanni,

I also tried out a new installation on my hard disk test, but the results are the same, I can also post feedback on the topic of Zenith432, to see if show up inconsistencies

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