Contribute
Register

Mojave on ASRock Z390 Phantom Gaming-ITX/ac

Status
Not open for further replies.
The panics I was referring to are seen only right before reboot/shutdown.

But just to be sure you don't have them, you mean you can actually shutdown the system from OSX, and the PC turns off (not reboots) without EmuVariable?

I am asking about shutdown because the panic causes a reboot, so it may be missed when rebooting.
If you can shutdown without EmuVariable then you're on to something, and it needs to be investigated.
 
Last edited:
The panics I was referring to are seen only right before reboot/shutdown.

But just to be sure you don't have them, you mean you can actually shutdown the system from OSX, and the PC turns off (not reboots) without EmuVariable?

I am asking about shutdown because the panic causes a reboot, so it may be missed when rebooting.
If you can shutdown without EmuVariable then you're on to something, and it needs to be investigated.


Correct, I always use "Shut Down..." or do a "Restart..." from the Apple menu. I've never had a panic on shutdown from any of my mobos with or without EmuVariable. On shut down, the OSX exits, followed by a click of the PS as it turns off.

Not directly related, but once I've got a build working well (like the Gigabyte Z390 Designare build), I use it to seed the next build. By seeding, I mean that I use a clone made with SuperDuper to transfer a working system/build onto another new SSD. This newly cloned drive, attached via USB3, boots the new mobo (well, there are often a few panics during initial booting until the graphics are sorted out). This gets me up and running faster than doing a fresh install from a USB stick. Once all is working, then I pull out various pieces to see how things are affected (like EmuVariable).

One thing I've observed is how easily corrupted the BIOS can become, especially during the initial boot panics. So once the OSX system is regularly booting and seems to be running okay, the BIOS should probably be re-flashed to minimize any stability problems it would otherwise contribute. I think some of the problems with various panics may stem from BIOS corruption. (I have to remind myself to do this, and once I re-flash the BIOS, I'm amazed at how smoothly the system then runs.)

I also wondering if the SSDT power management files I use, help with avoiding the panics you've seen.

These files were derived from an app called USBMap (by corpnewt). They're included in the patches folder download on my original post.
 
Last edited:
Looking again at the list of your drivers, the reason you were not having panics must be because you are using the very old OsxAptioFix2Drv-free2000.efi (instead of the newer AptioMemoryFix-64.efi). Perhaps that version doesn't have the latest patches for making native nvram work, and that is probably why it doesn't panic.
 
Last edited:
Looking again at the list of your drivers, the reason you were not having panics must be because you are using the very old OsxAptioFix2Drv-free2000.efi (instead of the newer AptioMemoryFix-64.efi). Perhaps that version doesn't have the latest patches for making native nvram work, and that is probably why it doesn't panic.

You are correct!

I tried various combinations, and while OsxAptioFix2Drv-free2000.efi is okay by itself, AptioMemoryFix-64.efi requires the presence of EmuVariable. By itself, AptioMemoryFix-64.efi will have panic restarts. Which then begs the question, why is newer better; what's wrong with staying with OsxAptioFix2Drv-free2000.efi?

On another matter, after un-locking MSR on a Designare build, I decided to try the same on the ASRock Z390 ITX mobo. On booting with Grub, it seems that the CFG Lock location of 0x5C4 is already 0x00 on BIOS v1.6. So v1.6 is natively un-locked. I un-checked KernelPm on the Clover Kernel & Kexts Patches page and it boots just fine.
 
You are correct!

I tried various combinations, and while OsxAptioFix2Drv-free2000.efi is okay by itself, AptioMemoryFix-64.efi requires the presence of EmuVariable. By itself, AptioMemoryFix-64.efi will have panic restarts. Which then begs the question, why is newer better; what's wrong with staying with OsxAptioFix2Drv-free2000.efi?
Well, newer is not always better, but in cases when native nvram access under macos does not work (and, I checked, it doesn't work for this board, no matter which version of *AptioFix* you are using), it should not be used without EmuVariable.

When OSX shuts down/reboots, it tries to write some variables to the board's nvram.
With older AptioFix no error it displayed, we don't know exactly what happens, but write does not succeed; with the new AptioMemoryFix it panics. But the end result is similar: we have an unsuccessful write to the board's nvram, which should be avoided. Also, I don't think that the case where it doesn't panic but doesn't work is necessarily better - as we don't know what ends up being written and where (you mentioned some corruption, maybe it is related?).

EmuVariable intercepts the writes to nvram, so when it is used, writes to the real nvram are not even attempted.
In general, EmuVariable is to be excluded only if real ("native") nvram writes work from OSX.

Unfortunately, until AptioFix developers fix nvram writes support for the newer version of Aptio, which is used in recent boards (Z390 and some others), native nvram writes isn't expected to work.
 
Last edited:
I did not know this. Thanks for the explanation.
 
Also the BIOS needs to show that the iGPU is being used, not the PCIe slot and need to bottom of the same window, that the iGPU is 'enabled' (see the BIOS uploads in my post). Also, I only used the i9 9900K chip and don't know what frame buffer changes you might need for the Clover config file. If you can get the iGPU going, try using Hackingtool to create the proper frame buffer for your i5.

you're right. the AsRock bios is a little confusing, theres an additional option at the bottom that will disable the iGPU if a dGPU is present. I had to switch that and my i5-9400 igpu was recognized fine without any need to specify framebuffer :)


On another matter, after un-locking MSR on a Designare build, I decided to try the same on the ASRock Z390 ITX mobo. On booting with Grub, it seems that the CFG Lock location of 0x5C4 is already 0x00 on BIOS v1.6. So v1.6 is natively un-locked. I un-checked KernelPm on the Clover Kernel & Kexts Patches page and it boots just fine.

no need to do this, AsRock already has MSR unlocked, called "CFG lock" in BIOS

Question on Thunderbolt 3 - do you have to have a dock? or can you connect a device directly? just curious, i'll be trying it out later.
 
I did not know this. Thanks for the explanation.
You're welcome!
Just to clarify, I was not saying that AptioMemoryFix is necessarily better than OsxAptioFix2 for this board (It's difficulty to say which is preferred, as none is working properly, it's a matter of personal preference here) - I was just saying that in any case EmuVariable should be added to protect the board from failed nvram writes.
 
For all guys with problems on the new Asrock BIOSes (for this board, and for other Asrock boards), add in Clover's config.plist,
under ACPI\DSDT\Patches the following patch (I already posted my patch in the General Z390 thread):
Code:
        <dict>
          <key>Comment</key>
          <string>Fix AsRock Z390 BIOS DSDT Device(RTC) bug</string>
          <key>Disabled</key>
          <false/>
          <key>Find</key>
          <data>
          oAqTU1RBUwE=
          </data>
          <key>Replace</key>
          <data>
          oAqRCv8L//8=
          </data>
        </dict>


The problem his an uninitialized variable in Device(RTC) that makes OSX DSDT parser freak out.
I am quite sure AsRock will eventually fix this, but for now, it is a usable solution.

THANKS MAN!!! I spend 3 days trying to run OSX Mojave installer, this patch helped me. I'm crying from happiness
 
I'm just backing up my build that's currently using @d3mone EFI. I'm not using a discrete GPU (1080ti installed but obviously not running) and so i'm running off the igpu of the 9900k. Getting ready to update to 10.14.5 and just wanted to check on a couple of things.

Currently my SMBIOS is set to iMac18,1. Should i update and then change my SMBIOS to something closer now that we have better support for this processor? Or will i have problems running off the igpu? Currently i have ig-platform-id set to 0x3E9B0007 to avoid graphical glitching.

cheers all!
 
Status
Not open for further replies.
Back
Top