Beiträge von traeu

Wenn du die Apple ID schon verwendest, würde ich erst Recht damit anfangen, zu überprüfen ob da alles korrekt ist. Ich glaube auch, dass iMessage und Facetime nochmal empfindlicher sind als andere Apple-ID-gebundenen Apps, also am besten erst mal nichts weiter nutzen was mit der Apple ID zusammenhängt. Höchstwahrscheinlich muss nur noch die ROM Nummer geändert werden, wenn die generierte Serial die bei Dortania beschriebene Prüfung besteht, NVRAM funktioniert und dein 1GBit-LAN schon En0 ist.

Wie du den 2.5GBit Port nutzen kannst, habe ich ja oben geschrieben. Kannst danach zur Sicherheit nochmal prüfen, ob weiterhin einer der beiden Ports En0 ist (im Terminal ifconfig), das ist wichtig für iServices.

Fürs Audio musst du mal bei Schmocklord vergleichen, ob dein PCI-Pfad bei den Device Properties korrekt ist, der ist beim Vision D nicht wie bei Dortania beschrieben. Falls Schmocklord in seiner Config noch eine andere Device-ID bei der Soundkarte drin hat: Das braucht man seit einem AppleALC Update nicht mehr. Für Audio muss also nur die Layout-ID eingetragen werden. Da Bootargumente Vorrang haben, darfst du dann kein alcid=X Bootargument mehr verwenden, weil das sonst den Layout-ID-Eintrag bei DeviceProperties überschreibt. Als Layout-ID funktionieren 7 & 11 (beide gleich) und 16. Musst mal testen was dir besser passt, bei einem von beiden ist das Front-Mikro etwas leise und wird als Line-In erkannt. Audioausgabe sollte aber bei keinem ein Problem sein. Auch die anderen Ports hinten sollten funktionieren.

Zur Opencore GUI gibts auch eine Anleitung bei Dortania, ist nicht schwierig und läuft bei mir bisher absolut stabil. Die Audio-Files im Ressources-Ordner kannst du dabei wieder löschen wenn du nur GUI und keine Audioausgabe im Bootmenü willst, das bläht den EFI-Ordner sonst ziemlich auf.

Für das aktuell eingebaute WLAN gibt es meines Wissens erste erfolgsvesprechende Experimente, aber ich denke das ist nichts, was du jetzt ausprobieren müsstest, wenn die Fenvi unterwegs ist.

Für das USB: Als erste Vorüberlegung kannst du mal in Schmocklords Github schauen, da ist eine PDF, in dem die USB-Anschlüsse (HS, SS und SSP) mit ihrem Namen bzw. ihrer Nummer abgebildet sind. MacOS erlaubt per USB-Controller nur 15 Ports. Das Vision D Board hat 2 USB Controller: An einem hängen nur die SSP-Ports (USBC-Buchse), deshalb muss man sich da keine Sorgen um das Limit machen. Am anderen Controller hängen alle HS (HighSpeed, USB2) und SS (SuperSpeed, USB3) Ports, also alle anderen. Auch wenn du sehen wirst, dass nicht jede Buchse ein eigener Port ist, weil manche Buchsen über Hubs zusammengefasst sind: Dadurch, dass USB3-Ports von MacOS als zwei Ports gezählt werden (HS und SS, weil man an USB3-Buchsen ja auch USB2-Geräte anschließen kann, das sind eigentlich zwei getrennte Anschlüsse in einer Buchse) überschreitet das Vision D Board das Portlimit, ich glaube 20 Ports sind es. Du musst also 5 Ports raussuchen, die du nicht brauchst, die dann deaktiviert werden. Den USB-Port für die onboard-Bluetooth-Karte brauchst du schonmal nicht, den Port für den RGB-Licht-Controller vermutlich auch nicht. Dann schaust du am besten, welche internen USB-Ports du nicht brauchst: Wenn dein Case keinen USB-C-Anschluss hat, kannst du da nochmal 3 Ports sparen und bist schon bei 15. Den internen USB2.0-Port brauchst du für das Bluetooth der Fenvi. Falls dein Case USBC und USB3 hat und du die internen Header dafür deshalb nicht deaktivieren willst, musst du die andere Ports raussuchen, die du (teilweise) deaktivierst. Du kannst zB auch von einer USB3 Buchse das USB2 deaktivieren um Ports einzusparen, dann gehen halt keine USB2-Geräte mehr an dieser USB3-Buchse.

Was du auf jeden Fall auch mal machen kannst, ist das Tool Hackintool zu installieren. Das kann bei vielen Sachen sehr nützlich sein!
Jetzt geht der wie ich finde eigentlich spaßigste Teil los: Du kannst grundsätzlich booten und diese Stufe nimmt dir keiner mehr. Jetzt kannst du dich solange den Feinheiten widmen, bis alles passt und funktioniert!

Bei Dortania gibt es sehr viele Anleitungen in der Rubrik Post-Install, die sehr nützlich sein werden.

Wenn die EFI kopiert ist, und du einmal ohne Stick gebootet hast, solltest du im BIOS (wieder) die Bootoption "Opencore" sehen. Das ist eine kleine Hilfe von Opencore (Bootstrap) um zu verhindern, dass sich Windows zukünftig vordrängeln kann (auch wenn ich erstmal die Windows Platte abgesteckt lassen würde). Wenn du dann im BIOS als erste Bootoption dieses Opencore auswählst und alle anderen Einträge deaktivierst (auch den Eintrag der SSD selbst) sollte sichergestellt sein dass dein Rechner immer in Opencore bootet.

Als nächstes könntest du die beiden LAN-Ports testen und einrichten und anschließend alles für die saubere Nutzung der iServices vorbereiten. Einer der LAN-Ports sollte jetzt schon gehen (der 1GBit-Port), denn den Treiber dafür, IntelMausi, hast du bereits. Für den 2.5GBit-Port wird ein Treiber, der schon in MacOS vorhanden aber eigentlich für ein leicht anderes Modell ist, zurechtgebogen (bzw die Karte wird so umbenannt, dass der MacOS-eigene Treiber sie als kompatibel erkennt). Dazu brauchst du einmal den Eintrag, den du vorher wegen der Kernel Panic gelöscht hast (Zur Sicherheit auch nochmal mit Schmocklords Config vergleichen ob der PCI Pfad korrekt ist), und einmal die beiden FakePCIID Kext aus Schmocklords Github (NICHT intel-hdmi-audio, den braucht man für die neuesten Opencore-Versionen gar nicht mehr, sondern die beiden anderen). Wenn du diese Kexts hinzufügst und aktivierst, und gleichzeitig den Device-ID Eintrag einfügst, solltest du ohne Kernel Panic booten und beide LAN Ports nutzen können.

Wenn die LAN Ports gehen, kannst du diese Anleitung durcharbeiten und iServices einrichten:
https://dortania.github.io/Ope…/universal/iservices.html

-Serial generieren bzw. prüfen ob deine aktuelle gut so ist

-Deine ROM zur MAC-Adresse von En0 ändern (ist bei dir aktuell noch 11 22 33 44 55 66)

-Prüfen ob du En0 als Netzwerkkarte hast (die beiden Terminalbefehle um die Netzwerkeinstellungen einmal zu resetten würde ich generell ausführen, schadet nix und danach sollte auf jeden Fall eine deiner LAN-Karten En0 heißen)

-Prüfen, ob NVRAM funktioniert. Sollte es eigentlich, du kannst zum testen einfach in Hackintool eine neue beliebige NVRAM-Variable mit beliebigem Namen und beliebigem Inhalt anlegen. Wenn die nach einem Reboot noch da ist (nicht wundern, wenn du einen String eingibst wird der nach dem Reboot nicht mehr lesbar sondern in HEX angezeigt), funktioniert NVRAM.

Dann hast du schonmal LAN, NVRAM, SMBIOS-Kontrolle und iServices erledigt. Falls du nen Apple-Account hast, solltest du dich ab dann ohne Probleme einloggen können. Wichtig: Das SMBIOS darfst du dann nicht mehr ändern (nicht einfach mal auf neu generieren klicken und vor allem nicht versehentlich verlieren) und muss auch immer übernommen werden, wenn du mal eine andere Config testen solltest. Sonst kann es Probleme mit dem Apple-Account geben.

Corv & Spike-Muc danke für das Lob, aber ich bin wirklich auch nur Anwender und aufmerksamer Leser von Anleitungen. Mein Glück ist bloß, dieses Board schon einmal verwendet zu haben. Die wirkliche harte Arbeit haben längst andere vor mir für uns erledigt und ich kann gar nicht sagen, wie unendlich dankbar ich dafür bin. An der Stelle mal ein fettes Dankeschön an alle Entwickler*innen und Vordenker*innen die das möglich machen! Abartig cool was ihr möglich macht und immer wieder cool zu sehen, dass ihr sogar noch Zeit und Lust habt, nebenher in Anfängerthreads wie diesen mitzuhelfen

Megagut!!

Jetzt wo du es sagst, ist es logisch: Wir brauchen später noch ein zwei Kexte, um deinen zweiten LAN-Port zusammen mit diesem Device-ID-Eintrag zum laufen zu kriegen. Dass dieser Eintrag ohne Kexte eine Kernel Panic erzeugt ist mir auch neu, wieder was gelernt.

Wenn du das Land und so weiter wählen kannst, bist du mit der Installation eigentlich durch. Dann solltest du bald zum ersten Mal den Schreibtisch deines neuen Hackis sehen können!

Der nächste Schritt wäre dann, die Kiste ohne USB-Stick zum booten zu bringen, indem du den EFI-Ordner vom Stick auf die EFI-Partition des Hackis kopierst. EFI kannst du per Terminal finden und mounten oder wie ich den Opencore Configurator dafür nutzen (der hat ein Menübar-Icon extra dafür), oder du nutzt eins der zahlreichen anderen Tools die hier so kursieren, die EFI mounten können viele.

Edit: Sogar das Forum verlinkt automatisch eine Anleitung dazu

Hebe dir auf jeden Fall den aktuellen EFI-Ordner gut auf, am besten auf dem Stick (und bei zukünftigen funktionierenden Versionsständen auch mal die Version auf dem Stick aktualisieren). Dieser EFI-Ordner ist das Herz deines Hackintoshs, der Rest der Festplatte ist 1:1 wie beim echten Mac. Damit kannst du also zur Not immer booten, wenn die Experimente mal zu wild wurden.

Eine andere Variante wäre, Änderungen am EFI immer erst vom Stick zu testen bevor du sie auf die Festplatte überspielst, aber ich finde das ein bisschen übertrieben. Wenn man Änderungen nur einzeln und mit Verstand vornimmt, kommt man eigentlich selten in die Situation, den Rettungs-Stick zu brauchen.

Kannst du bitte nochmal deine EFI hochladen?
Ich will mal versuchen, auf die Schnelle alles nicht zwingend zum booten notwendige zu entfernen, nur damit wir Fehlerquellen ausschließen, die zum jetzigen Zeitpunkt unnötig sind.

Falls das zum Erfolg führen sollte, können wir suchen woran es genau lag, falls nicht können wir immerhin auf einen Schlag ein paar Sachen als Ursache ausschließen.

Wenn im BIOS CFG-Lock deaktiviert ist, sollte auch AppleCpuPmCfgLock und AppleXcpmCfgLock nicht benötigt werden.

Schonmal sehr gut, dass du ein Bild bekommst!

Damit klar ist, wo du genau stehst: Das Installationsprogramm lief komplett durch und anschließend wurde in Opencore die neu installierten "mymac" Platte angezeigt? Wurde die Installation dort dann noch fortgesetzt oder kommt es immer wenn du versuchst von "mymac" zu Booten zu dieser Kernel Panic? Nach dem ersten Teil, der vom gebooteten Stick erfolgt, kommt eine weitere Installationsphase wenn man dann von der frischen Platte startet. Ist da schon irgendwas passiert oder direkt Kernel Panic?

Oder passiert die Panic schon während der Installer auf dem Stick noch läuft?

Der Installations-Stick bootet aber weiterhin problemlos?

Auf der Kiste lief schonmal Windows oder? Vielleicht bringt dann ein NVRAM-Reset etwas. Wenn du AllowNVRAMReset in der Config aktiviert hast (in deinem letzten EFI-Upload ists aktiv), zeigt Opencore direkt einen Eintrag zum resetten an.

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.

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.

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)

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.

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.

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!

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!

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...

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...

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!

Zeig uns bitte mal deinen aktuellen EFI-Ordner!

Und es wäre eben gut zu wissen, ob der Rechner vor Opencore oder beim MacOS-Boot hängt.

Kommt das Opencore-Menü und du kannst auswählen, dass du vom Install-Stick booten willst, oder kommst du erst gar nicht bis ins Opencore-Menü? Dann wüssten wir schonmal, welchen Teil deines EFI-Ordners und der Config wir uns genauer anschauen müssten.

Am besten zeigst du uns noch einmal deinen aktuellen EFI-Ordner und lädst ihn hier hoch. Als Tipp: Tools und Ressources-Ordner müssen nicht sein, dann kommst du auch an keine Uploadgrenze hier im Forum.

Außerdem wäre es gut zu wissen, wie weit du mit der aktuellen Config kommst: Hängst du fest bevor Opencore etwas anzeigt, oder kannst du in Opencore den Install-Stick wählen und bekommst danach einen Fehler? Gibt es eine Bildschirmausgabe und wenn ja, was steht zuletzt da?

Hallo Fatih1403! Deine Geizhals-Liste würde auch laufen. Da hast du den Vorteil, dass es hier im Forum schon vorgestellte Builds mit dem Board existieren, bei den anderen Boards bin ich mir nicht sicher. Grundsätzlich ist das Board nicht so wichtig, man sollte eigentlich alle Z490 und B460 mehr oder weniger perfekt zum Laufen kriegen. Der Unterschied ist nur, weil jedes Board seine Eigenheiten hat, ob du die Config selbst erarbeiten musst oder ob du auf bereits vorhandene Infos zurückgreifen kannst. Grundsätzlich sollte man aber eh nie eine Config 1:1 einfach so kopieren ohne sie zu verstehen, das führt meist schnell zu Hilflosigkeit beim kleinsten Fehlerchen.

Ich schätze die Hardware auch als ausreichend ein für Videoschnitt im semi-professionellen Bereich. Klar geht immer mehr, aber 10 Kerne muss man auch erstmal auslasten, vor allem beim schnippeln. Dass es beim Rendern nie schnell genug gehen kann ist klar, da würden mehr Kerne noch schneller zum Ziel führen. Und RAM lässt sich bei Bedarf immer recht einfach aufrüsten. Man sieht ja in der Aktivitätsanzeige, wenn das notwendig wäre, weil der Speicherdruck dauernd auf Anschlag ist und andauernd Zeugs ausgelagert wird.

PS: Wenn du auf ein Thema nicht antworten kannst, ist der letzte Post vmtl. bereits von dir. Dann kannst du einfach den bisherigen letzten Post editieren und bei Bedarf nochmal als neu markieren.

EDIT: Mein Text zum Board bezieht sich auf das Vision D, ich sehe gerade du hast die Liste nochmal erweitert und weitere Boards hinzugefügt.

Nimm dir die Zeit! So lange dauert es gar nicht und meiner Meinung nach ist es super informativ geschrieben und zu vielem gibts auch noch Hintergrundinfos, wenn man ganz neugierig ist. Und, wenn es gerade nicht um Grafik geht, hast du ja immer noch den Ordner von Schmocklord zum rüberschielen. Gerade bei der ACPI-Thematik sehr schön zum lernen, wenn man sich im Guide anschauen kann, wie man es manuell machen würde und warum man es so macht, und trotzdem schon Dank Schmocklords Arbeit die fertigen .asl-Dateien vorliegen hat.

Und bei Fragen: Immer her damit!

Genau das meinte ich mit copy&paste vs. selbst erarbeiten: Du solltest definitiv die Anleitung von Dortania durcharbeiten und deine vorhandene Config abgleichen oder besser den EFI-Ordner selbst aufbauen. Schmocklord verwendet noch eine AMD-GPU und ich glaube alle seine Config-Varianten berücksichtigen das. Da du nur die IGPU nutzen willst, müssen wohl noch ein paar Anpassungen vorgenommen werden.

Allgemein: Schmocklord ist sich sicher, dass seine Kiste bootet, deshalb hat er kein "-v" Bootargument mehr in der Config auch den restlichen Debugging-Kram vermutlich auch ausgestellt. Während du noch am Hacki arbeitest und er nicht so clean wie möglich aussehen soll, solltest du unbedingt mit verbose-Output booten, damit du siehst, was der Hacki macht und wo es klemmt. Ohne das hast du keine Chance. Es gibt in dieser Richtung auch noch ein paar weitere Einstellungen, die man vornehmen sollte, die das Debugging erleichtern, man kann zB deaktivieren, dass der Rechner bei einem Problem direkt neustartet und kann einstellen, dass bei einem Fehler noch weitere Infos ausgegeben werden, sodass hoffentlich ein paar weiße Zeichen auf schwarzem Hintergrund stehenbleiben, die etwas über das Problem verraten. Der Dortania-Guide nennt all diese Einstellungen.
Dann solltest du dein EFI so clean wie möglich gestalten und nichts verwenden, was für deine Hardware nicht nötig ist. Betrifft im vorliegenden Fall wohl hauptsächlich den AMD-GPU-Kram wenn die restliche Hardware gleich ist.

So sollte der nächste Bootversuch hoffentlich funktionieren, und wenn nicht, hast du hoffentlich eine Ausgabe die etwas über das Problem verrät. Im Guide sind auch ein paar der typischsten Fehlermeldungen, die beim ersten Booten so auftreten können, gelistet und ihre Ursachen und Lösungsansätze beschrieben.

Zum RAM: Ich denke das ist normal. Ich glaube der meiste RAM läuft mit 2667MHz Basistakt. Wenn die Riegel mit höheren Taktraten und XMP verkauft werden, bedeutet das, dass der Hersteller zusichert wie weit sich der Riegel übertakten lässt und mit dem XMP gleich das passende Übertaktungsprofil mit den richtigen Parametern mitliefert. Wenn also der tatsächliche Takt mit 3600 angezeigt wird und später MacOS auch 3600 anzeigt, ist alles ok.

Wie hoch der RAM maximal beim 10900K takten kann, weiß ich nicht genau, 3200MHz sind auf jeden Fall möglich. Würde mich wundern, wenn 3600MHz nicht auch gingen, Z490 ist ja schließlich der High-End-Chipsatz. Bei H410 und B460 ist schon unter 3000MHz Schluss, das hat Intel abgeriegelt.