CFG Lock is a BIOS setting that allows writing to a specific register, in this case MSR E2 (MSR = Model Specific Register). An MSR consists of one or more registers in blocks of instructions used to do certain tasks on a CPU. MTRs are also used to control CPU's access to memory ranges. Commands capable of reading and writing to MSR work with elevated privileges (the operating system, primarily).
Many motherboards come from factory with MSR E2 region locked (read but not write) and quite a few of them even hide this option in BIOS user interface. In those that do show the option to block or unblock this variable, it is usually called CFG Lock. CFG Lock is a bit with 2 values, 0x1 or 0x0. When it is 0x1, macOS cannot write into this region and kernel patches are required.
macOS wants to write this registry, both the Kernel and AppleIntelPowerManagement. It defines the C-states of the CPU, which is why it is essential for macOS. Without the ability to write to MSR E2, all or most of the CPU power management is lost and the system does not boot.
In Clover 2 patches have been used: KernelPM (for AppleIntelPowerManagement.kext) and KernelXCPM (for the kernel). In OpenCore 2 others have been used: AppleCpuPmCfgLock (for AppleIntelPowerManagement.kext) and AppleXcpmCfgLock (for the kernel). These patches fix the problem but the registry is still read-only. To ensure native CPU power management, CFG Lock bit must be set to 0x0.
To achieve this, the firmware must be modified to support writing to MSR E2. This method is preferred over Clover and OC patches, it generates greater system stability and the CPU power management more closely resembles that of a real Mac. The methods that are usually proposed for this task are too complex for most users who do not have a high level of knowledge, requiring specialized tools and even modified Grub.
Below I comment on an alternative method that is much simpler and that, at least in my case, seems to have been successful. Like any of the methods that modify this bit, it has the risk of not working or even damaging the BIOS, so if you try it it is under your entire responsibility.
User @Brumbaer has a tool called CFGLock.efi (see post). It is an EFI application, it has to be installed in OC Tools folder (Misc - Tools in config.plist) and in this way it is available in the OC menu next to Reset NVRAM. It should be accompanied by another tool included in the OC package called VerifyMsrE2.efi that reports current status of CFG Lock (locked / unlocked).
When CFGLock.efi runs, it displays information (CFG variable found, varstore in which it resides, current reading and requests user intervention to make the change from 0x1 to 0x0 or vice versa). Then you have to restart. With VerifyMsrE2.efi we can check if the change has been successful.
Both EFI applications can be run by selecting them directly in the OC menu but it is also possible, by installing OpenShell.efi tool, to run this shell and running them from there. Information for handling OpenShell.efi is available in OC and elsewhere.
I have tried CFGLock.efi and apparently it has worked well.
I have installed MacOS and Windows on the following hardware:
AMD Ryzen 7 3700X
MSI B450M Mortar Max
Sapphire Radeon Pulse RX 5600 XT 6G
Samsung 860 QVO, 1 TB SSD (PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x1)/Sata(0x5,0xFFFF,0x0)) - MacOS on this disk
Kingston A2000 SSD 1TB M.2 2280 NVMe (PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,15-AD-CD-26-28-B7-26-00)) - Windows on this disk
both disks GPT
Both OSs boot nicely and work as a charm when selecting either of the disks as boot disks in the BIOS.
However, trying to boot Windows 10 from the Opencore Bootmanager (no matter whether PickerMode=internal or OpenCanopy) causes a Windows Blue Screen ("SYSTEM THREAD EXCEPTION NOT HANDLED").
To be on the safe side, I have added an appropriate entry to Misc->Entries:
<string>Not signed for security reasons</string>
It points to the Windows 10 bootmanager on the Windows disk's EFI partition.
What's wrong with that? Why does this cause a BSOD? It is not clear to me why it works when booting from BIOS but not here.
config.plist attached (but maybe it has no relevance for the problem).
So I have my Windows computer, used a USB with Clover setup to boot into Mojave OS that I installed on the SD card in the computer. The world was a great place and all was well!
Then I did the steps to partition the pc system to now include the additional drive that I would put Clover on. Here's where I messed up: Instead of directly copying over the full Clover folder into the EFI folder of the new drive (which just had the Boot & Microsoft folders in it), I replaced the EFI's boot folder with Clover's boot folder. So the EFI folder now contains a Microsoft folder, a Clover folder, and Clover's Boot folder only.
Now, I only can access the Clover boot up menu, the macOS, but no Windows at all. Even if I go into BIOS and pick Windows Boot Manager or Partition 1 for the start up, I get a black screen for both. I can still access the macOS as well as Shell, but I don't know what that does other than displaying all of the yellow text fly by..
Is there a kind soul out there that can help me get Windows back to boot? Keep in mind I'm a bit of a newbie here so laying out the common-sense steps would be helpful!
Hello everyone, i just want to ask something. why is it that my radeon hd 7770 graphic card was detected as "Latte" gpu instead of verde when using radeon_bios_decode? is the card actually a Latte graphic card but someone flashed it so they can sold to me as radeon hd 7770? or is it actually a real radeon hd 7770 but the tool falsely detected it as latte cpu?