Sidebar Sidebar
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

Update: This is the test run with more details, separating deleted variables: #91

I also posted a firmware run after a manually triggered garbage collection after each reboot until automatic garbage collection run:



Code: 
1. Dump after manual Garbage Collection:

6 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
0 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
52864 Bytes free space of 65472


2. Dump after manual Garbage Collection

8 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
2 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
47488 Bytes free space of 65472


3. Dump after manual Garbage Collection:

10 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
3 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
42816 Bytes free space of 65472


4. Dump after manual Garbage Collection:

12 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
4 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
38144 Bytes free space of 65472


5. Dump after manual Garbage Collection:

14 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
5 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
33472 Bytes free space of 65472


6. Dump after manual Garbage Collection:

16 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
6 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
28800 Bytes free space of 65472


7. Dump after manual Garbage Collection:

18 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
7 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
24128 Bytes free space of 65472


8. Dump after manual Garbage Collection:

20 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
8 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
19456 Bytes free space of 65472


9. Dump after manual Garbage Collection:

22 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
9 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
14784 Bytes free space of 65472


10. Dump after manual Garbage Collection:

24 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
10 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
10112 Bytes free space of 65472


11. Dump after manual Garbage Collection:

26 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
11 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
5440 Bytes free space of 65472


12. Dump after manual Garbage Collection
(768 Bytes free, next is automatic Garbage Collection):

28 Memory Configs (take care)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
0 BluetoothActiveControllerInfos (ok)
0 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
12 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)
768 Bytes free space of 65472 (take care)


13. Dump after manual Garbage Collection:
(VSS2 Stream was written, free space is back)

VSS1     VSS2
6           4 Memory Configs (ok)
0           0 xml (ok)
0           0 iCloud Tokkens (ok)
0           0 Microsoft Certificates (ok)
0           0 BluetoothActiveControllerInfos (ok)
0           0 BluetoothInternalControllerInfos (ok)
0           0 current-network (ok)
2           2 AAPL Path Properties (ok)
51776 Bytes free space of 65472
 
Last edited:
  • Like
Reactions: ddhhddhh2
Warrington said:
VSS2 is not empty, it stays at 57813 Bytes of free space during the entire cycle of 8 reboots:

View attachment 1953921

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:

View attachment 1953925

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:

View attachment 1953928
Click to expand...


taking only 4 boots to fill up the nvram is not normal, see my test row at #27

…


that text about cleanup/triple nvram reset is meant as a hint what caused the empty 2nd stream.

it means, hey it is perfectly normal when you triggered a gc or if you have just flashed a new reconstructed firmware.

if you have not did such you should take care of it.
 
Last edited:
Macschrauber said:
taking only 4 boots to fill up the nvram is not normal
Click to expand...

I don't know what is normal or not, I'm just learning things.

This is the first report, right after the deep NVRAM reset (5 chimes):

nbxd144_02nvram.png


It looked pretty good and every reboot was using between 7000 and 8000 Bytes of free space. After 4 reboots, 4864 Bytes of free space looks really reasonable and it is also consistent with the results obtained from other machines.
 
Warrington said:
I don't know what is normal or not, I'm just learning things.

This is the first report, right after the deep NVRAM reset (5 chimes):

View attachment 1953951

It looked pretty good and every reboot was using between 7000 and 8000 Bytes of free space. After 4 reboots, 4864 Bytes of free space looks really reasonable and it is also consistent with the results obtained from other machines.
Click to expand...

So you just begin to understand how the nvram works and tell us we were wrong?

ok...
 
  • Love
  • Like
Reactions: crjackson2134 and prefuse07
Macschrauber said:
So you just begin to understand how the nvram works and tell us we were wrong?
Click to expand...

This is not about being right or wrong, this is about the NVRAM behaviour of a particular machine. I have every reason to believe the NVRAM works normally at the moment and I've already promised some details about a 5,1 mid-2010 machine that was not working normally.
 
What aboutt bricked cMPs then, if what it sounds like you are saying is that we don't need BootROM rebuilds, or even deep NVRAM resets/cleanup, that the NVRAM "just does its thing" -- how does this explain bricked cMPs then?
 
  • Like
Reactions: NC12
prefuse07 said:
it sounds like you are saying is that we don't need (...) deep NVRAM resets/cleanup
Click to expand...

I'm not saying that, later on I will show some examples when the deep NVRAM reset/cleanup was really needed.

But in normal use, during those cycles of 8 reboots each, it wasn't needed. It was just the normal way of working for the NVRAM.
 
  • Like
Reactions: NC12
It worked the last decade this way.

The problems come with multiboot systems (booting old and new OS), opencore, Windows certificates. All stuff what mess up the nvram and what possibly damage the gc.

If the free space is less than expected the gc could fail. If it fails and overwrites the Fsys stream the firmware will not load anymore. That's what we call a brick.

So it's important to check the free space (after a manually triggered gc).
 
  • Like
Reactions: NC12 and crjackson2134
Macschrauber said:
So it's important to check the free space (after a manually triggered gc)
Click to expand...

I fully agree. However, it seems that in normal use the machine is able to free up way more space than after a deep NVRAM reset.

A random ROM dump is not really relevant by itself, dozens of dumps tell a different story.
 
  • Like
Reactions: vworks
@Macschrauber ... Change this
cleanup/triple nvram reset - otherwise take care
to
Recent Cleanup/Triple Nvram Reset - Otherwise Take Care

The way it currently is appears to be telling people to do a cleanup/triple nvram reset or else they must take care but what it is actually trying to say (but is not) is that unless the store is empty because there has been a recent cleanup/triple nvram reset, they need to take care.

As an aside, your latest version provides an option to hide the serial number instead of the default of showing this.

You might want to consider making hiding the default instead and for those than want to show it to have to override this.
 
Dayo said:
@Macschrauber ... Change this
cleanup/triple nvram reset - otherwise take care
to
Recent Cleanup/Triple Nvram Reset - Otherwise Take Care

The way it currently is appears to be telling people to do a cleanup/triple nvram reset or else they must take care but what it is actually trying to say (but is not) is that unless the store is empty because there has been a recent cleanup/triple nvram reset, they need to take care.

As an aside, your latest version provides an option to hide the serial number instead of the default of showing this.

You might want to consider making hiding the default instead and for those than want to show it to have to override this.
Click to expand...


ok, if it confuses people I can change the text of the empty vss2 comment. Have to think about it as it is too long.


hiding the serial number as default I dislike.

the purpose of the tool is to have backups with a little analyzing plus a mild to strong warning (take care, not ok, very bad). Not to post it to forums.

I often get dumps to look at and it is very useful to have the serial number of the machine in the filenames.

users with more than one machines or workshops will need to seperate the dumps.

If one user wants to hide the serial for a screenshot he can do this by either holding the shift key when starting the dumper or by editing the script, it is documented and the script source is included.

the serial and IDs are in the dump file anyway, if someone is concerned giving it away.

as a side note people should never post a firmware file to the public. Giving the firmware dump to someone to check or rebuilt is a matter of trust of course.
 
  • Like
Reactions: NC12, crjackson2134 and prefuse07
Macschrauber said:
Have to think about it as it is too long.
Click to expand...
It is just one word extra, "Recent", which gives clarity. You can change "Otherwise Take Care" to "Caution Otherwise" if the word count is a hard limit. You can use "Caution" in place of "take care" throughout btw.

Macschrauber said:
hiding the serial number as default I dislike.
Click to expand...
Fair enough. Was thinking about the dialogue boxes really and not so much the dumped bin files themselves. People are likely to post those boxes.
 
Another perhaps clearer version (lined up) ....
cleanup/triple nvram reset - otherwise take care
caution unless after cleanup or triple nvram reset

However, I think "Recent" is important as even this may cause users to think you mean cleanup or triple nvram reset immediately before that specific reboot.

Based on that, I'll suggest ...
cleanup/triple nvram reset - otherwise take care
caution unless recent cleanup or triple nvram reset
or, maybe "triple" is not really needed to get the point across,
caution unless recent cleanup or nvram reset
 
Last edited:
  • Like
Reactions: Macschrauber
prefuse07 said:
I'd be curious to hear @tsialex's thoughts on this thread, as he is a BootROM guru...
Click to expand...
I‘m sure he doesn’t think anything about it. It would be a waste of his time. He’s a very educated, experienced, and credible, firmware engineer. It’s like asking Mozart what he thinks about the “Mary had a little lamb” song.
 
Last edited:
  • Haha
Reactions: prefuse07
crjackson2134 said:
“Mary had a little lamb”
Click to expand...
You do the classic nursery rhyme a great disservice as while beloved by toddlers, it is not the same thing as when the little angels are howling loudly with incoherent rage in the nursery.

The issue here is that the OP came to believe they had discovered a big hidden secret about NVRAM working and wanted to do a big take down of the big fish.

However, it was no secret (it is in "BootROM 101 - NVRAM for Absolute Beginners") and worse still, it was driven by a misinterpretation of a phrase in a tool they didn't quite understand.

@Macschrauber will hopefully fix the phrase to avoid future incidents of this kind.
Toddlers will be toddlers and as an adult, he has to take the blame!
 
  • Like
Reactions: NC12, Fastsavage, crjackson2134 and 2 others
I made the text for an empty 2nd stream a little less confusing. It comes with the next Dumper release:

Code: 
$test_nvram '141 0 0 0 0.bin'

serial from firmware: CK9xxx
Firmware 141.0.0.0
14 Memory Configs (ok)
0 xml (ok)
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
3 BluetoothActiveControllerInfos (not ok)
2 BluetoothInternalControllerInfos (not ok)
0 current-network (ok)
5 AAPL Path Properties (ok)
VSS2 is empty (ok after triple nvram reset or recent firmware rebuilt)

as it is not ok if you don't made a forced garbage collection or recenty flashed a rebuilt firmware is quite logical.

a rebuilt firmware has no populated VSS1 and VSS2 stream, VSS1 gets written during the first boot of a rebuilt firmware, VSS2 gets build when the first regular garbage collection runs after free space in VSS1 gets low.

...


those 3 BluetoothActiveControllerInfos and 2 BluetoothInternalControllerInfos are not ok
as the 2nd Store is empty. Even if I count all vars in both streams I differ if the 2nd stream is populated or not.

This could come, as Alex found out, due to different syntax of the
bluetooth nvram vars of systems newer than Mojave. So different Vars are written if the Mac boots old and new systems.

I have seen 10 or more Bluetooth vars and I guess this could lead into a problem. My Theory is that for example Big Sur can not read the active Bluetooth Controller written by Mojave and makes a new one.

Vice versa with Mojave, it could not read Big Sur's Bluetooth Controller Var and makes a new one. So the amount of vars rise.

You may get ridd of them by a nvram reset. If not you may need a firmware reconstruction.


...

side note: I have seen same with wifi network controllers and Big Sur, they seem not compatible as well so Big Sur needed a nvram reset and wiping the network settings also to get Wifi working if there were network vars of older MacOs systems in the nvram.
 
  • Like
Reactions: NC12, crjackson2134 and Warrington
Macschrauber said:
Got a new version of the dumper released

among other fixes and improvements changed wording:

take care -> caution
cleanup/triple nvram reset - otherwise take care -> ok after triple nvram reset or recent firmware rebuilt

Dropbox - File Deleted - Simplify your life

www.dropbox.com www.dropbox.com
Click to expand...
Thanks for this - trying to decide if I need a rebuild before i upgrade CPU's and RAM.

I'm sure this will help with that decision

Cheers
 
Fastsavage said:
Thanks for this - trying to decide if I need a rebuild before i upgrade CPU's and RAM.

I'm sure this will help with that decision

Cheers
Click to expand...

everyone with a 4.1->5.1 should have a proper firmware if it comes to OpenCore and unsupported Systems.

OC and OCLP make heavy use of the nvram, also there are some variables that are incompatible with earlier Systems like the Bluetooth variables, they fill the nvram more likely when regulary booting old and new OS.

@tsialex is the chief firmware expert to do the job professionally
 
Last edited:
  • Like
Reactions: prefuse07
I made a variant of my tool for the very common and affordable ch341a spi programmer

just linking to the german board I am active, screenshots and link is there, the first lines just tell that this is the dumper modified for ch341a tool.

www.macuser.de

Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

Ich hab eine Variante vom Dumper für den CH341A USB spi programmer gezaubert. Die Dinger gibts für ein paar Euro. Entweder man lötet den Chip drauf oder leistet sich einen Adapter wenn man das öfter braucht. Grundsätzliche Funktionen vom Dumper, eben für den Programmer. Im Grunde ist das der...
www.macuser.de www.macuser.de

edit: now obsolete, as the Dumper does detect a CH341a programmer if plugged in.
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back