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

CaseySJ · Jan 19, 2020

Gompy said:
Hi,

Thanx for the update.
I got the attached kernel panic. I use the OpenCore NDK Fork Zip.

Hello @Gompy

Are you trying OpenCore for the first time, or updating from previous release?

Gompy · Jan 19, 2020

CaseySJ said:
Hello @Gompy

Are you trying OpenCore for the first time, or updating from previous release?

I tried your previous update (OC and NDK own build), without succes. That was a fail also, but I got a black screen after the boot proces.

Now this is at the beginning of the boot proces with a new formatted USB drive.

zzmadd · Jan 19, 2020

CODYQX4 said:
I'm wondering if you can eliminate some of them further.

Judging by the OpenCore documentation we shouldn't need EnableSafeModeSlide.

Rich (BB code):

EnableSafeModeSlide Type: plist boolean Failsafe: false Description: Patch bootloader to have KASLR enabled in safe mode. This option is relevant to the users that have issues booting to safe mode (e.g. by holding shift or using -x boot argument). By default safe mode forces 0 slide as if the system was launched with slide=0 boot argument. This quirk tries to patch boot.efi to lift that limitation and let some other value (from 1 to 255) be used. This quirk requires ProvideCustomSlide to be enabled. Note: The necessity of this quirk is determined by safe mode availability. If booting to safe mode fails, this option can be tried to be enabled.

We shouldn't need ProvideCustomSlide either. It seems to scan the memmap and attempt to determine a working slide, and without passing it as a bootarg (and therefore leaking it to the OS), but if we're going to force slide=0 this should be able to be turned off.

Code:

ProvideCustomSlide Type: plist boolean Failsafe: false Description: Provide custom KASLR slide on low memory. This option performs memory map analysis of your firmware and checks whether all slides (from 1 to 255) can be used. As boot.efi generates this value randomly with rdrand or pseudo randomly rdtsc, there is a chance of boot failure when it chooses a conflicting slide. In case potential conflicts exist, this option forces macOS to use a 16 pseudo random value among the available ones. This also ensures that slide= argument is never passed to the operating system for security reasons. Note: The necessity of this quirk is determined by OCABC: Only N/256 slide values are usable! message in the debug log. If the message is present, this option is to be enabled.

I don't know if you need SetupVirtualMap. The docs say it's for some firmwares that have early boot crashes and this fixes it. I don't need it in my case and I would think since we run the same board that you wouldn't either.

Code:

SetupVirtualMap Type: plist boolean Failsafe: false Description: Setup virtual memory at SetVirtualAddresses. Select firmwares access memory by virtual addresses after SetVirtualAddresses call, which results in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory. Note: The necessity of this quirk is determined by early boot failures.

You had SetupVirtualMap and EnableSafeModeSlide on in all tests. I see you disabled ProvideCustomSlide in test 3 only and may be able to disable it again.

I know from using OpenCore that I don't need ForceExitBootServices and you only disabled it at the end. I wonder if this fixed something for you. I don't think I ever enabled it, as the docs seem to discourage using it unless necessary.

I would say we'll always need AvoidRuntimeDefrag and EnableWriteUnprotector to boot at all. I never turned AvoidRuntimeDefrag off as the docs say basically anything that isn't a real Mac or VMware should keep it on. I can't boot without EnableWriteUnprotector. DevirtualizeMmio is what frees us up some extra space (though oddly on actual OC I still need to turn iGPU off), so we should keep it.

QuirksProvideConsoleGopEnable I'm not sure of. It's implemented differently in OpenCore (a different config section), but I need the OpenCore equivalent to boot.

A test on my to do list is to see if I can figure out what quirk is implemented differently between OpenCore and OcQuirks where OcQuirks lets me boot reliably with iGPU but OpenCore doesn't.

This combination of drivers doesn't work for other Gigabyte boards. I'm testing the Z390 UD for example.

cylsfar · Jan 19, 2020

Hi

Thanks for your Guide

Everything on Catalina is good

I have only two things thatt don't work

1) Broadcom DW1820a
2) Thunderbolt 3

I have got a 9900K, a Gigabyte Designare Thunderbolt 3 and 64GB of memory.

Can you help me please?

pitt1717 · Jan 19, 2020

*** update on sleep.. must have been a fluke. moved the mouse and came back to life, so it looks like sleep works. ill keep an eye on it

also, meant to ask, why do you choose imacpro1,1 instead of the closer imac19,1 for open core and not clover?

pabloh · Jan 19, 2020

CaseySJ said:
Also try moving the card to another PCIe slot. Try both short slot and long slot. Also post a screenshot of System Information --> WiFi

View attachment 445652

Warning: Do not change or replace IO80211Family.kext. In fact, we should not change any files in /System/Library/Extensions.

Yeah I will not change a kext in the system folder again, thanks!

Think that caused the problem here. Because I tested my old card again with the newest Kext installed at it is still working and the older TP-Link card doesn't worked after my first clean install. So I think that's still the problem why the new card isn't working. Because the system still thinks that the older IO80211Family.kext is installed otherwise it can't use the older card.

I also tested all available PCI slots with the Fenvi FV-T919. I would say it is definitely a software problem here, but I have no idea how I can restore the original state without a clean install. I already tested to copy the newsiest IO80211Family.kext from me MacBook Pro to my hacki but without effect.

If nobody has an idea how to get use the "original" IO80211Family.kext I'll do a clean install next weekend...

Image shows the WiFi state with the Fenvi FVT919 installed in an x1 PCI slot. (Bluetooth is working)

Elias64Fr · Jan 19, 2020

CaseySJ said:
A successful patch -- in which we inject key pieces of Apple's Thunderbolt firmware into the Gigabyte Thunderbolt firmware -- might result in a functional Thunderbolt Bus and Thunderbolt Local Node. Some Thunderbolt devices (even Thunderbolt 3 devices) don't work properly without Thunderbolt Bus. Unfortunately, this won't affect Thunderbolt 1, which will remain incompatible.

Hi Casey & all hackintoshers :wave:

,

Thunderbolt firmware patch is not required to have Thunderbolt bus and local node. Currently I have full thunderbolt tree with an operating Egpu working like a real Mac :thumbup:

.. with Hotplug and EGPU icons on System bar for Graphic card eject.
I have 3 hachintosh working with differents UPSBridge/NHI device-id (two with 15D3/15D2 (ARv2) and one with 1578/1577 (ARv1). All are Alpine Ridge but it can work on Titan Ridge with some modifications... or not.

I work on a standard SSDT file but I need some help for testing on Z390 Designare board.

cylsfar · Jan 19, 2020

i have got same thing with not installed on wifi DW1820a and thunderbolt

Elias i ve got a z390 designare board

CaseySJ · Jan 19, 2020

Elias64Fr said:
Hi Casey & all hackintoshers ,

Thunderbolt firmware patch is not required to have Thunderbolt bus and local node. Currently I have full thunderbolt tree with an operating Egpu working like a real Mac .. with Hotplug and EGPU icons on System bar for Graphic card eject.
I have 3 hachintosh working with differents UPSBridge/NHI device-id (two with 15D3/15D2 (ARv2) and one with 1578/1577 (ARv1). All are Alpine Ridge but it can work on Titan Ridge with some modifications... or not.

I work on a standard SSDT file but I need some help for testing on Z390 Designare board.

If you're volunteering to modify the Thunderbolt SSDT for Z390 Designare, I would be more than happy to test it for you. If there are any files you need, just let me know.

I tried to modify the Thunderbolt SSDT based on Osy86 guide, but the Gigabyte DSDT does not have MMRP and MMTP ACPI methods as previously mentioned: