Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
@Dayo is this the only code for the 1st stage on cMP3,1:
Code:
// Extended 'HandleProtocol'
// Routes 'HandleProtocol' to 'OpenProtocol'
STATIC
EFI_STATUS
EFIAPI
HandleProtocolEx (
    IN   EFI_HANDLE  Handle,
    IN   EFI_GUID    *Protocol,
    OUT  VOID        **Interface
) {
    EFI_STATUS Status;

    Status = gBS->OpenProtocol (
        Handle,
        Protocol,
        Interface,
        gImageHandle,
        NULL,
        EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL
    );

    return Status;
} // EFI_STATUS HandleProtocolEx

STATIC
VOID
ReMapOpenProtocol (
    VOID
) {
    // Amend EFI_BOOT_SERVICES.OpenProtocol
    OrigOpenProtocol    = gBS->OpenProtocol;
    gBS->OpenProtocol   = OpenProtocolEx;
    gBS->Hdr.CRC32      = 0;
    gBS->CalculateCrc32 (gBS, gBS->Hdr.HeaderSize, &gBS->Hdr.CRC32);
} // ReMapOpenProtocol()

Maybe you can add it to OC with pull request?
 
Took a look at this and there is a specific fix for this issue in RefindPlus which is why it works there.

Basically adapts some OC code from ProvideConsoleGOP which will run on a MacPro5,1 and fix the loading screen but will not run on a MacPro3,1 even when that flag is on. This is because the active function implementing ProvideConsoleGOP in OC returns early on MacPro3,1 as it does not have the Console GOP issue that the MacPro5,1 has.

The RefindPlus fix does not propagate to OC when chain-loading as all System Table changes done in RefindPlus are reverted (the original is stashed before any changes are made) before handing off to other loaders.

Basically, the fix is undone when you decide to load OpenCore or any other loader. Just out of caution so that loaders receive original System Tables without RefindPlus changes.

Updated your OC issue to point them at the fix.
Thank you Dayo. I do believe I understand. Appreciate you jumping into my GitHub issue. Hopefully Vitaly will be able to parse GOP over UGA with a code update. It could certainly help others out there with similar configurations.
 
Maybe you can add it to OC with pull request?
A bit more complex as Vit pointed out.

That fix actually only works for GPUs with GOP. How to implement into OC needs thinking as needs changing the System Table. Possible ... just needs coordination with Vit on what is acceptable for them. Also, just found potential race condition in the RP code which I need to fix.

Anyway, this specific issue is UGA related. Need to find out how/why it works in RP and not OC.

The suggested GOP on UGA thing would be great though so maybe would be better to wait for them to do that as useful in many ways. Remember @joevt mulling about this a while ago?
 
Excuse me the question, I know this is not the perfect thread for it, but I can´t find any information. This OpenCore method will run in a Macbook Pro 17" 2011? I found this and it says thad sound is not supported. Right? Thanks.
 
Just finished installing OpenCore 0.6.6 on my Mac Pro 5,1 dual 2.93ghz with Radeon RX580, running latest Mojave (software compability issues with newer Mac OS stuff) so far everything seems ok but because I have two monitors hooked up I don't see the actual screen where I can choose which drive I should boot off.

Is this a know issue with multiple monitors?

I checked in terminal and Open Core is definitely installed.
 
Hey 205Maxi. So you got 384GB working? That's perfect. It's a triple channel CPU anyway. Personally, I was never going to use 8x64 anyway. From the screenshot you sent it looks like that's the limit you are hitting? Is that the issue you mean or is it something else? Are you saying it doesn't work because it's not reporting properly in the RAM section?
This is posted in cMP 5,1 forum but if you look at the screenshot, his MP is not cMP. There are 12 DDR4 slots in that MP.
 
I am using Opencore 0.6.6. in my cMP 4.1>5.1 with Mojave and Big Sur 11.2.1, even with Hardware Accel.

Everything working very fine (thanks to all the people here, especially the main authors)

Sorry if my question is silly, but when I try to check my Opencore Version in terminal, I get this:
 

Attachments

  • Screenshot 2021-02-14 at 11.17.58.png
    Screenshot 2021-02-14 at 11.17.58.png
    139.2 KB · Views: 141
I am using Opencore 0.6.6. in my cMP 4.1>5.1 with Mojave and Big Sur 11.2.1, even with Hardware Accel.

Everything working very fine (thanks to all the people here, especially the main authors)

Sorry if my question is silly, but when I try to check my Opencore Version in terminal, I get this:
 
  • Like
Reactions: Enricote
Sorry if my question is silly, but when I try to check my Opencore Version in terminal, I get this:

The same thing happened to me recently. I could no longer read the opencore-version nvram variable, even if ExposeSensitiveData was properly set.

When I booted natively into Mojave to diagnose the issue, I realized that something was wrong with the NVRAM. Perhaps it was just a coincidence, but I could no longer bless other volumes. I did a 4-time NVRAM reset, which finally allowed me to boot into recovery. I disabled SIP, rebooted and promptly restored a clean backup of my BootROM. Afterwards, everything was fine.

We've been warned many times by @tsialex about the eventual fate of the SPI flash memory. If you haven't done so already, back up your BootROM! I also have a replacement chip ready to go.

MX25L3206E.png
 
The same thing happened to me recently. I could no longer read the opencore-version nvram variable, even if ExposeSensitiveData was properly set.

When I booted natively into Mojave to diagnose the issue, I realized that something was wrong with the NVRAM. Perhaps it was just a coincidence, but I could no longer bless other volumes. I did a 4-time NVRAM reset, which finally allowed me to boot into recovery. I disabled SIP, rebooted and promptly restored a clean backup of my BootROM. Afterwards, everything was fine.

We've been warned many times by @tsialex about the eventual fate of the SPI flash memory. If you haven't done so already, back up your BootROM! I also have a replacement chip ready to go.

View attachment 1729956
I would like to share a script with @Macschrauber permission for quickly checking the NVRAM of a dump.
You can compare the results before and after the NVRAM reset and see if the reset helps or not. If there is no difference then you have to worry.
 
The same thing happened to me recently. I could no longer read the opencore-version nvram variable, even if ExposeSensitiveData was properly set.

When I booted natively into Mojave to diagnose the issue, I realized that something was wrong with the NVRAM. Perhaps it was just a coincidence, but I could no longer bless other volumes. I did a 4-time NVRAM reset, which finally allowed me to boot into recovery. I disabled SIP, rebooted and promptly restored a clean backup of my BootROM. Afterwards, everything was fine.

We've been warned many times by @tsialex about the eventual fate of the SPI flash memory. If you haven't done so already, back up your BootROM! I also have a replacement chip ready to go.

View attachment 1729956
Thank you cdf!
@tsialex reconstructed my BootROM about three months ago!
I have tried to set ExposeSensitiveData but that doesn't change the issue. In fact I had never changed it. It Always set as basic config.plst from #1
Should I be worried?
Thanks!

edited 17:55: I fixed the issue reflashing my BootROM using the reconstruction made by @tsialex.
ExposeSensitiveData is in 3 (default) and I can check my Opencore Version
 
Last edited:
FYI to everone, not being able to connect with AFP seems in fact to be an OpenCore issue !
I just tested it and after adding WiFi support I finally can connect to my NAS again through AFP.
Note that the connections were never done over WiFI, but with Cable / LAN!
SMB connections are not affected by this and do not need WiFi support.
 
Thank you cdf!
@tsialex reconstructed my BootROM about three months ago!
I have tried to set ExposeSensitiveData but that doesn't change the issue. In fact I had never changed it. It Always set as basic config.plst from #1
Should I be worried?
Thanks!
You may dump out the BootROM now and have a check.

It's been tested that we can dump / flash the cMP's BootROM even boot via OpenCore.

Or, for diagnostic purpose, you may try temporarily boot via my OpenCore package. Which is known that can read the OpenCore version. Since it's a complete package for 5,1. As long as you don't mod anything, there should be no room for user error, and able to provide accurate test result.

For your info, if you boot from my latest 0.6.6 package. You should see your BootROM version change to 9144.0.6.6.0. This is a sign that you switched to my OpenCore package. Then you can try if you can check the OpenCore version in terminal.

If everything works as expected, you should see something like this.
Screenshot 2021-02-14 at 22.51.52.png
 
Should I be worried?
Thanks!
See post by @startergo above yours.

Dump your current BootROM, reboot and do a Triple NVRAM Reset (Four Chimes) and dump the BootROM again.
Run the script on both versions and see if there is noticeable difference.

@cdf ... could there be something with OC v0.6.6? Seems a lot of recent reports.
Been going over the RefindPlus code base as well but nothing jumps out.

I checked mine with the @Macschrauber script recently and found a hell of a lot of MemoryConfigs (22).
Previous checks had never got to higher than three until this sudden jump to 22 in the last month.

Triple Reset got it down back to 1.
Already crept back up to 7 since then

cc @tsialex
 
Last edited:
  • Like
Reactions: Enricote
The same thing happened to me recently. I could no longer read the opencore-version nvram variable, even if ExposeSensitiveData was properly set.

When I booted natively into Mojave to diagnose the issue, I realized that something was wrong with the NVRAM. Perhaps it was just a coincidence, but I could no longer bless other volumes. I did a 4-time NVRAM reset, which finally allowed me to boot into recovery. I disabled SIP, rebooted and promptly restored a clean backup of my BootROM. Afterwards, everything was fine.

We've been warned many times by @tsialex about the eventual fate of the SPI flash memory. If you haven't done so already, back up your BootROM! I also have a replacement chip ready to go.

View attachment 1729956
ROMTool identified my 2010 MP5,1 SPI flash chip as MX25L3206E. It stated though that it could be wrong and should be identified manually. Where is it located on the board?
 
Where is it located on the board?
U8700. See here:

 
  • Like
Reactions: Enricote
U8700. See here:

Thank you! Looks like I have MX25L3205D.

BTW, same issue here:
1613316393386.png
 
Last edited:
The same thing happened to me recently. I could no longer read the opencore-version nvram variable, even if ExposeSensitiveData was properly set.

When I booted natively into Mojave to diagnose the issue, I realized that something was wrong with the NVRAM. Perhaps it was just a coincidence, but I could no longer bless other volumes. I did a 4-time NVRAM reset, which finally allowed me to boot into recovery. I disabled SIP, rebooted and promptly restored a clean backup of my BootROM. Afterwards, everything was fine.

We've been warned many times by @tsialex about the eventual fate of the SPI flash memory. If you haven't done so already, back up your BootROM! I also have a replacement chip ready to go.

View attachment 1729956
There is a extremely simple way (simple here as in not need to know how the NVRAM works/check free space indicators/validate checksums and etc) to check if the garbage collection failed and the need to reflash with the clean dump:

A clean reconstructed never booted image have the Free Space Full Size as 65448 - this is for a fully empty store:
VSS_reconstructed.EMPTY.png


A normal working single CPU Mac Pro with 3 DIMMs have the Free Space Full Size usually around 45000 to 40000 - this is for a healthy working dump:
VSS_44781 - EFISystemNvDataFvGUID - VSS - Free Space - Full size.png


A normal working dual CPU Mac Pro with 8 DIMMs (DIMM configuration data and SPD caches stored by MemoryConfig NVRAM entries are what takes the most space inside the VSS store) have the Free space Full size around 35000 to 30000 - this is for a healthy working dump:
VSS_34808.png


A Mac Pro that the garbage collection is not working anymore will have less than 1/3 of Free Space Full Size available, less than 22000 bytes available. Any less than this and you usually start having problems.

This one has just 8921 and already corrupted the NVRAM volume:
VSS_8921.png


Where is the second VSS store?
VSS_8921_No 2nd VSS.png


I personally don't wait for the garbage collection to fail, I have a recurrent appointment on my calendar to flash the cleaned BootROM image every 3 months. Since starting doing it, I never had a brick or any NVRAM problems - even with all my crazy tests that bricked so much times my backplanes in the past.
 
Last edited:
@tsialex thanks for the post above. For someone not well versed in this, how does one go about by cleaning the BootROM image? I was thinking of just cleaning NVRAM 3, perhaps 4 times then dumping that and keeping the saved binary file for backup.
 
@tsialex thanks for the post above. For someone not well versed in this, how does one go about by cleaning the BootROM image? I was thinking of just cleaning NVRAM 3, perhaps 4 times then dumping that and keeping the saved binary file for backup.
If the NVRAM garbage collection already failed, cleaning the NVRAM will do nothing - only the secondary VSS store will be cleaned. If yours is functional yet, wait for the 5th chime and dump it.

For dumps where the garbage collection is not working and you don't have a backup dump, a reconstruction will be needed.
 
  • Like
Reactions: JeDiGM and amstel78
If the NVRAM garbage collection already failed, cleaning the NVRAM will do nothing - only the secondary VSS store will be cleaned. If yours is functional yet, wait for the 5th chime and dump it.

For dumps where the garbage collection is not working and you don't have a backup dump, a reconstruction will be needed.
This is what my dump shows. Looks like I'm bound to start having some troubles down the road?
1613320878912.png


So do I just hold down Command-Opt-P-R until I hear the 5th chime, boot into non-OC MacOS, dump the BootROM and compare? If I get closer to 30000-35000, I should be good?
 
This is what my dump shows. Looks like I'm bound to start having some troubles down the road?
View attachment 1730050
You probably already are overusing the last NAND sectors where the first VSS store is stored inside the SPI flash memory. This will cause SPI failure.
So do I just hold down Command-Opt-P-R until I hear the 5th chime, boot into non-OC MacOS, dump the BootROM and compare? If I get closer to 30000-35000, I should be good?
Always dump or flash from a vanilla macOS install - dumps, and the System Information reports, from OC installs are not reliable.

Garbage collection needs space to work. If the circular log lost it's control of the head and tails, usually happens when there are less than a third of available space, you will overuse the NAND cells and have problems with the volume itself.

MP4,1/MP5,1 was designed for another era of NVRAM usage, back in 2008 the NVRAM use was very sparse, today is heavily used for all sort of things.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.