Ok, now we need to get rid of all possible SSDT's, yeah!!! That's wonderful lol

I like this approach thou. I am amazed how fast all the hackintosh world can change with a simple change your systems boot, now it does not
Yup lots to learn! I'm not sure I'll end up removing
all SSDTs. But I'm definitely interested to see how Ellybz achieved that. As he said, there's lots of different ways to do things, and not necessarily one 'correct' way.
I do like having cosmetic stuff configured via DeviceProperties, as it's all immediately visible in the config.plist. Just seems cleaner that way.
What I'm yet to really understand is whether it matters what devices are called from an ACPI level. To take one example - our X550 NICs. Using dolgarrenan's SSDTs, they get renamed to XGBE and XGBF. If that SSDT is not loaded, they're called ethernet1 and PXSX (I think).
So what I'd like to know is.. does that matter? Is there any benefit to having them called the same thing at an ACPI/IoReg level as they would be on a real Mac?
Knowing that would help to understand how important it is to have SSDTs/DeviceProperties/etc. Whether it actually matters for functionality, or if it's just a nice-to-have.
I'm now booted into the latest Big Sur release (11.1) without any problems. All kexts appear to work fine. I did an in-place upgrade to the newest OS release and the upgrade process went off without a hitch, too.
Good to hear. Have you enabled
SecureBootModel for BigSur? I'm a bit unsure about that. Dortania's guides seem to indicate it's practically required, at least for install and updates. But then Ellyby's BigSur config had it Disabled.
I just ordered one of the new AMD 6800 GPUs, so I'll need to upgrade to BigSur 11.1 in order to use that.
I've done a bit more digging on the bios reset thing, but so far no new information has turned up. I'll keep looking into it when I have time, maybe there's something we can do to fix it, but chances remain slim.
Yeah, I don't think we're going to get anywhere without some expert/developer help. To that end I posted in an official OpenCore thread on another site. I won't link it as it'll probably get flagged or something. As I rather feared, no responses after several days.
My feeling is that it's definitely a BIOS bug - or at least a BIOS peculiarity - and may well require a special quirk/tweak, ie one that doesn't yet exist. Meaning an OpenCore dev would have to write it. And will they be interested to do that if it only affects this one board? Probably not.
I will keep asking around and might approach an OpenCore developer directly. But mostly I'm resigning myself that we'll just have to live with it. At least it never effects normal booting. It only affects me when I need to boot from USB instead of NVMe, and that's rare now that I've got my config mostly working. And even if I do need to boot from USB, I can do so with only one extra reboot. So it's not the end of the world.
By the way, I'd highly recommend that you all familiarise yourself with OpenShell, and make sure it's enabled in your config. It's very useful for making quick changes and fixes to your config.plist.
For example: you want to test a new or different config.plist setting. On another motherboard you'd probably test this on USB, so as to leave your NVMe config unaffected. But that's a pain on this board, because of the boot failure issue. So instead you go ahead and change it directly on the NVMe. You try and boot, and the boot fails because of the new config.
Now, instead of reverting to your USB backup (and the extra reboots and BIOS F10 required by the boot failure issue), instead you can boot into OpenShell, from the OpenCore menu on your NVMe EFI.
Load OpenShell from OpenCore, then:
- Type fs0: or fs1: depending on whether your EFI is on the first or second NVMe/SSD. If
- Type cd EFI\OC
- Now you can copy files around, eg to restore a backup.
- So if you kept a backup of your config.plist from before you tried the most recent change, you can do something like: cp good.config config.plist to overwrite config.plist with your backup copy (called 'good.config' in this example).
- It will prompt you to confirm the overwrite with Y
- Or, you can directly edit your config with edit config.plist
- Here you can make quick text changes, change a 'true' to 'false' or whatever
- In the editor, the most important hotkeys are:
- Control-E = get help, which lists all the hotkeys
- F1 = go to line number
- F2 = save
- F3 = exit
- F4 = search
- When you're done, type reset and the system will reboot, and your restored/edited config will activate.
If you get into the habit of making a quick backup of your
config.plist within the same EFI folder prior to making any change, it's quick and easy to revert that change via OpenShell. Or for small text changes you can edit them in yourself.
I now use this method quite often when I want to try new changes. It saves having to put up with the boot failure any time I try and boot from USB. It's not quite as good as having Clover's built in config picker and parameter editor, but it's quicker than having to reboot multiple extra times because of the boot failure, and keep having to re-apply BIOS settings each time that happens.