HP EliteDesk 800 G4 / G5 Mini with RX560x dGPU (hackintosh)

[deeveedee]

@robi39 Please post your EFI with requests for help.

 

EDIT: @robi39 I downloaded the OC 1.0.3 EFI attached to Post #1, added my private Platform Info and rebooted with the EFI on a USB thumb drive.  All good.

Edited December 6, 2024 by deeveedee

[ird]

12 hours ago, robi39 said:

I just booted 15.1.1 fresh install with the EFI in the 1st post and my ethernet is not recognized everything else is working though HP elitedesk 800 G4 with the RX560X, not sure what could be wrong, ethernet is recognized and working in Windows 11, didn't change anything in the EFI, I had a USB ethernet and that. is working fine, BIOS is setup as yours in that pdf.

 

This?

 

 

[deeveedee]

@ird I didn't interpret @robi39 's "Ethernet not recognized" in that way, but maybe that's what they were referring to.  Thank you.

[robi39]

10 hours ago, deeveedee said:

@ird I didn't interpret @robi39 's "Ethernet not recognized" in that way, but maybe that's what they were referring to.  Thank you.

EFI is same as the first post, @ird unfortunately is not that issue, I don't see the ethernet at all, so it is not a connection issue.

EFI-MM81-RX560x-OC103-01.zip

[deeveedee]

@robi39 Yes - that is the identical EFI that I posted.  If that is indeed the EFI that you used (extracted from your own SSD, but modified to eliminate the Platform Info) and you have followed the directions in Post #1 while paying attention to the Known Issues , then I don't know why you'd be having the Ethernet issue that you described.

 

I haven't ever seen this behavior (even when I was first experimenting to find a working solution), so I'll make the following suggestions (guesses) and look forward to your report when you figure it out:

• Make sure that Ethernet is enabled in BIOS
• Make sure you have an HP EliteDesk 800 G4 Mini or HP EliteDesk 800 G5 Mini
• Reset NVRAM (use Open Core boot menu entry) before booting 15.1.1
• If you upgraded 15.1.1 from another version, try booting with my EFI (modifying it to include your Platform Info) and perform a new installation of Sequoia 15.1.1 to a clean APFS volume

 

EDIT: One other thing to try: in terminal, run 'kextstat | grep -i mausi' (without quotes).  What is the result?  Is IntelMausi.kext loaded?

Edited December 12, 2024 by deeveedee

[deeveedee]

I see a change that I inadvertently made to the OC 1.0.3 EFI that I attached to Post #1.  OC/Kexts/USBPorts.kext includes port HS14 for Bluetooth.  It's not enough of a change for me to post a new EFI, so if you want to revert to the USBPorts.kext that I was originally including (without Bluetooth port HS14), edit my posted EFI-MM81-RX560x-OC103-01 EFI as follows:

1. Delete OC/Kexts/USBPorts.kext
2. Copy OC/Kexts/SampleUsbKexts/USBPorts-noHS14.kext to OC/Kexts and rename OC/Kexts/USBPorts-noHS14.kext to OC/Kexts/USBPorts.kext

[robi39]

On 12/7/2024 at 4:44 AM, deeveedee said:

@robi39 Yes - that is the identical EFI that I posted.  If that is indeed the EFI that you used (extracted from your own SSD, but modified to eliminate the Platform Info) and you have followed the directions in Post #1 while paying attention to the Known Issues , then I don't know why you'd be having the Ethernet issue that you described.

 

I haven't ever seen this behavior (even when I was first experimenting to find a working solution), so I'll make the following suggestions (guesses) and look forward to your report when you figure it out:

• Make sure that Ethernet is enabled in BIOS
• Make sure you have an HP EliteDesk 800 G4 Mini or HP EliteDesk 800 G5 Mini
• Reset NVRAM (use Open Core boot menu entry) before booting 15.1.1
• If you upgraded 15.1.1 from another version, try booting with my EFI (modifying it to include your Platform Info) and perform a new installation of Sequoia 15.1.1 to a clean APFS volume

 

EDIT: One other thing to try: in terminal, run 'kextstat -a | grep -i mausi' (without quotes).  What is the result?  Is IntelMausi.kext loaded?

Yes, all of those suggestions were made, this was a clean install 15.1.1 not an upgrade, but I have another 800 G4 and that doesn't have that issue, so I'm not sure what it was, very weird thought that it works in Windows no problem though, but it must be some kind of weird hardware issue that only shows up in macos.

 

Thanks for all your help though, you can mark this issue solved.

[deeveedee]

@robi39 The fact that it works in Windows but not macOS is interesting. Will happily let this issue rest, but if you're curious and want to explore further, use ioreg explorer to compare how Ethernet is detected by macOS on the working and non-working units. That might give a clue.

[deeveedee]

Now that this hack is able to accommodate SATA drives with the mod documented here, I am going to enable Kernel > Quirks > ThirdPartyDrives in the Open Core config.plist.  This quirk does not affect NVMe SSDs and if your hack doesn't have a SATA drive, this quirk won't matter.  Future posted EFIs will enable this ThirdPartyDrives quirk.

Edited December 15, 2024 by deeveedee

[deeveedee]

Smooth upgrade to Sequoia 15.3 Beta.  The upgrade from Sequoia 15.2 ->  15.3 Beta (24D5034f) has resolved the Ethernet issue.  With this 15.3 Beta, I no longer need to toggle Ethernet to allow remote connections from MS Remote Desktop and VNC Viewer.  Apple has "fixed" this in previous Sequoia Betas, so it remains to be seen whether this is permanently fixed in Sequoia.

[deeveedee]

For anyone following the RX 560x conversation here, I have tested SMBIOS model iMacPro1,1 on our HP EliteDesk 800 G4 Mini with RX 560x and it still requires WhateverGreen.kext / CFG,CFG_FB_LIMIT=X property to fix the RX 560x blackscreen.

 

Without having more details, I suspect that NootedRed.kext (WhateverGreen modified to support AMD iGPU) is able to fix the RX 560x black screen and does not have the automatic CFG_FB_LIMIT problem that exists in WhateverGreen.kext.  One way to test this theory would be to install NootedRed.kext on our Intel-based hack to see if it fixes the RX 560x black screen.

 

EDIT: This Intel-based hack does not boot when injecting NootedRed.kext, so I'm not sure how to test my theory.  If someone knows about NootedRed.kext and can confirm/deny that the NootedRed kext includes WhateverGreen's Radeon dGPU black screen fixes, your comments are welcome.

Edited December 20, 2024 by deeveedee

[ird]

9 hours ago, deeveedee said:

For anyone following the RX 560x conversation here, I have tested SMBIOS model iMacPro1,1 on our HP EliteDesk 800 G4 Mini with RX 560x and it still requires WhateverGreen.kext / CFG,CFG_FB_LIMIT=X property to fix the RX 560x blackscreen.

 

Without having more details, I suspect that NootedRed.kext (WhateverGreen modified to support AMD iGPU) is able to fix the RX 560x black screen and does not have the automatic CFG_FB_LIMIT problem that exists in WhateverGreen.kext.  One way to test this theory would be to install NootedRed.kext on our Intel-based hack to see if it fixes the RX 560x black screen.

 

EDIT: This Intel-based hack does not boot when injecting NootedRed.kext, so I'm not sure how to test my theory.  If someone knows about NootedRed.kext and can confirm/deny that the NootedRed kext includes WhateverGreen's Radeon dGPU black screen fixes, your comments are welcome.

 

AFAIK NootedRed is only for Vega based iGPUs (Gen9). RX560 is previous generation (Gen8 Polaris). I doubt NootedRed can automatically do the same for Polaris. Source code also restricts it to Vega iGPUs: https://github.com/ChefKissInc/NootedRed/blob/master/NootedRed/Model.cpp

 

Now it is possible though that it may have the logic to solve the black screen (if he problem is shared between Gen8 and Gen9 AMD GPUs) but if that's true, we'd have to find it, extract it and port it over to WEG for other dGPUs.

Edited December 21, 2024 by ird

[deeveedee]

@ird I think I didn't explain very well.  My suspicion is that, since NootedRed is apparently derived from WhateverGreen, NootedRed has the WEG code to fix the Radeon black screen (nothing to port over to WEG).  I was wondering if someone knowledgeable about NootedRed could confirm that it does have this WEG code.  It would also be nice to know what WEG (and possibly NootedRed) are doing to fix the Radeon black screen.

 

EDIT: Grepping WEG source for 'black screen' reveals Radeon black screen fixes in kern_rad.cpp like this, so if someone understands what kern_rad.cpp is doing, maybe we can understand what WEG is doing to fix this RX 560x black screen.  Then maybe it's possible to see if this same code is in NootedRed.kext.

        // Fix boot and wake to black screen
        for (size_t j = 0; j < MaxGetFrameBufferProcs && getFrame[j] != nullptr; j++) {
                auto getFB = patcher.solveSymbol(hardware.loadIndex, getFrame[j], address, size);
                if (getFB) {
                        // Initially it was discovered that the only problematic register is PRIMARY_SURFACE_ADDRESS_HIGH (0x1A07).
                        // This register must be nulled to solve most of the issues.
                        // Depending on the amount of connected screens PRIMARY_SURFACE_ADDRESS (0x1A04) may not be null.
                        // However, as of AMD Vega drivers in 10.13 DP1 both of these registers are now ignored.
                        // Furthermore, there are no (extra) issues from just returning 0 in framebuffer base address.
                        
                        // xor rax, rax
                        // ret
                        uint8_t ret[] {0x48, 0x31, 0xC0, 0xC3};
                        patcher.routeBlock(getFB, ret, sizeof(ret));
                        if (patcher.getError() == KernelPatcher::Error::NoError) {
                                DBGLOG("rad", "patched %s", getFrame[j]);
                        } else {
                                SYSLOG("rad", "failed to patch %s code %d", getFrame[j], patcher.getError());
                                patcher.clearError();
                        }
                } else {
                        SYSLOG("rad", "failed to find %s code %d", getFrame[j], patcher.getError());
                        patcher.clearError(); 
                }
        }

 

Edited December 21, 2024 by deeveedee

[deeveedee]

After review of kern_rad.cpp in WhateverGreen.kext, found this code that is the reason we need to override WEG's auto-handling of CFG_FB_LIMIT for this RX 560x.

void RAD::applyPropertyFixes(IOService *service, uint32_t connectorNum) {
        if (service && getKernelVersion() >= KernelVersion::HighSierra) {
                // Starting with 10.13.2 this is important to fix sleep issues due to enforced 6 screens
                if (!service->getProperty("CFG,CFG_FB_LIMIT")) {
                        DBGLOG("rad", "setting fb limit to %u", connectorNum);
                        service->setProperty("CFG_FB_LIMIT", connectorNum, 32);
                } 

                // In the past we set CFG_USE_AGDC to false, which caused visual glitches and broken multimonitor support.
                // A better workaround is to disable AGDP just like we do globally.
        }
}

For whatever reason, the RX 560x in this EliteDesk 800 G4 Mini does not behave as other Radeon graphics cards that require this CFG_FB_LIMIT change automatically made by WhateverGreen.kext.

 

EDIT: Note that this CFG_FB_LIMIT fix is designed to be overridden, if necessary (as we need to do for this hack).  The fix is applied only if (!service->getProperty("CFG,CFG_FB_LIMIT")).  It does appear that the intended way to override WEG's auto-correction of CFG_FB_LIMIT is to set CFG,CFG_FB_LIMIT.

Edited December 23, 2024 by deeveedee

[ird]

9 hours ago, deeveedee said:

After review of kern_rad.cpp in WhateverGreen.kext, found this code that is the reason we need to override WEG's auto-handling of CFG_FB_LIMIT for this RX 560x.

void RAD::applyPropertyFixes(IOService *service, uint32_t connectorNum) {
        if (service && getKernelVersion() >= KernelVersion::HighSierra) {
                // Starting with 10.13.2 this is important to fix sleep issues due to enforced 6 screens
                if (!service->getProperty("CFG,CFG_FB_LIMIT")) {
                        DBGLOG("rad", "setting fb limit to %u", connectorNum);
                        service->setProperty("CFG_FB_LIMIT", connectorNum, 32);
                } 

                // In the past we set CFG_USE_AGDC to false, which caused visual glitches and broken multimonitor support.
                // A better workaround is to disable AGDP just like we do globally.
        }
}

For whatever reason, the RX 560x in this EliteDesk 800 G4 Mini does not behave as other Radeon graphics cards that require this CFG_FB_LIMIT change automatically made by WhateverGreen.kext.

 

Thank you for explaining, @deeveedee. Now it's clear what you are were saying. I haven't looked at WEG code myself but where is this function called? RX560X to my knowledge is not the same as the regular RX560 desktop version (I used to have a regular RX560 in another machine and WEG never had any issues nor did I have any black screen issues). It is possible for HP's RX560X vendor/device/subvendor ID to be missing from WEG's list of radeons to be patched.

[deeveedee]

@ird I'd have to look at the WEG source again to find where applyPropertyFixes is called.  Grepping the WEG source would show, but I'm not at my hack for a while.

[deeveedee]

Smooth upgrade to Sequoia 15.3 Beta (24D5055b).  The Ethernet issue with MS Remote Desktop and VNC Viewer has not returned, so it appears to be fixed.

 

EDIT: After upgrading to Sequoia 15.3 Beta (24D5055b), I experienced a DNS problem with Firefox 134.0.2, where Firefox could not resolve a streaming host URL.  I started/stopped Firefox a few times and cleared Firefox cache without success.  After toggling Ethernet using my previously provided script, Firefox was able to resolve the host name.  I can't be certain that this is a macOS issue, because I have recently increased restrictions on my Firewalla Gold.  I'll keep an eye on this.

Edited January 21, 2025 by deeveedee

[deeveedee]

I have updated my EliteDesk 800 G4 Mini 35W BIOS to version 2.29.01.  See here.

[deeveedee]

Status Update - conversion of 35W -> 65W HP EliteDesk 800 G4 Mini motherboard

 

After a bit of practice, I have mastered the ability to solder the tiny components on this HP EliteDesk 800 G4 Mini 35W motherboard.  I'm using a heatgun (hot air) under a table-mounted magnifying glass so that I can see the components while soldering.  Soldering components this small is a first for me and is extremely challenging.  Some components are so small that I'm using the pointed tip of a straight pin to position the components on the board.

 

I'm still experimenting with configuration changes and I am impressed with the resilience of this board.  I have made mistakes which have only caused a failed boot without damaging the board.  So far, I have added the MOSFET power circuitry on the top-side of the board (needed to provide the additional power phase for the i7-8700) and I have added the logic circuitry on the bottom-side of the board.  I'm desoldering the needed components from another EliteDesk 800 G4 Mini 35W board.  I'm using a 65W board as my reference to determine changes on the 35W board.

 

I am not finished with the necessary changes, but here is what I have achieved/observed so far:

• MOSFET power circuitry added to top-side of board
• Additional power phase logic circuitry added on bottom-side of board
• Modified soldered jumpers to permit booting with the added power phase (35W board does not boot after adding the power circuitry.  must make logical changes on the board).
• After modifications, booted BIOS passed all built-in and remote diagnostic tests without any errors.
• After my board modifications, the BIOS still recognizes the board as a 35W board, so I suspect that I am still missing a component change

With my hardware modifications so far, the board starts to boot Windows 11 and macOS, but the boot is halted with a sudden reboot.  Here is the maOS verbose boot log where the board reboots:

Spoiler

 

Here is the logic section of the underside of the board that determines whether the board boots with the added power phase

Spoiler

 

Edited January 26, 2025 by deeveedee

[deeveedee]

Thank you, eSAF!  

 

HP's support site has HP EliteDesk 800 G4 Mini BIOS version 2.30 available for download.

 

More details here.

 

EDIT: Booted Win11 and performed the BIOS update without issues.

Edited January 29, 2025 by deeveedee

[deeveedee]

After upgrading BIOS on my 35W EliteDesk 800 G4 Mini with i5-8600, I ran GeekBench to test ird's question here.  The GeekBench 6 CPU results are impressive for this little 2018 PC.  

 

GeekBench 6 CPU (EliteDesk 800 G4 Mini 35W, BIOS: 2.30, CPU: i5-8600 65WTDP, 230W Power Supply)

Spoiler

 

Edited January 31, 2025 by deeveedee

[deeveedee]

This solution is for MS Windows, not macOS

 

A recent Windows 11 update breaks Synaptics audio resulting in no sound output in Windows 11.  A solution is to uninstall "Synaptics HD Audio" from Device Manager and reboot Windows.  After reboot, sound will be restored.

 

 

EDIT: If uninstalling "Synaptics HD Audio" and rebooting does not fix sound, uninstall all AMD, Intel and Synaptics Audio items under "Sound, video and game controllers" and reboot.

 

Edited February 18, 2025 by deeveedee

[deeveedee]

I have updated the Open Core 1.0.3 EFI attached to Post #1 with the following changes that have been discussed previously in this thread:

• OC/config.plist
  • Enabled Kernel > Quirks > ThirdPartyDrives
• OC/Kexts
  • Restored USBPorts.kext to its original version without USBPort HS14.  

 

Note that with this updated EFI, working Bluetooth requires a modified USBPorts.kext that includes USB port HS14.  For those who want working Bluetooth while complying with the 15-port USB Port Count limit, edit the sample kext USBPorts-16.kext in OC/Kexts/SampleUsbKexts to remove an unused port while keeping port HS14.

[deeveedee]

Quick update: I now have a bootable EliteDesk 800 G4 Mini motherboard with both the dGPU PCIe port and the additional CPU power phase circuitry (for powering the i7-8700).  The board passes all tests and boots the OS, but it does not detect/recognize the RX 560x. 

 

I found additional minor circuitry differences between the 35W and 65W boards, so I have not yet exhaused my options to get a working 65W motherboard with RX 560x.  My goal is still to have an EliteDesk 800 G4 Mini with an RX 560x dGPU and an i7-8700 CPU.

 

EDIT: I'm only doing this because it's risky and I'm bored   For those with less of a risk appetite, the 35W motherboard with the i5-8600 and 230W power supply performs admirably.

 

Edited February 18, 2025 by deeveedee

[deeveedee]

It looks like Devs are getting ready to release a new version of SMCRadeonSensors.kext 2.4.0.  You can see a preview here (must log into github to download).

 

EDIT: I am going to be removing SMCRadeonSensors.kext from a future version of my posted EFI.  I see that donations are being accepted for kext development, so I'd prefer that users of SMCRadeonSensors.kext get the kext directly from the Devs here.  I'll leave the "Kext > Add" in the OC config.plist (disabled), but I will remove the kext from OC/Kexts folder.

Edited February 26, 2025 by deeveedee