Power Management Findings--Good News

[makk]

After reading through Slices new updates, he mentioned KernelPM.

 

When booting previously in OpenCore, I used CPUFriend and CPUFfriendDataProvider.kext to have independent CPU power management.

SSDT-PLUG.aml replaced with ssdt_data.aml.

It works on this hardware.

 

So I disabled KernelPM in Clover and it boots up using CPUFriend.kext and CPUFriendDataProveder.kext along with ssdt_data.aml as PLUG, to manage Power

XPCM mode independent of the KernelPM in config.plist.

 

PluginType set in config.plist. Drop PtidDevc in DropTables,

select PluginType to insure XPCMx86 Power management viewable in IOREG.

 

https://github.com/acidanthera/CPUFriend

 

https://github.com/corpnewt/CPUFriendFriend < to get the script to make CPUFriendDataProvider.kext and ssdt_data.aml <which replaces SSDT-PLUG.aml.

 

if you have CPUFriend.kext and CPUFriendDataProvider.kext, you may choose to omit a SSDT-PLUG-ALT, or SSDT-PLUG.

 

In short what this does is creates an independent from Kernel Power Management setting in Clover. No need for KernelPM enabling.

 

It is a Lilu Plugin so need Lilu.kext to work.  

 

This system is a Broadwell U 

 

This post is generated and reference is for newer than Sandybridge Haswell Ivybridge.

 

For Sandybridge and those older than Broadwell read the instructions to get this to work.

Read the instructions to get this to work regardless.

 

A LiluFriend is also referenced but, you choose.

 

It is customizable with CPUFriendFriend script.  And it saves quite a bit of worrying about Power Management.

 

In the config.plist ACPI settings for SSDT>Generate>PluginType set to true

DropTables>PtidDevc

No OEM

 

Place CPUFriend.kext in folder Kexts and reboot, clear NVRAM F11.

Run the CPUFriendFriend script

Select the CPU type and select the mode.

Must be precise or you will have anomalies in Desktop mode.

Place in the CPUFriendDataProvider.kext in Kexts Folder, reboot.

Clear NVRAM F11.

 

Sometimes you have to shutdown completely to drain the memory and then boot up. NVRAM could be flooded and not able to refresh appropriately.

changes take a bit a reboots to refresh. Lingering around.

 

 

 

 

 

 

 

[makk]

16 hours ago, Hervé said:

KernelPM does not enable/activate CPU power management in any way if that's what you thought. It's a kernel patch to prevent Haswell & later systems with locked MSR 0xE2 register (aka CFG lock) from experiencing KP at boot time in ML 10.8.5 and later. ML 10.8.5 introduced support for Haswell platforms for which CPU power management moved to the kernel (this extending to subsequent platform generations). At that time, it was then found out that the kernel seeked to write into MSR 0xE2 register for CPU PM purposes. This caused a KP for systems for which this register is locked by BIOS, something quite generalised. The patch prevents such write access attempt and therefore avoids KP.

 

For previous Intel generations (C2D, 1st gen Core, Sandy Bridge, Ivy Bridge), CPU power management was retained through AICPUPM kext.

 

Thank you that's good to know.

 

ok, so what enables this for  Broadwell to unlock msrs?

 

Probably should change the name to say what it is.

 

Like Unlock MSR

[makk]

8 hours ago, Hervé said:

The patch had carried its name for nearly 10 years, I think it'll stay that way...

And no, the patch does not unlock MSR 0xE2, read my previous reply.

<key> KernelPM </key>

<false />

It turns out that since 10.9 there is some CPUPM management built right into the kernel. This patch prevents kernel panic when 0xE2 is locked in BIOS.

[makk]

5 minutes ago, makk said:

<key> KernelPM </key>

<false />

It turns out that since 10.9 there is some CPUPM management built right into the kernel. This patch prevents kernel panic when 0xE2 is locked in BIOS.

 

https://drovosek01.github.io/CloverHackyColor-WebVersion/english/from Word/Clover_Of_Khaki_Color_eng_5129.htm#_bookmark183

 

 

 

[makk]

<key> KernelPM </key>

<false />

It turns out that since 10.9 there is some CPUPM management built right into the kernel. This patch prevents kernel panic when 0xE2 is locked in BIOS.

 

KernelPM does not enable/activate CPU power management in any way if that's what you thought. It's a kernel patch to prevent Haswell & later systems with locked MSR 0xE2 register (aka CFG lock) from experiencing KP at boot time in ML 10.8.5 and later. ML 10.8.5 introduced support for Haswell platforms for which CPU power management moved to the kernel (this extending to subsequent platform generations). At that time, it was then found out that the kernel seeked to write into MSR 0xE2 register for CPU PM purposes. This caused a KP for systems for which this register is locked by BIOS, something quite generalised. The patch prevents such write access attempt and therefore avoids KP.

 

For previous Intel generations (C2D, 1st gen Core, Sandy Bridge, Ivy Bridge), CPU power management was retained through AICPUPM kext.

[makk]

AppleRTC 

 

<key> AppleRTC </key>

<true />

The OSX operating system somehow does not work with CMOS as it is provided by the BIOS, as a result, when you wake up from sleep or when you reboot, the CMOS is reset. Not everyone has motherboards from Gigabyte in this sin. Moreover, often this problem is solved simply by patching DSDT: Device (RTC), which Clover does.

But, in some cases this patch does not help either. Then you can correct the AppleRTC kext itself, which is done here.Deprecated! vit9696 investigated the problem, and corrected RTC operations in Clover, now the recommended key value is <false />, since it affects hibernation. Although, a moot point, my hibernation key is still saved in NVRAM.

 

So turn this to disable or false