Another one with a corrupt header for the 2nd VSS store, it's the fourth one in 11 days.
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 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I've been trying to learn to read the dumps using UEFITool and using the low VSS store value method mentioned here I decided to check the VSS store size of a test rom dumped not long after a recent reconstructed rom flash. What threw me was the figure was 9645 which I see is low for VSS store one while the second was unused.
I thought maybe it was because the rom was only recently flashed so I dumped again and got an even lower figure of 2560. I started thinking I should reflash incase the number got even lower so I stripped everything out then booted in firmware mode. Now I did another dump before flashing the recon rom again but when I went to check it later the preflash dump VSS store size was up to 49322 in store 1 and now the second store was in use (down to 53897) and filled with largely duplicate variables seen in the first store although with a lot less 'Invalid' entries in either store.
I've been trying to find info on how the boot to nvram write process actually happened / works but can't find a manual or guide that helps me to understand things like how it relates to physical memory for example. Was that normal for the NVRAM to use the second when the first VSS store got low or was that just too low to go?
I'm curious if my hardware may be responsible for the difference in entries as the readings made after removing everything for the flash me think it was related to my drives or even my USB 3 card which were put back after first flash and I did the dump with them in to check the low store.
Is having a few different bootable HDD and CCC clones on SSD maybe what is causing the NVRAM to write something about each EFI at boot if no drive is blessed after flash does this make the NVRAM boot order info change each time or would blessing cause this to be fixed?
Here's the values...
First Dump:
---
VSS store 1: Full size: 25ADh (9645)
VSS store 2: Full size: FFA8h (65448)
---
Second Dump:
VSS store 1: Full size: A00h (2560)
VSS store 2: Full size: FFA8h (65448)
---
Third Dump Before Flash: (No Drives Cards In Firmware Mode etc)
VSS store 1: Full size: C0AAh (49322)
VSS store 2: Full size: D289h (53897)
---
Can having multiple partitions cause the NVRAM to fill up more with boot info or even different macOS variables from booting multiple installs on the one cMP? Could it just be the chip itself?
How would an NVRAM reset affect things before flashing and after? SMC reset too. Is there an order things are read / written I can see somewhere to maybe picture the process better? I am sure the corruption problem is fixed (from my limited understanding of the examples above looking for FFFFFF etc) so is it just a case of monitoring it or is there anything else I can troubleshoot with regards to what causes the duplicate / store two NVRAM writes?
I thought maybe it was because the rom was only recently flashed so I dumped again and got an even lower figure of 2560. I started thinking I should reflash incase the number got even lower so I stripped everything out then booted in firmware mode. Now I did another dump before flashing the recon rom again but when I went to check it later the preflash dump VSS store size was up to 49322 in store 1 and now the second store was in use (down to 53897) and filled with largely duplicate variables seen in the first store although with a lot less 'Invalid' entries in either store.
I've been trying to find info on how the boot to nvram write process actually happened / works but can't find a manual or guide that helps me to understand things like how it relates to physical memory for example. Was that normal for the NVRAM to use the second when the first VSS store got low or was that just too low to go?
I'm curious if my hardware may be responsible for the difference in entries as the readings made after removing everything for the flash me think it was related to my drives or even my USB 3 card which were put back after first flash and I did the dump with them in to check the low store.
Is having a few different bootable HDD and CCC clones on SSD maybe what is causing the NVRAM to write something about each EFI at boot if no drive is blessed after flash does this make the NVRAM boot order info change each time or would blessing cause this to be fixed?
Here's the values...
First Dump:
---
VSS store 1: Full size: 25ADh (9645)
VSS store 2: Full size: FFA8h (65448)
---
Second Dump:
VSS store 1: Full size: A00h (2560)
VSS store 2: Full size: FFA8h (65448)
---
Third Dump Before Flash: (No Drives Cards In Firmware Mode etc)
VSS store 1: Full size: C0AAh (49322)
VSS store 2: Full size: D289h (53897)
---
Can having multiple partitions cause the NVRAM to fill up more with boot info or even different macOS variables from booting multiple installs on the one cMP? Could it just be the chip itself?
How would an NVRAM reset affect things before flashing and after? SMC reset too. Is there an order things are read / written I can see somewhere to maybe picture the process better? I am sure the corruption problem is fixed (from my limited understanding of the examples above looking for FFFFFF etc) so is it just a case of monitoring it or is there anything else I can troubleshoot with regards to what causes the duplicate / store two NVRAM writes?
Last edited:
Maybe I'm not explaining this right, but I think that are some misunderstanding here and I probably need to elaborate this topic a little more.
What's important to know is if the garbage collection is working or not. The 1st VSS store is the main one, the 2nd is the secondary. The main VSS store is a circular log, modified variables are constantly added to the circular log without the old ones being erased from it, just marked for deletion. Imagine that the circular log is an old tape based answering machine, new messages are appended to the older ones until you get out of space and the tape is rewind.
Garbage collection works this way, it's a little complex process so, I'm simplifying a lot, but a healthy Mac Pro will basically work like this:
- Mac Pro is powered on, POST detects that the garbage collection process is needed, the secondary VSS is wiped, the valid entries from the main VSS store are backed up to the secondary.
- The sectors that store the VSS inside the SPI are wiped/erased. This takes time, read and write to an empty/erased sector in the SPI flash is fast, while erase is extremely slow.
- The circular log stored, now inside the 2nd VSS store, is read and written back to the main one.
- Main VSS store free space indicator is updated.
- Secondary VSS store is now ignored, since the main one is now working
- Boot process continues.
So, basically what you want to know is if your Mac Pro garbage collection is working or not. You dump the NVRAM, see the free space, then reset the NVRAM immediately, dump it again and compare if the free space is the same or less. If it is the same or even less, the garbage collection is not working - if the free space is now bigger, it's working at least in some capacity.
Please note that if you did reset the NVRAM before the first check or flashed a never booted image recently, your results are not reliable, you have to use your Mac Pro normally for a considerable period of time to have all variables present again inside the circular log.
Checking the free space this way is really important to track if garbage collection is working or not, OC devs talked about fragmentation sometimes already. When the circular log is constantly out of free space after a NVRAM reset, you clearly have fragmentation, with something like SecureBoot/NVIDIA web drivers blobs/etc blocking the circular log and making the already tiny space of the main VSS store even smaller.
Last edited:
Btw, it's difficult to understand the circular log, but think that it's like an old tape based answering machine, new messages are appended to the older ones in the tape util you get out of space and the tape is rewind and everything starts again.
Yes that's exactly the info I was after thanks! I understand now why the second store 'kicked in' / was written. I think it is working fine as the low value was what caused the second to be used and the duplicated info is to be expected (would physical memory affect this process or is that related really at all?). I was thinking it was duplicated entirely which caused me to think multiple versions of macOS were possible culprits. I have kept as many things like CCC backup drives out for now (not gone back to testing OC for now at least) and use AMD GPU on the 4,1 now so no need for NVIDIA webdrivers again hopefully! NVRAM wasn't reset before I was just curious if that would maybe kick the second store into action which I now know isn't the intended result. After flashing just reboot and unplug or is that not that important after flashing as it's all reset? I was thinking there was maybe something leftover somewhere but I understand the log process more now thanks
Last edited:
No backup, the VSS store is erased and then the circular log re-written without the superseded variables.
MP6,1 is also different, with bigger and multiple stores, it has rotation for the main VSS, so the NAND cell life for the VSS area is greatly improved.
I'm helping @VaZ unstuck the sectors of his main VSS store inside the SPI flash that are weirdly stuck, so I had to do some research for a dump that had a still functional main VSS almost completely full to use it to overwrite the data on the SPI and try to change the contents. The same thing happened with another user some weeks ago.
I inspected the last 25 dumps people sent me and I added the free space for the 1st and 2nd VSS stores of each dump to a spreadsheet, see the screenshot below. I bet that some people here would like to know the numbers with a somewhat considerable sample like this one.
I inspected the last 25 dumps people sent me and I added the free space for the 1st and 2nd VSS stores of each dump to a spreadsheet, see the screenshot below. I bet that some people here would like to know the numbers with a somewhat considerable sample like this one.
Last edited:
Btw, please don't focus too much with the free space available, it's a very useful metric, but the circular log sometimes have another problems or fail in different ways. For example, one of the dumps above have SIX bluetoothActiveControllerInfo variables and still loads of empty space as padding and not free space.
Another thing, you have to track it over time, dumping the BootROM again after a 4-times consecutively NVRAM reset and comparing the free space of both dumps to see if the garbage collecting is working or not, see my previous post here.
Another thing, you have to track it over time, dumping the BootROM again after a 4-times consecutively NVRAM reset and comparing the free space of both dumps to see if the garbage collecting is working or not, see my previous post here.
Last edited:
Hello!,
Have you found a way dump that 2.5GT/s from the MVC Card? I'm having the same with an nVidia GTX 780 3GB card and MVC says it's a purely cosmetic issue. The say the actual speed is 5.0GT/s. I've tested with some tools they suggested and indeed the speed is appearing to be 5.0GT/s.
The thing is that I'm experiencing little, or no difference at all from the original GT 120 and that is something that bothers me ALOT! So, if you've found a way to overcome this, please I'd definetely like to know about.
Thank you
niconc
@Stex sent me his dump and, wow, I'm surprised that his Mac Pro still works with all the variable multiplication specially bluetoothActiveControllerInfo.
Look at this the binwalk report against my diagnostic signatures and tools (serials redacted):
Look at this the binwalk report against my diagnostic signatures and tools (serials redacted):
- 1st VSS store with just 14143 bytes free from 65448,
- 19 MemoryConfig variable occurrences for 8 memory slots,
- 9 NVRAM bluetoothActiveControllerInfo variables, while should be just one, AFAIK it's the worst to date,
- PanicInfo Log, count is now 5, so 6 crashes were previous registered.
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
243907 0x3B8C3 BIOS version: MP51.88Z.F000.B00.1904121248
524288 0x80000 UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
768195 0xBB8C3 BIOS version: MP51.88Z.F000.B00.1904121248
1048576 0x100000 UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1064960 0x104000 UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1065216 0x104100 Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1077504 0x107100 Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1085696 0x109100 Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1114112 0x110000 UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1130496 0x114000 UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1130752 0x114100 Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1143040 0x117100 Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1151232 0x119100 Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1179648 0x120000 UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
1179688 0x120028 NVRAM start of the 1st VSS store
1179766 0x120076 NVRAM MemoryConfig type: (j)
1182899 0x120CB3 NVRAM PanicInfo Log
1188789 0x1223B5 NVRAM bluetoothActiveControllerInfo
1188956 0x12245C NVRAM MemoryConfig type: (g)
1191004 0x122C5C NVRAM MemoryConfig type: (h)
1193052 0x12345C NVRAM MemoryConfig type: (i)
1195564 0x123E2C NVRAM bluetoothActiveControllerInfo
1196302 0x12410E NVRAM bluetoothActiveControllerInfo
1196469 0x1241B5 NVRAM MemoryConfig type: (g)
1198517 0x1249B5 NVRAM MemoryConfig type: (h)
1200565 0x1251B5 NVRAM MemoryConfig type: (i)
1203077 0x125B85 NVRAM bluetoothActiveControllerInfo
1205835 0x12664B NVRAM bluetoothActiveControllerInfo
1206002 0x1266F2 NVRAM MemoryConfig type: (g)
1208050 0x126EF2 NVRAM MemoryConfig type: (h)
1210098 0x1276F2 NVRAM MemoryConfig type: (i)
1215212 0x128AEC NVRAM bluetoothActiveControllerInfo
1215521 0x128C21 NVRAM MemoryConfig type: (g)
1217569 0x129421 NVRAM MemoryConfig type: (h)
1219617 0x129C21 NVRAM MemoryConfig type: (i)
1222467 0x12A743 NVRAM bluetoothActiveControllerInfo
1223808 0x12AC80 NVRAM SIP state, type: (w)
1224281 0x12AE59 NVRAM bluetoothActiveControllerInfo
1224448 0x12AF00 NVRAM MemoryConfig type: (g)
1226496 0x12B700 NVRAM MemoryConfig type: (h)
1228544 0x12BF00 NVRAM MemoryConfig type: (i)
1245255 0x130047 NVRAM start of the 2nd VSS store
1245302 0x130076 NVRAM MemoryConfig type: (j)
1248435 0x130CB3 NVRAM PanicInfo Log
1254325 0x1323B5 NVRAM bluetoothActiveControllerInfo
1254492 0x13245C NVRAM MemoryConfig type: (g)
1256540 0x132C5C NVRAM MemoryConfig type: (h)
1343518 0x14801E HardwareID Base_xx: 18
1343538 0x148032 bzip2 compressed data, block size = 100k
1345167 0x14868F HardwareID 11-digits SSN: H09*****20H
1345184 0x1486A0 HardwareID 3-digit HWC model: 20H
1376256 0x150000 UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1416827 0x159E7B BIOS version: MP51.88Z.F000.B00.1904121248
1614976 0x18A480 Apple NVMe EFI Module
4063232 0x3E0000 UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0, GUID: E3B980A9-5FE3-48E5-929B-2798385A9027
4128768 0x3F0000 UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume, GUID: 04ADEEAD-61FF-4D31-BAB6-64F8BF901F5A
4128867 0x3F0063 BootBlock version: AAPLEFI1.88Z.0005.I00.1010071430
4194000 0x3FFED0 HardwareID MLB/LBSN: J59******1LTC, BuildDate: 0907**0907**@tsialex I am beginning to suspect that I might have a problem with my bootROM after reading this thread. I have a 4,1 flashed to 5,1 with bluetooth issues. I have upgraded to a combined AC-Wifi/BT 4.0 card but lately the bluetooth is totally missing. A USB Bluetooth dongle works fine until I sleep the computer or reboot. After that I have to turn off bluetooth, reboot and turn it on again for it to work.
Do you think this could be bootRom related? If so, how would I go about cleaning it up?
Thanks,
Oskar
Do you think this could be bootRom related? If so, how would I go about cleaning it up?
Thanks,
Oskar
Very possible, but needs investigation. I've sent you a PM with the instructions, get everything and I'll diagnose your Mac Pro BootROM dump.
Yes. I have PC version GTX Titan. I flashed the BIOS without any issue or removing any of PCIE cards.
I'm running Catalina 10.15.7 (DosDude Patched) on Mac Pro 2009 4,1 > 5,1 running Firmware 140.0.0.0.0. Is there a reason why during the upgrade from Mohave to Catalina it didn't upgrade to 144.0.0.0.0?
I'm guessing after reading this thread I'm going to have to download the Mohave Installer and run that method and hope it presents me the option to upgrade the firmware, correct?
I'm guessing after reading this thread I'm going to have to download the Mohave Installer and run that method and hope it presents me the option to upgrade the firmware, correct?
Hacked installs don't upgrade firmwares nor Catalina has a MP5,1 firmware.
MP5,1: What you have to do to upgrade to Mojave (BootROM upgrade instructions thread)
Please fully read this first post, you will probably find that you have one or more problems described into the various notes below. Mojave will only install if you have upgraded your BootROM to the current release and your Mac Pro have a Metal capable GPU*. If you are trying to install Mojave...
forums.macrumors.com
Thank you very much for the reply, I got it working perfectly.Hacked installs don't upgrade firmwares nor Catalina has a MP5,1 firmware.
MP5,1: What you have to do to upgrade to Mojave (BootROM upgrade instructions thread)
Please fully read this first post, you will probably find that you have one or more problems described into the various notes below. Mojave will only install if you have upgraded your BootROM to the current release and your Mac Pro have a Metal capable GPU*. If you are trying to install Mojave...
