Contribute
Register

[Success] - Asus ROG Strix Z490-E Gaming + i9 10900K + OpenCore

Hi there,
I landed here since I'm having some issues with H.264 acceleration on a similar build to yours (i7-10700K, Z490-E and 5700Xt Nitro+).
Before asking you support I just wanted to make a brief comment on your EFI (0.7.1) as I noticed some inconsistencies (maybe due to the lack of experience? I don't know...).
Lemme be more clear:

1. ACPI

Without a correct ACPI configuration, mainly SSDT based, macOS can't boot natively on our machines.
Below a small comment on your ACPI:

- SSDT-AWAC: it's okay, but I'd go with the Acidanthera's sample
- SSDT-EC-USBX: this SSDT is wrongly written, as EC0 device is natively defined onto Z490-E ACPIs . You should use SSDTTime (or just manually write it). USBX part is okay
- SSDT-GPRW: honestly I don't see any reason of adding it, if you don't have any kind of sleep issues. Maybe is still required? Never had the urge of using it on desktop
- SSDT-PLUG-XCPM: this is the old version and DTGP method is unused. Just use the latest available sample from Acidanthera's OpenCorePkg, or generate it using SSDTTime (or even manually)
- SSDT-PM: there's literally no need of adding a random PMCR device, as Z490-E ACPIs have it natively working...


2. Drivers

Nothing to tell about. They're okay but I'd highly recommend taking the latest HfsPlus.efi

3. Kexts

Well here I'd want to analyze it better...

1628510993273.png


- AppleALC: okay
- CommanderProFix: I gave it a rapid look on this GitHub repo, and it's okay
- CtlnaAHCIPort: are you sure you need it? Can't you just add a compatible property as in this example?
- FakePCIID kexts: honestly... there's no need of adding the I225-V FakePCIID kext. If you're on Big Sur 11.3+ you can just use dk.e1000=0 boot-arg in order to enable the I225-V LAN card Regarding the HDMI audio I don't know... Never had issues with it, nor I needed a kext
- USBInjectAll: seriously? USBInjectAll should NEVER be used, as well as SSDT-RHUB (not your case tho). Your motherboard supports ACPI USB mapping. Those who use UIA and/or SSDT-RHUB should remove it immediately, as well as disabling XhciPortLimit. From what I tested, they make the system more unstable and prone to misbehaving with USBs (just to make a stupid e.g. some USB address were overlapping)
- SMCSuperIO: I couldn't make it work, but probably I have to contact ITE (or whoever is the vendor of the SuperIO controller) and ask them for the schematics, and finally ask acidanthera's to support the controller in SMCSuperIO releases, as did here
- USBPorts: it's okay if you don't want to use the native SSDT USB table (xh_cmsd4)
- VirtualSMC and WhateverGreen: okay

4. Tools

1628511638925.png


ClearNvram isn't needed since it's available via OpenCore boot-menu by enabling AllowResetNvram Misc/Security flag, while ResetSystem should be available by default on OpenCore boot-menu

5. config.plist

- ACPI/Add: okay
- ACPI/Delete: There are two disabled entries. Why leaving them here?
- ACPI/Quirks/ResetLogoStatus: are you sure you need it?
1628511852403.png

- Booter/Patch: why leaving an unused patch there?
- Booter/Quirks: EnableSafeModeSlide and ProvideCustomSlide can be safely disabled. Just use OpenCore DBG binaries as well as Misc/Target=67 and check the log by looking for ProvideCustomSlide

- DeviceProperties/Add:
- PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0) isn't needed due to dk.e1000=0 boot-arg which will take care of the LAN
- PciRoot(0x0)/Pci(0x1f,0x3): are you sure you need device-id? I didn't had to use it honestly
- PciRoot(0x0)/Pci(0x2,0x0): framebuffer-fbmem isn't needed if you correctly configured your BIOS (iGPU Multi Monitor enabled, DVMT Pre-allocated 64/128MB, RC6 Standby disabled)
- PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0): okay but I'd like to use -wegnoegpu boot-arg or disable-external-gpu device-property. Is there any reason why you decided to use the other properties?

- Kernel/Add: I'd highly suggest you to give a look at ocvalidate KextInfo.c kext order but this isn't a big problem after all
- Kernel/Block and Kernel/Force: why leaving there unused stuff?
- Kernel/Patch: okay for the I225-V patch if you're on macOS Big Sur 11.3 and below, but why adding the patch for enabling the TRIM on the SSD? Why don't you just use sudo trimforce enable if it's not already enabled by default (compatible NVMEs should have it)? Why have you added the RTC patch if Kernel/Quirks/DisableRtcChecksum already fixes this problem?
- Kernel/Quirks: Kernel/Quirks/DisableRtcChecksum fixes the Safe POST Mode error on boot

- Misc/Boot: PollAppleHotKeys should be enabled as well as UEFI/Input/KeySupport, UEFI/Output/ProvideConsoleGop, UEFI/ProtocolOverrides/FirmwareVolume and UEFI/Quirks/RequestBootVarRouting for providing FV2 support
- Misc/Security: why the heck if AllowResetNvram is enabled you added ClearNvram tool?
- Misc/Tools: in my honest opinion I'd empty this section or if needed just leave OpenShell.efi enabled, but that's a choice of yours.

- NVRAM:

okay well, this section is bloated af and I'd highly recommend to fix it as it follows:

before:
1628512777861.png


after:

1628512921086.png


There's no need of adding an unused NVRAM GUID for rtc-blacklist if DisableRtcChecksum already does its job. If you ever need it, read dortania's guide i PRed some months ago, but trust me, you won't need it on this board

The Delete section is wrongly configured, as the added variables aren't deleted (in case you're asking yourself why, it's safer deleting and readding back the variables, just to be sure that you're correctly using the NVRAM).

The csr-active-config is wrongly configured for BigSur as new SIP bits were added in the meanwhile, so it's better to have it completely enabled (00000000) or disable the unneeded stuff. It's a choice of yours :) (P.S. having the SIP completely disabled, won't let you find macOS updates. I don't know why they added this stuff but probably it's for security sake? idk)

Legacy stuff is unneeded. We're in 2021 with UEFI dude

- PlatformInfo: okay, but please note that ROM field contains some data. Idk if it's yours MAC address but I'd highly suggest to remove it :)

- UEFI:
- APFS: okay
- AppleInput: okay
- Audio: since you don't have AudioDxe, nor Chimera stuff, you can safely empty the AudioDevice field
- ConnectDrivers: okay
- Drivers: okay
- Input: okay but PointerSupportMode should be empty since PointerSupport is disabled:

1628513425166.png

- ProtocolOverrides: okay
- Quirks: okay
- Reserved: why leaving there unused stuff?


In any case, the EFI isn't that bad at all, except for some SSDTs/ACPI patches.
By the way, I'd want to ask you: is H.264 working for you with Final Cut Pro X? I can't make it work, despite VideoToolBoxAPI reports a working hardware acceleration using iMac20,1 SMBIOS... Can you help me? :D
Greetings
dreamwhite


STATUS UPDATE wed 11 aug

Apparently a clean install of macOS Big Sur fixed the problem. I don't know why the old installation of Big Sur (freshly installed Catalina dirty upgraded to Big Sur) caused those issues ._.
 
Last edited:
Hi there,
I landed here since I'm having some issues with H.264 acceleration on a similar build to yours (i7-10700K, Z490-E and 5700Xt Nitro+).
Before asking you support I just wanted to make a brief comment on your EFI (0.7.1) as I noticed some inconsistencies (maybe due to the lack of experience? I don't know...).
Lemme be more clear:

--snipped--


In any case, the EFI isn't that bad at all, except for some SSDTs/ACPI patches.
By the way, I'd want to ask you: is H.264 working for you with Final Cut Pro X? I can't make it work, despite VideoToolBoxAPI reports a working hardware acceleration using iMac20,1 SMBIOS... Can you help me? :D
Greetings
dreamwhite


STATUS UPDATE wed 11 aug

Apparently a clean install of macOS Big Sur fixed the problem. I don't know why the old installation of Big Sur (freshly installed Catalina dirty upgraded to Big Sur) caused those issues ._.

Not sure where to start on this post. First of all you should read more of this thread, as you would notice that USBInjectAll is NOT loaded by default, it's there ONLY for people who want to customize the USB map that I created.

2nd a few versions back I tried following the Opencore guide TO THE LETTER and generated all new ACPI files, and the end result was MORE sleep issues for myself and others in this thread, so we all collectively decided to roll back to the way I had it before.

3rd writing stuff like "Legacy stuff is unneeded. We're in 2021 with UEFI dude" and "okay well, this section is bloated af" is not a great way to get help from myself and other regular contributors to this thread.
 
Not sure where to start on this post. First of all you should read more of this thread, as you would notice that USBInjectAll is NOT loaded by default, it's there ONLY for people who want to customize the USB map that I created.

2nd a few versions back I tried following the Opencore guide TO THE LETTER and generated all new ACPI files, and the end result was MORE sleep issues for myself and others in this thread, so we all collectively decided to roll back to the way I had it before.

3rd writing stuff like "Legacy stuff is unneeded. We're in 2021 with UEFI dude" and "okay well, this section is bloated af" is not a great way to get help from myself and other regular contributors to this thread.
Love it when someone joins a thread late, picks apart your contribution and then asks for help.:banghead::lolno::lolno::lolno::lolno::lolno::lolno:
 
Love it when someone joins a thread late, picks apart your contribution and then asks for help.:banghead::lolno::lolno::lolno::lolno::lolno::lolno:
And also starting with "...I'm having some issues with..." and then "I noticed some inconsistencies (maybe due to the lack of experience? I don't know...)". But.. some people just don't know when they are being rude... or do know, but just don't care.. :banghead:

@scope666 I'm running on 0.7.2 now and it is working perfectly for me. I did have some strange issues with my Radeon W5500, the displays turned black/green randomly, which I did not have before. I also just started using a new LG 4K monitor and I switched to the iGPU which seemed to be more stable.. I'll have to use it a bit longer to be sure though. I do not think this is related to the 0.7.2 update, but I might check the previous opencore version is stability issues still occur.
 
Not sure where to start on this post. First of all you should read more of this thread, as you would notice that USBInjectAll is NOT loaded by default, it's there ONLY for people who want to customize the USB map that I created.

2nd a few versions back I tried following the Opencore guide TO THE LETTER and generated all new ACPI files, and the end result was MORE sleep issues for myself and others in this thread, so we all collectively decided to roll back to the way I had it before.

3rd writing stuff like "Legacy stuff is unneeded. We're in 2021 with UEFI dude" and "okay well, this section is bloated af" is not a great way to get help from myself and other regular contributors to this thread.

Good morning everyone.

UIA should be avoided at all, neither if you want or not. It's a bad practice that may lead to unwanted consequences like not working USB, or misconfigured ports, and potential higher CPU usage. Removing it will only give you benefits. It's way better using a SSDT-UIAC or a USBPorts like kext, as @scope666 did

2. Regarding the sleep stuff I literally wrote honestly I don't see any reason of adding it, if you don't have any kind of sleep issues. Maybe is still required? Never had the urge of using it on desktop. It's pretty self explanatory i think. Are you using hibernatemode 0? I'll find the energy to read 80 pages of thread again and eventually update this comment

3. You're right. I was in mode "rude at 69420%". My bad :/ sorry to everyone I potentially offended. It wasn't definitely my way to help and give some contributions. Feel free to follow or not my advices to have a """cleaner""" EFI.

I just wanted to clarify some points that should be pointed out with a possible future release.
Overall, as I wrote, the EFI isn't such a mess but as every EFI, even those one who can be considered "perfect" (or similar to it), can be improved even more.

Regarding my issue with H.264 apparently it seems like a buggy dirty install from macOS Catalina to macOS Big Sur. A clean install fixed the issue and I can confirm that even restoring the old installation from Time Machine using Migration Assistant didn't fixed the problem.

Anyways, since I don't wanna be labeled as an idiot who talks without giving proofs of his work (kekw), I'm attaching the EFI I'm using with a Z490-E + i7-10700K + RX 5700XT Nitro+ and a bunch of Apple TRIM compatible NVMEs. Please read the comments at the start of the config.plist
 

Attachments

  • EFI.zip
    5.1 MB · Views: 104
Anyways, since I don't wanna be labeled as an idiot who talks without giving proofs of his work (kekw), I'm attaching the EFI I'm using with a Z490-E + i7-10700K + RX 5700XT Nitro+ and a bunch of Apple TRIM compatible NVMEs. Please read the comments at the start of the config.plist
Thanks for your update and contribution!

I took a look at your EFI and it looks really clean indeed. I adjusted it for my system and it works fine, now I will have to dig into it :), especially the SSDT USB is something I never did before. It's also nice to see Ethernet working ootb.

Some things are not in line with the Dortania guide like the SSDT-RHUB for example, but everything seems ok without it.
 
Good morning everyone.

UIA should be avoided at all, neither if you want or not. It's a bad practice that may lead to unwanted consequences like not working USB, or misconfigured ports, and potential higher CPU usage. Removing it will only give you benefits. It's way better using a SSDT-UIAC or a USBPorts like kext, as @scope666 did

2. Regarding the sleep stuff I literally wrote honestly I don't see any reason of adding it, if you don't have any kind of sleep issues. Maybe is still required? Never had the urge of using it on desktop. It's pretty self explanatory i think. Are you using hibernatemode 0? I'll find the energy to read 80 pages of thread again and eventually update this comment

3. You're right. I was in mode "rude at 69420%". My bad :/ sorry to everyone I potentially offended. It wasn't definitely my way to help and give some contributions. Feel free to follow or not my advices to have a """cleaner""" EFI.

I just wanted to clarify some points that should be pointed out with a possible future release.
Overall, as I wrote, the EFI isn't such a mess but as every EFI, even those one who can be considered "perfect" (or similar to it), can be improved even more.

Regarding my issue with H.264 apparently it seems like a buggy dirty install from macOS Catalina to macOS Big Sur. A clean install fixed the issue and I can confirm that even restoring the old installation from Time Machine using Migration Assistant didn't fixed the problem.

Anyways, since I don't wanna be labeled as an idiot who talks without giving proofs of his work (kekw), I'm attaching the EFI I'm using with a Z490-E + i7-10700K + RX 5700XT Nitro+ and a bunch of Apple TRIM compatible NVMEs. Please read the comments at the start of the config.plist

To address this one specifically, you'll see in the first post I have both an nVidia GPU (RTX 3080 Ti as of recently) for the Windows side, and an AMD RX 560 GPU in the lower PCI-E slot for macOS. It's a dual boot setup.

"- PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0): okay but I'd like to use -wegnoegpu boot-arg or disable-external-gpu device-property. Is there any reason why you decided to use the other properties?"

The method I'm using specifically disables ONLY the DGPU in the upper slot, leaving my AMD GPU enabled.

Again for UIA, my intention is for the user to only enable it temporarily if they're creating their own USB map, that's why it's disabled in the EFI.

I've learned since I started this thread that I have to strike a balance between what works for my machine, and the other users here. With that said I do appreciate your contributions, and will be testing them for possible inclusion.
 
The method I'm using specifically disables ONLY the DGPU in the upper slot, leaving my AMD GPU enabled.
Yeah sure, but isn't disable-external-gpu device property better? -wegnoegpu disables any GPU unconditionally, while the device property is applied just to the PciRoot path you specify, so in your case you can just leave disable-external-gpu. Am I wrong?
 
Back
Top