Asus ProArt z790 - BIOS updates!

[Sabzz]

Not an usb issue, it was the power managment from the oneboard intel nic.
The leds of the plug were still on after shut down, disabled in widnows then all good.
Sleep work after AQC113 firmware upate.
With the V2 SSDt from CaseySJ, TB hotplug work great even after sleep !

Great to hear!

Did you update BIOS incrementally or jumped a few versions?
What TB device are you hot-plugging? An AUDIO interface, monitor or...?

I'm considering updating just unsure if i can skip a few versions, or update one after the other. I also need to ensure my TB3 UAD Apollo Twin X works after the update as its a crucial part of my workflow.

Thanks

 

[vincerutabaga]

Great to hear!

Did you update BIOS incrementally or jumped a few versions?
What TB device are you hot-plugging? An AUDIO interface, monitor or...?

I'm considering updating just unsure if i can skip a few versions, or update one after the other. I also need to ensure my TB3 UAD Apollo Twin X works after the update as its a crucial part of my workflow.

Thanks

I did go straight for the last bios, not many version jumped, don't really remember ....

I hotplug (or boot with it) a sonnet Pcie extension over TB3, it got the JHL6540 alpine ridge controller.
Inside I have an UAD2 octo pcie card.

Tried older TB2 devices (like apple TB2 RJ45 with TB2 to TB3) it don't work. But with this board I don't need it anymore.
The AQC113 don't really work for realtime audio over ethernet, but the intel Nic is good.

 

[SmackAttack]

Heads-up:

For some unknown reason, I decided to update to the highest level BIOS (1801) today (from 1303).

Mac OS refused to boot (either from alternate OC EFIs, or OS backups) and it wasn't until I Disabled IOMMU in Advanced/System Agent(SA) Configuration that it worked. Pretty sure I've never had to disable that in the past.

FWIW,
j

 

[m4rk0]

Mac OS refused to boot (either from alternate OC EFIs, or OS backups) and it wasn't until I Disabled IOMMU in Advanced/System Agent(SA) Configuration that it worked.

That's the same exact setting I flipped in this post [which I edited afterwards, seeing it did not help] but it turned out not to be the right solution. It was more of a coincidence.
You can enable IOMMU back and:

• add slide=0 boot-arg as indicated here by the excellent @racermaster

That one alone should fix it, as it did in my case. However, while you are at it, why not disable CFG lock ?! (again, see post mentioned above)
Keep in mind that to disable CFG-Lock:

• you'll need to disable BIOS setting "Protect UEFI Variables"
• resetting NVRAM clears CFG-Lock

After those two, I never ever had any issue when booting macOS on BIOS 1501 first, 1801 later. Issues which I had previously.

 

[SmackAttack]

After those two, I never ever had any issue when booting macOS on BIOSes 1501 first, 1801 later. Issues which I had previously.

Curious.
I’ll look into this when I’m back on the machine tomorrow and report back.
Thanks!
J

 

[SmackAttack]

@m4rk0 ;

Okay, simply adding slide=0 restores bootability with IOMMU reenabled.

HOWEVER;
I'd like some guidance or your comment about CFG-Lock.

First, running "ControlMsrE2" through open canopy, I can confirm my system has a locked MSR register.

Second, including an Argument of "unlock" to the ControlMsrE2.efi does nothing... it remains locked, and yeah, I disabled UEFI protections in bios. Changing the Argument to "interactive" just crashes ControlMsrE2 (as others have reported).

Third, I ran through the old-school CFG Lock stuff dortania, and although I employed this method long ago, alas, the procedure seems to no longer work with the ASUS bios file, in that when one extracts a bin file to edit in a text editor to determine the correct string, it's no where to be found. SOOO..... your postings with @racermaster have me very confused, because he seems to have come up with a string which, traditionally you'd enter into a modGRUBShell, but that string a) doesn't align with the procedure on dortania, and b) how did he come up with that?

So in summary, how did YOU disable cfg-lock?

 

[m4rk0]

Okay, simply adding slide=0 restores bootability with IOMMU reenabled.

Yes. But not only that. Disabling IOMMU would have worked just temporarily. As I wrote, I disabled it, system booted, but after a few power cycles it did not boot anymore. So that wasn't the right solution.

b) how did he come up with that?

I have no clue! That's why I commented saying "Wow it works! How you guys keep updated with all of these findings is beyond me." in the post I referenced above.

So in summary, how did YOU disable cfg-lock?

• download setup_var.efi from this GitHub page
• add it to your EFI/OC/Tools folder, enable it using OpenCore Configurator under Misc / Tools, save config.plist
• reboot
• at OC picker choose OpenShell and move to Tools folder following the path above: EFI/OC/Tools
• type setup_var.efi -n CpuSetup 0x44 0x0
• reboot
• verify your CFG-Lock setting being disabled using ControlMsrE2.efi

Let me know.

PS I thought to include a little guide in the first page of CaseySJ's Z690 ProArt Creator thread, I'll try to write a couple of lines over the weekend.

 

[SmackAttack]

Yes. But not only that. Disabling IOMMU would have worked just temporarily. As I wrote, I disabled it, system booted, but after a few power cycles it did not boot anymore. So that wasn't the right solution.


I have no clue! That's why I commented saying "Wow it works! How you guys keep updated with all of these findings is beyond me." in the post I referenced above.

• download setup_var.efi from this GitHub page
• add it to your EFI/OC/Tools folder, enable it using OpenCore Configurator under Misc / Tools, save config.plist
• reboot
• at OC picker choose OpenShell and move to Tools folder following the path above: EFI/OC/Tools
• type setup_var.efi -n CpuSetup 0x44 0x0
• reboot
• verify your CFG-Lock setting being disabled using ControlMsrE2.efi

Let me know.

PS I thought to include a little guide in the first page of CaseySJ's Z690 ProArt Creator thread, I'll try to write a couple of lines over the weekend.

Ok, whelp, according to the flakey ControlMsrE2.efi, I now have CFG Lock unlocked... thanks for your help. I'm going to have to dive deep to discover how that CpuSetup string got discovered.

 

[racermaster]

Heads-up:

For some unknown reason, I decided to update to the highest level BIOS (1801) today (from 1303).

Mac OS refused to boot (either from alternate OC EFIs, or OS backups) and it wasn't until I Disabled IOMMU in Advanced/System Agent(SA) Configuration that it worked. Pretty sure I've never had to disable that in the past.

FWIW,
j

I haven't tried disabling the IOMMU. In my case I ran into boot failures with certain slides. One thing to note is that OC reports fewer usable slides with BIOS versions newer than 1303 (which had 256 usable slides):

16:628 00:000 OCABC: Only 50/256 slide values are usable!
16:629 00:000 OCABC: Valid slides - 0-49

However, not all of these slides are valid. There seems to be a hole somewhere in the middle of this range (XNU fails to start with slide=26, for example), even though the memory map says it should be usable (type 7 is EfiConventionalMemory, AKA free memory). I haven't narrowed down the list of bad slides. This might be a firmware bug if it's actually using a subset of this region for something (it should not marked as free in the memory map in that case).

16:463 00:000 OCABC: Desc 5: [0x100000-0x16653000) (Type 7)
...
16:498 00:000 OCABC: Slide 26 [0x3500000-0x136E2000)
16:499 00:000  - Supported (AvailableSize 270409728)

I also encountered a different issue with newer BIOS versions (1402/1501/1801). If I kept the IGPU enabled, certain devices stopped working properly in macOS. This included the onboard AX210 WiFi and my Chelsio NIC (T580-LP-CR). AirportItlwm died during firmware initialization and cxgb failed to send any packets. These issues went away when I disabled the IGPU.

I have no clue! That's why I commented saying "Wow it works! How you guys keep updated with all of these findings is beyond me." in the post I referenced above.

I used IFRExtractor-RS to dump the variable offsets. You'll need to first extract the UEFI Setup application from the firmware image using UEFITool (search for GUID 899407D7-99FE-43D8-9A21-79EC328CAC21 and extract the PE32 image section as-is). Then you can pass it to ifrextractor, which should dump a readable version of the IFR data (including variable offsets).

Hmm, actually I just tried this with 1801 and it doesn't work... 1501 does though. Fortunately the offsets match up (AFAICT).

 

[SmackAttack]

I used IFRExtractor-RS to dump the variable offsets. You'll need to first extract the UEFI Setup application from the firmware image using UEFITool (search for GUID 899407D7-99FE-43D8-9A21-79EC328CAC21 and extract the PE32 image section as-is). Then you can pass it to ifrextractor, which should dump a readable version of the IFR data (including variable offsets).

Hmm, actually I just tried this with 1801 and it doesn't work... 1501 does though. Fortunately the offsets match up (AFAICT).

That was going to be my next step… trying an older firmware to get it to work…glad I’m not crazy! I even tried it in Windows… same result.

Thanks for the reply!
J