Big Sur on HP EliteDesk 800 G4/G5 Mini - The Perfect MacMini8,1 Hackintosh - OpenCore

[rafale77]

Comparing the desktop and laptop framebuffers, I was also wondering why you rolled the ports [1,2,3] to index [0,1,2] as opposed [1,2,0]. I just tested it and it seems to work fine and appears to correspond better I have yet to find any downside of it.

Edit:
The framebuffer 3E9B0000 appears to be used by the macbook pro 15,1 which includes a 9th gen HD630 while the desktop version 3E9B0007 is used by the macmini8,1. Not sure what model uses the 3E920000.

See my latest patch with everything moved into the device properties and out of the boot-args, note that I am only changing the index of one port:

 

[deeveedee]

Comparing the desktop and laptop framebuffers, I was also wondering why you rolled the ports [1,2,3] to index [0,1,2] as opposed [1,2,0]. I just tested it and it seems to work fine and appears to correspond better I have yet to find any downside of it.

Why would I have tested that index combination after finding a working combination? And how does it "correspond better?" See my experimentation here and here. You could also argue that I should have tested 1,0,2; I simply stopped testing after finding indices that worked. It never occurred to me to keep testing, as I felt fortunate to have stumbled upon a working combination of indices, BusIDs, flags, etc. When I was first patching UHD630 framebuffers in May 2020, the guides (here and in "the other forum") claimed that video adapters (e.g. DP->DVI) would not work with UHD 630 patching and that we must use DP->DP, HDMI->HDMI cables. You can still see remnants of these claims here. I was simultaneously experimenting with different values for AAPL,ig-platform-id, Bus IDs, Flags, Indices to prove that video converters/adapters were possible with UHD630 patching (and got lucky to find a combination). Now that everyone knows we can use video converters/adapters, I'm sure there will be other combinations that work.

Note that I exhaustively tested all framebuffers here only because I was in the process of finding a working combination of properties with DP->DVI adapters. At the same time, I was trying to solve UHD630 sleep/wake (which I solved here). I was also trying to solve kernel panic on wake which I solved by using no-hda-gfx as documented here.

I was doing things with DP->DVI that I couldn't find documented anywhere. When it worked, I stopped.

EDIT: It just occurred to me that I was also trying to solve the "multi-display" problem at the same time. When I originally started patching, only one display would work on the HP EliteDesk 800 G4 Mini. I found shuhung's explanation here which lead me to add boot-arg igfxagdc=0 (which we now all use for our HackMini8,1 - most of us without understanding why we use it).

There were lot's of variables that I was changing simultaneously to find a working solution. Fortunately, now that the basics are proven and working, it is easy for others to build on what's been started. It would probably be helpful to review my Known Issues here and my methodology here to see just how many problems needed to be solved to produce the working HackMini8,1.

 

[rafale77]

Why would I have tested that index combination after finding a working combination? And how does it "correspond better?" See my experimentation here and here. You could also argue that I should have tested 1,0,2; I simply stopped testing after finding indices that worked. It never occurred to me to keep testing, as I felt fortunate to have stumbled upon a working combination of indices, BusIDs, flags, etc. When I was first patching UHD630 framebuffers in May 2020, the guides (here and in "the other forum") claimed that video adapters (e.g. DP->DVI) would not work with UHD 630 patching and that we must use DP->DP, HDMI->HDMI cables. You can still see remnants of these claims here. I was simultaneously experimenting with different values for AAPL,ig-platform-id, Bus IDs, Flags, Indices to prove that video converters/adapters were possible with UHD630 patching (and got lucky to find a combination). Now that everyone knows we can use video converters/adapters, I'm sure there will be other combinations that work.

Note that I exhaustively tested all framebuffers here only because I was in the process of finding a working combination of properties with DP->DVI adapters. At the same time, I was trying to solve UHD630 sleep/wake (which I solved here). I was also trying to solve kernel panic on wake which I solved by using no-hda-gfx as documented here.

I was doing things with DP->DVI that I couldn't find documented anywhere. When it worked, I stopped.

It seems to correspond better because of the comparison between the comparison between the two framebuffers (macmini8,1 and macbookpro15,1) information on hackintool indicates that ports 1 and 2 are identical and that port 3 (DP) on the desktop is changed to port 0 LVDM on the laptop (from the busid). It seems to indicate that only that one port needs to be custom patched. Port3 on our machine is also the one which is customizable so it makes a lot of sense to patch that one port anyway.
Sorry I didn't mean to be annoying. You did a ton of work. I am trying to optimize and reduce the amount of patching and obviously learning in the process. Just tinkering here...

 

[deeveedee]

@rafale77 Not sure I'm following. My testing revealed the video port/connector mapping documented here.

 

[rafale77]

@rafale77 Not sure I'm following. My testing revealed the video port/connector mapping documented here.

My testing showed something a bit different.
The conX number is up for us to assign as it is associated with how the iGPU deals with it.
From left to write on your port mapping, we have ports 1,2,3.

If you use the desktop framebuffer 3E9B0007, then
port1 (DP) -> con1
port2 (DP) -> con2
port3 (DP) -> con3
And this works without any custom port patching as long as connections are all indeed DP, meaning no adaptor used.

The way I have mine setup with the laptop framebuffer 3E9B0000 as per the config above (I found to be the same for 3E920000), I have
port1 -> con1 (DP ->customized as HDMI)
port2 -> con2 (DP -> custom patched as HDMI)
port3 -> con0 (LVDS -> custom patched as HDMI)
I didn't need to renumber ports 1 and 2. With this the adapters now work properly. Port 3 is the one which I suspect most often requires patching because some people may have a DVI, VGA or an HDMI port instead of a DP port. One of my machines came with a VGA port. Comparing the two framebuffers above I noticed that the pipe and busID of the desktop con3 are the same as the laptop con0. That's why I though about only patching that one port.

To illustrate this, my monitor currently plugged in to port3 (labeled con2 on your map) shows this:


As I unplug and plug the different ports, then when the monitor is connected to port1 then hackintool shows as index1 (con1) and port2 shows as index2 (con2).

The way yours is setup is:

port1 -> con0 (LVDS -> custom patched as HDMI)
port2 -> con1 (DP -> custom patched as HDMI)
port3 -> con2 (DP ->customized as HDMI)

It appears that the connector is assigned/mapped to physical ports by the property "framebuffer-conx-index = y" patch where x is the framebuffer connector ([0,1,2] or [1,2,3] and y is the physical port index [1,2,3]. If not custom patched, conx=x.

 

[deeveedee]

@rafale77 If that mapping/patching works on your rig, then I'd say congratulations are in order. Nice work.

 

[rafale77]

Thanks @deeveedee but I think the credit is all yours. I have read some of the older posts you linked and I am still blown away by how you came up with the busid patching which makes the video adaptors work. It is so finicky and peculiar... If there is one thing that I learned through my testing yesterday, it is that it shouldn't be taken for granted. It doesn't match any documentation I could find. Heck even doing a permutation on the busid breaks the video adaptor support... fascinating! Port1->busid=1->con1(0), Port2->Busid=2->con2(1), Port3->Busid=4->con0(2)

I honestly was a little bothered by using the mobile framebuffer which gets reported to correspond to an "h" series (i.e. 9880h) CPU and has chances to have differences with the desktop one we have given the chipset and ports but then the macmini (which uses the desktop framebuffer) also never had a 9 series CPU either and that could be an even bigger difference as I learned from linux kernels requiring changes to support the 9 series iGPU.

DRM is really the only thing I can think of which doesn't work on these hacks....

Edit:
Note that the UHD630 device ID from the intel website come as follow:
8th gen desktop CPU: 3E92
9th gen desktop CPU: 3E98
8th and 9th gen mobile CPU: 3E9B

Though the correspondence with the Apple framebuffer are not 1:1, it's hard not to see that there is somewhat of a correspondence between the first 4 bytes of the framebuffer ID and the intel device IDs. I am very curious about all these variations. There seems to be only one framebuffer starting with 3E98 (3E980003) and it has no connector. Maybe it is used on a iMac with dGPU...
So far I have tested
3E920000 mobile (likely 8 series mbp 8750h)
3E9B0000 mobile (likely 9 series mbp 9880h)
3E9B0007 desktop (MacMini 8700B)
3E9B0009 mobile with camellia (likely 9 series)
and @deeveedee's connector patches work on the 3 mobile framebuffers. The desktop one requires no connector patches but also don't work with video adapters. (DP->HDMI in my case)

 

[deeveedee]

@rafale77 You're doing a lot of research. I think it would be good to create a new thread about UHD630 patching, to keep this thread focused on Big Sur on HP EliteDesk 800 G4/G5 Mini.

 

[deeveedee]

I have attached a revised EFI to Post #1. This revised EFI (OC0.7.6-EFI-r002) includes the following change from OC0.7.6-EFI-r001:

• EFI/OC/config.plist: DeviceProperties > PciRoot(0x0)/Pci(0x2,0x0): framebuffer-conX-types are patched as HDMI <00080000> instead of Dual-Link DVI <04000000> to enable DP->DVI adapters in both Monterey and Big Sur.

Test any EFI changes on a USB drive before applying them to your production drive. After making EFI changes, Reset NVRAM before booting macOS.

 

[deeveedee]

On December 17, 2021, HP released a new BIOS update for the EliteDesk 800 G5 Mini.

02.11.00 Rev.A

19.0 MB

Dec 17, 2021

This BIOS update includes new Intel ME Firmware and addresses many security vulnerabilities. I have not yet updated to this new BIOS version, so I have not tested yet with MacOS. If someone does apply this BIOS update, please post your test results. Thank you!