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

[deeveedee]

For good measures this is my USBPorts.kext which I remapped with the corrected port connectors.

Nice! I see you changed the Type C ports.

@rafale77 I'm new to Type C. How did you know which Type C to choose ('Type C' or 'Type C + Sw')?

 

[rafale77]

type 9 and 10 difference is whether the port reports USB2 and USB3 as the same logical port.
The ones with switch 'Type C + Sw' report the same port. If they report a different logical port then they are only 'Type C'. The way to test it is to flip the connector of the USB C port. My test showed that the USB C SS3 popped up as HS10 when flipped... so they are 'Type C' (type 10) both representing the same physical port.

 

[rafale77]

After some testing on my real Mac I think I am inching closer to the problem. It appears to indeed be a BT problem. On the real mac, every time there is a watch unlock event, I see that the mac creates a BT connection with the watch if there isn't one. The hack fails to do this even though it seems like it tries. It could be that the hack tries to send the command down the wrong serial pipeline. I just experienced a strange event of BT connection-disconnection back and forth whereby whenever the connection was established, I was able to unlock. People fixing the problem by disabling the serial port seem to indicate that macos looks first for an uart which is how BT is connected in most real macs. At this point I just don't know why it is able to set the connection when we check the unlock setting and not subsequently once it disconnects.

Added my commented USBPorts file with @deeveedee's fixes.

 

[deeveedee]

A revised EFI for OC 0.6.3 is now attached to Post #1. This revised EFI includes a revised USBPorts.kext and removes SSDT-USBX.aml as discussed here, here and here. If you modify your own config.plist, don't forget to disable or remove ACPI/SSDT-USBX.aml in your config.plist.

*** NOTE ***
If you run USBMap.command after removing SSDT-USBX.aml (leaving USBPorts.kext), USBMap will report that you're missing USBX:

This is a false alarm, because IORegistryExplorer shows that USB Power Properties are loaded:

 

[deeveedee]

In the meantime, I disabled SIP by using the proper value for Big Sur according to this.

Why are you disabling SIP?

@rafale77 I assume you saw the "Fixing Auto Unlock" link on the Dortania page where you noted the SIP settings?

 

[rafale77]

Why are you disabling SIP?

@rafale77 I assume you saw the "Fixing Auto Unlock" link on the Dortania page where you noted the SIP settings?

On SIP, it looked like it was disabled to begin with. I just changed the code to upgrade to Big Sur. I am thinking about enabling it.

Yes I saw that link as well from the Dortania page and it isn't exactly the same problem. For them it was an authentication/cloud issue. I tried following every step of it 3 times... no luck. My case is a little different: It doesn't appear to be an authentication issue. The hack knows whether the watch is around or not. It is the BT connection status which seems to be out of sync between services and I don't know what is causing it. The most frequent report of fix for this issue from my research has been either removing a dGPU which I don't have and disabling the serial port. All these seem to indicate that it is an internal IO addressing issue. I even just tried changing the profile to iMac19,1 just now and the behavior is identical.

 

[deeveedee]

On SIP, it looked like it was disabled to begin with. I just changed the code to upgrade to Big Sur. I am thinking about enabling it.

My intention was to have SIP fully enabled. Correct me if I misundertood, but this is what I had intended:

I though that the default csr-active-config in the OC config.plist is "00000000 - SIP completely enabled (0x0)" according to this.

I believe that SIP is currently fully enabled in the OC config.plist attached to Post #1 of this Big Sur thread. SIP is disabled in the CLOVER config.plist attached here.

Is there something that I misundertood about csr-active-config? If so, please provide the correction for the config.plist attached to Post #1. Thanks!

 

[rafale77]

No you are correct. I think the confusion is from my hybridisation of the configuration. I started from another baseline and have been integrating various pieces of your EFI.

 

[rafale77]

Quick update on my installation. Only leftover issue is watch unlock and the related auto hotspot with the Dell DW1830 which after much console log reading is getting me nowhere. There seems to be a problem with bluetooth connection with apple mobile devices (My apple trackpad works). The bluetoothd service behaves differently than on a real mac and I have not gotten to the bottom of it.

 

[deeveedee]

For those who are interested in learning more about how to create custom SSDTs to patch your System ACPI, you may be looking at the SSDTs I included in the OC EFI attached to Post #1 and you're wondering why they're different from the Dortania pre-built SSDTs and why they are sometimes different from other OC SSDT ACPI patches.

• Dortania SSDTs are created to support multiple motherboards which have different ACPI Device names ( e.g. the HP EliteDesk 800 G4 Mini DSDT uses Device (PRxx) to reference CPUs while other motherboard DSDTs may use Device (CPUx) or Device (CPxx) ). Inspection of the extracted HP EliteDesk 800 G4 ACPI (including DSDT.aml and other extracted SSDTs) reveals that the G4 Mini ACPI refers to the CPUs as Device (PRxx) in Scope _SB_. No other CPU device references / scopes are needed in the SSDT-PLUG for the G4 Mini (which is why I have removed them). Since my SSDTs are specific to the EliteDesk 800 G4 Mini, they may not work in other systems. To properly patch a different system's ACPI, you should extract and inspect the System ACPI to determine the necessary patches.
• Some posted ACPI patches include definition of Method (DTGP). This is a method found in the ACPI of real Macs. Unless your ACPI Method (_DSM) patches use Method (DTGP), defining this method is unnecessary. My _DSM patches do not use DTGP and thus my SSDTs do not require definition of DTGP. You'll find other posted ACPI patches that define Method (DTGP) but never use it. This isn't "wrong" - it's just unnecessary.
• Some posted ACPI patches have an extensive list of unnecessary "External" declarations, including External declarations of the very devices / objects that they define. External declarations of objects are only necessary when you need to tell the iASL compiler that undefined objects are defined elsewhere in the System ACPI. If the object is being defined for the first time in an SSDT, specifying an External declaration of this object in the SSDT is incorrect. For example, the declaration of "External (MCHC, DeviceObj) in the very SSDT that defines Device (MCHC) is incorrect (MCHC is not defined anywhere else in the System ACPI). For this reason, the External declarations in the SSDTs in the OC EFI attached to Post #1 are minimal.
• Why do some SSDTs included code that is conditional on _OSI("Darwin") and some do not? _OSI("Darwin") is an ACPI call that returns TRUE when a system is running macOS. If you are multi-booting macOS and any other OS and your boot loader injects your patched ACPI for every booted OS, then your ACPI patches should include _OSI("Darwin") conditions so that your macOS-specific patches are only injected when running macOS. I dual-boot macOS and Windows, but I press F9 at startup on the rare instances when I want to boot Windows, so OC boot loader does not inject my ACPI patches when I run Windows. If you are using OC to boot macOS and other OSes, you will need to inspect and in some cases modify my posted ACPI patches (custom SSDTs) to make sure that every macOS-specific ACPI patch is conditional on _OSI("Darwin").

If you actually took the time to read this post, then you might be interested in testing your new knowledge. Find the unnecessary External declaration in my SSDTs posted in the OC EFI attached to Post #1. If you find the mistake, give this post a Thumbs Up.