Jump to content

IOUSBFamily 10.8.4 Slice+AnV with full AppleUSBXHCI support for any USB3 chip (V12)


122 posts in this topic

Recommended Posts

Not working with my Gigabyte Z77X-UD3H, I tried the latest v12 for intel.

All USB 3.0 Ports are not working after sleep, I'm so sad. :(

 

4x USB 3.0 Ports on the back are Via VL800 and 2x are from Intel.

 

Andy, do you have any idea how I can get them to work after sleep?

Could someone please post a working .kext file for the via vl800?

Link to comment
Share on other sites

Andy,

Is the kext you uploaded is "deployment" or "logging"? It may be a reason for non-working.

That could be it.

I should still modify the option for Panther Point multiplexing (on / off) but I forgot to build the logging version instead of the deployment one.

Thanks for reminding me.

When I find some time I'll mod it some more (I've been quite busy with Apple firmware dumping and extracting, etc... also with UEFI BIOS modding)

Link to comment
Share on other sites

I also want to propose this procedure instead of vanilla

void AppleUSBXHCI::PrintInterrupter(int __unused level, int IRQ, const char * __unused s)
{
  long unsigned int IMAN, IMOD, ERDP;
                                                      //at IRQ = 0
  IMAN = Read32Reg(&_pXHCIRuntimeReg->IR[IRQ].IMAN);  // = 2
  IMOD = Read32Reg(&_pXHCIRuntimeReg->IR[IRQ].IMOD);  // = a0
  ERDP = Read64Reg(&_pXHCIRuntimeReg->IR[IRQ].ERDP);  // = 7c002300
                   
	USBLog(level, "AppleUSBXHCI[%p]::PrintInterrupter %s IRQ:%d - IMAN: %08lx IMOD: %08lx ERDP: %08lx", this, s, IRQ,
		   IMAN, IMOD, ERDP);
}

There will be warning "unused values" when compiled to deployment but I am lazy to correct this.

Link to comment
Share on other sites

I also want to propose this procedure instead of vanilla

void AppleUSBXHCI::PrintInterrupter(int __unused level, int IRQ, const char * __unused s)
{
  long unsigned int IMAN, IMOD, ERDP;
                                                      //at IRQ = 0
  IMAN = Read32Reg(&_pXHCIRuntimeReg->IR[IRQ].IMAN);  // = 2
  IMOD = Read32Reg(&_pXHCIRuntimeReg->IR[IRQ].IMOD);  // = a0
  ERDP = Read64Reg(&_pXHCIRuntimeReg->IR[IRQ].ERDP);  // = 7c002300
                   
	USBLog(level, "AppleUSBXHCI[%p]::PrintInterrupter %s IRQ:%d - IMAN: %08lx IMOD: %08lx ERDP: %08lx", this, s, IRQ,
		   IMAN, IMOD, ERDP);
}

There will be warning "unused values" when compiled to deployment but I am lazy to correct this.

Sure, I'll implement it when I make the mods.

Will probably be wednesday as I'm quite busy at the moment.

Thanks for the new print interrupter code.

Link to comment
Share on other sites

I just tried slice's build, and this one fails upon resume (just like all the others so far). Actually it fails worse in that the disk is force ejected immediately (and doesn't come back automatically as in slice's test). This seems to simply be due to NoSleepForced being set to true and SleepFix being set false. I flipped the logic on these two (like it was in prior builds) and then the failure is just as before, where there is a setPowerState() timeout after about 90 seconds followed by forced eject a minute or so later.

 

Dumb question -

Is slice's v11 or the v12 mentioned in earlier posts supposed to be the latest version?

 

I thought this fix was going to be easy so I didn't really look into the driver source until now. I just took a peek at the linux driver, and all they had to do to support the Etron & Asrock usb3 chips was set two quirk flags (XHCI_RESET_ON_RESUME and XHCI_TRUST_TX_LENGTH). Looks like you've implemented the first quirk but not the second.

 

Any plans to work on this for etron& asrock chips?

Link to comment
Share on other sites

I can work with hardware that I have to test or may be with a good tester that quickly show me kernel.log with debug version.

But why you not implement this features by yourself? Show your diff and Andy will add it to the topic.

 

About versions 11 and 12 I think sources in the topic are exactly the same as I compiled. Last my changes was in post 55.

Last my compilation was "IOUSBFamily (deployment) build for archiving". XCode 4.6.3 in OSX 10.8.4. I have private headers in System folder obtained after XNU compilation but I am not sure it influenced on something.

Link to comment
Share on other sites

I can work with hardware that I have to test or may be with a good tester that quickly show me kernel.log with debug version.

Yes, I tested like 8 versions already; and provided kernel logs in earlier posts here. I'm running out of time at this point to test; the system is back in "production" use of sorts already actually. Have to leave the system powered on 24x7 because of this issue unfortunately.

But why you not implement this features by yourself? Show your diff and Andy will add it to the topic.

I certainly could, but I thought Andy was on this, after all he made the thread whose purpose seemed to be to support such mainstream & common usb3 chips. That is why I've been asking if he plans to support this. I might get to it myself in a few weeks (or months). Any longer than that then I'll probably never get around to it as I'll have too many newer systems to use with intel usb3 instead.

 

This will be a great project, obsoleting the other usb3 driver choices if resume from sleep fully worked.

Link to comment
Share on other sites

I see no confirmation it's working but I also see no attempt to do something:

- correctly install the kext,

- make patch DSDT

- apply my SSDT

- upload kernel.log and other reports

- screenshots, observation ...

etc.

Link to comment
Share on other sites

  • 2 weeks later...

Is there anybody has a proposition why XHCI should work with 5 ports while the chip contains only 4?

6:545  0:028  XhcGetCapability: 5 ports, 64 bit capable=1
6:677  0:131  XhcUsbPortReset!
6:715  0:038  XhcSetRootHubPortFeature: status Success
6:799  0:084  XhcClearRootHubPortFeature for port 0 Feature=4: status Success
6:957  0:157  XhcClearRootHubPortFeature for port 0 Feature=10: status Success
6:983  0:026  XhcClearRootHubPortFeature for port 0 Feature=14: status Success
7:139  0:155  XhcUsbPortReset!
7:169  0:029  XhcSetRootHubPortFeature: status Success
7:251  0:082  XhcClearRootHubPortFeature for port 4 Feature=4: status Success
7:306  0:054  XhcClearRootHubPortFeature for port 4 Feature=10: status Success

  • Like 1
Link to comment
Share on other sites

 

Is there anybody has a proposition why XHCI should work with 5 ports while the chip contains only 4?

6:545  0:028  XhcGetCapability: 5 ports, 64 bit capable=1
6:677  0:131  XhcUsbPortReset!
6:715  0:038  XhcSetRootHubPortFeature: status Success
6:799  0:084  XhcClearRootHubPortFeature for port 0 Feature=4: status Success
6:957  0:157  XhcClearRootHubPortFeature for port 0 Feature=10: status Success
6:983  0:026  XhcClearRootHubPortFeature for port 0 Feature=14: status Success
7:139  0:155  XhcUsbPortReset!
7:169  0:029  XhcSetRootHubPortFeature: status Success
7:251  0:082  XhcClearRootHubPortFeature for port 4 Feature=4: status Success
7:306  0:054  XhcClearRootHubPortFeature for port 4 Feature=10: status Success

It's possible the chip has internal support for up to 5 ports but only has 4 physical connections.

Just a thought... :-)

Link to comment
Share on other sites

No, it internally has exactly 4 ports.

http://www.via-labs.com/en/products/vl800/

 

When I set manually _rootHubNumPorts = 4

the driver stop working ! :blink::wacko:

:o

Odd...

I also have no idea why it stops working.

Probably something in the code then (the way it simply works)

Link to comment
Share on other sites

Are you sure it's not a bug in software?  If the chip actually reports 5 root hub ports - well, the USB3 spec says that each superspeed port must have a companion USB2.0 port along with it (in other words the connector must have dual USB3-USB2 wires.)  It is not allowed to have a superspeed-only connector.  However, the xHC may also support any number of USB 2.0-only ports that have no companion superspeed port.

So the total number of ports is 2*x + y, where

x = dual-protocol ports

y = USB2.0 only ports.

 

One possible use for USB 2.0-only port is a debug port.

I suggest you dump xHCI Extended Capabilities for the chip to study its port layout.  Especially xHCI Supported Protocol Cap and xHCI Debug Cap.  You can do this with 'xhcdump caps' if you install GenericUSBXHCI to drive it.  However, it won't give you detailed dump of the Debug Cap - as it's not used.

Is there anybody has a proposition why XHCI should work with 5 ports while the chip contains only 4?

Link to comment
Share on other sites

I posted this help request to Zenith's genericUSBXHCI thread as well but maybe it is more appropriate to seek help here.

 

I have a new system in that is based on a jetway Q77 board for pro tools. I have tried many things to get the USB 3.0 ports working properly with the applexhci drivers but the system just locks up as soon as I insert a drive or device. I have tried the various BIOS options for Auto/Smart Auto etc. There is no handoff option in BIOS for XHCI (only EHCI which is enabled). 

 

Now if I install Zenith's GenericUSBXHCI driver it DOES mostly work, disks mount on the USB 3.0 bus and no system freeze which is awesome, but i normally prefer to use the apple drivers for the intel controller and the generic for third party controllers through an ioprobe edit (i have both controller types on most of my systems).

 

Though compatibility issues have been shrinking i still find the apple drivers tend to work with more devices on the intel controllers. And on occasion with generic driver installed it seems like the ports stop working or wont work with USB 2.0 devices. In any case my primary goal is to get the intel ports working with the apple driver on this board if thats possible.

 

I am attaching the original unmodified DSDT extracted with maciasl as well as my latest modified one which includes the DSDT edits (i think originally developed by mieze) that have worked to make the intel ports fully functional on other boards. Please let me know if there is any other info i can provide to help figure this out!

Thanks,

g\

 

Link to comment
Share on other sites

Are you sure it's not a bug in software?  If the chip actually reports 5 root hub ports - well, the USB3 spec says that each superspeed port must have a companion USB2.0 port along with it (in other words the connector must have dual USB3-USB2 wires.)  It is not allowed to have a superspeed-only connector.  However, the xHC may also support any number of USB 2.0-only ports that have no companion superspeed port.

So the total number of ports is 2*x + y, where

x = dual-protocol ports

y = USB2.0 only ports.

 

One possible use for USB 2.0-only port is a debug port.

I suggest you dump xHCI Extended Capabilities for the chip to study its port layout.  Especially xHCI Supported Protocol Cap and xHCI Debug Cap.  You can do this with 'xhcdump caps' if you install GenericUSBXHCI to drive it.  However, it won't give you detailed dump of the Debug Cap - as it's not used.

I will make dump little later. But I already know port layout

Screen Shot 2013-09-27 at 14.57.54.png

I am thinking that there is possible bug in the software with cycles as

for(i=0; i

because I have only 4 port. 

But for now the driver works fine.

Link to comment
Share on other sites

Actually, 'for(i=0; i<_roothubnumports is not a bug because in the port register set array ports are indexed from zero to _roothubnumports but everywhere else iousbfamily numbered based at>

In this case i=0 will be wrong. Or it may be controller itself.

Link to comment
Share on other sites

I have a fresco 1100 card in a cardbus.  How can I get this to work?

Fresco logic works with native apple drivers. you dont need to do anything to get it working other than have 10.8.5 installed.

g\

Link to comment
Share on other sites

 Share

×
×
  • Create New...