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

[saCULar]

Running Monterey 21A559 installed via software update from RC1.  Both RC1 and the release boot *very slowly (2min 45sec to login screen) compared to Big Sur (43 sec to login screen) on another partition. Am using opencore 0.7.4 AudioGod EFI.

The biggest hold up following the appearance of boot up sequence beginning:

ALUC:clientDIed(PID: 468), entitled 1

ALUC:init(PID:482)

methodSetClientDomain entered

registerNotificationPort entered

ALUC:clientDied(PID:482), entitled 1

ALUC:init(PID:483)

methodSetClientDomain entered

registerNotificationPort entered

etc....

 

This boot issue is consistent after multiple reboots.

 

Any ideas welcome.  Once the machine logs in though it is very snappy.

 

PS just checked the activity monitor and the next PID:484 is still active and is associated with the process cfprefsd

Edited October 26, 2021 by saCULar
adding some missing information

[n19htz]

37 minutes ago, saCULar said:

Running Monterey 21A559 installed via software update from RC1.  Both RC1 and the release boot *very slowly (2min 45sec to login screen) compared to Big Sur (43 sec to login screen) on another partition. Am using opencore 0.7.4 AudioGod EFI.

The biggest hold up following the appearance of boot up sequence beginning:

ALUC:clientDIed(PID: 468), entitled 1

ALUC:init(PID:482)

methodSetClientDomain entered

registerNotificationPort entered

ALUC:clientDied(PID:482), entitled 1

ALUC:init(PID:483)

methodSetClientDomain entered

registerNotificationPort entered

etc....

 

This boot issue is consistent after multiple reboots.

 

Any ideas welcome.  Once the machine logs in though it is very snappy.

 

PS just checked the activity monitor and the next PID:484 is still active and is associated with the process cfprefsd

I got the same slow boot 0.7.4 OC, pretty annoying

[laxattack]

Has anyone had an issue trying to run the Monterey update? If I run it through the software update, it runs the app, has me restart, boots to a new Macintosh HD partition, reboots, goes back to my normal install, and never completes the update (still on 11.6.1)

[Cipha]

I just finished the update via System Update. Smooth like a fat kid on a waterslide... 

 

I just discovered OCAT. Is there anything wrong with using a tool like this?

https://github.com/ic005k/QtOpenCoreConfig

 

Made updating OC and Kexts so easy, there must be a hook?

[laxattack]

Running into a message of "a required firmware update could not be installed" when trying to update to Monterey. Anyone have any suggestions? I have tried different 1,1 and 19,1 setups with no change

[rob1980]

@AudioGod I'm not sure if you saw my other post the other day regarding the CNVI wifi?

 

Anyway, the card wasn't recognized at all by the computer (tried windows and Mac) and I'm still finding bits of info on different forums regarding gigabyte and locked CNVI however yours worked on the Master... 

I'm not sure if its just because mine is the Pro and not master, if its region related (doubtful) or something else.. 

 

Do you know if something like this lock could be removed with a bios mod?

 

Anyone else looking to get the BCM94360NG for the pro wifi, I'd perhaps hold off for a minute unless you're happy to be another test dummy  

 

 

[pkdesign]

On 10/26/2021 at 5:35 AM, n19htz said:

I got the same slow boot 0.7.4 OC, pretty annoying

I updated my Dell laptop and it seems to be booting faster. Will hopefully update my main machine soon so I can compare.

[AudioGod]

Message to everybody.
The other day I had a disaster at home and had a huge power surge that took out half the electronics in my house including my Computer, So many parts got burnt out that I am now totally out of action until further notice and will be unable to update the thread EFIs for a little while until I replace most the inners of my PC.
Sorry to be the bearer of bad news all but it’s to much money and to close to Christmas for me to sort out quickly so for now this is me signing out but I will return and continue trying to make things better for all as best as I can.
So sorry all but this one is out of my control.
Big Love
AG

[dsynos80]

Ah man, terrible news. You've been a huge help to everybody through your efforts! Big damage but its all material, health is above all so be safe and you'll be back. I am sure ppl here will keep the thread alive. Cheers to a fast return.

[i0ntempest]

Big F to AudioGos's computer.

Also right now I'm on Monterey using this EFI (modified a bit) on a Aorus Pro and I'm getting very slow boots as well. Upon researching this might be related to some kexts timing out or might be some audio problem. I'll need to investigate further, any help and tips are appreciated.

[rob1980]

@AudioGod do you know what caused the surge? We’re the power company carrying out any work in the area on the day etc?

 

These things don’t just normally happen and there’s often somebody to blame, pm me if you need any help in that area.

 

good luck getting things all up and running again.

 

 

[AudioGod]

12 minutes ago, rob1980 said:

@AudioGod do you know what caused the surge? We’re the power company carrying out any work in the area on the day etc?

 

These things don’t just normally happen and there’s often somebody to blame, pm me if you need any help in that area.

 

good luck getting things all up and running again.

 

 

Well from what I can tell it was the huge boiler on the roof that supplies hot water to the whole block I live in. It exploded but the landlord is claiming the surge caused it to blow.

I’m not the only person in my block that got fried either, Everybody was effected.

As my block is full of rich posh gits (not including me) they are up in arms threatening to landlord unless they compensate so we shall see what happens but I’ve lived here for long enough to know they will deny it and lie to cover themselves so again we shall see.

All good bud and thanks for the offer anyway.

It could of been worst as somebody could of been badly hurt. 

Edited October 27, 2021 by AudioGod

[panosru]

I just updated to Monterey, and so far I see that my bluetooth dongle (ASUS BT-400) isn't recognised 😕 😕 it was working just fine with Big Sur and Mojave 😕, I also tried BlueToolFixup.kext but still, it didn't worked 😕  

 

@AudioGod terrible new mate... I hope you'll be able to recover soon!

Edited October 27, 2021 by panosru

[Alex1982]

12 hours ago, panosru said:

I just updated to Monterey, and so far I see that my bluetooth dongle (ASUS BT-400) isn't recognised 😕 😕 it was working just fine with Big Sur and Mojave 😕, I also tried BlueToolFixup.kext but still, it didn't worked 😕  

 

@AudioGod terrible new mate... I hope you'll be able to recover soon!

I also faced the same issue with my BT-400 after update to Monterey. The BlueToolFixup.kext worked for me after I removed all Brcm* kexts (BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, BrcmPatchRAM3.kext)

[panosru]

@Alex1982 thanks for letting me know that it works for you! There is a hope after all! But in my case, I only have AirportBrcmFixup.kext, I'm not using any other Brcm* kexts, I will try removing the AirportBrcmFixup.kext and see what will happen, without it my WiFi won't work, but I want to make sure that it isn't interfering with BlueToolFixup kext.

 

UPDATE:

Nope, AirportBrcm wasn't the issue, strange though, for some reason the BlueToolFixup isn't working for me, but on Reddit I also see that it isn't working for others as well. I guess I'll have to stick with my gaming mouse for now until I find a fix for it or a usb dongle that is compatible with Slowterey, I meant to say, Monterey 😜 I also noticed that now without the AirportBrcm my WiFi still works just fine, and location services as well, I guess you win some you lose some... 

 

UPDATE2:

I found that the github repo does not have the v2.6.1 release yet, you can download it from here, once you download it and add only the BlueToolFixup kext (also register it in OC), then you reboot and the Bluetooth works again. For me, for some reason it didn't work right away, but after I run sudo kill -9 $(pgrep bluetoothd) it worked fine! Also, this command works in case you turn off your bluetooth, since so far you cannot turn it back on via the interface, I guess that will be fixed in later updates of the kext.

 

Thanks @Alex1982 for letting me know that the kext worked for you, otherwise I might look in other places and lose time  

Edited October 28, 2021 by panosru

[laxattack]

On 10/26/2021 at 10:58 PM, laxattack said:

Running into a message of "a required firmware update could not be installed" when trying to update to Monterey. Anyone have any suggestions? I have tried different 1,1 and 19,1 setups with no change

Apparently something was messed up in my BIOS, I had to clear CMOS and re-set everything up (and upgraded to a 1TB SSD) Finally got Monterey up and Running though!
!
 

19 hours ago, AudioGod said:

Message to everybody.
The other day I had a disaster at home and had a huge power surge that took out half the electronics in my house including my Computer, So many parts got burnt out that I am now totally out of action until further notice and will be unable to update the thread EFIs for a little while until I replace most the inners of my PC.
Sorry to be the bearer of bad news all but it’s to much money and to close to Christmas for me to sort out quickly so for now this is me signing out but I will return and continue trying to make things better for all as best as I can.
So sorry all but this one is out of my control.
Big Love
AG

That is a huge bummer @AudioGod, I wish you were in the US, I would send you some extra PC parts to help get you back up and running. Good luck, I hope you get back up and running soon!

[panosru]

On 10/18/2021 at 11:53 PM, texem said:

Another way ( but not click and go  ) is not using any USBPorts kext etc for mapping anymore.

 

I modified SSDT-6 from ACPI to enable / disable and description of ports for use or not by OpenCore ( max 15 are enabled for "Darwin" )

OC ACPI -> delete orig SSDT-6  

OC ACPI -> add modified  SSDT-6

 

"usbinjectall" or other port-mapping tools and kext's are obsolete .

 

btw: dump ACPI via IASL to find HSXX and SSXX port definitions in SSDT-6 on z390pro .

 

 

Is there any advantage in terms of performance and stability compared to usbmap kext?

[texem]

no

 

[panosru]

@texem thanks for the clarification! I thought that it would perform better, but, in any case, I'll poke around with it a bit, if I manage to make it work I might stick with it instead of the kext file  

[pkdesign]

The SSDT that texem provided works perfectly for me! Exactly the same USB ports that AudioGod's USBMap.kext provided.

 

Glad that you asked the question to texem, I was wondering the same thing. But I'll stay with his SSDT for now

8 hours ago, Alex1982 said:

I also faced the same issue with my BT-400 after update to Monterey. The BlueToolFixup.kext worked for me after I removed all Brcm* kexts (BrcmBluetoothInjector.kext, BrcmFirmwareData.kext, BrcmPatchRAM3.kext)

I believe you only need to delete the BrcmBluetoothInjector.kext not the others. That worked for my Dell Laptop. but that has a Dell DW1560 card in it.

Edited October 28, 2021 by pkdesign

[texem]

yes, what should i write else, there is no advantage other than making kext's obsolete 😉

 

So if you change your system model ( f.i from imacpro 1,1 to imac19,1  ) you don't need a new USBMap.kext ..

 

cheers

 

 

Edited October 28, 2021 by texem

[Cipha]

For those of you with Bluetooth problems, there's a bluetoolfix.kext nightly update (2.6.1) that fixed it for me partially on the Mac mini Hackintosh. Still no Airdrop is not working well and no Hands-off, but at least BT is activated again.

[panosru]

For me the kext file is easy to edit, I just edit the Info.plist of the kext and apply any modifications I need, for instance, my Info.plist file looks like this. And I'll apply some more modifications because I'm planning to re-arrange a few things so I might need to do some changes. Having said that, like @pkdesign, I too would like to make the kext file obsolete, no matter that I won't gain any more stability, I already use SSDT-GPRW because I prefer to wake up my computer via the power button and not in any other way, and, for some reason, it feels more "native" using aml files instead of kext files (I understand that might be irrelevant, but to me it feels that way).

 

@pkdesign, so you basically took what @texem posted here and you just applied it? Meaning, you copied the SSDT-6.aml file in ACPI/, then you deleted the USBMap.kext file from Kexts/, you removed the USBMap.kext record from Kernel -> Add in your config.plist, then you applied the patch described in @texem's txt and it worked for you, right? I'm a bit confused with a couple of things, did you replaced the table length value? If I open SSDT-6.aml file with MaciASL, the length I'm getting, as described by @antuneddu in the rtfd file he uploaded, is 10769, @texem's txt shows 11547. From what I understand, I should place 10769 in table length, correct?

 

Also, I'm confused a bit with @antuneddu post, after reading the italian guide (thanks to Google translate) he posted, I got the impression that you use SSDT-6.aml as base file, and you generate another aml file with the patches you need, I guess that is the SSDT-xh_rvp08.aml that I'm seeing in the rtfd file posted by @antuneddu, in case of @texem, the patches are applied directly on the SSDT-6.aml file, therefore we don't need to generate any new aml files, correct?

 

Last question, lets say that you want to apply some modifications, you just open the SSDT-6.aml file with MaciASL, modify the file according to your needs, save, update table length in OC config in case it was changed because of the modifications, reboot, and you are good to go?

 

I program in various programming languages, so I'm fine with coding, but since I'm not familiar with aml, I just want to make sure the following:

 

_UPC indicates the port capabilities and the _PLD the physical location of the device, meaning that in first clause you return Return (GUPC (Zero, Zero)) if you want to disable the port, otherwise you leave it as is, same applies for _PLD, also, in case you want to enable a port you have to return the proper hex value for it to work, the value can be found via IORegistryExplorer, am I correct? Also, the modifications should be applied inside the H1TC == Zero condition block, if it is inside an ElseIf clause, otherwise in Else clause, we ignore other conditions like _OSI ("Darwin") completely?

 

For example, I'm not using SS06 at all (rear USB-3 Type-c port), so the current code in SSDT-6.aml looks like this:

Scope (\_SB.PCI0.XHC.RHUB.SS06)
{
    Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
    {
        If ((S6TC == Zero))
        {
            If (((UMP3 & 0x20) == 0x20))
            {
                Return (GUPC (One))
            }
            Else
            {
                Return (GUPC (Zero))
            }
        }
        Else
        {
            Return (\_SB.UBTC.RUCC (S6CR, One))
        }
    }

    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
    {
        If ((S6TC == Zero))
        {
            If (((UMP3 & 0x20) == 0x20))
            {
                Return (GPLD (One, 0x06))
            }
            Else
            {
                Return (GPLD (Zero, 0x06))
            }
        }
        Else
        {
            Return (\_SB.UBTC.RUCC (S6CR, 0x02))
        }
    }
}

 

So, since I want to disable that port (to make space for others), the following modifications are sufficient, correct?

Scope (\_SB.PCI0.XHC.RHUB.SS06)
{
    Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
    {
        Return (GUPC (Zero))
    }

    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
    {
        Return (GPLD (Zero, 0x06))
    }
}

 

The USB ports are the following (taken from @glasgood post)

 

 

 

If you have USBC on Computer Chassis / Case, then SS01 and SS02 is mapped to that USB C port 

 

Thanks!

 

UPDATE:

So I installed the SSDT-6.aml file that @texem uploaded, I applied the necessary patches in OC, removed the USBMap.kext from EFI and from OC config, I applied the modifications I needed on SSDT-6.aml via MaciASL, saved everything, rebooted, and my external hard drives are not shown, also, hackintool shows that the SS06 port is still enabled, and basically, all the ports are enabled, maybe instead of returning zero I have just to completely comment out the whole port block?

 

With USBMap.kext:

 

With SSDT-6.aml:

Edited October 29, 2021 by panosru

[Anto65]

Spoiler

Also, I'm confused a bit with @antuneddu post, after reading the italian guide (thanks to Google translate) he posted, I got the impression that you use SSDT-6.aml as base file, and you generate another aml file with the patches you need, I guess that is the SSDT-xh_rvp08.aml that I'm seeing in the rtfd file posted by @antuneddu

Yassu 🙂  @panosru   I use my acpi oem extracted with OC SysReport (or via Clover f4) which is SSDT-3-xh_rvp08.aml (related to usb, the table length is 2592) after which the patch I mentioned has been applied, but on the same original SSDT. It is clear that you have to extract your Oem ACPIs and they will never be the same as mine or @texem's either as table length or otherwise, they are unique. Unless you have the same exact machine as @texeme you can use its SSDT as in the case of @pkdesign (lucky I would say 😏 ) after you apply the method  @gengik84  I mentioned or that of @texeme

[panosru]

@antuneddu Yassu!! What I noticed is that every time I'm applying a modification in SSDT-6, the length that is mentioned at the header of the file is changed, basically from what I understand it works like a hash of some sort, therefore it fluctuates upon alterations. After I disabled the ports I don't need by putting Return (GUPC (Zero, Zero)), I'm copying the new length and I paste it inside the OC config, but so far, Hackintool is showing all the ports of my machine, but as you can see from the screenshots I posted, half of my devices are not recognised (I notice that all my USB3 devices are not recognised).

 

I have the feeling that I'm messing up the oem acpi, I might need to get it via UEFI shell... If not, I'm attaching here my OC config and my SSDT-6.aml file, just in case I messed something up, maybe you or someone else could take a quick look and I would really prefer to be informed of what should I correct so I will do it myself instead of getting a fixed file

 

Thanks a lot!

 

UPDATE:

I dumped DSDT from UEFI shell, and I saw that the table length is set to 265165, I changed the value in OC config and I will reboot one last time before I go to bed because it is already 05:22 and I need some sleep. Also, why the fck it takes 6 minutes and 27 seconds to boot into Monterey? W T F ?! I kind of regret that I upgraded, I should've stayed with Bug Sur.

 

UPDATE2:

Good morning, once I set the value to 265165 I wasn't getting anything on my monitors, but eventually, after about ~10 minutes it booted into the OS, but the issue remained as it was, meaning that I might doing something wrong with the SSDT-6 file and for some reason it is not recognised I guess.

SSDT-6.aml config.plist

Edited October 29, 2021 by panosru