Device (HPET) disabled on a real MacMini8,1 - Do Skylake and newer hacks require HPET?

[deeveedee]

I believe that I have answered my own question: My HackMini8,1 does NOT need Device (HPET).  This may be true for other newer hacks.  Leaving this question open and would welcome feedback / comments from others.

=======================================

I was reviewing the ACPI for a real MacMini8,1 and noticed that HPET._STA returns 0 on condition _OSI("Darwin").

 

                Device (HPET)
                {
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (OSDW ())   // If (_OSI("Darwin"))
                        {
                            Return (Zero)
                        }

                        If ((OSYS >= 0x07D1))
                        {
                            Return (0x0F)
                        }
                        Else
                        {
                            Return (0x0B)
                        }

                        Return (Zero)
                    }
                }

 

Just to confirm, I looked in the IORegistry dump for a real MacMini8,1 and see that Device (HPET) is not present.

 

I have been patching HPET to make sure it is enabled for as long as I've been hacking.  Is this Device (HPET) behavior new with newer Mac models, or is the status of HPET necessarily different for hacks than it is for Macs?

 

EDIT: I examined the ACPI for a real iMac18,3 and see that Device (HPET) is disabled there, too.  On a real iMac18,3, HPET._STA returns 0 on condition _OSI("Darwin") and HPET does not appear in the iMac18,3 IORegistry dump.

 

EDIT2: I examined the ACPI for a real MacPro5,1 and see that Device (HPET) is enabled.  Unlike the MacMini8,1 and iMac18,3, HPET appears in the IORegistry dump for a real MacPro5,1.  It does appear that the status of HPET has changed with newer Macs.  Would welcome feedback from others.  Do newer hacks still require HPET?

Edited January 4, 2021 by tonyx86
Fixed link

[deeveedee]

I tried to test disabling HPET on my hack by renaming HPET._STA to HPET.XSTA and adding a new HPET._STA that always returns 0, but my patch didn't work.  My attempt was an adaptation of the standard HPET._CRS -> HPET.XCRS rename, but simply replacing "CRS" in the patch with "STA" did not work.  I'd like to experiment with HPET._STA, but don't know how to generate new ACPI renames.  Does anyone know how to rename HPET._STA to HPET.XSTA?  I'd like to try setting HPET._STA to 0 for an experiment, but don't want to inject a new DSDT.

[deeveedee]

My HPET._STA rename/patch did not work (although CLOVER r5122 indicated that my rename was applied and my SSDT-HPET was injected successfully), but I was able to disable HPET on my HackMini8,1 by setting HPTE = 0 in _SB._INI (on my HP EliteDesk 800 G4 Mini, HPET._STA is conditional on HPTE):

 

                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (HPTE)
                    {
                        Return (0x0F)
                    }

                    Return (Zero)
                }

 

I am currently running Catalina 10.15.7.03 on my HackMini8,1 with HPET disabled (confirmed that HPET does not appear in IORegistry Explorer) and so far, I don't notice any issues.

Edited January 4, 2021 by tonyx86
Fixed link

[deeveedee]

I have confirmed that Apple has been setting HPET._STA = 0 when running macOS since Skylake platforms (maybe earlier).  I'm surprised that I haven't seen this in any guides and that even the latest guides still explain how to enable / patch HPET for newer platforms. I have concluded that HPET should not be enabled on newer hacks, so my next posted EFI for my HackMini8,1 will have HPET._STA = 0 (deleting HPET from macOS).  With HPET disabled, I suspect that IRQ patching (e.g. with SSDT-TIME) is unecessary (since IRQ conflicts with HPET won't be an issue) and will experiment with this.

Edited January 4, 2021 by tonyx86
Fixed link

[deeveedee]

I've been told by a person I trust that this HPET._STA=0 is well known, so thank you everyone for following along in my journey as I discovered what you already knew. I'll chalk this up to the fact that my last hack was a Socket 1156 / H55 Chipset.  If this helped you to discover what I just learned, glad we made that discovery together.  Better late than never :)

[hardcorehenry]

9 hours ago, tonyx86 said:

I've been told by a person I trust that this HPET._STA=0 is well known, so thank you everyone for following along in my journey as I discovered what you already knew. I'll chalk this up to the fact that my last hack was a Socket 1156 / H55 Chipset.  If this helped you to discover what I just learned, glad we made that discovery together.  Better late than never

 

Here is different approach to HPET problem, that might interest you. I tested it for a while, works as expected, but I stick to mine reworked HPET from SSDTTime.

 

SSDT-IRQFix.dsl

Edited December 7, 2020 by hardcorehenry

[deeveedee]

3 hours ago, hardcorehenry said:

 

Here is different approach to HPET problem, that might interest you. I tested it for a while, works as expected, but I stick to mine reworked HPET from SSDTTime.

 

 

That's good info and seems to validate what I'm observing in this thread.   That approach is pre-Skylake (Broadwell and Haswell are mentioned in the thread) which is consistent with what I'm observing in this thread.  I only went back as far as Skylake to confirm that Apple sets HPET._STA=0 for Skylake and newer architectures.  My very limited finding is that with HPET._STA=0 for Kabylake and CoffeeLake (HPET does not appear in IORegistry), I don't need any IRQ patches and everything I've tested (sleep, wake, audio, restart, shutdown...) works perfectly.

Edited December 7, 2020 by tonyx86

[hardcorehenry]

On 12/7/2020 at 1:26 PM, tonyx86 said:

 

That approach is pre-Skylake

 

It is not, you most probably missed comment I pointed on screenshot attached. Additionaly IRQ fixes as expected in real OSX. (I have {0, 8, 11, 12}, but it's up to you).

 

Spoiler

 

In recap, in SSDT-IRQFix.dsl you should replace  Store (0x0F, \_SB.PCI0.LPCB.HPET._STA) with Store (Zero, \_SB.PCI0.LPCB.HPET._STA) and compile it.

 

[deeveedee]

2 hours ago, hardcorehenry said:

 

It is not

 

Ok - I misunderstood you before.  I'm glad your approach is working for you.

 

EDIT: @hardcorehenry I re-read your link and agree with andrezerocross who mentioned in that link that the correct HPET setting for Skylake and newer is HPET._STA=0 (it is what I independently discovered by reviewing the ACPI and IORegistry of real Apple Macs).  I am not sure if vit9696 is correct when he mentioned in that link that directly setting HPET._STA=0  may violate ACPI spec if HPET._STA is already defined as a method (which it is in my HP EliteDesk 800 G4 Mini and G3 Mini ACPI), but directly setting HPET._STA=0 via an SSDT patch does not work for me on my HP EliteDesk 800 G4 and G3 Mini.  I agree with Andrey1970AppleLife who mentioned in that link that we shouldn't touch the TIMR, IPIC and RTC IRQs (if we set HPET._STA=0).

 

While the debate still exists in the link that you posted, I don't believe that we can safely say that the correct approach is a simple assignment that directly sets HPET._STA=0 (or 0x0F) without knowing the original ACPI that we're patching.  The safest approach to disabling HPET (which I believe is correct for Skylake and later platforms) is to examine the original ACPI and patch accordingly.

Edited December 9, 2020 by tonyx86

[hardcorehenry]

3 hours ago, tonyx86 said:

 

Ok - I misunderstood you before.  I'm glad your approach is working for you.

 

EDIT: @hardcorehenry I re-read your link and agree with andrezerocross who mentioned in that link that the correct HPET setting for Skylake and newer is HPET._STA=0 (it is what I independently discovered by reviewing the ACPI and IORegistry of real Apple Macs).  I am not sure if vit9696 is correct when he mentioned in that link that directly setting HPET._STA=0  may violate ACPI spec if HPET._STA is already defined as a method (which it is in my HP EliteDesk 800 G4 Mini and G3 Mini ACPI), but directly setting HPET._STA=0 via an SSDT patch does not work for me on my HP EliteDesk 800 G4 and G3 Mini.  I agree with Andrey1970AppleLife who mentioned in that link that we shouldn't touch the TIMR, IPIC and RTC IRQs (if we set HPET._STA=0).

 

While the debate still exists in the link that you posted, I don't believe that we can safely say that the correct approach is a simple assignment that directly sets HPET._STA=0 (or 0x0F) without knowing the original ACPI that we're patching.  The safest approach to disabling HPET (which I believe is correct for Skylake and later platforms) is to examine the original ACPI and patch accordingly.

 

It seems you are right after all. Playing with IRQ when HPET disabled might be tricky. Unfortunately I'm on Haswell platform and can't prove otherwise.

[Slice]

If you don't need HPET then it doesn't mean you have to disable it. I have HPET on my Skylake platform without any conflicts.

[deeveedee]

Agreed.  Same could be said for many ACPI patches.  It's a personal preference that I have to make my hacks look as much like a real Mac as possible.  The good thing about hacking is that there is generally more than one "right" solution and there is plenty of room for individual preferences.

Edited December 12, 2020 by tonyx86

[deeveedee]

Adding a note about applying HPET._STA=0 ACPI patches with CLOVER: if you do set HPET._STA=0, my limited testing has shown that patching RTC, TIMR, IPIC to exclude IRQs is no longer necessary (since there are no longer risks of IRQ conflicts with HPET).  However, if you are using CLOVER's FixRTC ACPI patch, remember that this patch changes RTC length to 0x02 (to address RTC corruption issues) in addition to excluding RTC IRQ.  If you are using CLOVER and you patch your ACPI to set HPET._STA=0, you may still need CLOVER's FixRTC ACPI patch (for the RTC memory length patch).  An alternative to CLOVER's FixRTC ACPI patch (if you set HPET._STA=0 and no longer need to exclude RTC IRQ) may be Acidanthera's RTCMemoryFixup.kext with a custom rtcfx-exclude range.  At the time of this writing, I have not tested RTCMemoryFixup.kext with CLOVER.

Edited December 14, 2020 by tonyx86