Contribute
Register

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

Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
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: 31
Last edited:
Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
An OC Configurator that. you might find interesting ...

For all of my OC config.plist modifications, I have been using XCode (version 12.4 at the time of this post) instead of a 'configurator.' I tend to stay away from configurators, because they add uncertainty during the debugging process (I'm debugging the configurator AND my config.plist). There is an OC configurator that looks promising. Check this out. I won't be supporting this tool (at least not yet), but it might be worth investigating. It includes the OCValidate tool that highlights any errors in your config.plist (same ocvalidate utility included with the OpenCore download). You'll find that if you load my config.plist from OC0.6.8-EFI-r001, there are non-critical errors that would need to be fixed if any of identified properties were to be enabled (they are currently disabled, and thus do not cause any issues).
 
Last edited:
Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
In the other forum's OpenCore Discussion, Andrey1970 indicates that renaming SAT0 to SATA may be harmful. Since it's only cosmetic, I plan to remove the SAT0->SATA ACPI patch from my next posted EFI.

EDIT: In the other forum's OpenCore Discussion, a "new" concensus is that USB Power Properties should be specified in both USBX (SSDT injection) and in USBPorts.kext. In my next EFI, it is likely that I will add SSDT-USBX SSDT (attached) to inject the same USB Power Properties currently specified in USBPorts.kext.

@Carstimann and others who see a USB error message when plugging high-current devices into their USB3 ports: After adding SSDT-USBX SSDT (attached), I am still finding that I must plug the high-current device (e.g. iPhone 7) into the right-front USB3 port. The right-front USB3 port on our 800 Minis is labeled with a "lightning bolt" which indicates that it is a high-current port. If I plug my iPhone 7 into the left-front USB3 port, I see a USB error related to charging current. Note that if my iPhone 7 is fully charged, I can plug it into any port (because it doesn't need to be charged).
 

Attachments

  • SSDT-USBX.aml.zip
    696 bytes · Views: 27
Last edited:
Joined
Jul 21, 2011
Messages
277
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Hi, I found a possible problem on my ZBook, and it seems it also affects your build.

SSDT-PMCR creates the device PMCR but this new device uses the same Memory range as device PRRE

Device (PRRE)
{
Name (_HID, EisaId ("PNP0C02")) // _HID: Hardware ID
Name (_UID, "PCHRESV") // _UID: Unique ID
Name (_STA, 0x03) // _STA: Status
Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFD000000, // Address Base
0x006A0000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00000000, // Address Length
_Y11)
Memory32Fixed (ReadWrite,
0xFD6F0000, // Address Base
0x00910000, // Address Length
)
Memory32Fixed (ReadWrite,
-> 0xFE000000, // Address Base
0x00020000, // Address Length
)
Memory32Fixed (ReadWrite,
0xFE200000, // Address Base
0x00600000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFF000000, // Address Base
0x01000000, // Address Length
)
IO (Decode16,
0x0000, // Range Minimum
0x0000, // Range Maximum
0x01, // Alignment
0xFF, // Length
_Y10)
})

Device (PMCR)
{
Name (_HID, EisaId ("APP9876")) // _HID: Hardware ID
Name (_STA, 0x0B) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
Memory32Fixed (ReadWrite,
-> 0xFE000000, // Address Base
0x00010000, // Address Length
)
})
}

This could (or not) be a problem if the OS uses both devices. I'm not sure if OSX actually uses PRRE but it could be a future problem.

My temporary testing solution is to find and replace that section with an ACPI patch and in theory at least it will never show up as a gremlin in the future.

Code:
<dict>
    <key>Comment</key>
    <string>PRRE Memory overlap Fix</string>
    <key>Count</key>
    <integer>0</integer>
    <key>Enabled</key>
    <true/>
    <key>Find</key>
    <data>/QAAkQCGCQABAAAA/gAAAgCGCQA=</data>
    <key>Limit</key>
    <integer>0</integer>
    <key>Mask</key>
    <data></data>
    <key>OemTableId</key>
    <data>AAAAAA==</data>
    <key>Replace</key>
    <data>/QAAkQCGCQABAAAAAAAAAACGCQA=</data>
    <key>ReplaceMask</key>
    <data></data>
    <key>Skip</key>
    <integer>0</integer>
    <key>TableLength</key>
    <integer>0</integer>
    <key>TableSignature</key>
    <data>AAAAAA==</data>
</dict>

This Patch replaces:
Memory32Fixed (ReadWrite,
0xFE000000, // Address Base
0x00020000, // Address Length
)
with:
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00000000, // Address Length
)

And now that memory address doesn't show in IOREG under PRRE, and hopefully this change doesn't have any ill effects.
If you find a way to deactivate PRRE and replace it with a modified version without that section altogether, I think that would be an even better approach.
 
Last edited:
Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
EDIT: See here for my currently preferred approach to this potential resource conflict.

@theroadw Good catch!

@theroadw I'm not sure if this is legit, but I created a hotpatch that replaces PRRE._STA with PRRE.XSTA and injects a new PRRE._STA. The result is that Device PRRE is not detected in MacOS. My work is attached. Look in ACPI>Patch and ACPI>Add in the prre-sta.plist and see the attached SSDT-PRRE.aml. I'm running with this now. Let me know what you think. Note that _STA is Name (_STA, 0x03) in the original DSDT ( which I'm changing to Name (XSTA, 0x03) ) and I'm defining its replacement as a Method conditional on _OSI("Darwin").
 

Attachments

  • prre-sta.plist.zip
    1.1 KB · Views: 25
  • SSDT-PRRE.aml.zip
    629 bytes · Views: 30
Last edited:
Joined
Jul 21, 2011
Messages
277
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Well the problem with your config rename is that you're matching/renaming every _STA in your DSDT+SSDT's
So I modified your plist to only match the _STA in the PRRE device. Also attached is one that will kill it at the same time (no ssdt required as the rename changes the STA to Zero directly). This is not Windows Friendly if you use OC as your main bootloader, but I use refind so not a problem.

I didn't think completely getting rid of PRRE was the idea, I thought of replacing it with a PRRE without the offending memory range, but this also works I guess.
 

Attachments

  • kill-prre-sta.plist.zip
    1.2 KB · Views: 24
  • onlyrename-prre-sta.plist.zip
    1.3 KB · Views: 26
Last edited:
Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
Well the problem with your config rename is that you're matching/renaming every _STA in your DSDT+SSDT's
So I modified your plist to only match the _STA in the PRRE device. Also attached is one that will kill it at the same time (no ssdt required as the rename changes the STA to Zero directly). This is not Windows Friendly if you use OC as your main bootloader, but I use refind so not a problem.

I didn't think completely getting rid of PRRE was the idea, I thought of replacing it with a PRRE without the offending memory range, but this also works I guess.
@theroadw Take another look at my config.plist. I'm using OC's Base and Count. My patch replaces the first single instance (Count = 1) in Base \_SB.PCI0.PRRE. Our patches do the same thing. Also, I wanted to make sure it was "Windows-Friendly" for those who boot Windows and MacOS with OC (I don't, but some do).

EDIT: @theroadw Just to make sure my ACPI patch is working the way I intended (and I'm understanding OC correctly), I examined the original DSDT for the EliteDesk 800 Mini. In the DSDT, the definition of HPET follows the definition of PRRE. My HPET is still disabled (with HPTE=0), so HPET._STA remains untouched by my patch. Thanks again for finding this potential memory conflict.


EDIT2: For those who test a PRRE patch with Big Sur 11.2.3 and earlier (to either change PRRE or disable it completely), you won't observe any MacOS differences before and after the patch. Currently (as theroadw indicated), MacOS appears to ignore PRRE, so its Memory32Fixed buffer at 0xFE000000 is ignored by MacOS, too (there is no conflict with PMCR). As long as MacOS continues to ignore PRRE in Big Sur and future versions of MacOS (highly likely), this patch will not make any difference to the operation of our hacks. I am testing with the patch here (which disables Device PRRE when running MacOS, but leaves PRRE untouched for Windows) just to be certain that it has no unintended consequences. I may or may not include this patch in the next posted EFI. I encourage others to test and provide feedback.

EDIT3: See here for my currently preferred approach to this potential resource conflict.
 
Last edited:
Joined
Jul 21, 2011
Messages
277
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
@theroadw Take another look at my config.plist. I'm using OC's Base and Count. My patch replaces the first single instance (Count = 1) in Base \_SB.PCI0.PRRE. Our patches do the same thing. Also, I wanted to make sure it was "Windows-Friendly" for those who boot Windows and MacOS with OC (I don't, but some do).
Gotcha, it was late and I didn't see the base stuff. I could never make that base/count stuff work properly in the past so I just always make long unique matches.

What is PRRE anyways?
 
Joined
Sep 22, 2011
Messages
1,372
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
Gotcha, it was late and I didn't see the base stuff. I could never make that base/count stuff work properly in the past so I just always make long unique matches.

What is PRRE anyways?
The Base/BaseSkip/Count fields make OC hotpatching incredibly powerful. I patched the ACPI of an HP Envy Laptop (a work in progress) and found the hotpatching to be very intuitive with OC. Who would have thought it would be so easy to replace _STA?

I don't know what PRRE is, but it doesn't appear in a real MacMini8,1 ACPI and MacOS doesn't bind any drivers to it. I've been testing with and without the PRRE patch (PRRE disabled in MacOS) and I haven't found a difference. Hopefully others will test.

Your discovery made me realize that I didn't do a good enough job with reviewing the original ACPI before implementing patches and quite honestly, I just got lucky with PMCR. I never thoroughly checked Memory32Fixed regions for overlap/conflict and will definitely add this to my ACPI patching list. Thank you!
 
Joined
Jul 21, 2011
Messages
277
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Glad I helped, I've been troubleshooting my audio (CX8400 codec) and why it mutes the speaker only when on battery power (aspecially after sleep/wake) and only if using a battery manager like SMCBatteryManager. The log shows Battery polling takes place just before the mute, which leads me to believe this speaker muting problem is something in my ACPI config that isn't quite right, and when the battery manager polls the battery, something changes in the EC memory (or somewhere else?) and the result is the speaker mutes (but there is no log entry for the speaker muting or any sign in the OS other than just no sound, so the OS is oblivious to the fact). Because of this I've been forced to use VoodooHDA for audio but decided to dig in deeper into all the patches, etc... and I found this one.
 
Top