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

[pitt1717]

Please see the 4th bullet in this post:

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

Maybe the RAM modules (one or both) are defective? The Corsair Vengeance RGB modules should work -- they are XMP 2.0 certified. However, to be safe, you're certainly welcome to switch to G.Skill TridentZ. We should also keep in Mind, that i7 and i9 Processors are specified for 2666MHz RAM...

www.tonymacx86.com

I'll start reading up. Thank you.

Do you mean compiling the OpenCore source code or configuring the OpenCore config.plist?
Compiling...

Clover is still the dominant boot loader, whereas OpenCore is a "hobby" (as Apple says of its AppleTV device). Let's revisit this question once OpenCore reaches Version 1.00.

sounds good

 

[pitt1717]

That's the dilemma: (a) cool and useful new features versus (b) possible dead-ending of the fork. It's also possible that standard OpenCore will, in time, adopt some or all of the new features that are present in the fork.

Those running both macOS and Windows may benefit from the n-d-k fork right now.

So perhaps we should switch to the n-d-k fork now, and once standard OpenCore incorporates all of the critical features that are in the fork, we can switch back to standard OpenCore.

That may be a good idea. It seems OpenCore broke my dual booting.

 

[chrisrich93]

You're powering up the Apollo Thunderbolt stuff before powering up the computer? And I'm assuming you've adjusted your System Preferences:

View attachment 445247

Check your System Preferences and Ableton's audio engine preferences to make sure that it's not sneaking in a "Pro Tools Aggregate Device" kind of setup. If there's another device that's locked in a sample rate different from your session, that would be an issue. It's the most noticeable because your audio will quite noticeably degrade over several minutes, depending on the difference in sample rates. Or the "not loaded first device" simply won't connect.

I had an issue when I switched my Apollo 8 from the Mac Mini to the Hack and the back to the Mini where I had to reinstall the entire UAD-Mac-v9110 package on the Mini. It's like one system is "imprinting" onto the Thunderbolt stuff and is not willing to let it go. This does not happen between my real Mac Mini's: the 2018 and the 2x 2012's -everything is Mojave except for one of the 2012's.

LMK what happens.

I usually power the UAD devices at the boot screen, should I be turning them on before the computer? There's just one UAD device in the audio setup of Ableton, the issue seems to be more with just the plugins and the processing via the SHARC chips losing connection, audio quality stays fine. I have noticed the issue with the way I boot them and after the computer has been on and the displays go off, although I thought I didn't have sleep enabled I need to double check.

 

[manfriday]

Are you sure its under ACPI? I see it under booter--quirks.


I'm also getting when running nvram -c as sudo
nvram: Error clearing firmware variables: (iokit/common) not permitted



I guess the error doesn't matter, and I'm not sure what changed from my original folder to the new one. Now get the output when greping nvram. So it looks like it works now.

You are correct. it is under BOOTER. I made a mistake when I wrote my post. sorry about that!

 

[pitt1717]

I do have a question. As I'm reading through the OC plist, the SSDT and DSDT have no path appended. Yet, the kexts do. What has got me scratching my head is why is the path Contents/MacOS/VirtualSMC? I thought it would or should be /EFI/OC/Kexts/VirtualSMC.

 

[manfriday]

That may be a good idea. It seems OpenCore broke my dual booting.

It broke dual booting for me too until Casey pointed out the forked version of OpenCore.
The issue is probably that your DSDTs and SSDTs are being used for WINDOWS as well as macOS.
The forked version Case pointed out doesn't do that, and it fixed my issue.

If you dont feel like compiling it here it is:

 

[pitt1717]

You are correct. it is under BOOTER. I made a mistake when I wrote my post. sorry about that!

No biggie. It's working now, thanks.. This dual boot is gonna be an issue though. I saw you mentioned about the Windows drive string. You may be able to get it from Clover Configurator, under mount EFI... all the drives are listed. I just don't see where to add it as I don't see a line containing the same number. But there is a line to boot64.efi, I believe.

 

[manfriday]

So heres MY new issue with OC.

I can boot into Windows or macOS now. But every time I reboot, my BIOS changes the EFI disk. It boots to from the EFI containing OpenCore to Windows.
So each time I reboot, I need to go into the IOS and change it back to the correct boot disk, OR I need do an F12 and select the disk I want to boot from.

 

[pitt1717]

It broke dual booting for me too until Casey pointed out the forked version of OpenCore.
The issue is probably that your DSDTs and SSDTs are being used for WINDOWS as well as macOS.
The forked version Case pointed out doesn't do that, and it fixed my issue.

If you dont feel like compiling it here it is:

I just tried it. I like the menu a bit better but its stretched out. Windows still pukes on an acpi BIOS error.

**Update, its working now... forgot that I tried
ACPI->Quirks->EnableForAll to yes

changed it to no (default) and I can get into both OS's now

anyway to change the resolution?

 

[manfriday]

I just tried it. I like the menu a bit better but its stretched out. Windows still pukes on an acpi BIOS error.

Oh, you need to modify your config.plist.

ACPI->Quirks->EnableForAll to NO

for your stretched console try
Misc->Boot->ConsoleMode to Max
Misc->Boot->Resolution to Max