Planung meines ersten Hackintoshs gestartet

Danke für den Upload!
Auf den ersten Blick sind mir mehrere Sachen aufgefallen:

ACPI: Du hast mehrere USB-Port-Configs aktiv. Ich würde die alle erstmal deaktivieren (mehr als einer sollte sowieso nie aktiv sein!), und nur mit USBInjectAll-Kext und dem XHCIPortLimit-Quirk in der Kernel-Abteilung (hast du schon aktiv) booten. USB-Feintuning kannst du später machen, erstmal sollte USBInjectAll und der Quirk ausreichen, damit temporär alle Ports mal laufen (und dann genauer begutachtet und konfiguriert werden können). Ansonsten sieht ACPI gut aus.

Booter: Ich habe dort den SetupVirtualMap-Quirk deaktiviert. Dortania schreibt dazu:

"Fixes SetVirtualAddresses calls to virtual addresses, however broken due to Comet Lake's memory protections. ASUS, Gigabyte and AsRock boards will not boot with this on."
Könnte also relevant für dein Gigabyte-Board sein.

Kernel: Die CFG-Lock-Quirks kannst du deaktivieren, weil du im neuesten BIOS mittlerweile CFG-Lock direkt deaktivieren kannst.

Kexts kannst du aufräumen, manche Addons für VirtualSMC brauchst du nicht (Hast weder eine Batterie noch ein Dell-Laptop noch einen Lichtsensor verbaut...)

Der Rest sieht eigentlich ganz gut aus. Ich persönlich vermute, der eine Booter-Quirk könnte das Hauptproblem gewesen sein (deshalb lohnt es sich, den Guide zu lesen!)

Wenn die Tipps umgesetzt sind, ist es denke ich Zeit für einen weiteren Versuch!

DSM2

Hallo Alex, tausend Dank für deinen Hinweis!!

Ich habe bei der Einrichtung ebenfalls gelesen, dass USBInjectAll nicht notwendig ist, Dortania schreibt dazu ja auch "Shouldn't be needed on Desktop Skylake and newer".

Also habe ich es damals erstmal weggelassen und konnte nicht booten, erst nachdem ich USBInjectAll hinzugefügt hatte. Allerdings hatte ich auch ein Portmapping per SSDT-UIAC.aml für meine benötigten 15 Ports vorbereitet (ohne Portlimit-Patch).

Vielleicht nochmal für mich zum Verständnis:
-Brauche ich USBInjectAll, wenn ich einfach nur mit XHCIPortLimit-Quirk booten will, ohne irgendeine USB-Config per Kext oder SSDT-UIAC? EDIT: Nein

-Brauche ich USBInjectAll, wenn ich ein Portmapping per SSDT-UIAC einbinden möchte? EDIT: irrelevant, besser das USB-Mapping per USBPorts.kext erledigen

Für die Methode mit per Hackintool oä. erstellten USBPorts.kext brauche ich USBInjectAll ja nicht, das habe ich schon herausgefunden.

Möglicherweise dachte ich, USBInjectAll wäre notwendig, weil ich es von Anfang an zusammen mit einem SSDT-UIAC-Portmapping versucht habe, statt nur den XHCIPortLimit-Patch zu aktivieren und so zu booten? Und ich hätte auch ohne USBInjectAll Erfolg gehabt, hätte ich es nicht von Anfang an mit einer SSDT-UIAC versucht?

Ich habe es blöderweise nie ohne USBInjectAll, ohne SSDT-UIAC und mit Portlimit-Patch versucht, immer nur USBInjectall + SSDT-UIAC oder eben eine USBPorts.kext...

Kannst du das dann auch zur dauerhaften Nutzung empfehlen?

Die Opencore-Doku wird beim XHCIPortLimit-Quirk ja ziemlich deutlich:

"Note: This option should be avoided whenever possible. USB port limit is imposed by the amount of used bits in locationID format and there is no possible way to workaround this without heavy OS modification. The only valid solution is to limit the amount of used ports to 15 (discarding some)."

Ich habe bisher immer brav meine Ports auf <= 15 reduziert weil ich Angst vor Instabilität habe. Ist die Sorge deiner Meinung nach unbegründet?

Ist für jeden Port dann auch seine Anschlussart schon hinterlegt? Beim klassischen Port-Mapping gibt man ja auch an, ob der Port internal/USB-A/USB-C usw. ist.

Das bringt gerade etwas mein Weltbild zum Thema USB-Mapping durcheinander, ich war da bisher sehr überzeugt davon, dass das ein wichtiger Schritt zum stabilen Hacki ist. Aber gut, ich bin natürlich auch froh um jede Vereinfachung des Konfigurationsprozesses...

Upps, dann hatte ich das falsch verstanden und du hast dich nur auf die Installation bezogen!

Spike-Muc

Dann also als kleine Korrektur zu dem, was ich in Post 41 geschrieben habe:
-USBInjectAll und die SSDT-UIAC können generell dauerhaft weg

-Zur Installation: Nur den XHCIPortLimit-Quirk aktivieren, damit sollte USB temporär laufen

-Für den dauerhaften Betrieb: Statt USBInjectAll und eine der SSDT-UIAC zu verwenden, besser das Portmapping über eine USBPorts.kext erledigen. Das Hackintool ist dabei eine große Hilfe. Aber das können wir uns dann gerne anschauen, wenn die Kiste grundsätzlich bootet!

Spike-Muc hoppla, du hast ja gar kein VirtualSMC!

Das ist quasi "der" Kern eines jeden Hackintoshs. Ohne einen (virtuellen) System Management Controller geht bei MacOS gar nichts. SMCProcessor und SMCSuperIO sind "nur" Addons für die Haupt-Kext VirtualSMC. In deiner letzten Version war der noch drin, vermutlich dem Säubern versehentlch zum Opfer gefallen...

Ich schau mal weiter ob mir sonst noch was auffällt, aber ohne SMC kann es schonmal nicht klappen.

Edit:
-Für USBInjectAll hatten wir ja herausgefunden, dass du es nicht brauchst. Das also auch weg!

-Und hast du geprüft, ob du im BIOS auch entsprechend CFG-Lock deaktiviert hast?

-Die SSDT-EC-USBX brauchst du glaube ich vorerst weiterhin. Sie gehört wie im Guide beschrieben zu den benötigten SSDT für Comet Lake (neben AWAC und PLUG) und soll zwei Funktionen erfüllen:
1. ein fake EC-Device erstellen

2. USBX-Einstellungen machen (weiß nicht wie man es nennt, es geht dabei um Stromeinstellungen für USB)

Die Version von Schmocklord enthält, obwohl sie EC-USBX heißt, nur den zweiten Teil, scheint aber trotzdem zu funktionieren.

Ich habe letztens die Erfahrung gemacht, dass ein B460-Board nicht bootete ohne diese USBX-Einstellungen, deshalb denke ich, dass das der entscheidende Teil ist (und dass deshalb auch Schmocklords Version funktioniert). Bei Dortania ist aber auch beschrieben, wie man eine SSDT mit EC-Device und den USBX-Einstellungen für sein Board erstellen kann, wenn du es genau wissen willst.

Ich kann dir später, wenn der Rechner läuft, meine SSDT-EC zur Verfügung stellen, die nur den ersten Teil (EC) enthält. Der zweite Teil (USBX) kann nämlich von der USBPorts.kext, die wir basteln werden, miterledigt werden.

Zur Config:
-Die FuzzyMatch Option unter Kernel-->Scheme brauchst du nicht. KernelArch habe ich dort auch auf Auto. Wenns von Schmocklord stammt, wahrscheinlich aber nicht schädlich und nur fürs booten von BigSur relevant, so wie ich seine Config kenne...

Sonst sieht das denke ich gut aus, Zeit für den nächsten Versuch!

Bevor ich mir die Config nochmal im Detail anschaue, würde ich vorschlagen, wir schauen zuerst nach dem CFG-Lock. (Die Config sah letztes Mal eigentlich schon sauber aus!)

Das macht mich etwas stutzig, dass du diese Einstellung nicht findest im BIOS. Hast du die aktuellste BIOS-Version, bzw. welche BIOS-Version ist bei dir drauf? Diese Einstellung wurde per Update nachgereicht, meines Wissens sogar Dank der unermüdlichen Arbeit eines Forenmitgliedes hier. Die Einstellung muss unter Boot zu finden sein!

Das EFI-Tool, dass du gefunden und eingebunden hast, ist gut für Mainboard, bei denen diese Einstellung im BIOS vom Hersteller versteckt wurde. Deshalb sollten wir das eigentlich nicht benötigen...Diese EFI-Tools müssen übrigens in Opencore explizit gestartet werden (die sollten auch wie ein Booteintrag als Zeile erscheinen), das reine Einbinden von EFI-Tools ohne sie zu öffnen bringt nichts.

Falls mir zur Config noch was einfällt, reiche ich das noch nach.

Edit: In der Config ist mit sonst nichts mehr aufgefallen.

Zum Bearbeiten der config.plist: Wenn du mit dem Format gut zurechtkommst, kannst du das editieren wie du willst. Ich verwende den Opencore Configurator und hatte bisher keine Probleme deine Config zu öffnen, von daher ist das denke ich gut so wie du es machst. Wenn du auf Nummer sicher gehen willst, kannst du ja die Syntax in einem Plist-Editor kurz prüfen. Mit einem plist-Editor kann man generell weniger Fehler machen und manche finden das übersichtlicher. Der Opencore Configurator hat auch eine Text- und eine Plist-Ansicht, ich persönlich komme aber mit der grafischen klickibunti-Darstellung am besten klar. Der Configurator ist ein bisschen verpönt und gebrandmarkt weil er es wohl in früheren Versionen geschafft hat, saubere Configs zu zerstören, aber ich habe solche Probleme nie gehabt, habe wohl zu spät mit Opencore angefangen um das noch mitzubekommen.

Autsch, das ist ja so alt, dass es bei Gigabyte auf der Homepage nicht mal mehr gelistet wird. Bitte aktualisier das mal auf F6 vom 22.09.

Nicht wundern, das BIOS hat dann ein weißes helles Design. Und die CFG-Option sollte da sein.

Das ist auf jeden Fall ein weiterer Schritt zur Lösung!

Edit: Und, auch wenn es wehtut: Mach am besten die BIOS-Einstellungen danach neu.

Also Update einspielen, nochmal die BIOS-Werkseinstellungen laden, und dann nochmal alle Einstellungen vornehmen und als letztes als Einstellungsprofil sichern (am besten auch für die Zukunft auf einem USB-Stick, ist immer gut davon ein Backup zu haben).

Vielleicht wird es möglich sein, auf F6 ein Einstellungsbackup von F3 einzuspielen, aber ich würde das nicht empfehlen, bei so einem großen Sprung könnte dabei schon mal was schief gehen.

Das dürfte an der AAPL,ig-platform-id liegen, welche die IGPU ohne Displays betreibt, also nur zur Beschleunigung.

Hast Du noch keine GPU von AMD nachgerüstet?

Mieze die platform-id ist grundsätzlich nicht falsch, ist eine für IGPU mit Bildschirmanschluss. Ohne Bildschirmanschluss, nur für Computing, wäre 0300C89B. Seine aktuelle Config nutzt 07009B3E.

Dortania schreibt aber auch (deshalb ist es wichtig, den Guide zu lesen!):

"Note: With macOS 10.15.5 and newer, there seems to be a lot of issues with black screen using 07009B3E, if you get similar issues try swapping to 00009B3E"

Da haben wir also schon den nächsten Tipp für einen weiteren Anlauf!

Bei IGPU stocher ich immer ein bisschen im Dunkeln rum, ich habe bisher nur Hackis mit AMD GPU. Aber aktuell ist es wohl tatsächlich sinnvoll, erstmal mit der IGPU zu arbeiten und auf die neuen AMD-Modelle zu warten (und wenn man nur wartet, damit die Preise der RX5700XT sinken)

Hm...bleibt der Rechner dann dauerhaft an, also denkst du er ist gebootet und zeigt nur kein Bild an? Oder hängt er sich irgendwann auf oder stürzt ab/startet neu? Ein Anzeichen für gebootet könnte sein, dass Num-Lock auf der Tastatur funktioniert oder dass ein kurzer Druck auf den Einschaltknopf nicht zum Ausschalten ausreicht, oder vielleicht auch dass am Gehäuse die HDD-LED blinkt.

Und davor bootet er unauffällig und zeigt auch Debugeinträge auf dem Monitor an?

Wie sind die BIOS-Einstellungen der IGPU? Vielleicht kannst du uns davon ein Bild machen. Die relevanten Einstellungen müssten alle dort sein, wo sich auch die "Initial Display Output" Einstellung befindet.

Edit:
Was mir gerade auffällt: SchmockLord hat in seiner Config für die IGPU mit Displayausgang ("config_iMac20,2_iGPU with display output_with 5700XT.plist") noch einen Haufen weiterer Einstellungen für die IGPU, habe einen Screenshot angehängt. Allerdings kenne ich mich damit längst nicht gut genug aus, um dir erklären zu können, wofür diese gut sind. Möglicherweise ist für dich jede relevant, vielleicht auch nur eine einzige...ich weiß nur, dass HDMI Ausgänge oft zickiger sind als Displayport, und da das Vision-D-Board nur HDMI als Ausgang hat, wäre es gar nicht so abwegig, dass da noch weitere Einstellungen nötig sind.

Vielleicht kann dazu aber noch jemand was sagen, der sich mit diesen Einstellungen besser auskennt als ich.

Dann kannst du auf jeden Fall mal Schmocklords Einstellungen testen.

Als weiteren Versuch bleibt dann noch die Doku von Whatevergreen bzw. der Doku-Teil über Intel-GPU (diese ganzen Einstellungen über die wir reden sind alle für die Whatevergreen kext, damit es die IGPU konfigurieren und einbinden kann).

Dort findest du unter dem Abschnitt "Intel UHD Graphics 610-655 (Coffee Lake and Comet Lake processors)" noch weitere IDs, die du durchprobieren könntest. Dort sind sie in einer anderen Schreibweise genannt, nämlich byteweise vertauscht. ZB die erste ID, die du verwendet hast, "07 00 9B 3E" findest du in der Liste unter "0x 3E 9B 00 07". Für Desktops empfohlen ist da blöderweise aber auch genau die, die du schon zuerst verwendet hattest. Deshalb bin ich mir nicht ganz sicher, ob das Durchtesten von weiteren IDs, die eigentlich zu Laptops gehören, zum Erfolg führen könnte. Die von Dortania genannte Alternative 00009B3E, die du auch erfolglos getestet hast, gehört allerdings auch zu den Laptop IDs. Wenn Dortania auch Laptop IDs als Alternative vorschlägt, könnte es sich vielleicht lohnen, noch weitere IDs zu testen.

Ich muss allerdings wirklich sagen, dass das auch für mich komplettes Neuland ist, da ich wie gesagt bisher immer mit AMD-GPUs gearbeitet habe.