Contribute
Register

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

Hello @basett1,

Some answers and comments:
  • Most Thunderbolt devices do not require Thunderbolt Bus, so regular unflashed card should be used first. If it works well enough then there's no need to go further (i.e. no need to flash the firmware).
  • But if you do require Thunderbolt Bus, then please be aware of the various issues that arise (i.e. it may be necessary to warm-boot the system for Thunderbolt Bus to activate fully; sleep/wake issues may arise; etc.).
  • Because your motherboard has a THB_C Thunderbolt header, try connecting the GC-Titan Ridge to it. If the card works (i.e. Thunderbolt devices can connect and function) then keep the cable connected. But if there are some issues, you can also disconnect the cable from Thunderbolt header and use a jumper wire to connect the Top and Middle pins of the vertical J1 header on the back of the GC-Titan Ridge. That forces the card to power on.
  • Does it make sense to buy Z590 Vision D? Not necessarily. If your ASRock Z490 Phantom Gaming 4 works well with GC-Titan Ridge, then there's no reason to change. In general, however, the flashed on-board Thunderbolt controller on Z490 Vision D will be more reliable (but not perfect) than a flashed add-in-card.
You are right! I don't remember given the amount of messages in this thread.
I have a GC Titan Ridge V2 that I flashed with a firmware that you recommended me to use on a MSI H270 that did not have the TB header. With that configuration I had no problem whatsoever. Indeed, everything worked fine. Now I am doing a new configuration where I will install that same GC Titan Ridge already flashed, obviously they didn't work on Windows. For this reason I'm thinking about a mobo with TB for use the integrated in Windows and Titan Ridge on hack.

I was evaluating the Z590 Vision D since the Z490 seem to be nowhere to be found in EU.
In the next days I will receive the CPU, and I will try the mobo. I will update you with the news.
 

Attachments

  • ReportEFI_OC0.6.7_149.zip
    4.5 MB · Views: 32
  • Screen Shot 2021-03-14 at 3.18.51 PM.png
    Screen Shot 2021-03-14 at 3.18.51 PM.png
    141.8 KB · Views: 63
Attached.
Thank you
Without analyzing more I can tell you from your screenshot that there's a error in your boot-args.
Look at the last one, igfxfw= ?????
 
This looks like what can happen if someone out there uses a "valid/registered" serial number. There are probably people out there whose serials are also changing on reboot, who are not on forums, but also simply sign back into iCloud without giving it another thought and having any idea the cause.

A question of clarity the group: Are iCloud services safe to use on Hackintosh? I'm running this build with OC 067, Mojave, and Filevault, but I'm not signed in to any cloud services.
 
Without analyzing more I can tell you from your screenshot that there's a error in your boot-args.
Look at the last one, igfxfw= ?????
I've fixed that to igfxfw=2

Edit:
@jiffyslot
I've been having an issue using iServices as well. I log into iMessage, shows an empty message, then I'm automatically booted back to the log in screen.
 
Most of "hacked" "cracked" apps are made in this way soo ...

We need to "convert" binaries into the original written language, probably C/Objectif-C
modify It as we need,
compile it
This isn't easy task but here is a starting point
Very interesting.

Incidentally, just found that SIP was enabled, therefore Xcode's debugger was unable to attach to a running process. With SIP disabled, the debugger has no problem attaching to running processes, but those processes may only be user-space processes and not kernel-space processes. Because kexts are kernel-space processes, they're excluded from Xcode's debugger.
 
Very interesting.

Incidentally, just found that SIP was enabled, therefore Xcode's debugger was unable to attach to a running process. With SIP disabled, the debugger has no problem attaching to running processes, but those processes may only be user-space processes and not kernel-space processes. Because kexts are kernel-space processes, they're excluded from Xcode's debugger.
Man, I really thank you for all your efforts no matter what the final result will be. Shame on Antelope developers, who could do a better job in filling that 4% gap still to reach.
 
You likely at least need to be running xcode as root to attach to the kernel, or possibly even use the debugger from the command line to do it. I know way back (like 10+ years ago), 2-machine debugging was the way to go to do kernel-level debugging, as user-space kind of depends on the kernel not being stopped (like, say, at a breakpoint) to function.

As a first step, I would suggest looking up how the kernel matches kexts to hardware devices, I believe at least some of it is present in a plist in the kext, and see how that matches up with how the hardware shows up in the ioregistry.
 
Are iCloud services safe to use on Hackintosh? I'm running this build with OC 067, Mojave, and Filevault, but I'm not signed in to any cloud services.
I can’t answer for others, but I’m using all iCloud (free and paid ) services on my hackintosh without problem
 
Very interesting.

Incidentally, just found that SIP was enabled, therefore Xcode's debugger was unable to attach to a running process. With SIP disabled, the debugger has no problem attaching to running processes, but those processes may only be user-space processes and not kernel-space processes. Because kexts are kernel-space processes, they're excluded from Xcode's debugger.
From Apples official website https://developer.apple.com/library...al.html#//apple_ref/doc/uid/20002367-CHDIHFDI
 
Back
Top