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

[jaksemasch]

But there are obviously 2 EFI signatures 0E F1 (read from right to left - little endian).
The enableGOP-patched vBios shows one at offset 67584 (byte) and the other at 81920.

It's confusing to make heads and tails here due to the right to left reading, which afaik also applies to reading the file. Hence the first image, telling from the end of the data, is actually the last image and appears to be enableGOP. If the notion is correct, that the last image takes precedence, than this could explain why the Mac boot screen works, but PC GOP is a miss. Unless enableGOP is PC compatible, how can this possibly work?

Why even bother to have 2 GOP images in the file, if only one is used? I must also admit that I do not understand the swapping of the original NPDE header and image length. Could there be some confusion in the order?

How is this supposed to work, say if I want to install enableGOP myself?

I don' t see the difference in patching any of the vBios files that won't show a VGA boot screen after the enableGOP patch, compared to those that do.

 

[BadAxe80]

Hi,
I have a MacVidCards flash Sapphire RX580 which is not giving a boot screen on a EnableGOP flashed MP5,1.
I get display once it loads Mojave. I understand this can happen. However, it also won't load Sonoma with OCLP. I dont get the OCLP boot screen and it actually just boot loops.

So basically, if I backup the firmware of the MacVidCards RX580 and flash it back to stock, can I go back to the MacVidCards rom later if I need to? Will a ROM dump capture everything it needs? and will flashing the stock rom remove all trace of MacVidCards tinkering? I have access to a PC for flashing.

Realistically, with EnableGOP I'm unlikely to ever need the MVC rom again but I don't like to burn my bridges.

Thanks

I can't believe I missed the most obvious solution. Flick the dual bios switch!
Done and all working now.

 

[Bmju]

But there are obviously 2 EFI signatures 0E F1 (read from right to left - little endian).
The enableGOP-patched vBios shows one at offset 67584 (byte) and the other at 81920.

They are EFI drivers. They are all loaded, in the order they appear in the ROM. The GOP driver, which needs to be in the card for it to work with (U)EFI at all, is what was in there anyway. EnableGop is a driver to run some code from OpenCore, which modifies how GOP is set up to get it into the very specific format of GOP which is all that will work with Apple.

 

[Borowski]

Why even bother to have 2 GOP images in the file, if only one is used? I must also admit that I do not understand the swapping of the original NPDE header and image length. Could there be some confusion in the order?

Not every present image is mandatory and will be executed by host hardware.
For example, some modern cards (i found it on AMD Navi and up) have 2 UEFI GOP-images, one for x86- (code type 0x8664) and one for ARM-architecture (0xAA64).

NPDE-string in EnableGOP-header seems to be needed to avoid "invalid firmware image"-error with nvflash: https://forums.macrumors.com/thread...om.2388570/page-2?post=33530665#post-33530665
If you program with SPI, it isn't not needed and it works, i "forgot" it as i'm doing mods with hex-editor and it worked anyway. So it is only nvflash restriction.

 

[jaksemasch]

They are EFI drivers. They are all loaded, in the order they appear in the ROM. The GOP driver, which needs to be in the card for it to work with (U)EFI at all, is what was in there anyway. EnableGop is a driver to run some code from OpenCore, which modifies how GOP is set up to get it into the very specific format of GOP which is all that will work with Apple.

Image or driver, are these different words for the same thing?

When using GOP_Updater, it usually shows:
EFI is NOT last image! Fixing ID, last-image bit and checksum for EFI image.

Why bother with "last image" logic?

When I analyze an original vBios or vBios processed by GOP_Updater, I can only see one GOP section (55 AA .. F1 0F). After the enableGOP insert, I see 2.

You wrote: "they are all loaded in the order they appear in the ROM". Considering the little-endian architecture, I suppose that means first becomes last. I would think that whatever drivers loads last prevails, which I suppose should be the EnableGOP driver, hence the original GOP image or driver is out of the picture, or not?

After inserting the EnableGOP driver, which has apparently been designed to work for a Mac Pro, I therefore conclude that the card will no longer work with PC/UEFI. Is this correct?

 

[jaksemasch]

Not every present image is mandatory and will be executed by host hardware.
For example, some modern cards (i found it on AMD Navi and up) have 2 UEFI GOP-images, one for x86- (code type 0x8664) and one for ARM-architecture (0xAA64).

NPDE-string in EnableGOP-header seems to be needed to avoid "invalid firmware image"-error with nvflash: https://forums.macrumors.com/thread...om.2388570/page-2?post=33530665#post-33530665
If you program with SPI, it isn't not needed and it works, i "forgot" it as i'm doing mods with hex-editor and it worked anyway. So it is only nvflash restriction.

That sounds reasonable, but how does the system know which GOP-image (or driver?) to use? Isn't this managed by the PCIR (PCI Configuration Information Record), beside containing vendor and device ID, indicating where images are located in the vBIOS and which mode to use? My understanding is, the system's firmware (BIOS/UEFI) is responsible for interpreting the PCIR. The PCIR structure may include a "last image" bit, which indicates whether additional images follow. If multiple PCIR entries are present, the firmware prioritizes the last valid entry based on this bit.

If there are multiple NPDE (NVIDIA PCI Data Structure Extended) sections, doesn't there need to be some logic or rational which one will be used?

 

[jaksemasch]

Anyway, I suppose there are some compatibility issues. For example, enableGOP 1.4 only works after GOP_Updater. Perhaps due to the last image bit set by GOP_Updater? From what I understand, vBiosInsert seems to swap the order of the original GOP and enableGOP, while retaining the header, but I'm not sure. Depending on the original vBios, enableGOP 1.1 seems to break the PC part, but it's not that anything seems wrong with the original vBios.