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

[ncrispi]

If you follow the Catalina 10.15.4 guide (Step 1) that shows what Clover options to check on, then no extra files will be installed. Only the EFI folder in the EFI partition will be created.

MSR 0xE2 has to be unlocked for the 10.15.4 guide. My test bench is unlocked.

The setup I'm suggesting is on a USB flash disk and is temporary. It will have no impact on any future disk or OS configuration.

Having said this, I'm not suggesting that Clover will fix your sleep/wake issues. Instead, what I'm getting at is this:

• You have a system whose sleep/wake functionality does not work.
• I have a system whose sleep/wake functionality works remarkably well.
• So if we consider my test bench to be a "reference design" or "baseline", then doesn't it make sense to compare your system against a known working baseline?
• And then begin to systematically look for differences?

Okay I have created the USB and just booted from Clover setup on the USB.

UPDATE:
Just rechecked and am already showing some of the errors:
2020-03-30 20:36:44.076002-0400 localhost powerd[102]: [powerd:sleepWake] Wake reason: "<private>" identity: "<private>"
2020-03-30 20:37:23.801207-0400 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI
2020-03-30 20:37:23.801207-0400 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI


The private one is always happening either right when the computer wakes up or when it goes to sleep and the 2 XDCI ones are always happening right when the computer goes to sleep. I'll have to test a bit more for the Other error that actually wakes the PC from Find My Mac

 

[CaseySJ]

Okay I have created the USB and just booted from Clover setup on the USB.

UPDATE:
Just rechecked and am already showing some of the errors:
2020-03-30 20:36:44.076002-0400 localhost powerd[102]: [powerd:sleepWake] Wake reason: "<private>" identity: "<private>"
2020-03-30 20:37:23.801207-0400 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI
2020-03-30 20:37:23.801207-0400 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI


The private one is always happening either right when the computer wakes up or when it goes to sleep and the 2 XDCI ones are always happening right when the computer goes to sleep. I'll have to test a bit more for the Other error that actually wakes the PC from Find My Mac

• Did it enter sleep?
• Did it remain asleep?
• If so, did it remain sleep indefinitely or wake up by itself?
• If it woke up by itself, was it triggered by anything in particular from a user standpoint?
• Are you using Bluetooth mouse or keyboard?
• Have you checked Proximity Wake?

 

[ncrispi]

• Did it enter sleep?
• Did it remain asleep?
• If so, did it remain sleep indefinitely or wake up by itself?
• If it woke up by itself, was it triggered by anything in particular from a user standpoint?
• Are you using Bluetooth mouse or keyboard?
• Have you checked Proximity Wake?

These two codes don’t cause the computer to wake up from sleep (at least from a fans and lights perspective). These codes happen as soon as the fans and lights turn off for sleep. I am using a USB keyboard and USB mouse and proximitywake is set to 0.

for the other code that actually causes wake-ups, My computer is currently asleep and I am waiting to see if it wakes up after turning back on Find My Mac...

One thing that I did notice difference between OC and Clover is that OC I am able to find my mac WITHOUT wake for network access selected (the computer would also wake up (fans)). With Clover, I am not able to find my mac without wake for network access selected

@CaseySJ If you put your computer to sleep manually, and then wait until your fans and lights and all turn off (about 30 seconds?) then click your keyboard 2-3 times to wake it up.. what do your wake logs show?

similarly, when you put your computer to sleep and wake it up by opening Find My on your phone

log show --style syslog | fgrep "Wake reason"

 

[monarchx94]

Currently just past Step 2 installation, stuck at a light grey screen waiting for set up - been 45 mins.. restarted and still the same

 

[mango1122]

Update:

Thunderbolt 3 Dock is identified, USB, Ethernet works
Connecting a Display Port Monitor fails the system and it crashes, even tried type c -> display port adapter without the dock, still crashes. is this a known behaviour @CaseySJ

Interesting - My system is also crashing with the monitor connected to the display port on the TB dock. Has anyone else experienced this ? Note : Am using an in built TB port. @CaseySJ @NorthAmTransAm

 

[LeSeChe]

Hello Casey (and everyone),

I’ve been following this thread for a while, and first off I should thank you for this amazing build guide which has helped me have a stable Hackintosh for over a year! I came to Hackintosh from Arch Linux in December 2018 to enjoy better integration with my Macbook Pro, iPhone, and iPad.

Today I wanted to register an account and share the results of flashing the patched thunderbolt firmware onto my Z390 Designare. I used a Raspberry Pi 4b and the Pomona 5250 clip, and followed the Raspberry Pi mini-guide. Manfriday’s advice to disconnect-and-reconnect pin 1 from the pi helped make flashrom consistently read/write from the Winbond chip. I felt very lucky, the NZXT H710i case leaves enough room to access the chip from the side of the case without needing the remove the motherboard. After I was able to get 3 consistent, sequential reads from the chip using flashrom, I wrote the patched firmware to the chip. I have two LG UltraFine 5k displays connected to the Thunderbolt ports, and since flashing the patched firmware I haven’t noticed any issues with graphics glitching in Chrome, Electron-based apps (Slack), or apps that use (GPU) hardware acceleration (Spotify, Plex). I’m super happy about this result. For context, I’m using the iMac19,1 SMBIOS name, have iGPU enabled in BIOS, have my graphics card connected to the Designare’s DisplayPort-In, and I’m using the frame buffer patch from Hackintool (platform ID 0x3E9B0007).

One thing that I will note is that after flashing the patched firmware I no longer see the Gigabyte logo or Clover (boot screen and verbose output) when my computer boots. After I power the machine on, I wait about a minute, and then the display backlight comes on and then I see the macOS loading bar appear. I can see the Gigabyte logo (and regain access to the BIOS settings) and the Clover UI if I either: 1) reboot my machine by going to "Menu > Restart…" in macOS after booting once, or 2) boot after flashing the original firmware that I backed up off the Winbond chip. Has anyone else experienced this or have advice about how I should go about debugging this?

Thanks,
垃圾車 LeSeChe

 

[lambusser]

Are you getting the error message as per my thread Catalina thinks my Corsair Commander Pro is a UPS?
If so, I wonder how you got rid of the error message at the login screen?

I have not reconnected my Corsair Commander Pro to test in 10.15.4, but I assume the problem is that macOS is not looking at the manufacturer and device id's of the commander pro and is attaching itself to the USB device based solely on the Commander Pro name which is a name of a third party UPS device.

Passing the USB port to Win10 on Parallels Desktop is the way to go, but if this error can be fixed maybe by blacklisting the macOS UPS driver, but I'm not sure as to the correct way to approach it.

Hi @jb007,

Same issue...working on trying to figure that out now.

I'm hoping there's a OSX UPS service I can disable...anyone know?

I'll keep you updated!

Lam

 

[jb007]

Hi @jb007,

Same issue...working on trying to figure that out now.

I'm hoping there's a OSX UPS service I can disable...anyone know?

I'll keep you updated!

Lam

Thanks, I was just about to tackle this problem now. Not sure whether to post on my original thread or here, maybe both?

 

[lambusser]

Thanks, I was just about to tackle this problem now. Not sure whether to post on my original thread or here, maybe both?

I think we'll need all the help we can get

 

[lambusser]

Thanks, I was just about to tackle this problem now. Not sure whether to post on my original thread or here, maybe both?

Great news @jb007!

This may not be the most elegant way but I found a fix!

It turns out all we need to do is stop /usr/libexec/ioupsd (UPS daemon) from running...

1) Mount the root filesystem as RW - "sudo mount -uw /"
2) Rename ioupsd to something like ioupsd.ORIG (for safekeeping)
3) Reboot
4) Mount the root filesystem as RO - "sudo mount -ur /"

Done and done!

I'll look into finding out how we can stop PM from having configd launch ioupsd in the first place that would be even cleaner, but this will do for now

If someone can help with that, please let us know!

Lam