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.

Zitat von kuckkuck

Wir müssen experimentieren.

Ok, ist ja auch mal spannend.

Zitat von kuckkuck

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)

Zitat von kuckkuck

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

Ja

Zitat von kuckkuck

Benutzt du eine SSDT für Speedstep?

Nein

Zitat von kuckkuck

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?

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

Radikaler getestet - ohne Befund

Ich sehe in der ausgelesen DSST den Eintrag

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.

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

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

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

Zitat von kuckkuck

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.

Zitat von kuckkuck

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.

Zitat von kuckkuck

Radikalitäts-Steigerung + 1

Ich werde testen und berichten...

Zitat von kuckkuck

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

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.

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.