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

[deeveedee]

@joevt Thank you!  I never thought I'd be learning so much at this stage of my hackintosh experience.  Definitely going to miss this when Apple officially ends Intel support.

[MaLd0n]

The laziness that lives in many people is stronger than the remap procedure and this patch works very well and so far there has never been a problem. 

[deeveedee]

@MaLd0n I've been told that my laziness is stronger than most.

[MaLd0n]

I just generate the USB kext in Windows with the USB Tool Box and the patch always activated for macOS and let's move on. In my laptops, laziness couldn't win. 5 or 6 ports.

 

 

[ird]

46 minutes ago, deeveedee said:

@ird Were you able to learn from any of the work that @rafale77 was doing here?

 

Indeed, I did; lots!

 

unfairvga bootarg brings down the dGPU score so I decided against it. OTOH, what @rafale77 mentioned about "unforcing" the AMD decoder via command line not working for him was something I did not see in my case. I could see iGPU again decoding video without a reboot so I decided to stick with the shell scripts. I definitely need to do more testing so it's possible that I might have missed something. I'll report back here if and when I learn something new.

[deeveedee]

3 hours ago, ird said:

 I've never used DAGPM.kext, so can't comment on that.

 

Your Windows / macOS dual-boot experiences mirror mine.  I've never had much luck with booting Windows and macOS from the same drive, but I'm tempted to try again.   

 

With regard to kexts (including DAGPM.kext) and their impact on Windows, kexts are a macOS construct, so the kexts injected by Open Core (into macOS) have no affect on Windows.  ACPI patches done incorrectly can impact Windows when Open Core is used to boot Windows.

Correction: the "DAGPM patch" was my screw-up.  I mean the DMAR patch (the DMAR ACPI patch, not the DAGPM kext injection)

Edited July 20 by deeveedee

[ird]

1 hour ago, deeveedee said:

 

Your Windows / macOS dual-boot experiences mirror mine.  I've never had much luck with booting Windows and macOS from the same drive, but I'm tempted to try again.   

 

With regard to kexts (including DAGPM.kext) and their impact on Windows, kexts are a macOS construct, so the kexts injected by Open Core (into macOS) have no affect on Windows.  ACPI patches done incorrectly can impact Windows when Open Core is used to boot Windows.

Correction: the "DAGPM patch" was my screw-up.  I mean the DMAR patch (the DMAR ACPI patch, not the DAGPM kext injection)

 

Actually, now that I think of it - I've never booted Windows from within opencore bootloader. So, the question of ACPI patches impacting Windows is moot. I've always dual booted from BIOS menu (internal secondary nvme for my old G5 without RX560 or similar separate NVMe for non-HP machines). The reason has always been that through the OC bootloader, Windows COA digital license tied to the system is not applicable. It has the secondary benefit of not interfering with OC ACPI patches.

 

EDIT1: moved the GPU topic to new response to keep it separate.

Edited July 20 by ird

[ird]

Making a new post for a different topic. I had some time at my hands today so tried something I'd been wanting to since a long time. I wanted to experiment with unlocking extra GPU shaders if possible (from existing 896 to 1024 on the RX560). This is hit-or-miss based on the ASIC. If this ASIC had physical defects there is no way to do, else if it was locked in firmware (vbios), then there is a possibility.

 

My case was unfortunately the former with 896 physical cores (rest seem to be HW fused most likely due to defects). So, modding and flashing vbios did not unlock anything extra. Windows will boot with the modded vbios and work fine though. The reason I wanted to mention it here is because macOS did NOT boot with modded vbios and hung in stage1 boot. It was not until I restored the original vbios macOS booted. Just putting here for the record for future reference in case someone else goes through this experience themselves.

 

For additional reading, here's the thread for shader unlock: Unlock the shaders - AMD Radeon RX 560D | TechPowerUp Forums

 

WARINING: Do NOT attempt any of this if you don't know what you are doing and can't afford a bricked system. 

[deeveedee]

5 hours ago, ird said:

Explanation:

• ig-platform-id: corresponds to headless FB for CFL
• slot-name: enables the Activity monitor tab
• enable-metal: because RX560X supports Metal2 only (there seems to be some confusion on this with respect to Polaris family in general on 2 vs 3), force enabling metal on iGPU makes the headless device available for compute tasks in addition to video in apps like GB6 etc

 

This is good stuff.  I don't know much about dGPUs in macOS, so I'm learning.  On my hack, macOS Sonoma 14.5 System Info reports the RX 560x as Metal 3.  What should I use to confirm the actual Metal x support (if it's actually Metal 2)?

Spoiler

 

[ird]

1 hour ago, deeveedee said:

 

This is good stuff.  I don't know much about dGPUs in macOS, so I'm learning.  On my hack, macOS Sonoma 14.5 System Info reports the RX 560x as Metal 3.  What should I use to confirm the actual Metal x support (if it's actually Metal 2)?

  Hide contents

 

I wish I had a good answer for you, but the internet is all over the place and that's the confusion. Apple's own website says Metal 3 is only supported with iMac20,1 and newer (which should point to RX5000 and beyond dGPUs) and MacMini8,1/iMac 2017 (both of which use UHD630). They used to mention by GPU as I remember but don't anymore (see here: Support for Metal on Mac, iPad, and iPhone - Apple Support). Also their developer guide specifically excludes RX400/500 for Metal 3. See here: Metal Feature Set Tables (apple.com).

 

Now, searching on the internet will tell you that AMD Polaris family (RX400/500) and Vega does not support Metal 3 as well. However, Apple's own System Information seems to contradict their website by showing it supports Metal 3. I would think we can write some quick code for Metal query to ascertain. Perhaps some tool out there exists, need to search.

 

Meanwhile, here's some more literature on the topic: OC-Little-Translated/11_Graphics/Metal_3 at main · 5T33Z0/OC-Little-Translated (github.com)

 

EDIT1: Corrected links.

 

EDIT2: I also just learned that the GPU tab can be force enabled with this command. I've updated the original post as well.

 

defaults write com.apple.ActivityMonitor ShowGPUTab -bool true

 

EDIT3: And here's yet another source from Apple that excludes Polaris family: Metal Overview - Apple Developer Scroll down all the way to bottom see this:

 

 

Edited July 21 by ird

[deeveedee]

@ird I started reviewing the OC-Little reference, but found discrepancies between its derivation of AAPL,slot-name and the method recommended by Dortania (which I used).  I think it's cosmetic anyway, so I'm inclined to leave it alone.  This is a complicated subject, so I'm sure there are as many opinions and recommendations as there are documents (just like we're seeing with DMAR modifications).  

 

Keep up the good work.  This thread is becoming another good reference (and a source for still more and different opinions).

[ird]

7 hours ago, deeveedee said:

@ird I started reviewing the OC-Little reference, but found discrepancies between its derivation of AAPL,slot-name and the method recommended by Dortania (which I used).  I think it's cosmetic anyway, so I'm inclined to leave it alone.  This is a complicated subject, so I'm sure there are as many opinions and recommendations as there are documents (just like we're seeing with DMAR modifications).  

 

Keep up the good work.  This thread is becoming another good reference (and a source for still more and different opinions).

 

Agreed, lots of views and perspectives there. But I guess that's the beauty of community. We get to listen, see the big picture and experiment with our setup and ultimately get to choose what works best for us. That's the power of not having black boxes. I've definitely learned a lot over the past several weeks. Hackintosh community has changed drastically (in a good way) since the last time I was active. I'm glad to see a plethora of tools to make repetitive tasks easier now.

 

Back to the topic, the Polaris Metal 2 vs 3 only gets murky. What I thought was an anomaly with G4 RX560Xs showing Metal 3 support turned out to be not true. See here for an actual Macbook Pro (scroll down to the bottom of the page for System Information screenshot): Play Windows games in Parallels Desktop for Mac 

 

It shows the same - RX560X Metal 3 support. Whereas if you search for SysInfo screenshots of any other Polaris cards - RX570/X, RX580/X etc. all show just Metal 2 support though they are from the exact same family. I'm scratching my head for sure on this topic...

[deeveedee]

@ird I got a little distracted  but I'm back.  I, too, have seen conflicting reports about RX 560x  Metal 2 / 3, but I'm inclined to agree with your original assessment about RX 560x being limited to Metal 2.  To be honest, I'm not as concerned about whether it is Metal 2 or Metal 3 as I am about support for my apps and use cases.  I am very happy with this hack, so I don't have any remaining issues to diagnose / resolve at this time.  I am sure that if my use cases had dependencies on DRM or advanced graphics acceleration, I would have more work to do.  My hope is that, now that the black screen problem is solved, others will be able to extend this solution beyond me. 

 

Based on my own testing and extended use of this hack, I am still of the opinion that my dGPU and iGPU are working well with SMBIOS macMini8,1 and non-headless (headed? headful?) framebuffer.   My dGPU is fully accelerating all displays, even iGPU-connected displays that are not directly connected to the dGPU.  The reason I didn't purchase one of these Radeon-equipped Mini's before was my perception that dGPU graphics acceleration was limited to the single dGPU-connected DP port.  For my uses and to leverage the older displays that I already own, a multi-display configuration is a must. This hack does not disappoint.

Edited July 22 by deeveedee

[deeveedee]

For those who are interested, I answered a question about installing Intel Bluetooth for our HackMini8,1 running macOS Sonoma.  My answer is here.

[miliuco]

@deeveedee

I remember that RX 580 are Metal 2 so I'm pretty sure that RX 560 is Metal 2 too.

[deeveedee]

For those who may still be trying to figure out why the black screen issue with this RX 560x is fixed by manually overriding WhateverGreen's handling of CFG_FB_LIMIT, I have a wrinkle to introduce into the conversation:  the black screen issue can also be "fixed" by setting CFG,CFG_FB_LIMIT = 2.  

 

Recall that this RX 560x has a single DisplayPort on connector RadeonFramebuffer@0, so the default behavior of WhateverGreen is to automatically set CFG_FB_LIMIT=1.  When WhateverGreen is permitted to automatically set CFG_FB_LIMIT=1, this RX 560x boots to black screen.

 

The result of setting CFG,CFG_FB_LIMIT=2 is as expected: IOReg lists 2 RadeonFramebuffers (instead of the default  6 RadeonFramebuffers when CFG_FB_LIMIT=0)

 

IOReg with CFG,CFG_FB_LIMIT=2 (no black screen)

Spoiler

 

 

EDIT: When CFG,CFG_FB_LIMIT = 0 (overriding WhateverGreen's automatic behavior and causing WhateverGreen to set CFG_FB_LIMIT=0), IOReg lists 6 RadeonFramebuffers (and no black screen).  Note that CFG_FB_LIMIT = 0 is the default value for this RX 560x when WhateverGreen does not set CFG_FB_LIMIT.

 

IOReg with CFG,CFG_FB_LIMIT=0 (no black screen)

Spoiler

 

EDIT2: When WhateverGreen is allowed to automatically set CFG_FB_LIMIT=1 (overriding the default value CFG_FB_LIMIT=0) or CFG,CFG_FB_LIMIT is manually set to 1 (causing WhateverGreen to set CFG_FB_LIMIT=1), IOReg lists only 1 RadeonFramebuffer@0 and this RX 560x boots to black screen (even though this RX 560x has only a single DisplayPort on connector RadeonFramebuffer@0).

 

IOReg when allowing WhateverGreen to automatically set CFG_FB_LIMIT=1 or when manually setting CFG,CFG_FB_LIMIT=1  (black screen)

Spoiler

 

Edited July 27 by deeveedee

[deeveedee]

Could this explain the behavior of our RX 560x Mobile dGPU (explain the headful/headed behavior and the strange WhateverGreen behavior)?  According to TechPowerUp, the RX 560x Mobile GPU (the GPU in our HP EliteDesk 800 dGPU card) is designed for laptop use, so it is not designed for direct display connectivity:

 

This device has no display connectivity, as it is not designed to have monitors connected to it. Rather it is intended for use in laptop/notebooks and will use the output of the host mobile device. Radeon RX 560X Mobile is connected to the rest of the system using a PCI-Express 3.0 x16 interface.

 

This would explain why I am observing dGPU acceleration on the iGPU-connected Display Ports.  This might also explain why WhateverGreen's default CFG_FB_LIMIT behavior does not work with this dGPU.

[ird]

On 7/28/2024 at 2:28 PM, deeveedee said:

Could this explain the behavior of our RX 560x Mobile dGPU (explain the headful/headed behavior and the strange WhateverGreen behavior)?  According to TechPowerUp, the RX 560x Mobile GPU (the GPU in our HP EliteDesk 800 dGPU card) is designed for laptop use, so it is not designed for direct display connectivity:

 

This device has no display connectivity, as it is not designed to have monitors connected to it. Rather it is intended for use in laptop/notebooks and will use the output of the host mobile device. Radeon RX 560X Mobile is connected to the rest of the system using a PCI-Express 3.0 x16 interface.

 

This would explain why I am observing dGPU acceleration on the iGPU-connected Display Ports.  This might also explain why WhateverGreen's default CFG_FB_LIMIT behavior does not work with this dGPU.

 

This is an interesting observation. This could be a possibility. When you say your iGPU connected DPs are accelerated, do you know what GPU provides the acceleration? I'm not sure if there is a utility similar to RivaTuner Stats+MSI Afterburner for macOS (probably isn't) but if there's a way to see that information as an overlay confirming the GPU that'd resolve confusion.

 

One thing I'm not sure of is if the RX560X in the HP Minis is a true mobile version. I say that because GPU-Z dump of the GPU in my machine shows it as Polaris21 (vs. Polaris31 from the link above). I also confirmed this by flashing the modded VBIOS. At least one person from the thread that I attached elsewhere about unlocking RX560X shaders claims to have unlocked the full 1024 shader set, which probably makes this chip a Polaris21 XL/XL also sometimes known by the codename Baffin. I suspect the dies to be one of these:

 

1) AMD Radeon RX 560 Mobile Specs | TechPowerUp GPU Database

2) HP RX 560X Mobile Specs | TechPowerUp GPU Database

 

What you mention of GPUs lacking display engine sometimes happens for 3D-only accelerators (used to be a lot more common in the older days though - 3Dfx Voodoo, that needed a separate 2D card for displays). Today, the only reason this happens in laptops (and typically the display engine is just fused off in firmware and not physically removed from the die) is because they have a fixed set of port and in a multi GPU case (iGPU and dGPU), the ports mux the right GPU to the internally or externally attached screen.

 

In this case die is actually the same as desktop one as AMD supposedly never produced a "mobile-only-560" (unlike RX6500/6400/6300 that lacked video engines). What differentiates the mobile parts from the desktop ones are power budgets (35-55W), form factor (MXM vs PCIe vs the proprietary connector HP uses for Minis), lower base and boost GPU clocks and memory clocks (12xx vs 1070Mhz and 1750 vs 1500Mhz for mem) and in some cases a lower shader count (896 vs 1024).

 

What's for certain is that HP has a unique VBIOS for this card and it doesn't use the generic one from AMD. While I was experimenting with shader unlock and undervolting (both of which were unsuccessful), I saw that several entries in the BIOS like fan curves etc. are zeroed out and HP probably built that in the system bios itself. So, the reason for FB connector # and type mismatch might also stem from there. WEG might be failing to read proper values off the VBIOS.

 

I wanted to dig in more but work has been keeping me extremely busy and will continue to for quite some time. If you or anyone is interested in digging more from where I stopped, I'll attach the relevant files I have.

 

1. Screenshot of GPU-Z for die, speeds and feeds, BIOS versions
2. Original dump of HP RX560X VBIOS (RX560X_896SP_Polaris21_OG.rom)
3. Decoded sections of the VBIOS binary (RX560X_896SP_Polaris21_OG.rom.txt)
4. ATI flash 2.93 utility that can be used to flash or extract VBIOS: Version 2.93 NOTE: on the left side at the end of existing links click "Show Older Versions" to download version 2.93. Only this version is known to work reliably with our RX560X.
5. UPP Utility that I used to decode VBIOS section headers (don't need it, but just for reference): Link
6. Polaris BIOS editor (will let you examine clocks/voltages and other VBIOS sections): Link

 

EDIT1: Forgot to mention that the proprietary PCIe connector HP uses to connect the dGPU for data and power is only PCIe 3.0 @ 8x (not 16x).

 

RX560X_896SP_Polaris21_OG.rom RX560X_896SP_Polaris21_OG.rom.txt

Edited July 29 by ird

[deeveedee]

@ird Good stuff.  This is one case where your in-depth knowledge of AMD GPUs is going to shed light on my observations.  I'm not sure how to answer your question " do you know what GPU provides the acceleration?" since when I move benchmarks like Imagine Valley and GFXMetal to an iGPU-connected display, the benchmarks run at Radeon RX 560x frame rates (displaying Radeon accelerated quality graphics).   The same benchmarks are pathetically slow on a UHD630-only hack.  I don't really need a tool to measure what's easily observed.  Maybe I'm using the wrong terminology when I say "dGPU-Accelerated?"  If there is a better way for me to say that the Radeon dGPU is accelerating graphics on my iGPU-connected displays, let me know.

 

As far as the Polaris 21 vs 31 is concerned, if that is actually the case, then our RX 560x is not a mobile variant and I would be incorrect with my guess that our RX 560 card uses a mobile dGPU.  I think I could easily answer this by removing the heatsink and examining the GPU.  I may have to do that.

 

EDIT: @ird Do you have any way to test with multiple displays (or maybe test with a single display that is connected to one of the iGPU-connected Display Ports)?  With your knowledge and experience, you'd be able to see for yourself much easier than me.

 

EDIT2: @ird I almost forgot - I do have tests with conclusive evidence about which GPU provides the acceleration.  Review these test results.

Edited July 30 by deeveedee

[ird]

1 hour ago, deeveedee said:

@ird Good stuff.  This is one case where your in-depth knowledge of AMD GPUs is going to shed light on my observations.  I'm not sure how to answer your question " do you know what GPU provides the acceleration?" since when I move benchmarks like Imagine Valley and GFXMetal to an iGPU-connected display, the benchmarks run at Radeon RX 560x frame rates (displaying Radeon accelerated quality graphics).   The same benchmarks are pathetically slow on a UHD630-only hack.  I don't really need a tool to measure what's easily observed.  Maybe I'm using the wrong terminology when I say "dGPU-Accelerated?"  If there is a better way for me to say that the Radeon dGPU is accelerating graphics on my iGPU-connected displays, let me know.

 

As far as the Polaris 21 vs 31 is concerned, if that is actually the case, then our RX 560x is not a mobile variant and I would be incorrect with my guess that our RX 560 card uses a mobile dGPU.  I think I could easily answer this by removing the heatsink and examining the GPU.  I may have to do that.

 

EDIT: @ird Do you have any way to test with multiple displays (or maybe test with a single display that is connected to one of the iGPU-connected Display Ports)?  With your knowledge and experience, you'd be able to see for yourself much easier than me.

 

EDIT2: @ird I almost forgot - I do have tests with conclusive evidence about which GPU provides the acceleration.  Review these test results.

 

Sorry I missed the Unigine valley comments before. Yes, that is conclusive enough to determine what GPU it's rendered on. I realized I did not use the right words to describe my question, sorry about that. What I was supposed to ask is if there are apps to show which GPU is the display being composed on.

 

For reference, "compose"/composition means blending multiple framebuffers to display the final one. i.e., you may have several windows, menu bar, dock etc. each being rendered on the same or different GPU. In the end, a final display pass merges them before being displayed on the screen. What you saw with Unigine confirms that the DP connected to iGPU is compositing work done on dGPU. However, it does not prove* that the vice versa is not true i.e., iGPU rendered framebuffer can be "composed" on dGPU display engine.

 

One test might be to completely, disable iGPU in the BIOS (if HP even allows that). If that is possible and only the dGPU DP works, then it might point to each GPU having a display engine but also being capable of composing content rendered on other GPU before presenting to the user. I don't think this will say for sure but it's another data point that brings us one step closer in identifying the composition.

 

I'm not near my computer now but I remember the HP BIOS showed the presence of AMD GOP (graphics output protocol) on some settings page. If that is true, then that points to a working display engine on the dGPU. GOP is a "built in driver for BIOS" to display framebuffer without actual drivers (as none can be loaded when computer boots up). If interested, read more about GOP here, here and here.

 

EDIT1: Fixed some typos

Edited July 30 by ird

[deeveedee]

@ird I think it would be best for me to leave further iGPU / dGPU testing to others who are more experienced with Radeon dGPUs.  With my limited dGPU knowledge, I'm going to have a difficult time convincing others who are more experienced to change dGPU/iGPU paradigms that require a headless iGPU when using Radeon dGPU.  Hopefully others can test the multi-display solution described in this thread.

 

Also, upgrading this hack from Sonoma 14.5 -> 14.6 was easy via OTA.  

Spoiler

 

[deeveedee]

I have attached a new OC 1.0.1 EFI to Post #1.  In addition to being upgraded to Open Core 1.0.1, this new EFI incorporates the changes discussed in this thread for my multi-display solution using SMBIOS model macMini8,1.  These changes from my originally posted OC 1.0.0 EFI include the following:

 

EFI-MM81-RX560x-OC101-01

• BOOT
  • Updated BOOTx64.efi for OC 1.0.1
• OC
  • Updated OpenCore.efi for OC 1.0.1
  • Updated Drivers/*.* for OC 1.0.1 (except HfsPlus.efi)
  • Updated Tools/*.* for OC 1.0.1
  • Updated OC/Kexts
    • AppleALC.kext 1.9.1 Beta -> 1.9.1 Release
    • Lilu.kext 1.6.8 Beta -> 1.6.8 Release
    • RestrictEvents.kext 1.1.4 Beta -> 1.1.4 Release
    • VirtualSMC.kext 1.3.2 -> 1.3.3
      • SMCProcessor.kext 1.3.2 -> 1.3.3
      • SMCSuperIO.kext 1.3.2 -> 1.3.3
    • WhateverGreen.kext 1.6.7 Beta -> 1.6.7 Release
  • ACPI
    • Removed SSDT-GFX0 (connectors patch is not needed)
    • Renamed SSDT-GFX0-Off to SSDT-PEGP-Off (not manually renaming PEGP->GFX0)
    • SSDT-PEGP-Off: Change GFX0 -> PEGP and IGPU -> GFX0
    • Remove DMAR (modified DMAR is not needed to enable VT-d with macOS on this hack)
  • config.plist
    • ACPI > Patch
      • Remove GFX0->IGPU and PEGP->GFX0 renames
      • Added Base, Count, OemTableId, and/or TableSignature as needed to restrict ACPI patches
      • Added Find/Replace byte to _PTS -> XPTS patch to fix incorrect ACPI rename in DSDT
    • ACPI > Add
      • Remove SSDT-GFX0
      • Rename SSDT-GFX0-Off to SSDT-PEGP-Off
    • ACPI > Delete
      • Remove DMAR (no longer dropping and replacing DMAR table)
    • DeviceProperties > Add > PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
      • CFG,CFG_FB_LIMIT = 2 (fixes RX 560x blackscreen)
    • NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args
      • -igfxonlnfbs=0x0102 (restricts igfxonln=1 to connector indices 1 and 2)

 

In OC config.plist, Misc>Security>SecureBootModel = Disabled to allow installation / upgrade of Sonoma and Sequoia.  After installing / upgrading Sonoma or Sequoia and If desired, change SecureBootModel based on the guidance here.

[ird]

15 hours ago, deeveedee said:

I have attached a new OC 1.0.1 EFI to Post #1.  In addition to being upgraded to Open Core 1.0.1, this new EFI incorporates the changes discussed in this thread for my multi-display solution using SMBIOS model macMini8,1.  These changes from my originally posted OC 1.0.0 EFI include the following:

 

EFI-MM81-RX560x-OC101-01

• BOOT
  • Updated BOOTx64.efi for OC 1.0.1
• OC
  • Updated OpenCore.efi for OC 1.0.1
  • Updated Drivers/*.* for OC 1.0.1 (except HfsPlus.efi)
  • Updated Tools/*.* for OC 1.0.1
  • Updated OC/Kexts
    • AppleALC.kext 1.9.1 Beta -> 1.9.1 Release
    • Lilu.kext 1.6.8 Beta -> 1.6.8 Release
    • RestrictEvents.kext 1.1.4 Beta -> 1.1.4 Release
    • VirtualSMC.kext 1.3.2 -> 1.3.3
      • SMCProcessor.kext 1.3.2 -> 1.3.3
      • SMCSuperIO.kext 1.3.2 -> 1.3.3
    • WhateverGreen.kext 1.6.7 Beta -> 1.6.7 Release
  • ACPI
    • Removed SSDT-GFX0 (connectors patch is not needed)
    • Renamed SSDT-GFX0-Off to SSDT-PEGP-Off (not manually renaming PEGP->GFX0)
    • SSDT-PEGP-Off: Change GFX0 -> PEGP and IGPU -> GFX0
    • Remove DMAR (modified DMAR is not needed to enable VT-d with macOS on this hack)
  • config.plist
    • ACPI > Patch
      • Remove GFX0->IGPU and PEGP->GFX0 renames
      • Added Base, Count, OemTableId, and/or TableSignature as needed to restrict ACPI patches
      • Added Find/Replace byte to _PTS -> XPTS patch to fix incorrect ACPI rename in DSDT
    • ACPI > Add
      • Remove SSDT-GFX0
      • Rename SSDT-GFX0-Off to SSDT-PEGP-Off
    • ACPI > Delete
      • Remove DMAR (no longer dropping and replacing DMAR table)
    • DeviceProperties > Add > PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
      • CFG,CFG_FB_LIMIT = 2 (fixes RX 560x blackscreen)
    • NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args
      • -igfxonlnfbs=0x0102 (restricts igfxonln=1 to connector indices 1 and 2)

 

In OC config.plist, Misc>Security>SecureBootModel = Disabled to allow installation / upgrade of Sonoma and Sequoia.  After installing / upgrading Sonoma or Sequoia and If desired, change SecureBootModel based on the guidance here.

 

Amazing work, as always, @deeveedee! I have a suggestion. When you update the EFI links in the first post, it would be great to also add a link to this quoted post that has the changelog so that folks can easily jump to the right one to see what's included/changes etc.

[deeveedee]

@ird I maintain the change log here.  I think I already have the link that you requested, but if not, then I don't understand your request.  Please let me know.

[deeveedee]

This may be fixed in Sequoia Beta 6.  Leaving this post and continuing to monitor EFI access with Sequoia Beta.

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

Changes in Sequoia Beta 5 require us to access the fixed disk EFI differently as mentioned here and other posts.  I prefer not to switch-user to root, so my recommended commands are slightly different:

1. diskutil list
2. note EFI partition identifier in step 1 (e.g., disk0s1)
3. sudo mkdir /Volumes/EFI
4. sudo mount -t msdos /dev/disk0s1 /Volumes/EFI
   *** replace disk0s1 with the partition identifier that you observed in Step 2

 

Unmount EFI as before with

• sudo diskutil umount disk0s1
  *** replace disk0s1 with the partition identifier that you observed in Step 2

Edited August 12 by deeveedee