Asus Z690 ProArt Creator WiFi (Thunderbolt 4) + i7-12700K + AMD RX 6800 XT

[CaseySJ]

@CaseySJ I don't know if this is pertinent or not but after the last Ventura update (now i'm on v. 13.6.4) the old problems of the Asus ProArt Z690 have been back:

• System doesn't go to sleep if Aquantia ETH is connected, and
• Front USB-C port goes to disconnection before connecting in stable way.

My system is on BIOS v. 2802 and I had the Aquantia firmware updated already in the past.
Anyone with similar symptoms?

I am posting this from my Asus Z690 ProArt Creator with Sonoma 14.3 connected to a 10GbE network.

• Enter sleep -> works
• Wake from sleep -> works

However, I updated the firmware of on-board Aquantia chip several weeks ago. Current firmware is 1.3.33 as shown:

Regarding front-panel USB-C, unfortunately this port does not work reliably for me either. I just tried connecting a USB 3.2 Gen 2x2 NVMe SSD enclosure, but it wasn't recognized. I connected it instead to one of the Thunderbolt ports on the rear, and it works there.

 

[taylorsyn]

Working with v. 2802 and everything is going perfectly. Not yet tried 3101, sorry. I'm currently under Ventura 13.6.3

Thanks I am thinking the DSDT PCI address tables might of changed, I will investigate this further and report back my findings.

 

[KKTK]

First thing to check:

• System Settings -> Energy Saver -> Wake for Network Access should be disabled

BTW "Wake for Network Access" settings are present only in Monterey.

But my sleep issues are resolved:
In Ventura there are just two: "Enable Power Nap" and "Put hard disks to sleep when possible" and as soon as you check/uncheck any of these settings, Ventura sets hibernatemode to 3. Which is that safe sleep mode which dumps whole MEM to disk. And that safe sleep is not working in Ventura.
So: sudo pmset -a hibernatemode 0 standby 0 autopoweroff 0 is mandatory every time you fiddle inside Energy Saver settings.

 

[m4rk0]

z390 Designare with a Reference AMD 6950xt. All using WhateverGreen.
[..]
On the Designare, I had to spoof the 6950 [..] By doing the spoof through the SSDT (and not OC DP), my System Profiler ALSO shows Metal 3.

Hi SmackAttack,
As I am testing a 6950XT, could you tell me which method did you use to spoof the 6950XT through SSDT? Did you use the one on dortania website? https://dortania.github.io/Getting-Started-With-ACPI/Universal/spoof.html
Could you share your SSDT please? I think I'd just need to modify the ACPI path then.
Thanks

 

[etorix]

There's a whole thread of examples and guidance to read the ACPI and PCI paths from IOReg and/or Device Information.

 

[m4rk0]

There's a whole thread of examples and guidance to read the ACPI and PCI paths from IOReg and/or Device Information.

Hi etorix! Thanks for your reply.
Yes, I know that thread, but in this post in that same thread SmackAttack asked a question which did not find a definitive answer. Fast forward, I knew he posted the reply I quoted above, which is the ‘evolution’ of the question he asked. So I thought to ask for his help as he went through it before..
I’ll put my hands over the weekend on the matter, hope to get it done right.

 

[Azimuth1]

I am posting this from my Asus Z690 ProArt Creator with Sonoma 14.3 connected to a 10GbE network.

• Enter sleep -> works
• Wake from sleep -> works

However, I updated the firmware of on-board Aquantia chip several weeks ago. Current firmware is 1.3.33 as shown:
View attachment 577741
Regarding front-panel USB-C, unfortunately this port does not work reliably for me either. I just tried connecting a USB 3.2 Gen 2x2 NVMe SSD enclosure, but it wasn't recognized. I connected it instead to one of the Thunderbolt ports on the rear, and it works there.

I was on 1.3.33 myself... but, for no reason, I had sleep problems with cable attached. Now I've cleaned and reset the NVRAM and I launched Onyx for rebuilding OS services and things are again OK with AQ-113S: sleep working.

I'm "happy" that @CaseySJ have the same problem with from USB-C port ... I will not consider it anymore and rebuild my USB.kext accordingly.

 

[etorix]

Yes, I know that thread, but in this post in that same thread SmackAttack asked a question which did not find a definitive answer. Fast forward, I knew he posted the reply I quoted above, which is the ‘evolution’ of the question he asked. So I thought to ask for his help as he went through it before.

I've seen reports that spoofing through a SSDT is slightly better, or more "Mac-like", than through Device Properties but does not a finla answer on that (nothing to spoof in my collection).

If you can find a SSDT for the same slot on the same motherboard, great. Otherwise I'm all for learning to do tricks for one's hack.
It's not that difficult: Get the ACPI path to the GPU, by whatever means (from Hackintool or IOReg on macOS—as long as it runs with VESA driver—, from Windows or Linux…). Spot any unnamed PCI bridge along the way and its PCI address, and give the bridge a name (template SSDT-BRG0). And finally add a _DSM method to the GPU, with a package of properties to inject—the device-id spoof, and any cosmetic property you want to inject as well. (Anything goes here, as long as the size of the package matches the number of items, and the size of each buffer fits the injected data; strings need "length+1", due to the terminating NULL character.)

There are plenty of examples in the thread, with many possible situations (zero, one, two unnamed bridges; zero/non-zero addresses; basic spoof, or multiple cosmetic properties) and variants (full DTGP() method, in SSDT or external, or simplified method included in _DSM()).

But if you struggle you may ask for help here and/or in the RX6950 thread.

 

[SmackAttack]

Hi SmackAttack,
As I am testing a 6950XT, could you tell me which method did you use to spoof the 6950XT through SSDT? Did you use the one on dortania website? https://dortania.github.io/Getting-Started-With-ACPI/Universal/spoof.html
Could you share your SSDT please? I think I'd just need to modify the ACPI path then.
Thanks

Pretty sure I used the steps from dortania... but it's been awhile. I'll post the SSDT for ya, no problem, but be advised it was for a Z390 Designare, so if this is on a ProArt, you'll have to double check the patching path.
Further, as stated in the other thread, I've left the OC DP patching commented out, which results in System Profiler reporting the 6950xt as "AMD Radeon Navi21 16GB." HOWEVER, doing it this way results in "Metal 3" displayed in System Profiler/Graphics/Metal Support.
J

 

[racermaster]

I've seen reports that spoofing through a SSDT is slightly better, or more "Mac-like", than through Device Properties but does not a finla answer on that (nothing to spoof in my collection).

If you can find a SSDT for the same slot on the same motherboard, great. Otherwise I'm all for learning to do tricks for one's hack.
It's not that difficult: Get the ACPI path to the GPU, by whatever means (from Hackintool or IOReg on macOS—as long as it runs with VESA driver—, from Windows or Linux…). Spot any unnamed PCI bridge along the way and its PCI address, and give the bridge a name (template SSDT-BRG0). And finally add a _DSM method to the GPU, with a package of properties to inject—the device-id spoof, and any cosmetic property you want to inject as well. (Anything goes here, as long as the size of the package matches the number of items, and the size of each buffer fits the injected data; strings need "length+1", due to the terminating NULL character.)

There are plenty of examples in the thread, with many possible situations (zero, one, two unnamed bridges; zero/non-zero addresses; basic spoof, or multiple cosmetic properties) and variants (full DTGP() method, in SSDT or external, or simplified method included in _DSM()).

But if you struggle you may ask for help here and/or in the RX6950 thread.

ACPI _DSM (note that DTGP is unnecessary) and EFI DPP DB device properties should work fine; both are used on real Macs (the latter is used in EFI drivers). What really matters is the presence of an ACPI device for the PCI bridge (found on RDNA 2 GPUs), as AppleACPIPlatformExpert merges device properties into the IODeviceTree in two stages. The first one occurs much earlier (early enough for Lilu and WhateverGreen), but only applies to defined ACPI devices. Device properties under PCI devices without a corresponding ACPI device are handled in a later stage, which is too late for Lilu and WhateverGreen. This is described in more detail in the OpenCore documentation.