OC not start on last Surface UEFI Firmwire

[butter1232]

Tried a bunch of time over and over and copy efi file not to sure what I’m doing wrong

[badstorm]

Hi, did you disable Secure Boot?

Did you also tried OC debug version?

It seams something block the OC image or the OC .efi file is corrupted.

[butter1232]

I give that a try and I will update you

[butter1232]

Secure Boot Has been disabled the whole time

[butter1232]

Hey it been saying the same thing

Also I put the debug

[butter1232]

[Xiashangning]

I also have this issue, it seems that if you have applied the recent Microsoft Surface Firmware Update(on Jan 7th), then the system will block you completely from booting Opencore. I tried different ways but none of them works.

[badstorm]

Thanks @Xiashangning for this information. With this update only OC is corrupted or also other OS? Have you tried to run Linux? It works?

[butter1232]

Linux work

[Xiashangning]

Yes, like you did, I have tried Ubuntu, Manjaro etc, all of them work except OC. And I have been using SP7 with Big Sur for quite a while until I updated the firmware 4 days ago... After it installed, I cannot get into OC anymore. Sad.
傻 逼 微软！

[badstorm]

Since I think is a OC related problem, I opened a issue here

[badstorm]

@Xiashangning @butter1232 For prevent closing the issue opened replay also you to that issue.

[Xiashangning]

@badstorm so have you tried vit9696's solution? If not, then I will try it now. Hoping that is enough T_T

[badstorm]

My Surface is not udpated with that firmware version, so for now i cannot test. Try and let me know so i can update the configuration in this repo.

[butter1232]

I will let you know

[vit9696]

In addition to the master version please also try acidanthera/bugtracker#1354 (comment).

[Xiashangning]

@vit9696 , I've tried Softkbd-r6.zip and it does not work. By the way, with secure boot disabled, so far only Opencore could not been loaded by the system, Clover however can enter the booting selection screen (though I don't have a bootable config for SP7 using clover), other OS like ubuntu and manjaro work just as before. I doubt that this might be an Opencore specific issue... Perhaps there is something slightly different between Opencore and Clover?

[vit9696]

@Xiashangning i.e. you upgraded to OpenCore 0.6.6 master, and then replaced BOOTx64.efi, Bootstrap.efi, and OpenCore.efi and it failed? What exactly did happen? I would like to see the screenshots and logs from both master version and Softkbd-r6 (if they are created).

Perhaps there is something slightly different between Opencore and Clover?

Unlike Clover and other bootloaders OpenCore is a driver and uses two-stage boot model. Both things are valid UEFI spec-wise.

[Xiashangning]

OK, I will gather the files you need, right now it dinner time so... maybe 2 hours later I will update you what I get.

[Xiashangning]

@vit9696 Sorry for my first comment, I was performing these trials with the boot chain: grub->OC with secure boot enabled.

After I turned off secure boot and boot directly with Opencore, I have done what you asked and indeed the results are different! Here are the screenshots you must take a look at! It seems that this time, with the softkbd-r6, Opencore can read its 'core' file---Opencore.efi, but stops at loading HfsPlus.efi, reporting the same error: Access denied.

Meanwhile, I have read through the issue you mentioned above. It reminds me something. When Opencore and macOS boots, in verbose mode, the little keyboard icon shows periodically at the right-down corner, it shows when a line is completely printed, and disappears when printing another line. This 'feature' might indicate that Surface Pro thinks Opencore is a diag utility as HP does. And this firmware update has applied some so-called security limitations, so Opencore failed to load macOS since then.

The first photo is what I've got with master version

These two is with Softkbd-r6. The last one is just wanting to show you that the icon can be clicked and functions as a screen keyboard.


And the latter method does make Opencore boot, so here is the log file.(There isn't one for the master version since it won't boot)
opencore-2020-10-20-161155.txt

[vit9696]

So, this confirms that Microsoft broke UEFI driver loading through the bootloader in their firmware (thus the Access Denied message), which is a bug on their side. I suggest you file a support inquiry on them.

I am not positive there is an immediate workaround for that, and to be honest I am not sure there even is a complicate way to workaround it. Therefore I strongly advise to refrain from upgrading to this firmware and downgrade if possible.

From you I would like to see:

• all the BIOS preferences available on the laptop
• firmware dump
• trying to boot any OS without any drivers (it will likely fail with macOS, but Windows might work)
• trying to make a working clover setup and/or checking if it can load HFSDriver or it just silently fails

[Xiashangning]

1. All of the BIOS setting are as follow, they are just incredibly few! (STUPID Microsoft)
   BIOS settings.zip

2. Do you mean the BIOS dump? because the firmware update came within the Windows update, and I cannot find the cache files on my disk any more, maybe it got deleted automatically by Windows? (Since the update took place 8 days ago) So what I have now is the BIOS dump via an exe called 'BIOS backup', I don't know the exact size of Surface's BIOS so it is 16M. Maybe someone who haven't updated his firmware yet can download it so we can get the exact update files.
   Or there might exist some software for firmware dumping?
   surface.bin.zip

3. What do you mean trying to boot any OS without any drivers? Is that testing the booting process of Windows, Ubuntu, Manjaro etc. ? Well, they are all just fine (like before) I can enter the desktops of these OS without any issue. Also, Clover seems to behave nothing different.

4. OK, I will try.

[vit9696]

3. I meant removing UEFI Driver entries from config.plist and trying to boot an operating system from OpenCore. E.g. macOS, Windows, Ubuntu.

[Xiashangning]

Nope, I tried Windows PE, it report a software error with black screen and the cursor is invisible(I can move it around and click the task manager I invoked by pressing the keyboard) and Ubuntu boot into a black screen after I choose 'try ubuntu without installing'. macOS stops at the same place, as before and as those HP laptops do. ([EB|#LOG:EXITBS:START])

[Xiashangning]

Sorry I forgot the logs
Ubuntu.txt
windows PE.txt
macOS.txt

[vit9696]

Please return the drivers back and try this OpenCore.efi version instead of the one found in SoftKbd-r6. Keep booters and other files as in r6. I will need the logs.

oops.

[vit9696]

Sorry, uploaded the wrong file in the previous post. This one is correct.

SoftKbd-r6++.zip

[Xiashangning]

This time, the drivers are loaded but Opencore halted at ASSERT [OpenCore] Header.c(59): Context->FileSize != 0 after injecting the kexts.
opencore-2021-01-26-101634.txt

[Xiashangning]

My bad, DirectResetCold.
Okay, in fact I tried to insert the DirectResetCold function somewhere else I thought suspicious, now that I know they are called one after another. I will update you the exact place

[Xiashangning]

@vit9696 I trace the code down to AppleMapPrepareMemState
Since there are two settings in this function, so I have tried all the four combinations and I confirm that it stops at gRT->SetVirtualAddressMap
https://github.com/acidanthera/OpenCorePkg/blob/0.6.6/Library/OcAfterBootCompatLib/KernelSupport.c#L685

[vit9696]

Right, what are your current booter quirks?

[Xiashangning]

The one I am using now is AvoidRuntimeDefrag=YES, ProtectUEFIServices=YES, RebuildAppleMemoryMap=YES and SyncRuntimePermissons=YES and the rest NO

[Xiashangning]

AvoidRuntimeDefrag and SetupVirtualMap are the two settings concerned in AppleMapPrepareMemState and I have tried the 4 possible combinations of them, YES NO; YES YES; NO YES; NO NO.
All stoped at gRT->SetVirtualAddressMap
I could not find the function SetVirtualAddressMap so I am blocked now.

[vit9696]

Not just these. Actually there are several more relevant ones:

• RebuildAppleMemoryMap
• SyncRuntimePermissions
• ProtectUefiServices

The SetVirtualAddressMap is routed to OpenRuntime, here. If you cannot reach this place, then OpenRuntime is not properly mapped for some reason. Why — could be due to these quirks.

[Xiashangning]

To be more precise, the code stops at if(SetupVirtualMap)...else...
I will check it tomorrow, thanks again!
Have a good day/night :D

[vit9696]

Well, check if you can reach OpenRuntime tomorrow…

[Xiashangning]

It does reach OpenRuntime and stops at mCustomSetVirtualAddressMap, once again, please tell me where is its implementation
https://github.com/acidanthera/OpenCorePkg/blob/0.6.6/Platform/OpenRuntime/UefiRuntimeServices.c#L767

[vit9696]

Here: https://github.com/acidanthera/OpenCorePkg/blob/0.6.6/Library/OcAfterBootCompatLib/ServiceOverrides.c#L1010

[Xiashangning]

What? So you mean the calling sequence is
OcSetVirtualAddressMap => AppleMapPrepareMemState => gRT->SetVirtualAddressMap => WrapSetVirtualAddressMap => mCustomSetVirtualAddressMap => OcSetVirtualAddressMap => AppleMapPrepareMemState, then the code recalled ProtectRtMemoryFromRelocation for the second time and next called gRT->SetVirtualAddressMap but this time it is the original implementation by UEFI firmware(mSetVirtualAddressMap)?

[vit9696]

The calling sequence is:

• OcStartImage
• EfiBoot code
• OcGetMemoryMap (possibly many times)
• EfiBoot code
• OcExitBootServices
• EfiBoot code
• WrapSetVirtualAddressMap in OpenRuntime (gRT->SetVirtualAddressMap points to it for EfiBoot)
• OcSetVirtualAddressMap in OpenCore (OcAfterBootCompatLib, it is mCustomSetVirtualAddressMap indeed)
• AppleMapPrepareMemState
• Eventually gRT->SetVirtualAddressMap, which now points to original BIOS SetVirtualAddressMap. Through either PerformRtMemoryVirtualMapping or direct gRT->SetVirtualAddressMap.
• EfiBoot code
• AppleMapPrepareKernelState
• XNU code

[Xiashangning]

Understood, so it actually stops at the original BIOS SetVirtualAddressMap, then is there anything I can do to go further? I am now trying with the quirk SetupVirtualMap=YES and testing where the code stops inside PerformRtMemoryVirtualMapping

[Xiashangning]

But as your document says, modern firmware with memory protection doesn't support the quirk SetupVirtualMap, so I am wondering if testing SetupVirtualMap=YES won't help, for now I find that it stops inside the for loop of PerformRtMemoryVirtualMapping, still debuging...

[vit9696]

Whether or not SetupVirtualMap quirk is supported — it depends, but indeed it should neither be needed with modern firmware, nor it actually is supported. The explanation is provided in this issue: acidanthera/bugtracker#719.

If the code does not proceed after calling the original BIOS SetVirtualAddressMap, i.e. both with this quirk enabled and disabled, then it is very worrying. Basically there could be two possibilities:

• Either it indeed dies within the BIOS services, and we will need to understand what is special with the OC compared to e.g. Windows bootloader.
• Or it simply cannot reboot after SetupVirtualMap through DirectResetCold. In this case we can try using other methods to check whether the code is reachable. For instance, we can write memory to RTC and check after a hard reboot.

[Xiashangning]

Suppose that we cannot reboot using DirectResetCold, could you please tell me how to write RTC into memory in code and then how can I obtain it(through OpenShell?)
PS: I have searched online for tutorials about UEFI BIOS and try to learn something by myself. I am a programmer but unfortunately not in this domain...

[vit9696]

You can use https://github.com/acidanthera/OpenCorePkg/blob/0.6.6/Include/Acidanthera/Library/OcRtcLib.h. Please add the library dependency to the .inf file as needed (see LibraryClasses). Write some value at a reasonably high index (e.g. 255, so it does not collide with the firmware) and use RtcRw.efi to read it from Shell.

[vit9696]

I believe we did get things to move, at least on some models. Please check acidanthera/bugtracker#1486 (comment). This may be able to help with Microsoft Surface as well.

[Xiashangning]

@vit9696 !!! That is exactly what the Surface Pro series need !!!
I have built the master version of OC and enabled SetupVirtualMap.
macOS boots just smoothly as before T_T finally!
Thank you all for your wonderful work!

[badstorm]

@Xiashangning you resolve your issue? What you edited in this configuration to solve the problem?
So i can update this repo.
Thanks

[Xiashangning]

@badstorm Use the master version of OpenCore and enable 'DisableSecurityPolicy' quirk in UEFI section
Besides, I believe the commands for the touchpad are not correct, you should delete all the 'sudo' because with it the commands have no effect. Without 'sudo', the configuration works on my SP7
PS: I have a method to boot macOS with MS Secure Boot on ( using grub to boot OC then macOS), don't know if you want to have a try.

[Xiashangning]

In that way, we can remove the annoying red unlock icon

[badstorm]

Sure, if you want to help imporving this configuration you are very welcome. Please send a PR with this booting alternative so we can test it.

About Besides, I believe the commands for the touchpad are not correct, you should delete all the 'sudo' because with it the commands have no effect. Without 'sudo', the configuration works on my SP7 in my case is the opposite: with sudo works without no.

Ok, about the problem in this issue I wait for thre release of OC 0.66 to update the documentation.

Thanks

[Xiashangning]

@badstorm PR sent.
PS: How can I submit a PR for a new branch for testing my booting alternative?

[badstorm]

https://opensource.com/article/19/7/create-pull-request-github

[badstorm]

Fixed in Release 1667