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

[dsynos80]

BLUETOOTH INFO UPDATE:

 

After updating all kexts in Clover today, the 2 Bluetooth firmware files do not cause anymore boot problems,

so feel free to use them, replacing also your SSDT with this one.

I am still on Clover 5122

Aorus Pro WiFi f12j

 

REMEMBER TO UPDATE YOUR KEXTS, otherwise you may have boot problems.

SSDT-6-A M I.aml

IntelBluetooth.zip

Edited October 25, 2020 by dsynos80

[mariodj]

Please help, i try to connect nvme Adata Xpg SX8200 pro disk and got black screen. Do i need to change soemthing in bios before i connect?

 

Once i connect this disk i cant see bios.

Edited October 27, 2020 by mariodj

[dsynos80]

1 hour ago, mariodj said:

Please help, i try to connect nvme Adata Xpg SX8200 pro disk and got black screen. Do i need to change soemthing in bios before i connect?

 

Once i connect this disk i cant see bios.

I had no such problems with the same disk. Installed in top slot, seen directly from bios, formatted in fat through windows then cloned my old mac sssd.

I would suggest remove the nvme, enter bios and load defaults. Reboot, shutdown then reinstall.

 

[rob1980]

10 hours ago, mariodj said:

Please help, i try to connect nvme Adata Xpg SX8200 pro disk and got black screen. Do i need to change soemthing in bios before i connect?

 

Once i connect this disk i cant see bios.

Can also confirm, Im running two of the 1Tb cards, one for windows one for Mac, no issues or anything special required, detected the same as a HDD or SSD in bios.

[mariodj]

Ok so. When I set default bios settings I run windows and format nvme disk.

When I return to bios settings for hack installation I got black screen, can't go to bios :(

[WizeMan]

2 hours ago, mariodj said:

Ok so. When I set default bios settings I run windows and format nvme disk.

When I return to bios settings for hack installation I got black screen, can't go to bios

There is a possibility that windows enabled fast boot in the EFI? Reset to bios defaults and set it up again. Boot windows through OpenCore.

[mariodj]

8 hours ago, WizeMan said:

There is a possibility that windows enabled fast boot in the EFI? Reset to bios defaults and set it up again. Boot windows through OpenCore.

 

i disconnect all drives and its the same  no idea whats goin on

disk working only with defaults bios settings

 

update: I just test this disk on my MBP2015 and its working ok so disk is ok

so I install Catalina on MacBook and return to my hack  still the same

Edited October 28, 2020 by mariodj

[pkdesign]

On 10/22/2020 at 4:32 AM, benjiolino said:

I have the problem that approx. every fifth time I get the crossed out circle when booting. Then I just try again and it boots normally. Does anybody have the same problem?

Clover or OpenCore? I had that exact issue with Clover. It drove me to OC and I never looked back. 

[SirLinux]

Finished an install yesterday using a ASUS GeForce GT 710 Low-Profile Passive 2GB GDDR5 PCIe Graphics Card / i-9 9900k / Aorus Pro Wifi / 64gb Ram. GPU is driving 2 1080P monitors. After install the I let it update to the latest Catalina release and no issues. The primary use case for this build is to replace a 2012 Unibody 15" MacBook Pro running Logic Pro. The 2012 is getting a bit laggy these days with all the plugins, multiple tracks, etc.. Still chugging along though.  Anyway, now I need to figure out how to get all the plugins/ sounds and configs over to the new build to be certain there are no problems. 

One thing bothers me is that Geekbench 5 came out with a result of about 6500 for multi core. Wonder what happened there. 

Thanks @AudioGod and all others for this thread.

 

[AudioGod]

OpenCore 0.6.3 EFI Major Update (Big Sur Ready), 2nd November 2020 

(Use With Bios Revision F12K or Newer)

 

The EFIs and DSDTs have now been updated to the my latest versions.

Changes made include,

AppleALC 1.5.4,

Lilu 1.4.9,

WhateverGreen 1.4.4,

VirtualSMC 1.1.8,

AirportBrcmFixup 2.1.1,

IntelMausi 1.0.4,

OpenCore Updated to Revision 0.6.3 (Big Sur Ready),

OpenCanopy is Enabled as Standard,

SSDT-Plug and SSDT-PMC Have been freshly pulled and rewritten using bios F12K,

SSDT-EC-USBX.aml has now been added to the ACPI,

USBPort.kext has been rewritten manually and is now named USBMap.kext and the power tables are now being done via SSDT-EC-USBX instead of directly inside the USB.kext,

Plus other major tweaks and changes to all of the configs

 

PLEASE NOTE - It's now possible to go past the 15port limit safely without freaking out your system.

all you got to do to enable it is go into the plist and goto Kernel - Quirks and set XhciPortLimit to Yes. Once you do that and restart all USB ports will be active fully including usb 2 on usb 3 and type c etc.

 

Note - If you don't need it on then don't use it but at the same time if you wanna test it out then go for it and let me know if you get any strange behaviour.

 

OpenCore EFI Update v0.6.3 - 02/11/2020

OC 063 Z390 Pro 19,1 EFI 021120.zip - OpenCore v0.6.3, SMBios iMac19,1

OC 063 Z390 Pro 1,1 EFI 021120.zip - OpenCore v0.6.3, SMBios iMacPro1,1 (IGPU Disabled)

PLEASE DON’T FORGET TO RESET YOUR NVRAM BEFORE BOOTING INTO THE NEW EFI FOR THE FIRST TIME,

 

Note - If your not using a 5700 XT or any other Navi GPU then remove agdpmod=pikera from the boot arguments.

Note 2 - Do not try to carry across your old OpenCore Config.plist to the new EFI as to many changes have occurred in 0.6.0. Use the new Config.plist instead.

 

For OpenCore Using PlistEdit Pro add your details by modifying the following 

 

PLEASE NOTE - These EFIs are setup to be used with your msr Unlocked so make sure you use the correct bios settings listed below or use the F12K Unlocked Profile I have provided.

 

Additional Downloads

mb_bios_z390-aorus-pro_f12k.zip - Aorus Z390 Pro Bios Firmware F112K

mb_bios_z390-aorus-pro-wifi_f12j.zip - Aorus Z390 Pro Wifi Bios Firmware F112J

PlistEdit Pro.zip - PlistEdit Pro (use to edit OpenCore)

PLEASE NOTE - MSR Unlock is now baked into the BIOS as a setting so you no longer need my bios profile to unlock your MSR.

 

Bios Update F12K (F12J Pro Wifi) and Bios Settings

PLEASE NOTE - MSR Unlock is now baked into the BIOS as a setting so you no longer need my bios profile to unlock your MSR.

 

BIOS SETTINGS (Bios Revision F12k & F12j Pro Wifi)

 

• Enter BIOS -> Press Delete -> Enter Setup

• Save & Exit -> Load Optimized Defaults

• Boot -> CFG Lock -> Disabled

• Boot -> Windows 8/10 Features -> Win 8/10 WHQL

• Boot -> CSM Support -> Disabled (Can be set to Enabled if need be but try to have it set to Disabled first)

• Favourites -> Extreme Memory Profile (X.M.P.) -> Profile1

• Favourites -> VT-d -> Disabled (Can be set to Enabled or Disabled, Your choice)

• Settings -> IO Ports -> Internal Display Output -> PCIe 1 Slot

• Settings -> IO Ports -> Internal Graphics -> Enabled (Disabled If Using SMBios 1,1)

• Settings -> IO Ports -> DVMT Pre-Allocated -> 64M

• Settings -> IO Ports -> DVMT Total GFX0-Allocated -> 256M

• Settings -> IO Ports -> Aperture Size -> 256MB
• Settings -> IO Ports -> Wifi -> Disabled (Z390 Pro Wifi Only)

• Settings -> IO Ports -> Audio Controller -> Enabled

• Settings -> IO Ports -> Above 4G Decoding -> Enabled

• Settings -> IO Ports -> USB Configuration -> Legacy USB Support -> Auto

• Settings -> IO Ports -> USB Configuration -> XHCI Hands-off -> Enabled

• Settings -> Miscellaneous -> Software Guard Extensions (SGX) -> Disabled

• Settings -> Platform Power -> Platform Power Management -> Enabled

• Settings -> Platform Power -> ErP -> Enabled

• Settings -> Platform Power -> RC6(Render Standby) -> Enabled

• Save & Exit → Save & Exit Setup

 

F12K BIOS Profile With MSR Unlocked & All The Correct Settings Dialled in for you - The Easy Way 

@texem has made this bios profile for you all to use that will unlock CFG on your motherboard making it play alot more friendly with the NVRam.

It also has all the bios settings listed on this guide pre done and saved onto the profile.



Z390 PRO BIOS PROFILE - F12k.zip - Use with Z390 PRO Bios Revision F12K ONLY

Z390 PRO WIFI BIOS PROFILE - F12J.zip - Use with Z390 PRO WIFI Bios Revision F12J ONLY (Coming Soon)

 

1 - Download the profile and save it to a USB Key

2 - Go into the bios,

3 - Load the profile, 

4 - Save and exit

5 - Go straight back into the bios and save your bios to a new profile and name it Default or something like that.

6 - Save the changes and then restart and your done, your motherboard will now be CFG (MSR) Unlocked and all the correct settings will be dialled in for you.

 

Edited November 8, 2020 by AudioGod

[pkdesign]

Thank you @AudioGod as always!

 

Can I ask why you made the switch from a pure USBPorts to the SSDT-EC-USBX method?

 

I've updated to 0.6.3 and extended my USB ports by editing USBMap to include all the HS and SS ports. No issues so far.

Edited November 3, 2020 by pkdesign

[juan e. jot]

Following @AudioGod's directions, I was able to upgrade to his OC 0.6.3 EFI without a hitch. I of course (following his directions) did need to carefully port over any my-system-specific parts of config.plist, as reusing the old one was a no-no with so many changes from 0.6.2 to 0.6.3.

 

I had one question to do with that, a follow-up question to a previous issue on this thread, and one fortuitous observation regarding the changeover in how USB is handled:

• I use (and have properly pointed to in the new config.plist, provided the expected order hasn't changed) NVMEFix.kext for proper recognition of my SX8200 Pro boot drive; it works without, but had given random KPs in the past when I didn't use it, stopped doing so when I started using said kext. Correlation not being causation, a solid system is still preferable to a crashy one, even if I attribute it to the garlic I wear around my neck or whatever. Do you have any insight into whether the "need" for said kext has changed at all with this 0.6.3 update?
• I see the instruction to turn off WiFi in UEFI BIOS for the Z390 Aorus Pro Wifi; I assume then that folks' difficulty mapping HS14 (from the discussion, I assume that's the only port that will work?) for the onboard CNVI card's Bluetooth, as well as the spotty Bluetooth performance people are getting with current versions, was the reason not to include anything to do with the OpenIntelWireless suite (itlwm, IntelBluetoothFirmware & HeliPort) that you had earlier been tinkering with/asked folks for their experiences with? Fine for me for now, as I'm running the Fenvi T919 without issue.  I just occasionally consider whether I want to tinker, to maybe clear out that PCI port to optimize airflow for the graphics card (although said GPU is, for the most part, not heavily taxed under macOS at least). Using the onboard WiFi/BT card would also lighten the load of drivers I need to use under other OSes, though obviously that's outside the scope of this thread.
• Regarding USB, I have not tried your suggestion to push the port limit past 15, so I have nothing to report there. Depending on an answer to the HS14 issue above, that could possibly change. However, I notice that my installation of DriveDx (running SAT SMART Driver version 0.10.2s for recognition of SMART status on externally-connected USB drives) can now recognize my Seagate Backup Plus Hub drive, which it could not with the USBPorts.kext (and lack of SSDT-EC-USBX.aml) that AudioGod included with his 0.6.2 EFI. The overall functionality of the drive has been steady under any combination of versions of the app, driver, kext & aml, but it's nice to have SMART status on it, when previous external USB drives had had it, drives with the same idVendor/idProduct--but not same capacity--had been stated by the driver compatibility page to work, and I had given up switching around driver versions (back and forth with 0.8.2s) when I just couldn't get it to work. So it's a nice unexpected benefit to have it working now, thanks!

[pkdesign]

@juan e. jot FYI, i have the same SX8200 Pro as my boot drive and I have never had an issue with KPs or anything to do with the drive.

[Anthonythangaraj]

@AudioGod Thanks for the EFI. Everything works with my system. I used SMBios iMacPro1,1 smbios

 

I have 8700k, Z390 Auros Pro Wifi with Asus Strix Vega 64 on Bigsur 11.0.1

 

I have 2 issues - But not a big deal though

1. Some of my usbports was not working (Fixed by removing the usbmap.kext/SSDT-EC-USBX.aml and added my Usbport.kext from hackintool)

2. HDMI port works fine but display is not waking after sleep. Had to force reboot the system (Fixed by switching to Display port) . Any suggestion for fixing HDMI will be helpful as I am missing HDR works with only HDMI port on my monitor.

 

Just a small query, On Hackintool 'Intel Generation = ???' Is it suppose to be Normal.

Also do we still need 'darkwake=0' bootflag as my old EFI doesn't has it and i did't faced any issues without it.

 

Thanks 

Edited November 4, 2020 by Anthonythangaraj

[AudioGod]

@Anthonythangaraj and anybody else that’s having trouble with USB. When moving to the new EFI all you need to do is repair your permissions, clear your cache and reset your NVRam. After that your USB will be perfect. If you need more ports open then the max 15 I have setup already then just go past the 15 port limit using the quirk XhciPortLimit=Yes

The USBport.kext works just fine but using the ssdt and not having the usb power tables via the kext is more stable and a better solution.

 

Darkwake=0 is not needed but without it you have to click twice to wake the screen. With it you get instant wake with one click (darkwake is broken in BigSur) and ??? In hackintool is normal. Side note, hackintool is your friend in many ways but it don’t get it all right unfortunately. 

Edited November 4, 2020 by AudioGod

[stavidawg]

Any one know if we are safe to install the supplemental update that was just released?

[AudioGod]

20 minutes ago, stavidawg said:

Any one know if we are safe to install the supplemental update that was just released?

Yes the Catalina 10.15.7 supplemental update and Big Sur 11.0.1 RC are both perfectly fine to update too, 

[iamthekey]

Hi, will be clover update too? or I must change to opencore? Thanks

[AudioGod]

7 hours ago, iamthekey said:

Hi, will be clover update too? or I must change to opencore? Thanks

I will update clover when it works properly with Big Sur but unfortunately that hasn’t happened fully yet.  It works but not fully, not yet anyway.

[mariodj]

I just install new Samsung 970 Evo nvme and got no problems like it was on Adata SX8200pro 

 

Maybe problems cause was this Click Click

 

 

Now on boot i got windows and osx. I got linux as well but is not visible on boot. Is there any chance to add linux disk at boot ??

Edited November 7, 2020 by mariodj

[juan e. jot]

WiFi/BT status of my own tinkering with the OpenIntelWireless suite, inside @AudioGod's 0.6.3 EFI (as otherwise previously tailored to my own system):

 

EDIT next day: Feel free to read my steps below this bolded section, but know it's really easy to break the OpenIntelWireless suite's functionality. It seems a normal maintenance routine that includes Titanium Software's Onyx running its default Maintenance routine breaks the WiFi portion of said functionality.  This does not happen after running all of Northern Softwork's Catalina Cache Cleaner's Maintenance routines, or CCC's Cache Cleaning, all the way down to Deep for Local, System and All User Caches.  These two programs have very similar use cases, though their GUIs are a little different. They accomplish (if you look at the log of commands in Terminal, after running them) very similar CLI maintenance goals. I really wish I could pick out which CLI command among what Onyx ran, that was at "fault," even though this kind of maintenance is something that clearly needs to be done from time to time.  There is no such loss of WiFi functionality upon use of this product with either a real Mac or my Hack so far with the Fenvi T919 (both using a Broadcom chipset).

 

But currently when running config.plist & USBMap.kext configured to allow its use, after an Onyx default maintenance run, the WiFi icon is greyed out, saying it's unavailable when clicked. Going into System Preferences and turning it on yields a short hang, but no return to functionality, which remains the case after reboot, rerunning maintenance routines, etc. Merely switching back to a known-good, AirportBrcmFixup.kext-bearing EFI and physically reinstalling the T919 (though I cleared NVRAM and ran cache/permissions maintenance routines again, just for good measure) restored expected WiFi/BT functionality, including Continuity/Handoff.

 

So apparently, doing routine maintenance while running with OpenIntelWireless configured in your EFI & WiFi turned on in UEFI BIOS on an Aorus Z390 Pro WiFi, breaks said WiFi's functionality.  Clearly, a work in progress, but one worth watching (and trying if you like, keeping in mind YMMV and caveat emptor).

 

After trying first with itlwm 1.1.0_stable (which does not, though documentation makes it a bit difficult to suss out this answer except deep in the FAQ, support Continuity/Handoff) with HeliPort 1.0.1, AirportItlwm v1.0_Beta_Catalina (without HeliPort) seems to support Continuity with Handoff, though I have not tried Universal Clipboard yet. Bluetooth with Apple devices also seems to work. Steps necessary for me (YMMV) to get it done:

1. Make sure AirPortItlwm.kext, IntelBluetoothFirmware.kext & IntelBluetoothInjector.kext are all in the Kexts folder of your EFI (in my case I removed AirportBrcmFixup.kext when I physically uninstalled the Fenvi T919, and have yet--until the bork, but I see no evidence of a relation… yet--to run into issues),
2. Edit config.plist to include AirPortItlwm.kext, IntelBluetoothFirmware.kext & IntelBluetoothInjector.kext (versions 1.1.2) under Kernel > Add, (as stated above, I also removed AirportBrcmFixup.kext). You can live with the threat of mistakes by doing it all inside a text editor like BBEdit, or start off in a plist editor (my favorite is ProperTree) and do an OC or Clean OC Snapshot; but beware, that reorganizes and puts a lot of redundant code into AG's config.plist, so what I did was open up the old config.plist and copied over the Kernel>Add>numbered entries for the three new kexts I wanted (and erased the numbered entry for the one I no longer wanted) into my otherwise known-good config.plist,
3. Edit USBMap.kext by right-clicking to "Show Package Contents," go into Contents & edit Info.plist to include a reference to HS14. Be aware that if you stay under the 15-port limit as I have so far, you'll need to remove a separate HSxx; my choice was to jettison HS07. Now USB2 dongles don't show up when plugged into the back of the board, but USB3 ones still do (because those ports are also references as Super Speed (SSxx, USB3) not just High Speed (HSxx, USB2) ports. And if you've got the case-front USB ports connected to the mobo as I do, they still work as intended for both USB2 & USB3. I just chose to edit in BBEdit because I think ProperTree is more adept at OC's config.plist than Info.plists, but beware that I kept things in order (Cut the entire HS07 entry from <dict> on line 44 through </dict> on line 53, then pasted the whole entry under HS13's, but above SS01's, made sure to change the text of "HS07" to "HS14," the text between "<integer>" and "</integer>" what Dortania suggests on https://dortania.github.io/OpenCore-Post-Install/usb/manual/manual.html#usb-mapping-the-manual-way for internal ports (go read it), and between "<data>" and "</data>" to what a good decimal to Base64 converter suggests for the numerical value only of that HS14 port. Go on now, do your Internet research; I'll wait.
4. Reboot once your EFI house is in order, crossing fingers if it gives you solace. I noted that -v shows more lines about loading up an Intel wireless driver.  Woo.  At the desktop, as just above this list of steps, seems to work for me.

The only artifact of "this works differently than with the Fenvi T919" that I've found so far is that when Handoff references to an app/URL just opened up on a nearby iOS device pop up, they don't then go away after the iOS device navigates away. They are replaced by a new app/URL reference from the iOS device, though. And beyond their hanging around past the iOS device's having navigated away from them, everything works/looks as it should. Also, as above, at least from iTunes so far, Bluetooth audio sounds good.  I don't care about its potential to mess with WiFi throughput though, as I only use WiFi/BT for Continuity/Handoff, connecting to the Internet via Ethernet.

 

Lastly, a potential to-do for me: I have yet to explore AG's suggestion of how to expand USB past the 15-port limit.  If I do, I may restore HS07 and keep HS14 for the Intel CNVI's Bluetooth… however his suggestions allow that.

 

Edited November 9, 2020 by juan e. jot
After more research, reorganization & expansion of bolded section describing how easy OpenIntelWireless functionality is to bork, when doing routine and necessary system maintenance.

[juan e. jot]

Big Sur Beta 11.0.1 seems to work, after a long and arduous (multiple reboots & lengthy hangs "there-during") install process on a separate drive (just booted to OpenCore, so no separate EFI). Catalina needed me to log back into iCloud once I got back (had not set up any iCloud in Big Sur), but other than the fact that the Big Sur drive is now called "Update" and looks like its System partition is hanging open, it's fine in Catalina.

 

And in Big Sur? Meh: it looks completely cosmetic.  I know there's more going on under the hood, but I'm not super-jazzed.  Funnily, "macOS Help" in the Finder just gives you the Catalina help pages.  I guess we'll see tomorrow what a non-beta looks like.

 

UPDATE 11/10 (sorry, left side of the pond): Wee~eell… looks like they only introduced Fruity Silicon mackintoshes, did not actually unveil Bug Sir (my current, teasing name for it, though I haven't noticed any bugs as such), choosing instead to say on their web page that the release date is "11.12." That's OK; when I checked for updates on the 11.0.1 Beta, I got notification that RC2 was ready. This, I interpret to mean a couple of things:

• It's ready, they just want developers & beta testers to shriek "STOP THE PRESSES!!!" if there's some reality-breaking bug that the changes in RC2 engendered, and
• 11.0.1, I'm assuming, is what they're going to release, rather than 11.0. That's not totally off par for the course; I feel like the transition to OS Ecks was similar, though wikis seem to say there were solid x.y.0, x.y.1, etc. releases after the original DP and Public Beta. I've definitely seen it happen with mobile releases (eyeOS 10.0.1, I'm looking at you).

Updating from 11.0.1 Beta to 11.0.1 RC2 went off without a hitch, though as before, there were several reboots (no hangs, this time). The interface is slowly growing on me as more modern. Kinda swoopy, but still I don't see the point… which is how I'll feel while I tinker, until one day when I go back to Catalina & it looks antiquated. Hopefully, that will be after any initial release bugs are truly worked out, even if I haven't personally run across them yet.

 

For now, Catalina remains home. Regarding any oddnesses about the Beta mentioned above, "macOS Help" still refers one to the Catalina help pages (silly in an RC2, but they'll fix it eventually when n00bs flood the AppleCare call center with "my Launchpad doesn't look like that!," etc.), and in Catalina, the Big Sur boot drive icon is still named "Update" and looks like it actually points to the System partition or a proxy for the dedicated true Fruity EFI it expects or some such (but not the Data partition, anyway).  Oh well; if and when I update my main drive, the boot drive will show up on the "Bug Sir" desktop as expected.

 

Update 11/12: It appears my 11.0.1 RC2 installation on a separate drive effectively = the 11.0.1 Final they released, as after its release and an upgrade badge on System Preferences from inside Catalina, booting to said separate suggests no updates, even when checking for them.  Still says I'm enrolled in the Beta program, so maybe that's why. [It later turned out RC2 was build 20B28, the final release was 20B29.]

So... how long can I stand to hang out on "yesterday's OS?" Well, at least until the end of the work day, hoping I see no wide-spread tales of buggy woe on the InterWebz. Good luck out there!

Edited November 13, 2020 by juan e. jot
Acknowledge that 11.0.1 RC2 appears to =/= Final

[juan e. jot]

On 11/7/2020 at 4:57 AM, mariodj said:

I just install new Samsung 970 Evo nvme and got no problems like it was on Adata SX8200pro 

 

Maybe problems cause was this Click Click

 

 

Now on boot i got windows and osx. I got linux as well but is not visible on boot. Is there any chance to add linux disk at boot ??

 

Hi there. In my experience, OC (for the last several versions, anyway) by default just looks for macOS and Windows boot drives, and can be pointed toward one that it doesn't look for by default, by setting BlessOverride, as in the below post of mine from June. I've updated with some strikethroughs of old/inaccurate info and [new, replacement info]. As always, back up & YMMV. Good luck!

 

On 6/6/2020 at 4:59 PM, juan e. jot said:

Hi folks.  Just reporting what I found with regard to adding Linux to the boot menu for AG & texem's OpenCore EFI: adding a child to the BlessOverride array of config.plist with a string representing the path to the location on the drive of Linux's grubx64.efi (with Windows-style forward backslashes, not Linux/macOS/http-style forward slashes) replaces the Windows boot option (if you've installed it) next to the macOS boot option as presented by the OpenCanopy bootpicker screen.  If you have a functioning grub installation (as I do) and you then select Windows to boot from within grub, OpenCanopy remembers the selection and presents Windows (with a Windows disk icon) alongside macOS and the EFI selection leading to Linux, upon the next boot. Note that clearing NVRAM will clear that Windows icon as an option to boot, but going to grub & booting to Windows from it again, restores the Windows icon (and Windows-booting behavior) to OpenCanopy.

 

As always, your mileage may vary.  This is not a recommendation, but is as well as I've gotten it to function so far, in my case.  Read up, back up, and be ready for the pain of restoring (and whatever re-indexing macOS deems necessary after that, which may take several days) before trying anything that deviates from what AG & texem have already presented in this thread.

 

Issues (not AG or texem's, but OpenCanopy's):

• It doesn't look wonderful, as in OpenCanopy the Linux boot option just names itself the same name as whatever that drive's EFI partition is called & uses a generic icon. (Come to think of it, the macOS drive gets a generic icon too, but that's a separate issue that will take continuing to read & interpret OpenCore's Configuration.pdf.)
• Even if you set your macOS drive as what you want to default boot to in the Startup Disk pane under System Preferences (which is supposed to work under OC, even if it doesn't under Clover), OC still seems to boot up in whatever was most recently selected. [No longer true in OC 0.6.3, at least; as long as you have saved macOS your boot drive in System Preferences & not reset NVRAM, macOS will continue to be the default boot drive. Remember to set it in System Preferences again, if you have to reset NVRAM!]
• Worse, somehow even with "OpenCore" set in UEFI BIOS as the primary boot option, bootmgfw.efi (I assume) intermittently bypasses OpenCore entirely & the machine boots straight into Windows without showing the OpenCanopy picker.  This behavior happened (again, intermittently) with version 1909; I haven't tried it* since upgrading to 2004. [Since writing this post in June, I've found that it is not intermittent; it is when Windows feels it has some reason to become the default, such as when you've had to reinstall or perform some Recovery work on Windows. Going back into UEFI BIOS and putting either "OpenCore" if you see it, or "UEFI OS" (which is usually macOS, as other OSes name themselves pretty clearly in UEFI BIOS) if "OpenCore" isn't showing up, at the top of the list, and then Save & Exit UEFI BIOS; you should then (reliably until bootmgfw.efi feels the need to take over because of something you did with Windows) boot to the OpenCore bootpicker.

* By "haven't tried it" I mean that I didn't love the cosmetics of the first point, and the lack of "set it and forget it" control of the second two points made me return, for now, to Clover.  I'll keep watching OC, and look forward to trying AG & texem's 0.6.0 EFI when it's out! Maybe acidanthera will have addressed or made the ways for users to deal with the above, simpler in OpenCanopy by then… or later. [My update & the fact that it has to do with Windows has nothing to do with OC or Acidanthera fixing it; this is still the same behavior now with 20H2.]

 

[AudioGod]

 

Big Sur is now live to Download via the App Store. 

 

 

[panosru]

@AudioGod lucky you! nothing here yet!

 

I spoke too early! lucky me as well! ;P 

Edited November 12, 2020 by panosru