Z790 Chipset & Raptor Lake

[MissCatD]

Question. I was reading on various sites that OpenCore 0.9.3 fixed the port limit patch, for Monterey/Ventura. Before my re-map, I was still limited, though. I'm hoping it was self-error, and my new map corrects it. But is this rumor true? I don't recall seeing anything in the patch notes.

 

[MissCatD]

I'd like to add a bit of clarification context for the above comment.

Recognizing and honoring that CaseySJ is an very capable and influential contributor, I'll say that following his lead always pays off.

But in this case he's making a distinction about which I want to offer some clarification.

As well as Hackintool, there are two other popular helper options:

• Corpnewt's USBmap, which runs on macOS, and expects a Python3 instance supplied by macOS or a user-installed Python3 (Apple's Python2.7 was removed from macOS at Monterey 12.3 and Python3 only comes with Xcode Developer Tools. USBmap got updated to Python3 but didn't bundle it, which leads to a headache for some users.

• USBToolBox is an enhancement of Corpnewt's USBmap, that runs as a self-contained Python environment on Windows or macOS and streamlines discovery and deployment for certain use-cases, which I will clarify below.

Conceptually, using any of these helpers is the the same approach:

1) Enable detection of all system ports beyond the macOS 15-port PCI root controller limit (up to a hard limit of 26 ports per root).

2) Determine (Detect) specific port locations and personalities, choose to enable only 15 for the main controller, and set port types accordingly (aka "mapping").

3) Generate and install a kext for the map.

Hackintool is oldest and most venerable helper. It uses XhciPortLimit quirk and USBInjectAll.kext as a generic "dummy" map for step 1

USBmap came next. It overcame the broken XhciPortLimit quirk by use of a custom "dummy" map which you generate in step (1). You install the dummy, complete step 2, and replace the dummy with the final map in step 3. By virtue of the dummy map USBInjectAll.kext is not needed.

USBToolbox upgraded USBmap and can run in Windows to skip both setting up XhciPortLimit and the dummy. It also includes an optional "shim" kext which hides the detail of what SMBIOS is in force for the map kext so you can change your config.plist platform SMBIOS without having to update your existing custom map kext. USBToolbox also has a macOS version, but you still need to use a dummy-map to detect all ports.
No matter what helper you choose, there are various of details about USB mapping, e.g. root controller 15 port limit, 26 port hard limit, USB versions and companion ports, port types—internal vs ext, switched vs unswitched USB-C, etc. These issues remain consistent no matter what helper you choose. There's an exotic issue of PCI root controller renames that is affected by which helper you use, but this only comes up in certain configs, and is an outlier situation.

Having any helper is far more helpful than any difference between the helpers!

The finer point is that what the helper actually does is create a map kext which is just a wrapper for a text config file (what's called a codeless kext, meaning no binary driver). So you could approach mapping by editing the kext's internal Info.plist to set the SMBIOS, controller and port config. You can look up the needed information using IORegistryExplorer and edit a boilerplate map kext by hand. The Helpers help merely by hiding various naming and config dependencies.

The broader point is that much of what you learn using any given helper is applicable to the other helpers.

Ultimately all these helpers are about a bit of convenience, and the details only truly makes sense when you examine the ways the USB hacks work. IOW for most of us it will never make sense!

Hackintool has a GUI and a local forum Beginner's Guide which introduces many important aspects of mapping. The Hackintool GUI is somewhat easier to read than text output of the others, but IMO the advantage is academic. Hackintool plus Guide is very valuable. But it is far from clear and complete.

USBmap helper is (IMO) more self-explanatory than Hackintool, which partly explains why there's no writeup. But also it's creation assumed previous experience with Hackintool.

USBToolbox evolves USBMap and has been written-up elsewhere on the web, including its Github, but the focus is on features added to USBmap because that's how the helper evolved.

IMO, USBToolbox should be today's reference, but since XhciPortLimit got fixed, the old Hackintool way is back in business.

If I were to write up a tutorial, I would explain mapping in 2 parts: one about USB config under macOS and the other about a specific helper. Then I would accumulate as much lore as possible in footnotes.

(I got well underway with such a writeup, but I ran into so much detail I didn't quite understand that I got frustrated and gave up on it.)

I hope this helps provide perspective.

Best to everyone and thx for the great great work and resources.

It's been so long since I've done this, this was very helpful. -(^-^)- Thank you.

 

[suren6791]

Question. I was reading on various sites that OpenCore 0.9.3 fixed the port limit patch, for Monterey/Ventura. Before my re-map, I was still limited, though. I'm hoping it was self-error, and my new map corrects it. But is this rumor true? I don't recall seeing anything in the patch notes.

I have the XhciPortLimit Quirk enabled in Kernel. Below is my mapped USB Ports.

 

[MissCatD]

I have the XhciPortLimit Quirk enabled in Kernel. Below is my mapped USB Ports.
View attachment 570037

And all of your ports work with both USB2 and USB3 devices? (O,0)

Oh, heads up, it may or may not be causing problems, but it looks like your "Connector" list is inaccurate. (O,0) Each USB3-compatible port should have a USB2.0 and a USB3.0 connector, which is why you're seeing duplicates (companions) of the same ports! All of your "Connector"s should either be 2.0 or 3.0, and nothing else. "Internal" and "USB-C" are only port-types, so you should keep those labels to the "name" or "comments"! (^ ^) Does that make sense? I know it can be a little confusing.

Basically, all of your ports are mapped as 3.0. Half of the duplicates should be set to 2.0. (^ ^)

In example, here's a manual port map that I did, last night, of my own build...

Port 1 - 2.0   | MB USB-C 20G
Port 2 -
Port 3 - 2.0   | Case USB-C (1)
Port 4 - 2.0   | MB USB-A 3.2 (1)
Port 5 - 2.0   | MB USB-A 3.2 (2)
Port 6 - 2.0   | MB USB-A 3.2 (3)
Port 7 - 2.0   | MB BIOS USB-A 3.2 (1)
Port 8 - 2.0   | MB BIOS USB-A 3.2 (2)
Port 9 - 2.0   | Case USB-A (3)
Port 10 - 2.0 | Case USB-A (2)
Port 11 - 2.0 | MB USB-A x4 Back Hub (1-4)
Port 12 - 2.0 | MB Internal Hub
                          - USB NZXT Internal Hub (LEDs)
                          - Fenvi Wifi/BT
                          - PSU
Port 13 - 2.0 | ITE Device (Intel Wifi? Phanteks Case?)
Port 14 - 2.0 | Intel Bluetooth
Port 15 -
Port 16 -
Port 17 - 3.0 | MB USB-C 20G
Port 18 - 3.0 | Case USB-C (1)
Port 19 - 3.0 | MB USB-A 3.2 (1)
Port 20 - 3.0 | MB USB-A 3.2 (2)
Port 21 - 3.0 | MB USB-A 3.2 (3)
Port 22 - 3.0 | MB BIOS USB-A 3.2 (1)
Port 23 - 3.0 | MB BIOS USB-A 3.2 (2)
Port 24 - 3.0 | Case USB-A (3)
Port 25 - 3.0 | Case USB-A (2)

I.E. Port 3 and Port 18 are companion ports! (^ ^) They're the same port in physical appearance, but are mechanically 2 separate ports, based on the device that you plug into it. So let's say, if your port limit is incorrect, you may be able to get a USB2.0 device to work in a 3.0 port, but the 3.0 port might be disabled by macOS, only allowing you to use 2.0 devices within it.

The blanks are unknown. Probably something I missed on the internal motherboard.

This is why having a 15-port limit can be extremely frustrating, hahaha. (T¬T)

 

[suren6791]

And all of your ports work with both USB2 and USB3 devices? (O,0)

Oh, heads up, it may or may not be causing problems, but it looks like your "Connector" list is inaccurate. (O,0) Each USB3-compatible port should have a USB2.0 and a USB3.0 connector, which is why you're seeing duplicates (companions) of the same ports! All of your "Connector"s should either be 2.0 or 3.0, and nothing else. "Internal" and "USB-C" are only port-types, so you should keep those labels to the "name" or "comments"! (^ ^) Does that make sense? I know it can be a little confusing.

Basically, all of your ports are mapped as 3.0. Half of the duplicates should be set to 2.0. (^ ^)

In example, here's a manual port map that I did, last night, of my own build...

Port 1 - 2.0   | MB USB-C 20G
Port 2 -
Port 3 - 2.0   | Case USB-C (1)
Port 4 - 2.0   | MB USB-A 3.2 (1)
Port 5 - 2.0   | MB USB-A 3.2 (2)
Port 6 - 2.0   | MB USB-A 3.2 (3)
Port 7 - 2.0   | MB BIOS USB-A 3.2 (1)
Port 8 - 2.0   | MB BIOS USB-A 3.2 (2)
Port 9 - 2.0   | Case USB-A (3)
Port 10 - 2.0 | Case USB-A (2)
Port 11 - 2.0 | MB USB-A x4 Back Hub (1-4)
Port 12 - 2.0 | MB Internal Hub
                          - USB NZXT Internal Hub (LEDs)
                          - Fenvi Wifi/BT
                          - PSU
Port 13 - 2.0 | ITE Device (Intel Wifi? Phanteks Case?)
Port 14 - 2.0 | Intel Bluetooth
Port 15 -
Port 16 -
Port 17 - 3.0 | MB USB-C 20G
Port 18 - 3.0 | Case USB-C (1)
Port 19 - 3.0 | MB USB 3.2 (1)
Port 20 - 3.0 | MB USB 3.2 (2)
Port 21 - 3.0 | MB USB 3.2 (3)
Port 22 - 3.0 | MB BIOS USB 3.2 (1)
Port 23 - 3.0 | MB BIOS USB 3.2 (2)
Port 24 - 3.0 | Case-B (3)
Port 25 - 3.0 | Case-B (2)

i.e. Port 3 and Port 18 are companion ports! (^ ^) They're the same port in physical appearance, but are mechanically 2 separate ports, based on the device that you plug into it. So let's say, if your port limit is incorrect, you may be able to get a USB2.0 device to work in a 3.0 port, but the 3.0 port might be disabled by macOS.

The blanks are unknown. Probably something I missed on the internal motherboard.

All ports, USB2 and USB3 work well with no issues.

 

[Edhawk]

@MissCatD you are providing incorrect information.

The only ports that should be set as USB2 (0) are physical USB 2.0 ports on the rear I/O plate, those with a black tang.

Any virtual USB2 port served from a physical USB3 port or motherboard header should be set to match the physical properties of the parent port, i.e. as a USB3 (3) port. They should never be set as a USB2 port.

Both ‘INTERNAL’ and ‘TYPE-C’ are required USB connector types when configuring your USB ports. They are not just for use in the comments section. They should be used as follows:

The Internal (255) connector type should be used for any and all ports served from the USB2 motherboard headers. This will include any Bluetooth, Webcam (laptop), USB2 case front card readers or USB2 case front ports that are connected to an Internal USB2 header.

The Type-c+sw connector type (9) should be used for any Type-C port on the rear I/O plate.

The Type-c connector type (10) should be used for any Type-C port served from a motherboard Type-C header, serving your case front Type-C port(s).

 

[MissCatD]

@MissCatD you are providing incorrect information.

The only ports that should be set as USB2 (0) are physical USB 2.0 ports on the rear I/O plate, those with a black tang.

Any virtual USB2 port served from a physical USB3 port or motherboard header should be set to match the physical properties of the parent port, i.e. as a USB3 (3) port. They should never be set as a USB2 port.

Both ‘INTERNAL’ and ‘TYPE-C’ are required USB connector types when configuring your USB ports. They are not just for use in the comments section. They should be used as follows:

The Internal (255) connector type should be used for any and all ports served from the USB2 motherboard headers. This will include any Bluetooth, Webcam (laptop), USB2 case front card readers or USB2 case front ports that are connected to an Internal USB2 header.

The Type-c+sw connector type (9) should be used for any Type-C port on the rear I/O plate.

The Type-c connector type (10) should be used for any Type-C port served from a motherboard Type-C header, serving your case front Type-C port(s).

My sincerest apologies, I never meant to communicate incorrect information. Based on everything that I have read from guides, articles and forum discussions alike for many years, along with my own mapping experience, this is how I have misunderstood USB Mapping. I was misled by tools notating Internal and C ports as 3.0, 2.0 and 1.1, and many, many guides state that companion ports should be listed as USB-2.0 - as that's what they come up as, when testing.

 

[UtterDisbelief]

My sincerest apologies, I never meant to communicate incorrect information. Based on everything that I have read from guides, articles and forum discussions alike for many years, along with my own mapping experience, this is how I have misunderstood USB Mapping. I was misled by tools notating Internal and C ports as 3.0, 2.0 and 1.1, and many, many guides state that companion ports should be listed as USB-2.0 - as that's what they come up as, when testing.

Hey, no worries. I'm forever getting things mixed up.

USB configuration can be a pain sometimes because of how the DSDT relates to macOS.

Port duplication is usually caused by an add-on Thunderbolt controller. If you see XHC3 along with the XHCI controller, this is a good sign. In Hackintool the controllers are listed in the top panel.

Some older motherboards also included an extra USB3 controller to supplement what the chipset could offer. A recipe for confusion.

 

[RUSSKIYVOLK]

Hi.I assembled a new assembly to replace the Z490 and the core i5 10600k. Core i5 13600K processor and msi pro Z790-A wifi motherboard.At first glance, everything works well. I enclose my EFI, if suddenly someone needs it. Knowledgeable people, could you look through my downloader, maybe there are flaws there?

 

[Edhawk]

Your OpenCore EFI folder content looks fine.

Except, you are missing a kext for your Intel 2.5GB Ethernet port.

You have IntelMausi.kext named but disabled in your config.plist. This kext wouldn't work with your 2.5GB Ethernet port.

AppleIGB.kext and dk.e1000=0 or e1000=0 boot argument might get your Ethernet port working in macOS.

USBPorts.kext:
Your USBPorts.kext is trying to activate 25 USB ports, this won't work. Just the first 15 ports will be activated. So one of the two USB2 physical ports (HS16) on the rear I/O plate, all the USB3 Physical ports and the physical Type-C port (SS01 to SS09 inclusive) will not work.

You seem to have only added HS06 (virtual USB2 port) in respect of the Type-C port. The physical Type-C port is either not included or has been set with connector type USB3 under SS06 (possible companion port to HS06).

As these USB ports are all served by a single USB controller the 15 port limit will come in to play quite drastically with this USBPorts.kext. You need to cull the number of ports being activated in the kext, so you have the ports you will use available.