[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[luckyal]

RehabMan once explained that MSR 0xE2 is a write-once lock. When BIOS initializes, it triggers the lock, which remains locked for as long as the machine is on. It cannot be unlocked except with a reboot. The only solution, if one can call it a solution, is to modify the BIOS.

When we enable AppleIntelCPUPM and KernelPM, the AppleIntelCPUPowerManagement kext is patched to avoid touching the MSR 0xE2 register. Clover auto-detects and applies power management patches as well, which we can see from the Clover log

Doesn't the bootlog dump from Clover show the same thing:

0:101  0:000  MSR 0xE2 before patch 1E008000
0:101  0:000  MSR 0xE2 is locked, PM patches will be turned on
0:101  0:000  MSR 0xCE              08080838_F1012400

 

[CaseySJ]

Doesn't the bootlog dump from Clover show the same thing:

There are several ways to view the log, but the point is that it confirms MSR 0xE2 on the Designare Z390 is locked. In fact it's locked on most motherboards. Unfortunately, I haven't encountered a Gigabyte BIOS patch that reverses the lock.

 

[zoomlenz]

There are several ways to view the log, but the point is that it confirms MSR 0xE2 on the Designare Z390 is locked. In fact it's locked on most motherboards. Unfortunately, I haven't encountered a Gigabyte BIOS patch that reverses the lock.

I followed the guide here: https://github.com/acidanthera/AptioFixPkg/blob/master/README.md#verifymsre2

I prefer not to have patches if I can “simply” enable a hidden BIOS option.

 

[CaseySJ]

I followed the guide here: https://github.com/acidanthera/AptioFixPkg/blob/master/README.md#verifymsre2

I prefer not to have patches if I can “simply” enable a hidden BIOS option.

Good information!

The procedure worked for your Gigabyte Z390 Pro?
For what device or device driver did you need this?

After Step 7, the procedure does not explain how to reconstitute the firmware image and flash the BIOS, or does the setup_var command make an in-place change to something in the firmware?

 

[zoomlenz]

Good information!

The procedure worked for your Gigabyte Z390 Pro?
For what device or device driver did you need this?

After Step 7, the procedure does not explain how to reconstitute the firmware image and flash the BIOS, or does the setup_var command make an in-place change to something in the firmware?

Yes, worked fine on the Z390 Pro. Just did it to avoid the PM patches.

setup_var makes the change, no need to flash. Simply rebooted after that, iirc. Maybe a power cycle.

Before writing the new value of 0x00 I verified the initial value of 0x01 by typing setup_var with only the offset parameter.

 

[luckyal]

Yes, worked fine on the Z390 Pro. Just did it to avoid the PM patches.

setup_var makes the change, no need to flash. Simply rebooted after that, iirc. Maybe a power cycle.

Before writing the new value of 0x00 I verified the initial value of 0x01 by typing setup_var with only the offset parameter.

I'm thinking about giving this a try, but before I do, would you mind sharing screenshots/details about your EFI folder?

One might ask as to why all this trouble to get the machine to boot with VT-d and no dart=0 (or DMAR drop). Per this Apple Dev document, "[VT-d] allows virtual machines to have direct access to hardware" - which is what some drivers like the PreSonus Quantum and VRS-8 Thunderbolt Audio Interfaces require. These are ultra-low latency

My post here was after working around the clock with the help of @joevt who eventually helped solve this problem on the Z270 Asus build. That build followed suit like of the builds on tonymac which recommend VT-d being disabled and dart=0 removed. It appears that certain drivers require space within the first 256MB of contiguous memory in order to initialize. Disabling VT-d prevents access to that memory.

The reason I think it's relevant to this specific thread is because @loloduarte (referenced by @CaseySJ the OP) seems to have been able to install his PreSonus Quantum audio interface with this board. I can't figure out exactly why and how his build/BIOS differs from OP.

 

[zoomlenz]

I'm thinking about giving this a try, but before I do, would you mind sharing screenshots/details about your EFI folder?

Happy to share my EFI, but I’m away from my desktop until late Sunday.

 

[skittlebrau]

Close to 2 months later and everything is still great. This is the best Hackintosh I've ever assembled from a stability point of view. Thanks again CaseySJ for all the help!

So much so that I'm thinking I'll just sell my MacBook Pro 15" 2016 since I barely use it now.

 

[CaseySJ]

Close to 2 months later and everything is still great. This is the best Hackintosh I've ever assembled from a stability point of view. Thanks again CaseySJ for all the help!

So much so that I'm thinking I'll just sell my MacBook Pro 15" 2016 since I barely use it now.

Makes my day

 

[manHands]

As an aside, the new 27-inch 5K iMacs use the i9-9900F processor. There is no iGPU in this processor. This is probably why About this Mac still doesn't recognize the standard i9-9900K...even in 10.14.5 Beta 4.

Hey @CaseySJ. Just thought I'd share that the new 27-inch 5K iMacs do use i9-9900K processors that do have an iGPU.

SMBios 19.x - iMacs 2019

Oh this only applies IF one is running macOS 10.14.4 (18E2034) "Special Build?" Everyone else needs to have the ig-platform-id specified? Also, is there a way to upgrade to the special build from macOS 10.14.4 (18E227) or is fresh install required? I have been leaving everything blank for...

www.tonymacx86.com

Out of curiosity, where did you get your info that they were using the locked i9-9900F CPUs that don't have an iGPU?