I read post #178,
You mentioned something about heavy use of the NVRAM running Opencore or Multiple OS.
I'm running both, multiple OS's and OpenCore.
Please forgive me it was not firmware related.
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 Healthy NVRAM normal behaviour on 4,1->5,1 machines
- Thread starter Warrington
- Start date
-
- Tags
- mac pro 5.1 nvram
- Sort by reaction score
You mentioned something about heavy use of the NVRAM running Opencore or Multiple OS.
I'm running both, multiple OS's and OpenCore.
Please forgive me it was not firmware related.
This is a general data point, the more variables are in the NVRAM, the more often Garbage Collection runs.
Using multiple OS will fill the NVRAM more, a more populated NVRAM will do Garbage Collection more often than running a single, even supported, OS.
I refer to crossflashes, from 4,1 to 5,1 with the Netkas script / method. They tend to suffer more from NVRAM damage. More GC, more risk, GC could fail.
This is the logic behind that.
If you have a bootscreen capable GPU (EnableGop or EFI doesnt matter) and you are concerned about filling the NVRAM with a lot of variables, just do a deep NVRAM Reset (hold cmd-alt-p-r continuously until it chimes 3 times) before changing OS.
You will need to re-select OpenCore as initial bootloader, after a deep NVRAM reset, so the bootscreen helps a lot.
There is no general need for that, but it will keep the amount of Garbage Collections as low as possible.
Here is the post, showing what NVRAM Garbage Collection is: https://forums.macrumors.com/posts/32100306/
Hi, I'm trying to rebuild firmware 144 for my MP5.1
Can you explain this warning from Macschrauber's Rom Dump tool?
"Firmware volumes CRC32 checksums are less than expected. 8 found, 9 expected."
I should have already copied from my dump to 144.bin, FTW Fsys and LBSN
Thanks
Can you explain this warning from Macschrauber's Rom Dump tool?
"Firmware volumes CRC32 checksums are less than expected. 8 found, 9 expected."
I should have already copied from my dump to 144.bin, FTW Fsys and LBSN
Thanks
This may help you: https://forums.macrumors.com/thread...-4-1-5-1-bootrom-with-template-files.2437082/
Maybe your .fd-file is corrupted or you deleted something while editing.
Maybe your .fd-file is corrupted or you deleted something while editing.
Last edited:
my MP51.fd file is from mojave full installer (empty) without LBSN etc.
I did everything with dd commands, it seems to work too, uefi tool says crc32 valid, only the dump tool tells me crc32 less than expected 8 found 9 expected; editing in hexadecimal I see it as "nightmare error"
Do you want to try with this 144 firmware in attachment, these commands and your data? In uefitool the crc32 are valid
thx
Last edited:
I guess you used a script or commands of a youtube guy, but i can't recommend this sort of reconstruction as it leaves some issues unrepaired.
The attached .fd file is identical from installer, but it isn't suitable for rebuilding: Some parts are still missing and needs to be inserted: Bootrom updates won't touch (overwrite) the present NVRAM area, maybe thats why Apple left this part totally empty in its update files.
Last edited:
firmware in attach is empty no serial or personal data, i can't send pm because i'm new here, youtube video is not correct for "bug" in hex display in uefi tool output,this two are correct, can you try this two command for test and see if uefitool say crc32 valid ? this 144.fd with data from your dump
then the ideal would be to compare the result with your current one, that is, compare your current 144 with the one created
thx
Last edited:
The CRC32 in last volume will be correct, but not the zerovector after insertion of LBNS stuff.
And if you have already wrong checksums or missing parts in your dump, this simple copy/paste job will transfer the issues, i guess this is your problem atm.
And if you have already wrong checksums or missing parts in your dump, this simple copy/paste job will transfer the issues, i guess this is your problem atm.
no luckily the dump is fine, I only have the crc32 errors on the rebuilt firmware, only on dump tool, uefi say all crc32 are correct, thank you anyway for your interest, your guide is very useful and exactly what I need, of course manual editing for such a delicate operation is a bit scary, especially since I've never done it
Why do you don't contact me directly?
I don't think here is the place for others to rush in. I cant do something (and I dont want to) against it, but I and Alex did years of work to make the tools and gather all the information.
What is send is the plain "empty" MP51 144.0.0.0.0 firmware file. Dont ever send your personal firmware to public sources.
Sorry, I wrote in (MacPro 5.1 bootrom thread), it was moved right after, I don't know by whom, I used 2 dd command to move unique data from my dump to the installer's blank 144.fd, since your tool says 8 crc32 found 9 expected, I was alarmed and asked, after which I discovered that it depends on zero vector thanks to Borowski's "template" guide; from what I understand it would boot anyway, I understand all the time spent and thank you, I contacted you via email weeks ago I asked you what it meant to send you dumps with my unique data
I don't post the dump with the unique data publicly, but I don't send it to a stranger either; it requires total trust.
The simple reason I need to upgrade to 144 is that I have two GPUs; the first is too old for Mojave official upgrade procedure, the second gpu is too new. I discovered the firmware requirement for the new GPU later...
when I tried the guide by Borowsky with templates, which was also very well done, and I found the "little endian/byte swapped" CRC32s to be edited, I refused and went back to moving the entire blocks, since the firmware is valid anyway
congratulations also for the dumper tool
congratulations also for the dumper tool
Last edited:
If you wont trust me, you shouldnt run my tools with admin privileges. I could do everything, including sending your dump. So this makes no sense at all. So I cant help.
Sorry, running your tool with administrator privileges is one thing. If your tool sends my dump to a remote resource without my consent and without a warning, things get serious. 100% guaranteed safe.
It's "sensitive data" that only the owner has the right to possess.
It's like saying you can take something from the table because I let you into my house.
It's "sensitive data" that only the owner has the right to possess.
It's like saying you can take something from the table because I let you into my house.
Well, I cant get your wifi password in clear text, maybe email address or UUIDs of your drives, SSIDs, etc.
You can use the logs what is inside, even the test_nvram script has a lot of logic to decode and hexdump the variables.
Macschrauber-s-Rom-Dump/shell script examples.md at main · Macschrauber/Macschrauber-s-Rom-Dump
A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4,1 / 5,1 and Xserve 3,1 - Macschrauber/Macschrauber-s-Rom-Dump
github.com
I have a list of well over 1000 dumps of MP41/51 and hundreds from other Macs. All owners of them trusted me.
Last edited:
Seems the interaction WITH the person is not aware, and not well versed, and doesn't realize the amazing contributions you have tirelessly implemented to help so many.
The logical approach is to let them figure it out themselves.
CONVENTIONAL WISDOM WOULD SAY.
Last edited: