Contribute
Register

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

Status
Not open for further replies.
For those who would like to help test my currently preferred solution to @theroadw 's potential resource conflict here, replace SSDT-PMCR.aml (in EFI/OC/ACPI) with the attached version. The attached version implements the change here. Please report any issues with this "new" PMCR. Thank you.
 

Attachments

  • SSDT-PMCR.aml.zip
    639 bytes · Views: 65
In real Macbooks 15,1 (my SMBIOS) apple uses PMCR with memory so I'm keeping it as before and just disabling PRRE.
But it's an interesting find.

Also @deeveedee you may have missed this one, it's cosmetic only.

 
@theroadw My only concern with my originally proposed PRRE._STA=0 is that something in hardware is using PRRE's reserved memory regions and that a change in ACPI won't prevent the conflict. I am becoming more and more convinced that the safest way to handle the conflict you observed is to change Device PMCR (something we do control).

EDIT: I need to remind myself that we are running macOS on Windows hardware. Duplicating ACPI from a real Mac may not always be the best solution (although I do start with that approach in my hacks).
 
I may or may not upgrade to OC0.6.9, so I'm posting my current EFI for OC 0.6.8 here. This EFI includes the changes listed below (changes from OC0.6.8-EFI-r001 currently attached to Post #1). I'll attach this to Post #1 after more testing (and hopefully some feedback from others on the change to Device PMCR).

OC 0.6.8.R003 BETA
config.plist
- Removed SAT0->SATA ACPI patch
- New: ACPI > Add SSDT-USBX.aml
- Changes in OC 0.6.8 R002 (below)
ACPI
- Added SSDT-USBX.aml to inject the same power properties as USBPorts.kext
- Modified SSDT-PMCR.aml: removed Memory32Fixed resource setting (potential conflict with original Device PRRE)

OC 0.6.8 R002 (Never posted. Changes included in R003)
config.plist
- Fixed errors identified by OCValidate tool
- 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>!
 

Attachments

  • OC0.6.8-EFI-r003.zip
    2.3 MB · Views: 61
@theroadw My only concern with my originally proposed PRRE._STA=0 is that something in hardware is using PRRE's reserved memory regions and that a change in ACPI won't prevent the conflict. I am becoming more and more convinced that the safest way to handle the conflict you observed is to change Device PMCR (something we do control).

EDIT: I need to remind myself that we are running macOS on Windows hardware. Duplicating ACPI from a real Mac may not always be the best solution (although I do start with that approach in my hacks).

Without knowing how the OS uses PMCR, and if different SMBIOS's change anything with it's use, you could also be potentially creating a problem. Since PRRE doesn't attach to anything in OSX, it's very unlikely we'll have problems by disabling the device altogether.
I guess there's no right or wrong here. Both approaches may work perfectly
 
@theroadw As long as we're guessing about how these reserved memory buffers work, I mapped out the Memory32Fixed buffers declared within the HP EliteDesk 800 G4 Mini DSDT. There are "free" regions that are unclaimed: 0xFE020000-0xFE100000, 0xFED94000-0xFEE00000 and 0xFEF00000-0xFF000000. If we believe that Device PMCR just needs a free buffer of length 0x00010000, then for the HP EliteDesk 800 G4, the following PMCR._CRS might be acceptable:

Code:
                Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
                {
                    Memory32Fixed (ReadWrite,
                        0xFE020000,         // Address Base
                        0x00010000,         // Address Length
                        )
                })

EDIT: I am currently running with with this PMCR:

Screen Shot 2021-04-26 at 12.49.46 PM.png
 
Last edited:
@theroadw As long as we're guessing about how these reserved memory buffers work, I mapped out the Memory32Fixed buffers declared within the HP EliteDesk 800 G4 Mini DSDT. There are "free" regions that are unclaimed: 0xFE020000-0xFE100000, 0xFED94000-0xFEE00000 and 0xFEF00000-0xFF000000. If we believe that Device PMCR just needs a free buffer of length 0x00010000, then for the HP EliteDesk 800 G4, the following PMCR._CRS might be acceptable:

Code:
                Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
                {
                    Memory32Fixed (ReadWrite,
                        0xFE020000,         // Address Base
                        0x00010000,         // Address Length
                        )
                })

EDIT: I am currently running with with this PMCR:

View attachment 516427

I think that is the best solution, how did you get the 'free" regions? Just what's not declared used on the DSDT and SSDT's?
 
Last edited:
Caution: for anyone who attempts to duplicate this method on their rig, the "free" memory regions will be platform-specific. If you don't have an HP EliteDesk 800 G4/G5 Mini, you will need to calculate your own "free" memory regions.

@theroadw Yes. A tedious search for Memory32Fixed in the HP EliteDesk 800 G4 ACPI. I recorded the Base and Length and then calculated each buffer range (Base + Length). The result showed the "holes" in the memory mapped buffers.

EDIT: In the case of the HP EliteDesk 800 G4 Mini, there was nothing of importance in the SSDTs - only the DSDT.

EDIT2: @theroadw My memory mapping is attached.
 

Attachments

  • EliteDesk800-Memory32Fixed.pdf
    33.9 KB · Views: 75
Last edited:
Other than the Variable names _Y?? and UBTC which is absent, on the Zbook it's identical.
Thanks for the info!
Now I'm doing the same with PMCR, time will tell if it's right.
 
@theroadw There's a piece that I don't understand - more eyes on this could help. In the MacMini8,1 DSDT, there is a declared OperationRegion in SystemMemory at 0xFE000000 with a length 0x1EFF. I don't think it's a coincidence that the Base of this OperationRegion matches the Base of PMCR._CRS.

MacMini8,1 DSDT
Code:
       OperationRegion (PMST, SystemMemory, 0xFE000000, 0x1EFF)
       Field (PMST, DWordAcc, NoLock, Preserve)
       {
           CMDR,   32,
           IBSY,   1,
           IERR,   1,
...

Comparison of the MacMini's DSDT to the 800 G4's DSDT reveals that the MacMini's OperationRegion PMST is analogous to the G4 Mini's OperationRegion PWMR. Unfortunately, the 800 G4 Mini's PWMR does not have a hard-coded Base. It's Base is defined by PWRM (don't confuse PWMR with PWRM).

800 G4 Mini DSDT
Code:
    OperationRegion (PWMR, SystemMemory, PWRM, 0x1E30)
    Field (PWMR, DWordAcc, NoLock, Preserve)
    {
        CMDR,   32,
        IBSY,   1,
        IERR,   1,
...

Comparing further, we see that both the MacMini8,1 DSDT and the 800 G4 Mini DSDT declare method IPCW that accesses fields in PMST and PWMR respectively.

Without knowing the value of PWRM (which is defined at run-time since it's not hard-coded in ACPI), I'm concerned that changing the PMCR._CRS buffer location breaks something.

EDIT: By the way... I tried to set the Base of PMCR._CRS's buffer = PWRM, but the compiler didn't like it.
 
Last edited:
Status
Not open for further replies.
Back
Top