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

[Fastsavage]

Umm, still waiting dude.

Was just thinking that I hadn't seen @Warrington around for a while

 

[Macschrauber]

as 12.3 dropped Python I needed to make a new version of the dumper.

Also it shows the bootblock version and indicates a crossflash 4.1->5.1

Dropbox - File Deleted - Simplify your life

www.dropbox.com

 

[Dayo]

12.3 dropped Python

It didn't drop Python altogether, but just updated the version to Python 3 btw.

You therefore now need to use the python3 alias when running commands instead of the old python alias. This is unless you point the python alias to Python 3. Code obviously needs to be Python 3 compatible to work.

​

 

[ddhhddhh2]

Sorry, I'm pure little lamb regarding firmware and this topic, but I don't know how to properly seek the required knowledge and just came across this discussion which is somewhat relevant, so please allow me to ask some questions.

1. When people say SPI flash, do they mean NVRAM?

2. Every time turn off the cMP, and the next time power on the cMP, the life of the NVRAM is not more shortened?

3. If the second point is true, would it be wiser to use sleep as much as possible to reduce the number of reboots?

4. It was mentioned in the discussion that you need to reset NVRAM three times when upgrading the system, but I have rarely reset NVRAM on my cMP 5,1 except for a previous firmware upgrade, and I have never reset NVRAM even when upgrading the OS version, and no adverse events seem to have occurred. Is this an encouraged behavior?

5. I saw the tool developed by @Macschrauber, how do I get it? How do I use it? And how do I identify the life of the SPI flash when using it? For example, what numbers are considered healthy or dangerous?

6. If I learn to use that tool, once it is judged as "dangerous", do I have to face the fact of replacing the SPI flash?

I never thought I would be using cMP for so long, but I realize that it seems to be tied to the longevity of my cMP. I've seen some articles by @tsialex that mention updated SPI tutorials or related discussions, but that's way beyond my capabilities.

I used to work with a firmware engineer, but now that I'm in an environment without one, I don't think I'm capable of doing such a thing, so maybe I should learn to prevent my cMP from turning into a brick.

Please forgive me again for straying from the topic, but I hope these questions are of some help to little lamb.

 

[Dayo]

Send a PM to @tsialex. He will advise you on the best steps to take.

 

[Macschrauber]

5. I saw the tool developed by @Macschrauber, how do I get it? How do I use it? And how do I identify the life of the SPI flash when using it? For example, what numbers are considered healthy or
I used to work with a firmware engineer, but now that I'm in an environment without one, I don't think I'm capable of doing such a thing, so maybe I should learn to prevent my cMP from turning into a brick.

The link is provided, just download the tool, disable System Integrity Protection (or use an old OS, Mavericks work best for it) and run it.

It saves a copy of the Firmware with your machine IDs and scans the nvram for the known most problematic parameters.

The backup of the firmware is the most important step, it contains various IDs what are hard to gather if not backed up. Some are printed on the backplane of the machine but you need to disassemble the Mac a bit to see them. Other IDs are not printed and you will need your receipts or its a wild guess out of experience.

So, just download and run it with s.i.p. off.

If using other dumpers like DosDude’s RomTool s.i.p. also must be off. We all use the same tool in the back called flashrom and a helper tool needs s.i.p. off.

The main purpose of writing the tool is to give people an easy tool for saving the firmware plus to give them a warning when obvious things inside it went nuts.

It is not perfect and can not find every problem, read the firmware threads, there are loads of information in.

There is also a quick demonstration of my dumper in YouTube (The version in YT is a little outdated. The information now is more precise but the usage is still the same).

 

[ddhhddhh2]

The link is provided, just download the tool, disable System Integrity Protection (or use an old OS, Mavericks work best for it) and run it.

It saves a copy of the Firmware with your machine IDs and scans the nvram for the known most problematic parameters.

The backup of the firmware is the most important step, it contains various IDs what are hard to gather if not backed up. Some are printed on the backplane of the machine but you need to disassemble the Mac a bit to see them. Other IDs are not printed and you will need your receipts or its a wild guess out of experience.

So, just download and run it with s.i.p. off.

If using other dumpers like DosDude’s RomTool s.i.p. also must be off. We all use the same tool in the back called flashrom and a helper tool needs s.i.p. off.

The main purpose of writing the tool is to give people an easy tool for saving the firmware plus to give them a warning when obvious things inside it went nuts.

It is not perfect and can not find every problem, read the firmware threads, there are loads of information in.

There is also a quick demonstration of my dumper in YouTube

Thank you, I ran it and it showed the following message.

serial from firmware: YM127033EUG
Firmware 140.0.0.0
old Bootblock of MP51.007F.B03
Boot0001 is EFI\OC\OpenCore.efi
25 Memory Configs (ok)
0 xml (ok)
2 Kernel Panic Dumps
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
2 BluetoothActiveControllerInfos (ok)
2 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
16 AAPL Path Properties (ok)
5568 Bytes free space of 65472

It shows
2 Kernel Panic Dumps
5568 Bytes free space of 65472

Which Kernel Panic Dumps will have a hidden problem? As for "5568 Bytes free space of 65472", it looks like there is very little space left, which seems to imply that the SPI flash does not have much life left, right?

Thank you very much for making such a great tool.

 

[ddhhddhh2]

Send a PM to @tsialex. He will advise you on the best steps to take.

Okay, I will ask him for advice at the right time, hopefully it will not take up too much of his time, thank you.

 

[Macschrauber]

Thank you, I ran it and it showed the following message.

serial from firmware: YM12
Firmware 140.0.0.0
old Bootblock of MP51.007F.B03
Boot0001 is EFI\OC\OpenCore.efi
25 Memory Configs (ok)
0 xml (ok)
2 Kernel Panic Dumps
0 iCloud Tokkens (ok)
0 Microsoft Certificates (ok)
2 BluetoothActiveControllerInfos (ok)
2 BluetoothInternalControllerInfos (ok)
0 current-network (ok)
16 AAPL Path Properties (ok)
5568 Bytes free space of 65472

It shows
2 Kernel Panic Dumps
5568 Bytes free space of 65472

Which Kernel Panic Dumps will have a hidden problem? As for "5568 Bytes free space of 65472", it looks like there is very little space left, which seems to imply that the SPI flash does not have much life left, right?

Thank you very much for making such a great tool.

the automatic garbage collection should run very soon, next or next but one reboot.

see https://forums.macrumors.com/thread...our-on-4-1-5-1-machines.2333460/post-30829975

the nvram stream #1 is filled in a circle, from almost empty to full to almost empty, etc.

if the nvram has very low free space automatic garbage collection runs and free up space. This is the process where a brick could occur, if this process will break it will lead into a non working firmware.

 

[Macschrauber]

It didn't drop Python altogether, but just updated the version to Python 3 btw.

You therefore now need to use the python3 alias when running commands instead of the old python alias. This is unless you point the python alias to Python 3. Code obviously needs to be Python 3 compatible to work.

View attachment 1975637​

If I got it right you have to install Python 3 via the command line tools of xcode

Apple removes Python 2 in macOS Monterey. What now?

Apple has been warning that the Python 2 binary will be removed. It’s a fact now. Read what to do next.

www.jamf.com

it's a bit too much for just probing modifier keys in my script. I found a solution without python anyway in the meantime.

 

[Dayo]

you have to install Python 3 via xcode

Yeah. Seems to be quite a barrier. Didn't realise the Python 3 version they "provided" was just a placeholder.

Strange that they would make sure a change in a minor point release and not just wait till the next major point ... or have just done it at the Monterey release to start with.

a bit too much for just probing modifier keys

Faced the challenge of ensuring Python 3 support with MyBootMgr a while ago, as this needed to hook into a largish scripts derived from the OCLP and couldn't just use an alternative language.

Got it working, but pretty sure anyone that puts the binary through one of those much beloved but ultimately useless sites like Virus Total will get told it is malware ... same issue with the OCLP on those sites. I suppose Python now needs to more or less be avoided on Macs.

Certainly different from the the good old Apple Fan Boy "it just works" days when stuff like this did indeed just work right out of the box. I suppose the new largely iPhone sourced user base don't quite need such stuff to just work. Just chill in the walled garden and throw it away for a new one next year or so.

 

[ddhhddhh2]

the automatic garbage collection should run very soon, next or next but one reboot.

see https://forums.macrumors.com/thread...our-on-4-1-5-1-machines.2333460/post-30829975

the nvram stream #1 is filled in a circle, from almost empty to full to almost empty, etc.

if the nvram has very low free space automatic garbage collection runs and free up space. This is the process where a brick could occur, if this process will break it will lead into a non working firmware.

I just ran it again after booting and I did see more space, this time 48768 Bytes free space of 65472, which is really interesting.

 

[Dayo]

That's because garbage collection was run. This is explained earlier in this thread.

The potential issue is that if you had done a update about two reboots ago and this needed to put stuff in the NVRAM, there wouldn't have been enough space, which could lead to a brick.

The suggestion of a deep NVRAM reset before updates is to force garbage collection in order to free up space before such updates.

 

[ddhhddhh2]

That's because garbage collection was run. This is explained earlier in this thread.

The potential issue is that if you had done a update about two reboots ago and this needed to put stuff in the NVRAM, there wouldn't have been enough space, which could lead to a brick.

The suggestion to reset NVRAM before updates is to force garbage collection in order to free up space before such updates.

Yes, I ran it before shutting down yesterday, as well as when I turned it on today, which happened to be during the lowest as well as the clearing process.
So I guess, from empty, until filled, empty again, for SPI flash, it seems to be a cycle, so every time go through a cycle, the SPI flash life will inevitably be reduced once again.

 

[Dayo]

There is a rated life for reboots which is quite high but yes, every reboot does use this up.
On the other hand, the machine needs reboots to clear crud that accumulates with use ... such as your kernel panic dumps.

 

[Macschrauber]

I would recommend the following:

- flash a rebuilt firmware, or at least make a manual garbage collection

- set up your Mac with blessing of the ESP or Bootvolume

- dump this state of the firmware, you need to set s.i.p. off, so do it with an old OS (I use Mavericks) or configure OpenCore or RefindPlus to set s.i.p. off to reduce reboots.


as some may need to swap GPUs for this its the most comfortable solution. You just need to flash your configured dump without the need to bless the bootloader.

 

[Macschrauber]

As it seems to get problematic having a lot of compressed text contained Panic Logs the dumper now counts them separately.

Type A: a pointer to a file, not problematic
Type B: the kernel panic text in multiple compressed parts.

Alex have seen very large kernel panics in the nvram after a failed ota update to 12.3

better force the garbage collection before doing this update or better start with a fresh dump.

you may need to bless the ESP after gc.

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

 

[Macschrauber]

I have now taken the logical step of counting the critical nvram variables separately.

From the beginning it was not quite correct to count both streams together, but once you start with one method, it's hard to get rid of it.

One of the biggest obstacles was that the results are not comparable. I think I have now found a compromise that doesn't look quite as nice, but is workable. And that's what it's all about in the end...

17 + 2 Memory Configs -> 17 in the first stream, 2 in the second stream.

The previous version would have shown 19 memory configs. The internal evaluation has correctly considered the first stream.

The second one is something like a backup or rather a template and contains only the first instance of the variables.

The first stream grows until it is full and then there is the garbage collection. It makes a copy of the first stream after the first run into the second stream.

Everything is the same as before, only the counting is split. In other words: What is in the second stream is what is in the nvram after booting once after the regular GC.


If the second stream is empty (after firmware rebuild or manual GC) then the dumper writes that like the previous version: 4 memory configs.

4 + 0 would be a little stupid ;-)

The links:

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

 

[Dayo]

4 + 0 would be a little stupid

Not any more stupid than 0 + 0 above!

Better to have one consistent way of always showing the info.
That way, you can just explain what both sides mean as you have done and it will always apply.

Now you have to say "left is first stream and right is second, except when XYZ". Why not just always present it one way and remove the need for the "except when XYZ" explanation. You can bet that users will always forget this part.

 

[zzzippp]

Type A: a pointer to a file, not problematic
Type B: the kernel panic text in multiple compressed parts.

In the past day, I have been experiencing multiple Kernel panics on a MacPro5,1 8-core when chain-loading RefindPlus 079 -> OpenCore 0.7.9 - > Big Sur 11.6.4, nothing to do with macOS Monterey because I have never installed it. I think it has something to do with the SIP being enabled and the OC config having SecureBoot = Default, but it was working fine before that. I suspect this because on one boot into OC -> Big Sur, I did verbose mode and saw the message "Rooting from the live fs of a sealed volume is not allowed on a RELEASE build".

On dump of this MacPro5,1's BootROM, your tool found 5 of type A panic dumps, and 20 of type B!! I already have a reconstructed BootROM from @tsialex, so I am going to flash that to clear things out.

What I want to know is: Is there a way to read the compressed kernel panic text from the dumped BootROM file?

 

[Macschrauber]

In the past day, I have been experiencing multiple Kernel panics on a MacPro5,1 8-core when chain-loading RefindPlus 079 -> OpenCore 0.7.9 - > Big Sur 11.6.4, nothing to do with macOS Monterey because I have never installed it. I think it has something to do with the SIP being enabled and the OC config having SecureBoot = Default, but it was working fine before that. I suspect this because on one boot into OC -> Big Sur, I did verbose mode and saw the message "Rooting from the live fs of a sealed volume is not allowed on a RELEASE build".

On dump of this MacPro5,1's BootROM, your tool found 5 of type A panic dumps, and 20 of type B!! I already have a reconstructed BootROM from @tsialex, so I am going to flash that to clear things out.

What I want to know is: Is there a way to read the compressed kernel panic text from the dumped BootROM file?

next time you boot into a matching system you will get the screen for reporting the kp to Apple.

when you display details you will get the kp text.

if this happens please dump the firmware again, I assume the stored kp will be wiped after showing it.

 

[Macschrauber]

It happens all the time that users post screenshots of the dumper's test_nvram dialog with showing their full serial number.

This is not good as Hackintoshers like to use that numbers for their builts.

So masked it in the main dialog. I disliked it first as I need those serials to track dumps.

@Dayo got my attention to the simple but working solution: Just mask the dialog, keep the serial in the log and in the filenames.

what is shown is good enough to identify the model - but not good enough to use the serial for a Hackintosh.


same link

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

 

[Macschrauber]

New version of the dumper.

The analysis is much more intensive thanks to Syncretic's Scanvss tool.

I am in exchange with the author of the tool, so the dumper benefits a lot from it.

Over 100 variables are checked. There is now a distinction active / passive.

The MemoryConfigs are now differentiated according to the 4 types. If there are irregularities here, it could be contact problems on the modules or sockets. Or of course a defect.

By the higher possible number of the variables only variables are indicated (apart from the Windows certificates), which have at least one entry.

All other variables with an occurrence greater than 4 are listed. This does not have to be necessarily bad. There one must still collect experiences.

In the logfiles is now a complete run of Scanvss. Keep this log very privately as it contains personal data.



a messed nvram volume:

a healthy firmware:

Syncretic's Scanvss full log:

Dropbox - File Deleted - Simplify your life

www.dropbox.com

Ihr persönlicher Freigabelink | GMX Cloud

Mit diesem Link erhalten Sie Zugriff auf die mit Ihnen geteilten Daten.

c.gmx.net

 

[Macschrauber]

Silent upgrade...

as I was much more into scripting, investigating and fighting with the dragons of shell script syntax I had a lot of spelling and grammar issues and some typos.

Fixed a bunch of them.

My tongue language is not english - So there are a lot of grammar glitches kept in the tool.

Thanks @Dayo for endless patience in helping me with composing proper english dialogues

Apart of text corrections there are some fixes in the test_nvram shell script as well.

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

 

[Macschrauber]

Made some progress with the Dumper:

-- it alarms if checksums in Fsys or Gaid stores are incorrect and refuses flashing
-- filenames show correct boot rom version if spoofed via OpenCore
-- added LauncherOption:Full info for OpenCore setups
-- a progess bar
-- support for a ch341a_spi programmer, detects it and switches to ch341a mode
-- hints for dealing with problematic NVRAM streams like critical low free space or certificates
-- indication of firmware password set (security-mode=command or security-mode=full)

-> as the file is too large the latest version of the Dumper is available at:

https://c.gmx.net/@899644307915413392/-dLWoaKNRdOT1yPrQ7RZsw
https://www.dropbox.com/s/kr74r2ft0nrvp7n/Macschrauber's CMP Rom Dump.dmg?dl=0