Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.
I can repair graphics cards at the component level and desolder the VBIOS chip to reprogram it with a flash programmer or installing a larger chip if necessary. I’ve done this several times. I understand the benefits of patching the Mac firmware with EnableGOP, but that's not a path I want to explore. My goal is primarily educational, to see what works and what doesn't, and for that purpose I need a Mac Pro with the original Apple firmware.

I need a boot screen to switch between various Windows and macOS installations. I also frequently swap graphics cards between Mac and PC/Linux for testing with Nvidia MODS diagnostic tools. Such testing can’t be done with the VBIOS from MacVidCards without re-flashing each time, but works perfectly fine using the stock VBIOS with EnableGOP.

That said, what could be the reason that Nvidia Maxwell cards stop working in a PC after the EnableGOP patch? It functions quite well with the Kepler series. I’ve checked the vBiosInsert shell script to understand how it works, and it does some error checking. From a programmatic perspective, the patching seems successful.

Btw, to flash the VBIOS on the GTX 900 series, I use nvflash 5.218 with certificate check disabled, otherwise it cannot be flashed: http://www.overclock.net/attachments/41789. But I also used other/older nvflash versions which do not perform such checks.
 
Last edited:
  • Like
Reactions: Ausdauersportler
P.S.:

Added MacPro5,1 to my post that originated this discussion to make it clear to someone that finds it without reading the context:
Again, it is not completely incompatible. This statement is plainly wrong. As I explained - and you know this very well - one can add drivers to both graphics card firmware and Mac firmware and it does not affect the system unless you use it somehow. For example the most recent AMD cards have a 2nd GOP never used on older Intel hardware.

An AMD graphics card with an unmodified GOP video BIOS will behave in exactly the same way in MacPro3,1 and MacPro5,1 when pressing all/option: boot will stuck, screen is black. The same happens on iMac 2009-2011 with plain PC GOP video firmware on MXM cards.

Adding the EnableGop driver makes it working on MacPro5,1 (and for MXM cards on iMacs) but it does not change anything on MacPro3,1 - so how became the card suddenly (completely or more ) incompatible? This is a very special logic!

If I am not able to convince you here you should work on your logic or prove me wrong about the use of GPUs on MacPro systems - I agree my experience in general is really limited there.

P.S..
I remember the use case we are discussing about here very well and the user doing it in particular, too. You are mixing things up here.

You can even add the driver to MacPro3,1 firmware, it does not change the behavior of this system if not used. I does not make it incompatible or un-usable, it simply does not work.
 
Last edited:
Giving this another thought, modifying the Mac Pro firmware appears to be the more effective solution for addressing boot screen problems. However, patching the VBIOS is arguably a more portable approach. Most users can easily swap out a graphics card but may lack the skills to tackle custom firmware patches, especially when something goes wrong.

Obviously, we need a different approach to address Mac Pro's 3,1 and earlier, which to my knowledge require UGA and hence a firmware update from Apple to work with GOP, which isn't going to happen. These computers are too old to run anything past 10.14 anyway and MacVidcCards seems to be the only solution so far.

Unfortunately, if it weren't for the fun of testing and flashing graphics cards to show a Mac Pro boot screen, I wouldn't have much use for an old Mac Pro anymore. While I prefer using the Mac Pro over the Mac Mini it has become increasingly costly for my daily computer needs, with electricity prices soaring to 50 cents per kWh and likely rising further, but I digress.
 
Why is it necessary to process any Nvidia vbios file with GOP_Updater prior to inserting the enableGOP patch?

All the rom files I've tried so far are already UEFI compatible. The vBiosInsert.sh script appears to have no issue using these original roms, but won't show the Mac boot screen, unless these files are pre-processed by GOP_Updater. What is the rational behind this?

How does the vBiosInsert.sh function? It appears to be extracting the UEFI Bios, then inserting enableGOP.efi, compressing the EFI part (why?) and glueing things together again. How can this work? Does it add the enableGOP.efi or replace the existing UEFI? How does the Mac or PC know what to use at system startup? I suppose the Mac firmware will find what it needs by some identifier. If I understand correctly, enableGOP.efi does not alter the UEFI/VGA part of the original vbios. Hence why is GOP_Updater requires, or so it appears?

I managed to get a Mac boot screen with a GTX 960 and it also works in a PC, which previoiusly did not work. However, I'm using a newer vbios for a different GTX 960 model that does not seem compatibel. With that vbios, the computer (PC) crashes as soon as I start some benchmark program. I tried to adjust parameters using the Maxwell Bios Tweaker, but it just won't play nicely.

If I'm not mistaken, there used to be a tool that would show the structure of the vbios file, but I've lost the info. Does anyone know?

Thanks!
 
Last edited:
To my knowledge, the GOP-part can't be simply replaced on all nVidias without breaking signatures. Maybe this inactivates the GOP and i would expect the same issue in a Windows pc.

If GOP is present, there is no need to update it with GOPUpdater.

The script also adds the header (depending on AMD or nVidia) and the vendor- and device id at the beginning of GOPEnabler-image.
 
To my knowledge, the GOP-part can't be simply replaced on all nVidias without breaking signatures. Maybe this inactivates the GOP and i would expect the same issue in a Windows pc.

Not really according to this:
I have confirmed that the problem arises only after patching the VBIOS with EnableGop, not with GOP_Updater.


If GOP is present, there is no need to update it with GOPUpdater.
Correct it is only recommended.
 
On mo
To my knowledge, the GOP-part can't be simply replaced on all nVidias without breaking signatures. Maybe this inactivates the GOP and i would expect the same issue in a Windows pc.

If GOP is present, there is no need to update it with GOPUpdater.

The script also adds the header (depending on AMD or nVidia) and the vendor- and device id at the beginning of GOPEnabler-image.

In think there are some general misconceptions about the Nvidia signature buisiness. Starting with Pascal, the GPU introduced a security meachnism, that would protect certain GPU parameters at runtime. So you can't just tweak the clock or power, unless it was initiated by the vbios at GPU initialization/startup. The vbios on the other hand has a Nvidia signature, which nvflash will expect to be valid and refuse to flash the card if not.

To flash Pascal or newer, I use a modified nvflash that bypasses the signature check. I mentioned it in this thread a few posts ago. There are also other requirements, such as disabling vbios protection settings on newer cards, or disabling any running Nvidia grpahics driver depending on nvflash version. I'm not sure about UEFI, but I'm pretty sure the PC-BIOS laoding the VGA vbios extension does not care about signatures.

The signature buisines is all software, and perhaps some newer Nvidia graphics drivers will check the vbios signature, or fail to load. But does the GPU care about vbios signatures when it receives power? I don't think so.

Don't all graphics adapters still have a VGA BIOS extension running in 16-bit real-time mode when the PC-BIOS starts? I think many PC's still rely on the original PC-BIOS standard for compatibilty, and switch to UEFI 32-protected or 64-bit mode after some initial PC startup. Once UEFI has as been started, access to the BIOS is no longer possible without switching back in to real-time mode.
 
Last edited:
Not really according to this:




Correct it is only recommended.
I have verified several times using a GTX 770/780/960/970 that enableGOP won't show a Mac boot screen, unless you use GOP_Updater prior to vBiosInsert.sh. Thats what I don't understand. If UEFI and enableGOP are speparate parts of the firmware, why is this necessary? Is enableGOP a wrapper loaded by the Mac Pro pointing to the UEFI firmware? That might explain it.
 
But does the GPU care about vbios signatures when it receives power? I don't think so.
Yes it does. Just to clarify vBios GOP_update should not break the signature unless something is manually altered as you correctly noted. So in this respect flashing the vBios along with bypassing the signature check may lead to undefined behavior. You must check the signature for Windows to boot properly.
 
Last edited:
Yes it does. Just to clarify vBios GOP_update should not break the signature unless something is manually altered as you correctly noted. So in this respect flashing the vBios along with bypassing the signature check may lead to undefined behavior. You must check the signature for Windows to boot properly.
The firmware most likely cares about CRC checksums, which won't expire. Let's not confuse signatures and checksums. Signatures (certificates) are on differnet level. The signature, like I mentioned, can be important for the Nvidia Graphics driver, which may fail to load when wrong, or nvflash may refuse to flash the card.
 
There's a catch, though. While the EnableGop-patched GTX 770/780 and 960/970 work in a Mac Pro (Firmware 144.0.0.0) and can boot into macOS or UEFI Windows (installed from USB), the GTX 960/970, unlike the 770/780, will no longer work in a PC and cannot boot Legacy Windows MBR.
Code:
/Users/mbp151/OpenCore-Legacy-Patcher/payloads/OpenCore/Update-OpenCore.command ; exit;
/Users/mbp151/.zprofile:17: command not found: pyenv
/Users/mbp151/.zshrc:9: command not found: pyenv
mbp151@MBP151s-MacBook-Pro ~ % /Users/mbp151/OpenCore-Legacy-Patcher/payloads/OpenCore/Update-OpenCore.command ; exit;
Generating new OpenCore bundles...
Working directory: /Users/mbp151/OpenCore-Legacy-Patcher/payloads/OpenCore
Getting latest DEBUG...
   Getting latest DEBUG download url...
   Download url: https://github.com/acidanthera/OpenCorePkg/releases/download/1.0.2/OpenCore-1.0.2-DEBUG.zip
   Downloading latest DEBUG...
Getting latest RELEASE...
   Getting latest RELEASE download url...
   Download url: https://github.com/acidanthera/OpenCorePkg/releases/download/1.0.2/OpenCore-1.0.2-RELEASE.zip
   Downloading latest RELEASE...


If you have problems with `vBiosInsert.sh` from a specific release of EnableGop, please try the version included with the latest release of OpenCore. The script has received some useful updates to support additional GPUs since the last bump in the release version of the EnableGop driver itself. (Project readme also updated with this info: https://github.com/acidanthera/OpenCorePkg/commit/d4ddd2937b38fa06491ceefae30395622f19c566)
 
vBiosInsert.sh shows me in all cases that enableGOP was successful. Please see the screenshots in my inital post for confirmation. I've tried release 1.0.1 and 1.0.2, and also the development enableGOP 1.5, no change.

In my opinion, there's something missing in the vBiosInsert procedure, or the issue is with the original vbios. Hence I was looking for a tool to show the me the structure of the vbios file. Perhaps something is missing when it fails on the PC, such as a VGA Bios extenstion.
 
I have verified several times using a GTX 770/780/960/970 that enableGOP won't show a Mac boot screen, unless you use GOP_Updater prior to vBiosInsert.sh. Thats what I don't understand.
You either had broken or missing GOP. When you just drag and drop the vBios in the GOP_Upd cmd it should tell you.
 
@Bmju That should not happen in theory correct? What gives?
You are correct, that should not happen in theory. I don't know what gives.

In theory the EnableGop driver would be started on a PC, I just would not expect the conditions to trigger its payload to occur.

So it is news to me. But given that iMac graphics cards are only for the iMac (i.e. not easily swappable), and that MP5,1 always has the option to flash EnableGop to main firmware, then while I would like to understand and explore this more, it's probably going to remain a low priority.
 
I would like to understand and explore this more, it's probably going to remain a low priority.
On top of that Enable_GOP is not needed for a PC, so if a card is needed in a PC and can't boot with it the Enable_GOP the original vBios simply needs to be re-flashed.
 
On top of that Enable_GOP is not needed for a PC, so if a card is needed in a PC and can't boot with it the Enable_GOP the original vBios simply needs to be re-flashed.
Of course ... though in an ideal world this would be harmless in a PC too. There were a lot of early reports that it _was_ harmless in a PC.

It's possible that version 1.1 works fine in Macs and PCs, but that the current version 1.4 doesn't - if anybody who has problems with their GPU w/ EnableGop in a PC has a chance to test this?
 
  • Like
Reactions: 0134168
I would guess the issue with some PCs is UEFI "Secure Boot", which can't be disabled in some OEMs machines.
Stricter implementations will disable CSM (legacy emulation) and halt boot if any unsigned UEFI code is detected.
 
Can you confirm that using GOP_upd alone with your linked firmware makes the Windows MBR bootable on a PC?
I did not explicitly mention it in my initial post #1,041 but it does.

My test PC runs Windows 7 with a MBR partition. Hence UEFI/GOP does not come into play there. On the PC the BIOS won't even post after patching with enableGOP and just beeps. Changing the PC-BIOS to Windows 8/10 and PCI UEFI makes no difference though.

As I mentioned, no problems after GOP_Updater, just after enableGOP, and only with the GTX 960/970. On the Mac Pro I have UEFI windows 8.1/10 and it also identifies itself as UEFI in the hardware info., and Windows 7 on a boot camp GPT/MBR hybrid partition. Once I patch the GTX 960/970 with enableGOP, windows 7 on the Mac Pro hangs.

I'm just guessing, but it appears the GTX 960/970 graphics cards, after enableGOP, are only recognized by the Mac EFI. That's why I was wondering if it possibly invalidated the vbios VGA part. The rom file size after the enableGOP patch is the same, perhaps slightly larger.
 
Of course ... though in an ideal world this would be harmless in a PC too. There were a lot of early reports that it _was_ harmless in a PC.

It's possible that version 1.1 works fine in Macs and PCs, but that the current version 1.4 doesn't - if anybody who has problems with their GPU w/ EnableGop in a PC has a chance to test this?

I was wondering in #1,056 how vBiosInsert functions and why GOP_Updater is required for enableGOP to provide a Mac boot screen. Is enableGOP inserted into the vbios alongside the UEFI GOP and VGA bios? Is enableGOP some sort of Mac Pro EFI wrapper that relies on UEFI GOP?

I'll be happy to test enableGOP 1.1 to see it makes a PC difference and will post the results.
 
  • Like
Reactions: Bmju
I was wondering in #1,056 how vBiosInsert functions and why GOP_Updater is required for enableGOP to provide a Mac boot screen.
Where did you see that GOP_updater is required? I only see this:
  • CSM (Compatibility Support Module) disabled in firmware settings if present. On NVIDIA 6xx/AMD 2xx or older, GOP ROM may have to be flashed first. Use GopUpdate (see the second post) or AMD UEFI GOP MAKER in case of any potential confusion.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.