Jump to content

[HOW TO] OpenCore 0.8.2 > 0.8.3 differences


miliuco
 Share

10 posts in this topic

Recommended Posts

OpenCore 0.8.3 is out. You can get it in Acidanthera.

 

Main changes

  • Fixes for macOS 13 developer beta 3
  • Added ext4 file system driver
  • Changed RsaTool not to link against system SSL (but LibreSSL) on macOS
  • Fixes for macOS 10.4 and 10.5
  • Fixes for emulated NVRAM (OpenVariableRuntimeDxe.efi as separate driver, support for NVRAM reset and set default boot entry, upgraded emulated NVRAM logout script, ability to have emulated NVRAM in UEFI BIOS)
  • Added Driver >> LoadEarly (boolean) property for drivers loaded before NVRAM init (requires config.plist update) (see below).

config.plist

 

NVRAM >> removed LegacyEnable key.

 

UEFI >> Drivers: added a new key LoadEarly specifically designed for OpenVariableRuntimeDxe.efi, new driver for emulated NVRAM on UEFI BIOS machines with fragile (e.g. MacPro5,1) or incompatible NVRAM implementations. Other drivers must have LoadEarly false by default. Update config.plist.
 

- Notes for use of OpenVariableRuntimeDxe.efi:

  • OpenRuntime.efi specified after OpenVariableRuntimeDxe.efi in the Drivers list
  • OpenVariableRuntimeDxe.efi loaded using LoadEarly=true
  • OpenRuntime.efi also loaded using LoadEarly=true for correct operation of RequestBootVarRouting
  • LegacySchema populated
  • LegacyOverwrite enabled to be able to overwrite any existing variable
  • ExposeSensitiveData with at least bit 0x1 set
  • This driver requires working FAT write support in firmware, and sufficient free space on the OpenCore EFI partition for up to three saved NVRAM files
  • NVRAM values are loaded from NVRAM/nvram.plist
  • Reset NVRAM option installed by the ResetNvramEntry driver removes NVRAM/nvram.plist instead of affecting underlying NVRAM
  • CTRL+Enter in the OpenCore bootpicker updates or creates NVRAM/nvram.plist.

 

UEFI >> Drivers >> ToogleSIP: added --show-csr option (boolean flag) to be specified as plain text in the Arguments key of the Driver entry. If enabled, it shows current hexadecimal value of csr-active-config in the boot entry name. It doesn't work in OpenCanopy when Misc >> Boot >> PickerAttributes has OC_ATTR_USE_GENERIC_LABEL_IMAGE that provides predefined label images for boot entries without custom entries.

 

UEFI >> Audio >> SetupDelay (Integer): changed units from microseconds to milliseconds.


UEFI >> Drivers >> AudioDxe: added optional --codec-setup-delay argument to AudioDxe (number in milliseconds). There is no need to change anything if you don't use SetupDelay (it's value is 0). SetupDelay is needed if the initial part of the boot chime is either cut off (zero volume) or too loud (max volume) before settling to the correct volume.


Drivers

  • OpenVariableRuntimeDxe.efi: new driver added for emulated NVRAM. This driver allows to have emulated NVRAM in UEFI BIOS in cases where this may be useful. OC developers try to to bring emulated NVRAM closer to native NVRAM as much as possible and make it available to non-legacy BIOS for the first time. See notes above.
  • AudioDxe.efi: Added --force-device option as text string in Arguments, followed by the PCI path to the audio device (e.g. --force-device=PciRoot(0x0)/Pci(0x1f,0x3)) allowing UEFI audio on some types of HDA controllers even if the device does not report itself as an HDA audio controller.

Kexts

  • AppleALC 1.7.4: improved compatibility with High Sierra, updated README_CN
  • ECEnabler 1.0.3: updated README
  • IntelBluetoothFirmware 2.2.0: fixes for Monterey (read this)
  • Lilu 1.6.2: fixed kernel panic on macOS 13 developer beta 3
  • MacHyperVSupport 0.9: updated README, added macOS 13 support, fix for macOS 10.4
  • VoodooI2C 2.7: fixes for the main core and satellite extensions
  • WhateverGreen 1.6.1: code refactoring, fixes for Skylake as Kaby Lake in macOS 13.

Thank you OpenCore team!!!

 

Edited by miliuco
  • Like 7
  • Thanks 5
Link to comment
Share on other sites

Maybe to note, some of those changes about how NVRAM is handled are only for the (unusual) use case where you have new OpenVariableRuntimeDxe.efi installed; for most people, NVRAM behaviour (including behaviour of ResetNvramEntry.efi) stays the same.

Edited by Bmju
  • Like 3
Link to comment
Share on other sites

OpenCore / ocvalidate README notes:

  • When OpenVariableRuntimeDxe.efi is in use, its LoadEarly option must be set to TRUE.
  • When OpenVariableRuntimeDxe.efi is in use, OpenRuntime.efi LoadEarly option must be set to TRUE.

  • LoadEarly for any other driver but OpenVariableRuntimeDxe.efi and OpenRuntime.efi must be set to FALSE.

To clarify about LoadEarly.

 

Edited by miliuco
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Note about OpenVariableRuntimeDxe.efi

 

Old machines with legacy BIOS (i.e. machines which do not have UEFI compatible firmware) can install OpenDuet from the Utilities/LegacyBoot folder of OpenCore. OpenDuet behaves as a compatibility layer prior to OpenCore, to provide UEFI on machines which previously lacked it. It includes in-memory emulation of NVRAM (which is normally present in hardware, on all UEFI compatible machines). This new OpenVariableRuntimeDxe driver allows the use of in-memory emulated NVRAM with OpenCore, separately from OpenDuet.
 

OpenVariableRuntimeDxe not only brings emulated NVRAM to OpenCore, it also adds some improvements in functionality even for OpenDuet users (correct handling of NVRAM reset and CTRL+Enter). Importantly, in bringing emulated NVRAM to OpenCore, OpenVariableRuntimeDxe opens the possibility of using emulated NVRAM instead of original hardware NVRAM on UEFI machines with fragile hardware NVRAM implementations (for instance, where excessive NVRAM usage can eventually cause bricking, such as on the MacPro 4,1 and 5,1).

 

Thank you! @Bmju

 

Edited by miliuco
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 8/1/2022 at 6:34 PM, miliuco said:

OpenCore / ocvalidate README notes:

  • When OpenVariableRuntimeDxe.efi is in use, its LoadEarly option must be set to TRUE.
  • When OpenVariableRuntimeDxe.efi is in use, OpenRuntime.efi LoadEarly option must be set to TRUE.

  • LoadEarly for any other driver but OpenVariableRuntimeDxe.efi and OpenRuntime.efi must be set to FALSE.

To clarify about LoadEarly.

 

 

@miliuco - Thank you for this clarification.  I am currently running with OC 0.8.3 [Release] and all Drivers > LoadEarly = False (since I don't need OpenVariableRuntimeDxe.efi) and all is working well.

 

I saw a post in another thread where someone claimed that in order to use OC 0.8.4 [DEV], they needed to set OpenRuntime.efi > LoadEarly = True (all other Drivers with LoadEarly = False) even though they weren't loading OpenVariableRuntimeDxe.efi.  Have you heard anything to suggest that the guidance for LoadEarly is going to change for OC 0.8.4?

Edited by deeveedee
Link to comment
Share on other sites

@deeveedee

 

There is no change in 0.8.4 configuration pdf:

 

LoadEarly
Type: plist boolean
Failsafe: false
Description: Load the driver early in the OpenCore boot process, before NVRAM setup.

Note: Do not enable this option unless specifically recommended to do so for a given driver and purpose.

 

And it’s only recommended on the scenarios written above. 
 

Maybe that user has a specific hardware or settings to need LoadEarly true with OpenRuntime. 

  • Like 1
Link to comment
Share on other sites

@deeveedee, I think you are reading too much into it. I have been tracking the source code and no it is not needed. Though enabling it doesn't make a whole lot of difference in your config and mine. It just makes the driver load earlier in relations to the patched nvram. On my machine, I even upgraded without adding the key on my config.plist since they default to false. There is no code change if you are keeping them false and not loading openvariableruntime.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...