MSI Z690I Unify usb ports mapping

[badformat]

Thanks guys for your guidance.

I finally created usbmap.kext.

What helped:

1) The latest version of usbinjectall supported 600 mobos

2) PortLimit off in config

3) USBmap tool

4) uia_exclude/include boot args to see all HSs and SSs

I mapped 3 internal ports:

• RGB Mystic Light
• USB 2.0 Hub
• Intel WiFi/BT

8 HS ports
4 SS ports

15 ports total.

Looks like most of things works fine, but sleep.

I still got random wakes from Normal Sleep to Darkwake and back.

DarkWake from Normal Sleep [CDN] : due to XDCI RP09 RP08 RP21/ Using AC (Charge:0%) 12 secs

And I still don’t know how to fix it.

 

[c-o-pr]

The System Prep guide says a number of systems DO NOT require these patches. I assume you and @badformat have systems that don't require the rename patches. Theoretically that is!

• iMac18,x and newer
• • •

I don't know why they wouldn't need to use the rename patches, if they have the XHCI or XHC1 USB controller. As the same clashes could still occur.

Hope this helps.

Thanks for the illuminating background!

The list you provided covers how it is I'm not using the rename, 'cause I'm using late model iMac,20,2 SMBIOS.

When you write "avoid Hackintosh USB controllers clashing with the Apple controllers" I can read that sentence and parse it and feel like I know what you're talking about, but I have no idea what it means — what was conflicted? Why wouldn't USB want to look like mac USB?

Maybe I don't want to know the answer because the fact is I have almost no idea how any of ACPI stuff works. I know the PC industry standardized a big data structure which lives in the board and is consulted by the OS to grok the available HW. I know the point of the data structure is to abstract per-OEM/make/model layouts into idioms for consumption by the OS. Obviously Apple systems have personalities like any PC. I can see the idea of Lilu acting as a shim to allow editing the ACPI data structure underneath the OS to bring a hack board into better logical alignment with macOS. So with this 20,000 ft. view I grok the intrinsic value of ACPI renaming, but I've never seen first-hand how these needed adjustments are determined and chosen. I'm interested in the nuanced meaning of the terms "clash" or "conflict" per hack ACPI.

For an example of how my thinking works: In this USB case, I can imagine that a specific Mac model (SMBIOS) XHCI has certain Apple-defined layout constraints about which macOS makes assumptions which do not hold true for a PC mainboard. These constraints are bypassed by making the controller appear as a foreign name (rename), which presumably macOS treats more openly, but we have to add the secret sauce of missing layout details through a codeless kext, therefore USB port mapping. Am I on the right track?

Thanks again for the rundown.

 

[UtterDisbelief]

Thanks for the illuminating background!

The list you provided covers how it is I'm not using the rename, 'cause I'm using late model iMac,20,2 SMBIOS.

When you write "avoid Hackintosh USB controllers clashing with the Apple controllers" I can read that sentence and parse it and feel like I know what you're talking about, but I have no idea what it means — what was conflicted? Why wouldn't USB want to look like mac USB?

Maybe I don't want to know the answer because the fact is I have almost no idea how any of ACPI stuff works. I know the PC industry standardized a big data structure which lives in the board and is consulted by the OS to grok the available HW. I know the point of the data structure is to abstract per-OEM/make/model layouts into idioms for consumption by the OS. Obviously Apple systems have personalities like any PC. I can see the idea of Lilu acting as a shim to allow editing the ACPI data structure underneath the OS to bring a hack board into better logical alignment with macOS. So with this 20,000 ft. view I grok the intrinsic value of ACPI renaming, but I've never seen first-hand how these needed adjustments are determined and chosen. I'm interested in the nuanced meaning of the terms "clash" or "conflict" per hack ACPI.

For an example of how my thinking works: In this USB case, I can imagine that a specific Mac model (SMBIOS) XHCI has certain Apple-defined layout constraints about which macOS makes assumptions which do not hold true for a PC mainboard. These constraints are bypassed by making the controller appear as a foreign name (rename), which presumably macOS treats more openly, but we have to add the secret sauce of missing layout details through a codeless kext, therefore USB port mapping. Am I on the right track?

Thanks again for the rundown.

These are questions and observations for a separate thread as they are not supporting the OP and their problem. However I can see that @badformat has now mapped their ports using the classic method. By all means start a thread over in Post Installation / General Help where the USB guides are to carry on the discussion.

Looks like most of things works fine, but sleep.

I still got random wakes from Normal Sleep to Darkwake and back.

You might want to consider disabling that "Hub" which will cause continuing sleep/wake problems.

 

[badformat]

These are questions and observations for a separate thread as they are not supporting the OP and their problem. However I can see that @badformat has now mapped their ports using the classic method. By all means start a thread over in Post Installation / General Help where the USB guides are to carry on the discussion.



You might want to consider disabling that "Hub" which will cause continuing sleep/wake problems.

I'm not sure that I understand how to do that. I'm not even sure that I've found the proper reason. pmset log tell me that I have an issue with RP09 RP08 RP21. The only information about these RPs I can find in IORegistry Explorer:

I guess I need to search the net to find a way to disable ACPI devices/ACPI paths.

 

[UtterDisbelief]

I'm not sure that I understand how to do that. I'm not even sure that I've found the proper reason. pmset log tell me that I have an issue with RP09 RP08 RP21. The only information about these RPs I can find in IORegistry Explorer:

View attachment 552369

I guess I need to search the net to find a way to disable ACPI devices/ACPI paths.

Looks like USB on another controller. I am not sure because I am not familiar with your MSI motherboard but checking the specs on their site I see that there is Thunderbolt controller in the mix. Also, separately to this the ALC4080 audio codec may be connected by internal USB?

A good idea is to run the Hackintool app and check the USB tab. That should give you more user-friendly information.

 

[badformat]

These are questions and observations for a separate thread as they are not supporting the OP and their problem. However I can see that @badformat has now mapped their ports using the classic method. By all means start a thread over in Post Installation / General Help where the USB guides are to carry on the discussion.



You might want to consider disabling that "Hub" which will cause continuing sleep/wake problems.

Well, I've found out that after sleep one of the controllers stops working.

I have 2 controllers:

_SB_.PC00.XHCI.RHUB
_SB_.PC00.RP05.PXSX.TBDU.XHCI.RHUB (Thunderbolt 4 Maple Ridge (2020))

I know that _SB_.PC00.XHCI.RHUB is responsible for these ports:

+ RGB
+ Wifi/BT

I use only USB ports on a back panel.

and this controller _SB_.PC00.RP05.PXSX.TBDU.XHCI.RHUB is responsible for these ports (USB type C only SS, HS is controlled by _SB_.PC00.XHCI.RHUB):

I don't use Thunderbolt ports but I use USB Type C ports. Basically I have my external SSD and external audio usb interface plugged in to these 2 Type C ports.

These 2 Type C ports are mapped with 4 ports: two HS and two SS. My usb audio interface uses HS and my external SSD uses SS port.

After sleep my SSD drive is reconnecting from SS to HS port since _SB_.PC00.RP05.PXSX.TBDU.XHCI.RHUB controller is missing and there are no SS ports. I'm not sure what I did wrong with mapping. I'll continue to investigate.

BTW

_SB_.PC00.RP05.PXSX.TBDU.XHCI.RHUB controller can be switched on/off in BIOS using this parameter:

But I don't want to disable it since I use both Type C ports.

And my integrated audio is disabled also.

 

[badformat]

I've got an update regarding Thunderbolt patching, I'll leave a comment a bit later.

 

[badformat]

So,

Since my Type C ports are part of Thunderbolt I started to research how to patch my Thunderbolt component.

I found out that MSI Z590I Unify has the same Thunderbolt controller as Z690I Unify - JHL8540.

First I started to check an instruction how to patch Thunderbolt on another website, but since there wasn't specific instruction for Z590I/Z690I board I found post here. This one: https://www.tonymacx86.com/threads/...underbolt-4-maple-ridge-set-up-issues.321135/

@CaseySJ helped a lot there. I downloaded his Thunderbolt and DTPG aml files, changed the ACPI path to match with mine _SB_.PC00.RP05, added these .aml. files and that's it basically.

I didn't check Thunderbolt ports since I don't have Thunderbolt devices, but now I have a proper system information:

After this I decided to map my ports again. I removed all USB kexts, added the latest USBInjectAll and started the same process again (with uia_exclude).

This time my Type C SS was mapped to Thunderbolt Controller (XHC3) and Type C HS was still mapped to the second controller. (XHCI).

But I still had a problem with DarkWake/Instant wake and automatic SSD ejection after wake.

So I started to check all connected USB devices and the culprit was my external SSD. After I reconnected it from type C port to USB 3 (using type c to usb3 adapter) all problems are gone.

No DarkWake (perfect sleep) and no SSD ejection.

I don't know why there is sleep/wake issues with SSD connected to Type C port on Thunderbolt Controller, maybe because it is an NTFS drive connected via Paragon Software or something wrong with my ports or Thunderbolt mapping but I decided to not suffer anymore and keep it as it is.

 

[badformat]

so thuderbolt works now ? full speed?

I don't know. I've never was chasing for TB.

And unfortunately, I don't have any TB device to check.

My issues was with usb devices connected to Type C ports (and these ports are the part of TB controller) and with instant darkwake.

After:

1. Thunderbolt patching
2. USB Mapping
3. Changing ports for my external SSD from Type C to USB3

I don't have this issues anymore.

Of course I would love to have my SSD working after wake plugged to Type C but I tired for searching the specific solution.

 

[badformat]

your usb port mapping, is there any tradeoffs? or could you utilise everything? im wondering weather to get a drop in replacement for that onboard pci wifi thats under the heatsink, or just use the openintwlwireless driver and make do without air drop

I have an idea how to double check if my type c ss really works as it should. I’ll do it later this week. Except my problem with external ssd connected to this type c port I have no issues.

You don’t need to change built in wifi/bt card. Intel works pretty good to me. You just need to have the latest kexts (with IntelBtpatcher kext to make bt working)