Jump to content

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


deeveedee
964 posts in this topic

Recommended Posts

12 hours ago, deeveedee said:

On February 14, 2023, HP released BIOS upgrades for the EliteDesk 800 G4 and G5 Minis (version 02.22.00 Rev.A and version 02.16.00 Rev.A respectively).  I haven't tested either of these BIOS upgrades and welcome test results from others.

 

Good works on hackintosh

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

I just started using my newly acquired G4 mini the other day. The only issue I have, which bugs me quite a bit, as I rely on that functionality is wake on network access, which does not work. Neither for the ethernet connection nor for WiFi. I tried enabling wake on WiFi in the BIOS but that did not help. Nor did it make a difference wether I used itlwm (emulated ethernet for wifi) or AirPortItlwm ("true" WiFi) for the Intel WiFi card. I now wonder if there's anything else to try or if the Broadcom WiFi card would make a difference. I don't want to spend those 40 Bucks without knowing it would, though. Could you report wether wake on network access (for file sharing and Remote Desktop) works for anyone and if so, what are your settings?

Link to comment
Share on other sites

@Rastafabi I disable WOL and Wake for Network Access out of habit for all my hacks, so I can't comment on how well it works.  Have you tried Wake for Network Access with the wired LAN (disable Wi-Fi) to see if it works at all on this hack?

 

EDIT: Just re-read your post and see that you have tested Wake on wired Ethernet and it didn't work for you.  Can you please post your EFI?

 

EDIT2: See this thread.  Looks like you need to modify IntelMausi Info.plist

 

795390814_Screenshot2023-05-06at10_09_37AM.png.4bab55aac7d94b8f64e605ff770d57f4.png

Edited by deeveedee
Link to comment
Share on other sites

47 minutes ago, deeveedee said:

@Rastafabi I added a note to my previous post.  Looks like you need to modify IntelMausi Info.plist.

Thanks for the suggestion. However it does not work either. Now the machine either kernelpanics on sleep, does not sleep at all, or sleeps and power offs the network, but wakes again sporadically.

 

EDIT:

Here is my entire EFI folder in case it's still helpful.

Edited by Rastafabi
Attached Link to EFI folder
Link to comment
Share on other sites

2 hours ago, Rastafabi said:

Thanks for the suggestion. However it does not work either. Now the machine either kernelpanics on sleep, does not sleep at all, or sleeps and power offs the network, but wakes again sporadically.

 

I've never attempted Wake on LAN because I've heard that it causes problems with sleep on hackintoshes.  I was thinking that maybe you knew differently.  I don't think it's anything you're doing.

 

EDIT: I did review your config.plist and noted a couple of things:

  • No graphics DeviceProperties?
  • Do your Wired LAN testing with all Intel Wi-Fi/BlueTooth kexts completely disabled to eliminate variables while you attempt to get wake on LAN working with Wired LAN.  Also disable Intel Wi-Fi and BlueTooth in BIOS while testing wired Wake On LAN.
  • I'm totally guessing, but there is a DeviceProperty pci-aspm-default.  You can read more about it here and by searching for other posted explanations.   Sometimes, I've seen others resolve power-related stability issues by setting pci-aspm-default=0 for the specific device in the config.plist DeviceProperties.  For example, when I was experiencing some problems on my HackBookPro6,2, I set PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) > pci-aspm-default = 0 in my config.plist.  I actually don't know if it helped. You can use Hackintool to find the Device ID of your network devices (so that you can add attribute pci-aspm-default in your config.plist).

 

I'm out of ideas at this point.  Interested to learn about your progress.

 

 

Edited by deeveedee
Link to comment
Share on other sites

GOT IT WORKING (wake on demand [ethernet])

 

I found a precompiled IntelMausi kext, that solves to dark wake error I faced previously and enables wake on demand via ethernet.

Currently Wake on Lan is enabled in the BIOS which is a must.

The following PCIe injection might be is optional:

Quote

<key>PciRoot(0x0)/Pci(0x1F,0x6)</key>
<dict>
         <key>mausi-force-wol</key>
         <integer>1</integer>
         <key>pci-aspm-default</key>
         <integer>2</integer>
</dict>

 

Intel wireless can be enabled simultaneously. Wake on Intel wireless still isn't working though.

 

One oddity I found is that IntelMausi needs to be injected via OpenCore. When installed at /L/E the system panics. This is true though for any IntelMausi variant.

 

___________________

 

I also fiddled around with the wake on lan settings as I read that it did make a difference for some and I got as far as not to kernel panic on every sleep attempt, using a custom compiled MausiEthernet kext, though I did not achieve getting working sleep as the machine dark-wakes instantly again. Thus I do not know wether it would actually work this way. All I ever got was the following wake message.

$ log show --style syslog --start "2023-04-07" | fgrep "Wake reason"
2023-05-07 02:58:37.804364+0200  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI

Nor did it work trying anything else like messing around with the PCI port sleep parameters @deeveedee mentioned above.

Quote

pci-aspm-default=0

 

 

All that said It did work occasionally, but this was not repeatable at all and another sleep cycle or a reboot without altering the settings broke it again. 

 

__________

EDIT:

I reintroduced the graphics device properties though they do not make a difference apart from omitting one UI glitch logging the user out.

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

The last to standing issues I have are DRM and the Combo audio Jack, which only works as line-in.

 

DRM could be solved with the hp rx 560 dgpu and an MacPro 7,1 SMBIOS. This is rather expansive though. Alternatively a m.2 PCIe riser and a generic GPU can be used which isn't as clean and requires modifying the case/running the GPU externally and feeding out the riser-cable through the optional port cover.

Another potential solution could be downgrading the drivers to 10.15, as it shipped with a compatible firmware. I hesitate to try cause of the hassle of patching the OS and running a non vanilla install. 

 

Any suggestions regarding the audio jack? I would love to use my wired headphones for Facetime calls.

 

EDIT:

My bad. The port works fine. Apparently I just missed setting it as the output device… Not used to doing this manually.

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

@Rastafabi I was reviewing the history of IntelMausi WOL.  Based on this compare, It looks to me like WOL functionality was merged into the "official" Acidanthera IntelMausi.kext.  According to the IntelMausi Readme, WOL should work out of the box with Acidanthera's IntelMausi 1.0.7 if all is properly configured.  Have you tried testing the official Acidanthera IntelMausi.kext with boot-arg -mausiwol?

 

I think that if it works with the boot-arg -mausiwol but not without,there might be something incorrectly configured, but I don't have experience with it to comment further.

Edited by deeveedee
Link to comment
Share on other sites

4 hours ago, deeveedee said:

@Rastafabi I was reviewing the history of IntelMausi WOL.  Based on this compare, It looks to me like WOL functionality was merged into the "official" Acidanthera IntelMausi.kext.  According to the IntelMausi Readme, WOL should work out of the box with Acidanthera's IntelMausi 1.0.7 if all is properly configured.  Have you tried testing the official Acidanthera IntelMausi.kext with boot-arg -mausiwol?

 

I think that if it works with the boot-arg -mausiwol but not without,there might be something incorrectly configured, but I don't have experience with it to comment further.

To be sure, as I have been testing various scenarios previously, I just retried. However it does not work using Acidanthera's IntelMausi kext. While the G4 mini does sleep fine even with WOL enabled in the BIOS, it's not available to be awoken from another Mac's Finder/a Bonjour aware VNC client.

Edited by Rastafabi
Link to comment
Share on other sites

@Rastafabi  If you are saying that your hack does not wake-on-lan with Acidanthera's IntelMausi 1.0.7 and boot-are -mausiwol, but your WOL does work with IntelMausi from TonyMac, that is very confusing to me.

Link to comment
Share on other sites

@deeveedee basically this matches my observations, yes. Keep in mind however that I actually did not test WOL just yet, but actually macOS‘ wake on demand (WOD?) feature. 
 

WOL might work with either approach. I might be able to do some testing later this week.

Edited by Rastafabi
Link to comment
Share on other sites

@Rastafabi ... then this is not an issue specific to this MacMini8,1 and is something common to hackintoshes.  I think you should continue the discussion here or start a new thread to debug hackintosh wake-on-lan.  The Dortania Guide for Open Core says to disable WOL in BIOS in order to ensure proper operation of sleep / wake.

Link to comment
Share on other sites

Yeah. Wake on Demand really seems to be a hit or miss on hackintoshes. I'm glad that I got it to work though. I got sleep problems during my testing as well, so no wonder that in general it's recommended to disable it. However this also seems to disable the wake on demand ability as apparently the LAN controller gets deactivated on S3 as well as S5 sleep states. I will share my insights in the thread you linked @deeveedee

Link to comment
Share on other sites

@Rastafabi I think this is a bit confusing, so I'd like to clarify.  I have no sleep / wake problems (what you are calling Wake on Demand) with this HackMini8,1.  The only sleep problem to my knowledge was the problem fixed by this ACPI patch (for those booting from a SATA SSD instead of an NVMe SSD.  I did have sleep / wake problems when I had attempted to use Intel Wi-Fi/BlueTooth (earlier in the development of the Intel Wi-Fi/BlueTooth solution), so I never pursued it and don't support it in this thread (although there are plenty of other discussions to support it).

Link to comment
Share on other sites

I have attached my latest OC 0.9.2 EFI to Post #1.  If you are happy with your current EFI, there is no compelling reason to upgrade to OC 0.9.2.  This new EFI has the following changes from my previously post OC 0.9.0 EFI:

 

OC 0.9.2 EFI R001

  • EFI/BOOT: Update BOOTx64.efi
  • EFI/OC: Update OpenCore.efi
  • EFI/OC/Drivers: Update OpenRuntime.efi, AudioDxe.efi, ResetNvramEntry.efi
  • EFI/OC/Kexts:
    • Upgrade AppleALC.kext 1.8.0 -> 1.8.2
    • Upgrade Lilu.kext 1.6.4 -> 1.6.5
  • EFI/OC/config.plist
    • Add Kernel > Quirks > DisableIoMapperMapping (Boolean, False)
    • Add UEFI > Output > GopBurstMode (Boolean, False)
    • Add UEFI > Output > InitialMode (String, Auto)
    • Misc > Boot > HideAuxiliary = True (Hide Aux items like Recovery Volumes from boot menu). Press Space bar to show aux items.
    • Misc > Security > ScanPolicy = 17760515 (Hide EFI from OC boot menu)
  • EFI/OC/Tools: Update tools
Edited by deeveedee
  • Thanks 2
Link to comment
Share on other sites

When I state (and have stated) that there is no reason to upgrade to the newest version of OC if you are happy with your older version of OC, this is not a criticism of Acidanthera or of Open Core.  On the contrary.  This is a testament to the quality of the Open Core development and the amazing configuration management performed by the Acidanthera team.  The fact that we can continue to run reliably with older versions of Open Core is amazing.  Never take for granted the fact that we are getting this incredible software for free and that there are people in this forum who tirelessly continue to provide solutions and assistance without receiving any compensation.

  • Like 2
Link to comment
Share on other sites

I have noticed that some people who attempt to use my published EFI are confused by the multiple USB ports kexts in my EFI.  I thought that the use of the kexts was clearly explained in my instructions, but apparently not well enough.  I will be changing future published EFIs so that the sample USB kexts "USBPorts-16.kext" (which is NOT to be used without editing it) and "USBPorts-noHS14.kext" (which does not have the BlueTooth USB port enabled and which is the same as the USBPorts.kext) are moved to a folder within the OC/Kexts folder.  The new folder will be named SampleUsbKexts (OC/Kexts/SampleUsbKexts).  The only kext that will remain in OC/Kexts will be USBPorts.kext.  Until this change is made, please carefully read my instructions here.

 

EDIT: Since I'm the worst judge of my own writing, if you have any suggestions for my instructions so that they are easy to read and understand, please send me a private message with your suggestions.  Thank you.

Edited by deeveedee
Link to comment
Share on other sites

Hi, @pastrychef!  Long time, no talk!  Great to hear from you.  I do not own an EliteDesk with an RX560, but I have seen reports by others who had the RX560 working in earlier versions of macOS.  Does the card work for you with Monterey or Big Sur?

Link to comment
Share on other sites

×
×
  • Create New...