USB mittels SSDT deklarieren

    • Hilfreich

    Zuerst schauen wir uns die vorhandene „ACPI“ (Advanced Configuration and Power Interface) an. Darin vornehmlich die „DSDT“ (Differentiated System Description Table) und eine SSDT (Secondary System Description Table) für USB. Gerne nutze ich dafür einen Stick mit dem Bootloader „Clover“. Selbst wenn ihr den Bootloader „OpenCore“ nutzt, ist ein solcher Clover-Stick durchaus sinnvoll. Der muss gar nicht das vorhandene macOS starten können, es reicht völlig, wenn das Clover-Menü erreicht wird. Hier die Taste „F4“ drücken, und schon werden in „EFI\CLOVER\ACPI\origin“ die originalen ACPI-Tabellen geschrieben. Das ist nur eine von vielen Varianten, wie ihr an eure unveränderten ACPI-Tabellen kommt

    Die einzelnen Dateien lassen sich mit (dem unten verlinkten) „maciASL“ einsehen und bearbeiten. In der „DSDT“ findet man zumeist nur eine rudimentäre Darstellung von „XHCI“ (welches auch „XHC“ und ähnlich genannt sein kann). Hier ein erster Eintrag dazu, hier wurde das „Device“ angelegt und mit einer Adresse versehen.



    Auch im (ebenfalls unten verlinkten) „IORegistryExplorer“ wird das Device „XHCI“ mit der gleichen Adresse angezeigt, wie in der DSDT festgelegt: „XHCI@14“.

    In der Folge in der DSDT wird „XHCI“ näher beschrieben, es werden Funktionen für Sleep und Wake nachgereicht und weitere Devices innerhalb von XHCI gebildet, wie „RHUB“ und die darin enthaltenen USB-Ports.



    Am Beispiel eines X299 Systems, hier das „Asus Prime X299-Deluxe“, werden wir die vorhandenen USB-Ports näher beschreiben. Der Chipsatz X299 stellt 26 USB-Ports bereit, wie ebenfalls viele andere moderne Intel Chipsätze, somit sollte diese Anleitung Allgemeingültigkeit besitzen. Alle diese Ports, ob nun physisch komplett vorhanden oder nicht, sind im „Grundgerüst“ der „DSDT“ angelegt. Diese lauten, wie wir schon teilweise auf den Screenshots gesehen haben:


    HS01 … HS14


    USR1, USR2


    SS01 … SS10


    „HS“ steht für „High Speed“, 480mbit/s, USB2 mit abwärtskompatiblen USB1

    „USR“ sind Platzhalter und werden nicht benutzt

    „SS“ steht für „Super Speed“, 5gbit/s, USB3


    Wie man hier in der „DSDT“ sieht, sind innerhalb der definierten 26 Ports keine weiteren Beschreibungen zu finden. Dazu schauen wir uns eine weitere „SSDT“ an. Fündig werden wir bei diesem System in der „SSDT-1-A M I“, hier sehen wir alle Ports von „XHCI“ näher beschrieben, zusätzlich noch drei USB3.1 von ASMedia, die uns vorerst nicht weiter interessieren.

    Ganz interessant ist in der SSDT oben im „Header“ die Information „Length“. Diese wird hier in diesem Beispiel mit „0x00000E7B (3707)“ angegeben. Wir haben nun folgendes vor: wir werden diese SSDT kopieren, für unsere Zwecke ändern und ergänzen und per Bootloader zum richtigen Zeitpunkt laden lassen. Dazu müssen wir aber den Bootlader veranlassen, die originale SSDT nicht zu laden, ansonsten würde unsere SSDT nicht mehr geladen werden. Am Beispiel von „OpenCore“ setzen wir in der „config.plist“ unter „ACPI\Delete“ folgenden Eintrag:



    Hier wird also unter „TableSignature“ mit dem Wert „53534454“ (Hexadezimal für den ASCII-String „SSDT“) und „TableLength“ mit dem von uns gefundenen Wert als Zahl „3707“ exakt unsere gewünschte SSDT ermittelt und „entfernt“ (nicht etwa aus dem BIOS gelöscht, sondern lediglich das Laden unterdrückt). Natürlich könnte man auch einfach über „OemTableID“ suchen lassen, aber hier schleichen sich gern mal Fehler ein. Gerade auch hier im Beispiel die „A M I “ hat noch ein Leerzeichen hinter dem „I“. Da ist die Angabe der Länge doch einfacher.


    In der „config.plist“ über „ACPI\Add“ können wir unsere modifizierte SSDT, die wir selbstverständlich auch umbenennen können, wieder einfügen.


    Schauen wir uns unsere SSDT nun genauer an. Wir finden hier Methoden für „USB Port Capabilities“ (Beschreibung von beispielsweise USB2, USB3, USB-C, intern …) und „Physical Location of Device“ (Beschreibung beispielsweise „hinten rechts“). Würden die Mainboardhersteller alles richtig machen, hätten wir hier kaum etwas zu tun, denn diese Standards(!) sind natürlich nicht Apple-spezifisch. Lediglich Apples „Port-Limit“ von 15 Ports je Controller ist für macOS spezifisch.


    Grundsätzlich sind die beiden Methoden „_UPC“ und „_PLD“ für uns und macOS ausreichend, leider nur allgemein und nicht detailliert genug beschrieben. Hier setzen wir also an.


    Wenn wir uns vorher schon Gedanken gemacht haben, welche unserer möglicherweise mehr als 15 vorhandenen Ports wir unter macOS verwenden wollen, um so besser. Ich möchte jetzt nicht noch erklären, wie wir herausfinden, welche namentlichen Ports sich hinter welchen physisch am Mainboard vorhandenen USB-Schnittstellen verbinden. Nur kurz soviel: An einer USB3-Buchse laufen intern zwei Ports: ein USB2 und ein USB3 (HS, SS). Das sieht man auch direkt in der Buchse: auf der Zunge sind deutlich mehr Pins (oben, unten) als bei einer reinen USB2-Buchse. An den Pfostensteckern auf dem Mainboard (für USB-Ports am Gehäuse zum Beispiel), liegen ebenfalls mehr Ports an. Bei reinen USB2-Pfostensteckern werden je Stecker zwei USB2 übertragen, bei den USB3 sind es ebenfalls für zwei Buchsen, also inkl. Der jeweiligen USB2-Anteile hier schon vier Ports.


    Schauen wir uns das am Beispiel vom „Asus Prime X299-Deluxe“ an:



    Hier sehen wir an den beiden Pfostensteckern für USB3 liegen die ersten vier USB3 an (SS01 bis SS04 und die jeweils anteiligen USB2 mit HS01 bis HS04). Das sind schon mal acht Ports. Dann finden wir noch einen USB2-Pfostenstecker (HS07/HS08), das macht dann schon insgesamt 10 Ports. Darüber hinaus finden wir hinten vier USB2 übereinander (HS09 bis HS12), das macht nun schon 14 USB Ports insgesamt. Schlussendlich finden wir noch mit SS05 und SS06 zwei weitere USB3-Ports, mit deren integrierten USB2-Ports (HS05 und HS06) wären das schon unzulässige 18 Ports. Und zusätzlich gibt es zwei „interne“ (also komplett intern verdrahtete) USB2-Ports, nämlich für das Board-eigene Bluetooth sowie für „AURA“ – die LED-Steuerung. Damit wären wir bei insgesamt 20 Ports, die dieses Board tatsächlich von den 26 möglichen zur Verfügung stellt. Zumindest für macOS werden wir uns also von fünf Ports trennen müssen. Übrigens: Wer genau aufgepasst hat, der wird etwas stutzen: Ich schrieb, hinten sind zwei weitere USB3 Ports. Zu sehen sind aber vier (mal von den grünen USB3.1 und USB-C von ASMedia abgesehen). Hier finden wir eine Besonderheit vom Board, dass die Ports HS06/SS06 erst intern auf einen Hub treffen, um dann auf drei Ports hinten weitergeleitet zu werden.


    Merke: es reicht nicht nur die Anzahl der physischen Ports zu zählen um auf die tatsächliche Anzahl an benutzten Ports zu kommen, denn interne Hubs könnten diese schon drastisch reduzieren. Man sollte also immer über die genutzte Technik informiert sein. Wie finde ich nun heraus, welche derbeschriebenen Ports an der tatsächlichen Schnittstelle jeweils anliegen? USB2- und USB3-Gerät jeweils an allen Ports anhängen, in zum Beispiel „IORegistryExplorer“ sieht man dann, an welchen Port sich das jeweilige Gerät anhängt. Mehr nicht dazu, da gibt es auch schon etliche Abhandlungen darüber.


    In meinem Fall hatte ich mich dazu entschlossen, je einen USB3 und USB2 Pfostenstecker nicht zu nutzen, da mein Gehäuse eh nur zwei USB3 anbietet. Somit fielen HS03/SS03 und HS04/SS04 sowie HS07/HS08 (vergleiche Bild) macOS zum Opfer und ich bin mit 14 Ports am XHCI im Limit von maximal 15 Ports.


    Nun ändern wir unsere SSDT. Zuerst werfen wir die Methoden „GPLD“ und „GUPC“ raus, nebst „USSD“ und „UHSD“ (Name). Es schaut somit aus:



    Jetzt gibt es jede Menge Compiler-Warnungen, denn diese Methoden hatten ja Methode. ;)

    Nun entfernen wir auch die Einträge innerhalb aller Ports von XHCI.RHUB:



    … und auch gleich noch aus den Ports der ASMedia. Hier lassen wir aber zumindest die Adressen drin, denn es sind neue Devices (erstmalig angelegt in der ACPI) und diese benötigen eine Adresse. Unsere bisherigen „Scope“ benötigen keine, da diese auf das jeweils gleichnamige „Device“ in der „DSDT“ referenzieren.



    Nun ist die SSDT wieder fehlerfrei, allerdings sind auch damit noch keine weiteren Beschreibungen hinzugekommen. Das holen wir nun nach. In jeden Port (HS, SS) kopieren wir nun erstmal diesen Code, den wir im nächsten Durchgang dann noch individuell ändern:



    Hier haben wir sowohl "_UPC" wie auch "_PLD", die nicht nur macOS, sondern auch sämtliche anderen Systeme verstehen. Im Grunde waren die vorhandenen Einträge ähnlich, nur ungenau. Unter "_UPC" finden wir vier Einträge. Der erste sagt aus, ob dieser Port aktiv ist. "0xFF" steht für aktiv, "Zero" für nicht aktiv. Hiermit können wir also schon ganz genau steuern, ob dieser Port überhaupt genutzt werden soll. Wir lassen im ersten Durchgang diesen Wert auf aktiv. Aber wir können uns schon den zweiten Wert "0x03" anschauen und gegebenenfalls direkt ändern. Dieser Wert steht für die Art des Ports. Gültige Werte sind:


    0x00 – USB2 (ausschliesslich unabhängige USB2 werden so deklariert)

    0x03 – USB3 (auch zugehörige USB2, das heißt gleiche Buchse, werden so deklariert)

    0x09 – USB-C (wenn unabhängig von der Drehung des USB-C-Steckers der _GLEICHE_ Port genutzt wird)

    0x0A – USB-C (wenn je nach Drehrichtung des USB-C-Steckers ein weiterer Port genutzt wird)

    0xFF – USB2 intern (zum Beispiel für Bluetooth)


    Nun im zweiten Durchgang konzentrieren wir uns auf diejenigen Ports, die zwar in der SSDT aufgelistet vorhanden sind, aber physisch nicht am Mainboard. Diese bekommen als ersten und zweiten Wert "Zero" (oder "0x00", ist das gleiche). Wenn wir das geschafft haben, sind unsere Ports korrekt beschrieben, allerdings haben wir unser "Port Limit" noch nicht beachtet. Ich habe diese Ports (vorhanden, aber individuell wegen macOS gesperrt) absichtlich noch nicht weiter beachtet, da wir hier pfiffigerweise eine Abfrage nach "Darwin" durchführen. Nur bei Bestätigung durch macOS (Darwin – quelloffener Kern von OSX) werden diese Ports deaktiviert, unter Windows zum Beispiel bleiben die weiterhin offen. Wir fummeln in diesem Fall gar nicht weiter am ersten Wert von "_UPC" rum, sondern setzen eine zusätzliche Methode ein, nämlich "Status". Damit können wir grundsätzlich bestimmen, ob ein Device aktiv oder nicht sein soll, feinere dazwischenliegende Abstimmungen interessieren uns hierbei nicht:



    Die Methode ist ganz simpel, bei Erkennung von macOS (Darwin) wird _STA "Zero" ausgegeben und das Device ist inaktiv, ansonsten voll aktiv mit den sonst geltenden Beschreibungen.


    Das war jetzt letztendlich recht simpel, unten beigefügt sind sowohl originale wie auch modifizierte SSDT, so das jeder nachvollziehen kann, was sich geändert hat. Zusätzlich sind dann noch die drei USB3.1 ASMedia deklariert, auch hier schön zu sehen, dass es unterschiedlichste Konfigurationen gibt für die gleichen technischen Devices. Der erste an RP01 ist der interne USB-E (für Gehäuse USB-C). Hier wird per internem Kabel die Buchse auf dem Mainboard mit dem USB-C am Gehäuse verbunden. Auffallend ist, dass hierbei die beiden SS01/SS02 (USB3.1-Anteil) komplett verdrahtet auf eine Buchse geschoben werden. Je nach Steckerdrehrichtung wird der eine oder andere Port genutzt. Entsprechend auch als "0x0A" deklariert. Während "HS01" (USB2-Anteil) immer auf der Buchse landet, egal wie der Stecker sitzt. Somit ist "HS02" zwar in der ACPI vorhanden, aber technisch nicht vorgesehen und somit auch per "Zero" deklariert.

    An RP05 hängt der zweite ASMedia-Chip, der stellt zwei USB-A Buchsen (Grün) hinten am Mainboard bereit. Diese werden ganz normal als "USB3 deklariert, also "0x03".

    Und zuletzt an RP07 der dritte ASMedia, hier auch hinten, allerdings als ein USB-A (Grün) und ein USB-C. Bei letzterem ist es egal, wie der Stecker angesteckt wird, es wird immer der gleiche Port benutzt. In diesem Fall also "0x09" eingestellt.


    Ein letztes Special findet ihr unter HS13. Hieran hängt mein interner Bluetooth. Nach dieser Definition bleibt auch beim "DeepSleep" Bluetooth weiterhin aktiv, ich kann den Rechner per Maus oder Tastatur wecken und Bluetooth ist auch nach dem Wake selbstverständlich weiterhin aktiv. Dieses Problem hatte ich zuvor nicht, aber mit macOS Monterey war nach dem Sleep/Wake Bluetooth "tot". Das ist nun auch gefixt. :)


    Viel Spaß beim anschauen der eigenen ACPI, und Verbessern der USB-Deklaration.

    Dateien

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    4 Mal editiert, zuletzt von apfelnico ()

  • Großartig - danke!


    Man lernt nicht aus. Hatte letztens mit USB2 Probleme, jetzt weiß ich: falsch deklariert.

    Lenovo Yoga S740 i9 / OpenCore

    GA-Z590 Vision D / i9-10900F / 32GB / Radeon VII / LG 34UM95-P
    GA-Z97N-WiFi / 4790K / RX580

  • Lieber Nico oder halt apfelnico ;)

    du hast hier alles gut beschrieben aber GPLD und GUPC müssen nicht entfernt werden besonders für die Leute, die gerne alle Ausgänge unter Windows oder Linux nutzen möchten, stattdessen kann man hier eine neue Methode schreiben und mittel _OSI jeden Ausgang definieren, was unter macOS machen soll.


    Im Grunde genomen GUPC Methode macht nicht anders als was Name (_UPC, ...) unter macOS tut und genauso mit GPLD ist nicht anders als Name (_PLD, ...)


    Hier kann man neue Methode definieren mit 2 veränderten Variablen, die so aussieht


    So könne wir hier der erste und zweite index von der Name (PCKG, ....) ändern


    Danach definieren jeden Ausgang in der SSDT ohne was daran zu löschen, indem wir die Methode sagen, was sie zurückgeben soll


    So sieht nicht geänderte SSDT


    Und so sieht nachher



    Wenn man den Ausgang unter macOS deaktivieren möchte dann einfach statt

    Return (MUPC (0xff, 0x03))

    nimmt

    Return (MUPC (0x00, 0xff)) und so weiter....


    So bleiben alle Ausgänge auch unter Windows oder Linux und nicht nur 15 Ausgänge wie unter macOS

  • N0b0dy


    Ist aber exakt das, was ich sonst auch direkt gemacht habe. Auch beim ersten Beispiel sind ALLE Ports für Windows und andere Systeme vorhanden, nur eben sauber beschrieben. Per "_OSI" nur für macOS bestimmte Ports entfernt.


    Habe mir das gerade angeschaut was du gepostet hast, so geht es auch. Ein Problem dabei bleibt: Die Ports sind nicht korrekt für "nicht-Darwin"-Systeme deklariert. Denn mit "GUPC" wird ein "universelles" Konstrukt für "_UPC" geliefert, wobei nur die erste Zeile ausgetauscht wird (aktiv oder nicht). Auch für Windows oder Linux ist es sicher nicht verkehrt, wenn man es richtig macht. Und zwar ACPI-konform, das hat nichts mit Apple zu tun.


    Habe mal dein Vorschlag aufgegriffen und direkt "GUPC" verändert, so das zwei Parameter übergeben werden können:


    dann sieht das bei einem aktiven Port beispielsweise so aus:


    bei einem nicht vorhandenen:


    und bei einem, der nur in macOS deaktiviert sein soll:




    Anbei eine überarbeitete SSDT mit diesen Änderungen.

    Dateien

    • SSDT-XHCX.aml

      (6,38 kB, 178 Mal heruntergeladen, zuletzt: )

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

    Einmal editiert, zuletzt von apfelnico ()

  • Habe mich gerade mal daran versucht, aber in meiner orginalen SSDT sind unter \_SB.PCI0.XHC.RHUB noch andere Methoden: GPLD, TPLD, GUPC und TUPC und insgesamt ist da noch viel mehr anderer Kram drin neben den 26 Ports. Da weiß ich jetzt nicht, wie ich weitermachen soll.


    SSDT-7-xh_cmsd4.aml (Ist von nem Gigabyte Z490 Vision G, Bios F21a)

    Einmal editiert, zuletzt von 5T33Z0 ()

  • ST33Z0


    TUPC liegt da zwar, wird aber nicht benutzt. Aber eventuell von einer anderen SSDT darauf zugegriffen. Innerhalb dieser SSDT spielt diese Methode keine Rolle. Die ersten beiden Methoden brauchst du nicht anzufassen, GUPC könnte, wie ich in Post #4 schrieb, geändert werden. Sobald du diese Methode änderst, _MÜSSEN_ bei jedem Port zwei Angaben (Arg0, Arg1) gemacht werden, schaue dir dazu weiter den Post #4 an. Du kannst bei den Ports innerhalb von "_UPC" (also innerhalb der geschweiften Klammer) alles rausnehmen und dich dafür an dem halten, wie es in Post #4 in der beigefügten SSDT steht. Die Werte sollten klar sein, hatte ich ganz oben geschrieben, Beispiel für _OSI-Abfrage siehst du ebenfalls in der SSDT.

    Bei dir steht etwas mehr in der SSDT drin, bei den Ports gehts es um eine Abfrage, ob der überhaupt per BIOS aktiv geschaltet ist (Variable dazu auslesen) und wenn ja, wie dann zu verfahren ist. Das kann man ja entfernen. Ansonsten ist da noch etliches zu den RP geschrieben, ob aktiv und wenn ja, was dann … den Rest kannst du völlig unbeeindruckt drin lassen, hat ja seine Aufgaben.

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • Ja klar kannst du auch GUPC ändern statt eine neue hinzufügen aber dann musst du hier vieles dabei ändern und für die meisten werden nicht mitbekommen, was wurde gemacht oder geändert.

    Für die meisten wissen nicht mal wie USBMap.kext erstellen müssen, wie denn das damit, kannst du vergessen 8o

    Es gibt noch dritte Möglichkeit, wo du den Device RHUB unter macOS unterdrückst/deaktivierst und einen neuen Device definierest (XHUB oder ZHUB....) und wie du oben am Anfang "Post Nr. 1" alles geklärt hast, die Ausgänge für MacOS deklarieren ;), da bleibt RHUB unversehrt für andere Systeme und die original SSDT muss nicht in OpenCore deaktiviert :thumbup:


    ST33Z0 wenn du uns mitteilst, welche USBs unter macOS behalten möchtest dann könnte deine SSDT bearbeiten und so damit wäre ein Beispiel für die anderen

    Screenshot von Hackintool würde reichen

  • N0b0dy

    Das ist nichts für Einsteiger, völlig klar. Und ich möchte eben die Ports korrekt beschrieben haben. Etwas, was die Hersteller versäumt haben. Das hat zunächst NICHTS mit macOS zu tun. Lediglich für macOS kommen noch bestimmte Einträge hinzu.


    ST33Z0

    habe mal deine SSDT überarbeitet und liegt anbei.

    Du siehst, die Methode "GUPC" wurde verändert und jeder Port hat einen dazu passenden Eintrag. Die Werte sind bei allen Ports zunächst gleich (aktiv, usb3). Das musst du noch ändern, das weiß ich natürlich nicht.


    Wie ein fehlender Port (also wirklich physisch vom Hersteller auf diesem Board nicht bestückt, gegenüber den 26 möglichen Ports des Controllers) aussieht, siehst du unter "USR1/2". Das könntest du für die entsprechenden Ports auch so festlegen.


    Wie ein Port aussieht, den du nur unter macOS deaktivieren möchtest wegen des PortLimits, siehst du beispielhaft unter "HS01".


    Viel Erfolg!

    Dateien

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • Wo genau liegt denn der Vorteil zur Kext Methode?

  • Wo genau liegt denn der Vorteil zur Kext Methode?

    Wenn sonst alles läuft, möchte man ja etwas zu tun haben. :)


    Kext ist prima. Aber, diese selbsterstellte USB-Kext ist ja keine ausführbare Kext, sondern übermittelt lediglich fehlerbereinigte und weitere Beschreibungen über USB an die eigentliche Kext. Etwas, was nicht notwendig wäre, würde die ACPI schon korrekt sein. Also mehrere Stufen darunter. Und wer das reparieren möchte und den nötigen Ehrgeiz mitbringt, der ist herzlich eingeladen hier mitzumachen. Ein tatsächlicher Vorteil ist dann auch gegeben, da nun alles ab Basis stimmt. Diese selbstgebauten "HelperKexte" funktionieren natürlich auch nur solange, wie eben diese Mechanismen verfügbar sind. Und auch da hat sich in den letzten macOS-Versionen einiges geändert, plötzlich funktionierten Kexte nicht mehr, die von "Hackintool" erstellt wurden, weil es nun andere Schnittstellen gab. Mit der SSDT-Methode hingegen sind die Ports sauber beschrieben schon auf ACPI-Ebene. Das muss hier keiner machen, ein Kext funktioniert auch. Es war nur mal 'ne Frage danach und ich habs mal versucht aufzudröseln. :)

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • Wo genau liegt denn der Vorteil zur Kext Methode?

    USB Ports, die via ACPI Tabelle definiert werden, sind betriebssystem-agnostisch, wie es so schön heißt. Das heißt, sie funktionieren dann mit jedem OS. Wenn man aber eine USBPorts.kext für Catalina gebastelt hat für iMac20,2, dann funzt die Kext nicht, wenn man auf iMac19,1 wechselt weil man zum Beispiel macOS Mojave nutzen will. Dann muss man da wieder dran rumfummeln.


    Zudem ist es seit macOS seit Big Sur 11.4(?) nicht mehr so einfach, die Ports zu mappen, da der XHCI port limit quirk nicht mehr funktioniert. Den ganzen Stress kann man halt damit umgehen, dass die Ports via ACPI gemapt werden. Das macht man einmal und hat dann Ruhe bis sich etwas am BIOS ändert. Dann muss man eventuell die Angaben der tabelle, die gedroppt werden soll in der Config anpassen (falls sich das Original geändert hat)


    EDIT: Habe jetzt ein bisschen Knoten im Kopf vom Gefrickel. Bis auf die beiden Front Panel USB 3 Ports (HS09/SS09) scheint alles soweit zu funktionieren. Die SSDT wird auch geladen (kann sie unter maciASL über "File > New from ACPI" öffnen). Könnte sich das vielleicht jemand ansehen? Weiß nicht, wo da der Fehler ist. Anbei die SSDT und ein PDF mit Auslistung der Ports und Mainboard-Skizze. Thx

    Dateien

    Einmal editiert, zuletzt von 5T33Z0 ()

  • apfelnico  ST33Z0 Danke Euch beiden. Da ich aus verschiedenen Gründen bis auf Weiteres bei Catalina und meiner Hardware bleibe erst einmal nicht relevant, aber nach Hardwarewechsel ganz sicher ein Teil des Projektes. Vote für Aufnahme der Thematik ins Dortania. 👍🏻😊

  • hier ist meine Variante, du kannst sie testen und berichten...

    Viel Erfolg

    ST33Z0

  • hier ist meine Variante, du kannst sie testen und berichten...

    Viel Erfolg

    ST33Z0

    Vielen Dank für die Mühe. Die Front Panel USB 3 (SS09/SS10) funzen leider immer nocht nicht. Werde morgen mal rein gucken, wo das Kabel zum Front Panel dran hängt. Vielleicht liegt's ja daran. Mit meinem USBPorts Kext funktionierts komischerweise.

  • lade bitte hier oder als PN eine gespeicherte IOReg File mit USBPorts Kext und eine mit meiner SSDT hoch dann sehe es genau an

    ST33Z0

  • ST33Z0

    Alle durchdekliniert laut deiner Zeichnung, 15 Ports für macOS:

    Dateien

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • apfelnico Vielen Dank. Leider funktioniere SS09 und SS10 damit auch nicht. Ein USB 2 Stick wird allerdings erkannt.


    Ich habe festgestellt, dass es noch eine "SSDT-5-A M I.aml" gibt, in der RHUB und HS10 und HS14 vorkommen. Weiß nicht, ob das von Bedeutung ist.


    N0b0dy IOReg für beide Fälle anbei.

    Dateien

    • IOReg.zip

      (12,1 MB, 113 Mal heruntergeladen, zuletzt: )
    • SSDT-5-A M I.aml

      (11,51 kB, 105 Mal heruntergeladen, zuletzt: )
  • IOReg mit ACPI deutet darauf, dass deine geänderte SSDT nicht richtig geladen, du solltest nachprüfen, ob wirklich original SSDT in OpenCore deaktiviert ist

    ST33Z0

  • Kann man mir bei meinem Z590 Pro auch weiterhelfen?:/

    Ich würd das ganze auch mal mit Acpi austesten.
    Ich schnalls anscheinend doch noch nicht so recht...
    anscheinend muss ich ja den "SSDT-5-xh_rksu4.aml" patchen,
    Da gibt es noch ne USB-C Tabelle die verstehe ich jetzt überhaupt nicht...

    Anbei hab ich den Kext Info.plist den ich zurzeit einsetze..

    Gruss Coban

    Dateien

     MSI-Z590Pro Wifi | Intel® Core™ i9-10900k CometLake | 32GB DDR4 RAM | Radeon RX 570 Red Devil | Nvme WD Black SN750 1TB | BCM94360NG | OpenCore aktuell / Catalina / BigSur / Monterey / Ventura Beta / Win 10 Pro / Win 11 Pro / Ubuntu / ChromeOS

     MSI-B150M Mortar | Intel® Core™ i7-6700 Skylake | 64GB DDR4 RAM | Intel® HD Graphics 530 | Samsung NVMe 960 EVO / 1x2 TB HDD | BCM943602BAED DW1830 | OpenCore aktuell / Catalina / BigSur / Monterey / Win 10 Pro / Ubuntu

     Lenovo S340-15IIL | Intel® Core™ i7-1065G7 IceLake | 12GB DDR4 RAM | Intel® Iris Plus Graphics G7 | Nvme Intel SSDPEKNW512G8L/SSD Samsung 256GB | BCM94360NG | OpenCore aktuell / Catalina / BigSur / Monterey / Ventura Beta / Win 10 Pro / Win 11 Pro / Ubuntu / ChromeOS


    " Chasch nöd s Föifi und s Weggli ha."