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

@rafale77 When I last reviewed someone's IOReg who was using SSDT-USBX.aml and USBPorts.kext that had differing USB Power Properties, I noted that their IOReg contained both sets of USB Power Properties (albeit in different locations in the IOReg).  If I remember correctly, one injected the power properties at the XHC device level and one injected the power properties on a per-port level.  Take a look at IOReg again with different USB Power Properties in USBX and USBPorts and see if you find both sets of power properties in the IOReg.

 

There was a brief discussion in the Open Core General Discussion that concluded that having both USBX and USBPorts was best (using the same USB Power Properties in each).  It doesn't surprise me that this debate continues :)

Edited by deeveedee
Link to comment
Share on other sites

Ok.  I'm sticking with my recommendation to include the same USB Power Properties in both SSDT-USBX and USBPorts.kext.  I suspect a more careful analysis will find that including the same in both does not hurt anything and I don't want to retest my EFI.  If you find otherwise and believe that there is a problem with including the same USB Power Properties in both USBX and USBPorts, please let me know.

Link to comment
Share on other sites

I really don't think it hurts anything either. I am just on a mission to streamline and eliminate unnecessary and redundant patches/drivers and I am discovering that there is more of these than I thought as people have been adding stuff over time. I am a bit OCD that way...

Some people make recommendations because for their context and their time it worked but then it sticks even under other context and new patches come in making the previous patch unnecessary but the recommendation stuck and it becomes the norm etc... My EFI 0.8.3 has gone from being >6MB to now <3MB. Zipped it is now ~1.4MB. That's a lot of unnecessary files and codes I took out.

Edited by rafale77
Link to comment
Share on other sites

@rafale77 , @deeveedee - Currently I am using the EFI provided on page 1 and everything works great. Generated SMBIOS, tried usb remap - doesn't really help. I am at my parents house for a few weeks using LAN and I gave the wifi card to a friend of mine for tests. It's BCM94360NG. Same in my laptop. Bluetooth is ON only when I use it and then turn it back off. Annoying...but that's for now, not a big deal. On my laptop sometimes I have sound glitches after sleep and the only solution is to open SysPref/Sounds/Input and the sound is immediately back working :D Also USB related problem, never solved. These problems happens rarely, but still there.

Link to comment
Share on other sites

@Jazzoo Without seeing your EFI, I'm guessing at Bluetooth possibilities (I know that you're using the EFI attached to Post #1, but you'd be surprised at the number of times I've screwed up my EFI while making minor mods).  It's always best to post your EFI if you want assistance.  There is some editing of the USBPorts.kext Info.plist that you need to make in order to ensure properly working Bluetooth.  Since you have mostly working Bluetooth, I'm certain that you've added HS14 to your USBPorts.kext Info.plist.  You also need to make sure that your HS14 port type is 255 (see UsbConnector property):

 

For working Bluetooth, USBPorts.kext Info.plist must define USB Port HS14 with UsbConnector = 255 (0xFF)

Spoiler

1475333315_ScreenShot2022-08-01at5_48_40PM.png.8348499ef6f7f6290bfa503110585dfa.png

 

You also need to make sure that you have only 15 USB Ports defined (which requires removing one port from the USBPorts-16.kext that I provide in the EFI attached to Post #1.

 

One other suggestion for Bluetooth is provided here.

 

EDIT: @Jazzoo If you find that my suggestions don't address your Bluetooth issue, it appears that you're not alone.  Owners of real Macs have reported the same here.  If this is an Apple issue, you may want to search to see if real Mac owners have solved this.  I don't see this on my HackBookPro15,2 and I don't use Wi-Fi/Bluetooth on my HackMini, so I'll try my best to help, but I'm handicapped.

 

I did notice this proposed solution in this thread:

 

MacBook Pro 15" mid-2015 - Monterey 12.1- Same issue - excess CPU usage from bluetoothd process happening daily.

Deleting the com.apple.Bluetooth.*.plist file in ~/Library/Preferences/ByHost/ directory and rebooting worked for me.

(* is a long string of letters / numbers). Issue has not returned for 3-4 days.

 

 

EDIT2: @Jazzoo I tried to duplicate your bluetoothd problem on my HackBookPro15,2. I'm not sure of your exact steps to reproduce, so I performed a simple test where I sent my audio to a bluetooth speaker.  I then closed the hackbook lid to sleep the laptop.  After the laptop was asleep, I opened the lid to wake the laptop.  I did not experience the high-cpu bluetoothd problem.  I observed bluetoothd to use 2.9-3.2% CPU while playing audio to my bluetooth speaker (before and after sleep).  If you have another test, let me know.  Note that I also have a BCM94360NG.

Edited by deeveedee
Link to comment
Share on other sites

I have updated my baseline EFI to OpenCore 0.8.3.  I am using this updated EFI with my production rig running Monterey 12.5 and my test rig running Ventura Beta.  The new EFI (now attached to Post #1) has the following changes:

 

OC 0.8.3 EFI R001

  • EFI/BOOT: Update BOOTx64.efi
  • EFI/OC: Update OpenCore.efi
  • EFI/OC/Drivers: Update OpenRuntime.efi, AudioDxe.efi, ResetNvramEntry.efi
  • EFI/OC/ACPI
    • Simplify SSDT-XOSI to return Ones (true) when _OSI("Windows 2015") || _OSI("Windows 2017"). Note that this change is very specific to the HP EliteDesk 800 G4/G5 Mini ACPI and may not be suitable for other platforms.
  • EFI/OC/Kexts:
    • Update Lilu.kext 1.6.1 -> 1.6.2
    • Update AppleALC.kext 1.7.3 -> 1.7.4
    • Update WhateverGreen.kext 1.6.0 -> 1.6.1
  • EFI/OC/config.plist
    • Removed NVRAM > LegacyEnable
    • Added LoadEarly (boolean, false) to each UEFI > Drivers > Item
  • EFI/OC/Tools: Update tools

 

If you upgrade your EFI, it is best to Reset NVRAM before booting macOS with your new EFI.

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

@deeveedee 

Replaced on Monterey old EFI 0.8.2 with your new 0.8.3 and works great no error.
Also, the Monterey and Ventura USB boot installation starts to install without error.
I don't dare to install Ventura, because I'm afraid that the fan from the processor will go crazy again and work constantly full, even when the PC is idle.

Thank you for your work.

  • Like 1
Link to comment
Share on other sites

@deeveedee 

 

Just for information.
I upgraded the Monterey with a Ventura B2 public and the fan from the processor works normally as on the Monterey. Very interesting.

If I install a clean installation of Ventura, the fan from the processor works constantly at full power, it does not stop at all.
I downloaded your latest EFI OC0.8.3-EFI-R001.zip

Link to comment
Share on other sites

@deeveedee Sorry for the late reply. I put the itwlm.kext so I can use my intel card (9560NGW) and it's working great. Here's my EFI you can take a look.

Generated different SMBIOS. I don't have my bcm wifi/bt card to test now, but everything seems smooth under Monterey and Ventura.

 

EFI 0.8.3

 

The bluetooth problem appears rarely, let's say once per week and only after wake from sleep. I use it mostly for my bt mouse (steelseries wireless) and my speaker (jbl flip 5). I was concerned if the problem comes from the devices I use but even if there is nothing connected to the laptop it peaks the cpu at 100+% until I disable/enable the bluetooth. USB remap doesn't help, tried it many times. I found so many people on internet having the same problem on real macs, may be fresh install will fix it, may be not. I kinda gave up at some point cuz it drives me crazy :D

 

Thanks for your support! You are hero!

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

@Jazzoo That's great news.  Your findings make the low price-point of this hack even more compelling, since people don't have to purchase a new Wi-Fi/Bluetooth card if their rig already has the Intel card.

 

When you first explained your bluetoothd issue here, I interpretted your statement to indicate that the bluetoothd CPU issue was observed with the BCM94360NG card.  Do you observe the bluetoothd CPU issue with Broadcom-based BCM94360NG, Intel-based 9560NGW, or both?

 

EDIT: Note that when I first started hacking my HP Envy x360 Laptop (i5-8250U/UHD620), I tried itwlm.kext with the installed Intel Wi-Fi and I observed sleep issues with Big Sur.  I switched to the BCM94360NG with no additional kexts and the sleep issues were resolved.  I never tested the Intel solution again.  Your results indicate that itwlm.kext has improved.

Edited by deeveedee
Link to comment
Share on other sites

39 minutes ago, Jazzoo said:

@deeveedee Sorry for the late reply. I put the itwlm.kext so I can use my intel card (9560NGW) and it's working great. Here's my EFI you can take a look.

Generated different SMBIOS. I don't have my bcm wifi/bt card to test now, but everything seems smooth under Monterey and Ventura.

 

EFI 0.8.3

 

The bluetooth problem appears rarely, let's say once per week and only after wake from sleep. I use it mostly for my bt mouse (steelseries wireless) and my speaker (jbl flip 5). I was concerned if the problem comes from the devices I use but even if there is nothing connected to the laptop it peaks the cpu at 100+% until I disable/enable the bluetooth. USB remap doesn't help, tried it many times. I found so many people on internet having the same problem on real macs, may be fresh install will fix it, may be not. I kinda gave up at some point cuz it drives me crazy :D

 

Thanks for your support! You are hero!

image.png.93a9fb98d2b9ae41b75b02a63945a964.png

@JazzooYour Config.plist have slight modificatiob needed mainly LoadEarly Needed for OpenRuntime.efi only disable LoadEarly on the Drivers 

  • Like 2
Link to comment
Share on other sites

@datafeedexpert - Good catch! I don't enable LoadEarly in the EFI I provided in Post #1 and I didn't look at this.   I was reading @miliuco 's post here trying to figure out when to enable "LoadEarly" for Drivers.  I interpret the instructions as requiring "LoadEarly" only when using Driver OpenVariableRuntimeDxe.efi (for rigs that don't have proper NVRAM support).  Is my understanding correct?  If so, shouldn't Jazzoo have all Drivers configured with LoadEarly = false?

 

@Jazzoo I reviewed the EFI that you provided (which is why I suggest providing your EFI whenever you ask for help or report a problem).  Here are my observations:

  • You are enabling three USB kexts in your config.plist.  You should only be enabling one.  I can't say if this would be the cause of USB issues that you observed.  I provided USBPorts-16.kext, USBPorts-noHS14.kext as examples and intended for you to only enable USBPorts.kext.  Please re-read my instructions here and here.
    Spoiler

    1254887584_ScreenShot2022-08-03at9_04_58AM.png.7c59f66deee6d1f810006aa2183f4de7.png

  • Your config.plist is missing csr-active-config in NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82.  This may default to 0 (SIP Enabled), but I think that it's a good practice to include this property for clarity.
  • When you post a config.plist on a public forum, delete PlatformInfo > Generic > MLB, ROM, SystemSerialNumber, SystemUUID so you're not sharing private info
  • LoadEarly should be false in your UEFI > Drivers

 

I suspect that some of the issues with your config.plist are because you are using a configurator to configure your config.plist.  With the config.plist that I include with the EFI attached to Post #1, it is my opinion that a configurator doesn't help.  I don't use a configurator, because I don't like the way it makes changes to my config.plist that I don't explicitly define.  Just my preference.  No offense to the many who do use configurators.

Edited by deeveedee
Link to comment
Share on other sites

@deeveedee - Bluetooth peaks occur only with BCM94360NG both on my desktop and my laptop. Since intel 9560NGW has bluetooth 5.1 I am not able to use it under macos (at least I don't know how to enable it). Bluetooth on intel cards used to work with 726X model equiped with bluetooth 4.X. In terms of a signal strenght bcm cards have stronger reception than Intel, not to mention that they get connected twice faster. Intel is still enough for everyday usage so no need to replace it unless you want to squeeze the most of your hack and use sidecar, airdrop etc. Sleep is working without any problems with intel cards here, laptop and desktop tested. 

By the way I have tested Ventura with an old HDD as external drive thru usb-c port. System even sleep/wake properly :D Windows never allowed me even to boot the system from external drive.

 

@datafeedexpert - thanks for the remark! I will fix it later today.

Edited by Jazzoo
Link to comment
Share on other sites

@Jazzoo Thanks for the clarification.  I suggest that you fix your config.plist as I described here and retest.  Your USB ports may be configured incorrectly because you are enabling three different USB kexts.

  • Thanks 1
Link to comment
Share on other sites

Definitely not a secret.  I have mentioned my prefered tool multiple times in this thread and others.  I use XCode to edit plists.  It's just my preference.  Use the tool that you prefer and be sure to understand how the tool may modify your plist in ways that you have not specified.  When creating a hack and experimenting with configuration changes, it's hard enough to debug my own changes, let alone changes that may be made by the configurator.  I prefer to minimize the variables that I need to debug and don't want to spend any time debugging the new version of a configurator.  If you really want to know my methodology, read this entire thread from the beginning.  It's all out in the open.

 

EDIT: @Jazzoo - I believe that LoadEarly should be false for all of your drivers.  It's the way I have configured my EFI attached to Post #1 and it works perfectly for me.

 

EDIT 2: It looks like a release of OCAT had a bug where LoadEarly was being configured at TRUE when the user specified FALSE (or something like that).  This is exactly the kind of configurator issue that I don't want to spend time debugging.  Again, just my preference.  Don't get me wrong - XCode has its issues, too.  

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

@Jazzoo One thing I forgot to mention ... the 0C 0.8.3 EFI that you posted does not include the _PTS fix that I described here (the fix now included in the EFI I attached to Post #1).  This fix was required to enable working sleep/wake for systems booting from SATA SSD (not required for systems booting from NVMe SSD).  Your system which boots from a USB-attached SSD is sleeping / waking properly without the _PTS fix?

Link to comment
Share on other sites

@deeveedee

Yes, LoadEarly has to be True only in 2 drivers, OpenVariableRuntimeDxe.efi (always) and OpenRuntime.efi (only when accompanies to OpenVariableRuntimeDxe.efi).

All other scenarios must have loadEarly False.

You're right, @Jazzoo must have all LoadEarly as False.

 

Also, you say "for rigs that don't have proper NVRAM support". 

So far, old machines with Legacy BIOS (Legacy BIOS machines do not have UEFI compatible NVRAM) can install OpenDuet from the Utilities/LegacyBoot folder of OpenCore. Duet incorporates the ability to emulate NVRAM. Duet behaves as a compatibility layer, prior to OpenCore, to have the feature of emulated NVRAM with OpenCore.
Emulated NVRAM was not available at all unless on a legacy BIOS machine, prior to this release. This new OpenVariableRuntimeDxe driver integrates the Duet feature within OpenCore.

It not only brings the emulated NVRAM adding improvements but also, and this is an important difference, brings the possibility of having emulated NVRAM on UEFI machines with broken or incompatible native NVRAM.
I guess this will be useful in a small number of cases but the OC developers have thought it convenient to add this option.

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

@deeveedee - I actually boot from external HDD. It's an old 500GB WD Blue 2.5 drive that I use only for test. Sleep/Wake works great despite my expectation that this will be the only thing that doesn't work :)

 

I am still freaking amazed how well this mini pc works! There's no performance comparison with any other genuine mac at this price point. I love it! 

Thank you guys for your contribution!

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

×
×
  • Create New...