afterwards I check which fans run at maximum speed, I also believe that @tsialex can help me understand what the problem is
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I think your problem may not be BootROM related. You better open a new thread (or find a related thread) to discuss this issue. In the mean time, you better check if there is anything overheating (e.g. the Northbridge). Or if all fans speed able to show up correctly (e.g. not zero).
I wonder if our friends @khronokernel and @dhinakg at OCLP might consider making the emulated NVRAM driver an advanced setting in OCLP, now that it is - I believe - stable and potentially well worth having. Loading it (i.e. so that emulated NVRAM is used) is just a mod to
config.plist of course, but installing the script (i.e. so that the contents of NVRAM are saved at macOS restart) could be some automatic part of the post-install patching system if the driver itself is loaded, possibly?
Last edited:
By the way, @Dayo , I believe you should be able to load it as a UEFI driver without OC, and successfully get an empty, emulated NVRAM store which will work fine for running OS-es (only difference is OC will not be communicating with an additional protocol the driver exports, to allow OC to ask it to load - or save, e.g. with CTRL+Enter - the NVRAM contents from
ESP:\NVRAM\nvram.plist). You could double-check that it works (e.g. you would have different test variables in emulated vs. non-emulated NVRAM, as I'm sure you've already tried). Not sure exactly your use-case is for having it loaded without OC? But if it is to let all OS-es (Windows, Linux) also run without using the real NVRAM store of a cMP, even if started by RefindPlus not OC, then I think it should work (albeit without in-OS or in-installer changes to NVRAM ever getting saved, but that's suprisingly little of a problem, it turns out). (And OC should still see it and communicate successfully with it, if loaded afterwards - as long OC doesn't reinstall the driver over itself again, of course!)
Last edited:
That would be desirable. Giving persistence up is a bit too much of an ask however.
I suppose giving In-OS NVRAM persistence up can be lived with but In-Installer persistence is a must. Could write something to temporarily disable things for updates but seems too much hassle for miniscule gain.
Anyway, got back to looking at adding the Emulated NVRAM "As it Stands" to MyBootMgr again ... hopefully by the next version and opened a ticket on the OpenCore repo to that end. Forgot to cc you.
Last edited:
Yes, but you should always dump and flash from a supported macOS release. It's not safe to dump or flash from hacked installs or OC instances, don't ask why… 🧱
You don't need a METAL GPU to flash a never booted BootROM image, no METAL dependence or verification.
Maybe I'm missing something, you are emulating the main VSS store and not the whole NVRAM volume, no (at least is what I understood from the code the last time I've checked)? Or you started to implement support for the secondary, FTW, Fsys and Gaid stores?
While FTW is not used by MacPro5,1 EFI, it's used in PEI phase by older Macs.
I may need to do more research. I mean 'my' driver is an EDK-II driver, one which OpenDuet (i.e. OpenCore's UEFI support for BIOS-only systems) also already used, prior to the standalone driver. I had to downgrade various UEFI 2.0 parts of the driver to EFI 1.1 to make it work on older macs. And I do know for certain that it traps everything which would normally be read and written by gRT->GetVariable, SetVariable and GetNextVariableName. Exactly how that maps to an answer to your question, I am less sure. I mean, I assume the secondary volume must also be protected (never written to), in that I assume that the secondary volume is normally modified, as appropriate, by the primary volume's NVRAM access code, and the normal primary volume NVRAM access code is not even running once the emulated NVRAM is in place.
Remind me again why we can't just expect MyBootMgr users to run the install script themselves, on each macOS install which they have?
More or less the same reasons why the daemon set up script exists in the first place I suppose.
With respect to the specific request, I had thought it would be a trivial and desirable enhancement but it appears I underestimated the difficulty and overestimated the desirability.
Not a biggie, I have closed the ticket and will look instead into putting a custom action together as was suggested.
Last edited:
We can't expect the users to run the script for the same reasons the script exists in the first place? You've lost me!
But apart from that, and also as summarised with a bit more detail on the issue, I agree with your status report. Thanks.
Hey folks! I'm new to MacRumors (nice to meet you all!) and just got a MacPro 5,1. I dumped the BootROM to check if it is healthy, and it seems to be close to bricking (no free space listed at all). @tsialex would I be able to PM you about reconstructing my BootROM?
EDIT: I see you mentioned that we shouldn't dump from an OC instance. I did dump mine from Monterey via OC. Do I need to install a copy of Mojave first and re-dump?
EDIT: I see you mentioned that we shouldn't dump from an OC instance. I did dump mine from Monterey via OC. Do I need to install a copy of Mojave first and re-dump?
Don't dump or flash booted from OpenCore, too much moving parts and I had very bad dumps and flashes over the years, even had a brick flashing from 12.6.1 past week. Keep it simple and reliable. I've sent you a PM with instructions.
Mojave is the choice for me. A booting USb flash. Just 1,05 euros in Aliexpress.
In theory, PEI when at power on initialization detects the main VSS store with less than 2KB of available space should immediately trigger a garbage collection run.
In real life, BootROM image dumps like this one from @macguru8 are becoming worryingly common:
One DIMM change/one MemoryConfig entry superseded and, at minimum, the secondary VSS store is overrun.
In real life, BootROM image dumps like this one from @macguru8 are becoming worryingly common:
One DIMM change/one MemoryConfig entry superseded and, at minimum, the secondary VSS store is overrun.
What's he got filling the NVRAM up ... any particularly large items?
Presumably running Monterey ... has he messed with Ventura as well?
Going back to this, while it still seems desirable for users to be able to run the script *for* any installation they want *from* a single installation (the specific request made), there are just too many moving parts to consider that mean setting emulated NVRAM up on a setup that allows arbitrarily booting via OpenCore, or not, is currently probably best left as a manual task.
Would be great to have an option to specify a
Min Kernel limit on loading the driver, as this, in combination with the earlier request, would have made it *easier* to pull together. However, I can't envision such a proposal passing muster since it would need to be applied to all drivers loaded.Basically an extension of the
LoadEarly concept, which already tests the limits of "proper" config and would probably have been summarily tossed out by the Dear Leader if it had been proposed by any other.EDIT:
Kernel filtering can't be done for drivers as too early to determine kernel version.
Last edited:
Well, any new option would normally need applying to all drivers or none, though our drivers now take arguments, so driver-specific options can also be added. But a MinKernel option for a driver I would suggest does not make sense, because these are (U)EFI drivers, not macOS patches.
I also don't think we need it (or something like it), in this particular case.
The emulated NVRAM works in all versions of macOS (or in Windows, or in any version of Linux); it is neutral about what OS is run. And the Launchd script works in very many versions of macOS: it was updated and tested to work down to Snow Leopard in the recent release of OpenCore. To be clear, I have no evidence that it does not work below Snow Leopard, I just haven't tested it (yet; I had to stop somewhere, Snow Leopard 10.6 is quite a low version to go down to, for most people; quite a few parts of OC &/or associated Tools are compiled with support only down to Lion 10.7, for example).
Do you actually have a real version of macOS (below Snow Leopard, presumably) where you have reason to believe that emulated NVRAM plus the script does not currently work?
No, it was for flexibility and choice (broadly speaking).
In any case, given the amount of effort involved (and limited probability of success) in overcoming prevailing headwinds and obstacles, I decided to take an independent path to tackling stuff I am interested in. Appreciate your efforts btw.
Hello Tsialex, I had a bad adventure with a previous cMP 4.1 to 5.1 that died on me... and now I purchased a complete "new" machine (a 12 core 2010 already with 144 installed - previous owner did the upgrade, hopefully correctly). First thing I wanted to do is have a reconstructed bootROM and a programmed spi chip as spare available. I can hot air solder SMD and also have a programmer that should work. I will receive the machine next week, but am preparing for it... what should I do?
Thank you,
Franco
Thank you,
Franco
First step is to buy the replacement SPI flash memory (MXIC 25L3206E is the only one that you can still buy brand new from reputable sellers) and any supplies you'll need like Kapton tape, desolder braid, flux and etc.
When you have everything on hand, you can start by dumping the current BootROM image and then you ask by PM for the clean-up/upgrade/reconstruction service.
Btw, you should replace the backplane SPI flash memory right away, it's between 10 to 12 years old by now. It usually fails right in the worst possible moment. Think as a required mid-life preventive maintenance.
OK, well I do have a small home lab for electronics and already have everything to rework SMD except the MXIC 25L3206E part... Digikey and Farnell both have it and I have to add it to an existing order to avoid steep shipping costs -maybe a week or so before I can do that. Will get back to you once I get the IC and Mac. Do you receive PMs again, or do I post here?
Thanks -Franco.
Hey tsialex, is there anyway you can PM me? I need help with BootRom, of course if you have time. Thanks