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]

opencore-2021-04-13-110919.txt Stuck at the beginning.

[vit9696]

Do not see any issue on our end and the new code is not even able. Must be some issue at yours. E.g. corrupted ESP.

[startergo]

If I disable ForgeUefiSupport and ReloadOptionRoms it boots normally. opencore-2021-04-13-171026.txt Although OpenCanopy stopped working recently

[vit9696]

Which of the two causes it?

[startergo]

I don't think the OpenCanopy issue is related to the GOP reload change it happened before that.

[vit9696]

OpenCanopy could be related to resource updates.

[startergo]

That was first thing I tried. Resource updates did not help (actually did not see them updated either)

[vit9696]

cc @mhaeuser

[mhaeuser]

That was first thing I tried. Resource updates did not help (actually did not see them updated either)

They will help when you properly overwrite all files. :)

[startergo]

Just replaced the whole directory and it worked. Apparently update newer files (merge folder) does not work here. (talking about OpenCanopy only)

[dakanji]

@startergo ... is RP in the picture?

You might want to soft bless OC and boot directly if so (to make sure RP is not impacting anything ... thinking about the ReloadGOP bit which it also does)

[startergo]

@startergo ... is RP in the picture?

You might want to soft bless OC and boot directly if so (to make sure RP is not impacting anything ... thinking about the ReloadGOP bit which it also does)

I disabled that feature in RP.

[vit9696]

You were ask to report which of the two quirks causes a hang. Also, disabling RP is a requirement at least during the tests.

[startergo]

I thought both of them have to be enabled?

[vit9696]

Correct. But that does not change my question.

[startergo]

Anyway it is the ForgeUefiSupport which hangs. RP or no RP it does not matter. opencore-2021-04-13-195157.txt opencore-2021-04-13-200007.txt The second log is with only ReloadOptionRoms enabled

[vit9696]

Thx, please recheck master. I believe I identified and fixed at least one issue.

[startergo]

opencore-2021-04-13-225912.txt Another error

[vit9696]

This one is fixed in master. Was pushed some time after the message.

[vit9696]

@dakanji did you have any issues with driver connection after enabling NVIDIA Option ROM loading? Seems to hang there…

[startergo]

Works now. I had some kernel panics with Big Sur, but HS booted fine and OpenCanopy was working always Archive.zip

[priezz]

@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?

[dakanji]

did you have any issues with driver connection after enabling NVIDIA Option ROM loading?

Don't actually use these GPU but got no reports so far. @startergo was a tester at the time (I believe still uses this) and can chime in.

BTW, "MyFreePool" is a convenience function that always checks if the pointer is NULL and only applies "FreePool" when it is not NULL. So there is some laziness in using it that needs checking if using FreePool directly.

EDIT: The procedure is actually implemented in RefindPlus after drivers have already been loaded.

• Prelims
• Load Drivers
• Connect Devices to Controllers
• Check for GOP on device paths
• Tweak System Table and attempt to Reload GOP if not present on any device path
• Reconnect devices if GOP was reloaded
• Restore System Table if changed earlier
• Continue

[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.