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

[Inqnuam]

@CaseySJ Just downloaded and installed the native brightness app that you mentioned in your Z490 build
Is there any possibility to active this support without the app and use the native Magic Keyboard bright touches to control it? The combination fn + f1/f2 works when the app is lunched but i would like to use the native touches if possible of course

 

[CaseySJ]

I too had the Prohibited/Null boot fail after following the mini-guide and updating to Clover 5120 and was able to use the original 3 files work around successfully. In my case I was still on release 17 of OcQuirks. I then tried Casey's #2 suggestion above since #3 wasn't working, and downloaded release 23 of OcQuirks.efi (June 27 build), OpenRuntime.efi and modified the OcQuirks.plist, installed in the drivers/UEFI folder and it worked. I then tried removing the OcQuirks.plist and just using the Clover Quirks settings, but that failed again. Lastly, I left the Clover Quirks settings checked with matching OcQuirks.plist in drivers/UEFI and it worked. So, I'm guessing that, on my system, the clover 5120 config.plist Quirks keys aren't getting passed correctly. I used Clover Configurator. Looking at them in config.plist, the true key settings appear to be the same as in OcQuirks.plist. Maybe that's a clue as to why some of us are having an issue with the Clover installed OcQuirks?

I was able to reproduce this problem with Clover 5120, hence the micro-guide has been changed as shown below. However, please refer to the micro-guide for complete details. The new procedure will update Clover, but will leave UEFI drivers and kexts alone.

 

[CaseySJ]

I’ll update as soon as possible + DROM description for each line like in your screenshot

Thanks. The DROM description part is optional and not really necessary (I just reused an older screenshot). The main point is to start those lines in red box with the length value.

 

[djlild7hina]

@CaseySJ Just downloaded and installed the native brightness app that you mentioned in your Z490 build
Is there any possibility to active this support without the app and use the native Magic Keyboard bright touches to control it? The combination fn + f1/f2 works when the app is lunched but i would like to use the native touches if possible of course

Have you tried MonitorControl? It adjusts brightness and volume and you can use magic keyboard keys

 

[Inqnuam]

Have you tried MonitorControl? It adjusts brightness and volume and you can use magic keyboard keys

Thanks! Do you know if it’s possible to launch the app only in the background? I don’t want to see the app icon in the top bar.

 

[joeblough]

Correct -- the digital signature is only checked when writing. Once firmware is written, the operational assumption is that the firmware is trusted, hence no validation is done during read.

The reason is a bit more complicated. Thunderbolt controllers operate in one of two modes:

1. Internal Connection Manager (ICM) in which the controller itself manages link training, PCI tunneling, and other low-level details. This is the mode that Windows and Linux require.
2. O/S Managed Mode in which the operating system offloads many of these low-level details. This is the mode that macOS prefers. We cannot activate the full potential of Thunderbolt on macOS unless we switch the controller to this mode. The modification we make to Thunderbolt firmware switches the controller into this mode.

Note that Thunderbolt operation can be impaired under both Windows and Linux when the firmware is flashed. But if we boot into macOS first and warm-boot into Windows, then in many cases Thunderbolt will work.

ah right, i read about that along the way. while maybe i'm not surprised that OSX expects the firmware to configure the TB3 chip for Managed Mode, i'm surprised that windows doesn't try to change the mode and not rely on the firmware, given how many different hardware platforms microsoft has to support. unless of course there's no way to switch modes from the driver, but that seems unlikely.

anyway for me this isn't a huge concern since if i want to use windows i'll just run VMware.

Raspberry Pi is preferred. Have you seen the Raspberry Pi guide in this thread? In fact, the three articles highlighted below are essential:

View attachment 481393

Note that the Linux dump and the Flash ROM (SPI) dump will be different. The Flash ROM dump is the complete contents of the flash ROM chip whereas the Linux dump is only the Thunderbolt firmware sub-section.

We read the Flash chip at least 3 times, run shasum (checksum), and check whether checksums are identical each time. Then we type strings <firmware-file.bin> to make sure that the file is not gibberish, but contains at least some recognizable text.

All of this is also explained in the Raspberry Pi mini-guide.

yes, i was reading those after i posted about the TTL levels - so i've ordered the SPI clip but it is clearly on a slow boat. looks like it might be more than a week before i receive it. yeah i'll extract a bunch of times and take the md5sum to make sure i've gotten the real data. this GPIO stuff is prone to sampling errors since its all driven by software...

 

[joevt]

Note that the Linux dump and the Flash ROM (SPI) dump will be different. The Flash ROM dump is the complete contents of the flash ROM chip whereas the Linux dump is only the Thunderbolt firmware sub-section.

We read the Flash chip at least 3 times, run shasum (checksum), and check whether checksums are identical each time. Then we type strings <firmware-file.bin> to make sure that the file is not gibberish, but contains at least some recognizable text.

You can also compare the output from Linux dump ((1MiB-16KiB)/2)=516096 bytes=504KiB=0x7E000 with the firmware dump starting at 0x4000 or 0x82000 depending on the 4 byte little endian value at 0x0000 or 0x1000. DROM exists at 0x200 after that start (0x200 for Linux, 0x4200 or 0x82200 for full dump).

 

[MantaRaptor]

Hi @CaseySJ. I am a long time lurker and have used your guide to get my machine up and running with Catalina.

Everything works well, however I have a weird issue: after long periods of sleep, the time on my machine is always wrong. I've got the settings within time and date set as set time zone automatically as well as the set time automatically setting being checked with Apple's servers. It does eventually get the time right after a few minutes and so the time does eventually sync properly, however it's annoying as after long sleeps (like overnight) the clock is often wrong by a few hours.

Looking online, people have said this could be a CMOS issue? I don't think so, but will wait for your advice, as in my opinion if it was a CMOS issue, it wouldn't remember all the BIOS settings you've mandated we should make to get this machine up and running, right? Also, if it helps, the BIOS time is never correct, even if I set it, after a reboot, it reverts back to it's original setting (which is around an hour behind normal time).

Would appreciate any help from you as this is my last hurdle. Thank you.

 

[jiffyslot]

Could that be an RTC issue?

 

[CaseySJ]

Hi @CaseySJ. I am a long time lurker and have used your guide to get my machine up and running with Catalina.

Everything works well, however I have a weird issue: after long periods of sleep, the time on my machine is always wrong. I've got the settings within time and date set as set time zone automatically as well as the set time automatically setting being checked with Apple's servers. It does eventually get the time right after a few minutes and so the time does eventually sync properly, however it's annoying as after long sleeps (like overnight) the clock is often wrong by a few hours.

Looking online, people have said this could be a CMOS issue? I don't think so, but will wait for your advice, as in my opinion if it was a CMOS issue, it wouldn't remember all the BIOS settings you've mandated we should make to get this machine up and running, right? Also, if it helps, the BIOS time is never correct, even if I set it, after a reboot, it reverts back to it's original setting (which is around an hour behind normal time).

Would appreciate any help from you as this is my last hurdle. Thank you.

Let's address the more common issue first: Date/Time in BIOS is always wrong for me as well. I vaguely recall opening an EFI Shell and setting date/time on the command line, but I don't recall if that worked and, if so, for how long. This is annoying, but I believe most of us just live with it.

The less common problem is the date/time in macOS. As @jiffyslot mentioned, it may be a good idea to install SSDT-AWAC.aml by simply copying the attached file into the CLOVER/ACPI/patched folder and rebooting. AWAC stands for "A Weird A$$ Clock".