Possible bug? Mac OS 1st stage boot screen not displayed with UGA video cards

[CornCat78]

Boot picker is visible but no 1st stage (grey background with Apple logo) boot screen. Screen remains gray immediately after OS selection from boot selection menu. 2nd stage (black screen with Apple logo) appears shortly after. Setting OC boot-args to verbose does result in text being displayed during 1st stage boot.

System: Mac Pro 3,1
GPU: Apple EFI Radeon 7950
OS: Catalina 10.15.7

EFI folder and all logs attached.
Archive.zip

Edited to add: video output works correctly on RefindPlus boot picker.

[vit9696]

Is GOP supported on this machine? It is required for both macOS (EfiBoot & XNU kernel) and OpenCore (in graphics mode, e.g. OpenCanopy).

Without GOP macOS kernel will not be able to print anything onscreen before GPU driver initialisation (2nd stage). The verbose text you saw is likely not from macOS kernel, but actually from EfiBoot, which is printed by EFI protocols (potentially relying on UGA), not by framebuffer rendering.

Many OpenCore features also require GOP. For example, Builtin text renderer and OpenCanopy need it. According to the log there are no GOP protocols at all. Fortunately TextRenderer is reset back SystemText without aborting the boot process, and OpenCanopy seems to be unused:

02:822 00:048 OCC: Failed to find handles with GOP
02:860 00:037 OCC: Using builtin text renderer with 1 scale
02:898 00:038 OCC: ASCII Text Reset [HandleProtocolFallback] - Not Found
02:930 00:032 OCC: Setup ASCII Output - Not Found

Currently OpenCore does not have UGA → GOP conversion. Only GOP → UGA via UgaPassThrough to be able to use new GPUs with 10.4 and similar. To workaround your issue I believe we can implement GOP protocol on top of UGA. Is it what is required?

[CornCat78]

Hello Vitaly, I'm unsure. The Mac Pro 3,1 should support GOP cards. The Radeon 7950 should also support GOP but since it was flashed with an Apple EFI BIOS, I can't test. I can confirm that I do get a graphical boot picker via RefindPlus which is chain loading OpenCore. If it's possible to implement GOP protocol over UGA, I will be willing to test it out. Thank you. Edit: I should mention that 1st stage boot screen is visible if OpenCore is taken out of the equation. ⁣

[CornCat78]

Just did some more research. While my MP3,1 is an EFI64 machine, I do not believe GOP is supported.

[dakanji]

@vit9696

MacPro3,1 supports GOP but unlike MacPro5,1 does not have GOP on the ConsoleOut Handle (know the MacPro5,1 one is problematic and needs ProvideConsoleGOP to get around issues).

Anyway, I use a MacPro3,1 and you will note that the OP stated that it works in RefindPlus.

This is because I have done this in RefindPlus:

• Mapped deprecated gBS->HandleProtocol to gBS->OpenProtocol as per UEFI Specs
• More importantly, gBS->OpenProtocol is itself mapped to an OpenProtocolEx function

The OpenProtocolEx function includes bits from your ConsoleHandleProtocol function

Your ConsoleHandleProtocol function returns early on MacPro3,1 as it does not have the ConsoleOut GOP issues the MacPro5,1 has. As a result, the part that sorts out the GOP interface and fixes the loading screen is not run on MacPro3,1.

I brought this bit into RefindPlus and amended it to drop the UGA bit in the if/else as this was causing problems.
By mapping HandleProtocol/OpenProtocol to include this, the Stage 1 Loading Screen is fixed in RefindPlus.

RefindPlusOpenProtocolEx function: https://github.com/dakanji/RefindPlus/blob/180a848c7bd44c583844c1416c7b921f6b1e1a6e/MainRP/main.c#L616

Basically, sorting the interface out fixes the Stage 1 Loading Screen in both MacPro3,1 and MacPro5,1. Not tested MacPro4,1 but sure it works there as well. Also, no issues reported or expected on non-Macs as it only works when specifically needed.

[vit9696]

@dakanji

According to:

02:822 00:048 OCC: Failed to find handles with GOP

There are no GOP protocol instances anywhere on the platform. The failed function is essentially what you have:

  Status = gBS->LocateHandleBuffer (
    ByProtocol,
    &gEfiGraphicsOutputProtocolGuid,
    NULL,
    &HandleCount,
    &HandleBuffer
    );

Unless rEFInd proxies UGA to GOP, it is a mystery to me what is being talked about. There are no GOP protocols, neither on ConsoleHandle, nor on any other handle.

[dakanji]

See what you mean.

Must admit the fix was confirmed on RX 580 which uses GOP. Stage 1 Loading shows up with that after the mapping.

Assumed it would be the same on his but yes, he is on a GPU with UGA and as the ConsoleOut Handle on MacPro3,1 does not have GOP, then there will be no GOP to work with in the first place.

Not sure why it works in RefindPlus and not OC then. I suppose GOP on UGA would be a possible interesting fix.

[vit9696]

Hrm. While it is unrelated to this issue, given the information you gave me, I do want to hear the exact details why do you think OC is broken on MP3,1 with RX 580. Whenever GOP is not found ConsoleHandleProtocol returns mConsoleGraphicsOutput instance, which is set through the else branch here:

https://github.com/acidanthera/OpenCorePkg/blob/f3502e7336784ed194b7c423c0881d5366b4d346/Library/OcConsoleLib/ConsoleGop.c#L179-L194

Unless LocateProtocol function, which finds protocol on any handle, is broken, I do not see why would genuine OC fail. In the case LocateProtocol is indeed broken, at the very least you would get Missing compatible GOP in the log with a return code I would like to know.

[dakanji]

Need to go back and check the scope of the fix. Might have been RefindPlus specific.

I use both and sometimes get mixed up on which items was being addressed but pretty sure Stage 1 Loading Screen was not showing on OC ... will confirm and raise separate issue if so to not derail the OP's issue.

[dakanji]

EDIT: Late here for me ... Will get back to this tomorrow!
Quick response: cMP3,1 always fails this test as the previous gBS->HandleProtocol check for GOP on the ConsoleOut Handle will return EFI_UNSUPPORTED. It therefore never enters the code block.

cMP5,1 returns EFI_SUCCESS for the same test given that it has a mutant GOP instance on the ConsoleOut Handle.
EDIT: Late here for me ... Will get back to this tomorrow!

[vit9696]

Quick response: cMP3,1 always fails this test as the previous gBS->HandleProtocol check for GOP on the ConsoleOut Handle will return EFI_UNSUPPORTED. It therefore never enters the code block.

This is expected. It should go to:

https://github.com/acidanthera/OpenCorePkg/blob/f3502e7336784ed194b7c423c0881d5366b4d346/Library/OcConsoleLib/ConsoleGop.c#L180

And then assign the GOP handle to mConsoleGraphicsOutput here:

https://github.com/acidanthera/OpenCorePkg/blob/f3502e7336784ed194b7c423c0881d5366b4d346/Library/OcConsoleLib/ConsoleGop.c#L194

So that this check in ConsoleHandleProtocol will succeed:

https://github.com/acidanthera/OpenCorePkg/blob/f3502e7336784ed194b7c423c0881d5366b4d346/Library/OcConsoleLib/ConsoleGop.c#L71

It is late here too, let's continue tomorrow.

[dakanji]

Mixed up what was being fixed.
It was Nvidia GPUs which did not show the Stage 1 Loading Screen after the fix here was applied: #1280

[PMheart]

@CornCat78 Could you please try the new GopPassThrough in config.plist->UEFI->Output? You can download pre-built binaries here.

If the link above does not work, please visit here instead and download Artifacts there.

If GopPassThrough works then I believe that we can close this issue by merging acidanthera/OpenCorePkg#211.

[CornCat78]

Thank you @PMheart. I'll test later this afternoon and report back with my findings. For the purpose of the test, can I just copy the GopPassThrough entry from the sample.plist into my existing, or are there other new entries unique to v067 that need to be copied as well in order to boot?

And just to confirm for the actual update, I only need to replace BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi?

[PMheart]

Thank you @PMheart. I'll test later this afternoon and report back with my findings. For the purpose of the test, can I just copy the GopPassThrough entry from the sample.plist into my existing, or are there other new entries unique to v067 that need to be copied as well in order to boot?

And just to confirm for the actual update, I only need to replace BOOTx64.efi, OpenCore.efi, and OpenRuntime.efi?

Yes, definitely! Just copy it, and make sure ocvalidate does not complain about anything.

Regarding file changes, the former two should be updated, yet I don’t think there is any need to touch OpenRuntime.efi since there is no change made to it.

Also, you need to update config.plist. ;)
If you also use Vault, please update it with CreateVault too I believe.

Hopefully this helps.

[CornCat78]

Just tested. Unfortunately I still only get a grey screen for 1st stage boot of Mac OS. Confirmed that v067 is running:

I'm attaching config.plist which was modified to include GopPassThrough as well as the log file.

opencore-2021-02-17-160214.txt
config.plist.zip

[vit9696]

Try the latest version when it lands, I wonder if the priorities were not well-set.

[vit9696]

The latest PR binaries are available on the artifacts page https://github.com/acidanthera/OpenCorePkg/actions/runs/575419667.

[CornCat78]

The latest PR binaries are available on the artifacts page https://github.com/acidanthera/OpenCorePkg/actions/runs/575419667.

Just updated with the latest binary; still no 1st stage boot screen.

Perhaps it's a config error on my end? When GopPassThrough is enabled, should UgaPassThrough be disabled? It is currently enabled in my config.plist.

Latest logs attached.
opencore-2021-02-18-111857.txt

This is certainly different from previous log entries:

[PMheart]

Worth trying with it disabled I think.

[vit9696]

You forgot to enable ProvideConsoleGop. Also update to the latest version once it lands. And indeed UGA pass through makes no sense for your setup.

[PMheart]

Sorry, I forgot to mention it too. Pushed requirements to the testing branch.

[PMheart]

@CornCat78 You can test the new one here. Please go with ProvideConsoleGop and GopPassThrough enabled, but with UgaPassThrough disabled. Thanks.

[CornCat78]

@CornCat78 You can test the new one here. Please go with ProvideConsoleGop and GopPassThrough enabled, but with UgaPassThrough disabled. Thanks.

Updated to latest binary:

Also ensured ProvideConsoleGop and GopPassThrough are enabled, with UgaPassThrough as disabled.

Unfortunately still no 1st stage boot screen, and I lost second stage boot screen as well. After bootpicker, screen remains grey until MacOS login window.

Config.plist and latest log attached.
config.plist.zip
opencore-2021-02-19-094335.txt

[vit9696]

Ok, the situation seems clear to me:

• With rEFInd you do not see 1st stage boot screen, but only some parts of EfiBoot output, which happen in UEFI mode, and which you mistake with the 1st stage boot screen. I.e. you cannot see early XNU output with rEFInd (as well).
• Second stage boot screen "loss" is likely boot attempt dependent, as the system does not boot the same way all the time. Sometimes it does show Apple logo, sometimes it boots straight to the login window, depending on how quickly GPU drivers initialise. I can imagine different OC properties to affect it, but this is not "a bug".
• Your GPU apparently provides no framebuffer information to the UEFI environment, so it is simply not possible to hand it to EfiBoot (and thus XNU).

The last part is confirmed by this part of the log:

04:674 00:056 OCC: Found 0 handles with GOP draw
04:735 00:060 OCC: Found 1 handles with Apple Framebuffer info
04:793 00:057 OCC: Found 3 handles with UGA for GOP check
04:849 00:056 OCC: Trying handle 0 - 7E7A4718
04:908 00:058 OCC: Installed GOP protocol - Success (Handle 0 - 7E7A4718, Resolution 1920x1080, FramebufferBase 0, PixelFormat 3)
04:966 00:057 OCC: Trying handle 1 - 7E32AD98
05:016 00:050 OCC: Installed GOP protocol - Success (Handle 1 - 7E32AD98, Resolution 640x480, FramebufferBase 0, PixelFormat 3)
05:077 00:060 OCC: Trying handle 2 - 7E192D18
05:133 00:055 OCC: Installed GOP protocol - Success (Handle 2 - 7E192D18, Resolution 1920x1080, FramebufferBase 0, PixelFormat 3)

Note, that all the handles with UGA protocols have no Apple Framebuffer handles (FramebufferBase is 0), and as a result there is no real way for XNU to draw anything onscreen till the driver init.

According to Found 1 handles with Apple Framebuffer info, there seems to exist some stray handle with Apple Framebuffer protocol. There is a slight chance it points to something usable, but it was not the case on MP4,1 at least. @PMheart can you try that handle maybe and print something in the log perhaps?

[vit9696]

@CornCat78 is that GPU officially supported by Apple? Because apparently Apple-flashed GPUs should have Apple Framebuffer info protocols, but this one clearly does not have any.

[CornCat78]

@CornCat78 is that GPU officially supported by Apple? Because apparently Apple-flashed GPUs should have Apple Framebuffer info protocols, but this one clearly does not have any.

Yes, the Radeon 7950 is an officially supported card by Apple. In fact, there was Mac edition of this card that was sold by Apple at one point, of which I believe this EFI BIOS is based on.

[vit9696]

Right, so this GPU was manually flashed with Apple EFI? Then I believe this EFI BIOS is simply incompatible with XNU kernel. We will make a test of that only Apple Framebuffer info we found, but I do not have many hopes on it. No framebuffer information on all relevant handles is absolutely clear to me from the log.

CC @dakanji

[vit9696]

Well, with GOP GPUs it may, but this is UGA. I changed this to do nothing when no GOP is available in 0.6.7 anyway...

[CornCat78]

@vit9696 unfortunately halted on critical error with OpenCanopy installed. Perhaps it's something with config.plist? Attaching that as well as logs here.
opencore-2021-02-21-130426.txt

config.plist.zip

P.S. took the resources folder from https://github.com/acidanthera/OcBinaryData and copied to EFI/OC. All files should be in the correct position.

[vit9696]

Good. For this to work (as well as FileVault 2) you need GopPassThrough (not included in the build above). Please check
OpenCore-65aa4eda-NOOPT.zip for both OpenCanopy and 1st stage. If both work fine, also check FV2 (could do later).

[CornCat78]

@vit9696 so good news and bad news. Good news is that OpenCanopy works:

Bad news is that while 1st stage boot screen also appears, the Apple logo oddly has disappeared. Only thing visible is the horizontal loading bar.

Logs attached for review.
opencore-2021-02-21-131657.txt

[vit9696]

Hmmm. Is this consistent? Could you try this version: OpenCore-65aa4eda-NOOPT-T1.zip?

[vit9696]

Also, please try SystemGeneric renderer with both T1 and the previous build.

[CornCat78]

T1 build works. OpenCanopy loads and 1st stage boot screen is complete:

Give me a few minutes to test and revert on the SystemGeneric renderer.

Logs for T1 attached below.
opencore-2021-02-21-133444.txt

[dakanji]

@vit9696 ... ok to add this to docs?

  \emph{Note}: This property is only active when GOP is available and is
  disabled otherwise (is always equivalent to \texttt{false}).

[CornCat78]

@vit9696 sorry, but can you confirm that the TextRenderer value should be changed from BuiltinGraphics to SystemGeneric?

[vit9696]

@dakanji Could do, yes. Maybe Current implementation behind will only be active when GOP…

@CornCat78 yeah.

[CornCat78]

@vit9696 NOOPT build with renderer set to SystemGeneric:

• OpenCanopy works
• 1st stage boot screen replaced with previous static verbose output until login window
  

See attached log. Will test with T1 build now.
opencore-2021-02-21-135652.txt

[dakanji]

Just to close out the now redundant RP tests, the AppleFramebuffer is available before RP is loaded and is available as the first line of code in the entry function.

[CornCat78]

@vit9696 NOOPT-1 build using SystemGeneric renderer results in the following:

• OpenCanopy functional
• 1st stage bootscreen with Apple logo and status loading bar visible and functional

Logs attached.
opencore-2021-02-21-140733.txt

[dakanji]

Assume these are all with AppleFramebuffer set to false.

Not doubting @vit9696 but can you confirm that everything works when that is set back to true (as it should when that setting is ignored)?

Not on 0.6.6 obviously

[vit9696]

Good. I updated the GopPassThrough PR with the latest changes. Please make sure this version works fine with both
SystemGeneric and BuiltinGraphics. If it is ok, I will push it to master OpenCore-4c8a2de6-NOOPT.zip

[CornCat78]

@dakanji yes, AppleFramebufferInfo was set to false for both NOOPT and NOOPT-1 tests.
@vit9696 sure, give me a few minutes to test. Will revert shortly.

[dakanji]

yes, AppleFramebufferInfo was set to false for both NOOPT and NOOPT-1 tests.

Please test whatever is the "final" one with it set to true at some point. Just to close everything out.

Thanks

[CornCat78]

@vit9696 just completed testing the latest build toggling between SystemGeneric and BuiltinGraphics. In both instances, OpenCanopy and 1st stage boot screen were visible and functional. Logs are included below.

1. BuiltinGraphics:
   opencore-2021-02-21-142342.txt

2. SystemGeneric:
   opencore-2021-02-21-142805.txt

For a MP3,1 with UGA such as mine, what is the optimal setting you would recommend using?

[CornCat78]

@dakanji , sure. Will test that now and provide you with the results and corresponding log. Give me a few minutes.

[CornCat78]

@dakanji, in order to be thorough I tested AppleFramebufferInfo set to True with both SystemGeneric and BuiltinGraphics. Results and logs follow:

1. SystemGeneric: OpenCanopy is visible and functional. 1st stage boot screen shows black screen with initial verbose output (photo previously provided about an hour ago) until login prompt.
   opencore-2021-02-21-144009.txt

2. BuiltinGraphics: OpenCanopy is visible and functional. 1st stage boot results in blank grey screen until login prompt.
   opencore-2021-02-21-144433.txt

And I just want to say thanks to you, Dayo and especially @vit9696, as well as @PMheart and @startergo . All of you guys are amazing. I've learned so much about OpenCore and even RP through this experience. I really appreciate all the work you do.

[vit9696]

@CornCat78 I would recommend BuiltinGraphics as it should give better text output.

As for AppleFramebufferInfo=YES, I am puzzled. Are you sure you made these tests with OpenCore-4c8a2de6-NOOPT.zip? Because there should be no difference with this build whether you have AppleFramebufferInfo=YES or AppleFramebufferInfo=NO.

[CornCat78]

@vit9696 regarding my tests with AppleFrameBufferInfo set to YES, I used the last build you provided at this link: https://github.com/acidanthera/bugtracker/files/6017846/OpenCore-4c8a2de6-NOOPT.zip

[vit9696]

Found it. Please retest that this build does not harm you with AppleFrameBufferInfo set to YES. All committed to master.

OpenCore-484c91d3-NOOPT.zip

[dakanji]

@vit9696 ... regarding GOP Pass Thru, is there any undesirable feedback when UGA Pass Thru is also set?
If so, should one of them not be set up such that it disables the other when it is set? That is, make them mutually exclusive if there is indeed such undesirable feedback?

[CornCat78]

Found it. Please retest that this build does not harm you with AppleFrameBufferInfo set to YES. All committed to master.

OpenCore-484c91d3-NOOPT.zip

Yes, this build works perfectly with AppleFrameBufferInfo set to YES. OpenCanopy is functional, followed by 1st stage boot screen, then ironically enough, 2nd stage boot screen appeared as well.
Thank you again @vit9696.

Logs attached:
opencore-2021-02-21-152342.txt

[vit9696]

GOP Pass Thru and UGA Pass Thru can be enabled together. They are harmless.

[dakanji]

2nd stage boot screen appeared as well

Seems an enhancement. Even over directly booting ... https://youtu.be/iSh405fhaHI