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

[deeveedee]

Yeah the only thing from my search I have not tried is to disable the audiodxe at boot but I am very dubious that it will do anything. At this point I can only think of a bug in the BT firmware injection...

And no I don't have this problem with my 3 real macs...

Thanks for looking though

Did it work in Catalina?

Have you tried without using any Acidanthera BrcmPatchRAM Kexts? If your card is not detected without the kexts, have you tried enabling only the BrcmBluetoothInjector.kext (just injects the device) without updating the firmware (disabling BrcmPatchRAM3.kext and BrcmFirmwareData.kext)? My thinking is that if it is the firmware update, try not updating the firmware.

 

[rafale77]

No it did not work on Catalina.

The wifi portion of the card is natively supported by MacOS and I don't need any Kext or patch for it to work. However it works only on 2 streams. Getting all 3 wifi streams requires the airportbrcmfixup kext and changing the region to #a. Wifi works flawlessly besides this 2 vs 3 streams.
I am using the brcmPatchRam to get bluetooth working since it appears that the firmware doesn't get injected otherwise. I will try your suggestion to see if it works but I have already tried something like this and BT just won't work if I remember correctly.

Also noticed that Big Sur has a new boot chime and OC right now still plays the old one... one more thing to optimize...

Edit: And you were right. The device injection was sufficient without the BT firmware uploader. MacOS apparently was able to upload the firmware on its own. The unlock problem remains though... It works as long as the watch is connected but fails to reconnects or unlock once it gets disconnected.

 

[dolphin19303]

This is a place-holder for installing / running Big Sur on the HP EliteDesk 800 G4/G4 Mini PC. This thread is derived from the original Catalina Guide and will gradually replace the Catalina guide.

Getting help with your hack
Before you ask for help, do your homework by reading ALL Known Issues here. If you want assistance with your hack or you have an issue that needs to be resolved, please post your question in this thread with your problem reporting files. If using OC, post your sanitized EFI (remove MLB, SystemSerialNumber, SystemUUID). If using CLOVER, use @black.dragon74 's problem reporting tool here. If macOS's Read-Only protections block your installation of black.dragon74's gen_debug script, please copy the gen_debug script attached here to your Desktop, change script properties with the terminal command 'chmod a+x ~/Desktop/gen_debug' and run the script from your Desktop.

See BIOS configuration here

Draft OC 0.6.3 EFI Attached

Big Sur install screen shots here

Big Sur GeekBench 5 CPU Benchmark here

I already did a fresh install successfully with EFI in #1. Many thanks for @deeveedee to keep this brand on fire

 

[deeveedee]

Edit: And you were right. The device injection was sufficient without the BT firmware uploader. MacOS apparently was able to upload the firmware on its own. The unlock problem remains though... It works as long as the watch is connected but fails to reconnects or unlock once it gets disconnected.

In macOS, I don't think that the Bluetooth firmware is updated at all without BrcmPatchRAM3. I think that the MacOS firmware update model is different from the Windows firmware update model (BrcmPatchRAM3 emulates the Windows firmware update), so your Bluetooth firmware is not updated on macOS boot and wake without BrcmPatchRAM3. If the Bluetooth behavior is the same with and without BrcmPatchRAM3 / BrcmFirmwareData, it may mean that your firmware is not getting updated with BrcmPatchRAM3. Have you confirmed that BrcmPatchRAM3 is actually updating your Bluetooth firmware?

 

[rafale77]

In macOS, I don't think that the Bluetooth firmware is updated at all without BrcmPatchRAM3. I think that the MacOS firmware update model is different from the Windows firmware update model (BrcmPatchRAM3 emulates the Windows firmware update), so your Bluetooth firmware is not updated on macOS boot and wake without BrcmPatchRAM3. If the Bluetooth behavior is the same with and without BrcmPatchRAM3 / BrcmFirmwareData, it may mean that your firmware is not getting updated with BrcmPatchRAM3. Have you confirmed that BrcmPatchRAM3 is actually updating your Bluetooth firmware?

Honestly... this crossed my mind because indeed I am seeing exactly the same firmware version with and without the the brcmpatchram3 injection. How would I verify this and how would I make sure that it does.

 

[deeveedee]

Honestly... this crossed my mind because indeed I am seeing exactly the same firmware version with and without the the brcmpatchram3 injection. How would I verify this and how would I make sure that it does.

Read this. Rehabman's repo may have additional info.

EDIT: @rafale77 I worked extensively with the Bluetooth kexts to get Bluetooth working on my Dell Latitude E6410 laptop (still running Catalina). Firmware updating was a problem, because I found that BrcmPatchRAM3.kext injection wasn't being handled properly by CLOVER. I ended up "fixing" the firmware update problem by injecting BrcmPatchRAM3 / BrcmFirmwareData with CLOVER and installing BrcmBluetoothInjector in /Library/Extensions (where it was cached by macOS).

During my testing, I stumbled upon a very odd interaction between AppleALC.kext and the Brcm kexts. I ended up needing to use VoodooHDA instead (because it installed AppleHDADisabler.kext).

Here are a few things to try (in this order - stop when you have success):

• Confirm that your Bluetooth card model is in the BrcmPatchRAM3 plist.
• Do you see any different Bluetooth behavior (including firmware update) if you disable AppleALC.kext and install AppleHDADisabler.kext?
• Does your Bluetooth firmware update if you disable BrcmBluetoothInjector (retaining BrcmPatchRAM3 / BrcmFirmwareData)?
• If you switch to CLOVER r5122 (use the EFI attached here) and Catalina, does your Bluetooth Firmware update if your 3rd-party kexts are in /E/C/k/O?
• If you switch to CLOVER r5122 (use the EFI attached here) and Catalina, does your Bluetooth Firmware update if you install BrcmPatchRAM3 / BrcmFirmwareData in /E/C/k/O, set CLOVER Inject Kexts = YES and install the rest of your 3rd-party kexts in /Library/Extensions?

 

[kapiza]

Great! Glad that worked for you. Be sure to create your own USB port mapping, so that you can disable XhciPortLimit.

@kapiza I spoke too soon and didn't see that you edited your previous post. Sorry that didn't work. I haven't patched your model PC and don't know the differences enough to suggest patches. Have you tried to install Catalina first?

Yes, my graphics Device Properties are set for DP->DVI.

Thanks for your suggestions anyway! I will give Catalina a try then…

 

[rafale77]

Read this. Rehabman's repo may have additional info.

Thanks for all the help. Here are the quick answers I already know:

• Confirm that your Bluetooth card model is in the BrcmPatchRAM3 plist.

It is a well supported card and it is there. The firmware version it uploads is also identical to the firmware version macOS is reporting with or without the brcmpatchram3 loaded: device 0A5c-6410, firmware version 4518. I even looked at the individual firmware injectors in the repo and they point to the exact same version.

• Do you see any different Bluetooth behavior (including firmware update) if you disable AppleALC.kext and install AppleHDADisabler.kext? This will be my next test... Will report back when I try.
• Does your Bluetooth firmware update if you disable BrcmBluetoothInjector (retaining BrcmPatchRAM3 / BrcmFirmwareData)? No, this would fail and BT would stop working. I mistakenly did this at one point.

Edit:

Still not fixed but some interesting observations:

I can confirm that the BrcmBluetoothInhector is a must have. Without it BT just doesn't work.
With or without BrcmPatchRam3, BT works but Hackingtool shows "FW Loaded" with the patch ram with the name of the device as you can see on my screenshot. Without BrcmPatchRam3, Hackintool shows the BT chipset instead ("Broadcom 20703") and "FW Loaded" is unchecked.

I see absolutely no difference in behavior one way or another and the Apple System Info screen shows exactly the same thing in the BT section. It doesn't appear that the brcmpatchram and firmware loading is necessary for this device and that macos can handle it on its own but either way, the watch unlock behaves the same way.

I have also tested disabling the audio kext and it made no difference.

 

[rafale77]

I am starting to think that I was barking at the wrong tree with chasing the bluetooth implementation, mostly because everything else about it works. I tested various delays but they are mostly related to waking from sleep. I started looking into my icloud account, fixed the ROM and made my hack more "kosher" but still no luck. I looked at the NVRAM content, wiped it out and am seeing an EFIBluetoothDelay entry I am not seeing on my real macs.
I see that it is also missing a bluetoothInternalControllerInfo entry which is in the real mac and not in the hack. It is a legacyschema entry in the config.plist which does not show up in the nvram. Really not sure what these are.

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

 

[deeveedee]

EDIT: Use @rafale77 's improved USBPorts.kext here. Remove SSDT-USBX.aml if you still have it in your ACPI folder.
---------------------------------------
I found two mistakes in the USBPorts.kext that I generated with Hackintool:

• HS14 was configured as an external USB3 port (USBConnector 3) when it should have been Internal (USBConnector 255)
• kUSBSleep and Wake Power properties were not set for MacMini8,1 (they were Hackintool defaults, I think)

My other mistake was that I had SSDT-USBX.aml and USBPorts.kext in my EFI. SSDT-USBX.aml is no longer necessary with USBPorts.kext.

I will be updating my EFI as follows:

• Remove SSDT-USBX.aml from ACPI (and remove from OC config.plist)
• Replace USBPorts.kext with the attached updated version (Internal HS14, USB Power properties from MacMini8,1)