OpenCore General Discussion

[gorans]

48 minutes ago, Hervé said:

Don't know why you post here to be honest; you probably have some config settings to adjust and it's not really an OpenCore matter or problem.

 

Well, I'm using OpenCore as a bootloader and I set IGPU properties through OpenCore config.plist as per Dortania OpenCore guide. The only app that shows IGPU properties (Hackintool 3.5.3) is not showing proper value. If You say that's normal behavior for IGPU that's only used for acceleration or if You have any advice how to do a proper check, please do so.

[hardcorehenry]

On 2/14/2021 at 8:12 AM, hardcorehenry said:

Updated OC today to the latest commit and… did I miss something? Anyone else have the same issue?

  Reveal hidden contents

 

 

Smbios(MLB) issue has been fixed. Hackintool shows everything correctly

Also:

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:HW_MLB

return correct value.

Thanks!

Edited February 15, 2021 by hardcorehenry

[Frankovich]

On 2/12/2021 at 10:47 PM, Hervé said:

@Frankovich, yes Dortania's documentation does detail what to do for CPU power management on Sandy Bridge and Ivy Bridge CPUs and clearly explains what to do with CPU PM tables with regards to impact on Windows, but whatever...

https://dortania.github.io/OpenCore-Post-Install/universal/pm.html#sandy-and-ivy-bridge-power-management

 

As for "USB for x79", you made no mention of this until now, so no further comment...

For x79, USBInjectAll.kext not work without some patches (EUSB to EH01 and USBE to EH02) that make loading macOS impossible to run ssdtPRGen.sh and etc. About this issue, I didn`t find any info at dortania. And if you think that dortania does detail wrote about PM, I can not conform with it. Again for x79 need some patches except your godly ssdtPRGen.sh. Yes, I realize that my motherboard not typical and dortania documentation is very good, but not fully for all hardware, but you shouldn't think that if something not works, it`s only because users can not read dortania correctly, should suggest that maybe there missed some info for some situations. When I migrate from Clover to OC near a year ago - in dortania wasn`t info about Sandy Bridge or Sandy-E, the oldest was Ivy. So I was really happy that an article about it was added. 

 

Hope you will understand me correctly. I don't want to make an angry discussion, maybe I didn`t found info about these patches at dortania and it`s only my mistake, just want to say that everyone can do mistakes and need to be able to recognize them. 100% dortania is a perfect example of documentation with the most detailed info but not with all, and all Hackintosh user happy that they have it. 

Finally want to say thanks for showing that now we have an article about Sandy-E, and wish you a good day. Best regards.

Edited February 15, 2021 by Frankovich

[Alpha22]

Question: dualboot windows10 big sur using open core I have to configure something related to dualboot in the config.plist.
I ask why with open core windows 10 loads the wheel endlessly

thanks

[deeveedee]

For anyone who still likes the FakeSMC (v.6.26-357.1800) HWMonitor.app and wants to use FakeSMC with OC, see @FreeJHack 's newer FakeSMC (v.6.26-357.1801)  here.  I was still using the 'old' FakeSMC.kext on my rig with OC 0.6.6 and thought it was working fine (despite the backtrace errors).  I now suspect that the 'old' FakeSMC with OC was responsible for some random reboots that I experienced after updating my rig's BIOS.  I also suspect that my use of the 'old' FakeSMC with OC 0.6.6 was responsible for the restart that I experienced here when upgrading from BS 11.2 to 11.2.1.  If you use FreeJHack's FakeSMC and you use XCode to edit your config.plist, see my note here.

Edited February 16, 2021 by tonyx86
Added FakeSMC version (to distinguish from different FakeSMC products)

[Alpha22]

3 hours ago, Hervé said:

By far and large, OpenCore applies ACPI patches (DSDT, SSDTs, config patches) to all of the operating systems you load through OpenCore; in that respect, this is very different to the way Chameleon/Enoch and Clover operate in that those only applied ACPI patches to OS X/macOS. So, in your particular case, it may well be that what you experience with Win10 is a side effect of your OpenCore arrangement, yes.

you have advice to give me

[blackosx]

@Hervé does a great job here helping people but he doesn’t have a crystal ball to help you@Alpha22

It looks like you’ve had this issue for a little while..

Essentially, you will need to spend time researching and testing.. For example, try checking https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/misc-issues.html or acidanthera bugtracker for previous issues that may have been asked and resolved. For example, if your issue is acpi related then maybe see https://github.com/acidanthera/bugtracker/issues/802

Does your Windows boot if you don’t provide OpenCore patched DSDT or SSDT?

EDIT: Sorry about large font. Damn iOS.
EDIT2: hopefully resolved

Edited February 15, 2021 by blackosx

[deeveedee]

After experimenting with different OC EFIs and after switching between experiments with CLOVER and OC (finally settling on OC) and experimenting with FakeSMC.kext and VirtualSMC.kext (looking like I'll be settling on VirtualSMC), my rig was in a very strange state where the OC text boot picker was not always visible at boot and during boot, the Apple Logo was not visible (although the progress bar was visible).  When I could see the boot picker, OC's NVRAM reset did not resolve the issue.  I finally ended up disconnecting AC power, holding the power button for 30 seconds and reconnecting power.  This restored my rig to perfect working condition and now OC bootpicker is always visible and the Apple Logo is always visible.

 

KInd of a newbie question from someone who should probably know better: Does anyone know what my "hardware reset" did that OC's NVRAM reset did not do?

Edited February 16, 2021 by tonyx86

[tunglamvghy]

I've installed macOS 11.2 from usb, I faced up with this errors "Waiting for root device".

I've tried to plug to all ports of my pc, tried XHC-unsupported.kext or SATA-unsupported.kext but no luck. Please help.

CPU Type      DualCore Intel Pentium 4415U, 2300 MHz
Motherboard Name      Acer Aspire A315-53
Motherboard Chipset      Intel Sunrise Point-LP, Intel Kaby Lake-U
System Memory      3971 MB

Here is my EFI

EFI b8.zip

Edited February 17, 2021 by tunglamvghy1210

[Matgen84]

Hi OC team @vit9696

XhciPortLimit to True, seems don't work for Big Sur 11.3 Beta 2. For updating, users must put it to False in config.plist (testing with OC 0.6.7 Beta)

 

 

[nmano]

I try to update 0.6.7

I delete Bootstrap folder in OC.

not show boot menu.

If anyone susses please post working EFI.

Thanks Team.

[Mr.Blue]

So I have this weird problem with OpenCore and Windows. I have Big Sur installed on one disk and Windows installed on another disk. I keep getting "BSOD: ACPI BIOS ERROR" when I try to boot Windows from OC boot menu unless I remove the patch that renames SAT0 to SATA. But that's not the only issue. When I boot into Windows from OC menu after removing the SAT0 patch, my keyboard and touchpad don't work. I2C controller gives this "resource error" in device manager. I use SSDT patches for them to work properly under Mac OS but the problem is that every single one of my SSDT files has the "If (_OSI ("Darwin"))" line. All should be fine, correct me if I'm wrong. I can boot Windows from OC If I remove all of the SSDT files and manual patches from the config and my keyboard and touchpad works just file. Why on earth would OC KEEP injecting SSDTs and patches into Windows while it clearly needs none of those?

I have zero issues if I get into the BIOS and change boot order which is kinda lame when I can just use OC boot menu. 

 

I attached my EFI folder below if someone wants to check and give me some feedback. I removed resource folder in order to decrease the zip file size. 

02.19.2021 - EFI.zip

Edited February 18, 2021 by Mr.Blue

[jlrycm]

On 2/15/2021 at 11:19 AM, Alpha22 said:

you have advice to give me

@Alpha22, in my case, i opted for chainloading refind to OpenCore and Clover following a guide that @MifJpn documented in a Japanese webpage devoted to hackintosh. It was very easy to configure. You can give it a try and see if it works for you.

 

https://mifmif.mydns.jp/alpha/?p=1165

 

By doing this, I was able to have a boot screen in which I can choose between Windows 10, OpenCore or Clover, and Windows boots without having any ACPI related side effects. There are some guides in dortania involving Bootcamp and also using/creating SSDTs that have a parameter which precludes OpenCore from applying to Win10 ACPI settings intended to macOS. You can try that too, but I found much easier to setup the chainload.

Edited February 18, 2021 by jlrycm

[Riley Freeman]

11 hours ago, Mr.Blue said:

So I have this weird problem with OpenCore and Windows. I have Big Sur installed on one disk and Windows installed on another disk.

 

I have a similar setup here on my Z68 with Windows on one disk and OpenCore/Big Sur on another. I have Windows set as the default boot manager in the BIOS so with no intervention my system boots into Windows. If I want to boot Big Sur I pick the disk with Big Sur in the startup boot menu (OpenCore is installed on the same disk as Big Sur). For this to work here I have to set LauncherOption to None under Misc->Boot otherwise OpenCore always makes itself the default boot option.

 

This works best for me as I prefer to keep third-party bootloaders away from Windows.

 

If you want to boot Windows with OpenCore you will have to make your SSDTs OS-aware so they only patch if the system is macOS. Look into the OSDW method as this is what Apple use in their firmwares. Back when I used Ozmosis on this system I used this to make my DSDT edits macOS-specific.

[Mr.Blue]

18 minutes ago, Riley Freeman said:

 

I have a similar setup here on my Z68 with Windows on one disk and OpenCore/Big Sur on another. I have Windows set as the default boot manager in the BIOS so with no intervention my system boots into Windows. If I want to boot Big Sur I pick the disk with Big Sur in the startup boot menu (OpenCore is installed on the same disk as Big Sur). For this to work here I have to set LauncherOption to None under Misc->Boot otherwise OpenCore always makes itself the default boot option.

 

This works best for me as I prefer to keep third-party bootloaders away from Windows.

 

If you want to boot Windows with OpenCore you will have to make your SSDTs OS-aware so they only patch if the system is macOS. Look into the OSDW method as this is what Apple use in their firmwares. Back when I used Ozmosis on this system I used this to make my DSDT edits macOS-specific.

Yes, what you said is exactly what I do. Disable LauncherOption and press F12 almost 100 times every time I want to boot into Windows. But why bother? I mean Clover did it just fine, Chameleon and Chimera did it just fine. For me, OC is easier to deal with and I have zero compatibility issues. It's great. But why can't we isolate Windows completely from OC's injection that's what I wonder and my only issue.

And one more thing, are you saying adding "If (_OSI ("Darwin"))" to SSDTs is not enough? I also have a patch that renames _OSI to XOSI in my patches, not sure if that helps anything besides proper I2C under macOS.

[MacNB]

5 minutes ago, Mr.Blue said:

Yes, what you said is exactly what I do. Disable LauncherOption and press F12 almost 100 times every time I want to boot into Windows. But why bother? I mean Clover did it just fine, Chameleon and Chimera did it just fine. For me, OC is easier to deal with and I have zero compatibility issues. It's great. But why can't we isolate Windows completely from OC's injection that's what I wonder and my only issue.

 

 

It's an OC design philosophy from the outset. This has been debated many many times. 

And, this goal is unlikely to change even though I have seen some signs of feature creep (e.g. CustomSMBIOS).

 

OC makes your PC almost fully emulate a Mac's EFI that means it's ACPI too.

On a real Mac where it permits Windows to boot via Bootcamp, OC does the same.

 

On my Z77 system with a fully working NVRAM, I switch between macOS & Windows either via OC boot menu or via startup disk options in macOS & Windows.

In macOS I can choose the Windows startup disk from System Preferences to boot Windows & restart; Windows boots.

In Windows, with Bootcamp installed, I can then boot back to macOS by selecting boot Mac OSX from the Bootcamp menu and the PC restarts into macOS.

Windows system Info tells me that I have a real Mac (manufacturer, Board ID, Firmware, etc...). I have OEM Windows.

All this is seamless just like a real Mac.....as long as your SSDT's are compatible.

I did have DSDT originally when I used to use Clover but that's dropped now and only a couple of SSDT's (for EC & USB3).

 

On my older Legacy system (Dell Inspiron 530), where an DSDT absolutely necessary, I could not boot Windows (I got the ACPI BIOS ERROR blue screen of death error).

I worked on the DSDT iteratively by adding the "If (_OSI ("Darwin"))" checks on the Devices and now have Windows booting via OC. Even though this system does not have a real working NVRAM, I can still choose to boot Windows from macOS Startup Disk. OK I cannot go back to macOS from Windows bootcamp as there's no NVRAM. So on this system, I just select the OS via OC's boot menu which works fine. And with emulated NVRAM, the default boot OS is retained on every boot.

 

Yes there are caveats to booting "other" OS's via OC, but it's primary design goal was to boatload macOS.

 

Choosing to boot Windows via F12 BIOS is the least intrusive way.

[Riley Freeman]

48 minutes ago, Mr.Blue said:

Yes, what you said is exactly what I do. Disable LauncherOption and press F12 almost 100 times every time I want to boot into Windows. But why bother? I mean Clover did it just fine, Chameleon and Chimera did it just fine. For me, OC is easier to deal with and I have zero compatibility issues. It's great. But why can't we isolate Windows completely from OC's injection that's what I wonder and my only issue.

And one more thing, are you saying adding "If (_OSI ("Darwin"))" to SSDTs is not enough? I also have a patch that renames _OSI to XOSI in my patches, not sure if that helps anything besides proper I2C under macOS.

 

Things have changed a little bit since I used OSDW. Back then I was using a single DSDT rather than injecting SSDTs. I guess _OSI or _XOSI is a newer way of achieving the same thing so you're probably on the right track. But if they're working correctly they shouldn't be messing up Windows.

[hardcorehenry]

30 minutes ago, 5T33Z0 said:

I have a question about enabling XCPM for IvyBridge CPUs in OpenCore for Catalina.

 

For latest Catalina try:

F:8D 43 C4 3C 42 
R:8D 43 C6 3C 42

If there were problems try without Mask and ReplaceMask.

Edited February 20, 2021 by hardcorehenry

[MacNB]

4 hours ago, 5T33Z0 said:

I have a question about enabling XCPM for IvyBridge CPUs in OpenCore for Catalina. I've been trying to get it to work now for some time, but I am stuck in a dead end. According to the configuration manual about emulatuing CPUs to enable XCPM it states:

0. "Note 4: Note that the following configurations are unsupported by XCPM (at least out of the box):

• Consumer Ivy Bridge (0x0306A9) as Apple disabled XCPM for Ivy Bridge and recommends legacy power management for these CPUs. _xcpm_bootstrap should manually be patched to enforce XCPM on these CPUs"

But there are no further explanations in there on actually how to do it. So I did some more research and found this Kernel Patch:

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (Ivy Bridge) 10.15
Count: 1
Enabled: YES
Find: 8D43C43C22
Identifier: kernel
Limit: 0
Mask: FFFF00FF
MinKernel: 19.
MaxKernel: 19.99.99
Replace: 8D43C63C22
ReplaceMask: 0000FF0000
Skip: 0

SOURCE: https://github.com/khronokernel/OpenCore-Vanilla-Desktop-Guide/issues/32

 

So I added this to Kernel > Patch but it lead to a Kernel Panic: "Patch is borked". Apparently, the Mask and ReplaceMask have to be identical in length. But in this case, the mask has 8 digits and the replacement mask has 10. So I concluded that If a value in Mask is 'F' and the corresponding value of the Replacement Mask is '0', there are 2 F's missing at the end of the Mask value. So I changed it to FFFF00FFFF.  Then I replaced the SSDT-PM for the legacy power management Plugin by SSDT-PLUG to enable the x86platformplugin. And rebooted. But the patch doesn't seem to work. The CPU runs at a low frequency and the output of sysctl machdep.xcpm.mode is still 0.

 

I know it's not an important issue since the Laptop works fine with the Legacy Plugin, but I really, really would like to understand how this works or what I am doing wrong so any insight would be highly appreciated. Thank you

 

 

 

I use XCPM on my i7-3770K successfully.

While back I dissembled the Catalina kernel to find the patch for this CPU. Your FIND & REPLACE are different.

I do not use SSDT-PLUG and have my own SSDT-PM generated by Piker Alpha's script. It enables PLUGIN-TYPE.

like so in the Method (ACST, 0, NotSerialized)...

...bla bla...


        Method (_DSM, 4, NotSerialized)
        {
            Store ("Method _PR_.CPU0._DSM Called", Debug)

            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                    0x03
                })
            }

            Return (Package (0x02)
            {
                "plugin-type",
                One
            })
        }

... bla bla ...

The patch I use (for Catalina 10.15.7 & Big Sur 11.2.1):

Base: _xcpm_bootstrap
Comment: _xcpm_bootstrap (For Ivy Bridge) 10.15.5+ by MacNB
Count: 1
Enabled: YES
Find: 8D43C43C42
Identifier: kernel
Limit: 0
Mask: 0
MinKernel: 19.50.00
MaxKernel: 20.99.99
Replace: 8D43C63C42
ReplaceMask: 
Skip: 0

Output from sysctl command:

 

MacNB@My-Mac %  sysctl -n machdep.xcpm.mode
1
MacNB@My-Mac % 

 

[Stefanalmare]

Hi! I'm trying to spoof R7 260x in Big Sur (no acceleration without spoofing), but I have KP always right before login. A hint? Thank you!

[oSxFr33k]

 

[SOLVED]

 

But still have a question on how to add the Hex String from Clover Devices/Properties(Hex) a really needed feature in my case.

 

 

Laptop Haswell with dGPU GTX 770m IGPU disabled by Asus so this is non Optimus, fully supported Boot and Native GPU acceleration in Clover but getting Kernel Panic in OpenCore 0.6.6.  I also need to figure out how to add a hex string that is in my Clover Config to OpenCore Config most likely the DeviceProperties Add section but not sure of the exact format it should be in?  I need to add inject YES and the Hex String.  See the Screenshot Panic Error and the Clover Screenshot section.

 

One more screenshot showing the PCIRoot GPU added Inject and Properties if this format is the correct one then added YES and HEX string to them.

 

 

Edited:  I have verified I get the same NVDAStartup Panic in Clover if I don't include this Hex string Properties.   If I convert this hex to text, you can see the information regarding the connectors, Display Brightness and Undserscan if connected to external monitor via HDMI

 

I have had this Hex string go with me on every version of MacOS starting with Mavericks on a Asus G750JX-DB71.

e10b00000100000001000000d50b00003800000002010c00d041030a000000000101060000010101060000007fff0400280000004100410050004c00300030002c004c0069006e006b0046006f0072006d006100740000000800000000000000220000007600620069006f0073002d007200650076006900730069006f006e00000009000000130054068014000000400030002c00450044004900440000000401000000ffffffffffff0006af9d2100000000001601049026157802c8959e575492260f505400000001010101010101010101010101010101143780c070382040306436007dd6100000180000000f0000000000000000000000000020000000fe0041554f0a202020202020202020000000fe004231373348573032205631200a005100000000000000000000000000000000000000000000000000000000000000004c534e313534594c30313030310a2000444c4d323237313033485a4634394741370a20202020200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002e000000400030002c004100410050004c002c0062006f006f0074002d0064006900730070006c006100790000000400000020000000400030002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d6163100000006d006f00640065006c0000001b0000004e5649444941204765466f72636520475458203737304d240000004100410050004c00300030002c004400750061006c004c0069006e006b000000080000000100000022000000400031002c0064006900730070006c00610079002d00630066006700000008000000ffff0801360000004100410050004c00300030002c0049006e007600650072007400650072004600720065007100750065006e0063007900000008000000000000002400000067007200610070006800690063002d006f007000740069006f006e0073000000080000000c00000014000000400032002c006e0061006d0065000000120000004e5644412c446973706c61792d431c000000400030002c00660062006f006600660073006500740000000800000000000200100000004e0056004300410050000000180000000501000000000100060000000000000f0000000020000000400031002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d61631e00000072006f006d002d007200650076006900730069006f006e000000080000003336383222000000400033002c006400650076006900630065005f00740079007000650000000b000000646973706c61792e000000400031002c004e005600440041002c0055006e006400650072007300630061006e004d0069006e00000008000000520000002a0000004100410050004c00300030002c0044006100740061004a0075007300740069006600790000000800000001000000200000004100410050004c00300030002c0044006900740068006500720000000800000000000000220000005600520041004d002c0074006f00740061006c00730069007a00650000000c000000000000c0000000001c000000400030002c00700077006d002d0069006e0066006f0000001c000000021800649059020008520000a51c0000000400000100000022000000400030002c0064006900730070006c00610079002d006300660067000000080000000301000022000000400032002c006400650076006900630065005f00740079007000650000000b000000646973706c617920000000400032002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d61632e000000400030002c006200610063006b006c0069006700680074002d0063006f006e00740072006f006c00000008000000010000001e0000005600520041004d002c0074006f00740061006c004d004200000008000000000c000020000000400033002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d616328000000400030002c0063006f006e006e006500630074006f0072002d007400790070006500000008000000020000001e000000730075006200730079007300740065006d002d00690064000000080000000c0100002c0000004e005600440041002c0069006e00760061006c00690064002d0063006f006e006600690067000000080000000000000038000000400030002c007500730065002d006200610063006b006c0069006700680074002d0062006c0061006e006b0069006e00670000000400000014000000400031002c006e0061006d0065000000120000004e5644412c446973706c61792d422e000000400032002c004e005600440041002c0055006e006400650072007300630061006e004d0069006e0000000800000052000000180000004100410050004c00300030002c00540037000000080000009001000028000000400031002c0063006f006e006e006500630074006f0072002d0074007900700065000000080000000004000022000000400031002c006400650076006900630065005f00740079007000650000000b000000646973706c6179180000004100410050004c00300030002c00540036000000080000000000000024000000400031002c00630061006e002d0068006f0074002d0070006c0075006700000004000000260000005600520041004d002c006d0065006d00760065006e0064006f007200490044000000060000000600180000004100410050004c00300030002c0054003500000008000000010000001e000000730061007600650064002d0063006f006e0066006900670000003c0100000f084c04f200000060001006a00e0003027f400b0807e00b300050003c07030009000800ef83000000000000010000000000000000040000010a0a0400000002000000000000400b0807400b0807000000403e00010000000000000f0080000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000001000000000000000000000000000000020000000000000f0080000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000002000000000000000000000000000000030000000000000f0080000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000003000000000000000000000000000000180000004100410050004c00300030002c0054003400000008000000c800000028000000400032002c0063006f006e006e006500630074006f0072002d0074007900700065000000080000000004000014000000400033002c006e0061006d0065000000120000004e5644412c446973706c61792d44180000004100410050004c00300030002c0054003300000008000000c80000002e000000400030002c004e005600440041002c0055006e006400650072007300630061006e004d0069006e0000000800000052000000180000004100410050004c00300030002c0054003200000008000000010000001c000000400030002c006200750069006c0074002d0069006e00000004000000240000004100410050004c00300030002c004c0069006e006b0054007900700065000000080000000100000028000000400033002c0063006f006e006e006500630074006f0072002d007400790070006500000008000000000800001c0000006400650076006900630065005f00740079007000650000000f0000004e5644412c506172656e742a0000004100410050004c00300030002c0050006900780065006c0046006f0072006d006100740000000800000000000000180000004100410050004c00300030002c00540031000000080000000000000014000000400030002c006e0061006d0065000000120000004e5644412c446973706c61792d4122000000400030002c006400650076006900630065005f00740079007000650000000b000000646973706c61792e000000400033002c004e005600440041002c0055006e006400650072007300630061006e004d0069006e0000000800000052000000

 

Converted to Text gives some information about the hex string.

 

 

áÕ8ÐA
ÿ(AAPL00,LinkFormat"vbios-revision	T@0,EDIDÿÿÿÿÿÿ¯!&xÈWT&PT7Àp8 @0d6}Ö þAUO
         þB173HW02 V1 
QLSN154YL01001
 DLM227103HZF49GA7
     .@0,AAPL,boot-display @0,compatibleNVDA,NVMacmodelNVIDIA GeForce GTX 770M$AAPL00,DualLink"@1,display-cfgÿÿ6AAPL00,InverterFrequency$graphic-options@2,nameNVDA,Display-C@0,fboffsetNVCAP @1,compatibleNVDA,NVMacrom-revision3682"@3,device_typedisplay.@1,NVDA,UnderscanMinR*AAPL00,DataJustify AAPL00,Dither"VRAM,totalsizeÀ@0,pwm-infodYR¥"@0,display-cfg"@2,device_typedisplay @2,compatibleNVDA,NVMac.@0,backlight-controlVRAM,totalMB @3,compatibleNVDA,NVMac(@0,connector-typesubsystem-id,NVDA,invalid-config8@0,use-backlight-blanking@1,nameNVDA,Display-B.@2,NVDA,UnderscanMinRAAPL00,T7(@1,connector-type"@1,device_typedisplayAAPL00,T6$@1,can-hot-plug&VRAM,memvendorIDAAPL00,T5saved-config<Lò` @à0P<	ï

@@@>AAPL00,T4È(@2,connector-type@3,nameNVDA,Display-DAAPL00,T3È.@0,NVDA,UnderscanMinRAAPL00,T2@0,built-in$AAPL00,LinkType(@3,connector-typedevice_typeNVDA,Parent*AAPL00,PixelFormatAAPL00,T1@0,nameNVDA,Display-A"@0,device_typedisplay.@3,NVDA,UnderscanMinR

 

Edited Again:

 

NVDAStartup panic was caused by not having rom-version in device properties, missed that part in the Dortania Guide.  I would still like to know how to add the hex string from Clover to OpenCore anyone?

 

 

 

 

 

Edited February 22, 2021 by oSxFr33k
Solved

[Mr.Blue]

Is there a way to make OpenCore boot faster? Or at least see what's taking time before the Apple logo? My BIOS POSTs in 3 seconds and I see the Apple logo at the 10th second mark. What does OC spend those 7 seconds with? My OC folder is only 8.7MB and I'm running it on Evo 860 SSD.

Windows also shows BIOS time as 3.4secs when booted directly from UEFI instead of OC.

I've disabled all of the debugging options except ApplePanic, removed unnecessary drivers and I've disabled picker although I've an installed theme. 

[deeveedee]

@Mr.Blue I noticed longer boot times when I had enabled BootChime.  I imagine the audio mp3 file and Audio driver needed to load?  Not sure what resources (including mp3) you're loading at startup, but that might have something to do with it and might be something you want to check.  I didn't want the BootChime anyway, so getting rid of it (disabling UEFI Audio Support and removing the Audio driver) resulted faster boot time) was an easy decision for me.  I'm currently using text boot picker and no BootChime and startup is fast.  Then again, I prefer to boil water on the stove vs. the microwave, so I may not be the best judge of fast

[AudioGod]

@Hervé Hello Buddy, He’s talking about before the bootpicker when OC is initialising the drivers and the fact that when the Audio Driver is loaded via drivers in the config.plist the time before OpenCanopy Starts is around 3 seconds longer. This is just the nature of loading that extra driver.

On mine and all others with a X570 hack using the SmallTree I211-AT patch kext that pause before the bootpicker is around 8 seconds because of that kext, I hate that but I’m used to it now. (If only somebody with the knowledge would redo that kext..hint hint fantastic ones hehe)

 

Edited February 27, 2021 by AudioGod

[Mr.Blue]

10 hours ago, tonyx86 said:

@Mr.Blue I noticed longer boot times when I had enabled BootChime.  I imagine the audio mp3 file and Audio driver needed to load?  Not sure what resources (including mp3) you're loading at startup, but that might have something to do with it and might be something you want to check.  I didn't want the BootChime anyway, so getting rid of it (disabling UEFI Audio Support and removing the Audio driver) resulted faster boot time) was an easy decision for me.  I'm currently using text boot picker and no BootChime and startup is fast.  Then again, I prefer to boil water on the stove vs. the microwave, so I may not be the best judge of fast

 

10 hours ago, Hervé said:

@Mr.Blue sounds like you need to check the Misc->Timeout value set in your OC config. With a timeout of 1s + external Picker (+ Chime enabled for no extra delay), OC initiates Big Sur startup in 1s on my Hackintosh laptops. It's very fast. The 1s delay allows for a very quick keyboard action if I want to boot Win10 instead.

 

9 hours ago, AudioGod said:

@Hervé Hello Buddy, He’s talking about before the bootpicker when OC is initialising the drivers and the fact that when the Audio Driver is loaded via drivers in the config.plist the time before OpenCanopy Starts is around 3 seconds longer. This is just the nature of loading that extra driver.

On mine and all others with a X570 hack using the SmallTree I211-AT patch kext that pause before the bootpicker is around 8 seconds because of that kext, I hate that but I’m used to it now. (If only somebody with the knowledge would redo that kext..hint hint fantastic ones hehe)

 

 

OK so it looks like the issue was the boot chime that I live for  After removing AudioDxe, OC takes only 2 seconds to load everything and I see the Apple logo in 5 seconds after hitting the power button.

I don't use picker and it's disabled in my config since I can't boot into Windows from OC anyways. But that was not the issue. Removing themes and OpenCanopy or disabling ApplePanic had no effect, but AudioDxe causes 5-6 seconds delay before the picker. Removing it from the config reduced OC's loading time by 90% I can say. I suppose that's just the nature of that driver and there's no way to make it load faster?

Edited February 28, 2021 by Mr.Blue