MATT cards are expensive and you still have to pay for the reconstruction service anyway. If you can solder/desolder a SOIC-8 yourself, it's the cheapest and most reliable way to go, but it's not for everyone.
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
MATT cards are expensive and you still have to pay for the reconstruction service anyway. If you can solder/desolder a SOIC-8 yourself, it's the cheapest and most reliable way to go, but it's not for everyone.
Did you ever read the first post? It's one of the first links on the "What to do if your Mac Pro bricked" section…
Hm, good to know, thank you! I personally have a good bootrom (thanks!) but if the price of a Matt card is enough I guess it would make sense to give soldering a go. I don’t like soldering small things, but when I think about it a SOIC-8 is HUGE compared to the 0204 passives I soldered to overclock my old PowerBook…
15+ years later, our sight is obviously not the same, but like you said, it's HUGE and easy enough to do even without any specialized tooling.
I suppose you’re right — I still use through-hole DIP size parts when I can…but nobody else does 😂
As tsialex mentioned it’s explained on the first page, but the gist is that a MATT card is a circuit board with a flash chip for the boot ROM on it, and when it’s attached to the Mac Pro’s backplane board via a special socket the MATT card’s flash chip replaces the onboard boot ROM.
You can replace the boot ROM chip without soldering by attaching one of these, but it sounds like they might be close enough in price to a replacement backplane board itself to not be worth it. (If nothing else, it’s super easy to buy replacement chips to solder, and backplane boards aren’t hard to find on eBay. Only one person makes MATT cards and they sell them directly.)
MATT cards are a solid SPI flash replacement product, but only really make sense for the can't solder crowd or for developers.
For anyone that have some experience soldering, it's not worth at all.
If one can solder the flash chip easily imo its way better than attaching a card to a socket what has oxidation from 10 plus years on it.
Yep, let's not forget that - DeoxIT is not exactly cheap. Even the no-brand contact cleaner sprays are becoming expensive since the start of the pandemic.
Plus they can harm all sort of plastic material if not brushed away properly with isopropanol.
On my regular job I have often to do with vintage components. Some contact cleaners will destroy plastic parts of old switches, potentiometers and such over time.
On my regular job I have often to do with vintage components. Some contact cleaners will destroy plastic parts of old switches, potentiometers and such over time.
Yes, some are so aggressive that we used it to instantly disintegrate RJ45 connectors without harming the cable in datacenter racks where we couldn't cut the connector.
If you have an early-2009 CPU tray, you'll need an early-2009 backplane.
MacPro 5.1 power issue
Serial number of the backplane, MLB: See my writeup for another user: Backplanes: From my spreadsheet, the MLB suffixes below show the model year of the backplane: 1LTB are 2009 backplanes made in 2009 for MP4,1, very early ones. 1LTC are 2009 backplanes made in 2009 for MP4,1. BH7A are...
forums.macrumors.com
Apologies, this probably isn't really the right thread, but I'm not sure what is - happy to be redirected!
Is it possible to reconstruct a bios image suitable for flashing, starting from an .scap file? I do already know how to examine the sections and drivers in an .scap or in a raw firmware dump using uefitool, and ofc I do already know that firmware should be patched with correct serials before flashing. But I don't know how/whether you could go from scap to flashable image. (In fairness, this is in order to downgrade the firmware on an MBP10,2, hence no .fd files, so again, not really on topic - sorry! - but I suspect people with the right knowledge hang out here!)
Is it possible to reconstruct a bios image suitable for flashing, starting from an .scap file? I do already know how to examine the sections and drivers in an .scap or in a raw firmware dump using uefitool, and ofc I do already know that firmware should be patched with correct serials before flashing. But I don't know how/whether you could go from scap to flashable image. (In fairness, this is in order to downgrade the firmware on an MBP10,2, hence no .fd files, so again, not really on topic - sorry! - but I suspect people with the right knowledge hang out here!)
Secure capsules are not the complete BootROM image. Besides all the missing hardware IDs, there is also the ME data missing. In theory, with a full SPI image dump, you can replace the EFI area of the BootROM (you can extract the EFI from the .scap via UEFITool) and make the downgrade work after correcting all the checksums, but you can't re-flash via efiflasher (series of reasons, like downgrades are not accepted, the RSA2048 signing and etc) you'll need to flash with a SPI flash programmer.
AFAIK, there is no tool that can stitch everything automagically.
You can try a shortcut, first dump your whole SPI via the external SPI programmer and save it securely. Next find a whole SPI dump from the version that you want to downgrade or a near one, it's not too difficult ghost hacks and etc, test if it works with your Mac.
After you get it booting, you let the most recent supported macOS release to upgrade the BootROM to the current release. Then you compare both releases + the EFI extracted from the .scap and start to map what you will need to do to your real BootROM image.
I did it some years ago with MacPro6,1 to help codejingle.
Yeah, I think I'd more or less seen that something along those lines _should_ work, at least in theory. Good to know it does!
I don't suppose you have any links to checksum info anyway? Would be very useful to be able to make minor mods, and have it not refuse to boot.
I don't suppose you have any links to checksum info anyway? Would be very useful to be able to make minor mods, and have it not refuse to boot.
Look at Trammell Hudson blogs/presentations about Thunderstrike I & II and also the Legbacore site white papers. Trammell is usually using a 15" Retina MBP as the victim
but almost everything is applicable to you.Also, why you need to downgrade?
There is also lot's of useful info with osxreverser https://reverse.put.as/ white paper/presentations.
Thank you for pointers!
Why do I need to downgrade? Weird story. No one else seems to be reporting it, but on 429.0.0.0.0 on that MBP102, OC debug logging hangs. It appears to hang in the firmware console output, at the point when a line is printed at the bottom of the screen, you get two copies of the last line, then it hangs (which to me looks like it's hanging during the firmware's scrolling and printing code). It can be on any log line, so the more lines you log, the more likely it is to happen (which looks a bit like it must be some sort of race condition). Even more weirdly, once it's happened on a given line, it tends to repeat happening in that line, even after a reboot, but will eventually switch to another line (or even no line before OC stops early console logging, in which case you can then actually boot!). As long as only OC early log is going to console (which it always does, in DEBUG build), and not the rest of the OC debug log (i.e. as long as Target BIT1 is 0), then the system boots more often than it hangs, but only just! This issue can also occur even without OC, but unfortunately something about the OC setup makes it much more likely to occur. I know, wtf, right?
EDIT: It has been suggested to me that if I can make it replicable without OC (i.e. in purely supported code, or at best in a very simple, non-controversial UEFI app), then it may be possible to report it to Apple and get it fixed - but so far, I can't (I can maybe have a program which might show it, one it 10 runs, after several thousand lines of output, when not in OC!! Or repeatably, after definitely < 100 lines of output, when in OC!). This is - of course - rather frustrating, because my system is still (I believe) _just_ in support for security updates: the ROM update that causes this cock-up is from middle of this year, for example.
Why do I need to downgrade? Weird story. No one else seems to be reporting it, but on 429.0.0.0.0 on that MBP102, OC debug logging hangs. It appears to hang in the firmware console output, at the point when a line is printed at the bottom of the screen, you get two copies of the last line, then it hangs (which to me looks like it's hanging during the firmware's scrolling and printing code). It can be on any log line, so the more lines you log, the more likely it is to happen (which looks a bit like it must be some sort of race condition). Even more weirdly, once it's happened on a given line, it tends to repeat happening in that line, even after a reboot, but will eventually switch to another line (or even no line before OC stops early console logging, in which case you can then actually boot!). As long as only OC early log is going to console (which it always does, in DEBUG build), and not the rest of the OC debug log (i.e. as long as Target BIT1 is 0), then the system boots more often than it hangs, but only just! This issue can also occur even without OC, but unfortunately something about the OC setup makes it much more likely to occur. I know, wtf, right?
EDIT: It has been suggested to me that if I can make it replicable without OC (i.e. in purely supported code, or at best in a very simple, non-controversial UEFI app), then it may be possible to report it to Apple and get it fixed - but so far, I can't (I can maybe have a program which might show it, one it 10 runs, after several thousand lines of output, when not in OC!! Or repeatably, after definitely < 100 lines of output, when in OC!). This is - of course - rather frustrating, because my system is still (I believe) _just_ in support for security updates: the ROM update that causes this cock-up is from middle of this year, for example.
Last edited:
Looking at the darwin-xnu code, it seems a
ResetNVRam=1_OR_WHATEVER_NONZERO boot argument can also be used instead of setting this as an NVRAM Variable. Interestingly, there is an additional option ... ObliterateNVRam=1_OR_WHATEVER_NONZERO.ResetNVRam appears to flush a "systemDict" if it is not NULL and then flushes a "commonDict" while ObliterateNVRam appears to create a new "systemDict" store altogether if it is not NULL. If "systemDict" is NULL, it does the same on "commonDict", which is skipped otherwise. The new stores created are sized to match the allowed max size of the current store.Such multiple stores didn't sound like something a cMP would support so I checked and found that the
ObliterateNVRam option was only added to the kernel sometime in 2020. The kernel code is current up to last year, 2021The good news is that there is a comment that running it on some unknown unit identified by a code basically bricks that unit and they are first checking whether the NVRAM can be obliterated before running this.
The bad news is that the kernel code is only current as of 2021 and the mystery "savior" unit, Trashcan perhaps, may have since been dropped and the kernel updated, or is due to be updated, to assume everything it is running on has NVRAM that can be obliterated. You run an update one day and your NVRAM gets obliterated ... literally.
Caveat Emptor to those running the latest and greatest on their legacy units!
Best thing to do is to get a sacrificial MATT Card and always run with this in place in such cases.
I wonder whether OpenCore can intercept and nullify attempts to set this though.
Last edited:
AFAIK is 2019 iMac, not late-2013 Mac Pro, and I think that only 2020 and later Macs with CHRP NVRAM* can obliterate the VSS stores.
Btw, xnu-8792.41.9 was released earlier today - now we have the XNU sources, and everything else open source, from Ventura.
* Yes, the world goes around and were back to Common Hardware Reference Platform again.
Could be. Would be good if so as means Ventura would stay safe.
Speculating that "systemDict" is VSS1 and that "commonDict" is VSS2 ... or equivalents.
ResetNVRam empties both while ObliterateNVRam creates a new VSS1 or a new VSS2 if VSS1 is already empty. Seems to keep the old VSS2 if a new VSS1 was created.
Last edited:
From a quick look, the new kernel has tweaked this area.
ResetNVRam previously had priority over ObliterateNVRam if both are set. It is now the other way round.
PS: I was wrong about the check whether the NVRAM can be obliterated. It is not a blanket check that happens all the time but only when one specific variable is present:
ResetNVRam previously had priority over ObliterateNVRam if both are set. It is now the other way round.
PS: I was wrong about the check whether the NVRAM can be obliterated. It is not a blanket check that happens all the time but only when one specific variable is present:
policy-nonce-digests. In such cases, it would not obliterate the NVRAM due to issues with the unknown item. The unknown item may not be a Mac unit but some bug/limitation (most likely).
Last edited: