[GUIDE] Catalina, Big Sur, Monterey, Ventura, Sonoma, Sequoia on HP EliteDesk 800 G4/G5 Mini - The perfect MacMini8,1 Hackintosh

[deeveedee]

@MacKonsti I got the GitHub message.  This is my last hack - my next will be a real Mac with Apple silicon.  This HackMini is the best hack I've owned - if I got lucky with some of my ACPI patches, I'll take it.

[deeveedee]

EDIT: Slice informed me here that MSR 0xE2 is a register in each CPU and CFG Lock is a BIOS setting - the two are separate entities. It is absolutely possible for MSR 0xE2 to be locked (detectable by VerifyMsrE2 and ControlMsrE2) while CFG LOCK is not exposed in BIOS (and thus not changeable by ControlMsrE2). I'm leaving this experiment and still requesting volunteers to test, because I am still able to boot with OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks both false while MSR 0xE2 is locked.

 

NOTE: As Slice indicated here, setting AppleCpuPmCfgLock and AppleXcpmCfgLock to true will not hurt anything.  I will not be changing these settings in my posted EFI.  This post is for experimentation only.  In my next posted EFI, I will be changing AppleCpuPmCfgLock from true to false as recommended by Andrey1970 here.

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

Would anyone like to help me with an experiment?  Make sure you have a bootable USB with your "safe" EFI so you can boot if you have any problems.

 

IMPORTANT: If your 800 G4/G5 Mini does not boot after setting AppleCpuPmCfgLock and AppleXcpmCfgLock both false, please post your sanitized config.plist with your reported findings.  Thank you.

When I first switched from CLOVER to OC, I was uncertain about OC quirks AppleCpuPmCfgLock and AppleXcpmCfgLock (related to locked MSR 0xE2). CLOVER required KernelPm=true to boot Catalina, but OC would boot Catalina with AppleCpuPmCfgLock and AppleXcpmCfgLock both set to false. I used OC's VerifyMsrE2 tool and confirmed that MSR 0xE2 is locked; however, further analysis of the BIOS (by me and @rafale77 ) revealed that CFG LOCK is not publicly exposed and ControlMsrE2 is not able to unlock CFG Lock.

I am currently running my rig with AppleCpuPmCfgLock and AppleXcpmCfgLock both false. I don't know why, but it appears that, despite the locked state of MSR 0xE2, our EliteDesk 800 Minis are still able to boot macOS without enabling OC's AppleCpuPmCfgLock and AppleXcpmCfgLock quirks. Note that CLOVER was not able to boot Catalina without enabling KernelPm.

If you'd like to join me in this experiment, modify your config.plist so that Kernel>Quirks AppleCpuPmCfgLock and AppleXcpmCfgLock are both false.  Be sure to have a bootable USB with your "safe" EFI so that you can boot if you have any problems.

Edited April 4, 2021 by tonyx86
Added Andrey1970's correct setting for AppleCpuPmCfgLock

[v.osypets]

20 hours ago, tonyx86 said:

If you'd like to join me in this experiment, modify your config.plist so that Kernel>Quirks AppleCpuPmCfgLock and AppleXcpmCfgLock are both false. 

 

In my case (Elitedesk 800G5) it didn't boot with disabled those two quirks.

[deeveedee]

@v.osypets That is very interesting.  I am currently booting both my 800 G4 Mini (i7-8700) and 800 G5 Mini (i7-9700) with AppleCpuPmCfgLock and AppleXcpmCfgLock both false.  Just to be sure that I'm not confusing my settings, I made sure that AppleCpuPmCfgLock and AppleXcpmCfgLock are false on my primary disk EFI and on a new USB stick.  My rig boots fine in both cases.  Are you using iMac19,1 SMBIOS as your signature indicates and do you have a RX 560X GPU?  I am using MacMini8,1 with HD630 iGPU.  If you could post your sanitized config.plist, I'd like to compare to find differences.  Thank you.

[theroadw]

Just as a follow up on the CFG experiment, I booted mi ZBook with both quirks off, and it "worked" until I ran a CPU intensive app, and big crash, full reboot, CPU panic. This never happened with CFG lock quirks, so while it may be booting, it is unstable, so reverting to the old setting.

[deeveedee]

EDIT: Open Core 0.6.8 OCValidate identified issues with the config.plist that I posted with OC0.6.8-EFI-r001 (attached to Post #1). These issues are harmless for our EliteDesk 800 Minis and will be fixed in the next posted EFI. If you want a 'clean' config.plist, I corrected the errors in the attached config.plist. The errors identified by OCValidate were:

• OCS: Missing key Patch, context <Booter>!
• OCS: Missing key TextMode, context <Entries>!
• OCS: Missing key RealPath, context <Tools>!
• OCS: Missing key TextMode, context <Tools>!
• OCS: Missing key RealPath, context <Tools>!
• OCS: Missing key TextMode, context <Tools>!
• OCS: Missing key RealPath, context <Tools>!
• OCS: Missing key TextMode, context <Tools>!

 

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

 

My first EFI for OpenCore 0.6.8 is now attached to Post #1. This new EFI includes the following changes:

OC 0.6.8 EFI R001
ACPI

• Added missing _OSI("Darwin") conditions to conditionally enable Apple devices for macOS (SSDT-DMAC, SSDT-PLUG, SSDT-PMCR, SSDT-PPMC, SSDT-XSPI)
• Replaced SSDT-AWAC-HPET with SSDT-AWAC-HPET-RTC which includes RTC patch (same as CLOVER's Fix RTC) which changes RTC memory length from 0x8 to 0x2 to prevent RTC memory corruption

config.plist

• Added Base and BaseSkip keys to ACPI patches (ACPI > Patch)
• Added Booter > Quirks>ForceBooterSignature (Boolean, false)
• Added UEFI > AppleInput properties
• Added UEFI > Output > GopPassThrough (Boolean, false)
• Added UEFI > Audio > ResetTrafficClass (Boolean, false) (had missed this when it was added for OC 0.6.7)
• Removed UEFI > ProtocolOverrides > AppleEvent (now in UEFI > AppleInput)
• Changed Kernel > Quirks > AppleCpuPmCfgLock from true to false (only AppleXcpmCfgLock is required to be true)
• ACPI > Add > Item0: changed from SSDT-AWAC-HPET.aml to SSDT-AWAC-HPET-RTC.aml (includes RTC patch)
• Kernel > Add: Removed RTCMemoryFixup.kext
• NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args: removed rtcfx_exclude

 

Kexts

• Updated WhateverGreen.kext to version 1.4.9
• Updated VirtualSMC.kext to version 1.2.2
• Updated AppleALC.kext to version 1.5.9
• Updated NVMEfix.kext to version 1.0.6
• Updated Lilu.kext to version 1.5.2

• Removed RTCMemoryFixup.kext (using RTC memory length ACPI patch instead)

 

 

OC068-config-r002.plist.zip

Edited April 6, 2021 by tonyx86
Attached revised config.plist with non-critical errors fixed

[deeveedee]

In the OpenCore Discussion here, Andrey1970 indicates that renaming SAT0 to SATA may be harmful. Since it's only cosmetic, I plan to remove the SAT0->SATA ACPI patch from my next posted EFI.

In the OpenCore Discussion, a "new" concensus starting here is that USB Power Properties should be specified in both USBX (SSDT injection) and in USBPorts.kext. In my next EFI, it is likely that I will add SSDT-USBX SSDT (attached) to inject the same USB Power Properties currently specified in USBPorts.kext.

 

SSDT-USBX.aml.zip

Edited April 16, 2021 by tonyx86
Attached SSDT-USBX.aml

[deeveedee]

Thanks to @theroadw for noticing that the Device PMCR I'm injecting with SSDT-PMCR has a Memory32Fixed memory resource that matches a Memory32Fixed memory resource already designated by the HP EliteDesk 800 G4/G5 Mini's Device PRRE.  Both devices (PMCR and PRRE) include memory resource setting

                    Memory32Fixed (ReadWrite,
                        0xFE000000,         // Address Base
                        0x00010000,         // Address Length
                        )

I have not been screening my ACPI patches for overlapping (and potentially conflicting Memory32Fixed memory resource settings) and completely missed this.  While this potential mistake does not appear to have been causing any problems, I have a gut feeling that it would be safer to completely avoid the potential conflict.  

 

After examing the ACPI dumps of other real Macs (including iMac18,x), I have noticed that some Macs do not designate any Memory32Fixed memory resource for Device PMCR.  I am now running my hack with the following injected Device PMCR (which eliminates the Memory32Fixed resource):

            Device (PMCR)
            {
                Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (_OSI ("Darwin"))
                    {
                        Return (0x0B)
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }
            }

After several reboots and multiple sleep/wake cycles, I am not noticing any difference in behavior with the "new" PMCR.

 

EDIT: on Day 2 with this revised PMCR (no Memory32Fixed resource setting), my hack continues to work without issues.  I am continuing to lean toward this "new" Device PMCR definition for my updated PMCR patch.

 

My current SSDT-PMCR.aml is attached.

 

SSDT-PMCR.aml.zip

Edited April 25, 2021 by tonyx86
Attached updated SSDT-PMCR.aml

[deeveedee]

EDIT: I used Rehabman's ACPI Debug to dump the value of PWRM in the G4/G5 Mini ACPI.  Maybe not so surprisingly, the value of PWRM is

kernel: (ACPIDebug) ACPIDebug: { "PWRM: ", 0xfe000000, }

Based on my own review of the G4/G5 Mini ACPI and comparison to a real MacMini8,1's ACPI, IntObj PWRM (in the G4/G5 Mini's unpatched DSDT) is equal to the Base address of the Memory32Fixed buffer in a real Mac's PMCR._CRS.  Therefore, the original Acidanthera PMCR patch can be used without any modification to the original DSDT (no need to change any Memory32Fixed buffers in PRRE).  This exercise was a long way of confirming that there is no PMCR._CRS memory conflict and the Acidanthera PMCR patch is correct.

 

EDIT: I have concluded that there is no need to patch PRRE and that the PMCR patch is ok as-is.  My opinion is that the Memory32Fixed memory reservations in PRRE on a PC (and in PMCR on a real Mac) are simply marking reserved memory for OperationRegions PWMR (on a PC) and PMST (on a real Mac).  The overlapping memory reservations in PRRE and PMCR don't hurt anything.  I suspect that others, like me, will find that their systems behave just fine when including the PMCR patch and leaving PRRE unpatched.

Edited April 30, 2021 by tonyx86
Replaced with correction: conclusion is that PMCR and PRRE are fine as-is

[deeveedee]

My final EFI release for OC 0.6.8 is now attached to Post #1.  I have settled on the changes below (from R001) for my OC 0.6.8 EFI baseline (R004). If you use this EFI, be sure to populate Platform > Generic > MLB, ROM, SystemSerialNumber and SystemUUID with your own values in config.plist. Also be sure to customize USBPorts.kext as per the installation instructions (if you need to customize it).

OC 0.6.8 EFI R004: Changes from R001

config.plist

• Removed SAT0->SATA ACPI patch
• New: ACPI > Add SSDT-USBX.aml
• Fixed errors identified by OCValidate tool
  • OCS: Missing key Patch, context <Booter>!
  • OCS: Missing key TextMode, context <Entries>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!
  • OCS: Missing key RealPath, context <Tools>!
  • OCS: Missing key TextMode, context <Tools>!

ACPI

• Added SSDT-USBX.aml to inject the same power properties as USBPorts.kext
• NOTE: SSDT-PMCR.aml remains unchanged from R001

Edited April 27, 2021 by tonyx86

[deeveedee]

Just upgraded to Big Sur 11.3 using the OC 0.6.8 EFI r004 (attached to Post #1). No issues. Upgrade was flawless. The key to this upgrade seems to be that Kernel > Quirks > XhciPortLimit = False in the OC config.plist and you have a properly constructed USBPorts.kext with no more than 15 logical USB ports.

 

About This Mac: Big Sur 11.3

Spoiler

 

[deeveedee]

Now that I have completed 5 hacks since I switched from CLOVER to OC, my philosophy about Device EC is changing. I found on my most recent hack (a Kaby Lake R laptop), that it was easiest to add a Fake EC rather than rename the existing EC0 -> EC. This is because my SSDT hotpatches for brightness keys and ACPI debugging needed to be applied to the original EC0. It wasn't hard to apply the hot-patches with an EC0->EC rename - just a little easier to apply without the rename. Also, according to @1Revenger1 here , conditionally injecting a Fake EC (using condition _OSI("Darwin"), won't cause problems if you are dual-booting macOS and Windows with OC.

To make a long story short, I think it will be better to inject a Fake EC rather than rename the original EC in most cases and I am currently running this HackMini with the attached Fake EC. I don't notice any difference with the Fake EC and the renamed EC on this HackMini8,1, but for me, this is just a way to standardize my own hacks on a single methodology. If I continue to run this way with no problems, my next posted EFI will inject a Fake EC rather than rename EC0->EC.

There are a couple of things about the way I apply the Fake EC that may be different from what you've read:

• My EC scope is \_SB.PCI0.LPCB and not \_SB. I chose this scope because it's the scope in a real MacMini8,1 and I didn't notice any difference when I changed the scope to \_SB.
• Even though this HackMini is a "Desktop" PC, I don't disable the original EC0 device. My IORegistry has both the original Device EC0 and the Fake EC

If you want to test this Fake EC on your own rig, you will need to copy the attached SSDT-EC.aml to your EFI/OC/ACPI folder and make the following changes to your config.plist:

• disable the EC0->EC ACPI Patch (so the original EC0 is not renamed)
• Add a new "ACPI Add" rule to inject SSDT-EC

You can confirm that you've switched to the Fake EC by checking with IORegistryExplorer. You will see the new Fake EC and the original EC0. Note that AppleACPIEC is attached to the original EC0, because of the "PNP0C09" IONameMatch.

 

IORegistryExplorer: EC

Spoiler

 

SSDT-EC.aml.zip

Edited May 3, 2021 by tonyx86

[deeveedee]

I looked at the changes in Open Core 0.6.9 and don't see anything that motivates me to update (yet). Going to allow the dust to settle and watch other comments to learn a little before updating from 0.6.8 to 0.6.9. If anyone tries the update on their own, please share your lessons learned. NVMeFix.kext v1.0.7 has a new -nvmefaspm boot argument to force ASPM L1 on all NVMe SSDs. Read here for background. This sounds interesting.

[deeveedee]

EDIT: After this post, a new OC 0.6.9 was committed to github to correct the CustomDelays type error.  Sample.plist is now correct.

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

Took a quick look at OC 0.6.9 and ran ocvalidate against the sample.plist. Looks like ocvalidate 0.6.9 (and thus 0C 0.6.9) is looking for CustomDelays to be Boolean (contrary to the String value in sample.plist). If you're making your own changes from the 0.6.8 EFI r004 attached to Post #1, it looks like the changes for 0.6.9 are as follows (what I would release as OC 0.6.9 EFI R001):

Changes for OC 0.6.9
config.plist
- Remove: ACPI > Patch no longer includes EC0->EC rename
- New: ACPI > Add includes SSDT-EC to inject Fake EC
- New: UEFI > Quirks > EnableVectorAcceleration (True)
- New: UEFI > Quirks > ForgeUefiSupport (False)
- New: UEFI > ReloadOptionRoms (False)
- Change: UEFI > AppleInput > CustomDelays from String/"Auto" to Boolean/False (contrary to String value in 0.6.9 sample.plist)

Kexts
- Update: IntelMausi.kext v1.0.6
- Update: VirtualSMC.kext v1.2.3
- Update: NVMeFix.kext v1.0.7
- Update: Lilu.kext v1.5.3
- Update: AppleALC.kext v1.6.0

 

EDIT: This update looked so easy after I wrote this post, that I just went ahead and updated. No issues with 0.6.9 (and I don't notice any differences). I am currently running with boot-arg -nvmefaspm for NVMeFix.kext 1.0.7 for testing.

Edited May 5, 2021 by tonyx86

[thientruongdx]

you can edit for HP EliteDesk 800 G3 Mini

[deeveedee]

Post #1 now includes an EFI for Open Core 0.6.9 (OC0.6.9-EFI-r001). This new EFI for OC 0.6.9 includes the following changes from OC0.6.8-EFI-r004:

OC 0.6.9 R001
config.plist

• Remove: ACPI > Patch no longer includes EC0->EC rename
• New: ACPI > Add includes SSDT-EC to inject Fake EC
• New: UEFI > Quirks > EnableVectorAcceleration (True)
• New: UEFI > Quirks > ForgeUefiSupport (False)
• New: UEFI > ReloadOptionRoms (False)
• Change: UEFI > AppleInput > CustomDelays from String/"Auto" to Boolean/False

ACPI

• New: SSDT-EC.aml to inject a Fake EC

Kexts

• Update: IntelMausi.kext v1.0.5 -> v1.0.6
• Update: VirtualSMC.kext v1.2.2 -> v1.2.3
• Update: NVMeFix.kext v1.0.6 -> v1.0.7
• Update: Lilu.kext v1.5.2 -> v1.5.3
• Update: AppleALC.kext v1.5.9 -> v1.6.0

Before using this new EFI, edit config.plist to populate PlatformInfo > Generic > MLB, ROM, SystemSerialNumber, SystemUUID with your own values. See full installation instructions here.

Edited May 6, 2021 by tonyx86

[deeveedee]

7 hours ago, thientruongdx said:

you can edit for HP EliteDesk 800 G3 Mini

 

I won't go into a lot of details here about the G3 Mini, but if you're like me, you'll find that everything works on the G3 Mini except wake from sleep.  I no longer have macOS running on my G3 Mini (it's a Windows Server now) and I don't have my G3 Mini's EFI.  In order to hack your G3 Mini, you'll need to dump your original ACPI so that you can make the necessary changes to my G4/G5 Mini EFI.  Some differences between the G3 Mini and G4 Mini EFI (differences that I remember) will be as follows:

• Device PMCR and PPMC are different (look at your original ACPI)
• You may need an ACPI patch to fix a kernel panic at boot
• Wake from sleep doesn't work, so disable sleep
• See the Dortania Guide for Quirks and other config.plist options that are different for the G3 Mini architecture (Sky Lake or Kaby Lake)

You can use this guide to learn.  If you have a choice, I would recommend a G4 or G5 Mini instead of the G3 Mini.

[deeveedee]

Thanks to the conversation about _DSM starting here, I will be making a change to my OC config.plist to create a configuration that is better suited to dual-booting macOS and Windows with OC.  I'll need to review my config, but I suspect that I'll be able to remove the _DSM rename patch in config.plist.

 

EDIT: I've cycled my hack through multiple reboots and multiple shutdown/starts and all is working well without the _DSM->XDSM rename patch.  The system is working perfectly and there are no ACPI errors.

Edited May 8, 2021 by tonyx86

[deeveedee]

For some reason, SSDT-PPMC is missing from the OC 0.6.9 EFI that I attached to Post #1. The missing SSDT results in a very brief "Failed to find SSDT-PPMC" error reported by OC at boot, but other than that, it doesn't seem to affect anything. I will include this missing SSDT in my next EFI. If you want to "fix" your EFI before I post the update, copy the attached SSDT-PPMC.aml to your EFI/OC/ACPI folder.

SSDT-PPMC.aml.zip

[deeveedee]

A new OC EFI OC0.6.9-EFI-r002 is now attached to Post #1. This new EFI includes the changes below. Since this revised EFI replaces OC0.6.9-EFI-r001 (which has been deleted from Post #1), the OC0.6.9-EFI-r001 changes are also listed below.

Before using this new EFI, edit config.plist to populate PlatformInfo > Generic > MLB, ROM, SystemSerialNumber, SystemUUID with your own values. See full installation instructions here.

OC 0.6.9 EFI R002
config.plist

• Remove: ACPI Patch _DSM->XDSM is unnecessary and is no longer included

ACPI

• Restore missing SSDT-PPMC.aml (inadvertently deleted this when publishing 0C 0.6.9 EFI R001)

OC 0.6.9 R001
config.plist

• Remove: ACPI > Patch no longer includes EC0->EC rename
• New: ACPI > Add includes SSDT-EC to inject Fake EC
• New: UEFI > Quirks > EnableVectorAcceleration (True)
• New: UEFI > Quirks > ForgeUefiSupport (False)
• New: UEFI > ReloadOptionRoms (False)
• Change: UEFI > AppleInput > CustomDelays from String/"Auto" to Boolean/False

ACPI

• New: SSDT-EC.aml to inject a Fake EC

Kexts

• Update: IntelMausi.kext v1.0.5 -> v1.0.6
• Update: VirtualSMC.kext v1.2.2 -> v1.2.3
• Update: NVMeFix.kext v1.0.6 -> v1.0.7
• Update: Lilu.kext v1.5.2 -> v1.5.3
• Update: AppleALC.kext v1.5.9 -> v1.6.0

Edited May 8, 2021 by tonyx86

[lolwatpear]

Im using your latest version (OC 0.6.9 EFI R002)  with the mini 800 g5 and I have no ethernet.  all that it there is the bluetooth interface.  I didn't modify the EFI at all.  Do you know what could be wrong? 

 

Edit: intelmausi isn't loaded per kextstat | grep -v com.apple

Edited May 8, 2021 by lolwatpear

[deeveedee]

@lolwatpear Please post your sanitized EFI (remove ROM, MLB, SystemSerialNumber, SystemUUID).

 

EDIT: @lolwatpear I just downloaded OC 0.6.9 EFI R002 and copied it to the EFI on a USB thumb drive.  I edited config.plist to insert my ROM, MLB, SystemSerialNumber, SystemUUID.  All working perfectly.  Hopefully we'll be able to figure this out after you upload your actual EFI (sanitized).

 

EDIT2: @lolwatpear  While you're collecting your sanitized EFI to upload, check your BIOS to make sure that Embedded LAN is enabled.  I just tested to see this for myself: if your Embedded LAN is disabled in BIOS, IntelMausi doesn't load (and you won't have Ethernet).

 

BIOS: Built-in Device Options

Spoiler

 

Edited May 9, 2021 by tonyx86

[lolwatpear]

3 hours ago, tonyx86 said:

@lolwatpear Please post your sanitized EFI (remove ROM, MLB, SystemSerialNumber, SystemUUID).

 

EDIT: @lolwatpear I just downloaded OC 0.6.9 EFI R002 and copied it to the EFI on a USB thumb drive.  I edited config.plist to insert my ROM, MLB, SystemSerialNumber, SystemUUID.  All working perfectly.  Hopefully we'll be able to figure this out after you upload your actual EFI (sanitized).

 

EDIT2: @lolwatpear  While you're collecting your sanitized EFI to upload, check your BIOS to make sure that Embedded LAN is enabled.  I just tested to see this for myself: if your Embedded LAN is disabled in BIOS, IntelMausi doesn't load (and you won't have Ethernet).

 

BIOS: Built-in Device Options

  Hide contents

 

 

Sorry, for some reason my second update to that post wasnt added hours ago and thought it was.  The mini version of the 800 g5 uses realtek lan, not Intel. The realtek kext made it work.  Thanks for the setup.

Edited May 9, 2021 by lolwatpear

[deeveedee]

@lolwatpear I have both the HP Elitedesk 800 G4 Mini and HP EliteDesk 800 G5 Mini (pictured in Post #1).  Both have Intel LAN and both use IntelMausi.kext.  The HP Specs indicate Intel LAN as well.  Are you sure you have an HP EliteDesk 800 G5 Mini?  It could be, but it's the first that I've heard this.  If you can post a picture of your PC, that would be helpful.  Thank you.

[lolwatpear]

9 hours ago, tonyx86 said:

@lolwatpear I have both the HP Elitedesk 800 G4 Mini and HP EliteDesk 800 G5 Mini (pictured in Post #1).  Both have Intel LAN and both use IntelMausi.kext.  The HP Specs indicate Intel LAN as well.  Are you sure you have an HP EliteDesk 800 G5 Mini?  It could be, but it's the first that I've heard this.  If you can post a picture of your PC, that would be helpful.  Thank you.

Sorry I figured it out.  Im using the prodesk 400 g5.  When I searched for an opencore EFI for prodesk 400 g5, your thread comes up and I just missed the whole elite/prodesk naming convention lol.  So the NIC must be one of the few differences between the the two.  Otherwise, your EFI appears to be working great for the prodesk 400 g5 in my case.