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

[deeveedee]

EDIT: This OC EFI is superseded by the OC EFI here.
------------------------------------------------------------
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 here.

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.

 

[deeveedee]

I have decided not to pursue a Clover bootloader solution for Big Sur. Clover r5122 for Catalina will be my last Clover-based baseline for my HP EliteDesk 800 G4 Mini. The Acidanthera team is doing an awesome job with OC and I'm comfortable enough now with OC to drop Clover. Many thanks to the Clover Team and to all in this forum for the Clover support - it has been an awesome ride.

 

[deeveedee]

Does anyone know how to eliminate the annoying audio "pop" caused by AudioDxe.efi driver? I like the Boot Chime, but not enough to put up with the loud "pop" during macOS boot. Currently, in my OC config.plist, I have disabled the Boot Chime as follows:

• UEFI > Audio > AudioSupport = No
• UEFI > Drivers: remove AudioDxe.efi

 

[deeveedee]

If you are adventurous, experiment with this AT YOUR OWN RISK. During my testing, I experienced a catastrophic SSD crash requiring erase and restore from TimeMachine. I cannot say with certainty that the crash was caused by the incorrect power management settings. I stumbled upon this by accident and have not seen this documented anywhere.

I am now testing with OC 0.6.5 and the modified SSDT-PLUG.aml attached. With this modified SSDT-PLUG, my Geekbench 5 multi-core benchmarks are consistently higher AND my low CPU multipliers are 10, 11 and 12 (not limited to 13). Note that I lose Energy Saver options, so this is a trade-off. Again, TEST AT YOUR OWN RISK.

Note that my rig is running with HPET DISABLED via ACPI patch (HPET._STA=0 just like a real MacMini8,1). See my reasoning here. I'm not sure if this HPET setting affects these results. I also use RtcMemoryFixup.kext with custom rtcfx_exclude range (with CLOVER, I did not use "Fix RTC"). I also have both DDR4 memory banks populated (I have found that single-bank performance is less).

	OC 0.6.5 with modified SSDT-PLUG.aml (attached)	OC 0.6.5 with original SSDT-PLUG.aml
Energy Saver Preferences	2 settings available	5 settings available
GeekBench 5 multi-core benchmark	5600+	5500+
Lowest CPU multiplier	10,11,12,13	13

GB5 Benchmarks with modified SSDT-PLUG.aml (EliteDesk. 800 G4 Mini, I7-8700, 2 x 16GB DDR4)

Spoiler

HWMonitor.app showing 10x CPU multiplier

Spoiler

*** The attached SSDT-PLUG patch is specific to the EliteDesk 800 Mini ACPI (_SB_.PR00). If you use this patch, make sure it is compatible with your ACPI ***

 

[rafale77]

I have finally resolved my watch unlock problem by using a reverse M.2 adapter like this:
https://www.ebay.com/itm/Suit-for-H...T2-BCM94360CD-To-A-E-Key-Adapter/143820549029 and an original apple bcm94360CS card. Total cost $19... Takes a lot of squeezing because there isn't a lot of room in there but it works.

Now, I don't have anything which doesn't work anymore. (that I know of)

 

[deeveedee]

@rafale77 - I copied your USB TypeC connector types in USBPorts.kext and hadn't learned about the "TypeC" and "TypeC+Sw" types, so I decided to learn. As I was reviewing, 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.

1. Is this also true for your G5 Mini's USB C port?
2. Does this mean that the USB C connector type should be changed from "TypeC" to "TypeC+Sw" for HS10 and remain "TypeC" for SS03 or SS04 (only choose either SS03 or SS04 to stay within the 15 port limit)?

Since everything appears to be working correctly, I suspect that this is only cosmetic, but I'm still curious. Thanks.

Details:
The HP EliteDesk 800 G4 Mini USB C port (Front) 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. 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."

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.

EDIT: I have attached USBPorts-15.kext which removes SS04 to comply with the 15-port limit. The difference between the attached USBPorts-15.kext and the current USBPorts.kext in the EFIs attached to Post #1 is that the HS10 'Connector' is changed from TypeC to TypeC+Sw.

 

[rafale77]

@rafale77 - I copied your USB TypeC connector types in USBPorts.kext and hadn't learned about the "TypeC" and "TypeC+Sw" types, so I decided to learn. As I was reviewing, 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.

1. Is this also true for your G5 Mini's USB C port?
2. Does this mean that the USB C connector type should be changed from "TypeC" to "TypeC+Sw" for HS10 and remain "TypeC" for SS03 or SS04 (only choose either SS03 or SS04 to stay within the 15 port limit)?

Since everything appears to be working correctly, I suspect that this is only cosmetic, but I'm still curious. Thanks.

Details:
The HP EliteDesk 800 G4 Mini USB C port (Front) 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. 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."

View attachment 504899

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.kext with all 16 ports defined. The attached USBPorts.kext does NOT comply with the 15-port limit. I enable OC's Kernel>Quirks>XhciPortLimit to boot with the attached USBPorts.kext.

View attachment 504900

This is news to me. I actually tested with a USB3.0 device (SS03) and flipping it turned it into a USB2 device (HS10). Could it be that it was because I had SS04 disabled? I doubt it, since I am pretty sure I did this with the USBenableAll kext. What USBC device did you try? Maybe it is a cable wiring difference with the device.

 

[deeveedee]

This is news to me. I actually tested with a USB3.0 device (SS03) and flipping it turned it into a USB2 device (HS10). Could it be that it was because I had SS04 disabled? I doubt it, since I am pretty sure I did this with the USBenableAll kext. What USBC device did you try? Maybe it is a cable wiring difference with the device.

I did the test for 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. So I think the only change from your TypeC mapping is that I changed HS10 from TypeC to TypeC+Sw. Maybe it is the wiring of the adapter.

 

[deeveedee]

I have finally resolved my watch unlock problem by using a reverse M.2 adapter like this:
https://www.ebay.com/itm/Suit-for-H...T2-BCM94360CD-To-A-E-Key-Adapter/143820549029 and an original apple bcm94360CS card. Total cost $19... Takes a lot of squeezing because there isn't a lot of room in there but it works.

Now, I don't have anything which doesn't work anymore. (that I know of)

You were incredibly persistent in your pursuit of this solution and it paid off! Nice job. Do you happen to have IORegistryExplorer 2.1 dumps with your old and new Bluetooth cards? I'd be curious to know the differences.

 

[deeveedee]

This is news to me. I actually tested with a USB3.0 device (SS03) and flipping it turned it into a USB2 device (HS10). Could it be that it was because I had SS04 disabled? I doubt it, since I am pretty sure I did this with the USBenableAll kext. What USBC device did you try? Maybe it is a cable wiring difference with the device.

This just got a little more interesting and behaves as you described. 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. The corresponding USBPorts.kext for this new mapping is attached.