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

[deeveedee]

@MacKonsti - I'm a glutton for punishment.  What you describe sounds way too logical and easy for me.

 

Feature request: incorporate version tracking into this forum.

Edited February 7, 2021 by tonyx86

[deeveedee]

I'm still running Catalina 10.15.7 in my production environment, but I do test BS to make sure I'm ready to migrate when BS 11.4 is available.  My upgrade from BS 11.2 to 11.2.1 completed successfully with one minor issue as documented here.

 

EDIT: The Catalina update to 10.15.7 (19H524) completed without any issues.  The Catalina update was flawless.  Note that I'm using the exact same OC 0.6.6 EFI for both BS and Catalina (EFI attached to Post #1).

 

Spoiler

 

Edited February 11, 2021 by tonyx86
Added note about Catalina 10.15.7 (19H254) update.

[deeveedee]

I purchased a used (like new) HP EliteDesk 800 G5 Mini (i7-9700 8-core/32GB RAM) and had some time to transfer my Big Sur SSD to the 800 G5 Mini.  After configuring the BIOS, it booted without any changes and without any problems.  The only difference I see between the G4 Mini/i7-8700 and G5 Mini/i7-9700 is that the i7-9700 multicore performance is better.  Otherwise, the units seem identical.

• CPU: i7-9700 (8-Core, No Hyperthreading, CoffeeLake, UHD630)
• Display: 3 x DP -> DigitalDVI
• Chipset: Q370
• Memory: 32GB (2 x 16GB) DDR4
• Wi-Fi: Intel (disabled in BiOS)
• 90W Genuine HP Power Supply
• Cost: $460 USD with shipping (base cost before I add 2 x M.2 NVMe SSDs and add 1 x 2TB SATA6 HD)

 

GeekBench5

Spoiler

 

 

About This Mac

Spoiler

 

Edited February 13, 2021 by tonyx86

[deeveedee]

I was experiencing random reboots after updating my G4 Mini's BIOS from version 2.14.01 to 2.15.  I'm not sure, but I suspect FakeSMC (I was still using the 'old' FakeSMC.kext with OC).  There is a FakeSMC.kext / OC compatibility issue that, for whatever reason, did not cause any problems for me with older BIOS versions.

 

I am now running with @FreeJHack's FakeSMC here and BIOS version 2.15.  I will report my finding after further testing.

[deeveedee]

After informally observing followers of this and other OpenCore threads, I will be switching to VirtualSMC.kext. FakeSMC has served me well for a long time, but in this case, I think it would be best to stay current with the majority of OC users.

 

EDIT: After I switched from FakeSMC (v.6.26-357.180x) to VirtualSMC, I observed some very strange graphics behavior at boot (OC text bootpicker was not displayed and Apple Logo was not visible with the progress bar).  These issues were not resolved with OC's NVRAM reset.  I shutdown my PC, removed AC power and held the power button for 30 seconds.  Upon reboot, the problems were resolved.  All appears to be well now with VirtualSMC.  Will continue to monitor behavior.

Edited February 16, 2021 by tonyx86

[deeveedee]

I have attached a revised EFI (OC0.6.6-EFI-r003.zip) to Post #1. This revised EFI includes the change below.

OC0.6.6-EFI_r003
Replaces FakeSMC.kext (version .6.26-357.180x) with VirtualSMC.kext (version 1.2). FakeSMC.kext and FakeSMC_CPUSensors.kext are removed. Read the OC0.6.6-EFI-r001 change notes included in the zip archive to help you select the correct USBPorts.kext for your system. Also be sure to populate config.plist PlatformInfo>Generic with your own values.

Edited February 17, 2021 by tonyx86

[deeveedee]

If I'm interpretting this issue correctly, we won't be able to set OpenCore's XhciPortLimit=1 to permit more than 15 logical USB Ports when booting Big Sur 11.3. The OC EFI that I have attached to Post #1 currently has a USBPorts.kext with 16 logical USB ports (allowing each user to customize their own USB port map). It would appear that we each need to make sure that we have a 15-logical-port USBPorts.kext prior to booting Big Sur 11.3.

A couple of options for each of us to consider are as follows:

• Use my USBPorts-noHS14.kext (included in the OC EFI attached to Post #1) if you do not have or are not using Bluetooth USB
• If you have a USB port that is occupied by a USB 2.0 keyboard and/or mouse connection, delete the unused USB 3.0 logical port from your USBPorts.kext (e.g. if you have a USB 2.0 keyboard connected to physical USB port "right-rear-bottom" (logical port HS02), delete logical USB 3.0 port SS10).

 

EDIT: XhciPortLimit is officially deprecated in OC 0.6.7. OC users will need to have properly patched USB port map (complying with the 15-port limit).

Edited February 23, 2021 by tonyx86

[deeveedee]

In preparation for OC 0.6.7, my config.plist will have the following changes (so far):

• Booter > Quirks > ProtectUefiServices: change from 0 to 1
• PlatformInfo > Generic > MaxBIOSVersion = 0

I have noticed that OC Sanity Checker recommends different values for ProtectUefiServices (0 or 1) depending on whether the platform is Desktop or Laptop and depending on whether the platform is 8th Gen or 9th Gen Intel. I'm settling on ProtectUefiServices = 1.

Also, my future config.plists will include a Kernel > Add entry for NVMeFix.kext.

Also, if testing with rtcfx_exclude indicates that it needs to be changed to resolve RTC issues, I may change this boot-arg. It appears that we have some flexibility with this, so as long as the rtcfx_exlude range isn't too broad, it will resolve the RTC issue on G3 and G4 without adversely impacting operation of G5 (so all can have the same EFI).

 

EDIT: Looks like there's a new quirk (UEFI > Quirks > ActivateHpetSupport) that we'll want to set <False> in our config.plist.

Edited February 28, 2021 by tonyx86
Added note about quirk ActivateHpetSupport

[deeveedee]

Post #1 now has an attached EFI for OpenCore 0.6.7. The changes to this new EFI are as follows:

OC 0.6.7 R001
config.plist changes

• Changed Booter>Quirks>ProtectUefiServices from No to Yes
• Added PlatformInfo>Generic>MaxBIOSVersion = No
• Added Kernel>Add entry for NVMeFix.kext
• Added UEFI>Quirks>ActivateHpetSupport = No
• Removed UEFI>Input>KeyMergeThreshold
• Changed Boot-Arg rtcfx_exclude=B0-B3,B7 to rtcfx_exclude=B0-B8. This change did not resolve the RTC issue for the G4 Mini.

Kext Updates

• Changed default USBPorts.kext to match USBPorts-NoHS14.kext (Kernel>Quirks>XhciPortLimit=False)
• Updated AppleALC.kext 1.5.7 -> 1.5.8
• Updated VirtualSMC.kext 1.2.0 -> 1.2.1
• Updated WhateverGreen.kext 1.4.7 -> 1.4.8
• Added NVMeFix.kext 1.0.5

This EFI update for Open Core 0.6.7 includes a USBPorts.kext that is equivalent to USBPorts-NoHS14.kext (also included in this EFI) to comply with the 15-port logical USB port limit (with Kernel>Quirks>XhciPortLimit=False). This USBPorts.kext does not have port HS14 (the internal Bluetooth USB port). We can no longer boot with more than 15 logical USB ports starting with Big Sur 11.3. This EFI also includes USBPorts-16.kext that you can edit to customize your own USB port map. USBPorts-16.kext includes all 16 of the available logical USB ports on the G3, G4 and G5 Minis.

Before using this EFI, replace the following PlatformInfo>Generic values in config.plist with your own (use https://github.com/corpnewt/GenSMBIOS):

• MLB
• ROM
• SystemSerialNumber
• SystemUUID

This EFI enables the boot chime. If you want OpenCore to load faster, disable UEFI>AudioSupport and delete the UEFI Audio driver (in config.plist).

 

 

 

[MacKonsti]

Hi @tonyx86 as I am following your log/diary of changes here out of technical interest (because getting a used G4/G5 in Europe is friggin' expensive) it's a shame you don't start up a Git Hub repo with all this great knowledge that would be shared/viewed by even more people!

 

So I've been meaning to ask you a couple of things:

 

a) I see you use (and update) NVMeFix kext ; have you finally confirmed that your hack/NVMe is really benefitting from its use, eventually? I am using a SABRENT NVMe (Phison) and I could not determine via Intel Power Gadget if using NVMeFix has an impact; sleep works OK. Perhaps only power consumption is the proof?

 

b) On my Intel NUC10 that has a front USB-C port, I tried (OK I admit with a USB-A-to-C dongle/converter) to rotate the use of the plugged device, and did not see a change of the USB HSxx device used in IORegistryExplorer, as the one you discovered recently. Can I ask you as to the types of USB-C plugged devices or adapters used? Were they native USB-C devices or USB-3-to-USB-C controllers etc.? Could it be a difference in the USB-controller chipset used, I wonder?

 

Thanks again for keeping posting your findings!

[deeveedee]

1 hour ago, MacKonsti said:

a) I see you use (and update) NVMeFix kext ; have you finally confirmed that your hack/NVMe is really benefitting from its use, eventually? I am using a SABRENT NVMe (Phison) and I could not determine via Intel Power Gadget if using NVMeFix has an impact; sleep works OK. Perhaps only power consumption is the proof?

I have not confirmed the necessity of NVMeFix.kext nor have I confirmed its benefit to my hack.  It appears to me that my rig works the same with and without it.  I normally try to include only those elements that are required, but in this case, I'm trying to create an EFI that accommodates as many people (and their configurations) as possible.  I believe that some NVMe SSDs will require this kext, and those who don't won't be harmed by it.

 

1 hour ago, MacKonsti said:

b) On my Intel NUC10 that has a front USB-C port, I tried (OK I admit with a USB-A-to-C dongle/converter) to rotate the use of the plugged device, and did not see a change of the USB HSxx device used in IORegistryExplorer, as the one you discovered recently. Can I ask you as to the types of USB-C plugged devices or adapters used? Were they native USB-C devices or USB-3-to-USB-C controllers etc.? Could it be a difference in the USB-controller chipset used, I wonder?

You experience the same behavior with your HSxx device as I do, so I'm not sure what to explain.  When I insert a USB2 device in either orientation into my USBC port, the logical port identity has the same HSxx identifier.  It's only when I insert a USB3 device that I notice a change in SSxx identity when I rotate the device.  USBC is a form-factor and electrical connector specification.  Is it possible that your USBC port is USB2-only?  According to HP specifications of my EliteDesk Mini, my USBC port is a USB3.1 port.  USBC ports can be used for display as well (mine is not).  If you believe that your USBC port is USB3.x and you are not observing an SSxx identity of the port when you insert a USB3 device, then I believe you are missing something in your USB port map or possibly missing a kext/driver?  Not certain.  When I was missing one of the  USBC SSxx identifiers in my USB port map, the port assumed its HSxx identity when I inserted a USB3 device.  I hope that helps.

 

2 hours ago, MacKonsti said:

Thanks again for keeping posting your findings!

You are welcome!  Glad that you continue to find this interesting (and hopefully helpful).  I'd like to pursue your github suggestion, but am too busy with other things at the moment.  Hopefully this thread can offer some of the benefits of a github repo for now.

[deeveedee]

I have added macOS installation instructions with Open Core here.  My production baseline is now Open Core.  CLOVER has served me well and I still admire, encourage and follow CLOVER's development.

[MacKonsti]

On 3/2/2021 at 12:49 AM, tonyx86 said:

Before using this EFI, replace the following PlatformInfo>Generic values in config.plist with your own (use https://github.com/corpnewt/GenSMBIOS):

• MLB
• ROM
• SystemSerialNumber
• SystemUUID

Hello mate, a quick question if you know... on Clover the value for ROM was set to be UseMacAddr0 but I have not found concrete information for OpenCore what we are supposed to put (encoded Base64 of course).

 

So if I run (from OpenCore package) macserial --sys (no arguments) I get ROM: FFFFFFFFFFFF as result, but not sure if this is correct either.

 

a) any idea where we can find ROM value injected by Clover in IORegistry? (via IORegistry Explorer)

 

b) what kind of information have you put in your OpenCore configuration as ROM? All the configs shared around contain <data>ESIzRFVm</data> which translates as "11 22 33 44 55 66" in HEX so I am sure this isn't correct

 

I ask because GenSMBIOS doesn't provide ROM data at all, I've tried many options, so not sure if ROM is provided... Only Serial, BoardSerial and SmUUID are provided. Thanks!

Edited March 7, 2021 by MacKonsti

[deeveedee]

@MacKonsti I haven't performed a "from scratch" OC install (all of my installs are migrations from CLOVER), so I haven't had to generate a new ROM value.  For new ROM value, you should be able to use the same method that works for CLOVER: use a network MAC Addr.  See here.  

[MacKonsti]

Thanks for your reply @tonyx86 but as you saw in the main Clover thread, perhaps, on my hack the BIOS/firmware doesn't return/provide the MAC address of the LAN controller to be used so I have to resort to this type of solution by hard-coding it on the ROM <data> in both Clover and OpenCore. Thanks for the Dortania link, I will apply this tonight and update my Repository comments/guide too.

 

Edited March 8, 2021 by MacKonsti

[deeveedee]

@MacKonsti Your ROM information will be helpful to others who are trying to create an EFI from scratch (instead of a migration from CLOVER).  Thank you for posting!  I may need to include your comments in my instructions, since it is clear that GenSMBIOS is only part of the solution.  As usual, your questions and answers have provided me with another learning experience.  Thank you!

[deeveedee]

Thanks to recommendations from @theroadw (in another forum) and @anthonyuk (here), I will be changing my OC EFI baseline to eliminate the use of RtcMemoryFixup.kext / rtcfx_exclude boot-arg.  My new OC EFI will include an RTC patch that changes RTC memory length to 0x02 (exactly what @Slice's CLOVER does with "Fix RTC" to prevent RTC corruption).  Those who want to test their 800 G4 and G5 Minis with this new EFI can try the attachment.

 

The attached EFI has the following changes from OC0.6.7-EFI-r001:

OC 0.6.7 R002 BETA
Config.plist changes

• 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 changes

• Removed RTCMemoryFixup.kext

ACPI changes

• 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)

How this change works:
SSDT-AWAC-HPET-RTC.aml sets STAS = 0x02 which disables Devices AWAC and RTC. SSDT-AWAC-HPET-RTC.aml defines a new Device (RTC0) (which replaces the disabled RTC) that sets RTC memory length = 0x02.

OC0.6.7-EFI-r002.zip

Edited April 3, 2021 by tonyx86

[deeveedee]

Download-Fritz implied here that RtcMemoryFixup.kext is used to patch RTC memory when Hibernate and "FileVault 2 Unattended Restart" are used. I don't use Hibernate or FV2 Unattended Restart with my hack, so I do not need RtcMemoryFixup.kext (with custom rtcfx_exclude). This should be my last post about RtcMemoryFixup.kext, as I have switched to the RTC patch mentioned here.  By eliminating RtcMemoryFixup.kext, we no longer need to be concerned with finding a new rtcfx_exclude range each time we apply system updates.  

 

To confirm correct application of the RTC patch, open IORegistryExplorer and confirm that RTC is deleted, RTC0 is detected and RTC.IODeviceMemory.length = 0x2.

 

IORegistryExplorer: RTC0

Spoiler

I re-ran Geekbench 5 to confirm that the RTC patch (instead of RtcMemoryFixup.kext) does not hurt performance. GB5 score seems unphased by the patch.

GB5 Scores for HP EliteDesk 800 G5 Mini / i7-9700 / 32GB DDR4

Spoiler

 

Edited March 30, 2021 by tonyx86

[deeveedee]

In preparation for my next OC EFI, I have updated ACPI patches with STA methods that conditionally enable/disable added devices for macOS. These updated ACPI patches are attached. The changes affect the following SSDTs:

• SSDT-DMAC
• SSDT-PLUG
• SSDT-PMCR
• SSDT-PPMC
• SSDT-XSPI

Note that these STA updates are important if you intend to boot multiple OSes with a single boot loader (e.g. you intend to boot Windows and macOS with OpenCore). I boot only macOS with OC, so I am not able to fully test these changes.

I would welcome and appreciate review and feedback for these proposed ACPI patches - especially from people who are booting both Windows and macOS with OC. Thank you.

 

ACPI.zip

Edited March 31, 2021 by tonyx86

[MacKonsti]

Hi @tonyx86 so you added a condition if not "Darwnin" to disable the SSDT hacks, correct? Seems it may be indeed needed for dual OS booting systems. Sorry that I still can not join the EliteDesk family, they are bloody expensive over her  Perhaps adding the DSL code in the ZIP file would allow people to read and appreciate the code, too (quicker than disassembling it, I mean). That way any useful comments in the DSL are kept for us to read (at least, this is what I do, you saw my repo). Cheers mate.

 

Question: What does your Device (PPMC) refer to, as hardware? What does lspci report for address 0x001F0002 I mean? My advice is to keep these in comments next to device name like I do, so you recall fast. Thanks.

[deeveedee]

@MacKonsti Device (PPMC) is not detected (doesn't appear in IORegistryExplorer) on my hack nor is it detected on a real MacMini8,1.  I include it only because it's part of a real MacMini8,1 ACPI, but I don't know what it does.  I wish I had a more intelligent answer for you.  May be it's more cosmetic - not sure.  You are correct - the SSDT edits now include the "if not Darwin" condition with the following nuances:

• SSDT-PLUG wraps the _DSM method in the if condition (there is no _STA method)
• SSDT-PMCR's _STA method returns 0x0B on true condition (_OSI("Darwin")), where the other SSDT _STA methods return 0x0F (0x0B matches the returned value in a real MacMini8,1 ACPI
• SSDT-XOSI returns the original _OSI(Arg0) on false condition _OSI("Darwin")

I modeled SSDT-PLUG after the recommended "pre-built" SSDT-PLUG from the Dortania Guide.

Edited April 1, 2021 by tonyx86

[MacKonsti]

Mate, if you also look on my repo, the first thing I always do on hacks is to launch Ubuntu and run lspci -nn so I can detect all the devices outside the Mac/Windows domain (obviously all are enabled in BIOS before starting tweaking).

If Hackintool does not find or report a physical device at 00.1f.02 in PCIe tab, then do not include PPMC mate. Do not add stuff that aren't there on your hardware

What you need to compare is also the devices list of lspci -nn or Hackintool on that original MacMini8,1 too. What is it? SBUS? SPI?

 

This is what I mean by lspci -nn on Terminal (from my NUC8) check first column:

00:00.0 Host bridge [0600]: Intel Corporation Core Processor Host Bridge/DRAM Registers [8086:3ed0] (rev 08)
00:02.0 VGA compatible controller [0300]: Intel Corporation Coffee Lake Iris Plus Graphics 655 [8086:3ea5] (rev 01)
00:08.0 System peripheral [0880]: Intel Corporation Core Processor Gaussian Mixture Model [8086:1911]
00:12.0 Signal processing controller [1180]: Intel Corporation Coffee Lake Thermal Subsytem [8086:9df9] (rev 30)
00:14.0 USB controller [0c03]: Intel Corporation Coffee Lake USB 3.1 xHCI Host Controller [8086:9ded] (rev 30)
00:14.2 RAM memory [0500]: Intel Corporation Coffee Lake Shared SRAM [8086:9def] (rev 30)
00:14.3 Network controller [0280]: Intel Corporation Coffee Lake CNVi Wireless [8086:9df0] (rev 30)
00:16.0 Communication controller [0780]: Intel Corporation Coffee Lake MEI Controller [8086:9de0] (rev 30)
00:17.0 SATA controller [0106]: Intel Corporation Coffee Lake SATA Controller [AHCI Mode] [8086:9dd3] (rev 30)
00:1c.0 PCI bridge [0604]: Intel Corporation Coffee Lake PCI Express Root Port #1 [8086:9db8] (rev f0)
00:1c.4 PCI bridge [0604]: Intel Corporation Coffee Lake PCI Express Root Port #5 [8086:9dbc] (rev f0)
00:1d.0 PCI bridge [0604]: Intel Corporation Coffee Lake PCI Express Root Port #9 [8086:9db0] (rev f0)
00:1d.6 PCI bridge [0604]: Intel Corporation Coffee Lake PCI Express Root Port #15 [8086:9db6] (rev f0)
00:1f.0 ISA bridge [0601]: Intel Corporation Coffee Lake LPC Controller [8086:9d84] (rev 30)
00:1f.3 Audio device [0403]: Intel Corporation Coffee Lake High Definition Audio Controller [8086:9dc8] (rev 30)
00:1f.4 SMBus [0c05]: Intel Corporation Coffee Lake SMBus Host Controller [8086:9da3] (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Coffee Lake SPI Controller [8086:9da4] (rev 30)
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (6) I219-V [8086:15be] (rev 30)
01:00.0 Storage controller [ff00]: Realtek Semiconductor Co. Ltd. RTS522A PCI Express Card Reader [10ec:522a] (rev 01)
02:00.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:00.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:01.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
03:02.0 PCI bridge [0604]: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] [8086:15da] (rev 02)
6c:00.0 USB controller [0c03]: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] [8086:15db] (rev 02)
6d:00.0 Non-volatile memory controller [0108]: Phison Electronics Corporation E12 NVMe Controller [1987:5012] (rev 01)

I always have this as my guide to know exactly what I assign and where (look at my SSDT-NAMES.dsl for example, where I assign cosmetic device "names" to non-named devices thanks to this list above, that would otherwise appear on IORegistryExplorer as some funny-named PCI device with numbers. Just the name, no code or properties). This is why MCHC needs to be named nowadays; in many motherboards, the first device 00:00.0 has no "name" in IORegistry so we just baptise this as "MCHC" and nothing else, so macOS won't complain.

 

Another example: device 00:1f:02 on my old NUC is the SATA port ; same on my MSI Core i7-4790K board:

00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04)

00:1f.2 SATA controller [0106]: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] [8086:8c82] 

So do think twice before assigning some device with a fixed hardware address like in your case.... Just my very friendly advice.

This is why it doesn't show on your IORegistry LOL but better avoid it.

[deeveedee]

@MacKonsti It's good advice.  If the real MacMini8,1 didn't have PPMC in its ACPI (even though it doesn't "have" the device), then I'd agree.  It's only my attempt to make my HackMini as close to a MacMini8,1 as possible.  Note that if I had followed the typical approach, I'd still have HPET enabled (which is NOT enabled on a real MacMini8,1). There's definitely more than one way to skin this cat.

[deeveedee]

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) 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 OC 0.6.8.

 

EDIT 2: Andrey1970 provided a table here 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.

 

config.plist.zip

Edited April 5, 2021 by tonyx86
Added note about AppleInput properties

[MacKonsti]

1 hour ago, tonyx86 said:

@MacKonsti It's good advice.  If the real MacMini8,1 didn't have PPMC in its ACPI (even though it doesn't "have" the device), then I'd agree.  It's only my attempt to make my HackMini as close to a MacMini8,1 as possible.  Note that if I had followed the typical approach, I'd still have HPET enabled (which is NOT enabled on a real MacMini8,1). There's definitely more than one way to skin this cat.

If you try to clone too hard a MacMini you may fall in your own trap... I mean, there is an extent (in my belief) of what can be cloned. But getting Hackintool to run on a real MacMini8,1 or get its original IORegistryExplore dump is the best thing. Look here please.

 

P.S. Time that you moved to GitHub too mate!

Edited April 1, 2021 by MacKonsti