Contribute
Register

XHC USB Kext Creation Guideline

Status
Not open for further replies.
Precision M6800 said:
Sorry I did a post by a mistake
Click to expand...

Well it might be the correct fully implemented kext for your motherboard. You still have to derive the generally applicable truncated 15 port kext out of it, anyway. The USB adapters for testing could be purchased at any electronic store in your neighbourhood and are quite cheep anyway.

You need to verify the kext for ALL implemented onboard USB2.0 and USB3.0 connectors/headers.
 
So, I am working at the kext for the Gigabyte Z390 Designare.

It behaves a little different as my other boards.

1) If I use XHCI as IONameMatch it gets stuck at the beginning of the boot process (Apple Logo with progress bar).
The others were booting normally but without effect on the USB Ports.
Do I have to patch Names in Clover or do Gigabyte Boards generally need "XHC" instead?

2) I do not get F_USB31C to work. This should be an USB 3.1 Gen2 Port (9) on HS01 and SSP1. If I insert HS01 with
"UsbConnector 9", the board gets also stuck at Apple Logo. If I throw HS01 Out, everything is fine but Port SSP1 is
not working. I tested with USB2 and USB3 device, I have no USB C Stick. There is a "normal" USB connector beside
the small USB-C type at the Front Panel. I supposed, they belong together. Maybe not, but the "normal" one also
doesn't respond on any other HS Port and I have no internal Case connector Cable left. Strange.

kgp, could you please have a look at my .aml´s for USB Power? are they correct?
 

Attachments

  • Racke-iMacPro-Z390Designare-XHCI-work.kext.zip
    2.1 KB · Views: 62
  • SSDT-EC.aml
    63 bytes · Views: 80
  • SSDT-USBX.aml
    185 bytes · Views: 78
Last edited:
Racke said:
So, I am working at the kext for the Gigabyte Z390 Designare.

It behaves a little different as my other boards.

1) If I use XHCI as IONameMatch it gets stuck at the beginning of the boot process (Apple Logo with progress bar).
The others were booting normally but without effect on the USB Ports.
Do I have to patch Names in Clover or do Gigabyte Boards generally need "XHC" instead?

2) I do not get F_USB31C to work. This should be an USB 3.1 Gen2 Port (9) on HS01 and SSP1. If I insert HS01 with
"UsbConnector 9", the board gets also stuck at Apple Logo. If I throw HS01 Out, everything is fine but Port SSP1 is
not working. I tested with USB2 and USB3 device, I have no USB C Stick. There is a "normal" USB connector beside
the small USB-C type at the Front Panel. I supposed, they belong together. Maybe not, but the "normal" one also
doesn't respond on any other HS Port and I have no internal Case connector Cable left. Strange.

kgp, could you please have a look at my .aml´s for USB Power? are they correct?
Click to expand...

What is the original IONameMatch for the Gigabyte Z390 Designare in IOREG, implemented by macOS without using any USB kext or SSDTs? Should be also hard-wired in your DSDT.aml..

I usually use XHCI on X99 and X299 in line with SSDT-X299-XHCI.aml + SSDT-DTPG.aml.zip

If your motherboard ACPI table features anything else then XHCI, you can do a simple ACPI replacement within the SSDT. Assuming that your hardwired IONameMatch is XHC, you would perform the following XHC -> XHCI replacement within the attached SSDT:


Code: 
DefinitionBlock ("", "SSDT", 1, "KGP", "X299XHCI", 0x00000000)
{
    External (_SB_.PCI0.XHC, DeviceObj)    // (from opcode)
    External (DTGP, MethodObj)    // 5 Arguments (from opcode)

Scope (\_SB.PCI0)
    {
        Scope (XHC)
        {
            Name (_STA, Zero)  // _STA: Status
        }


        Device (XHCI)
        {
            Name (_ADR, 0014000000)  // _ADR: Address
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {

            .
            .
            .
            .
            }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
        }     
    }
}

In the kext you would use IONameMatch XHCI subsequently. Anyway, I always thought the IONameMatch of the kext is directly applied to the USB ACPI table. Thus, if one would use IONameMatch XHC in the kext, one would find XHC in the USB ACPI table, while if one would use IONameMatch XHCI in the kext, one would find XHCI in the USB ACPI table. I never considered the additional ACPI replacement XHC -> XHCI necessary. Either using XHC or XHCI, all ports defined in your kext should be implemented.

To avoid improper USB power assignments during boot, I use SSDT-X299-USBX.aml.

To simulate the missing EC controller on Gigabyte motherboards, you should use SSDT-EC.aml developed by @apfelnico.

A USB 3.1 Gen2 port is never assigned to the USB XHC (XHCI) Controller but is usually implemented on different controllers.

Note that USB 3.1 Gen2 is USB 3.1, while USB 3.1 Gen1 is USB3.0, which indeed can be part of the USB XHC (XHCI) Controller ACPI table implementation. One would use "9" or "10" only in case of a USB 3.1 Gen1 Type-C connector (USB3.0 Type-C connector), where "9" means double sided (device can be plugged both ways) and "10" means single sided (device cannot be flipped).

Try to generate and upload a port-layout for the Gigabyte Z390 Designare in line with your kext. Subsequently I can analyse both.

EDIT: btw.. don't forget to use boot flag npci=0x2000 in your config.plist with Gigabyte boards. Maybe this is the source for your current boot issues?

Good luck
 

Attachments

  • SSDT-X299-XHCI.aml.zip
    1.2 KB · Views: 98
  • SSDT-X299-USBX.aml.zip
    983 bytes · Views: 116
  • SSDT-DTPG.aml.zip
    852 bytes · Views: 99
  • SSDT-EC.aml.zip
    4.5 KB · Views: 96
Last edited:
kgp said:
What is the original IONameMatch for the Gigabyte Z390 Designare in IOREG, implemented by macOS without using any USB kext or SSDTs? Should be also hard-wired in your DSDT.aml..

I usually use XHCI on X99 and X299 in line with SSDT-X299-XHCI.aml + SSDT-DTPG.aml.zip

If your motherboard ACPI table features anything else then XHCI, you can do a simple ACPI replacement within the SSDT. Assuming that your hardwired IONameMatch is XHC, you would perform the following XHC -> XHCI replacement within the attached SSDT:


Code: 
DefinitionBlock ("", "SSDT", 1, "KGP", "X299XHCI", 0x00000000)
{
    External (_SB_.PCI0.XHC, DeviceObj)    // (from opcode)
    External (DTGP, MethodObj)    // 5 Arguments (from opcode)

Scope (\_SB.PCI0)
    {
        Scope (XHC)
        {
            Name (_STA, Zero)  // _STA: Status
        }


        Device (XHCI)
        {
            Name (_ADR, 0014000000)  // _ADR: Address
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {

            .
            .
            .
            .
            }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
        }    
    }
}

In the kext you would use IONameMatch XHCI subsequently. Anyway, I always thought the IONameMatch of the kext is directly applied to the USB ACPI table. Thus, if one would use IONameMatch XHC in the kext, one would find XHC in the USB ACPI table, while if one would use IONameMatch XHCI in the kext, one would find XHCI in the USB ACPI table. I never considered the additional ACPI replacement XHC -> XHCI necessary. Either using XHC or XHCI, all ports defined in your kext should be implemented.

To avoid improper USB power assignments during boot, I use SSDT-X299-USBX.aml.

To simulate the missing EC controller on Gigabyte motherboards, you should use SSDT-EC.aml developed by @apfelnico.

A USB 3.1 Gen2 port is never assigned to the USB XHC (XHCI) Controller but is usually implemented on different controllers.

Note that USB 3.1 Gen2 is USB 3.1, while USB 3.1 Gen1 is USB3.0, which indeed can be part of the USB XHC (XHCI) Controller ACPI table implementation. One would use "9" or "10" only in case of a USB 3.1 Gen1 Type-C connector (USB3.0 Type-C connector), where "9" means double sided (device can be plugged both ways) and "10" means single sided (device cannot be flipped).

Try to generate and upload a port-layout for the Gigabyte Z390 Designare in line with your kext. Subsequently I can analyse both.

EDIT: btw.. don't forget to use boot flag npci=0x2000 in your config.plist with Gigabyte boards. Maybe this is the source for your current boot issues?

Good luck
Click to expand...
The original IONameMatch is "XHC". If this is not a problem for Apple, I will leave it as it is.

Hm, if I plug an USB3 Device in the USB 3.1 Gen 2 Port on the Backplate, it pops up in SSP4. So it seems assigned to the XHC Controller.

Screenshot 2019-01-26 at 22.02.02.png
Screenshot 2019-01-26 at 22.02.41.png


My other problem while trying to get the Frontpanel Thunderpolt to work is solved by just reading the case manual. The USB port beside it has nothing to do with it ( I thought it was an USB port directly connected to Thunderbolt as I misunderstood the (wrong) SSDT creation from another threat while comparing to my kext)
It is no USB port, but just a Quickloading Connector.

My Boot Problem is still unsolved, even if it has not happened the last 5 Boots. It started, when I switched from RX580 to Vega 64.
 
kgp said:
If you use SMBIOS iMacPro1,1, you might also want to change IONameMatch XHC to XHCI. No idea if for this motherboard you also need an additional ACPI replacement XHC -> XHCI in your config.plist in this case.

Good luck,

KGP
Click to expand...

Hm, why? What exactly is these XHC/XHCI stuff doing? Sorry for asking, I'm sure there is somewhere an explanation in this board already? Never mind, will search around. It's off-topic, but meanwhile, I figured out why I use iMacPro1,1 - with iMac18,3 quicklook preview of JPEGs doesn't work anymore.

Anyhow, it's great to be able to run macOS on standard hardware so I'd like to thank you and all others here for your great support to make it possible and easy. :)
 
Build 1
ROG MAXIMUS X HERO |  i7 8700K |  RX 570 Pulse 8GB
oklhost said:
Hm, why? What exactly is these XHC/XHCI stuff doing? Sorry for asking, I'm sure there is somewhere an explanation in this board already? Never mind, will search around. It's off-topic, but meanwhile, I figured out why I use iMacPro1,1 - with iMac18,3 quicklook preview of JPEGs doesn't work anymore.

Anyhow, it's great to be able to run macOS on standard hardware so I'd like to thank you and all others here for your great support to make it possible and easy. :)
Click to expand...

You can either use XHC or XHCI, everything rather depends on the proper port definition within your XHC USB kext. XHCI is only preferential when using my SSDT-X299-XHCI.aml, but one can also adopt the latter for its use with XHC. SMBIOS iMacPro1,1 is a very good choice anyway and also the baseline for my X99 and X299 guides ;)..
 
Racke said:
The original IONameMatch is "XHC". If this is not a problem for Apple, I will leave it as it is.

Hm, if I plug an USB3 Device in the USB 3.1 Gen 2 Port on the Backplate, it pops up in SSP4. So it seems assigned to the XHC Controller.

View attachment 382498View attachment 382499

My other problem while trying to get the Frontpanel Thunderpolt to work is solved by just reading the case manual. The USB port beside it has nothing to do with it ( I thought it was an USB port directly connected to Thunderbolt as I misunderstood the (wrong) SSDT creation from another threat while comparing to my kext)
It is no USB port, but just a Quickloading Connector.

My Boot Problem is still unsolved, even if it has not happened the last 5 Boots. It started, when I switched from RX580 to Vega 64.
Click to expand...

Your screenshot states USB3.0 and not USB3.1 for the device connected to SSP4. Thus the respective USB port might be USB3.1 Gen1 instead? What happens when connecting a USB3.1 device to the same connector? Does it also show up under SSP4? Anyway, if SSP4 is assigned to this connector, you also have to implement it in your kext. What about the respective HS port? Is SSP4 else assigned to any other USB3.0 connector?

Your boot problem might not be related with the XHC USB kext but rather with your GPU implementation?
 
kgp said:
Your screenshot states USB3.0 and not USB3.1 for the device connected to SSP4. Thus the respective USB port might be USB3.1 Gen1 instead? What happens when connecting a USB3.1 device to the same connector? Does it also show up under SSP4? Anyway, if SSP4 is assigned to this connector, you also have to implement it in your kext. What about the respective HS port? Is SSP4 else assigned to any other USB3.0 connector?

Your boot problem might not be related with the XHC USB kext but rather with your GPU implementation?
Click to expand...
Well, if Gigabyte is not lying, SSP3 and SSP4 are USB 3.1 Gen 2 Connectors. Anyway, I will get a real USB 3.1 device and a thunderbolt device this evening and will check what will happen if I plug this in.

There are different boot problems to solve. First is surely connected to my Graphic card.
With the RX580 I have no problem at all
With the Vega 64 and with USBinjectall combined with a functional SSDT it stops sometimes in the middle of the boot progress bar.
With Vega 64 and correct USB-XHC.kext it stops sometimes at the beginning of the Boot progress bar
With wrong implemented USB-XHC.kext it doesn't boot at all.

I will search with verbose mode for the reason

Strange, as you can see I had a few hacks before and never had this problems. perhaps I should flash the Bios of my Vega
Anyway, this doesn't belong to this threat, but is the reason for my delayed kext delivery
 
Racke said:
Well, if Gigabyte is not lying, SSP3 and SSP4 are USB 3.1 Gen 2 Connectors. Anyway, I will get a real USB 3.1 device and a thunderbolt device this evening and will check what will happen if I plug this in.

There are different boot problems to solve. First is surely connected to my Graphic card.
With the RX580 I have no problem at all
With the Vega 64 and with USBinjectall combined with a functional SSDT it stops sometimes in the middle of the boot progress bar.
With Vega 64 and correct USB-XHC.kext it stops sometimes at the beginning of the Boot progress bar
With wrong implemented USB-XHC.kext it doesn't boot at all.

I will search with verbose mode for the reason

Strange, as you can see I had a few hacks before and never had this problems. perhaps I should flash the Bios of my Vega
Anyway, this doesn't belong to this threat, but is the reason for my delayed kext delivery
Click to expand...

If SSP3 and SSP4 are really associated to USB 3.1 Gen 2 Connectors, does this not also imply some yet likely still undiscovered association of these connectors with respective HS ports? Did you check on the latter?
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top