You need to be aware of the OpenCore
WriteFlash quirk too. Only if it's set will the variables in config.plist affect things outside of OpenCore too.
Got a tip for us?
Let us know
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
- Thread starter Bmju
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
If OC fails or canceled or has WriteFlash set (or one of those conditions), then the black background color is saved to NVRAM which affects Apple Boot Picker. The old Apple Boot Picker for Macs of this era isn't smart enough to draw the text as white in that case (at least that's true for my MacPro3,1). Black text on a black background is invisible so I choose a non-standard color for Open Core, such as light blue, which will allow the text in the old Apple Boot Picker to be visible.
I'm not sure about the 'fails or is cancelled' part. OpenCore (or anything else) only changes the colour of the native boot picker iff it writes a permanent (non-volatile) value to the
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor NVRAM variable.EDIT: Btw not being able to change its colour to write on black must be a feature of older firmware only (which I wasn't aware of before), since cMP 144.0.0.0.0 definitely _can_ change its colour to work fine on a black background.
I'm not sure if there was any such plan before my time (as you know, quite a lot of OpenCore's history falls into that category), but not that I'm aware of since, and I would say no, and unlikely.
That "anything else" can be the terminal command:
nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor=blah blah whether
WriteFlash is enabled or not. Right ?I think I remember reading something by @vit9696 some time ago (here or elsewhere) about OpenCore eventually being installed in firmware. Given that OpenCore originates from The Hermit Crabs Labs, who are also behind Ozmosis (a bootloader installed in firmware), this would make sense. Of course, if there even ever was such an intention, it is very possible that it is no longer part of the plan!
Yes. The only thing that would prevent _that_ from working (i.e. affecting the native firmware UI) would be if you are using the fairly recently added emulated NVRAM support from OpenCore.
Regarding
github.com
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor, I don’t believe that it can be set natively (outside OC?) for MacPro5,1. This is part of several oddities that seem to revolve around the theme protocol in that machine’s firmware:Inconsistent color theme in verbose mode · Issue #1741 · acidanthera/bugtracker
On some legacy Macs, the second-stage boot screen is not as expected when booting in verbose mode: The Apple logo is white and the background and progress bar are gray. This oddity can be observed ...
github.com
Hmm - yes - there is a lot of complexity here! Some variables cannot be set normally in macOS, but can be enabled via SIP, or set in Recovery. Some other variables (such as gpu-power-prefs, on some machines) have additional firmware level security (which carries over into the OS, via UEFI runtime). (In addition to what sounds like a separate macOS bug which you identified in that bugtracker issue.)Regarding4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor, I don’t believe that it can be set natively (outside OC?) for MacPro5,1. This is part of several oddities that seem to revolve around the theme protocol in that machine’s firmware:
Inconsistent color theme in verbose mode · Issue #1741 · acidanthera/bugtracker
On some legacy Macs, the second-stage boot screen is not as expected when booting in verbose mode: The Apple logo is white and the background and progress bar are gray. This oddity can be observed ...
Hello!
I have a genuine Mac Pro 5,1 and a Sapphire RX 580. As I want to be ultra careful, & I am using Martin Lo's OpenCore package, this combination uses "DirectGopRendering" in the OpenCore config, would I have to add the "EnableGopDirect.ffs" to the firmware and add "EnableGopDirect.efi" as a driver to OpenCore?
All assistance is most appreciated!
I have a genuine Mac Pro 5,1 and a Sapphire RX 580. As I want to be ultra careful, & I am using Martin Lo's OpenCore package, this combination uses "DirectGopRendering" in the OpenCore config, would I have to add the "EnableGopDirect.ffs" to the firmware and add "EnableGopDirect.efi" as a driver to OpenCore?
All assistance is most appreciated!
As mentioned the 1st Post, purpose of Pre-OpenCore GOP support is to enable the native Apple boot picker and early macOS boot progress bar display on non-natively supported GPUs, before, or even without, the rest of OpenCore.
So for example if you hold the Alt/Option on the keyboard straight after the Apple Chime, you will see the Apple Start-up Manager screen to select the the drive to boot...this is before OpenCore starts. If you do not use OpenCore, you will see Apple's native startup UI and progress bar on many of the listed GPU's on the 1st post.
That is achieved by adding to your existing Mac BootROM with the EnableGOP.ffs or EnableGopDirect.ffs.
For your RX580 EnableGop.ffs is sufficient.
The EnableGopDirect.ffs is for adding this feature to your existing Mac BootROM if have a GPU that requires DirectGopRendering setting in OpenCore config.plist file; e.g. Radeon VII GPU.
The EnableGop.efi and EnableGopDirect.efi are for adding this feature to your GPU's firmware instead of your Mac's firmware. There's a separate process for flashing your GPU.
Only one is necessary....flashing your Mac or flashing your GPU.
This is a really great feature addition to your Mac but you strictly do not need it if you are happy with the fact that OpenCore already shows you the boot progress bar and can even display OpenCore's Startup Managers (or boot picker) always at boot up or only if you hold the Alt/Option/Esc key (depending on how it's boot picker is configured).
Read the warning of the 1st post !
If you do not know what you are doing then you could brick your Mac or your GPU !
Last edited:
Regarding4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:DefaultBackgroundColor, I don’t believe that it can be set natively (outside OC?) for MacPro5,1. This is part of several oddities that seem to revolve around the theme protocol in that machine’s firmware:
Inconsistent color theme in verbose mode · Issue #1741 · acidanthera/bugtracker
On some legacy Macs, the second-stage boot screen is not as expected when booting in verbose mode: The Apple logo is white and the background and progress bar are gray. This oddity can be observed ...
@cdf From some quick tests, it seems you are right (of course! ;-) ), you cannot set this variable from within macOS (not even in Recovery, and/or not even with SIP disabled) on the 144.0.0.0.0 firmware. (However I am sure you can on the MacPro3,1, as @joevt reported.)
A few added complexities, for anyone trying to understand how all this behaves:
- If you do not override the UserInterfaceTheme protocol in config.plist, then the native implementation is already set up and running, using the colour value corresponding to the NVRAM state from before OpenCore started, which means OpenCore doesn't show the colour it has just set.
- You can verify this by restarting directly into the native picker, at which point it *does* take on the colour which OpenCore has set, and so will OpenCore if you go directly to that next.
- The Apple User Interface Theme protocol has a default colour, which is light grey on this firmware, used if the NVRAM variable is not present.
- macOS seems to be deleting this variable, presumably to force a reset to the default colour.
- Note that Big Sur, for instance, is deleting the value, not setting it to black as you might have expected; so resulting in grey on this firmware.
Last edited:
Saying "ozmosis borked it" is the same as saying this gun shot at me and wounded me. Ozmosis bios was designed for a specific motherboard and it was working fine on it. The moment you start tinkering with your bios you have to have a back up plan and be prepaid for a brick and for a recovery from the brick. If you are not prepared from a brick stay away from your bios.
I know and it’s why I prefer that OC stays as is. You know that a lot of people had their BIOS modded by the folks at Hackintosh-Forums.de and had no problems but, yes, s..t could happen and I wasn’t prepared.
Will OC be designed for one Apple machine (or Intel MB) in the eventuality it would be necessary to embed it in the BIOS? I doubt…
BTW, I RMA’ed the board, bought a second identical one awaiting the first one and… reinstalled the Oz BIOS, me poor « unprepared » guy. It worked until I finally shifted back to Clover. Do I have the right to « bork » my board even if not prepared? Do I have your permission?
Last edited:
There is a change in Radein VII in the new Opencore 0.9.0 EnableGopDirect.ffs Has anyone tested it? The previous one didn't work well for me.....
Thank!
Thank!
Can you try?
Based on your reports earlier in this thread, I believe OpenCore never really 'fixed' the issue with the Radeon VII, but more got lucky that a certain version of the code pinged the driver's memory layout to a state where the caching was right. It's possible we got something similar with EnableGop 1.1.
Note: I set myself a rule with EnableGop versioning to only increase the version number if there is a significant functional difference. The driver is rebuilt automatically at every release, and may not be binary the same, even if the version number is the same. The functional difference between the initial release and 1.1 is the fix for verbose boot lines appearing over the picker, which does indeed (also) apply to the native picker when enabled by EnableGop, and is fixed in EnableGop by the code change which fixes it in OC.
Sure. So, I will re-make another ROM with EnableGop 1.1 ffs, then test it (disable both ProvideConsoleGop and DirectGopRendering).
If can see boot screen but buggy, then I will try EnableGopDirect 1.1 ffs.
Thank you, that'd be great!
As ever you really don't need to disable the related OpenCore parameters, though you can. ProvideConsoleGop really won't do anything if it's already been provided. DirectGopRendering will, in fact, provide the same thing twice, but it is more or less harmless. I tend to leave the main OC settings alone, if I'm just testing.
Last edited: