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

[Muscovite]

You can also write the EFI files directly to the EFI partition, but you'll have to be extra careful with the Windows bootx64.efi file.

Writing to the empty EFI volume on the target drive? From where? Careful how? Could you please kindly elaborate

 

[osxfr33k]

When a MATT card is installed, it replaces the backplane SPI and all access are routed to it. Any upgrades/dumps are made to/from the MATT card SPI flash.

Just a note, read what I wrote several times in the past, MATT card is not a ready made solution - it makes your Mac Pro bootable again, but then it's a clone of another 2010 Mac Pro and this has several implications, you have to re-flash it with your own cleaned/reconstructed dump.

BTW, BootROM corruption/SPI flash failure will happen to every Mac Pro early2009/mid-2010/mid-2012, the NVRAM volume filesystem is not robust enough for 11 years of heavy usage.

Thanks for the information. I completely agree on how fragile it is but the rest of the bootrom wont get corrupted will it? I asked you this question in another thread that if I could downgrade the bootrom. Well I spent all weekend on that Macpro4,1 and it would only occasional get the chime but still boot to a black screen. So after about the 109th try I was able to get it to boot to the recovery CD and it flashed the original snow leopard bootrom. Just when one thinks they cannot recover there is still that chance. I really can’t explain how I was able to do this but it worked.

CMIzapper just replied after I asked the question here and said after it boots with the Matt Card carefully remove it then romtool will dump and flash to the backplane SPI this is interesting.

 

[tsialex]

CMIzapper just replied after I asked the question here and said after it boots with the Matt Card carefully remove it then romtool will dump and flash to the backplane SPI this is interesting.

This is totally and completely wrong, perhaps you understood wrong. The only scenario that what you wrote makes any sense at all is doing a hot removal of the replacement SPI flash and flashing a working dump previously saved before the corruption.

Btw, before people start having ideas, hot removal can, and probably will, damage the backplane.

 

[osxfr33k]

This is totally and completely wrong, perhaps you understood wrong.

no he said carefully remove the Matt Card after it boots up. Then it will read to and flash to the backplane SPI. Why won’t it work because the bootrom gets loaded into memory so it will still read the Matt card?

quote:

“
Romtool will only see the Matt card when that is placed.
One trick is to boot the Mac with the matt card, and then carefully pull it out.
After that Romtool will see the original Mac ROM.”

 

[tsialex]

no he said carefully remove the Matt Card after it boots up. Then it will read to and flash to the backplane SPI. Why won’t it work because the bootrom gets loaded into memory so it will still read the Matt card?

When your do a hot removal, the signals are routed back to the backplane SPI, but this is a very bad idea:

• LITTLE FRANK is a LPC connector, any short circuit and you will damage the SPI, the southbridge and/or the backplane SMC.
• LITTLE FRANK circuit is not hot swappable, while it can be done you probably will damage the backplane, from a circuit stand-point it's worse than removing a PCIe card while on.
• The MOLEX connector used on LITTLE FRANK is rated just for 10 insertions, this was never designed for this usage.

BTW, you won't solve the main problem, the SPI flash dying of excessive cycles of write/erase. The SPI flash used on the backplane is rated for 100k cycles of write/erase. The SPI is 4KB sectored, one bit changed in the NVRAM volume and you have to erase/write a 4KB sector. SPI flash for the 2009 Mac Pros are probably past that for normally used Macs.

 

[osxfr33k]

When your do a hot removal, the signals are routed back to the backplane SPI, but this is a very bad idea:

• LITTLE FRANK is a LPC connector, any short circuit and you will damage the SPI, the southbridge and/or the backplane SMC.
• LITTLE FRANK circuit is not hot swappable, while it can be done you probably will damage the backplane, from a circuit stand-point it's worse than removing a PCIe card while on.
• The MOLEX connector used on LITTLE FRANK is rated just for 10 insertions, this was never designed for this usage.

BTW, you won't solve the main problem, the SPI flash dying of excessive cycles of write/erase. The SPI flash used on the backplane is rated for 100k cycles of write/erase. The SPI is 4KB sectored, one bit changed on the NVRAM and you have to erase/write a 4KB sector.

i thought it was too good to be true.

 

[tsialex]

i thought it was too good to be true.

It's not a tool, it's a replacement SPI flash that you insert, get your Mac Pro booting, flash the previously saved dump and then forget it installed on the backplane.

Since you have 3 Mac Pros, it's more cost-effective and sensate to replace the SPI flash for each backplane that you have.

 

[osxfr33k]

It's not a tool, it's a replacement SPI flash that you insert, get your Mac Pro booting, flash the previously saved dump and then forget it installed on the backplane.

Since you have 3 Mac Pros, it's more cost-effective and sensate to replace the SPI flash for each backplane that you have.

Agreed with some captain tape to protect any near by circuits and chipquick solder to desolder the SPI quickly and replace with a newer one after it’s flashed with the backup rom makes way more sense in the end.

 

[tsialex]

Agreed with some captain tape to protect any near by circuits and chipquick solder to desolder the SPI quickly and replace with a newer one after it’s flashed with the backup rom makes way more sense in the end.

Yes. A SPI flash memory adequate for replacement is less than $2 on Mouser/DigiKey.

 

[Tiem]

Agreed with some captain tape to protect any near by circuits and chipquick solder to desolder the SPI quickly and replace with a newer one after it’s flashed with the backup rom makes way more sense in the end.

Sorry couldn't resist. Back OT ?

 

[Flacko]

On the first page under instructions it says its better to do this under Mojave rather than Catalina is that still the recommendation?

Installing direct to Catalina worked for me. Had Mojave on SSD for backup but it was not needed. Mounted the NVME disk EFI where Catalina 15.5 was installed (running with NVRAM no compat check). Installed OC as outlined, Blessed the EFI volume and it booted up with no problems. Used VM to do an OTA update of the 15.5 supplemental and then edited the OC config to get full hardware acceleration and boot screen. No issues so far.

 

[jackluke]

About BigSur on unsupported Mac, since on this thread there is an expert community of MacPro and OpenCore, I have some questions:

To @h9826790 who already installed BigSur on an unsupported MacPro, is your mac based on Nehalem Intel architecture ?

To @cdf , @tsialex , @startergo and to everyone else who tried to make an USB BigSur Installer with createinstallmedia:

Are you able to boot the "USB BigSur Installer Recovery" with Westmere architecture ? Or are you getting an early kernel panic due to AppleACPICPU ?

If you have a kernel panic with Westmere, know this is common also to Arrandale and Clarkdale Intel architectures , while instead weirdly a Penryn Core2Duo still can boot BigSur.

Also Sandy Bridge and Ivy Bridge can boot BigSur.

 

[tsialex]

About BigSur on unsupported Mac, since on this thread there is an expert community of MacPro and OpenCore, I have some questions:

To @h9826790 who already installed BigSur on an unsupported MacPro, is your mac based on Nehalem Intel architecture ?

To @cdf , @tsialex , @startergo and to everyone else who tried to make an USB BigSur Installer with createinstallmedia:

Are you able to boot the "USB BigSur Installer Recovery" with Westmere architecture ? Or are you getting an early kernel panic due to AppleACPICPU ?

If you have a kernel panic with Westmere, know this is common also to Arrandale and Clarkdale Intel architectures , while instead weirdly a Penryn Core2Duo still can boot BigSur.

Also Sandy Bridge and Ivy Bridge can boot BigSur.

We all have Westmere/Gulftown Xeons, Nehalem don't support Apple Hypervisor/VMM.

I did not test Recovery, but I can check. Installer works fine when spoofing iMacPro1,1 + VMM.

 

[jackluke]

We all have Westmere/Gulftown Xeons, Nehalem don't support Apple Hypervisor/VMM.

I did not test Recovery, but I can check. Installer works fine when spoofing iMacPro1,1 + VMM.

Without spoofing to iMacPro1,1 and mainly without VMM spoofing, can you boot through Westmere a BigSur Installer (only with "-no_compat_check") ?

 

[tsialex]

Without spoofing to iMacPro1,1 and mainly without VMM spoofing, can you boot through Westmere a BigSur Installer (only with "-no_compat_check") ?

I'm at work, if no one can check for you before, I'll test it later today.

 

[205Maxi]

Without spoofing to iMacPro1,1 and mainly without VMM spoofing, can you boot through Westmere a BigSur Installer (only with "-no_compat_check") ?

Hello yes actually you can boot without OC, in the terminal;

*** diskutil apfs list and identify your UUID unique Preboot Volume string.

*** diskutil mount Preboot

open /Volumes/Preboot/

check that in your UUID-folder /System/Library/PrelinkedKernels/prelinkedkernel is present****


BigSur beta 11.0 unless you have the version ( 20A5299w ) prelinkedkernel size should be: ~ 25,7 MB


locate: /Volumes/Preboot/UUID-BigSur/System/Library/CoreServices/com.apple.Boot.plist

Consider replacing it at: /Volumes/Preboot/UUID-BigSur/Library/SystemConfiguration/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Cache</key>
<string>System\Library\PrelinkedKernels\prelinkedkernel</string>
<key>Kernel Flags</key>
<string>-no_compat_check amfi_get_out_of_my_way=1</string>
</dict>
</plist>

Normaly when you reboot, Big Sur should now use the prelinkedkernel instead.

 

[jackluke]

Hello yes actually you can boot without OC, in the terminal;

*** diskutil apfs list and identify your UUID unique Preboot Volume string.

*** diskutil mount Preboot

open /Volumes/Preboot/

check that in your UUID-folder /System/Library/PrelinkedKernels/prelinkedkernel is present****


BigSur beta 11.0 unless you have the version ( 20A5299w ) prelinkedkernel size should be: ~ 25,7 MB


locate: /Volumes/Preboot/UUID-BigSur/System/Library/CoreServices/com.apple.Boot.plist

Consider replacing it at: /Volumes/Preboot/UUID-BigSur/Library/SystemConfiguration/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Cache</key>
<string>System\Library\PrelinkedKernels\prelinkedkernel</string>
<key>Kernel Flags</key>
<string>-no_compat_check amfi_get_out_of_my_way=1</string>
</dict>
</plist>

Normaly when you reboot, Big Sur should now use the prelinkedkernel instead.

I discovered that BigSur prelinkedkernel fix (also because "booter-fileset-kernel" from opencore doesn't worked), anyway I asked a different question, if Westmere is a supported architecture from BigSur kernel.

 

[HuRR]

Random question.

I have a "official" 5,1 with an NVME loaded with Mojave as my main drive. I then have Mojave in Bay 1, High Sierra in Bay 2, and Windows 10 (Legacy) in Bay 3. I made a Opencore USB bootloader (using @h9826790 package) and followed all the directions and reset SMC as well. It loaded the OC picker perfectly. When I select the NVME drive, I see the Apple boot logo and then it just hangs. If I select the Mojave SSD, it boots up perfectly. Any insight would be greatly appreciated. Planning on upgrading to Catalina but want to try it out on the SSD before I update with the NVME.

 

[jackluke]

Also another question for those who installed BigSur and use opencore as bootloader, BigSur introduced a new csrutil with this: csrutil authenticated-root status

it can be disabled from a BigSur Recovery (or Installer), ASentientBot patched the BigSur boot.efi to disable that: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28604525

but I'd keep stock the BigSur boot.efi, and as many know opencore can patch it in nvram without replacing, I am currently using this opencore csr-active-config: 77000000 (or base64: dwAAAA==)
in hex from terminal: 0x00000077

After BigSur Recovery csrutil authenticated-root disable, this is the "new BigSur SIP disabled" (from my current BigSur normal booting terminal) nvram csr-active-config: csr-active-config=w%08%00%00

in hex from BigSur terminal conversion: 0x00000877

how to convert this value to Base64 for opencore 0.59 csr-active-config data value ?

I've already tried many, but don't worked, I guess current opencore is unable to patch the BigSur boot.efi .

 

[205Maxi]

I have tried csrutil authenticated-root disable in recovery mode and after boot back it is disabled but I can't still get sudo mount -uw / to work it fails with error 66.

 

[205Maxi]

Also another question for those who installed BigSur and use opencore as bootloader, BigSur introduced a new csrutil with this: csrutil authenticated-root status

it can be disabled from a BigSur Recovery (or Installer), ASentientBot patched the BigSur boot.efi to disable that: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28604525

but I'd keep stock the BigSur boot.efi, and as many know opencore can patch it in nvram without replacing, I am currently using this opencore csr-active-config: 77000000 (or base64: dwAAAA==)
in hex from terminal: 0x00000077

After BigSur Recovery csrutil authenticated-root disable, this is the "new BigSur SIP disabled" (from my current BigSur normal booting terminal) nvram csr-active-config: csr-active-config=w%08%00%00

in hex from BigSur terminal conversion: 0x00000877

how to convert this value to Base64 for opencore 0.59 csr-active-config data value ?

I've already tried many, but don't worked, I guess current opencore is unable to patch the BigSur boot.efi .

dwgAAA== should be the new value for OC.

If you do a printf "$(echo -n 'w%08%00%00' | sed -E '/\\/s//\\\\/g;/%/s//\\x/g')" | base64 then you obtain the above value.. I haven't tried it yet, will do after I am done with some tasks..

 

[jackluke]

dwgAAA== should be the new value for OC.

If you do a printf "$(echo -n 'w%08%00%00' | sed -E '/\\/s//\\\\/g;/%/s//\\x/g')" | base64 then you obtain the above value.. I haven't tried it yet, will do after I am done with some tasks..

Already tried dwgAAA== and doesn't worked, this means that opencore 0.59 is unable to patch the BigSur boot.efi or its nvram boot-args .

 

[205Maxi]

Already tried dwgAAA== and doesn't worked, this means that opencore 0.59 is unable to patch the BigSur boot.efi or its nvram boot-args .

I run the latest open core DBG version 0.6, I am testing now and will report back here...

 

[jackluke]

I run the latest open core DBG version 0.6, I am testing now and will report back here...

But before testing you should from BigSur Recovery or Installer use csrutil authenticated-root enable, otherwise it's still stored in nvram .

 

[205Maxi]

But before testing you should from BigSur Recovery or Installer use csrutil authenticated-root enable, otherwise it's still stored in nvram .

I think that I am gonna have to go back on ver. 0.5.9 because I am not longer able to boot in the recovery as I was before I put ver. 0.6