Contribute
Register

[Release] Hackintool v3.x.x

Can you tell me in details how to do it?
 
My hackintool generated two DisplayEDID.kext on my desktop.
Do I need both to be in EFI/CLOVER/kexts/Other?

PS.
The image I attached is the result that I placed two DisplayEDID.kext into EFI/CLOVER/kexts/Other
But it doesn't look right.
 

Attachments

  • 1.png
    1.png
    1.1 MB · Views: 183
Can you please run Hackintool (Hackintool.app/Contents/MacOS/Hackintool) from Terminal and perform the same task causing the crash and paste any errors printed to the Terminal screen here.

I re-ran v2.2.5 and had no crashes when downloading KEXT files. (But I also found this weekend that I had a corrupted boot drive, which I fixed before re-running the test with v2.2.5.)

Thanks for you hard work!
 
I placed two DisplayEDID.kext into EFI/CLOVER/kexts/Other
Try clicking on the 'i' icon to get instructions on where to place them. Hopefully the help is working in other languages now.
 
So I just get the
Missing Xcode Tools. Open Terminal and run

xcode-select --install
error when I try to compile Lilu plugins, but it's already installed. Running the command gives the error:
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
 
Hackintool v2.2.6 Released
- Improved Boot EFI detection
- Set Boot EFI manually
- AppleIntelInfo shows 30 second timer to log CStates. Restores HWP state after logging. Added Intel Regs warning
- Calculator now shows reverse bytes

@shuhung @DimitrisG please let me know if HWP state is restored correctly after logging.
 
Last edited:
Hackintool v2.2.6 Released
- Improved Boot EFI detection
- Set Boot EFI manually
- AppleIntelInfo shows 30 second timer to log CStates. Restores HWP state after logging. Added Intel Regs warning
- Calculator now shows reverse bytes

@shuhung @DimitrisG please let me know if HWP state is restored correctly after logging.

No, stuck at highest frequency.
When XCPM is on, enable 0x770 HWP will caused above issue.
For supported Core series CPU, HWP feature need called by XCPM.
For unsupported Pentium CPU, XCPM not native enabled then it will work correctly.

Tested with i3 7100, stuck at highest frequency.
Tested with Pentium G4560 without XCPM, work perfectly, everything OK.

Edit: For supported CPU, HWP feature should called by XCPM, part of frequency vector table.
400528
 
Last edited:
No, stuck at highest frequency.
When XCPM is on, enable 0x770 HWP will caused above issue.
For supported Core series CPU, HWP feature need called by XCPM.
For unsupported Pentium CPU, XCPM not native enabled then it will work correctly.

Tested with i3 7100, stuck at highest frequency.
Tested with Pentium G4560 without XCPM, work perfectly, everything OK.

Edit: For supported CPU, HWP feature should called by XCPM, part of frequency vector table.
View attachment 400528

Looking this up I found the following:
HWP_ENABLE (bit 0, R/W1Once) — Software sets this bit to enable HWP with autonomous selection. When
set, the processor will disregard input from the legacy performance control interface (IA32_PERF_CTL). Note
this bit can only be enabled once from the default value. Once set, writes to the HWP_ENABLE bit are ignored.
Only RESET will clear this bit. Default = zero (0).
So it appears that once it's enabled it can't be disabled without rebooting the PC. I've committed v2.2.8 and added a warning when enabling HWP state logging.
 
Last edited:
Looking this up I found the following:

So it appears that once it's enabled it can't be disabled without rebooting the PC. I've committed v2.2.8 and added a warning when enabling HWP state logging.

Put system to sleep will reset 0x770 to 0.

It is useful for HWPEnabler or Clover HWPEnabler (Pentium CPU without native XCPM enable) user, now Hackintool can used for resume HWP functional after wakeup.
 
Back
Top