- Joined
- Mar 6, 2013
- Messages
- 266
- Motherboard
- Gigabyte X299X Designare 10G
- CPU
- i9-10980XE
- Graphics
- AMD 6900XT
- Mobile Phone
OK sounds like you're in the same position as the rest of us then.
Regarding the RAM speed reset: this is an expected result of the boot failure issue, which happens if :
a) You boot OpenCore from the F12 boot menu, BIOS boot override menu, or after having been in the BIOS and then "Exit without saving"
and/or
b) You boot with two or more OpenCore bootloaders visible, for example one OpenCore partition on your NVMe and then a second on a USB drive. Possibly non-OpenCore bootloaders might also trigger it, eg Linux. But Windows does not appear to in my own testing.
Either scenario (and possibly others) will trigger the dreaded curse of this motherboard, which is that you will get an automatic shutdown 10 seconds after the boot starts (regardless of what is happening at that time), and then when the system comes back up your CPU and RAM will be at default frequencies. You'll only notice the difference regarding CPU if you were overclocking, but RAM is much more noticeable because most people enable XMP.
Once that's happened once, you can then continue to boot OpenCore even in the above conditions, until such time as you re-save BIOS settings with F10 in the BIOS. This means that your RAM will be stuck at non-XMP speeds.
So, to get your RAM working, first go into the BIOS and make sure you have XMP enabled, then re-apply your settings with F10. From that point onwards, make sure you follow these rules:
This means that booting temporarily from USB is a two-step process: Go into the BIOS and boot the USB from Boot Override; 10 seconds later it reboots; go back into the BIOS and boot USB from Boot Override again; this time it works; some time later, when you're done with the USB, go back into the BIOS and re-apply your settings with F10 to get XMP Working again; reboot, and now you can boot normally from your main NVMe drive.
This is all a major pain but there's currently no known fix, and my feeling is that there probably won't be a fix. It's a BIOS bug. Given it doesn't happen with Windows it's theoretically possible that some change to OpenCore could avoid it, but that's going to require help from an OpenCore dev and I'm not holding out my hopes that we'll be able to get that.
As mentioned in previous posts I'm working on an OpenCore config that will enable easy dual-boot of macOS and Windows, and won't trigger this issue. Once we have that, at least we'll have smooth dual booting of those OS and at that point the bug shouldn't really happen again, except if you ever find yourself needing to temporarily boot from USB for some fix or test.
I've been having some trouble getting all the SSDTs working right, and I diverted onto investigating sleep over the last 24 hours. But I'll be looking at SSDTs again tomorrow so hopefully I'll have an EFI to share in the next day or two.
In the meantime, here's the BIOS config I promised a while ago. This is for BIOS version F3C. It's very simple, and probably matches what you already have. But you can install this as a safe guard that you have things setup OK. It has the settings required for macOS boot and Thunderbolt, C-States Enabled on C6, and mostly everything else on Auto. Note that XMP will be disabled, so you'll need to manually enable that.
Regarding the RAM speed reset: this is an expected result of the boot failure issue, which happens if :
a) You boot OpenCore from the F12 boot menu, BIOS boot override menu, or after having been in the BIOS and then "Exit without saving"
and/or
b) You boot with two or more OpenCore bootloaders visible, for example one OpenCore partition on your NVMe and then a second on a USB drive. Possibly non-OpenCore bootloaders might also trigger it, eg Linux. But Windows does not appear to in my own testing.
Either scenario (and possibly others) will trigger the dreaded curse of this motherboard, which is that you will get an automatic shutdown 10 seconds after the boot starts (regardless of what is happening at that time), and then when the system comes back up your CPU and RAM will be at default frequencies. You'll only notice the difference regarding CPU if you were overclocking, but RAM is much more noticeable because most people enable XMP.
Once that's happened once, you can then continue to boot OpenCore even in the above conditions, until such time as you re-save BIOS settings with F10 in the BIOS. This means that your RAM will be stuck at non-XMP speeds.
So, to get your RAM working, first go into the BIOS and make sure you have XMP enabled, then re-apply your settings with F10. From that point onwards, make sure you follow these rules:
- Never boot OpenCore from the F12 boot menu or BIOS Boot Override menu.
- Any time you go into the BIOS, always either hit F10 to save, or else power down or hit the restart button; never exit the BIOS with "Exit Without Saving"
- When booting, do not have two or more OpenCore partitions visible to the BIOS at one time. Meaning that if you have one on your NVMe drive, make sure you don't also have a USB stick or another drive with another OpenCore partition.
- Windows bootloader partitions do not trigger the issue, at least in my experience.
This means that booting temporarily from USB is a two-step process: Go into the BIOS and boot the USB from Boot Override; 10 seconds later it reboots; go back into the BIOS and boot USB from Boot Override again; this time it works; some time later, when you're done with the USB, go back into the BIOS and re-apply your settings with F10 to get XMP Working again; reboot, and now you can boot normally from your main NVMe drive.
This is all a major pain but there's currently no known fix, and my feeling is that there probably won't be a fix. It's a BIOS bug. Given it doesn't happen with Windows it's theoretically possible that some change to OpenCore could avoid it, but that's going to require help from an OpenCore dev and I'm not holding out my hopes that we'll be able to get that.
As mentioned in previous posts I'm working on an OpenCore config that will enable easy dual-boot of macOS and Windows, and won't trigger this issue. Once we have that, at least we'll have smooth dual booting of those OS and at that point the bug shouldn't really happen again, except if you ever find yourself needing to temporarily boot from USB for some fix or test.
I've been having some trouble getting all the SSDTs working right, and I diverted onto investigating sleep over the last 24 hours. But I'll be looking at SSDTs again tomorrow so hopefully I'll have an EFI to share in the next day or two.
In the meantime, here's the BIOS config I promised a while ago. This is for BIOS version F3C. It's very simple, and probably matches what you already have. But you can install this as a safe guard that you have things setup OK. It has the settings required for macOS boot and Thunderbolt, C-States Enabled on C6, and mostly everything else on Auto. Note that XMP will be disabled, so you'll need to manually enable that.
Attachments
Last edited: