That is correct. I believe this is normal as well based on my previous observations @Dayo correct?
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
About 'GOP exists on ConsoleOutHandle and has 0 modes', it's definitely that. I've worked on it recently. I just wouldn't necessarily have remembered it was exactly that without going back to the code, https://github.com/acidanthera/OpenCorePkg/blob/master/Library/OcConsoleLib/ConsoleGop.c#L113-L134, except that the log makes it pretty clear anyway.
If you're asking for second opinions about the lack of the second part of the progress bar, then thanks, and they're welcome. Though I have indeed asked around, and the general consensus already is - what I said - i.e. it's normal and/or unavoidable on many non-natively compatible cards. I'm not quite sure why @MacNB2 feels they saw a difference though, and so am still open to exploring it, if there are contrasting cases where this (unavoidable?) issue does and doesn't appear, on the same system with the same GPU.
Thanks for checking the code.
So I just installed EnableGop.ffs back into the BootROM and flashed it.
I installed my drive with Mountain Lion, High Sierra and Mojave and booted them one after other to see if that's where I remembered seeing full progress bar.
Here's what I saw :
- Mountain Lion: Grey Apple Logo with spinning progress wheel which eventually stops and immediately shows Login screen (just like pre OpenCore boot....i.e. like native boot). 👍
- High Sierra: Apple Logo with Progress bar that completes 100% and fades to Login Screen (just like pre OpenCore....i.e. like native boot). 👍
- Mojave: Apple Logo with Progress bar just over 50% then screen clears (slight white flash) then 2nd stage Apple logo appears with progress bar to 100% followed by Login screen (similar to pre OpenCore....i.e. native boot). 👍
May be...as Mandalorian says..."This is the way"
Yes, the log is showing OpenCore, via its ProvideConsoleGop quirk, fixing the MP51's Mutant ConOut GOP instance.
You should remember this as you did the testing that helped the OpenCore dev sort it out. I suppose Feb 2020 counts as prehistory in OpenCore terms: https://forums.macrumors.com/posts/28187069
PS for others, many of the settings mentioned in the linked post are no longer in OC as standalone options. Separately, the ProvideConsoleGop setting requirement for showing the OC screen is MP51 specific and does not apply to the MP31; which will show the OC screen with or without this setting IIRC.
Last edited:
Interesting. There's clearly something going on here. Since - everyone assures me - this has not changed recently (neither from EnableGop, nor from any other recent change), then I assume it was looked into in detail at some point before, and accepted as unavoidable, but it's not something I've looked into yet. It's possible (if still unlikely) that something could improve this, especially given that some macOS versions don't show the issue. I think (not checked yet) that it is very likely to do with changing gfx mode at that point in the boot sequence. Since there is limited control over what modes you _can_ select in GOP (e.g. you cannot specify the refresh rate) then this may be enough to explain the issue. Something to add to the (ever growing...) list of interesting things still to research in OpenCore.
Last edited:
If you can please send the K6000 ROM as well, I can compare and contrast what is going on in them.
I inserted EFI gop enabled into the bios of the Quadro P5200M. Now the backlight works when turned on.
I had an idea to develop a small and cheap board to implement Pre-OpenCore GOP by reading and updating NVRAM without hassle.
Please see the OpenNVRAM project
Let me know what you think!
Please see the OpenNVRAM project
Let me know what you think!
Thanks for the report. This actually enabled backlight when it didn't have it before using just OC?
I can't understand, OpenCore doesn't work in my MacPro 5.1, I never can boot with hold/Option key, doesn't works on Rx580 shappire metal (Catalina from Dosdude1). It works ok and jumps between OSx versions from Preferences, ever never open core picker boot available in my case.
Have you flashed your MacPro BootROM with EnableGop.ffs added OR flashed your RX580 with EnableGop.efi added ?
Neither of the flashing is necessary to enable OpenCore to work on the MacPro 5,1.
EnableGop is an optional feature not related to the functioning OpenCore.
Seems like you have posted in the wrong thread and I suggest you read the OpenCore thread first and ask there.
It's correct that you see something (the default grey background colour) before OpenCore. But that's not really the backlight coming on. It is the GOP protocol being enabled and producing some output for the monitor.
It seems you misunderstand how OpenCore works, that’s why you believe it never work.
By holding Option key to boot, you are actually commanding the 5,1 to use the natively Apple boot manager, but don’t let it boot to OpenCore. Then of course OpenCore won’t work. You asked the cMP to NOT to boot OpenCore.
For OpenCore core boot picker to show up. You need to have a graph card that has working UEFI GOP, but not Metal. Metal is OS level API, can’t do anything to provide boot screen.
If you use a “known good” OpenCore EFI folder, but stop can’t see the boot picker. Then there are few possible reasons.
1) Your RX580 was flashed for mining etc. Therefore, the GOP part is now broken. In this case, you can re-flash it with another known good factory ROM.
2) The card never flashed, but with a factory ROM which has no GOP to work on cMP. This happen occasionally, usually on the card that has dual ROM. If your card has dual ROM, try to boot from another ROM. If that’s a single ROM card, then you have to flash it.
3) Your monitor has a very long wake up time. E.g. it takes more than 10s to wake up, therefore, you can’t see the boot picker before time out, but straight to the Apple loading screen. You can check the OC config, increase timeout value (e.g. 30s). Then you may able to see the boot picker.
4) The port you are using cannot display the GOP boot screen. But another port actually works.
5) You programmed OpenCore config to not show boot picker by default. In this case, you should hold Esc key to call the boot picker, but not Option key.
Anyway, the EnableGop tool in this thread is actually able to fix that “Option boot” issue.
You can follow the instruction to create a Mac Pro BootROM with EnableGop injected. Then once you flashed the cMP with this new ROM, you will able to hold Option key to boot (with almost any modern graphic card that can utilise UEFI GOP). However, the logic still the same, when you hold Option key to boot, you are using the native Apple boot manger, not OpenCore boot picker.
Which MacOS do you recommend to read/inject/write rom. I have Mojave/Catalina and Ventura on MacPro5,1. Also how will this work with a graphics card already flashed with bootscreen rom or a Georgics card like that naturally displays bootscreen such as my original non metal card ATI 5770.
Another question will it matter if I boot using rEFInd+ boot into sieve natively or boot from EFI Opencore for this procedure.
I know it’s a lot of questions but to make sure I don’t screw up.
To be really safe I realize I should read/save the rom with a rom programmer.
I have read all my roms on PC laptops when I was playing around with flashing unhidden menus but I could use my clip onto the 6 pin rom without desoldering and read with my Xeltek super pro programmer but I don’t think you can do this on the mac need to power one of the pins and believe it’s more involved than just that.
Thanks.
Another question will it matter if I boot using rEFInd+ boot into sieve natively or boot from EFI Opencore for this procedure.
I know it’s a lot of questions but to make sure I don’t screw up.
To be really safe I realize I should read/save the rom with a rom programmer.
I have read all my roms on PC laptops when I was playing around with flashing unhidden menus but I could use my clip onto the 6 pin rom without desoldering and read with my Xeltek super pro programmer but I don’t think you can do this on the mac need to power one of the pins and believe it’s more involved than just that.
Thanks.
Last edited:
In fact none of those matter. If you can program the ROM, it doesn't matter which OS you are in or whether you booted via OpenCore (or rEFInd+) or not. (It does matter whether or not you _can_ program the ROM, of course. So you have to very-long-press-and-hold the power button on start up (power light flashes, beep sound); and on macOS, but not Ubuntu (or other Linux), you also need SIP disabled.)
Hi, my updated script definitely runs, and reports success, with those two ROMs. Please can you try the results for those two cards (attached) and report back whether they work or not? Thank you.
Ah now for the next question since i forgot you can recover from a bad rom via the long press and CD recovery rom if the process fails or the severity of what went wrong? I will follow the thread on this one but I’m think if it’s really bricked if this method would still work to recover it.
Last edited:
There is no easy way to recover from a bad rom flash which results in an unbootable machine.
If you flashed to vBIOS, you can reflash it using a CH341A and a SOIC clip, either using another machine, or using the same machine with a different graphics card.
If you flashed to main firmware, you cannot recover except with a Matt card or by desoldering your NVRAM chip.
But there are multiple reports of EnableGop _not_ causing an unbootable machine, if you flash to main firmware (or vBIOS, for that matter) carefully following the instructions.
That's all the information I can provide - you have to take it and then make your own decision whether to proceed.
I tested all versions EnableGop(Direct) 1.0-1.2. A little bit of sharing of how I use software flashing.
1) It’s very very easy to use the DXEIinject to create the cMP BootROM. Highly recommend this.
1a) After create the ROM, double check that the new ROM image's size is same as the original ROM image (the size should be 4,194,304 bytes in Finder for Mac Pro 5,1).
1b) Then use UEFItool to locate EnableGop(Direct).
1c) And then, use Macschrauber's CMP Rom Dump tool to examine the newly create ROM image. If the original image is a clean re-constructed ROM image, the result should looks something like this.
Let it double check the existance of EnableGop(Direct), and calculate the checksum etc.
If all these three steps are done. The ROM image should be fairly safe to use.
2) Then shutdown and hold power button to put the cMP into firmware flashing mode. I flashed my cMP in Mojave, Catalina, Big Sur, Monterey. No issue so far. So I will say for this kind of one off flashing. Any macOS can do the job, and booting via OpenCore is also fine.
Before flash the new ROM image into the cMP, always backup the current ROM (e.g. by using ROMTool).
2a) After use ROMTool to flash the cMP. Do NOT reboot. But use Macschrauber's CMP Rom Dump tool to dump and examine the newly create ROM again. It should gives you identical result as the previous check.
2b) Then use some Hex tool (e.g. Hex Friend which has a nice GUI. Or as simple as hexdump in Terminal) to open the new dump (from Macschrauber's CMP Rom Dump tool, should be inside download folder). Also open the ROM image that created by DXEInject. And compare them. There should be no difference between the two ROM image.
2c) And then, check the ROM image size (dump from Macschrauber's CMP Rom Dump tool), which is 4,194,304 bytes in Finder.
After these three extra steps. I believe should be safe enough to reboot. If any one of the above step show strange result, do NOT reboot / shutdown, but flash a known good ROM image back in (e.g. a tested clean re-constructed ROM. Or at least, the ROM image you've dumped just before flashing. Or in worst case, a serialess BootROM extracted ). And dump out the ROM image again to examine it.
I straightly follow the steps above. So far, all flashing are good, and my cMP still working.
3) Last but not least, for OpenCore users, before reboot, you better mount the EFI partition and re-bless OpenCore. This can ensure the cMP will reboot to the OpenCore copy you want automatically (even though you should able to hold Option key the select OpenCore in the Apple native boot manager now. But better assign the OpenCore you want now, just in case the boot screen doesn't work. And you end up stuck at black screen, with an unsupported macOS, which can be a bit hard to recover).
1) It’s very very easy to use the DXEIinject to create the cMP BootROM. Highly recommend this.
1a) After create the ROM, double check that the new ROM image's size is same as the original ROM image (the size should be 4,194,304 bytes in Finder for Mac Pro 5,1).
1b) Then use UEFItool to locate EnableGop(Direct).
1c) And then, use Macschrauber's CMP Rom Dump tool to examine the newly create ROM image. If the original image is a clean re-constructed ROM image, the result should looks something like this.
Let it double check the existance of EnableGop(Direct), and calculate the checksum etc.
If all these three steps are done. The ROM image should be fairly safe to use.
2) Then shutdown and hold power button to put the cMP into firmware flashing mode. I flashed my cMP in Mojave, Catalina, Big Sur, Monterey. No issue so far. So I will say for this kind of one off flashing. Any macOS can do the job, and booting via OpenCore is also fine.
Before flash the new ROM image into the cMP, always backup the current ROM (e.g. by using ROMTool).
2a) After use ROMTool to flash the cMP. Do NOT reboot. But use Macschrauber's CMP Rom Dump tool to dump and examine the newly create ROM again. It should gives you identical result as the previous check.
2b) Then use some Hex tool (e.g. Hex Friend which has a nice GUI. Or as simple as hexdump in Terminal) to open the new dump (from Macschrauber's CMP Rom Dump tool, should be inside download folder). Also open the ROM image that created by DXEInject. And compare them. There should be no difference between the two ROM image.
2c) And then, check the ROM image size (dump from Macschrauber's CMP Rom Dump tool), which is 4,194,304 bytes in Finder.
After these three extra steps. I believe should be safe enough to reboot. If any one of the above step show strange result, do NOT reboot / shutdown, but flash a known good ROM image back in (e.g. a tested clean re-constructed ROM. Or at least, the ROM image you've dumped just before flashing. Or in worst case, a serialess BootROM extracted ). And dump out the ROM image again to examine it.
I straightly follow the steps above. So far, all flashing are good, and my cMP still working.
3) Last but not least, for OpenCore users, before reboot, you better mount the EFI partition and re-bless OpenCore. This can ensure the cMP will reboot to the OpenCore copy you want automatically (even though you should able to hold Option key the select OpenCore in the Apple native boot manager now. But better assign the OpenCore you want now, just in case the boot screen doesn't work. And you end up stuck at black screen, with an unsupported macOS, which can be a bit hard to recover).
Great write up. 👍
The first post does not list version 1.2. Where did you get that from and what are the differences between 1.1 and 1.2 ?
BTW, in step 2a above isn’t it easy to use just
diff command from terminal to compare the two binary ROM images ?Yes, any method can compare the ROM.
1.2 still at beta stage. Bmju is helping us to solve the Radeon VII's issue. Therefore he send me the direct link to perform beta testing. Anyway, at this moment, regardless if the new version can fix the Radeon VII's issue, it should able to provide a noticeable performance improvement. In my own test, the rendering speed can be up to 32x faster.
Got it.
32x is great performance improvement !
Is that just for Radeon VII or for all GPUs ?