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

[tsialex]

Hey guys, hope you are all doing well. I wanted to ask if I can use Opencore bootloader to freeze my NVRAM so it doesn't get corrupted, but I want to use Mojave still, I don't want to use newer OS? Thanks.

There is no freeze NVRAM, even with a emulated VSS store you still use your real VSS stores/NVRAM volume. With an emulated VSS store you just minimize the OS usage, but a lot of VSS store writing is while the Mac Pro firmware is in PEI mode doing POST operations - anything hardware related is still written to the real SPI, for example MemoryConfig entries, long before OpenCore is even loaded.

You sure can use emulated NVRAM, but your Mac Pro already have 10/12/13 years of SPI usage already and you can't avoid that. For someone that wants to run Mojave, a reconstructed BootROM image and a MATT card (or replacing the SPI flash yourself) makes a lot more sense, IMHO.

 

[Dayo]

Hey guys, hope you are all doing well. I wanted to ask if I can use Opencore bootloader to freeze my NVRAM so it doesn't get corrupted, but I want to use Mojave still, I don't want to use newer OS? Thanks.

You definitely can. Running OpenCore's emulated NVRAM feature is the smartest thing to do on a cMP.

It is of course not a panacea for everything bad that can happen but note that even if running a reconstructed BootROM and then you run an update, for instance, and this tries to dump 30kb of data into your NVRAM when you are at a point in the NVRAM free space cycle where you have 20kb of space, your NVRAM will be hosed.

This is why it is best to spend almost 200 bucks to add a Matt card to the setup so that you can recover if such happens. If you have additional equipment and the know how, you will be able recover the Matt card for reuse. Otherwise, you will need to buy a new one.

On the other hand with Emulated NVRAM, you will be perfectly fine in such a situation. Actually, you will be fine even if it tries to dump 300kb and you only have 2kb of free space left in the hardare NVRAM! (Not that anything working normally will try to dump 300kb but you get the point)

It doesn't totally freeze Nvram btw ... which is why the post says it *BASICALLY* freezes it. Subtle difference to bear in mind as there are some minor firmware level Nvram storage interactions that can still happen. The important thnig is that the big Nvram storage hits generally happen when loading the OS Kernel in general and when running updates in particular. Especially as from Big Sur.

The best setup IMO is to implement EmuNvram ASAP and then consider Nvram Reconstruction especially if your Nvram needs this, such as when running a flashed MP41 in particular.

If you have the cash to spare, you might as well go the whole hog and add a Matt card to this which will make things as bullet proof as possible. A bit OTT for someone that wants to stick with Mojave though.

You will need to refer to the OpenCore maunal to set Emulated Nvram up yourself. You can ping @Bmju for help on that if you get stuck.

 

[tsialex]

This is why it is best to spend almost 200 bucks

Where you got this crazy number? A MATT card is € 65, reconstruction $60.

If you can replace the SPI flash yourself, you can do EVERYTHING for less than $75, including all supplies.

 

[Bmju]

I would also say it is possible to reset the Matt card yourself. (And can confirm the € 65 price from recent experience! ) In my understanding, if you are trialling test firmware changes and want to use just use one Matt card, and no SOIC clip, then you do have to be prepared to connect or disconnect the Matt card while the OS is running - unadvisable as that sounds - in order to have one bootable thing, one sacrificial (test) thing, and a way to boot from one then recover the other.

 

[ogiphone02]

There is no freeze NVRAM, even with a emulated VSS store you still use your real VSS stores/NVRAM volume. With an emulated VSS store you just minimize the OS usage, but a lot of VSS store writing is while the Mac Pro firmware is in PEI mode doing POST operations - anything hardware related is still written to the real SPI, for example MemoryConfig entries, long before OpenCore is even loaded.

You sure can use emulated NVRAM, but your Mac Pro already have 10/12/13 years of SPI usage already and you can't avoid that. For someone that wants to run Mojave, a reconstructed BootROM image and a MATT card (or replacing the SPI flash yourself) makes a lot more sense, IMHO.

Ah alright thanks.

 

[ogiphone02]

You definitely can. Running OpenCore's emulated NVRAM feature is the smartest thing to do on a cMP.

It is of course not a panacea for everything bad that can happen but note that even if running a reconstructed BootROM and then you run an update, for instance, and this tries to dump 30kb of data into your NVRAM when you are at a point in the NVRAM free space cycle where you have 20kb of space, your NVRAM will be hosed.

This is why it is best to spend almost 200 bucks to add a Matt card to the setup so that you can recover if such happens. If you have additional equipment and the know how, you will be able recover the Matt card for reuse. Otherwise, you will need to buy a new one.

On the other hand with Emulated NVRAM, you will be perfectly fine in such a situation. Actually, you will be fine even if it tries to dump 300kb and you only have 2kb of free space left in the hardare NVRAM! (Not that anything working normally will try to dump 300kb but you get the point)

It doesn't totally freeze Nvram btw ... which is why the post says it *BASICALLY* freezes it. Subtle difference to bear in mind as there are some minor firmware level Nvram storage interactions that can still happen. The important thnig is that the big Nvram storage hits generally happen when loading the OS Kernel in general and when running updates in particular. Especially as from Big Sur.

The best setup IMO is to implement EmuNvram ASAP and then consider Nvram Reconstruction especially if your Nvram needs this, such as when running a flashed MP41 in particular.

If you have the cash to spare, you might as well go the whole hog and add a Matt card to this which will make things as bullet proof as possible. A bit OTT for someone that wants to stick with Mojave though.

You will need to refer to the OpenCore maunal to set Emulated Nvram up yourself. You can ping @Bmju for help on that if you get stuck.

Yea got it, I think I have something like 46XX space left when I was checking it. It's 5,1 not flashed.

 

[tsialex]

I would also say it is possible to reset the Matt card yourself. (And can confirm the € 65 price from recent experience! ) In my understanding, if you are trialling test firmware changes and want to use just use one Matt card, and no SOIC clip, then you do have to be prepared to connect or disconnect the Matt card while the OS is running - unadvisable as that sounds - in order to have one bootable thing, one sacrificial (test) thing, and a way to boot from one then recover the other.

Besides the possibility of a short while hot inserting, don't forget that the MOLEX connector is rated for just 20 insertions, already had to replace both the male and female connectors.

 

[Dayo]

A MATT card is € 65

HA! Could have sworn he was quoting EUR 100 at one point. Might have been blinded by the Trashcan version.

Anyway, good to know it is more affordable than I thought ... more so since the EUR has slumped in value since the war in Ukraine. Not available for MP31 either way.

Best startegy is a combination for holistic coverage as I said though. Each bit does something useful.

 

[tsialex]

Not available for MP31 either way.

MacPro3,1 FWB flash memories are the best technology of the time, it's extremely difficult to find one that failed, while SPI fails all the time.

While much more reliable, it's a real pain in the a$$ to replace/reprogram it and cost ~10x more.

Best startegy is a combination for holistic coverage as I said though. Each bit does something useful.

I agree, but since @ogiphone02 explicitly wants to run Mojave, emulated VSS store main advantage is a moot point, no Software Updates. The 12+ years old SPI flash problem still exists and no significant advantages (in this specific use case) for a lot more complexity.

 

[Dayo]

Not so sure about complexity in real terms but, yes, it does require some extra steps for which a Mac OS script has been provided ... easy to do as long as the admittedly prevalent irrational fear of Terminal is not present. With MyBootMgr, a "Yes" button click on a question while setting things up would put it in place.

A weakness of the EmuNvram, as it currently stands, is lack of persistence on Non-MacOS instances.
That is, while it spares them Nvram hits, it only uses volatile storage and does not leverage disk storage for persistence.

Apparently not noticeable in operation but is a short coming nonetheless.
Basically needs corresponding Window/Linux daemons to be created by @Bmju to remove this imperfection.

Anyway, I suppose the OP has enough info to make a call on whether to add this option to their toolkit or not.

 

[Bmju]

Besides the possibility of a short while hot inserting, don't forget that the MOLEX connector is rated for just 20 insertions, already had to replace both the male and female connectors.

Yes, the connector feels super-fragile to me too. And hot-plugging probably not recommended, for many reasons! But then there would need to be "additional hardware", namely a SOIC clip, in order to reprogram own Matt chip otherwise. (Right?!) And you still don't get round MOLEX reconnection limit... :-(

I feel like there would probably be fancier solutions, e.g. something like a Matt card, but with external re-programmer permanently connected - but I think that would need to be home-made (or Apple dev. hardware, maybe). Maybe someone knows more?

 

[Bmju]

Basically needs corresponding Window/Linux daemons to be created by @Bmju to remove this imperfection.

I'm not going to create them! (Sorry!) Maybe someone else will make a PR to OpenCore for this.

 

[tsialex]

Yes, the connector feels super-fragile to me too. And hot-plugging probably not recommended, for many reasons! But then there would need to be "additional hardware", namely a SOIC clip, in order to reprogram own Matt chip otherwise. (Right?!) So you still don't get round MOLEX reconnection limit... :-(

I feel like there would probably be fancier solutions, e.g. something like a Matt card, but with external re-programmer permanently connected - but I think that would need to be home-made (or Apple dev. hardware, maybe). Maybe someone knows more?

You can always accomplish this on the cheap, with a clamshell SOIC socket instead of the backplane SPI. I have one with my test Mac Pro.

Another solution is to improve the Matt card idea with a ICSP connector (MOSI/MISO/CLK/GND/VCC), a 74HC244 as a buffer and a switch on the CS line to allow it to disconnect from the backplane, so you just power off the Mac Pro, connect the ICSP cable and flash it.

 

[cdf]

Interesting. Depending on how the CS pin of the original chip is connected to the header, maybe a dual-BIOS-type solution could be implemented. Flipping the switch would select either the original chip or the new one. If the switch can be flipped with the Mac booted (could this corrupt the flash memory?), then either chip could be recovered with ROMTool provided that the other is healthy. Maybe this could eliminate the problem of header wear and the risks with hot insertion.

 

[tsialex]

Interesting. Depending on how the CS pin of the original chip is connected to the header, maybe a dual-BIOS-type solution could be implemented. Flipping the switch would select either the original chip or the new one. If the switch can be flipped with the Mac booted (could this corrupt the flash memory?), then either chip could be recovered with ROMTool provided that the other is healthy. Maybe this could eliminate the problem of header wear and the risks with hot insertion.

No need to use a dual SPI flash solution, if it was what you were thinking, a 64MBit flash memory is a better solution and probably would work fine with hot switching. Just use the second half as a recovery image.

 

[Bmju]

No need to use a dual SPI flash solution, if it was what you were thinking, a 64MBit flash memory is a better solution and probably would work fine with hot switching. Just use the second half as a recovery image.

But how could you force the system to boot from one or the other half of the chip?

 

[cdf]

I was thinking of switching between the original chip and one on the Matt card so as to provide a way to safely recover the original chip (but I’m not sure about hot switching in this case)...

Regarding using a 64Mbit chip: Unless there is a way in hardware to select one half or the other, wouldn’t this solution require a software (firmware) component?

 

[Bmju]

I was thinking of switching between the original chip and one on the Matt card so as to provide a way to safely recover the original chip (but I’m not sure about hot switching in this case)...

Regarding using a 64Mbit chip: Unless there is a way in hardware to select one half or the other, wouldn’t this solution require a software (firmware) component?

Well, you definitely can hot plug a standard Matt card. At least, 'a friend' says he's done such a stupid thing with no problems so far... And actually, without dumping anyone in it, someone (not @tsialex!) who should definitely know about Matt cards said it would work, before 'the friend' tried it. (Disclaimer: I am still not recommending it!) So I guess having it on a physical switch can't be worse....

Regarding the 64Mb chip, I am sure there must be a hardware solution to map this - but not at all sure if there would be a simple one?

 

[Dayo]

I guess having it on a physical switch can't be worse

Might be worth suggesting inserting a switch to the guy that makes the Matt cards.

I take it that the main attraction of a switch is that this might allow getting at a damaged one. Right?
If so, would this allow arbitrarily flashing back to one or the other option?

 

[cdf]

I take it that the main attraction of a switch is that this might allow getting at a damaged one. Right?
If so, would this allow arbitrarily flashing back to one or the other option?

Yes (to both questions), that’s the idea. (I think it’s time for another hardware project 😉)

 

[Bmju]

Might be worth suggesting inserting a switch to the guy that makes the Matt cards.

I take it that the main attraction of a switch is that this might allow getting at a damaged one. Right?
If so, would this allow arbitrarily flashing back to one or the other option?

If you're flashing work-in-progress firmware tests, there's always a possibility that the firmware will become unbootable - at which point ofc you cannot reprogram it in-OS, since the machine won't boot. If you can extract the bricked NVRAM chip (unplug a Matt card; desolder the on-board chip), you can re-program it while it is out of the machine, e.g. using a SOIC clip connected to (an OS running on) another machine. However... if you can boot your machine using the 'other' chip (whichever one of out of the on-board chip or the Matt card is still bootable), and then hot-switch between them while the machine is on, then you can boot with the one that still works, and then hot-switch and fix (i.e. reprogram) the one which is bricked. So 'yes' and 'yes', basically.

 

[Bmju]

I think it’s time for another hardware project

Sounds like it might be possible to modify just the Matt card here, then plug it in and leave it in, with a switch running from it to the outside...

 

[Dayo]

I think I have something like 46XX space left when I was checking it.

The available free space is not a constant. It progressively reduces as you use the unit, mainly on each boot, until it hits a minimum threshold value at which point, space is freed up by the firmware and the cycle starts again. The minimum threshold value at which space is freed up is 2,048 bytes (2 kilobytes).

So, depending on where things are in the cycle when you check, you might have 4,608 bytes or 45,056 bytes of free space as an example. Nothing unusual with either value of themselves but while a Mac OS update dumping 19kb to the NVRAM when you happen to be at 45kb in the cycle is not an issue, it is a potential brick inducer if you happen to be at 4kb. (Assuming the Nvram is otherwise healthy, it is best to always reset it manually to maximise available space before running updates)

Other problems happen when the process that frees space up, Garbage Collection, has failed and stuff therefore continues to be written beyond the designated storage boundary, overwriting other stuff until it hits something critical and the machine is unable to be booted (AKA Bricked). Such problems are part of what is rectified by reconstructing the BootROM.

 

[dokdee]

It's a service. You send your current BootROM image dump, pictures of the MLB and ESN labels and the SystemInformation report. Your current BootROM image dump is validated against the data from the labels, all checksums verified, all modules checked if are the current versions, then everything is upgraded, NVRAM volume cleaned, BootROM reconstructed and tested. After all that, a never booted BootROM image for your Mac Pro is sent.

Hi tsialex - firstly thanks for all your excellent info here! What a wonderful resource these forums are.
Could you please pm me about your bootrom reconstruction service? (I'm new here, so it seems I can't pm you myself.)

I recently bought a 5,1 2010 - and the ROM dump looks just like the corruption shown in the bottom UEFI tool screenshot of your first post. I don't want to make any further config changes or updates for fear of getting a brick :-/
Hoping you can help - thanks!

 

[streak8047]

Recover dead bios recovery MacPro 5.1 ,it was possible to restore using CH341a clip programmer ,already having bios for macpro 5.1 from another Macpro,with out removing chip can be write the bios files can be able to change serial of original MacPro. 2009 Logic board Memory chip shows chip 25VF032B ,Ch341A detects as different chip W25Q80DV/DL.