Jump to content
30960 posts in this topic

Recommended Posts

Why not merge the IVYXCPM AppleIntelCPUPM KernelPM to one option named ApplePowerManagement?

 

This 3 options are all for the same point to solve the native powermanagement so why our add more and more options to Clover to make us puzzle?

 

These 3 options are not coexist as common use so why we use some "if" code to judge what cpu use what patch?

 

For example no matter we have any cpus we only need enable ApplePowerManagement option then Clover can make correct patch for correct cpu such as when clover detect snb then use ASUSIntelCPUPM when clover detect ivy then use Ivyxcpm patch when clover detect skl or kbl then use KernelPM and Piker's MSR 0xE2 _xcpm_idle automatically.

 

If someone dont like use this or dont like HWP in skl or kbl they can just disable ApplePowerManagement option so easy.

 

I think the purpose of clover efi bootloader is to simplifly option and make more complex and puzzled option be enabled or disabled automatically.

 

Thanks for all the developers for clover and i suggest merge some puzzled or same function option to one or just make it enable or disable automatically it can make clover more usefull more easy and more convenience。

 

Thanks to everyone!

  • Like 2

That's an entirely different thing all together. That's giving other CPUs that can boot without this patch, the ability to have this patch. This means that the only setting that would matter is KernelIvyXCPM=true, or it uses detection.... I didn't look at your patch but is that what it does or does setting KernelIvyXCPM=false turn off this patch altogether?

 

But for me, xcpm on IVY(i3 3225) cause random reboot. xcpm on IVY Bridge is just an exprtiemential argument and later Apple removed this for i

 

 

Oh god, it's beyond that at this point. Plus just another level of complexity gasoline you're throwing into a wildfire. lol

That's an entirely different thing all together. That's giving other CPUs that can boot without this patch, the ability to have this patch. This means that the only setting that would matter is KernelIvyXCPM=true, or it uses detection.... I didn't look at your patch but is that what it does or does setting KernelIvyXCPM=false turn off this patch altogether?

 

 

 

 

Oh god, it's beyond that at this point. Plus just another level of complexity gasoline you're throwing into a wildfire. lol

apanti, xcpm on i3 3225 cause random reboot. xcpm argument on IVY Bridge is just an exprtiemential product. That's why Apple removed IVY Bridge in 10.12 or later. Enforce xcpm on IVY Bridge is really weird because macOS already supported IVY Bridge perfectly, I see no point to add this boolean to enforce xcpm on IVY Bridge.

 

Experienced hackintoshers can add xcpm patch through kernel patch section manually for IVY Bridge, but for a user, I think better to stick with original AICPUPM on IVY Bridge.

 

Developers have the ability to help user correct something , instead of adding too many options, that will be a disaster and multiple options may very likely interfered each other and make an unstable system.

 

That's my opinion on IVY Bridge xcpm and some duplicated CpuPM options. Should make Clover clean and smart instead of making it looks so complexity for users!

 

Edited: That's why I made EnableExtCpuPM/EnableExtCpuXCPM because we can determine which patches should be applied on different type of CPUs automatically. Even later on merge KernelPM inside it..

 

syscl

  • Like 2

..had to search a bit but also I found the relative code here: http://forge.voodooprojects.org/p/chameleon/source/tree/HEAD/branches/ErmaC/Enoch/i386/libsaio/xml.cI think those 3 functions are compatible with Clover (i guess .. since to me looks like the same in plist.c... ):

 

XMLGenerateKextInjectorFromTag

XMLConvertTagPtrToPropertyList_v1

XMLConvertTagPtrToXMLString

Hi, why not inject it via a dummy info-only kext?

 

Never had to use it: http://www.insanelymac.com/forum/topic/282687-radeon-hd-6770-full-qeci-mlmavericksyosemiteelcapitansierra/

 

I was debugging InfoPlist patching and it should work if made correctly

But there is one problem. If you want to patch IOPCIMatch with your DeviceID then it will not work because the kext is not loaded yet for patching.

For this purpose you have to use FakeID feature in Clover.

 

This current state is occurred only with 10.13 - Previous versions still work fine! (take a look at the link above). I used the same way (boot without cache, debug on yes) to patch my kexts on the fly (AMD5000Controller + AMDRadeonX3000) but it always says AMD5000Controller patched 2 times! and AMDRadeonX3000 not patched!

 

287141291.png

I even cannot use FakeID or inject manually my device-id into Info.plist (S/L/E), while all these methods fork fine with previous macOS versions. Neither DSDT injection method! Always have a black screen!

 

Maybe my macOS install is somehow broken, who knows. I'll try to redo a clean install and try again but I doubt it works.

  • Like 1

Never had to use it: http://www.insanelymac.com/forum/topic/282687-radeon-hd-6770-full-qeci-mlmavericksyosemiteelcapitansierra/

 

 

This current state is occurred only with 10.13 - Previous versions still work fine! (take a look at the link above). I used the same way (boot without cache, debug on yes) to patch my kexts on the fly (AMD5000Controller + AMDRadeonX3000) but it always says AMD5000Controller patched 2 times! and AMDRadeonX3000 not patched!

 

287141291.png

I even cannot use FakeID or inject manually my device-id into Info.plist (S/L/E), while all these methods fork fine with previous macOS versions. Neither DSDT injection method! Always have a black screen!

 

Maybe my macOS install is somehow broken, who knows. I'll try to redo a clean install and try again but I doubt it works.

boot into recovery and kill csr csrutil disable and reboot 10.13 has issues with some older kexts and that solves it

 

 

Sent from my iPhone using Tapatalk

  • Like 1

Why not merge the IVYXCPM AppleIntelCPUPM KernelPM to one option named ApplePowerManagement?

 

This 3 options are all for the same point to solve the native powermanagement so why our add more and more options to Clover to make us puzzle?

 

These 3 options are not coexist as common use so why we use some "if" code to judge what cpu use what patch?

 

For example no matter we have any cpus we only need enable ApplePowerManagement option then Clover can make correct patch for correct cpu such as when clover detect snb then use ASUSIntelCPUPM when clover detect ivy then use Ivyxcpm patch when clover detect skl or kbl then use KernelPM and Piker's MSR 0xE2 _xcpm_idle automatically.

 

If someone dont like use this or dont like HWP in skl or kbl they can just disable ApplePowerManagement option so easy.

 

I think the purpose of clover efi bootloader is to simplifly option and make more complex and puzzled option be enabled or disabled automatically.

 

Thanks for all the developers for clover and i suggest merge some puzzled or same function option to one or just make it enable or disable automatically it can make clover more usefull more easy and more convenience。

 

Thanks to everyone!

Hi,

I guess not only me, but also lots of Clover developers once wanted such clean-ups.

To be honest, the situation is absolutely not that easy like what you claimed. On MSR 0xE2 locked 7-series motherboard with XCPM, we may even need KernelPm + KernelIvyXCPM. This is a case you didn't mention. Anyway it's not the major point. Thing is, nobody really wants to break anything.

For now various parts of power management are still being unknown. So we'd better not do so many changes, at least, right now.

 

Best regards,

PMheart

Maybe something like this helps you?

http://www.insanelymac.com/forum/topic/231075-chameleon-24svn-official-pkg-installer/?p=2365253

  • Like 1

I think users would like auto detection and delete some confusing options. Too many options too complicated, and devs have the ability to judge which cases to use which fixes, instead of leaving users endless messy option.

 

Please sorry for my bad English. that's my two cents opinion.

  • Like 1

I think users would like auto detection and delete some confusing options. Too many options too complicated, and devs have the ability to judge which cases to use which fixes, instead of leaving users endless messy option.

 

Please sorry for my bad English. that's my two cents opinion.

Auto detection is not always possible.

Hackintosh cannot be completely automatic, but instead requires the human brain to make decisions based on the specific problem at hand and the solutions available.

 

XCPM (and related patches) on Ivy is one such perfect example. It is a solution employed only if necessary. The conditions under which it is needed are determined by the human with their hands on the keyboard.

  • Like 8

boot into recovery and kill csr csrutil disable and reboot 10.13 has issues with some older kexts and that solves it

 

 

Sent from my iPhone using Tapatalk

 

Thank you for your suggestion but unfortunately, it did not help.

 

 

I'm already using FakeSMC trick with IOKitPersonalities infos, otherwise it not works. It is why I posted the link to my tuto. No, it is something else but I do not know what.

 

I already had a similar issue on 10.11 and Download-Fritz pointed me to the right way: http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2161396.

 

On 10.12 it works fine (Clover r4084 or 4096, do not remember) but on 10.13 (Clover r4127) it never worked.

Thank you for your suggestion but unfortunately, it did not help.

 

 

I'm already using FakeSMC trick with IOKitPersonalities infos, otherwise it not works. It is why I posted the link to my tuto. No, it is something else but I do not know what.

 

I already had a similar issue on 10.11 and Download-Fritz pointed me to the right way: http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2161396.

 

On 10.12 it works fine (Clover r4084 or 4096, do not remember) but on 10.13 (Clover r4127) it never worked.

kexts not prelinked

apanti, xcpm on i3 3225 cause random reboot. xcpm argument on IVY Bridge is just an exprtiemential product. That's why Apple removed IVY Bridge in 10.12 or later.

 

I guess that explains why KernelIvyXCPM only worked on 10.11.6 here.

 

While we're talking about all this stuff, it would be nice if Clover integrated stinga11's patches for SNB-E. Maybe two-thirds of the config.plist on my X79 consists of the patches that enable this from 10.9-10.13.

  • Like 1

I guess that explains why KernelIvyXCPM only worked on 10.11.6 here.

 

While we're talking about all this stuff, it would be nice if Clover integrated stinga11's patches for SNB-E. Maybe two-thirds of the config.plist on my X79 consists of the patches that enable this from 10.9-10.13.

Hi Riley, I have already included SNB-E patches and Clover can patch it automatically, but I am not sure if this patch in Clover work or not. Please let me know in the r4152+ it work or not. Your report can help Clover to refine this patch (EnableExtCpuPM).

 

Thank you in advance,

syscl

  • Like 1

Hi Riley, I have already included SNB-E patches and Clover can patch it automatically, but I am not sure if this patch in Clover work or not. Please let me know in the r4152+ it work or not. Your report can help Clover to refine this patch (EnableExtCpuPM).

 

Thank you in advance,

syscl

 

I built r4154 and added EnableExtCpuPM to my config but the CPU runs at full speed on boot. Are you sure EnableExtCpuPM is in the current source? I didn't see any mention from a quick look.

I built r4154 and added EnableExtCpuPM to my config but the CPU runs at full speed on boot. Are you sure EnableExtCpuPM is in the current source? I didn't see any mention from a quick look.

Till now there is no EnableExtCpuPM in config.plist because this need devs final decision. So u don't need add this boolean manually, Clover does the patch automatically now. If this not work, could you please provide your config.plist and some log from maclog? I will try to fix it once I back to my house.

 

Thank you,

syscl

  • Like 1

Auto detection is not always possible.

Hackintosh cannot be completely automatic, but instead requires the human brain to make decisions based on the specific problem at hand and the solutions available.

 

XCPM (and related patches) on Ivy is one such perfect example. It is a solution employed only if necessary. The conditions under which it is needed are determined by the human with their hands on the keyboard.

 

 

Hi,

I guess not only me, but also lots of Clover developers once wanted such clean-ups.

To be honest, the situation is absolutely not that easy like what you claimed. On MSR 0xE2 locked 7-series motherboard with XCPM, we may even need KernelPm + KernelIvyXCPM. This is a case you didn't mention. Anyway it's not the major point. Thing is, nobody really wants to break anything.

For now various parts of power management are still being unknown. So we'd better not do so many changes, at least, right now.

 

Best regards,

PMheart

 

 

I want to say does real mac ivy use xcpm?

 

The goal of hackintosh is more and more close to a real mac.

 

Apple dont support xcpm on ivy by default must have it reason and you can force to use xcpm on ivy hackintosh by your self but it would not better make it be the all the ivy hackintosh default option,

 

If this option be added to clover more ivy hacktion users will enable it and anyone can comfirm this patch or xcpm on ivy stable with no bug or problem?

 

I think we would follow apple's rule by default and we can mamually add this xcpm patch by our selves but not add to clover and this is not we considered.

 

My view is just merge the ASUSCPUPM,KernelPM,Haswell-E to one option like ApplePMPatch or just delete these puzzled option because we can detect MSR lock status and detect almost any CPU types by Clover so we can patch these PM patchs by default and we can patch it precision and look this can be done well by clover.

 

Please don't say xcpm on ivy because this is not a real ivy mac devices do and i don't support add this option to Clover or by default and if the xcpm on ivy don't stabel who can be responsible for the mistakes or bugs?if someone like xcpm on ivy very very very very very much they can add xcpm patch for ivy by themselves.

 

Thanks for everyone working on hackintosh project!

Till now there is no EnableExtCpuPM in config.plist because this need devs final decision. So u don't need add this boolean manually, Clover does the patch automatically now. If this not work, could you please provide your config.plist and some log from maclog? I will try to fix it once I back to my house.

 

Here you go. Hopefully this helps.

 

The config still has all the patches I use for my SNB-E so you can see what I've been using up to now. Obviously I removed these before testing.

files.zip

I want to say does real mac ivy use xcpm?

 

The goal of hackintosh is more and more close to a real mac.

 

Apple dont support xcpm on ivy by default must have it reason and you can force to use xcpm on ivy hackintosh by your self but it would not better make it be the all the ivy hackintosh default option,

 

If this option be added to clover more ivy hacktion users will enable it and anyone can comfirm this patch or xcpm on ivy stable with no bug or problem?

 

I think we would follow apple's rule by default and we can mamually add this xcpm patch by our selves but not add to clover and this is not we considered.

 

My view is just merge the ASUSCPUPM,KernelPM,Haswell-E to one option like ApplePMPatch or just delete these puzzled option because we can detect MSR lock status and detect almost any CPU types by Clover so we can patch these PM patchs by default and we can patch it precision and look this can be done well by clover.

 

Please don't say xcpm on ivy because this is not a real ivy mac devices do and i don't support add this option to Clover or by default and if the xcpm on ivy don't stabel who can be responsible for the mistakes or bugs?if someone like xcpm on ivy very very very very very much they can add xcpm patch for ivy by themselves.

 

Thanks for everyone working on hackintosh project!

xcpm pathces not perfect. It means that is not vanilla support. Like you said, ivy cpu not support xcpm. User have to check patch on their system by self. Other xcpm patches too. i mentioned this problem(xcpm patches's perfection) before. i suggested option to disable auto patch. Because auto patch(not pefect) force use on user system. Also we alway have to wait update commit for some patchs related on any os version. If found some patches, wait, wait then rebuild clover and install repeatly.

Ofc like apianti, just goal for boot. Its no problem. Just boot. But still need to check system on each patches and behavior. One of cases, low freqeuncy and high peformance issue. Pike also wrote TO-DO list - low frequency.

 

Ofc auto-patch is useful for normal user. Because no need any option(fakecpuid and kernel patches).

But its not include that optimize patch and pass check kernel patch and minimize kernel patch on user system and bios setting by check one by one.

 

Because of these reasons, i suggested option for coder and advanced user and developer on clean kernel status(vanilla, dont touched) before.

I hope don't misunderstand developer. Just my think is summary. I will not write this think again.

 

Sorry for my bad english.

 

Thanks

-Sherlocks

 

 

 

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 2

xcpm pathces not perfect. It means that is not vanilla support. Like you said, ivy cpu not support xcpm. User have to check patch on their system by self. Other xcpm patches too. i mentioned this problem(xcpm patches's perfection) before. i suggested option to disable auto patch. Because auto patch(not pefect) force use on user system. Also we alway have to wait update commit for some patchs related on any os version. If found some patches, wait, wait then rebuild clover and install repeatly.

Ofc like apianti, just goal for boot. Its no problem. Just boot. But still need to check system on each patches and behavior. One of cases, low freqeuncy and high peformance issue. Pike also wrote TO-DO list - low frequency.

 

Ofc auto-patch is useful for normal user. Because no need any option(fakecpuid and kernel patches).

But its not include that optimize patch and pass check kernel patch and minimize kernel patch on user system and bios setting by check one by one.

 

Because of these reasons, i suggested option for coder and advanced user and developer on clean kernel status(vanilla, dont touched) before.

I hope don't misunderstand developer. Just my think is summary. I will not write this think again.

 

Thanks

-Sherlocks

 

 

 

나의 LG-F800S 의 Tapatalk에서 보냄

 

My mean is we can make clover more simple and easy to use and now clover can do it.

 

Although in the pas the xcpm patch are in the clover code if xcpm patch outdate we add new patch to clover code and now we just merge these option to one option there is no different with past.

 

And i dont say it is bad for ivy users to use xcpm,we can choose any way such as cpupm or xcpm we like but if this way is not support by apple by default and we force to use it such as xcpm on ivy we would better not add these option to clover or just by default because it may have potential risks or bugs so if someone like some function not be supported by apple such as xcpm on ivy bridge we can add it by ourselves if someone like and i do not deny any effort and development on xcpm on ivy.

 

Thanks.

  • Like 2

kexts not prelinked

 

They are!

CFBundleIdentifier[273].......: com.apple.kext.AMDRadeonX3000
_PrelinkBundlePath............: /System/Library/Extensions/AMDRadeonX3000.kext
kextPath......................: kexts/System/Library/Extensions/AMDRadeonX3000.kext
_mkdir(kexts/System/Library/Extensions/AMDRadeonX3000.kext, 755)
_PrelinkExecutableRelativePath: Contents/MacOS/AMDRadeonX3000
kextExecutablePath............: kexts/System/Library/Extensions/AMDRadeonX3000.kext/Contents/MacOS
_mkdir(kexts/System/Library/Extensions/AMDRadeonX3000.kext/Contents/MacOS, 755)
CFBundleIdentifier............: AMDRadeonX3000
_PrelinkExecutableSourceAddr..: 0xffffff8002a30000 -> 0x28b8000/42696704 (offset)
_PrelinkExecutableSize........: 0x644000/6569984
executablePath................: kexts/System/Library/Extensions/AMDRadeonX3000.kext/Contents/MacOS/AMDRadeonX3000
Executable....................: AMDRadeonX3000 (6569984 bytes written)
kextPlistPath.................: kexts/System/Library/Extensions/AMDRadeonX3000.kext/Info.plist
Info.plist....................: 2175 bytes written

CFBundleIdentifier[274].......: com.apple.kext.AMDLegacySupport
_PrelinkBundlePath............: /System/Library/Extensions/AMDLegacySupport.kext
kextPath......................: kexts/System/Library/Extensions/AMDLegacySupport.kext
_mkdir(kexts/System/Library/Extensions/AMDLegacySupport.kext, 755)
_PrelinkExecutableRelativePath: Contents/MacOS/AMDLegacySupport
kextExecutablePath............: kexts/System/Library/Extensions/AMDLegacySupport.kext/Contents/MacOS
_mkdir(kexts/System/Library/Extensions/AMDLegacySupport.kext/Contents/MacOS, 755)
CFBundleIdentifier............: AMDLegacySupport
_PrelinkExecutableSourceAddr..: 0xffffff8003074000 -> 0x2efc000/49266688 (offset)
_PrelinkExecutableSize........: 0x12f000/1241088
executablePath................: kexts/System/Library/Extensions/AMDLegacySupport.kext/Contents/MacOS/AMDLegacySupport
Executable....................: AMDLegacySupport (1241088 bytes written)
kextPlistPath.................: kexts/System/Library/Extensions/AMDLegacySupport.kext/Info.plist
Info.plist....................: 2494 bytes written

CFBundleIdentifier[275].......: com.apple.kext.AMD5000Controller
_PrelinkBundlePath............: /System/Library/Extensions/AMD5000Controller.kext
kextPath......................: kexts/System/Library/Extensions/AMD5000Controller.kext
_mkdir(kexts/System/Library/Extensions/AMD5000Controller.kext, 755)
_PrelinkExecutableRelativePath: Contents/MacOS/AMD5000Controller
kextExecutablePath............: kexts/System/Library/Extensions/AMD5000Controller.kext/Contents/MacOS
_mkdir(kexts/System/Library/Extensions/AMD5000Controller.kext/Contents/MacOS, 755)
CFBundleIdentifier............: AMD5000Controller
_PrelinkExecutableSourceAddr..: 0xffffff80031a3000 -> 0x302b000/50507776 (offset)
_PrelinkExecutableSize........: 0x1b6000/1794048
executablePath................: kexts/System/Library/Extensions/AMD5000Controller.kext/Contents/MacOS/AMD5000Controller
Executable....................: AMD5000Controller (1794048 bytes written)
kextPlistPath.................: kexts/System/Library/Extensions/AMD5000Controller.kext/Info.plist
Info.plist....................: 2434 bytes written

All is good here  latest Clover r4154

Sierra, HSierra and even in old  System like Mac OS X Lion 10.7.5

Big thanks to all Coder and Devs for the work

my i5-2500K Sandy Bridge Quad-Core 3.3GHz (3.7GHz Turbo Boost) Intel HD 3000 works well

no probleme before the patch and after  :) 

 

 

 

sans_t29.jpg

 

 

  • Like 1

I want to say does real mac ivy use xcpm?

No.

But XCPM on Ivy is a useful feature when AppleIntelCPUPowerManagement will not work properly (certain CPUs, likely mismatch with data in X86PlatformPlugin plists).

  • Like 2

They are!

Then I can suppose that something mismatch with Find and Replace... but is easy to discover if you post your prelinkedkernel. An Info.plist inside the Prelinked dictionary is not the same inside the bundle on the filesystem (missing tabs '\t', no line feeds '\n', different tags with 'IDREF' etc..). So opening the Info.plist with a hex editor can deceive you, imho.

I want to say does real mac ivy use xcpm?

 

The goal of hackintosh is more and more close to a real mac.

 

Apple dont support xcpm on ivy by default must have it reason and you can force to use xcpm on ivy hackintosh by your self but it would not better make it be the all the ivy hackintosh default option,

 

If this option be added to clover more ivy hacktion users will enable it and anyone can comfirm this patch or xcpm on ivy stable with no bug or problem?

 

I think we would follow apple's rule by default and we can mamually add this xcpm patch by our selves but not add to clover and this is not we considered.

 

My view is just merge the ASUSCPUPM,KernelPM,Haswell-E to one option like ApplePMPatch or just delete these puzzled option because we can detect MSR lock status and detect almost any CPU types by Clover so we can patch these PM patchs by default and we can patch it precision and look this can be done well by clover.

 

Please don't say xcpm on ivy because this is not a real ivy mac devices do and i don't support add this option to Clover or by default and if the xcpm on ivy don't stabel who can be responsible for the mistakes or bugs?if someone like xcpm on ivy very very very very very much they can add xcpm patch for ivy by themselves.

 

Thanks for everyone working on hackintosh project!

If this is really the goal, then I think some features like injecting _DSM or InjectKexts simply break it. (Real Macs use EFI String properties, and all 3rd-part kexts are under /L/E as of 10.11)

I never let it be the default option, but just added a boolean, for desired user to choose.

These patches were for sure confirmed to work, I just gathered them from https://github.com/al3xtjames/Gigabyte-GA-Z77X-macOS-Install/blob/master/config/config_main.plist#L125, and at least on my case and @theracermaster's case, it worked fine. All other things that will suck would be MSR 0xE2 bit 15 lock, then simply turn on KernelPm.

Why didn't you propose to deprecate KernelCPU then? If the patches made you confused.

That's just not that easy, if not, Clover would do this at an earlier time.

Adding such option is not my decision but Clover developers'. If I did wrong work then they shall simply never add it.

 

Sincerely,

PMheart

My mean is we can make clover more simple and easy to use and now clover can do it.

 

Although in the pas the xcpm patch are in the clover code if xcpm patch outdate we add new patch to clover code and now we just merge these option to one option there is no different with past.

 

And i dont say it is bad for ivy users to use xcpm,we can choose any way such as cpupm or xcpm we like but if this way is not support by apple by default and we force to use it such as xcpm on ivy we would better not add these option to clover or just by default because it may have potential risks or bugs so if someone like some function not be supported by apple such as xcpm on ivy bridge we can add it by ourselves if someone like and i do not deny any effort and development on xcpm on ivy.

 

Thanks.

So you should definitely create your own fork of Clover, and remove all features that you have no need, above all, my utterly stupid changes, this is the most reasonable choice I guess.

If just one option, then the situation becomes catastrophic... Just like I said.

If you really think so, then please post something to stop developing AMD kernels, because Apple doesn't support AMD CPU... Any instrument can be dangerous in improper hands. What's more I never let XCPM on Ivy Bridge become mandatory.

Thanks. I didn't dig too deep into getting XCPM working on my laptop once AICPUPM worked fine. But now I have it working with a single config.plist entry :)

 

Well, it's working in 10.11.6, but not in 10.12.6 or 10.13 PB. Maybe I'm missing something else.

Hi, oops! I know why! When I was merging the changes, I forgot to add a call to KernelIvyBridgeXCPM

 

@Sherlocks Please commit the new kernel_patcher.c and it would be fine then, thanks!

 

Final EDIT: These ones should be ok, confirmed.

 

kernel_patcher.c.zip

 

Binaries:

working_4154.zip

  • Like 3
×
×
  • Create New...