MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[tsialex]

What benefit is there to having a never booted ROM image vs the one I have now which I did before installing OC the first time?

A never booted image for your Mac Pro is made exactly the same way as the image the OEM manufacturer programmed to the SPI flash when the backplane was made, but updated to the current EFI (144.0.0.0.0) and to the current BootBlock (AAPLEFI1.88Z.0005.I00.1904121247). The NVRAM volume VSS stores are completely empty, with the full 64548 bytes available - a thing that you can never get again after you powered your Mac Pro the first time. Every time you re-flash the reconstructed image, you boot as fresh as your Mac Pro first power on. From what you wrote two posts ago, you can get just half of it now after the NVRAM reset.

For someone with a cross flashed early-2009 or a mid-2010 made back in 2010, it's even more important since the MP5,1 firmware images went out from the factory with very buggy hardware descriptors and BootBlocks that Apple iterated constantly and finally corrected later in the mid-2010 for the mid-2012 production. You can't get the current hardware descriptors, BootBlocks and FirmwareRestoration modules since they are independent inside the BootROM image and not upgraded by the efiflasher when doing EFI upgrades. Hardware descriptors are not even inside the MP51.fd generic upgrade image, but I've posted the source of each production release on the BootROM thread.

If you need more info, please ask by PM.

 

[amstel78]

What benefit is there to having a never booted ROM image vs the one I have now which I did before installing OC the first time? Are you saying the only way to obtain a so called "never booted" image is to manually edit one into that state?

Apart from what Alexandre said, my understanding is that as VSS stores get full, the circular log loses control over heads and tails, causing even more issues with the VSS stores. As the space decreases, NAND sectors start getting overwritten constantly which can cause the SPI flash to prematurely fail.

This was why I had sought clarification a few times in the past about what exactly "WriteFlash" does in OC's config file. I had wrongly assumed that having it set to "false" would keep any variables from being written to the SPI. I was wrong though, and if your BootROM was already full, those writes that occur every time your system is booted will cause premature failure.

This is the reason why I opted to have Alex create a "never booted" BootROM file for me. It will have both VSS stores empty as well as correct deficiencies. This gives my SPI flash a little breathing room and should act as a small insurance policy now that I'm using OC daily.

I took a look at the SPI flash chip in my backplane today. It's tiny and getting the backplane out of the chassis looks like a PITA. I'm actually really good with a soldering iron and have replaced a few SMT components in my day, but I'd rather avoid the hassle to begin with.

 

[Dewdman42]

A never booted image for your Mac Pro is made exactly the same way as the image the OEM manufacturer programmed to the SPI flash when the backplane was made, but updated to the current EFI (144.0.0.0.0) and to the current BootBlock (AAPLEFI1.88Z.0005.I00.1904121247). The NVRAM volume VSS stores are completely empty, with the full 64548 bytes available - a thing that you can never get again after you powered your Mac Pro the first time. Every time you re-flash the reconstructed image, you boot as fresh as your Mac Pro first power on. From what you wrote two posts ago, you can get just half of it now after the NVRAM reset.

For someone with a cross flashed early-2009 or a mid-2010 made back in 2010, it's even more important since the MP5,1 firmware images went out from the factory with very buggy hardware descriptors and BootBlocks that Apple iterated constantly and finally corrected later in the mid-2010 for the mid-2012 production. You can't get the current hardware descriptors, BootBlocks and FirmwareRestoration modules since they are independent inside the BootROM image and not upgraded by the efiflasher when doing EFI upgrades. Hardware descriptors are not even inside the MP51.fd generic upgrade image, but I've posted the source of each production release on the BootROM thread.

Thanks for the explanation. If I decide I would like to try that, I'll PM you...think I'll still with what I have for now.

Apart from what Alexandre said, my understanding is that as VSS stores get full, the circular log loses control over heads and tails, causing even more issues with the VSS stores. As the space decreases, NAND sectors start getting overwritten constantly which can cause the SPI flash to prematurely fail.

This was why I had sought clarification a few times in the past about what exactly "WriteFlash" does in OC's config file. I had wrongly assumed that having it set to "false" would keep any variables from being written to the SPI. I was wrong though, and if your BootROM was already full, those writes that occur every time your system is booted will cause premature failure.

This is the reason why I opted to have Alex create a "never booted" BootROM file for me. It will have both VSS stores empty as well as correct deficiencies. This gives my SPI flash a little breathing room and should act as a small insurance policy now that I'm using OC daily.

I took a look at the SPI flash chip in my backplane today. It's tiny and getting the backplane out of the chassis looks like a PITA. I'm actually really good with a soldering iron and have replaced a few SMT components in my day, but I'd rather avoid the hassle to begin with.

I understand, thanks for chiming in. I don't think my circular buffer is abnormally full now, its a dual CPU with 8 dimms used and my free space is in the range tsialex mentioned as "normal", so I will just keep things as they are, for now. Well I should say that is what is in the ROM I made a few months ago before installing OC for the first time. I should do another ROM dump and have a look at it now to see if its still in that range.

I can see the benefit of having a "never booted" ROM to start out with...besides the fact that I probably have all the buggy firmware stuff tsialex mentioned since my 5,1 is a mid 2010 model. I'm guessing that various updates have worked past that, but basically there is old dead code in my ROM now, using up some of that free space. But I don't really know. I am not having any problems, for now everything is working fine. For now I don't think it sounds like the garbage collection in my 5,1 is having a problem (yet), but I can see the benefit of having more room to avoid that ever happening. And I can see the wisdom of resetting to it every couple of months after fooling around with OC over and over again.

 

[amstel78]

I understand, thanks for chiming in. I don't think my circular buffer is abnormally full now, its a dual CPU with 8 dimms used and my free space is in the range tsialex mentioned as "normal", so I will just keep things as they are, for now. Well I should say that is what is in the ROM I made a few months ago before installing OC for the first time. I should do another ROM dump and have a look at it now to see if its still in that range.

I can see the benefit of having a "never booted" ROM to start out with...besides the fact that I probably have all the buggy firmware stuff tsialex mentioned since my 5,1 is a mid 2010 model. I'm guessing that various updates have worked past that, but basically there is old dead code in my ROM now, using up some of that free space. But I don't really know. I am not having any problems, for now everything is working fine. For now I don't think it sounds like the garbage collection in my 5,1 is having a problem (yet), but I can see the benefit of having more room to avoid that ever happening. And I can see the wisdom of resetting to it every couple of months after fooling around with OC over and over again.

Your system sounds just like mine, an actual 2010 5,1 with 8 DIMM slots. Per Alex, the SPD cache for each DIMM takes up a lot of space in NVRAM. Before I did the 5-chime NVRAM reset, there was 23+ MemoryConfig variables. After the reset, less than 14.

Anyway, after third reboot with the clean base ROM, my free space in the first VSS store went up to almost 41k. The second VSS store is completely empty.

 

[mrt209]

After Step 2, enabling hardware acceleration, I can boot my Mac, choose my boot drive, but after the Apple logo shows and it finishes loading my screen goes black... Any ideas?

Edit: Monitor works when using hdmi cable, anyway to enable Displayport?
Edit: Found an issue in the config file, mistake in the gpu path, works now.

 

[0134168]

Excuse me for my ignorance. Been with OC for some days now and everything seems to work like a charm. I make regular backups. Should I backup also the EFI content every time or is it something that never change unless you touch it?

Thank you so much.

 

[TECK]

anyway to enable Displayport?

I'm using DisplayPort without issues on a 4K monitor.

 

[h9826790]

After Step 2, enabling hardware acceleration, I can boot my Mac, choose my boot drive, but after the Apple logo shows and it finishes loading my screen goes black... Any ideas?

Edit: Monitor works when using hdmi cable, anyway to enable Displayport?
Edit: Found an issue in the config file, works now.

Which OS?

Try another DP port first.

 

[mrt209]

@h9826790 @TECK

I mixed up the path of my GPU with my NVME, fixed it and works now. Thanks for the reply though

 

[TECK]

Should I backup also the EFI content every time or is it something that never change unless you touch it?

Is up to you but the EFI only changes when there is a new OC release. I personally never backup the EFI or the config.plist and generate both fresh every time there is a new OC release, with OC Plistlib Generator. The only file I save is my setup.py which will generate the EFI tree and config.plist automatically, for each new OC release.

 

[0134168]

I'm using DisplayPort without issues on a 4K monitor.

Using 2 displayport monitors Led Cinema Display 27" here. Works like a charm.

 

[0134168]

Is up to you but the EFI only changes when there is a new OC release. I personally never backup the EFI or the config.plist and generate both fresh every time there is a new OC release, with OC Plistlib Generator. The only file I save is my setup.py which will generate the EFI tree and config.plist automatically, for each new OC release.

Thank you so much for your help. Really appreciated. If I may the question… why to update if everything is working like a charm? I´m on REL-060-2020-08-03 and it´s really great how is working in these few days I have been using it.

 

[TECK]

why to update if everything is working like a charm?

With every new OC version, new features are added and bugs fixed, which improves your overall Mac stability. I mean you should stay with El Capitan because is working great, why upgrade to Catalina or Big Sur.

 

[0134168]

With every new OC version, new features are added and bugs fixed, which improves your overall Mac stability. I mean you should stay with El Capitan because is working great, why upgrade to Catalina or Big Sur.

Not exactly the same. As far as I can boot a full working Catalina, it´s ok for me. Advantages will come from the OS, as you say.

 

[TECK]

Not exactly the same.

Of course is the same, what if between 0.6.0 (which you use) and 0.6.6 there was a bug fix which could harm your BootROM, have you checked? Or even worse. Not to mention you could easily brick your Mac with wrong OC settings, if you don't know what you are doing.

 

[0134168]

What I meant when i said "full working Catalina" was with no errors or bugs.

 

[0134168]

What I meant when i said "full working Catalina" was with no errors or bugs. But I understand your point perfectly. Thank you.

 

[TECK]

What I meant when i said "full working Catalina" was with no errors or bugs.

How do you know that? Even the macOS engineers do not know that in a supported hardware, they release new fixes every quarter. Even less us, the users experimenting blindly with very little knowledge of OC bootloader. I'm the first to say I probably know about 10% of OC functionality, after over an year of constant reading documentation and studying it.

 

[permanentmacdabbler]

Excuse me for my ignorance. Been with OC for some days now and everything seems to work like a charm. I make regular backups. Should I backup also the EFI content every time or is it something that never change unless you touch it?

Thank you so much.

The EFI partition can corrupt (APFS formatted drive corruption caused me to learn the hard way) but depending on how quickly you can reset your config it might be easier to just reinstall and reset.

 

[0134168]

The EFI partition can corrupt (APFS formatted drive corruption caused me to learn the hard way) but depending on how quickly you can reset your config it might be easier to just reinstall and reset.

Thank you so much.

 

[rx78]

A dump is never clean, unless is a never booted image or a hardware dump from a never powered up brand new replacement backplane from Apple - that don't exists anymore.

Clean here has to be understood as functional and with around half space free/avaliable, see my post below.

OpenCore on the Mac Pro

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: Dump the BootROM with ROMTool Open the dump with the most...

forums.macrumors.com

Thanks for all the info you've written up about this. I was concerned about my bootrom being corrupt but the tools you've linked had eased my mind. I think mine's still relatively healthy.

If I were to do a periodic reflash from a back up, do I just use ROMTOOL?

 

[tsialex]

If I were to do a periodic reflash from a back up, do I just use ROMTOOL?

Exactly.

Please remember that looking the free space is the dumbest way to check if a BootROM is healthy. There are plenty of different ways that a BootROM can became corrupt, especially with early-2009s and mid-2010 made back in 2010.

 

[rx78]

Exactly.

Please remember that looking the free space is the dumbest way to check if a BootROM is healthy. There are plenty of different ways that a BootROM can became corrupt, especially with early-2009s and mid-2010 made back in 2010.

Nice.

Maybe I'll ask about your bootrom cleaning services in the future

 

[eVasilis]

...especially with early-2009s and mid-2010 made back in 2010.

Mine was manufactured in June 2011. Is the re a difference in the bootrom chip?

Thanks!

 

[tsialex]

Mine was manufactured in June 2011. Is the re a difference in the bootrom chip?

Thanks!

Yes, late produced mid-2010 usually follow the mid-2012 specs.

It's not just the model of the SPI flash that is different, but it's contents too. BootROM is an image with several components inside:

• EFI firmware
• NVRAM volume
• BIOS/CSM
• Firmware Recuperation module / BootBlock
• Bootloader

Apple firmware upgrades just upgrade the EFI part of the BootROM, everything else is kept as the factory sent and completely ignored by the efiflasher when doing firmware upgrades.

If you have any further doubts about this please ask your questions on the BootROM thread, this is now way off-topic here.