Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Hi @tsialex,
I have a genuine MacPro5,1 (2010) with BootROM 144.0.0.0.0. I have problems installing newer macOS with OCLP; the installer repeatedly fails with MobileSoftwareUpdateErrorDomain Code=53 – Splat global ticket failed to verify.

Macschrauber's Rom Dump reports:

  • Length of 2nd VSS Store is wrong (FF FF FF FF)
  • VSS2 (Formatted) (VSS2 header problem)
  • one unnamed VALID variable
  • only 12110 bytes free of 65464
  • CRC32 checksums OK

NVRAM variables can be written, but do not persist after reboot.
I have the original 4 MB firmware dump.

What to do? 🙂

Unfortunately, you have a clearly corrupt NVRAM volume, no doubt.

Some things to check and try:

  1. Check the RTC battery voltage, replace it with a real BR2032 if below 2,95V. There were cases in the past that when the RTC was not working correctly, you couldn't reset the NVRAM.
  2. Did you tried a deep NVRAM reset?

    Sometimes the deep NVRAM reset can solve the 2nd VSS store NVRAM corruption, so, always try it first.

    If the 2nd VSS store is still corrupt after doing it, you gonna need the BootROM Reconstruction service.

    To deep NVRAM reset, install a wired KB that works for NVRAM resets (be aware that not all KB models work for multiple consecutive NVRAM resets), press and keep pressed CMD-ALT-P-R until you hear at least the 4th chime.
  3. Maybe you could also need a SPI flash memory replacement, one of the clues of a defective/spent SPI is the no persistence of NVRAM variables. Obviously, the macOS install will fail if the NVRAM values are not being staged correctly.

    You can backup the BootROM again, save it to your cloud storage, and then flash the MP51.fd temporarily to diagnose if the SPI is damaged.

    Your Mac Pro won't have any serialization, won't work with iCloud/FaceTime/Messages or any app that require serials, so, this is not a solution but just a diagnostics step, once MP51.fd is flashed successfully will have a working NVRAM volume, so, if the same issue with the NVRAM entries not surviving reboot/power off still happens, you gonna need to replace the SPI.

    Mojave 10.14.6 full installer have the MP51.fd:

    Code:
    /Applications/Install macOS Mojave.app/Contents/Resources/Firmware/MP51.fd


    If the SPI is really kaput, maybe you can't even successfully flash the MP51.fd, so be aware that there is some risk involved here.
 
My MP 5,1 is showing an odd Boot ROM version

Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: 6-Core Intel Xeon
Processor Speed: 3.46 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 12 MB
Hyper-Threading Technology: Enabled
Memory: 64 GB
Boot ROM Version: 9144.1.0.1.0
SMC Version (system): 1.39f11
SMC Version (processor tray): 1.39f11

what would have caused that? and how do i fix it?
 
Boot ROM Version: 9144.1.0.1.0

This is spoofing the System Firmware/BootROM version caused by MartinLo OC/OCLP/etc to avoid macOS trying to install iMacPro1,1/MacPro7,1 firmware upgrades erroneously when spoofing another Mac to run unsupported macOS releases.

Normal and expected behaviour when running OC/OCLP, the System Firmware with a enormous number is used so macOS never finds an old firmware installed. Besides that, MartinLo also uses the suffix (xxxx.1.0.1.0) to clearly show the current version of his config installed. OCLP instead uses 9999.999.999.999.999.
 
This is spoofing the System Firmware/BootROM version caused by MartinLo OC/OCLP/etc to avoid macOS trying to install iMacPro1,1/MacPro7,1 firmware upgrades erroneously when spoofing another Mac to run unsupported macOS releases.

Normal and expected behaviour when running OC/OCLP, the System Firmware with a enormous number is used so macOS never finds an old firmware installed. Besides that, MartinLo also uses the suffix (xxxx.1.0.1.0) to clearly show the current version of his config installed. OCLP instead uses 9999.999.999.999.999.
Thank for the info Alex, I always wondered about that.
 
This is spoofing the System Firmware/BootROM version caused by MartinLo OC/OCLP/etc to avoid macOS trying to install iMacPro1,1/MacPro7,1 firmware upgrades erroneously when spoofing another Mac to run unsupported macOS releases.

Normal and expected behaviour when running OC/OCLP, the System Firmware with a enormous number is used so macOS never finds an old firmware installed. Besides that, MartinLo also uses the suffix (xxxx.1.0.1.0) to clearly show the current version of his config installed. OCLP instead uses 9999.999.999.999.999.
ah ok i am using Martin lo'c OC, so its nothing to worry about then? no need to flash the boot rom to correct it?

Thanks Tsialex
 
Try deep NVRAM-reset.

Any OCLP-based OS installations present?
NVRam deep clean did nothing.
yes i tried an OCPL install of Monterey however it would not boot either through OCPL or matins 1.0.1 config.

tried a stand alone steamOS install yesterday, only the steamOS drive in bay 1 no OC of any kind,
but it would not always boot, and it could not find my factory WFI and Bluetooth cards,
so I need to upgrade those to Finnish that up,
also thinking i may need martins OC with linux OS support in the OC config.Plist to boot the linux correctly.

I'm using martins OC because i have windows 11 installed in bay 2 for gaming,
don't wont windows to brick my Boot rom.

had this old gal since 2016 and its never missed a beat.
 
Last edited:
Normal and expected from MartinLo OC. Said that, check if your BootROM image is healthy.
cheers for the info, i have Macschrauber's Rom Dump which i used to back up my Boot rom,
can i test the back up image with the test feature in that ?

Never mind lol just answered that one my self, yes i can 8).
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.