Fixing USB in OpenCore

Ich hatte das Problem das bei mir keine USB 2 erkannt werden (also auf dem Desktop im Hackintool wurden sie angezeigt). Habe dann einen Kext erstellt und den eingebunden und es funktionierte dann.

Ich hab es mit USB Injectall gemacht. Nutzt du den Kext nicht?

Lisa

Wenn diese ACPI-Patches (in Clover genutzt) tatsächlich notwendig sind, lassen die sich exakt so auch in OpenCore setzen.

In der "config.plist" findest du hier das Gesuchte, habe beispielsweise mal den ersten Patch gesetzt, so sollte das aussehen:

Hallo Lisa,

hat es denn bei Dir geklappt? Ich habe mit meinem Mainboard Z87X-D3H ebenfalls das Problem,dass bei mir nur die USB 2 erkannt werden. Da ich aber recht neu bin, weiß ich nicht, welche Anpassungen und vor allem wo gemacht werden sollen. Womöglich könntest Du mich mal kurz dabei unterstützen. Ich wäre Dir dafür sehr dankbar.

Den Eintrag EHC1 habe ich nicht einmal unter ACPI --Patch. Mir fehlt das Verständnis dafür, wie mein System aktuell funktioniert. Installiert habe ich es ebenfalls über OpenCore Dortania Guide.

Mein System:

Mainboard
GA Z87X-D3H (rev. 1.0), Bios F9
Prozessor
Intel i7-4770K (Haswell)
Grafikkarte
HD 4600
Bootloader
OpenCore 0.6.2
Betriebssystem
macOS Catalina 10.15.7

Vielen Dank im Voraus!

Ich habe gerade (als Newbie) mit Hilfe des Dortania-Guide ein System neu aufgesetzt. Vielleicht helfen meine Erfahrungen hier ein wenig weiter. Falls ich Unsinn schreibe, bitte ich die "Wissenden" um Korrektur. Der Dortania Guide hat m.E. beim Post-Install, genauer beim USB-Mapping eine Lücke. Im "Zweig" Intel-Chipsatz wird zwar auf das USBMap.command Konsolen-Tool Bezug genommen. Leider muss man aber selbst forschen, um herzauszufinden, wie die vom Script produzierte USBmap.kext in der config.plist eingebunden wird. Ich hoffe, ich habe das -> hier richtig beschrieben.

Beim Finetuning bin ich dann aber zum Hackintool gewechselt. Der darin enthaltene USB-Patcher ist meiner Ansicht nach sehr viel einfacher zu bedienen als das Konsolen-Tool. Die nachfolgenden Schritte beziehen sich also auf eine bereits in der config.plist eingebundene USBMap.kext. Ich bin so vorgegangen:

-> im Hackintool den USB-Tab auswählen -> Einträge mit Besen-Button (Clear all) löschen

-> mit der Spritze (Inject) alle Ports laden

-> mit dem Button rechts daneben (Aktualisieren), die aktuelle Belegung einblenden, Reihenfolge also CIA...

-> HS = USB 2.0, SS = USB 3.0, USR (auf Mac nicht genutzt)

-> USB 3.0 Buchsen (blau) belegen immer zwei Ports, also 1x HS + 1 x SS

-> Zeichnung des Mainboards aus Manual ausdrucken und die USB Ports markieren und beschriften (USB-Buchsen und USB-Onboard-Anschlüsse)

-> Frontbuchsen sind zumeist mit einem Kabel auf eine Pfostenleiste geführt und können daher ebenfalls ausprobiert werden

-> USB 2.0 Stick Schritt für Schritt in alle Buchsen stecken

-> im Hackintool unter Comments (letzte Spalte) die jeweils durch den Stick aktivierten Ports sinnvoll benennen und auch in der Zeichnung eintragen

-> es dürfen max. 15 Ports belegt werden, also z.B. 5 x USB 3.0, (=10), 4 x USB 2.0 (=2) und 1 x Onboard USB 2.0 (z.B. für Bluetooth)

-> für USB 3.0 Ports gibt es also jeweils zwei Einträge in der Liste (z.B. HS01 und SS01), für alle anderen jeweils einen (HS)

-> ggf. müssen also einige Buchsen "stillgelegt" werden, daher genau überlegen, welches Mapping am Sinnvollsten ist

-> alle Einträge, die nicht identifizierbar sind oder abgeschaltet werden müssen, in der Liste auswählen und mit (-) löschen

-> nochmals checken, ob wirklich nur max. 15 Einträge verblieben sind

-> mit dem []-> Button unten ganz rechts werden drei Dateien erzeugt, man braucht nur die USBPorts.kext

-> wenn zuvor lt. Dortania-Guide eine USBMap.kext in der config.plist eingebunden wurde, die Datei USBPorts.kext umbenennen in USBMap.kext

-> EFI mounten z.B. mit MountEfi

-> alte USBMap.kext aus OC/Kexts sichern für den Fall, dass es nicht funktioniert

-> neue USBMap.kext dorthin speichern

-> neu starten, Ports testen, ggf. WLAN und Bluetooth testen

Faust Magst du mal prüfen, ob o.g. Vorgehensweise deine Anleitung für das USB-Mapping ergänzen könnte? Insbesondere was die Einbindung der kext in die config.plist betrifft. Dort stimme ich dir zu macraq . Danke für deine Mühe!

macraq

Wichtig ist auch das XHCiPortLimit in der config.plist auf false zu setzen, nachdem die Ports richtig gemappt wurde.

Bei vorheriger Verwendung des USBInjectall.kext darf dieser bei der Kext Methode auch nicht mehr verwendet werden.

Eine SSDT-USBX wird auch nicht mehr benötigt, da die "USB Power properties" in der erstellten USBPorts.kext enthalten sind. (zumindest wenn man das Mapping mittels Hackintool durchgeführt hat)

LetsGo Lt. Dortania Guide wird - bei meiner Skylake-Konfiguration - die USBInjectall.kext nicht verwendet. Es wird stattdessen offenbar die SSDT-EC-UBX-DESKTO.aml im ACPI Ordner genutzt. So steht´s in der Anleitung, wenn ich mich recht erinnere... XHCI Port Limit steht tatsächlich auf "True". Ich habe den Dortania-Guide wirklich peinlich genau eingehalten. Bis eben auf die nebulöse Stelle des Intel-USB Mapping.

Sollte man also statt des Hackintools doch lieber USBMap.command benutzen, damit es keine Probleme gibt? Bei meinem Rechner funktionieren mit der oben beschriebenen Vorgehensweise alle Ports wie erwartet - inkl. Bluetooth, Airdrop etc...

macraq

Manchmal wird die USBInjectall.kext aber empfohlen (z.B. OEMS). Das ist ist auch nur der Vollständigkeit halber, falls jemand diese Kext eben verwendet.

Dann muss man diese unbedingt nach dem Mappen wieder entfernen, falls man die Kext Methode fürs Mappen verwendet.

Ich habe mir die produzierten Kexte (USBMap.kext und USBPort.kext) mal angesehen. Sie sind vom Inhalt her recht ähnlich. Ich bin mir aber nach wie vor unsicher, ob meine Vorgehensweise, also dass Umbenennen der Kext ok ist. Es wäre schön, wenn jemand eine Antwort darauf hätte.

Völlig wumpe wie du die nennst. Kann auch „meine_lieblings-usb.kext“ heißen.

Muss denn dann nach erfolgreichem Mapping auch die SSDT-EC-UBX-DESKTO.aml wieder entfernt werden?

burzlbaum Grundsätzlich würde ich sagen, nein, sie muss nicht entfernt werden.

Ich habe sie nun aber auch mal deaktiviert und im Zusammenhang mit meinem USBport.kext bleibt mein USB mapping bestehen.

Schaden tut sie nicht, aber anscheinend brauch ich sie auch nicht wirklich. Das kann eventuell an meinem board liegen. Ein anderes braucht sie eventuell.

Vielleicht weiß jemand anders noch mehr darüber?

Wie schaut die SSDT denn genau aus? Klingt nach USB-Power (Stromstärke) und EC-Device, bei Desktop-Systemen i.d.R. wichtig.

Ich verwende diese bei mir.

Mit MacIASL kann man .aml Dateien ansehen (und auch ändern, als .aml kompilieren).

Ich nutze diese SSDT-EC-UBX.aml neben USBMap.kext, da die Funktionen (offensichtlich USB Powermanagment) nicht vom .kext injected werden.

Hintergrund:

Beide Sachen haben also sehr unterschiedliche Aufgaben (USBKext sorgt für Einhaltung Portlimits von benötigten - aktiven Port- OHNE in OC die Ports generell zu begrenzen um das Limit einzuhalten. OC Portlimit (oder Portlimit Patches) können auch Ports "ausblenden" die man eigentlich braucht und widerum andere aktiv halten die man nicht braucht.

In der info.plist aus dem USBport.kext finde ich auch Einträge die für's Powermanagement zuständig sind. Werden die nicht genutzt?

Meine EFI sieht so aus. Habe diese auch nur übernommen und nicht selbst geschrieben. Funktioniert mit identischer Hardware aber wohl an anderer Stelle gut. Ich vermute, der Fehler liegt irgendwo beim Mapping aber ich bekomme es alleine leider nicht hin.