Glasgood's macOS Mojave [SUCCESS][GUIDE] for Aorus Z390 Pro

[AudioGod]

17 minutes ago, gino8080 said:

 

 

You guys think I can go with the new mini update without fear? 

 

Because now my system seems perfect ( just 2 times It gave me blank screens after a wake from sleep, and needed to reboot manually )

so I'm tempted to do this update

But I'm just a bit scared of meesin all  

I just done a full clone with superduper.

 

SHould I go with update?

 

and if YES what's the best way? directly from system update or incremental update?

 

thank youuuu

 

I've done the update on two systems now with no problems. Just make sure all your texts and clover is up to date.

 

I did the update via the normal way in system update 

Edited August 4, 2019 by AudioGod

[gino8080]

29 minutes ago, AudioGod said:

Just make sure all your texts and clover is up to date.

ehmm How to be sure they are all up to date?

 

CLover should be the latest (i downloaded & installed yesterday )

and for the kext I'm using the EFI from the good @glasgood

 

by the way I'm already at 10.14.6

so should be safe to update to this minor build right?

 

Can I go through the system updater?

[AudioGod]

7 minutes ago, gino8080 said:

ehmm How to be sure they are all up to date?

 

CLover should be the latest (i downloaded & installed yesterday )

and for the kext I'm using the EFI from the good @glasgood

 

by the way I'm already at 10.14.6

so should be safe to update to this minor build right?

 

Can I go through the system updater?

Yes go though system updater,

And by the sound of it your ready togo. Don't worry it's a very painless update 

[gino8080]

9 minutes ago, AudioGod said:

Yes go though system updater,

And by the sound of it your ready togo. Don't worry it's a very painless update 

 

Thanks!

And after 10 minutes of fear and 2 reboots..

 

everything seems ok!! for now at least 

 

 

[tasc]

2 hours ago, tasc said:

I'm up and running on new EFI DSDT now, much smoother this time after doing a CMOS reset. Everything seems to be working, sleep, shutdown, etc. However, I do notice a couple ACPI errors in clover boot log, not sure what to make of these:

 

Mald0n generated me a new SSDT patch to fix these. Not sure why I need it and others don't yet, but I've included it here in case you run into these ACPI errors.

SSDT-6-A M I.aml.zip

[AudioGod]

1 hour ago, tasc said:

 

Mald0n generated me a new SSDT patch to fix these. Not sure why I need it and others don't yet, but I've included it here in case you run into these ACPI errors.

SSDT-6-A M I.aml.zip

 

What did he tell you it would resolve?

[larabee]

@AudioGod 

I tried to follow you guys and put the old know EFI back in, failed to boot and I took your advise to reset my BIOS by taking out the battery. Looks like that works too. 

I'll keep playing with it , but for now, I feel really good about the system. The score is higher with the new EFI, my render time is shorter, I'm a happy camper. 

[tasc]

41 minutes ago, AudioGod said:

 

What did he tell you it would resolve?

 

Well it resolves the ACPI errors in the screenshot I posted above, but why I was getting those I'm not sure. I asked him why I needed that patch when others running the same board/bios didn't. Haven't heard back yet, but I'll relay the info when I find out.

[AudioGod]

20 minutes ago, larabee said:

@AudioGod 

I tried to follow you guys and put the old know EFI back in, failed to boot and I took your advise to reset my BIOS by taking out the battery. Looks like that works too. 

I'll keep playing with it , but for now, I feel really good about the system. The score is higher with the new EFI, my render time is shorter, I'm a happy camper. 

 

Overall I'm well happy too but my strange behaviour has returned if I shut down after sleep. I just wish I could fix that and then I would be so happy. Most people wouldn't give a dam but a use sleep alot as I'm always doing a few things at once when I'm home and usually on more then one system. I'm one issue from perfection.

Edited August 5, 2019 by AudioGod

[tasc]

13 minutes ago, AudioGod said:

 

Overall I'm well happy too but my strange behaviour has returned if I shut down after sleep. I just wish I could fix that and then I would be so happy. Most people wouldn't give a dam but a use sleep alot as I'm always doing a few things at once when I'm home and usually on more then one system. I'm one issue from perfection.

 

Argh, thought we were past those issues. I use sleep a lot as well, and I haven't seen any sleep/shutdown issues yet, but maybe it's just a matter of time. I've only been up and running about half a day so far on the new setup.

[AudioGod]

@larabee I know you don't mind so much but if your still having the same problem as me then I have a theory....if I'm not mistaken your z390 pro came with bios f8 out of the box and as it's back up bios. My board is the same revision where as @glasgood z390 pro again if I'm  not mistaken came with bios f5 out of the box and as it's back up bios. It's not impossible that the boards are slightly different or different revisions even to coincide with the stock bios's if that's the case it would explain the different behaviour that I get and glasgood gets and I can put it to the test as system number two that's sitting here waiting for its replacement gpu has f5 as it's out of the box bios so when I test the new efi on that one if it works as it should then theres the problem and the resolve would be for myself or you to extract and patch our own boards dsdt. 

 

As soon as the god dam gpu arrives I can find out!

 

 

11 minutes ago, tasc said:

 

Argh, thought we were past those issues. I use sleep a lot as well, and I haven't seen any sleep/shutdown issues yet, but maybe it's just a matter of time. I've only been up and running about half a day so far on the new setup.

 

So did I my friend but since i got back from work i have been bouncing around between two systems all evening and it's really put mine to the test. 

 

@tascAlso have you been using your new ssdt for as long as the problem has gone away for by any chance?

Could that be connected and yes I am grasping at straws and thinking out aloud...hahaha

Edited August 5, 2019 by AudioGod

[larabee]

4 hours ago, AudioGod said:

@larabee I know you don't mind so much but if your still having the same problem as me then I have a theory....if I'm not mistaken your z390 pro came with bios f8 out of the box and as it's back up bios. My board is the same revision where as @glasgood z390 pro again if I'm  not mistaken came with bios f5 out of the box and as it's back up bios. It's not impossible that the boards are slightly different or different revisions even to coincide with the stock bios's if that's the case it would explain the different behaviour that I get and glasgood gets and I can put it to the test as system number two that's sitting here waiting for its replacement gpu has f5 as it's out of the box bios so when I test the new efi on that one if it works as it should then theres the problem and the resolve would be for myself or you to extract and patch our own boards dsdt. 

 

As soon as the god dam gpu arrives I can find out!

 

 

Good luck with that buddy. Hope you find out the root cause. Let me know if you need me to do anything  

Right now I'm testing the OPENGL performance and notice the same behavior as yours where I can get a whole lot more performance with Glasgood new EFI. I completely disable sleep on my hack to avoid the problem with deep sleep and shutdown. 

[tasc]

4 hours ago, AudioGod said:

 

@tascAlso have you been using your new ssdt for as long as the problem has gone away for by any chance?

Could that be connected and yes I am grasping at straws and thinking out aloud...hahaha

 

@AudioGod I don't think the new ssdt has anything to do with fixing the sleep/shutdown issues. I only had those before I got my bios totally cleared out. Even without the new ssdt, I was able to sleep and shutdown/restart without issue (but I only tested a few times). The ssdt just cleaned up some ACPI errors that I'm not sure were much of an issue or not. The one thing that is strange is why I'm getting those and nobody else is. Mald0n responded to what that SSDT he made for me does: "Is a oem ssdt usb, u can edit this ssdt for a real native usb"

 

@glasgood I noticed in the new DSDT clover config that you turned off USB inject/FixOwnership and don't inject audio or resetHDA. When mald0n generated me an EFI and clover config, he had those checked on. I also see you may be doing the audio layout/device with properties (below). Any reason you chose to do it like this instead of letting clover handle it? That's really the only main difference I see in your config and the one he gave me.

 

Edited August 5, 2019 by tasc

[glasgood]

1 hour ago, tasc said:

 

@AudioGod I don't think the new ssdt has anything to do with fixing the sleep/shutdown issues. I only had those before I got my bios totally cleared out. Even without the new ssdt, I was able to sleep and shutdown/restart without issue (but I only tested a few times). The ssdt just cleaned up some ACPI errors that I'm not sure were much of an issue or not. The one thing that is strange is why I'm getting those and nobody else is. Mald0n responded to what that SSDT he made for me does: "Is a oem ssdt usb, u can edit this ssdt for a real native usb"

 

@glasgood I noticed in the new DSDT clover config that you turned off USB inject/FixOwnership and don't inject audio or resetHDA. When mald0n generated me an EFI and clover config, he had those checked on. I also see you may be doing the audio layout/device with properties (below). Any reason you chose to do it like this instead of letting clover handle it? That's really the only main difference I see in your config and the one he gave me.

 

 

 

Both achieve the same results, but as far as I know Device / Audio / Inject is legacy method. Developers are working on an alternative/ possible replacement for Clover named OC, in OC is seems that device ID's are injected via Device Properties via OC's config.plist ( unless defined within an SSDT or DSDT ). I assume it might be the preferred way for the Lilu patching engine, AppleALC is a plugin to the Lilu patching engine.  So my preferred way is via injection in Device Properties,

 

So Injecting Audio layout ID via devices Properties, is also the same alternative method used for Injecting CPU ig-platform-id,  framebuffers.    

 

You will notice that CPU  ig-platform-id is now rarely injected via Graphics and is specified within Devices Properties.

 

 

 

 

 

And the preferred method is injecting Properties Key information via Devices / Properties, 

 

 

 

 

This Properties Key Info is exactly what you would find inside a SSDT / DSDT ( maybe from an ACPI side, it's a more efficient way of providing device information )

 

 

 

 

Device Info Injected via config.plist in OC

 

 

 

 

 

 

 

 

 

 

 

Edited August 5, 2019 by glasgood

[soniferous_fox]

On 8/3/2019 at 1:20 PM, glasgood said:

I was reading that Japura is framebuffer used on the iMac Pro.  wonder if it would work for you guys!

 

------------------------AMD10000Controller.kext-------------------------



Kamarang (4) @ 0x5ed30
DP, DP, DP, HDMI
000400000403000000010101000000002205020200000000
000400000403000000010201000000001204010100000000
000400000403000000010300000000001000050500000000
000800000402000000010400000000002001060600000000



Japura (6) @ 0x611a0
LVDS, LVDS, DP, DP, DP, DP
020000000001000008010151220000002205020200000000
020000000001000008010261120000001204010100000000
000400000001000000010313400000002001050600000000
000400000001000000010423300000001000060500000000
000400000001000000010543600000001102030300000000
000400000001000000010633500000002103040400000000




Iriri (4) @ 0x6f730
DP, DP, DP, HDMI
000400000403000000010101000000002205020200000000
000400000403000000010201000000001204010100000000
000400000403000000010300000000001000050500000000
000800000402000000010400000000002001060600000000




-------------------------AMD9500Controller.kext-------------------------

Orinoco (5) @ 0x6ef30
DP, DP, HDMI, HDMI, DVI-D
000400000403000000010101000000001204060100000000
000400000403000000010201000000002205040300000000
000800000402000000010300000000001102010200000000
000800000402000000010400000000002103050400000000
040000000400000000010500000000000000030600000000


Acre (3) @ 0x6f360
DP, HDMI, DVI-D
000400000403000000010101000000001102020100000000
000800000402000000010200000000002103050400000000
040000000402000000010300000000000000030500000000


 

 

@glasgood Hi. Just out of interest, where does this info come from? I notice that for Orinoco it says DP, DP, HDMI, HDMI, DVI-D, and wondered if that was something to do with my 3rd DP port not working when using Orinoco.

 

Thanks.

[hackinbot]

20 hours ago, ilcondannato said:

Definitely... I will try now.

I'm on Sapphire RX580 8gb Nitro+

BUT

on slot 1 I've flash sapphire special edition (blue version) and on slot 2, the limited ed. (Gray version) ...but...think this 2 bios, only modify clock...so...

Nitro+ work in all ports!!!

 

DP 1 work

DP 2 work

HDMI 1 work

HDMI 2 work

DVI-D work

 

All working GOOD

(from start pc to up and running osx Catalina) ...I think Mojave it's ok too

 

Ok, thanks for confirming that all ports work for you. I guess there's something strange with my 4GB Nitro+ version then. Oh well.

 

I'm using "EFI NON DSDT SMBIOS iMac Pro 1,1" updated with Clover r5033 for now. I couldn't get a stable boot with the DSDT EFI & FileVault 2 enabled. FileVault is a requirement for my workstation.

 

So far so good (other than only 2 DP working). The system appears stable.

[glasgood]

1 hour ago, soniferous_fox said:

 

@glasgood Hi. Just out of interest, where does this info come from? I notice that for Orinoco it says DP, DP, HDMI, HDMI, DVI-D, and wondered if that was something to do with my 3rd DP port not working when using Orinoco.

 

Thanks.

 

From AMD9500Controller.kext and can be found in System/Library/Extensions. 

[D3v1L]

37 minutes ago, hackinbot said:

 

Ok, thanks for confirming that all ports work for you. I guess there's something strange with my 4GB Nitro+ version then. Oh well.

 

I'm using "EFI NON DSDT SMBIOS iMac Pro 1,1" updated with Clover r5033 for now. I couldn't get a stable boot with the DSDT EFI & FileVault 2 enabled. FileVault is a requirement for my workstation.

 

So far so good (other than only 2 DP working). The system appears stable.

 

 

Uhm...think some problem with framebuffer....uhm what fb U use? (btw I'm on Orinoco and it works well)

I say this 'cause, if you don't use DSDT efi, maybe you are on other FB ....only my suppouse so... 

 

...my sleep problem , solved...Is a {censored} 2.4ghz USB key (mouse) ...just remove from mb port and insert on lateral keyboard port...and voilà..all working great! 

(on 10.15.b5 Catalina!) 

 

[D3v1L]

...ok just speak too fast...now sleep working...but when wake...some usb3 didn't work...my 2 external hdd stop working...need to disconnect and reconnect...uhm...just "investigation mode on" 

 

 

[tasc]

9 hours ago, glasgood said:

 

Both achieve the same results, but as far as I know Device / Audio / Inject is legacy method. Developers are working on an alternative/ possible replacement for Clover named OC, in OC is seems that device ID's are injected via Device Properties via OC's config.plist ( unless defined within an SSDT or DSDT ). I assume it might be the preferred way for the Lilu patching engine, AppleALC is a plugin to the Lilu patching engine.  So my preferred way is via injection in Device Properties,

 

Interesting, thank you for that thorough explanation. I'm learning a bit more every day messing around with this stuff.

[AudioGod]

@glasgood did you ever look into and Unlock the 0xE2 MSR register on your board?

 

I've eneded up reverting back to the old EFI now as until I can find a resolve for the cold boot after wake from sleep problem i cant be risking my system from a disaster. I'm gutted because I'm loving the way the new EFI works but i have to go with fully stable over problematic.

[tasc]

@glasgood Mald0n also generated a DSDT for my build, and I'm curious if it is any different than the one you were given (aside from cosmetic PCI names). Would be interesting to know how these differ given we are both running the same board with same bios. Maybe any differences could shed some light on why others like @AudioGod are having issues - or why I need that custom SSDT to fix my ACPI errors.

 

Not sure how easy it is to spot differences in DSDT files, but I don't think I have the knowledge to do that yet

 

tasc-DSDT.aml

[AudioGod]

33 minutes ago, tasc said:

@glasgood Mald0n also generated a DSDT for my build, and I'm curious if it is any different than the one you were given (aside from cosmetic PCI names). Would be interesting to know how these differ given we are both running the same board with same bios. Maybe any differences could shed some light on why others like @AudioGod are having issues - or why I need that custom SSDT to fix my ACPI errors.

 

Not sure how easy it is to spot differences in DSDT files, but I don't think I have the knowledge to do that yet

 

tasc-DSDT.aml

Il give it a in a moment buddy to see if it has and different effect to my system. Should I try it with your ssdt too?

[tasc]

1 hour ago, AudioGod said:

Il give it a in a moment buddy to see if it has and different effect to my system. Should I try it with your ssdt too?

 

I went ahead and disassembled both of our DSDTs to see if the differences would be easy to spot, and actually they are fairly easy to see when using a diff tool. I can see glasgood has the broadcom wireless adapter in his, while I do not use any wireless card. It looks like mald0n renamed my SAT0 to SATA and GIGE to GLAN, but those are patched in clover anyways so should result in the same thing.

 

There's only a couple other areas that differ - I can see where glasgood added in the EC power patch and the wake patch, and I have an additional display section probably due to my nvidia card in slot 2. Other than that there a just a few discrepancies:

 

(-) lines are my DSDT, (+) lines are glasgood DSDT

+    External (UMAP, IntObj)    // (from opcode)

-    OperationRegion (GNVS, SystemMemory, 0x3936E000, 0x0866)
+    OperationRegion (GNVS, SystemMemory, 0x3E484000, 0x0866)

-    Name (PNVB, 0x39421B98)
+    Name (PNVB, 0x3E557B98)

-    OperationRegion (BNVS, SystemMemory, 0x393DA000, 0x43)
+    OperationRegion (BNVS, SystemMemory, 0x3E4F0000, 0x43)

I don't think using my DSDT will make a big difference. In fact that SSDT patch that mald0n gave me only works when I use glasgood's DSDT, so that's what I'm using.

Edited August 5, 2019 by tasc

[AudioGod]

21 minutes ago, tasc said:

 

I went ahead and disassembled both of our DSDTs to see if the differences would be easy to spot, and actually they are fairly easy to see when using a diff tool. I can see glasgood has the broadcom wireless adapter in his, while I do not use any wireless card. It looks like mald0n renamed my SAT0 to SATA and GIGE to GLAN, but those are patched in clover anyways so should result in the same thing.

 

There's only a couple other areas that differ - I can see where glasgood added in the EC power patch and the wake patch, and I have an additional display section probably due to my nvidia card in slot 2. Other than that there a just a few discrepancies:

 

(-) lines are my DSDT, (+) lines are glasgood DSDT

-DefinitionBlock ("", "DSDT", 2, "ALASKA", "Olarila", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "ALASKA", "GlasGood", 0x01072009)

+    External (UMAP, IntObj)    // (from opcode)

-    OperationRegion (GNVS, SystemMemory, 0x3936E000, 0x0866)
+    OperationRegion (GNVS, SystemMemory, 0x3E484000, 0x0866)

-    Name (PNVB, 0x39421B98)
+    Name (PNVB, 0x3E557B98)

-    OperationRegion (BNVS, SystemMemory, 0x393DA000, 0x43)
+    OperationRegion (BNVS, SystemMemory, 0x3E4F0000, 0x43)

I don't think using my DSDT will make a big difference. In fact that SSDT patch that mald0n gave me only works when I use glasgood's DSDT, so that's what I'm using.

 

I gave it a shot anyway as it's good to have a b sample and sure enough I'm getting exactly the same problems with your dsdt.

Do you remember what bios came with your board out of the box?

Was it F5 or F8?

 

Maybe the person that did your dsdt can shed some light on my problem for me.

What's hes name and where do I find him buddy?