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

[deeveedee]

Leaving this full post for historical purposes, but the answer to the question is in EDIT2 below.

 

I was searching for more info about differences between 35W and 65W HP EliteDesk Mini motherboards and found this discussion.  As my testing demonstrated, the i7-8700 (65W TDP) does NOT run reliably on the 35W board.  My testing has also shown that a 65W board will not work at all without the three MOSFETs and Power Inductor Choke Coil that are missing from the 35W board.

 

I'd like to test a 35W board after adding the missing VRM components, but I don't want to remove them (again) from my one spare 65W board.  Is there anyone with knowledge about discrete components who can provide sourcing information about the VRM parts that are missing from the 35W board (listed below)?  Does the Primary and Secondary identifier of the parts need to be an exact match?

• MOSFET: Manufacturer: Alpha Omega Silicon, Primary Identifier: 6414a,  Secondary identifier: GL9B4B, Quantity: 1
• MOSFET: Manufacturer: Alpha Omega Silicon, Primary Identifier: 6794, Secondary Identifier: GV9G1T, Quantity: 2
• R22 0.22UH/R22 SMT Power Inductor Choke Coil, Quantity: 1

I have found similar parts on AliExpress and other sites, but the MOSFETs have a secondary identifier that I listed above and I don't know if I need to match the secondary identifier.  For example, I have found MOSFETs manufactured by Alpha Omega Silicon with Primary Identifier 6414a, but not with the secondary identifier GL9B4B.  I don't know if I need to find exact primary and secondary identifier matches when ordering the parts, or if it is sufficient to match only the primary identifier.

 

Thanks in advance for any help.  If I can order the missing parts, I'll solder them to a 35W board and test again with an i7-8700.

 

EDIT: Photos of actual components

 

R22

Spoiler

 

6414a

Spoiler

 

6794

Spoiler

 

 

EDIT2: According to this, the second number doesn't matter.

Edited May 26 by deeveedee

[deeveedee]

I have ordered the discrete VRM components from vendors on AliExpress.  They're going to take some time to arrive.  I'll report back again when I have soldered the components onto the 35W motherboard and re-tested the i7-8700.  My desired outcome is that the additional components allow the 35W motherboard to provide sufficient power to the i7-8700 during benchmarks (a test that previously failed).  I can't believe that I'm the first to try this crazy stunt, so if someone has already tried this, please report your findings.

 

Note that I found that the 65W motherboard would not POST after these same discrete VRM components were removed.  I think the worst case scenario is that the 35W board boots fine with the additional components, but does not utilize them.  Keeping my fingers crossed.

Edited June 1 by deeveedee

[deeveedee]

It does appear that naive optimism was all that was required to predict that macOS 15 would support this hack.  Here's a complete list of supposedly supported Macs in macOS 15 (Sequoia).

 

EDIT: Here's the official Apple announcement.

Edited June 10 by deeveedee

[CloverLeaf]

On 5/17/2024 at 10:48 AM, CloverLeaf said:

@deeveedee MacOS 15 will support Intel-based Macs  

 

@deeveedee ... ⬆️  

[deeveedee]

Sequoia Beta installed without issues on this hack using the EFI attached to Post #1 (SMBIOS MM8,1) and the following updates.  All works well.

• AppleALC.kext updated to Acidanthera Beta
• WhateverGreen.kext updated to Acidanthera Beta
• Lilu.kext updated to Acidanthera Beta

With the beta kexts, there is no need for -lilubetaall boot-arg

 

Also, I have received the VRM discreet components and will be soldering them onto the motherboard.  As soon as I have test results with the augmented VRM, I will post my updated status.

 

About This Hack: Sequoia Beta

Spoiler

 

GeekBench 6 Metal Score with Sequoia Beta

Spoiler

 

Edited June 17 by deeveedee

[CloverLeaf]

I see some positive feedback for MacOS Sequoia. @deeveedee Do you feel any difference compared to MacOS Sonoma ?

[deeveedee]

😪 😪😪

After soldering the discrete VRM components onto the 35W EliteDesk 800 G4 Mini motherboard, the board would not POST.  Apparently, my worst-case projection wasn't pessimistic enough.  After soldering the additional VRM components onto the motherboard, I applied power to the bare board.  The board passed the smoke test, so I installed a SODIMM, CPU and the CPU heatsink/fan (the minimum necessary to boot into BIOS.  I saw a single yellow light coming from the underside of the motherboard (probably just an indication of power), but there were no other signs of life.

 

I'm currently posting this on another working system and am hoping that removal of the components restores the 35W motherboard to its previous working condition.  Chalk this experiment up to a failed attempt.

 

Don't try this at home.

 

EDIT: I am impressed with this HP EliteDesk 800 G4 Mini motherboard.  The board seems to selectively test and power up sections of the board to protect components.  The CPU and memory that I installed on the modified 35W board still works perfectly well in another system, so my costs for this experiment (so far) are limited to my time and the minimal investment to purchase the discrete components (about $15 USD).  If the motherboard still works after I remove the VRM components (fingers crossed), and even if it doesn't, I think it was a worthwhile risk.

 

--------------------------------------

 

6 minutes ago, CloverLeaf said:

I see some positive feedback for MacOS Sequoia. @deeveedee Do you feel any difference compared to MacOS Sonoma ?

I haven't tested enough yet, but on this hack, it seems to me that GB6 metal benchmarks for RX560x are lower with the Sequoia Beta (based purely on comparing the numbers).

Edited June 17 by deeveedee

[deeveedee]

I removed the extra discrete VRM components from the 35W board and it is working normally again.  This multi-layer board is VERY hard to solder with my heat gun, so I am suspicious of the MOSFET surface-mount solder joints.  Now that I know the board can survive soldering and de-soldering the components, I am going to try again with the hope of doing a better job of soldering the components. Some of the pads on the MOSFETs are very tiny and may not have had complete soldering.  I'm too stubborn to give up yet.

 

EDIT: I re-soldered the components onto the 35W board, being very careful to make sure all solder joints were complete.  Still no luck.  The 35W board does not POST when the missing VRM components are added.

 

If I get enough courage, my next attempt would be to desolder the PCI connector (for the dGPU) from the 35W board and solder it onto a 65W board.

 

EDIT: For anyone else who is crazy enough to attempt these motherboard mods, the EliteDesk 800 G4 Mini motherboard will run a self-test without any installed components.  Apply power to the board without any CPU, memory, SSD. The board will issue error LED codes via the power LED on the front of the board.  If there are no flashing codes, then the board is "dead."  For example, when I added the discrete VRM components and applied power, there were no flashing LED codes (only a yellow power indicator from somewhere on the board).  Without risking CPU, memory, SSD or other components, the health of the motherboard can be assessed.

Edited June 19 by deeveedee

[CloverLeaf]

You really got deeper into that rabbit hole  

[deeveedee]

On 6/18/2024 at 10:16 AM, CloverLeaf said:

You really got deeper into that rabbit hole  

My happy place.

 

EDIT: I made an initial attempt at desoldering the PCI connector from a working 35W board.  I was not able to apply enough heat to melt the solder without risking damage of the plastic connector.  I'm up for the challenge, but this test is not going to be easy.

Edited June 19 by deeveedee

[deeveedee]

I re-ran GB6 Metal benchmark in Sequoia after allowing the initial macOS installation processes to settle down.  It appears to me that GB6 metal benchmarks in Sequoia are virtually the same as those in Sonoma.  This initial Sequoia Beta is solid.  Maybe because so little has changed for Intel-based Macs.  One apparent improvement that I have noticed is that Xcode 16 Beta loads/launches fast!

 

Revised GB6 Metal Benchmark (Sequoia Beta)

Spoiler

 

About This hack Sequoia Beta

Spoiler

 

EDIT: If someone else can test and report their findings ... I don't think adding the GFX0 Acre frame buffer name / compatible properties makes any difference in Sequoia.

 

EDIT2: I don't think I have performed GB6 CPU benchmarks yet (was using GB5), so I'll record them here to establish a new baseline.

Spoiler

 

EDIT3: For comparison, here's the GB6 CPU benchmark for the HP EliteDesk 800 G5 Mini with i9-9900 CPU.  While performance is fantastic for this little rig, HP has significantly limited PL1/PL2 power limits for the i9-9900 to the point that the G4 Mini with i5-8600 / 230W power supply is not too shabby against the G5 Mini / i9-9900.  The G4 Mini with beefed-up power supply is a better bang for your buck.

Spoiler

 

Edited Sunday at 12:22 AM by deeveedee

[deeveedee]

I have successfully removed the dGPU PCI connector from a 35W board.  The connector is in good shape despite the massive heating.  When I removed the connector, some of the pins remained soldered to the board (pulling out of the connector), because the solder did not melt on some pins that are probably ground or Vcc pins. I needed to heat each of the remaining pins with a soldering iron to remove them from the board one at a time.  I then needed to carefully insert the pins back into the connector.

 

Soldering the connector onto a 65W board is going to require A LOT of patience.  I'm planning to perform the task over multiple sessions.  I have fairly good patience for tedium, but this is pushing me to my limits that I can only take in small doses.

 

EDIT: Removal of the dGPU PCI connector was not easy with a heat gun / rework station.  If anyone has experience with rework on multi-layer, double-sided boards like our EliteDesk 800 Mini motherboard, I am open to your suggestions.  I had to apply high heat for way too long and even that did not fully melt the solder on all of the pins.  In hind sight (too late), I think a better approach may have been to add solder to the connector pin pads (essentially bridging all of the pins with solder), remove the connector and then clean the excess solder from the connector pins.  The extremely tight pin spacing makes any rework extremely difficult for an amateur like me.

 

EDIT2: I accidentally broke one of the connector pins.  They are very brittle (not sure if that's a result of the excessive heating). The broken pin is going to be the end of this experiment until I come up with a fix.  I suspect that some of the pins in the connector are not used (possibly even the broken pin).  If I could figure out the unused pins on this proprietary connector, I could move a pin if necessary.  Examining board traces is not sufficient, since this board has many layers. This challenge just got a lot harder.

Edited Saturday at 11:22 AM by deeveedee

[deeveedee]

Cinebench is a good CPU stress test which confirms that the "65W" i5-8600 works reliably with the unmodified 35W HP EliteDesk 800 G4 Mini motherboard.  Note that Cinebench does not benchmark the dGPU, so it does not benefit from the RX560x.

 

Cinebench R23 Benchmark

Spoiler

 

Intel Power Gadget: captured while running Cinebench

Spoiler

 

Edited Saturday at 12:02 PM by deeveedee

[deeveedee]

I'm looking for a macOS Radeon sensor app that shows temps (and possibly power) for this RX560x.  I tried installing SMCRadeonSensors.kext v2.1.0 from here, but it breaks the behavior of my Sequoia dock auto hide/show (seems to work ok if I disable dock auto hide/show and keep dock always visible).  Maybe I'll have more luck with the next release.  What apps / utilities are others using to monitor Radeon dGPU temps / power in macOS?

 

EDIT: Looks like the Sequoia dock issue might be resolved with SMCRadeonSensors.kext v2.2.0.  Testing now.

 

EDIT2: Now I'm looking for the app that displays the AMD sensor data enabled by SMCRadeonSensors.kext.  iStat Menus did not.

Edited Sunday at 01:02 PM by deeveedee

[deeveedee]

My attempts to move the dGPU PCI connector from a 35W board to a 65W board have failed.  I broke another connector pin.  Fortunately, the 35W board from which I removed the connector still works fine and it doesn't have a dGPU.

 

For those who want to attempt to create a 65W motherboard with the Radeon dGPU, I would recommend that you try to figure out why the 35W board does not POST after installing the additional discrete VRM components.  Someone who has a lot of patience may want to closely compare the two boards under high magnification to see if there is a hard jumper (soldered) that is different on the two boards.

 

EDIT: If anyone know where to purchase the dGPU PCI connector, I would definitely attempt to solder the connector onto the 65W board if it was a new connector that hadn't been removed from a 35W board.

Edited Sunday at 08:05 PM by deeveedee

[miliuco]

7 hours ago, deeveedee said:

What apps / utilities are others using to monitor Radeon dGPU temps / power in macOS?

I use the same app by ChefKissInc. Not tried yet On Sequoia.

Menubar has also this info, my GPU is RX 6600 XT, I don't know if it's valid for RX 560X.

 

 

[deeveedee]

Thanks, @miliuco !  I will try iStat Menus again.  It did not display Radeon temp in Sequoia on my first attempt.

[deeveedee]

EDIT: Leaving this post for historical purposes, but it appears that the issues I observed were caused by my choice of Screen Saver and Wall Paper.  See my next post.

 

==================================

 

Up to this point in my Sequoia Beta testing and experimentation, I have been testing primarily with a single display connected to the RX560x DP port (using SMBIOS MM8,1).  I am now testing with two displays: the boot display connected to the RX560x DP port and the second display connected to UHD630 DP port 1 (left-most port when looking at the back of the unit).

 

I am finding that macOS is "confused" about display arrangement when attempting to operate with a mixed-mode of RX560x and UHD630 connected displays.  I haven't started to debug this, but I am moving back to macOS Sonoma to minimize the possibility that I am dealing with Beta macOS issues.

 

EDIT: The display arrangement issue may just be a Sequoia issue.  I am now running Sonoma 14.5 and the mixed display arrangement (one RX560x display and one UHD630 display) is working fine.  This requires more testing, but I'm not worried about debugging the initial release of a Sequoia Beta.

 

My test configuration is as follows:

• macOS Sonoma 14.5
• SMBIOS MacMini8,1
• RX560x DP set as Apple boot display and main display
• UHD630 DP set as Extended display
• using DP->DVI adapters on both displays

 

EDIT2: Other issues that I have noticed (in Sonoma testing)

• Microsoft Remote Desktop has issues with graphics acceleration when displays on my UHD630-connected displays.  This is because I am using DP->DVI adapters.  Solution is to disable MS Remote Desktop graphics acceleration.
• Microsoft Remote Desktop is confused by mixed-mode RX560x and UHD630 displays when operating in full-screen mode.  Disabling full-screen mode for MS Remote Desktop (operating each Remote Desktop in a window) fixes the issue.

 

EDIT3: Others who are testing graphics and who are not using DP->DVI adapters may see different test results.  The use of DP->DVI adapters has been challenging since I first started creating a macOS solution for the EliteDesk 800 G4/G5 Minis in May 2020 (see here).

Edited Monday at 05:32 PM by deeveedee

[deeveedee]

I have added this issue to Known Issues:

 

• Use of any Wallpaper other than "Dynamic Wallpapers" (System Settings > WallPaper) and use of any Screen Saver other than "macOS" (System Settings > Screen Saver) may cause multiple issues (including shutdown, startup, application launch ...).  Solution is to use only Dynamic Wallpapers and macOS Screen Saver.  Also, you may need to disable "Show as wallpaper" and "Show on all Spaces."

 

EDIT: This issue is common for those using OCLP to patch "Unsupported Macs" and hacks.  I had forgotten about it and had been experimenting with other Wall Papers and Screen Savers on this hack.  Some Sonoma problems I observed have all been resolved by changing Wall Paper and Screen Saver.  I will need to do the same for Sequoia and retest Sequoia.

 

EDIT2: It does appear that my choice of Wall Paper and Screen Saver was to blame for the issues I observed in Sequoia.  Using Sequoia now with Dynamic Wallpaper "macOS Beta" and macOS Screen Saver "macOS Beta" and I am not observing any display issues.

Edited Monday at 06:13 PM by deeveedee

[deeveedee]

I was debugging Sonoma and Sequoia with VirtualSMC Sensor Kexts enabled in my config.plist (including SMCRadeonSensor.kext 2.2.0 which is not yet released and is a pre-release).  I think that the pre-release version of SMCRadeonSensor.kext was causing startup problems for me in both Sequoia and Sonoma, so I have disabled all SMC Sensor kexts for my testing.

 

I plan to leave all Sensor kexts disabled for my testing.  When I publish my next EFI for this hack, it may have the Sensor kexts in OC/Kexts and they may be present in the config.plist Kernel > Add, but they will not be enabled.

 

 

EDIT: I added the following multi-display debugging tip to Known Issues:

• While debugging a multi-display configuration, you may experience macOS startup and/or login issues.  If so, startup and login to macOS with only the single boot / main display powered on.  After login, power on the other displays.  The displays should all be hot-pluggable.  At the time of this writing, I have not figured out why this happens, but it is likely related to the macOS handling of mixed-mode Radeon and Intel connected displays.

 

This multi-display issue may be somehow related to my connectors patch in SSDT-GFX0 which I still suspect of being incorrect.  The only way to confirm the connectors patch is to generate full debug log with WEG and Lilu debug kexts, examine the detected connector and then modify the connectors patch if necessary.

Edited Monday at 06:51 PM by deeveedee

[deeveedee]

After updating RestrictEvents.kext to 1.1.4 Beta from lorys89 here, Sequoia Beta 2 update applied without any issues.  macOS notified me of the Sequoia Developer Beta 2 update and I applied the 2GB update via OTA.

 

About This Hack: Sequoia Beta 2

Spoiler

 

EDIT: During the upgrade, I needed to turn off all but the main boot display (connected to RX560x) to allow the macOS upgrade to finish.  I have added this to Known Issues.  After the upgrade completed, I was able to turn on the additional displays for my multi-display setup.

Edited Monday at 07:55 PM by deeveedee

[deeveedee]

I have enabled WEG debug log based on info provided by joevt in this thread:

• Replace WhateverGreen.kext with DEBUG version from here
• Replace Lilu.kext with DEBUG version from here
• Add these boot-args to OC config.plist (not sure all are necessary): -liludbgall liludump=360 -wegdbg msgbuf=1048576
• EDIT: After initially posting this, I have updated my debug boot-args to debug=0x12a -liludbgall liludump=240 -wegdbg msgbuf=1048576

After making the EFI changes for WEG debugging and rebooting, look in /var/log for the Lilu log.

 

I noticed in the log the statement which confirms that my 20-byte connector patch is wrong

WhateverGreen       rad: @ (DBG) getConnectorsInfo conoverrides have invalid size 20 for 1 num

 

EDIT: The rad connector values that need to be patched are revealed by the WEG debug output:

0 is type 00000400 (DP  ) flags 00000304 feat 0100 pri 0000 txmit 11 enc 02 hotplug 01 sense 01

The patched values are determined from my post here.

 

type:  00000400

flags: 00000304

feat: 0100

pri: 0000

txmit: 11

enc: 02

hot plug: 01

sense: 01

 

This is a 16-byte patch.  I will make the connector patch changes and test.

 

EDIT2: Note that the WEG debug log suggests the use of boot-arg -raddvi to enable WEG's connector auto-correct (see log entry below).  WEG does not auto-correct our RX560x connector after adding boot-arg -raddvi.  We must define the connector patch with the connectors property (as I have done in SSDT-GFX0)

WhateverGreen       rad: @ (DBG) autocorrectConnector use -raddvi to enable dvi autocorrection

Again - my testing shows that use of WEG's -raddvi boot-arg does not fix our RX560x connector.

Edited 17 hours ago by deeveedee

[miliuco]

@deeveedee

 

Good find!!!

[deeveedee]

Thanks, @miliuco !  I tested a candidate 16-byte connectors patch, but it didn't work.  There's a lot about Radeon connector patching that I don't know, so I'm learning.

 

I'm also noticing multi-display issues (mixed mode with one display connected to dGPU and other displays connected to iGPU).  The RX560x dGPU in this EliteDesk 800 G4 Mini has only a single DP port, so the other two DP ports are driven by iGPU.  I'm hoping for more interest and participation in this thread so that we have other contributors to the solution.

 

For now, this hack is working with my 20-byte GFX0 connectors patch (SSDT-GFX0) in the EFI attached to Post #1 and I can reliably boot / login with multiple displays if I do the following:

• Set RX560x-connected display as Main and UHD630-connected displays as Extended
• Boot and login with only the one RX560x-connected display powered on (other extended displays powered off)
• Power on UHD630-connected extended displays after login

Following these display steps seems to be even more important after Resetting NVRAM.  I find that after Resetting NVRAM and after I boot / login once with displays off, I can then boot / login with all displays on until I reset NVRAM again.  I'm still testing this theory.

[deeveedee]

After failing to create a 16-byte connectors patch, I was beginning to doubt my SSDT-GFX0 patch.  I performed a quick test as follows to confirm that my patch is actually working and is the reason that the RX560x is working in this hack:

• I changed my connectors patch (derived here and implemented in SSDT-GFX0) as follows
  • Original patch: 0004000004030000000101010000000011020101
  • Revised patch: 0004000004030000000101010000000011020201

The revised patch leaves AMD9500Controller framebuffer connector 0 unchanged.  With the Revised patch implemented in SSDT-GFX0, this hack boots to black screen (just as it does without the patch).

 

My 20-byte patch is working and is doing what it is intended to do.  If anybody is following this and wants to try for themselves, I am going to inspect the WhateverGreen.kext code to see if I can figure out how to create the proper 16-byte or 24-byte patch as required here.

 

EDIT:

 

Code snippets from WhateverGreen/kern_con.hpp are below:

        /**
         *  Connectors from AMDSupport since 10.12
         */
        struct ModernConnector {
                uint32_t type;
                uint32_t flags;
                uint16_t features;
                uint16_t priority;
                uint32_t reserved1;
                uint8_t transmitter;
                uint8_t encoder;
                uint8_t hotplug;
                uint8_t sense;
                uint32_t reserved2;
        };

Connectors since macOS 10.12 have 24-byte connectors, so I should be defining a 24-byte connector, not a 16-byte (or 20-byte) connector.

 

EDIT2:

 

This code from WhateverGreen/kern_con.hpp suggests that my 20-byte connector will still work (as it does).  The reserved 4-bytes are not assigned.

                static inline void assign(T &out, const Y &in) {
                        memset(&out, 0, sizeof(T));
                        out.type = in.type;
                        out.flags = in.flags;
                        out.features = in.features;
                        out.priority = in.priority;
                        out.transmitter = in.transmitter;
                        out.encoder = in.encoder;
                        out.hotplug = in.hotplug;
                        out.sense = in.sense;
                }

 

Edited 21 hours ago by deeveedee