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

[ammoune78]

In my side, here's the Output log of my firmware, using @Macschrauber cMP ROM NVRAM Test:

2009=>5.1
Firmware 144.0.0.0 (latest)
Bootblock of 144.0.0.0 - rebuilt Firmware
Boot0001 is EFI\OC\OpenCore.efi
15 + 3 Memory Configs (ok)
0 + 0 xml (ok)
0 + 0 iCloud Tokkens (ok)
0 + 0 Microsoft Certificates (ok)
0 + 0 BluetoothActiveControllerInfos (ok)
0 + 0 BluetoothInternalControllerInfos (ok)
1 + 1 current-network (ok)
1 + 1 AAPL Path Properties (ok)
27200 Bytes free space of 65472

As i can see, and after just two four days from flashing Reconstructed ROM, "My cMP issadly at the edge of the cliff" following the 27200. But it received the last update before yesterday, and installed it.

My question is, would it be smarter by using Catalina rather than Monterey?

Even those, a flashing with reconstructed BootRom needs every 3 months, or after checking the NVRAM, for another possible edge comming?

 

[Dayo]

This is the signature

@tsialex/@Macschrauber ... Do these (Types A & B) have other stuff that can help in identifying them in the NVRAM as I am thinking it could be possible to block them, similar to how the Windows Certificates are blocked.

What might be useful is one or more of the following:

• A unique GUID for these items
  • For instance, Certs have GUIDs that match what type of Cert they are and they are stored in the NVRAM under this GUID
• A unique naming pattern
• Any other unique characteristics that could be used to filter a payload when the NVRAM write is triggered

 

[ammoune78]

I've changed just now the spoofing from MP7,1 to iMP1,1, made a dump after reboot, and ran BootRom test again, and got frustrating 16640 Size

I'm going to make a downgrade to Catalina, just to be in safe-mode

 

[Dayo]

got frustrating 16640 Size

Having a 16640 size is nothing unusual by itself.

The available size in the NVRAM keeps reducing until it gets to a certain very low value, sometimes as low as 2000 bytes, then garbage collection kicks in, space is freed and the cycle starts all over.

This is the way the NVRAM works and just grabbing the size at some random point in the cycle is useless.

Such a size is only indicative of issues if you observe this immediately after garbage collection has run. You therefore need to force garbage collection by executing a triple NVRAM reset (at least 4 chimes) and check a dump taken after this.

 

[ammoune78]

You therefore need to force garbage collection by executing a triple NVRAM reset (at least 4 chimes) and check a dump taken after this.

And fortunately, this is what i did before i saw your reply, 3 successive PRAM and did a test, and that garbage gone. As these Mac Pros have a small ROM chip, therefore not enought room for saving that garbage, make the ROM to explod. Hackintosh's do not have these problems at least. But Monterey cause exessive writing in the NVRAM, that's why i just was about to install Catalina before that PRAM, so at least i can forget NVRAM for a month or 2.

Removed sensitive

 

[tsialex]

@tsialex/@Macschrauber ... Do these (Types A & B) have other stuff that can help in identifying them in the NVRAM as I am thinking it could be possible to block them, similar to how the Windows Certificates are blocked.

What might be useful is one or more of the following:

• A unique GUID for these items
  • For instance, Certs have GUIDs that match what type of Cert they are and they are stored in the NVRAM under this GUID
• A unique naming pattern
• Any other unique characteristics that could be used to filter a payload when the NVRAM write is triggered

I think that you are looking at this issue from the wrong way, this is symptom/adverse effect and not the cause.

What needs to be blocked by OpenCore is the staging of firmware upgrades, not the crashes being saved when the firmware upgrades fail. Blocking the PanicLogs itself will block all other KPs that need to be saved. The real issue is that Apple changed the staging of firmware upgrades with Monterey and that is what we need to address.

 

[ammoune78]

I think that you are looking at this issue from the wrong way, this is symptom/adverse effect and not the cause.

What needs to be blocked by OpenCore is the staging of firmware upgrades, not the crashes being saved when the firmware upgrades fail. Blocking the PanicLogs itself will block all other KPs that need to be saved.

I think the best way is to advise @vit9696 on that particular problem, so at least we don't have to add into the calendar next PRAM resets.

 

[ammoune78]

@tsialex After only one restart from my previous post, i've got 44275. 52101 - 44275 = 7826, so 7826 bytes eaten after one restart is too big, should i have same thing in Big Sur or Catalina? I don't think so!

 

[tsialex]

Until the staging of firmware upgrades are not addressed, this is the safest way to overcome any NVRAM issues before Monterey software upgrades, not just the unwanted firmware upgrades but all the behind the scene interaction with the NVRAM that happens when you do software updates:

• Force a garbage collection, check if your Mac Pro NVRAM available space is at least around 32000 (half the total size of the main VSS store), if not, flash your cleanest dump/reconstructed image.
• Enable VMM spoofing on the OC config.plist.
• Do the Software Update, keeping VMM spoofing enabled until the software updates are complete
• Repeat the first step - force a garbage collection, check if your Mac Pro NVRAM available space is at least around 32000 (half the total size of the main VSS store), if not, flash your cleanest dump/reconstructed image.
• Disable VMM spoofing, you don't want it enabled since you will have issues with power management and Intel SpeedStep/Turbo will be disabled.

 

[tsialex]

@tsialex After only one restart from my previous post, i've got 44275. 52101 - 44275 = 7826, so 7826 bytes eaten after one restart is too big, should i have same thing in Big Sur or Catalina? I don't think so!

I've explained several times in the past that is useless to track the changes in the circular log immediately after forcing a garbage collection, the process takes several reboots to complete/re-populate the entries and the conclusion is after 11 or 12 reboots. You only have meaningful results after a week of normal usage and it's where you should check again.

Even if you do reboot 12 times on a short period of time to try to force the completion of the garbage collection process, like some people that don't understand what is going on suggested in the past, it won't be the real value since you won't have the Bluetooth and iCloud related entries repopulated immediately, for example. There are several entries that depend on remote queries, like iCloud Wi-Fi credentials.

 

[Dayo]

this is symptom/adverse effect and not the cause.

I know that it is dealing with the symptom but relieving symptoms can be a part of treatments, especially in lieu of, or pending, a treatment for the underlying issue. It doesn't have to be "All or Nothing" so to speak.

As for impacts on other stuff, this is why the request for unique elements if present. Knowing if there are any unique characteristics will help with assessing whether this is a viable option that can be done without adverse impacts.

At least let there be a look to see what if anything can be done while those with the chops deal with the full solution. If such is found, a block can be retired as will be redundant.

 

[tsialex]

I know that it is dealing with the symptom but relieving symptoms can be a part of treatments, especially in lieu of, or pending, a treatment for the underlying issue. It doesn't have to be "All or Nothing" so to speak.

As for impacts on other stuff, this is why the request for unique elements if present. Knowing if there are any unique characteristics will help with assessing whether this is a viable option that can be done without adverse impacts.

At least let there be a look to see what if anything can be done while those with the chops deal with the full solution. If such is found, a block can be retired as will be redundant.

Look, I wouldn't disagree with you if we didn't already have any workarounds, but we already have.

Since time is really scarce, we should dedicated it to find ways to address the main issue, blocking the firmware upgrades staging, since using VMM for Software Updates like on Catalina is enough have successful 12.3/12.3.1 upgrades.

 

[tsialex]

Btw, the first beta of 12.4 was just released on the seed channel, let's see the new issues it brings

Edit:

BigSur 11.6.6 beta 1 (20G604) also released.

 

[ammoune78]

I'm thinking about a bigger chip, like a 16 for example, but the problem will be migrating the volumes onto a new EFI ROM image. It's doable on UEFI ROM on PC's, but in Apple EFI i don't know how. If this would work, it will be better, but again the firmware check upon Mac Pro starting is another thing, if i'm not mistaking or dreaming!

 

[tsialex]

I'm thinking about a bigger chip, like a 16 for example, but the problem will be migrating the volumes onto a new EFI ROM image. It's doable on UEFI ROM on PC's, but in Apple EFI i don't know how. If this would work, it will be better, but again the firmware check upon Mac Pro starting is another thing, if i'm not mistaking or dreaming!

This idea again Installing a 64Mb chip won't make any difference, the BootROM is 32Mb and you will only use top-half of the replaced SPI flash, the bottom half will be completely ignored.

Doing this only makes sense if we had the source of EFI to modify it and implement the same mitigations Apple used on newer Macs, like spreading the VSS stores to overcome the NAND contiguous writes like they did with MacPro6,1.

 

[Dayo]

Since time is really scarce, we should dedicated it to find ways to address the main issue

We should, but are you aware of anyone actively working on this or have any suggestions on where such steps should start from?

 

[ammoune78]

This idea again Installing a 64Mb chip won't make any difference, the BootROM is 32Mb and you will only use top-half of the replaced SPI flash, the bottom half will be completely ignored.

Doing this only makes sense if we had the source of EFI to modify it and implement the same mitigations Apple used on newer Macs, like spreading the VSS stores to overcome the NAND contiguous writes like they did with MacPro6,1.

I was meaning by creating a 128Mb ROM image, then migrating all the volumes from the 32Mb Apple BootRom onto the newest 128Mb just created. That way, the nvram problem will be gone. But the problem is in migration process , modules should be migrated by Apple code and not standard UEFI code using windows or Linux.
I was about to do it 2 months ago, and already had steps to do it, from a user that already done that before in Fernando win-raid forums.
I can post a link to that post minutes later cause i'm rolling back to Catalina!

 

[tsialex]

We should, but are you aware of anyone actively working on this or have any suggestions on where such steps should start from?

We can block all the staging of firmware upgrades, more or less what you suggested for the PanicLog.

I want to discover the real cause of the crashes, maybe it's possible to block just it initially and not the whole staging. I've already did several dumps with different stages of the 12.3 software update process, but it's an extremely time consuming since the crashes don't happen 100% of time, sometimes the staging don't fail and crash, and I have to remove the MATT card and dump it externally at each reboot.

 

[tsialex]

I was meaning by creating a 128Mb ROM image, then migrating all the volumes from the 32Mb Apple BootRom onto the newest 128Mb just created. That way, the nvram problem will be gone. But the problem is in migration process , modules should be migrated by Apple code and not standard UEFI code using windows or Linux.
I was about to do it 2 months ago, and already had steps to do it, from a user that already done that before in Fernando win-raid forums.
I can post a link to that post minutes later cause i'm rolling back to Catalina!

That's not the way EFI works. Maybe it can work for some flavor of BIOS/UEFI, but not for the Apple implementation of TIANOCORE.

Btw, seems you are failing to really understand what is the real problem. Even if it was possible with the Apple code base to make the VSS store bigger, won't address the issue of contiguous NAND writes. Look how much changed between MacPro5,1 and MacPro6,1 NVRAM implementation to mitigate the NAND issues.

 

[tsialex]

I was meaning by creating a 128Mb ROM image, then migrating all the volumes from the 32Mb Apple BootRom onto the newest 128Mb just created. That way, the nvram problem will be gone. But the problem is in migration process , modules should be migrated by Apple code and not standard UEFI code using windows or Linux.
I was about to do it 2 months ago, and already had steps to do it, from a user that already done that before in Fernando win-raid forums.
I can post a link to that post minutes later cause i'm rolling back to Catalina!

Btw, how you gonna address the X86 reset vector? How you gonna change the relative address?

 

[ammoune78]

This is what i've said, it's doable on UEFI PC, but on Apple is completely different thing.

But no, i know the problem, since i used hackintosh for many years, and done several things on PC firmwares like Ozmosis, complet acpi modification, and some other things, since it was one of my favorite hobbies. Just to don't confuse me, The HermitCrabs Lab are who made Ozmosis, and this genius OpenCore project is the successor of Ozmosis by vit9696, The HermitCrabs Lab and other genius developers from insanelymac and applelife.ru, they are all old-school. I swear these guys are genius developers, even clover was stuck at big sur because of the runtime implementation by Apple until OpenCore have seen the day, and by the way every bootloader have to use OpenCore quirks in order to boot from big sur to up, unless another genius team appears, but i don't think so.

My problem is i don't want to buy another board just because of nvram, flashing until the chip died or anything else.
Because Macintosh isn't Hackintosh

 

[alphascorp]

Some comments: When using VMM, make sure to have SecureBootModel=Disabled. Also, unless your graphics card gives you the native boot picker or you're using RefindPlus, switching between two instances of OC (rather than two configs) can be tricky (not to mention that proper blessing of OC is crucial for a successful macOS installation). Moreover, if you're concerned about NVRAM corruption, you should verify the health of your firmware chip (follow @tsialex's procedure or use @Macschrauber's tool). And just to be sure, you can also flash a clean BootROM before and after installing macOS.

Thanks @cdf for the quick response,
I have already checked 2 months ago with the procedure of @tsialex



To get a clean BootRom I had read somewhere (but I don't remember where) that I could extract it from the Mojave installer. But I'm a little afraid to brick my cMP with a bad rom because it's a 4.1 flashed to 5.1

EDIT: I found where I had read here, where to find the MP51 rom (Install macOS Mojave.app/Contents/Resources/Firmware), thanks @tsialex

 

[ammoune78]

Here's the post, just to know what i've meant, but, i think Nikolaj schlej, is the one that could help on this scenario

Is a BIOS Region Migration to a bigger sized Chip possible?

Hey guys, I’m wishing to migrate the UEFI bios ROM file from the 128 MXIC MX Chip to a bigger one, so i’m thinking on the 256 to have more room inside, because i need to add some EFI modules insides. Would it be possible? My Motherboard is a GA-Z87X-UD3H that have a duale BIOS chips with a...

www.win-raid.com

 

[tsialex]

Here's the post, just to know what i've meant, but, i think Nikolaj schlej, is the one that could help on this scenario

Is a BIOS Region Migration to a bigger sized Chip possible?

Hey guys, I’m wishing to migrate the UEFI bios ROM file from the 128 MXIC MX Chip to a bigger one, so i’m thinking on the 256 to have more room inside, because i need to add some EFI modules insides. Would it be possible? My Motherboard is a GA-Z87X-UD3H that have a duale BIOS chips with a...

www.win-raid.com

Look, this solves absolutely nothing, if you ever read my previous posts, some weeks ago I've calculated all the non used and contiguous empty areas inside the whole BootROM image - there are around 2MB completely empty and unused TODAY. Even if you successfully address all the issues with relocating the modules and relative addresses for the X86 reset vector, SEC core, the PEI and inside the EFI for a 64Mb SPI flash, the PEI code (and later the EFI) will continue to work with the VSS store as a 64KB segment.

Without the source code to re-implement the VSS store design - if it's even possible with the MacPro5,1 platform, since Apple didn't change the size of the VSS store with MacPro6,1, but used other type of mitigations, like multiple VSS stores inside the NVRAM volume to spread the writes inside the NAND.

 

[cdf]

Thanks @cdf for the quick response,
I have already checked 2 months ago with the procedure of @tsialex

View attachment 1986854

To get a clean BootRom I had read somewhere (but I don't remember where) that I could extract it from the Mojave installer. But I'm a little afraid to brick my cMP with a bad rom because it's a 4.1 flashed to 5.1

If you haven't already, you should back up your BootROM: your chip's free space seems low (hopefully garbage collection still works).

Because your BootROM has identifiers that are unique to your machine, you can't obtain a perfectly functional one from a macOS installer. To get a clean BootROM, I highly recommend purchasing a reconstruction service from @tsialex. His work is top-notch.