Contribute
Register

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

Status
Not open for further replies.
Dear @deeveedee !
I have a issue! When i charging any Iphone in any usb port then i got a notify "Unplug the accessory using too much power to re-enable usb devices".

 

Attachments

  • Screen Shot 2021-04-29 at 00.18.58.png
    Screen Shot 2021-04-29 at 00.18.58.png
    38.9 KB · Views: 51
Last edited:
Just upgraded to Big Sur 11.3 using the OC 0.6.8 EFI r004 (attached to Post #1). No issues. Upgrade was flawless. The key to this upgrade seems to be that Kernel > Quirks > XhciPortLimit = False in the OC config.plist and you have a properly constructed USBPorts.kext with no more than 15 logical USB ports.

Screen Shot 2021-04-28 at 1.36.59 PM.png
 
This is my last note about USB power.
Thanks you but it not solved :(
I am thinking the case could be caused by a weak power supply adapter.

edit 1: type C port is ok ! not have that issue
 
Last edited:
I just experienced an error when attempting to run Disk Utility "First Aid" on my entire SSD. The error message indicated that disk repair could not proceed, because there was something wrong with my EFI Volume. It's likely that I introduced this EFI error when making EFI changes and improperly shutting down - not sure. Anyway, to resolve this, I did the following in Terminal:
  1. run "diskutil list" to find the EFI Volume identifier (disk0s1 in my case)
  2. run "sudo diskutil mount <EFI Volume Identifier>" (replace <EFI Volume Identifier> with what you found in Step 1 (disk0s1 in my case)
  3. run "sudo diskutil repairVolume <EFI Volume Identifer>" (replace <EFI Volume Identifier> with what you found in Step 1 (disk0s1 in my case)
After manually repairing my EFI Volume, Disk Utility First Aid runs without issues on my full disk.
 
I just experienced an error when attempting to run Disk Utility "First Aid" on my entire SSD. The error message indicated that disk repair could not proceed, because there was something wrong with my EFI Volume. It's likely that I introduced this EFI error when making EFI changes and improperly shutting down - not sure. Anyway, to resolve this, I did the following in Terminal:
  1. run "diskutil list" to find the EFI Volume identifier (disk0s1 in my case)
  2. run "sudo diskutil mount <EFI Volume Identifier>" (replace <EFI Volume Identifier> with what you found in Step 1 (disk0s1 in my case)
  3. run "sudo diskutil repairVolume <EFI Volume Identifer>" (replace <EFI Volume Identifier> with what you found in Step 1 (disk0s1 in my case)
After manually repairing my EFI Volume, Disk Utility First Aid runs without issues on my full disk.
or you could:
boot recovery and in terminal:
diskutil repairDisk disk0
 
Upgrade was smooth as butter... Took only about 20 minutes.

Screen Shot 2021-04-28 at 13.57.38.png
 
Thanks you but it not solved :(
I am thinking the case could be caused by a weak power supply adapter.

edit 1: type C port is ok ! not have that issue
According to the specs on the HP EliteDesk 800 G4 Mini USB Ports, the front-right USB port is USB 3.1 Gen 1 with 1.5A current limit). The Type C port is USB 3.1 Gen 2 with 3A current limit. This is consistent with your observations. Looks like we should be using the Type C port for our "high current" devices.
 
Now that I have completed 5 hacks since I switched from CLOVER to OC, my philosophy about Device EC is changing. I found on my most recent hack (a Kaby Lake R laptop), that it was easiest to add a Fake EC rather than rename the existing EC0 -> EC. This is because my SSDT hotpatches for brightness keys and ACPI debugging needed to be applied to the original EC0. It wasn't hard to apply the hot-patches with an EC0->EC rename - just a little easier to apply without the rename. Also, according to @1Revenger1 , conditionally injecting a Fake EC (using condition _OSI("Darwin"), won't cause problems if you are dual-booting macOS and Windows with OC.

To make a long story short, I think it will be better to inject a Fake EC rather than rename the original EC in most cases and I am currently running this HackMini with the attached Fake EC. I don't notice any difference with the Fake EC and the renamed EC on this HackMini8,1, but for me, this is just a way to standardize my own hacks on a single methodology. If I continue to run this way with no problems, my next posted EFI will inject a Fake EC rather than rename EC0->EC.

There are a couple of things about the way I apply the Fake EC that may be different from what you've read:
  1. My EC scope is \_SB.PCI0.LPCB and not \_SB. I chose this scope because it's the scope in a real MacMini8,1 and I didn't notice any difference when I changed the scope to \_SB.
  2. Even though this HackMini is a "Desktop" PC, I don't disable the original EC0 device. My IORegistry has both the original Device EC0 and the Fake EC

If you want to test this Fake EC on your own rig, you will need to copy the attached SSDT-EC.aml to your EFI/OC/ACPI folder and make the following changes to your config.plist:
  1. disable the EC0->EC ACPI Patch (so the original EC0 is not renamed)
  2. Add a new "ACPI Add" rule to inject SSDT-EC
You can confirm that you've switched to the Fake EC by checking with IORegistryExplorer. You will see the new Fake EC and the original EC0. Note that AppleACPIEC is attached to the original EC0, because of the "PNP0C09" IONameMatch.

Screen Shot 2021-05-03 at 11.11.15 AM.png
 

Attachments

  • SSDT-EC.aml.zip
    638 bytes · Views: 53
Last edited:
I looked at the changes in Open Core 0.6.9 and don't see anything that motivates me to update (yet). Going to allow the dust to settle and watch other comments to learn a little before updating from 0.6.8 to 0.6.9. If anyone tries the update on their own, please share your lessons learned. NVMeFix.kext v1.0.7 has a new -nvmefaspm boot argument to force ASPM L1 on all NVMe SSDs. Read here for background. This sounds interesting.
 
Status
Not open for further replies.
Back
Top