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

[Ausdauersportler]

For anyone with a Mac Pro made before November 2010, with hardware descriptors base_16 to base_20, just the improvements of the upgrade to base_21 version already pay for the reconstruction.

The improvements are huge for early-2009s, and the mid-2010s made before November 2010, dual CPU Mac Pros. Apple removed the phantom sensors and fine tuned the voltage and amperage sensors to the max, that's why you see so much better thermals after the reconstruction.

While I don't think that Apple intended to make the POST faster with 144.0.0.0.0 BootBlock/PEI tweaks, it was primarily to solve the black screen when cold booting with a PCIe switched card, some users report faster boot times. This only happened because @crjackson2134 spent months doing bug reports, following on everything engineers asked and testing betas back then - he even got a brick with W3680 and 142.0.0.0.0 for his efforts…

Hello!

Of course I do not want to hi-jack the thread here, but is there any information available about this black screen problem in the public, how it exactly happen, what had to be done to come around it without having a firmware update, what you learned about the BootBlock/PEI tweaks and what you guys found about it doing some own reverse engineering back and the in the past?

Thanks in advance!

 

[tsialex]

Hello!

Of course I do not want to hi-jack the thread here, but is there any information available about this black screen problem in the public,

Besides several posts here on this thread around 138.0.0.0.0 to 144.0.0.0.0 timeframe and on Apple's RADAR, I don't think so. @crjackson2134 probably still have the numbers.

how it exactly happen,

Black screen at cold boot when a PCIe switched card is installed, it's a Mac Pro bug only AFAIK. If I remember correctly @crjackson2134 had 1 black screen at every 3 or 4 power ups, he can explain in more detail. At the time I commented here that I had the exactly same config (same GPU, same CPU, same SSD7101A-1, same blades) as him and did not had the same number of black screens, but I didn't and still don't shutdown my Mac Pro daily as he did back then.

Without the PCIe switched card, no black screens when cold powering up.

what had to be done to come around it without having a firmware update,

Shutdown, wait a little and try powering it up again.

what you learned about the BootBlock/PEI tweaks and what you guys found about it doing some own reverse engineering back and the in the past?

Thanks in advance!

Back then I tracked each module that changed between the several beta firmware releases, so we saw exactly where Apple was making the changes and we knew that was a BootBlock/PEI related issue, but AFAIK no one ever disassembled the updated modules and compared to the past releases to found what exactly Apple did to solve the black screen problem.

 

[alphascorp]

Hello @tsialex
I have SST25VF032B on my early 2009 backplane (cMP4,1 flashed 5,1).
I would like to prepare a ROM in case mine goes bad.
Can I replace my SST25VF032B with this MX25L3206E?
https://www.amazon.fr/flash-25L3206E-MX25L3206EM2I12G-MX25L3206EM2I-12G-MX25L3206E/dp/B09RZXGBC5/ref=sr_1_2?__mk_fr_FR=ÅMÅŽÕÑ&crid=TFG286MU3GSA&keywords=MX25L3206E&qid=1651585145&sprefix=mx25l3206e,aps,68&sr=8-2
Can you tell me by PM the cost for a ROM rebuild, if you are not too busy. Thanks in advance.

 

[tsialex]

Hello @tsialex
I have SST25VF032B on my early 2009 backplane (cMP4,1 flashed 5,1).
I would like to prepare a ROM in case mine goes bad.
Can I replace my SST25VF032B with this MX25L3206E?
https://www.amazon.fr/flash-25L3206E-MX25L3206EM2I12G-MX25L3206EM2I-12G-MX25L3206E/dp/B09RZXGBC5/ref=sr_1_2?__mk_fr_FR=ÅMÅŽÕÑ&crid=TFG286MU3GSA&keywords=MX25L3206E&qid=1651585145&sprefix=mx25l3206e,aps,68&sr=8-2

Yes, it's a drop in replacement. Apple used MX25L3206E with mid-2012s. You can also use MX25L3205A or MX25L3205D.

Can you tell me by PM the cost for a ROM rebuild, if you are not too busy. Thanks in advance.

PM with instructions/cost sent.

 

[rp7777]

@tsialex - appreciate your help/advice.

I have a Mac Pro 2012 (was a 2010 that had a logic board issue and was replaced with a 2012 board).

I have updated boot rom to 144.0.0.0.0 and running Mojave (since around 2019).

I have ATI Radeon RX 580 GPU (powered off single mini-pcie connector - other thread covered this and I will be soon doing Pixlas Mod to cover potential power issues).

I have installed PCI NVMe card (Kryo 2 card) and soon another (OWC Accelsior 1M2).

Also replaced WiFi/BT with Broadcom BCM943602CDP so ready for later OS.

I want to install OpenCore and upgrade MacOS (Big Sur or Monterey) at some point.

I have been reading (mostly here) about OpenCore, upgrade, Boot Rom thread, NVRAM etc. and the impression I have (could be wrong) is that it is wise (especially if going OpenCore/upgrading) to ensure my BootROM is good and have a "clean" version to flash if needed.

Could you advise if that is an approach I need to follow - if so, would you be so kind to advise instructions/guide etc. on providing BootROM dump (have done with Macshrauber tool and ROMtool already but maybe different required?) and if you could take a look at my BootROM and advise/clean/whatever may be required.

Understand that you may send info via PM - appreciate if you could and cost details etc.

Any and all help is appreciated.

 

[tsialex]

@tsialex - appreciate your help/advice.

I have a Mac Pro 2012 (was a 2010 that had a logic board issue and was replaced with a 2012 board).

I have updated boot rom to 144.0.0.0.0 and running Mojave (since around 2019).

I have ATI Radeon RX 580 GPU (powered off single mini-pcie connector - other thread covered this and I will be soon doing Pixlas Mod to cover potential power issues).

I have installed PCI NVMe card (Kryo 2 card) and soon another (OWC Accelsior 1M2).

Also replaced WiFi/BT with Broadcom BCM943602CDP so ready for later OS.

I want to install OpenCore and upgrade MacOS (Big Sur or Monterey) at some point.

I have been reading (mostly here) about OpenCore, upgrade, Boot Rom thread, NVRAM etc. and the impression I have (could be wrong) is that it is wise (especially if going OpenCore/upgrading) to ensure my BootROM is good and have a "clean" version to flash if needed.

Could you advise if that is an approach I need to follow - if so, would you be so kind to advise instructions/guide etc. on providing BootROM dump (have done with Macshrauber tool and ROMtool already but maybe different required?) and if you could take a look at my BootROM and advise/clean/whatever may be required.

Understand that you may send info via PM - appreciate if you could and cost details etc.

Any and all help is appreciated.

Sure, check your PM, please follow the instructions to the letter. Btw, I can also match your backplane to the case, if you want to.

 

[thibsweb]

I have ATI Radeon RX 580 GPU (powered off single mini-pcie connector - other thread covered this and I will be soon doing Pixlas Mod to cover potential power issues).

Off-topic, but you really should not need to do Pixlas mod for an RX580. A dual mini 6 pin to single 8pin cable works flawlessly.

 

[tsialex]

Off-topic, but you really should not need to do Pixlas mod for an RX580. A dual mini 6 pin to single 8pin cable works flawlessly.

Some RX 580 models, like Sapphire Nitro+, when in full load can draw a lot more than the backplane can safely provide and the SMC overcurrent protection shuts down the PSU. Also, there are several models that the power connectors are 8-pin + 6-pin.

Anyway, this is way off-topic here and there are several threads that extensively cover this topic already.

 

[FlorisVN]

First of all great thread for macpro users out there !

I have two 4,1 flashed to 5,1 MacPro's, one I use daily the other one is a spare backup one.
I am still running Mojave on it, but am planning on running Bigsur or Montery in the future.

Anyway, I thought I should make a rom backup asap, and get a check on it, and if neccecery fix my rom if it's getting corrupted.

Then buy a Matt card, and flash my reconstructed rom on the mattcard, and run of the mattcard.
Is that a good solution, to presurve my macpro's and expending the life of them.. ?

Thanks in advance,

 

[tsialex]

Then buy a Matt card, and flash my reconstructed rom on the mattcard, and run of the mattcard.
Is that a good solution, to presurve my macpro's and expending the life of them.. ?

If you can't de-solder/solder a 8-pin SOIC, MATT card is the way to replace the SPI. You will get the SPI running for another decade.

 

[FlorisVN]

If you can't de-solder/solder a 8-pin SOIC, MATT card is the way to replace the SPI. You will get the SPI running for another decade.

Thanks for your fast response !

Nope I can't de-solder/solder a 8-pin SOIC, So then indeed the MATT card would the best solution for me..
Great to hear it will be a good future proof solution..

I was wondering how to flash the MATT card, the reflashing of this card is not completely clear to me..
Is this being done trough for example MacOS, and using flashrom for example with brew ?

I have used flashrom also in the past for flashing imac bootroms..

Looking forward to your message, thanks in advance

 

[tsialex]

Thanks for your fast response !

Nope I can't de-solder/solder a 8-pin SOIC, So then indeed the MATT card would the best solution for me..
Great to hear it will be a good future proof solution..

I was wondering how to flash the MATT card, the reflashing of this card is not completely clear to me..
Is this being done trough for example MacOS, and using flashrom for example with brew ?

I have used flashrom also in the past for flashing imac bootroms..

Looking forward to your message, thanks in advance

You flash it exactly as you flashed your never booted BootROM image. It's a SPI flash replacement, once installed it will behave exactly the original SPI.

• Shutdown your Mac Pro,
• install the MATT card to the LittleFRANK connector,
• power your Mac Pro,
• boot Recovery,
• disable SIP,
• reboot,
• login to macOS and open ROMTool,
• finally, flash your own never booted BootROM image.
• shutdown

 

[FlorisVN]

You flash it exactly as you flashed your never booted BootROM image. It's a SPI flash replacement, once installed it will behave exactly the original SPI.

• Shutdown your Mac Pro,
• install the MATT card to the LittleFRANK connector,
• power your Mac Pro,
• boot Recovery,
• disable SIP,
• reboot,
• login to macOS and open ROMTool,
• finally, flash your own never booted BootROM image.
• shutdown

Thanks for these instructions !
That sounds very clear

I forgot I was able to use ROMTool to also flash back a firmware..

I used a CH341 with flashrom in the past to flash the rom back, to iMac's..

 

[sfalatko]

Thanks for these instructions !
That sounds very clear

I forgot I was able to use ROMTool to also flash back a firmware..

I used a CH341 with flashrom in the past to flash the rom back, to iMac's..

One other reminder - disable your wifi and disconnect your ethernet before you install the MATT card so that your iCloud/messages account won't get locked because of the serial number in the MATT card generic ROM. Once you flash your own ROM and confirm that your machine serial number is showing correctly you can reconnect to the internet....

 

[tsialex]

One other reminder - disable your wifi and disconnect your ethernet before you install the MATT card so that your iCloud/messages account won't get locked because of the serial number in the MATT card generic ROM. Once you flash your own ROM and confirm that your machine serial number is showing correctly you can reconnect to the internet....

If the macOS install/main disk you are booting is logged in to iCloud/Messages/FaceTime, you will be logged off the moment you boot the MATT card for the first time/still factory flashed because of the different hardwareIDs. No way to avoid this unless you use a flash/rescue disk/macOS install not logged to Apple services.

Since I frequently have to test BootROMs with other hardwareIDs than my own, I've tried all imaginable ways to avoid this without success. Overtime this become such of a hassle that I bought a cheap/dead Mac Pro and repaired it just for doing the BootROM tests and don't mess with my main Mac Pro.

 

[Dayo]

I've tried all imaginable ways to avoid this without success.

Is disconnecting from the internet not enough?

 

[tsialex]

Is disconnecting from the internet not enough?

If the macOS install/main disk you are booting is logged in to iCloud/Messages/FaceTime, you will be logged off the moment you boot the MATT card for the first time/still factory flashed because of the different hardwareIDs.

It's like you moved the main disk to another Mac.

 

[Dayo]

I see. Appears to be.
Just got a bit confused by your needing a separate cheap/dead unit.

 

[Macschrauber]

can second that, I use my caseless test rig to flash firmwares plus a 2nd AppleID I just created for firmware tests.

I try not to forget to deactivate Machine IDs once I have tested a rom or complete machine.

dont want to mess up my own AppleID. Tho I have more than 10 devices registered on it.

 

[Dayo]

Trying to wrap my head around implications of this ...

While individual bytes can be read or written, erases must occur in 4kB blocks - therefore, if you want to change one bit from 0 to 1, you have to erase the entire 4k block that contains it.

in light of this ...

Variables are limited to 2048 bytes

Does this mean that changing one variable might affect other variables stored in the same 4kb block.

I am of course concluding that if the max variable size is 2kb, there can be more than one variable stored in a 4kb block ... or is that a wrong conclusion to start with?

If stuff is working in 4kb block chunks, why not make the max size 4kb to fit this approach? I suppose I must be showing a lack of understanding of something basic here ... which I will be quite pleased to have explained!

 

[joevt]

Does this mean that changing one variable might affect other variables stored in the same 4kb block.

No, only the space used by the new variable will appear to be changed. All other bytes in the 4K blocks will have the same values as in the NVRAM because the blocks were previously read from NVRAM into RAM. The nvram blocks may contain more than one variable. Variables may span multiple blocks.

It's the same thing as changing a byte in a file. The entire block containing the byte must be read from disk, then you change the byte, then you write the entire block back to disk.
The disk blocks contain other strings of bytes. Strings of bytes may span multiple blocks.

If stuff is working in 4kb block chunks, why not make the max size 4kb to fit this approach?

Max size is arbitrary. They could have chosen a max size equal to the entire nvram size (minus some overhead)... You don't gain anything with having different max sizes except the ability to write larger variables.

Maybe you are thinking of minimum size, so that there is one variable per 4K block. That would be a waste of space and limit the number of variables you can have in NVRAM since variables are usually much shorter than 4K.

 

[Dayo]

The entire block containing the byte must be read from disk, then you change the byte, then you write the entire block back to disk. The disk blocks contain other strings of bytes. Strings of bytes may span multiple blocks.

Thanks.

I suppose where I am getting muddled up is that when writing back, changed variables apparently get appended to the end of the store and the existing record just gets invalidated.

So in a case with Var A, B & C of 1kb each in a block plus Var D of 2kb spanning into the next, does a change to Var A mean Vars B, C & D therefore have to go along for the ride to the end of the store ... with Var D taking those from the next block along and so on?

Obviously can't be the case but just trying to understand the likely mechanics.

 

[tsialex]

Thanks.

I suppose where I am getting muddled up is that when writing back, changed variables apparently get appended to the end of the store and the existing record just gets invalidated.

So in a case with Var A, B & C of 1kb each in a block plus Var D of 2kb spanning into the next, does a change to Var A mean Vars B, C & D therefore have to go along for the ride to the end of the store ... with Var D taking those from the next block along and so on?

Obviously can't be the case but just trying to understand the likely mechanics.

No, it's a circular log. When a variable is superseded, it's marked for deletion at the next GC and the current value is added to the end of the circular log, this continues until GC is needed, usually when the VSS store is practically full.

The NVRAM is designed in a way to minimize NAND erases.

 

[Dayo]

When a variable is superseded, it's marked for deletion at the next GC and the current value is added to the end of the circular log

Thanks. I was referring to this but was perhaps too imprecise with terminology.

The NVRAM is designed in a way to minimize NAND erases.

Seems my actual block was in mixing erasures and updates up.
Was thinking of them as if they are same thing or more accurately, that updates involved erasures (not the case).

 

[tsialex]

Seems my actual block was in mixing erasures and updates up.
Was thinking of them as if they are same thing or more accurately, that updates involved erasures (not the case).

Yep, I suppose that you were thinking that the NVRAM was like a RAM stored matrix or something along the lines. NAND behaves very differently from RAM.