Contribute
Register

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

Joined
Sep 22, 2011
Messages
1,381
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
@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:
Joined
Jul 21, 2011
Messages
279
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
Edit- I see what you mean now following IPCW...

Maybe disabling PRRE or removing (zeroing) the Memory overlap is a better (less risky) solution.

What I could find is that in a MacBookPro PMST is almost identical to my PWRM except for a couple of fields related to changing the IGPU power states _PS0 and _PS3.
This is also above my pay grade, but I would venture to say they are more than related, and as long as we don't rename PWRM to PMST, then OSX won't really even use the memory. My guess is that OSX likes the range to be there and available, (for PMST) but since we don't have that, then it's just sitting there.
As to what we would gain/loose if we used it... who knows, probably hybernation related.


MacBookPro 16,1

Screen Shot 2021-04-26 at 7.32.27 PM.png



ZBook G5

Screen Shot 2021-04-26 at 7.33.18 PM.png
 
Last edited:
Joined
Sep 22, 2011
Messages
1,381
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
I used Rehabman's ACPIDebug to dump the value of PWRM. Maybe not so surprisingly, the value of PWRM is

Code:
kernel: (ACPIDebug) ACPIDebug: { "PWRM: ", 0xfe000000, }

It looks to me like we can leave the original Acidanthera PMCR patch.
 
Joined
Jul 21, 2011
Messages
279
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
LOL, and I went back to my first config patch just zeroing out the region in PRRE.
 
Joined
Nov 9, 2019
Messages
26
Motherboard
Elitedesk 800 G5 mini
CPU
i5-9500T
Graphics
UHD 630
Mobile Phone
  1. iOS
Me again, it's been so long since I booted into windows that now I realize that sound on windows is a LOT louder than with hackintosh.
Is it a normal thingy? The volume is so low, that sometimes I can't even hear a thing. If it's a normal thing, I'm sorry pointing it out.
 
Joined
Sep 22, 2011
Messages
1,381
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
@theroadw As I was reviewing the differences between the real Mac ACPI and the G4 Mini ACPI, I concluded that PMCR (and PRRE) are simply marking reserved memory locations used by OperationRegions PMST in a real Mac and by PWMR in the G4 Mini). The fields in each OperationRegion are used by Method IPCW. Having both PMCR and PRRE mark the Memory32Fixed at 0xfe000000 as "reserved" doesn't hurt anything. I'm leaving PRRE unpatched. Ultimately, this helps to explain why we weren't observing any differences in behavior with the different patching techniques.

@stormblessed In the OC config.plist UEFI > Audio, there are properties VolumeAmplifier and MinimumVolume. I think you should be able to play with these properties (very carefully - start with your speaker volume low).

EDIT: @stormblessed It just occurred to me that you are talking about the audio volume after the OS has booted (not the boot chime). The settings in the config.plist are for the boot chime (I don't think they affect the audio volume after boot).
 
Last edited:
Joined
Sep 22, 2011
Messages
1,381
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
My final EFI release for OC 0.6.8 is now attached to Post #1. After BETA EFI versions R002 and R003, I have settled on the changes below (from R001) for my OC 0.6.8 EFI baseline (R004). If you use this EFI, be sure to populate Platform > Generic > MLB, ROM, SystemSerialNumber and SystemUUID with your own values in config.plist. Also be sure to customize USBPorts.kext as per the installation instructions (if you need to customize it).

OC 0.6.8 EFI R004: Changes from R001

config.plist
  • Removed SAT0->SATA ACPI patch
  • New: ACPI > Add SSDT-USBX.aml
  • 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>!
ACPI
  • Added SSDT-USBX.aml to inject the same power properties as USBPorts.kext
  • NOTE: SSDT-PMCR.aml remains unchanged from R001
 
Joined
Jul 21, 2011
Messages
279
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
@theroadw As I was reviewing the differences between the real Mac ACPI and the G4 Mini ACPI, I concluded that PMCR (and PRRE) are simply marking reserved memory locations used by OperationRegions PMST in a real Mac and by PWMR in the G4 Mini). The fields in each OperationRegion are used by Method IPCW. Having both PMCR and PRRE mark the Memory32Fixed at 0xfe000000 as "reserved" doesn't hurt anything. I'm leaving PRRE unpatched. Ultimately, this helps to explain why we weren't observing any differences in behavior with the different patching techniques.
Sounds like a very logical probability, the only thing I don't like is the Plug and Play part of device PRRE, maybe that's all it does, maybe it does more (if there's drivers)
Either way I don't think it is worth spending more time on it.
 
Joined
Sep 22, 2011
Messages
1,381
Motherboard
HP EliteDesk 800 G5 Mini
CPU
I9-9900
Graphics
UHD 630
Mac
  1. Mac mini
Mobile Phone
  1. iOS
This is also above my pay grade, but I would venture to say they are more than related, and as long as we don't rename PWRM to PMST, then OSX won't really even use the memory.
I'm responding to this just for everyone's benefit, since we're all learning here. I reviewed ACPI documentation and believe I understand the purpose of OperationRegion and Field constructs in ACPI. OperationRegion labels a memory region (PWMR). Field assigns variable names to memory locations within the OperationRegion. Renaming PWMR to PMST isn't really the concern (or necessary). As long as the associated Field references the correct OperationRegion, the OperationRegion name doesn't matter. We could implement an ACPI patch to rename OperationRegion PWMR to PMST and also to modify the associated Field (changing PWMR to PMST), but the net result would be no change. I think the only thing that "matters" within the Field construct is the name of the variables (e.g. CMDR, IPSW, etc.) which are referenced by Method IPCW.
 
Last edited:
Joined
Jul 21, 2011
Messages
279
Motherboard
Zbook G5 17"
CPU
i7
Graphics
AMD WX-4170
Mac
  1. MacBook Pro
  2. Mac mini
  3. Mac Pro
I'm responding to this just for everyone's benefit, since we're all learning here. I reviewed ACPI documentation and believe I understand the purpose of OperationRegion and Field constructs in ACPI. OperationRegion labels a memory region (PWMR). Field assigns variable names to memory locations within the OperationRegion. Renaming PWMR to PMST isn't really the concern (or necessary). As long as the associated Field references the correct OperationRegion, the OperationRegion name doesn't matter. We could implement an ACPI patch to rename OperationRegion PWMR to PMST and also to modify the associated Field (changing PWMR to PMST), but the net result would be no change. I think the only thing that "matters" within the Field construct is the name of the variables (e.g. CMDR, IPSW, etc.) which are referenced by Method IPCW.
Thank you for the explanation, yes I understood from your previous post and I get that the name doesn't matter because it's internal and it's the call to Method IPCW the one that matters.
(I didn't go back to edit my post)
It's the difference between doing some light weekend coding and hardware design I guess... apples-to-oranges (pun intended)
 
Top