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

[deeveedee]

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

 

[deeveedee]

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

 

[theroadw]

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.

Spoiler: ACPI PATCH

<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.

 

[deeveedee]

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").

 

[theroadw]

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.

 

[deeveedee]

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.

 

[theroadw]

@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?

 

[deeveedee]

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!

 

[theroadw]

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.

 

[deeveedee]

@theroadw. Good detective work! Are you using Rehabman's ACPI Debug? I'm using it with OC0.6.8 / Catalina 10.15.7 on an HP Envy x360 15m (Kaby Lake R / UHD620) and it's very helpful.