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

[tsialex]

This was completely unexpected, Monterey 12.6.4 beta4 (21G521) have a MacPro6,1 EFI firmware upgrade, from 470.0.0.0 to 474.0.0.0.0:

Hardware Overview:

  Model Name:	Mac Pro
  Model Identifier:	MacPro6,1
  Processor Name:	6-Core Intel Xeon E5
  Processor Speed:	3,5 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:	16 GB
  System Firmware Version:	474.0.0.0.0
  OS Loader Version:	540.120.3~22
  SMC Version (system):	2.20f18
  Panel Illumination Version:	1.4a6

No news of what this EFI firmware upgrade is about at this moment. There was no developer or any public beta testing for any of the versions between 470.0.0.0.0 and 474.0.0.0.0, unusual, but not unheard when the EFI firmware upgrade was issued for security-related reasons.

Side note, it's one more of the interminable software upgrades, with multiple reboots and taking around 20 to 30 minutes - several minutes with the screen completely off when you think that something went wrong. Just wait and fight the urge of shutting down the Mac Pro.

 

[behart]

Thanks. There are quite a few components on those boards. I will begin sourcing a new machine or backplane. I like the idea of having a second machine that is functional to check all the parts. I have upgraded the ram, processors, and video card. I'll relate my (mis)adventures here...

Well, I have my machine working again. I found a local guy who does a great job recycling Apple stuff. I picked up a used backplane and while I was there, grabbed a second optical drive for fun. I excitedly swapped the board that evening...

I turned on the machine and after a few seconds got the tone and thought I was home free. That boot was about 10% of the Mojave bar and then stopped. The machine now would not boot, with the same behavior I had with the original backplane. Bummer. I unplugged everything and tried again in the morning. No luck. Unplugged and waited a day and a half, same thing.

I decided that it must not be backplane related. I decided to take a close look at the cpu tray, since that was the only common thing at that point. If I had hosed two backplanes, I wasn't about to wreck a third without proving my tray was OK. I haven't had this machine long, nor used it much yet, and the inside of this one was really quite clean so I had not super scrutinized each board. While examining the tray, I noticed some slight corrosion and a thin layer of dust that had seen a light layer of condensation at some point on the machine front side of the board. There is a large chip on that edge that is mostly under the cpu cooler. It looked like there was enough crud that some of the pins could be shorted. Given the rest of the board was so clean, I had missed this earlier. I had a can of compressed IPA and cleaned and brushed the front of the tray well, focusing on the chip's pins. I blew off the remaining IPA with air.

Boom, back in business. Booted right away with the second mainboard. I tested a few things, dumped that ROM just in case, and then put the original one back in. This one booted right away as well. This board is the one I put a new chip on with MP51.fd burned using a programmer. So I used ROMTool to burn the image of the chip I removed to the new chip. Now I have my serial number back and can use iCloud, etc. I put in my OpenCore Monterrey disk and all is well. It finished the updates it was doing when the machine died, which worried me for a second before I remembered that.

So, observations. Clean boards really well. Use spray isopropyl alcohol and compressed air to really get between pins and under chips. Perhaps the most important thing I have now noticed is exactly how the firmware status lights work. When I had a non-working state, all the lights were on at the same time immediately after power up. Now that the system is working, they work their way to the on state. So just because EFI Done and GPU OK are lit, does not necessarily mean that. Now, they come on one by one after the tone. Hopefully, this helps someone else who sees all the lights come on at once instead of as each check is passed like they are supposed to.

-Ben

 

[tsialex]

Well, I have my machine working again. I found a local guy who does a great job recycling Apple stuff. I picked up a used backplane and while I was there, grabbed a second optical drive for fun. I excitedly swapped the board that evening...

I turned on the machine and after a few seconds got the tone and thought I was home free. That boot was about 10% of the Mojave bar and then stopped. The machine now would not boot, with the same behavior I had with the original backplane. Bummer. I unplugged everything and tried again in the morning. No luck. Unplugged and waited a day and a half, same thing.

I decided that it must not be backplane related. I decided to take a close look at the cpu tray, since that was the only common thing at that point. If I had hosed two backplanes, I wasn't about to wreck a third without proving my tray was OK. I haven't had this machine long, nor used it much yet, and the inside of this one was really quite clean so I had not super scrutinized each board. While examining the tray, I noticed some slight corrosion and a thin layer of dust that had seen a light layer of condensation at some point on the machine front side of the board. There is a large chip on that edge that is mostly under the cpu cooler. It looked like there was enough crud that some of the pins could be shorted. Given the rest of the board was so clean, I had missed this earlier. I had a can of compressed IPA and cleaned and brushed the front of the tray well, focusing on the chip's pins. I blew off the remaining IPA with air.

Boom, back in business. Booted right away with the second mainboard. I tested a few things, dumped that ROM just in case, and then put the original one back in. This one booted right away as well. This board is the one I put a new chip on with MP51.fd burned using a programmer. So I used ROMTool to burn the image of the chip I removed to the new chip. Now I have my serial number back and can use iCloud, etc. I put in my OpenCore Monterrey disk and all is well. It finished the updates it was doing when the machine died, which worried me for a second before I remembered that.

So, observations. Clean boards really well. Use spray isopropyl alcohol and compressed air to really get between pins and under chips. Perhaps the most important thing I have now noticed is exactly how the firmware status lights work. When I had a non-working state, all the lights were on at the same time immediately after power up. Now that the system is working, they work their way to the on state. So just because EFI Done and GPU OK are lit, does not necessarily mean that. Now, they come on one by one after the tone. Hopefully, this helps someone else who sees all the lights come on at once instead of as each check is passed like they are supposed to.

-Ben

I've also revived several backplanes/CPU trays after meticulous clean up. The oily residue from the thermal pads over time accumulate dust and sometimes the resulting grime is conductive enough to make havoc.

Someday I'll have an ultrasonic cleaner that is big enough for a Mac Pro backplane, the heated 3L one that I own currently is incredible for cleaning small boards and make old boards that no one would give a cent practically brand new.

 

[yota92]

Hey @tsialex, thanks for all your work! I'm also interested in a reconstructed BootROM. I recently added EnableGop to mine, and everything is working fine, but I'd like to be a bit more proactive around recovery now that I've started tinkering with it.

 

[jfree]

Hello all ! I'm a new member to MacRumors but have been researching the threads here and customizing / maintaining my cMP for years now thanks to this site : )

I am currently interested in learning more about bootrom flashing + reconstruction. It is a confusing topic for me but I have just completed a bootrom dump, and the free space number doesn't seem so healthy (per the great info from @tsialex - thank you for all your work in this space)!

After a recent hardware issue I just replaced my logic board, and so re-flashed my 4.1 -> 5.1. Reading up on the bootrom issue I decided to make flashing a part of my usual maintenance, however the numbers after this first dump are already looking problematic.

I'd be very interested in any advice or support in completing a reconstruction, so I can start flashing and keeping the bootrom healthy with this just-replaced logic board : )

 

[tsialex]

Hello all ! I'm a new member to MacRumors but have been researching the threads here and customizing / maintaining my cMP for years now thanks to this site : )

I am currently interested in learning more about bootrom flashing + reconstruction. It is a confusing topic for me but I have just completed a bootrom dump, and the free space number doesn't seem so healthy (per the great info from @tsialex - thank you for all your work in this space)!

After a recent hardware issue I just replaced my logic board, and so re-flashed my 4.1 -> 5.1. Reading up on the bootrom issue I decided to make flashing a part of my usual maintenance, however the numbers after this first dump are already looking problematic.

I'd be very interested in any advice or support in completing a reconstruction, so I can start flashing and keeping the bootrom healthy with this just-replaced logic board : )

The best dump you can get is right after a deep NVRAM reset. You will need to install Mavericks for that - so you won't have to set SIP disabled via Recovery and save several logs inside the NVRAM, if you use ElCapitan to Mojave.

Unfortunately, this is not much helpful for a cross-flashed early-2009 and only a BootROM reconstruction service can repair the mess that the cross-flashing process makes.

 

[jfree]

Oh- here's a screenshot of my free space!

 

[tsialex]

Oh- here's a screenshot of my free space!

Did you have Windows UEFI installed? This is very similar to the way UEFITool misidentify the failed circular log from Windows SecureBoot.

Btw, the current version that is fool proof with MacPro5,1 firmware is UEFITool NE A63, you should avoid earlier and newer versions.

Release UEFITool NE/UEFIExtract/UEFIFind A63 · LongSoft/UEFITool

New features: it is now possible to paste GUIDs in raw EDK2 format into Search window as is without manual re-formatting, thanks to @mikebeaton support for HiDPI displays, thanks to @NikolajSchlej...

github.com

 

[jfree]

The best dump you can get is right after a deep NVRAM reset. You will need to install Mavericks for that - so you won't have to set SIP disabled via Recovery and save several logs inside the NVRAM, if you use ElCapitan to Mojave.

Unfortunately, this is not much helpful for a cross-flashed early-2009 and only a BootROM reconstruction service can repair the mess that the cross-flashing process makes.

Thank you for the quick response tsialex- It's great to be in touch having been helped by your posts : )

I am able to go back to mavericks and dump from that OS, but if you advise a reconstruction service I am interested!

 

[jfree]

Did you have Windows UEFI installed? This is very similar to the way UEFITool misidentify the failed circular log from Windows SecureBoot.

Btw, the current version that is fool proof with MacPro5,1 firmware is UEFITool NE A63.

I attempted to use the current UEFITool for mac but it wouldn't load for me for some reason-- so I went with an older version. Will download and try to run a more recent one now (the version I used was NE A50)

 

[tsialex]

I attempted to use the current UEFITool for mac but it wouldn't load for me for some reason-- so I went with an older version. Will download and try to run a more recent one now (the version I used was NE A50)

UEFITool NE A64 is buggier as hell when using the search, while A65 only works with Monterey and newer macOS releases.

So, use UEFITool NE A63:

Release UEFITool NE/UEFIExtract/UEFIFind A63 · LongSoft/UEFITool

New features: it is now possible to paste GUIDs in raw EDK2 format into Search window as is without manual re-formatting, thanks to @mikebeaton support for HiDPI displays, thanks to @NikolajSchlej...

github.com

 

[jfree]

Ok so

UEFITool NE A64 is buggier as hell when using the search, while A65 only works with Monterey and newer macOS releases.

So, use UEFITool NE A63:

Release UEFITool NE/UEFIExtract/UEFIFind A63 · LongSoft/UEFITool

New features: it is now possible to paste GUIDs in raw EDK2 format into Search window as is without manual re-formatting, thanks to @mikebeaton support for HiDPI displays, thanks to @NikolajSchlej...

github.com

Ok just did that!

 

[tsialex]

Ok so

Ok just did that!

If this is the best you can get after a NVRAM reset, your garbage collection is not working. I've sent you a PM about the BootROM reconstruction service.

 

[jfree]

Updated numbers after a deep NVRAM reset -- per your advice elsewhere @tsialex : )

Are these more viable, or still in the range of needing reconstruction? Based on what you've posted, I see they should be more like 35,000

 

[tsialex]

Updated numbers after a deep NVRAM reset -- per your advice elsewhere @tsialex : )

Are these more viable, or still in the range of needing reconstruction? Based on what you've posted, I see they should be more like 35,000

MacPro early-2009 BootROM is too different from mid-2010s, not only with the EFI itself but also the NVRAM volume. The cross-flashing process is partial, while the EFI is fully replaced with the mid-2010 one and the BootBlock hacked with the correct X86 Reset Vector, the MacPro4,1 NVRAM volume is not touched.

The NVRAM volume design is a lot different from a MacPro5,1:

Store:	early-2009	mid-2010/mid-2012
VSS	just one	primary and secondary
FWB	fully working, save garbage collection logs	just a placeholder, not working
Fsys	yes	yes
Gaid	yes	yes

MacPro5,1 EFI expects the MacPro5,1 NVRAM layout and then finds the MacPro4,1 one that is slightly incompatible, this makes the NVRAM volume corrupt overtime and then ultimately a brick. This is the main reason of so much early-2009 bricks.

 

[jfree]

MacPro early-2009 BootROM is too different from mid-2010s, not only with the EFI itself but also the NVRAM volume. The cross-flashing process is partial, while the EFI is fully replaced with the mid-2010 one and the BootBlock hacked with the correct X86 Reset Vector, the MacPro4,1 NVRAM volume is not touched.

The NVRAM volume design is a lot different from a MacPro5,1:

Store:	early-2009	mid-2010/mid-2012
VSS	just one	primary and secondary
FWB	fully working, save garbage collection logs	just a placeholder, not working
Fsys	yes	yes
Gaid	yes	yes

MacPro5,1 EFI expects the MacPro5,1 NVRAM layout and then finds the MacPro4,1 one that is slightly incompatible, this makes the NVRAM volume corrupt overtime and then ultimately a brick. This is the main reason of so much early-2009 bricks.

Ok I see! So would that make the bootrom reconstruction less effective of a solution? And for the long term solution just switching to an actual 5.1 (2010-2012) machine sounds like a smart move

 

[tsialex]

Ok I see! So would that make the bootrom reconstruction less effective of a solution?

Seems you didn't understood, the BootROM reconstruction process is exactly to repair the mess and the final result is identical of the MacPro mid-2012 release 0x0d made in late 2013 right before the production moved to MacPro6,1, except that the original System Serial Number and other hardware identifications (HWC/SON/MLB/BD) are kept as saved from the factory. Everything else is exactly identical to a mid-2012 0x0d top to bottom.

So, simplified, the end result - the never booted BootROM image, is functionally a mid-2012, but with an early-2009 SSN.

Let's not forget that while the BootROM image can be made functionally identical of a mid-2012, the SMC H8S microcontroller firmware is not upgradeable, the SMC firmware of an early-2009 will be 1.39f5 forever. The SMC firmware 1.39f11 of mid-2010s/mid-2012s was never leaked from Apple.

And for the long term solution just switching to an actual 5.1 (2010-2012) machine sounds like a smart move

If you can find a lightly used dual CPU mid-2012 on the cheap, it's the way to go just for being 3 years newer, but since mid-2012s dual CPU Mac Pros sold so small numbers compared to the early-2009s, it's usually not cost effective. This obviously depends on where you are located.

I can get at least 3 early-2009s model 20H for the price of one pristine mid-2012 F4MH locally.

 

[jfree]

Seems you didn't understood, the BootROM reconstruction process is exactly to repair the mess and the final result is identical of the MacPro mid-2012 release 0x0d made in late 2013 right before the production moved to MacPro6,1, except that the original System Serial Number and other hardware identifications (HWC/SON/MLB/BD) are kept as saved from the factory. Everything else is exactly identical to a mid-2012 0x0d top to bottom.

So, simplified, the end result - the never booted BootROM image, is functionally a mid-2012, but with an early-2009 SSN.

Let's not forget that while the BootROM image can be made functionally identical of a mid-2012, the SMC H8S microcontroller firmware is not upgradeable, the SMC firmware of an early-2009 will be 1.39f5 forever. The SMC firmware 1.39f11 of mid-2010s/mid-2012s was never leaked from Apple.



If you can find a lightly used dual CPU mid-2012 on the cheap, it's the way to go just for being 3 years newer, but since mid-2012s dual CPU Mac Pros sold so small numbers compared to the early-2009s, it's not cost effective.

I can get at least 3 early-2009s model 20H for the price of one pristine mid-2012 F4MH locally. This obviously depends on where you are located.

Seems you didn't understood, the BootROM reconstruction process is exactly to repair the mess and the final result is identical of the MacPro mid-2012 release 0x0d made in late 2013 right before the production moved to MacPro6,1, except that the original System Serial Number and other hardware identifications (HWC/SON/MLB/BD) are kept as saved from the factory. Everything else is exactly identical to a mid-2012 0x0d top to bottom.

So, simplified, the end result - the never booted BootROM image, is functionally a mid-2012, but with an early-2009 SSN.

Let's not forget that while the BootROM image can be made functionally identical of a mid-2012, the SMC H8S microcontroller firmware is not upgradeable, the SMC firmware of an early-2009 will be 1.39f5 forever. The SMC firmware 1.39f11 of mid-2010s/mid-2012s was never leaked from Apple.



If you can find a lightly used dual CPU mid-2012 on the cheap, it's the way to go just for being 3 years newer, but since mid-2012s dual CPU Mac Pros sold so small numbers compared to the early-2009s, it's not cost effective.

I can get at least 3 early-2009s model 20H for the price of one pristine mid-2012 F4MH locally. This obviously depends on where you are located.

haha yes there’s a lot I don’t catch! Thanks for the simplified version. Ok I am going to look into a potential upgrade to a 2012 machine, or else will be doing the bootrom reconstruction with you for sure. @tsialex thank you for taking time to share knowledge with me!

 

[JedNZ]

Slightly off-topic/brick revival process:

Look what arrived earlier this week:

View attachment 1834739

The CPU tray from the pristine mid-2012 brick, that I bought as a case/dead from a media company, already completely cleaned (wasn't filthy from the get go, but when I refurb something I like to start with everything completely cleaned) and ready for the thermal paste application. The CPU tray now seems brand new, I'm very pleased with that.

View attachment 1834742

Applied GD460 thermal paste, since this is a more solid formulation than the usual thermal paste I prefer to use a little more and partially spread it myself:

View attachment 1834765

Re-installed the original push pins for the northbridge heatsink until the correct size screws and lock nuts arrive. Borrowed 4 x Micron 8GB RDIMMs from my early-2009 dual CPU tray - still looking for reasonably priced 2Rx4 16GB DIMMs.

Now I'm gonna test the hell out of the newly arrived X5690 and the previously dead backplane that I replaced the SPI flash memory with a brand new MXIC MX25L3206E.

View attachment 1834784

Btw, I took several photos of the SPI replacement process - I already posted from start to finish here back in September 2018 - but maybe I can do a one post resume will all the steps later.

@tsialex Any issues with the GD460 thermal paste you used with your CPU? I'm about to refresh the thermal grease on my three cMP 4,1>5,1 machines (including the Northbridge heatsink). In the past I used Arctic Silver 5, but I bought a few packs of GD460 a year ago so would like to use that, so long as no-one has had any issues with it.

 

[tsialex]

@tsialex Any issues with the GD460 thermal paste you used with your CPU? I'm about to refresh the thermal grease on my three cMP 4,1>5,1 machines (including the Northbridge heatsink). In the past I used Arctic Silver 5, but I bought a few packs of GD460 a year ago so would like to use that, so long as no-one has had any issues with it.

No problems, excellent cost-benefit thermal paste. I'm half way on a 100g bottle, after initially using a 20g bottle for tests.

Like any other thermal paste, use before expired.

 

[Oliveacaen]

@tsialex

I just bought a cross-flashed 4.1->5.1 early 2009 Mac Pro (CPUs upgraded / GPU (non Mac RX580 ) ..
Went through OCLP + Pre-OpenCore GOP without issue , now running Ventura .
I have Issue with the 2nd VSS Store (FF FF FF FF) .

Your service would be really much appreciated !

Can you please PM me regarding a BootROM reconstruction?

 

[RolfNoot]

Do a deep nvram reset (command option P R on start, 4x chimes). Didn’t you backup your nvram before flashing?

 

[Oliveacaen]

Do a deep nvram reset (command option P R on start, 4x chimes). Didn’t you backup your nvram before flashing?

Thanks !
nvram reset was done , nothing to do...still got this issue on VSS2 ,
I had a backup somewhere ... but as everything went fine ... well... I deleted it 🤦‍♂️

 

[tsialex]

@tsialex

I just bought a cross-flashed 4.1->5.1 early 2009 Mac Pro (CPUs upgraded / GPU (non Mac RX580 ) ..
Went through OCLP + Pre-OpenCore GOP without issue , now running Ventura .
I have Issue with the 2nd VSS Store (FF FF FF FF) .

Your service would be really much appreciated !

Can you please PM me regarding a BootROM reconstruction?

Sure, PM sent.

Thanks !
nvram reset was done , nothing to do...still got this issue on VSS2 ,
I had a backup somewhere ... but as everything went fine ... well... I deleted it 🤦‍♂️

If your NVRAM volume got to a point that a multiple NVRAM reset is failing to restore the secondary VSS store header, you have multiple issues, so, send me the dump as you have currently (no need to dump it again) and avoid powering up.

 

[Oliveacaen]

Sure, PM sent.



If your NVRAM volume got to a point that a multiple NVRAM reset are failing to restore the secondary VSS store header, you have multiple issues, so, send me the dump as you have currently (no need to dump it again) and avoid powering up.

Many thanks Alex , I will come back to you ASAP !