GOP boot screen with Nvidia videocards on EFI1.1 platforms

[startergo]

@vit9696 as you know the Nvidia cards do not produce boot screen in OC on EFI 1.1 platforms like cMP. Lately we have been working on this issue. @joevt created a driver FakeEdk2Driver joevtApps.zip to hack the EFI version to be 2.x and add the CreateEventEx function to boot services. Then we put the FakeEdk2Driver.efi in the drivers folder of @dakanji RefindPlus to load first and we put the extracted uncompressed NVIDIA GOP EFI ROM loading as a second driver to load (in order) there. As a result the NVIDIA boot screen appeared at boot. See the attached log file.
20v12d2308.txt.zip
Can this functionality be integrated in OC?

[joevt]

Setting the ST->Hdr.Revision is a hack. We might want a UnfakeEdk2Driver to load after the EFI drivers that require the hack are loaded to undo it (but haven't seen a situation yet where that is required).

Only the BS is modified. We might want to do Runtime Services as well, maybe make QueryVariableInfo and QueryCapsuleCapabilities functions that return an error (the former is rarely used by drivers and the latter is not supposed to be used by drivers).

The option roms that are not loaded because of an incompatible version check (as happens without the hack) exist in RAM pointed to by fields in the PciIo protocol. I have a ReloadPCIRom driver that can load from that RAM image (as long as the RAM image is not modified by the driver - some roms may erase the EFI image from RAM after it's decompressed, loaded, and started).

Ultimately, I would like to see boot screen before even the Mac Startup Manager is supposed to appear, using the Driver#### and DriverOrder nvram variables to load the FakeEdk2Driver, ReloadPCIRomDriver, a UGA on top of GOP driver (since Startup Manager probably uses UGA) and a Screenshot driver that doesn't require SimpleTextInEx protocol so a screenshot of the Startup Manager can be taken. With the drivers loaded this way, OpenCore and RefindPlus don't need to do that work.

[vit9696]

I believe it is ok to bump the BS version to 2.x without the ability to revert as it is really unlikely that anybody will real behave incorrectly with this change. I believe that it should become a quirk in OpenCore named UpgradeBootServices or something like that. Similarly I believe it is ok to add another UEFI quirk ReloadOptionRoms to reload the NVIDIA drivers.

I am not sure I have time to work on this, but if patches are submitted it will be great to merge them. I do not believe it is possible to do it better as Driver#### is not supported by Mac EFI (from what I know).

[joevt]

I use Driver#### to load apfs.efi instead of apfs ROM patch or dosdude1 apfs patch. I can also use it to load nvme.efi and even ntfs.efi though I don't believe its a good idea to boot Windows EFI on MacPro3,1 - but maybe it can be made safe by doing whatever OpenCore does to make it safe for MacPro5,1?

With Driver####, I can see APFS partitions in the built-in Mac Startup Manager (hold option key at boot).
https://forums.macrumors.com/threads/macos-10-14-mojave-on-unsupported-macs-thread.2121473/post-29153786
https://forums.macrumors.com/threads/mac-pro-3-1-nvme-support-upgrade-guide-questions.2194878/post-28956730

Some other misc stuff:

Here's an example of booting the Startup Manager directly (aka BootPicker):
https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28956775
It uses a similar Device Path that the Boot Camp boot would use (when you select a Windows partition in the Startup Disk preferences panel).

There's a way to run either app (BootPicker or Boot Camp) from the EFI Shell:
https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28964173

rEFInd boots BIOS Boot Camp on old Macs by looking for certain known device paths.

[vit9696]

I guess in older Mac EFI Boot#### paths were indeed supported. That was dropped in 2015 or so due to security reasons. Perhaps MacPro3,1 firmware was simply left not updated.

In any case my points hold mostly. Ideally we get a patch for these in time for 0.6.4. Similarly for MBR booting.

[joevt]

I think I've only heard from one other person using my Driver#### info. Maybe you're right and newer Macs don't support it. I can test on a Mac mini 2018, or MacBook Pro 2015, but I don't think there's a point if they support GOP etc (except, a screenshot driver might be nice to get a screenshot of the Startup Manager).

I guess while we're talking about different boot methods, have you ever found a protocol that deals with the macOS HFS+ Finder Info record (seen using the bless --info command)? An HFS+ partition has a record with a file ID for a boot file. I haven't checked if there's a file system protocol function to convert file id to device path. The file ID usually points to /System/Library/CoreService/boot.efi but it could point to any file. This is one feature of the macOS Startup Manager that is missing from rEFInd and OpenCore. I believe APFS volumes have a similar Finder Info record.

[vit9696]

I am pretty sure it is not possible to set it from UEFI, but most likely bless is able to do it somehow. Have never investigated the exact steps needed, however.

[startergo]

@vit9696 Are the drivers loaded in specific alphabetic/numeric order or randomly? How do we define the loading order?

[startergo]

I created an FFS driver module from the FakeEdk2Driver and inserted it as a second to load driver in the firmware and flashed the firmware:

Upon boot the OC boot screen was visible on the NVIDIA Titan
opencore-2020-11-14-232945.txt
This means that if only the code from the FakeEdk2Driver is loaded early enough OC should find a GOP replacement.

[vit9696]

Well, in this case you could just update your firmwares maybe?

[startergo]

I can but the average user may not be able. Some of them for sure will go for a brick. Also I use pluggable chip which can be easily reprogrammed in case of a brick.

[joevt]

I created an FFS driver module from the FakeEdk2Driver and inserted it as a second to load driver in the firmware and flashed the firmware:

This means that if only the code from the FakeEdk2Driver is loaded early enough OC should find a GOP replacement.

Is Driver#### not early enough to get the same behaviour?

[startergo]

Is Driver#### not early enough to get the same behaviour?

I tried only the 2 drivers loading consecutively with Driver####. Never tried FakeEdk2/FakeUEFI2 on its own through Driver####.

[vit9696]

Well, if there are no plans to upstream it can I just close the issue? Or did I misunderstand the situation?

[startergo]

We are still testing it so it is not ready for upstreaming. This make take a while.

[joevt]

The main issue is: while we can make RefindPlus or OpenCore appear on GOP display, the macOS stage 1, etc. booters may not appear (although I haven't tried OpenCore yet). Well, maybe getting the boot loader to appear is good enough. I don't know enough about the old Mac Pro boot procedure to understand what needs to be changed. Do we need AppleFramebufferInfo modifications (is that a thing on MacPro3,1 - I guess I should look to see if it exists - examine the current values - modify the values)? I don't think RefindPlus has the AppleFramebufferInfo option.

[vit9696]

10.4 EfiBoot uses AppleFramebufferInfo to get the framebuffer base address, which UGA protocol does not offer. I don't know about BootPicker. As for the changes it is really all about merging your driver into OpenCore or not, we can have that for easier maintenance. We do not see much value in making the boot screen available at pre-OpenCore stage.

Actually, keep in mind that we believe it is a good idea to eventually start flashing OpenCore into the firmwares when we get things sorted out here and there.

[startergo]

As for the changes it is really all about merging your driver into OpenCore or not

Do you mean as a driver binary or inside the code?

[vit9696]

I do not think having it merged as a driver is idiomatic for OpenCore, so as a quirk, yes.

[dakanji]

Implementations from RefindPlus:

1. AmendSysTable.c : Call AmendSysTable() to change SystemTable Revision and provide CreateEventEx
2. AcquireGOP.c : Call AcquireGOP() to reload OptionROM and reinstall GOP

[vit9696]

Until there is going to be a PR for this or any further discussion I am closing it. Current solution to embed a firmware driver seems to be more or less ok, and there is not much desire to merge this stuff to OpenCore on your side from what it seems.

[dakanji]

A lot more difficult to incorporate into OC and whether the effort of an attempt is worth it is debatable.

I personally think at this time that it is best to roll the two actions into one driver which those that need this, Kepler users on cMP, can load with OC as needed. Actual full incorporation into OC can be revisited later.

Just my own thoughts.

[vit9696]

Implemented, make sure to test it.

[startergo]

Does not even create a log file:

[vit9696]

Yes, that should be fixed in master. EDK II is borked beyond salvation sometimes.

[startergo]

@startergo, trying the same and I am stuck on "Connecting drivers...". Please advice, how many graphics cards do you have installed and if the cable is connected to the unflashed nvidia or to the one with the Apple firmware?

I have 2 or 3 cards, but only the unflashed NVIDIA was connected to a display. I may have connected GT-120 at some point to select OC. There is something odd though, because I can't boot BS as it panics. I can boot HS (which is HFS+).

[startergo]

When I disabled the 2 quirks it boots normally to Big Sur, so it is definitely related. I have 2 BS partitions one on an NVME and one on an HDD and both of them panicked (did not boot) before.

[priezz]

Well, I could successfully launch OpenCore with the output to the unflashed Nvidia card, but I also have the issue booting Big Sur (from SATA), so I think it could be connected with some changes in 0.6.9.

[vit9696]

Well, any panic log? Could use ApplePanic feature to save it on ESP or make a photo. Make sure keepsyms=1 is provided.

[priezz]

There was just one panic and in all the other cases OS is just stuck on the boot (the bar is about 30% long). The odd thing is that com.apple.driver.AppleIntelMCEReporter is being loaded when it should not (AppleMCEReporterDisabler.kext is enabled in the config). So here is the panic log, two OC logs and the OC config.

panic-2021-04-14-005158.txt
opencore-2021-04-14-005152.txt
opencore-2021-04-14-004549.txt
config.plist.txt

Edit: ApplePanic is enabled, keepsyms=1 is provided.

[vit9696]

I do not know about AppleMCEReporterDisabler.kext, but there is a boot argument (-nehalem_error_disable) to reliably turn it off.

[priezz]

I do not know about AppleMCEReporterDisabler.kext, but there is a boot argument (-nehalem_error_disable) to reliably turn it off.

The doc gives an advice that this param disables AppleTyMCEDriver. Is AppleIntelMCEReporter a part of that?

[vit9696]

Oh, I thought you meant the other one. Then it is quite strange. No, these are entirely separate drivers.

According to the log you have no kext injection at all. Are you sure you have kexts enabled? It will help to see another OS booting.

[priezz]

Are you sure you have kexts enabled?
They are enabled in the config (attached in the prev post). The same config works well with 0.6.8, which knows nothing about the two new quirks.

[vit9696]

Right, I think I know the reason. Please try acidanthera/OpenCorePkg@3bcd69d once it builds.

[priezz]

I have just tried the most recent build (#9ca899d). Here are the findings:

1. Still no video when the other card (GT 120) is installed. I have tried 3 scenarios:
   a) cable plugged to the card with metal support (GTX 780 Ti)
   b) cable plugged to GT 120
   c) cable plugged to GT 120 and re-plugged to GTX 780 before pressing the return key on the EFI choice at the native boot menu;
2. Big Sur hanged at the bootscreen on the first try (waited > 30 min) but booted normally on the second one.

The logs are attached.
novideo-2021-04-15-142112.txt
novideo-2021-04-15-143141.txt
novideo-2021-04-15-143552.txt
hanged-on-bootscreen-2021-04-15-144130.txt
normal-2021-04-15-160200.txt

[vit9696]

Well, there is no plan to support GT 120 and GTX 780 at the same time. The firmware does not play all too well in this case, and there is little reason for us to debug. Does it work fine with just the GTX 780 installed with Big Sur?

[startergo]

1. Still no video when the other card (GT 120) is installed.

If there is an EFI card installed, but not connected to a display it will not work. It never did even with AMD. If there are 2 AMD's one with EFI vbios and one without, the boot screen will always appear on the EFI card and if it is not connected to a display it will not boot. If there are no EFI cards installed disconnecting the display will leave that card in a dormant state and the initialization will occur on the card connected to a display.

[vit9696]

@startergo does BS work for you with the latest build on an NVIDIA GPU?

[startergo]

Big Sur and Catalina boot without a problem
opencore-2021-04-15-181918.txt
opencore-2021-04-15-183921.txt

[priezz]

@vit9696 , is it possible to ignore/disable the installed GT 120? It is not likely to remove it completely from the system as soon as at the moment it is the only way to have the native boot menu.

[joevt]

@vit9696 , is it possible to ignore/disable the installed GT 120? It is not likely to remove it completely from the system as soon as at the moment it is the only way to have the native boot menu.

I suppose any action that has an "apply to all" semantic, such as loading GOP from all GPUs that don't have GOP, should have an ability to ignore specific cases - either by device location (EFI device path) or IDs (vendor/product combo) or whatever.

[startergo]

is it possible to ignore/disable the installed GT 120?

Can you please elaborate what are you trying to achieve? If you want to disable the GT-120 while booted to OSX that is possible. It will still be active for the Apple and Opencore bootpickers, but will be disabled half way during boot from the bootpicker to the login screen. You can either disable the driver in the device properties:
https://forums.macrumors.com/threads/opencore-on-mac-pro-7-1.2283835/post-29590262
or through SSDT:
https://forums.macrumors.com/threads/opencore-on-mac-pro-7-1.2283835/post-29726901

[vit9696]

I do not think GT 120 gets its Option ROM reloaded. Rather it dies for another reason. Since the Option ROM loading code checks for child handles if I remember correctly.

[priezz]

is it possible to ignore/disable the installed GT 120?

Can you please elaborate what are you trying to achieve?

For some reason there is no video output to my GTX 780 when GT 120 is installed (even when HDMI cord is plugged into 780 only). So I want OpenCore to ignore 120. Ideally OpenCore could ignore all cards with no display connected.

[vit9696]

It is not about OpenCore, it is about your firmware, I am afraid.

[startergo]

For some reason there is no video output to my GTX 780 when GT 120 is installed

As I said it will not happen. The boot screen will be on the GT-120. GT-120 must be connected to a display. Not only that. The system will not boot if the display is not connected to GT-120.

[dakanji]

There is a potential issue as this creates an incomplete UEFI 2.x implementation and users will have issues if they chainload anything from OC that may try to use UEFI 2.x specific functionality.

OC basically needs to restore things back to the original setup before it boots anything so as not to pass an essentially broken table on.

[vit9696]

I do not believe there is any real situation as CreateEventEx is the only function added, and we implemented it to a certain level.

[dakanji]

As an example, rEFInd (and variants) will test for UEFI 2.x. If detected, they will try to use gRT->QueryVariableInfo which will not be present.

Some, such as MacPro3,1 users, may chain-load rEFInd so as to boot into Legacy Windows. They should chain-load OC from RP and boot Legacy Windows directly from RP of course, but people are stubborn ;-)

PS: Situation in this case arises because the tools would have queried the revision on gBS or gST earlier, stashed the result then use this to decide on a gRT call later but it is not unreasonable to expect that the revisions would be the same.

Seems there is a potential for other situations to arise.

[vit9696]

gRT has HeaderVersion field. rEFInd should check it instead.

[dakanji]

PS: Situation in this case arises because the tools would have queried the revision on gBS or gST earlier, stashed the result then use this to decide on a gRT call later but it is not unreasonable to expect that the revisions would be the same.

That is just an example btw. Point is that OC is changing something fundamental which something downstream (not necessarily rEFInd) will not be expecting to be changed.

[mhaeuser]

That is just an example btw. Point is that OC is changing something fundamental which something downstream (not necessarily rEFInd) will not be expecting to be changed.

@dakanji It is a rarely needed quirk, and only broken code dies. If you give us an example where it is non-trivial to just update downstream, we may adapt it.