Thanks. I suppose there needs to be an elimination/investigation of what I dub as the
OsxAptioFix Effect
.
So, back in 2017, some chaps started looking into getting bootscreens on cMP with modern GOP Capable GPUs and were looking at rEFInd:
I compiled Jief_Machak's version of rEFInd, that should have support for initializing graphics cards that have a GOP rom on them. Pretty much any resent graphics card should work. If you don't know what rEFInd is, it's basically a boot manager, Jief said he was not able to boot Windows, but I'm...
forums.macrumors.com
In 2018, it finally got to a point where it worked on the MP3,1 but not on the MP5,1 (with AMD GPUs Only):
Awesome, I figured it would work with the 3,1, just don't know why it doesn't seem to with the 5,1. 4,1 untested, as I assume most folks already flashed them to 5,1.
forums.macrumors.com
For some reason though, to also get the Stage 1 loading screen, you needed to load an OsxAptioFix driver:
I think I added this driver to rEFInd..... https://github.com/NTT123/Hackintosh-HP-Z420-MacOS-High-Sierra-10.13-10.14/blob/master/CLOVER/drivers64UEFI/OsxAptioFix2Drv-64.efi
forums.macrumors.com
I started the stuff that would end up as RefindPlus in trying to update the patched rEFInd v0.11.5 instance from that thread to v0.12.0. It was finally cracked sometime in 2020 and as a bonus, the MP5,1 issue was also sorted (Nvidia GPUs on both was sorted later):
Managed to build the current version of Refind (v0.12.0) to give Pre-Boot Configuration Screen (AKA Bootscreen) on all cMP. You may need the "OsxAptioFix3Drv_x64.efi" driver to get Boot Stage 1 Progress bar and/or Verbose Boot and Single User Mode. EDIT: No longer required and actively...
forums.macrumors.com
The OsxAptioFix driver was still needed for full support and stayed that way until someone, I think it was
@joevt, asked the big question of "Why?" in another channel. Macs do not use Aptio boards and do not need the hack stuff on the memory the driver does and the stuff probably doesn't even do anything.
Luckily, the OsxAptioFix driver is OpenSource and after looking and testing stuff, it turned out that it was just about three or so lines of code in the driver that is there as a side show item, not directly related to the memory fix that the driver does, that sorted stuff out on cMP. If the primary aim of memory manipulation gymastics had actually run, it would have messed stuff up.
I think there is a chance something similar is going on with the UsbBusDxe driver in our case.
Current status is:
- XhciDxe
- EDK II Version (AKA OpenCore Version)
- Tested and fails
- OpenSource, so can be looked at
- Clearly requires UEFI 2.x as calls CreateEventEx
- CreateEventEx requirement can be bypassed
- Clover Versions
- Not yet tested ... seems to be more than one version
- OpenSource, so can be looked at (Variants of EDK II Version)
- Initial look suggests misc tweaks done
- Clearly requires UEFI 2.x as calls CreateEventEx
- CreateEventEx requirement can be bypassed
- Trashcan Version
- Tested and works when UsbBusDxe is reinstalled
- Only UsbBusDxe from Trashcan tested
- Not clear whether other versions similarly work
- ClosedSource, so cannot be looked at
- Does not appear to require UEFI 2.x
- UsbBusDxe
- EDK II Version
- Not yet tested
- OpenSource, so can be looked at
- Potential avenue to understand what is happening depending on misc test results
- Potential way to get to "Active Ingredient"
- MP5,1 Version
- Not yet tested
- ClosedSource, so cannot be looked at
- Still would be intersting to know if works like Trashcan version
- Trashcan Version
- Tested and works for fixing XhciDxe ... why exactly?