Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Bmju

Bmju

macrumors 6502a
Original poster
Dec 16, 2013
708
770
You wait ten years for a driver to enable pre-boot graphics on unsupported GPUs in EFI era Macs, and then two come along at once...

This post is to announce a firmware driver to enable the native Apple boot picker and early macOS boot progress bar (plus other parts of the firmware UI: target disk mode; firmware password; internet recovery on machines which have it; etc.) on non-natively supported GPUs, before, or even without, the rest of OpenCore.

The basic idea is: if your GPU already works in but not before OpenCore, then with this driver added to your main firmware or GPU firmware it should be able to work before OpenCore, too.

It has now been fairly widely tested, on both iMac and Mac Pro, but nevertheless it is a firmware driver:
  • If for any reason it fails (or perhaps is incorrectly installed) it can completely brick your machine.
  • If you are not comfortable modifying and burning updates to main firmware or GPU firmware, and recovering from bricks of either of these (which will involve additional hardware) - do not proceed. (Or at the very least, wait for clear and replicable instructions and proven success stories for your specific system, from other users who do have this expertise, before proceeding.)
Instructions and required files can be found in the /Utilities/EnableGop directory of the current OpenCore release. (To see the instructions directly, but without the required built files to actually use them, see here.) For the very latest build (if any recent updates have been made) see the first couple of posts in the thread below.

Background​


This driver has a completely separate origin and development history from @Syncretic's current impressive work. This driver aims to be lightweight and standalone. It comes naturally out of the huge amount of work already done in OpenCore (and mainly finished a couple of years ago, except for these additional steps) to support the OpenCore boot menu on non-natively supported GPUs, within OpenCore. It is also - as part of OpenCore - open source.

After reversing enough of the MacPro firmware to work out how to link OpenCore’s GOP to the Apple firmware UI protocol, it seemed worth trying to enable this before OpenCore as well - i.e. to try to get 'as native' support for these cards. A little bit more experimentation made it clear that the best way to do this would be to piggy-back off the existing, very well tested work already done in OpenCore to support these cards - basically to package up the required parts of OpenCore (ForgeUefiSupport, ProvideConsoleGop and the recent code to connect this to the Apple firmware UI) into a firmware injectable driver, and then figure out a way to deliver its 'payload' (particularly the ProvideConsoleGop part) at the right time. Early versions also used OpenCore’s ReloadOptionRoms, as OpenCore has to do, to load any option ROM which needs ForgeUefiSupport - but with the correct approach it was possible to avoid this, letting the firmware do it for us, which turned out to make the driver much more stable.

So after considerable reversing, some additional new code, and a lot of helpful testing and input from those listed below, this is now working.

Tested Mac models:​

  • MacPro4,1/5,1
  • MacPro5,1
  • iMac9,1 (see Notes)
  • iMac10,1
  • iMac11,1
  • iMac11,2
  • iMac11,3
  • iMac12,2
Notes:
  • The current version of the driver is believed to be safe on all 2009-2012 iMacs and on the MacPro4,1/5,1 and MacPro5,1
    • iMac12,1 should be supported but not yet known: a confirmed test result would be welcome
  • Most recent available firmware in all cases
  • Other Mac models not yet tested, and outside the ones listed above probably will not work (since the required patches apply to the listed firmware only) - please PM me to discuss support
  • iMac9,1 with MXM slots needs a modified driver which is not part of the OpenCore distribution, some ready to use vBIOS version can be found on this Github repo

NOT Supported:​

  • The current version of the driver is NOT compatible with the MacPro3,1, it will make the boot process hang and should not be installed there, in the MacPro3,1 BootROM or the GPU firmware

Tested GPUs:​

  • GT610 (with original or added GOP in VBIOS)
  • GT640
  • GT710
  • GT720 (EnableGopDirect)
  • GT730
  • GTX60
  • GTX660
  • GTX670
  • GTX750Ti
  • GTX780
  • GTX960
  • GTX1050Ti
  • GTX1070
  • GTX1080Ti
  • HD 7770
  • HD 7970 (all except EnableGop(Direct) version 1.2)
  • K2000
  • K2000d
  • K420
  • K600 (with GOP addition in VBIOS)
  • M4000, M5100, W5170M, M6000 (AMD Venus, MXM)
  • M6100, W6150M, W6170M (AMD Saturn, MXM)
  • NVS 510
  • P3000
  • Radeon VII
  • RX460
  • RX480 (PCI and MXM)
  • RX5500XT (PCI and MXM)
  • RX5700XT
  • RX580 Lite (no DVI) - works but reported very slow to start native picker
  • RX580 Nitro+
  • RX6600M (Syncretic patch required, MXM card, GOP does not enable backlight - EFI and OC picker works and can be used blindly, likely model limitation)
  • RX6800 (Syncretic patch required)
  • RX6900XT (Syncretic patch required)
  • W6600 (Syncretic patch required)
  • W6800 (Syncretic patch required)
  • Vega 56
  • Vega (687F)
  • RX560, RX570, RX580, RX590
  • S7100X (MXM)
  • WX4130, WX4150, WX4170, WX7100 (AMD GCN4, MXM)

Notes​

  • All GPUs work with EnableGop, unless explicitly listed as requiring EnableGopDirect
  • Some GPUs listed above may need additional firmware - such as a GOP driver for older GPUs which do not come with one; or other patches - in order for them to work with OpenCore in the first place (hence to be eligible to work with EnableGop in firmware); try searching for the card in this thread or the following iMac specific threads:
  • The driver should also work fine with natively supported GPUs such as GT120 (tested) (e.g. when installed in main firmware and swapping cards)
  • It should work with OpenCore (of course) and with RefindPlus
  • OpenCore settings which this driver already implements can be, but do not have to be, disabled

Releases of EnableGop in not-yet-released versions of OpenCore may be obtained as per the first couple of posts in the thread below. Older versions may be downloaded as required from the named OpenCore release.

If you find you are short on space when flashing to GPU firmware - which can be especially a problem for AMD GPUs - then try EnableGop 1.1 (available with the 0.9.0 release of OpenCore).

EnableGop version (released with OpenCore version):

1.4 (0.9.3)​

  • Incorporates recent updates to OpenCore console control code, but no difference in behaviour compared to version 1.3 is expected on any supported systems.

1.3 (0.9.2)​

  • Included fix to GopBurstMode for non-standard frame buffer information on AMD Radeon HD 7970 and similar
  • Applied GopBurstMode even on natively supported cards, as it can provide a noticable speed up
Note: GopBurstMode is applied by all versions of this driver for the speed-up it gives, so it may be advisable to test OpenCore with GopBurstMode enabled before burning to main firmware or GPU firmware. However the driver has been fairly widely tested now, and there are no known remaining issues on any systems listed as supported, after the fix mentioned above.

1.2 (0.9.1)​

  • Added GopBurstMode support
Note 1: This should provide faster GOP rendering on all EnableGopDirect systems; and rendering at least at the same speed as before, and on some systems noticeably faster than before, on almost all EnableGop systems.

Note 2: The compressed driver for version 1.2 is 1KB larger than for version 1.1, so for AMD GPU firmware which is tight on space version 1.1 may be used instead to avoid the need for VGA stripping to make additional space.

1.1 (0.9.0)​

  • Fixed early verbose boot lines appearing over picker
  • Added EnableGop version number to UI section

1.0 (0.8.9)​

  • Initial public release

The GPU firmware (aka VBIOS) insertion script vBiosInsert.sh now supports both AMD and Nvidia cards.

In the case of AMD, considerably less space is normally available than with Nvidia, due to a strict limit of 128k for legacy and EFI parts of the potentially larger ROM image (the rest of which is only usable internally by the card itself).

So far, there has largely been enough spare space on desktop format (PCIe) cards for Mac Pro, and not enough space on iMac format (MXM) cards. If there is not enough space (i.e. script reports ROM data exceeds the 128k limit) then it is necessary to strip some legacy VGA parts of the GPU firmware, or check on the iMac threads listed in the next spoiler to see if this has already been done for your card.

You can also inject EnableGop into the main system firmware instead of the GPU firmware - see the README.md file in the Utilities/EnableGop directory of the most recent OC builds, or here. In that case the AMD firmware size limit does not matter.

NB If Enable AMD GOP from OCLP is required for you to get a menu is OpenCore then your card won't work as-is with EnableGop. Your card must include GOP in its own firmware in order to work with EnableGop. I have not tested this, but have been told that GopUpdater from WinRAID is one good solution for adding GOP to AMD cards. Once you have added GOP to the card and got it working in OpenCore without OCLP Enable AMD GOP, then it should work pre-OpenCore with EnableGop.

There has been an active community of iMac users making updates and modifications to iMac GPU firmware since long before EnableGop was written. They have kindly adopted EnableGop (and helped to test it), so for many iMac GPUs, you can already find a modified version including EnableGop (and with legacy VGA parts stripped if necessary, see previous spoiler), if you search for your GPU in these threads:

The script relies on the EDK-II EfiRom tool to compress the driver EFI file into option ROM format, and on UEFIRomExtract as part of verifying the modified ROM.
These additional tools should be on your path rather than in the same directory as the script. For example, you could:
  • mkdir ~/MyTools
  • Copy the required tools into ~/MyTools
  • Add export PATH=~/MyTools:$PATH to ~/.bashrc or ~/.profile
  • Close and re-open your shell window
Also useful, if you want to start looking inside GPU firmware dumps:
And for examining main firmware:

Credits​

 
Last edited:
  • Like
  • Love
Reactions: gilles_polysoft, m4v3r1ck, stupots and 43 others
joevt said:
Source code and readme currently at https://github.com/acidanthera/OpenCorePkg/tree/master/Staging/EnableGop
Is Staging the permanent home or does it move to Utilities later? Or maybe Staging is the permanent source code repository location and Utilities refers to the folder in the unzipped assets download - not the directory in the source code repository?
Click to expand...

Yes, the last option is it (though Staging it semi-permanent, it might go to Platform at some point) - but to provide more detail, and in case it helps anyone else:

If you go to the OpenCore builds page, as linked in the OP, then click on a specific build (for these purposes, the most recent - top - completed one which has the same name as the most recent commit on the master branch), wait for a moment on the resultant page (the artifacts take a little longer to appear than the rest of the page), then scroll down to the bottom of the page, you will see the build artifacts:
Screenshot 2023-01-31 at 09.21.05.png

These artefacts are only downloadable if you are logged in to GitHub. Download and unzip 'macOS XCODE5 Artifacts', it contains the very same files (OpenCore-0.8.9-RELEASE.zip and OpenCore-0.8.9-DEBUG.zip) provided in the monthly OpenCore releases, but downloaded from here you have a build available for each commit (including commits not on the master branch, so check which commit you are downloading), not just the commit tagged each month for release.

The compiled .efi and .ffs files, and the Nvidia script, plus the same instructions you have correctly linked to, are gathered together in /Utilities/EnableGop inside those zip files (use the RELEASE version).

This additional palaver is only required for now, for those wishing to get a copy of the compiled files ahead of the next OpenCore release date. Or you can, of course, download and compile from source. :cool:
 
Last edited:
  • Like
Reactions: superjill, j43zt12 and Ausdauersportler
Bmju said:
Or scroll down, as mentioned - they are at the bottom, below Annotations.
Click to expand...
I haven't used the artifacts for a while and when I opened the build link and scrolled to the bottom the artifacts were not there. Then I found the button and clicked it. Now on revisiting the page I can see the artifacts by scrolling directly. Maybe if caches and cookies are cleared you have to click on artifacts at least once?
 
startergo said:
I haven't used the artifacts for a while and when I opened the build link and scrolled to the bottom the artifacts were not there. Then I found the button and clicked it. Now on revisiting the page I can see the artifacts by scrolling directly. Maybe if caches and cookies are cleared you have to click on artifacts at least once?
Click to expand...
I think you may just have to wait, actually. I put 'wait for a bit' in my previous instructions, then took it out - I think I'll put it back in again!
 
  • Like
Reactions: startergo
Can you give more details on this:
No longer supported: Install as Driver#### entry

Early test versions of this driver included code to allow it to work when installed as a Driver#### entry (Driver#### entries do work when installed via bcfg and using MacPro4,1/5,1 firmware; they do not work on that firmware if using efibootmgr, and they are not supported by iMac firmware). This code has been removed in order to minimise the driver size for VBIOS insertion.
Click to expand...
What's the difference between efibootmgr and bcfg? The first is a linux command and the second is a UEFI Shell command? What about doing it from macOS?
https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff

Which models of iMac were tested with the Driver#### method? Did you try setting 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:EnableDriverOrder to "1"? It's described here:
https://wikileaks.org/ciav7p1/cms/page_26968100.html (the GUID they use has a typo)
but I've never tested it.

What code difference is there between the driver that's load from firmware, and the driver that would have loaded from Driver####? Can't the same driver that loads from firmware also load from Driver#### (if your firmware supports Driver####) ?
 
  • Like
Reactions: Petri Krohn
Blimey, yes, but it might be easier in a PM. I did not find out how to enable Driver#### in iMac, if you can - there seems to be some mention of it in the code, but they at least do not seem to be loaded by the 'normal' (standard EFI) code, at the standard load time. `efibootmgr` and `bcfg` are, obviously, `efibootmgr` and `bcfg`, I doubt you would find different versions of them, certainly not related to setting Driver#### options, but yes, they are Linux and UEFI Shell. I did not test iMac with Driver#### at all. Yes, the same file can load as a driver or be inserted into firmware. But what it actually does may - or may not - work at those different load times. Loading as a driver is too late to forge UEFI and affect the subsequent (it is not subsequent, in that case) loading of option ROMs. (Hence it has to detect it is loaded as a driver, forge UEFI, then reload option ROMs - which is the removed code.)

EDIT: Why does only one of `efibootmgr` and `bcfg`work? I cannot remember which way round it is, but one sets a short form path and one sets a long form path, and only one of those actually worked (caused the driver to load), on the Mac Pro.
 
Bmju said:
Loading as a driver is too late to forge UEFI and affect the subsequent (it is not subsequent, in that case) loading of option ROMs.
Click to expand...
How about loading forgeefi.efi beforehand as a UEFI driver? You can set UEFI driver loading order.
 
startergo said:
How about loading forgeefi.efi beforehand as a UEFI driver? You can set UEFI driver loading order.
Click to expand...
I'm confused. Are you talking about using the loading order of a driver installed in firmware to get UEFI forging in at the right time? If so, that is exactly what this does already. (@joevt's question was about whether Driver#### worked, and what I'd tried in that respect. Without particularly trying to address how relevant that is to where this project is now, I was trying to answer.)
 
Bmju said:
Are you talking using the loading order of a driver installed in firmware to get UEFI forging in at the right time?
Click to expand...
No I am talking about loading drivers from UEFI by blessing them. This particular driver (forgeuefi) has been tested before both ways.
 
Sure 'forgeuefi' can forge. But are you suggesting (or saying) that it can forge when loaded as Driver#### (I assume on Mac Pro, not iMac?) _and_ that this can then affect subsequent loading of option ROMs from VBIOS? (I appreciate already that it can affect any subsequent drivers, which could include GOP drivers loaded as additional Driver#### entries.)

I also appreciate that yourself, @joevt, @Dayo and others did considerable research on all this a couple of years ago, so apologies if I've missed anything. That said, my current understanding from @joevt (from a message on an Acidanthera bugtracker issue, I did not manage to achieve contact on this via PM) is that there was nothing to look for in his forgeuefi driver (and I did look) that wasn't already now included in OpenCore.
 
Bmju said:
that there was nothing to look for in his forgeuefi driver (and I did look) that wasn't already now included in OpenCore.
Click to expand...
Sure I don't disagree. But if someone wants to test it first before flashing to a firmware this is the safest way.
Bmju said:
Sure 'forgeuefi' can forge. But are you suggesting (or saying) that it can forge when loaded as Driver#### (I assume on Mac Pro, not iMac?)
Click to expand...
I don't remember, but it could be possible. MacPro yes.
 
startergo said:
But if someone wants to test it first before flashing to a firmware this is the safest way.
Click to expand...

Sure, this is a valid point, and I wrote it this way at first, but:
  • The code path as compared between something which works as a Driver#### and something which works when inserted into firmware (or option ROM) is different (for the reasons already stated), so you're not really testing like-for-like
  • The code always required in the Driver#### path (i.e. reload and re-connect option ROMs) is actually the code that made the whole thing less stable
  • iMac users successfully convinced me that supporting VBIOS insertion as well as main firmware insertion was worth doing, so space is at a premium (free space in VBIOS is usually much less)
Then, I'm releasing this with the caveats and warnings above, but it has been tested and found to work very well by several experienced users, and I've intentionally run all those tests, and made modifications and improvements in response to them, before announcing anything more widely.

I'm hoping that users who _do_ have the ability to recover from problems (i.e. a Matt card, or a SOIC clip, with experience of using it) may be able to try this and post a few more success stories here. But I can report there _is_ currently a small coterie of happy users, with the hardware as listed tested, and working very cleanly.
 
  • Like
Reactions: m0bil, tsialex, joevt and 3 others
startergo said:
@Bmju has anybody tested eGPU boot screen support?
Click to expand...
Probably beyond the scope of this patch. eGPU boot screen can work only if Thunderbolt connected PCI devices are enumerated during EFI in the same step that enumerates all other PCI devices. You would maybe need to inject a PEI driver to do that - find all Thunderbolt controllers, and enable them. Do that before or during PCI enumeration - if the Thunderbolt controllers are not enabled by default. Doing it during DXE time instead of PEI time is more difficult, unless you have a way to shuffle PCI resources after they've been allocated (bus numbers, memory, I/O, etc).

Maybe some of the existing SSDT or Thunderbolt firmware mods enable Thunderbolt controllers and do it early enough?
 
  • Like
Reactions: Amethyst1
On iMacs, I understand from other testers that an external display (from internal GPU) works only if internal display is disconnected. As for an external GPU, yes it's a matter of getting that connected during EFI (I would have said in the DXE phase) and basically a separate issue. That said, if an external GPU was connected in such a way that it could work in OpenCore but not with the native firmware UI, then I would say that yes, in that (hypothetical?) case, there is hope.
 
My comments were about computers like the Mac Pro that don't have built in support for Thunderbolt controllers or hot pluggable PCI. If you can boot to a Thunderbolt connected drive (using tunnelled PCIe), then a Thunderbolt connected eGPU could be connected and usable also.
 
  • Like
Reactions: NataliaC and Amethyst1
joevt said:
If you can boot to a Thunderbolt connected drive (using tunnelled PCIe), then a Thunderbolt connected eGPU could be connected and usable also.
Click to expand...

Sounds 100% correct to me, too. Still the fact that the eGPU is accessible in EFI does not mean that it would be chosen, I guess, over the existing internal GPU. I'd stick to the claim that it would be best to resolve this in OC first (i.e. getting that eGPU to display the OC menu; unless this is already a known, solved problem?) and then to worry about whether EnableGop does enough to carry over the same solution to pre-OC.
 
Bmju said:
Sounds 100% correct to me, too. Still the fact that the eGPU is accessible in EFI does not mean that it would be chosen, I guess, over the existing internal GPU. I'd stick to the claim that it would be best to resolve this in OC first (i.e. getting that eGPU to display the OC menu; unless this is already a known, solved problem?) and then to worry about whether EnableGop does enough to carry over the same solution to pre-OC.
Click to expand...
Right. Making the iMac choose to boot using a different display or GPU to show the startup process would require some investigation and work. Remember on Power Macs you could select the startup screen by dragging the happy Mac to a different display in the Monitor's & Sound Control Panel?
https://www.sonnettech.com/publicfiles/pdfs/pdf_onlinedocs/english/mac/sonata_sd_usermanual.pdf
 
  • Like
Reactions: Amethyst1
I don’t have an eGPU, but the first thing that I would test is a warm boot with only the eGPU connected to a display. This warm boot should be done from either Windows (standard ICM firmware) or MacOS (modified ECM firmware) after getting the eGPU to produce an image on the display. If this test is a success, then getting pre-boot eGPU display would seemingly not be EnableGop-related but would rather come down (as mentioned by @joevt) to enabling the Thunderbolt controller by adding a component (likely a PEI driver) to the Mac Pro’s firmware.

Reversing parts of modern-Mac firmware components may also provide some clues. With current UEFI forging (provided that it is done early enough), it may also be possible to simply add some of those components to the Mac Pro’s firmware. Here’s an interesting precedent:

www.tonymacx86.com

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

192khz holy wow. Any idea how we can check the sample rate of a .movpkg "file" ? (of course I checked every file from the screenshot)
www.tonymacx86.com www.tonymacx86.com
 
  • Like
Reactions: Bmju
cdf said:
Reversing parts of modern-Mac firmware components may also provide some clues.
Click to expand...
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.
 
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?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back