[GUIDE] Catalina, Big Sur, Monterey, Ventura, Sonoma on HP EliteDesk 800 G4/G5 Mini - The perfect MacMini8,1 Hackintosh

[deeveedee]

I just applied the most recent Catalina 10.15.7 security update and Safari 14.0.2 update without any issues. During the update, my HackMini8,1 did have a few dramatic pauses and screens flickered, but I remained patient and all was well. Just be patient. As always, backup first - just in case.

 

Note: if you see lost RTC (clock) during the installer reboots, just acknowledge the warning and allow your HP EliteDesk 800 G4 Mini to recover gracefully. Your G4 mini will reboot and resume the macOS upgrade without issues. There does appear to be the need for RTCMemoryFixup.kext / custom rtcfx-exclude on this rig as noted here. The RTC issue does not occur during normal operation, so fixing this remains a low priority for me.

 

Spoiler

 

Spoiler

 

Edited January 14, 2021 by tonyx86
Fixed broken link

[deeveedee]

FYI: For those wondering why I haven't been active with OC/BS lately, I'm waiting for the next release of OC. For those who are interested, I would suggest monitoring the Acidanthera OC commits for changes from one release to the next. Following the release of OC 0.6.4, Acidanthera has a new commit that will affect MacMini8,1 (new BIOS/Firmware version). I'm not sure how this affects the behavior of our HackMinis but it's why I'm not acting on the release of 0.6.4. My testing baseline is still OC 0.6.3 for now, but I do plan to install 0.6.5 (or whatever it's called next).

BTW - if you look at the Acidanthera commits to OC, you will see just how much effort is required to maintain OC (and CLOVER for that matter). These bootloader teams are really doing A LOT of work that most of us take for granted. The OC and CLOVER teams deserve our appreciation, admiration and respect for all that they do to make our hacks possible.

Edited December 17, 2020 by tonyx86

[deeveedee]

I am now running Catalina 10.15.7 (still CLOVER r5122) without CLOVER driver NvmExpressDxe.efi as noted here.

Edited January 14, 2021 by tonyx86
Fixed broken link

[deeveedee]

I have determined that the correct rtcfx_exclude range (for use with RtcMemoryFixup.kext) for my EliteDesk 800 G3 Mini is not a contiguous range (e.g. not B0-B4). The correct range for my G3 Mini is

          rtcfx_exclude=B0-B3,B7

I determined this by trial and error when attempting to wake from sleep. I haven't yet gotten wake from sleep to work on the G3 Mini (Kabylake, i7-7700T, HD630), but with this rtcfx_exclude range, attempts to wake from sleep do not corrupt RTC.

I'm posting this in this thread, because the RTC issue on the EliteDesk 800 G4 Mini is hard to reproduce. Maybe the range for the G3 Mini will work (or at least be a good starting point) for the G4 Mini.

 

EDIT: I tried to convert my G3 Mini rtcfx_exclude range to an rtc-blacklist in OC 0.6.3, but my converted exclude range did not work. I'm sure this is user error and will need to review this again to find my mistake. Staying with boot-arg rtcfx_exclude and RtcMemoryFixup.kext for now.

 

Spoiler

 

Edited December 27, 2020 by tonyx86

[v.osypets]

I use DisableRtcChecksum quirk in OpenCore, which blocks 0x58-0x59 regions. In my case it's enough to use machine without any problems.

Edited December 28, 2020 by v.osypets

[deeveedee]

7 hours ago, v.osypets said:

I use DisableRtcChecksum quirk in OpenCore, which blocks 0x58-0x59 regions. In my case it's enough to use machine without any problems.

You have the G5 Mini and not the G4 Mini - correct?  Based on what I've observed in this and an another forum, the 800 G5 Mini does not have the RTC issues seen on the G4 Mini.  The RTC issues are more pronounced on the G3 Mini.  It appears that HP has somehow improved RTC from the G3 to G4 to G5.  I rarely see RTC issues on my G4 Mini (only during macOS installation and during the use of some OpenCore tools).  On my G3 Mini, the RTC issue is very easy to reproduce unless I implement the rtcfx_exclude range with RtcMemoryFixup.kext.

 

Fortunately, the fix is as simple as implementing the rtcfx_exclude and if the RTC issue does occur, recovery from the RTC issue is as simple as pressing <Enter>.

Edited December 28, 2020 by tonyx86

[deeveedee]

EDIT: When framebuffer-conX-type is set to Single-link DVI as described below, Hackintool crashes when selecting Patch > Connectors. It appears that Hackintool is not compatible with Single-link DVI setting. Since Dual-link DVI appears to work fine even when actual connector is Single-link DVI, it is best to leave framebuffer-conX-type setting at Dual-link DVI if you use Hackintool.
--------------------------------------------------

I just learned something new after reading this Dortania page: the DVI connector type 0x0004 that I've been using is for dual-link DVI. My DVI connectors are single-link (display resolution 1680x1050), so my framebuffer-conX-type should be 0x0200 (reverse byte order 0x00020000). I am now running with this revised connector type and am not seeing any difference in behavior. I suspect that this doesn't matter for me, because my display resolution is below 1920x1200 as discussed here. For those with DVI displays having resolution higher than 1920x1200, you would need dual-link DVI.

Edited December 30, 2020 by tonyx86

[deeveedee]

Prior to my upgrade to OC 0.6.5, I upgraded to Big Sur 11.1 (20C69) (still running OC 0.6.3). I also attached the latest version (r006) of my OC 0.6.3 EFI to Post #1. Including RTCMemoryFixup.kext with boot-arg rtcfx_exclude=B0-B3,B7 has resolved the RTC issues that I observed with my EliteDesk 800 G4 Mini. The updated EFI (r006) includes the following changes from r005:

ACPI

• Replaced SSDT-AWAC with SSDT-AWAC-HPET: disables AWAC and HPET
• Removed SSDT-HPET (no longer patching HPET now that it is disabled)

Kexts

• Updated AppleALC, Lilu and WhateverGreen
• Added RTCMemoryFixup

config.plist

• Updated "ACPI > Add" to reflect ACPI changes
• Updated "ACPI > Patch" by eliminating unnecessary HPET / IRQ patching (now that HPET is disabled)
• Added "Booter > Quirks > AllowRelocationBlock=No" (prep for OC 0.6.4+)
• Changed "Booter > Quirks > EnableWriteUnprotector" from Yes to No (as recommended by OC Sanity Checker for CoffeeLake Laptop)
• Updated "Kernel > Add" with RTCMemoryFixup
• Added "Misc > Security > BlacklistAppleUpdate=Yes" (prep for OC 0.6.4+)
• Added "rtcfx_exclude=B0-B3,B7" to "NVRAM > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args" to prevent RTC corruption on Big Sur Shutdown and during MacOS installs

About This Mac

Spoiler

 

Edited January 14, 2021 by tonyx86
Fixed broken link

[deeveedee]

The OC EFI update referenced below has been superseded by the update here.
----------------------------------------------------

I have attached a revised OC0.6.5-EFI-r001.zip archive to Post #1. This revised EFI for 0C 0.6.5 includes the following updates:

• Replaced all drivers with those released with OC 0.6.5 (including OpenCore.efi)
• Updated AppleALC, IntelMausi, WhateverGreen kexts
• Updated config.plist with 0C 0.6.4+ changes:
  • Added NVRAM > LegacySchema > 7C436110-AB2A-4BBB-A880-FE41995C9F82 items (not relevant to our rig, but added for completeness
  • Changed UEFI > Audio > PlayChime type from Boolean to String and set to Auto
  • Added UEFI > Audio > SetupDelay to match OC 0.6.5 sample.plist
  • Added @rafale77 's  starup audio settings to UEFI > Audio (although I have no boot chime which is fixed here)
  • Changed UEFI > ProtocolOverrides > FirmwareVolume from 0 to 1 to match OC 0.6.5 sample.plist
  • Removed UEFI > Quirks > DeduplicateBootOrder to match OC 0.6.5 sample.plist

Edited January 6, 2021 by tonyx86

[deeveedee]

I attached a revised CLOVER r5122 EFI (CLOVER r5122-v6.zip) archive to Post #1. This archive for CLOVER r5122 / Catalina includes the following updates:

• Updated AppleALC, IntelMausi and WhateverGreen kexts
• Changed boot-arg darkwake=3 to darkwake=2 (back to my original - I had changed to 3 based on a suggestion, but it didn't make a difference)
• Added rtcfx_exclude=B0-B3,B7 (for RTCMemoryFixup.kext) to resolve RTC issues with macOS installer (still testing this exclude range)
• Disabled TRIM kernel patch (I only have NVMe SSDs. You may need to enable if you have SATA SSDs)
• Removed NvmExpress driver
• Added RTCMemoryFixup.kext (for reasons stated earlier)

This archive no longer includes an LE folder (all kexts are in EFI/CLOVER/kexts/Other in the archive). If you choose to install kexts in /Library/Extensions (I still do for Catalina), you will need to select /L/E kexts from the E/C/k/O folder. Also, if you use my CLOVER config.plist, you will need to replace all instances of XX-MASKED-XX with your own values.

Edited January 5, 2021 by tonyx86

[deeveedee]

A recent website upgrade has broken intra-forum links.  If you click on a link and it is unresolved, try changing the link as follows:

 

Broken link: https://www.insanelymac.com/topic

 

Fixed link: https://www.insanelymac.com/forum/topic

 

Add "/forum" in the link as shown.

Edited January 5, 2021 by tonyx86

[deeveedee]

Ok - now we're just showing off. I have attached a revised OC0.6.5-EFI-r002.zip archive to Post #1. This revised EFI fixes boot chime (a user RTFM issue), sets the boot chime for the left-front audio port and adds the SSDT-MM81 with some MacMini8,1 additions (purely cosmetic).

OC-065-EFI-r002 EFI Changes

• Added AudioDxe.efi to EFI/OC/Drivers and to config.plist (UEFI > Drivers)
• Added SSDT-MM81 to EFI/OC/ACPI and to config.plist (ACPI > Add)
• Changed config.plist UEFI/Audio/AudioOut from 2 to 1 for boot chime via left-front audio port. Change to 2 for boot chime via internal speaker.

Edited January 6, 2021 by tonyx86

[deeveedee]

Thanks to @viorel78 in another forum for showing me how to examine the boot log for ACPI errors, I found that CLOVER r5122 is injecting a bad SBUS Fix (results in ACPI parse error for SBUS.BUS0._DSM) when CLOVER's "Fix SBUS" is enabled. The solution for CLOVER r5122 is to use the attached SSDT which we are using for OpenCore and to disable CLOVER's "Fix SBUS" and disable CLOVER's "Add MCHC." I upgraded to CLOVER r5127 and found that the problem remains (not fixed in CLOVER r5127). This fix will be incorporated into a future update of the CLOVER EFI attached to Post #1. I will not be fixing this since I have switched to OpenCore.

 

 

SSDT-SBUS-MCHC.zip

Edited January 11, 2021 by tonyx86
Added note about continued problem in CLOVER r5127

[deeveedee]

EDIT: The Geekbench 5 benchmarks below with CLOVER r5127 were collected with SSDT>Generate>PluginType enabled in Clover's config.plist and without SSDT>PluginType=1.  While performance is slighly better (as measured with Geekbench 5), most Energy Saver options (in Energy Saver Preferences) are not available unless SSDT>PluginType=1 is also set in Clover's config.plist.  With SSDT>PluginType=1, performance with r5127 is the same as with r5122.  Also, while testing with r5127 and only SSDT>Generate>PluginType (without SSDT>PluginType=1), I experienced a corrupted SSD that required me to completely erase and recover from TimeMachine backup.  I can't be certain that this catastrophic failure was caused by incorrect power management settings, but I would not advise using Clover r5127+ without setting both SSDT>Generate>PluginType and SSDT>PluginType=1. Note that this requirement to add SSDT>PluginType=1 is new after Clover r5122.

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

Posting my Geekbench 5 scores captured before and after CLOVER r5127 upgrade.  I can't say for certain what contributes to the increased multi-core performance, but I don't believe that I've ever had a GB5 multi-core score over 5550.  This latest is 5611.

 

CLOVER r5122

Spoiler

 

CLOVER r5127

Spoiler

 

Edited January 8, 2021 by tonyx86

[deeveedee]

EDIT: This bug is apparently fixed in a release AFTER CLOVER r5128 (see commit here).  I won't be installing / testing CLOVER, but I'm posting here for others who may still be using CLOVER.

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

@iCanaro reported that there are known issues with Clover r5127's "SSDT>Generate>PluginType" (see here) and advises to use SSDT-PLUG instead (just like we're doing with OpenCore).  I plan to switch my Clover EFI to SSDT-PLUG and will test.  I would strongly advise against using Clover r5127's SSDT->Generate->PluginType.

 

The "fix" for Clover r5127 is to add "Plugin Type = 1" as discussed here.  Either use SSDT-PLUG.aml (as with OC) or enable "Plugin Type = 1" in CLOVER config.plist.

Edited January 23, 2021 by tonyx86

[deeveedee]

My current baseline for this rig is still Catalina 10.15.7.03 with CLOVER r5122.  After much effort to maintain two candidate baselines (and documentation in this thread) for both CLOVER and OC, I have decided to drop CLOVER in favor of OC as I migrate to Big Sur.  I'll migrate to Big Sur when it reaches incremental version 4 and plan to have an OC bootloader solution at that time.  Many thanks to the CLOVER Team for their great work and to everyone in this forum for the outstanding CLOVER support.  It's been an amazing journey!

 

To switch from CLOVER to OC, do the following:

1. Make a full system backup before you convert
2. Open Hackintool and collect the following info (collecting this from your CLOVER config.plist is possible, too, if you can avoid the confusion of RtVariables.MLB and SMBIOS.BoardSerialNumber):
   1. Serial Number (this will be OC's PlatformInfo.Generic.SystemSerialNumber)
   2. System ID (this will be OC's PlatformInfo.Generic.SystemUUID)
   3. ROM (this will be OC's PlatformInfo.Generic.ROM)
   4. Board Serial Number (this will be OC's PlatformInfo.Generic.MLB)
3. Follow this guide to remove the CLOVER stuff from your system: Converting from CLOVER to OC
4. After you have completely removed the CLOVER EFI from your system, replace it with your OC EFI
5. Populate your OC config.plist with the values you collected in Step 1
6. Reboot (now with OC bootloader)
7. Follow any prompts to allow extensions for apps that you've installed

Edited January 8, 2021 by tonyx86

[sthEn]

So basically - THANK YOU, THANK YOU and THANK YOU.

 

That was basically plug and play. Downloaded your zip, changed serials and ID's, and boom, we're in the system  Just deleted AppleALC, because i'm using USB DAC anyway, and it's working OOTB.

 

Using G4 Mini with desktop with full CPU i5-8500 3.0GHz + 16GBs of RAM.

Almost perfect plex server 

 

Two things:

1. Were you able to get 4k @ 60Hz on this? I'm getting only 1080p, but that might be my DP>HDMI adapter, because i also can't get past 1440p@60Hz on G1 Mini using this.

2. Why are you using FakeSMC instead of VirtualSMC?

Edited January 11, 2021 by sthEn

[deeveedee]

I'm glad you found this helpful.  Congrats on your new hack.

[deeveedee]

I learned something about the HP EliteDesk 800 G4 Mini that I didn't know: the USB C port uses the same port ID (HS10) for both orientations with USB 2.0 devices, but it uses different port IDs (SS03 and SS04) for each orientation with USB 3.0 devices.  Since everything appears to be working correctly with the current USBPorts.kext USB mapping, I suspect that this change below is only cosmetic, so I'm posting this for interested readers who are learning about USB patching.  I use the word "orientation" to be consistent with the term used in Hackintool's context-sensitve help, which implies that there is a "upside" and a "downside" when connecting USB-C devices (since the connector can be inserted both ways).  The USB-C port is able to sense this "upside orientation" and "downside orientation" as you will read below.

Details:
The HP EliteDesk 800 G4 Mini USB C port (Front) uses the same port ID (HS10) for both connector orientations with USB 2.0 devices, but it uses different port IDs (SS03 and SS04) for each orientation with USB 3.0 devices. If I read the Hackintool help screen (below) correctly, I think this means that the connector type for the USB C port with USB 2.0 devices is "TypeC+Sw," but the connector type for the USB C port with USB 3.0 devices is "TypeC."

 

Hackintool Port Connector Instructions

Spoiler

 

This also means that the HP EliteDesk 800 G4 Mini has 16 different USB port IDs, which exceeds the maximum of 15, so we need to choose either SS03 or SS04 (not both) to remain within the 15-port limit. Attached is my revised USBPorts-16.kext with all 16 ports defined. The attached USBPorts-16.kext does NOT comply with the 15-port limit. I enable OC's Kernel>Quirks>XhciPortLimit to boot with the attached USBPorts-16.kext.  You will need to enable the appropriate USB port-limit patch for your bootloader.

 

Revised Hackintool USB Port Mapping (does not comply with 15-port limit)

Spoiler

 

I tested this with simple USB thumb drives (one USB 2.0 and one USB 3.0) and a USB > USB-C adapter. I'm sure it's more cosmetic than anything else. I am currently running with HS10 as TypeC+Sw (since it is a single Port ID for both orientations) and SS03 as TypeC. I deleted SS04 to stay within the 15-connector limit. The only change from the current TypeC mapping is that I changed HS10 from TypeC to TypeC+Sw.  This new 15-port USB mapping is in the attached USBPorts-15.kext.

 

EDIT: After deleting SS04 (to comply with the 15-port limit), when a USB 3.0 device is inserted into the USB-C port in the "SS04 orientation" (the orientation no longer in the USB map), the USB 3.0 device is recognized on port HS10. So it does appear that the USB-C port is recognized differently depending on whether its SS04 Connector is included in the USB map. When I flip the device, it is recognized on port SS03 as expected. If I use the port limit patch and keep both SS03 and SS04 in the map, the USB-C device is recognized on ports SS03 and SS04 as expected.

 

Since I am not using my Wi-Fi / Bluetooth (I still have the unsupported Intel M.2 card), I have removed HS14 from my USB map and restored SS04. With this new mapping, a USB 3.0 device inserted into the USB-C port is recognized on ports SS03 and SS04 as expected. The corresponding USBPorts-noHS14.kext for this new USB mapping is attached.

 

USB port mapping with HS14 Removed and SS04 Added

Spoiler

 

USBPorts-15.kext.zip

USBPorts-16.kext.zip

USBPorts-noHS14.kext.zip

Edited January 15, 2021 by tonyx86
Added new USBPorts-noHS14.kext

[deeveedee]

A couple of comments about future revisions to my OC EFI:

• I do plan to upgrade to OC 0.6.6 because of the switch from HfsPlus.efi (and VBoxHfs.efi) to FswHfsPlus.efi. You can follow the reasoning by viewing the OC 0.6.6 commits here.
• I think that individual USB patching strategies will need to be unique based on our USB port needs. After discovering that the USB-C port behaves differently than we first determined (with the USB-C port having two Port IDs (SS03 and SS04) for USB3 devices and one Port ID (HS10) for USB2 devices) each of us will need to create a USB port map that complies with the 15-port limit and provides the ports we need. Since I'm not using my internal Bluetooth USB port, I can drop HS14 from my USB map. In the future, since I always have my USB 2.0 Hub connected to HS02 (rear right bottom) for mouse and keyboard, I could drop SS10 and restore HS14. I won't ever need SS10 as long as I keep my USB 2.0 Hub connected to HS02. I think that I will be providing multiple USBPorts.kext candidates with future EFIs to allow each of us to choose/tailor one that works for us.

[deeveedee]

The Catalina security update and Safari update installed without any problems. My current baseline is Catalina 10.15.7 (19H512) and OpenCore 0.6.5 (using EFI OC0.6.5-EFI-r002.zip attached to Post #1).  OpenCore even properly selected the correct macOS Install volume when rebooting the installer.

 

About This Mac: 10.15.7 (19H512)

Spoiler

 

Edited February 2, 2021 by tonyx86

[deeveedee]

Post #1 now includes an attached draft EFI for OC 0.6.6 (OC0.6.6-EFI-r001). I used this updated EFI to upgrade to Big Sur 11.2 with no problems. Changes from the previous OC 0.6.5 EFI are as follows:

 

Changes in this EFI (from OC0.6.5-EFI-R002)

• Upgraded to OC0.6.6
• Replaced SSDT-MM81 with SSDT-DMAC (new SSDT only adds device DMAC)
• OC/Kexts contains multiple versions of USBPorts.kext. The default USBPorts.kext has 16 logical USB ports and requires config.plist Kernel>Quirks>XHCIPortLimit=1. Other USBPorts options are below.
• USBPorts.kext now labels SS03 and SS04 "Connectors" as TypeC. There is disagreement about this, but it is working for me and I suspect it's more cosmetic than functional. Refer to Hackintool context sensitive help for more info.
• Changed config.plist: Kernel>Quirks>XHCIPortLimit=1 (for 16-port USBPorts.kext). Use Hackintool to customize USBPorts.kext (to comply with 15-port limit) and change XHCIPortLimit to 0.
• Revised SSDT-XOSI.aml to be 'multi-boot friendly' - includes _OSI("Darwin") conditions
• Replaced Driver HfsPlus.efi with OpenHfsPlus.efi
• Upgraded Acidanthera kexts AppleALC.kext, WhateverGreen.kext, Lilu.kext
  • AppleALC.kext 1.5.6 -> 1.5.7
  • WhateverGreen.kext 1.4.6 -> 1.4.7
  • Lilu.kext 1.5.0 -> 1.5.1
• Changed config.plist: UEFI>Audio>VolumeAmplifier from 143 to 70 (lower boot chime volume)
• Changed config.plist: Added Kernel>Quirks>SetApfsTrimTimeout
• Changed config.plist: Added Misc>Boot>LauncherOption, LauncherPath, PickerVariant
• Changed config.plist: Added PlatformInfo>UseRawUuidEncoding
• Changed config.plist: Added UEFI>Quirks>DisableSecurityPolicy
• Changed config.plist: Removed Misc>Security>BootProtect

USBPorts.kext options included in this EFI:

• USBPorts-noHS14.kext: HS14 (internal Bluetooth USB) not included in port map - complies with 15-port limit, set XhciPortLimit=0
• USBPorts-16.kext: Includes 16 logical USB ports - exceeds 15-port limit, set XhciPortLimit=1 (not intended for production use)
• USBPorts.kext: same as USBPorts-16.kext

 

About This Mac: 11.2 (20D64)

Spoiler

 

Edited February 7, 2021 by tonyx86
Fixed typo

[deeveedee]

My advice about this BIOS update: After comparing the release notes for this latest BIOS update (2.15) to the previous BIOS update (2.14.01), I don't believe that this update is urgent - don't rush to install this. BIOS update 2.15 fixes the "After Power Loss" issue (which I have never seen) and updates Intel Reference Code as mentioned below. The other firmware is unchanged from 2.14.01 to 2.15. My advice: don't be the first to apply this BIOS update.

===============================================
 

There is a new BIOS update for the EliteDesk 800 G4 Mini (version 2.15). I am still running with BIOS version 2.14.1 and have not tested with the new BIOS version.

 

The new BIOS (2.15) includes the following changes:

• Fixes an issue where "After Power Loss" in BIOS setup lost functionality after s3 resume.
• Update Intel Reference code to 7.0.74.20
• This BIOS upgrade package also includes the following firmware versions:
  • Intel Management Engine Corporate v12.0.70.1652 (Production)
  • Super I/O (SIO) 7.9.51
  • Intel VBIOS 9.2.1014 (2018/06/21)
  • Intel GOP 9.0.1075
  • USB Type-C PD firmware FW 6.8.0
  • Intel/Realtek PXE rom IBA CL v0.1.13
  • Intel/Realtek UEFI PXE rom EFI v0.0.19

Edited February 4, 2021 by tonyx86
Added advice for not rushing to install this BIOS update

[deeveedee]

Sorry to post a revised EFI again so soon, but @Andrey1970 told me that I should still be using HfsPlus.efi (not OpenHfsPlus.efi) (even though OpenHfsPlus.efi is included in the OC 0.6.6 Release Pkg). OpenHfsPlus.efi is apparently not yet ready for prime time.

The OC0.6.6-EFI-r002.zip archive attached to Post #1 reverts to HfsPlus.efi.

[MacKonsti]

Hi @tonyx86 I am following our work when and as much as I can, despite not having this HP hack, however why don't you create a GitHub project and slowly update it there so that you a) avoid zipping here and b) have a single URL reference, as GitHub provides versioning?

If you have the earlier ZIPs you can commit and push each version (with your notes) up to the latest one. I have done the same for my three Hackintosh set-ups... Cheers!