Contribute
Register

Z490 & Z590

Joined
Feb 16, 2012
Messages
164
Motherboard
Z590i Vision D
CPU
i7-11700
Graphics
RX560
Mac
  1. MacBook Air
That's what I got today from Gigabyte about the non-working Thunderbolt 4.

"Thank you for the information I forward to TW. Until now, unfortunately, I have not received information either about the confirmation of the problem or about possible solutions. The only information I have is that the control panel needs more time for analysis."
 
Joined
Sep 25, 2019
Messages
73
Motherboard
Gigabyte z590i vision d
CPU
i9-10900K
Graphics
MSI RX5500XT Gaming X 8GB
Hey Sash11, did you test the Thunderbolt? Do you believe the flashing is going to be necessary?
What about the Bluetooth 5.1?
My video card Radeon VII on photoshop and Lightroom are terrible. My Magic Mouse on Fenvi bluetooth it's super sluggish, I can't find a solution. I tried to get an eGPU, but I couldn't make it to work with my Z490. I didn't flash because I have such bad luck with this kind of procedures.
I appreciate your input.

Thanks
Fabrik
I have not tested the TD4 yet - don't have any devices with that interface. However I do not see it listed under PCI or Thunderbolt/USB4 sections in System Report.
For WiFi/Bluetooth I'm using native module BCM94360NG that works OOB. Magic Keyboard and Trackpad have no issues. As far as video is concerned - I don't do any video editing these days. But I will run some benchmarks to see how performance looks. CPU has full metal acceleration with AAPL,ig-platform-id 07009B3E.

P.S. My RX5500XT worked with boot argument agdpmod=pikera. Otherwise I was getting a black screen. Also I've disabled Booter Quick ProvideCustomSlide and added another boot argument slide=0, based on debug info from opencore on this board:
65:321 00:111 OCABC: Only 130/256 slide values are usable!
65:432 00:111 OCABC: Valid slides - 0-77, 185-236
 
Last edited:
Joined
Sep 25, 2019
Messages
73
Motherboard
Gigabyte z590i vision d
CPU
i9-10900K
Graphics
MSI RX5500XT Gaming X 8GB
Got i225-V ethernet working with just a Device Properties entry and Kernel Patch entry, just like Dortania's guide suggests:
I did not use any of the kexts:
FakePCIID.kext
FakePCIID_Intel_I225-V.kext
FakePCIID_Intel_HDMI_Audio.kext
 

Attachments

  • Screen Shot 2021-04-21 at 16.34.09.png
    Screen Shot 2021-04-21 at 16.34.09.png
    35.1 KB · Views: 38
  • Screen Shot 2021-04-21 at 16.34.44.png
    Screen Shot 2021-04-21 at 16.34.44.png
    12.2 KB · Views: 36
Joined
Apr 12, 2021
Messages
33
Motherboard
ASUS ROG Z590 Maximus XIII Hero
CPU
i9-10900K
Graphics
Radeon Pro W5700
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Classic Mac
  1. Centris
  2. Power Mac
Mobile Phone
  1. iOS
Re not needing the v225 kexts:

Thank you for this heads-up!

Either I didn't see that kernel patch or it was edited into the guide since I followed those steps guide a while ago? I followed your example and works fine.

I also see that FakePCIID_Intel_HDMI_Audio.kext is not only impertinent my system in context but the whole approach is a total hold-over from a previous era.

This never should have got into my config.

Also, most of the original purpose of FakePCIID.ext plus its companion Intel HD kexts have been subsumed by WhateverGreen and AppleALC.

As these advances are occurring while we work, a lot of config experience in the forums that was helpful just a year ago is now pure lore. I praise the level of development and support to the OpenCore community, and at same time from my pov standing on shoulders of giants, maybe it's not getting easier...? I wish Golden Build forum could be a searchable db of proven configs by generation.
 
Joined
Oct 24, 2013
Messages
388
Motherboard
Gigabyte Z590 Vision D
CPU
i7-11700K OC @ 5.2GHz
Graphics
RX 6800 XT
Mac
  1. iMac
  2. MacBook
  3. MacBook Pro
Mobile Phone
  1. iOS
That's what I got today from Gigabyte about the non-working Thunderbolt 4.

"Thank you for the information I forward to TW. Until now, unfortunately, I have not received information either about the confirmation of the problem or about possible solutions. The only information I have is that the control panel needs more time for analysis."
My dialogue with Gigabyte support is similarly frustrating. They seem to be way in over their heads on this Thunderbolt 4 hot-plug support issue. At this point in their correspondence with me, they are now blaming the firmware of my devices on the hot-plug issue, even though these devices hot-plug just fine with Titan Ridge and also with an Asus z590 motherboard with Maple Ridge, NVM24.

Gigabyte has said they've tested certain Thunderbolt 3 devices, that hot-plug fine with their Z590 Vision D. But what I pointed out to Gigabyte is we need to be as clear as possible so that we can resolve the issue. Lack of clarity is part of the problem.

As I have dug into this issue some more, what I am observing is "Thunderbolt 3" is a simple term, but the reality is more complicated. So we must unpack. There are in fact various Thunderbolt 3 controllers embedded into devices on the market. As we know, there is Alpine Ridge and Titan Ridge. And within the Alpine Ridge "family" there are at least 3 different controllers in use in various peripheral devices, JHL6240, JHL6340, and JHL6540.

After testing, a pattern is emerging. Non-functional hot-plugging on the Z590 Vision D appears to apply to Thunderbolt 3 devices with Alpine Ridge JHL6240 and JHL6540 controllers inside, but not JHL6340 inside. What happens when JHL6240 and JHL6540 devices are plugged into the Z590 Vision D while the OS is running is that the Thunderbolt enclosure is recognized in Windows Thunderbolt control center, but the embedded PCIe device, such as an Aquantia AQC107, or a USB hub connected to a dock, does not receive PCIe lanes, and as such, the PCIe device fails to show up in Windows Device Manager. So the enclosure comes on, but the embedded PCIe device does not. The device becomes a zombie. On, but dead. However, my NVMe enclosure with JHL6340 actually hot-plugs just fine with the Z590 Vision D's NVM26.5. And when macOS goes to sleep and awakens, this device is not prematurely ejected. Curiously, however, at least in Windows, once Windows is put to sleep and reawakens, the Maple Ridge controller is re-initialized, and devices connected to the Thunderbolt bus that are in a zombie state, including the JHL6240 Ethernet adapter, go off briefly and come back on, and finally receive their PCIe lanes, and then operate normally. So at least in Windows, there is a pseduo hot-plug support, but only if you put Windows to sleep first, then wake it up again. Linux seems to do this too. This is unacceptable.

So rather than talking past each other, what Gigabyte needs to do is create a matrix of various Thunderbolt 3 controllers and test each to see if the various ones do in fact have hot-plug support on the Z590 Vision D, and if not then reach out to Intel. Because, the same devices with JHL6240 and JHL6540 that fail to hot-plug to the Z590 Vision D actually hot-plug successfully with Maple Ridge on a Z590 Asus Hero, so long as NVM24 is installed (and not NVM26).

So while Gigabyte has claimed to have observed functional hot-plugging with some "Thunderbolt 3" devices, it is not enough to conclude that hot-plugging is properly working for all Thunderbolt 3 devices, given the variety of Thunderbolt 3 controllers on the market, as well as the range of Intel NVM that these devices are running. It is not clear whether Gigabyte in its tests exclusively used JHL6340 devices or Titan Ridge devices, or if they indeed tested or excluded testing devices with JHL6240 and JHL6450. If they did in fact test JHL6240 devices, were they running with a newer NVM than that of the devices we are using?

When Intel said that Thunderbolt 4 has backwards compatibility with Thunderbolt 3 I did not expect that certain Alpine Ridge devices would hot-plug, and others would not.

I have also observed that there are at least 3 versions of the Maple Ridge NVM in the wild. The Asus Hero 13 comes with NVM24, MSI has NVM26, and the Z590 Vision D has NVM26.5. With version 24 of the NVM on the Asus Hero, hot-plugging Thunderbolt 3 devices works fine regardless of if they are JHL6240,6340, or JHL6540. But Asus has BIOS updates on its website, 0605 and 0704, and nowhere in Asus' release notes do they warn the user that the BIOS update process of 0605 and 0704 will update the NVM to 26, and that there is no ability to opt-out whatsoever, and that once updated there is no way to downgrade back to 24, even if you flashback to the original BIOS. When the Maple Ridge controller on the Asus motherboard is updated to NVM26, this is a one way ticket to compatibility problems with hot-plugging certain Alpine Ridge devices, (i.e., those with JHL6240 and JHL6540) as I've mentioned above for Gigabyte.

Then there is the other issue of Gigabyte hiding certain BIOS settings from the user. As long time users of Gigabyte motherboards should be aware, Gigabyte used to hide the CFG-Lock setting, and it was enabled by default on some motherboards, meaning that that macOS would not boot without enabling a patch. By using a modified-grub boot loader, you could actually change the value of the CFG-Lock setup variable to effectively set it to 'disabled.' But Gigabyte finally added the ability to modify this setting in the Z490 Vision D BIOS after I asked them to last year (given that some of their competitors allowed the user to change this setting on some motherboards).

In order to learn what settings are there and in which setup variable, you have to extract the UEFI code within. What I have uncovered is that there are various hidden settings related to Thunderbolt hot-plug on the Zz490 Vision D BIOS that are missing from Z590, such as "ACPI Notify on TBT Hot-plug" and "SW SMI on TBT hot-plug." These variables may be hidden, but they are enabled by default on the Z490 Vision D, but are not in the Z590 Vision D BIOS. I do not know whether Maple Ridge needs these settings for hot-plug to work, it could be that Maple Ridge doesn't need these settings. But I wonder if part of the reason why the OS doesn't seem to become aware when certain Alpine Ridge devices are hot-plugged to Maple Ridge with NVM26 or NVM26.5 is because there is no ACPI signal being sent to the OS? I don't know.

Another variable that Gigabyte hides from the Z590 Vision D user is the 'Control Iommu Pre-boot Behavior.' I am not fully sure how this setting interacts with the Thunderbolt controller, but Asus notes this setting is 'to Support DMA Protection Feature.' This setting is disabled by default on the Z590 Vision D, but enabled by default on the Asus Hero 13 (at least on the original 0232 BIOS, IDK if this changed on later BIOS). The reason why this setting is important for me is because when my Goshen Ridge Thunderbolt 4 dock is connected to the Z590 Vision D at default settings, the boot process slows down dramatically, taking nearly 40 seconds to post. Gigabyte is aware of this, and has blamed the problem of slow boot on the firmware of my Goshen Ridge dock. But, when I set the 'Control Iommu Pre-boot Behavior' to 'Enable IOMMU during boot' the boot process shortens considerably, and 20-30 seconds are saved! So it doesn't appear to be a firmware issue with my dock, but rather a BIOS configuration issue with the Z590 Vision D.

Gigabyte also disables hot-plug on the root port 5 of the Z590 Vision D by default. The Thunderbolt controller is connected to root port 5 on both the Asus Hero 13 and the Gigabyte Z590 Vision D. Asus enables hot-plug on this rootport by default. Enabling hot-plug on this root port didn't fix the hot-plug issues with certain JHL6540 and JHL6240 devices, but it allows an eGPU to power one monitor while Windows/Linux boots, and the internal GPU powers the other monitor. This wasn't working before. Also Windows can now go to sleep and awaken and the eGPU is not ejected...upon waking up from sleep, the GPU'S fan spin up briefly and then spin down into to 0 RPM mode, and the connected monitor comes on! Also, enabling hot-plugging on this rootport allows for much more consistent hot-plugging support with my JHL6340 devices, as well as better performance on my Goshen Ridge dock's downstream Thunderbolt ports. Not clear why Gigabyte disables this by default, and Asus does not, or why gigabyte hides the ability for the user to modify this setting. Enabled is the way to go!

Finally, Gigabyte's z590 has a hidden menu that pertains to RGB Fusion code that appears to allow the user (if it were enabled) to control the RGB lighting of the Vision D. I am not sure why Gigabyte hides this menu from the user. It also hides this menu in its Z490 Vision D BIOS as well.

So to summarize, Gigabyte needs to:
  • Test for hot-plugging support with various Alpine Ridge devices for hot-plug support. It is not enough to simply test a Titan Ridge device or a JHL6340 device and conclude that ho-tplug is working, when JHL6240 and JHL6540 devices (and possibly others) are having trouble.
  • Reach out to Intel to see if there truly is an incompatibility with Maple Ridge NVM26.5 and devices with JHL6240/JHL6540, and if so, make the new firmware available for users to update Maple Ridge.
  • Allow the user to enable the 'Control Iommu Pre-boot Behavior' option, as the Asus Hero allows the user to control this, so does Gigabyte's W480 Vision W, according to its manual. This setting allows for seemingly better compatibility with my Goshen Ridge device. If they allow the user of the W480 Vision W to access this setting, then why not the Z590 Vision D?
  • Enable the hidden RGB fusion code in the BIOS to let us unleash the unlimited power of RGB, without needing to boot Windows.
 
Last edited:
Joined
Feb 16, 2012
Messages
164
Motherboard
Z590i Vision D
CPU
i7-11700
Graphics
RX560
Mac
  1. MacBook Air
So the NVM24 BIOS for Thunderbolt 4 Maximus 13 is implemented in the BIOS file for the 507 motherboard. Is it impossible to extract it somehow?
 
Joined
Apr 12, 2021
Messages
33
Motherboard
ASUS ROG Z590 Maximus XIII Hero
CPU
i9-10900K
Graphics
Radeon Pro W5700
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Classic Mac
  1. Centris
  2. Power Mac
Mobile Phone
  1. iOS
On Ubuntu you will need to install an OEM kernel that will enable the IGPU output : sudo apt install linux-oem-20.04b

Tested with Linux Mint and worked.

Thank for you this hint

I followed up and discovered I couldn't ibstall the OEM package because 20.04 LTS is required. Ubuntu does not tell you this and just dryly reports no such package, and the write-up at Canonical doesn't say this either, nor does any lore returned by Google, but it's true! And I was running 20.10.

So I got OEM kernel running and found that the iGPU and dGPU integrate perfectly on all ports for this Maximus VIII board, as expected. I can mix and match outputs no problemo.

Along the way I got tripped up and almost took a nasty spill when the Ubuntu 20.04.2 LTS installer offered to re-install over the top of my existing Ubuntu on an outboard SATA drive, which I accepted with an odd feeling of gratitude at how helpful it was being and looming subconscious dread, then I clicked OK and Ubuntu went ahead and clobbered the EFI partition with OpenCore on my macOS drive. At same time in a moment of confusion I copied my main drive EFI over to my testing flash drive rather than other way around (Note to self: change one thing at a time and don't be an idiot). Suddenly it was grub, grub everywhere with all grubs leading to Ubuntu and no evidence there ever was a macOS install. For a while I had no idea what was going on and it gave me a good scare! Super chancy and I spent an hour trying to figure out what Ubuntu had done, another hour on how to submit a problem report to Canonical — omg PITA, they really do not want to hear about little things like installer destroying your PC, in spite of their CEO's claim they are building an "OS for everyone" which "just works." ... Just works, I remember those dayz. I wonder how many PC users have been destroyed when they decided to give Linux a try and Ubuntu just blasted their Windows EFI?

What I am coming to really appreciate about OpenCore is how it for me is demystifying the critical early phases of boot. No one else really wants you to know what's going on down there, they all want to race by boot and give you their youtube channel.

I also am coming to better understand Linus Torvald's warnings about UEFI from decades ago, saying that it would become another OS under the OS and replicate OS problems. Now my BIOS config is as complicated as OS7 was back in 90s and the board-makers barely care about tools to manage and save that config.

But back to graphics: So out of fatigue and frustration after Ubuntu escapade I mindlessly clicked on a youtube video about WEG graphics config, the kind of vid with bright-colored splash screen and huge fonts that is nothing but a screen recording with an Indian voice talking over every single mouse-click of OpenCore Confugurator—a tool I do not use and recall being derided for ignorantly blending Clover config with OC—and I scroll along hoping for a clue when suddenly the clouds parts with a beam of light coming down from heaven, and god's voice in the tone of an Indian IT plagiarist holding a golden chalice says "choosing SMBIOS is critical to getting graphics working, if you choose wrong it doesn't matter what else you do with config"...

Doh!

Well, I am using iMac 20,2 SMBIOS, and MacOS prolly does not support iGPU display output at all for this config, because that system always has a dGPU and built-in display! So I go back to Dortania to beginning where SMBIOS is discussed and think OK I didn't appreciate the implications of this config. For days I've been noodling at how to get a display to output from iGPU, and that's never gonna happen on this model. Garr!

Anywayz, thanks for your help re OEM kernel, it worked and I learned a lot.

Next up, getting a CalDigit Thunderbolt4 Element to test TB config... If only such a device was available...
 
Last edited:
Joined
Jul 1, 2018
Messages
117
Motherboard
ASUS ROG STRIX Z590-A
CPU
i7-11700K
Graphics
GTX 760
Mac
  1. MacBook
  2. MacBook Pro
  3. Mac Pro
Classic Mac
  1. iBook
  2. iMac
  3. Power Mac
Mobile Phone
  1. Android
  2. iOS
  3. Other
Got i225-V ethernet working with just a Device Properties entry and Kernel Patch entry, just like Dortania's guide suggests:
I did not use any of the kexts:
FakePCIID.kext
FakePCIID_Intel_I225-V.kext
FakePCIID_Intel_HDMI_Audio.kext
I followed the guide and unless I messed something up, its not working for me. My Z590-A also has the i225-V but it won't even show up in System Information. I'm not sure where I went wrong.
Thanks for your help!
 
Joined
Sep 25, 2019
Messages
73
Motherboard
Gigabyte z590i vision d
CPU
i9-10900K
Graphics
MSI RX5500XT Gaming X 8GB
I followed the guide and unless I messed something up, its not working for me. My Z590-A also has the i225-V but it won't even show up in System Information. I'm not sure where I went wrong.
Thanks for your help!
You are using kexts as well. Set both of them to NO and see is that will help.
Screen Shot 2021-04-25 at 12.01.13.png
 
Joined
Apr 12, 2021
Messages
33
Motherboard
ASUS ROG Z590 Maximus XIII Hero
CPU
i9-10900K
Graphics
Radeon Pro W5700
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Classic Mac
  1. Centris
  2. Power Mac
Mobile Phone
  1. iOS
That was a great write-up on pitfalls of new Thunderbolt!

For everyone following along, the IOMMU pre-boot config is a measure to deal with Thunderclap:


This is a very significant peripheral device DMA vulnerability. Basically the original design of TB extended the PCI bus outside the chassis over serial, but didn't update the core-centric memory projection model to account for the huge change administrative surface of the system, so untrusted devices with rich logic (whole other computers) ended up being hooked straight up to kernel memory, which is a bit of a risk when the device contains logic more far flexible than a network or drive controller. My sense is the TB design still has not thought all this thru but also my thinking is far out of date, so big HAND WAVE for next comment: Basically the peripheral bus used to be thought of as under care of kernel and devices were adapted for a narrow I/O use-case through simple (and fast) controller logic and a kernel driver, both of which included an tacit agreement on part of designers that the device to not do bad stuff. But once the PCI bus becomes part of a fabric of other devices, the design of the kernel protection model gets ... more interesting, because it is an inherent property of a kernel to shield privileged device memory (below the syscall) from wanton userspace programs (above). Everything on bus which can do direct memory access (RAM) was considered trusted. Well as Peter Sellers once said as Inspector Clousseau about a priceless Steinway, maybe "not any more?"
 
Top