Was just thinking that I hadn't seen @Warrington around for a whileUmm, still waiting dude.
Was just thinking that I hadn't seen @Warrington around for a whileUmm, still waiting dude.
It didn't drop Python altogether, but just updated the version to Python 3 btw.12.3 dropped Python
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.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
Send a PM to @tsialex. He will advise you on the best steps to take.
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.
It didn't drop Python altogether, but just updated the version to Python 3 btw.
You therefore now need to use thepython3
alias when running commands instead of the oldpython
alias. This is unless you point thepython
alias to Python 3. Code obviously needs to be Python 3 compatible to work.
Yeah. Seems to be quite a barrier. Didn't realise the Python 3 version they "provided" was just a placeholder.you have to install Python 3 via xcode
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.a bit too much for just probing modifier keys
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.
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.
Not any more stupid than 0 + 0 above!4 + 0 would be a little stupid
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?