[Hackintosh Coffee Lake] Gigabyte Z370 HD3P - Intel Core i7-8700K - 16 Go RAM - Radeon RX 570 - macOS/Windows - avec OpenCore, Retex/Guide complet Hackintosh avec OpenCore et carte mère Z370 HD3P

[MaxPoska]

Hackintosh Coffee Lake

OpenCore - Z370 HD3P

Avertissement:

Ce topic n'est pas un guide complet universel pour créer un hackintosh de zéro pour toutes les configurations.
C'est un retour d'expérience (retex) et guide détaillé d'installation de macOS sur ma configuration avec carte mère Z370 HD3P avec l'aide d'OpenCore et qui peut éventuellement aider d'autres personnes qui souhaitent se lancer dans l'aventure hackintosh et qui ont la même configuration
Je ne prétends pas détenir la vérité absolue donc si vous avez des remarques ou suggestions sur le paramétrage n'hésitez pas

-----------
-----------

Sommaire:

Dans le post 1:

• Setup
  Liste des composants matériels de ma configuration
• Liens utiles
  OpenCore et Guides Dortania
  Kexts utilisés
  SSDT utilisés
  Utilitaires divers utilisés
  Dossier EFI
• Création d'une clé USB d'installation avec OpenCore
  Création de la clé
  Installation des éléments nécessaires dans la partition EFI de la clé (OpenCore, SSDT, Drivers, Kexts, "Resources")
  
  Fin du post 1 et détails de chaque section dans le post 2:
  
• Paramétrage du config.plist
  
  Dans le post 3:
  
• Paramétrage du BIOS
  Explication sur la version du BIOS utilisée
  Paramétrage
• Installation de macOS
  Installation de macOS
  Démarrage sans clé USB
• Installation de Windows
  Préparation de l'installation de Windows
  Installation des pilotes de la carte Broadcom BCM94360CD (Bluetooth/Wifi)
  
  Dans le post 4:
  
• Fignolage (config.plist, réglage BIOS, Bootcamp)
  Finalisation du config.plist
  Réglage ordre de boot BIOS
  Windows: Installation de Bootcamp 6 et pilotes pour Magic Keyboard et Magic Mouse 2
  Réglage du système à démarrer au démarrage
  
  Dans le post 5:
  
• Détails sur l'injecteur USB
  Inventaire des ports USB
  Détails sur le Kext injecteur
• Gérer les mises à jour d'OpenCore
  Méthodologie théorique pour faire une mise à jour d'OpenCore
  Cas pratique (passage d'OpenCore 0.7.2 vers 0.7.3)

-----------
-----------

• Le setup:

Je n'ai pas changé grand chose depuis l'achat de la config en 2019 (juste changé 1 disque dur pour le stockage).
Les changements sont surtout autour du hackintosh (chaise, éclairages..)

Carte mère: Gigabyte Z370 HD3P
Processeur: Intel Core i7-8700K @ 3,7 Ghz (6 coeurs / 12 threads / turbo jusqu'à 4,7 Ghz)
Ventirad: BeQuiet Dark Rock 4
Boitier: Fractal Design Define R5
Alimentation: BeQuiet Straight Power 11 750W 80PLUS Gold
Mémoire RAM: Corsair Vengeance LPX 16Go (2x8Go) DDR4 2666MHz (CMK16GX4M2A2666C16)
Carte Graphique: Sapphire PULSE Radeon RX 570 4Go GDDR5 (2xHDMI / 2xDisplayPort)
Carte Wifi et Bluetooth: Broadcom BCM94360CD
SSD: 1xSSD NVME M.2 WD SN750 de 1TO (version avec dissipateur) pour macOS et 1xSSD MX 300 750 Go pour Windows.
Disques durs: Plusieurs disques durs WD pour stockage données et sauvegarde Time Machine
Ecrans: 2x Dell U2417H Full HD 1080p (1 sur pied et 1 sur bras)
Enceintes: Bose Companion 20
Webcam: Logitech HD Pro C920
Périphériques: Magic Mouse 2 et Magic Keyboard

(Ne vous laissez pas distraire par les Avengers, le hackintosh est le boitier en bas à gauche )

-----------

• Liens utiles:

OpenCore: https://github.com/acidanthera/OpenCorePkg/releases/
OCBinaryData: https://github.com/acidanthera/OcBinaryData
Guide Dortania pour OpenCore: https://dortania.github.io/OpenCore-Install-Guide/
Guide Dortania Post-installation OpenCore: https://dortania.github.io/OpenCore-Post-Install/

Les 2 guides Dortania sont très utiles pour appréhender l'utilisation d'OpenCore.
J'ai pu réaliser ce hackintosh sous OpenCore grâce à ces 2 guides .
J'y ferais souvent référence dans ce retex.

Kexts utilisés:
VirtualSMC (et plugins): https://github.com/acidanthera/VirtualSMC/releases
Lilu: https://github.com/acidanthera/Lilu/releases
WhateverGreen: https://github.com/acidanthera/WhateverGreen/releases
AppleALC: https://github.com/acidanthera/AppleALC/releases
IntelMausi: https://github.com/acidanthera/IntelMausi/releases
NVMeFix: https://github.com/acidanthera/NVMeFix/releases
USB-Map-Z370HD3P: Injecteur USB personnalisé pour la Z370 HD3P (pour plus d'infos, voir la partie "détails sur injecteur USB" dans le post 5 du retex): https://www.dropbox.com/s/2z3c4etlpgaqnra/U...P.kext.zip?dl=0

SSDT utilisés:
SSDT-Plug (CPU Power Management): https://github.com/dortania/Getting-Started...PLUG-DRTNIA.aml
SSDT-EC-USBX: https://github.com/dortania/Getting-Started...SBX-DESKTOP.aml
SSDT-AWAC: https://github.com/dortania/Getting-Started...d/SSDT-AWAC.aml

Utilitaires utilisés:
MountEFI: https://github.com/corpnewt/MountEFI
ProperTree: https://github.com/corpnewt/ProperTree
OCConfigCompare: https://github.com/corpnewt/OCConfigCompare

Dossier EFI:
Je vous mets à disposition mon dossier "EFI" pour la Z370 HD3P de la clé USB d'installation basé sur OpenCore 0.7.3: https://www.dropbox.com/s/wrodbwt1s4vjusc/E...70HD3P.zip?dl=0
ATTENTION: Il y a quelques réglages à faire dans le config.plist avant d'utiliser ce dossier "EFI":

- Si vous n'utilisez pas le BIOS modifié par Gigabyte pour avoir l'option "CFG-Lock" de disponible dans le BIOS (voir le détails dans le post 3 du retex) vous devrez alors passer le paramètre "AppleXcpmCfgLock" à "True" dans le config.plist dans la section "Kernel --> Quirks"
- Le config.plist mis en partage est vierge de numéros de série. Vous devrez générer les vôtres à l'aide de l'outil GenSMBIOS et renseigner les paramètres nécessaires dans la section "PlatformInfo"

Vous trouverez plus de détails sur comment modifier le config.plist à la fin de ce post et les détails des paramètres à renseigner dans la section "PlatformInfo" ainsi que l'utilisation de GenSMBIOS dans le post 2.

- Le config.plist est réglé pour être en mode verbose. Vous pouvez lire la partie "fignolage" du retex dans le post 4 pour savoir comment le retirer en post installation.


Je vais maintenant vous expliquez ce que contient ce dossier "EFI" et comment j'ai fait étape par étape

• Création d'une clé USB d'installation et utilisation d'OpenCore

Création de la clé USB:

Dans ce retex, j'ai installé macOS Big Sur (11.5.2) avec l'aide d'OpenCore 0.7.2.

Dans un premier temps, après avoir téléchargé la version de macOS voulu, il faut créer une clé USB bootable.
La première étape consiste à créer une clé USB d’installation tout à fait banale comme indiqué par Apple ici

Je formate donc une clé USB au format "Mac OS étendu (journalisé)" avec le schéma "Table de partition GUID" à l’aide de l’utilitaire de disque de macOS. Je nomme ma clé "MyVolume" (le nom de la clé n’a pas d’importance du moment qu’il est raccord avec le nom présent dans la commande suivante).



Ensuite, grâce à la commande "createinstallmedia", je lance la création de la clé USB d’installation.

Donc, dans mon cas, pour l’installation de macOS Big Sur, je tape cela dans le terminal:

Code

sudo /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume

Une fois le processus de création de la clé terminé, il faut maintenant la rendre "compatible hackintosh".
C’est là que l’on va "installer" le bootloader OpenCore.

Tout d'abord, il faut monter la partition "EFI" de la clé USB. C’est dans cette partition que l'on déposera tous les fichiers nécessaires au Hackintosh (OpenCore, les drivers d’OpenCore, les kexts ect ect)

Pour cela, on a besoin de l’utilitaire "MountEFI"
Au premier lancement, il faut faire un clique droit sur "MountEFI.command" et cliquer sur "Ouvrir" pour pouvoir lancer l’utilitaire.
On sélectionne ensuite le disque pour lequel on souhaite monter la partition EFI et qui correspond à notre clé USB (pour mon cas ici, c’est le "2")


La partition "EFI" apparaitra alors dans le Finder


Installation des éléments nécessaires dans la partition EFI de la clé (OpenCore, SSDT, Drivers, Kexts, "Resources"):

On va maintenant installer ce qu’il faut dans la partition "EFI".
C'est ici que nous avons besoin d'OpenCore.
Je télécharge la version "RELEASE" d’OpenCore.
Ce retex se base sur la dernière version d'OpenCore disponible au moment de son écriture, c'est à dire la version 0.7.2.

Nous aurons aussi besoin de OCBinaryData qui contient des ressources pour l’interface graphique d’OpenCore (et qui contient aussi le driver "HFSPlus.efi" qui nous sera utile ).

Il faut ensuite copier le dossier "EFI" qui se trouve dans le répertoire "X64" du dossier OpenCore que l'on a téléchargé, et le coller dans la racine de la partition "EFI" de notre clé USB.
Attention à bien copier le dossier "EFI" lui même et pas seulement son contenu.



On va ensuite avoir besoin d’ajouter des fichiers supplémentaires:

- Les SSDT

Les fichiers SSDT dont on a besoin ici sont, pour faire très simple, des fichiers qui vont permettre de mieux identifier certains éléments matériels de notre configuration.
Je ne vais pas entrer dans le détail volontairement car je ne maitrise pas ces notions.
Vous pouvez aller jeter un coup d’oeil ici du guide de Dortania si vous voulez en savoir plus .

Personnellement, je n’ai pas créé mes SSDT personnalisés. J’ai repris les fichiers universels proposés par le guide de Dortania et qui suffisent amplement.

Pour notre carte mère (chipset Z370) et notre processeur (de génération Coffee Lake), nous avons besoin des 3 fichiers suivants:
- SSDT-Plug: Pour la gestion d’alimentation du CPU
- SSDT-EC-USBX: Pour la gestion des ports USB (à utiliser en plus du kext injecteur USB)
- SSDT-AWAC: Pour la gestion de l’horloge système, utile seulement si vous êtes sur un BIOS supérieur à la version F11 sur la Z370-HD3P.

Ces fichiers sont à déposer dans le répertoire "EFI/OC/ACPI" dans notre partition "EFI" de la clé USB.

- Les Drivers

Les drivers vont permettre à OpenCore d'exploiter notre matériel afin de démarrer macOS mais aussi, certains de ces drivers vont permettre à OpenCore d’étendre ses possibilités pour, par exemple, gérer une interface graphique dans le menu de boot, de gérer l’audio au démarrage (pour avoir le "gong" de démarrage des vrais Mac par exemple ) etc etc

Si vous voulez plus d’informations sur ce que font tous les drivers fournis avec OpenCore, vous trouverez les infos dans le document "Configuration.pdf" présent dans le répertoire "Docs" du package d'OpenCore que l'on a téléchargé.

Attention à ne pas confondre ces drivers là (utilisés par OpenCore) avec les Kexts, que l'on verra plus tard et qui sont aussi des sortes de drivers mais utilisés cette fois par le système (macOS).

Pour ma part, je n’utilise que les drivers suivants:

Ils sont dans le répertoire "EFI/OC/Drivers" dans notre partition "EFI" de notre clé USB.

- AudioDxe.efi : qui permet à OpenCore d'avoir accès au contrôleur audio (pour ajouter le petit "gong" de démarrage)
- CrScreenshotDxe.efi : qui me permet de fait des screenshots lorsque je suis sur le menu d’OpenCore
- OpenRuntime.efi: qui permet une gestion de la mémoire (driver indispensable et obligatoire)
- OpenCanopy.efi: qui permet à OpenCore d'avoir accès aux ressources graphiques (pour qu'OpenCore puisse avoir une interface graphique)

J’ajoute un 5ème driver qui provient de OCBinaryData et qui se trouve dans le dossier "Drivers" d'OCBinaryData, c’est:

- HfsPlus.efi: qui permet à OpenCore de voir les partitions HFS (comme par exemple la partition Recovery).

Je supprime tous les autres drivers qui sont présents dans "EFI/OC/Drivers" et qui ne me servent pas.

- Les Kexts

Les Kexts sont un peu comme les drivers (pilotes) utilisés par macOS. Si vous voulez plus d’infos, je vous invite à lire ce topic sur Macbidouille

J’utilise les kexts suivants (à chaque fois, je télécharge le version "RELEASE" des Kexts):

- VirtualSMC.kext: Qui permet de simuler la puce SMC présente sur les Mac (Kext indispensable et obligatoire)
- SMCProcessor.kext : fait partie du package de VirtualSMC. C’est un plugin servant au monitoring (Température CPU)
- SMCSuperIO.kext: fait partie du package de VirtualSMC. C’est un plugin servant au monitoring (Vitesse ventilateur)
- AppleALC.kext: Pour la reconnaissance du contrôleur audio (ALC1220)
- WhateverGreen.kext: Pour la gestion de la carte graphique AMD (RX 570)
- Lilu.kext: Qui est indispensable pour VirtualSMC, WhateverGreen et AppleALC
- IntelMausi.kext: Pour la reconnaissance du contrôleur Ethernet présent sur notre carte mère (i219V)
- NVMeFix.kext: Qui permet de mieux gérer la consommation des SSD Nvme tiers
- USB-Map-Z370HD3P.kext : Mapping personnalisé des ports USB de la carte mère Z370 HD3P créé par mes soins (voir la partie "Détails sur l'injecteur USB" dans le post 5 pour plus de détails sur la nécessité de ce kext et sur les ports USB qui y sont référencés).

Ces kexts sont à mettre dans le répertoire "EFI/OC/Kexts" dans notre partition "EFI" de la clé USB.

- Les "Resources"

Les fichiers présents dans ce dossier vont permettre à OpenCore d'avoir une interface graphique et d'avoir des fichiers audios à gérer au démarrage (comme le "gong" de démarrage par exemple)

Le répertoire "EFI/OC/Resources" contient, de base, 4 sous répertoires: "Audio", "Font", "Image", "Label" qui sont vides.

On va remplacer ces répertoires par ceux présents dans OCBinaryData, qui eux, contiennent les médias nécessaires

Donc je supprime ces 4 sous répertoires et je les remplace par les 4 même sous répertoires d’OCBinaryData qui contiennent les fichiers audio, de polices, d’icônes ect.

- Les "Tools"

Les fichiers présents dans ce répertoire sont des outils autonomes qui permettent de faire certaines actions.
De même que les drivers OpenCore, si vous voulez plus d’informations sur ce que font tous ces outils fournis avec OpenCore, vous trouverez les infos dans le document "Configuration.pdf" présent dans le répertoire "Docs".

Ces outils sont dans le répertoire "EFI/OC/Tools" dans notre partition "EFI" de la clé USB.

Je n’entre pas dans le détail ici car je les supprime tous (attention je supprime seulement les fichiers présents dedans mais je garde le répertoire "Tools" qui est donc vide)

- Le "config.plist"

Il nous reste un dernier fichier à ajouter à notre partition "EFI" c’est le "config.plist".

C'est LE fichier le plus important.

Il s'agit du fichier de configuration d’OpenCore que l’on va devoir customiser

L’idée est de se baser sur le fichier "sample" qui se trouve dans le répertoire "Docs" du package d’OpenCore que l’on a téléchargé.


On copie ce fichier "sample" et on vient le coller dans le répertoire "EFI/OC" dans notre partition "EFI" de la clé USB.
On renomme ensuite ce fichier "config.plist"

Une fois ce fichier ajouté, notre dossier "EFI" est complet

Il devrait ressembler à ça:


ATTENTION: On ne peut pas encore démarrer sur la clé. Il faut maintenant "customiser" le config.plist (le "sample" ne peut pas s’utiliser en l'état).

C'est ce que l'on va voir dans la prochaine étape

• Paramétrage du config.plist

Donc, avoir copié le "sample.plist" dans notre dossier "EFI" et l'avoir renommé en "config.plist" n'est pas suffisant et il faut maintenant le customiser.
On doit, en effet, le personnaliser, afin qu'ils correspondent à notre configuration.

On va pas se le cacher, c’est l’étape la plus longue et chiante ... mais tout va bien se passer

Pour commencer, il nous faut un éditeur plist.
J’ai utilisé celui recommandé par le guide de Dortania: ProperTree car il possède des fonctions propres à l'utilisation d'OpenCore (comme le "OCSnapshot" que l'on va voir plus bas)

Une fois le dossier téléchargé, aller dans le répertoire "Scripts" et faire un clique droit sur le fichier "buildapp-select.command" et cliquer sur "Ouvrir" afin de créer une app dédiée.



Il se peut qu’une fenêtre s’ouvre vous demandant d’installer des outils supplémentaires pour python 3.
Installer les.



Ensuite, s'il y a plusieurs versions de python installés sur votre machine, le programme vous demandera celui que vous souhaitez utiliser.
Choisir python3



Le programme créera alors une app "ProperTree" à la racine du dossier.


Déplacer la alors dans le dossier "Applications" et on est prêt

Une fois l'application lancée, ouvrir le fichier "config.plist" qui se situe dans le dossier "EFI/OC" de la partition "EFI" de la clé USB (soit par le menu "file" --> "Open" ou le raccourci clavier "Cmd + O")

La première étape consiste à déclarer les fichiers SSDT, Kexts et Drivers dans le config.plist et dont on a besoin.
En effet, c'est un différence avec le bootloader Clover.
Avec OpenCore, les SSDT, Kexts, Drivers et Tools doivent être déclarés dans le config.plist pour pouvoir être pris en compte.

Pour ce faire, ProperTree a une fonction bien pratique qui permet de faire cette déclaration automatiquement: Le "Snapshot"
Sélectionner le menu "OC Clean Snapshot" dans ProperTree (menu "File"-->"OC Clean Snapshot" ou le raccourci clavier "Cmd + Shift + R")

On choisit le répertoire "OC" qui se trouve dans le dossier "EFI" de notre partition "EFI" de la clé USB


Cette action va permettre de déclarer les fichiers SSDT, Kexts, Drivers et Tools qui sont dans notre dossier "EFI", directement dans le config.plist (et, par la même occasion, supprimer la déclaration de ceux qui sont par défaut dans le sample).

Ensuite, nous voila maintenant prêt à configurer les différentes sections du config.plist

Il y a 8 sections à configurer (et chaque section à ses propres sous sections)



Ces sections se paramètrent en fonction de la génération du processeur et, pour certains paramètres, en fonction du chipset.

Je me suis basé sur cette partie du guide de Dortania pour savoir ce que je devais paramétrer pour la génération de processeur "Coffee Lake" (puisque le processeur i7-8700K est de cette génération) ainsi que la partie post Install du guide de Dortania pour la configuration de l’audio et interface graphique

Je vais uniquement indiquer les paramètres que j’ai modifiés/ajoutés par rapport au sample sans entrer dans le détail de chacun d’eux.
Si je ne parle pas d’un paramètre c’est que j’ai laissé la valeur par défaut définie dans le sample.

Je ne peux que vous encouragez à aller voir le guide de Dortania et/ou voir le document "Configuration.pdf" pour avoir le détail de chaque paramètre et comprendre à quoi il sert.

Et c’est parti (dans le post suivant)

Ce message a été modifié par MaxPoska - 2 Oct 2021, 22:35.

[MaxPoska]

ATTENTION: Je rappel que le retex est basé sur OpenCore 0.7.2.
Il peut y avoir des propriétés qui ont, entre-temps, été ajoutées/supprimées avec les mises à jour plus récente d'OpenCore (voir "Gérer les mises à jour d'OpenCore" du retex dans la 2ème partie du post 5)

-- ACPI --

Pas grand chose à faire dans cette section.
Il faut juste vérifier que les 3 SSDT (et uniquement ceux-là) que l’on a ajoutés dans le répertoire "EFI/OC/ACPI" sont bien présents dans la section ACPI --> Add et qu'ils sont bien activés ("Enabled" --> "True").
Ils ont normalement été ajoutés automatiquement grâce au snapshot que l’on a fait précédemment.



-- Booter --

Section Quirks (Booter --> Quirks)

DevirtualiseMmio --> True
EnableWriteUnprotector --> False
RebuildAppleMemoryMap --> True
SyncRuntimePermissions --> True



-- DeviceProperties --

Section Add (DeviceProperties --> Add)

Ici, je vais paramétrer l’audio et la carte graphique intégrée au CPU (UHD 630) afin que ces 2 éléments puissent être bien reconnu par macOS.

Pour l’audio:

Je remplace "PciRoot(0x0)/Pci(0x1b,0x0)" présent dans le sample par "PciRoot(0x0)/Pci(0x1F,0x3)" qui définit l’adresse du contrôleur audio intégré sur la Z370 HD3P (ALC1220).

Ensuite je définis le layout id sur "5":

layout-id --> 05000000

On peut voir la liste des layouts supportés pour notre codec (ALC1220) ici.
On voit qu'il y a plusieurs layouts compatibles avec notre codec (1, 2, 3, 5, 7, 11, 13, 15, 16, 17, 21, 27, 28, 29, 30, 34, 35, 98, 99, 100)
Je ne les ai pas tous testés et le "5" me donne satisfaction sur la qualité audio sur les haut-parleurs branchés sur la sortie audio (prise verte) à l'arrière de la carte mère ainsi que sur des écouteurs branchés via la prise casque sur l'avant du boitier.

Voir ici sur le guide de Dortania pour plus de détails sur le réglage de l'audio avec OpenCore.

Pour la carte graphique intégré au processeur (UHD 630):

Il faut créer une nouvelle entrée dans la sous section "Add".

Pour cela, on fait un clique droit sur "Add" et on clique sur "New Child under ‘Add’ (+)" .
On nomme la propriété "PciRoot(0x0)/Pci(0x2,0x0)" et on définit le type sur "Dictionnary".

Enfin, on fait un clique droit sur ce nouvel élément comme précédemment pour y ajouter une sous section ("New Child under ‘PciRoot(0x0)/Pci(0x2,0x0)’ (+)") et on nomme cette sous section "AAPL,ig-platform-id" de type "Data" avec la valeur "0300913E ".

Pour être précis, la valeur à définir sur la propriété "AAPL,ig-platform-id" ne sera pas la même si vous utilisez le GPU interne pour gérer votre affichage (si vous n’avez pas de carte graphique dédiée).
En effet, pour ma part, j’utilise une carte graphique dédié (dGPU) qui est ma RX570 pour gérer l’affichage.
J’ai donc besoin d’activer et de paramétrer le processeur graphique du CPU uniquement pour du calcul pour certaines tâches du système et non pour l’affichage.

Si vous n’avez pas de carte graphique dédiée et utilisez la carte graphique interne au processeur pour gérer votre affichage, je vous recommande la lecture de ce passage du guide de Dortania pour savoir quelle valeur il vous faut pour le paramètre "AAPL,ig-platform-id"



-- Kernel --

Section Add (Kernel --> Add)

On doit normalement retrouver ici les Kexts que l’on a ajouté dans "EFI/OC/Kexts"
Ils ont normalement été ajoutés automatiquement grâce au snapshot que l’on a fait précédemment.
On vérifie aussi qu'ils sont bien activés ("Enabled" --> "True")




Section Quirks (Kernel --> Quirks)

AppleXcpmCfgLock --> False

ATTENTION: Un mot sur ce paramètre.

Ce paramètre permet de patcher macOS lorsque l'on n'a pas la possibilité de désactiver le CFG-Lock dans le BIOS.

De base, dans le BIOS de la Z370 HD3P, vous n’avez pas la possibilité de désactiver le CFG-Lock.
Pour ma part, Gigabyte m’a envoyé une version modifiée du BIOS F14a dans laquelle figure cette option (voir "Paramétrage du BIOS" du retex dans le post 3 où je parle de ce BIOS avec cette option, que je mets en partage si vous souhaitez l'utiliser)

Cela me permet de passer le paramètre AppleXcpmCfgLock à "False" pour ne pas à avoir patcher macOS.

Si vous n’utilisez pas ce BIOS modifié, il faudra que vous passiez le paramètre AppleXcpmCfgLock à "True".

DisableIoMapper --> True
PanicNoKextDump --> True
PowerTimeoutKernelPanic --> True



Section Scheme (Kernel --> Scheme)

KernelArch --> x86_64



-- Misc --

Section Boot (Misc --> Boot)

HideAuxiliary --> False (par défaut dans le sample)

Je le laisse à faux sur la clé USB mais je le passerai à vrai en post-installation (voir la partie "Fignolage" du retex dans le post 4)
Cela permettra de cacher les partitions auxiliaires dans le menu de boot d'OpenCore (comme la partition "recovery" par exemple)

LauncherOption --> Disabled (par défaut dans le sample)

Je le laisse à "Disabled" sur la clé USB mais je le passerai à "Full" en post-installation (voir la partie "Fignolage" du retex dans le post 4)
Cela sert au multiboot avec Windows et me permettra d'avoir l’option "OpenCore" dans les choix de boot dans le BIOS.

PickerMode --> External
PickerVariant --> Acidanthera\GoldenGate

Ces 2 paramètres me permettent d'avoir une interface graphique dans le menu de boot d'OpenCore.

J’utilise le set d’icônes "GoldenGate" que l’on a copié dans dans le dossier "EFI/OC/Resources".
Les sets d’icônes se trouvent dans le dossier "EFI/OC/Resources/Image/Acidanthera"

Vous avez 3 sets d’icônes fournis avec OCBinaryData: Chardonnay, GoldenGate, Syrah

A vous de choisir en fonction de vos goûts

Plus d’infos sur le paramétrage de l’interface graphique dans le guide de Dortania ici



Section Debug (Misc --> Debug)

ApplePanic --> True
DisableWatchDog --> True



Section Security (Misc --> Security)

AllowNvramReset --> True
AllowSetDefault --> True
ScanPolicy --> 0
Vault --> Optional



Section Tools (Misc--> Tools)

Cette section est normalement vide car je n’ai gardé aucun tools (dossier "EFI/OC/Tools").
Si vous en avez gardé, ils ont normalement été ajoutés dans cette section lors du Snapshot fait au début.

-- NVRAM --

Section Add (NVRAM --> Add)
Sous section 7C436110-AB2A-4BBB-A880-FE41995C9F82 (NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82)

boot-args —> -v keepsyms=1 (par défaut dans le sample)

Je laisse l’argument "-v" sur le config.plist de la clé USB.
Cela permet d’être en mode verbose.
Il sera retiré en post-installation (voir la partie "Fignolage" du retex dans le post 4)

prev-lang:kbd --> 66723A31 313131

La valeur spécifiée ici permet de définir le clavier en français numérique (plutôt que Russe par défaut)



-- PlatformInfo --

Dans cette section, on paramètre le SMBIOS.
Le SMBIOS, c'est un peu "la carte d'identité" du hackintosh.

C'est ici que l'on va indiquer à quel "vrai" Mac notre hackintosh se fera passer ainsi que les numéros de série.

Le choix du SMBIOS n'est pas à prendre à la légère. En effet, cela peut avoir un impact sur les performances.
L'idée étant de choisir un SMBIOS d'un Mac dont la configuration matérielle se rapproche le plus des composants de notre hackintosh.

Plus d'infos sur le choix d'un SMBIOS: voir ici dans le guide de Dortania

Pour ma part, le modèle de Mac dont les composants s'approchent le plus des composants de mon hackintosh est l'iMac de 2019.

Le numéro de modèle de l'iMac 2019 de 21,5 pouces est le: 19,2
Le numéro de modèle de l'iMac 2019 de 27 pouces est le: 19,1

Je choisis le modèle "iMac 19,1".
Donc mon hackintosh se fera passer pour un iMac (Retina 5K, 27 pouces 2019)

Je l'indique dans le paramètre suivant:

SystemProductName --> iMac19,1

Attention, si vous n’utilisez pas l’iMac 19,1 pour une raison ou une autre et que vous souhaitez utiliser mon injecteur USB personnalisé, vous devrez modifier dans le plist de l’injecteur USB le modèle pour qu’il soit en adéquation avec celui que vous aurez choisi ici (voir "Détails sur l'injecteur USB" du retex dans le post 5)

Ensuite, vous devrez personnaliser les paramètres suivants:

MLB
ROM
SystemSerialNumber
SystemUUID

Ils permettent d’avoir des numéros d'identification propre à chacun (numéros de série)

Pour ma part, j’ai repris les mêmes numéros de série que j’avais précédemment sous macOS Catalina avec Clover.

Si vous partez de 0, je vous recommande de lire cette partie du guide de Dortania ainsi que celle ci pour générer des numéros de série qui seront utilisable pour iMessage.

L’idée étant de générer des numéros de série à l’aide de l’outil GenSMBIOS

Exemple de numéros de série générés avec GenSMBIOS:

CODE

#######################################################
# iMac19,1 SMBIOS Info #
#######################################################

Type: iMac19,1
Serial: C02CF016JV3Q
Board Serial: C02011104QXLNV98C
SmUUID: 3BEFE58A-6D8D-4B40-A7AC-F3A3128BA242
Apple ROM: 54724FB0BC5E

Press [enter] to return...

Ensuite, il suffit de recopier les informations générées dans les paramètres que j’ai mentionné:

La valeur de "Serial" est à indiquer dans "SystemSerialNumber"
La valeur de "Board Serial" est à indiquer dans "MLB"
La valeur de "SmUUID" est à indiquer dans "SystemUUID"
La valeur de "Apple ROM" est à indiquer dans "ROM"

Voila ce que ça donne avec l’exemple:



-- UEFI --

Section APFS (UEFI --> APFS)

MinDate --> 0 (par défaut dans le sample)
MinVersion --> 0 (par défaut dans le sample)

Si vous installez comme moi macOS Big Sur ou suivant, vous pouvez laisser sur 0.
Si vous souhaitez démarrer sur macOS Catalina (ou avant jusque High Sierra) alors mettez ces paramètres sur  "-1".



Section Audio (UEFI --> Audio)

Cette section est pour qu’OpenCore puisse avoir accès au contrôleur audio et jouer le petit "gong" de démarrage comme sur un vrai Mac
Cette section ne sert qu'à régler l'audio que pour OpenCore et pas pour macOS.
En effet, nous avons déjà configuré l'audio pour macOS dans la section DeviceProperties.

Ça m’a amusé d'avoir le petit "gong" de démarrage alors je l’ai configuré mais si cela ne vous intéresse pas, laissez les options par défaut du sample.

Autrement:

AudioCodec —> 0 (par défaut dans le sample, si vos enceintes sont bien connectés à la sortie "line out" (prise verte) à l’arrière de la carte mère sinon il faudra que vous testiez de 0 à 5 quelle est la bonne sortie)
AudioDevice —> PciRoot(0x0)/Pci(0x1F,0x3)
AudioSupport —> True
MinimumVolume —> 70
VolumeAmplifier —> 143

Plus d’infos dans cette partie du guide de Dortania




Section Drivers (UEFI --> Drivers)

Dans cette section, on doit normalement retrouver les drivers que l’on a ajouté dans le dossier "EFI/OC/Drivers".
Ils ont été ajoutés automatiquement lors du Snapshot.



ATTENTION: à partir de la version 0.7.3 d'OpenCore (je rappel que ce retex est basé sur la version 0.7.2), les drivers ont maintenant des propriétés supplémentaires (voir la partie "Gérer les mises à jour d'OpenCore" du retex dans le post 5)

-----

Et voila, on a terminé de configurer le fichier config.plist (youhou !! )

Il reste une dernière étape, c’est de vérifier que notre config.plist est bien conforme et qu’il n’y a pas de paramètre qui serait oublié ou non valide.

Il y a un petit utilitaire dans le répertoire d’OpenCore qui s’appelle "ocvalidate" et qui va nous servir à vérifier que le config.plist est conforme.

"ocvalidate" se trouve dans le répertoire "Utilities/ocvalidate" du package OpenCore que l'on a téléchargé au tout début.

Lancer une fenêtre terminal et glisser/déposer le fichier "ocvalidate" dans la fenêtre du terminal.
Ensuite, glissez/déposez le fichier config.plist à la suite.

(Le glissez déposez permet d’avoir automatiquement le chemin des 2 fichiers de renseigner)

Exécuter la commande et vérifier qu’il n’y a pas d’erreur comme ci-dessous:

Code

Last login: Thu Aug 26 15:12:26 on ttys000
maxime@iMHack-de-Maxime ~ % /Users/maxime/Downloads/OpenCore-0.7.2-RELEASE/Utilities/ocvalidate/ocvalidate /Volumes/EFI/EFI/OC/config.plist

Completed validating /Volumes/EFI/EFI/OC/config.plist in 1 ms. No issues found.
maxime@iMHack-de-Maxime ~ %

La création de la clé USB d'installation est maintenant terminée

On va pouvoir passer aux réglages du BIOS.... dans le post suivant

Ce message a été modifié par MaxPoska - 27 Sep 2021, 22:58.

[MaxPoska]

• Paramétrage du BIOS

Version du BIOS utilisée: F14a modifié par le support de Gigabyte

Comme expliqué dans la partie "paramétrage du config.plist" dans le post précédent, de base, l'option pour désactiver le CFG-Lock n'est pas présente dans le BIOS de la Z370 HD3P.

Si vous souhaitez plus d'infos sur le CFG-Lock et comprendre son importance, je vous renvoi à cette partie du guide de Dortania ou encore ici

Ce qu'il faut retenir c'est que macOS a besoin d'avoir un accès en écriture à une zone de registre bien spécifique (MSR 0xE2) pour la gestion du CPU.
De base, beaucoup de BIOS de carte mère verrouillent ce registre en lecture seulement et ne permettent pas de déverrouiller ce registre (paramètre CFG-Lock non présent dans les options du BIOS).

Bien sûr, il existe des solutions pour contourner le problème (patcher macOS, patcher le BIOS) mais le mieux étant d'avoir l'option "CFG-Lock" directement dans le BIOS afin de débloquer l'accès en écriture (pour désactiver le CFG-Lock).

J'ai donc contacté le support de Gigagyte pour savoir s'il pouvait m'envoyer une version du BIOS modifiée de la version F14a de la Z370 HD3P qui ajoute l'option "CFG-Lock".

Et ils ont répondu favorablement à ma demande et m'ont donc envoyé ce BIOS qui contient cette option (merci au support de Gigabyte )

Je vous mets à disposition ce BIOS si vous souhaitez l'installer: https://www.dropbox.com/s/oya3e3hon8hptvx/Z...F-F14a.zip?dl=0

MD5 du fichier zip: fd4a0db2c82b92e5d6154f34a9d85e97
MD5 du fichier décompressé: 07936e4bc83534dca11be63d3cda0772

ATTENTION:
Ce BIOS est uniquement pour le modèle de carte mère Gigabyte Z370 HD3P.
Je ne pourrais être tenu responsable en cas de brick de votre carte mère lors du flashage avec ce BIOS.

Si vous ne souhaitez pas l'installer, il faudra alors que vous passiez le paramètre AppleXcpmCfgLock dans le config.plist (section Kernel --> Quirks) à "True" pour patcher macOS comme indiqué dans le post précédent.

Pour commencer, je règle le BIOS en français et je charge les réglages par défaut

"System " --> "System Language " --> "Français"
"Enregistrer et Quitter" --> "Charger les réglages par défaut optimisés"

- Activer XMP (permet de passer ma mémoire à 2666Mhz au lieu de 2133Mhz)
"MIT" --> "Réglages avancés de mémoire" --> "Extreme Memory Profil (X.M.P)" --> "Profil 1"

- Désactiver le démarrage rapide (désactivé par défaut normalement)
"BIOS" --> "Démarrage rapide" --> "Désactivation"
- Désactiver le CSM
"BIOS" --> "Support CSM" --> "Désactivation"
- Désactiver le Secure Boot
"BIOS" --> " Secure Boot" --> " Secure Boot" --> "Désactivation"

- Désactiver le CFG-Lock (uniquement disponible si vous avez installé le BIOS modifié dont je parlais au début)
"Périphériques" --> "CFG Lock" --> "Désactivation"
- Activer décodage au-dessus de 4G
"Périphériques" --> "décodage au-dessus de 4G" --> "Activation" 
- Régler la sortie d'affichage sur la carte graphique
"Périphériques" --> "Sortie d’affichage initiale" --> "Fente PCIe 1" (ou choisir "IGFX" si vous utilisez la carte graphique intégrée au processeur)
- Désactiver le Serial Port et le Parallel Port
"Périphériques" --> "Configuration Super ES" --> "Serial Port" --> "Désactivé"
"Périphériques" --> "Configuration Super ES" --> « Parallel Port"--> "Désactivé"
- Activer l'XHCI
"Périphériques" --> "Configuration USB" --> "XHCI direct" --> "Activé"

- Désactiver VT-D
"Puce" --> "VT-D" --> "Désactivation"
- Activer Puce graphique interne
"Puce" --> "Internal Graphics" --> "Activation"
"Puce" --> "DVMT Pre-Allocated" --> "64M"

(A noter que les réglages "DVMT Pre-Allocated" et "DVN Total Gfx Mem" seront visible une fois les réglages enregistrés et après un reboot)

- Pour finir, enregistrer la configuration puis quitter

Une fois le réglage du BIOS réalisé, on peut enfin installer macOS

• Installation de macOS

Aller, le plus dur est fait
Avant de commencer l'installation, personnellement, je préfère débrancher tous les disques durs/SSD et ne garder que le SSD Nvme qui va accueillir macOS de connecter.
Pour commencer l'installation de macOS, on insère la clé USB dans un port USB du hackintosh (de préférence, dans un port qui est mappé par l'injecteur hein ) et on oublie pas de régler la priorité de démarrage sur la clé afin de booter directement sur la clé USB



Vous devriez arriver sur le menu de démarrage d'OpenCore



Choisir alors "install macOS Big Sur" (ou "install macOS xxxx" où "xxxx" est la version de macOS que vous installez).

Pleins de lignes de textes vont alors défiler (c'est normal, on est en mode verbose ) et si tout se passe bien, vous devriez arriver sur le menu d'installation de macOS.
A partir de là, on utilise "l'utilitaire de disque" pour formater le disque sur lequel on souhaite installer macOS.

Je formate le SSD au format "APFS" et je le nomme "Macintosh HD".
Ensuite, on lance l'installation de macOS sur le disque fraichement formaté.

Il y aura plusieurs reboot durant l'installation.
Pour macOS Big Sur, si je me rappel bien, il y a eu 4 reboot:

1er reboot sur "macOS installer"
2ème reboot sur "macOS installer"
3ème reboot sur "Macintosh HD" (ou le nom que vous aurez donné au disque)
4ème reboot sur "Macintosh HD" (ou le nom que vous aurez donné au disque)

Vous n'avez rien à faire, OpenCore, bootera tout seul sur les bonnes partitions.

Au 4ème reboot, on doit arriver au menu de configuration de macOS (menu où l'on choisis son nom d'utilisateur, configure son mot de passe etc etc)

Une fois cette configuration terminée, on arrive enfin sur le bureau de macOS

Une fois l’installation de macOS terminée, il nous reste à copier le dossier "EFI" de la partition "EFI" de la clé USB vers la partition "EFI" du disque interne sur lequel macOS est installé afin de pouvoir démarrer sans la clé USB.

Pour ce faire, on réutilise l'utilitaire MountEFI pour monter les 2 partitions "EFI" et copier le dossier "EFI" de la clé USB vers la partition "EFI" du disque interne sur lequel on vient d'installer macOS.

A partir de là, on peut démarrer sur macOS sans la clé USB

(Si vous avez plusieurs disques bootable de connecter au PC, changez la priorité de boot pour avoir le disque où macOS est installé en 1er dans l'ordre de boot).

Tout devrait déjà être fonctionnel: L'ethernet, l'audio (penser à sélectionner "Haut-parleurs internes" dans les "Préférences système" --> "Son" de macOS), la partie graphique, les ports USB.. puisque l'on a déjà tout configurer dans notre config.plist

Reste les finitions comme la suppression du mode verbose, cacher certaines partitions dans le menu de boot d'OpenCore ou encore des réglages liés au multiboot avec Windows (voir partie "Fignolage" du retex dans le post 4)

• Installation de Windows

OpenCore sait très bien gérer le multiboot avec Windows.
Pour ma part, j’ai un disque dédié à Windows mais vous pouvez aussi installer Windows sur le même disque où vous avez installé macOS.

Il est préférable d’installer Windows en mode UEFI.

Vous pouvez utiliser ce tutoriel sur Macbidouille pour savoir comment faire.
Comme précisé, dans le tutoriel, j’ai utilisé l’utilitaire "Rufus" pour créer une clé USB bootable d’installation de Windows en mode UEFI

J'ai formaté aussi le SSD qui va accueillir Windows, à l'aide de "l'utilitaire de disque" de macOS afin que le disque soit en mode GUID/GPT:
- dans "Format" choisir "Mac OS étendu journalisé" (on reformatera en NTFS lors de l’installation de Windows)
- dans "Schéma" --> " Table de partition GUID"

Pour l’installation, je préfère débrancher le disque où macOS est installé pour ne pas que Windows vienne tout péter au cas où

Ensuite, rien de compliquer, il faut booter sur la clé USB, reformater la partition qui était en "HFS+" ("macOS étendu journalisée") en "NTFS" et procéder à l’installation de Windows tout à fait normalement.

Une fois Windows installé, on rebranche, le disque sur lequel macOS et OpenCore sont installés.

On vérifie dans le BIOS que c’est bien le disque où macOS et OpenCore sont installés qui est premier dans l’ordre de boot (et non pas le "Windows Boot Manager").

Windows doit alors apparaître dans le menu de boot d’OpenCore et on peut choisir de booter sur macOS ou Windows via OpenCore (voir partie "Fignolage" du retex dans le post 4 pour régler le boot par défaut)



Pour les pilotes de la carte Broadcom BCM94360CD (pour le Bluetooth et Wifi), on récupère les pilotes en téléchargeant Bootcamp 5 via ce lien directement sur le site d'Apple.

ATTENTION: on n'installe pas Bootcamp 5 (voir partie "Fignolage" du retex dans le post 4 pour voir l'installation de Bootcamp 6), ça nous sert juste à récupérer les pilotes qui vont bien.

Une fois le Zip téléchargé:
Le pilote pour le Bluetooth se trouve dans le répertoire "$WinPEDriver$/AppleBluetoothBroadcom64"
Exécuter le fichier "DPInst" pour installer le pilote Bluetooth.



Le pilote pour le wifi se trouve dans le répertoire "Bootcamp/Drivers/Broadcom"
Exécuter le fichier "BroadcomWirelessWin8x64" pour installer le pilote Wifi.



On va maintenant voir quelques finitions... dans le post suivant

Ce message a été modifié par MaxPoska - 28 Sep 2021, 20:01.

[MaxPoska]

• Fignolage (config.plist, réglage BIOS, Bootcamp)

Pour terminer, on va ajuster quelques paramètres pour finaliser notre installation

-- Config.plist --

- Dans la section "Misc"

Section Boot (Misc --> Boot)

HideAuxiliary --> True

Cela permet de cacher certaines entrées dans le menu de boot d'OpenCore comme la partition Recovery, le disque TimeMachine si vous avez un disque de sauvergarde TimeMacine de connecté, les entrées comme "Reset NVRAM" afin d'avoir un menu de boot plus propre.
Les éléments cachés restent accessible en tapant sur la barre d'espace dans le menu de boot.

Voilà ce que donne le avant/après l'activation de ce paramètre:



LauncherOption --> Full

Cela permet d’avoir l'option "OpenCore" directement dans les options de boot du BIOS (que l’on va sélectionner en premier dans l’ordre de boot).
J’ai pu remarquer que parfois, lorsque je démarrais sur Windows et après l’installation d'une une mise à jour, le choix de mon disque de démarrage était supprimé et lors du redémarrage, OpenCore bootais non plus par défaut sur macOS mais sur Windows.
Cette option règle le problème.

Vous trouverez plus d'informations ici dans le guide Dortania.

- Dans la section "NVRAM"

Section Add
Sous section 7C436110-AB2A-4BBB-A880-FE41995C9F82 (NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82)

boot-args --> keepsyms=1

Je supprime l’argument "-v" pour ne plus être en mode verbose (je laisse keepsyms=1 qui est utile pour les logs en cas de Kernel panic)

Pour résumer les changements:



-- Régler l'ordre de boot dans le BIOS --

Comme je le disais, une fois le paramètre "LauncherOption" réglé sur "Full", on a la possibilité de sélectionner "OpenCore" dans le menu du BIOS.
L'option n'apparaitra qu'après un reboot.



-- Bootcamp et utilisation Magic Keyboard et Magic Mouse 2 sous Windows --

L'installation d'une version de Bootcamp va nous permettre d'avoir accès aux choix du système à démarrer par défaut au démarrage (soit Windows soit macOS) directement depuis Windows.
On a vu plus haut que Bootcamp 5 nous permettait de récupérer les drivers de la la carte Broadcom BCM94360CD pour le Wifi/Bluetooth.
Cependant, nous n'avions pas installé Bootcamp 5 à ce moment là.
En effet, Bootcamp 5 est ancien et ne permet pas de voir les partitions en APFS (donc notre partition macOS).
De plus, Bootcamp 5 n'inclus pas les drivers pour la Magic Mouse 2.

Nous avons besoin d'avoir au moins Bootcamp 6.1.
Le problème, c'est qu'Apple ne propose pas de lien de téléchargement direct pour Bootcamp 6.1 comme elle le propose avec Bootcamp 5.

Nous allons donc utiliser l'utilitaire Brigadier

Cet utilitaire va nous permettre de télécharger directement Bootcamp 6.1 et les drivers pour un modèle de Mac spécifique.

Pour l'utiliser sous Windows:
Ouvrir une fenêtre "invite de commande" en mode Administrateur.
Se positionner dans le répertoire où se trouve brigadier et lancer tout simplement le fichier brigadier.bat

En imaginant que le fichier brigadier.bat se trouve dans le répertoire c:\brigadier-master

Code

c:\brigadier-master>brigadier.bat

OpenCore à "injecté" le numéro de modèle de notre hackintosh pour Windows également.
Donc si on lance juste le fichier brigadier.bat sans paramètre, brigadier va télécharger bootcamp pour le modèle iMac19,1 (celui que l'on a paramétré dans le config.plist, paramètre "SystemProductName").

Il reste possible de dire à brigadier de télécharger bootcamp pour un autre modèle de Mac.
On le précisera alors en paramètre:

Code

c:\brigadier-master>brigadier.bat --model iMac19,1

Brigadier est un utilitaire codé en python.
Si une fenêtre s'ouvre et demande d'installer Python 3, répondre oui (y)

Brigadier va alors télécharger Bootcamp depuis les serveurs d'Apple pour le modèle choisis.

Pour ma part, je laisse brigadier télécharger Bootcamp pour le modèle iMac19,1 qui ira très bien.

Bootcamp sera alors téléchargé et décompressé dans le même dossier où se trouve brigadier



Avant d'installer Bootcamp à proprement parler, je fais le ménage dans les drivers.
En effet, si on lance le "setup.exe" de bootcamp tout de suite, ça va aussi installer les différents drivers qui sont présents dans le répertoire et nous n'avons pas besoin de tous ces drivers.

Dans le dossier "$WinPEDriver$", je garde juste le driver de la Magic Mouse 2



Dans le dossier "Drivers" je supprime tous les dossiers à l'exception du dossier "Apple"
Dans ce dossier "Apple" je garde les éléments suivants:


Lancer alors le fichier "setup.exe" qui se trouve dans le répertoire "Bootcamp" pour démarrer l'installation de Bootcamp et des drivers que l'on a conservé.


Si on tombe sur l'erreur "Cette version de Boot Camp n'est pas destinée à ce modèle d'ordinateur" lors du lancement du fichier "setup.exe", on peut aussi lancer l’installation de Bootcamp en passant par le fichier "Bootcamp.msi" qui se trouve dans le dossier "Drivers\Apple".
Exécuter alors la commande suivante en mode administrateur pour lancer l'installation:

Code

c:\brigadier-master\Bootcamp-061-97204\Drivers\Apple>msiexec /i BootCamp.msi

Vérifier que l'on installe bien une version 6.1 de Bootcamp


Bootcamp va alors s'installer avec les drivers que l'on aura laissés

Plus d'infos sur l'installation de Bootcamp dans le guide de Dortania ici

Astuce pour la Magic Mouse 2:

Il se peut que la Magic Mouse 2 soit bien détecté mais que le scroll ne fonctionne pas.
Cela veut dire que le driver de la Magic Mouse 2 ne s'est pas bien installé.

Pour résoudre le problème, aller dans le "Gestionnaire de périphériques" de Windows.
Lorsque la souris est connecté, dans le menu "Périphériques d'interface utilisateur" est indiqué "Périphérique HID Bluetooth" au lieu de "Apple Wireless Mouse"


Pour installer le driver manuellement, faire un clic droit sur "Périphérique HID Bluetooth" et sélectionner "Mettre à jour les pilotes", sélectionner ensuite "Parcourir mon poste de travail pour rechercher des pilotes" et sélectionner le répertoire "AppleWirelessMouse" présent dans le répertoire "$WinPEDriver$" dans le dossier Bootcamp que l'on a téléchargé avec brigadier.



Le driver doit alors s'installer et "Périphérique HID Bluetooth" devient "Apple Wireless Mouse" et le scroll doit fonctionner


Astuce pour le Magic Keyboard:

Lorsque j'avais fait mon installation de Windows sur mon hackintosh j'avais un problème sur le layout du Magic Keyboard. Les touches @ et < étaient inversés.
J'avais alors modifié le layout du clavier français Apple pour ré-inverser ces 2 touches (je crois me souvenir avoir utilisé un outil de Microsoft pour faire ça: Microsoft Keyboard Layout Creator)

Je vous mets le lien en téléchargement, pour ce clavier, de ce mapping du Magic Keyboard: https://www.dropbox.com/s/sku5g1u74t8ew4f/L...yboard.zip?dl=0
Lancer le fichier "setup.exe" pour installer le clavier.
Ensuite, dans les paramètres de Windows, choisir le clavier "Français (France) - Français (Apple) - Custom"


-- Multiboot: choisir le système à démarrer au démarrage --

Pour choisir le système sur lequel on veut démarrer par défaut, OpenCore va, comme sur un vrai Mac, prendre en compte de disque de démarrage qui est paramétré dans les préférences système



Et comme on a installé Bootcamp, on peut aussi faire ce choix depuis Windows dans le panneau de configuration de Boot Camp



Ce message a été modifié par MaxPoska - 28 Sep 2021, 20:03.

[MaxPoska]

• Détails sur l'injecteur USB

Depuis macOS El Capitan, macOS ne sait gérer que 15 ports USB par contrôleur.
On pourrait se dire que cette limitation est large mais en réalité, on peut atteindre cette limite assez rapidement.
En effet, par exemple, un port USB3 physique présent sur la carte mère va en réalité être comptabilisé comme 2 ports USB "logique": 1 comme port USB3 et 1 comme port USB2
Sur la carte mère Z370 HD3P, il y a un total de 15 ports USB physiques répartis sur 2 contrôleurs: 1 contrôleur géré par le chipset et 1 contrôleur supplémentaire géré par la puce ASMedia 3142 (qui est reconnu nativement sous macOS)

Code

Chipset+ASMedia® USB 3.1 Gen 2 Controller:

    1 x USB Type-C™ port on the back panel, with USB 3.1 Gen 2 support
    1 x USB 3.1 Gen 2 Type-A port (red) on the back panel

Chipset:

    1 x USB Type-C™ port with USB 3.1 Gen 1 support, available through the internal USB header
    6 x USB 3.1 Gen 1 ports (4 ports on the back panel, 2 ports available through the internal USB header)
    6 x USB 2.0/1.1 ports (2 ports on the back panel, 4 ports available through the internal USB headers)

En partant du principe qu'un port USB3 compte pour 2 ports, cela donne en réalité 24 ports USB logique utilisable.

Si on ne fait rien, certains ports USB seront désactivés de manière aléatoire par macOS à chaque démarrage pour rester dans la limite de 15 et ils ne seront pas forcément reconnu pour fonctionner à la bonne vitesse.
Par exemple, on démarre son hackintosh un jour J, ce seront les ports USB en façade du boitier qui seront désactivés par macOS et si on redémarre son hack à J+1, ça sera des ports USB à l'arrière de la carte mère qui ne fonctionneront pas, etc etc.

Pour éviter cela, le but de la création d'un injecteur USB est de se créer un kext personnalisé avec les ports USB que l'on souhaite activer tout en restant dans la limite des 15 ports USB par contrôleur.

-- Inventaire --

La première étape consiste donc à faire un inventaire de tous les ports USB de notre carte mère.

Pour faire cela, j'ai:
- Passé provisoirement à "True" le paramètre "XhciPortLimit" présent dans le config.plist dans la section "Kernel --> Quirks" afin de faire sauter temporairement la limite des 15 ports USB
- Utilisé le kext USBInjectAll pour injecter tous les ports USB
- Utilisé l'utilitaire IORegistry pour découvrir l'adresse des contrôleurs et des ports USB

Alors pourquoi s'embêter à faire cet inventaire et rester dans la limite de 15 ports si il y a un paramètre et un kext qui nous permettent d'outrepasser cette limite et de les utiliser tous ?
Parce que l'utilisation de ces solutions de contournement n'est pas fiable sur le long terme et présente un risque de corruption des données notamment.

Ensuite, le but du jeu est de connecter une clé USB dans chaque connecteur et de vérifier le nom et l'adresse du port avec IORegistry.
On connecte une clé USB2 dans un connecteur USB2, une clé USB3 dans un connecteur USB3, une clé USB2 dans un connecteur USB3 etc etc pour faire l'inventaire complet.

Par exemple:

Quand je connecte une clé USB3 dans le port USB3 le plus à droite en façade du boitier, je repère ensuite dans IORegistry sur quel port la clé a été associé (la clé USB apparait en vert)



Ici, la clé USB a été montée sur le port "SS05" à l'adresse "15000000".
J'en conclus donc que le port USB3 du connecteur UBS3 à droite du boitier en façade est le port "SS05" à l'adresse "15000000".

Et on fait ça pour tous les ports

Si vous souhaitez avoir plus d'informations sur l'intérêt de faire ce référencement et comment le faire, vous pouvez lire cette partie du guide de Dortania

Voici ce qu'a donné mon inventaire pour la Z370 HD3P:

Je n'ai pas référencé 3 ports:
- Le second port USB2 qui est disponible sur le port interne F_USB2 puisque je n'ai qu'une seule chose qui est connecté sur ce connecteur c'est la carte Broadcom qui est utilisée pour le Bluetooth
- Les 2 ports (USB2 et USB3) du connecteur USB-C interne (F_USB30C) car je n'ai pas de port USB-C sur mon boitier en façade pour pouvoir utiliser ce connecteur.

Si on calcule tous les ports référencés (21) + les 3 ports non référencés, on arrive bien à un total de 24.

Concernant les ports USB que je conserve.
- Pour le contrôleur ASMedia: il n'y a que 4 ports USB liés à ce contrôleur sur 15 possibles. Donc je conserve les 4.
- Pour le contrôleur du chipset: il y en a 20. Donc je dois en éliminer 5 pour rester dans la limite de 15. Je sacrifie les 3 ports que je n'ai pas référencés ainsi que les 2 ports liés au connecteur USB3 à côté du port Ethernet.

-- Le Kext injecteur --

Une fois que l'on a fait l'inventaire des ports USB que l'on souhaite conserver et utiliser, il faut maintenant les référencer dans un kext (mon kext déjà fait peut être téléchargé en haut du topic dans "les liens utiles" ou si vous suivez le guide de Dortania, vous téléchargerez un sample).
Ce kext va permettre de dire à macOS: "Voilà, ce sont les ports USB qui sont utilisés sur cette machine"

Pour accéder au fichier de configuration du kext, on fait un clique droit sur le kext et on sélectionne "Afficher le contenu du paquet".
Le fichier de configuration se nomme "info.plist" et se trouve dans le répertoire "Contents".

Pour commencer, on paramètre les contrôleurs:


Dans la rubrique "IOKitPersonalities"

- iMac19,1-ASMedia --> représente le contrôleur ASMedia
- IOPathMatch --> définit le chemin du contrôleur ("IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/PXSX@0/PXSX@00000000" pour le contrôleur ASMedia et "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC@14/XHC@14000000" pour le contrôleur du chipset). Ce chemin a été repéré grâce à IOService (comme les ports).
- model --> iMac19,1 qui correspond au SMBIOS qui a été choisi pour ce hackintosh. Il doit être le même que ce qui est paramétré dans le "config.plist" dans la section "PlatformInfo --> SystemProductName". Sinon, les infos du kext ne seront pas prises en compte.

Ensuite, on paramètre les ports:

- Contrôleur ASMedia (iMac19,1-ASMedia)



- Contrôleur chipset (iMac19,1-XHC)




- port-count --> Indique le port qui a l'adresse la plus grande que l'on injecte pour notre contrôleur

Dans la description de chaque port (balise ports):

- HA03, SA01, HS03, SS03 etc etc --> représente le nom du port. HS pour HighSpeed pour les ports USB2 et SS pour SuperSpeed pour les ports USB3.
Pour le contrôleur ASMedia, IORegistry me référence les ports sous le nom "AppleUSB30XHCIPort" et "AppleUSB20XHCIPort"
Or, dans le kext, il faut que le nom soit sur 4 caractères. Donc, pour rester dans la philosophie de nom des ports du chipset, j'ai choisi de nommer les ports USB du contrôleur ASMedia de la manière suivante: HA pour HighSpeedAsmedia pour les ports USB2 et SA pour SuperSpeedAsmedia pour les ports USB3

- UsbConnector --> indique le type de connecteur USB. "3" pour un connecteur USB3, "0" pour un connecteur USB2, "9" pour un connecteur USB-C, "255" pour un connecteur interne (pour le Bluetooth)
- port --> indique l'adresse du port que l'on a trouvé grâce au référencement
- Comment --> Commentaire libre: j'indique ici de quel port il s'agit sur quel connecteur pour m'y retrouver

Voilà, la déclaration des ports USB est maintenant complète

A la fin, on oublie pas de retirer USBInjectAll.kext pour le remplacer par notre kext personnalisé (et de le déclarer et l'activer dans le config.plist sinon il ne sera pas pris en compte) et de passer le paramètre "XhciPortLimit" à "False" afin de revenir sur la limite des 15 ports USB.

A la fin, on peut vérifier dans IOService que tous les ports USB que l'on a gardé sont bien chargés par le kext:

• Gérer les mises à jour d'OpenCore

OpenCore est un bootloader stable, certes, mais encore relativement jeune et, à ce titre, il est très régulièrement mis à jour.
En effet, à la période où j’écris ces lignes, il y a une mise à jour d’OpenCore qui sort mensuellement. Tous les premiers lundi de chaque mois pour être précis.

Cependant, sachez que vous n’êtes pas obligé de faire toutes les mises à jour d’OpenCore. J’aurai même tendance à dire que tant que sa configuration fonctionne, ne pas faire les mises à jour.

En fait, vous devez un minimum vous renseigner pour savoir ce qu’apporte la nouvelle mise à jour d’OpenCore pour savoir s'il y a des choses qui peuvent être intéressante et qui valent le coût pour vous de mettre à jour OpenCore.

Pour voir ce qu’apporte un mise à jour vous pouvez:

- Lire le post de blog des développeurs ici
- Consulter le changelog d’OpenCore lors du téléchargement du package
- Consulter le document "Différences.pdf" présent dans le répertoire "Docs" lorsque l’on télécharge OpenCore. Ce document met en avant les différences avec la précédente version d’OpenCore.
- Faire une recherche Google (ou autres moteur de recherche)

Le principe d'une mise à jour d’OpenCore consiste à remplacer les fichiers les plus importants qui sont dans notre partition "EFI" par les fichiers de la nouvelle version, notamment, les fichiers suivants:

- "BOOTx64.efi" qui se trouve dans la partition "EFI" dans le répertoire "EFI/BOOT"
- "OpenCore.efi" qui se trouve dans la partition "EFI" dans le répertoire "EFI/OC"
- Les drivers qui se trouvent dans la partition "EFI" dans le répertoire "EFI/OC/Drivers"

Personnellement, j’en profite aussi pour mettre à jour les Kexts lorsque je fais une mise à jour d’OpenCore.

Ça, c’était la partie facile.

Le plus lourd maintenant est qu’il faut aussi mettre à jour parfois le fichier de configuration d’OpenCore: le config.plist.

En effet, les développeurs ajoutent parfois des paramètres dans certaines sections ou, au contraire, en retirent.

Il faut donc comparer notre fichier config.plist avec le nouveau sample.plist présent dans la nouvelle version d’OpenCore pour voir les différences et faire les ajustements dans notre config.plist.

Le retex est basé sur la version 0.7.2. Entre temps est sortie la version 0.7.3.

Je vais donc faire la mise à jour d’OpenCore 0.7.2 vers la 0.7.3 pour illustrer comment je procède.
(Je ne prétends pas dire que c'est "LA" méthode, et qu'il faut faire comme ça, je présente juste "MON" rituel de mise à jour basé sur les conseils du guide de Dortania ici)

-- Cas pratique: mise à jour d'OpenCore 0.7.2 vers 0.7.3 --

Avant de commencer, je conseil d’avoir une sauvegarde du dossier "EFI" ainsi qu'une clé USB avec un dossier "EFI" OpenCore fonctionnel (comme celui de la clé USB d’installation) afin de s’en servir pour démarrer au cas où quelque chose se passe mal.

Pour commencer, je regarde le changelog de la version 0.7.3.



On y voit des choses intéressantes comme une amélioration des performances d’OpenCanopy (pour la gestion de l’interface d’OpenCore) ou encore l’ajout d’un driver pour Linux.
Mais les 2 points sur lesquelles il faut faire attention c’est l’ajout d’arguments pour les drivers et un nouveau paramètre dans la section UEFI.

Je vais donc devoir modifier le config.plist.

Pour commencer, il faut monter la partition "EFI" à l’aide de MountEFI pour avoir accès aux fichiers.

Ensuite, je télécharge la nouvelle version d’OpenCore.

Avant de modifier le config.plist, je commence par mettre à jour les fichiers dans la partition "EFI"

Je remplace les fichiers "BOOTx64.efi", "OpenCore.efi" et les drivers qui sont dans le dossier "EFI" par ceux du package d’OpenCore que l’on vient de télécharger et qui sont dans le répertoire "x64/EFI"
Pour le driver "HfsPlus.efi", on peut aller voir dans OCBinary Data ici s'il y a une nouvelle version du driver (mais il n'est pas souvent mis à jour) et ce n'est pas le cas ici.
Je mets aussi à jour les Kexts que j’utilise s'il y a des mises à jour (ce n’est pas une obligation mais généralement j'en profite pour le faire).

Ensuite, pour la modification du config.plist, je vais utiliser un outil qui ma permettre de comparer le fichier config.plist que j’utilise avec le sample du nouveau package d’OpenCore: OCConfigCompare
En effet, même si là, on pourrait s’en passer car on a repéré grâce au changelog quelles étaient les modifications à apporter, si on saute plusieurs versions d’OpenCore, cet utilitaire devient vite très utile

Lancer OCConfigCompare (clique droit sur "OCConfigCompare.command" puis "Ouvrir" pour le premier lancement)

La première étape consiste à sélectionner les 2 fichiers de configuration à comparer (notre fichier config.plist local et le nouveau sample)

Choisir l’option "3" pour sélectionner le fichier sample et glisser/déposer dans la fenêtre le fichier sample présent dans le répertoire "Docs" du package d’OpenCore que l’on a téléchargé



Ensuite, choisir l’option "4" pour sélectionner notre fichier config.plist local et glisser/déposer dans la fenêtre le fichier config.plist qui se trouve dans notre partition "EFI" dans le dossier "EFI/OC"



Enfin, sélectionner l'option "7" pour lancer la comparaison entre les 2 fichiers



La comparaison présente un tableau à 2 résultats:

CODE

#######################################################
# OC Config Compare #
#######################################################

Checking for values missing from User plist:

config.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1b,0x0)
config.plist -> Misc -> BlessOverride -> From|To-Array - Empty: Skipped
config.plist -> Misc -> Tools -> To-Array - Empty: Skipped
config.plist -> NVRAM -> Delete -> 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> Delete -> 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> Delete -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> LegacySchema -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> LegacySchema -> 8BE4DF61-93CA-11D2-AA0D-00E098032B8C -> From-Array - Non-Dictionary Children: Skipped
config.plist -> UEFI -> Drivers -> Array[0] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[1] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[2] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[3] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[4] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Quirks - Missing Key: ForceOcWriteFlash

Checking for values missing from Sample:

Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1F,0x3)
Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x2,0x0)
Sample.plist -> Misc -> BlessOverride -> From|To-Array - Empty: Skipped
Sample.plist -> Misc -> Tools -> From-Array - Empty: Skipped
Sample.plist -> NVRAM -> Delete -> 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> Delete -> 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> Delete -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> LegacySchema -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> LegacySchema -> 8BE4DF61-93CA-11D2-AA0D-00E098032B8C -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> UEFI -> Drivers -> From-Array - Non-Dictionary Children: Skipped

Press [enter] to return...

La première partie montre les paramètres qui sont présents dans le sample mais absents de notre fichier config.plist.
Autrement dit, ce sont les éléments ajoutés.

La deuxième partie, c’est l’inverse, ce sont les paramètres présents dans notre config.plist mais absents du sample.
Autrement dit, ce sont les éléments retirés.

Tous les résultats ne sont pas forcément pertinents:

- Tout ce qui est noté "Skipped" peut être ignoré

Il reste donc:

CODE

#######################################################
# OC Config Compare #
#######################################################

Checking for values missing from User plist:

config.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1b,0x0)
config.plist -> UEFI -> Drivers -> Array[0] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[1] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[2] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[3] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[4] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Quirks - Missing Key: ForceOcWriteFlash

Checking for values missing from Sample:

Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1F,0x3)
Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x2,0x0)

Press [enter] to return...

- Ensuite, les lignes liées aux clés manquantes dans la section "DeviceProperties" peuvent être ignorées puisque c'est normal

Pour le signalement "PciRoot(0x0)/Pci(0x1b,0x0)" absent de notre config.plist c'est normal puisque cette ligne concerne l'audio dans le sample et nous l'avons remplacée par la vrai adresse du contrôleur audio ("PciRoot(0x0)/Pci(0x1F,0x3)") sur la Z370 HD3P (voir paramétrage du config.plist du retex dans le post 2)
Du coup, c'est normal aussi qu'OCConfigCompare nous remonte l'absence de la ligne "PciRoot(0x0)/Pci(0x1F,0x3)" dans le sample.

Enfin, pour le signalement "PciRoot(0x0)/Pci(0x2,0x0)" absent du sample et présent dans le config.plist, c'est normal aussi puisque nous avons ajouté cette ligne lors du paramétrage du config.plist pour régler le processeur graphique interne au processeur (voir paramétrage du config.plist du retex dans le post 2).

Donc, au final, il n'y a que ceci d'intéressant et à prendre en compte:

CODE

#######################################################
# OC Config Compare #
#######################################################

Checking for values missing from User plist:

config.plist -> UEFI -> Drivers -> Array[0] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[1] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[2] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[3] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Drivers -> Array[4] - Type Difference: String --> Dictionary
config.plist -> UEFI -> Quirks - Missing Key: ForceOcWriteFlash

Press [enter] to return...

On retrouve bien les sections dont parlait le changelog portant sur les drivers et l'ajout d'un paramètre dans la section "UEFI --> Quirks".

Ensuite, il faut recopier les paramètres manquants du sample vers le fichier config.plist.
Pour cela, on ouvre côte à côte le fichier sample et notre config.plist dans ProperTree pour bien identifier les changements remontés par OCConfigCompare et pour les reporter dans notre config.plist



A gauche, le sample de la version 0.7.3
A droite, le config.plist de notre partition "EFI" basé sur la version 0.7.2

Comme indiqué par OCConfigCompare, on remarque bien que la section "Drivers" a bien changée.
Les élément du tableau "Drivers" sont maintenant de type "Dictionnary" au lieu de "String" et l'on remarque que l'on a maintenant 3 propriétés par driver: "Path", "Enabled", "Arguments"

La documentation d'OpenCore nous apprend ceci sur ces nouvelles propriétés:

CODE

11.11 Drivers Properties
1. Path
Type: plist string
Failsafe: Empty
Description: Path of file to be loaded as a UEFI driver from OC/Drivers directory.
2. Enabled
Type: plist boolean
Failsafe: false
Description: If false this driver entry will be ignored.
3. Arguments
Type: plist string
Failsafe: Empty
Description: Some OC plugins accept optional additional arguments which may be specified as a string here.

Donc je reprends cette structure dans le config.plist et je passe le paramètre "Enabled" à "True" pour chacun des drivers que j'utilise pour qu'ils soient pris en compte.

Pour l'ajout du paramètre "ForceOcWriteFlash" dans la section "UEFI --> Quirks", voici ce que dit la documentation d'OpenCore sur ce nouveau paramètre:

CODE

5. ForceOcWriteFlash
Type: plist boolean
Failsafe: false
Description: Enables writing to flash memory for all OpenCore system variables.
Note: This value should be disabled on most types of firmware but is left configurable to account for firmware
that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be
observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot
and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt
for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing
issues. When toggling this option, a NVRAM reset may be required to ensure full functionality

Lorsqu'un nouveau paramètre est ajouté comme celui ci, généralement, je regarde ce qui est recomandé par le guide de Dortania à son sujet.

Malheureusement, pour le cas qui nous inéresse, le guide de Dortania est resté sur la version 0.7.2 (la version d'OpenCore supportée par le guide est inscrit directement en page d'acceuil du guide) donc je me fie uniquement à la documentation.
A la lecture de la doc, je vais laisser ce paramètre avec sa valeur par défaut (c'est à dire sur "False" pour ne pas l'activer)

Voici ce que ça donne une fois les changements apportés à notre config.plist



Evidemment, on oublie pas de sauvegarder

Une fois les modifications terminées, je relance une comparaison pour vérifier que rien n'a été oublié.

La nouvelle comparaison donne ceci:

CODE

#######################################################
# OC Config Compare #
#######################################################

Checking for values missing from User plist:

config.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1b,0x0)
config.plist -> Misc -> BlessOverride -> From|To-Array - Empty: Skipped
config.plist -> Misc -> Tools -> To-Array - Empty: Skipped
config.plist -> NVRAM -> Delete -> 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> Delete -> 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> Delete -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> LegacySchema -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
config.plist -> NVRAM -> LegacySchema -> 8BE4DF61-93CA-11D2-AA0D-00E098032B8C -> From-Array - Non-Dictionary Children: Skipped

Checking for values missing from Sample:

Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x1F,0x3)
Sample.plist -> DeviceProperties -> Add - Missing Key: PciRoot(0x0)/Pci(0x2,0x0)
Sample.plist -> Misc -> BlessOverride -> From|To-Array - Empty: Skipped
Sample.plist -> Misc -> Tools -> From-Array - Empty: Skipped
Sample.plist -> NVRAM -> Delete -> 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> Delete -> 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> Delete -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> LegacySchema -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> From-Array - Non-Dictionary Children: Skipped
Sample.plist -> NVRAM -> LegacySchema -> 8BE4DF61-93CA-11D2-AA0D-00E098032B8C -> From-Array - Non-Dictionary Children: Skipped

Press [enter] to return...

C'est parfait, il ne reste que les élements qui peuvent être ignorés.

Enfin, pour terminer, je revalide mon config.plist avec l'utilitaire "OCvalidate" présent dans le répertoire "utilities" de la nouvelle version d'OpenCore que l'on a téléchargé.

Code

maxime@iMHackdeMaxime ~ % /Users/maxime/Downloads/OpenCore-0.7.3-RELEASE/Utilities/ocvalidate/ocvalidate  /Volumes/EFI/EFI/OC/config.plist

Completed validating /Volumes/EFI/EFI/OC/config.plist in 1 ms. No issues found.
maxime@iMHackdeMaxime ~ %

Si il n'y a pas d'erreur alors on peut redémarrer pour vérifier que tout va bien

Personnelement, au redémarrage, j’aime bien faire un reset NVRAM (taper sur la barre espace sur le menu d'OpenCore et sélectionner "Reset NVRAM") pour m'assurer de repartir propre (attention, il faudra alors reselectionner le disque de démarrage à utiliser par défaut dans les préférences système si comme moi vous êtes en multiboot).

Enfin, pour vérifier la version d'OpenCore qui est utilisée, vous avez l'information dans le menu de boot d'OpenCore en bas à droite au démarrage ou alors on peut taper la commande suivante dans le terminal

Code

nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version

R.A.S pour moi, passage sur OpenCore 0.7.3 avec succès

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-073-2021-09-06
maxime@iMHackdeMaxime ~ %

---------------------------
FIN

Si vous avez tout lu, bravo
En espérant que ça puisse aider
--------------------------

Ce message a été modifié par MaxPoska - 30 Sep 2021, 13:33.

[arrakis28]

Magnifique travail d'explications dans la langue de Molière d'une configuration sous OpenCore.
Cela mériterait une rubrique spéciale.

Parce que quand j'ai commencé mon hack, je n'ai rien trouvé d'aussi détaillé en français pour OpenCore.

Ce message a été modifié par arrakis28 - 10 Sep 2021, 20:29.

[Duke]

Beau travail vraiment, je vais m'en servir pour ma prochaine tentative avec OpenCore !

[polyzargone]

Cela mériterait une rubrique spéciale.

Sans aller jusque là, son retex a été mis en avant ici : Support d'OpenCore

@MaxPoska

Excellent travail, merci à toi !

[MaxPoska]

Merci pour vos retours

Ravi si ça peut aider

(Bon maintenant j'ai la pression, faut que je termine de l'écrire )

[odemolay]

bravo c'est parfait

[MaxPoska]

Update au 28/09/2021:

Installation de la mise à jour macOS Big Sur 11.6 (20G165).



OpenCore en version 0.7.3
AppleALC.kext en version 1.6.4
IntelMausi.kext en version 1.0.7
Lilu.kext en version 1.5.6
NVMeFix.kext en version 1.0.9
VirtualSMC.kext (et plugins) en version 1.2.7
WhateverGreen.kext en version 1.5.3

R.A.S

Ce message a été modifié par MaxPoska - 28 Sep 2021, 20:37.

[MaxPoska]

Update au 12/10/2021:

Mise à jour d'OpenCore en version 0.7.4

- Update des fichiers:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:



Ajout d'une propriété "Comment" dans la section UEFI --> Drivers pour chaque driver



- Update des kexts :

AppleALC.kext en version 1.6.5
WhateverGreen.kext en version 1.5.4

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-074-2021-10-04
maxime@iMHackdeMaxime ~ %

R.A.S

[MaxPoska]

Update au 29/10/2021:

Installation de la mise à jour macOS Big Sur 11.6.1 (20G224).



OpenCore en version 0.7.4
AppleALC.kext en version 1.6.5
IntelMausi.kext en version 1.0.7
Lilu.kext en version 1.5.6
NVMeFix.kext en version 1.0.9
VirtualSMC.kext (et plugins) en version 1.2.7
WhateverGreen.kext en version 1.5.4

R.A.S

Pour l'instant, je ne prévois pas d'installer macOS Monterey (comme d'hab j'attends quelques mois avant d'installer une version majeur).
Par contre, je vais probablement l'installer sur un disque dur de test

[MaxPoska]

Update au 11/11/2021:

Mise à jour d'OpenCore en version 0.7.5

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi et HfsPlus.efi (récupéré depuis OCBinaryData pour ce dernier)

- Modification du config.plist:




Ajout du paramètre "ResizeAppleGpuBars" dans la section "Booter" --> "Quirks"
Ajout du paramètre "ResizeGpuBars" dans la section "UEFI" --> "Quirks"

Je laisse la valeur de ces 2 paramètres sur "-1" dans mon config.plist comme dans le sample pour désactiver ces 2 nouveaux paramètres (processeur et carte graphique non compatible de toute façon avec le Resize Bar)

- Update des Kexts

AppleALC.kext en version 1.6.6
Lilu.kext en version 1.5.7
WhateverGreen.kext en version 1.5.5

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-075-2021-11-02
maxime@iMHackdeMaxime ~ %

R.A.S

[tinkar]

Bravo pour ce retour d'expérience extrêmement bien détaillé ! Cela donne envie d'essayer.

[MaxPoska]

Bravo pour ce retour d'expérience extrêmement bien détaillé ! Cela donne envie d'essayer.

Merci

Update au 29/12/2021:

Installation de la mise à jour macOS Big Sur 11.6.2 (20G314).



Mise à jour d'OpenCore en version 0.7.6

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout des paramètres "ReconnectGraphicsOnConnect" et "UIScale" dans la section "UEFI" --> "Output"
Ajout du paramètre "EnableVmx" dans la section "UEFI" --> "Quirks"

Je laisse les valeurs par défaut qui sont dans le sample dans mon propre config.plist pour ces nouveaux paramètres.



Paramètres à supprimer:

Du fait de l'ajout du paramètre "UIScale" dans la section "UEFI" --> "Output", les paramètres suivants sont à supprimer du config.plist:

Suppression du paramètre "UIScale" dans la section "NVRAM" --> "Add" --> "4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14"
Suppression du paramètre "0" avec la valeur "UIScale" dans la section "NVRAM" --> "Delete" --> "4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-076-2021-12-06
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.7
Lilu.kext en version 1.5.8
VirtualSMC.kext (et plugins) en version 1.2.8

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 29 Dec 2021, 18:26.

[MaxPoska]

Update au 30/01/2022:

Installation de la mise à jour macOS Big Sur 11.6.3 (20G415).



Mise à jour d'OpenCore en version 0.7.7

Pour cette version, et pour ce qui nous intéresse ici, il y a beaucoup de changement concernant la gestion de l'audio dans le menu de boot d'OpenCore (attention, je parle bien de l'audio dans le boot géré grâce au driver "AudioDxe.efi" et qui sert à avoir, par exemple, le petit "gong" au démarrage. Rien à voir donc avec l'audio au niveau du système macOS (qui lui est géré par le Kext "AppleALC.kext")).

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "SystemAudioVolumeDB" dans la section "NVRAM" --> "Add" --> "7C436110-AB2A-4BBB-A880-FE41995C9F82"
Ajout des paramètres "PointerPollMask", "PointerPollMax", "PointerPollMin" dans la section "UEFI" --> "AppleInput"
Ajout des paramètres "AudioOutMask", "DisconnectHda", "MaximumGain", "MinimumAssistGain", "MinimumAudibleGain" dans la section "UEFI" --> "Audio"

Je laisse les valeurs par défaut qui sont dans le sample dans mon propre config.plist pour ces nouveaux paramètres.

Le paramètre "AudioOutMask" vient remplacer le paramètre "AudioOut" pour définir la sortie audio.
On avait "0" sur "AudioOut" que l'on remplace par "1" pour le paramètre "AudioOutMask".
J'ai bien toujours le "gong" au démarrage.

Paramètres à supprimer:

Suppression des paramètres "AudioOut" (qui est donc remplacé par "AudioOutMask"), "MinimumVolume", "VolumeAmplifier" (dont les fonctions sont remplacés par les différents paramètres que l'on a ajoutés) dans la section "UEFI" --> "Audio"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-077-2022-01-10
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.8
Lilu.kext en version 1.5.9
WhateverGreen en version 1.5.6

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 31 Jan 2022, 19:51.

[MaxPoska]

Update au 12/02/2022:

Mise à jour d'OpenCore en version 0.7.8

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètre à supprimer:

Suppression du paramètre "SystemAudioVolumeDB" dans la section "NVRAM" --> "Add" --> "7C436110-AB2A-4BBB-A880-FE41995C9F82"

(Paramètre qui avait été ajouté dans la 0.7.7)

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-078-2022-02-07
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.6.9
Lilu.kext en version 1.6.0
WhateverGreen en version 1.5.7

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 12 Feb 2022, 23:46.

[MaxPoska]

Update au 20/02/2022:

Il y a quelques jours, j'ai fait l'installation de la mise à jour de macOS Big Sur 11.6.4 (20G417).



R.A.S

Sur mon disque dur de test, j'ai installé macOS Monterey.
Je l'ai lancé en mode "mise à jour" depuis macOS Big Sur comme sur un vrai Mac.

Aucun problème lors de de cette mise à jour avec OpenCore 0.7.8

(Pour l'instant, je reste encore avec macOS Big Sur sur mon disque principal)

Ce message a été modifié par MaxPoska - 20 Feb 2022, 22:09.

[MaxPoska]

Update au 13/03/2022:

Mise à jour d'OpenCore en version 0.7.9

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "Strategy" dans la section "Kernel" --> "Block"
Ajout du paramètre "LogModules" dans la section "Misc" --> "Debug"

Je reprends les valeurs par défaut du sample dans mon propre config.plist pour ces 2 paramètres.

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-079-2022-03-07
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.0
WhateverGreen en version 1.5.8
VirtualSMC.kext (et plugins) en version 1.2.9

R.A.S suite à ces updates

[MaxPoska]

Update au 27/03/2022:

Il y a quelques jours, j'ai fait l'installation de la mise à jour de macOS Big Sur 11.6.5 (20G527).



R.A.S

[MaxPoska]

Update au 23/04/2022:

Mise à jour d'OpenCore en version 0.8.0

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi

- Modification du config.plist:

Paramètres à ajouter:

Ajout du paramètre "CustomPciSerialDevice" dans la section "Kernel" --> "Quirks"
Ajout du paramètre "ForceAquantiaEthernet" dans la section "Kernel" --> "Quirks"

Ajout du paramètre "Serial" en tant que "paramètre chapeau" (dictionnaire) dans la section "Misc"
Ajout du paramètre "Init" dans la section "Misc" --> "Serial"
Ajout du paramètre "Override" dans la section "Misc" --> "Serial"

Pour l’ensemble de ces nouveaux paramètres, je reprends les valeurs par défaut du sample dans mon propre config.plist.

Paramètre à supprimer:

Suppression du paramètre "SerialInit" dans la section "Misc" --> "Debug"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-080-2022-04-18
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.1

R.A.S suite à ces updates

-------

A noter que depuis 3 mois, il y a une nouvelle version de l'outil OCConfigCompare qui dispose d'une nouveauté fort appréciable.
Pour rappel, cet outil permet de faire la comparaison entre son config.plist et le sample.plist d'une nouvelle version d'OpenCore afin d'en détecter les différences et faire l'ajout/suppression de paramètres plus facilement lors des mises à jour d'OpenCore.

Cette nouvelle version améliore la visibilité des résultats de la comparaison en ne prenant pas en compte certaines sections du config.plist qui sont non pertinentes dans le paramétrage par défaut de l'outil (grâce à la commande "Key Hide Prefixes")



Il en ressort un résultat de comparaison plus "épuré" et pertinent



-------

Ce message a été modifié par MaxPoska - 23 Apr 2022, 22:59.

[MaxPoska]

Update au 17/05/2022:

Installation de la mise à jour macOS Big Sur 11.6.6 (20G624).



R.A.S

[MaxPoska]

Update au 29/06/2022:

Installation de la mise à jour macOS Big Sur 11.6.7 (20G630).



Mise à jour d'OpenCore en version 0.8.1

Une des nouveautés qui va nous impacter avec cette version est que dorénavant, la fonction de "Reset Nvram" (disponible comme entrée dans le menu de boot d'OpenCore) n'est plus inclus dans OpenCore en lui même mais est géré par un driver.
Il y a également un second nouveau driver qui ajoute une entrée dans le menu de boot d'OpenCore permettant d'avoir un raccourci pour activer ou désactiver le SIP (System Integrity Protection): ToggleSipEntry.efi
Je ne vais pas utiliser ce dernier driver donc je ne l'ajoute pas pour ma part.


- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi et ajout d'un nouveau driver ResetNvramEntry.efi

- Modification du config.plist:

Paramètres à ajouter:

Afin de pouvoir exploiter le nouveau driver "ResetNvramEntry.efi" il faut que celui-ci, au même titre que les autres drivers, soit déclaré (et activé) dans le config.plist

Ajout des différents paramètres pour gérer ce driver dans "UEFI" --> "Drivers"



(Il faudra également ajouter les infos pour "ToggleSipEntry.efi" si vous souhaitez l'utiliser)

Paramètres à supprimer:

Suppression des paramètres "AllowNvramReset" et "AllowToggleSip" qui sont dans la section "Misc" --> "Security" dont les fonctions sont gérés par les nouveaux drivers

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-081-2022-06-06
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.2
WhateverGreen en version 1.5.9

R.A.S suite à ces updates

Ce message a été modifié par MaxPoska - 29 Jun 2022, 23:11.

[MaxPoska]

Update au 07/07/2022:

Mise à jour d'OpenCore en version 0.8.2

Cette version apporte surtout une meilleur compatibilité avec macOS Ventura.
La plupart des kexts sont également mis à jour à cette occasion.

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Aucune modification à faire dans le config.plist

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-082-2022-07-04
maxime@iMHackdeMaxime ~ %

- Update des kexts:

VirtualSMC.kext (et plugins) en version 1.3.0
AppleALC.kext en version 1.7.3
Lilu.kext en version 1.6.1
WhateverGreen en version 1.6.0
NVMeFix.kext en version 1.1.0

R.A.S suite à ces updates

[MaxPoska]

Update au 21/07/2022:

Installation de la mise à jour macOS Big Sur 11.6.8 (20G730).




R.A.S

Probablement ma dernière mise à jour de Big Sur sur ce hack. Il va être temps d'installer macOS Monterey sur mon disque principal

[MaxPoska]

Update au 02/08/2022:

Mise à jour d'OpenCore en version 0.8.3

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Paramètres à ajouter:

Pour chaque driver présent dans "UEFI" --> "Drivers", il y a un paramètre supplémentaire à ajouter: "LoadEarly"
Je laisse la valeur "False" par défaut pour ce paramètre pour tous mes drivers.

Paramètre à supprimer:

Suppression du paramètre "LegacyEnable" dans la section "NVRAM"

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-083-2022-08-01
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.4
Lilu.kext en version 1.6.2
WhateverGreen en version 1.6.1

R.A.S suite à ces updates

[MaxPoska]

Update au 10/08/2022:

Mise à jour vers macOS Monterey

----------
----------

Sommaire:

- Prérequis
- Mode mise à jour ou clean install ?
- Création d'une clé USB d'installation
- Installation de macOS Monterey depuis la clé USB
- Utilisation de ProperTree sur Monterey
- Résoudre le problème d’appairage Bluetooth entre macOS et Windows
- Partage de mon EFI basé sur OpenCore 0.8.3

----------
----------

- Prérequis

Avant de faire une mise à jour majeur de macOS, il est important d’avoir OpenCore et les Kexts que l’on utilisent qui soient eux-mêmes à jour.
En effet, la plupart du temps, lors d'une nouvelle version majeure, les bootloaders et/ou kexts ont besoin de faire quelques ajustements pour prendre en charge la nouvelle version de macOS.

Si je regarde les changelogs d'OpenCore, on peut remarquer que macOS Monterey a commencé à être prit en charge à partir de la version 0.7.1 et d'autres ajustements ont été réalisés sur la version 0.7.4.

Pour la mise à jour des Kexts, il suffit d'aller télécharger les dernières versions (liens des Kexts utilisés sur la config dans le post 1 dans la rubrique "Liens Utiles").

Pour la mise à jour d'OpenCore, outre le fait de remplacer les fichiers par la nouvelle version, il y a une attention particulière à porter sur le config.plist qu'il faut bien mettre à jour (voir "Gérer les mises à jour d'OpenCore" de mon retex dans le post 5)
En effet, il est important d’ajouter ou de retirer les paramètres qui sont ajoutés ou supprimés du config.plist de la nouvelle version d’OpenCore par rapport à celle que l’on utilise.
Pour cela, et comme je le décris dans mon retex, on va utiliser l'utilitaire OCConfigCompare pour comparer notre config.plist avec le sample.plist et repérer ainsi les changements.

A titre d’exemple, voici ce que donne une comparaison d’un config.plist de la version 0.7.3 d’OpenCore (qui était la version que je partageais dans ce retex) avec le sample.plist de la dernière version 0.8.3.



On voit qu'il y a eu quelques ajouts et suppressions et c'est un travail qui peut s'avérer plus ou moins long si vous n'avez pas suivi les mises à jour d'OpenCore au fur et à mesure.
Une fois les ajustements faits, pensez à bien vérifier votre config.plist à l’aide de l’utilitaire ocvalidate de la nouvelle version afin de s’assurer que son config.plist est bien conforme, qu’il ne manque pas de paramètres et qu’il n’y a pas d’incohérence.

Encore une fois, vous trouverez plus de détails sur la procédure dans la partie "Gérer les mises à jour d'OpenCore" de mon retex dans le post 5

Je vous conseille également de vérifier dans le fichier pdf de configuration d’OpenCore ou, plus simplement, dans le guide de Dortania, s’il n’y a pas des paramètres à ajuster qui seraient spécifique à macOS Monterey (spoiler alert: rien n’est à ajuster en ce qui concerne notre configuration qui soit spécifique à Monterey )

Pour ma part, ayant suivi les différentes mises à jour successive d’OpenCore, je suis déjà sur la dernière version en date (0.8.3).
J’ai également toutes les dernières mises à jour des kexts.
Donc mon dossier EFI était déjà prêt pour macOS Monterey

- Mode mise à jour ou clean install ?

A partir du moment où l'on a bien respecté les prérequis sur la mise à jour d'OpenCore et de ses kexts, la mise à jour de macOS peut être effectuée en mode "mise à jour" depuis les "Préférences système" comme sur un vrai Mac !

J'ai pu faire le test et tout s'est bien déroulé. Je n'ai rien eu à faire de particulier et je suis passé de macOS Big Sur à macOS Monterey en quelques minutes sans rien faire de particulier et après quelques reboot.
J'ai quand même au préalable déconnecté le SSD où était installé Windows mais c'est plus par précaution que par obligation.

Cela étant dit, pour ma part, je préfère partir sur une clean install (donc une réinstallation complète du système) lors d’une mise à jour majeur.
Ça me permet de repartir sur un système propre. Rien à voir avec le hackintosh donc, c’est juste une question d’habitude (je fais la même chose sur mon MacBook Pro).


- Création d'une clé USB d'installation

Qui dit clean install, dit préparation d’une nouvelle clé USB de boot

De la même manière que l’on avait créé une clé USB de boot pour macOS Big Sur, on va utiliser la commande "createinstallmedia" pour créer une nouvelle clé USB de boot pour macOS Monterey (voir les explications dans le post 1 dans la rubrique "Création de la clé USB")

La commande à taper dans le Terminal pour macOS Monterey est la suivante (en partant du principe que votre installateur de Monterey se trouve dans le dossier "Applications" et que la clé USB se nomme "MyVolume"):

Code

sudo /Applications/Install\ macOS\ Monterey.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume

Ensuite, pour rendre la clé compatible hackintosh, il suffit de recopier le dossier "EFI" qui est présent dans la partition du disque où macOS Big Sur est installé (toujours en à l'aide de l’utilitaire "MountEFI" pour monter la partition EFI) dans la partition "EFI" de la clé USB.
En effet, tout le paramétrage a été fait précédemment, il suffit de reprendre le fruit de nos travaux

Copier bien le dossier "EFI" en lui même avec ses sous dossiers



Vous aurez peut être remarqué qu’il y a un dossier supplémentaire dans notre dossier "EFI" comparé à la clé USB d’installation que nous avions créée pour macOS Big Sur.

En effet, en plus des dossiers "BOOT" et "OC" d’OpenCore, il y a un dossier "APPLE" qui contient un sous dossier "FIRMWARE" qui lui même contient un fichier.
C’est un fichier qui est automatiquement créé lors de l’installation de macOS et qui sert à la mise à jour des firmwares des vrais Mac.
Vous n’avez pas à vous en soucier, ce n’est pas utiliser pour notre hackintosh et vous pouvez, au choix laisser ce dossier "APPLE" ou le supprimer sur la clé USB d’installation.
On en parle ici sur le guide de Dortania.
Pour ma part, je l'ai supprimé et conservé uniquement les dossiers "BOOT" et "OC" (histoire de se débarrasser du superflu )

Ensuite, j’apporte une petite modification sur le config.plist de la clé USB pour être en mode verbose (utile pour le déboguage s'il y a un a problème lors de l’installation).
Pour ce faire, j’ajoute le paramètre "-v" dans la section "NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82" au niveau du paramètre "boot-args"



- Installation de macOS Monterey depuis la clé USB

L'installation de macOS Monterey se déroule exactement de la même manière que pour macOS Big Sur (voir la partie "Installation de macOS" dans le post 3 du Retex)
Prenez bien soin de régler la priorité de démarrage pour que la clé USB soit en premier dans l'ordre de Boot.
Personnellement, je préfère également déconnecter tous les disques durs brancher et ne garder que le SSD sur lequel on va installer macOS de brancher pour ne pas que l'installateur de macOS installe des choses la où il ne devrait pas (encore une fois, c'est plus une précaution qu'une obligation).

Ensuite, l'installation se déroule normalement: On sélectionne "Install macOS Monterey" dans le menu de boot, on arrive sur le menu d'installation, on formate/choisis le disque sur lequel on veut installer son système puis on patiente

Après quelques reboots, l'installation de macOS est terminé et on arrive sur l'écran de configuration (la où l'on créé son compte local, définis son mot de passe ect).
Pour finir, on arrive enfin sur le bureau de macOS Monterey .

Ensuite, comme expliqué dans le Retex, il suffit de monter la partition "EFI" de la clé USB pour récupérer le dossier "EFI" et le copier pour le coller dans la partition "EFI" du SSD où est installé macOS Monterey.
Dès lors, on peut démarrer sans clé USB (et au redémarrage, on sélectionne "OpenCore" dans le BIOS en 1er dans l'ordre de boot)

Enfin, on retire le mode verbose.
Pour ce faire, on édite notre config.plist pour retirer le "-v" dans la section "NVRAM --> Add --> 7C436110-AB2A-4BBB-A880-FE41995C9F82" au niveau du paramètre "boot-args" toujours à l'aide de "ProperTree".

En parlant de ProperTree, je me suis rendu compte qu'il y avait une petite subtilité pour pouvoir l'utiliser sur macOS Monterey.
On voit ça juste en dessous

- Utilisation de ProperTree sur Monterey

Sur macOS Monterey, il semble qu'il y ait un problème dans le composant Python inclus dans le système qui gère les interfaces graphiques (brique "tk").
Si on créé l'application ProperTree grâce au script, en sélectionnant simplement "/usr/bin/env python3" comme je l'indique dans la partie "Paramétrage du config.plist" à la fin du post 1 du Retex, on se retrouvera avec une application qui sera inutilisable car l'interface sera entièrement noir.

Pour contourner le problème, il faut installer la dernière version de Python 3 (si vous avez utilisé MountEFI juste après l'installation pour accéder aux partitions "EFI", vous devriez déjà avoir installé Python 3 donc vous n'avez pas à le refaire )

Ensuite, lorsque l'on utilisera le script "buildapp-select.command" pour créer l'application, il faut sélectionner l'option "/usr/local/bin/python3 3.10.6 - tk 8.6" (et non pas "/usr/bin/env python3 comme pour Big Sur)



- Résoudre le problème d’appairage Bluetooth entre macOS et Windows

Après ma nouvelle installation de macOS Monterey, je me suis rendu compte d’un problème dans mon utilisation du dual boot avec Windows, en particulier avec mes périphériques Bluetooth (clavier et souris).

En effet, lorsque je bootais sur Windows, ma Magic Mouse et mon Magic Keyboard n’était plus appairer. Je devais les ré-appairer avec Windows pour que mes périphériques Bluetooth fonctionnent à nouveau.
Le problème, est que lorsque je retournais sur macOS, cette fois si c’était macOS qui perdait l’appairage et je devais donc ré-appairer mon clavier et ma souris avec macOS. Et ceci se produisait à chaque boot d’un OS à l’autre.

Bien que je ne boot pas souvent sur Windows, il se trouve qu’en ce moment, je dois pas mal le faire pour utiliser un programme qui n’existe pas sur macOS. Ce problème de perte d’appairage m’a donc vite agacer et après une recherche, j’ai trouvé une explication et une solution rapide.

J’ai donc trouvé la solution ici

Le problème réside donc dans le fait que lors d’un appairage entre un périphérique Bluetooth et un OS, une "clé de connexion" se génère et est stockée par le système. Cette clé est différente à chaque appairage et c’est pour cela que je perds la connexion à chaque appairage entre macOS et Windows: la clé de connexion est différente sur chacun des 2 OS.

La solution est donc simple: il suffit d’avoir la même clé de connexion sur les 2 systèmes pour que les périphériques Bluetooth puissent fonctionner sur les 2 OS sans avoir besoin de les ré-appairer à chaque fois
Apparemment, sur les vrai Mac, c’est BootCamp qui se charge de faire cette synchronisation de clés entre les 2 systèmes.
Bien que j’ai BootCamp installé sur ma partition Windows, je ne sais pas si cette synchronisation ne se fait pas car c’est un hackintosh et non un vrai Mac ou que j’utilise une ancienne version de BootCamp ou pour une autre raison.

Quoi qu’il en soit, pour résoudre le problème, j’ai donc suivi les étapes décrites par l’auteur du fil Reddit, à savoir:

1. Démarrer sur Windows et appairer mon clavier et ma souris à Windows
2. Redémarrer sur macOS et appairer à nouveau mes périphériques à macOS
3. Ouvrir l’application "Trousseau d’accès" sur le Mac
4. Rechercher les entrées qui s’appellent "MobileBluetooth":
Il devrait y avoir 1 entrée "MobileBluetooth" pour chaque appareil appairé.
Pour savoir quelles sont les entrées Bluetooth qui correspondent à quelle périphérique, pour chaque ligne "MobileBluetooth", vous avez une information qui est nommée "Compte".
Il s’agit de l’identifiant unique de notre périphérique (l’adresse MAC).
Vous pouvez savoir à quelle périphérique appartient chaque adresse MAC en allant dans l’application "Informations systèmes" au niveau de la rubrique "Matériel --> Bluetooth"



Dans mon cas, on sait que:

- Le clavier correspond à l’adresse MAC commençant par 70:F0:87
- La souris correspond à l’adresse MAC commençant par 48:4B:AA
- La carte Bluetooth en elle même a également une adresse MAC qui commence par 88:63:DF (on peut le noter car ça nous servira pour s’y retrouver tout à l’heure dans Windows)

Notez ces informations quelques part sur un bout de papier ou dans un fichier texte dans TextEdit par exemple.

5. Double cliquer sur chaque entrée mobile Bluetooth qui nous intéresse et cocher la case "Afficher le mot de passe" (taper votre nom et votre mot de passe pour afficher la donnée)
En réalité ce n’est pas un mot de passe qui va s’afficher mais des données sous forme XML.

6. Cliquer dans la zone de texte, appuyer sur les touches "Command + A" pour tout sélectionner et copier coller le contenu dans un fichier texte pour récupérer tout le contenu de l’XML. Répéter l’opération pour chaque périphérique (clavier et souris dans mon cas).



Ce qui va nous intéresser dans ce xml c’est la balise "LinkKey" qui contient la fameuse clé de connexion que l’on va devoir recopier sur Windows.



7. Copier votre fichier texte dans lequel vous avez noté toutes les infos sur une clé USB ou à un endroit accessible depuis votre partition Windows et redémarrer sur Windows.
Assurez vous d’avoir un clavier et une souris en USB à utiliser sous Windows le temps de faire la manip (puisque le clavier et la souris Bluetooth ne seront plus appairer).

8. Sur Windows, nous allons avoir besoin d’un petit utilitaire pour éditer la base de registre. Pour cela, télécharger PSTools
9. Dézipper le fichier zip téléchargé. L’utilitaire dont a besoin est "psexec.exe". Je vous conseil de déplacer l’utilitaire "Psexec.exe" qui est dans le répertoire "PStools" que l’on a téléchargé, à la racine de votre disque (C:) afin de pouvoir y accéder plus facilement en ligne de commande.
10. Exécuter l’application "Invite de commandes" en tant qu’administrateur. Pour ce faire, taper "cmd" dans la barre de recherche et positionnez vous sur "invite de commandes" et enfin cliquer sur "Exécuter en tant qu’administrateur"



11. Dans la fenêtre qui s’ouvre taper "cd c:/"  (ou le chemin complet où vous avez mis l’utilitaire psexec.exe) puis taper la commande

Code

psexec -s -i regedit

12. Une fenêtre d’acceptation du contrat va s’ouvrir, cliquer sur "Agree"



13. L’éditeur de registre va alors s’ouvrir.
Dans la partie gauche, aller dans le répertoire:

Code

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\Adresse_MAC_de-votre-carte (dans mon cas 8863df….)

14. Dans la partie droite, c’est ici que l’on retrouve la clé de connexion (dans la colonne "Données") associé à l’adresse MAC (que l’on repère dans la colonne "Nom") correspondant au clavier et à la souris.
On voit bien que les clés de connexion sont différentes entre ce qu’il y a sur macOS et ce qu’il y a sur Windows.



15. Il faut donc que l’on modifie ce qu’il y a dans la colonne "Données" afin d’avoir la même clé de connexion que ce qu’il y a sur macOS
Pour ce faire, double cliquer sur l’adresse MAC dans la colonne "nom" du périphérique pour lequel on souhaite modifier la clé de connexion.
Une fenêtre "modification de la valeur binaire" va alors s’afficher.
Effacer la clé existante et recopier la clé qui est utiliser sur Macos (pas besoin de mettre les tirets) puis cliquer sur "Ok"





16. Fini Maintenant que l'on a la même clé de paramétré sur Windows et macOS, plus de problème de dés-appairage

- Partage de mon EFI basé sur OpenCore 0.8.3

Je vous mets à disposition mon dossier "EFI" pour la Z370 HD3P de la clé USB d'installation basé sur OpenCore 0.8.3: https://www.dropbox.com/s/bj4kkv1l5hrbmks/E...70HD3P.zip?dl=0

ATTENTION: Il y a quelques réglages à faire dans le config.plist avant d'utiliser ce dossier "EFI":

- Si vous n'utilisez pas le BIOS modifié par Gigabyte pour avoir l'option "CFG-Lock" de disponible dans le BIOS (voir le détails dans le post 3 du retex) vous devrez alors passer le paramètre "AppleXcpmCfgLock" à "True" dans le config.plist dans la section "Kernel --> Quirks"
- Le config.plist mis en partage est vierge de numéros de série. Vous devrez générer les vôtres à l'aide de l'outil GenSMBIOS et renseigner les paramètres nécessaires dans la section "PlatformInfo"
Vous trouverez plus de détails sur les paramètres à renseigner dans la section "PlatformInfo" ainsi que l'utilisation de GenSMBIOS dans le post 2.
- Le config.plist mis en partage est réglé pour être en mode verbose. Vous pouvez lire la partie "fignolage" du retex dans le post 4 pour savoir comment le retirer en post installation.

-----------

Pour conclure, ma mise à jour vers macOS Monterey s'est passé de manière totalement fluide (sans vraiment de surprise, je sais que ça fonctionne bien depuis plusieurs mois ) et, à part les 2 derniers points remontés, je n'ai rien de particulier à signaler

Ce message a été modifié par MaxPoska - 7 Sep 2022, 22:02.

[MaxPoska]

Update au 18/08/2022:

Installation de la mise à jour macOS Monterey 12.5.1 (21G83).




R.A.S

[MaxPoska]

Update au 07/09/2022:

Mise à jour d'OpenCore en version 0.8.4

- Update des fichiers OpenCore:

- BOOTx64.efi
- OpenCore.efi
- Les drivers: AudioDxe.efi, CrScreenshotDxe.efi, OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efi

- Modification du config.plist:

Il n'y a pas de paramètres à retirer ou ajouter

(sauf si vous utilisez les "tools", dans ce cas la, il y a un nouveau paramètre à ajouter: "FullNvramAccess" pour chaque outils utilisé)

Code

maxime@iMHackdeMaxime ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-084-2022-09-05
maxime@iMHackdeMaxime ~ %

- Update des kexts:

AppleALC.kext en version 1.7.5

R.A.S suite à ces updates