Skip to content

← All issues

Mac Pro 5,1 and 6,1

· by @WhiteLighter78

I thought I'd start a new thread for these two Macs. How are we doing on these GPU patches? Thanks! Should I also test the new Alpha 18.6/18.8 on the MacBookPro15,1 and MacMini8,1? I'm currently working on my iMac 11,2, swapping CPUs and GPU!

Comments

@albert-mueller ·

@Medelcartelinc is writing the root patches mostly

@Medelcartelinc ·

@WhiteLighter78 @albert-mueller

For the Mac Pro 6,1, the factory dual AMD FirePro D300, D500, and D700 cards are GCN 1 architecture (Pitcairn and Tahiti). With Apple completely stripping the legacy 31001 Metal compiler stack in Tahoe, getting full acceleration back on GCN 1 and 2 is one of the big ongoing challenges we are untangling in the legacy graphics branches right alongside our Polaris and non-Metal work. You will get basic unaccelerated framebuffer output right now, but fully accelerated WindowServer and Metal rendering are still actively being engineered.

The Mac Pro 5,1 is a slightly different story because it depends entirely on your PCIe GPU configuration. If you have an upgraded Metal-native card installed such as an RX 580 Polaris or a Vega, graphics acceleration works cleanly, but the primary bottleneck on the 5,1 is that Westmere Xeon CPUs lack AVX and AVX2 instruction sets, requiring heavy instruction emulation and cryptex adjustments for modern system frameworks.

Testing the new Alpha builds on your MacBookPro15,1 and Macmini8,1 would be tremendously helpful. Because both of those are Coffee Lake T2 machines with native AVX2 and native Metal support, running the latest patcher there lets us isolate and validate T2 bridgeOS handoff, APFS volume mounting, and installer reliability without any legacy GPU variables in the mix.

@albert-mueller ·

@WhiteLighter78 @albert-mueller

For the Mac Pro 6,1, the factory dual AMD FirePro D300, D500, and D700 cards are GCN 1 architecture (Pitcairn and Tahiti). With Apple completely stripping the legacy 31001 Metal compiler stack in Tahoe, getting full acceleration back on GCN 1 and 2 is one of the big ongoing challenges we are untangling in the legacy graphics branches right alongside our Polaris and non-Metal work. You will get basic unaccelerated framebuffer output right now, but fully accelerated WindowServer and Metal rendering are still actively being engineered.

The Mac Pro 5,1 is a slightly different story because it depends entirely on your PCIe GPU configuration. If you have an upgraded Metal-native card installed such as an RX 580 Polaris or a Vega, graphics acceleration works cleanly, but the primary bottleneck on the 5,1 is that Westmere Xeon CPUs lack AVX and AVX2 instruction sets, requiring heavy instruction emulation and cryptex adjustments for modern system frameworks.

Testing the new Alpha builds on your MacBookPro15,1 and Macmini8,1 would be tremendously helpful. Because both of those are Coffee Lake T2 machines with native AVX2 and native Metal support, running the latest patcher there lets us isolate and validate T2 bridgeOS handoff, APFS volume mounting, and installer reliability without any legacy GPU variables in the mix.

I only have 2018 Mac mini and 2020 4 thunderbolt 3 ports MacBook Pro. I have 0 non-T2 systems.
@Medelcartelinc

@WhiteLighter78 ·

Ok! Thank you for the update on the 5,1 and 6,1 machines! I have a Radeon RX 580 in the 5,1 and have EnableGOP injected into that firmware so I always have a boot screen! I will go and try the new versions on the MBP and mini and report back! 👍

@WhiteLighter78 ·

MBP stops here with alpha 18.8

@Medelcartelinc ·

@albert-mueller @WhiteLighter78

Looking at your verbose screen on the MacBook Pro with alpha 18.8, the kernel, Lilu, and base userland are initializing cleanly all the way up to loginwindow (PID 76) and storagekitd. The stall right at cvmsServ (PID 152) indicates that launchd is handing off to WindowServer and tripping over the display and graphics shader pipeline, which is expected on Tahoe before graphics framebuffer and Metal shims take over.

Regarding @albert-mueller's Mac mini 2018, we have just finished implementing and compiling the fix for the installer blocker diagnosed in Issue #327. Apple dropped board identifier J174AP alongside J132AP and J140kAP from Tahoe's SupportedDeviceModels, and the installer daemon osinstallersetupd was failing board matching. We expanded RestrictEvents with an active target-type sysctl hook (rerouting to J680AP for installer daemons) and updated the boot arguments so the 2018 mini and 2018/2019 MacBook Pros can bypass that block without getting kicked out. We just opened PR #331 with the updated payloads and automated boot-args injection, making the 2018 mini ready to verify the clean pass-through.

@m0rtiis1 ·

Mac book pro 15.1 2018
used latest open core legacy patcher T2 4.0.0.18009.1 - 4.0.0 alpha 18.9.1

Image

@m0rtiis1 ·

Mac book pro 15.1 2018
used latest open core legacy patcher T2 .0.0.18009.3 - 4.0.0 alpha 18.9.3

Image

@WhiteLighter78 ·

Same here on MBP 15,1.

@WhiteLighter78 · · edited

Tested new version 180010.1 on Mac Pro 6,1 as it auto-upgraded, and I noticed in build 18009.13 that the yellow screen issue has been fixed, so I ran the root patches again, after reverting the last ones. It successfully root patched, but it seems they didn't do anything. No graphics acceleration, but no yellow screen! and no sound/wifi. Going into the root patching, it says all patches have been applied. @Medelcartelinc

@WhiteLighter78 ·

Tested Alpha 19 on the Mac Pro 6,1 again, root patching still brings solid yellow screen after reboot. Reverted patches for now.

@m0rtiis1 · · edited

Mac book pro 15.1 2018
open core legacy patter t2 4.0.0.190002 - 4.0.0 alpha 19.2

Image

& open core legacy patcher t2 version 4.0.0.180010.4

Image

@WhiteLighter78 ·

I haven't gotten anywhere with my mbp 15,1 either. I haven't posted anything because nothing has changed. Every version stops here

@albert-mueller ·

Is the grey screen gone? on the latest alpha?

@WhiteLighter78 ·

On the MPB 15,1? or you mean the yellow screen on the Mac Pro 6,1?

@albert-mueller ·

On the MPB 15,1? or you mean the yellow screen on the Mac Pro 6,1?

On the Mac Pro6,1

@WhiteLighter78 ·

I'm trying it right now! And no. It still booted to the yellow screen unfortunately

@albert-mueller · · edited

Hi @WhiteLighter78, thanks for the report! To look into this we need to know exactly which versions you're running. Please edit your issue or reply below with:

  • macOS version, ideally with the build number (e.g. 26.6.1 (25G76)). You can find it under → About This Mac, or by running sw_vers in Terminal.
  • OpenCore Legacy Patcher version (e.g. 4.0.0.18009), shown in the app's main window. If you built from source, the commit hash works too.

"Latest" or "new" isn't enough, since new builds come out often. This comment will go away once the versions are added.

4.0.0.19004.5
MacPro5,1 and 6,1
macOS version - @WhiteLighter78 needs to answer

@WhiteLighter78 ·

4.0.0.190004.5, Mac Pro 6,1 and macOS Tahoe 26.7

@WhiteLighter78 ·

How are things looking for the Mac Pro 6,1 TrashCan? or the Mac Pro 5,1 with an AMD Radeon RX 570/580?

@sonimcrinebru-art ·

@WhiteLighter78

I did manage to get the Tahoe installer to boot on my 15,1. For some reason, disabling Whatevergreen in boot args fixed the window server issues for me.

@WhiteLighter78 ·

ok I tried that, and I at least got to the apple logo, but the progress bar just stopped. Were you able to install it at all on the MBP 15,1?

@sonimcrinebru-art ·

ok I tried that, and I at least got to the apple logo, but the progress bar just stopped. Were you able to install it at all on the MBP 15,1?

I was able to do get to stage 2 of the installer. I can share you my 15,1 EFI if you'd like

@WhiteLighter78 · · edited

Ok, so I chose a macbook pro 16,1 model spoof and added the -wegoff and currently installing onto an external drive for testing. I'll let you know how it goes. EDIT: after the reboot, on the "29 minutes remaining" screen, it eventually gets to that macos error occured while preparing the installation.

@sonimcrinebru-art ·

@WhiteLighter78

Lots of T2 Macs have this issue. @zkennedy137 is solving this issue but I have not heard an update from him for 2-3 days.

@WhiteLighter78 ·

Oh okay. But hey, this is the first time I've even gotten this far!!

@sonimcrinebru-art ·

Oh okay. But hey, this is the first time I've even gotten this far!!

One more thing, for 15,1 I don't think you'd need to spoof to 16,1 since my own 15,1 got to this issue without changing SMBIOS and only using SpoofVMM.

@zkennedy137 ·

@WhiteLighter78

Lots of T2 Macs have this issue. @zkennedy137 is solving this issue but I have not heard an update from him for 2-3 days.

I am working on it but I cannot guarantee that it won't come down to the T2 chip itself. There is a good chance we may have to develop a payload to spoof the bridge-os version from the T2 itself with the checkm8 exploit this may be possible. It will be a lot of work though but given the Find My Mac bypass tool it should be possible. Once installed it shouldn't need to be run again only on the first boot and reboots (stages of the install). Given that checkm8 isn't persistent it will have to be run on each boot at least for the install. After that maybe won't be necessary. Anyways I am workin on It just trying to find a way to spoof the Bridge-OS version that way the installer bypasses that check on stage 2.

@m0rtiis1 ·

@WhiteLighter78
Lots of T2 Macs have this issue. @zkennedy137 is solving this issue but I have not heard an update from him for 2-3 days.

I am working on it but I cannot guarantee that it won't come down to the T2 chip itself. There is a good chance we may have to develop a payload to spoof the bridge-os version from the T2 itself with the checkm8 exploit this may be possible. It will be a lot of work though but given the Find My Mac bypass tool it should be possible. Once installed it shouldn't need to be run again only on the first boot and reboots (stages of the install). Given that checkm8 isn't persistent it will have to be run on each boot at least for the install. After that maybe won't be necessary. Anyways I am workin on It just trying to find a way to spoof the Bridge-OS version that way the installer bypasses that check on stage 2.

Mac book pro 5.1
Open core legacy patcher t2 version 4.0.0.190008.1 - 4.0.0 alpha 19.8.1

this is my last try with latest open core I reach this screen attached and after that Mac book pro shuts down and never reaches the installation page

Image Image Image Image

@m0rtiis1 · · edited

Ok, so I chose a macbook pro 16,1 model spoof and added the -wegoff and currently installing onto an external drive for testing. I'll let you know how it goes. EDIT: after the reboot, on the "29 minutes remaining" screen, it eventually gets to that macos error occured while preparing the installation.

@WhiteLighter78 Mac book pro 15.1 I never reached the installation page after loading texts at some point Mac shuts down can you please tell steps you have done to reach installation page?

@WhiteLighter78 ·

@m0rtiis1 Ok so what I did was when I created my EFI with opencore, I chose SMBIOS Spoof Level Minimal and SMBIOS Spoof Model MacBookPro16,1 and then as per @sonimcrinebru-art 's suggestion, I disabled whatevergreen with -wegoff in boot args. After I did that, the installer made it to the installation screens. I was able to pass the language selection and then off to the installation screens. I didn't want to bork my sequoia installation so I attached a USB to SATA SSD, and used disk utility to format a new drive. I then installed to that drive. It went on to the second reboot. That's as far as I've gotten, but this is the first time I've gotten this far at all.

@m0rtiis1 ·

I disabled whatevergreen with -wegoff in boot args

@WhiteLighter78 ok thanks a lot 🙂 but can you tell me the steps how to I disabled whatevergreen with -wegoff in boot args what did you do to disable it I just open terminal and type it in terminal after I disable csrutil in the recovery screen?

@WhiteLighter78 ·

BIG NEWS!! I just found out the official OCLP team has released version 3.0.0 RC2 and I tested it against the Mac Pro 6,1 and can confirm graphics acceleration is WORKING! OMG OMG! YES! I don't think T2 macs are ready yet, but my Mac Pro trashcan is working audio, graphics and wifi!

@WhiteLighter78 ·

@m0rtiis1 To disable whatevergreen, I just used propertree to edit the config.plist and added -wegoff to the boot args.

@WhiteLighter78 ·

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

@albert-mueller ·

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

Dortania hasn’t enabled T2 at all. I just checked their commit history.

@albert-mueller ·

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

Anyways slowly this project migrates to fork of Dortania’s PatcherSupportPkg and on top of this will be costum patch set to fix a few remaining issues.

@m0rtiis1 · · edited

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

Anyways slowly this project migrates to fork of Dortania’s PatcherSupportPkg and on top of this will be costum patch set to fix a few remaining issues.

I feel so sad a lot of people installed Tahoe in older Macs & T2 Macs still can't install it Mac Book pro 15.1 😞 is there a hope for us??

@albert-mueller ·

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

Anyways slowly this project migrates to fork of Dortania’s PatcherSupportPkg and on top of this will be costum patch set to fix a few remaining issues.

I feel so sad a lot of people installed Tahoe in older Macs & T2 Macs still can't install it Mac Book pro 15.1 😞 is there a hope for us??

For the T2 side of things in my project, @zkennedy137 is doing a lot of reverse engineering, testing to try fix the T2 Macs.

@m0rtiis1 ·

Spent all day on the Mac Pro 5,1, as that one didn't want to play nice with OCLP 3.0.0 RC2. I thought doing an in-place upgrade to Tahoe would have worked over Sequoia and it did not. So fresh install, after a lot of tweaking, but I can confirm Mac Pro 5,1 is now on Tahoe with all the patches working. Also got the iMac 16,2 going as well. So that's 3 Macs today. All non T1/T2's of course. Next up is the MBP 15,1 lol

Anyways slowly this project migrates to fork of Dortania’s PatcherSupportPkg and on top of this will be costum patch set to fix a few remaining issues.

I feel so sad a lot of people installed Tahoe in older Macs & T2 Macs still can't install it Mac Book pro 15.1 😞 is there a hope for us??

For the T2 side of things in my project, @zkennedy137 is doing a lot of reverse engineering, testing to try fix the T2 Macs.

@albert-mueller @zkennedy137 @Medelcartelinc
I guess since Open Core original developers have released Open Core RC2 for most of devices before T2 chips now this is a good time for you guys to focus on T2 chips only since your main projects was intended for T2 chips instead of working in older machines & T2 chips both and since you are the one who can make the T2 chips work 🙂

@Medelcartelinc ·

Hi @m0rtiis1,

While focusing heavily on T2 is definitely the primary mission (and @zkennedy137 and @albert-mueller are doing great reverse-engineering work there), the assumption that "everything pre-T2 is solved with Dortania RC2" isn't entirely accurate—especially for T1 Macs (MacBook Pro 2016 & 2017 Touch Bar).

T1 models are in a unique architectural limbo on macOS Tahoe:

  1. The Touch ID / SEP Dilemma:
    • If you force legacy Ventura kexts (AppleKeyStore, AppleCredentialManager) to get Touch ID working, the kernel-to-userland IPC mismatch with Tahoe breaks LocalAuthentication, syspolicyd, and securityd. This causes endless password prompt loops in System Settings, breaks Apple Account login, and prevents apps like Messages and FaceTime from opening.
    • If you use Native Software Keystore mode (bypassing the legacy SEP linkage), the entire OS runs with 100% stability—Apple Account, System Settings, Gatekeeper, Handoff, and AirPlay all work flawlessly—but biometric Touch ID has to be bypassed in favor of password prompts.
  2. There is currently no seamless workaround anywhere that provides both working Touch ID and stable user-space services on Tahoe for T1.

So while T2 remains a massive undertaking, T1 hardware still requires active engineering and care. That said, all findings from T1 security bridge patching provide valuable insights for T2 development as well!