HowTo: Thunderbolt HotPlug/HotSwap Finetuning für euren Hackintosh

Das Board ist heute tatsächlich gekommen (hatte die Hoffnung schon fast aufgegeben, DHL hat sich da echt was geleistet – aber egal) und ich muss sagen, sooooo einfach war es mit dem Hacky noch nie.

Beim ersten Einschalten kam diese Nachricht:

Dann habe ich im BIOS lediglich den Stick mit der EFI von meinem Gigabyte Z370N ausgewählt (nix an der EFI verändert, ich schwör!) und das Teil war dann blitzartig unter 10.12.6 einsatzbereit. Keine spezielle BIOS Einstellungen geladen, alles so gelassen wie das Board geliefert wurde. Hat mich sehr beeindruckt.

Natürlich zeigt er in den Systeminformationen unter Thunderbolt nichts an. Das wäre jetzt wirklich die Härte gewesen, wenn das auf Anhieb geklappt hätte.

Bin jetzt etwas unschlüssig, wie ich am sinnvollsten weitermache. Wahrscheinlich erst mal die USB Situation checken, da liegt einiges im Argen, nirgendwo USB3, der USB-C Port reagiert auch noch nicht.

Oh – sorry, du hattest das womöglich als versteckte Kritik einsortiert. War keinesfalls so gemeint. Wenn ich TB3 nutzen will, ist die Anzeige in den Systeminformationen das letzte, was mir dabei wichtig erscheint. Alles ist gut.

Bin derzeit noch bei der Konfiguration der USB Ports. Der USB-C Port wird nicht erkannt (angesteckte Geräte werden nicht angezeigt), könnte das was mit dem aktivierten TB3 im BIOS zu tun haben? Meine BIOS Version ist oben im Bild, soll ich upgraden? Hier die Situation mit den Ports:

1. Geräte mit 480 Mbps:

2. Geräte mit 1.5 Mbps:

3. Geräte mit 5 Gbps:

Wie gesagt, wenn ich was bei USB-C einstöpsle, passiert nix. BIOS?

Aktivier mal USB über Thunderbolt, das ist ein Standart-Blocker..

Mork vom Ork

Erst mal dicken Respekt, das zum Thema zu machen. Kann allerdings nicht so ganz nachvollziehen, was nun an der SSDT neu sein soll. HotPlug funktioniert schon lange, habe auch einigen Leuten hier geholfen, dort funktioniert es ebenso. In deiner (Basis-) SSDT ist einiges drin, was noch raus kann. Um mal bei deiner SSDT zu bleiben:

In Zeile 23-27 wird auf externe Quellen verwiesen. Der Verweis auf XHC_ kann ersatzlos gestrichen werden, es gibt keinerlei weiteren Bezug in der SSDT darauf. Im Original werden hier in der Folge USB2 vom XHC geroutet, ist hier völlig unsinnig. Auch heißt je nach System dieses Device auch mal XHCI oder anders. Egal, es kommt auch gar nicht weiter vor in deiner SSDT. Der Aufruf einer externen Methode DTGP funktioniert natürlich auch nur, wenn sie denn wo anders schon enthalten ist, darauf sollte noch hingewiesen werden (inject per Clover in die DSDT, oder enthalten in einer weiteren SSDT). Der letzte Eintrag PXSX kann ebenso raus, ist dieser doch schon exakt mit Pfad weiter oben beschrieben worden.

Die Methode NTFY (Zeile 34) kann ersatzlos gestrichen werden, völlige Nebelkerze. Denn mit "Name (STA, Zero" blendest du das vorhandene Device "PXSX" aus, um für ein eigenes Device "UPSB" auf Adresse 0x0 (Zero) Platz zu schaffen, "Notify" wird also niemals ausgeführt.

Die _DSM Methoden habe ich mal um die unsinnige "if"-Schleife reduziert.

Beschreibung Definitionsblock "TbtOnPCH" finde ich auch nicht so elegant, denn diese SSDT sollte doch allgemeingültig sein. Also nicht nur auf irgendwelche RPxx vom PCH, sondern auch direkte PCIe der CPU zugeordnet.

Es bleibt also, wie in vielen anderen SSDTs zum Thema, zum einen der Pfad zum Device "NHI0" und einige wichtige Beschreibungen per _DSM-Methode eingefügt.

Deine Erkenntnis, dass der komplette Baum wie in der originalen Apple SSDT zu Problemen führt, ist richtig. Besser ist es allerdings, die Stamm-Devices DSBx noch aufzunehmen, denn hier können noch jeweils _DSM-Methoden hinzugefügt werden, die sich in der Kette vererben ("AAPL,slot-name"). Der Vorteil, nun werden auch die angeschlossenen Geräte in der PCI-Sektion (Systembericht) angezeigt! Weiterhin kann so auch der XHCI-Controller beschrieben werden. Habe ich mal integriert und "XHC5" genannt, damit dieser nicht namentlich mit eventuell weiteren XHCx-Controllern kollidiert.

Ich habe die überarbeitete SSDT mal im Anhang gesetzt (Pfade natürlich überarbeiten), teste es gern. Der Teil des Tutorials, welcher sich dem BIOS widmet, finde ich sehr spannend. Ich habe das Glück, ein BIOS zu haben welches alle relevanten Einstellungen zu Controller zulässt; dieses allen Boards zugänglich zu machen – noch mal dicken Respekt.

Zitat von Mork vom Ork

ResEdit

welches System fährst Du?

10.12.6, wie schon gesagt. Habe deinen Hinweis mit USB HS10 und SS10 zu spät gelesen. Den USB2 Header und den USB3 Port auf dem MoBo habe ich im BIOS deaktiviert, dann die nicht genutzten Ports mit uia_exclude=HS01;HS02;HS07;HS10;HS11;HS12;HS13;HS14;SS05;SS06;SS09;SS10;USR1;USR2 ausgeklammert. Das sieht dann jetzt so aus:

Mehr USB brauche ich auch nicht. Habe dann eine Plugable Docking Station UD-CAM (ASIN B078WXTYTW) mit TB3 Kabel (!) am TB3 Port angeschlossen und siehe da: Die dort integrierte Soundkarte wird als USB-Tonausgabegerät erkannt, das darin befindliche USB-Netzwerk-Interface (10/100/1000 RJ45) ebenfalls. Auch die HDMI Schnittstelle wird erkannt, habe jedoch (bisher) kein Dual-Monitor Setup erfolgreich testen können. Immerhin wird das USB-Protokoll über TB3 weitergereicht, obwohl ich HS10 und SS10 "unsichtbar" konfiguriert habe.

Bin echt erstaunt, wie locker sich das bislang alles gemacht hat, im BIOS habe ich lediglich die nervigen LED-Lichtorgeln des MoBos deaktiviert und die iGPU als Standard gesetzt. Sonst wie gesagt NULL Konfiguration im BIOS vorgenommen.

Edit: Sorry, hatte ich vergessen: Onboard BT und WLAN habe ich ebenfalls deaktiviert im BIOS. Brauche ich beides nicht.

Zitat von Mork vom Ork

Letztlich habe ich nicht getestet, ob es nun nur Dank der neuen BIOS Einstellungen funktioniert, oder ob auch die "NOTIFY"-Funktion ihren Teil dazu beiträgt.

Im Original https://osy.gitbook.io/hac-min…details/thunderbolt-3-fix wurde beschrieben, welche "_Exx" Funktion (Edge Triggered GPE) ein "Notify" für genau den benutzten Slot beinhaltet. Bei mir ist es "_E4C". Eine Methode Namens "NTFY" wurde ermittelt, diese wird in der DSDT benutzt. Entweder man editiert diese direkt in der DSDT, oder man versucht diese über Clovers DSDT-Patches durch Rename unbrauchbar zu machen. So sieht diese bei mir zum Beispiel aus:

Um dann in der Folge in einer eigenen SSDT die Funktion neu zu erschaffen, mit an geeigneter Stelle modifizierte Notify, die bis zum NHI0 reicht. Sinnvoll wäre es natürlich, auch die restlichen unbearbeiteten "Cases" wieder aufzunehmen. Das kann also je nach System ganz anders aussehen, hier war es ein NUC. Und wie gesagt, deine "NTFY" hängt an "PXSX", welches du gerade "unschädlich" gemacht hast. Wenn es wichtig wäre, wäre es besser im aktiven Strang "UPSB" aufgehoben. Noch besser jedoch das Original ausgetauscht unter "Scope (_GPE)".

Zitat von Mork vom Ork

Und mit dem ganzen UPSB/DSBx Wust hatte ich ja auch geschrieben, das ich es in der Tutorial-SSDT bewusst weggelassen habe, da ich dadurch in einem längeren, hintereinandergeschalteten Strang an TB-Devices das

Problem hatte, das ich die Kette dann nicht an jeder x-beliebigen Stelle unterbrechen konnte, ohne das mein Rechner umgehend einen Neustart gemacht hat. Habe ich die selbe Kette aber unter Nutzung der im Tutorial

besprochenen SSDT genutzt, konnte ich die Kette an jeder x-beliebigen Stelle trennen und ggf. neu stecken.

Das dadurch die bequeme Möglichkeit der Benennung der Devices mittels der _DSM-Methode verloren geht, habe ich zu Gunsten der Funktionalität ersteinmal in Kauf genommen.

Das habe ich ja verstanden und auch als richtig geschlussfolgert kommentiert. Nur ist es sinnvoll, (nicht den kompletten Strang!), sondern die ursprünglichen "DSBx" (nicht nur "DSB0") ebenfalls mit aufzunehmen (schaue doch dazu in meine überarbeitete Version). Es ändert sich somit nichts mit dem "Kettenproblem"! Aber da hier bereits nun schon eine _DSM-Methode gesetzt wird (mit dem Parameter "AAPL,slot-name"), wird dieser in der sich später aufbauenden Kette "vererbt". Es geht also gar nicht darum, eine lange Kette zu bauen und ein Gerät direkt per _DSM-Methode zu benennen, sondern dass das Gerät, unabhängig davon wie es heißt und ob der Hersteller es auch benannt hat, dass dieses Gerät eben in der PCI-Sektion des Systemberichts/Systeminformationen auftaucht. Denn hier ist es für den Nutzer sehr einfach einzusehen, ob überhaupt ein Treiber für dieses Gerät geladen wurde. Ansonsten tappt man da im Dunkeln. Kannst du gern ausprobieren. _DSM-Methode von z.B. "DSB1" entfernen, schon sieht man an diesem Strang in der PCI-Sektion keine Geräte mehr (die natürlich dennoch funktionieren).

Hast du meine überarbeitete SSDT mal ausprobiert? Ich möchte ja nur helfen, einerseits Dinge zu verschlanken, andererseits wichtige Dinge zu integrieren.

Kurze Frage, wieso eigentlich die ganzen _STA Funktionen? Tauchen die Geräte in den original Tables nicht auf oder sorgt im Original irgendeine _OSI Konstruktion für die Deaktivierung der Devices? Inwiefern sollten die Device bereitgestellt werden, wenn ein anderes OS als macOS bootet? Hier sollte man evtl. darüber nachdenken vorhandene _OSIs zu verändern oder die gesetzten _STAs mit _OSIs zu versehen um cross-platform Support zu gewährleisten, Treiber wie OpenCore nutzen ACPI Tabellen auch bei nicht-macOS boot. Sorry, besitze selber keinerlei betroffene Hardware, deswegen kann ich nicht selber reinschauen.

Zitat von DSM2

persönlich eine andere Lösung für Onboard Chipsets die aber recht komplex ist.

Würdest du die vielleicht mal hier kurz beschreiben? Dann können wir mal drüber schauen, ob sich das irgendwie vereinfachen/verallgemeinern lässt. Ich weiß nicht, ob du dabei mit ACPI arbeitest, aber wäre definitiv interessant. 4 (oder eher 32 ) Augen sehen mehr als 2

Zitat von kuckkuck

Kurze Frage, wieso eigentlich die ganzen _STA Funktionen? Tauchen die Geräte in den original Tables nicht auf

Nein, diese Devices gibt es nicht in der original ACPI. Siehst du schon allein daran, dass es als "Device" in der SSDT definiert ist, nicht "Scope" (also erweiterte Einträge eines vorhandenen Devices). Mit der Methode _STA wird der aktuelle Status abgefragt. Deaktivierung von z.B. PXSX erfolgt nicht direkt mit einer Methode, sondern ändern des Parameters "Name (_STA, Zero)". Somit wird der Weg frei für das neue Device "UPSB". Sonst würde alles an PXSX hängen, was grundsätzlich nun auch kein Problem wäre.

Jup, darauf hab ich nicht geachtet, mir war nicht bewusst inwiefern hier FW Settings die ACPI Tabellen beeinflussen und evtl. gesamte Devices streichen, wer weiß (obwohl, gibts sowas überhaupt?). Ich vermute mal die Devices stammen aus Apple-ACPI Dumps? Matcht der Treiber auf UPSB?

Mir ist bewusst wie _STA funktioniert, was ich sage ist, um es noch sauberer zu machen würde ich in diesem Fall noch _OSI Abfragen einbauen. Sprich:

Zumindest bei UPSB oder Untergeräten wie DSBx sollte das so möglich sein.

kuckkuck

Das würde doch reichen:

Wenn "Darwin", dann PXSX ausblenden und normal fortfahren. Bei allem anderen wird es nicht ausgeblendet, und der TB-Controller wird wie gehabt an PXSX angehängt. Der Rest der SSDT ist somit hinfällig …

Der Teil mit der offenen Else Funktion gefällt mir, dann kann die FW oder sonst ein OS hier noch komplett selbstständig walten solange Darwin nicht gecalled wird. Der wichtigste Teil ist damit getan.

Ob man den ganzen Rest mit aktivem Status anhängen will, wenn nicht macOS gebotet wird, ist ansichtssache. Da würde ich einfach noch für UPSB eine entsprechende if Konstruktion in die _STA Methode einbauen, macht ja keinen Sinn in diesem Fall weitere Devices einzubinden, die absolut ins Leere laufen und unbedingt aktiv sein wollen.

kuckkuck

Dann so

apfelnico Das klingt nach einer Idee!