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: https://github.com/acidanthera/bugtracker/issues/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 https://github.com/acidanthera/OpenCorePkg/pull/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

[dakanji]

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.

Just to be clear for @vit9696 benefit that your particular version is not an official version but flashed with an EFI that you believe is from the official version.

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

For the interested audience, do you mean this looks exactly like the Stage 1 Loading Screen, with Apple Logo and Progress Bar, but is actually not?

[CornCat78]

@vit9696, that is correct. This is a Gigabyte Radeon 7950 that was previously flashed with the Apple EFI BIOS for their version of the 7950. For all intents and purposes, it works exactly as a normal Apple 7950 would.

That said, curious to know how RefindPlus is able to show a graphical boot picker.

@dakanji - yes, I do believe this card was flashed with an EFI from the official version. I could be wrong though.

FWIW, this is what's reported in profiler:

[vit9696]

@CornCat78 can you record the boot process with rEFInd and OpenCore on a video? From power on to login screen. In verbose mode and in non-verbose mode. I.e. a total of 4 videos. That would be the easiest.

For the interested audience, do you mean this looks exactly like the Stage 1 Loading Screen, with Apple Logo and Progress Bar, but is actually not?

I am not positive there is a progress bar (i.e. moving), so I think it is EfiBoot that draws something, then the screen remains unchanged, then GOP starts and continues to draw things.

[CornCat78]

@vit9696 I will try to make the videos and post them to a private YT page later today. Will supply the link here once done.

[CornCat78]

@vit9696 @dakanji - I have made three videos. As RefindPlus is chain loading OC, I was able to show both RefindPlus as well as OC booting Mac OS with verbose off. I have another video of just OC v067 with verbose on. Unfortunately, I could not capture RefindPlus verbose output despite uncommenting set_mac_boot_args "-v". The third video is my MP3,1 booting with RefindPlus and OC disabled.

1. RFP chain loading OC, no verbose: https://youtu.be/EB-tCsgBGyo
2. OC v067 verbose: https://youtu.be/RojhJD5I-xA
3. Normal boot (no RFP/OC): https://youtu.be/iSh405fhaHI

Hopefully the above helps.

Edit: forgot to mention that OC is running the DEBUG release so everything is much slower at boot.

[dakanji]

Thanks but the videos are not quite what was requested.

Also, when you do the two OpenCore ones, do not chain-load. Boot directly into OpenCore.

So...

• Video 1: RP booting into Mac OS (Not Verbose)
• Video 2: RP booting into Mac OS (Verbose)
• Video 3: OC booting into Mac OS (Not Verbose)
• Video 4: OC booting into Mac OS (Verbose)

Videos 3 & 4 should not be with OC chain-loaded to remove potential influence of RP.

[CornCat78]

@dakanji to clarify, you want RefindPlus just to boot into the non-OC instance of Mac OS, both verbose and non-verbose?

Also, uncommenting set_mac_boot_args "-v" in overrides.conf did not result in verbose output displayed on screen. I would be happy to provide both videos if you can tell me what I'm doing wrong with RFP verbose output.

There is already a video of OC booting into Mac OS in verbose, so I will create another with verbose disabled.

[dakanji]

you want RefindPlus just to boot into the non-OC instance of Mac OS, both verbose and non-verbose?

What's what Vit requested, yes.

uncommenting set_mac_boot_args "-v" in overrides.conf did not result in verbose output displayed on screen.

That should have given you the output but can't say why it wouldn't right now. If you right click on the Mac OS icon, I think you will be given an option to boot into verbose mode.

Once done, best to make a list of all four (similar to mine above).

[CornCat78]

Thank you, @dakanji . It is clear now.

@vit9696 , please see four videos as requested:

1. RP booting into Mac OS (not verbose): https://youtu.be/ESw0avSs0wU
2. RP booting into Mac OS (verbose): https://youtu.be/z3AhRWAb-1k
3. OC booting into Mac OS (not verbose): https://youtu.be/_8aXrfQj7QE
4. OC booting into Mac OS (verbose): https://youtu.be/RojhJD5I-xA

[dakanji]

Clearly seems to work on RP.

Without stepping on Vit's toes too much, can you download these two RefindPlus builds and boot directly into Mac OS with each in turn?

https:dakanji.com/X106-107-Archive.zip

No video needed. Just report on whether Stage 1 Screen shows up or not for each.

[PMheart]

I added more logging info to help trace the problem. Please try again once artifacts are ready here.

[startergo]

2. OC v067 verbose: https://youtu.be/RojhJD5I-xA

Interesting sometimes I get the exact same verbose boot., but I thought OC gets stuck so I never waited long enough and I forcefully reboot and on the next reboot I can see all verbose output until login.

[CornCat78]

Clearly seems to work on RP.

Without stepping on Vit's toes too much, can you download these two RefindPlus builds and boot directly into Mac OS with each in turn?

https:dakanji.com/X106-107-Archive.zip

No video needed. Just report on whether Stage 1 Screen shows up or not for each.

Sure, will do so later today (about to start work). Will report back as soon as I have results.

[CornCat78]

@dakanji - was able to test X106 and X107. Both show the 1st stage boot screen.

Edit: working at home due to COVID has its benefits.

[dakanji]

Thanks.

Was a blind test regarding the mapping thing I raised early on.

Your results confirm it is not a factor as one of the two builds had this switched off.

@vit9696 Only other thing I can think of as a difference is that RP uses the UGA instance on the ConsoleOut handle when available, such as on a MacPro3,1. Not sure whether this might be relevant.

[startergo]

@dakanji - was able to test X106 and X107. Both show the 1st stage boot screen.

Edit: working at home due to COVID has its benefits.

@corncat78 Can you try the original rEFInd version?

[CornCat78]

@startergo I could, but it will take me a little time as I'm unfamiliar with configuring rEFInd. That said, I don't know how much help it will be when diagnosing this issue with OC. As was demonstrated, RP is able to show the 1st stage boot screen on Mac EFI/UGA cards. That leads me to think that this is limited to a code issue with OC.

[PMheart]

@CornCat78 Just in case you missed my message above... Could you please try the new builds as well, which can be found here?

[CornCat78]

@CornCat78 Just in case you missed my message above... Could you please try the new builds as well, which can be found here?

Yes, will try the new binary later this afternoon and report back. Thanks!

[CornCat78]

@PMheart I just updated to the latest binary; unfortunately still no 1st stage boot. Please see attached logs.

opencore-2021-02-19-212400.txt

[vit9696]

Well, what we get clearly has nothing. Maybe rEFInd does something special, and Mac EFI starts to provide some protocol suddenly.

@dakanji can you help us? I can tell you that EfiBoot does the code below to get first stage visible. That means, it either uses GOP protocol on the console handle, or first available AppleFramebufferInfo. For us there are no GOP and the only existent AppleFramebufferInfo fails to return the information (as you see above). Perhaps rEFInd does something for it to start working? Could you add logs to see:

• Whether any GOP protocols are available?
• How many AppleFramebufferInfo protocols are available?
• Whether AppleFramebufferInfo starts to return information successfully?
• If it does, when does it happen and what is needed to be executed for that?

UINTN __fastcall DetectDepth(EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *a1)
{
  UINT32 TotalMask; // edx
  UINTN result; // rax
  unsigned int v3; // ecx
  int v4; // eax

  TotalMask = a1->PixelInformation.BlueMask | a1->PixelInformation.RedMask | a1->PixelInformation.GreenMask;
  result = 0i64;
  if ( a1->PixelFormat < (unsigned int)PixelBitMask )
    return 32i64;
  if ( a1->PixelFormat == PixelBitMask )
  {
    v3 = 0;
    v4 = 0;
    do
      v4 += _bittest((const int *)&TotalMask, v3++);
    while ( v3 != 32 );
    result = (v4 + 7) & 0xFFFFFFF8;
  }
  return result;
}

// local variable allocation has failed, the output may be wrong!
signed __int64 __fastcall sub_B808(Boot_Video *VideoInfo, _DWORD *a2)
{
  signed __int64 Status; // rax
  EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE *Mode; // rax
  __int64 FramebufferBase; // rcx
  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info; // rdi
  __int64 (__fastcall **FramebufferInfo)(_QWORD, __int64 *, int *, int *, int *, int *, int *); // [rsp+40h] [rbp-20h] BYREF
  EFI_GRAPHICS_OUTPUT_PROTOCOL *v8; // [rsp+48h] [rbp-18h] OVERLAPPED BYREF

  Status = 0i64;
  FramebufferInfo = 0i64;
  v8 = 0i64;
  if ( a2 )
  {
    Status = (unsigned int)dword_8729C;
    *a2 = dword_8729C;
  }
  if ( gFrameBufferBase )
    goto SET_INFO;
  if ( (gBS->HandleProtocol(*(EFI_HANDLE *)(qword_8B860 + 56), &gEfiGraphicsOutputProtocolGuid, (void **)&v8) & 0x8000000000000000ui64) == 0i64 )
  {
    Mode = v8->Mode;
    FramebufferBase = Mode->FrameBufferBase;
    if ( FramebufferBase )
    {
      Info = Mode->Info;
      gWidth = Info->HorizontalResolution;
      gHeight = Info->VerticalResolution;
      gFrameBufferBase = FramebufferBase;
      gFrameBufferSize = Mode->FrameBufferSize;
      Status = DetectDepth(Info);
      gDepth = Status;
      if ( !(_DWORD)Status )
      {
        gFrameBufferBase = 0i64;
        return Status;
      }
      Status = Info->PixelsPerScanLine * ((unsigned int)Status >> 3);
      gRowBytes = Status;
      goto SET_INFO;
    }
  }
  Status = gBS->LocateProtocol(&gAppleFramebufferInfoProtocolGuid, 0i64, (void **)&FramebufferInfo);
  if ( Status >= 0 && FramebufferInfo )
  {
    Status = (*FramebufferInfo)(
               FramebufferInfo,
               &gFrameBufferBase,
               &gFrameBufferSize,
               &gRowBytes,
               &gWidth,
               &gHeight,
               &gDepth);
    if ( Status < 0 )
    {
      gFrameBufferBase = 0i64;
      Status = 0i64;
      gRowBytes = 0;
      gWidth = 0;
      gHeight = 0;
      gDepth = 0;
    }
SET_INFO:
    if ( VideoInfo )
    {
      VideoInfo->v_baseAddr = gFrameBufferBase;
      VideoInfo->v_rowBytes = gRowBytes;
      VideoInfo->v_width = gWidth;
      VideoInfo->v_height = gHeight;
      Status = (unsigned int)gDepth;
      VideoInfo->v_depth = gDepth;
    }
  }
  return Status;
}

[dakanji]

@vit9696 ... I don't think rEFIt Variant code as in rEFInd/RefindPlus is actually doing anything special anywhere and maybe the answer is in the simple/primitive setup.

On GOP Query ... RefindPlus output from the attachments in the OP:

On AppleFramebuffer Query ... I don't believe this is used at all.

At least the term does not appear anywhere in the code base.

All RefindPlus seems to do is:

• Use either GOP or UGA to provide the boot screen and when the user selects Mac OS,
• Launch StartLoader

StartLoader seems to simply call:

• BeginExternalScreen
  • This just clears the screen and runs ConsoleControl->SetMode as needed
• StoreLoaderName
  • This just stores the loader's name in NVRAM
• StartEFIImage
  • This loads the Apple EFI Loader as a child image and waits for ExitBootServices from that.

It seems to me that all that happens is that RP hands off to the Apple EFI Loader which then basically runs as if executed directly as in the OP's video: https://youtu.be/iSh405fhaHI

Might have missed something but seems this is the (relative) primitive setup that is in place.

[vit9696]

Hmm, maybe it is important which console control mode it is actually (graphics versus text)? @CornCat78 can you redo the logs with this one?

OpenCore-0.6.7-DEBUG.zip

Also, may I have MP3,1 firmware? CC @dakanji