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

[Bmju]

Not at Mac to test right now, but it seems likely/possible, given the conflicting reports, than whether nvram ResetNVRam=1 is allowed within macOS depends on whether the CSR_ALLOW_UNRESTRICTED_NVRAM bit 6 0x40 of SIP flags is set?

 

[Macschrauber]

Not at Mac to test right now, but it seems likely/possible, given the conflicting reports, than whether nvram ResetNVRam=1 is allowed within macOS depends on whether the CSR_ALLOW_UNRESTRICTED_NVRAM bit 6 0x40 of SIP flags is set?

I did my test with Mavericks (pre SIP era):

From Mavericks OS ResetNVRam=1 had no effect
From Mavericks Recovery ResetNVRam=1 forced a deep nvram reset with 2nd stream empty (same as triple nvram reset by alt-cmd-p-r held until 4 chimes)


Today I tested again as I did some Debugging with my Dumper with Monterey

sudo nvram ResetNVRam=1

shut the Mac Pro off

shut the Mac Pro on, it started two times

The only disk I had in was a spinner with OpenCore in the ESP and Monterey, booted directly into Monterey

It worked this time, 2 Memory Configs told that the firmware has been started twice, 2nd VSS store empty told the full NVRAM reset was done.

 

[Dayo]

I did my test with Mavericks (pre SIP era):

From Mavericks OS ResetNVRam=1 had no effect
From Mavericks Recovery ResetNVRam=1 forced a deep nvram reset with 2nd stream empty

Just for clarity, you booted Mavericks directly and didn't go through OpenCore, right?

RefindPlus should be same as booting directly but maybe eliminate that if used to remove any doubts on that aspect.

 

[Bmju]

View attachment 1990264

VOID
OcLoadNvramSupport (
  IN OC_STORAGE_CONTEXT  *Storage,
  IN OC_GLOBAL_CONFIG    *Config
  )
{
  if (Config->Nvram.LegacyEnable && Storage->FileSystem != NULL) {
    OcLoadLegacyNvram (Storage->FileSystem, Config);
  }
  OcDeleteNvram (Config);
  OcAddNvram (Config);
  OcReportVersion (Config);
}

That was meant to be a very abbreviated way of saying: I don't think the existing LegacyEnable/LegacySchema can help. Actually, that conclusion depends on what OcLoadLegacyNvram actually does (e.g. Does it load the plist file and set up a replacement runtime NVRAM service? But it doesn't, it just loads the file and sets permitted variables into the existing NVRAM service).

 

[Bmju]

Just for clarity, you booted Mavericks directly and didn't go through OpenCore, right?

RefindPlus should be same as booting directly but maybe eliminate that if used to remove any doubts on that aspect.

I am more or less certain OpenCore is not preventing these writes. The only NVRAM reads/writes it intercepts are for the boot menu (in order to allow OC to have its own separate boot menu in a different namespace to the machine's own menu, when RequestBootVarRouting is true). I think the SIP explanation (and the reasonable guess of the specific bit which matters) is most likely. Needs someone (me, later?) to test. (Obviously, I'm adding the further guess that these NVRAM writes are prevented unconditionally on Mavericks, even when run with sudo - maybe that's unlikely, not sure.)

 

[Dayo]

Needs me to test

Thanks for volunteering!

 

[Macschrauber]

Just for clarity, you booted Mavericks directly and didn't go through OpenCore, right?

RefindPlus should be same as booting directly but maybe eliminate that if used to remove any doubts on that aspect.

yes, directly, was a pretty basic MP5.1 with Stock HD5770. So no need for a bootloader at this stage.

 

[Bmju]

What about macOS Big Sur?

I know it's somewhat off-topic, but my lack of in-depth knowledge about OpenCore leads me to wondering why MacPro3,1/4,1/5,1 users aren't taking advantage of OpenCore's emulated NVRAM feature to avoid any writes to physical NVRAM other than what's absolutely necessary? I assume there's a good reason preventing this since no popular OC on CMP solution enables it.

I looked a bit more. @zzzippp you're referring to https://dortania.github.io/OpenCore...ml#enabling-emulated-nvram-with-a-nvram-plist (same thing as in OC Configuration.pdf, ofc, but with quite a lot more detail) . From a bit of research so far, and trying to ask around, this is not the full NVRAM emulation solution it sounds like. This is mostly aimed at legacy BIOS Hackintoshes which are using OpenDuet (a UEFI firmware emulation layer than runs under legacy BIOS). I believe that it won't help with solving MacPro NVRAM write problems, because when there is a normal UEFI NVRAM runtime service (as there is on the MacPro), then nothing in this 'emulation' stops that from working. Any full-blown, non-volatile NVRAM writes made in-OS would still be full-blown, non-volatile NVRAM writes. If I've understood correctly, the NVRAM service provided by OpenDuet is always effectively volatile (even if apparently non-volatile; because there is no backing NVRAM), which is what makes this useful there.

 

[Bmju]

Thanks for volunteering!

So I can confirm that on a non-upgraded MacPro 4,1 (MP41.0081.B07) running Lion 10.7.5 (i.e. pre-SIP), then sudo nvram ResetNVRam=1 works from the main OS with or without OpenCore.

It also works fine from the main OS on a MacBookPro10,2 (426.0.0.0.0), running current Big Sur RC 11.6.6 (20G604), with SIP enabled, and with or without OpenCore.

 

[joevt]

As an aside, I found that Monterey can hit the NVRAM more than 30 times on a standard boot up ... with many of them seemingly the same item. Mojave gets up to 20 hits ... so not so much better actually.

What method do you use to count the NVRAM hits?

Might be interesting to dump accesses made by the NVRAM runtime services to serial port. OpenCore has code to output to any serial port (not just built-in COM1) using port mapped IO (like COM1) or MMIO. You can add a serial port PCIe device to a Mac (it might even work from Thunderbolt). Since its EFI, it will work for any OS including Windows. https://github.com/acidanthera/OpenCorePkg/pull/331

I am more or less certain OpenCore is not preventing these writes. The only NVRAM reads/writes it intercepts are for the boot menu (in order to allow OC to have its own separate boot menu in a different namespace to the machine's own menu, when RequestBootVarRouting is true). I think the SIP explanation (and the reasonable guess of the specific bit which matters) is most likely. Needs someone (me, later?) to test. (Obviously, I'm adding the further guess that these NVRAM writes are prevented unconditionally on Mavericks, even when run with sudo - maybe that's unlikely, not sure.)

I think it would be good for OpenCore to prevent writes to NVRAM variables that are set in config.plist. For example, if you set boot-args in config.plist, then OpenCore should prevent write to boot-args since config.plist will override the value anyway on next boot. Also, since the value comes from config.plist, OpenCore shouldn't write the value because it can just have NVRAM runtime services get the value from memory.

 

[tsialex]

Might be interesting to dump accesses made by the NVRAM runtime services to serial port. OpenCore has code to output to any serial port (not just built-in COM1) using port mapped IO (like COM1) or MMIO. You can add a serial port PCIe device to a Mac (it might even work from Thunderbolt). Since its EFI, it will work for any OS including Windows. https://github.com/acidanthera/OpenCorePkg/pull/331

How would it work for EFI NVRAM access during POST, since OC is not loaded yet? Maybe I'm mistaking something, but I don't remember MacPro3,1 to MacPro5,1 to have serial support with the EFI.

 

[Syncretic]

First, a mea culpa - I've revised my earlier post to note that Cmd-Opt-P-R actually does clear RTCRAM; my notes were clear on this, but I managed to overlook that part when I posted.

Btw, Apple used Macronix MX25L3206E with mid-2012s.

That whole family (MX25L3205*, MX25L3206*, MX25L3233*, MX25L3235*) shares the same JEDEC ID, so they all look the same to the Apple EFI.

the regular GC when the 1st stream is nearly full is a complete other thing what leaves vss2 not empty

The regular garbage collection seems to be the only thing that actually uses VSS2; GC is what populates VSS2 in the first place. During GC, VSS2 gets a condensed copy of VSS1, then VSS2 gets copied to VSS1.
The only time the consistency of VSS2 is operationally relevant is when VSS1 has the "Garbage Collection In Progress" bit set at boot time, which indicates that GC got interrupted (normal completion would have reset that bit). If that happens, and VSS2 looks valid, VSS2 will be copied to VSS1. Otherwise, VSS2 will either be ignored, or erased if it looks invalid/corrupted.

While this may be absent in MP51 and/or MP41, I recollect @tsialex finding such a count in the MP31 BootROM.

(sigh) One more thing added to the seemingly endless pile of stuff I'd eventually like to look into...

---

Another fun(?) fact: the command-line program nvram has a hidden feature: nvram -s will forcibly sync the NVRAM cache to the actual NVRAM. (99% of the time, you won't really care about this, but when you do, it's nice to know.)

---

I've thrown together a quick-and-dirty command-line program to offer a deeper look at the NVRAM variables. It uses the memory-mapped copy of the NVRAM, therefore it requires DirectHW.kext to be loaded (not included here; I'd expect any flavor of DirectHW.kext to work, including the one bundled with FlashROM). This program looks at the raw data, does a quick analysis of the headers for validity, and displays all of the variables (including deleted ones, and from all GUIDs). Optionally, you can display the variable values (as a hex dump), the VSS and variable header raw values, the raw variable GUIDs, etc. At the end of each VSS, it displays statistics (total number of variables found, number of deleted variables found, free space available, dead space that can be reclaimed when GC eventually runs, etc.). See attached (use scanvss -h to display valid options; since it uses DirectHW.kext, you may need to run it with sudo). The output isn't particularly pretty (n.b. "quick-and-dirty"), but I think it's interesting nonetheless. (This has only been tested on Mac Pro, ROM 144.0.0.0.0; it may or may not work on other Macs or other ROM versions. It's read-only, so it's not going to make a mess of anything; if your ROM is sufficiently different, the output will just be nonsensical.)

Because it uses the memory-mapped copy of the NVRAM, it's displaying a snapshot of the VSS the last time Boot Services exited (either at boot time or when waking from S3 sleep). That means if you run it, save the stats, then add or delete some variables and run it again, you probably won't see any changes until you either reboot or put the Mac completely to sleep and wake it up again.

If I ever decide to finish this program, I'll try to find a way to use the "live" copy of the NVRAM, add a feature to (optionally) fill the VSS just past the GC threshold (so that the next reboot will force GC), and I'll also try to remove the DirectHW.kext dependency.

(Current versions attached: v0.14 uses fixed offsets for parsing. v0.17 actually parses the FFV to locate the VSS records instead of making MacPro-specific assumptions. It also allows parsing individually extracted FFV files instead of requiring a complete ROM dump. This should work on more Macs than just the Mac Pro. It also handles the case where only one VSS is present (such as Mac Pro 3,1). Because its internals are significantly different, I've left both v0.14 and v0.17 attached to this message; use whichever one best suits your needs. Hopefully, the v0.14 branch will be completely replaced by the newer methodology, but only time will tell. v0.17 has also been tested on Mac Pro 3,1 (both "live" NVRAM and file dumps).)

 

[joevt]

How would it work for EFI NVRAM access during POST, since OC is not loaded yet? Maybe I'm mistaking something, but I don't remember MacPro3,1 to MacPro5,1 to have serial support with the EFI.

It would work for the OS, not EFI. If you load it with Driver#### then it would work for the Apple Startup Manager or the boot loader (OpenCore, RefindPlus, etc.)
You can add a serial port PCIe card. If you add a serial driver, then you can redirect EFI console output to serial also.
https://github.com/acidanthera/bugtracker/issues/1954

 

[Dayo]

What method do you use to count the NVRAM hits?

I wrapped RunTime->SetVariable and logged access to it on boot in RefindPlus.

 

[Dayo]

So I can confirm that on a non-upgraded MacPro 4,1 (MP41.0081.B07) running Lion 10.7.5 (i.e. pre-SIP), then sudo nvram ResetNVRam=1 works from the main OS with or without OpenCore.

It also works fine from the main OS on a MacBookPro10,2 (426.0.0.0.0), running current Big Sur RC 11.6.6 (20G604), with SIP enabled, and with or without OpenCore.

Can @Bmju advance an hypothesis on the difference with the earlier MP51/Mavericks outcome or can @Macschrauber review his test to make sure everything was ship shape?

 

[Bmju]

Okay, going full noob here. How would I go about dumping my existing ROM from unupgraded MacPro4,1 (MP41.0081.B07) on MacOS X Lion 10.7.5?

I've tried ROMTool as linked by @tsialex here ("Could not detect you system's EEPROM type. The operation cannot proceed."; I've tried building and installing DirectHW.kext as suggested by @startergo here (no change); I've tried to see if I can get a dump with @Macschrauber's tool here (I think it only supports Big Sur and Mavericks? ""detected Mac Pro 2009" doesn't understand the <<event sysonotf>> message"; I've also just tried @Syncretic's new tool here (Segmentation fault: 11).

Are any of these even supposed to work on such an old OS & ROM? Not sure! (Though I have some hope that ROMTool should?) Anyway, any suggestions as to how I should dump/examine the state of my ROM before doing any upgrades?

 

[Bmju]

Can @Bmju advance an hypothesis on the difference with the earlier MP51/Mavericks outcome or can @Macschrauber review his test to make sure everything was ship shape?

The only hypothesis I can very tentatively advance for @Dayo's consideration is the same as what @Syncretic said: maybe the NVRAM is so borked in some of these MacPro's that you have to try reset several times before it works.

If the observation truly is that ResetNVRam reliably works from Recovery and reliably does not work from main OS on those machines, then I have no hypothesis.

It might be worth testing read nvram -p ¦ grep ResetNVRam after write just to confirm the var is getting set. Maybe even using @Syncretic's new nvram -s before the read, to try to see the true state of the NVRAM? But I'm not really sure if these would help.

 

[Dayo]

One more thing added to the seemingly endless pile of stuff I'd eventually like to look into...

To add to your list, I presume MP31 must behave quite a bit differently as it apparently only has one (1) VSS.
I suppose it must copy the valid stuff to RAM, clear the store and write them back without a second VSS "safety net" the others have

 

[joevt]

I wrapped RunTime->SetVariable and logged access to it on boot in RefindPlus.

What kind of logging? If the wrap is EFI, shouldn't it go away at ExitBootServices time? Or did you log to something that's available to EFI after ExitBootServices (such as ram or nvram) instead of a file? Or did you do a kernel patch?

 

[Dayo]

What kind of logging? If the wrap is EFI, shouldn't it go away at ExitBootServices time?

If the wrap is discarded on ExitBootServices, it simply means it logged the calls up to that point. As ExitBootServices is called when the boot phase is completed, the wrapped function would have covered what was hit during booting as was intended.

AFAIK though, RunTime functions keep running post ExitBootServices.

According to the CIA Hacking Tools Reveal on WikiLeaks...

When ExitBootServices is called by the OS loader, the firmware gives control of the system to the loader.
All of the boot service memory is reclaimed, the boot services are all terminated,
and the OS loader can hand over control of the system to the OS.
At this point, only the runtime services provided by the firmware are still accessible.

I believe this is the same thing mentioned here:

NVRAM access is an EFI Runtime service. This means that the EFI code that loads at boot time stays resident and handles NVRAM requests even after the OS (e.g. MacOS) has loaded.

EDIT 1:
Could be that wrapped items still get dumped regardless but I doubt it given the above and also that from looking at OpenCore code, they take specific steps to revert misc wrapped items when ExitBootServices is called. I actually want to implement something similar in RefindPlus.

EDIT 2:

did you log to something that's available to EFI after ExitBootServices instead of a file?

I see you might have specifically meant the actual physical logging continuing. Well, this was just a file and if logging got cut off on ExitBootServices, then it would have stopped at boot completion in that case.

 

[Bmju]

AFAIK though, RunTime functions keep running post ExitBootServices

Definitely correct. OpenCore RequestBootVarRouting - the option to keep OC boot menu entries separate from the main BIOS boot menu - works by redirecting the same runtime services call; so that, e.g. if an OS update sets a particular installer location as BootNext, then this will be stored in OC's boot menu (because of the redirect), so OC will start (BIOS boot menu), followed by the correct next stage of the update (OC boot menu).

 

[Dayo]

On re-reading the query, it seems @joevt meant the actual logging to a file. Not sure whether this does indeed get cut off at that point or not.

I suppose it would have logged the hits up to that point if it does and it would have still got a boot up time hit count regardless.

 

[Macschrauber]

Okay, going full noob here. How would I go about dumping my existing ROM from unupgraded MacPro4,1 (MP41.0081.B07) on MacOS X Lion 10.7.5?

I've tried to see if I can get a dump with @Macschrauber's tool here (I think it only supports Big Sur and Mavericks? ""detected Mac Pro 2009" doesn't understand the <<event sysonotf>> message"

it works from Mavericks (where it has a special app for) to Monterey.
Only Yosemite does not work with directhw.kext.
It has also a working directhw.kext in what it loads and unloads dynamically.

never seen your error, guess that has to do with notifications.

 

[startergo]

Okay, going full noob here. How would I go about dumping my existing ROM from unupgraded MacPro4,1 (MP41.0081.B07) on MacOS X Lion 10.7.5?

I've tried ROMTool as linked by @tsialex here ("Could not detect you system's EEPROM type. The operation cannot proceed."; I've tried building and installing DirectHW.kext as suggested by @startergo here (no change); I've tried to see if I can get a dump with @Macschrauber's tool here (I think it only supports Big Sur and Mavericks? ""detected Mac Pro 2009" doesn't understand the <<event sysonotf>> message"; I've also just tried @Syncretic's new tool here (Segmentation fault: 11).

Are any of these even supposed to work on such an old OS & ROM? Not sure! (Though I have some hope that ROMTool should?) Anyway, any suggestions as to how I should dump/examine the state of my ROM before doing any upgrades?

One thing to check is if there are multiple instances of DirectHW.kext approved and loaded in the system. Unload and Delete all separate instances of the kext. This kext was developed by coresystems and was blocked by Apple with it's default identifier. @dosdude1 version for instance has a modified identifier:com.doresystems.driver.DirectHW rather than com.coresystems.driver.DirectHW which bypasses the XProtect. If you are building it from source modify the identifier similarly.
For troubleshooting purposes run RomTool from terminal as super user:

sudo /Volumes/CATALINAOWC/Users/g5/Downloads/ROMTool.app/Contents/MacOS/ROMTool
Password:
Executing: /usr/bin/kmutil load -p /var/root/Library/Application Support/ROMTool/DirectHW.kext
Mapping low megabyte at 0x0000000000000400, unaligned size 0xffc00.
Mapping low megabyte, 0xffc00 bytes at unaligned 0x0000000000000400.
sh: dmidecode: command not found
dmidecode execution unsuccessful - continuing without DMI info
WARNING: No chipset found. Flash detection will most likely fail.
2022-04-13 07:03:45.460 ROMTool[787:8115] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSCFConstantString substringToIndex:]: Index 18446744073709551615 out of bounds; string length 0'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007ff814ebc1e3 __exceptionPreprocess + 242
    1   libobjc.A.dylib                     0x00007ff814c1cc13 objc_exception_throw + 48
    2   Foundation                          0x00007ff815c62127 -[NSString substringToIndex:] + 174
    3   ROMTool                             0x0000000100002c97 ROMTool + 11415
    4   ROMTool                             0x000000010000321b ROMTool + 12827
    5   libdispatch.dylib                   0x00007ff814bbe0cc _dispatch_call_block_and_release + 12
    6   libdispatch.dylib                   0x00007ff814bbf317 _dispatch_client_callout + 8
    7   libdispatch.dylib                   0x00007ff814bc19fc _dispatch_queue_override_invoke + 787
    8   libdispatch.dylib                   0x00007ff814bceac2 _dispatch_root_queue_drain + 343
    9   libdispatch.dylib                   0x00007ff814bcf25c _dispatch_worker_thread2 + 160
    10  libsystem_pthread.dylib             0x00007ff814d76f8a _pthread_wqthread + 256
    11  libsystem_pthread.dylib             0x00007ff814d75f57 start_wqthread + 15
)
libc++abi: terminating with uncaught exception of type NSException
zsh: abort      sudo
x299@x299s-iMac-Pro ~ % sudo su
sh-3.2# cd /var/root/Library/Application Support/
sh: cd: /var/root/Library/Application: No such file or directory
sh-3.2# cd /var/root/Library/Application\ Support/
sh-3.2# pwd
/var/root/Library/Application Support

For instance the above log is on my hack where it fails to find the chip. As you can see you can load DirectHW.kext with:

sudo /usr/bin/kmutil load -p /var/root/Library/Application\ Support/ROMTool/DirectHW.kext

SIP of course must be disabled (for systems newer than Mavericks, which is the last OS you can modify NVRAM variables directly from terminal without reboot).

Here is the terminal log from @Syncretic tool:

sudo /usr/bin/kmutil load -p /var/root/Library/Application\ Support/ROMTool/DirectHW.kext
x299@x299s-iMac-Pro ~ % sudo /Users/x299/Downloads/scanvss

------------------
VSS1 (INVALID SIGNATURE) (UNKNOWN FORMAT) (UNKNOWN HEALTH)
------------------
zsh: segmentation fault  sudo /Users/x299/Downloads/scanvss

Edit: I am not sure when kmutil was added if it is missing try kextload.

 

[joevt]

On re-reading the query, it seems @joevt meant the actual logging to a file. Not sure whether this does indeed get cut off at that point or not.

I suppose it would have logged the hits up to that point if it does and it would have still got a boot up time hit count regardless.

boot up time hit count would include whatever boot.efi does but probably not xnu kernel.
If your wrapped runtime services code is in RefindPlus binary and RefindPlus isn't marked as runtime, then the code would disappear? OpenCore puts its runtime efi code in a separate driver for this purpose?
I wonder how ExitBootServices works so your runtime wrap doesn't cause a crash while trying to do file I/O...