Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[CaseySJ]

Hi @CaseySJ,

I explored more. I have been able to generate a custom USBmap.kext which only has Info.plist inside it (and not executable code), and used that to enable USB ports. I disabled all SSDT-UIAC-VISION-D-V*.aml. and USBInjectAll.kext. The ports were still working.

Having no extra code (through a kext) is a good thing, it lets OpenCore handles the port maps, since USBInjectAll is no longer maintained, this makes it even better and as dortania mentioned in my above post's quote, this makes it closer to "Real Mac" because Apple also uses similar method for port maps in real Macs.

I'll post more the proper custom USBMap.kext soon, which is very specific to our Vision D board. Dortania recommends having custom SSDTs and Port maps, as this reduces bloat and faster boot times compared to having generic SSDT and stuff, because those have to go through lots of of non-existing things to figure things our at start of the boot.

Current working config, without UIAC.aml's and no USBInjectAll.kext.

View attachment 524614View attachment 524615



Yes, that's correct. You will need either USBInjectAll.kext or a custom USB port map to enable proper working of the USB ports. This is because macOS is very poor in picking USB ports from ACPI tables. Thing is USBInjectAll.kext should be used temporarily while preparing config and booting into macOS for very first time. After that a custom map with limited no. of ports can be created (because macOS has limit of 15 ports limit, counting each hub as single unit). XhciPortLimit quirk is also meant to be temporary and be enabled while generating port map. After that, a new USBMap's plist should be used and both USBInjectAll.kext, XhciPortLimit should be removed. Even SSDT-UIAC-VISION-D-V*.aml ACPI tables shouldn't be needed as the new map can disable ports too.

All,

While it’s perfectly okay to create your own USBPort kext, it is not necessary. The Dortania guidelines are being misinterpreted. USBInjectAll is indeed being maintained by other developers (not the original developer), one of whom is me. There are two versions of USBInjectAll in the EFI folder — one for Mojave and the other for Catalina and up.

There is NOTHING WRONG with USBInjectAll. In fact there are advantages to USBInjectAll that do not exist with USBPort kext. For example, the ability to disable and enable specific USB ports with just a boot argument.

While everyone is always free to make their own choice, I do not want to perpetuate the impression that USBInjectAll somehow needs to be replaced. It does not.

 

[CaseySJ]

Hi @CaseySJ,

I am building a new system, with Z490 Vision D, i7-10700, 32GB DRAM and Sabrent M.2. My question is it will be housed in the BeQuiet 900 Dark Base ATX Full Tower case and the latest Vision D zip you have, will that work? The case is a bit different than the 500 but for the most part it should install. My parts arrive this week so I will hopefully be more knowledgable after building it.

Yes no problem. There’s plenty of room in that case. Any case that accommodates an ATX size motherboard is suitable for the Z490 Vision D. Larger cases, of course, accommodate water cooling pumps, more internal hard drives, larger GPUs, etc.

 

[CaseySJ]

Hi @CaseySJ
Can you please advise me. I changed my M.2 today to a 2TB and the speed of the drive is miserably slow. I see that it shows the link width only as X1 and the other 2 M.2 show as x4, is there any way to change this to X4. The previous M.2 was very fast. The brands are the same Crucial.
View attachment 524654

View attachment 524655

The third M.2 slot shares PCI lanes with the bottom long slot. There’s a table in the Vision D owner’s manual that explains what happens when a PCIe NVMe SSD is installed in the third M.2 slot. I don’t have access to manual at the moment, but you’ll find that table easily.

 

[MacArthur]

Thank you for finding this!! It’s been a very busy week at the office; will follow-up soon.

That's what I told you 3 days ago after comparing both config.plist of 0.71 EFI "brand new" and mine updated with hackinDROM (which enable update and activation of USBInject all).
But my post "pending moderator approval" (maybe because of attached screenshots) was not approved and therefore not published.
No worries about that, happy that I found the culprit and, if you remember well your questioning, happy to confirm there were neither UFO nor aliens around me as you were asking ;-)

 

[jeffgsm]

I have a 256GB Silicon Power NVMe SSD mounted inside a USB 3.2 Gen 2 enclosure connected to the front panel USB-C port on the Z490 Vision D. Results:

Conclusion:

• The front panel USB-C port is delivering USB 3.2 Gen 2 speed.

Hi Casey, by any chance is the Z490 Vision D front panel (F_U32C) USB Type-C capable of "USB 3.2 Gen 2x2 20Mbps" cause I get 10Mbps on SS01, reverse the plug, get 10Mbps on SS02 with a USB 3.2 Gen 2 device ? It appears both 10Mbps ports are wired to/from the MB Type-E header to Type-C connectors ? This appears very similar to the same location Z590 chipset port (ie. Z590 Vision D block diagram) that shows it as a 1 x USB 3.2 Gen 2x2. Via PCH, not RKL CPU.

I recently upgraded my OC 0.7.1 BigSur from a 10th Gen CPU to a i7-11700K (plus BIOS F20 for RKL support) and amazingly, it flies in default BIOS mode and is just as stable as any MB ! Yeah it can pull 250W and needed an extra cpu cooler fan. Plus after much pain I found a workaround for the RKL XMP BIOS mess - I have 3200MHz CL16 4x16GB ADATA mem, so every time you screw things up you MUST clear CMOS, Load BIOS Defaults, select XMP Profile 2, select DDR4-3600 (yeap not a typo - to get a magic system memory multiplier that works), can set "Gear 1 or leave as Auto, same result", "do nothing else !" then Save BIOS & reboot - Bingo, "Gear 1" @ 3,273Mhz Memory Clock (macOS shows a bit higher ?). Also the RKL CPU connected PCIe 4.0 NVMe M.2 works - tested with Gen3 NVMe - nice 3500/3000MB read/write with ADATA SX8200 Pro. Yeah no more PCH traffic jams I used Windows HwInfo to check available and used link speeds - can't find a Mac equiv. The GPU and adjacent PCIe X8 slot are PCIe 4.0. Even the RKL Xe iGPU works in 'VGA' (HD) mode out-of-the-box under Catalina & BigSur - no config.plist additions. Great backup if you just sold your dGPU - no acceleration but performance is quite useable, except GPU intensive games or apps.

BUT I still have the same confusion (F5 or F20 BIOS) with the rear Type-C ports (shared for Thunderbolt & USB). Somedays I can hotplug in & out USB 3.2 Gen 1 or 2 devices in and they work, other days they only run at USB 2. If I disable Thunderbolt in BIOS I completely loose the TR XHC/USB3 host, but always have USB2 via the Chipset XHC controller. Thunderbolt 3 devices work flawlessly - even mixed mode 1 x TB3 device and 1 x USB 3.2 device.
I'd love to know if a USB4/Thunderbolt 4 hub works with the original GC Z490 Vision D NVM-50 thunderbolt chip firmware - I already custom flashed your modded NVM-50 and it doesn't support the hubs ? I preferred not to risk re-flashing to test

On a brighter side, it appears Gigabyte designed these MBs and wrote the user manual before they knew what Rocket Lake was, so it now seems the Z490 chipset with GC's PCIe switches is a better MB than the Z590 chipset ?
I'll now keep my Z490 Vision D MB a bit longer . Attached a few system pix that may help others.
Cheers, J

 

[dsingh]

The below is what it shows in Hackintool after using the usbmap.kext and disabling the v2.aml. All my ports now show as Internal- Why?
View attachment 524636

That means the USBMap isn't loaded correctly, if you remove that too, you will see the same list as all Internal. This is default how macOS picks ports automatically without any kexts. Which USBMap.kext are you using, did you create your own? Are you using iMac19,x or iMac20,x?

 

[RandC]

The things to look for are - in last column when you are Discovering ports using that tool, the port types are correctly displayed (when USBInjectAll and V2, XhciPortLimit are temporarily enabled), it will range from 0, 3, 9 and 255. But for some reason, when generating the kext, it picks up and makes everything to 3. I had to manually set the types from Discovery section. Perhaps you can disable HS14 which is internal Intel WiFi (assuming you are not using that). If you are not going to modify RGB Fusion values on macOS, you can remove HS12. HS11 is internal header USB 2.0 Hub at the bottom of the board. If you have nothing plugged in there (Fenvi card usually go there) you can turn that off. Also disable HS02 because it doesn't map to anything, same goes with SS08, SS09, SS10 (maybe SS11 if it exists). You'll now only need to remove 2-3 more ports, that may need some care.

@dsingh Thanks so much for your help. I probably would not have notice the type issue. What I did was boot with Casey's defaults, e.g., USBInjectALL enabled, an SSDT enabled and XhciPortLimit enabled, e.g. what I had working in OC 0.7.0. I then ran USBMap, Discover Ports. It didn't show HS02, SS08 or anything higher. So I'll change the types and start will that. Thanks again for your assistance.

 

[RandC]

Thanks @dsingh. I found a project on GitHub called USBMap which will automate the process. https://github.com/corpnewt/USBMap. So I've got a USBMap.kext made by that program. It does work. I can boot but some of my USB ports are not working. (I turned everything on.) I think I need to to back to SSDT-UIAC-VISION-D-V2.ami[*] and figure out what to turn off.

Thanks again for your help.

Rand

Although HS02, etc were not in the list displayed, they were in the info.plist. So I'll have to remove them as you suggested. Thanks.

Rand

 

[dsingh]

@dsingh Thanks so much for your help. I probably would not have notice the type issue. What I did was boot with Casey's defaults, e.g., USBInjectALL enabled, an SSDT enabled and XhciPortLimit enabled, e.g. what I had working in OC 0.7.0. I then ran USBMap, Discover Ports. It didn't show HS02, SS08 or anything higher. So I'll change the types and start will that. Thanks again for your assistance.

Those won't be displayed in the discovery section. But while creating the kext, it will show you all the ports. Here, you can toggle to enable/disable the ports you don't want by entering comma separated list like 2,14 etc. The last column here, may show you all port types as 3. You may need to correct those to what you saw in Discovery section. To set types, for example, enter T:2,3,4,5:9 - this will set type of 2,3,4 and 5 ports to type '9'. Valid types are 0, 3, 9, 255. Just match everything from the discovery section of you can also use V2.aml for that. Afterwords, I confirmed everything to be matching with V2.aml.

Good luck.

 

[dsingh]

In fact there are advantages to USBInjectAll that do not exist with USBPort kext. For example, the ability to disable and enable specific USB ports with just a boot argument.

the USBMap generated plist looks like this:

...
<key>IOProviderClass</key>
<string>AppleUSBXHCIPCI</string>
<key>IOProviderMergeProperties</key>
<dict>
<key>kUSBMuxEnabled</key>
<true/>
<key>port-count</key>
<data>
FwAAAA==
</data>
<key>ports</key>
<dict>
<key>HS01</key>
<dict>
<key>UsbConnector</key>
<integer>9</integer>
<key>port</key>
<data>
AQAAAA==
</data>
<key>Comment</key>
<string>Front Panel USB 3.1 Gen 2 Type C, 2.0 personality</string>
</dict>
<key>HS02</key>
<dict>
<key>#port</key>
<data>
AgAAAA==
</data>
<key>UsbConnector</key>
<integer>0</integer>

</dict>
<key>HS03</key>

The USB port can be disabled easily by commenting out "port" like is done with HS02 above. It's straightforward and easy if you use ProperTree, in case people don't want to edit XMLs directly like I do.

It is equivalent to USBInjectAll which uses boot args to enable/disable specific port. The above example is neat because it is possible to add <comment> to each USB port section to help people remember which port they are disabling. Like I did for the HS01 above. This is not possible when using SSDT-UIAC*.aml and USBInjectAll because those comments may not be compiled and removed.
I had go through the process of looking at reference back and forth to test each port until I remembered all of it.
Once all comments are added, any other person can simply open the Info.plist to enable/disable ports of their like by simply reading the comments. They won't have to know each port by their internal ACPI names.

Moreover, I think if a simpler solution exists, it should be the right one. Occam's razor principle.
If OpenCore itself handles all of the above natively, I'd prefer using that method, instead of having another executable binary which loads into the kernel and do the same while system is loading. Kexts make system unstable if they are not programmed correctly, and if they are not maintained with newer APIs every year. There can be memory leakage problems with them, any bug in kext will compromise the whole system because they run in elevated space of memory which has access to everything. This is the reason why Apple is moving those to user space using DriverKit, where rest of apps run. They are loaded when app is loaded and shipped with it. This is the reason we see so many things getting deprecated like IOPCIDevice recently in favor of DriverKit's PCI APIs.

You can learn more about problems with kexts and their modern alternate - DriverKit here https://developer.apple.com/videos/play/wwdc2019/702/

In short, kexts should be avoided if another simpler solution is possible. That should make the system more stable. Kexts are hard to write, so I prefer inbuilt kexts over external where possible.