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

[theroadw]

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

ZBook G5

 

[deeveedee]

I used Rehabman's ACPIDebug to dump the value of PWRM. Maybe not so surprisingly, the value of PWRM is

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

It looks to me like we can leave the original Acidanthera PMCR patch.

 

[theroadw]

LOL, and I went back to my first config patch just zeroing out the region in PRRE.

 

[stormblessed]

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.

 

[deeveedee]

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

 

[deeveedee]

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

 

[theroadw]

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

 

[deeveedee]

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.

 

[theroadw]

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)

 

[rafale77]

Attempting an update to 11.3 right now after having upgraded to 0.6.8 and the @deeveedee's ACPI changes... Fingers crossed.