Cambiar de OpenCore 0.8.2 a 0.8.3

OpenCore 0.8.3 ya ha salido. Puedes obtenerlo en Acidanthera. También se han publicados sendos mensajes de PMHeart y de Dhinak en Dortania, al estilo de los mensajes que Vit9696 publicaba de forma regular hasta febrero de 2022. Estos mensajes traen un resumen de los cambios principales y, detalle importante, de los autores que hay detrás de cada cambio. Es muy recomendable leerlos. Además, tenemos en un mismo lugar los cambios que ha habido en OpenCore y las kexts.

Cambios principales

  • Correcciones para poder instalar macOS 13 Developer Beta 3
  • Se ha integrado el driver ext4 para ser utilizado con OpenLinuxBoot.efi
  • RsaTool ha cambiado para enlazar con LibreSSL en lugar de hacerlo con la librería SSL por defecto de macOS
  • Correcciones para sistemas antiguos: macOS 10.4 and 10.5
  • NVRAM emulada: se ha añadido un nuevo driver OpenVariableRuntimeDxe.efi con características interesantes: soporta NVRAM reset desde el icono correspondiente en el menú de OpenCore, permite marcar la entrada de arranque predeterminada, se ha actualizado el script de cierre de sesión para facilitar las actualizaciones de macOS desde Actualización de Software, permite tener NVRAM emulada en BIOS UEFI que tienen NVRAM nativa defectuosa o incompatible
  • Se ha añadido la propiedad LoadEarly (boolean) para drivers que se cargan antes de inicializar la NVRAM.

config.plist

NVRAM >> se ha quitado la clave LegacyEnable.

UEFI >> Drivers: se ha añadido la clave LoadEarly específicamente diseñada para OpenVariableRuntimeDxe.efi, nuevo driver que permite tener NVRAM emulada en BIOS UEFI que tienen implementación de NVRAM frágil (ej: MacPro5,1) o incompatible. Hay que actualizar config.plist.

Notas para el uso de OpenVariableRuntimeDxe.efi:

  • OpenRuntime.efi va después de OpenVariableRuntimeDxe.efi en la lista de Drivers
  • OpenVariableRuntimeDxe.efi siempre lleva LoadEarly=true
  • OpenRuntime.efi lleva LoadEarly=true solamente cuando acompaña a OpenVariableRuntimeDxe.efi (para un funcionamiento correcto de RequestBootVarRouting)
  • Hay que rellenar la sección LegacySchema
  • LegacyOverwrite=enabled para poder escribir en las variables NVRAM existentes
  • ExposeSensitiveData con el bit 01 como mínimo
  • Los valores NVRAM se cargan desde el archivo NVRAM/nvram.plist
  • OpenVariableRuntimeDxe.efi requiere soporte de escritura en sistemas FAT y espacio suficiente en la partición EFI de OpenCore para poder guardar al menos 3 archivos con los valores NVRAM
  • La opción Reset NVRAM borra el archivo NVRAM/nvram.plist sin afectar a la NVRAM subyacente
  • CTRL+Enter en el selector de OpenCore actualiza o crea el archivo NVRAM/nvram.plist.

Aclaración acerca de LoadEarly:

  • Cuando se usa OpenVariableRuntimeDxe.efi, su opción LoadEarly ha de ser TRUE.
  • Cuando se usa OpenVariableRuntimeDxe.efi, la opción LoadEarly de OpenRuntime.efi también ha de ser TRUE.
  • Para cualquier otro caso o driver, LoadEarly ha de ser FALSE.

UEFI >> Drivers >> ToogleSIP: se ha añadido la opción –show-csr (boolean) para ir como texto en la propiedad Arguments. Si se añade este parámetro, el valor hexadecimal actual de csr-active-config se muestra en la etiqueta bajo el icono del driver. No funciona si Misc >> Boot >> PickerAttributes incluye OC_ATTR_USE_GENERIC_LABEL_IMAGE que proporciona imágenes y etiquetas predefinidas para entradas del selector.

UEFI >> Audio >> SetupDelay (Integer): se han cambiado las unidades de microsegundos a milisegundos.

UEFI >> Drivers >> AudioDxe: se ha añadido el argumento opcional –codec-setup-delay (número en milisegundos). No has de cambiar nada si no utilizas SetupDelay (si SetupDelay=0). SetupDelay es necesario si la parte inicial del sonido de arranque se corta (volumen cero) o es demasiado fuerte (volumen máximo) antes de ajustarse al volumen correcto.

Drivers

OpenVariableRuntimeDxe.efi: nuevo driver para tener función NVRAM emulada en OpenCore sin tener que recurrir a OpenDuet y para tener NVRAM emulada en BIOS UEFI (ver más abajo). Los desarrolladores de OC intentan acercar la NVRAM emulada a la NVRAM nativa tanto como sea posible y ponerla a disposición de BIOS UEFI por primera vez.

Nota acerca de OpenVariableRuntimeDxe
Las máquinas antiguas con BIOS Legacy (es decir, las máquinas que no tienen firmware compatible con UEFI) pueden instalar OpenDuet desde la carpeta Utilities/LegacyBoot de OpenCore. OpenDuet se comporta como una capa de compatibilidad antes de OpenCore, para proporcionar UEFI en máquinas que anteriormente carecían de ella. Incluye emulación en memoria de NVRAM (que normalmente está presente en el hardware, en todas las máquinas compatibles con UEFI). NVRAM emulada de esta forma solamente estaba disponible en máquinas con BIOS antiguas no UEFI.
Este nuevo controlador OpenVariableRuntimeDxe permite el uso de NVRAM emulada en memoria con OpenCore, por separado de OpenDuet.
OpenVariableRuntimeDxe no solo trae NVRAM emulada a OpenCore, sino que también añade algunas mejoras en la funcionalidad incluso para los usuarios de OpenDuet (manejo correcto de reinicio de NVRAM y CTRL+Enter).
Es importante destacar que, al llevar la NVRAM emulada a OpenCore, OpenVariableRuntimeDxe abre la posibilidad de usar NVRAM emulada en lugar de NVRAM nativa en máquinas UEFI con implementaciones de NVRAM frágiles (por ejemplo, donde el uso excesivo de NVRAM puede eventualmente causar bloqueos, como en MacPro 4,1 y 5,1).
Yo supongo que esto será útil en un número pequeño de casos pero los desarrolladores de OC han creído conveniente añadir esta opción.

AudioDxe.efi: se ha añadido el argumento –force-device para ser utilizado como cadena de texto, seguida por la ruta PCI al dispositivo de audio (ej. –force-device=PciRoot(0x0)/Pci(0x1f,0x3)) permitiendo audio UEFI en algunos controladores HDA que no son reconocidos como tales.

Kexts

  • AppleALC 1.7.4: compatibilidad mejorada con High Sierra, README_CN actualizado
  • ECEnabler 1.0.3: README actualizado
  • IntelBluetoothFirmware 2.2.0: correcciones para Monterey (lee ésto)
  • Lilu 1.6.2: correción para el kernel panic que se presenta en macOS 13 Developer Beta 3
  • MacHyperVSupport 0.9: README actualizado, soporte para macOS 13, correcciones para macOS 10.4
  • VoodooI2C 2.7: correcciones para la extensión principal y las extensiones satélites
  • WhateverGreen 1.6.1: mejora del código, correcciones para la suplantación de Skylake como Kaby Lake en macOS 13.

¡¡¡Gracias, equipo de OpenCore!!!

6 comentarios en «Cambiar de OpenCore 0.8.2 a 0.8.3»

  1. Creo que esto sólo es para determinados equipos y no para todos. Veo demasiado complicado hacer que toda la comunidad cambie de estrategia de NVRAM.

    Responder
    • Por supuesto, solamente para aquellos equipos que NO pueden tener NVRAM nativa o para modelos muy específicos que, aunque tienen NVRAM nativa, es defectuosa y provoca fallos que pueden ser evitados implementando NVRAM emulada (ejemplos típicos son MacPro 4,1 y 5,1).
      La mayoría tenemos BIOS UEFI y por tanto NVRAM nativa y esto no nos aplica.
      Pero los que tienen BIOS antiguas (no UEFI) han de emular NVRAM, y pueden seguir como hasta ahora (instalar OpenDuet desde la carpeta Utilities/LegacyBoot de OpenCore) o recurrir al nuevo driver OpenVariableRuntimeDxe que evita el uso de OpenDuet y añade algunas mejoras. Sin olvidar la que puede ser su utilidad principal que, aunque muy restringida en número de usuarios, permite mejorar el funcionamiento de la NVRAM en los comentados MacPro 4,1 y 5,1 que tienen NVRAM nativa pero mal implementada.

      Responder
  2. Gracias por el artículo. Una duda. Puedo seguir teniendo NVRAM emulada como hasta ahora o necesariamente he de cambiar al nuevo driver OpenVariableRuntimeDxe?

    Responder
    • No es obligatorio el cambio. Puedes seguir teniendo la NVRAM emulada igual que la has tenido hasta ahora. Pero añadiendo el nuevo driver tienes algunas mejoras en el manejo de la NVRAM.
      Lo que hace diferente al nuevo driver es que permite llevar la NVRAM emulada a máquinas UEFI que hasta ahora no podían tenerla, sólo podían tenerla nativa. ¿Y quién querría llevar NVRAM emulada a máquinas UEFI? Yo pienso que va a ser en muy pocos casos en los que la BIOS UEFI tiene una mala implementación de la NVRAM y no se puede hacer que funcione bien en modo nativo con macOS.

      Responder

Responder a Eli Cancelar la respuesta