Jump to content

AudioGod's Aorus Z390 Master Patched DSDT EFI for Catalina Mini Guide and Discussion


AudioGod
1,847 posts in this topic

Recommended Posts

2 minutes ago, jake_mike said:

 

Ah cool, they seemed to be off when I was comparing to yours that's why I was a bit concerned :)

 

One is connected via HDMI, second via DP (using DP to HDMI adapter).

 

I did not touch any arguments in the Clover config. I am complete Hackintosh noob, started learning yesterday (using your guide). 

 

 I just posted a new EFI for you made to be used without the igpu, your find that preforms a lot better with your gpu, (check my last post to you)

if you dont render and you want sidecar working then stick with this EFI and remove the boot argument agdpmod=pikera from the clover config.

Edited by AudioGod
  • Thanks 1
Link to comment
Share on other sites

2 minutes ago, AudioGod said:

 

 I just posted a new EFI for you made to be used without the igpu, your find that preforms a lot better with your gpu, (check my last post to you)

if you dont render and you want sidecar working then stick with this EFI and remove the boot argument agdpmod=pikera from the clover config.

 

Thank you! Out of curiosity, how this is different to switching iGPU off in BIOS?

 

I am planning to do some rendering in Adobe Premiere in the near future - how will that work? Sidecar is not needed atm. 

Link to comment
Share on other sites

1 minute ago, jake_mike said:

 

Thank you! Out of curiosity, how this is different to switching iGPU off in BIOS?

 

I am planning to do some rendering in Adobe Premiere in the near future - how will that work? Sidecar is not needed atm. 

 

With igpu enabled when you do anything like rendering it pushes the work over to the igpu instead of the gpu and uses quick sync. It’s very good and in most cases worth having that way but the Radeon VII is the exception as it pulls a can of woop ass when rendering compared to the igpu.

 

that’s it really.

  • Thanks 1
Link to comment
Share on other sites

22 hours ago, AudioGod said:

 

With igpu enabled when you do anything like rendering it pushes the work over to the igpu instead of the gpu and uses quick sync. It’s very good and in most cases worth having that way but the Radeon VII is the exception as it pulls a can of woop ass when rendering compared to the igpu.

 

that’s it really.

 

Thanks for the explanation, it makes things clear now.

 

UPDATE:

 

I managed to enable the second screen by manually switching the input on the monitor to HDMI 2 and then back to HDMI 1. This also works for black screen on wake, both monitors must be switched to HDMI 2 and then back to HDMI 1. 

  

Changing the 'darkwake=0' did not fix the issue :(

  

Any ideas please?

Link to comment
Share on other sites

Hey guys.

 

I managed to get stock OpenCore (instead of a fork) running on my i9-9900K + Z390 Aorus Master + RX 580 + 64GB RAM + 970 Evo Plus as an iMac19,1 with iGPU enabled under Mojave 10.14.6 (not updating to Catalina just yet — too buggy for me). Unfortunately, I cannot get it to boot without using MemoryAllocation.efi, which seems to be a combination of code from OsxAptioFix2Drv-free2000.efi and OsxAptioFix3Drv.efi. As we all know, OsxAptioFix2Drv-free2000.efi has been declared bad by its developer and I'm currently looking for a way to boot without memory allocation errors without using MemoryAllocation.efi and with iGPU enabled, set up as iMac19,1.

 

Settings iGPU memory to 32 and 128 MB in BIOS has not helped. Slide=0 and a few other calculated values failed too. So has OsxAptioFix3Drv.efi.

 

Any ideas welcome.

Edited by M0r1d1n
Link to comment
Share on other sites

1 hour ago, M0r1d1n said:

Hey guys.

 

I managed to get stock OpenCore (instead of a fork) running on my i9-9900K + Z390 Aorus Master + RX 580 + 64GB RAM + 970 Evo Plus as an iMac19,1 with iGPU enabled under Mojave 10.14.6 (not updating to Catalina just yet — too buggy for me). Unfortunately, I cannot get it to boot without using MemoryAllocation.efi, which seems to be a combination of code from OsxAptioFix2Drv-free2000.efi and OsxAptioFix3Drv.efi. As we all know, OsxAptioFix2Drv-free2000.efi has been declared bad by its developer and I'm currently looking for a way to boot without memory allocation errors without using MemoryAllocation.efi and with iGPU enabled, set up as iMac19,1.

 

Settings iGPU memory to 32 and 128 MB in BIOS has not helped. Slide=0 and a few other calculated values failed too. So has OsxAptioFix3Drv.efi.

 

Any ideas welcome.


MemoryAllocation.efi is perfectly safe don’t worry.

FwRuntimeServices.efi Is the alternative .Efi to OsxAptioFix2Drv-free2000.efi. 
can I just also point out going a little off topic for a second. Find me one person that has ever borked or blown there system due too OsxAptioFix2Drv-free2000.efi ?

i would love to hear about it and what happened but I’m willing to bet your never find the story’s I’m after because it’s never happened.  

 

19 hours ago, jake_mike said:

 

Thanks for the explanation, it makes things clear now.

 

UPDATE:

 

I managed to enable the second screen by manually switching the input on the monitor to HDMI 2 and then back to HDMI 1. This also works for black screen on wake, both monitors must be switched to HDMI 2 and then back to HDMI 1. 

  

Changing the 'darkwake=0' did not fix the issue :(

  

Any ideas please?


Only thing that springs to mind is to check that macOS is sending the correct colour palet to your screens as there is a bug in macOS that sometimes thinks your monitors are ARGB when they are actually RGB so you need to force RGB to the screen to correct it. I don’t know if this would apply to your own monitors but it’s worth a check for sure,

 

https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/

Edited by AudioGod
Link to comment
Share on other sites

1 hour ago, AudioGod said:

MemoryAllocation.efi is perfectly safe don’t worry.

 

Since the author of OsxAptioFix2Drv-free2000.efi has specifically stated that you SHOULD NOT use it, and MemoryAllocation.efi re-uses code from the former, I would prefer to choose another route. Better safe than sorry.

Link to comment
Share on other sites

I don’t think you get how the EFI is working but sure no problem buddy. LoL

(go easy with the caps!)

clover is your best route using oc quirks in that case for 19,1 with igpu enabled.

pull the battery from your bios for a few mins to fully reset it and that will work.

its very hard to get OC running under 19,1 the way you want.

or you can try the ssdt that everybody is raving on about that also already in my dsdt. That might work for you bud? :) 

 

Edited by AudioGod
Link to comment
Share on other sites

1 hour ago, AudioGod said:


MemoryAllocation.efi is perfectly safe don’t worry.

FwRuntimeServices.efi Is the alternative .Efi to OsxAptioFix2Drv-free2000.efi. 
can I just also point out going a little off topic for a second. Find me one person that has ever borked or blown there system due too OsxAptioFix2Drv-free2000.efi ?

i would love to hear about it and what happened but I’m willing to bet your never find the story’s I’m after because it’s never happened.  

 


Only thing that springs to mind is to check that macOS is sending the correct colour palet to your screens as there is a bug in macOS that sometimes thinks your monitors are ARGB when they are actually RGB so you need to force RGB to the screen to correct it. I don’t know if this would apply to your own monitors but it’s worth a check for sure,

  

https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/

 

I have changed the EFI back to 19,1. Disabled the iGPU in the BIOS and removed the agdpmod=pikera argument from the config, but left darkwake=8 untouched. All working fine now. Both screens switching on and waking up no problem :thumbsup_anim:

 

 

  • Like 1
Link to comment
Share on other sites

41 minutes ago, AudioGod said:

I don’t think you get how the EFI is working but sure no problem buddy. LoL

(go easy with the caps!)

clover is your best route using oc quirks in that case for 19,1 with igpu enabled.

pull the battery from your bios for a few mins to fully reset it and that will work.

its very hard to get OC running under 19,1 the way you want.

or you can try the ssdt that everybody is raving on about that also already in my dsdt. That might work for you bud? :) 

 

 

I took a look at your OC fork config and there are many things I don't like. It can work … but that doesn’t mean it works.

Link to comment
Share on other sites

1 minute ago, iStigPL said:

 

I took a look at your OC fork config and there are many things I don't like. It can work … but that doesn’t mean it works.

What’s the problem dude?

it works perfectly and it’s not my fork it’s NDK and even @MaLd0n uses it himself so please do tell myself and @texem what your problems with it are?

Link to comment
Share on other sites

21 minutes ago, AudioGod said:

What’s the problem dude?

it works perfectly and it’s not my fork it’s NDK and even @MaLd0n uses it himself so please do tell myself and @texem what your problems with it are?

 

There are some standards I prefer to use. 

- It seems you've dumped DSDT without references. 

- I've noticed you made USB map or at least you tried to as you have USBPorts.kext, but why in the same time there is XhciPortLimit patch set True....

I don't have more time to check all, but these things are what matters. It’s not just about what works.

Link to comment
Share on other sites

Just now, iStigPL said:

 

There are some standards I prefer to use. 

- It seems you've dumped DSDT without references. 

- I've noticed you made USB map or at least you tried to as you have USBPorts.kext, but why in the same time there is XhciPortLimit patch set True....

I don't have more time to check all, but these things are what matters. It’s not just about what works.

 

@texem the guy that made the EFI will answer your questions but there's a good reason for everything as he will explain to you when he's not busy. At the end of the day if you don't like it then don't use it but don't come on this thread all salty like your the master of OC configs. it comes across as very arrogant and rude buddy and I've not got the time or energy to waste on stuff like that.

  • Like 1
Link to comment
Share on other sites

45 minutes ago, iStigPL said:

 

I took a look at your OC fork config and there are many things I don't like. It can work … but that doesn’t mean it works.

 

if you don't like it .. no one forced you to use it. And keep in mind : it's a template. Create your own USBPorts.kext and set XHCI to false and whatever you want but please respect the words of AudioGod

 

 

  • Like 1
Link to comment
Share on other sites

2 minutes ago, AudioGod said:

 

@texem the guy that made the EFI will answer your questions but there's a good reason for everything as he will explain to you when he's not busy. At the end of the day if you don't like it then don't use it but don't come on this thread all salty like your the master of OC configs. it comes across as very arrogant and rude buddy and I've not got the time or energy to waste on stuff like that.

 

I'm happy that you are happy with your config. There is always better way to do sth and that's what I'm trying to achieve.

 

Just take a look at what M0r1d1n wrote. He did some investigation on MemoryAllocation.efi sources, but your response was "MemoryAllocation.efi is perfectly safe don’t worry" and later "I don’t think you get how the EFI is working but sure no problem buddy", so who is rude buddy ?

 

Link to comment
Share on other sites

6 minutes ago, texem said:

 

if you don't like it .. no one forced you to use it. And keep in mind : it's a template. Create your own USBPorts.kext and set XHCI to false and whatever you want but please respect the words of AudioGod

 

 

Guys what are your problems ? I thought this discussion is to improve that build.... 

  • Confused 2
Link to comment
Share on other sites

12 minutes ago, iStigPL said:

 

I'm happy that you are happy with your config. There is always better way to do sth and that's what I'm trying to achieve.

 

Just take a look at what M0r1d1n wrote. He did some investigation on MemoryAllocation.efi sources, but your response was "MemoryAllocation.efi is perfectly safe don’t worry" and later "I don’t think you get how the EFI is working but sure no problem buddy", so who is rude buddy ?

 


that’s not me being rude that me accepting he’s doing stuff he’s way and what you left out is I go on to suggest what to do instead so please halt with your bad attitude cos that’s not what this thread is here for. 
little hint calling somebody buddy is not rude it’s being friendly like I always try to be and as a side note, the ndk Efi that’s on here has been downloaded over 200 times since it’s release and everybody but yourself is happy with it and in the words of spock the needs of the many outweigh the needs of the few.

 

also one last thing is we are always up for constructive changes to any config if it helps so your always welcome to help improve things if you think you can my only point is that the way you come across is very arrogant and that’s never helpful.

 

If you wanna start again in a nice way and call it crossed wires then by all means do so,

Edited by AudioGod
Link to comment
Share on other sites

@iStigPL We actually have a new non forked Version of Real OC V055 that’s under test right now that I prefer much much more.

i might even like it more then clover now.....maybe...possibly...

if you promise not to beat me up if you don’t like it you can try it if you like? :thumbsup_anim:
 

if you want a copy then PM me pal and I send you a private copy to try? 

Edited by AudioGod
Link to comment
Share on other sites

@AudioGod Any particular reason you chose the fork instead of stock OC? I got mine running on stock 0.5.4 without major issues.

 

In regard to your setup, if you have a USBMap, you should set USB limit to false. I think there were a few more details to fix but I’ll take a look later. Don’t remember now. 

Link to comment
Share on other sites

2 minutes ago, AudioGod said:

@iStigPL We actually have a new non forked Version of Real OC V055 that’s under test right now that I prefer much much more.

i might even like it more then clover now.....maybe...possibly...

if you promise not to beat me up if you don’t like it you can try it if you like? :thumbsup_anim:

 

relax, I won't hurt you :angel: what I didn't like was not calling somebody buddy, but your opinion "I don’t think you get how the EFI is working".  It seems M0r1d1n did investigation about MemoryAllocation.efi source as it is combination of code from OsxAptioFix2Drv-free2000.efi and OsxAptioFix3Drv.efi.

So few people have noticed such details so your opinion was not fair.

I think you read about OsxAptioFix2Drv-free2000.efi here, so I it would be great to find solution to not have memoryallocation.efi installed. 

I don't have solution for that, but I'd like we try to find it. And finally I didn't mean to offend You. 

 

As far as you last config is concerned:

USBPorts.kext or custom SSDT for USBInjectAll.kext is made to fit in USB port limit, so you don't have to use XhciPortLimit. 

 

XhciPortLimit
Type: plist boolean
Failsafe: false
Description: Patch various kexts (AppleUSBXHCI.kext, AppleUSBXHCIPCI.kext, IOUSBHostFamily.kext) to
remove USB port count limit of 15 ports.
Note: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in
locationID format and there is no possible way to workaround this without heavy OS modification. The only valid
solution is to limit the amount of used ports to 15 (discarding some). More details can be found on AppleLife.ru.

 

Please also take a look at your DSDT.aml file. What I've noticed is there is only DSDT file, without SSDT files. I don't know what was inside them, co maybe it was not important, and you knew that, or maybe it would be better to check that. 

 

* iASL Warning: There were 113 external control methods found during
     * disassembly, but only 102 were resolved (11 unresolved). Additional
     * ACPI tables may be required to properly disassemble the code. This
     * resulting disassembler output file may not compile because the
     * disassembler did not know how many arguments to assign to the
     * unresolved methods. Note: SSDTs can be dynamically loaded at
     * runtime and may or may not be available via the host OS.

 

And finally OC fork. I know people are doing great job, but so many little project were closed in the past and that made me stick with default branch.  

 

 

Link to comment
Share on other sites

14 minutes ago, Morid1n said:

@AudioGod Any particular reason you chose the fork instead of stock OC? I got mine running on stock 0.5.4 without major issues.

 

In regard to your setup, if you have a USBMap, you should set USB limit to false. I think there were a few more details to fix but I’ll take a look later. Don’t remember now. 


im testing real oc 055 now and the reason why I choose to use the forked version was because I hate the way oc loads the dsdt and ssdt when loading into any other os, the forked version bypasses all of that when booting onto windows. 

 

for the usb, i agree with you on that one but that’s about to change too as I now have it done with no port limits via the dsdt that malid0n just did for me with no usb kext needed (just like my clover Efi is)

it’s all under test right now and il update the thread soon. :) 

Link to comment
Share on other sites

3 minutes ago, jake_mike said:

@AudioGod is it possible to have the FileVault enabled in this version? 


yes I believe you can  indeed, somewhere a few pages back on this thread or my z390 pro thread there is somebody explaining how he got it working correctly.

il see if I can find it for you now.

 

Edited by AudioGod
Link to comment
Share on other sites

×
×
  • Create New...