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

[Bmju]

Many thanks @startergo, @Macschrauber for your very helpful answers. I'll definitely try your tips @startergo and try to get it to work - am I correct that using flashrom from Linux (e.g. as here) is basically doing the same thing? And so I guess that ROMTool - if/when I can get it to work - and flashrom have interchangeable data files, at least in theory?

 

[Dayo]

boot up time hit count would include whatever boot.efi does but probably not xnu kernel.

Yeah, a few things to ponder but it was just a test build to do check/count out of curiosity and had any value beyond that at the time. Information gleaned was enough.

I wonder how ExitBootServices works so your runtime wrap doesn't cause a crash while trying to do file I/O...

You are right though that RefindPlus does not hang as it should on the surface in that circumstance.

Perhaps this is because it actually runs OS loaders as child images and that when these call ExitBootServices, the call actually goes to RefindPlus and not to the firmware directly, allowing RefindPlus to shut itself down first and pass this call on to the firmware ... or something along those lines.

Just an hypothesis ... something to look into properly down the line.

UPDATE 1:
Had a quick look and it is definitely nothing to do with being ChildImage.

The child image is called indeed, but as an OS Loader, it is a one way call as these never return ... I suppose an OS Loader might return on ExitbootServices failure (Not Sure).

Typically, the only feedback given by an OS Loader is an ExitBootServices Event raised just before loading the OS Kernel.

One possibility is the the MemLogLib used by RP does not make any BootServices->XYZ function calls to update the log (once the basics are done to set it up etc).

UPDATE 2:
Paid some more attention to MemLogLib and I can see that it is installed as a protocol on the Global Image Handle and that it uses the EDK2 IoLib. This may explain continued access beyond ExitBootServices. I also note that logging survives a warm reset. That is, it continues to log to the same file in use before a warm reset.

 

[startergo]

Many thanks @startergo, @Macschrauber for your very helpful answers. I'll definitely try your tips @startergo and try to get it to work - am I correct that using flashrom from Linux (e.g. as here) is basically doing the same thing? And so I guess that ROMTool - if/when I can get it to work - and flashrom have interchangeable data files, at least in theory?

It is the same. From Linux is even easier because DirehtHW.kext is not needed. Also add Dmidecode (you may have to compile acidanthera's dmidecode for Linux)

 

[tsialex]

Many thanks @startergo, @Macschrauber for your very helpful answers. I'll definitely try your tips @startergo and try to get it to work - am I correct that using flashrom from Linux (e.g. as here) is basically doing the same thing? And so I guess that ROMTool - if/when I can get it to work - and flashrom have interchangeable data files, at least in theory?

ROMTool is just a GUI for flashrom. Btw, flashrom only runs after 10.8.something, forgot which release.

 

[startergo]

from Linux (e.g. as here)

By the way I looked at the video and @dosdude1 did not correct the CRC checksum after changing the s/n. @tsialex wouldn't that cause an issue? How about the ME region? Any checksums there?

 

[tsialex]

By the way I looked at the video and @dosdude1 did not correct the CRC checksum after changing the s/n. @tsialex wouldn't that cause an issue?

Checksum being invalid for the Fsys store itself don't make it the MacPro5,1 un-bootable, you can even boot with just MP51.fd where the Fsys store is just zeros, but all sort of issues later happen with iCloud/Messages/FaceTime when you have hardwareIDs that don't match.

People frequently dump other Macs or get dumps from the net, change just the SSN and then don't understand why they can't login with Apple services or have crazy MDM issues.

How about the ME region?

ME is disabled for a lot of Macs, not even supported for MacPro5,1.

Any checksums there?

ME region, for Macs that have it enabled, have to be exact and it's signed. Any error there and you get your Mac un-bootable.

Btw, starting with MacPro6,1, there are other things that you need to adjust, like scap encapsulation.

 

[tsialex]

@Bmju After you dump your early-2009, PM me the dump, I'll correctly upgrade it to 144.0.0.0.0 for you, without the need to make a mess with cross-flashing.

 

[Syncretic]

After a request from @Macschrauber, I added a few minor features and fixed some unfortunate bugs in scanvss. The most notable new feature is the ability to scan a BootROM dump file instead of the local flash. I updated the version attached to my previous post (original didn't have a version number; current is 0.12). Since it's posted publicly, feel free to use this tool as you see fit (attribution would be nice, but of course, it's unenforceable). The usual disclaimers apply - NO WARRANTY, USE AT YOUR OWN RISK, etc.

Here is the terminal log from @Syncretic tool:

sudo /usr/bin/kmutil load -p /var/root/Library/Application\ Support/ROMTool/DirectHW.kext
x299@x299s-iMac-Pro ~ % sudo /Users/x299/Downloads/scanvss

------------------
VSS1 (INVALID SIGNATURE) (UNKNOWN FORMAT) (UNKNOWN HEALTH)
------------------
zsh: segmentation fault  sudo /Users/x299/Downloads/scanvss

Is that on a real Mac Pro, or a hack? What BootROM version?

 

[startergo]

Is that on a real Mac Pro, or a hack? What BootROM version?

on a hack

 

[Syncretic]

on a hack

My guess would be that a hack would not map the (virtual) BootROM the same way a real Mac does, meaning that scanvss is unlikely to ever work on a Hackintosh (sorry!). It may or may not work on non-Pro Macs; someone else would need to test that.

 

[tsialex]

It may or may not work on non-Pro Macs; someone else would need to test that.

Below is the output for my late-2012 Mac mini, same results for my early-2013 15" rMBP:

------------------
VSS1 (INVALID SIGNATURE) (UNKNOWN FORMAT) (GARBAGE COLLECTION INTERRUPTED. THIS VSS WILL PROBABLY BE ERASED DURING NEXT REBOOT.)
------------------
(VSS1 variable area is empty!)
---
Free space appears to be correctly formatted and valid.
Apparent free space in VSS1: 65448 bytes
Found 0 variables (0 valid, 0 deleted)
Reclaimable dead space (deleted variables): 0 bytes

------------------
VSS2 (INVALID SIGNATURE) (UNKNOWN FORMAT) (GARBAGE COLLECTION INTERRUPTED. THIS VSS WILL PROBABLY BE ERASED DURING NEXT REBOOT.)
NOTE: VSS2 is the result of the most recent garbage collection operation.
      It gets copied to VSS1 after garbage collection, so whenever it's not
      empty, it resembles the first part of VSS1.
      If garbage collection failed, VSS2 will be copied to VSS1 during the
      next reboot, if possible.
      Otherwise, it is ignored during normal operation.
------------------
(VSS2 variable area is empty!)
---
Free space appears to be correctly formatted and valid.
Apparent free space in VSS2: 65448 bytes
Found 0 variables (0 valid, 0 deleted)
Reclaimable dead space (deleted variables): 0 bytes

Edit:

Just tested my mid-2012 13" MBP, same results.

 

[startergo]

Many thanks @startergo, @Macschrauber for your very helpful answers. I'll definitely try your tips @startergo and try to get it to work - am I correct that using flashrom from Linux (e.g. as here) is basically doing the same thing? And so I guess that ROMTool - if/when I can get it to work - and flashrom have interchangeable data files, at least in theory?

There is another tool for dumping ROM and much more: chipsec. I am not sure it will work on such an old processor but at least the chipsec.kext (which you have to compile and place in ~/Downloads/chipsec/chipsec/helper/osx) is targeted to 10.7 (Lion).

Spoiler: Output

sudo python3 /Users/x299/Downloads/chipsec/chipsec_util.py  spi info
Password:

################################################################
##                                                            ##
##  CHIPSEC: Platform Hardware Security Assessment Framework  ##
##                                                            ##
################################################################
[CHIPSEC] Version : 1.8.3
[CHIPSEC] OS      : Darwin 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64
[CHIPSEC] Python  : 3.10.4 (64-bit)

Executing: /usr/bin/kmutil load -p /Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext
[CHIPSEC] API mode: using CHIPSEC kernel module API
[CHIPSEC] Helper  : OSXHelper (/Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext)
[CHIPSEC] Platform: Intel Xeon Processor E5/E7 v5 (Skylake)
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 2020
[CHIPSEC]      RID: 07
[CHIPSEC] PCH     : Intel X299 (200 series) PCH
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: A2D2
[CHIPSEC]      RID: 00
[CHIPSEC] Executing command 'spi' with args ['info']

[CHIPSEC] SPI flash memory information

============================================================
SPI Flash Map
------------------------------------------------------------

BIOS Flash Primary Region
------------------------------------------------------------
BFPREG = 0FFF0280:
  Base  : 00280000
  Limit : 00FFFFFF

------------------------------------------------------------
Flash Region             | FREGx Reg | Base     | Limit   
------------------------------------------------------------
0 Flash Descriptor       | 00000000  | 00000000 | 00000FFF
1 BIOS                   | 0FFF0280  | 00280000 | 00FFFFFF
2 Intel ME               | 027F0001  | 00001000 | 0027FFFF
3 GBe                    | 00007FFF  | 07FFF000 | 00000FFF
4 Platform Data          | 00007FFF  | 07FFF000 | 00000FFF
5 Flash Region 5         | 00007FFF  | 07FFF000 | 00000FFF

============================================================
SPI Flash Descriptor
------------------------------------------------------------

Flash Signature and Descriptor Map:
0FF0A55A
00040003
5A100208
00310330
0FF0A55A

Components:
125C00F5
AD604221
C7C4B9B7

Regions:
00000000
0FFF0280
027F0001
00007FFF
00007FFF

Masters:
00A00F00
00400D00
00800900

============================================================
SPI Opcode Info
------------------------------------------------------------
PREOP : 0x0000
OPTYPE: 0x0000
OPMENU: 0x0000000000000000

Prefix Opcode 0 = 0x00
Prefix Opcode 1 = 0x00
------------------------------------------------------------
Opcode # | Opcode | Optype | Description
------------------------------------------------------------
Opcode0  | 0x00   | 0      | SPI read cycle without address
Opcode1  | 0x00   | 0      | SPI read cycle without address
Opcode2  | 0x00   | 0      | SPI read cycle without address
Opcode3  | 0x00   | 0      | SPI read cycle without address
Opcode4  | 0x00   | 0      | SPI read cycle without address
Opcode5  | 0x00   | 0      | SPI read cycle without address
Opcode6  | 0x00   | 0      | SPI read cycle without address
Opcode7  | 0x00   | 0      | SPI read cycle without address

============================================================
SPI Flash Protection
------------------------------------------------------------

SPI Flash Region Access Permissions
------------------------------------------------------------

BIOS Region Write Access Grant (00):
  FREG0_FLASHD: 0
  FREG1_BIOS  : 0
  FREG2_ME    : 0
  FREG3_GBE   : 0
  FREG4_PD    : 0
  FREG5       : 0
BIOS Region Read Access Grant (00):
  FREG0_FLASHD: 0
  FREG1_BIOS  : 0
  FREG2_ME    : 0
  FREG3_GBE   : 0
  FREG4_PD    : 0
  FREG5       : 0
BIOS Region Write Access (4A):
  FREG0_FLASHD: 0
  FREG1_BIOS  : 1
  FREG2_ME    : 0
  FREG3_GBE   : 1
  FREG4_PD    : 0
  FREG5       : 0
BIOS Region Read Access (CF):
  FREG0_FLASHD: 1
  FREG1_BIOS  : 1
  FREG2_ME    : 1
  FREG3_GBE   : 1
  FREG4_PD    : 0
  FREG5       : 0

BIOS Region Write Protection
------------------------------------------------------------
[*] BC = 0x00000AAA << BIOS Control (b:d.f 00:31.5 + 0xDC)
    [00] BIOSWE           = 0 << BIOS Write Enable
    [01] BLE              = 1 << BIOS Lock Enable
    [02] SRC              = 2 << SPI Read Configuration
    [04] TSS              = 0 << Top Swap Status
    [05] SMM_BWP          = 1 << SMM BIOS Write Protection
    [06] BBS              = 0 << Boot BIOS Strap
    [07] BILD             = 1 << BIOS Interface Lock Down

SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR1 (88)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR2 (8C)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR3 (90)     | 00000000 | 00000000 | 00000000 | 0   | 0
PR4 (94)     | 00000000 | 00000000 | 00000000 | 0   | 0

[CHIPSEC] (spi) time elapsed 0.005
Executing: /usr/bin/kmutil unload -p /Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext
x299@x299s-iMac-Pro chipsec-1.8.3 % sudo python3 /Users/x299/Downloads/chipsec/chipsec_util.py  spi dump rom.bin

################################################################
##                                                            ##
##  CHIPSEC: Platform Hardware Security Assessment Framework  ##
##                                                            ##
################################################################
[CHIPSEC] Version : 1.8.3
[CHIPSEC] OS      : Darwin 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64
[CHIPSEC] Python  : 3.10.4 (64-bit)

Executing: /usr/bin/kmutil load -p /Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext
[CHIPSEC] API mode: using CHIPSEC kernel module API
[CHIPSEC] Helper  : OSXHelper (/Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext)
[CHIPSEC] Platform: Intel Xeon Processor E5/E7 v5 (Skylake)
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: 2020
[CHIPSEC]      RID: 07
[CHIPSEC] PCH     : Intel X299 (200 series) PCH
[CHIPSEC]      VID: 8086
[CHIPSEC]      DID: A2D2
[CHIPSEC]      RID: 00
[CHIPSEC] Executing command 'spi' with args ['dump', 'rom.bin']

[CHIPSEC] Dumping entire SPI flash memory to 'rom.bin'
[CHIPSEC] it may take a few minutes (use DEBUG or VERBOSE logger options to see progress)
[CHIPSEC] BIOS region: base = 0x00280000, limit = 0x00FFFFFF
[CHIPSEC] Dumping 0x01000000 bytes (to the end of BIOS region)
[spi] reading 0x1000000 bytes from SPI at FLA = 0x0 (in 262144 0x40-byte chunks + 0x0-byte remainder)
[CHIPSEC] Completed SPI flash dump to 'rom.bin'
[CHIPSEC] (spi) time elapsed 113.558
Executing: /usr/bin/kmutil unload -p /Users/x299/Downloads/chipsec/chipsec/helper/osx/chipsec.kext

 

[zzzippp]

I think it would be good for OpenCore to prevent writes to NVRAM variables that are set in config.plist. For example, if you set boot-args in config.plist, then OpenCore should prevent write to boot-args since config.plist will override the value anyway on next boot. Also, since the value comes from config.plist, OpenCore shouldn't write the value because it can just have NVRAM runtime services get the value from memory.

Based on what @Syncretic posted write requests for variable values already existing in NVRAM will be denied, won't they?

So for example, to boot my MacPro5,1 to Big Sur, I chain-load RefindPlus -> OC -> Big Sur, and both RefindPlus and OC are configured to set -no_compat_check in boot-args.

As I understand it, @Dayo has set RefindPlus up to check for -no_compat_check when it loads and won't make a NVRAM write request if it already exists. But if it did make the write request, nothing would happen if that variable value already existed.

OC, on the other hand, is configured to set boot-args to debug=0x144 keepsyms=1 -no_compat_check, and based on what I see when I boot "natively" into macOS Mojave (not via OC), those arguments aren't written to the physical NVRAM. I only see -no_compat_check.

Is that correct? Or is a write of boot-args made to NVRAM every time I boot into Big Sur?

 

[tsialex]

Based on what @Syncretic posted write requests for variable values already existing in NVRAM will be denied, won't they?

So for example, to boot my MacPro5,1 to Big Sur, I chain-load RefindPlus -> OC -> Big Sur, and both RefindPlus and OC are configured to set -no_compat_check in boot-args.

As I understand it, @Dayo has set RefindPlus up to check for -no_compat_check when it loads and won't make a NVRAM write request if it already exists. But if it did make the write request, nothing would happen if that variable value already existed.

OC, on the other hand, is configured to set boot-args to debug=0x144 keepsyms=1 -no_compat_check, and based on what I see when I boot "natively" into macOS Mojave (not via OC), those arguments aren't written to the physical NVRAM. I only see -no_compat_check.

Is that correct? Or is a write of boot-args made to NVRAM every time I boot into Big Sur?

NVRAM entries are re-written to the flash only if the content is different. The entry is always compared with the current stored content.

OC is passing the parameters to the kernel, but not modifying inside the NVRAM volume itself, the boot-args entry don't change it's position in the circular log at each boot if it's what you are asking.

 

[Dayo]

I only see -no_compat_check.

Your query is a RefindPlus/OpenCore integration query.
I will answer on the MyBootMgr thread to keep from going too far off topic here

 

[joevt]

Based on what @Syncretic posted write requests for variable values already existing in NVRAM will be denied, won't they?

So for example, to boot my MacPro5,1 to Big Sur, I chain-load RefindPlus -> OC -> Big Sur, and both RefindPlus and OC are configured to set -no_compat_check in boot-args.

As I understand it, @Dayo has set RefindPlus up to check for -no_compat_check when it loads and won't make a NVRAM write request if it already exists. But if it did make the write request, nothing would happen if that variable value already existed.

While it's probably true that nvram is not written if the value is unchanged, the point of my suggestion is to be able to use different nvram values when I'm not using OpenCore such as when booting an older macOS version. For example, I would like to use different DefaultBackgroundColor values for OpenCore and macOS Startup Manager, so I would set nvram to one color for macOS Startup Manger, and set config.plist to a different color for OpenCore. OpenCore doesn't need to write the config.plist value to nvram - it could just remember it in a buffer. What's the point of putting variables in config.plist if they're going to be put in nvram anyway? I can put them in nvram myself.

OC, on the other hand, is configured to set boot-args to debug=0x144 keepsyms=1 -no_compat_check, and based on what I see when I boot "natively" into macOS Mojave (not via OC), those arguments aren't written to the physical NVRAM. I only see -no_compat_check.

Is that correct? Or is a write of boot-args made to NVRAM every time I boot into Big Sur?

The OC documentation regarding nvram handling is not clear. Maybe booting into macOS from OpenCore and shutting down inside OpenCore have different NVRAM behaviors.

 

[Bmju]

Based on what @Syncretic posted write requests for variable values already existing in NVRAM will be denied, won't they?

So for example, to boot my MacPro5,1 to Big Sur, I chain-load RefindPlus -> OC -> Big Sur, and both RefindPlus and OC are configured to set -no_compat_check in boot-args.

As I understand it, @Dayo has set RefindPlus up to check for -no_compat_check when it loads and won't make a NVRAM write request if it already exists. But if it did make the write request, nothing would happen if that variable value already existed.

OC, on the other hand, is configured to set boot-args to debug=0x144 keepsyms=1 -no_compat_check, and based on what I see when I boot "natively" into macOS Mojave (not via OC), those arguments aren't written to the physical NVRAM. I only see -no_compat_check.

Is that correct? Or is a write of boot-args made to NVRAM every time I boot into Big Sur?

Depending on whether OC config WriteFlash is false or true, OC either sets the non-volatile flag for NVRAM writes, or does not. Volatile values will never be seen after reboot. However, if a variable is requested to be set in OC with WriteFlash false (i.e. volatile), but a different, pre-existing, non-volatile value exists, then the pre-existing value is cleared, for reasons discussed here https://github.com/acidanthera/bugtracker/issues/1212 (basically, there is no other way to set the specified value, given the UEFI NVRAM spec). I'm not exactly sure how this fits with what you're seeing (i.e. if nothing else is resetting boot-args, then after a reboot you should either see the value OC sets, or blank).

I also saw this which might be relevant too: https://github.com/acidanthera/bugtracker/issues/575

 

[Dayo]

Variables are limited to 2048 bytes, including the variable name (as stored in UTF-16) and a 32-byte header (which includes the variable's GUID).

Just as an observation, looking at code in OpenCore's CleanNVRAM tool, they seem to look for variables in 1024 byte chunks. Not sure why. I note that the code is in a loop where the buffer can be enlarged in 1024 byte increments. Presumably always needs at least two loops in view of the above. Wonder why they didn't set it to 2048.

EDIT: Read again and note it says LIMITED above ... Means can be less.

There is no counter or other means to see how many reboots you've held Cmd-Opt-P-R through.

Mac rebooted 2 times (can hear it from the GPU Fan howling 2 times)

I wonder how it knows to boot twice given the apparent absence of a count store ... Some temporary flag added perhaps?

 

[TrumanLA]

For MacPro5,1 BootROM upgrades, please read the first post of the thread below to know how to do the firmware upgrade:

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

For MP4,1 to MP5,1 cross firmware flashing, see this thread below:

Mac Pro Firmware Upgrade Utility Released!

Mac Pro Firmware Upgrade Utility Released!

forum.netkas.org

MacPro5,1 BootROM releases, from the oldest EFI update to the newest:​

​

BootROM Version	Released with:	Type:	Note:
MP51.007F.B03	Mac Pro EFI Firmware Update 1.5	General release	First public released Mac Pro 5,1 firmware update, BootPicker improvements, microcodes vulnerable to Spectre and Meltdown
MP51.0083.B00	10.13 DP5	Beta	Beta APFS support, microcodes vulnerable to Spectre and Meltdown
MP51.0084.B00	10.13 DP6 and 10.13.0	General release	Initial APFS support, microcodes vulnerable to Spectre and Meltdown
MP51.0085.B00	10.13.4 and Mojave DP1 to DP3	General release	APFS support, microcodes vulnerable to Spectre and Meltdown
MP51.0087.B00	10.13.5	General release	Missing microcodes and bricks the Mac Pro if you boot UEFI installed Windows 10
MP51.0089.B00	10.13.6	General release	Spectre/Meltdown mitigated microcodes on the April 2 Microcode Update Guidance.
138.0.0.0.0	10.14 DP7 and 10.14.0	General release	5GT/s support for every PCIe 2.0 card
139.0.0.0.0	10.14.1 DP1	Beta	Minor updates and corrections
140.0.0.0.0	10.14.1 DP3 and 10.14.1 to 10.14.4	General release	Native NVMe boot support, several minor updates and corrections (NVMe is not stable/several bugs found)
141.0.0.0.0	10.14.4 DP2	Beta	Minor updates and corrections
142.0.0.0.0	10.14.4 DP4 and 10.14.5 DP1	Beta	Updated APFSJumpStart EFI module - W3xxx Xeon bricker. This BootROM version was never released outside betas.
144.0.0.0.0	10.14.5 DP4 and 10.14.5	General release	Lot's of corrections, booting improvements, works with W3xxx Xeons. This is the current BootROM release

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.

The whole SPI flash replacement procedure is:

• desolder the U8700 flash memory from the backplane PCB,
• use an external SPI flash programmer and it's own app (or flashrom, if it's on the supported list of programmers) to dump the contents of the SPI flash memory removed from the MacPro backplane,
• program MP51.fd, or your reconstructed never booted BootROM image or even a previously saved backup dump, to the replacement SPI flash memory (Macronix MX25L3205A/MX25L3205D/MX25L3206E, SST 25VF032B),
• verify if the flashing process was done correctly,
• solder back the SPI flash memory,
• while the backplane is outside the case, take a picture of the MLB label near the AirPort Extreme connector, also take a picture of the ESN label, the one on the case near the GPU outputs,
• reinstall the backplane in the Mac Pro case,
• test if the Mac Pro is now capable of POST and it's booting macOS with the replacement flash memory,
• if the Mac Pro is now booting macOS, ask a firmware engineer to do a BootROM reconstruction service based on the corrupt dump, the case ESN and the backplane MLB labels to get your Mac Pro fully working again.

How to do a BootROM dump with ROMTool:

• If you are running anything newer than Mavericks, you will need to disable SIP. You can boot your Recovery partition or you can boot a createinstallmedia USB installer (≥10.11) to disable SIP.
  
  Boot your Recovery partition or boot a createinstallmedia USB installer, open Terminal and then disable SIP with the command:
  

  csrutil disable

  Note: Yosemite SIP is not compatible with ROMTool/flashrom. Don’t use Yosemite at all.
• Do a BootROM dump using ROMTool, zip password is "rom". You need SIP disabled and no AV or any anti-malware running. ROMTool is usually a false-positive to any AV/anti-malware because it uses flashrom and DirectHWAccess.kext. If you have any AV/Malware detection tool installed, do a clean install on another disk, it will be easier and less time consuming than disabling/removing kexts/etc.
  
  
  If ROMTool asks you to confirm what is the model of your SPI flash, it's the 8-pin SOIC flash memory next to the PCIe AUX-B power connector, label U8700 - see the photos below. The model of the SPI flash memory is usually related to the model year:​
  • with early-2009 almost all backplanes have SST25VF032B,
  • with mid-2010 usually is Macronix MX25L3205A or MX25L3205D, sometimes can be MX25L3206E with mid-2010s made in the 1st half of 2012, very rarely is SST25VF032B,
  • with mid-2012 usually is Macronix MX25L3206E, it's not common to see mid-2012 with MX25L3205A or MX25L3205D.
  • If ROMTool don’t ask you the SPI model at all, Apple used a SST25VF032B.

How to check the health of the NVRAM/if the garbage collection is still working:​

There is a extremely simple way (simple here as in not need to know how the NVRAM works/check free space indicators/validate checksums and etc) to check if the garbage collection failed and the need to reflash with the clean dump:

• Dump the BootROM with ROMTool
• Open the dump with the most recent release of UEFITool NE (right now is UEFITool NE A59)
• Go to EFISystemNvDataFvGUID, open it
  
  
  
• Go to the first VSS store, open it:
  
• Click Free space, it's after the last variable/VSS entry:
  
• Check on the right panel the Full size:
  

A clean reconstructed never booted image have the Free Space Full Size as 65448 - this is for a fully empty store:

A normal working single CPU Mac Pro with 3 DIMMs have the Free Space Full Size usually around 45000 to 40000 - this is for a healthy working dump:

A normal working dual CPU Mac Pro with 8 DIMMs (DIMM configuration data and SPD caches stored by MemoryConfig NVRAM entries are what takes the most space inside the VSS store) have the Free space Full size around 35000 to 30000 - this is for a healthy working dump:

A Mac Pro that the garbage collection is not working anymore will have less than 1/3 of Free Space Full Size available, less than 22000 bytes available. Any less than this and you usually start having problems and could even brick your Mac Pro. This is critical with Big Sur and Monterey Software Updates, but also happened in the past with previous macOS versions (examples #1, #2) because the number of variables needed to be set-up for the software updates.

This one has just 8921 and already corrupted the NVRAM volume:

Examples of corruption:​

Where is the secondary VSS store?

This dump below had two different failures, a corrupt circular log and failed garbage collection on primary VSS store where after the corrupt point the circular log was identified as padding, and the secondary VSS store completely trashed and not even being identified by UEFITool anymore. The owner of this early-2009 got it repaired in the nick of time before bricking it.

If you found that your NVRAM volume have any of the issues above and you need a BootROM reconstruction service, send me a PM.

Advice after several bricks over the years:​

First a fact, MacPro5,1 NVRAM was designed back in 2008ish, when the NVRAM was used sparingly. Now we are in 2022 and the NVRAM is used constantly for all sort of things, like all sort the iCloud variables (for example, Wi-Fi credentials for the wireless networks that you connect with your iPhone and MacBooks are saved into the NVRAM) to the several variables needed to bootstrap software updates when you have sealed containers (BigSur and Monterey).

The NVRAM is now the Achilles heel of our MacPro5,1 and I personally don't wait for the garbage collection to fail. Now I have a recurring appointment on my Calendar to flash the never booted BootROM image every 3 months. Since starting doing it, I never had a brick or any NVRAM problems - even with all my crazy tests that bricked so much times my backplanes in the past. Do the same.

I cannot overstate how many solutions are in this thread that would EASILY go unnoticed which took me YEARS to discover bc (no offense) their utility were under-emphasized. (This is meant as praise):

I've only just now figured out some of the things embedded modestly in this post, ie:


FlashROM...........CLI .BIN (ROM) R/W + Verify utility
MiniPro...............TL866x analog of FlashROM
XXD...................CLI Hex Viewer (and editor, kinda).
vbindiff...............Visual Binary Difference
UEFITool.............GUI app that organizes EFI / ROMs



Speaking of which, between
- FlashROM
- CH341a
- UEFITool
... you have all the tools you need to resolve:

- Remove or even see the iCloud email address
- Unlock a PIN (6-digits would take 200 days otherwise)
- Serialize an MLB to match the system SN
- Cleaning the ME (Management Engine)
- Fix - Fsys CRC32 (at 590000 )

- The serial's CRC32 is calculated off the Fsys section, (only).
- UEFITool allows exporting just the Fsys section of the .bin
- Terminal: CRC32 [filename.bin]
- You can just replace it 'backwards per Hex pair', but ...

To acclimate to how the calculated CRC32 is oriented,
calculate the old SN & mimic its order (backwards).


Each ONE of the above subjects / CLI binaries are worthy of threads unto themselves.

I've barely touched on how powerful the references in "tsialex" thread is,
and I bet this is closer to the rule than the exception.

We're all fortunate to have such a knowledgeable resource.

 

[MymarkMacpro]

Hi tsialex

Thanks for the great information you give here first of all.

I waiting for my RX580 to arrive to update my 2009 MP4,1 flashed to5,1 Nac Pro. I have dumped my rom and had a look at it and my limited knowledge and my fear of bricking my cherished Mac has me double checking everything. I seem to have multiple sets of information in the UEFI even after deep cleaning the pram 5 times. I have several intel micro code sets aswell as several VSS stores. Also the motherboard battery is currently out of the system as I am waiting for a new one. Is that an issue?

Any help is very much appreciated

 

[tsialex]

Hi tsialex

Thanks for the great information you give here first of all.

I waiting for my RX580 to arrive to update my 2009 MP4,1 flashed to5,1 Nac Pro. I have dumped my rom and had a look at it and my limited knowledge and my fear of bricking my cherished Mac has me double checking everything. I seem to have multiple sets of information in the UEFI even after deep cleaning the pram 5 times. I have several intel micro code sets aswell as several VSS stores. Also the motherboard battery is currently out of the system as I am waiting for a new one. Is that an issue?

Any help is very much appreciated

You are looking at the wrong place, see below where you have to look:

Anyway, all early-2009 cross-flashed Mac Pros need reconstruction to repair the mess that is the cross-flashing process.

 

[MymarkMacpro]

Damn that was fast. Thanks for your reply. Reconstruction is that costly and willit improve performance?

Mark

 

[tsialex]

Damn that was fast. Thanks for your reply. Reconstruction is that costly and willit improve performance?

Mark

While there are indirect performance improvements from the very improved sensor calibration of late mid-2012 firmwares when compared with an early-2009, see the hardware descriptor evolution, that's not the focus for a cross-flashed - it's to avoid/postpone bricking (and needing to replace the SPI flash memory).

 

[alphascorp]

Hello @tsialex

We briefly chatted here a few days ago about BootRom, I had posted a screenshot from February (now deleted by moderators) showing the free space was 25408.
Today I made a new backup of my BootRom and I checked the free space again and I was very surprised to find that is now 42383. How is this possible?
The only thing I did in 2 months was updating to 11.6.5 last month and to 11.6.6 last week (also updated OCLP from 0.4.1 to 0.4.3). But I don't think that's what freed up the space.

 

[tsialex]

Hello @tsialex

We briefly chatted here a few days ago about BootRom, I had posted a screenshot from February (now deleted by moderators) showing the free space was 25408.
Today I made a new backup of my BootRom and I checked the free space again and I was very surprised to find that is now 42383. How is this possible?
The only thing I did in 2 months was updating to 11.6.5 last month and to 11.6.6 last week (also updated OCLP from 0.4.1 to 0.4.3). But I don't think that's what freed up the space.

View attachment 1993939

View attachment 1993940

The most probable explanation is that the payload for the updates forced the garbage collection to run.