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.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Did you make your own EFI folder base on post#1 of this thread?
Also, what happen if you select BootKicker?
Idk, but I think so. I bought this Mac Pro a year ago with installed OC. Mac worked perfectly all year long. But today this happens.
After selecting Bootkicker — black screen and nothing.
It does look like your SSD, you have basically got no boot options except those being provided directly by OpenCore. And it looks like OpenCore has automatically switched to auxiliary mode, because there are no other boot entries.
Presumably this is what you see even if you force power off and restart?
It is always worth trying the Reset NVRAM option.
It is also worth opening your Mac Pro and reseating your SSD. Or even taking it out and plugging it into another Mac to check it is readable.
You did not say which version of macOS you are running, nor which graphics card you have. But except with the very newest versions of OpenCore, the BootKicker option will not do anything on a non-natively supported graphics card.
Also, it is basically certain that this is not caused by OpenCore, and if you are running a version of macOS which is only supported via OpenCore, then removing it definitely won't help!
Last edited:
The Mac was in sleep mode for about 24 hours, I clicked on the keyboard to wake it up and saw this problem (before that I had not touched any settings of macOS, OC or apps, had not changed any of the accessories and hardware, maybe only the mouse and keyboard in the USB ports)It does look like your SSD, you have basically got no boot options except those being provided directly by OpenCore. And it looks like OpenCore has automatically switched to auxiliary mode, because there are no other boot entries.
Presumably this is what you see even if you force power off and restart?
It is always worth trying the Reset NVRAM option.
It is also worth opening your Mac Pro and reseating your SSD. Or even taking it out and plugging it into another Mac to check it is readable.
You did not say which version of macOS you are running, nor which graphics card you have. But except with the very newest versions of OpenCore, the BootKicker option will not do anything on a non-natively supported graphics card.
Also, it is basically certain that this is not caused by OpenCore, and if you are running a version of macOS which is only supported via OpenCore, then removing it definitely won't help!
Rebooting didn’t help
Thanks, I forgot to mention my specs
MacPro 5.1 2012 6-core Xeon
Monterey 12.3
Radeon RX560 4gb (metal supported)
See you can't remove OpenCore, at least. Monterey definitely cannot boot without it. :-/ (And as you will see, lots of people are successfully using it - it isn't the issue, here, honest!).The Mac was in sleep mode for about 24 hours, I clicked on the keyboard to wake it up and saw this problem (before that I had not touched any settings of macOS, OC or apps, had not changed any of the accessories and hardware, maybe only the mouse and keyboard in the USB ports)
Rebooting didn’t help
Thanks, I forgot to mention my specs
MacPro 5.1 2012 6-core Xeon
Monterey 12.3
Radeon RX560 4gb (metal supported)
Remove, re-seat, test (in another Mac) the SSD?
I'm very happy with Monterey! But I thought uninstalling it was the solution to reinstalling OC
I tried reconnecting the SSD and reboot - didn't work.
Reconnecting to a different slot and reboot - didn't work.
I connected the SSD via USB to my old MBP 17' (with no OS) but via Recovery Mode - SSD is not readable. Is that why OC can't see the Data?
I've no idea what's happened to your SSD, but I'll say again, OC does not do that to SSDs. No reports of it all, from LOTS of users. (Also, since I know the codebase pretty well, no, there is no code in there to wipe SSDs. ;-) )
So yes: no Mac, with our without OpenCore as a bootloader, is going to be able to boot macOS from an unreadable SSD, I'm afraid.
Perhaps look at the broken drive with Disk Utility on a Mac (if you can get it to show anything at all), or one of various HDD tools on Linux, to see if you can recover anything?
But the simplest solution here seems like a new SSD, and a complete reinstall of Monterey; you'd need to make an install USB using another Mac.
You are absolutely right! Maybe I misspoke, but I'm pretty sure it wasn't OpenCore that broke my SSD
there could be a million other reasons for that.I'm going to try and install a new SSD now. Next, can I just follow the basic OpenCore installation instructions?
I suggest that you follow post #1 to the letter. By the way, OC 0.8.9 is about to be released. You might want to wait for a few hours.
The guide has been updated to OpenCore version 0.8.9.
🎉 Version 0.8.9 marks the beginning of a new era for the classic Mac Pro: Native boot-screen support for standard graphics cards! @Bmju has done an outstanding job of expanding the OpenCore project to include drivers that can be added to your Mac's firmware. It is now possible to get pre-boot display with a standard graphics card without having to go through OC first! To read more about this amazing contribution, head over to the pre-OpenCore GOP thread. Step-by-step instructions have also been added to the guide (see Appendix: Native boot-screen support).
🎉 Version 0.8.9 marks the beginning of a new era for the classic Mac Pro: Native boot-screen support for standard graphics cards! @Bmju has done an outstanding job of expanding the OpenCore project to include drivers that can be added to your Mac's firmware. It is now possible to get pre-boot display with a standard graphics card without having to go through OC first! To read more about this amazing contribution, head over to the pre-OpenCore GOP thread. Step-by-step instructions have also been added to the guide (see Appendix: Native boot-screen support).
It is wonderful that @Bmju and a few others have figured out a way to inject GOP features in the cMP ROM, but I don't quite understand why this is being distributed as an OpenCore component or add-on. As far as I can see, this is a most excellent addition to a cMP and possibly other old Macs as well, but, won't Mojave users equally benefit from it even if they never use OpenCore?
Well why not? It is part of the OpenCore project, it uses OpenCore code directly. As per the instructions here, there is no need to *install* OpenCore in order to get it. Yes, you have to download OpenCore, to get the current, built versions of the files. But the steps for installing it, from then, do not involve actually installing OpenCore!
EDIT: Given that info, and if there is a relevant thread which you wish to announce it on, you are very welcome to.
^No, I have nothing against it. Just curious why it is being distributed with OpenCore, although I understand that, historically, it makes perfect sense. Many thanks!
I figured it out.
Not to say I could have done it without the support and community acknowledged here, or without OpenCore itself, including the earlier work in OpenCore by several in this community which this builds on - I couldn't! If you are referring to the fact that @Syncretic figured it out before me you are correct, though the two projects were developed completely independently.
Well again, it's not just historical. It uses OpenCore code directly: as mentioned, it very directly builds on earlier research in OpenCore. I actually tried initially to do it in a non-OpenCore way. I thought that the remaining bits, after linking a late arriving GOP to the Apple Firmware UI - which was also my own research, also now included in OpenCore - would be simple. But they were not. I realised I would end up reinventing several wheels, already running smoothly in OpenCore, and already extensively tested on multiple systems, less successfully than the originals! Finally, I suppose it does also give anyone downloading it the assurance that it has been reviewed by senior members of, and is included in, a well-known and trusted project. Those are the reasons I can think of. Enjoy.
Last edited:
The guide for enable_gop injection in this thread tells the "traditional" way of identifying the rom chip, booting an old system and so on.
Anyway, my dumper identifies the chip by probing, also it has not the need to be run in an old supported OS. It runs also in Catalina, Big Sur, Monterey and even Ventura.
csr_allow_untrusted_kext is sufficient for loading directhw.kext as a helper kext dynamically to dump and to flash the firmware.
Also it identifies the GUID of the enable_gop injection DXE.
Plus the additional analyse it does.
The links:
c.gmx.net
https://www.dropbox.com/s/kr74r2ft0nrvp7n/Macschrauber's CMP Rom Dump.dmg?dl=0
Anyway, my dumper identifies the chip by probing, also it has not the need to be run in an old supported OS. It runs also in Catalina, Big Sur, Monterey and even Ventura.
csr_allow_untrusted_kext is sufficient for loading directhw.kext as a helper kext dynamically to dump and to flash the firmware.
Also it identifies the GUID of the enable_gop injection DXE.
Plus the additional analyse it does.
The links:
Ihr persönlicher Freigabelink | GMX Cloud
Mit diesem Link erhalten Sie Zugriff auf die mit Ihnen geteilten Daten.
Last edited:
Perhaps I'm being overly conservative here... Well, if we can get @tsialex to approve this approach, I'll be more than happy to revise the guide (in fact, it's approaching the character limit for a single post)
If one has the ability to read it with Mavericks it's far more easy as you don't need to fiddle with S.I.P.
For my own needs I use Mavericks most of the time for hardware related stuff.
To get an accurate dump that is not influenced by OpenCore, a native booting system is the system of choice. But not everyone has the possibility to quickly boot an old system. Or he doesn't have the compatible hardware for it.
The Dumper package includes a version for Mavericks of course ;-)
For my own needs I use Mavericks most of the time for hardware related stuff.
To get an accurate dump that is not influenced by OpenCore, a native booting system is the system of choice. But not everyone has the possibility to quickly boot an old system. Or he doesn't have the compatible hardware for it.
The Dumper package includes a version for Mavericks of course ;-)
Maybe you can use something like this to create a portable boot solution with Mavericks and your tool?
Mavericks is also what I use now for dumping and flashing. With EnableGop (or @Syncretic's firmware), it's a great choice even with a standard modern graphics card!
@Macschrauber, I wonder if the checks done by your dumper could also be used to validate the integrity of a dump. That way, even if done through OC, there's a certain assurance that the "firmware update" will be successful.
@Macschrauber, I wonder if the checks done by your dumper could also be used to validate the integrity of a dump. That way, even if done through OC, there's a certain assurance that the "firmware update" will be successful.
If dumping is the problem I would recommend using a lightweight Linux on a thumb drive. I have GRML Linux in my tool box, it has flashrom on it what can read and write our firmware.
Analysing can be done later in almost any Mac OS with the Dumper by loading the .rom file.
That would be a dream come true. That can't be achieved by any tool. I wish we had some kind of a firmware emulator thing, a virtual machine we can load the firmware into and run it like a real Mac Pro.
I'd recommend the use of Uefi Tool to check at least the checksums after injecting a DXE. The Dumper verifies checksums in the FSys Stream, but that's not touched by injecting DXEs, it's more a firmware reconstruction thing.
EnableGOP Basic check by Uefi Tool:
Perhaps I'm being overly conservative here... Well, if we can get @tsialex to approve this approach, I'll be more than happy to revise the guide (in fact, it's approaching the character limit for a single post)
The real problem is that nothing is ever 100% safe, even Apple's efiflasher fails while flashing and the end result is a brick. The process seems secure enough, but once you start to do it very frequently, you learn very fast that is prone to failure.
I recently had several bricks while flashing from Monterey, testing the PiquaBoot releases that helped Syncretic develop the NAVI 2x HII support with my RX 6600. So, if even with a dedicated Mac tailored specifically for flashing still bricks, imagine someone with a barely working crazy unsupported config?!?
The "traditional way" is just the steps we found over the years to make the dumping/flashing process the safest and to have minimal flashrom failures, i.e. bricks. We have to always remember that while we can repair a brick with some work, end users can't.
Since is very time intensive to repair a bricked Mac Pro, I've also moved to a Mavericks dedicated disk to minimize failures and to not have to mess with SIP.