Jump to content

[GUIDE] Catalina, Big Sur, Monterey, Ventura, Sonoma on HP EliteDesk 800 G4/G5 Mini - The perfect MacMini8,1 Hackintosh


deeveedee
874 posts in this topic

Recommended Posts

Upgrade to Monterey 12.5 proceeded without issues.  I'm using the OC 0.8.2 EFI attached to Post #1.

 

Spoiler

1144410867_ScreenShot2022-07-23at1_08_08PM.png.052b3723bd53a4e485c7e54038025f69.png

 

 

EDIT: If you want to change the description in "About This Mac," edit /Users/[your user name]/Library/Preferences/com.apple.SystemProfiler.plist

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

15 minutes ago, Jazzoo said:

You need to be more specific about your hardware. It's possible to make wifi working, can't say so about the bluetooth. Depends on your wifi/bt card.

can you tell me how to enable wifi  i added wifi kext but it doesn't show wifi at all.  maybe somewhere in config.plist some setting to edit?

my hardware HP ELITEDESK G4 8600T mini.

Edited by luky35
Link to comment
Share on other sites

@luky35 You have an Intel Wi-Fi card.  This is not the thread to get your Intel Wi-Fi working.  Please search for the many other threads that explain how to get Intel Wi-Fi working in a hackintosh.

 

You can start with hints here, but this is the wrong thread in which to solve this.

Edited by deeveedee
Link to comment
Share on other sites

8 hours ago, deeveedee said:

@luky35 You have an Intel Wi-Fi card.  This is not the thread to get your Intel Wi-Fi working.  Please search for the many other threads that explain how to get Intel Wi-Fi working in a hackintosh.

 

You can start with hints here, but this is the wrong thread in which to solve this.

@deeveedee You can delete my posts about the Wifi card, I found what I was looking for.

Link to comment
Share on other sites

@luky35 I'm glad you found what you were looking for.  I'm just a regular contributor to this forum with no more "power" than you have.  I can't delete your posts any more than you can delete mine.  You and I are both unpaid participants who volunteer our time and effort here to learn and to help others.  Your posts will remain in this thread unless one of the moderators of this forum feels the need to delete them.

  • Like 1
Link to comment
Share on other sites

This post is for the advanced tinkerers and will probably bore you if you're just happy to turn on your hack without wanting to know how it works (like my wife with her car).  I'm posting this to record my own learning (which is still partial at this point) and to hopefully help you to learn, too.  It is likely that this post will be modified as I learn more (and possibly change or correct my thinking).

 

I have been reading about ACPI Method _OSI and learned a few interesting things:

  1. ACPI Method _OSI (Operating System Interfaces) returns "True" when the currently running operating system matches the evaluated argument (e.g., _OSI("Windows 10") returns "True" when the currently running operating system is "Windows 10").  Method _OSI was originally intended to help identify which operating systems a PC supports.  Its use has been expanded by some BIOS developers to identify other supported components (like "Processor Aggregator Device"). 
  2. BIOS developers DO NOT test all ACPI paths for all operating systems/versions, because PCs are designed and tested to support specific OS versions (e.g., the HP EliteDesk 800 G4 and G5 Minis are designed and tested by HP to support Windows 10 and Windows 11).  Even though the HP EliteDesk 800 G4 and G5 Mini BIOS has conditional ACPI execution paths for many different versions of Windows (and even for Linux), it is likely that only Windows 10 and 11 have been rigorously tested.
  3. Because BIOS developers do not test all ACPI paths invoked for unsupported Operating Systems, executing ACPI code paths invoked when an _OSI match is not found (as would be the case when the PC is running macOS) can result in unpredictable system behavior.  It is best to make sure that only manufacturer-tested ACPI code paths are executed.

An ACPI patching strategy implemented by some hackintosh hackers is to override ACPI Method _OSI so that, when running macOS, the overriden _OSI method "pretends" that the currently running OS is one of the Windows operating system versions supported by the hacked PC.  In order to do this correctly, one must inspect the extracted, unpatched ACPI from their hacked system to evaluate various ACPI paths that are conditionally executed depending on the currently running operating system (which is determined by using Method _OSI).  After evaluating the various conditional ACPI paths, test macOS while emulating each of the supported Windows versions (by overriding Method _OSI) to determine which emulated Windows version results in the best operation of macOS.  This less than stellar explanation should make more sense with the illustrations below.

 

The basic _OSI override technique is to rename _OSI to XOSI (via an ACPI patch) and then to implement a new method XOSI similar to the following:

Method XOSI (Arg0)
{
   if (_OSI("Darwin")) // If the current operating system is macOS
   {
      if (Arg0 == "Windows 2015")  // If checking for Windows 10 compatibility
      {
         return (Ones)  // Method _OSI returns 0xffffffffffffffff (Ones) for true and Zero for false
      }
   } else {
      return (_OSI(Arg0)) // If we're not running macOS, perform the original _OSI check
   }
}

 

An inspection of the EliteDesk 800 G4 and G5 Mini BIOS reveals ACPI code paths that are conditionally executed depending on the Operating System Version ("Linux" and multiple Windows Operating System Versions).  There are two different operating system version checks in the HP EliteDesk 800 G4 and G5 Mini BIOS.  You can inspect the DSDT yourself to see that the EliteDesk 800 G4 and G5 Mini BIOS checks for operating system versions up to Windows 2015 (Windows 10) in one code path and up to Windows 2017 (Windows 10, version 1703) in the other code path.  Because of the way Method _OSI is implemented, _OSI returns "True" for all Windows versions matching and older than the currently running Windows OS.  This means that if the EliteDesk 800 G4 or G5 Mini is running Windows 11, _OSI("Windows 10") and "OSI("Windows 10, version 1703) will return "True."

 

Because of the way our original Method XOSI was implemented combined with our hack's DSDT, our hack's ACPI was emulating Windows 2017 when running macOS.  It is unlikely that HP is going to change the operating system checks in our BIOS, so we can simplify Method XOSI to always return true when running macOS when checking for currently running "Windows 10" OR currently running "Windows 10, version 1703" as follows:

 

Method XOSI (Arg0)
{
   if (_OSI("Darwin")) // If the current operating system is macOS
   {
      if ((Arg0 == "Windows 2015") || (Arg0 == "Windows 2017"))  // If checking for Windows 10 or Windows 10, version 1703 compatibility
      {
         return (Ones)  // Method _OSI returns 0xffffffffffffffff (Ones) for true and Zero for false
      }
   } else {
      return (_OSI(Arg0)) // If we're not running macOS, perform the original _OSI check
   }
}

 

I am currently running with the simplified SSDT_XOSI attached.  Since the original Method XOSI was returning true for all Windows OS versions, this simplified XOSI does not change the behavior of our hacks.  This changed SSDT_XOSI is only part of my learning.  Hopefully this helps you to understand a little more, too.

 

 

 

SSDT-XOSI.aml.zip

Edited by deeveedee
Updated attached SSDT-XOSI
  • Like 2
Link to comment
Share on other sites

@deeveedee, Did you find any benefits from using the XOSI patch to make you ACPI think it is Windows? I looked through my DSDT and couldn't find anything of significance. It appears to be mostly used in another method called OSYS and there is actually an SSDT-OSYS floating around which has for purpose to enable laptop functionalities. Just curious if the G4/G5 have anything attached to it.

Link to comment
Share on other sites

@rafale77 SSDT_XOSI was part of my early solution (see here).  The addition of this SSDT is something I learned from Rehabman and I never bothered to test without it.  It's possible that it's not needed.  For this hack, it ensures that only HP-tested modes of the ACPI are exercised.

Link to comment
Share on other sites

Hi @deeveedee I remember from old readin' that the XOSI was mainly helpful to get the PC to behave like Windows, and most notably regarding the internal ports for BTLE. Some people's PCs were not showing up internal BTLE or USB ports if not using XOSI.

Some others could be related to sleep as some darker ACPI features we don't know about weren't used (on non-Windows :D )

On my Intel NUC, I have not seen any other behaviour with or without XOSI. I did start with it, of course, but after disabling it, I have not noticed any other behaviour.

It is true that some BIOSes or Firmwares have some other code run/performed if it's not a Windows OS running -- but it has never been clear nor statistically proven (by the majority of users, for example) as to what this really offers.

Perhaps in modern bootloaders, it's obsolete. Who knows... except those who master ACPI :)

Just my 5cents

Edited by MacKonsti
  • Like 2
Link to comment
Share on other sites

@MacKonsti You could say the same about SSDT-PTS (Rehabman's Arg0 fix), since most who remove it will not see any difference.  The more I hack, the more I realize about the EFI that if it works, it's good.  I'm sure we'll continue to debate techniques until Apple completely discontinues macOS support for Intel. :)

  • Thanks 1
Link to comment
Share on other sites

Agreed, on most recent systems with newer firmwares/BIOS, the Prepare-to-Sleep (PTS) code is working just fine without the need to inject that old argument.
Rehabman's work in the past was amazing but don't forget, he was addressing equally older hardware e.g. 3rd or 4th generation CPUs.

So all old hacks, in my view, may not even be considered (I cannot comment for AMDs however).
I tried to get to a minimum of settings on bootloaders so that they are easier to maintain as hacks, especially for me, to be honest. Except for laptops that could be another nightmare, sometimes, desktops appear to need less tweaking.

But learning comes from tweaking of course :D

 

Don't jinx it yet :D:D (for Apple dropping macOS)

  • Like 1
Link to comment
Share on other sites

I don't have an HP to study anymore but I looked deeper into the DSDT of my lenovo and found that XOSI itself doesn't do anything useful for MacOS:

It would enable PAGD, Processor Aggregator Device, which MacOS doesn't use.

If I was spoofing as linux, it would disable another device LBAI... not relevant in our Hacks.

It is then used in the OSYS method which returns a windows dependent value. OSYS, if the OS used is a newer windows triggers an additional dependency, a device (PEPD) I don't have, for several devices (i.e SAT0, GFX0) so I think it could actually potentially break them. And then it enables some I2C devices I don't have and are also disabled in my DSDT. It is no surprise it isn't doing anything.

That being said, it is very machine and BIOS dependent... My Hack philosophy is to minimize patches and codes, while mimicking as much as possible a real mac but there are many other ways to do this...

Edited by rafale77
  • Like 1
Link to comment
Share on other sites

@rafale77 Good points.  FYI - My posted XOSI (and any you see in other hacks) won't enable Processor Aggregator Device.    I stand corrected - you are correct that my simplified XOSI does return true for XOSI("Processor Aggregator Device") which has the unintended consequence of enabling Device PAGD.  I agree that this is not harmful but not desirable.  

 

I may be tweeking my simplified XOSI.  Thanks for reviewing.

 

EDIT: @rafale77 - I have modified my simplified SSDT-XOSI here (which is specific to the HP EliteDesk 800 G4 / G5 Mini BIOS) so that PAGD is not enabled.  Thanks again for reviewing.

Edited by deeveedee
Link to comment
Share on other sites

×
×
  • Create New...