OpenCore, el gestor de arranque de nuestro Mac ProActualmente hay dos gestores de arranque (bootloaders) que se pueden utilizar para iniciar macOS en nuestro PC: Clover y OpenCore. Clover tiene un planteamiento más clásico y es un poco más "dinosaurio" con mucha historia a sus espaldas, y OpenCore, que ha sido mi elección porque es mucho más moderno, y está increÃblemente bien documentado y estructurado. En
este enlace tenéis una comparativa de uno frente a otro, aunque está elaborada por OpenCore y podrÃa no ser imparcial.
Como os decÃa, OpenCore está increÃblemente bien documentado y el único inconveniente que le veo es que la documentación está en inglés, lo cual puede hacerlo menos accesible, pero el rigor y la calidad de la documentación es fantástico y da gusto pasearse por
la guÃa de instalación de OpenCore en el proyecto Dortania.
En esta guÃa os contaré los pasos que he seguido para mi configuración, pero la guÃa de Dortania cubre todo tipo de plataformas, tanto Intel como AMD en sus distintas generaciones de procesadores, y ahà podéis encontrar todo lo necesario para el proceso de pre-instalación, instalación y post-instalación para terminar con éxito cualquier proyecto que utilice hardware compatible.
Hay muchÃsima información y es necesario leerla bien a fondo y por completo si se quiere acabar con un sistema al 100%. Es muy fácil dejarse algo por el camino y que el sistema "casi funcione", pero que no lo esté haciendo como debe.
OpenCore se instala en una carpeta llamada EFI que se almacena dentro de la partición EFI, no os despistéis con ello. Es el mismo nombre el que tiene la partición y la carpeta.
Preparación de la carpeta EFIEl siguiente paso es descargar el bootloader OpenCore
desde su GitHub. A dÃa de hoy la última versión es la 0.6.3 y es la que usaremos como gestor de arranque tanto de nuestro pendrive de instalación, como de nuestra instalación definitiva. El enlace para la descarga está al final de la lista de las notas de la versión, y descargaremos el archivo OpenCore-0.6.3-RELEASE.zip. Hay otro que indica DEBUG pero nos interesa este.
Descomprimimos el archivo descargado y vemos que entre otras carpetas, contiene una llamada EFI que es la que nos interesa. Esa carpeta contiene la estructura base de nuestra carpeta EFI que tendremos que completar, y una vez revisada, es la que tendremos que copiar en la partición EFI oculta que acabamos de montar con MountEFI.
Empiezo por el final, y aquà podéis ver el contenido de la carpeta EFI que estoy utilizando en mi equipo. Veréis que está organizado en carpetas y he añadido un breve comentario junto a cada componente y también la versión del mismo, y a continuación os detallaré qué es lo que hace cada uno de ellos y tendréis sus enlaces de descarga.
El equipo de OpenCore mantiene actualizado su bootloader y la mayorÃa de los componentes que utilizamos para nuestra carpeta EFI
en su repositorio de Github y mi configuración está basada en la última versión 0.6.3
https://github.com/acidanthera/OpenCorePkg/releases/tag/0.6.3Una vez descomprimido el archivo OpenCore-0.6.3-RELEASE.zip, podéis copiar la carpeta EFI que está dentro de la carpeta X64, ya que contiene la estructura base de la carpeta EFI que personalizaremos para nuestro sistema.
Además del núcleo de OpenCore, que realiza la función del gestor de arranque, necesitaremos descargar más componentes que tendremos que guardar en las distintas carpetas ACPI, Drivers, Kexts y Resources. Todas son necesarias, pero la más importante es la carpeta Kexts, que es como se llaman a las extensiones del Kernel del sistema operativo que se ejecutarán antes de iniciar macOS y que se encargarán de "realizar la magia" y convencer a macOS de que lo que hay debajo es hardware 100% compatible.
ACPI y parcheo de la DSDTLa carpeta ACPI contiene las tablas DSDT que describen con detalle el hardware de nuestro equipo, y si queremos conseguir que nuestro equipo funcione a la perfección, necesitaremos extraer las tablas DSDT, revisarlas, parchearlas y compilarlas.
El proyecto OpenCore ofrece unas DSDT genéricas para los diferentes chipsets, y hablan de todo esto
en su documentación online.
- SSDT-PLUG para la gestión de energÃa
- SSDT-EC/USBX para el controlador embebido
- SSDT-AWAC/RTC0 para corregir el reloj del sistema
- SSDT-PMC para ajustar la NVRAM
Con esto el sistema funciona, pero no funciona perfecto ya que no conseguiréis que macOS identifique correctamente todos los componentes hardware, y entre otras cosas hay que mapear los puertos USB para que coincidan con los que tiene realmente vuestro equipo.
Para que todo se detecte perfectamente por macOS Big Sur, hay que extraer el binario de la DSDT, decompilarlo, analizarlo, editarlo para adaptarlo a macOS y volverlo a compilar. Y eso requiere de un conocimiento profundo no solo de tu hardware, sino de las herramientas necesarias para hacerlo.
Aquà podéis ver el contenido de mi archivo DSDT.aml abierto por el programa MACIasl, posicionado en el código que define los puertos USB, y a la izquierda el contenido del programa IO Registry Explorer, equivalente al registro de Windows y que es la representación interna que tiene macOS sobre nuestro hardware.
Si pulso "compilar", aparecen tan solo unos warnings, pero el archivo DSDT está perfecto y lo guardo a buen recaudo junto con el resto de mi carpeta EFI.
Este capÃtulo de ACPI es demasiado complejo para mi, asà que he utilizado un atajo y he recurrido a Mald0n, del
foro Olarila, que probablemente sea la persona que más sabe sobre este tema y que tiene bastante industrializado el proceso de creación de la DSDT que necesitáis para vuestra configuración.
Si os pasáis por su foro, veréis que a cambio de un donativo os ofrece el servicio de parcheo de la DSDT. De hecho, tiene un programa "Runme.app" que se encarga de extraer la información necesaria de vuestro sistema y generar un archivo comprimido, que se lo pasáis a Mald0n por privado y os devuelve el archivo con el resultado.
No exige cantidades concretas y el servicio que ofrece me parece que bien merece esa donación, pero esto es un tema muy personal y si no queréis hacerlo, podéis usar la configuración estándar de OpenCore o intentar parchearlo por vuestra cuenta.
En mi caso y tras una breve conversación - con permiso de la diferencia horaria con Brasil - Mald0n me envió el archivo
DSDT.aml y el archivo
SSDT-TB3HP.aml que es un complemento necesario para Thunderbolt. Con esos archivos colocados en la carpeta ACPI, todos los componentes son reconocidos a la perfección por macOS Big Sur.
Kexts (Kernel Extensions)Estas extensiones del kernel del sistema operativo son las responsables de "maquillar" el hardware para que se identifique frente al sistema como una componente soportado por macOS Big Sur.
VirtualSMC es un emulador de SMC, que es la consola de gestión del sistema de los equipos Apple, una especie de director de orquesta del hardware. Existe una alternativa muy popular llamada FakeSMC, pero prefiero quedarme con la oficial del proyecto OpenCore, actualmente en la versión 1.1.8.
Además del archivo VirtualSMC.kext, tendremos que copiar los archivos SMCProcessor.kext y SMCSuperIO.kext, responsables de presentar los sensores de funcionamiento del procesador y de los dispositivos de entrada / salida al sistema operativo.
https://github.com/acidanthera/VirtualSMC/releases/tag/1.1.8LiLu es un parcheador de extensiones que es prerrequisito para otras opciones, y se ha actualizado a la versión 1.4.9
https://github.com/acidanthera/Lilu/releases/tag/1.4.9WhateverGreen es una extensión que presenta nuestra gráficas tal y como necesita verla macOS, actualizada a la versión 1.4.4.
https://github.com/acidanthera/WhateverGreen/releases/tag/1.4.4AppleALC presenta nuestra tarjeta de sonido como una tarjeta geniuna de Apple, y se ha actualizado a la versión 1.5.4
https://github.com/acidanthera/AppleALC/releases/tag/1.5.4NVMeFix se encarga de eliminar la limitación que impone Apple para que los discos SSD que se usan sean los suyos, y consigue que nuestros discos SSD NVMe funcionen de forma nativa. La última versión es la 1.0.5
https://github.com/acidanthera/NVMeFix/releases/tag/1.0.4IntelMausi se encarga de la tarjeta Ethernet Intel I219V7 que utilizo como principal. Actualizado a a versión 1.0.4
https://github.com/acidanthera/IntelMausi/releases/tag/1.0.4Os recomiendo que os paséis de vez en cuando por el repositorio bugtracker que el proyecto Acidenthera tiene en GitHub, en donde mantienen actualizado un listado del estado de cada uno de sus proyectos.
Mejor aún, os recomiendo que os registréis en GitHub y que marquéis como "Watch > Releases only" cada uno de los repositorios que os interesan y asà os llegará al correo un mensaje cuando haya una nueva versión.
https://github.com/acidanthera/bugtrackerAdemás de los componentes del proyecto Acidanthera mantenidos por el equipo de OpenCore, usamos algún componente más de otros desarrolladores de la comunidad.
SmallTreeIntel82576 se encarga de la tarjeta Ethernet Intel secundaria, en este momento en versión 1.3.0
https://github.com/khronokernel/SmallTree-I211-AT-patch/releases/tag/1.3.0Resolviendo el problema de la memoria en MacPro7,1macOS presenta un error cuando usamos memoria que no es ECC en un MacPro, y para resolverlo se utiliza el kest
MacProMemoryNotificationDisabler. Actualmente está en versión 1.1 y funciona con macOS Catalina, pero no en macOS Big Sur. Es un problema estético y no impide el correcto funcionamiento, pero me gusta dejar las cosas bien y he dado con una solución.
La clave está en activar una opción en el archivo config.plist que lleva la personalización de OpenCore llamada "CustomMemory", y definir de forma manual los 12 slots de memoria que tiene un MacPro de 2019 original, y rellenarlos con los módulos de memoria que tenemos en sus slots correctos, y con módulos falsos de 1MB en los que hemos creado.
Todo está documentado en este capÃtulo de la guÃa de Dortania
https://dortania.github.io/OpenCore-Post-Install/universal/memory.html#mapping-our-memoryNo es necesario indicar que la memoria que se está usando sea ECC, pero sà que es necesario que todos los módulos estén identificados y con al menos 1MB de RAM. Aquà veis qué pasa si dejo uno de ellos con 0MB de RAM, macOS Big Sur muestra el error de nuevo y marca todos los módulos en naranja.
Asà que con todos los módulos identificados, el problema queda resuelto. No es la forma más elegante y me hubiera gustado poder indicar que los módulos falsos están vacÃos, pero me vale perfectamente.
Y ahora el sistema reconoce perfectamente los 32GB de RAM como memoria soportada y bien instalada.