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

[Bmju]

NB It is ResetNVRam not ResetNVram

 

[Dayo]

NB It is ResetNVRam not ResetNVram

Indeed and case sensitive.
Amended the posts accordingly.

 

[Mattias_N]

Hi im new here i have two Mac Pro 2010 and i was thinking to reconstruct the boot rom if that is possible

i have save the the Boot Roms and i think they are ok

 

[tsialex]

Hi im new here i have two Mac Pro 2010 and i was thinking to reconstruct the boot rom if that is possible

i have save the the Boot Roms and i think they are ok

Sure. PM sent.

 

[Mattias_N]

ok

 

[trifero]

Hi im new here i have two Mac Pro 2010 and i was thinking to reconstruct the boot rom if that is possible

i have save the the Boot Roms and i think they are ok

Wise choice.

 

[Mattias_N]

Wise choice.

yes now my mac pro's running good

 

[William4673]

Hello all. The following is a report on my Boot Rom degradation during the past 5 months of reflashing history.
My reconstructed bottom was crafted by @tsialex and it has done miracles. It is faithful and reliable. Thank you sir. 👍

I originally came to him with a boot room that was completely trashed and at risk of bricking. I cannot even give a number on the "free space" within EFISYSTEMNVDATAFVGUID window on UEFI tool, as my second VSS store had vanished. See below.

My initial intent was to flash every 3 months, which I had seen as a reccomendation floating around in the community. I however didn't trust this and, after collecting my own data, decided to reflash every 30 days. I have a dual CPU model 5,1 Mac Pro with firmware 144.0.0.0.0. This data doesn't apply to single cpu models, as their recommended minimum NVRAM free space is different. 22000 is the minimum a dual model should go down to before symptoms are shown and you risk bricking. (Correct me if Im wrong anyone.)

______________________________________________________________________________________________

(YEAR IS 2022 FOR ALL DATES LISTED)

Original reflash after reconstruct: July 9th - > July 19th
Remaining Free Space on VSS Store 1 before reflash: 35408
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

2nd reflash : July 19th - > August 10th
Remaining Free Space on VSS Store 1 before reflash : 41827
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

3rd reflash : August 10th - > August 22nd
Remaining Free Space on VSS Store 1 before reflash : 42724
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

In between these two rom dumps I installed Monterey. Knowing Monterey hammers the NVRAM during install, I decided to do it early on in the cycle, so the rom would have enough free space to allow the process to go successfully and safely. I did this by following the guide in h9826790's post.​

​

4th reflash : August 22nd - > August 27th
Remaining Free Space on VSS Store 1 before reflash : 27074
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

I do not understand what caused the below datapoint, as I didnt install any new operating systems, update any software, or boot windows without Martin Lo's package (which protects from secure boot singing). It may be a simple matter of garbage collection failing. In any case, garbage collection wears out the NAND cells of the Boot Rom chip more rapidly than just clearing it with the Boot Rom tool. This, I need help to understand/remedy.​

5th reflash : August 27th - > September 24th
Remaining Free Space on VSS Store 1 before reflash : 19542
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

6th reflash : September 24th - > October 24th
Remaining Free Space on VSS Store 1 before reflash : 23522
VSS Store 1 Free Space cleaned to be a full 65448 after reflash.

END OF REPORT
______________________________________________________________________________________________

I am set to reflash on the 24th of November. Happy Turkey Day. 🦃

Here is my general use case for the machine, for your information and perspective. I triple boot OS'es.

I use Windows 10 regularly for university programs and such. My workflow includes coding, CAD work, and light occasional gaming.

I use macOS Mojave for music listening, schoolwork, and movie watching.

I am using macOS Monterey far more these days than I used to. I use universal control, modern macOS apps (e.i. Notability), Internet browsing, file management, document based schoolwork, and music listening.

I hope this post gives clarity and point of view for all interested in either owning a cMP, or currently using one. From MY specific degradation history, as well as the symptoms I have experienced when nearing my next reflash appointment: ( LONG boot chime times, never able to reach open core boot screen, Windows will fail to boot, inconsistent macOS boot prohibited "🚫" signs, general UI & OS sluggishness, unable to get the machine to even display to a monitor without a 4 chime NVRAM reset via keyboard shortcut ), I recommend flashing more often than not.

I highly recommend a tight schedule, at MAXIMUM 30 days between flashes, and care towards when you update. Also be aware of the symptoms of your cMP day to day.

If anyone has any corrections for this post please respond and I will fix it for the betterment of everyones knowledge. Hope this post comes of some use to you all. Stay safe.

-W

 

[Audiomangiraldo]

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

@tsialex today I changed the backplane but on the first start the machine started but with the fans spinning at full speed, I then reset the P-RAM and SMC and for the first time I heard the sound of chime. i read on an old post you wrote that it is a SMC version problem between back plane and CPU tray. how do i check and fix it?

 

[h9826790]

@tsialex today I changed the backplane but on the first start the machine started but with the fans spinning at full speed, I then reset the P-RAM and SMC and for the first time I heard the sound of chime. i read on an old post you wrote that it is a SMC version problem between back plane and CPU tray. how do i check and fix it?

 

[Matty_TypeR]

You need a 4.1 back plain ( no matter if flashed to 5.1 ) with a 4.1 CPU tray. SMC version is different on 4.1 back plain's to 5.1 back plains, as it is for 4.1 cpu trays and 5.1 cpu trays.

If you try and mix 4.1 and 5.1 fans will spin at full speed. thats goes for back plains and CPU trays. they both must match SMC version and you cant update the SMC version.

4.1 back plain must have a 4.1 cpu tray, 5.1 back plain must have a 5.1 cpu tray.

 

[Audiomangiraldo]

You need a 4.1 back plain ( no matter if flashed to 5.1 ) with a 4.1 CPU tray. SMC version is different on 4.1 back plain's to 5.1 back plains, as it is for 4.1 cpu trays and 5.1 cpu trays.

If you try and mix 4.1 and 5.1 fans will spin at full speed. thats goes for back plains and CPU trays. they both must match SMC version and you cant update the SMC version.

4.1 back plain must have a 4.1 cpu tray, 5.1 back plain must have a 5.1 cpu tray.

How i can verify if my CPU tray Is 4.1 ?

 

[Matty_TypeR]

View attachment 2111063

you check with looking as shown here. they should be the same, as shown.

 

[tsialex]

I highly recommend a tight schedule, at MAXIMUM 30 days between flashes, and care towards when you update. Also be aware of the symptoms of your cMP day to day.

Even if you have a hardware config that keeps getting below the safe threshold, you just need to re-flash immediately before installing a BigSur/Monterey Software Update, like the recent 12.6.1, or a clean macOS install. It's the major two things that can cause damage to your BootROM NVRAM volume when you have too little space available - you can enter boot loops or even brick if the garbage collection fails while you are doing the Software Updates/installing macOS. Just booting back and forth macOS releases/Windows won't cause any issues.

I also observed that the yearly major Windows Updates take a toll with the NVRAM, but I'm still investigating if is really needed to take any precautions and if is better to re-flash before or after (Windows seems to not have a clean up phase while installing/updating, differently from macOS) doing the Windows Updates. More on that later.

 

[BrianRecchia]

What sort of wear-leveling, if any, does the NVRAM implement?

I ask because many people seem to think reflashing a “good dump” is a good idea to ensure that your SPI chip doesn’t die, but to me this sounds absolutely counterintuitive — rewriting blocks is what wears the chip out, and of course restoring a good dump isn’t going to repair any bad flash blocks.

So really what I’m getting at is, what is the point of this reflashing? How is it *not* terrible idea to regularly, repeatedly flash a (known fragile) SPI flash?

(Personally, I’ve had my bootrom rebuilt by tsialex and I’ve flashed that once, and I intend to dump again and inject a custom boot chime into that one to reflash. After that I don’t expect to do any more flashing with any sort of regularity)

 

[tsialex]

What sort of wear-leveling, if any, does the NVRAM implement?

I ask because many people seem to think reflashing a “good dump” is a good idea to ensure that your SPI chip doesn’t die, but to me this sounds absolutely counterintuitive — rewriting blocks is what wears the chip out, and of course restoring a good dump isn’t going to repair any bad flash blocks.

So really what I’m getting at is, what is the point of this reflashing? How is it *not* terrible idea to regularly, repeatedly flash a (known fragile) SPI flash?

(Personally, I’ve had my bootrom rebuilt by tsialex and I’ve flashed that once, and I intend to dump again and inject a custom boot chime into that one to reflash. After that I don’t expect to do any more flashing with any sort of regularity)

SPI flash memories of this era have no wear leveling, the NVRAM VSS store works with a circular log to avoid premature wear, with superseded entries marked for deletion and new ones added to the tail. If you want more details, go back to the beginning of the thread.

Seems counterintuitive to re-flash the never booted BootROM image, but you are missing the point that we are trying really hard to avoid - garbage collections are extremely wear intensive with the whole procedure taking most times 6 to 8 reboot cycles, with other people here had 10+ in the past, and frequently fail usually while doing (or right after) macOS software updates since the staging procedure for SSV software updates frequently take 20~25KB. This is so intensive that @Bmju is developing emulated NVRAM for a long time, the main feature of the current 0.8.6 OC update. Clean installs also take a lot of NVRAM staging.

While re-flashing the never booted image, flashrom just read/erase/write the sectors where the VSS stores are stored with a one time operation and read/validate everything else inside the SPI flash memory. No boot loops, no corrupted NVRAM volume, no bricks.

 

[Dayo]

How is it *not* terrible idea to regularly, repeatedly flash a (known fragile) SPI flash?

It is a terrible idea to flash every 30 days as someone posted earlier for the reasons you pointed out. The NVRAM free space goes up and down as part of normal usage and going down towards 2 kb is not a reason to flash the ROM. It is normal for it to do so and it would reset back up by itself. The issue is if you want to run something like an update when it is sitting at something like 3 kb in the cycle and the update wants to stash 19 kb in the NVRAM.

I can understand @tsialex giving a simplistic guidance for people to flash every few months as opposed to some complicated flow chart on tracking and taking steps before doing something that might result in an overrun.

Ultimately, using Emulated NVRAM as mentioned, which has moved quite a bit forward thanks to @Bmju, will be the main recommendation. I just wish he would stop slacking and get his finger out to make it not need Mac OS specific daemons and also make it that you can install the driver outside OpenCore while he is at it ... among other things he should be doing ;-)

The good news is that we will soon be at a point where we don't need to bother about updates!

 

[tsialex]

The good news is that we will soon be at a point where we don't need to bother about updates!

LOL, I really prefer to bother about SSV software updates

 

[BrianRecchia]

Thanks for the very deep explanation! This all makes a whole lot more sense now!

I’m guessing that writing to the VSS stores under normal operation handles bad blocks safely, then? Because I’d imagine that there’s no bad block table in a never-booted boot ROM, but I also would imagine it’s completely normal to have, like, one or two bad blocks just randomly somewhere in the middle of a VSS store? (Or really anywhere on the chip, but I’m also assuming that the initial real-mode boot code that the CPU JMPs into probably needs to be contiguous good blocks, even if only for a few blocks?)

 

[Bmju]

Ultimately, using Emulated NVRAM as mentioned, which has moved quite a bit forward thanks to @Bmju, will be the main recommendation. I just wish he would stop slacking and get his finger out to make it not need Mac OS specific daemons and also make it that you can install the driver outside OpenCore while he is at it ... among other things he should be doing ;-)

Lol. It really is pretty stable now. Initially I was rather worried myself about why it killed sleep. But now that I understand the issue, it was nothing really to do with the driver itself - it just specifically needed added support to transfer the NVRAM S3 wake script variables across from system NVRAM.

And apart from that, I have been using it completely stably, including macOS updates, on multiple systems (Dell mff hack, MBP10,2, cMP5,1) for months now, with no problems at all. And the fixed sleep likewise, for weeks.

I'm afraid you're not going to get non-script saving of NVRAM, at least not from me. Anything more fundamental than that - at least that any of us have thought of - would be incredibly complex and not worth the effort, imho. The new script has several major improvements over the old one - though all credit to the old one too, of course.

 

[tsialex]

Thanks for the very deep explanation! This all makes a whole lot more sense now!

I’m guessing that writing to the VSS stores under normal operation handles bad blocks safely, then?

If a sector goes bad, you have a brick or at least a crazy behaving Mac. There are no spare sectors, no NAND cell management, no fail-safe with a MacPro5,1.

This become more complicated with newer Macs, where mitigations were developed like wear spreading with multiple VSS stores that are rotated over time and other techniques like moving MemoryConfig entries to dedicated stores.

With SI Macs, the NVRAM is managed completely differently.

Because I’d imagine that there’s no bad block table in a never-booted boot ROM, but I also would imagine it’s completely normal to have, like, one or two bad blocks just randomly somewhere in the middle of a VSS store?

No, you can't have that.

(Or really anywhere on the chip, but I’m also assuming that the initial real-mode boot code that the CPU JMPs into probably needs to be contiguous good blocks, even if only for a few blocks?)

X86 Reset Vector is hardcoded, if you have defective sector or corrupt info stored, you have a brick, the processor is not going to try to find a valid info nearby…

Maybe you are not understanding the whole picture or looking too much for the SPI hardware failure side and completely forgetting that you can also have logically corrupted NVRAM volumes with a perfectly good SPI flash memory, in fact is more common than SPI hardware failures.

 

[Audiomangiraldo]

you check with looking as shown here. they should be the same, as shown.

@Matty_TypeR i have verify the boot rom of my Mac Pro 4.1 and this is the result

 

[Matty_TypeR]

As you show both SMC versions are the same your fan's should not run at full speed. perhaps there is another issue. Do all the fans run at full speed? or just 1 or 2 of them?

You might also want to update your boot rom, tsi Alex would be the man to speak to about that.

 

[BrianRecchia]

Is it possible to dump a MacPro4,1 bootrom, reconstruct it as a MacPro5,1 bootrom, and flash it back under Catalina without a metal GPU?

 

[Matty_TypeR]

TsiAlex is the man to speak to about reconstruction, but i think you will need a Metal GPU for sure.