MP 1,1-5,1 (MP4,1/5,1) Looking for BootROM Beta Testers

[Syncretic]

From the "better ten years late than never" department: I'm looking for beta testers for a set of BootROM modifications. While working toward my larger goal (AVX emulation), I needed to gain expertise with (and some control over) the BootROM, and this set of modifications seemed like a useful start.

If you're interested after reading this post, send me a PM with a list of the hardware you have available to test; I'll start responding to those PMs the first week of January (after I return from holiday - don't be disappointed if you don't get a response right away).

What's included:​

• Native boot/progress screens for most modern* GPUs
• Native Apple boot picker for most modern* GPUs
• Some UEFI2 support, allowing many newer unmodified GPUs to boot on MP4,1/5,1 (including AMD RX6x00 and MSI GT710)
• EFI USB3 support, including boot from USB3 for most USB3 adapters
• Improved EFI USB1.1/USB2 support, allowing some previously troublesome devices to connect (including TESmart KVM switches)
• "One and done" deep NVRAM reset (Cmd-Opt-P-R) - no need to hold through 3-5 chimes
• A method to easily enable/disable SIP

* A "modern" GPU is one that produces either the UGA or GOP protocol. Graphics cards older than about 2012 are unlikely to work; cards newer than about 2012 are likely to work.

To anticipate a few questions:​

• For now, this is strictly for the MP4,1/MP5,1. However, it's conceivable that the process could be adapted to MP3,1 and/or other Mac models at some point in the future.
• These BootROM modifications have been in small-group alpha test for about four months, and they're currently stable.
• These BootROM changes do not change how MacOS handles devices. It's possible for the modified BootROM to allow your graphics card to show the native Apple boot screens, but if MacOS doesn't contain drivers for your card, MacOS will be either slow or unusable.
  Even if MacOS does contain drivers for your card, these BootROM modifications will not resolve any existing issues you may have with resolution/refresh rate/color depth (i.e. if MacOS has problems with your card, these BootROM mods aren't going to solve those problems).
• If your GPU has framebuffer oddities (looking at you, Polaris) that result in pink lines/corruption of the boot screens just before MacOS loads, those artifacts will still be present (these BootROM modifications do not change the (mis)behavior of your GPU).
• This is "Phase 1" of a multi-phase effort to extend the useful life of the Mac Pro 4,1/5,1 by several more years (what I think of as "Project Macthuselah"). "Phase 2" involves injecting my AVX emulator into the system before MacOS ever loads (I think I've figured out how to do that). To get to that point, I needed to gain some control over the BootROM, which resulted in the modifications listed above.
• The first stage of the Mac boot process happens in EFI, and the second stage happens after the MacOS kernel has loaded. By design, EFI does not support interrupt-driven communications, which means that booting from a USB3 device does not achieve (or even approach) true USB3 speeds until the EFI portion is complete and the MacOS kernel has loaded, after which the boot becomes much faster. This is both normal and unavoidable, given the inherent constraints of EFI.
• Other BootROM modifications are being discussed. Suggestions are welcome.
• These BootROM modifications are compatible with OpenCore. They do not replace OpenCore; in particular, booting MacOS versions later than Mojave still require support from a boot loader such as OpenCore.
• None of these BootROM modifications touch the network, collect any telemetry data, or "phone home" (i.e. connect or transmit data to any other system or "the cloud"). They just provide the services outlined above, nothing more.
• These BootROM modifications were developed entirely in-house, either from scratch or derived from modified TianoCore sources. The BootROM modifications do not include any code from any branch of OpenCore, rEFInd/RefindPlus, or other third-party sources (other than TianoCore).
• Just to be very clear: this set of BootROM modifications does not provide AVX emulation. AVX is the larger project; this is just a step in that direction. The AVX project is still a work in progress.

Prospective beta testers should:​

• have a Mac Pro 4,1 or 5,1 with the 144.0.0.0.0 BootROM (clean/reconstructed is preferable, but non-reconstructed is OK)
• be comfortable flashing their BootROM, and have a backup of their BootROM
• have a stable system (testing/debugging is troublesome if the system is flaky)
• preferably have access to a variety of video cards, USB3 cards/devices, and/or mice/keyboards (wired and wireless)
• preferably be able to reboot frequently in order to test various configurations
• preferably have a strong stomach and low aversion to risk (or a MATT card, or a socketed SPI chip)

If, after reading all of that, you're still interested in being a beta tester, send me a PM with a description of your test hardware. I'll respond during the first week of January (be patient!).

 

[tsialex]

I've been testing the @Syncretic great improvements since May and want to further reinforce some points.

First, do not expect that your 2nd hand mining modded GPU will work - if you have a 2nd hand GPU that does not work with OC BootPicker currently, expect that you'll have to flash the factory firmware back to your GPU. Again, if your GPU does not have the factory firmware (or a valid firmware like some MVC flashed cards), the pre-boot configuration support will not gonna work for you.

Another thing to be aware, not all displays resolutions work for the pre-boot configuration support and some older GPUs will only work via DVI and not when connected via HDMI/DP. This doesn't magically solve the issues with 24" Apple Cinema displays and other monitors that have unusual screen resolutions or respond with incorrect EDID data.

Also, if you have more than one GPU installed at the same time, you'll probably find issues with the pre-boot configuration support. If you have a MVC flashed GPU and a GOP one, the combo will probably not gonna work or work in unexpectedly ways.

The added UEFI 2.x HII support for NAVI 2x GPUs works perfectly, worked out of the box with my Asus DUAL-RX6600-8G and other testers tested with different RX 6800/6900, just install your NAVI 2x GPU with the factory firmware, no need to flash the patched firmware with a PC anymore. You now can have NAVI 2x GPUs working and with full pre-boot configuration support right out of the box with your MacPro5,1 and Monterey.

These BootROM improvements doesn't mean in any way that your unsupported GPU will start to work with macOS (NAVI 22 GPUs like 6700/6700 XT or any post Kepler NVIDIA GPUs will not be accelerated, even if the fail-safe EFI drivers now work and you'll have a extremely slow and practically useless display working with macOS), but it's very useful for someone that primarily wants to run Windows.

XFX video cards that doesn't work when installed in a MacPro5,1, like several pre-Polaris models, will continue to not work. VIA USB v3.0 controllers seem very problematic and some NewerTech USB v3.0 cards also doesn't work. Some USB HID devices can affect your boot ability, we are preparing a list of things that does not work or are problematic.

 

[Borowski]

Good morning,

if possible or a todo: reduce booting-time.
Would be nice, if NVMe-drives could appear/start first in boot-order. Most users have NVMe for system and SATA only for data.

 

[mode11]

Echoing @Borowski, I don't know if there's anything the EFI can do to reduce the duration of boot-time TRIM with Samsung NVMe drives? Even having swapped my 960 Evo for a 970 Pro, there's still a delay of about 45 seconds on each boot, which seems excessive.

 

[tsialex]

Echoing @Borowski, I don't know if there's anything the EFI can do to reduce the duration of boot-time TRIM with Samsung NVMe drives? Even having swapped my 960 Evo for a 970 Pro, there's still a delay of about 45 seconds on each boot, which seems excessive.

TRIM process is done by macOS, not by the EFI.

 

[mode11]

Feared as much. Oh well.

 

[hwojtek]

if possible or a todo: reduce booting-time.

While it may be reduced by OC with proper trim settings, the time between power on and chime is directly related to the amount of RAM, and I know, it takes ages with 128 GB.

Also @Syncretic - this is not big, it's BIG!!! Kudos, you're single-handedly saving a generation of Macs from extinction. Can't express my admiration.

 

[Petri Krohn]

WOW!

If this ever gets ported to the Mac Pro 3,1, it leaves only one thing on my wish list:

Implement SSE4.2 as a microcode update.

https://forums.macrumors.com/threads/mp3-1-others-sse-4-2-emulation-to-enable-amd-metal-driver.2206682/page-9?post=31855309#post-31855309

 

[vxlvo]

From the "better ten years late than never" department: I'm looking for beta testers for a set of BootROM modifications. While working toward my larger goal (AVX emulation), I needed to gain expertise with (and some control over) the BootROM, and this set of modifications seemed like a useful start.

If you're interested after reading this post, send me a PM with a list of the hardware you have available to test; I'll start responding to those PMs the first week of January (after I return from holiday - don't be disappointed if you don't get a response right away).

What's included:​

• Native boot/progress screens for most modern* GPUs
• Native Apple boot picker for most modern* GPUs
• Some UEFI2 support, allowing many newer unmodified GPUs to boot on MP4,1/5,1 (including AMD RX6x00 and MSI GT710)
• EFI USB3 support, including boot from USB3 for most USB3 adapters
• Improved EFI USB1.1/USB2 support, allowing some previously troublesome devices to connect (including TESmart KVM switches)
• "One and done" deep NVRAM reset (Cmd-Opt-P-R) - no need to hold through 3-5 chimes
• A method to easily enable/disable SIP

* A "modern" GPU is one that produces either the UGA or GOP protocol. Graphics cards older than about 2012 are unlikely to work; cards newer than about 2012 are likely to work.

To anticipate a few questions:​

• For now, this is strictly for the MP4,1/MP5,1. However, it's conceivable that the process could be adapted to MP3,1 and/or other Mac models at some point in the future.
• These BootROM modifications have been in small-group alpha test for about four months, and they're currently stable.
• These BootROM changes do not change how MacOS handles devices. It's possible for the modified BootROM to allow your graphics card to show the native Apple boot screens, but if MacOS doesn't contain drivers for your card, MacOS will be either slow or unusable.
  Even if MacOS does contain drivers for your card, these BootROM modifications will not resolve any existing issues you may have with resolution/refresh rate/color depth (i.e. if MacOS has problems with your card, these BootROM mods aren't going to solve those problems).
• If your GPU has framebuffer oddities (looking at you, Polaris) that result in pink lines/corruption of the boot screens just before MacOS loads, those artifacts will still be present (these BootROM modifications do not change the (mis)behavior of your GPU).
• This is "Phase 1" of a multi-phase effort to extend the useful life of the Mac Pro 4,1/5,1 by several more years (what I think of as "Project Macthuselah"). "Phase 2" involves injecting my AVX emulator into the system before MacOS ever loads (I think I've figured out how to do that). To get to that point, I needed to gain some control over the BootROM, which resulted in the modifications listed above.
• The first stage of the Mac boot process happens in EFI, and the second stage happens after the MacOS kernel has loaded. By design, EFI does not support interrupt-driven communications, which means that booting from a USB3 device does not achieve (or even approach) true USB3 speeds until the EFI portion is complete and the MacOS kernel has loaded, after which the boot becomes much faster. This is both normal and unavoidable, given the inherent constraints of EFI.
• Other BootROM modifications are being discussed. Suggestions are welcome.
• These BootROM modifications are compatible with OpenCore. They do not replace OpenCore; in particular, booting MacOS versions later than Mojave still require support from a boot loader such as OpenCore.
• None of these BootROM modifications touch the network, collect any telemetry data, or "phone home" (i.e. connect or transmit data to any other system or "the cloud"). They just provide the services outlined above, nothing more.
• These BootROM modifications were developed entirely in-house, either from scratch or derived from modified TianoCore sources. The BootROM modifications do not include any code from any branch of OpenCore, rEFInd/RefindPlus, or other third-party sources (other than TianoCore).
• Just to be very clear: this set of BootROM modifications does not provide AVX emulation. AVX is the larger project; this is just a step in that direction. The AVX project is still a work in progress.

Prospective beta testers should:​

• have a Mac Pro 4,1 or 5,1 with the 144.0.0.0.0 BootROM (clean/reconstructed is preferable, but non-reconstructed is OK)
• be comfortable flashing their BootROM, and have a backup of their BootROM
• have a stable system (testing/debugging is troublesome if the system is flaky)
• preferably have access to a variety of video cards, USB3 cards/devices, and/or mice/keyboards (wired and wireless)
• preferably be able to reboot frequently in order to test various configurations
• preferably have a strong stomach and low aversion to risk (or a MATT card, or a socketed SPI chip)

If, after reading all of that, you're still interested in being a beta tester, send me a PM with a description of your test hardware. I'll respond during the first week of January (be patient!).

Did you ever finish it? i really need help with my GPU right about now

 

[hwojtek]

Did you ever finish it? i really need help with my GPU right about now

Did you see the date of the actual post? It was 10 days ago.
Did you read it? No, really?
Are you willing to be a beta tester?
What is that you demand?

 

[Borowski]

invalid, reported PM.

 

[benmuetsch]

Wow, this sounds very amazing. By the one hand I would like to try and contribute, by the other hand, this Mac Pro is my main workstation so I dunno at the moment..
But the effort and skill you guys put into this is simply amazing.
Any chance to get better Thunderbolt-support via BootROM?
I still have a TB2 Falcon Ridge card which refuses to do anything in the cMP

 

[Rastafabi]

I‘ve got some feature suggestion for your firmware development @Syncretic:

1. Mac Pros with native firmware can make use of the restore disks, even with catastrophic failures. Mac Pros 4,1s with a 5,1 ROM cannot. Could the firmware be modified in a way to either restore the functionality to its original disks, or to legit 5,1 rescue drives? Admittedly this is a very specific and rarely needed functionality.
2. Another thing would be -if this is possible at all- to redirect nvram calls to a text file on the efi volume of the first disk found, to reduce stress regarding writes.
3. What also could be interesting is enabling different boot paths to be recognised as efi boot targets: like /boot/refind/refind_x64.efi or /boot/ubuntu… and the like /boot/*… including representing appropriate distinguishable names in the boot picker (presumably the efi file parents folder name)
4. Fixing the ROM to not break when efi booting windows
5. Keyboard maps to support firmware-passwords in non us layouts
6. Support BIOS mode booting from USB, like 2012 MacBook Pros
7. Take a look at why Ventoy multiboot USBs do not work with Macs
8. Embedded efi shell as a boot option (optional, maybe toggle via nvram variable)
9. Option to cycle through available monitors to display the boot picker and remember the selection
10. Option to always boot to the boot picker (via nvram variable)

 

[719c6]

Just curious if you can release any news or updates?

 

[glopez007]

Hi Syncretic,
I just sent you a PM. Hope you will include me as a beta tester of your modded BootROM.
Thanks,
glopez007

 

[freqrider]

3,1 mod! Pretty Please!

 

[ProDFX]

I can participate in tests. I have a Mac Pro 3.1 with Meritec socket for firmware chip + xGecu T56 programmer.
1. There are a couple of USB3 cards on the ASM1042A chip for testing (HighPoint RocketU 1144CM and noname сhinese card).
2. GTX680 with GOP support.

HighPoint RocketU
Device ID.....: 1042
Class Code....: 00 04 01

Chinese noname
Device ID.....: 1042
Class Code....: 30 03 0C


Can't send PM....

 

[tommy chen]

I can participate in tests. I have a Mac Pro 3.1 with Meritec socket for firmware chip + xGecu T56 programmer.
1. There are a couple of USB3 cards on the ASM1042A chip for testing (HighPoint RocketU 1144CM and noname сhinese card).
2. GTX680 with GOP support.

HighPoint RocketU
Device ID.....: 1042
Class Code....: 00 04 01

Chinese noname
Device ID.....: 1042
Class Code....: 30 03 0C


Can't send PM....

but you do realize that this is for the 5.1 and not the 3.1?

 

[ProDFX]

but you do realize that this is for the 5.1 and not the 3.1?

Yes. Mac Pro 5.1 is also available.
I would like to test it on a Mac Pro 3.1 as not everyone can experiment with 3.1 fearlessly.

 

[NC12]

Yes. Mac Pro 5.1 is also available.
I would like to test it on a Mac Pro 3.1 as not everyone can experiment with 3.1 fearlessly.

No, read the post again it says

• For now, this is strictly for the MP4,1/MP5,1. However, it's conceivable that the process could be adapted to MP3,1 and/or other Mac models at some point in the future.

 

[ProDFX]

This post meant. On MP5.1 as a matter of course.

 

[zhandouji]

I dont know why I can't send you a pm,can you give me an e-mail?
thank you
I have mc561 x5675*2 vega64 96gb ram,1t nvme.

 

[Syncretic]

I got pulled away from this project for a while; my sincere apologies to the many folks who have PM'd me and not received a response. I'll be catching up on my inbox this week (in case anyone was curious, I can report that the MacRumors unread PM badge does count well into the double digits). To my existing testers: expect an updated version this week, assuming you're still willing to keep testing. To the prospective testers who have PM'd me and not received a response - I'll try to get back to all of you this week, but be aware that unless you have some hardware that isn't already represented in the existing test pool, I'm probably going to keep you in reserve for now.

Prior to getting pulled away, I had ventured down an absurdly deep rabbit hole. I got a simple-sounding bug report - "MBR (legacy) boot doesn't work" - so I figured I'd just fix that and get on with other things. "Fix that" led me on an adventure into the depths of the BootROM. To make an excruciatingly long story short, legacy booting is very fragile, and the hardware needs to be left precisely how the legacy BIOS expects it to be; one wrong bit in a status register and the boot will hang. Of course, the precise state that the legacy BIOS needs isn't publicly documented, so down the rabbit hole I went. While frustrating and time-consuming, it was educational.

I started on a few new features during this time, but I think I'm going to pause that development until AVX is done. The new features include an (optional) abbreviated memory test and a replacement NVRAM handler that stores more than 64kB and does wear-leveling. Those features will be nice, but "nice features" can become a time-sink, and AVX is becoming a necessity, so that's becoming my priority. (I am also working on a simple bootable installer for the ROM modifications; if that ever becomes stable enough, I'll put it on Github so that other ROM-flashing projects can benefit.)

For the handful of people who program in EFI, here are a few tidbits that you may find useful:

• The Mac Pro 5,1 EFI seems to be based on the reference code in EDK 1.01 (it lacks various elements that were introduced in EDK 1.02, and contains various elements that were not present in EDK 1.00). Knowing this can be extremely helpful when reversing the BootROM modules, because in many cases, the more modern EDKII code looks completely different (for example, in the BootROM/EDK 1.01, UsbBusDxe uses linked lists; by EDK 1.04 they had changed it to use arrays, which is how EDKII is implemented as well). EDK 1.01 was finalized on 17 November 2006, and there were 5 more EDK1 releases (ending with 1.06) before EDKII came out. As is known, Apple introduced a number of "think different" protocols, but most of the forward-looking UEFI2 code seems to have come from the original Intel EDK1.01 developers.
• To wit: the Mac Pro 5,1 EFI contains an early version of UEFI 2.0's CreateEventEx, but it's not exposed in the Boot Services table. With a little creative programming, it's possible to use the native CreateEventEx instead of simply wrapping CreateEvent.
• In the same vein, because of its age, the later-deprecated global event types EFI_EVENT_SIGNAL_READY_TO_BOOT (0x0203) and EFI_EVENT_SIGNAL_LEGACY_BOOT (0x0204) are present and usable. Or, using the aforementioned CreateEventEx, GUID-based event groups are also usable.
• If you need to delay BDS for some reason (e.g. a lengthy startup sequence), there's a mechanism to do that cleanly. Protocol EDA517B5-F953-40D6-B900-9AF50079CEE4 consists of a UINT64 boolean flag, and an EFI_EVENT. If you create the event as NOTIFY_WAIT, set the flag to 1, and install the protocol (during startup, or as early as possible), BDS will wait on that event to be signaled before proceeding. (This wait occurs after the three-phase 89342532-E9D4-447F-A856-0D98CF1341EF callback protocol and the WaitForUSB protocol (7737B6C2-5731-4A19-AF2D-70E4AE1B5670), but before BDS console initialization.)

As always, I thank everyone for their patience. With some elbow grease and a little TLC, our cheesegraters should have at least a few more years in them.

 

[PeterHolbrook]

Is there any news about this project that can be shared?

 

[freqrider]

Use the one released with latest OpenCore. It's been out for a while now and reported working fine. @PeterHolbrook