AudioGod's Aorus Z390 Pro Patched DSDT Mini Guide and Discussion

[Neek]

2 hours ago, panosru said:

I wonder if anyone tried the F12l BIOS

Been running F12l under Catalina for a couple weeks. No issues.

[jimborae]

Yep nothing too disasterous report with bios F12l so far. The only issue I might be seeing is the Smart Fan 5 control profiles seem to be a bit fubared, in that I try & disable them for System Pump 5 & 6 board connectors and it doesn't seem to stick & always re-enables them. Need to play a bit more to see if I can work it out.  

 

In my case it's irelevant really anyway as System Fan 6 Pump is only used to monitor the flow rate and not actually control the DC5 water pump's voltage/speed. 

Edited February 3, 2021 by jimborae

[pkdesign]

1 hour ago, AudioGod said:

Exactly

Well. It works. Not sure how to tell, but I can boot into macOS and Windows with no problem. I will assume since @AudioGod told me it works that it is doing something 

[AudioGod]

5 minutes ago, pkdesign said:

Well. It works. Not sure how to tell, but I can boot into macOS and Windows with no problem. I will assume since @AudioGod told me it works that it is doing something 

If you open up HWINFO it will list it properly with your correct hardware info and not the smbios info.

Or run GeekBench and when the results pop up it will list it correctly and not claim it’s a Mac.

Edited February 3, 2021 by AudioGod

[panosru]

I just flashed the new BIOS, I did not update the fallback BIOS just in case, I used all the settings from previous BIOS (to make sure I will be able to load the previous profile I saved it with the most failproof way, I took a photo of each screen in previous BIOS and then reapplied them ). Everything seems to work fine!

 

I noticed that with the new BIOS when I enable the option "Above 4G Decoding", a new option appears underneath it - which is disabled by default - called "Re-Size BAR Support".

 

I have no clue what that is, the only BAR that I'm familiar with is the one that you have to pass the exam in order to become an attorney

[AudioGod]

@panosru Re-Size BAR Support is for big Navi and SAM support. Don’t enable it as macOS won’t be able to boot with it enabled.

 

SAM = Smart Access Memory 

 

Edited February 3, 2021 by AudioGod

[eSaF]

3 minutes ago, panosru said:

the only BAR that I'm familiar with is the one that you have to pass the exam in order to become an attorney

Or the one you go to with your buddies to get pi$$ed. 

[jimborae]

1 minute ago, eSaF said:

Or the one you go to with your buddies to get pi$$ed. 

 

That's the only one worth knowing about! 

[juan e. jot]

7 hours ago, AudioGod said:

Press F12 at start up and then select your boot drive (not OpenCore bootstrap) reset nvram, go into the bios and set order so only your OS X boot disk is selected (not OpenCore bootstrap) and restart and done.

On the next boot up it will set it correctly, and the bootstrap will be selected and working.

 

If for some reason that’s not enough to clear it then pull your mains cable and remove the bios battery for 5 mins or if you want to be even more extreme then reflash your bios and it will kill all traces but that’s a last resort.

less extreme, disable the boot strap in the config and then do any of the above then set it back to full when done.

All methods should work if not one of them definitely will.

 

Oh my good golly, that was a doozy!  What finally (knock on wood) seems to have worked for me was going back to HfsPlus.efi from OpenHfsPlus.efi; in its current form, OpenHfsPlus.efi seems to hang OC from being able to find an externally USB-connected HFS+ volume, such that none of the boot options ever show up! The inconsistency of the problem got real consistent when that external drive was disconnected, and only internal non-HFS+ drives were connected: it worked with no issue. Reconnect HFS+ before boot, get a lack of boot options again.

 

Going back to HfsPlus.efi seems to have reverted, for now, to good behavior. No idea how it would have treated an internal HFS+ volume, as I don't have one, and sorry, I'm not shucking my external drive in the name of science.

Edited February 4, 2021 by juan e. jot
Apparent, for now, knock-on-wood resolution to problem (maybe).

[pkdesign]

I am totally confused about Bootstrap, etc. I see that @AudioGod has LauncherOption set to Full. Mine is currently set to Disable but I can still boot just fine. I've read that once the change is made you can delete the BOOTx64.efi but that is still present in AudioGod's EFI.

 

I've read through the Dortania Guide a hundred times and still don't understand it. Help!

[AudioGod]

25 minutes ago, pkdesign said:

I am totally confused about Bootstrap, etc. I see that @AudioGod has LauncherOption set to Full. Mine is currently set to Disable but I can still boot just fine. I've read that once the change is made you can delete the BOOTx64.efi but that is still present in AudioGod's EFI.

 

I've read through the Dortania Guide a hundred times and still don't understand it. Help!

The bootstrap default path points to Bootx64 so I don’t see how you can delete it. (Launcherpath=\EFI\BOOT\BOOTx64.efi)

Yes of course you can boot with it disabled, the whole point of the bootstrap is to give your MacOS disk boot priory and keep it that way no matter what you do, without it enabled you risk it jumping to the windows drive when you reset nvram or update windows.

Edited February 4, 2021 by AudioGod

[pkdesign]

34 minutes ago, AudioGod said:

The bootstrap default path points to Bootx64 so I don’t see how you can delete it. (Launcherpath=\EFI\BOOT\BOOTx64.efi)

Yes of course you can boot with it disabled, the whole point of the bootstrap is to give your MacOS disk boot priory and keep it that way no matter what you do, without it enabled you risk it jumping to the windows drive when you reset nvram or update windows.

Thanks for that. I need to stop reading posts and just be happy I've got a perfectly (almost) working hack! I made the LauncherOption change to Full to match your EFI.

 

In the Config for OC it says:

 

LauncherPath
Type: plist string
Failsafe: Default
Description: Launch path for LauncherOption.

Default stays for launched OpenCore.efi, any other path, e.g. \EFI\Launcher.efi, can be used to provide custom loaders, which are supposed to load OpenCore.efi themselves.

 

Funny, resetting NVRAM always did revert my boot to Windows. I always had to choose my macOS disk after I did it. Must have always had something wrong set.

 

I'm going to leave it alone now!

 

This is the post I was referring too:

 

 

Edited February 4, 2021 by pkdesign

[juan e. jot]

I'm not sure whether my issue above, with the current version OpenHfsPlus.efi making OC 0.6.6's graphical boot picker hang if I have an external HFS+ volume connected at boot time (solved by going back to HfsPlus.efi), is one I can submit an issue about on Github or elsewhere the developers would see. Looking at both the OC master repo & the OcBinaryData repo, pull requests seem set to "compare" (forks) in ways I haven't seen for other developers, and I see no dedicated "issue" tab for either repo. I just wonder how to let them know I have this issue & ask if they've heard it from others and are testing conditions which affect & possible solutions to it.

 

What do you folks think? TIA!

[AudioGod]

5 minutes ago, juan e. jot said:

I'm not sure whether my issue above, with the current version OpenHfsPlus.efi making OC 0.6.6's graphical boot picker hang if I have an external HFS+ volume connected at boot time (solved by going back to HfsPlus.efi), is one I can submit an issue about on Github or elsewhere the developers would see. Looking at both the OC master repo & the OcBinaryData repo, pull requests seem set to "compare" (forks) in ways I haven't seen for other developers, and I see no dedicated "issue" tab for either repo. I just wonder how to let them know I have this issue & ask if they've heard it from others and are testing conditions which affect & possible solutions to it.

 

What do you folks think? TIA!

Report to them for sure,

if you cant do it on the GitHub then do so over at the OpenCore thread on here.

 

Edited February 4, 2021 by AudioGod

[pkdesign]

I have finally figured it out! Once you have OC 066 set up properly (LauncherOption, etc.) you can delete the BOOT folder entirely. BOOTx64.efi is no longer needed. At boot, you then press F12 and select "OpenCore" as your boot and off you go.

[juan e. jot]

3 hours ago, AudioGod said:

Report to them for sure,

if you cant do it on the GitHub then do so over at the OpenCore thread on here.

 

Thanks! Have done so.

[stavidawg]

Safe to install the newest OS X update?

[jimborae]

1 hour ago, stavidawg said:

Safe to install the newest OS X update?

Yes 

[rob1980]

Could somebody tell me if USB C functions as a power device only or for data transfer too? I ask as my new iPhone has a USB C cord now as is not detected.

Thanks

 

 

 

[AudioGod]

On 2/4/2021 at 9:39 PM, pkdesign said:

I have finally figured it out! Once you have OC 066 set up properly (LauncherOption, etc.) you can delete the BOOT folder entirely. BOOTx64.efi is no longer needed. At boot, you then press F12 and select "OpenCore" as your boot and off you go.

Isn’t that a bit risky to do that?

If you flash your bios to a newer revision one day or have to clear your bios for some reason it’s gonna wipe out the nvram and your have no way of getting back into the drive all of a sudden, 

Surely it’s better left in there even if it’s dormant no?

Edited February 5, 2021 by AudioGod

[Alex1982]

13 hours ago, rob1980 said:

Could somebody tell me if USB C functions as a power device only or for data transfer too? I ask as my new iPhone has a USB C cord now as is not detected.

Thanks

The same issue, only charging on USB C and no data transfer on macOS. On Windows data transfer works.

[AudioGod]

15 minutes ago, Alex1982 said:

The same issue, only charging on USB C and no data transfer on macOS. On Windows data transfer works.

@rob1980 @Alex1982 I might no why actually. Is one of you available to do a test in around 45 mins from now?

 

[jimborae]

32 minutes ago, AudioGod said:

@rob1980 @Alex1982 I might no why actually. Is one of you available to do a test in around 45 mins from now?

 

 

Yo AG. if they aren't, I am, & I think I've witnessed this behavior also, although it didn't register with me at the time. 

 

*Edit* Yep confirmed, none of the USB Type C ports do anything but. but charge. I have 2 USB Type C ports on my hack, one is the onboard port on the back and I also have another via a front panel add on that connects to the motherboard connector.  

 

Edited February 6, 2021 by jimborae

[Alex1982]

@AudioGod, sure, I can. Which test you are meaning? I already do some testing before by disabling 15 USB port limit in OC(as suggested earlier in this thread), so all HS and SS ports be available. When I disable 15 USB port limit I see that macOS started detecting my USB C devices but all of them always connected to HS(not SS) port(I check it via Hackintool). From above observation I concluded that when 15 USB port limit enabled(I use your USBMap.kext as is without any modifications) HS ports are disabled for USB C that's why devices is not detected. The question here why USB C devices connecting only as HS but not SS. Probably the cause of @rob1980 issue is the same with mine.

[AudioGod]

Do u think it’s possible that it’s looking for usb2 over usb c?

 

I used to use a usb c hub on my old Intel hack and all my devices worked but they were all true usb 3 not 2.0 using a type c connection.

 

@Alex1982 going by what you just said that does seem to be the case.

 

you have two options in that case, go past the 15port limit or change the USBMap and give usb2 as well as 3.0 to type-c.

I can Bosch up a new kext in a few mins to try if you want to do the later?

 

p.s and before you say the iPhone uses a type c usb 3.0 cable well I don’t think that’s ever been the case. It’s always been usb2.0 as far as I’m concerned. I even just checked just this second on my iPhone via windows and it’s showing usb2.0 speeds.

Edited February 6, 2021 by AudioGod