MP 1,1-5,1 Healthy NVRAM normal behaviour on 4,1->5,1 machines

[prefuse07]

So are you saying that adding a MATT card to my cMP was not needed?

 

[Macschrauber]

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:

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

 

[Macschrauber]

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

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.

 

[prefuse07]

I'd be curious to hear @tsialex's thoughts on this thread, as he is a BootROM guru... I'm subbed to see if he chimes in, and to see the evolution of this thread. I must say, @Warrington, this is some interesting stuff!

 

[Warrington]

taking only 4 boots to fill up the nvram is not normal

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):

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]

So are you saying that adding a MATT card to my cMP was not needed?

I'm not saying anything, I won't make any assumptions.

 

[Macschrauber]

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.

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

ok...

 

[Warrington]

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

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.

 

[prefuse07]

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?

 

[Warrington]

it sounds like you are saying is that we don't need (...) deep NVRAM resets/cleanup

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.

 

[Macschrauber]

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).

 

[Warrington]

So it's important to check the free space (after a manually triggered gc)

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.

 

[Dayo]

@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.

 

[Macschrauber]

@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.

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.

 

[Dayo]

Have to think about it as it is too long.

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.

hiding the serial number as default I dislike.

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.

 

[Dayo]

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

 

[crjackson2134]

I'd be curious to hear @tsialex's thoughts on this thread, as he is a BootROM guru...

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.

 

[Dayo]

“Mary had a little lamb”

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!

 

[Fastsavage]

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.

Probably doesn't want to get into a pointless argument.......

 

[Macschrauber]

I made the text for an empty 2nd stream a little less confusing. It comes with the next Dumper release:

$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.

 

[Macschrauber]

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

 

[Fastsavage]

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

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

 

[Macschrauber]

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

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

 

[Macschrauber]

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.

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

edit: now obsolete, as the Dumper does detect a CH341a programmer if plugged in.

 

[amstel78]

I'm not saying the firmware will realise anything, I will tell everybody exactly what happened. Was nothing dramatic.

Umm, still waiting dude.