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
Interested to see the rest of this assertion as this contradicts findings from @tsialex. The amount of free space left in your screenshot above is dangerously low.
This is what I'm seeing after tonight's ROM dump. I'll need to reflash with a pristine ROM as it's been a while. That said, my 5,1 has all of its DIMM slots populated and is running OpenCore.
And after the 5th NVRAM reset chime. Looks like the garbage collector is still working fine.
This is what I'm seeing after tonight's ROM dump. I'll need to reflash with a pristine ROM as it's been a while. That said, my 5,1 has all of its DIMM slots populated and is running OpenCore.
And after the 5th NVRAM reset chime. Looks like the garbage collector is still working fine.
Last edited:
It from what appears to be an account created recently, apparently specifically for the purpose below:
They might well be right, I can't say, but hiding behind a sock puppet account strips all credibility away.
Best stick with the credible party IMO.
Last edited:
It’s pretty well documented that the NVRAM is the weakest point of our 4,1 and 5,1 so we need to take care of them and use advise and experiences from credible sources.
We all know that with computers you see new errors and faults every day… always something the same but different.
My vote is with experience.
We all know that with computers you see new errors and faults every day… always something the same but different.
My vote is with experience.
The amount of free space is actually changing at every reboot, this is the little "secret" nobody will tell.
Here is the free space after the next reboot. Now it looks great, right?
And the same amount of free space, as reported by test_nvram.app:
This is how NVRAM really works, 1st VSS store free space is never static. Only the 2nd VSS store is sometimes static.
My experience is now based on analyzing hundreds of dumps from dozens of 5,1 and 4,1->5,1 machines.
8 reboots (and 8 dumps) before, the 1st VSS store free space was reported the same:
And this is how things changed after the next reboot:
With absolutely nothing changed on the machine, in terms of hardware or software, 3 memory configs have been added and 7040 Bytes of free space have been used.
Last edited:
I'm curious about the way you're analyzing these dumps.
I suppose you're not only running the Macschrauber's dumper and looking at the amount of free space...
UEFITool NE is a great tool and most of the results won't go public. Binwalk is also a great tool, but is not the beginning and the end of all things.
The screenshots from Macschrauber's dumper are easier to understand for everybody, this is why I include them in these posts.
I have some very interesting results from a 5,1 mid-2010 machine and I will write about them within a few days.
The amount of free space changing on the SPI flash after each reboot is normal behavior, as far as I understand. This can be affected by the garbage collection routine. The problem arises when certain operations require many variables to be stored in the flash ROM (such as during an OS update), and there's not enough available space remaining. With your first screenshot showing less than 4k bytes, what happens if that does not free up after a reboot during an OS update? I assume it could lead to corruption elsewhere in the ROM.
I don't know what happens if does not free up. What I know for sure is it does free up every time, this is what I'm writing about.
After every reboot, the free space decreases with something between 7000 and 8000 Bytes. And when the remaining free space of the 1st VSS store is less than that (at the 8th reboot for this particular machine) it does free up. This is how the NVRAM really works, this is the point.
The other point is the machine won't free up more space if it "believes" that more space is not needed (between the 4th and the 5th reboot, let's say).
This is what I used to believe a few months ago. That 5,1 mid-2010 machine mentioned above helped me learn a few things.
Interesting. Well, I myself don't know too much about the inner workings of the SPI flash ROM, but I am concerned about it from a longevity perspective. I'm interested to read more about the behavior you posited above, as this is the first time I've heard about there being a specific, repeatable pattern to ROM memory management.
Same here. In my case, I'm concerned about the longevity perspective of dozens of 4,1->5,1 machines, so I ended up doing this research. One of the interesting results is that the SST25VF032B from the 4,1 machines actually seems to generate less problems than the MX25L3205D from the mid-2010 machines.
So what happens if you are running an update that needs to store large data and you are on the 6th or 7th reboot of the garbage collection cycle for instance? Are you saying the firmware will realise it needs more space in advance and trigger the garbage collection even though it would only have ordinarily done this on the 8th reboot?
I suppose what you are pointing out is not generally known and I get your point that it hasn't perhaps been explained as it perhaps should have.
An important point that should be stressed, but perhaps hasn't enough, is that you should always do a triple NVRAM reset to force garbage collection BEFORE running any update.
There hasn't been a lot of focus on this but this is how the NVRAM works.
There is one example where it is set out:
Mac OS 11.3 has broken support for older Mac Pros
I ran the tests again, this time I took care to set Startup Disk from the prefpane to the Big Sur 11.3 Disk. I restarted more than 20 times, this time logging the nvram free space thru a complete nvram circle (from filled to full to garbage collection to the same filled situation) and it...
forums.macrumors.com
EDIT: Changed "is generally known" to "is not generally known"
Last edited:
I'm not saying the firmware will realise anything, I will tell everybody exactly what happened. Was nothing dramatic.
Thanks. I just figured the garbage collector would run after each reboot, or if a set threshold was reached. I didn't realize it would take up to 8 reboot cycles for the memory to be dumped.There hasn't been a lot of focus on this but this is how the NVRAM works.
There is one example where it is set out:
Mac OS 11.3 has broken support for older Mac Pros
I ran the tests again, this time I took care to set Startup Disk from the prefpane to the Big Sur 11.3 Disk. I restarted more than 20 times, this time logging the nvram free space thru a complete nvram circle (from filled to full to garbage collection to the same filled situation) and it...
Seems to vary. Was the 10th reboot in the linked example.
Main point is that you would not ordinarily know where things are in terms of free space or what payload size needs to go into the NVRAM. If things are not in your favour, you can expect to get an overrun and ultimately, a brick.
This is of course unless we actually ever get to see the mentioned "nothing dramatic" outcome at some point.
Last edited:
Can I ask the purpose of analysing hundreds of dumps - are you looking to solve the issue of bricking or ??
You can say that too, but mostly I'd like to know what I'm doing, whatever I'm doing.
Last edited:
@Warrington I wonder if you use the latest version of my Tool.
forums.macrumors.com
As I don't see the notification about VSS2 being empty after triggered garbage collection.
And yes, we know the NVram gets filled up until almost full. After full the garbage collection will run. This will take about 12 reboots from almost empty to full, see the screenshots Dayo posted the link for.
A Dual machine with lots of Ram and 8 Memory slots filled up have bigger nvram "packets" as a Single CPU machine with just 2 Ram slots populated. There are some more variables filling the nvram like stored wifi networks and much more. So it depends how much reboots it takes to get the garbage collection run.
@tsialex investigated and posted loads of details. His investigation and his help made me able to start writing my dumper as I wanted a tool for our CMPs.
Plus I wanted people to take more care about the boot rom and to make backups.
Healthy NVRAM normal behaviour on 4,1->5,1 machines
Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...
forums.macrumors.com
As I don't see the notification about VSS2 being empty after triggered garbage collection.
And yes, we know the NVram gets filled up until almost full. After full the garbage collection will run. This will take about 12 reboots from almost empty to full, see the screenshots Dayo posted the link for.
A Dual machine with lots of Ram and 8 Memory slots filled up have bigger nvram "packets" as a Single CPU machine with just 2 Ram slots populated. There are some more variables filling the nvram like stored wifi networks and much more. So it depends how much reboots it takes to get the garbage collection run.
@tsialex investigated and posted loads of details. His investigation and his help made me able to start writing my dumper as I wanted a tool for our CMPs.
Plus I wanted people to take more care about the boot rom and to make backups.
Last edited:
... and btw
I have also about 300 dumps and use them for mass tests if I add a feature to the bash script behind the dumper.
If you want to use it for tests you can either extract the test_nvram bash script or use it like (example is for the mounted .dmg)
for cutting the serial number the argument -shortserial can be added to test_nvram
I have also about 300 dumps and use them for mass tests if I add a feature to the bash script behind the dumper.
If you want to use it for tests you can either extract the test_nvram bash script or use it like (example is for the mounted .dmg)
Code:
. /Volumes/Macschrauber\'s\ CMP\ Rom\ Dump/RomDump\ Macschrauber.app/Contents/Resources/test_nvram ~/ck.bin
serial from firmware: CK2xxxx
MP51.88Z.0089.B00.1806081708
25 Memory Configs (ok)
2 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
2 BluetoothActiveControllerInfos (ok)
2 BluetoothInternalControllerInfos (ok)
2 current-network (ok)
9 AAPL Path Properties (ok)
Length of 2nd VSS Store is wrong (FF FF FF FF)
7616 Bytes free space of 65472for cutting the serial number the argument -shortserial can be added to test_nvram
VSS2 is not empty, it stays at 57813 Bytes of free space during the entire cycle of 8 reboots:
VSS2 was empty only for the first 4 reboots after the deep NVRAM reset and your tool was correctly reporting it as empty. After the 4th reboot, the VSS2 was still empty, but the free space of the 1st VSS was already below 7000 Bytes:
That recommendation (cleanup/triple nvram reset) was not necessary at that point, the triple nvram reset itself created that situation and no other deep reset was needed.
The next reboot cleaned the 1st VSS completely: