MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[tsialex]

Hi, i do not own a MacPro, i am just curious.
If there is a way to write in non public NVRAM areas, maybe there should be a way to erase these areas?

Sure, it’s possible to erase individual non public variables, but how do you solve the fragmentation?

The FS is already doomed when the multiplication process starts. It was never intended for long term usage like on MP5,1.

Apple knew this, at least around 2012-ish. MP6,1 use a different approach with multiple stores that are addressed differently and don’t suffer with the MP5,1 problems, AFAIK.

The last Mac that don’t yet have a T2, 2019 iMac, has a NVRAM more than 4x the size of MP5,1 and with redundancy, for a similar, if not smaller since it has a lot of less DIMMs/disks/cards to configure, usage of the MP5,1 NVRAM right now

 

[marzer]

Sorry, but this is not an end user job.

One bit misplaced and you have a brick, it’s a job for a firmware engineer that knows about Macs.

I noticed you have offered diagnostic services to others in the past. Are you still available to diagnose/reconstruct firmware? I don't expect this machine to last forever but with the HW upgrades (GPU,BT/WIFI/NVME) I put in, it'd be nice to get 2-3 years before the ROM corruption renders it useless.

 

[paalb]

I’ve also tried the ProperTree method but both end up with Terminal saying that config.plist doesn’t exit, isn’t readable, or is not a regular file.

You need to have the correct path to config.plist when you check if it is valid. One way of doing it: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-29158723

 

[thielsa]

I just updated to Big Sur 11.2 Beta using OpenCore 06.4 on my MacPro 5.1. Worked flawlessly.

 

[Dayo]

there is no hypervisor support, but what is interesting is that the VMM flag still works to enable updates

Did you manage to get to the bottom of this?

 

[startergo]

Did you manage to get to the bottom of this?

This is the check in the distribution file:

Spoiler: distr file

<script>
function InstallationCheck(prefix) {
    var boardIds = ['Mac-9AE82516C7C6B903','Mac-F221BEC8','Mac-031B6874CF7F642A','Mac-112818653D3AABFC','Mac-9394BDF4BF862EE7','Mac-AA95B1DDAB278B95','Mac-CAD6701F7CEA0921','Mac-50619A408DB004DA','Mac-7BA5B2D9E42DDD94','Mac-226CB3C6A851A671','Mac-CFF7D910A743CAAF','Mac-AFD8A9D944EA4843','Mac-27ADBB7B4CEE8E61','Mac-F305150B0C7DEEEF','Mac-35C1E88140C3E6CF','Mac-827FAC58A8FDFA22','Mac-77EB7D7DAF985301','Mac-6FEBD60817C77D8A','Mac-7BA5B2DFE22DDD8C','Mac-827FB448E656EC26','Mac-66E35819EE2D0D05','Mac-2E6FAB96566FE58C','Mac-031AEE4D24BFF0B1','Mac-00BE6ED71E35EB86','Mac-4B7AC7E43945597E','Mac-5A49A77366F81C72','Mac-63001698E7A34814','Mac-937CB26E2E02BB01','Mac-FFE5EF870D7BA81A','Mac-87DCB00F4AD77EEA','Mac-A61BADE1FDAD7B05','Mac-C6F71043CEAA02A6','Mac-4B682C642B45593E','Mac-BE0E8AC46FE800CC','Mac-90BE64C3CB5A9AEB','Mac-3CBD00234E554E41','Mac-66F35F19FE2A0D05','Mac-189A3D4F975D5FFC','Mac-B4831CEBD52A0C4C','Mac-E1008331FDC96864','Mac-FA842E06C61E91C5','Mac-81E3E92DD6088272','Mac-FC02E91DDD3FA6A4','Mac-06F11FD93F0323C5','Mac-06F11F11946D27C5','Mac-6F01561E16C75D06','Mac-F60DEB81FF30ACF6','Mac-473D31EABEB93F9B','Mac-0CFF9C7C2B63DF8D','Mac-1E7E29AD0135F9BC','Mac-9F18E312C5C2BF0B','Mac-E7203C0F68AA0004','Mac-65CE76090165799A','Mac-CF21D135A7D34AA6','Mac-F65AE981FFA204ED','Mac-112B0A653D3AAB9C','Mac-DB15BD556843C820','Mac-27AD2F918AE68F61','Mac-937A206F2EE63C01','Mac-77F17D7DA9285301','Mac-E43C1C25D4880AD6','Mac-BE088AF8C5EB4FA2','Mac-551B86E5744E2388','Mac-564FBA6031E5946A','Mac-A5C67F76ED83108C','Mac-B809C3757DA9BB8D','Mac-5F9802EFE386AA28','Mac-747B1AEFF11738BE','Mac-AF89B6D9451A490B','Mac-EE2EBD4B90B839A8','Mac-42FD25EABCABB274','Mac-7DF2A3B5E5D671ED','Mac-2BD1B31983FE1663','Mac-7DF21CB3ED6977E5','Mac-A369DDC4E67F1C45','Mac-35C5E08120C7EEAF','Mac-C3EC7CD22292981F','Mac-53FDB3D8DB8CA971',];
    var cpuFeatures = system.sysctl( 'machdep.cpu.features' );
    cpuFeatures=cpuFeatures.split(" ");
    for( var i = 0; i &lt; cpuFeatures.length; i++ ){
        if( cpuFeatures[i] == "VMM" ){
            return true;
        }
    }
    var nonSupportedModels = ['MacBookPro4,1','MacPro2,1','Macmini5,2','Macmini5,1','MacBookPro5,1','MacBookPro1,1','MacBookPro5,3','MacBookPro5,2','iMac8,1','MacBookPro5,4','MacBookPro8,1','iMac5,1','iMac11,2','iMac7,1','MacBookAir4,1','MacBookPro3,1','Macmini5,3','MacBookPro1,2','Macmini4,1','iMac9,1','iMac6,1','iMac4,1','Macmini1,1','iMac4,2','MacBookPro2,2','MacBookPro2,1','iMac12,2','MacBook3,1','MacPro3,1','MacBook5,1','MacBook5,2','iMac11,1','iMac10,1','MacBookPro7,1','MacBook2,1','MacPro4,1','MacBookPro6,2','iMac12,1','MacBook1,1','MacBookPro5,5','MacBookPro6,1','Xserve2,1','MacBookAir3,1','MacBookAir3,2','MacBookAir1,1','Xserve3,1','MacBookAir2,1','MacBook7,1','Xserve1,1','Macmini2,1','iMac5,2','MacBookPro8,2','MacBookPro8,3','iMac11,3','MacBook6,1','Macmini3,1','MacBook4,1','MacBookAir4,2','MacPro1,1',];
    var currentModel = system.sysctl('hw.model');
    if (nonSupportedModels.indexOf(currentModel) &gt;= 0) {
        my.result.message = system.localizedString('ERROR_DC35364117');
        my.result.type = 'Fatal';
        return false;
    }
    var boardId = system.ioregistry.fromPath('IOService:/')['board-id'];
    if (boardIds.indexOf(boardId) == -1) {
        my.result.message = system.localizedString('ERROR_DC35364117');
        my.result.type = 'Fatal';
        return false;
    }
    if (system.compareVersions(system.version.ProductVersion, '10.9') &lt; 0) {
        my.result.message = system.localizedStringWithFormat('ERROR_B85E600482', '10.9');
        my.result.type = 'Fatal';
        return false;
    }
    return true;
}
function VolumeCheck(prefix) {
    var myTargetSystemVersion = (my.target.systemVersion || system.files.plistAtPath(my.target.mountpoint + "/System/Library/CoreServices/SystemVersion.plist"));
    return true;
}

You can insert the board-id and remove mac model from the var nonSupportedModels and create the installer with:

open /Applications/macadmin-scripts-master/content/downloads/26/37/001-68446/r1dbqtmf3mtpikjnd04cq31p4jk91dceh8/001-68446.English.dist  -a Installer.app

But it still prompts for an update if you want to install to an APFS volume. I can't figure out where is that check.

 

[Dayo]

The issue we were discussing at that point was specifically only about Hypervisor Support and how VMM appeared to be working although the CPU does not have Hypervisor support.

Your distribution file brings to light that once you tell it you have VMM as a CPU feature, it just accepts this at face value and proceeds. This mean setting the VMM flag will allow updates to proceed on any CPU and does not require Hypervisor Support (Westmere CPU). Confirmed this is the case on a 3,1 and a Mojave update as well.

@cdf said perhaps something was missed when things were being specified and I think this might be it.

Interesting side note is that this is probably how the flashed 4,1 units have been able to use this and had nothing to do with them being flashed. That is, not related to MacPro5,1 firmware.

 

[cdf]

Did you manage to get to the bottom of this?

Well, unless something changed in macOS or OpenCore, I think we may have jumped to the wrong conclusion early on about hypervisor support being a requirement for setting the VMM flag...

 

[joevt]

No, it does not exits, each Mac Pro has it's own BootROM that is unique, but it's possible to create a never booted image tailored for your Mac Pro, exactly the same as the OEM manufacturer did during the production of the backplane, but updated to the current EFI release. Lot's of people on this thread already have it.


NVRAM reset only removes public variables and when the FS is working correctly. SecureBoot, MemoryConfig and lot's of others variables are not public.

A public variable is what you can see with nvram -xp, everything else is what I'm calling non-public ones.

This means any variable that you can see with the dmpstore > dmpstore.txt command in the EFI Shell? Does dmpstore show the secure boot certificates?

Writing any NVRAM variable takes a classic Mac Pro one step closer to being bricked? Like boot-args, sound volume, graphics mode, etc.? I think every time you boot, nvram variables are written (also maybe every sleep). I don't reboot my MacPro3,1 very often or put it to sleep.

While dmpstore can show all the nvram variables, you need a ROM dump to see how they get smeared across NVRAM?

The real problem is the NVRAM data/variables not being erased anymore and the NVRAM volume part of the BootROM accumulating superseded variables over the years to the point that it's full and then it self destructs. SecureBoot just makes this process much faster since the certificates/DBs/PKs occupy so much valuable space inside the NVRAM volume. MP5,1 NVRAM size is tiny for todays standards, it's 1/4 of the size of a 2019 iMac, for example.

You say "not being erased anymore". Does that mean they do get erased up to a point? When does this point occur and is there a way to tell when that point has been crossed?

 

[startergo]

I think we may have jumped to the wrong conclusion early on about hypervisor support being a requirement for setting the VMM flag...

Yes, because we know we can inject the VMM flag (or any other CPU flag as they are artificial flags set by the user, even though some may crash the system) and Catalina Installer is checking for the flag with :

var cpuFeatures = system.sysctl( 'machdep.cpu.features' );
    cpuFeatures=cpuFeatures.split(" ");
    for( var i = 0; i < cpuFeatures.length; i++ ){
        if( cpuFeatures[i] == "VMM" ){
            return true;
        }

When does this point occur

More importantly how to parse that NVRAM junk? Is it only:
binwalk /path/to/file.bin or it needs a --magic nvram signature file?

 

[PeterHolbrook]

Sorry, but this is not an end user job.

One bit misplaced and you have a brick, it’s a job for a firmware engineer that knows about Macs.

Fair enough. I understand I can do the following:

• Somehow read/extract the current contents of my BootROM. I'm afraid I would need instructions to do that.
• Given its current state, if possible, I'd like to be able to assess roughly how long it may be until my BootROM self-bricks.
• Somehow contact a reputable firmware engineer (you, presumably) for him/her to generate a pristine, personalized version of my BootROM.
• Put away the newly generated BootROM for immediate and future use.
• Flash my BootROM with the pristine content it is supposed to have. Again, I would need instructions on how to do that. Or perhaps I should ship my Mac Pro 5,1 somewhere for someone else to do the flashing process? I would hate to do that, as it would defeat the entire process.

 

[tsialex]

This means any variable that you can see with the dmpstore > dmpstore.txt command in the EFI Shell? Does dmpstore show the secure boot certificates?

Never checked this exactly, I'll take a look at it, but remember that what you see is not what is stored on the SPI flash memory.

Writing any NVRAM variable takes a classic Mac Pro one step closer to being bricked? Like boot-args, sound volume, graphics mode, etc.? I think every time you boot, nvram variables are written (also maybe every sleep). I don't reboot my MacPro3,1 very often or put it to sleep.

Let's be clear, I was talking specifically about MP5,1 (and to a less degree MP4,1 since there are several firmware diffs that I'm not addressing) here.

MP3,1 has completely different BootROM structure, the NVRAM is not inside the BootROM container or even the FWB flash memory that stores the BootROM image. MP3,1 has a dedicated SPI, a 8-pin SOJ just around the big FWB on the logic board, it's placed below or very near of the BT card if I remember correctly. A corrupted MP3,1 NVRAM don't affect the BootROM stored on the FWB.

AFAIK, but I maybe be wrong and I'll verify this, MP3,1 don't even caches the SPD inside the NVRAM stores or pre-initialises the memory controller like MP4,1 on wards - I'll confirm this sometime next week since I got my MP3,1 out of storage for a job.

MP3,1 NVRAM is even smaller than the ridiculously tiny MP5,1 one , it's just a 64KB SPI. For sure, NVRAM storage needs at the time were very different. MP1,1/2,1 NVRAM implementation are similar of MP3,1.

Some MP4,1/MP5,1 variables like MemoryConfig are several KB in size (it's not just a cache of the usual 256 bytes of the SPD). When a MP4,1/MP5,1 NVRAM volume is working correctly, a 4-time consecutively NVRAM reset forces a refresh of the NVRAM volume and the MemoryConfig variables are erased with a forced re-initialisation of the memory controller.

The default mode of the firmware is to always use the NVRAM caches/configuration of the DIMMs that is already on the NVRAM - even if you change DIMMs (I've always thought that this behaviour is very weird, I know that it's relatively time consuming to read the SPDs at every boot via SMBUS, but the POST is already too long, why not check the SPDs - maybe there is some specific platform reason for this behaviour that I'm completely missing).

Btw, MemoryConfig variables have different headers for different memory controller channels.

While dmpstore can show all the nvram variables, you need a ROM dump to see how they get smeared across NVRAM?

I'm not sure about this, I don't remember ever seeing MemoryConfig, with any dmpstore and this needs verification.

NVRAM is parsed and presented very differently then what are really stored on the SPI flash. Most times you have a perfect nvram -xp and a completely crazy SPI image. See my next point below.

You say "not being erased anymore". Does that mean they do get erased up to a point? When does this point occur and is there a way to tell when that point has been crossed?

Let me explain the "not being erased anymore", it's an extremely absurd simplification of my part to facilitate understanding of the real problem for the usual MR reader - but you probably deducted that.

While it's obvious that the NVRAM volume is not a normal FS like we see on a HDD/SSD, its not even exactly an usual NOR storage like we usually see with embedded solutions like the common JFFS/JFFS2 implementations (but it's analogous).

The design of the NVRAM 1st and 2nd stores was made in a way to prolong the life of the SPI flash memory, the firmware tries to avoid deletions/re-writes to preserve the NAND cells, and it's relatively complex since it's a 4KB sectored flash memory. It's also a circular log, very similar of JFFS/JFFS2 design here, with the variables at the tail having precedence from the obsolete/superseded ones at the head. There are some form of garbage collection going on, I've observed on several dumps that the second NVRAM store at some point was used as an exact backup of the first and variables are moved to the start of the first one and I can track that this happened, albeit indirectly, observing the serial numbers of the DIMMs. I can elaborate more on this, but not here.

One of the ways the NVRAM stores are refreshed is with the 4-time NVRAM reset procedure, but this works just to a point - Apple implemented persistence for some variables later on (like for some of the MDM settings and the iCloudLock). AFAIK, no MP5,1 NVRAM variable stored on the 1st and 2nd stores has any form of persistence and you can even force the erase the firmware password - obviously talking here about a correctly working NVRAM store and not a corrupted one - but I'm not going to explain this publicly.

It's just my wild guess here, but I have a strong impression that SecureBoot accelerates the NVRAM corruption process changing the way the circular log works, maybe changing it's head (could be that this is related to the massive SecureBoot size, I need to investigate this more and disassemble the EFI module that manages the NVRAM volume to really understand this issue) and thus causing fragmentation.

 

[tsialex]

Fair enough. I understand I can do the following:

• Somehow read/extract the current contents of my BootROM. I'm afraid I would need instructions to do that.

Correct.

• Given its current state, if possible, I'd like to be able to assess roughly how long it may be until my BootROM self-bricks.
• Somehow contact a reputable firmware engineer (you, presumably) for him/her to generate a pristine, personalized version of my BootROM.

I'm trying to follow MR rules here and let's be clear that I'm not advertising any services here. It's probably best if we talk more via PM.

• Put away the newly generated BootROM for immediate and future use.
• Flash my BootROM with the pristine content it is supposed to have. Again, I would need instructions on how to do that. Or perhaps I should ship my Mac Pro 5,1 somewhere for someone else to do the flashing process? I would hate to do that, as it would defeat the entire process.

A very reliable way to overcome the fragmentation and the inevitable corruption of BootROM at some future time is to flash a never booted image from time to time and the process of flashing the reconstructed image is relatively simple and painless. You can do it in ten minutes, just need to power your Mac Pro with the Firmware Programming Mode, flash it, reboot. Since we are on the OC thread, let's be crystal clear that you have to boot vanilla when dumping or flashing the BootROM - I've encountered weird things like stuck NVRAM sectors flashing when OC is running and at least two other people had the same stuck NVRAM sectors.

I test a lot of things even with my main Mac Pro and I developed the habit of flashing my reconstructed image every 90 days. You probably won't need to do that with this regularity/timeframe.

Please note that I had complete SPI failure back in 2018 with my test early-2009 (where everything started) and in 2019 for my mid-2010. Since then I replaced the SPI flash of all my backplanes, even the backups.

 

[tsialex]

More importantly how to parse that NVRAM junk? Is it only:
binwalk /path/to/file.bin or it needs a --magic nvram signature file?

I've elaborated about this before, you have to understand a lot of how the NVRAM works to judge what is going on.

Yes, it's needed a signature file. I'm not going to open source or share my tools at this point, I'll submit it directly to binwalk for inclusion when it's ready. Some of my signatures will never be submitted to binwalk since it could extremely facilitate cloning with people posting the report on line.

 

[cdf]

Yes, because we know we can inject the VMM flag (or any other CPU flag as they are artificial flags set by the user, even though some may crash the system) and Catalina Installer is checking for the flag with :

var cpuFeatures = system.sysctl( 'machdep.cpu.features' );
    cpuFeatures=cpuFeatures.split(" ");
    for( var i = 0; i < cpuFeatures.length; i++ ){
        if( cpuFeatures[i] == "VMM" ){
            return true;
        }

It's more than that. Early on we observed that the VMM flag couldn't be set on certain machines that lack hypervisor support.

 

[tsialex]

It's more than that. Early on we observed that the VMM flag couldn't be set on certain machines that lack hypervisor support.

Yes, I tested it with my dual E5520 tray back then and didn't got it enabled with earlier OC releases. I don't remember if I talked this with you by PM or on the Catalina thread, something changed since then.

 

[Dayo]

It's more than that. Early on we observed that the VMM flag couldn't be set on certain machines that lack hypervisor support.

I suspect that was more of an assumption (understandable) as opposed to an actual finding.

I think a test was done to see whether VMM could be ENABLED on such machines and following a negative result, if was assumed/interpreted as that it could not be SET which is actually subtly different.

Yes, I tested it with my dual E5520 tray back then and didn't got it enabled with earlier OC releases.

Edited to included this before posting. Turns out that while you can't enable it, you can set it. It wouldn't work, but it will be there saying it is present when queried which is enough for the distribution file check.

 

[tsialex]

I suspect that was more of an assumption (understandable) as opposed to an actual finding.

I think a test was done to see whether VMM could not be ENABLED on such machines and following a negative results, if was assumed/interpreted as that it could not be SET which is subtly different.


Edited to included this before posting. Turns out that while you can't enable it, you can set it. It wouldn't work, but it will be there saying it is present when queried which is enough for the distribution file check.

Probably spoof would be more appropriate here then set, but yes, semantics aside, for sure couldn't be enabled.

 

[Dayo]

Probably spoof would be more appropriate here then set, but yes, semantics aside, for sure couldn't be enabled.

Spoofed indeed. Still cannot be enabled on such machines as the capability is not there to start with and nothing has changed on that. Just a wrong test for the purpose ... with hind sight.

 

[tsialex]

Spoofed indeed and still cannot be enabled on such machines as the feature is not there to start with and nothing has changed on that. Just a wrong test for the purpose with hind sight.

If you have time available, please get a lower 0.5.[0-3] or even 0.0.4 release and try to spoof with your MP3,1 + Mojave or High Sierra.

 

[tsialex]

Btw, I've asked moderation to make this thread a stickie, already done, and remove the old NVIDIA FAQ from the stickies, being one is a moot point since High Sierra is not supported anymore and NVIDIA will probably never issue a macOS driver again…

 

[macgirl-mx]

I installed Big Sur on my cMP 4,1>5,1 on a NVME SSD with a cheap PCIE X4 card, OpneCore 0.6.4 from Martin Lo, also have Catalina on a SATA SSD

I blessed and tried to boot from the EFI partition of the NVME SSD card, but it takes the EFI partition from de SATA SSD, and if I erase the contents of the EFI on the SATA SSD the cMP does not boot, it shutdowns after a minute or 2

I tried to unbless the SATA SSD EFI partition, with no success.

Is my cheap adapter not able to boot?

 

[cdf]

I blessed and tried to boot from the EFI partition of the NVME SSD card, but it takes the EFI partition from de SATA SSD, and if I erase the contents of the EFI on the SATA SSD the cMP does not boot, it shutdowns after a minute or 2

I tried to unbless the SATA SSD EFI partition, with no success.

There have been reports of difficulties with OpenCore on NVMe drives, but also note that the EFI partition your NVMe drive cannot be blessed properly if your Mac is already booted through OC with RequestBootVarRouting enabled.

 

[LordeOurMother]

The guide to install Windows included in the sticky seems to install it in the normal EFI mode.

How can I install legacy mode with OC? If this is not possible, I will most likely just not install OC and I'll use one of the various available scripts to pick my boot drive.

 

[startergo]

The guide to install Windows included in the sticky seems to install it in the normal EFI mode.

How can I install legacy mode with OC? If this is not possible, I will most likely just not install OC and I'll use one of the various available scripts to pick my boot drive.

It is not compatible with OC. Only UEFI mode is.