MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[tsialex]

- What to do if your Mac Pro bricked:

If your early-2009 to mid-2012 is now bricked, you have three options:

1. Buy a replacement backplane on eBay and replace the backplane yourself, cheapest option if you can't solder SMD. Remember that you need a 2009 backplane if you have an early-2009 Mac Pro. If you have a mid-2010 or mid-2012 you can use either 2010 or 2012 backplanes. Don't mix early-2009 backplanes with mid-2010/mid-2012 CPU trays, or vice-versa - either scenario is a SMC firmware version mismatch and all your fans will run at maximum RPM, full time and without any software control.
2. Buy a Mac Pro MATT card and use it as a replacement SPI flash, this is not recommended since all MATT cards are clones and won't work for iCloud/iMessage/FaceTime. A replacement backplane is usually cheaper and you have to flash a clean version of your own Mac Pro BootROM image to the MATT card.
3. Desolder, reprogram and solder back the SPI flash, chip U8700 on the backplane. It's not possible to read or write to the SPI flash memory while it's soldered on the MP5,1 backplane. A cheap SPI flash programmer like ch341a will work for read/write the BootROM after the SPI flash memory is desoldered from the backplane. Start reading here, read all my posts on the subject from there. I strongly recommend that you replace your original SPI flash memory with a brand new one, don't solder it back to the backplane, it will fail soon since SPI flash memories have limited lifetime (manufacture rated for just 100.000 erase/write cycles) when used as NVRAM for a Mac Pro. Again, most hard bricks are caused by the failure of the SPI flash, it's a US$ 2 component easily available, MXIC MX25L3206E, just replace it! Btw, yes, you can use a MXIC MX25L3206E as a modern replacement for the two older models SST25VF032B and MXIC MX25L3205D used on early-2009 and mid-2010 respectively, Apple did it for mid-2012 Mac Pros.
   
   Mojave has the generic MP51.fd firmware image inside the full installer, it's enough for boot your Mac Pro again but not for iCloud/iMessage/FaceTime login.
   
   

   Install\ macOS\ Mojave/Install\ macOS\ Mojave.app/Contents/Resources/Firmware/MP51.fd

   
   A firmware reconstruction is needed to get your Mac Pro fully working.

 

[mark.salam]

First of all - a massive thankyou for this thread and all of the extremely useful information provided.

I really thought I'd screwed up after reading here. I was starting out with OC and was trying to get Windows 10 on my MP 4,1 -> 5,1. 144 firmware. I had been (somewhat ignorantly) doing Windows install in UEFI mode via USB installer. Was successful but I had a strange anomaly whereby I would have a black screen (no signal to monitor. Could ping the machine but couldn't RDP to it) after seeing the Windows logo for like 30 minutes...and then would just appear and proceed to work fine. Anyhow, after numerous reinstalls I decided to try to install on its own without any OC. Did the full install. Tried it. Same anomaly. Then I saw all of this. Eek! Did a dump and binwalk. I think (?) it looks alright? (assuming I've done it correctly) but was hoping to get a few additional expert opinions here. Thanks!

(I've just gone out a grabbed some DL DVD's and will install Windows in Legacy - I'm assuming thats the safest approach? )

 

[tsialex]

First of all - a massive thankyou for this thread and all of the extremely useful information provided.

I really thought I'd screwed up after reading here. I was starting out with OC and was trying to get Windows 10 on my MP 4,1 -> 5,1. 144 firmware. I had been (somewhat ignorantly) doing Windows install in UEFI mode via USB installer. Was successful but I had a strange anomaly whereby I would have a black screen (no signal to monitor. Could ping the machine but couldn't RDP to it) after seeing the Windows logo for like 30 minutes...and then would just appear and proceed to work fine. Anyhow, after numerous reinstalls I decided to try to install on its own without any OC. Did the full install. Tried it. Same anomaly. Then I saw all of this. Eek! Did a dump and binwalk. I think (?) it looks alright? (assuming I've done it correctly) but was hoping to get a few additional expert opinions here. Thanks!

View attachment 1801862

(I've just gone out a grabbed some DL DVD's and will install Windows in Legacy - I'm assuming thats the safest approach? )

You don't have SecureBoot certificates/dbs/pks, but it's just one of the problems that your NVRAM can suffer, check the VSS free space.

OpenCore on the Mac Pro

Thank you @tsialex as always! Your knowledge overwhelms me! I have fixed my problem just reflashing BootROM using the reconstructed one that you made it for me. Now everything is ok again

forums.macrumors.com

 

[tsialex]

I thought that I've already saw every BootROM weirdness after inspecting so much dumps and nothing would surprise me anymore, but then @Knoxvilletim sent his MP4,1>5,1 dump with 49 SPD caches for the 36JSZF1G72PZ-1G4D DIMM:

Btw, another one with the secondary VSS store overrun:

 

[mark.salam]

You don't have SecureBoot certificates/dbs/pks, but it's just one of the problems that your NVRAM can suffer, check the VSS free space.

OpenCore on the Mac Pro

Thank you @tsialex as always! Your knowledge overwhelms me! I have fixed my problem just reflashing BootROM using the reconstructed one that you made it for me. Now everything is ok again

forums.macrumors.com

Thanks. So I did check my VSS free space. Initially was really low. Like 300 ish. I did a few PRAM resets and got it up to 30000 ish I think. But I’m not entirely sure I understand what this means? Did the Windows install break the garbage collection? Also I notice a lot of “invalid” in there. Is that indicative of a problem as well? If so…what to do?

 

[tsialex]

Thanks. So I did check my VSS free space. Initially was really low. Like 300 ish. I did a few PRAM resets and got it up to 30000 ish I think. But I’m not entirely sure I understand what this means?

It's a good sign and you have to follow this overtime, but this one is just an obvious problem and you probably have other problems that need further investigation.

Did the Windows install break the garbage collection?

No, since you don't have SecureBoot.

It's more a failure overtime problem, since the "filesystem" of the NVRAM volume and the SPI itself were not designed/nor are resilient enough for more than a decade of continuous usage.

Also I notice a lot of “invalid” in there. Is that indicative of a problem as well?

Depends, you could have variable multiplication for MemoryConfig and others. I bet on MemoryConfig.

If so…what to do?

Sent you a PM with instructions.

 

[trifero]

Time to reflash with the one reconstructed by @tsialex . I suggest everyone to get one from him.

 

[Knoxvilletim]

I thought that I've already saw every BootROM weirdness after inspecting so much dumps and nothing would surprise me anymore, but then @Knoxvilletim sent his MP4,1>5,1 dump with 49 SPD caches for the 36JSZF1G72PZ-1G4D DIMM:

View attachment 1802111

Btw, another one with the secondary VSS store overrun:

View attachment 1802114

I want to give a shout out to @tsialex. My early 2009 MP which I updated three years ago to 5,1 worked fine for the most part. I only had occasional issues where it would slow down and my software would hang. Resetting the SMC seemed to clear it up at least temporarily. I posted my issue and @tsialex quickly responded with some suggestions. Long story short, he found my BootROM to be in terrible shape as noted above. It was probably close to bricking. I had no clue as my MP ran fine for the most part. @tsialex provided me with a clean BootROM specifically for my MP along with installation instructions. Worked like a charm and I am so relieved. So many thanks to @tsialex for the support he provides to the community.

 

[tsialex]

I want to give a shout out to @tsialex. My early 2009 MP which I updated three years ago to 5,1 worked fine for the most part. I only had occasional issues where it would slow down and my software would hang. Resetting the SMC seemed to clear it up at least temporarily. I posted my issue and @tsialex quickly responded with some suggestions. Long story short, he found my BootROM to be in terrible shape as noted above. It was probably close to bricking. I had no clue as my MP ran fine for the most part. @tsialex provided me with a clean BootROM specifically for my MP along with installation instructions. Worked like a charm and I am so relieved. So many thanks to @tsialex for the support he provides to the community.

I'm glad that all went well and you repaired the issue in time, I was very surprised with the 49 SPD caches of your Mac Pro dump.

I started to look at this issue after @crjackson2134 first noticing the issue with his Mac Pro and then with @Eschers Mac Pros. Since then I started to informally track the DIMMs that are prone to this issue and I'll publish the worst offenders later, maybe with list of DIMMs to avoid.

 

[rGiskard]

Late to the party with this, but my 2009 cMP cross-flashed to macpro5,1 has been running El Capitan for years. I never wanted to update the firmware before because of the cross-flash and it kind of was neglected as I moved on to other Macs.

Did a BootROM dump, 5x nvRAM zap, and a second BootROM dump. I think my BootROM is hosed.

Mac Pro configured with single Intel W3690 and four DIMMs.
BootROM: MP51.007F.B03

Here's the VSS store sizes,

BootROM before 5x zap
1st VSS store free space: 43435
2nd VSS store free space: 53437

BootROM zapped 5x
1st VSS store free space: 47330
2nd VSS store free space: 65448

Free space looks promising, but the 2nd VSS store is empty, so apparently the circular log has lost the head/tail and cannot back up. I did another 5x nvRAM zap but there were no further changes.

Also lots of "Invalid" entries, which I suppose is bad?

Binwalk output:

Is the BootROM due for a reconstruction? I was going to update this Mac Pro to Mojave and sell it but I don't want to dump a time bomb on someone (and this could be the excuse I need to keep it, heh.)

 

[tsialex]

Late to the party with this, but my 2009 cMP cross-flashed to macpro5,1 has been running El Capitan for years. I never wanted to update the firmware before because of the cross-flash and it kind of was neglected as I moved on to other Macs.

Did a BootROM dump, 5x nvRAM zap, and a second BootROM dump. I think my BootROM is hosed.

Mac Pro configured with single Intel W3690 and four DIMMs.
BootROM: MP51.007F.B03

Here's the VSS store sizes,

BootROM before 5x zap
1st VSS store free space: 43435
2nd VSS store free space: 53437

BootROM zapped 5x
1st VSS store free space: 47330
2nd VSS store free space: 65448

Free space looks promising, but the 2nd VSS store is empty, so apparently the circular log has lost the head/tail and cannot back up. I did another 5x nvRAM zap but there were no further changes.

Also lots of "Invalid" entries, which I suppose is bad?

View attachment 1803842

Binwalk output:

View attachment 1803843

Is the BootROM due for a reconstruction? I was going to update this Mac Pro to Mojave and sell it but I don't want to dump a time bomb on someone (and this could be the excuse I need to keep it, heh.)

First thing, why you are still running this ancient BootROM release?

The real problem here is the cross-flashing process, where you update just the EFI firmware component of the BootROM image. The NVRAM volume, the Firmware Restoration module and the CSM continue to be the original one from the MP4,1 firmware. This make the MP4,1>5,1 Mac Pros extremely susceptible of BootROM corruption.

While not all invalid entries are really invalid to the EFI firmware, UEFITool don't understand some GUIDs, this demands further investigation. Check your PMs.

 

[CDFermi]

Need help shutting down fan on a MBA2013 (M13). It was working just fine (Catalina) after updating to 1TB SSD. WENT abroad and the MBA somehow updated from Catalina to Big Sur (Firmware upgrade to 431:0.0.0) even though I had install updates automatically unchecked! and now the MBA comes up with new errors such high fan speed (heat transfer paste new!). Tried many tricks to change Firmware (should be 421:0.0.0.) including most hacks posted here plus trying old USB (diskwarrier) installer to Yosemite, and also Mojave (running fine on my trusty MBP 2012. I assume that Big Sur installer changed Firmware from 421 to 431. Any sudo command (I am not a programmer), other at terminal would be appreciated. Of other solutions would be welcomed as well. Thanks.

 

[tsialex]

Need help shutting down fan on a MBA2013 (M13). It was working just fine (Catalina) after updating to 1TB SSD. WENT abroad and the MBA somehow updated from Catalina to Big Sur (Firmware upgrade to 431:0.0.0) even though I had install updates automatically unchecked! and now the MBA comes up with new errors such high fan speed (heat transfer paste new!). Tried many tricks to change Firmware (should be 421:0.0.0.) including most hacks posted here plus trying old USB (diskwarrier) installer to Yosemite, and also Mojave (running fine on my trusty MBP 2012. I assume that Big Sur installer changed Firmware from 421 to 431. Any sudo command (I am not a programmer), other at terminal would be appreciated. Of other solutions would be welcomed as well. Thanks.

Apple removed the possibility of BootROM downgrades 10+ years ago, you can only flash a newer version, never the same or earlier.

It's only possible to downgrade by other means, you'll need to reprogram the SPI flash memory externally with an external SPI flash programmer and you need to have a backup dump of the BootROM saved before the upgrade.

Ask for more info on the MacBook Air forum.

 

[CDFermi]

Thanks. I bought the mba used and do not have anything in it. I guess I am out of luck. What a shame. For those of us who helped Apple since the 80’s fine tune it’s products (beta testing by knowledgeable users like you), it is sad to experience the latest trend to force users who may not be able to purchases new products to dump their good old products!

 

[CDFermi]

How about just stopping the fan noise? Any remedy?

 

[tsialex]

Thanks. I bought the mba used and do not have anything in it. I guess I am out of luck. What a shame. For those of us who helped Apple since the 80’s fine tune it’s products (beta testing by knowledgeable users like you), it is sad to experience the latest trend to force users who may not be able to purchases new products to dump their good old products!

This argument of yours don't stand scrutiny. Apple removed downgrades to remove the possibility of firmware implants, a long request for anyone in the security field. You can't have security with the possibility of workarounds. Also, you can downgrade it by other means, if you prepared beforehand and have the equipment.

If the BootROM upgrade caused this, other people also would have it. Btw, it's the SMC that controls the fan and not the BootROM firmware.

How about just stopping the fan noise? Any remedy?

Don't get me wrong, but did you noticed that you are on a MacPro5,1 thread? Please go to the MacBook Air forum and search for a more appropriate thread or open one there.

 

[gradyg22]

Hi @tsialex. I'm here with the same issue I'm sure you're used to hearing by this point. I have been using Opencore on my 4,1->5,1 Mac Pro. When I've had issues, I NVRAM reset, and Windows will boot up without Opencore protection. Today, after solving some other problems, I noticed no matter what, the Mac would always boot right to Windows, bypassing Opencore. Google took me to another MacRumors thread, a guy with the same issue. In there, you instructed that he needed to 3x NVRAM reset with just a Mojave disk and a Windows disk, and that if it still booted to Windows, the bootrom was corrupted. Well, guess what my Mac Pro is now doing. I'm feeling hopeful after seeing all the help you gave others. I've seen you referred to a couple times as the 'BootROM Guru,' so any of your thoughts or help would be appreciated. Thank you in advance!

 

[tsialex]

Hi @tsialex. I'm here with the same issue I'm sure you're used to hearing by this point. I have been using Opencore on my 4,1->5,1 Mac Pro. When I've had issues, I NVRAM reset, and Windows will boot up without Opencore protection. Today, after solving some other problems, I noticed no matter what, the Mac would always boot right to Windows, bypassing Opencore. Google took me to another MacRumors thread, a guy with the same issue. In there, you instructed that he needed to 3x NVRAM reset with just a Mojave disk and a Windows disk, and that if it still booted to Windows, the bootrom was corrupted. Well, guess what my Mac Pro is now doing. I'm feeling hopeful after seeing all the help you gave others. I've seen you referred to a couple times as the 'BootROM Guru,' so any of your thoughts or help would be appreciated. Thank you in advance!

Power off immediately, remove any disks besides your native Mojave install. Don't let you Mac Pro boot anything except a fully native macOS install.

You will need a BootROM reconstruction, do it before you get yourself a brick to recover. What happened is one of the adverse effects of cross-flashing to MP5,1 overtime. I'll send a PM with instructions.

Btw, if you have BootCamp on the same disk, you will need to remove/format the BootCamp partition with another Mac (or install Mojave to a new/nuked disk with another Mac, don't use your corrupted Mac Pro to do it).

 

[trifero]

Hi @tsialex. I'm here with the same issue I'm sure you're used to hearing by this point. I have been using Opencore on my 4,1->5,1 Mac Pro. When I've had issues, I NVRAM reset, and Windows will boot up without Opencore protection. Today, after solving some other problems, I noticed no matter what, the Mac would always boot right to Windows, bypassing Opencore. Google took me to another MacRumors thread, a guy with the same issue. In there, you instructed that he needed to 3x NVRAM reset with just a Mojave disk and a Windows disk, and that if it still booted to Windows, the bootrom was corrupted. Well, guess what my Mac Pro is now doing. I'm feeling hopeful after seeing all the help you gave others. I've seen you referred to a couple times as the 'BootROM Guru,' so any of your thoughts or help would be appreciated. Thank you in advance!

Please follow @tsialex instructions. I suggest, when everything is healthy again, that you install Windows in Legacy Mode.

 

[joevt]

Hi @tsialex. I'm here with the same issue I'm sure you're used to hearing by this point. I have been using Opencore on my 4,1->5,1 Mac Pro. When I've had issues, I NVRAM reset, and Windows will boot up without Opencore protection. Today, after solving some other problems, I noticed no matter what, the Mac would always boot right to Windows, bypassing Opencore. Google took me to another MacRumors thread, a guy with the same issue. In there, you instructed that he needed to 3x NVRAM reset with just a Mojave disk and a Windows disk, and that if it still booted to Windows, the bootrom was corrupted. Well, guess what my Mac Pro is now doing. I'm feeling hopeful after seeing all the help you gave others. I've seen you referred to a couple times as the 'BootROM Guru,' so any of your thoughts or help would be appreciated. Thank you in advance!

Always make sure there is no partitions with a bootx64.efi that belongs to Windows. Will Windows install a bootx64.efi on some occasions? Such as during an update?

Maybe OpenCore's Windows UEFI nvram stomping mitigation would work better as a Driver#### boot driver - If Windows installs bootx64.efi without you knowing, the Driver#### will still get executed as long as you haven't zapped the PRAM since installing it. One of OpenCore's goals is to eventually be installed in firmware so that won't be necessary? But updating the firmware for every OpenCore update might be excessive.

Please follow @tsialex instructions. I suggest, when everything is healthy again, that you install Windows in Legacy Mode.

There's probably a method to convert Windows UEFI to legacy. First remove the EFI files. Then make the disk hybrid GPT/MBR with boot code in the MBR (use iPartition.app or gpt-fdisk = gdisk). Then make sure the legacy boot files exist on the Windows partition (including boot code in the first block of the partition) There's a utility on the Windows install DVD to fix up the boot. There might be other issues with the conversion such as drivers? I haven't tried it before.

 

[trifero]

Always make sure there is no partitions with a bootx64.efi that belongs to Windows. Will Windows install a bootx64.efi on some occasions? Such as during an update?

Maybe OpenCore's Windows UEFI nvram stomping mitigation would work better as a Driver#### boot driver - If Windows installs bootx64.efi without you knowing, the Driver#### will still get executed as long as you haven't zapped the PRAM since installing it. One of OpenCore's goals is to eventually be installed in firmware so that won't be necessary? But updating the firmware for every OpenCore update might be excessive.


There's probably a method to convert Windows UEFI to legacy. First remove the EFI files. Then make the disk hybrid GPT/MBR with boot code in the MBR (use iPartition.app or gpt-fdisk = gdisk). Then make sure the legacy boot files exist on the Windows partition (including boot code in the first block of the partition) There's a utility on the Windows install DVD to fix up the boot. There might be other issues with the conversion such as drivers? I haven't tried it before.

There are lot of guides for convert windows UEFI to Legacy.

 

[tsialex]

Please follow @tsialex instructions. I suggest, when everything is healthy again, that you install Windows in Legacy Mode.

If it was a classic case of SecureBoot trashing the NVRAM, a deep NVRAM reset would erase any 8BE4DF61-93CA-11D2-AA0D-00E098032B8C variables (this is the GUID of the variables that control boot). The user would not have bless, but would have the BootPicker working.

I have a hunch, based on past cases where you can only boot Windows, that this is more complex than just SecureBoot. Seems more a case of a early-2009/MP4,1 NVRAM volume that auto-destructed itself - garbage collection is not working, NVRAM reset process is now useless and the secondary VSS store header will be overrun.

 

[tsialex]

I have a hunch, based on past cases where you can only boot Windows, that this is more complex than just SecureBoot. Seems more a case of a early-2009/MP4,1 NVRAM volume that auto-destructed itself - garbage collection is not working, NVRAM reset process is now useless and the secondary VSS store header will be overrun.

My hunch was almost dead right. The VSS store circular log lost it's tail, garbage collection is not working and all free space is now identified as a padding area. This problem can be easily identified with UEFITool:

This is the full binwalk report against my diagnostic signatures, hardware-ids redacted, this NVRAM have one SecureBoot combo and multiplication of both MemoryConfig and bluetoothActiveControllerInfo variables.

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
1179810       0x1200A2        NVRAM MemoryConfig type: (g)
1181858       0x1208A2        NVRAM MemoryConfig type: (h)
1183906       0x1210A2        NVRAM MemoryConfig type: (i)
1185954       0x1218A2        NVRAM MemoryConfig type: (j)
1187293       0x121DDD        NVRAM MemoryConfig type: (g)
1189341       0x1225DD        NVRAM MemoryConfig type: (h)
1192313       0x123179        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1194576       0x123A50        NVRAM MemoryConfig type: (g)
1196624       0x124250        NVRAM MemoryConfig type: (h)
1198716       0x124A7C        NVRAM MemoryConfig type: (g)
1200764       0x12527C        NVRAM MemoryConfig type: (h)
1205181       0x1263BD        NVRAM bluetoothActiveControllerInfo
1207942       0x126E86        NVRAM bluetoothActiveControllerInfo
1208109       0x126F2D        NVRAM MemoryConfig type: (g)
1210157       0x12772D        NVRAM MemoryConfig type: (h)
1212669       0x1280FD        NVRAM bluetoothActiveControllerInfo
1212794       0x12817A        NVRAM IASInstallPhaseList log plist
1212834       0x1281A2        XML document, version: "1.0"
1214207       0x1286FF        NVRAM SIP state, type: (w)
1214680       0x1288D8        NVRAM bluetoothActiveControllerInfo
1214847       0x12897F        NVRAM MemoryConfig type: (g)
1216895       0x12917F        NVRAM MemoryConfig type: (h)
1245255       0x130047        NVRAM start of the 2nd VSS store
1343511       0x148017        bzip2 compressed data, block size = 100k
1345189       0x1486A5        HardwareID Base_xx: 20
1345198       0x1486AE        HardwareID 11-digits SSN: H00xxxxx4PD
1345215       0x1486BF        HardwareID 3-digit HWC model: 4PD
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: C07xxxxxxxxxx, BuildDate: 1003xx1003xx

Some more boots and @gradyg22 would have a brick to recover.

Btw, this Mac Pro is a factory refurb one, see the backplane MLB with a 17 digits, and maybe a B08.

 

[trifero]

If it was a classic case of SecureBoot trashing the NVRAM, a deep NVRAM reset would erase any 8BE4DF61-93CA-11D2-AA0D-00E098032B8C variables (this is the GUID of the variables that control boot). The user would not have bless, but would have the BootPicker working.

I have a hunch, based on past cases where you can only boot Windows, that this is more complex than just SecureBoot. Seems more a case of a early-2009/MP4,1 NVRAM volume that auto-destructed itself - garbage collection is not working, NVRAM reset process is now useless and the secondary VSS store header will be overrun.

But anyway, installing Windows in Legacy mode better than in EFI mode is a good advice. Don´t you think?

 

[diegotv]

@tsialex
Just finished going through this awesomely long thread, Would like to thank you for your time and patience....

Have a Mid 2012 MP5,1 with a Radeon 8Gb RX VEGA 56 running Catalina using Dosdude's patch, the latest native MacOs is High Sierrra 10.13.6 but the Boot ROM wasnt updated it still is MP51.0087.B00.

I would like to update to 144.0.0.0.0 so
can I do it thru the macOSUpd.RecoveryHDUpdate.pkg described on #1,569 or should i try to reinstall High Sierra, mojave, path?
If macOSUpd.RecoveryHDUpdate.pkg is a go, can i do it from the High Sierra MacOS or do i need to upgrade to Mojave? and do i still need to disconnect/take out all drives, 4k monitors, pcie cards?

Thank you