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

alphascorp · Apr 19, 2022

tsialex said:
The most probable explanation is that the payload for the updates forced the garbage collection to run.

Yes, this is the most logical explanation.
Have you ever seen something similar happen?

tsialex · Apr 19, 2022

alphascorp said:
Yes, this is the most logical explanation.
Have you ever seen something similar happen?

This is exactly the expected/normal behavior.

What is wrong is when the garbage collection fails and you have a boot loop or a corrupt NVRAM volume, something that is becoming common since software updates NVRAM payload size increased significantly with Big Sur and even more with 12.3+.

alphascorp · Apr 19, 2022

tsialex said:
This is exactly the expected/normal behavior.

What is wrong is when the garbage collection fails and you have a boot loop or a corrupt NVRAM volume, something that is becoming common since software updates NVRAM payload size increased significantly with Big Sur and even more with 12.3+.

OK, thank you @tsialex for those clarifications.

tsialex · Apr 19, 2022

alphascorp said:
OK, thank you @tsialex for those clarifications.

Btw, it's becoming common, but there are threads here of MacPro5,1 bricking after software updates or OS installs since at least High Sierra and that's why you shouldn't have a too low available space. If after a deep NVRAM reset (you can also start with a sudo nvram ResetNVRam=1) you still around low 20's, you'll need a reconstruction service.

Mac Pro 4.1 > 5.1 bricked by High Sierra security update?

Hi all, need some advice please for a semi-literate/just enough to be dangerous cMP user. It’s a 12 core 3.33GHz with 96GB RAM and GT120 running, or was running, High Sierra. I bought the 4.1>5.1 cMP in Feb 2016 already flashed and can’t remember the OS it came with (possibly may have...

forums.macrumors.com

High Sierra Install Bricked My 4,1 That I had Flashed to 5,1

My early 2009 Mac Pro that was running 10.12 for months without issues, bricked after trying to install 10.13 (I know, I was stupid to update). I downloaded High Sierra and the first thing it did in the installation is updated the flash. The update went ok and it rebooted fine. It then...

forums.macrumors.com

719c6 · Apr 20, 2022

TrumanLA said:
- Serialize an MLB to match the system SN

Is there a CRC32 for the MLB?

tsialex · Apr 20, 2022

719c6 said:
Is there a CRC32 for the MLB?

OpenCorePkg/Utilities/macserial/FORMAT.md at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

Dayo · Apr 20, 2022

*EDIT*
The variable name filter used was wrong and misidentified variables as image security database items when they were not. They were some other variables being written on boot.

It appears that Monterey saves some form of UEFI SecureBoot Infrastructure to the NVRAM when booting.

RefindPlus Log Extract of Boot Time NVRAM Writes:

Code:

   9:344    0:019  Running Child Image via Loader File:- 'boot.efi'
   9:381    0:036  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:395    0:013  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:409    0:014  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:423    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:437    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:451    0:013  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:466    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:481    0:015  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:495    0:013  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:510    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:527    0:017  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:542    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:556    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:570    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:585    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:599    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'

Might be the same with Big Sur

719c6 · Apr 21, 2022

tsialex said:
OpenCorePkg/Utilities/macserial/FORMAT.md at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

Are the MAC IDs present in the ROM?

tsialex · Apr 21, 2022

719c6 said:
Are the MAC IDs present in the ROM?

MP5,1: BootROM thread | 144.0.0.0.0

This is a work in progress These identifiers are used by Apple to fully identify and validate your Mac, without them you can't login with iCloud/iMessage/FaceTime. Identifier:Definition: SSNSystem Serial Number HWCHardware Code SONSystem/Sales Order Number LBSN/MLB SNMain Logic Board Serial...

forums.macrumors.com

joevt · Apr 21, 2022

Dayo said:

It appears that Monterey saves some form of UEFI SecureBoot Infrastructure to the NVRAM when booting.

RefindPlus Log Extract of Boot Time NVRAM Writes:

Code:

   9:344    0:019  Running Child Image via Loader File:- 'boot.efi'
   9:381    0:036  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:395    0:013  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:409    0:014  In Hardware NVRAM ...     Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:423    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:437    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:451    0:013  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:466    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:481    0:015  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:495    0:013  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:510    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:527    0:017  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:542    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:556    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:570    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:585    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'
   9:599    0:014  In Hardware NVRAM ...       Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE'

Might be the same with Big Sur

What size are those EFI_IMAGE_SECURITY_DATABASE? The log should include that info. Also, what flags? If they're not "NV" then it doesn't matter.

Dayo · Apr 22, 2022

joevt said:
What size are those EFI_IMAGE_SECURITY_DATABASE? The log should include that info. Also, what flags? If they're not "NV" then it doesn't matter.

Size and persistence information would indeed be enlightening. I have dismantled the boot time logging infrastruture as I decided to move on from that curiosity but I could roll it back in later to see what gives.

This should give an idea of the likely size in the interim:

edk2/MdePkg/Include/Guid/ImageAuthentication.h at 2306555bf9081ae9979405f96428738807e580d4 · tianocore/edk2

EDK II. Contribute to tianocore/edk2 development by creating an account on GitHub.

github.com

I'll guess each packed entry appearance is 1024 bytes or 2048 bytes perhaps.

Dayo · Apr 22, 2022

Dayo said:
I'll guess each packed entry appearance is 1024 bytes or 2048 bytes perhaps.

Thinking out loud on the above, if it is indeed writing upwards of 10kb to the NVRAM with a NonVolatile flag, I wonder whether it would be possible/desirable to change the flag to Volatile to pipe it to the RAM instead?

On the flip side, I suppose once it is written once, subsequent write attempts will return Success but nothing actually happens. Even with that however, GC will always happen faster because of that lump of data sitting there .... assuming it is NonVolatile in the first place.

Depends on being correct on the size. Will try to get this later.

joevt · Apr 22, 2022

Dayo said:
Thinking out loud on the above, if it is indeed writing upwards of 10kb to the NVRAM with a NonVolatile flag, I wonder whether it would be possible/desirable to change the flag to Volatile to pipe it to the RAM instead?

Or use your own ram storage method. You don't always have to call the original NVRAM storage routine.

Dayo said:
On the flip side, I suppose once it is written once, subsequent write attempts will return Success but nothing actually happens.

Your NVRAM code could check the existing value and report if the new value is different.

Dayo · Apr 22, 2022

joevt said:
Or use your own ram storage method. You don't always have to call the original NVRAM storage routine.

Well, such calls can always be filtered and handed as wanted in a SetVariable hook. Should be implemented in OpenCore as only relevant on unsupported units and a hook is already in place.

Will deal with filtering APPL,PanicInfo stuff first. Can perhaps extend the changes to include this item later.

Dayo · Apr 22, 2022

*EDIT*
The variable name filter used was wrong and misidentified variables as image security database items when they were not. They were some other variables being written on boot.

Seems to be with a Volatile flag and of relatively small size:

Code:

 Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  0 bytes  ***  Persistent: FALSE'
 Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  0 bytes  ***  Persistent: FALSE'
 Not Found When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  0 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  8 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  4 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  4 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  4 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size: 16 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size: 16 bytes  ***  Persistent: FALSE'
   Success When Setting Variable:- 'EFI_IMAGE_SECURITY_DATABASE  ****  Size:  1 bytes  ***  Persistent: FALSE'

Dayo · Apr 23, 2022

Syncretic said:
I'll add a feature to (optionally) fill the VSS just past the GC threshold (so that the next reboot will force GC)

EDK II appears to have a built in function to reclaim NVRAM space:

edk2/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c at 96e1d337e0109d970282de71181a5cc317876829 · tianocore/edk2

EDK II. Contribute to tianocore/edk2 development by creating an account on GitHub.

github.com

Two gotchas...

Legacy Macs are on EFI 1.x which do not have QueryVariableInfo to get the NVRAM details, especially the RemainingVariableStorageSize output. Also, we found a while ago that some other Mac model that did have UEFI 2.x, I think it was the 2018 Mac Mini, did not have QueryVariableInfo either. It's as if Apple took pains to remove it since it should be available in UEFI 2.x.
- I suppose this absence might only be relevant on something like RefindPlus and not affect your tool which can presumably get the information by other means
- Looking at that EDK II file further though, it looks like it might be possible to emulatte QueryVariableInfo by calling the VariableServiceQueryVariableInfo function.
RemainingVariableStorageSize itself might not be something to 100% rely on. At least according to some article I was reading from someone trying to manage GC on some Samsung device that was getting bricked due to NVRAM overruns.

All in all, it seems better to just set ResetNVRam=1 and reboot.

m0bil · Apr 28, 2022

Syncretic said:
My guess would be that a hack would not map the (virtual) BootROM the same way a real Mac does, meaning that scanvss is unlikely to ever work on a Hackintosh (sorry!). It may or may not work on non-Pro Macs; someone else would need to test that.

Testing this on an iMac 12,2 from 2011.

Using version 0.14 I get:

Code:

-- Parsing VSS from file 'iMac27Lab.rom' instead of local flash.

----------------
Signature: ffffffff (INVALID!)
Size:      ffffffff (-1)
Format:    ff (UNKNOWN!)
State:     ff (UNKNOWN!)
Unk16[0]:  ff (Garbage Collection In Progress)
Unk16[1]:  ff
Unk32:     ffffffff
----------------
(VSS1 variable area is empty!)
---
Free space appears to be correctly formatted and valid.
Total space in VSS1: -1 bytes
Total space used by variables (and VSS header): 16 bytes
Apparent free space in VSS1: 65448 bytes
Found 0 variables (0 valid, 0 deleted)
Reclaimable dead space (deleted variables): 0 bytes

----------------
Signature: ffffffff (INVALID!)
Size:      ffffffff (-1)
Format:    ff (UNKNOWN!)
State:     ff (UNKNOWN!)
Unk16[0]:  ff (Garbage Collection In Progress)
Unk16[1]:  ff
Unk32:     ffffffff
----------------
(VSS2 variable area is empty!)
---
Free space appears to be correctly formatted and valid.
Total space in VSS2: -1 bytes
Total space used by variables (and VSS header): 16 bytes
Apparent free space in VSS2: 65448 bytes
Found 0 variables (0 valid, 0 deleted)
Reclaimable dead space (deleted variables): 0 bytes

Using version 0.17 on full rom dump I get "iMac27Lab.rom does not appear to be a valid Mac BootROM dump"

But, extracting EfiSystemNvDataGuid (FFF12B8D-7696-4C8B-A985-2747075B4F50)
volume from bootrom with UEFITool, and using version 0.17 on the extracted volume it works just fine!

thibsweb · Apr 28, 2022

Thanks so much for all this useful info. So I checked my early macpro 2009 (bought early march 2009) flashed to 5.1 and using 144.0.0.0 and Legacy Mojave. It is a single CPU W3690 with 3x16GB RDIMMS. My first VSS store shows 44537 free space after deep nvram reset.

@tsialex, do you confirm this means ROM is still healthy ?

thanks so much

tsialex · Apr 28, 2022

thibsweb said:
Thanks so much for all this useful info. So I checked my early macpro 2009 (bought early march 2009) flashed to 5.1 and using 144.0.0.0 and Legacy Mojave. It is a single CPU W3690 with 3x16GB RDIMMS. My first VSS store shows 44537 free space after deep nvram reset.

@tsialex, do you confirm this means ROM is still healthy ?

thanks so much

The mix and match of MP4,1 and MP5,1 components inside the BootROM image of a cross-flashed early-2009 is a disaster waiting to happen. Not one cross-flashed early-2009 BootROM image is really healthy, even if the VSS store is marked as healthy in the ZeroVector.

Early made early-2009 also have very buggy hardware descriptors (base_16 to base_19, if you bought back in March should be base_16 or base_17).

thibsweb · Apr 28, 2022

tsialex said:
The mix and match of MP4,1 and MP5,1 components inside the BootROM image of a cross-flashed early-2009 is a disaster waiting to happen. Not one cross-flashed early-2009 BootROM image is really healthy, even if the VSS store is marked as healthy in the ZeroVector.

Early made early-2009 also have very buggy hardware descriptors (base_16 to base_19, if you bought back in March should be base_16 or base_17).

Thanks for the quick answer. Can this be cleaned up and optimised with your services, or is it useless at this point ?

tsialex · Apr 28, 2022

thibsweb said:
Thanks for the quick answer. Can this be cleaned up and optimised with your services, or is it useless at this point ?

Sure, I can upgrade everything inside the BootROM to the most recent components:

upgrade the MLB sector correctly,
upgrade the NVRAM volume to same one from 144.0.0.0.0,
upgrade the hardware descriptor to the base_21 version,
upgrade the Fsys store to the same one (0x0d version) sent with the mid-2012s made right before the end of production,
upgrade the BootBlock to AAPLEFI1.88Z.0005.I00.1904121247.

thibsweb · Apr 30, 2022

tsialex said:
Sure, I can upgrade everything inside the BootROM to the most recent components:

upgrade the MLB sector correctly,

upgrade the NVRAM volume to same one from 144.0.0.0.0,

upgrade the hardware descriptor to the base_21 version,

upgrade the Fsys store to the same one (0x0d version) sent with the mid-2012s made right before the end of production,

upgrade the BootBlock to AAPLEFI1.88Z.0005.I00.1904121247.

Just to report that I had my BootROM reconstructed and that on top the fact it is nice to have a perfect working and clean NVRAM and a never booted ROM to use in case of problems, I can see immediate changes :

I can now hear at times some fans I almost never heard outside of heavy processing tasks or flight sim/gaming;
my CPU runs about 8°C cooler;
my Northbrige runs about 5°C cooler;
startup sequence duration between power on and startup chime sound is a bit reduced by approx 2 seconds.

EvilMonk · Apr 30, 2022

I’m going to be needing your services @tsialex please if you can find some time. I have more work I need from you since I’ll get my Mac Pro 2009 and 2012 Rom done. I had to put my Mac Pro 2009 serial number on the 2012 when I blew up my backplane board, I couldn’t find the serial number of my 2012 Mac Pro to write with the Apple Service Disk back when it happened, the sticker on the tower is stripped off in half, I remembered later it’s on the Mac Pro product box. I don’t know if we could fix that when doing the rom?)
Thank you ?

tsialex · Apr 30, 2022

EvilMonk said:
I’m going to be needing your services @tsialex please if you can find some time. I have more work I need from you since I’ll get my Mac Pro 2009 and 2012 Rom done. I had to put my Mac Pro 2009 serial number on the 2012 when I blew up my backplane board, I couldn’t find the serial number of my 2012 Mac Pro to write with the Apple Service Disk back when it happened, the sticker on the tower is stripped off in half, I remembered later it’s on the Mac Pro product box. I don’t know if we could fix that when doing the rom?)
Thank you 😊

Seems I'll have some threads to untangle

Get everything that you have and I'll try my best to go back to the original hardwareIDs.

tsialex · Apr 30, 2022

thibsweb said:
Just to report that I had my BootROM reconstructed and that on top the fact it is nice to have a perfect working and clean NVRAM and a never booted ROM to use in case of problems, I can see immediate changes :

I can now hear at times some fans I almost never heard outside of heavy processing tasks or flight sim/gaming;

my CPU runs about 8°C cooler;

my Northbrige runs about 5°C cooler;

startup sequence duration between power on and startup chime sound is a bit reduced by approx 2 seconds.

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…

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

macrumors 6502

Contributor

macrumors 6502

Contributor

macrumors member

Contributor

macrumors 68020

macrumors member

Contributor

macrumors 604

macrumors 68020

macrumors 68020

macrumors 604

macrumors 68020

macrumors 68020

macrumors 68020

macrumors 6502

macrumors newbie

Contributor

macrumors newbie

Contributor

macrumors newbie

macrumors 6502

Contributor

Contributor

Our Staff