USB2 Devices -> EHCI Routing zu AppleUSBEHCI

  • Klar immer nur mit Backup @kuckkuck... ;)


    Ich bin gerade mit der XOSI Variante dran. Ich kann sehen (wenn ich mit MaciASL die aktuelle Tabelle auslese, das die XOSI Methode in der DSST vorhanden ist. Bisher bemerke ich im System keine Veränderung. Gibt es eine Stelle wo ich validieren kann ob die Einstellungen überhaupt zu einer Veränderung führen? Fühlt sich gerade etwas "blind" an.


    Ich nehme an, das die Umbenennungen XHCI->XHC, EHC1->EH01, etc. auf bei der Methode aktiv bleiben oder habe ich das missverstanden?


    Nachtrag: Im MaciASL sehe ich auch die SSDT-XOSI im ACPI.


  • Ja das ist alles etwas "blind" und merken kannst dus nur dann wenn sich etwas mit deinen USB Ports etwas verändert... Wir müssen experimentieren.


    Dein SSDT Auszug ist aus der AML Datei welche Windows 8 simulieren würde. Wieso das so ist kann ich dir später erklären. Jetzt erstmal: Wo hast du diese aml gespeichert? Wo ist die DSL Datei und unter welchem Namen hast du die beiden jeweils gespeichert? Ist die SSDT.aml in der config.plist in der sorted order? Benutzt du eine SSDT für Speedstep?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Einmal editiert, zuletzt von kuckkuck ()

  • Wir müssen experimentieren.


    Ok, ist ja auch mal spannend.


    Wo hast du diese aml gespeichert? Wo ist die DSL Datei und unter welchem Namen hast du die beiden jeweils gespeichert?


    EFI/CLOVER/ACPI/patched/SSDT-XOSI.aml
    _OSI zu XOSI zunächst via Clover Patch (ACPI-->DSDT-->Patches)


    Ist die SSDT.aml in der config.plist in der sorted order?


    Ja


    Benutzt du eine SSDT für Speedstep?


    Nein


    Wieso das so ist kann ich dir später erklären.


    Ich denke das habe ich schon verstanden. Windows 8 weil sowohl für Windows 8 (_OSI string: "Windows 2012") und alle früheren Windows Versionen ein 0xFFFFFFFF als Return value liefern. Soll Windows7 gemeldet werden, müsste der Eintrag "Windows 2012" entfernt werden. Damit wäre "Windows 2009" respektive Windows 7 der höchstwertige valide Eintrag. Korrekt?

  • Genau so ist es. Da Windows 8 nicht will, probieren wir jetzt erst einmal Windows 7. Dazu einfach in der DSDT.dsl Windows 2012 als Bemerkung/Kommentar setzen ( //) und danach neu als .aml Compilieren und einbinden. Dadurch werden alle Bemerkungen entfernt und somit auch Windows 8, was dann zum aktivieren von _OSI Windows 2009 führt. _OSI Windows und alle vorherigen Versionen müssen -->true-return liefern und dürfen deshalb nicht entfernt werden. Die Server Versionen aka x.1 lassen wir auch raus ;)
    Wenn du keine SSDT für Speedstep benutzt, benenn die SSDT-XOSI.aml mal in SSDT.aml um :thumbup:

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Einmal editiert, zuletzt von kuckkuck ()

  • Hallo @Kuckuck


    ich habe nochmal beide Varianten ohne jegliche Injektoren etc. getestet. Weder Windows 7 noch Windows 8 scheinen eine Veränderung zu ergeben. Über den Weg MaciASL/New from AHCI/SSDT kann man sehen, das die Änderungen jeweils übernommen wurden, mehr aber auch nicht. Vielleicht verhält sich das ASUS Bios in beiden (allen) Fällen gleich?


    Ohne Injektor funktionieren alle USB2 Ports übrigens auch perfekt. Mit Rehabman's XHCI-x99-injector.kext wird alles gnadenlos über den AppleUSBXHCIPCI geroutet was logischerweise dazu führt das auch die USB3 Geräte laufen, aber damit auch die Audio Probleme vorhanden sind. Was mich wunder ist, das der XHCI-x99-injector eigentlich nur 0x8d318086 auf den AppleUSBXHCIPCI bindet. Warum wirkt sich das auf die USB2 Devices am Controller 0x8d2d8086 aus? Ich meine es wäre ja ok, wenn die USB2 Devices die in einem USB3 Port stecken auch vom xHCI verwurstelt werden, aber warum kassiert der auch alle USB2 Ports vom EHCI ein?


    Gruß Joe

  • Gut dann machen wir das eben radikaler...
    Öffne mal ein Backup von einer DSDT, die noch keine Veränderungen bezöglich OSI oder EHC1-->EH01... hat. Dann hol dir Rehabmans Laptop Repo für MaciASL und apply den OS Check Fix für Windows 7. Dabei wir die _OSI Darwin Methode jetzt komplett ersetzt. Mal sehen was passiert. Windows 8 und als letztes Vista kannst du natürlich auch probieren. Und wenn das auch nicht will gibt es eine noch etwas radikalere Lösung...


    Zu deinen Versuchen mit FakePCIID_XHCIMux: hattest du nach installieren des Kexts mal mit den XHCI Modes im BIOS gespielt?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Radikaler getestet - ohne Befund :)


    Ich sehe in der ausgelesen DSST den Eintrag

    Code
    1. If (LOr (_OSI ("Darwin"), _OSI ("Windows 2009")))
    2. {
    3. Store (0x0E, OSVR)
    4. }


    Und die Controller heißen wieder EHC1, EHC2 und XHCI - insofern wurde alles angewendet. Einen Unterschied im Verhalten kann ich nicht feststellen. Ich werde jetzt mal den Patch für Windows 8 Testen und ggf. mal Windows 10.


    Nachtrag: Windows 8 bringt auch keine Veränderung. Windows 10 entfällt alt Test, da in der ausgelesenen DSDT kein Eintrag zu “Windows 2015”, was laut MS Doku Windows 10 wäre, existiert.

  • Was ist mit Vista, was ist mit meiner letzten Frage aus der Nachricht oben?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Entschuldige, hatte ich nicht explizit erwähnt. Identisch.

  • Zu deinen Versuchen mit FakePCIID_XHCIMux: hattest du nach installieren des Kexts mal mit den XHCI Modes im BIOS gespielt

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Verdammt :) Ja, hab ich auch. Gefühlt läuft nur Smart Auto wirklich gut. Bei Auto treten USB3 Disconnects auf.


    Am besten scheint im Moment die folgenden Variante zu sein.
    DSDT: Nur EHC1/EH01, EHC2/EH02, XHCI/XHC_
    Kext: FakePCIID+FakePCIID_XHCIMux+USB_Injector x99
    Clover Boot Argument -uia_exclude_hs


    Bisher laufen alle Ports perfekt stabil. Und durch das Boot Argument sind auch nur die SSP Ports auf den XHCI gebunden.
    Die Abwärtskompatibilität der USB3 Ports geht aber immer noch nicht.


    Ich frage mich langsam ob ich nicht einen Denkfehler habe und da in der Konstellation überhaupt nicht möglich ist?
    Kann es sein, das der FakePCIID_XHCIMux per Definition die Abwärtskompatibilität an den USB3 Ports kill?
    Und wenn nicht, kann es daran liegen das bei meinem System EH01 in der IORegistry komplett leer sind und alle Ports am EH02 hängen? Vielleicht ein Zielkonflikt?


    Gruß Joe

  • Hmm... FakePCIID_XHCIMux killt nicht die Abwärtskompatibilität, er routet nur Ports zu einem EHC Controller...

    Und durch das Boot Argument sind auch nur die SSP Ports auf den XHCI gebunden.


    Das Boot Argument tut absulut garnichts ohne USBInjectAll.kext. Das wird nichts ;)
    Kurze Frage, wie verhalten sich deine USB Ports bezüglich des Mikros wenn kein einziger Patch bezüglich USB realisiert ist?


    Radikalitäts-Steigerung + 1 :thumbsup: : Such dir mal die ESEL Methode in der DSDT raus


    Und jetzt killen wir die einfach mal... :D

    Code
    1. Method (ESEL, ...)
    2. { Return(0)
    3. ...
    4. }

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    3 Mal editiert, zuletzt von kuckkuck ()

  • Hmm... FakePCIID_XHCIMux killt nicht die Abwärtskompatibilität, er routet nur Ports zu einem EHC Controller.


    Ok, dann ist die Frage ob er das in irgendwie mit den ACPI Namen korrespondiert. Vielleicht ist da EH01 hardcoded drin, oder sowas? Mich wundert nur das bei mir alles am EH02 hängt und der EH01 leer ist.


    Das Boot Argument tut absulut garnichts ohne USBInjectAll.kext. Das wird nichts ;)


    Nein, das ist nicht korrekt. Ohne das Argument werden die HSxx Ports an den XHC gebunden - mit nicht. Ich nehme an das der FakePCIID_XHCIMux den Parameter auch auswertet. Der Hinweis zum Einsatz kam von Rehabman in einem anderen Thread den ich dazu gelesen hatte.


    Kurze Frage, wie verhalten sich deine USB Ports bezüglich des Mikros wenn kein einziger Patch bezüglich USB realisiert ist?


    Mikro beziehst Du auf das USB Audio Device? Wenn ja, ist die Antwort - läuft korrekt ohne jeden Kext als USB2 Device. Ohne Kexte fehlt dann aber der USB3 Support.


    Radikalitäts-Steigerung + 1 :thumbsup:


    Ich werde testen und berichten... ;)

  • Der Hinweis zum Einsatz kam von Rehabman in einem anderen Thread den ich dazu gelesen hatte.


    Das will ich sehen... Glaube ich nicht, aber vielleicht hast du recht...
    Wie wirkt sich das Nutzen des Bootargs mit FakePCIID_XHCIMux auf den XHC Controller in IOReg aus? Was ist zu sehen?


    Ich werde testen und berichten...


    Dann tu das mal, ich bin gespannt was bei deinem System passiert...


    Wenn das nicht funktioniert (und auch nicht die deaktivierung von XSEL (machen wir später)) dann rate ich dir dazu mal den Port Limit Patch zu probieren. Wie das geht ist auch in der FAQ beschrieben. Das macht vielleicht insofern Sinn, als das deine USB Ports ohne Patch gut zu funktionieren zu scheinen. Ich bin gespannt.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.


  • Das will ich sehen... Glaube ich nicht, aber vielleicht hast du recht...


    Läuft... ;) Jetzt wollte ich Dir gerade den Quote reinsetzen weil ich den Tab noch offen hatte, da seh ich das es die Antwort auf einen Post von der Seite davor war und der hatte natürlich doch die USBInjektAll. Mea Culpa :)


    Aber ich bin auch bei Rehabman auf die Aussage gestolpert: "By default forces all XHCI ports to route USB2 devices to EHC1."


    Ich probier noch mal eben was und dann Teste ich weiter... ;)

  • Das mit EHC1 oder 2 ist normal und kommt aufs SMBios drauf an ;) Welche System Definition benutzt du denn?
    Wie sind deine Tests ausgegangen?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • MacPro 6,1


    Ich hab gestern Abend früh Schluss gemacht und teste heute Abend weiter.


    @Kuckuck Codeword "Der ESEL ist offline" :) Leider auch keine signifikanten Änderungen erkennbar.


    In der Info.plist der FakePCIID_XHCIMux finden sich die RM,pr- Einträge.



    Wirklich viel habe ich dazu nicht gefunden aber Rehabman schreibt dazu folgendes:

    Zitat

    Configuration properties and their defaults: RM,pr2-force <00 00 00 00>. By default forces all XHCI ports to route USB2 devices to EHC1. RM,pr2-init <01>. Will write RM,pr2-force value at startup if non-zero. RM,pr2-block <01>. Will block writes to XUSB2PR if non-zero. RM,pr2m-block <01>. No evidence that OS X drivers attempt to write XUSB2PRM (offset 0xD4), but since this kext relies on a valid value here (as provided by the BIOS), writes to it are blocked if non-zero. RM,pr2-honor-pr2m <01>: Changes to XUSB2PR will be masked by XUSB2PRM if this is non-zero. RM,pr2-chipset-mask: Writes to XUSB2PR are masked by this value. This is defined by the chipset documentation. Default value depends on chipset. Refer to Intel 7/8/9-series chipset data sheet for more info.


    So wie ich das verstehe wäre es doch damit möglich per RM,pr2-force nur die reinen USB 2.0 Ports an den EHCI zu leiten, oder? Das würde ja schon ausreichen. Ein USB 2.0 Device am USB 3.0 (Dongles etc.) dürfte gern auch XHC bearbeitet werden. Bisher erschließt sich mir die Maskierung aber überhaupt nicht - bzw. die Nummerierung auf deren Basis dann maskiert wird. Wirst Du da schlau draus?



    --- Themensprung / Warnung :) ---



    Auf die Gefahr Dir jetzt vollkommen auf die Nerven zu gehen... aber ich möchte das wirklich verstehen. Ich habe mir die DSDT nochmal sehr genau angesehen. Speziell das Thema korrekte _UPC Objekte. Beim XHC stimmen die Angaben von DSDT und IOReg überein, also Portbezeichnungen / Anzahl / Adressen. Bei EH01 und EH02 nicht.Bei EH01 (Adresse 8d26) fehlt der HUB und es fehlen alle Ports, selbst mit USBInjektAll ohne Filter. Bei EH02 werden die sechs Ports korrekt übernommen, aber die Nummern der Ports werden um zehn inkrementiert? Es taucht dem entsprechend auch nur ein USB2.0 Bus im USB Gerätebaum auf. Ich finde das nach wie vor sehr seltsam.



  • Zum Anfang:
    Das ganze ist von mehreren dingen abhängig. RM,pr2-force routet zwar zu EHC, wird aber nur aktiviert wenn RM,pr2-init aktiviert ist um beim Start RM,pr2-force zu aktivieren. XUSB2PR wird geblockt damit bei dem ganzen Prozess Apples Treiber nicht zwischen funken. Lediglich das Chipset Value könnte nötige Veränderungen bringen, was aber überhaupt garnicht dokumentiert ist... Insofern ist das ganze eher eine Sackgasse für uns :(
    Das mit der DSDT mag komisch sein, aber ich kann dir nicht sagen ob das Behavior wirklich falsch ist oder sogar so stimmt... Ich mein der eine Controller wird weggelassen, der andere in teilen der Bezeichnungen inkrementiert. Wer weiß. :D
    Ich weiß nur was wir als nächstes versuchen könnten, und das wäre XSEL statt ESEL zu deaktivieren. Gleiche Prozedur wie mit ESEL. Wir wollen ja Abwärtskompatibilität erschaffen, nicht aufwärts :D
    Kurze Frage nebenbei, wie weit ist deine Standard DSDT gepatcht? Sind da wenigstens die basics drin?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Einmal editiert, zuletzt von kuckkuck ()

  • Ok, dann gehe ich nachher mal XSEL an. Danke für die Erklärung!


    Die DSDT umfasst derzeit, die XHCI/EHC1/EHC2 Änderung, die Anpassung der GFX für die PCIID meiner 980ti (MacPro6,1). Dazu die Basics aus dem Wiki, allerdings ohne HDMI und Audio Einträge. Ich nutze den internen ALC Audio Chip nicht. OS Check Fix und USB Power auch nicht.


    Gruß Joe


    @Kuckuck - Auch mit XSEL keine Änderung.

  • Und hast du mal den port limit patch probiert?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.