iM 4,1-14,4 EnableGop: Pre-OpenCore GOP support for EFI-era iMacs and Mac Pros

[Bmju]

Wondering if anyone tried to boot the RTX3000 / 4000 series card on the cMP yet?

From memory, there was a firmware compatibility for the 3000 cards. May be this is a work around for the cMP to use these cards in Windows?

I think there were some improvements in Windows booting, in some cases, on iMac (e.g. other additional GOP drivers no longer needed).

The iMac and Mac Pro are very similar in regards to what is needed for GOP support.

I should probably tone down the warnings. Apart from one recalcitrant report of a problem, which then went quiet, it has seemed to work very well in several machines now. So if you would perhaps be able to try it and then report back, please do! The DXEInject insertion method is quite straightforward (thanks to @dosdude1 for leaving that convenient tool around from earlier research).

 

[h9826790]

I think there were some improvements in Windows booting, in some cases, on iMac (e.g. other additional GOP drivers no longer needed).

The iMac and Mac Pro are very similar in regards to what is needed for GOP support.

I should probably tone down the warnings. Apart from one recalcitrant report of a problem, which then went quiet, it has seemed to work very well in several machines now. So if you would perhaps be able to try it and then report back, please do! The DXEInject insertion method is quite straightforward (thanks to @dosdude1 for leaving that convenient tool around from earlier research).

I want to test that, but I don't have the RTX cards. Someone asked me about if possible to use RTX cards on cMP, then I remember this thread.

But I can download DXEInject and test that with my Radeon VII. It seems this card is not on the tested list yet.

 

[joergz]

Very interesting solution. Anybody tried that on a cMP 3,1 yet and/ or knows the result for a GT730?

 

[h9826790]

Just modded a reconstructed 5,1 ROM image by using DXEInject with EnableGopDirect.ffs (my Radeon VII need DirectGopRendering), flashed the cMP, and a success. I can now hold Option key to boot.

So, you may update the "Tested GPU list" with Radeon VII (EnableGopDirect).

 

[Bmju]

Very interesting solution. Anybody tried that on a cMP 3,1 yet and/ or knows the result for a GT730?

I would recommend flashing to VBIOS initially on MP3,1.

I understand that reflashing the main BIOS on MP3,1 if there are any problems, is not easy (older NVRAM chip, hard to source correct flashing h/ware)? And the driver has not been tested on MP3,1. In fact, I would guess it will need additional patches, and probably will just have no effect.

You can however flash to VBIOS to test it, and then you only need a standard SOIC clip + CH341A controller (driven by another machine, or your machine with another GPU) to recover if it hangs (assuming you've pulled off the unmodified VBIOS first).

 

[cdf]

Non of the Macs has a boot screen support for the eGPU. The thing is that I cannot even apply new properties at the end of the thunderbolt hook via SSDT like SSDT-BRG0.aml.

Right. Perhaps Thunderbolt-supporting Macs prevent preboot display from eGPUs, particularly for devices with built-in displays. On the other hand, unsupported platforms might not be able to tell the difference, especially after a warm boot when everything is already setup by the OS. As far as the the firmware (with EnableGop) is concerned, an eGPU is just any other GPU. The anticipated problem is getting such a system to see the eGPU when cold booting, and this apparently comes down to enabling the Thunderbolt controller early enough. Clues for how to do this may very well still be found in existing firmware components of machines with Thunderbolt support.

As for the inability to apply properties (presumably on Thunderbolt-supporting hacks), it may come down, in a similar vein, to the presence of existing (contending) firmware components.

 

[joevt]

Right. Perhaps Thunderbolt-supporting Macs prevent preboot display from eGPUs, particularly for devices with built-in displays.

I think my Mac mini 2018 had egpu boot screen a couple times in the past but not recently. I currently boot from USB. Maybe I need to switch back to booting from internal drive (unlikely).

 

[startergo]

I think my Mac mini 2018 had egpu boot screen a couple times in the past but not recently.

Recently I tried it on that machine and no boot screen either. Maybe the firmware has changed preventing boot screen?

 

[joergz]

I would recommend flashing to VBIOS initially on MP3,1.

I understand that reflashing the main BIOS on MP3,1 if there are any problems, is not easy (older NVRAM chip, hard to source correct flashing h/ware)? And the driver has not been tested on MP3,1. In fact, I would guess it will need additional patches, and probably will just have no effect.

You can however flash to VBIOS to test it, and then you only need a standard SOIC clip + CH341A controller (driven by another machine, or your machine with another GPU) to recover if it hangs (assuming you've pulled off the unmodified VBIOS first).

Thanks for the advice. I'm somehow inclined to update the MP3,1 rom because I had great results with adding NVMe and AFPS drivers in the past. I understand the GOP driver might be more risky though. The EnableGop.ffs is not yet available compiled somewhere and I need to wait for the 0.8.9 release?

 

[Bmju]

Thanks for the advice. I'm somehow inclined to update the MP3,1 rom because I had great results with adding NVMe and AFPS drivers in the past. I understand the GOP driver might be more risky though. The EnableGop.ffs is not yet available compiled somewhere and I need to wait for the 0.8.9 release?

As discussed above, the compiled files are available now: https://forums.macrumors.com/thread...-era-imacs-and-mac-pros.2378942/post-31924781

There is genuinely a possibility of bricking your MP3,1, I really do not know - it simply has not been tried on MP3,1 at all, yet. However, burning to the VBIOS first should confirm almost certainly whether or not you will get a brick in main firmware, if it does not brick in VBIOS, it is very unlikely to brick the main firmware.

If you are using an Nvidia card, the steps for burning to VBIOS are actually not that hard either, the provided script should work. If you are entirely comfortable re-flashing a non-bootable main board, then of course go ahead with that. I would very much like to know the results of all this - but I do not want your machine to become unusable for you!

 

[Macschrauber]

injected enablegop.ffs into my 4.1 test rig with rebuilt 144 firmware and can report success with

Nvidia Quadro K2000 (unchanged)
Nvidia Quadro K2000d (unchanged)
Nvidia Quadro K600 (with GOP addition in GPU Bios)
Nvidia Quadro 410 (with GOP addition in GPU Bios)
GT640 1GB
AMD RX560 V1 (unchanged)
Sapphire RX580 Pulse

with the RX560 I booted El Capitan natively and got framebuffer graphics

 

[Macschrauber]

I wonder when I add the "enable gop addition" to the VGA bios if the GPU will lose its secure boot validation and if yes: will that affect Uefi Windows booting?

 

[h9826790]

I wonder when I add the "enable gop addition" to the VGA bios if the GPU will lose its secure boot validation and if yes: will that affect Uefi Windows booting?

I tested to boot UEFI Windows, no problem. Of course, I did that via OpenCore to avoid MS cert writing into the cMP's BootROM.

 

[Macschrauber]

I tested to boot UEFI Windows, no problem. Of course, I did that via OpenCore to avoid MS cert writing into the cMP's BootROM.

was that with modding the Mac firmware or the GPU firmware?

 

[h9826790]

was that with modding the Mac firmware or the GPU firmware?

Modded Mac firmware.

I also disabled the OpenCore ProvideConsoleGop and DirectGopRendering to make sure my cMP did actually load EnableGopDirect (I can still see the boot screen), and then select UEFI Windows 11 in the OC boot picker.

 

[h9826790]

Some more sharing about "what will happen". Since my Radeon VII need DirectGopRendering, I only tested EnableGopDirect.ffs, but haven't inject the EnableGop.ffs.

The boot screen works, but with some artefacts. e.g. When moving the mouse pointer, there is a little back square follow the mouse pointer. The boot picker still usable, but not as nice as using ProvideConsoleGop and DirectGopRendering in OpenCore (which feels completely smooth with my Radeon VII).

But the good news is that users can treat this EnableGopDirect (cMP firmware level) as the emergency function. And still enable OpenCore ProvideConsoleGop and DirectGopRendering. In this case, the user can still enjoy a nice and smooth OpenCore boot picker, but have the native boot screen ability as backup.

Regardless the cMP's bootROM is modded or not, OpenCore can still take over the GOP part, and provide a nice and smooth boot picker.

 

[Bmju]

@h9826790 ProvideConsoleGop in OC will do nothing if there is already a console gop, e.g. as provided by EnableGopDirect.ffs. You are correct that DirectGopRendering will still do something - though I'd expect it to just reinstall the same feature, and _look_ no different.

So I'm surprised you're seeing the native menu look different with the driver. Have you tried BootKicker.efi, from the latest, not yet released OpenCore? My prediction would be you will see the same artefacts - whether or not you have EnableGopDirect.ffs in your firmware. (Which is to suggest that the interaction here, causing the cursor trail, is actually some incompatibility between the native picker (but not the different OC picker) and the GOP on your card.)

Also my prediction (and intention with the driver) would be that, once the driver is installed in firmware, the two relevant OC settings ProvideConsoleGop and DirectGopRendering, set or not set, should make no difference to a) how OpenCore looks, b) whether EnableGopDirect.ffs gets loaded (it will just load, before OC even starts), and c) whether or not Windows loads, and how it looks. Which is to say, no, it is not the intention that OC 'takes over the GOP part once it loads', rather the GOP part has already been provided (by actual OC code, but running earlier), so OC will use that.

EDIT: The above is not completely correct. ProvideConsoleGop will, indeed, detect that it is already installed and do nothing, if EnableGop or EnableGopDirect is installed. However, DirectGopRendering will provide direct GOP rendering a second time, if EnableGopDirect is installed and already providing it. This second version does not produce any visible difference on most systems - but with the weird caching behaviour of the Radeon VII, it is possible that one implementation works completely and the other shows caching effects (mouse trails).

 

[h9826790]

@h9826790 ProvideConsoleGop in OC will do nothing if there is already a console gop, e.g. as provided by EnableGopDirect.ffs. You are correct that DirectGopRendering will still do something - though I'd expect it to just reinstall the same feature, and _look_ no different.

That's my expectation as well. That's why I gave it a test, and report back this unexpected result.

Anyway, further tests confirm that ProvideConsoleGop has no effect now, but the difference is comming from DirectGopRendering

My OpenCore is the current 0.8.8 release version. And the EnableGopDirect.ffs was extracted from the artifacts 0.8.9 release utilites folder. May be this is the difference coming from. And once I update to 0.8.9, I will see the same artefacts regardless I turn on DirectGopRendering or not.

@h9826790Have you tried BootKicker.efi, from the latest, not yet released OpenCore? My prediction would be you will see the same artefacts - whether or not you have EnableGopDirect.ffs in your firmware. (Which is to suggest that the interaction here, causing the cursor trail, is actually some incompatibility between the native picker (but not the different OC picker) and the GOP on your card.)

I haven't try the BootKicker, because I have the Sonnet TempoSSD installed. Whenever there is a boot drive installed onto this card, the native Apple boot manage won't work (the cMP will still shows the light grey screen, but nothing for the users to choose). Interestingly, this bug only exist with the 5,1 firmware, but not the 4,1 firmware. Sonnet know this, but they never fix it. Therefore, if I need to test BootKicer, I have to re-connect all the boot drives, which is what I tends to avoid if not really neccessary to do.

Anyway, when I did the "native boot screen test" by holding option to boot, I did re-connect all the drives to make sure it's really working, and the native boot manager works with artefacts

If I select OpenCore from the native boot manager, the same artefacts will carry to the OpenCanopy Boot Picker. Then the loading screen will only has the loading bar (please ignore the dust), but missing the Apple (most likely it's there if I can move the mouse to "re-paint" that area, which I can't do because no mouse pointer movement at that stage).

But if I turn on DirectGopRendering in OpenCore, and let OpenCanopy load automatically, then all artefacts are gone, and I can see the Apple in early loading phase.

TBH, this is not logical to me.

My understanding is, no matter I bless OpenCore to make it load automatically, or select that via the Apple boot manager. The sequence still the same. Mac power up -> EnableGopDirect.ffs loads -> OpenCore loads -> DirectGopRendering replace the already working EnableGopDirect.ffs.

But now, the actual outcome

1) Let the Mac auto boot to OpenCore boot picker -> no artefacts

2) Select OpenCore from the Apple boot manager -> have artefacts

Anyway, I will say this is still a huge step forward. The native Apple boot manager is completely usable. Even with artefacts, it is still good enough to server as an extremely useful emergency rescure tool. If you want me to carry out any other test to collect whatever info you want, please let me know. I will try my best to help.

 

[joergz]

As discussed above, the compiled files are available now: https://forums.macrumors.com/thread...-era-imacs-and-mac-pros.2378942/post-31924781

There is genuinely a possibility of bricking your MP3,1, I really do not know - it simply has not been tried on MP3,1 at all, yet. However, burning to the VBIOS first should confirm almost certainly whether or not you will get a brick in main firmware, if it does not brick in VBIOS, it is very unlikely to brick the main firmware.

If you are using an Nvidia card, the steps for burning to VBIOS are actually not that hard either, the provided script should work. If you are entirely comfortable re-flashing a non-bootable main board, then of course go ahead with that. I would very much like to know the results of all this - but I do not want your machine to become unusable for you!

Thanks again. I guess I will try the VBIOS approach first then. Since I'm not very familiar with Hex editors, would that be the correct command based on my screenshot from the original VBIOS of my card?

./NvInsertEfi.Sh original.rom EnableGop.ffs 0000F800 modified.rom
or rather ./NvInsertEfi.Sh original.rom EnableGop.ffs F800 modified.rom

 

[Bmju]

Thanks again. I guess I will try the VBIOS approach first then. Since I'm not very familiar with Hex editors, would that be the correct command based on my screenshot from the original VBIOS of my card?

./NvInsertEfi.Sh original.rom EnableGop.ffs 0000F800 modified.rom
or rather ./NvInsertEfi.Sh original.rom EnableGop.ffs F800 modified.rom

View attachment 2152671

You have the correct value, but if it is hex, start it with 0x, i.e. 0xF800 (or 0x0000F800, same). If you run NvInsert.sh with no arguments its usage text shows you the correct format for the offset in hex and in decimal.

 

[Macschrauber]

There is an error in the documentation about using nvidia.sh (needs to be confirmed). Replace EnableGop.ffs with EnableGop.efi

The shell tells so and if I use ffs it reports several errors.

 

[Bmju]

1) Let the Mac auto boot to OpenCore boot picker -> no artefacts

2) Select OpenCore from the Apple boot manager -> have artefacts

Okay, that is very interesting, thank you for the report.

Just to be clear, the behaviour of 1 (whenever you let it happen) or 2 (whenever you make it happen) is completely unaffected by ProvideConsoleGop and DirectGopRendering in OpenCore config.plist, right? (That is what I expect and what I understand from your report.)

If you are able to choose whether to autoboot into OpenCore picker or to enter the Apple picker (with ALT) (and then select OpenCore) on one and the same setup, with the same drives plugged in (it is the same setup in both 1 & 2, right?), then yes please, it would still be very helpful if the next test could be to add BootKicker.efi Tool to that setup (that and everything from the latest build, please) and report what that looks like, if you start it from OpenCore, after 1, and after 2. (If you are testing BootKicker beyond reporting how it looks graphically, then please read the current docs in Configuration.pdf for how it is supposed to work now before reporting issues - thank you!)

I can report to everyone else: this mouse trail issue is a very uncommon bug: i.e. no one else has seen it before on all the other cards tested (for list, see OP). I believe it is clearly dependent on this particular card. That said, it will of course be great if we can find a fix.

 

[Bmju]

There is an error in the documentation about using nvidia.sh (needs to be confirmed). Replace EnableGop.ffs with EnableGop.efi

The shell tells so and if I use ffs it reports several errors.

Fixed - tyvm.

 

[joergz]

You have the correct value, but if it is hex, start it with 0x, i.e. 0xF800 (or 0x0000F800, same). If you run NvInsert.sh with no arguments its usage text shows you the correct format for the offset in hex and in decimal.

Thank you. Now I stumble upon these errors when running NVInsert:
EfiRom not available!
UEFIRomExtract not available!

Are they available in the OC package? Couldn't really find them via web search.

 

[Bmju]

At the moment those do need to be gathered via web search, sorry. If you really can't find, PM me and I can ping you copies of them.