7 posts in this topic
Recently Browsing 0 members
No registered users viewing this page.
What is CFG Lock and MSR 0xE2?
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.
macOS boots up and works fine with the OC patches AppleCpuPmCfgLock and AppleXcpmCfgLock disabled.
VerifyMsrE2.efi reports "This firmware has UNLOCKED MSR 0XE2 register!".
Hackintool in Utilities - Get AppleIntelInfo displays this text: AppleIntelInfo.kext v3.0 Copyright © 2012-2017 Pike R. Alpha. All rights reserved. IA32_MISC_ENABLES................(0x1A0) : 0x850089 ------------------------------------------ - CFG Lock............................. : 0 (MSR not locked) Note: Hackintool current version (3.4.6) doesn't show text after Get AppleIntelInfo in Big Sur beta 10. It's got from Catalina.
Intel Power Gadget - Frequency graph shows variations between maximum and minimum suggestive of CPUPM.
I would like to ask for some advice or help even.
I have had some usability issues in the past with my hackintosh so I installed Mojave for the second time but it keeps producing the same exact problem. Most of the time the system stutters and lags after login. The app icons just bounce if I want to open them and even if it does it takes forever. Another thing I picked up on is that it seems like there's no internet access whenever this occurs. The problem ceases after like 2-3 restarts and everything is back to normal.
What could cause an issue like this? I had the same thing happening with my previous install but I thought that was because of unnecessary kexts I left in the EFI. I only have the bare minimum required this time so I'm kinda lost.
Mobo: Gigabyte B360M D3H
Graphics: Radeon Vega 64 8OC
CPU: Intel i7 8700k
Ram: 32 Gig
SSD: Samsung Evo 860 250gb
I also have a separate HDD with Windows 10 installed for gaming purposes. I would greatly appreciate any kind of help, thanks in advance!
I have an old Hackintosh that I have brought back to life. An ASUS P5KPLAM-SE mobo, Intel Core 2 Quad, with a Sapphire HD 5670 1GB graphics card. It used to work just fine on High Sierra 10.13.3 (I think it was .3) However I only used the DVI port. Updated to 10.13.6 and with AMD kexts rollback to the previous versions I got everything o wrk just fine: boot, HDMI video, HDMI audio etc etc. The only problem I face is that my USB keyboard and mouse freeze/hang seemingly very random... I can not seem to get it right. Unplugging and replugging the USB device makes it work again, sometimes for a few seconds sometimes for an hour ... No idea what's wrong... Have tried tons of options in clover, USBInjectall.kext with port limit patch, whatever I could find... Would there be anyone out there who would have an idea of what could be the problem?
*This guide is deprecated and will not be maintained anymore*
Update: Now running Mojave! Thanks to mojave2core! Yeah Still using C2D in 2019!
Inserted a nice and cheap GT710 that is not relying on nVidias Webdrivers and runs OOB under Mojave.
Nice, seeing High Sierra running on this old but capable system! It rocks with a new ASUS GT1030
6 GB DDR2 RAM
Asus GT1030 2GB
Sandisk SSD 128GB
TP-Link AC1200 Wifi USB
Inateck KT4006 USB 3.0 PCIe (No boot)
Clover: 4297 4360
A good deal of DSDT editing was necessary to get this machine to boot High Sierra but finally it works flawlessly, even sleep and wake!
You NEED to have the DSDT put in place for installation because otherwise macOS doesn't recognize the SATA ports.
There are a few important BIOS settings: SATA hast to be set to AHCI and "native" and HPET has to be run "64-bit", I'd recommend to disable IDE and the serial and parallel port.
For the GT1030 nVidia Webdrivers are needed, have to boot with nv_disable=1 until you have them installed.
You have to install Clover in legacy mode because this old fella does not support UEFI.
Only downside: The so often recommended Inateck USB-card isn't recognized by BIOS, so you cannot boot from it. It works perfectly within macOS though, have the ac-Wifi connected to it.
I managed to install Mojave on my MSI GP62-6QE laptop with somewhat success. The only annoying thing left is that everytime I shut it down it seemingly kernel panics and I get the "Your computer has restarted because of a problem" at startup.
I tried many different things such as removing emuvariablesuefi64, checking FixShutdown in CloverConfig but it seems the NVRAM is causing this issue.
I have deleted the nvram file from the EFI partition but it seems stuck somewhere else, I can't clear out the nvram from the terminal or in single user mode as it returns a "Not permitted" error.
Clearing out the nvram by pressing F11 at the boot menu screen works however.