Contribute
Register

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

Joined
Jul 3, 2010
Messages
165
Motherboard
Gigabyte Z390 Designare
CPU
i9-9900K
Graphics
RX 5700 XT
Mac
MacBook Pro, Mac mini, Mac Pro
Mobile Phone
iOS
Trying to get my new Sapphire Pulse 5700 XT to boot. Has anyone gotten it to work? If so, how?

Edit: Never mind. I figured it out. I still had Shikigva=60 in my config. Once I deleted that, it boots fine. Thanks!

Edit 2: Actually, I spoke too soon. I had to do one more step. Had to remove Inject ATI and Oronico frame buffer from the Graphics section. Now it boots up reliably.
 
Last edited:
Joined
Jan 5, 2014
Messages
50
Motherboard
GA-Z97X-UD3H
CPU
i7-4790K
Graphics
HD 4600
Mac
MacBook Pro
Mobile Phone
iOS
We must delete it and copy the .aml version of that. It's also in the ZIP file. Okay, I can see where the confusion is coming from. I'll have to unhide those filename extensions and re-upload the ZIP. Will do that tomorrow.
Yeah maybe that would make your guide idiot proof. Making me a … never mind.

Copied the R6 .aml file into the EFI folder and Bluetooth working fine now.

Your willingness to help less savvy people with this stuff so quickly is very cool. Thanks.
 
Last edited:
Joined
Jan 5, 2019
Messages
80
Motherboard
Gigabyte Z390 Designare
CPU
i7-8700K
Graphics
RX 580
Looking for help, my hackintosh suddenly won’t power up, when the power supply is turned on the designaire board illuminates white, that’s all i get no video or post and no power light.

Thoughts on where to start?
 
Joined
Sep 21, 2013
Messages
556
Motherboard
Gigabyte Aorus Z370 GA-7
CPU
i7-8700K
Graphics
RX 580
Mac
MacBook, MacBook Pro, Mac mini
Classic Mac
Classic, iBook, Power Mac, PowerBook, Quadra, SE/30
Mobile Phone
Android, iOS
Awesome!
  • Do not install Windows 10 at this time. It's not necessary for initializing the GC-Titan Ridge.
  • Connect the Thunderbolt header cable to the motherboard.
Here's your homework assignment! After you make the changes I can check everything for you.
  1. IOReg shows that Thunderbolt is attached to RP21.
    View attachment 434765
    • Because this is a Thunderbolt 3 card with two USB-C connectors, it means you also get two USB ports that support both USB 2 and USB 3 protocols. Hence, notice the lower part of the above screenshot where I've marked the two USB 2 and two USB 3 ports.
      • Notice in BLUE that each port has an address (ADR) from 1 to 4. This will be needed shortly.
        • ADR 1 and ADR 2 are for USB 2 as shown
        • ADR 3 and ADR 4 are for USB 3 as shown
  2. Now let's look at the original DSDT.aml. Let's find RP21 in that file, using MaciASL:
    • When we expand the RP21 section we see this:
      View attachment 434768
    • Now we must check if there are any pre-defined DEVICEs under RP21. We can see above that yes indeed there is already a device here named PXSX.
    • By convention, Apple's Thunderbolt SSDT names the first device as UPSB and creates all sub-devices under this all-important top-level UPSB device.
    • But the right now PXSX is taking up that space, so in a moment we will get rid of PXSX.
  3. Now we're ready to modify the Thunderbolt hot-plug SSDT. We start by downloading KGP's SSDT from the X299 repository on GitHub. The file name is SSDT-X299-TB3HP.dsl. And we edit it with MaciASL.
    • Don't worry about the name of the file. You can change it later.
    • We also need to download SSDT-DTPG.aml. No changes will be made to this file, but we will need to open it in MaciASL and save it in .aml format.
    • Note that .dsl files are disassembled files, which means they cannot be used. They must be compiled into ACPI Machine Language (.aml) format. This is done in MaciASL by simply doing File --> Save As... and choosing the ACPI Machine Language Binary output file format.
  4. Let's have a look at the standard KGP Thunderbolt hot plug SSDT:
    • Notice that for the X299 system, the Thunderbolt root path is _SB_.PC01.BR1A. But on your board, it is _SB_.PCI0.RP21.
    • Also notice that on KGP's X299 system, there happen to be 2 default devices in BR1A called SL01 and PEGP. This is why the two red boxes are (a) referencing those devices, and (b) setting their ADR to 0, which in effect disables them. Only when those device have been disabled are we ready to create our own UPSB device.
      View attachment 434774
    • So you will need to modify the two red boxes to (a) reference _SB_.PCI0.RP21 and _SB_.PCI0.RP21.PXSX.
    • And then you'll need to modify the second red box to change the address of PXSX to 0.
  5. We're nearly done. We must now adjust our USB ports. We do that by expanding the XHC5 (XHC is the USB Controller) section as shown here:
    • Notice on the left side that the hot plug SSDT defines 4 USB ports SSP1, SSP2, HS01, HS02. And if we click on SSP1 we will see on the right side in blue that its ADR is set to One.
      View attachment 434779
    • But this is not quite right. Because if you go back to the first screenshot above, you'll see that the two USB 2 ports have address 1 and 2. And the two USB 3 ports actually have addresses 3 and 4.
    • So we must change the address of SSP1 to 3, and SSP2 to 4.
    • And we must change the address of HS01 to 1 and HS02 to 2.
  6. Now we should save the .dsl file and then save it as a compiled ACPI binary file by selecting File --> Save As... --> ACPI Machine Language Binary.
  7. Finally, we can test hot plug by copying both the hot-plug SSDT (.aml file) and the SSDT-DTPG (.aml file) to the CLOVER/ACPI/patched folder and rebooting. It would be good to examine the IORegistryExplorer output.
Hi, I'm getting return errors when I try to save or compile this: I've replaced the BR1A with RP21 but I got this when using Save As... Is it because I'm working from a real Mini? I know that my Hack TB is on RP21...
 

Attachments

CaseySJ

Moderator
Joined
Nov 11, 2018
Messages
5,465
Motherboard
Gigabyte Designare Z390
CPU
i7-9700K
Graphics
RX 580
Mac
MacBook Air, Mac Pro
Classic Mac
Quadra
Mobile Phone
iOS
Hi, I'm getting return errors when I try to save or compile this: I've replaced the BR1A with RP21 but I got this when using Save As... Is it because I'm working from a real Mini? I know that my Hack TB is on RP21...
Look carefully at Step 4. There’s a difference between PC01 and PCI0. If your DSDT does not have SL01 and PEGP at RP21, you cannot delete nonexistent devices. That guide requires interpretation and adaptation. It’s not a do-it-exactly-like-this guide. It’s meant to be just a little more challenging than that.
 
Joined
Jun 23, 2019
Messages
44
Motherboard
Gigabyte Z390 Designare
CPU
i9 9900K
Graphics
Vega Frontier Edition
Looking for help, my hackintosh suddenly won’t power up, when the power supply is turned on the designaire board illuminates white, that’s all i get no video or post and no power light.

Thoughts on where to start?
This seems more like hardware problems, and not hackintosh related.

However, you could try clearing the CMOS through a physical method, by taking out the battery and reinserting it.

The next would possibly be to take out the ATX 24 pin cable, and replugging it. Perhaps also checking other cables. If that doesn't work, test by taking out a high power unit, such as GFX, and test.

Could also be the PSU itself, not working well by giving enough power.

Perhaps CaseySJ or someone else knows better.
 
Joined
Jun 23, 2019
Messages
44
Motherboard
Gigabyte Z390 Designare
CPU
i9 9900K
Graphics
Vega Frontier Edition
did anyone convert this to opencore and would share the config?
OpenCore is in its Public Beta. That said, it is for testers and people who're actually willing to test it on their systems, to gain knowledge from the workarounds and the documentations. It might work well. In my case it does. But there is little or no support for it, when it comes to extensive help support via a thread, such as this. As this thread is as of now purely based on CaseySJ's method and Clover.

I have uploaded my EFI-OC folders here before. But I feel it takes the learning experience from people. Not only that, it might divert the attention from the main things mentioned in this thread.

I suggest you read the documentations, grab some snacks and you'll most likely do it well. Who knows.
You can use the SSDTs provided by CaseySJ, available from the front page of this thread.
 
Joined
Jun 23, 2019
Messages
44
Motherboard
Gigabyte Z390 Designare
CPU
i9 9900K
Graphics
Vega Frontier Edition
Well I want to know for sure :).
Well, I could mention a bit. Especially after talking to VIt9696 about it.

This is something I've talked to many developers about before, also Clover developers, formerly TonyMac admin and developer PJALM and so on. And many of them have had some shared feelings about this, some have not. Throughout the history of macOS and bootloaders, opinions and thoughts have changed.

Here are some reasons why unsigned kexts should be injected via bootloader.

**-_Should and should_-** This is very opinionated. A reason I don’t really want to go on about it a lot.

Injecctions via bootloader secures early kext startup. This means there will be no problems with kexts such as Lilu and related kexts. Lilu being a kext that is becoming a main kext for many things, and will eventually be common standard for a lot, with its plugins etc. Hence the example of Lilu. This requires loading before root fs mount for policy installation.

If one installs to /Library/Extensions or /System/Library/Extensions, it requires rebuilding kext cache, whilst also ensuring permissions. This is more prone to error.

Damaged kexts in /Library/Extensions or /System/Library/Extensions are harder to replace. It requires running recovery, mounting boot fs, to analyse and finding the kexts, replacing them, setting permissions, running kextcache. With the bootloader, it is way easier, doing it via UEFI Shell, or other OS, such as Windows, BSD, Linux. As the MacOS drive is clean, and can be injected via another source, one could easily restore it that way as well.

If you Install to /Library/Extensions or /System/Library/Extensions, it requires you to disable System Integrity Protection (SIP). Regardless if you ignore security, this isn’t expected by Apple. Such systems will be less tested and more error prone.

On a real Mac, having secure boot (this will soon be with hackintosh as well using OpenCore), it isn’t possible to install third party early startup kexts, even if they are signed with authorised developer certificate. They can only load way after graphics startup. This doesn’t apply to Lilu and many other drivers. This is for example why a company such as NVIDIA can’t do much, with their drivers for MacOS.

There are of course downsides of kext injections.

Such as..

Injected kexts fall to property load dependencies and sometimes don’t load at all. This happens more with Clover. OpenCore lets XNU do it. Kext injections can break. Especially for Clover. As Clover relies on a method that is deprecated, and is no longer supported by Apple. However, it might still break for OpenCore. Though OpenCore is made with a different approach which is more reliable. Injected kexts lack some things, i.e. data information through API’s, allowing you to read files in kext directory. This will not work for injected kexts as their directories are not mounted. Though, many few kexts need it. In practice, you can rewrite every kext to avoid it.

So in this case, installing in /Library/Extensions and /System/Library/Extensions, as well ass injecting, could be good thing and a bad thing. Especially with Clover. Though the recovery stage could be a deal breaker. For newer methods, in this case OpenCore, one might want to rely on just injecting.

For me, the “just injecting” approach works well. With Clover and OpenCore. But to each their own.

"Just injecting" approach is also called the "vanilla method" by many people. I don't agree with that naming for such method. But calling something vanilla, you refer it to plain, original and clean. The only thing plain, original and clean from the third party injections is the drive, when you take it out. Having it in the hackintosh requires the third-party work around, regardless. Nothing "vanilla" with it, in my opinion. Though, it is "just injection" method. Perhaps saying "vanilla install" or "vanilla method" is easier and nicer.
 
Last edited:
Joined
Aug 29, 2019
Messages
41
Motherboard
Gigabyte Z390 Designare
CPU
i7-9700K
Graphics
Vega 64
@Etyel,

It is far safer and easer to install Windows on to a separate SSD ... that way if something goes wrong with one of the operating systems (hardware or software) it wont effect the other.

You only need to boot Clover from one EFI partition, Clover will then scan all the drives/ssd's in your system and give you the option to boot MacOS or Windows.

Cheers
Jay
Finally I managed to install Windows with a key prepared with Media Creation Tool, it seems to work so I think I'll leave it there.
 
Joined
Apr 25, 2011
Messages
57
Motherboard
Gigabyte Z390 Designare
CPU
i7-9700K
Graphics
RX 580
Mac
MacBook Pro
Mobile Phone
iOS
Well, I could mention a bit. Especially after talking to VIt9696 about it.

This is something I've talked to many developers about before, also Clover developers, formerly TonyMac admin and developer PJALM and so on. And many of them have had some shared feelings about this, some have not. Throughout the history of MacOS and bootloaders, opinions and thoughts have changed.

Here are some reasons why unsigned kexts should be injected via bootloader.

**-_Should and should_-** This is very opinionated. A reason I don’t really want to go on about it a lot.

Injecctions via bootloader secures early kext startup. This means there will be no problems with kexts such as Lilu and related kexts. Lilu being a kext that is becoming a main kext for many things, and will eventually be common standard for a lot, with its plugins etc. Hence the example of Lilu. This requires loading before root fs mount for policy installation.

If one installs to /Library/Extensions or /System/Library/Extensions, it requires rebuilding kext cache, whilst also ensuring permissions. This is more prone to error.

Damaged kexts in /Library/Extensions or /System/Library/Extensions are harder to replace. It requires running recovery, mounting boot fs, to analyse and finding the kexts, replacing them, setting permissions, running kextcache. With the bootloader, it is way easier, doing it via UEFI Shell, or other OS, such as Windows, BSD, Linux. As the MacOS drive is clean, and can be injected via another source, one could easily restore it that way as well.

If you Install to /Library/Extensions or /System/Library/Extensions, it requires you to disable System Integrity Protection (SIP). Regardless if you ignore security, this isn’t expected by Apple. Such systems will be less tested and more error prone.

On a real Mac, having secure boot (this will soon be with hackintosh as well using OpenCore), it isn’t possible to install third party early startup kexts, even if they are signed with authorised developer certificate. They can only load way after graphics startup. This doesn’t apply to Lilu and many other drivers. This is for example why a company such as NVIDIA can’t do much, with their drivers for MacOS.

There are of course downsides of kext injections.

Such as..

Injected kexts fall to property load dependencies and sometimes don’t load at all. This happens more with Clover. OpenCore lets XNU do it. Kext injections can break. Especially for Clover. As Clover relies on a method that is deprecated, and is no longer supported by Apple. However, it might still break for OpenCore. Though OpenCore is made with a different approach which is more reliable. Injected kexts lack some things, i.e. data information through API’s, allowing you to read files in kext directory. This will not work for injected kexts as their directories are not mounted. Though, many few kexts need it. In practice, you can rewrite every kext to avoid it.

So in this case, installing in /Library/Extensions and /System/Library/Extensions, as well ass injecting, could be good thing and a bad thing. Especially with Clover. Though the recovery stage could be a dealbreaker. For newer methods, in this case OpenCore, one might want to rely on just injecting.

For me, the “just injecting” approach works well. With Clover and OpenCore. But to each their own.

"Just injecting" approach is also called the "vanilla method" by many people. I don't agree with that naming for such method. But calling something vanilla, you refer it to plain, original and clean. The only thing plain, original and clean from the third party injections is the drive, when you take it out. Having it in the hackintosh requires the third-party work around, regardless. Nothing "vanilla" with it, in my opinion. Though, it is "just injection" method. Perhaps saying "vanilla install" or "vanilla method" is easier and nicer.
Thanks, the whole approach to do it before the OS starts is, also in my opinion, better the a patch.
The OpenCore is really good to understand but the implementation is difficult.
I've read the reference manual and I am starting to understand OpenCore. It is a combo of injecting on the specification of hardware. Just like for my old hack to inject a string for the HD6870 for example.
 
Top