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

[Bmju]

Anyway, I will say this is still a huge step forward.

Thank you.

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.

Apparently there is a known similar issue with DirectGopRendering (probably to do with memory caching of GOP framebuffer), with just a few cards (not all DirectGopRendering cards), even in OC itself. It is not clear why this problem is triggering in your card with the EnableGop driver, but not in main OC (since these share the same relevant GOP setup code).

 

[h9826790]

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.)

Correct, in both cases 1 and 2, both ProvideConsoleGop and DirectGopRendering were enabled.

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.

I also believe this is very specific to the Radeon VII.

When we did the Mac GOP internal tests with vit9696 Back in Feb 2020, it's also the Radeon VII having trouble to show anything, which end up vit9696 need to work more on the direct GOP.

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!)

Sure, let's see if I have enough time to do it tonight.

My plan is.

1) Install the latest OpenCore 0.8.9, add BootKicker.efi, both ProvideConsoleGop and DirectGopRendering enable

2) test boot to see if there is any artefacts in the boot picker

2a) select Monterey if artefacts spoted in step 2, to check if any artefacts in loading screen

3) Shutdown, remove all drives from the Sonnet card to make sure the native boot manager can work

4) Only connect one SATA SSD to the optical bay's native SATA port. This SSD contain OpenCore 0.8.9 and Monterey 12.6.3 (all other boot drives will be removed).

5) Hold option key to boot, expect native boot manager show up with artefacts

6) Select OpenCore, expect OpenCanopy boot picker show up with artefacts

7) Select BootKicker, expect to see the Apple boot manager again with aretfacts

8) Select OpenCore, the Mac Pro should reboot and default to load OpenCore

9) OpenCanopy boot picker should show up automatically (assume no artefacts in step 1a)

10) Select BootKicker, expect to see the Apple boot manager with artefact

11) Use Control + Enter to bless OpenCore, expect the Mac will reboot, and load OpenCore

 

[Bmju]

1) Install the latest OpenCore 0.8.9, add BootKicker.efi, both ProvideConsoleGop and DirectGopRendering enable

You might want to confirm this with a couple of additional steps (if you have time) - but IMO (and I would definitely like to know, if not!) the OpenCore settings ProvideConsoleGop and DirectGopRendering become completely irrelevant (even within OpenCore itself, once it has started) if EnableGopDirect.ffs is installed: there is no change to either of them which should make any change in what you see, once you have EnableGopDirect.ffs in firmware.

Certainly, whichever way we look at things, OpenCore settings ProvideConsoleGop and DirectGopRendering are always irrelevant to (i.e. have absolutely no effect on) anything which happens before OpenCore starts.

Possibly this was not clear, I guess I have not said it, but: EnableGop and EnableGopDirect driver do not in any way read the OpenCore config.plist. They just have their own absolutely preset configuration, applied for the small bits of OC which they embed.

 

[Bmju]

Actually in step 10, after getting some more info from Vit, I am now expecting that the Apple picker will not show artefacts, in that test. But yes, all these tests and I would very much like to know all results. Tyvm.

 

[h9826790]

Test done. Time to report, found some funny thing indeed.

1) Install the latest OpenCore 0.8.9, add BootKicker.efi, both ProvideConsoleGop and DirectGopRendering enable

This is done. If required, I can perform the same test again with both disabled. But so far, these settings seems doing nothing in the test. HOWEVER, it makes the difference in another situation. I will get into this at the end of this post

2) test boot to see if there is any artefacts in the boot picker

2a) select Monterey if artefacts spoted in step 2, to check if any artefacts in loading screen

Absolute smooth in step 2. So, no need to go step 2a, because expect everything normal. [N.B. The boot drive is still on the Sonnet TempoSSD card]
[no critical time mark, just a video to show normal OpenCanopy]

Rather than preform step 2a, which I expect nothing will happen. I selected BootKicker, which I expect a pure light grey screen will show up (due to the Sonnet card). But I am wrong, the screen somehow like "captured", but I can repaint it to black by using the mouse pointer. And artefacts also introduced by selecting BootKicker
[no critical time mark, whole video shows the artefacts]

3) Shutdown, remove all drives from the Sonnet card to make sure the native boot manager can work

4) Only connect one SATA SSD to the optical bay's native SATA port. This SSD contain OpenCore 0.8.9 and Monterey 12.6.3 (all other boot drives will be removed).

5) Hold option key to boot, expect native boot manager show up with artefacts

6) Select OpenCore, expect OpenCanopy boot picker show up with artefacts

Done, expectation is correct, artefacts happen in both step 5 and 6

I forgot to disable the 10s timeout in OpenCore boot picker, which makes OpenCore auto select Monterey after 10s (even the mouse pointer is moving). And the Apple logo is missing, but just loading bar showed up (same as post #43).
[OpenCore selected at 0:25, Monterey auto selected at 0:35]

7) Select BootKicker, expect to see the Apple boot manager again with aretfacts

8) Select OpenCore, the Mac Pro should reboot and default to load OpenCore

Done, expectation is correct, BootKicker works with artefacts
[BootKicker selected at 0:08, further select OpenCore at 0:25]

9) OpenCanopy boot picker should show up automatically (assume no artefacts in step 1a)

10) Select BootKicker, expect to see the Apple boot manager with artefact

11) Use Control + Enter to bless OpenCore, expect the Mac will reboot, and load OpenCore

Done, this is the unexpected outcome start (or more precise, this should be the real expected result, which just not fit my observation so far).

Now, the Mac reboot to OpenCanopy by BootKicker after step 9. I expect no artefacts, but I am wrong.
When artefacts happen in OpenCanopy, only the upper half of the mouse pointer will show up initially. Both the restart and shutdown icon missing, but I know I can "paint" them out by using the mouse pointer, and they can work if I kick the correct position.

[BootKicker selected at 0:24, OpenCore (Control + Enter) selected at 0:55]

After step 11, shutdown, performed a cold boot. I expect OpenCanopy will back to normal (base on the observation before this test). But I am wrong again, artefacts still there (which should be the expected result indeed).
[Shutdown at 0:05, cold boot at 0:13, POST at 0:30, boot picker show up 0:42]

Then I shut down the Mac, reconnect all hard drives (total 3 boot drives, the other two also contain OpenCore 0.8.8). Main boot drive (with OpenCore 0.8.9 beta) move back to the Sonnet TempoSSD card. After power on, cMP still obey the BootKicker command, auto boot to the blessed OpenCore 0.8.9 beta (despite there are three OC copy on 3 boot drive, only the 0.8.9 OC copy has BootKicker enabled. Therefore, I can confirm this is the blessed 0.8.9 OC copy}.

Full light grey screen for few seconds (this light grey screen wasn't exist in step 2. Also not exist before the test). Then OpenCanopy showed up, and surprisingly, no artefacts this time (this fit my previous observation, but completely unexpected now).
[no critical time mark, just a video to show normal OpenCanopy in dark mode after light grey screen]

So, it's even more strange now. When I boot the same drive via the native SATA II port, artefacts exist regardless I hold Option key to boot or not.

But when the boot drive is on the TempoSSD (a Sonnet PCIe SATA III card), then OpenCanopy boot picker is perfect.

The variables seem is the TempoSSD card??? Which shouldn't affect the DirectGopRendering outcome. When I perform the test in post #41 (boot with ProvideConsoleGop and DirectGopRendering disabled), my SSD was on the TempoSSD card. Exactly the same hardware setup as in step 2, but the outcome is same as "After step 11" (boot picker with artefacts) Therefore, somehow the TempoSSD card works better with DirectGopRendering, but not that good with EnableGopDirect.ffs.

In sumary

A) EnableGopDirect.ffs + TempoSSD = artefacts

B) EnableGopDirect.ffs + native SATA II port = artefacts

C) EnableGopDirect.ffs + DirectGopRendering + native SATA II port = artefacts

D) EnableGopDirect.ffs + DirectGopRendering + TempoSSD = perfect boot picker

This is a completely unexpected result. Please let me know if you believe I missed anything which lead to this strange result.

 

[Bmju]

Test done. Time to report, found some funny thing indeed.


This is done. If required, I can perform the same test again with both disabled. But so far, these settings seems doing nothing in the test. HOWEVER, it makes the difference in another situation. I will get into this at the end of this post


Absolute smooth in step 2. So, no need to go step 2a, because expect everything normal. [N.B. The boot drive is still on the Sonnet TempoSSD card]
[no critical time mark, just a video to show normal OpenCanopy]

Rather than preform step 2a, which I expect nothing will happen. I selected BootKicker, which I expect a pure light grey screen will show up (due to the Sonnet card). But I am wrong, the screen somehow like "captured", but I can repaint it to black by using the mouse pointer. And artefacts also introduced by selecting BootKicker
[no critical time mark, whole video shows the artefacts]

Done, expectation is correct, artefacts happen in both step 5 and 6

I forgot to disable the 10s timeout in OpenCore boot picker, which makes OpenCore auto select Monterey after 10s (even the mouse pointer is moving). And the Apple logo is missing, but just loading bar showed up (same as post #43).
[OpenCore selected at 0:25, Monterey auto selected at 0:35]

Done, expectation is correct, BootKicker works with artefacts
[BootKicker selected at 0:08, further select OpenCore at 0:25]

Done, this is the unexpected outcome start (or more precise, this should be the real expected result, which just not fit my observation so far).

Now, the Mac reboot to OpenCanopy by BootKicker after step 9. I expect no artefacts, but I am wrong.
When artefacts happen in OpenCanopy, only the upper half of the mouse pointer will show up initially. Both the restart and shutdown icon missing, but I know I can "paint" them out by using the mouse pointer, and they can work if I kick the correct position.

[BootKicker selected at 0:24, OpenCore (Control + Enter) selected at 0:55]

After step 11, shutdown, performed a cold boot. I expect OpenCanopy will back to normal (base on the observation before this test). But I am wrong again, artefacts still there (which should be the expected result indeed).
[Shutdown at 0:05, cold boot at 0:13, POST at 0:30, boot picker show up 0:42]

Then I shut down the Mac, reconnect all hard drives (total 3 boot drives, the other two also contain OpenCore 0.8.8). Main boot drive (with OpenCore 0.8.9 beta) move back to the Sonnet TempoSSD card. After power on, cMP still obey the BootKicker command, auto boot to the blessed OpenCore 0.8.9 beta (despite there are three OC copy on 3 boot drive, only the 0.8.9 OC copy has BootKicker enabled. Therefore, I can confirm this is the blessed 0.8.9 OC copy}.

Full light grey screen for few seconds (this ligh grey screen wasn't exist in step 2. Also not exist before the test). Then OpenCanopy showed up, and surprisingly, no artefacts this time (this fit my previous observation, but completely expected now).
[no critical time mark, just a video to show normal OpenCanopy in dark mode after light grey screen]

So, it's even more strange now. When I boot the same drive via the native SATA II port, artefacts exist regardless I hold Option key to boot or not.

But when the boot drive is on the TempoSSD (a Sonnet PCIe SATA III card), then OpenCanopy boot picker is perfect.

The variables seem is the TempoSSD card??? Which shouldn't affect the DirectGopRendering outcome. When I perform the test in post #41 (boot with ProvideConsoleGop and DirectGopRendering disabled), my SSD was on the TempoSSD card. Exactly the same hardware setup as in step 2, but the outcome is same as "After step 11" (boot picker with artefacts) Therefore, somehow the TempoSSD card works better with DirectGopRendering, but not that good with EnableGopDirect.ffs.

In sumary

A) EnableGopDirect.ffs + TempoSSD = artefacts

B) EnableGopDirect.ffs + native SATA II port = artefacts

C) EnableGopDirect.ffs + DirectGopRendering + native SATA II port = artefacts

D) EnableGopDirect.ffs + DirectGopRendering + TempoSSD = perfect boot picker

This is a completely unexpected result. Please let me know if you believe I missed anything which lead to this strange result.

@h9826790 - Thank you very much for the thorough tests and videos, which really help.

I think the basic idea here (very roughly) is that the GOP memory is not being marked correctly for caching. Then it depends on the specifics of exactly when GOP is set up, and what else has loaded first, as to whether this happens or not (maybe it just depends on which bit of memory the GOP framebuffer 'ends up' in). I will have to spend some time looking into possible workarounds (some _very_ tentative suggestions from Vit) and see if I can get back to you with a test version in due course, if that is okay.

If I may, I would like to repeat to other readers that this problem is specific to this card (which was already known to be problematic for DirectGopRendering, from before), and that most cards - even most cards which require DirectGopRendering - do not show these artefacts, and just work!

 

[Macschrauber]

As my dumper was mentioned in the howto site I want to announce a new feature:

For personal use I had a CH341a programmer version of it. I combined the Mac Pro and the CH341a version.

So one can use the Dumper to backup/analyze the firmware and in case of a brick can flash the chip in the CH341a tool with the Dumper as well. Same analyzing and warning functionality.

 

[Bmju]

As my dumper was mentioned in the howto site I want to announce a new feature:

For personal use I had a CH341a programmer version of it. I combined the Mac Pro and the CH341a version.

So one can use the Dumper to backup/analyze the firmware and in case of a brick can flash the chip in the CH341a tool with the Dumper as well. Same analyzing and warning functionality.

That sounds like great addition to an already very helpful tool. Which is the best link for the new version?

 

[Macschrauber]

The link from the youtube channel is ok, if the dropbox link breaks I can update it.

Here's a link to the main post about the Dumper:

Healthy NVRAM normal behaviour on 4,1->5,1 machines

Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...

forums.macrumors.com

 

[h9826790]

You might want to confirm this with a couple of additional steps (if you have time) - but IMO (and I would definitely like to know, if not!) the OpenCore settings ProvideConsoleGop and DirectGopRendering become completely irrelevant (even within OpenCore itself, once it has started) if EnableGopDirect.ffs is installed: there is no change to either of them which should make any change in what you see, once you have EnableGopDirect.ffs in firmware.

I fully understand EnableGopDirect.ffs work stand alone, and nothing related ProvideConsoleGop and DirectGopRendering.

@h9826790 - Thank you very much for the thorough tests and videos, which really help.

I think the basic idea here (very roughly) is that the GOP memory is not being marked correctly for caching. Then it depends on the specifics of exactly when GOP is set up, and what else has loaded first, as to whether this happens or not (maybe it just depends on which bit of memory the GOP framebuffer 'ends up' in). I will have to spend some time looking into possible workarounds (some _very_ tentative suggestions from Vit) and see if I can get back to you with a test version in due course, if that is okay.

This make sense now, and completely possible.

Sure I can do the follow up beta testing if there is any work around you want to try. A million thanks in advance.

 

[Macschrauber]

I just inserted enablegop.efi into an old GT640 1GB Kepler GPU's vbios with the shell script successfully.
Had GOP in the vga firmware of course (I patched that some day).

NVFLASH reported an unknown GOP after adding enablegop.efi (as expected).

 

[Macschrauber]

As my dumper is mentioned in @Bmju Github site I announce here that it now detects EnableGop's GUID for EnableGop and EnableGopDirect in the Mac Pro firmware and writes it in the report. It also can be used to flash the firmware.

To use it for dynamically loading DirectHW.kext (at least) csr_allow_untrusted_kexts needs to be set in s.i.p. settings and the kext needs to be allowed in Security & Privacy control panel.

Or use an old OS, I prefer Mavericks as my test and repair system as it is the oldest compatible system. It should run with
-no_compat_check set as boot-arg with framebuffer driver thru OpenCore as well.

https://www.dropbox.com/s/kr74r2ft0nrvp7n/Macschrauber's CMP Rom Dump.dmg?dl=0

Alternative Url (Dropbox seems to be blocked temporarily)

Ihr persönlicher Freigabelink | GMX Cloud

Mit diesem Link erhalten Sie Zugriff auf die mit Ihnen geteilten Daten.

c.gmx.net

 

[h9826790]

As my dumper is mentioned in @Bmju Github site I announce here that it now detects EnableGop's GUID for EnableGop and EnableGopDirect in the Mac Pro firmware and writes it in the report. It also can be used to flash the firmware.

To use it for dynamically loading DirectHW.kext (at least) csr_allow_untrusted_kexts needs to be set in s.i.p. settings and the kext needs to be allowed in Security & Privacy control panel.

Or use an old OS, I prefer Mavericks as my test and repair system as it is the oldest compatible system. It should run with
-no_compat_check set as boot-arg with framebuffer driver thru OpenCore as well.

View attachment 2153838

Dropbox - File Deleted - Simplify your life

www.dropbox.com

Thanks, works beautifully.

 

[Borowski]

What will happen, if gpu has UGA- and GOP-images? Some cards from MVC and some Turing-cards have both.

Any easy way to download the files from github? Very hard to find.

 

[Bmju]

What will happen, if gpu has UGA- and GOP-images? Some cards from MVC and some Turing-cards have both.

This driver does not touch UGA, so far it has not proven necessary in order to get as-native pre-boot support for all the cards x machines listed in the Spoiler in the first post. The presence of UGA will not break anything, however.

Any easy way to download the files from github? Very hard to find.

The first post, and the first couple of replies to it, already discuss this in detail.

 

[Marche90]

The first post, and the first couple of replies to it, already discuss this in detail.

Any idea why the artifacts appear but are unclickable? They behave as text with no way to download them, at least on my end. Do we need to have a GitHub account to do so?

 

[Bmju]

Do we need to have a GitHub account to do so?

Yes. Good point. I'll update the earlier posts.

 

[reddrag0n]

question, where would i find that folder with EnableGopDirect.ffs ??


*EDIT*
NM, i was able to find it in the 0.8.9 prerelease, i was originally looking in the older verisons aka 0.8.8 and lower

 

[Bmju]

I've checked exactly this, with last week artifacts (20230203) and yesterday's final release and there are thousands of changes when comparing with hexedit. There is a way to do it that I'm not seeing?

Hi @tsialex! - I feel this was off-topic on @cdf's Mac Pro thread.

I think it depends what you want to check for. If there are loads of hex changes, then the driver has for sure compiled differently. But there were several changes in the OC build chain recently. (I am not 100% sure if that is it, can check.) In any event, what I mean is, if you want a header which means 'meant to be the same', then the UI Section text should do it - note already different between EnableGop and EnableGopDirect, for instance.

 

[tsialex]

Hi @tsialex! - I feel this was off-topic on @cdf's Mac Pro thread.

Hi! Sorry for posting there, should have posted here.

I think it depends what you want to check for. If there are loads of hex changes, then the driver has for sure compiled differently. But there were several changes in the OC build chain recently. (I am not 100% sure if that is it, can check.) In any event, what I mean is, if you want a header which means 'meant to be the same', then the UI Section text should do it - note already different between EnableGop and EnableGopDirect, for instance.

So, ignoring toolchain changes and let's say down the road you'll find a bug or a modification that warrants an improved version of EnableGop/EnableGopDirect, your plan is to change the UI Section text to clearly indicate it? Something like EnableGopv2 with UI Section text?

 

[Bmju]

Hi! Sorry for posting there, should have posted here.



So, ignoring toolchain changes and let's say down the road you'll find a bug or a modification that warrants an improved version of EnableGop/EnableGopDirect, your plan is to change the UI Section text to clearly indicate it? Something like EnableGopv2 with UI Section text?

That's a tentative plan. Let me just check because I feel there should be built-in version number somewhere already that we can find in the .ffs file. I'm not immediately seeing it in UEFITool. But yes, I appreciate your need, and I'll make sure to address it with something.

 

[Bmju]

cc @freqrider - This project is now known not to work on the MP3,1. Some initial reversing of the MP3,1 firmware has shown that what the firmware UI there needs is working UGA, not working GOP. Some further, initial, remote tests have convinced me that this is not something I can resolve without physical access to a machine, which I do not currently have unfortunately.

 

[freqrider]

Understood. But why GOP rendering works via OC? Or does it? I have turned it of in config.plust and still had a bootscreen?

 

[Bmju]

Understood. But why GOP rendering works via OC? Or does it? I have turned it of in config.plust and still had a bootscreen?

Yes, it does, and this is the right question to ask! But there's no huge why, really, OpenCore just does require GOP, on all the machines where it works. It is able to find and use not yet connected versions of GOP, it is also able to provide GOP over UGA. On the other hand the Apple firmware on each machine requires whatever it requires. It turns out on the 2009-2012 Mac Pros and iMacs, the Apple firmware in this regard is very similar, and requires GOP. On the other hand the cMP3,1 firmware requires UGA.

Nothing you are seeing in the boot menu on OpenCore requires UGA (regardless of which machine it is on, and regardless of what the native firmware UI on that machine requires).

I understand that early mac OS X boot does require UGA. So depending on how you set up OpenCore, you either will or will not see early stage boot progress, on early macOS. And something similar to the set-up required for this is what will be required to enable the firmware UI on the Mac Pro 3,1. Plus something similar to my existing driver, to encapsulate the required parts of OpenCore as a stand-alone firmware driver.

 

[freqrider]

Yes, it does, and this is the right question to ask! But there's no huge why, really, OpenCore just does require GOP, on all the machines where it works. It is able to find and use not yet connected versions of GOP, it is also able to provide GOP over UGA. On the other hand the Apple firmware on each machine requires whatever it requires. It turns out on the 2009-2012 Mac Pros and iMacs, the Apple firmware in this regard is very similar, and requires GOP. On the other hand the cMP3,1 firmware requires UGA.

Nothing you are seeing in the boot menu on OpenCore requires UGA (regardless of which machine it is on, and regardless of what the native firmware UI on that machine requires).

I understand that early mac OS X boot does require UGA. So depending on how you set up OpenCore, you either will or will not see early stage boot progress, on early macOS. And something similar to the set-up required for this is what will be required to enable the firmware UI on the Mac Pro 3,1. Plus something similar to my existing driver, to encapsulate the required parts of OpenCore as a stand-alone firmware driver.

And the 3,1 fw, as you probably know, is not true uefi but a hybrid efi, I've been told... not sure if that makes a difference? Now, flashing it with a true uefi bios? That would be hilarious!