Jump to content
8755 posts in this topic

Recommended Posts

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

@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
  • 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

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

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

@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
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?

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

@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

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

@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

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

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

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
43 minutes ago, deeveedee said:

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.

 

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.

Are you using Duet (LegacyBoot) to boot your computer? If yes, read this:

"Recommended configuration settings for this driver:

• OpenVariableRuntimeDxe.efi loaded using LoadEarly=true. OpenDuet users should not load this driver, as it

is included in OpenDuet.

• OpenRuntime.efi specified after OpenVariableRuntimeDxe.efi (when applicable), also loaded using LoadEarly=true"

I never used OpenVariableRuntimeDxe.efi in my legacy rig and I had no problems with USB, Ps2 mouse/keyboard in picker.

  • Like 1
  • Thanks 1
×
×
  • Create New...