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

[deeveedee]

This thread extends the EliteDesk 800 G4/G5 Mini thread here which provides a macOS solution using the UHD630 iGPU.  This thread provides a macOS solution for the HP EliteDesk 800 G4 / G5 Mini with the AMD Radeon RX560x dGPU.  With this solution, all video ports are enabled / accelerated.

 

The EFI for this hack is attached.

Instructions for using this EFI are below.

My methodology for developing this EFI is here, which turns out to be total luck, because the actual RX560x black-screen solution is here.

GB5 Metal scores comparing UHD630 with RX560x are here.

GB6 Metal score for RX560x is here

Unigine Heaven Benchmark is here

The EFI change log is here

Known issues, observations and solutions are here

 

The specifications for the PC that I am using for this solution are as follows:

• HP EliteDesk 800 G4 Mini
• i5-8500T CPU
• AMD Radeon RX560x 4GB dGPU
• 32GB DDR4 (2 x 16GB)
• 500GB WD Black SN750 M.2 NVMe SSD
• 150W Power Adapter
• See testing with 65W CPU and 230W Power Adapter here

 

Instructions for using the attached EFI

 

• This thread is an extension of this thread.  I will not be rehashing the entire methodology that resulted in this solution, so if you want to know the history and the basics, read this.
• The attached EFI drives multiple displays connected to both the RX560x DP port and UHD630 iGPU ports.  It uses SMBIOS model Macmini8,1.  For those wishing to connect only a single display to the RX560x DP port, a configuration similar to this or this may be desirable.
• Add your own PlatformInfo to the Open Core config.plist
• iGPU DeviceProperties work with my DP->DVI adapters.  You may need to revise iGPU and Audio DeviceProperties for your own hack depending on your graphics ports/adapters
• In order for iGPU ports to work, Integrated Video must be enabled (Integrated Video checkbox checked) in BIOS.  For multiple display configurations, BIOS selection of the Boot VGA display appears to only affect which display shows the BiOS boot sequence and doesn't appear to affect macOS multi-display operation after macOS is booted.
• The attached EFI keeps the configured Framebuffer definition for the RX560x DP port.  I have found that this enables the RX560x to drive my DP->DVI adapter/display without issues.  I suspect that it will work with a DP->HDMI adapter as well, but this needs to be tested
• SecureBootModel is Disabled in config.plist to permit installation of Sonoma 14.4+.  Change to your preferred SecureBootModel after installing macOS if desired.
• This EFI assumes that VT-d is enabled in BIOS.  A revised DMAR table is included in the EFI.
• This EFI assumes that TPM is enabled in BIOS (for those who want to dual-boot with Windows).  An ACPI patch removes the TPM device in macOS.
• There are threads that provide performance tweaking properties to add to the GFX0 properties (via config.plist DeviceProperties or SSDT).  So far, I have not experimented with RX560x performance tweaks since my primary goal was providing a solution for a working hack.

Notes: DAGPM.kext (derived from a kext original provided by Toleda) may not be necessary.  I haven't tested without it.  I'm sure there are other things in my EFI that are unnecessary, but it works.

 

EFI-UHD630-RX560x-OC100-01.zip

Edited 22 hours ago by deeveedee
Added Sequoia to tags

[deeveedee]

EDIT: My discovery of the RX560x black-screen solution was total luck, but I'll take it.  The actual solution to the RX560x black-screen issue is here.  Leaving the post below for history and a good laugh.

 

The key to success with AMD Radeon patching of this hack (my first Radeon Framebuffer patching experience with WhateverGreen) was recognizing that, after booting macOS, the display connected to the RX560x DP port was "on" but black. The display "on" but black meant that macOS has a compatible AMD Framebuffer, but the connector within the frame buffer was incorrectly defined.  What simplified debugging for me was creating an EFI that simultaneously enabled the UHD630 graphics ports and RX560x so that I could boot without a black screen (display connected to a UHD630 port) and inspect IOReg to confirm fixes and identify problems.  Long story short, I was able to resolve the connector definition issue (which caused the black screen) based on a hint here.  The addition of an SSDT that defined connector-count and connectors proved to be the solution to the black screen problem. 

 

My methodology (a series of false starts and dead-ends that you can see by reviewing this thread) was basically as follows:

• Extract EliteDesk 800 G4 Mini ACPI and inspect to identify necessary ACPI patchs
• Extract vBIOS for RX560x and use tools on the extracted vBIOS to determine the number of defined connectors in the vBIOS (one)
• Create an SSDT that redefined the single connector (at Framebuffer Index 0) with connector-count = 1, where the connector property is built from information extracted from vBIOS and the macOS frame buffer definition for the Radeon 9500 Acre frame buffer
• My references for some of the methodology and tools are here and here.  The references and tools were for older macOS, so I needed to adapt to changes in Framebuffer with the aid of HexFiend which I used to inspect the Framebuffer definitions in macOS Catalina (which I assumed to be appropriate for Sonoma)

 

By combining this SSDT (which defines connector-count and connectors) with an EFI similar to the one that I created for the UHD630-only version of the EliteDesk 800 G4/G5 Mini, I have a hack that drives multiple displays and benefits from RX560x graphics acceleration.

 

EDIT: Note that my SSDT-GFX0 defines connectors as a 20-Byte value.  This reference indicates that the connector definition should be 16 or 24-Byte format.  My connectors property did not work without the additional 4-Byte "Code Construction" { 0x11, 0x02, 0x01, 0x01 } (Read here).  Also, when you inspect IOReg, you will see that GFX0 has 6 Framebuffer connectors with only one display attached to the connector at Index 0.  I attempted to add property { "CFG,CFG_FB_LIMIT", 0x01 } to my SSDT-GFX0, but this broke my patch.  I didn't bother learning more or attempting other values.  Also note that, unlike for the UHD630, I did not need any AppleGraphicsDevicePolicy boot-args for the RX560x (e.g., I did not need agdpmod=vit9696).

Edited 23 hours ago by deeveedee

[deeveedee]

Known Issues, Observations and Solutions

 

• Possible RX560x performance increase when adding @0,name and @0,compatible GFX0 properties.  See here.  Update: I have removed name and compatible property definitions from SSDT-GFX0 for macOS Sequoia.  Not sure if these properties are making any performance difference in Sequoia.
• Solved - see here.  I'm suspicious of my 20-byte connectors property in my SSDT-GFX0.  While it works, I think it should be 16 or 24 byte as stated here.  I tried without success to use Lilu and WhateverGreen debug kexts (to produce debug log and to see discovered connectors).  I think it is necessary to try another attempt at producing debug log with the debug kexts so that the correct connectors byte sequence can be created.  This is a low priority, since my solution is working.  Note that padding the connectors patch with an additional four 0x00 bytes (for a total of 24 bytes) breaks the patch and causes boot to black screen.
• For those who wish to use a single display connected to the RX560x DP port (no displays connected to UHD630 iGPU ports), this configuration (iMac19,1) or this configuration (iMac19,2) may be desirable.  For working wake with iMac19,x, you may not be able to use a headless iGPU framebuffer.  See here.
• With DAGPM.kext disabled while testing iMac19,2 SMBIOS, I observed hesitation during operation of GeekBench6 and I lost my left mouse button.  I did not test long enough to confirm that disabling DAGPM.kext was the cause of this.  I am leaving DAGPM.kext enabled and don't plan to test further.  See more here.
• When switching between SMBIOS models during my testing (e.g., switching between Macmini8,1, iMac19,1 and iMac19,2), I noticed that graphics performance improved after more than one reboot / NVRAM reset cycle.  I'm not sure why this would be the case, but when switching SMBIOS models, it may be best to reboot and reset NVRAM more than once before running benchmarks.
• I'm using RestrictEvents.kext property revblock=media on my HackBookPro6,2 and I think it has improved non-metal performance on that old hack.  I've seen posts that suggest the property is useful for Metal dGPUs also.  I have added this property to my OC config.plist and am testing.
• Solved With SMBIOS iMac19,2 and a headless iGPU, wake from sleep results in black screen.  The solution I found is not to use headless iGPU frame buffer when using SMBIOS iMac19,2.  See here.
• At the time of this writing, the MM8,1 EFI attached to Post #1 specifies SecureBootModel=Disabled in the OC config.plist.  This allows Sonoma 14.4+ to be installed / upgraded.  After installing/upgrading Sonoma, SecureBootModel can be enabled (e.g., for SMBIOS MM8,1, SecureBootModel = j174).  Read more about Open Core's SecureBootModel here.
• 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."
• 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.
  The SSDT-GFX0 posted here appears to have resolved my multi-display issues.  Still testing.
• With multiple displays, where the Main display is connected to the dGPU DP port and Extended displays are connected to the iGPU DP ports, starting Firefox browser on an Extended display may result in a blank Firefox window.  Starting Firefox on the Main display and then moving the window to an Extended display is a work-around.  If the problem persists, disable Firefox hardware acceleration (General > Performance > Uncheck Use Recommended Performance Settings > Uncheck Use Hardware Acceleration)
• Back in May 2020 when I was figuring out how to enable multiple displays on my HackMini8,1 here with only UHD630 iGPU, I needed to disable AGDC.  I thought that disabling AGDC for the RX560x might help with any multi-display issues on this hack, but disabling AGDC (using CFG,CFG_USE-AGDC=false in OC config.plist DeviceProperties) results in booting to black screen.  I did confirm via IORegistry Explorer that the DeviceProperty does properly set CFG_USE_AGDC = false: 

Edited 22 hours ago by deeveedee

[deeveedee]

Change Log

 

• 11 May 2024: EFI-UHD630-RX560x-OC100-01: First working EFI with full acceleration of both RX560x and UHD630 graphics.  Based on Open Core 1.0.0.

Edited May 11 by deeveedee

[CloverLeaf]

Still fighting the black screen ? 🙂

[deeveedee]

@CloverLeaf So far, I have created this thread and reviewed a few other threads for the RX560.  I haven't yet created the new EFI for testing.  I hope to be able to look again later next week.

[CloverLeaf]

Nice! Last time I tried playing with RX560 I was not able to pass the black screen after boot. @pastrychef had exactly the same issue. Seems like everything is working but no video output. I would love to see your Mini working!

 

 

PS: Just ordered Mini G4+RX560....  Will contribute to the troubleshooting soon. 

Edited May 6 by CloverLeaf

[deeveedee]

@CloverLeaf Pastrychef's black screen was fixed by eliminating WhateverGreen.kext.  I plan to find a solution that keeps WEG.  I'll be able to start looking at this later this week.

[CloverLeaf]

@deeveedee Yes, I saw that but it didn't fix the issue for me. I will test again in a few days.

[deeveedee]

I have successfully installed macOS Sonoma 14.4 on this hack with RX560x.  I need to cleanup my EFI a bit and optimize it, but for those who wish to attempt before I post my first EFI, here's what I did:

• Start with my original EFI here
• Upgrade to Open Core 0.9.9 (not necessary, but I did anyway)
• Add ACPI patch to rename GFX0 -> IGPU
• Add ACPI patch to rename PEGP -> GFX0 and disable unused PEG1.GFX0 and PEG2.GFX0 (formerly PEG1.PEGP and PEG2.PEGP)
• Create graphics DeviceProperties (in config.plist) for Radeon, but spoof RX580 (I wasn't able to get RX560 to work on my first pass which is why I still need to clean up my EFI.  I don't know if this is because of the graphics card or the fact that I'm using DP->DVI adapters).  Spoof by setting ATY,DeviceID = 0xDF67 and Framebuffer name to ATY,Orinoco.  There are probably other spoofs that work, but this is what I did to get around the black screen for now. My goal is to eliminate the spoof after I examine IOReg, but this spoof results in a working macOS.
• Keep WhateverGreen.kext and add boot-arg agdpmod=vit9696 (not sure this was necessary, didn't test without)
• Keep Macmini8,1 SMBIOS (I'd like to test with iMac19,1 and plan to switch if it works)

Spoiler

 

Next steps for me before I post my first EFI are:

• Experiment with other DeviceIDs / Framebuffers.  This might be tricky for me, because I am using DP->DVI adapters
• Experiment with SMBIOS iMac19,1
• Eliminate unnecessary changes (e.g., I may not have needed some of the ACPI renames)
• Cleanup my EFI and make sure I've documented my changes / steps

 

EDIT: I changed SMBIOS to iMac19,1 and upgraded to Sonoma 14.4.1.  This will be my last update for a while as I'm busy with other things.

 

Spoiler

 

EDIT2: Ok, I couldn't resist.  I now have my hack working with Framebuffer = Acre (should be the native Framebuffer for this RX560).  Now, no more updates for a while.

Edited May 8 by deeveedee

[deeveedee]

I'd like others who are interested to take a look at the attached EFI.  I've decided to post this before I debug / test further to give others the opportunities to test and revise.  The known problems with this EFI are as follows:

• I was unable to eliminate the "black screen" in macOS with the native RX560x DeviceID (0x67FF).  The attached EFI spoofs DeviceID 06EF (a valid DeviceID for RX560 with Framebuffer Acre).
• With the spoofed RX560 DeviceID, macOS boots without black screen, but graphics is not fully accelerated.
• Since graphics is not fully accelerated, I set WallPaper (System Settings) to Dynamic:Sonoma with "Show As Screen Saver" toggled OFF

My next steps when I get some time will be to configure this hack to allow remote login, change the DeviceID to 67FF (or remove DeviceID from DeviceProperties to allow macOS to detect the native DeviceID) and to remotely login to the hack to examine IOReg while the hack is in "black screen"

EFI-OC099-Draft1.zip

Edited May 8 by deeveedee

[CloverLeaf]

Thank you for your effort man! I will test it after work tonight. I have DP->DP and DP->HDMI options. Let me know if I can do anything else that will contribute to this.

[deeveedee]

@CloverLeaf I'm open to your suggestions, as I won't have much time to play with this for a few days to a week.  When I was first creating the EFI for the UHD630 version in the other thread, I experienced black screens until I found the correct DeviceProperties for my configuration with DP->DVI adapters.  My instincts tell me that the correct approach with the RX560 is to enable Remote Login (System Settings > General > Sharing), allow this hack to boot black screen and then to remote login and look at IOReg.

 

Note that I have added kext DAGPM.kext which I think might be unnecessary.   I read in another thread that Toleda created the kext for AMD power management.  I took his kext and inserted my own entries for iMac19,1.  Since I'm using iMac19,1 SMBIOS, I think that the dGPU power management should be handled natively, but I haven't gotten far enough to test (and won't until graphics acceleration is working).

 

Clearly, since this hack boots with DeviceID 0x67EF, the issue to be resolved is the selection of a working DeviceID / Framebuffer that enable graphics acceleration without the black screen.

[hardcorehenry]

Adding no-gfx-spoof property via config or ACPI might help.

Spoiler

 

[deeveedee]

@hardcorehenry Thanks!  I did see that here and will definitely test.

 

EDIT: @hardcorehenry thank you for the suggestion.  no-gfx-spoof did not work for me.  Hoping that someone else tests.

 

I'm beginning to get the feeling that a video bios flash might be necessary.

 

See this for a video bios flashing example.

 

EDIT2: I see that I'm not the first to suspect this.  See here to give credit where credit is due.

Edited May 9 by deeveedee

[CloverLeaf]

19 hours ago, deeveedee said:

I'm beginning to get the feeling that a video bios flash might be necessary.

 

See this for a video bios flashing example.

 

Seems like it will be less painful than trying to trick it in some weird ways.

[deeveedee]

While I'm busy with other stuff, I didn't want to leave testers without a workable solution.  I have switched back to SMBIOS Macmini8,1 with a configuration that enables both the iGPU driven video ports and the dGPU port.  The following changes are necessary and are included in the attached EFI:

• BIOS: Set boot display to Internal VGA
• config.plist: Change SMBIOS to MacMini8,1
• config.plist: Restore DeviceProperties for your iGPU
• config.plist: Remove @0,AAPL,boot-display property from dGPU DeviceProperties (after further testing, I don't think this matters except to determine the display that shows the Apple logo during boot)
• config.plist: Restore iGPU boot-args
• config.plist: Set iGPU framebuffer-con2-index = -1 (there are only two iGPU ports, so disable the third port in the frame buffer)
• Revert to USBPorts.kext for Macmini8,1
• Change DAGPM.kext Machine to Macmini8,1

By switching back to Macmini8,1, we can boot macOS with graphics acceleration (for displays connected to iGPU ports) while debugging dGPU.  This will allow us to make changes to the dGPU DeviceProperties without having to deal with dGPU black screen.  Note that I could have achieved the same dual-GPU configuration with iMac19,1, but am switching to Macmini8,1 since it's easier for me to keep track of multiple EFIs.

 

I have performed the above mods on my hack's EFI and see the following:

 

Both iGPU and dGPU are in IORegistry

Spoiler

 

DAGPM.kext properties are in IORegistry

Spoiler

 

About This Mac shows UHD630 (no surprises)

Spoiler

 

My new test EFI is attached.  This EFI has iGPU DeviceProperties for MY DP->DVI adapters.  You may need to change iGPU DeviceProperties for your hack.

EFI-UHD630-RX560-DRAFT1.zip

 

Edited May 13 by deeveedee

[deeveedee]

I performed a quick search for suitable vBIOS alternatives at TechPowerup for our HP RX560x and didn't find a suitable alternative.  The RX560x is a mobile version of RX560, so I don't think flashing with a desktop RX560 vBIOS is advisable (I don't know enough to be certain).

 

For now, I think the best approach to getting working RX560x in macOS is to experiment with the dual GPU configuration.  This Radeon info is interesting.  Maybe using debug versions of Lilu and WhateverGreen could produce useful debug data.

 

With the EFI I posted here, I see the following Graphics System Info:

Spoiler

 

 

Edited May 10 by deeveedee

[deeveedee]

For those who want to attempt to figure out possible AMD9500Controller patches for this hack, it might be easier to investigate in macOS Catalina where AMD Framebuffer kexts still contained the patchable binaries.  The steps that you can research are as follows:

 

• Install macOS Catalina (the dual-GPU EFI I have provided works for Catalina, too)
• Download Pavo's PHP script and make sure it references AMD9500Controller
• run Pavo's PHP script to extract AMD frame buffer definitions in Catalina and look at Framebuffer definitions for Framebuffer Acre

 

EDIT: When you do the steps above, you'll find the following frame buffer definition for Acre

Acre (3) @ 0x718c5
, , 
0000007adf05000000000000040000040300000001010100
000000110202010000000000080000040200000001020000
000000210305040000000004000000040200000001030000

 

Edited May 10 by deeveedee

[logyon]

Impessiving testing and experimenting so far.

 

How far os do you think it will reach to Sonoma?

[deeveedee]

I am a newbie when it comes to Radeon Framebuffers.  This will be my first attempt to patch Radeon Framebuffers myself (and so far, I don't know what I'm doing).  Based on what I've read, the experts who are still active are Slice and Mieze.  Maybe RobertX.  I'm sure the Acidanthera folks like vit9696 know this stuff, too.   For those who are here to watch and wait without actively participating and helping, it will be more fun to watch grass grow.

 

EDIT: I am able to patch the Acre Framebuffer in Catalina.  My patches in Open Core EFI are being reflected in IORegistry.  For example, I am able to change connector-type from DP -> HDMI and I can change ATY,ControlFlags.  Now, I just need to figure out what needs to be patched.

Edited May 10 by deeveedee

[deeveedee]

I have followed this guide without success, so I'm showing my work so others can review and hopefully improve upon what I've done:

• I installed and booted Catalina using my EFI posted here.  Catalina still includes code in the kexts, so kexts can be patched with binary replacement (without WhateverGreen).
• I used Pavo's PHP script to extract the Catalina AMD Framebuffers.  After using Pavo's script, I found that the FrameBuffer extraction wasn't perfect.  Probably because Pavo's PHP script version that I used was for an earlier version of macOS.
• I inspected the extracted FrameBuffer definitions from Pavo's script and, using HexFiend, selected the FrameBuffer definition for Acre Connector at Index 0: 0004000004030000000101010000000011020201
• I followed the instructions here to create the "Code Construction" for our HP RX560x: 11020101
• I combined the original Acre FrameBuffer Connector at Index 0 with the HP RX560x Code Construction to form 0004000004030000000101010000000011020101. 
• I performed a binary replace in kext com.apple.kext.AMD9500Controller (using Open Core Kernel > Patch):
  • Find:             0004000004030000000101010000000011020201
  • Replace #1:  0004000004030000000101010000000011020101
  • Replace #2: 0004000004030000000100000000000011020101
    (I tried both Replace #1 and Replace #2 without success)
  • I did confirm that my Open Core binary replacements were actually performing the replacement by inspecting test results in IORegistry Explorer.
    
     

I'm skipping a lot of explanation, but hopefully, those who have studied can follow this and point out my errors.  After performing a binary replacement with Open Core, the display is still black.

Edited May 11 by deeveedee

[deeveedee]

I don't quite know how, but I have achieved full RX560x graphics acceleration in Sonoma 14.4.1.  I was experimenting with Catalina AMD Framebuffer patching and accidentally booted Sonoma during my testing and to my surprise ... no black screen and full acceleration.  So now we know that it is possible and that my Framebuffer patching strategy is close.  I just need to figure out what I did so I can create instructions.

 

I am currently running with a slightly modified version of this EFI and have multiple displays connected to both the RX560x DP and UHD630 DPs.  My GB5 Metal scores for UHD630 and RX560x are below for comparison.

 

i5-8500T UHD630 GB5

Spoiler

 

RX560x GB5 Metal

Spoiler

 

Edited May 11 by deeveedee

[CloverLeaf]

I didn't have the time to play with my mini, but you did a great progress! Congrats @deeveedee!

[deeveedee]

@CloverLeaf Thanks!  I rebooted and the full graphics acceleration persisted.  I'm going to spend some time to figure out which of my changes are necessary before posting a final solution.  The good news is that the RX560x can be patched without flashing a new vBIOS and it works in Sonoma.

 

EDIT: I have two EFIs - one with fully working RX560x and one with RX560x black screen.  Figuring out the difference should be a simple step-by-step process of elimination.  I'm going to admit now that I think I got a little lucky.

 

EDIT2: I have narrowed the required change down to a few mods that I can incorporate into an SSDT.  Ironically, the patches that I was trying to test in Catalina work in Sonoma and not Catalina!  If I hadn't accidentally booted Sonoma while testing Catalina, I never would have known.  How does the expression go?  ... Luck is when opportunity meets preparedness.  The patching strategy worked, just not in the way I thought it would.

 

I'm going to digest all this for a while and come back when I have everything tested and cleaned up.  This didn't take as long as I thought it would.

 

EDIT3: The methodology that worked for me is summarized here

Edited May 11 by deeveedee