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

[TrumanLA]

I have a real POMONA (MODEL-520 from Digikey), a fake POMONA MODEL-520 and that black one.
The problem's not the clip, but the high drain of the components of the board and the way Apple wired the circuit.
I even injected 3V3 on VDD to overcome the drain.

I agree (emphatically) that those black clips SUCK (worthless) ...

I'd also wondered if reprogrammers could work without removal using:
• Medusa -- (many L-13 & Mid-15 A1398 Retinas have to be in sleep mode for the Medusa 2 to work)
- or -
• DS-809SE -- (I believe it injects both 3.3v and other voltage-options as systems-require.)

But, if he already tried injecting voltage and it still doesn't work ?
I guess there're just too many ways for voltage to be consumed by other components to work without removal.

(Unless there's been some new info ... if you guys think the medusa2 might work, I'll give it a shot)

 

[tsialex]

I agree (emphatically) that those black clips SUCK (worthless) ...

I'd also wondered if reprogrammers could work without removal using:
• Medusa -- (many L-13 & Mid-15 A1398 Retinas have to be in sleep mode for the Medusa 2 to work)
- or -
• DS-809SE -- (I believe it injects both 3.3v and other voltage-options as systems-require.)

But, if he already tried injecting voltage and it still doesn't work ?
I guess there're just too many ways for voltage to be consumed by other components to work without removal.

(Unless there's been some new info ... if you guys think the medusa2 might work, I'll give it a shot)

Why spent almost $400 on a Medusa + adapter?

For bricks, you can read the BootROM from the SPI flash memory the moment you desolder it from the backplane and for working Mac Pros you already should have made the backup dump by now, no?

You have to replace the SPI flash memory with a brand new one anyway, since by now even the last mid-2012 ever made already have 8+ years of SPI flash usage and will die soon.

Even if you have to do this for a living supporting a lab/production company or something else, you can always use the dirty tricks like once in a hot moon do a hot-swapping with a MATT card, if you just need to get it going for sometime before replacing the SPI.

Since you have to replace the SPI flash memory, it's useless to have a Medusa - even for a lab/production company.

Btw, the corrupted BootROM image is only useful to help a firmware engineer reconstruct the BootROM. You won't dump a brick, flash it to a new SPI and install it back - continues to be a brick, but now with a new SPI flash memory.

 

[lancillotto]

Hi Tsialex, sorry to ask, I think I have found most of the answers in the thread, only a last confirmation ..
I have a used 4.1>5.1 macpro working great with latest macOS and OC, I want to be safe because I have no idea how much was used in the past. For now I need basically to dump my BootROM from a safe OS (mojave or high sierra) and wait for the worst? In that moment I will need a BootROM reconstruction and a matt card?
Thank you.

 

[tsialex]

Hi Tsialex, sorry to ask, I think I have found most of the answers in the thread, only a last confirmation ..
I have a used 4.1>5.1 macpro working great with latest macOS and OC, I want to be safe because I have no idea how much was used in the past. For now I need basically to dump my BootROM from a safe OS (mojave or high sierra) and wait for the worst? In that moment I will need a BootROM reconstruction and a matt card?
Thank you.

Some people only act when forced, while others act preventively.

This one is a very good example that you know that will fail since it's a SPI flash memory that have over 11 years of usage and now you are using modern versions of macOS/OC forcing it to work on overdrive. Your Mac Pro SPI flash memory can die tomorrow or one year from now, you just don't know the exact date, but surely it will fail.

Personally, I had an extremely bad experience with my first brick, my main Mac Pro bricked exactly in the week that I had a major work deadline, my work provided MBP had a dead battery the week before and I had to move to a barely running MP3,1 with just 12GB of RAM. I don't even like to remember the chaos of that week…

Anyway, a cross-flashed early-2009 is not a fully MP5,1, several components inside the BootROM image weren't updated with the cross-flashing process and some, like the NVRAM volume, are extremely prone to corruption from garbage collection failure - that's why you see so much early-2009 bricks here on MR.

The best course of action is to correct this issue once and for all with a clean-up/upgrade/BootROM reconstruction now to eliminate the risk of corruption from the cross-flashing/failed GC and then you buy a MATT card when you can. If downtime is not a problem for you, when you are forced to.

Even with a reconstructed BootROM you still have the risk of SPI flash memory failure, it's a 11+ years one probably on it's sunset, so you will need to replace the SPI flash - with a MATT card or replacing U8700 on the backplane.

 

[lancillotto]

Personally, I had an extremely bad experience with my first brick, my main Mac Pro bricked exactly in the week that I had a major work deadline, my work provided MBP had a dead battery the week before and I had to move to a barely running MP3,1 with just 12GB of RAM. I don't even like to remember the chaos of that week…

I more than agree, I will act asap and buy a Matt Card. With regard to BootROM reconstruction, it is something I would be able to do by following the instructions? I am not a firmware expert at all..
Thank you

 

[tsialex]

I more than agree, I will act asap and buy a Matt Card. With regard to BootROM reconstruction, it is something I would be able to do by following the instructions? I am not a firmware expert at all..
Thank you

Just cleaning the BootROM is a simple enough process that probably most developers can do, but the really complex procedures are the migration from a cross-flashed hybrid BootROM image to a real MP5,1 one and the upgrade of the whole image to the last ever issued release - this is outside of the capabilities of non firmware engineers without Mac Pro experience.

I've sent you a PM.

 

[trifero]

Another succesfully reconstructed ROM from @tsialex . One of those problems able 4.1>5,1.

Thank you so much.

 

[reinrag1a]

Sigh.. I hate to bother you @tsialex, but I can tell that I'm another user in need of a reconstruction. (My NVRAM is already not garbage collecting). My dump after doing the 5 PRAM resets is.. well.. its obviously not good based on my reading this thread.

I do have very old RomTool dumps that seem OK.. but they are of the .0084.B00 and .0089.B00 vintage.. it has
62236 bytes in the "Padding" at the end of the VSS. (not sure why these versions calls it padding and later versions call it freespace)

My saved 138.000.000.000 looks like it has too little free space left.. lots of invalid entries and only 21112 bytes. I suppose I could try to flash this in High Sierra and then do a PRAM reset and see if it will gc.. and then try to upgrade it to 144....

 

[tsialex]

Sigh.. I hate to bother you @tsialex, but I can tell that I'm another user in need of a reconstruction. (My NVRAM is already not garbage collecting). My dump after doing the 5 PRAM resets is.. well.. its obviously not good based on my reading this thread.

I do have very old RomTool dumps that seem OK.. but they are of the .0084.B00 and .0089.B00 vintage.. it has
62236 bytes in the "Padding" at the end of the VSS. (not sure why these versions calls it padding and later versions call it freespace)

My saved 138.000.000.000 looks like it has too little free space left.. lots of invalid entries and only 21112 bytes. I suppose I could try to flash this in High Sierra and then do a PRAM reset and see if it will gc.. and then try to upgrade it to 144....

There are no difference between what UEFITool finds as padding between EFI releases, since padding is usually a representation of what UEFITool didn't understood at all, like a variable that got its value truncated or some other mess like it. If you have a large padding area, it's usually a sure sign that the circular log became corrupt.

I've sent you the instructions by PM, get everything as instructed and I'll take a look.

 

[zozomester]

There are no difference between what UEFITool finds as padding between EFI releases, since padding is usually a representation of what UEFITool didn't understood at all, like a variable that got its value truncated or some other mess like it. If you have a large padding area, it's usually a sure sign that the circular log became corrupt.

I've sent you the instructions by PM, get everything as instructed and I'll take a look.

Hi tsialex,
Can you help clean up my Bootrom?
I don't think it's very good ......
Thank you!

 

[tsialex]

Hi tsialex,
Can you help clean up my Bootrom?
I don't think it's very good ......
Thank you!

PM sent, get everything exactly as instructed and I'll take a look.

 

[Eschers]

Hi tsialex,
Can you help clean up my Bootrom?
I don't think it's very good ......
Thank you!

How did you check this?

 

[zozomester]

How did you check this?

Macschrauber's CMP Rom Dump:

OpenCore on the Mac Pro

I noticed some folks are installing OpenCore on their MacBook Pro's, I have a 15" 2008 4,1 MacBook Pro and want to see if i can do a native install of Mojave on it, rather than the patched install of Mojave currently installed. What is the eariest model MBP that OpenCore will work with?

forums.macrumors.com

 

[tsialex]

Binary static analysis is frequently useful, BUT you have to know a lot of things to judge the results.

First thing, dual CPU trays and single CPU trays have very different thresholds that you need to take account when analyzing.

Also, dumping booted from OC is not reliable and I don't accept any dumps from it. For example, @zozomester dump is showing a gigantic padding area. Padding areas inside the NVRAM VSS stores can be a circular log being corrupt or errors when dumping booted with OC. I'll only know for sure if it's really a NVRAM corruption with a dump booted from a fully supported macOS install (10.9 or 10.11.6 to 10.14.6 - 10.10 SIP is incompatible with flashrom or ROMTool) without OC.

This is a lot more complicated than what it seems and the @Macschrauber tool didn't detected it, nor mine. Opening the dump with UEFITool showed it instantly. So, even a dump that shows healthy with binary static analysis can be a brick in rapid progress.

 

[Eschers]

Macschrauber's CMP Rom Dump:

OpenCore on the Mac Pro

I noticed some folks are installing OpenCore on their MacBook Pro's, I have a 15" 2008 4,1 MacBook Pro and want to see if i can do a native install of Mojave on it, rather than the patched install of Mojave currently installed. What is the eariest model MBP that OpenCore will work with?

forums.macrumors.com

Thank you very much!

Binary static analysis is frequently useful, BUT you have to know a lot of things to judge the results.

First thing, dual CPU trays and single CPU trays have very different thresholds that you need to take account when analyzing.

Also, dumping booted from OC is not reliable and I don't accept any dumps from it. For example, @zozomester dump is showing a gigantic padding area. Padding areas inside the VSS store can be a circular log being corrupt or errors dumping booted with OC. I'll only know for sure if it's really a NVRAM corruption with a dump booted from a fully supported macOS install (10.11.6 to 10.14.6) without OC.

This is a lot more complicated than what it seems and the @Macschrauber tool didn't detected it, nor mine. Opening the dump on UEFITool showed it instantly. So, even a dump that shows healthy with static analysis can be just a brick in rapidly progress.

I flash my reconstructed Bootrom every few months just to be sure. Usually every new opencore release I remove it completely, flash the bootrom (by @tsialex ) and then proceed with new opencore config!

 

[Dewdman42]

Can I ask, what is involved in configuring and installing a MATT card, into 2010 5,1? I see they are under $100, is that true? I already have never booted image from @tsialex.

 

[tsialex]

Can I ask, what is involved in configuring and installing a MATT card, into 2010 5,1? I see they are under $100, is that true? I already have never booted image from @tsialex.

No configuration. Just install it and flash the never booted image exactly as you do.

 

[Dewdman42]

the installation is plugging in something to something...I haven't been able to find more details about that. But once I plug it in, how does it boot up prior to being flashed (in order to flash it)?

 

[tsialex]

the installation is plugging in something to something...I haven't been able to find more details about that. But once I plug it in, how does it boot up prior to being flashed (in order to flash it)?

I've written a lot about MATT cards, please use the search with MATT and my username. You will find more than you will ever want to know, also pictures of it installed.

 

[Macschrauber]

Binary static analysis is frequently useful, BUT you have to know a lot of things to judge the results.

This is a lot more complicated than what it seems and the @Macschrauber tool didn't detected it, nor mine. Opening the dump on UEFITool showed it instantly. So, even a dump that shows healthy with binary static analysis can be a brick in rapid progress.

absolutely, as I say, the main purpose of my tool is to backup the firmware.

(and to flash the firmware with some more checks like verifying bitwise after flashing. DosDude's tool is an universal flasher for all kind of Macs. My Tool is MP5,1 only.)

Plus some _basic_ checks for the most common nvram variables and windows certificates, free space, for empty 2nd Stream and some corrupted headers. The most obvious firmware faults I have experienced.

My experience is from about 100+ Mac Pros I had in my hands plus a whole bunch of dumps I got from the fellows of our german Mac forum.

I learned the basic things from @tsialex, he is the mastermind behind all of the firmware knowledge. Also I investigated for my own after the master shared his wisdom with me. I spent 100s of hours making binwalk signatures and reading Alex' Firmware threads.

So I am more the tech guy what uses the information to fix and repair Mac Pros with firmware problems. Plus I made tools for my own needs and shared it. Just for you guys to keep on backing up the firmware and also to turn on a big red light if there are obvious problems in it.

 

[zozomester]

Binary static analysis is frequently useful, BUT you have to know a lot of things to judge the results.

First thing, dual CPU trays and single CPU trays have very different thresholds that you need to take account when analyzing.

Also, dumping booted from OC is not reliable and I don't accept any dumps from it. For example, @zozomester dump is showing a gigantic padding area. Padding areas inside the NVRAM VSS stores can be a circular log being corrupt or errors when dumping booted with OC. I'll only know for sure if it's really a NVRAM corruption with a dump booted from a fully supported macOS install (10.9 or 10.11.6 to 10.14.6 - 10.10 SIP is incompatible with flashrom or ROMTool) without OC.

This is a lot more complicated than what it seems and the @Macschrauber tool didn't detected it, nor mine. Opening the dump with UEFITool showed it instantly. So, even a dump that shows healthy with binary static analysis can be a brick in rapid progress.

I sent the files in a private message. Thanks in advance!

 

[trifero]

Another succesfully reconstructed ROM from @tsialex . This time for a Mac Pro 5,1 2010, that still was in an ancient boot rom version, as he told me. Now is in 144.0.0.0 directly.

 

[tsialex]

Another succesfully reconstructed ROM from @tsialex . This time for a Mac Pro 5,1 2010, that still was in an ancient boot rom version, as he told me. Now is in 144.0.0.0 directly.

One big advantage of a BootROM reconstruction is that you can reconstruct 144.0.0.0.0 (or any other EFI release, don't matter) from any EFI version dumped - you can start from a MP51.007F.B03 dump and reconstruct 144.0.0.0.0.

You can also upgrade MP4,1 dumps to 144.0.0.0.0, after adjusting the x86 Reset Vector to the correct address for a MP51 firmware.

The previous owner was probably a Snow Leopard holdout guy, several NVRAM entries/variables from that era.

 

[zzzippp]

the installation is plugging in something to something...I haven't been able to find more details about that. But once I plug it in, how does it boot up prior to being flashed (in order to flash it)?

I'd like to point out that they can flash a BootROM image to the MATT Card before shipping it to you. From the MATT Card webpage:

A Matt card does not solve any NVMe/sleep issues. But you can read and patch your ROM and send us the modified dump immediately before or immediately after ordering a Matt card and we can write your dump onto your Matt card.

EDIT: As @tsialex pointed out in the next message, if you dump your active BootROM, it can contain iCloud credentials, Wi-Fi network credentials, and other sensitive data which anyone with the BootROM dump file can view. Even if you send a reconstructed, clean, and never-booted BootROM image, it will still contain hardwareIDs for your Mac Pro, so keep that in mind if you decide to send your BootROM image to cmizapper to flash to a MATT Card that you're ordering.

 

[tsialex]

I'd like to point out that they can flash your (preferably reconstructed never-booted) BootROM image to the MATT Card before shipping it to you. From the MATT Card webpage:



Then you should in theory just be able to plug in the card to your MP 5,1's motherboard and everything will work as normal.

Your BootROM dump contains sensitive data like iCloud email/credentials and all credentials for Wi-Fi networks that you connect with your iPhone/iPad/MacBook that are synced via iCloud, besides all the hardwareIDs for your Mac Pro and sometimes the keys/authorization for apps that you paid.

While I'm not saying in anyway that cmizapper would do something with your data, I strongly recommend that you do this step yourself.