Contribute
Register

Big Sur on HP EliteDesk 800 G4/G5 Mini - The Perfect MacMini8,1 Hackintosh - OpenCore

Status
Not open for further replies.
@stormblessed The EliteDesk Minis with 65w CPUs have a copper heatsink, a SATA cooling fan (a cooling fan in the SATA drive caddy - in addition to the CPU cooling fan) and at least a 90w power supply. If you review GeekBench scores for i9 and i7, I don't believe you'll see enough of a difference to justify the price. By the time you purchase the copper heatsink, SATA drive fan and PSU, you might wish that you had just purchased another used Mini and sold your current one.

Now that you have completed your install, do you have any comments / suggested revisions for the instructions here?
 
@stormblessed The EliteDesk Minis with 65w CPUs have a copper heatsink, a SATA cooling fan (a cooling fan in the SATA drive caddy - in addition to the CPU cooling fan) and at least a 90w power supply. If you review GeekBench scores for i9 and i7, I don't believe you'll see enough of a difference to justify the price. By the time you purchase the copper heatsink, SATA drive fan and PSU, you might wish that you had just purchased another used Mini and sold your current one.

Now that you have completed your install, do you have any comments / suggested revisions for the instructions here?
Thanks! I didn't know I would also need to get a Sata Fan, I thought that the copper heatsink would do the job. One thing that is triggering me, I removed the sata HDD slot to use two ssd NVME. The ssd temperature is nearly the CPU temperature, which is 60 degrees and sometimes it jumps to 70. Never seen a SSD get this hot before. When I'm well settled the CPU get's around 60 degrees and the ssd 50-52. But still, on my desktop and laptop the max i've seen was 40-48 degrees I think.
About the instructions, it's all good! it was my fault I skimmed. But to make it more user friendly I'd say you could put a post install guide with pictures. But then, it's already so well detailed, I'm not sure if it would be good or just an overkill.
Once again, i've never had a hackintosh so well configured and working as this one. Thanks!
Edit: Picture, I put it on some thermalpad I had just waiting to be used, but I forgot that I would need some metal on it to make it work, haha. So I removed it afterwards.
 

Attachments

  • WhatsApp Image 2021-03-31 at 21.00.50.jpeg
    WhatsApp Image 2021-03-31 at 21.00.50.jpeg
    125.1 KB · Views: 78
Last edited:
@stormblessed - I'll proof read your post install guide when you post it ;)

The 65W Minis have access panels (top covers) with vent holes. The 35W minis that I've owned had solid access panels (no vent holes). If your mini access panel doesn't have vent holes, you'll need a new access panel, too. Possibly another reason that it makes more sense to buy another unit than to upgrade your existing unit.
 
EDIT: It looks like the OC 0.6.8 config.plist is still a work in progress. It appears that there is a new UEFI properties block called AppleInput that includes some of the properties that used to be in UEFI > Input. The attached config.plist is likely going to be changing for OC 0.6.8.
---------------------------------------------------------------
I'm going to take a little risk and post my OC 0.6.8 config.plist before I've tested it. Some of you might want to migrate to OC 0.6.8 before I post a new EFI. If you do test the attached config.plist, be sure to replace PlatformInfo > Generic MLB, ROM, SystemSerialNumber, and SystemUUID with your own values. The changes to this config.plist (from OC 0.6.7 r002 BETA here) are as follows:
  • Added Base and BaseSkip keys to ACPI patches (ACPI > Patch)
  • Added Booter > Quirks>ForceBooterSignature (Boolean, false)
  • Added UEFI > Input > KeyInitialDelay (Integer, 0)
  • Added UEFI > Input > KeySubsequentDelay (Integer, 0)
  • Added UEFI > Output > GopPassThrough (Boolean, false)

If you find any errors in this config.plist, please post your findings for the benefit of others. Thank you.

EDIT: I noticed that my config.plist was missing the following setting which was added for OC 0.6.7. It's not applicable to our EliteDesk Minis, but I'm adding it for completeness.
  • UEFI > Audio > ResetTrafficClass (Boolean, false)
This additional setting is not in the attached config.plist, but will be in my EFI when I post one for 0.6.8.

EDIT 2: In the other forum, Andrey1970 provided a table that clearly specifies the OC-required CfgLock quirk settings. In my next posted EFI, I will be changing from having both CfgLock quirks = true to only AppleXcpmCfgLock = true (AppleCpuPmCfgLock = false). Others here in this thread have recommended this correct setting of the CfgLock quirks before and I'm finally getting around to correcting this. These corrected quirks settings for CfgLock are not in the attached config.plist but will be in my next posted EFI.
 

Attachments

  • config.plist.zip
    5.5 KB · Views: 73
Last edited:
EDIT: In "the other forum," Slice informed me that MSR 0xE2 is a register in each CPU and CFG Lock is a BIOS setting - the two are separate entities. It is absolutely possible for MSR 0xE2 to be locked (detectable by VerifyMsrE2 and ControlMsrE2) while CFG LOCK is not exposed in BIOS (and thus not changeable by ControlMsrE2). I'm leaving this experiment and still requesting volunteers to test, because I am still able to boot with OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks both false while MSR 0xE2 is locked.

---------------------------------------------------------------------------

Would anyone like to help me with an experiment? Make sure you have a bootable USB with your "safe" EFI so you can boot if you have any problems.

When I first switched from CLOVER to OC, I was uncertain about OC quirks AppleCpuPmCfgLock and AppleXcpmCfgLock (related to locked MSR 0xE2). CLOVER required KernelPm=true to boot Catalina, but OC would boot Catalina with AppleCpuPmCfgLock and AppleXcpmCfgLock both set to false. I used OC's VerifyMsrE2 tool and confirmed that MSR 0xE2 is locked; however, further analysis of the BIOS (by me and @rafale77 ) revealed that CFG LOCK is not publicly exposed and ControlMsrE2 is not able to unlock CFG Lock.

I am currently running my rig with AppleCpuPmCfgLock and AppleXcpmCfgLock both false. I don't know why, but it appears that, despite the locked state of MSR 0xE2, our EliteDesk 800 Minis are still able to boot macOS without enabling OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks. Note that CLOVER was not able to boot Catalina without enabling KernelPm.

If you'd like to join me in this experiment, modify your config.plist so that Kernel>Quirks AppleCpuPmCfgLock and AppleXcpmCfgLock are both false. Be sure to have a bootable USB with your "safe" EFI so that you can boot if you have any problems.
 
Last edited:
EDIT: In "the other forum," Slice informed me that MSR 0xE2 is a register in each CPU and CFG Lock is a BIOS setting - the two are separate entities. It is absolutely possible for MSR 0xE2 to be locked (detectable by VerifyMsrE2 and ControlMsrE2) while CFG LOCK is not exposed in BIOS (and thus not changeable by ControlMsrE2). I'm leaving this experiment and still requesting volunteers to test, because I am still able to boot with OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks both false while MSR 0xE2 is locked.

---------------------------------------------------------------------------

Would anyone like to help me with an experiment? Make sure you have a bootable USB with your "safe" EFI so you can boot if you have any problems.

When I first switched from CLOVER to OC, I was uncertain about OC quirks AppleCpuPmCfgLock and AppleXcpmCfgLock (related to locked MSR 0xE2). CLOVER required KernelPm=true to boot Catalina, but OC would boot Catalina with AppleCpuPmCfgLock and AppleXcpmCfgLock both set to false. I used OC's VerifyMsrE2 tool and confirmed that MSR 0xE2 is locked; however, further analysis of the BIOS (by me and @rafale77 ) revealed that CFG LOCK is not publicly exposed and ControlMsrE2 is not able to unlock CFG Lock.

I am currently running my rig with AppleCpuPmCfgLock and AppleXcpmCfgLock both false. I don't know why, but it appears that, despite the locked state of MSR 0xE2, our EliteDesk 800 Minis are still able to boot macOS without enabling OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks. Note that CLOVER was not able to boot Catalina without enabling KernelPm.

If you'd like to join me in this experiment, modify your config.plist so that Kernel>Quirks AppleCpuPmCfgLock and AppleXcpmCfgLock are both false. Be sure to have a bootable USB with your "safe" EFI so that you can boot if you have any problems.
This is an interesting idea and I quickly tested my setup and my ZBook G5 also booted with AppleCpuPmCfgLock and AppleXcpmCfgLock quirks off and according to VerifyMsrE2 I've a locked MSR 0xE2. (Also impossible to find anywhere in the BIOS)
Now I ran the CPU tests on Hackintool and It claims my MSR is locked!
So I question if OC is enabling the quirks automatically by testing for MSR lock and finding that the config is wrong?
Or are the reports from VerifyMsrE2 and Hackintool assuming locked by not finding a setting as you suggest?
 
@theroadw In "the other forum" someone reported that their 800 G5 Mini does not boot when AppleCpuPmCfgLock and AppleXcpmCfgLock quirks are false. I'm hoping we get a big enough sample size that we can figure this out. For now, I'm still continuing to boot with both AppleCpuPmCfgLock and AppleXcpmCfgLock quirks false.

EDIT: Slice indicated that setting AppleCpuPmCfgLock and AppleXcpmCfgLock to true will not hurt anything. I will not be changing these settings in my posted EFI. This idea will be for experimentation only, but I will not be changing the CfgLock quirks in my posted EFI. I will be changing AppleCpuPmCfgLock from true to false as indicated here.
 
Last edited:
Hello all,

could use your latest ACPI changes without problems.
In my Settings i allready used AppleCpuPmCfgLock = false
I also could boot with AppleCpuPmCfgLock and AppleXcpmCfgLock = false.
(tried it some time ago with older OC too and i use the moded SSDT-PLUG.aml)

Multiboot is working as before. (I allready use your latest SSDT-XOSI.aml)

The only problem i´ve got behind the latest macOS Update is that i allways have to reset
my Bluetooth with USB BCM20702A0 to connect to my Airpods. (Handoff not working because no wifi)
Connecting to Soundbars/TV is working as before.

After all Bluetooth replies, witch Adapter is the best/cheapest Wifi/Bluetooth right now?
 
Last edited:
@Carstimann Are you using OC's Kernel > Quirks > ExtendBTFeatureFlags = true?

Still waiting for other replies to this post.
 
EDIT: Open Core 0.6.8 OCValidate identified issues with the config.plist that I posted with OC0.6.8-EFI-r001 (attached to Post #1). These issues are harmless for our EliteDesk 800 Minis and will be fixed in the next posted EFI. If you want a 'clean' config.plist, I corrected the errors in the attached config.plist. The errors identified by OCValidate were:
  • OCS: Missing key Patch, context <Booter>!
  • OCS: Missing key TextMode, context <Entries>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!

------------------------------

My first EFI for OpenCore 0.6.8 is now attached to Post #1. This new EFI includes the following changes:

OC 0.6.8 EFI R001
ACPI

  • Added missing _OSI("Darwin") conditions to conditionally enable Apple devices for macOS (SSDT-DMAC, SSDT-PLUG, SSDT-PMCR, SSDT-PPMC, SSDT-XSPI)
  • Replaced SSDT-AWAC-HPET with SSDT-AWAC-HPET-RTC which includes RTC patch (same as CLOVER's Fix RTC) which changes RTC memory length from 0x8 to 0x2 to prevent RTC memory corruption
config.plist
  • Added Base and BaseSkip keys to ACPI patches (ACPI > Patch)
  • Added Booter > Quirks>ForceBooterSignature (Boolean, false)
  • Added UEFI > AppleInput properties
  • Added UEFI > Output > GopPassThrough (Boolean, false)
  • Added UEFI > Audio > ResetTrafficClass (Boolean, false) (had missed this when it was added for OC 0.6.7)
  • Removed UEFI > ProtocolOverrides > AppleEvent (now in UEFI > AppleInput)
  • Changed Kernel > Quirks > AppleCpuPmCfgLock from true to false (only AppleXcpmCfgLock is required to be true)
  • ACPI > Add > Item0: changed from SSDT-AWAC-HPET.aml to SSDT-AWAC-HPET-RTC.aml (includes RTC patch)
  • Kernel > Add: Removed RTCMemoryFixup.kext
  • NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args: removed rtcfx_exclude
Kexts
  • Updated WhateverGreen.kext to version 1.4.9
  • Updated VirtualSMC.kext to version 1.2.2
  • Updated AppleALC.kext to version 1.5.9
  • Updated NVMEfix.kext to version 1.0.6
  • Updated Lilu.kext to version 1.5.2
  • Removed RTCMemoryFixup.kext (using RTC memory length ACPI patch instead)
 

Attachments

  • OC068-config-r002.plist.zip
    5.7 KB · Views: 83
Last edited:
Status
Not open for further replies.
Back
Top