Jump to content

OpenCore General Discussion


dgsga
8,774 posts in this topic

Recommended Posts

Opencore ConnectDrivers taking a long time at boot.

Questions for the Devs: why does it take so long ?

 

Recently fired up one of my ageing hacks (Dell Inspiron 530 Legacy BIOS) to help someone with Legacy config.

It has OC 0.8.3 DEBUG installed (with latest OpenDuet).

I remember the slow startup after the BIOS POST screen clears and before Opencore debug messages come up on the screen (about 10 seconds).

 

Looking at the debug log, I see:

...
00:427 00:002 OC: Connecting drivers...
12:735 12:307 OC: Connecting drivers done...
...

So it's actually taking OC over 12 seconds to connect these drivers.

 

Questions for the Devs: why does it take so long ? What's actually happening in these 12 seconds ?

 

As a test, in the config.plist I set

ConnectDrivers=FALSE

This made the boot time longer and the log file showed:

...
06:165 00:048 OC: Connecting drivers...
18:282 12:117 OC: Connecting drivers done...
...

 

It's taking over 12 seconds NOT to connect drivers.

Obviously, I lost Snow Leopard in the Boot Picker list since HfsPlusLegacy.efi driver was not connected.

 

I was expecting that by setting ConnectDrivers=FALSE, that would speed up the boot process by saving ~12 seconds but it makes it worse.

 

So, what's happening with ConnectDrivers setting ?

Edited by MacNB
Link to comment
Share on other sites

Recently I cloned my Win11 SSD drive to another drive. (I have an NVMe drive with macOS, and two SSD drives in my system. One is Win11 and one is just data.)

 

Ever since I get the following message four times, every time I boot, right before the OpenCanopy boot screen:

HDR: Open PCI I/O protocol (try DisconnectHda quirk?) - Already started 

System works perfectly fine after boot but don't know why this shows up now. I did try to switch the UEFI>Audio>DisconnectHda to YES (it was set to NO) but that didn't help.

 

EDIT:

I reset NVRAM and the comment went away.

Edited by pkdesign
Link to comment
Share on other sites

5 hours ago, deeveedee said:

Glad to see that "Retired" does not actually mean retired.  Maybe we'll still hear from Herve, too.  Hope you're well, Herve.

Still Active, A Bit Premature With My Post, BUT WILL BE HAPPENING COME XMAS WHEN I GET AN M2 MacBook Pro OR Mac mini 😁

Link to comment
Share on other sites

@Download-Fritz I'm not sure how to submit an OpenCore feature request, so I'll post here and allow you to direct me to the correct process/procedure.  Thank you for adding '--preserve-boot' as an optional argument to UEFI Driver ResetNvramEntry.efi.  This is a great optional argument that allows us to preserve the BIOS boot order when we reset NVRAM.

 

Would it be possible to have another optional argument for ResetNvramEntry.efi that allows us to preserve the OC boot menu selection when we reset NVRAM?

 

Thank you and many thanks to you and the Acidanthera developers for all of your hard work on Open Core, kexts and documentation.

 

 

EDIT: I did review Misc > Boot > LauncherOption as a possible way to "lock" the OC boot entry selection, but I didn't think it could be used to protect the OC boot entry selection from ResetNvram.

Edited by deeveedee
Link to comment
Share on other sites

  • 4 weeks later...

Thank you Developers!  My upgrade from OC 0.8.4 to OC 0.8.5 was easy with the changes listed here.  Thank you for continuing to support us with your hard work.  I hope you are all well and staying safe.

  • Like 4
Link to comment
Share on other sites

The language may be distorted in a way that disgusts me because I use google translate.

CleanNvram.efi vs ResetNvramEntry.efi Does it work the same? I have a feeling ResetNvramEntry.efi work differently CleanNvram.efi
For example, if using CleanNvram.efi will delete all previously set values. different from ResetNvramEntry Can delete some values

Link to comment
Share on other sites

32 minutes ago, naiclub said:

The language may be distorted in a way that disgusts me because I use google translate.

CleanNvram.efi vs ResetNvramEntry.efi Does it work the same? I have a feeling ResetNvramEntry.efi work differently CleanNvram.efi
For example, if using CleanNvram.efi will delete all previously set values. different from ResetNvramEntry Can delete some values

Don't use CleanNvram.efi!!! It kill all, BIOS, CMOS, your system etc.

I lose my Ventura installation and forced to format my HDD, clear CMOS and make new boot variables.  F...k!

  • Like 1
  • Sad 3
Link to comment
Share on other sites

26 minutes ago, Slice said:

Don't use CleanNvram.efi!!! It kill all, BIOS, CMOS, your system etc.

I lose my Ventura installation and forced to format my HDD, clear CMOS and make new boot variables.  F...k!

I'm sorry
But my case is different from what you said above.
I used to clear the boot order called mac osX located in the bios boot menu. that it likes to intervene first before booting the actual name of the system etc.
In case I didn't clear the values inside the BIOS in any way. It's still fine, no problem.
If I use ResetNvramEntry.efi won't clean the mac osX name in the slightest
Especially if I install new mac or update new version mac osX will increase in boot order.

I sincerely apologize to you.

Link to comment
Share on other sites

@johnnyl Attached the Skylake EFI for Ventura, you have been requesting.

Please note that this EFI is used in a multi-boot configuration including:

 

Monterey

Ventura

Ubuntu 22.04.1 LTS

Windows 10 Enterprise

Windows 10 Professional 

 

USB-ports configuration is per the SSDT-PORTS.aml file in the ACPI section.

 

My serial number has been made unrecognisable with "abababababab", wherever it appears.

 

The heading section of the config.plist file contains all configuration options that may be of interest.

 

Greetings Henties

Office OC 0.8.5 Release 04 Oct 2022.zip

Edited by Henties
  • Like 2
Link to comment
Share on other sites

On 10/5/2022 at 6:08 AM, Slice said:

Don't use CleanNvram.efi!!! It kill all, BIOS, CMOS, your system etc.

I lose my Ventura installation and forced to format my HDD, clear CMOS and make new boot variables.  F...k!

The only issue that I've seen that resembles your experience is documented here.  Was your experience with a Lenovo PC by any chance?

Link to comment
Share on other sites

I think both items do the same thing. First, ResetNVRAM was bundled within OC and the developers added CleanNvram defined as "ResetNVRAM alternative bundled as a standalone tool" in the Configuration.pdf. Now, ResetNVRAM is a separate driver and CleanNVRAM is less useful. But the features are the same. 

  • Like 2
Link to comment
Share on other sites

On 10/5/2022 at 5:37 PM, naiclub said:

I'm sorry
But my case is different from what you said above.
I used to clear the boot order called mac osX located in the bios boot menu. that it likes to intervene first before booting the actual name of the system etc.
In case I didn't clear the values inside the BIOS in any way. It's still fine, no problem.
If I use ResetNvramEntry.efi won't clean the mac osX name in the slightest
Especially if I install new mac or update new version mac osX will increase in boot order.

I sincerely apologize to you.

As before, OC had been before. At present, there has never been this problem again.

But now it's the clover that's the problem. But it's not that serious, just mac osX snag into the BIOS menu boot order and use OC to boot into CleanNVRAM. to clear the list of mac osX names, now the BIOS menu page will come back to normal and look very clean.

Link to comment
Share on other sites

@bleeker attached the Haswell EFI for Ventura, you have been requesting.

Please note that this EFI is used in a multi-boot configuration including:

 

Monterey

Ventura

Ubuntu 22.04.1 LTS

Windows 10 Enterprise

Windows 10 Professional 

 

USB-ports configuration is per the USBPorts.kext file located in the OC Kexts section.

 

My serial number has been made unrecognisable with "abababababab", wherever it appears.

 

The heading section of the config.plist file contains all configuration options that may be of interest.

 

Greetings Henties

Seaview EFI OC 0.8.5 Release 04 Oct 2022.zip

  • Like 2
Link to comment
Share on other sites

What do these alternating screens mean when attempting to boot High Sierra installer with OC 0.8.5 on a Legacy BIOS (not UEFI) laptop?

 

I am trying to boot High Sierra Installer with Open Core 0.8.5 on a Dell Latitude E6410 (Nvidia Graphics).  I developed a fully working CLOVER solution here (including working sleep and wake) with a fully patched DSDT and decided to try my hand at an Open Core solution with ACPI hot patches (SSDTs and ACPI binary replacements only).  The laptop does not support UEFI, so I'm booting OC with LegacyBoot.  If all works, I plan to post this solution as a guide, since the hot patches are extensive and might help others.  The High Sierra installer appears to boot, but I'm stuck at screens that I haven't seen before.  Does anyone know what these two alternating screens mean?  They appear to be telling me to power off the unit.  These screen appear immediately after Nvidia graphics loads and I don't see any other screens.

 

Alternative Screen #1

Spoiler

thumbnail_IMG_2117.jpg.40913b4d4d51f8980254887130ac2727.jpg

 

Alternating Screen #2

Spoiler

thumbnail_IMG_2118.jpg.fa921a9353d054f208b776a05431aa07.jpg

 

Edited by deeveedee
Link to comment
Share on other sites

@1Revenger1 Thank you!  Looks like my trackpad isn't being detected.  Getting to this point was a lot of work.  Figuring out the mouse should be easy compared to the work so far.  Thanks again.

 

@1Revenger1 I am now able to fully boot the High Sierra installer after replacing VoodooPS2Controller-R6Bronxteck with Acidanthera's VoodooPS2Controller kext (with VoodooInput, VoodooPS2Keyboard and VoodooPS2Trackpad).  Bronxteck's modified VoodooPS2Controller served me well for a long time on the Latitude E6410.

 

My conversion from CLOVER/Custom DSDT to OC/HotPatches is almost complete.  I just need to figure out why my USB patches aren't enabling the USB ports with OC where they did with CLOVER.  Should be relatively easy (famous last words).

Edited by deeveedee
Link to comment
Share on other sites

I have successfully converted my HackBookPro6,2 (Dell Latitude E6410 / NVidia Graphics) from CLOVER / custom DSDT to OC / hot patched ACPI based on my original solution here.  All appears to be working perfectly, including sleep / wake.  The OC ACPI hot patches were especially painful with this old laptop because the OC ACPI patching base paths did not work in many cases.  Applying the ACPI binary renames required the tedious use of HexFiend (hex viewer) to inspect the original unpatched ACPI to find the hex sequences to be replaced.  Rehabman's ACPI patching guide still applies.  Search for 'Rehabman Patching LAPTOP DSDT/SSDTs'

 

After this exercise, I'd have to say that generating a custom DSDT for this old laptop is much easier than finding and applying the ACPI hot patches.

 

After I am able to boot newer macOS versions (using OC legacy patching tools), If all goes well I'll be posting a new Dell Latitude E6410 OC EFI and a brief guide.

 

 

968305893_ScreenShot2022-10-15at11_05_18AM.png.1cf1ca722c1f3575e659ac747fa06c1b.png

Edited by deeveedee
  • Like 2
Link to comment
Share on other sites

@cyrhex

Cryptexfixup is developed by Acidanthera, as OpenCore, OCLP and a lot of kexts. Talking them here is not useful, I don’t think that you get any answer from them. 
If you are looking for help, give more info to the forum, because "dlyb error" doesn’t says too much. 
How are you installing the kext? OpenCore or OCLP? What hardware? What and when do you see the error? And any other info that you think useful. 

Link to comment
Share on other sites

Has anyone noticed a problem with driver Ps2KeyboardDxe.efi when OpenVariableRuntimeDxe.efi is enabled (with load early enabled)?  Details below...

 

I am experimenting with OpenVariableRuntimeDxe.efi as I switch my Latitude E6410 from CLOVER to OC.  I have noticed that without OpenVariableRuntimeDxe.efi (where OpenRuntime.efi does not load early), my internal PS/2 keyboard up/down cursor keys work fine to navigate the OC boot picker.

 

If I enable OpenVariableRuntimeDxe.efi (load early) with OpenRuntime.efi set to load early, my laptop's internal PS2 keyboard cursor keys do not work (initially). I discovered that if I press <F12> during boot-up to open the BIOS boot menu and then select my boot device, the PS2 keys work for the OC boot picker.  If I don't press <F12> and I allow the laptop to boot normally, the internal PS2 keyboard keys do not work for the OC boot picker. Only reliable work-around is to use OpenUsbKbDxe.efi with an external USB keyboard if I want to navigate the OC boot picker.  This appears to be a driver timing issue, because I can get the internal PS2 cursor keys to work with the OC boot picker if I boot from USB stick (slower boot).

 

The <F12> work-around is adequate, but I'm curious to know if anyone else has seen this and if so, is there a solution.  My UEFI drivers are below:

 

  • OpenVariableRuntimeDxe.efi (load early)
  • OpenRuntime.efi (load early)
  • HfsPlusLegacy.efi
  • ResetNvramEntry.efi (--preserve-boot)
  • Ps2KeyboardDxe.efi

 

If I use OpenUsbKbDxe.efi instead of Ps2KeyboardDxe.efi (to enable an external USB keyboard), the external USB keyboard works without any work-arounds.

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...