Thank you @tsialex as always! Your knowledge overwhelms me!
I have fixed my problem just reflashing BootROM using the reconstructed one that you made it for me.
Now everything is ok again
Attachments
Last edited:
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
I have fixed my problem just reflashing BootROM using the reconstructed one that you made it for me.
Now everything is ok again
Zapped NVRAM (waited for the 5th chime) and then booted into recovery. Disabled SIP then restarted into vanilla Mojave. Dumped the BootROM and this is the result:
I take it the above is a good sign?
Will be interesting to see how this changes one I re-bless OpenCore. That said, I thought setting
WriteFlash to <false/> prevented OC from writing to NVRAM, instead storing variables into RAM?I will tuck this ROM dump away for safe keeping. OT: What should the free space size be for a clean MP3,1 with 2 processors and 8 DIMMs?
It’s good enough, but you don’t have much headroom.
OC eve with protection enabled still need some variables inside the NVRAM.
MP3,1 have a separate flash memory for the NVRAM, it’s a very different BootROM architecture. You can’t clean it, btw.
Differently from a MP4,1/5,1, a failed NVRAM SPI with a MP3,1 still boots, but you can’t bless for example.
Thanks again for sharing your knowledge with me. Much appreciated.
Last couple of questions. How can I confirm garbage collection is working correctly? And since it appears zapping NVRAM in my 5,1 cleans things up to an acceptable level, would you suggest I do this every several months or so? I'd like to keep the SPI flash working as long as possible.
It’s too complex to really know if a NVRAM volume is healthy, you have to know a lot about Apple flavor of the EFI implementation to evaluate it.
Track the space available, it’s the simplest way to see if it’s still doing it’s job.
Like I wrote, I flash my never booted image every 3 months, I have a recurrent appointment in my calendar.
Understood. Unfortunately I don't have a "never-booted" ROM backup, so will have to flash based on what I have today - or zap until the 5th chime is heard (just to clear space).
Sometimes, when starting with a clean nvram the 4 times nvram reset cleans an exploding stream. Dont ask me why, it happens.
started with a clean nvram, something went nuts with a bootloader, 1st VSS was almost full after only a few boots. In that case the deep nvram reset helped. Of course I have the binwalks and dumps but this is clearly visible.
maybe it was cleaned because of the previous perfect empty stream. I dont know
started with a clean nvram, something went nuts with a bootloader, 1st VSS was almost full after only a few boots. In that case the deep nvram reset helped. Of course I have the binwalks and dumps but this is clearly visible.
maybe it was cleaned because of the previous perfect empty stream. I dont know
When the garbage collection is still working, the circular log is backed up to the second store and the first one is reset.Sometimes, when starting with a clean nvram the 4 times nvram reset cleans an exploding stream. Dont ask me why, it happens.
started with a clean nvram, something went nuts with a bootloader, 1st VSS was almost full after only a few boots. In that case the deep nvram reset helped. Of course I have the binwalks and dumps but this is clearly visible.
maybe it was cleaned because of the previous perfect empty stream. I dont know
View attachment 1730147
If the circular log lost the control of the head/tail, just the second store is cleaned and the 1st stays as is, that's why some dumps have a crazy 1st VSS store and a pristine 2nd VSS recently cleaned.
yes, it only works with prestine streams. I tried it with messed streams and with luck the deep nvram reset helped to free up a little but not even close to the results when starting with a clean stream.
So second it that everyone should have at least a rom backup or even better a cleaned up firmware to refresh.
This is the Free Space of my dumped BootROM before I reflashed today because of my issue: 14376. This copy was a clean/reconstructed one exactly on November 16th ( 3 months ago ). I am not a very busy computer engineer... I am just a user... I have really done many changes in Opencore in the lasts few weeks.... that is true....
Attachments
Last edited:
Yes, when you are testing with OpenCore configs, trying to find the golden config for your Mac Pro, it's better to flash the backup/cleaned dump more frequently. After you get it stabilised, no need to be as aggressive with the schedule.
One thing that is clear, no one should start with OC tests without knowing the status of the NVRAM free space. Like I always say, the MP5,1 NVRAM is tiny for todays standards and it's deadly for someone with a already compromised NVRAM, even reseting the NVRAM 4-times continuously before anything.
While the MP4,1/5,1 project stood the test of time, the NVRAM is the Achilles heel of it.
@tsialex just asking again in case you didn't see it in my other post, but what effect does the "WriteFlash" variable in OC do as far as NVRAM is concerned? I was under the impression that having that set to "false" would mitigate the number of writes OC does to NVRAM, instead loading to system RAM?
I've saw it and answered already on post #7010.
Yes, when WriteFlash=false OC writes a lot less, but several variables are stored inside the NVRAM by OC for it to work.
It's easy to prove, flash the generic upgrade image MP51.fd from 10.14.6 MAS full installer (where the NVRAM is just FFs), then enable OC, use your Mac Pro, then do some reboots, use some more and finally dump it. Open the dump with HexFiend and look between 0x120000 and 0x12FFFF, it's where the 1st store of the NVRAM is.
Code:
Install\ macOS\ Mojave/Install\ macOS\ Mojave.app/Contents/Resources/Firmware/MP51.fdEdit:
Never do this without a backup dump of your BootROM previously saved.
The generic image don't have any serials (there are 7 different hardwareIDs that make your Mac Pro unique, none is present inside the MP51.fd).
Last edited:
Hi there!
How does one go about reconstructing the bootrom? Will re-applying the 144.0.0.0 one do the trick?
Thanks!
PM sent.
No, see why:
- First you can't re-flash the same firmware version or downgrade it. efiflasher checks the EFI version before doing anything.
- Second, the generic image doesn't even have a NVRAM volume, just FFs where the NVRAM is stored. Apple efiflasher completely ignores the NVRAM area of the BootROM image and keep it as is inside the SPI flash memory.
Btw, not just the NVRAM area, but the boot loader, the Firmware Recuperation module and the BootBlock. Just the EFI component of the BootROM image is ever upgraded.
Last edited:
Does that flash memory difference make a 3,1 any better or worse than a 4,1/5,1 when it comes to OpenCore NVRAM write risks? Would you use a 3,1 over a 4,1 for testing for example?
It's a different implementation and while it's better in some aspects, it's a lot worse with others, like being almost impossible to unbrick since you have to desolder a FWB flash memory
Edit: Just checked and it's a M50FW016, so it's a TSOP-40
I've stopped using my MP3,1 after the second logic board bricked.
I don't recommend a MP3,1 for OC development at all, it's NVRAM SPI is older/smaller, installed on a place with several other components near it, while with a MP5,1 is extremely easy to remove/replace.
Btw, MP3,1 non-modified EFI don't support APFS or NVMe.
Last edited:
Thanks I will keep it as my trusty backup cMP and stick with the 4,1. I’ve kept it unpatched for this long and avoided things like that APFS rom patch for fear of the reasons you just confirmed for me 😉
I made a boot rom backup before I first attempted opencore but how can I tell if it’s a clean and proper backup?
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
Last edited:
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...
Well I guess I am trying to understand how to make sure my BootROM would be ok to restore it every 3 months like you do. You said you have a "never booted" Image. I guess mine is not that since the full size is 30936. So how would I create a "never booted" rom Image?
Look I'm not trying to sell a service here, I've taught some developers here how to do the quick and dirty basics and I've written enough over the years for everyone with a good understanding of EFI to do it himself, but doing a clean-up/reconstruction is really a firmware engineer job since to do it successfully you have to understand how to do several checksums with the correct endianness for the areas that you need to extract from the dump, know what to use and what to discard, how to insert what you need and where. Besides all that, you have to correct two free space indicators that are plain wrong (just FFs) inside the MP51.fd that Apple never bothered to made it right since the NVRAM is not present there and ignored by efiflasher when flashing.
If you are a developer that have a good understanding of all I wrote above and is capable of desolder and reprogram the SPI flash memory with a SPI programer if something went wrong, unfortunately for sure it will the first time, it's an afternoon job to do it. If this is not your description and you want it right the first time without any downtime, just send me a PM.
Last edited:
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?
Last edited: