Beiträge von traeu

Zitat von kuckkuck

Ja, du kannst ja mal beide Wege durchlaufen und dann vergleichen, das Ergebnis ist ein anderes.

Auch wenn ich keinen direkten Unterschied spüre, hat es dennoch geklappt, auch die iMacPro1,1-Plist als Basis zu nehmen. Werde jetzt einfach diese CPU-Daten nehmen! Sollte ja theoretisch am besten zu meiner CPU und meinem SMBIOS passen.

Zitat von traeu

Wenn ich dann der Anleitung weiter folge, trotz dass ich die Maximalfrequenz nicht anpassen kann, und am Ende CPUFriend und die erhaltene SSDT-data aktiviere, wird X86PlatformPlugin nicht mehr geladen, in den Energieeinstellungen sind zwei getrennte Slider und die Powernap-Funktion ist nicht mehr da.

Das hier war also völliger Unsinn, es hätte wunderbar funktioniert, wenn ich den CPU-Namen angepasst hätte...

Ich habe wohl zu recht den Fehler damals schon bei mir vermutet

Zitat von kuckkuck

Der Grund ist, dass deine alte SSDT _SB.PR00 anspricht, während die generierte _PR.PR00 anspricht. Der Pfad zur CPU0 ist also in der generierten falsch, was häufig passiert.

oh Mann, ein bisschen peinlich....jetzt, wo du es gesagt hast, sehe ich es natürlich auch! Aber da wäre ich irgendwie nicht von alleine draufgekommen...probiere ich direkt aus wenn ich wieder bei der Kiste bin!

Danke für diesen Tipp

Zitat von schmalen

traeu mit was und wie hast du diese abgewandelt, könntest du die entsprechende SSDT die nun läuft mal reinstellen?

Ich habe nur in der Plist die Maximalfrequenz an meine CPU angepasst (bei iMac20,2 von 4500 auf 5000), dann noch (persönliche Preferenz) UnifiedSleepSlider auf NO gesetzt und dann die Zeichenkette bei Frequency Vector in einen Hex Editor kopiert und wie beschrieben die drei Werte Minimalfrequenz (auf 800), EPP (auf 0x40) und EPB (auf 4) angepasst.

Meine eigene Plist anhängen sollte jetzt nicht mehr nötig sein, ich erwarte dass es auch mit der generierten direkt geht, wenn ich den von Kuckkuck gefundenen Fehler behebe indem ich den CPU Namen anpasse. (EDIT: Ja, wie soll es anders sein: Mit geändertem CPU-Namen funktioniert es auch mit der generierten SSDT!)

Die einzige Frage die ich jetzt noch habe (die aber eigentlich gar nicht mehr relevant ist): Unterscheidet sich das Ergebnis des Ressource Converter Scripts, je nachdem ob man direkt die zur CPU passende Plist nimmt oder man erst FreqVectorsEdit verwendet?

kuckkuck vielen Dank für deine ausführliche Antwort! Mit deiner Hilfe habe ich es geschafft, es zum laufen zu bringen. Also, ganz sicher bin ich mir noch nicht, ob alles gut so ist; ich hoffe, das kann noch jemand beurteilen der sich besser damit auskennt.

Was ich gemacht habe:
-Die Plist von iMac20,2 kopiert und entsprechend abgewandelt

-Mit dem Konverter-Script die SSDT erstellt

-aktuelle SSDT-PLUG deaktiviert, neu erstellte SSDT aktiviert, CPUFriend.kext aktiviert

--> Plugin Type 1 wird nicht eingestellt, die Powernap-Option ist wieder verschwunden und X86PlatformPlugin lädt nicht...menno!

Dann nochmal einen Schritt zurück: Mit der alten SSDT-PLUG wurde Plugin Type 1 geladen, mit der neuen SSDT nicht mehr...also habe ich angefangen zu vergleichen: Irgendwie sieht es in beiden SSDTs ähnlich aus an der Stelle, wo Plugin Type 1 geladen werden soll, aber nicht gleich...meine alte SSDT-PLUG band auch noch die SSDT-DTGP ein, die neue mit dem Konverter-Script generierte nicht mehr...also irgendwie unterscheiden sich die Methoden! Dann habe ich einfach mal ins Blaue hinein versucht, die bisherige SSDT-PLUG, die ja funktionierte, mit den Frequenz-Daten aus der neu erzeugten SSDT zu erweitern.

Und dann klappte es! Man sieht am Verlauf der Taktraten deutlich, dass die CPU nicht mehr grundlos hochaktet und der Verlauf ruhiger geworden ist (beide Screenshots wurden im IDLE aufgenommen). Ich sehe auch in IORegistryExplorer, dass X86PlatformPlugin wieder geladen ist und dort sehe ich auch, dass die Frequenzinfos geladen sind.

Jetzt aber meine große Frage:
Wieso funktioniert Plugin Type 1 nicht bei der SSDT, die das Konverter-Script erzeugt? Kann sich das jemand erklären, der sich mit diesen ACPI-Sachen besser auskennt als ich?

Und vor allem: Ist das in Ordnung so und "sauber" eingebaut?

Kleine Ergänzung zu meinem Beitrag #299, in dem ich eigentlich beschlossen hatte, den Thunderbolt-Chip original zu lassen und nicht mehr anzufassen.

Ich habe inzwischen die Soundkarte bekommen, eine UAD Apollo Twin X Duo mit TB3. Da ist mir aufgefallen, dass sie nicht hotplugfähig ist, sondern nur erkannt wird, wenn sie vor dem Booten den Rechners eingeschaltet wird.

Mit der veränderten Firmware klappt Hotplug mit der Soundkarte problemlos.

Ob das nur diese Soundkarte betrifft oder auch andere Thunderbolt-Geräte kann ich leider nicht testen, habe nur dieses Gerät.

Deshalb wird jetzt final doch die gepatchte TB-Firmware verwendet: Leicht längere Bootzeit und kein USB3-Hotplug an den USBC-Ports kann man in Kauf nehmen, wenn dafür die Soundkarte zuverlässig läuft und man bei Verbindungsabbruch den Rechner nicht neu starten muss!

kuckkuck & Inspector42 danke für die Antworten!
Ich möchte nicht ausschließen, dass ich aktuell noch einen gewaltigen Denkfehler mache und es noch nicht erkannt habe. Deshalb hier nochmal genau, was ich versucht habe und bei was ich gescheitert bin:

-Vorab: Ich nutze eben das SMBIOS iMacPro1,1
-Habe den Kext auf den Schreibtisch kopiert, um es mit der neuen FreqVectorsEdit-Version von Inspector42 zu bearbeiten

-Habe vor der Verwendung von FreqVectorsEdit mir mal die originale Plist von Mac-7BA5B2D9E42DDD94 (also iMacPro1,1) angeschaut: Dort gibt es keine verschiedenen Frequencies, aber dennoch ist ein Vector hinterlegt
-Habe dann FreqVectorsEdit mit der -k Option gestartet und auf meinen Schreibtisch gezeigt, damit die dort abgelegte Kopie vom Kext bearbeitet wird
-Dann in FreqectorsEdit den Eintrag "Mac-AF89B6D9451A490B" gewählt (iMac20,2) und FreqVectosEdit seine Arbeit machen lassen

-In den Kext reingeschaut: FreqVectorsEdit hat nun die Plist von Mac-7BA5B2D9E42DDD94 (iMacPro1,1) bearbeitet, vermutlich mit den Infos von iMac20,2 gepatcht, weil ich das ja ausgewählt habe
-Die Plist hat aber nach dem patchen genau wie vor dem patchen keinen Frequencies-Eintrag, nur die binären Vector-Infos (habe einen Screenshot angehängt)

Wenn ich dann der Anleitung weiter folge, trotz dass ich die Maximalfrequenz nicht anpassen kann, und am Ende CPUFriend und die erhaltene SSDT-data aktiviere, wird X86PlatformPlugin nicht mehr geladen, in den Energieeinstellungen sind zwei getrennte Slider und die Powernap-Funktion ist nicht mehr da.

Habe ich also irgendwo einen groben Denkfehler, oder ist die Vorgehensweise eigentlich so korrekt? Eigentlich müsste doch jeder, der diese Anleitung ausprobiert und wie ich das iMacPro1,1 SMBIOS verwendet, auf das Problem gestoßen sein, dass in der zum iMacPro1,1 gehörenden Plist keine Frequencies-Einträge sind...deshalb suche ich den Fehler noch bei mir.

EDIT: Ja, der Fehler lag bei mir...hätte ich Pfad und Namen der CPU in der generierten SSDT angepasst, hätte alles wunderbar funktioniert!

Zitat von kuckkuck

Wenn der Eintrag nicht vorhanden ist, ist primär die Frage, ob in der Plist überhaupt FrequencyVectors hinterlegt sind. offline

Ja, Vectors sind defintiv in der iMacPro1,1 Plist hinterlegt, nur eben keine Liste mit Maximalfrequenzen...

Zitat von kuckkuck

Wenn du das PowerManagement des iMac20,2 nutzen willst, musst du doch die Plist des iMac20,2 durch FreqVecs bearbeiten lassen, eventuell noch selber manuell anpassen und dann durch CPUFriend injecten lassen. Da ist doch egal was in der Plist des iMacPro1,1 steht, denn die wird ja dann durch CPUFriend im Speicher überschrieben.

Meinst du, ich muss die originale iMac20,2 Plist bearbeiten lassen? Also dass am Ende die original iMac20,2-Plist verändert wurde?

FreqVectorsEdit scheint, wenn man keine weiteren Parameter angibt, immer die Plist von dem SMBIOS zu bearbeiten, das man gerade gebootet hat, und diese dann mit Infos von jener Plist abzuändern, die man im FeqVectorsEdit-Menü angegeben hat.

(also iMacPro1,1 gebootet und im Menü iMac20,2 ausgewählt: Die iMacPro1,1-Plist wird mit Infos aus der iMac20,2-Plist abgeändert)
Wenn am Ende die originale iMac20,2-Plist verändert sein muss: Muss dann die iMac20,2-Plist mit Infos von iMac20,2 (was ich ja im Menü auswähle) gepatcht werden? Das klingt für mich nicht wirklich logisch...
Wenn am Ende die originale iMacPro1,1-Plist verändert sein muss: Dann macht es ja doch einen Unterschied, welche Plist man aktuell verwendet und was da vor dem patchen drinsteht, denn wenn vor dem patchen keine Frequencies-Einträge da waren, sind danach auch keine da, und dann kann ich sie auch nicht auf meine eigene Maximalfrequenz anpassen

Zitat von Inspector42

Das Script überschreibet mit -b und der board-id vom iMac19,1 genau diese plist mit den Inhalten der Konfiguration, die Du aus der langen Liste mittels Eingabe der Nummer eingegeben hast.

Wenn Du dann aber mit der iMacPro1,1-plist für CPUFriend weitermachst, verwendest Du die unveränderte Original-plist aus der kext.

Das habe ich nicht gut erklärt: Ich habe natürlich, als ich das Tool ohne Parameter verwendet habe, die iMacPro1,1-Plist weiterverwendet. Als ich es dann eben mal testweise mit -b und der iMac19,1-ID probiert habe, habe ich danach die iMac19,1-Plist weiterverwendet. Also immer die, die verändert wurde, das sieht man ja gut am Änderungsdatum.
Das mit dem -b habe ich nur ausprobiert, weil ich sehen wollte, ob es egal ist, welche Plist man als Basis nimmt und ob es nur um den Vector-Eintrag geht oder auch um das Drumherum. Da ich aber verschiedene SSDT-data mit deutlich verschiedenen Größen erhalte, wenn einmal iMacPro1,1 und einmal iMac19,1 als Basis für die gleichen Patches (beide Male iMac20,2 ausgewählt und LFM, EPP & EPB gleich) gewählt wird, weiß ich jetzt, dass es nicht nur auf den Vector-Eintrag der zur Maximalfrequenz passt ankommt, sondern auch auf die Plist, die als Basis verwendet wurde.

Nachdem ich nochmal recherchiert habe und herausfand, dass iMac20,2-Geräte nur 10th Gen i7 oder i9 sein können, wollte ich nochmal probieren, das CPU-Management an meinen i9 10900K anzupassen.

Dabei bin ich auf ein Problem gestoßen und ich komme nicht weiter:
Ich nutze das SMBIOS iMacPro1,1, Board ID Mac-7BA5B2D9E42DDD94, und wollte als Basis fürs CPU-Management iMac20,2 verwenden.

Die zu meinem SMBIOS gehörende Plist vom iMacPro1,1, die ja durch FreqVectorsEdit bearbeitet wird (habe die Variante von Inspector42 gewählt und nutze eine Kopie des Kext auf dem Desktop), hat keinen "Frequencies" Eintrag, er scheint komplett zu fehlen. Dementsprechend kann ich folgenden Punkt der Anleitung nicht ausführen und weiß nicht, ob und wie wichtig das ist:

Zitat von kuckkuck

Unter Frequencies steht ein Eintrag mit genau der Maximalfrequenz unserer installierten CPU. Wenn nicht, passen wir den nähesten Eintrag auf unseren MaxClock an und merken uns den Index.

Kann ich diese Methode trotzdem irgendwie mit dem SMBIOS iMacPro1,1 nutzen?

Wie wichtig ist es, dort die passende Maximalfrequenz stehen zu haben, bzw. was bedeutet es, wenn dort einfach gar kein Eintrag vorhanden ist?

Edit: Habe noch ein bisschen rumgespielt, aber wirklich schauer bin ich nicht geworden. Ich habe die Prozedur zwei Mal gemacht, einmal mit Standardeinstellungen, also dass FreqVectorsEdit mein SMBIOS iMacPro1,1 als Basis nimmt, und einmal mit dem Parameter -b und der Board-ID vom iMac19,1. Beide Male iMac20,2 bzw. dessen Board-ID in der Liste in FreqVectorsEdit ausgewählt. In den Plists habe ich die gleichen Anpassungen vorgenommen und mit dem Ergebnis dann mit dem Ressource Converter von CPU Friend die .dsl Dateien erstellt. Dabei fällt mir auf, dass sich die dsl-Dateien wesentlich in der Größe unterscheiden. Die Plist mit iMac19,1-Basis erzeugt die größere dsl-Datei (ca. 3x so groß, enthält auch 3 verschiedene Vektoren statt nur einem beim iMacPro1,1).

Ich dachte, man nimmt diese Methode, um unabhängig vom genutzten SMBIOS ein zur CPU passenderes Management zu erhalten. Jetzt bin ich mir unsicher, inwiefern sich das aktuell gewählte und dann wohl auch als Basis in FreqVectorsEdit verwendete SMBIOS auf das Endergebnis auswirkt und was passiert, wenn in einer Plist wie beim iMacPro1,1 die Einträge mit der Maximalfrequenz fehlen.

Inspector42 danke für die Erklärung! Da es bisher nur einen einzigen Frequenz-Eintrag in der iMac20,1 bzw. iMac20,2 Plist gibt, denke ich, dass es am wahrscheinlichsten ist, dass die Einträge noch nachgeliefert werden und die aktuellen iMacs tatsächlich mit angepasstem OS ausgeliefert werden (an die Möglichkeit hatte ich gar nicht gedacht...)

Wenn für die 10. Generation wirklich nur ein einziger Eintrag für alle CPUs ausreichend wäre, würde das doch bedeuten, dass es eine größere Änderung gegeben hätte oder? Bisher schien es ja doch wichtig zu sein, die richtige Maximalfrequenz und ein möglichst ähnliches CPU-Modell zu wählen...
Ich werde auf jeden Fall nach jedem Update in die Dateien schauen, dann werde ich ja schon sehen, ob und wann sich noch was ändert!

kuckkuck aber es ist denkbar und plausibel, dass Apple für die neuen Prozessoren die Infos noch nicht eingebaut hat?

Denn der neue iMac mit 10th Gen i9 wird ja schon verkauft...

Aber gut, wenn bei den 2019er iMac Plists passende Frequenzen zu allen verfügbaren CPUs eingetragen sind und bei den 2020er Modellen nicht, muss es wohl so sein, dass da noch etwas fehlt!

Vielen Dank für diese ausführliche Anleitung!

Habe mich eben daran versucht, aber ich komme leider schon bei der Wahl des Macs nicht weiter...

Ich habe einen i9 10900K, mein Boost-Takt ist 5GHz.

Müsste also nicht iMac20,2 (Mac-AF89B6D9451A490B) bzw. iMac20,1 (Mac-CFF7D910A743CAAF) perfekt sein, da es diese Modelle mit i9 10910K gibt und die auch mit 5GHz angegeben sind? Ich finde in den entsprechenden Plists leider nur jeweils einen Eintrag bei "Frequencies", 4500. Ist da der i9 (noch) nicht berücksichtigt? Oder habe ich einen Denkfehler? Probiert habe ich es mit dem aktuellen 10.15.6 19G2021.

SchmockLord

Ich habe gestern nochmal den SOIC Clip rausgekramt und die originale Firmware auf den TB-Chip zurückgeflasht. Das Ergebnis ist eindeutig, es muss irgendeinen Fehler bzw. eine Inkompatibilität bei der gepatchten TB-FW bzw. zwischen der FW und dem SSDT geben. Mit der originalen TB-FW habe ich Hotplug, egal ob ich dein EFI verwende oder exakt das, was ich auch für den gepatchen TB-Controller verwendet habe. Mit der gepatchten Firmware kriege ich kein Hotplug, egal ob mit 1:1 deinem EFI oder mit meinem. Dabei ist es auch egal, ob ich die USB-Ports per SSDT+USBInjectAll oder mit Hackintools USBPorts.kext einbinde.

Weitere Nebenwirkung, die ich bei der gepatchten FW bemerkt habe (im Nachhinein erscheint die Ursache logisch): Der Boot hing bei gepatchter FW immer über 5 Sekunden an einer Zeile mit irgendwas USB-betreffendes (je nachdem ob ich USB-SSDT+UIA oder USBorts.kext verwendet habe, war der Fehler ein anderer, aber immer etwas mit USB). Jetzt wieder mit original-FW bootet MacOS 7 Sekunden schneller (17 statt 25) und bleibt bei keiner Zeile mehr länger stehen.

So bleibt wohl festzuhalten, dass die gepatchte Firmware Nebenwirkungen hat, die so nicht kommuniziert werden. Mal sehen, ob ich dazu eine Antwort bei Tom Ate erhalte oder ob das Problem dort sogar schon bekannt ist und verschwiegen wird...

Ich werde mal abwarten, bis ich die TB3-Soundkarte, die damit verwendet werden soll, in den Händen halte und erstmal sehen, ob sie auch mit der originalen Firmware läuft. Ursprünglich dachte ich, es kann nicht schaden, weil gepatchte FW=näher am original-Mac, aber unter diesen Umständen sollte man wohl erst prüfen, ob man alles Benötigte auch mit original-FW zum Laufen kriegt.

Edit: CaseySJ hat geantwortet, dass USBC-Hotplug bei Gigabyte Z490 derzeit nicht funktioniert, weder bei internen, noch bei PCIe-Thunderbolt-Karten. Auf Z390 ist es möglich und evtl. wird auch noch eine Lösung für Z490 gefunden.

-->Werde also definitiv versuchen, mit der originalen FW klarzukommen und nur zur Not auf die gepatchte ausweichen, und ansonsten mal beobachten wie die Tomaten zukünftig reifen!

Zitat von SchmockLord

Aber was mir auffällt: GPIO3-Force Power steht bei dir auf Disabled, sollte aber auf Enabled. Und Security Level steht auf User Authorization, soll aber auf No Security.

Ja ich weiß, ich meinte ja, dass ich das Board vor den Fotos extra resettet habe (hatte Sorge, dass durchs Übernehmen des BIOS-Profils von meinem ersten Board evtl. Einstellungen nicht mehr sichtbar sind) normalerweise sind die Settings so wie von dir beschrieben!

SchmockLord

habe mal Bilder meiner TB & USB-BIOS-Einstellungen gemacht und angehängt (hab das Board zur Sicherheit davor resettet, deshalb sind die Einstellungen falsch, geht nur um die Menüpunkte). Zu USB sehe ich bei TB nichts. Nicht dass da mein Board einen Fehler hat? Seit dem ersten defekten bin ich etwas misstrauisch...

Werde heute Abend aber trotzdem nochmal an sie Sache rangehen und dein EFI + original-TB-FW testen!

no_Legend

Klingt für mich auch eher so, als würde die Maus irgendetwas unnötiges über USB senden, was der Rechner dann fälschlicherweise als Mausbewegung oder so interpretiert.

Wenn du dieses Modell weiter nutzen willst, bleibt dir wohl nur, das Aufwecken per USB zu deaktivieren, dann kann man ihn halt nur noch per Powerknopf wecken wenn er eingeschlafen ist.

SchmockLord

Genau so einen Kartenleser habe ich auch, er wird per Hotplug nicht erkannt.
Ich habe deine Config nicht 1:1 übernommen, aber jetzt wo ich weiß, dass es grundsätzlich gehen sollte, weiß ich dass es sich lohnt, nochmal Zeit zu investieren! Ich habe die gepatchte Firmware installiert, nutze dafür die TB-SSDT von hackindrom.zapto.org und habe meine USB-SSDT leicht angepasst, weil ich den internen USBC-Header nicht brauche.

Werde jetzt schrittweise alles rückgängig machen, mal mit exakt deinem EFI testen und ggf. die Original-FW auf den TB-Chip zurückflashen.

Im BIOS gibts ja soweit ich das gesehen habe keine Einstellungen, die die USB-Funktion der TB-Ports betreffen...

Danke für die Infos, ich werde berichten ob ich Erfolg hatte!

Ich habe auf jeden Fall noch ein zwei Stellen die zwicken, aber Standby ist keine davon! Ohne große Konfiguration (eigentlich nur der WakeFixup und WoL und Powernap deaktiviert) schläft die Kiste zuverlässig ein und wacht auch 8h später noch zuverlässig beim ersten Tastendruck auf und hat noch alle USB-Sticks gemounted, nichts im Schlaf ausgeworfen...

Du hattest ja ursprünglich mal von Darkwake 8 geschrieben, aber in der Richtung war bei mir nichts notwendig.

Das Aufwachen dauert zwar noch relativ lange, aber das geht klar, bis ich irgendwann mal auf etwas stoße, was das verbessern könnte!

Edit 25.08.20

SchmockLord eine Frage hätte ich noch an dich: Funktioniert bei dir Hotplug von USB3-Geräten an den USB-C/TB-Ports? USB2-Geräte werden bei mir sofort eingehängt, aber USB3-Geräte werden nur erkannt, wenn sie vor dem Boot angeschlossen wurden. Ein Thunderbolt-Gerät konnte ich noch nicht testen.

Ich habe die veränderte Firmware von CaseySJ auf den TB-Chip geflasht und verwende das DROM-SSDT von hackindrom.zapto.org. Da in diesem SSDT der USB3.1 Controller "XHC3" genannt wird (statt wie in deinem "XHC5") habe ich das entsprechend in meiner USB-SSDT angepasst.

Was ich dazu noch beobachtet habe:
-Der Rechner schläft nicht mehr ein, wenn ich ein USB3-Gerät an einen der USB-C-Ports stecke und trotz fehlender Erkennung stecken lasse

-In den System Infos unter PCI sehe ich den USB3.1-Controller, Treiber installiert steht meistens auf "Ja". Ich habe aber auch schon beobachtet, dass dort selten nach einem Neustart auch "Nein" steht, aber nach einem weiteren Neustart oder einem Start mit angeschlossenem USB3-Gerät steht es wieder auf "Ja".

Funktioniert Hotplug auf diesen Ports bei dir mit USB3-Geräten? Möglicherweise liegts an der geflashten Firmware, falls es bei dir funktionieren sollte...nur bevor ich den Clip wieder auspacke und die alte Firmware testweise zurückspiele, würde ich gerne mal hören ob das bei dir (und natürlich auch bei allen anderen Vision D Besitzern) funktioniert!

no_Legend ich saß gestern Nacht an der gleichen Thematik: Der acpi-wake-type Eintrag ist wohl ein Überbleibsel vom Versuch, den Rechner bzw. den Bildschirm beim ersten Tastendruck aufzuwecken (es gibt da einen Fehler, wo der PC sonst zwei Tastendrücke braucht bis der Bildschirm angeht). Der acpi-wake-type-Eintrag ist die empfohlene Methode, funktioniert aber leider bei mir auf dem Vision D Board nicht. Stattdessen funktioniert die zweite Variante, mit USBWakeFixup.kext und SSDT-USBW, die ja auch in Schmocklords EFI enthalten sind.

https://dortania.github.io/OpenCore-Post-Install/usb/misc/keyboard.html#method-1-add-wake-type-property-recommended

Mit

pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

kann man schauen, wann der Rechner schlafen gegangen ist und wann er aufgewacht ist und wieso, vielleicht liefert dir das einen Hinweis, wieso er immer wieder aufwacht. Auch dazu gibts ne kleine Sektion mit Beschreibungen bei Dortania:
https://dortania.github.io/Ope…sb/misc/instant-wake.html

Vielen Dank für die Tipps!

Ich habe das Board/CMOS einmal komplett zurückgesetzt und die Grafikkarte ausgebaut. Die Bootzeit (Ergänzung: Habe ohne OS, nur bis ins BIOS getestet) ist leider immer noch fast genau so lange, 27 Sekunden. Und auch da leuchtet die VGA-LED noch 20 Sekunden lang und davon steht 16 Sekunden lang die "80" auf der Segmentanzeige.

Jetzt kann es nur noch am Mainboard, dem RAM oder der CPU liegen...

Da ich keinen passenden RAM oder eine andere CPU zum testen zur Verfügung habe, werde ich wohl das Mainboard als wahrscheinlichste Fehlerquelle zurücksenden.

Falls jemand ohne Mühe seine Segmentanzeige im Blick hat: Ist die "80" bei euch ein Code wie viele andere, der nur schnell durchblinkt, ohne dass sich das Board an der Stelle länger aufhält?

Hallo! Ich bin seit kurzem auch Besitzer des Vision D Boards mit i9 10900K und RX 5700XT Red Dragon und wundere mich etwas über die Boot/POST-Zeit bzw. frage mich, ob die so normal ist.

Zwischen Einschalten und dem BIOS-Screen bzw. Opencore vergehen bei mir 32 Sekunden.

Dazu kann ich sehen:

-Die "VGA" LED leuchtet von den 32 Sekunden 23 Sekunden lang

-Die Segmentanzeige auf dem Board zeigt 15 Sekunden lang "80" an, während die VGA-LED leuchtet

Die Codes 80-8F sind "OEM Reserved" , also wohl eine Sackgasse...
Die VGA-LED scheint etwas mit der GPU zu tun zu haben. Ich habe die iGPU im BIOS deaktiviert und verwende nur die RX 5700XT.

Sind die Boot/POST-Zeiten bis zum BIOS bei euch unauffällig? Oder ist die von mir gestoppte Zeit im Rahmen und normal? Sollte ich über einen GPU-Tausch nachdenken, solange die 14 Tage-Frist noch nicht abgelaufen ist?

Ach ja, vielleicht noch erwähnenswert: Ich habe den Thunderbolt-Chip geflasht, falls das einen Unterschied machen könnte.

Falls jemand einen Hinweis zur Audioausgabe der R9 390 hat, wäre ich weiterhin sehr dankbar! Betreibt vielleicht jemand von euch diese GPU problemlos mit Audioausgabe, und wenn ja, wie wurde sie eingebunden und wie sieht die restliche Hardware drum herum aus?

Und falls ich mich beim Erstellen des Threads ungeschickt angestellt habe, freue ich mich auch da über Hinweise, was ich besser machen kann

Hallo! Vorneweg: Das ist mein erster Post hier (mein erster Post in einem Forum überhaupt), falls etwas nicht passt bitte Bescheid geben und falls das Unterforum falsch ist, bitte verschieben!

Seit letztem Jahr bin ich dabei, meinen 2016 gebauten PC zum Hackintosh zu erweitern. Davor hatte ich keinerlei Erfahrung mit Hackintosh, nur MacOS kenne ich schon seit 2010 durch mein treues Macbook. Mittlerweile habe ich (fast) alles zum laufen gebracht. Deshalb möchte ich hier meine Kiste vorstellen und euch um Rat fragen: Ich bin mir sicher, dass es noch die ein oder andere Verbessung gibt!

Zum Aufbau:
-Mainboard: Asus Maximus VIII Hero
-CPU: i5 6600K

-RAM: 16 GB
-GPU: AMD Radeon R9 390, 4K TV (HDMI) per Adapter an DisplayPort 1

-WLAN/BT: Fenvi T919

-Bootloader: Clover 5109

-MacOS 10.5.4 auf M2 SSD

-Partition für Beta-Installationen im selben APFS-Container wie das Haupt-OS, momentan auch auf 10.5.4

-Windows 10 auf separater SATA-SSD

Ich habe letztes Jahr mit Mojave angefangen und bin mittlerweile problemlos durch Updates auf der aktuellsten Catalina-Version. Mein aktuelles EFI sollte also für 10.4 und 10.5 funktionieren. Gestartet habe ich damals mit dem Tony, dem ich dann aber recht schnell den Rücken zugekehrt habe, weil ich selbst verstehen wollte, was da alles so passiert. War nach einigen Stunden lesen doch eine große Erleuchtung, als der Grundaufbau logisch und keine Magie mehr war und feststand, dass die Beasts auch nur mit Wasser kochen. Mein Systempartition sollte mittlerweile Vanilla sein und die Grundconfig weitestgehend dem Vanilla-Guide folgen.

-Kexte: VirtualSMC+Addons, Lilu, WEG, AppleALC, USBInjectAll, IntelMausi

-Driver: APFSDriverLoader, AptioMemoryFix, VBoxHFS, VirtualSMC.efi

-NVRAM: Läuft mit AptioMemoryFix ohne Weiteres
-CPU Power-Management: SSDT.aml erstellt mit ssdtPRGen
-GPU: Läuft mit Clover Device-Arbitrary-Patch. Wenn ich das richtig verstanden habe, wird sie dadurch als leicht anderes Modell erkannt und von den MacOS-eigenen Treibern eingebunden. WEG ist zusätzlich installiert: Der einzige sichtbare Unterschied für mich ist, dass mit WEG beim Booten über dem weißen Apfel keine lila Streifen auftreten. Im Betrieb habe ich keinen Unterschied gemerkt.

-USB: Läuft mit USBInjectAll, vorgefertigter SSDT-USB.aml für mein Mainboard und dem Deaktivieren ungenutzter interner USB-Ports per Bootargument
-WLAN/BT: Läuft nativ ohne jedes Zutun (für BT muss die Karte noch zusätzlich per USB angeschlossen werden)

-Audio: Codec (ALC1150) wird von AppleALC unterstützt, Layout 1 per Bootargument eingestellt

Was funktioniert:

-Clover: GUI in 4K

-Boot: 18sek von Clover zum Loginbildschirm (inkl. ca. 4sek Umschalten des TV auf 60Hz, während man trotz schwarzem Bild schon das Kennwort lostippen kann)

-Sleep: Nach dem Aufwachen geht soweit ich es mitbekommen habe noch alles (USB, Sound, Netzwerk)
-GPU: mit vollen 8GB RAM erkannt, 4K@60Hz Ausgabe über Displayport, Audio über DisplayPort

-USB: Alle äusseren und inneren USB2 und USB3 Ports funktionieren (bis auf die wegen des Portlimits deaktivierten)

-Audio: Mit AppleALC und Layout 1 funktionieren alle Ein- und Ausgänge (Frontblende Mikro & Kopfhörer, hinten 3x Stereo Out, Mikro, Line In), Audioausgabe per Displayport & Bluetooth

-Netzwerk: LAN & WLAN

-Themperatursensoren

-iMessage, iCloud

-TimeMachine Backups

-VMs in Virtualbox

Ungetestet:
-USBC-Port

-mehrere Bildschirme

-optischer Audioausgang (Laut Codec- und Layout-Doku von AppleALC unterstützt)

-Continuity/Handoff

Probleme:

-Lüftergeschwindigkeit wird in HWMonitor nicht mehr angezeigt, seit ich VirtualSMC einsetze. Funktionierte mit FakeSMC noch. Wollte aber dennoch etwas einsetzen, was noch aktiv weiterentwickelt wird.

-Die USB3-Geschwindigkeit der Ports vorne am Gehäuse ist komischerweise ziemlich niedrig. Die hinteren Ports liefern im Benchmark plausiblere Werte. Unter Windows 10 ist die Geschwindigkeit der Ports vorne und hinten gleich. Kann ich mir wirklich nicht erklären! Den einzigen Unterschied, den ich sehe, ist, dass die Ports vorne quasi interne Ports auf dem Mainboard sind und die hinteren externe.

-GPU Intel HD530: Mein größtes Luxusproblem. Ich brauche sie überhaupt nicht, aber am liebsten wäre mir natürlich, sie wäre korrekt eingebunden. Aktuell sollte sie nach meinem Wissen headless eingebunden sein. Sie taucht aber im Systembericht überhaupt nicht auf. Ich hatte auch schon versucht, sie "normal"/nicht headless einzubinden. Dann verlängerte sich die Bootzeit auf das doppelte und beim Versuch, ein Display an den Port der internen GPU anzuschließen, fror der PC ein. EDIT: Mir fällt gerade ein, dass die interne GPU möglicherweise noch im BIOS deaktiviert ist. Muss ich morgen unbedingt prüfen! Vielleicht für das zusammen mit einem Hinweis zur korrekten Konfiguration ja zum Erfolg.

-DisplayPort-Audio: "Kleines" Problem, hat aber für mich aktuell den größten Störfaktor: Die Audioausgabe über den DisplayPort (wo per HDMI-Adapter der TV angeschlossen ist) hat regelmäßig ganz kleine Aussetzer. Ca. alle 30sek bleibt der Ton für einen ganz kurzen Moment weg. Meistens läuft es nach dem Boot erstmal ein paar Minuten störungsfrei, aber dann setzen zuverlässig die Ruckler ein und gehen auch nicht mehr weg. Das Problem tritt auch auf, wenn WEG deaktiviert wird oder die GPU statt mit WEG und Arbitrary-Patch damit eingebunden wird, die Modellnummer der GPU direkt in den apple-eigenen AMD-Kexten zu ergänzen. Weitere Ideen für Tests hatte ich nicht.

Ich habe hier meinen Clover-Ordner angehängt, in dem sich auch noch ein Bootlog (mit Clover Configurator erstellt) und die Systeminformationen befinden. Seriennummern habe ich soweit ich sie gefunden habe unkenntlich gemacht. Vielleicht hilft es jemandem mit einem ähnlichen System weiter.

Ich würde mich sehr über Tipps zur Verbessung des Setups freuen! Besonders, wenn jemand einen Hinweis zu den Audiorucklern oder zur Intel GPU (habe gelesen, die HD530 sei etwas störrisch) hat.

Edit2: Kam endlich dazu, meine BIOS-Einstellungen zu prüfen: die interne Grafikkarte war aktiviert, daran kann es also leider nicht gelegen haben. Dann habe ich dazu erstmal keine Idee mehr und lebe erstmal damit, dass sie nicht korrekt eingebunden ist, bis ich über eine Lösung stolpere.