Beiträge von bobpedro

  • Hackintool Anleitung USB-Patching in Deutsch

    cobanramo hier meine Bios-Settings zu USB:



    Nochmal um Dich abzuholen:

    Mein Hack wacht automatisch aus dem Standby auf, was an der BT-Karte liegt, die über den internen USB-Connektor mit dem Mainboard verbunden ist. Daher versuche ich mithilfe eines USB Port-Mappings den entsprechenden Anschluss-Typ auf "intern" zu stellen, da dies oft als Lösung des Problems gehandhabt wird.


    Das Erstellen des Port-Mappings bekomme ich mittlerweile hin, allerdings wird die BT-Karte dann gar nicht mehr erkannt wenn als Connector-Typ "intern" verwendet wird. Benutze ich den Typ "USB" ist die Karte aktiv, aber Standby funktioniert dann eben nicht. Da liegt das Problem.

  • Hackintool Anleitung USB-Patching in Deutsch

    Hey cobanramo,


    also heute habe ich einen neuen Versuch gestartet: Boot mit 3 Clover Renames (EHC2 -> EH02, EUSB -> EH01, XHC1 -> XHC), 2 Port-Limit-Patches für Catalina, USBInjectAll.kext und SSDT-EC.aml. Prozedur für das Erkennen aller Ports wie gehabt und danach Setzen der richtigen Connector-Typen:



    Dann Export und Reboot mit oben genannten Settings aber folgenden Änderungen: USBInjectAll.kext <-> USBPorts.kext und SSDT-EC.aml <-> SSDT-EC-USBX.aml. Nach Reboot dann folgendes Bild:



    Zustand also unverändert, d.h. Port-Mapping klappt für:

    - USB-Controller mit Connector-Typ "intern"

    - USB2-Geräte mit Connector-Typ "USB2"


    Es funktionieren nicht:

    - BT-Gerät BCM20702A0 mit Connector-Typ "intern"

    - Port-Mapping bei der USB3 Karte (hier funktioniert allerdings schon der Renaming-Patch nicht, ist aber auch egal, interessiert mich nicht)


    Also was mache ich noch falsch, dass das BCM Device nach Setzen des Connector-Types auf "intern" nicht mehr erkannt wird...?

    Muss ich den Port-Limit-Patch nach Erstellen des Mappings wieder deaktivieren?

    Bin etwas ratlos...

  • Hackintool Anleitung USB-Patching in Deutsch

    Ok danke für das Feedback, das einzige was mich jetzt noch brennend interessiert bevor ich den nächsten Anlauf starte sind die Renaming-Patches... brauche ich die und wenn ja warum? (PS: Dein Link zu #12 führt leider ins Leere).

  • Hackintool Anleitung USB-Patching in Deutsch

    Hey cobanramo


    vielen Dank nochmal für die ausführliche Anleitung!!!


    Ich habe versucht mal so eine Grafik zu erstellen wie Du:


    Also ich habe deine Anleitung befolgt: USBPorts.kext und SSDT-UIAC.aml raus, USB-Renames raus, Port-Limit-Patch rein und USBInjectAll.kext rein. USB-Boot-Args habe ich sonst keine. Nicht wundern, falls im Moment die externe USB3-Karte wieder auftaucht, die brauche ich gerade zum arbeiten.


    Hier der Screenshot vom IOACPIPlane:


    Wenn ich bei IOService schaue kann ich keine richtige Port-Nummerierung erkennen, das sieht nicht so geordnet aus wie bei Dir oder den USB3-Devices:


    Wenn ich jetzt das Hackintool öffne alles lösche (Besen) und aktualisiere sieht das ganze so aus (XHC1 ist die USB3-Karte):


    Wenn ich jetzt auf das Spritzen-Symbol drücke zeig sich folgendes Bild:


    Nach Einstecken eines USB2-Sticks in alle USB2-Ports:


    Nach Löschen aller nicht-grünen Einträge:


    Die Connector-Typen würde ich dann so zuordnen:


    Da ich das ganze jetzt ohne Renaming-Patch durchgeführt habe, bin ich nicht sicher ob das so richtig ist, dass die IOUSBHostDevices die Ports 0x01 mit PR01 und PR10 belegen und zwei andere Anschlüsse ebenfalls den Port 0x01 aber mit HP11/HP21.


    Wofür ist der Renaming-Patch gut, brauche ich den für die Erstellung des Port-Mappings? Dann würde ich das ggfls. nochmal so wiederholen und die wieder aktivieren:


    Drücke ich jetzt im Hackintool auf Export werden eine USBPorts.kext, SSDT-UIAC.aml/.dsl und SSDT-EC-USBX.aml/.dsl generiert. Ich würde dann den USBPorts.kext mit USBInjectAll.kext tauschen. Eine SSDT-EC.aml habe ich immer drin, da sonst mein System nicht startet.


    Die SSDT-UIAC.aml kann ich anstelle des USBPorts.kexts verwenden richtig? Aber wofür ist die SSDT-EC-USBX.aml gut? Ich habe mal was von Strom-Versorgung der USB-Ports gelesen...?


    LG

  • Hackintool Anleitung USB-Patching in Deutsch

    Hey Coban, vielen Dank für die ausführliche Info. Die internen USB3 habe ich deaktiviert, da sie mit GenericUSBXHCI.kext wohl nur bedingt zum laufen gebracht werden können -> siehe hier.


    Der Portlimit-Patch dachte ich sei notwendig bei Erstellung des Port-Mappings. Ja die internen Anschlüsse sind auch belegt, an USB1314 hängt die BT-Karte, mit USB1112 werden 2x USB2 ans Front-Panel geführt, und an USB910 hängt ein Card-Reader mit 1x USB2. Ich habe mal versucht die Konfiguration zu skizzieren:



    Also so wie ich das sehe müsste die Konfiguration korrekt sein, warum wird die BT-Karte aber nicht mehr erkannt wenn sie als intern deklariert ist...?

  • High Sierra auf P8P67-PRO

    Hey Mocca55 danke für die Antwort.


    Ich bin mittlerweile schon einen Schritt weiter, ich habe es geschafft ein funktionierendes Port-Mapping zu erstellen (Link). Wenn ich den Anschluss der BT-Karte jedoch als intern deklariere wird sie nicht mehr erkannt. Deklariere ich sie als USB2 wacht er wieder auf. Ich komme einfach nicht weiter. Ich würde eigentlich gerne auf eine BCM94360CS2 wechseln, aber auch dafür muss das Port-Mapping ja funktionieren.


    Mach Dir keinen Stress, aber falls Du noch Ideen hast freue ich mich natürlich :D

  • Hackintool Anleitung USB-Patching in Deutsch

    Also ich habe die USB3-Karte jetzt ausgebaut und widme mich erstmal nur USB2. Die Renames scheinen zu passen, die beiden Controller heißen EUSB (Back-Panel) und EHC2 (Internal). Die Renames funktionieren auch, im Hackintool werden die Controller mit dem geänderten Namen angezeigt: EUSB -> EH01, EHC2 -> EH02 (wenn die Rename-Patches aktiv sind).


    Wie ist das mit dem Connector-Typ, muss alle aktiven Ports des Controllers als intern deklarieren oder reicht es aus das für die BT-Karte zu tun? In der Anleitung steht die Port-Renames müssen danach wieder raus, leider funktioniert dann wie gesagt das Port-Mapping nicht mehr.


    Wie ist das mit dem Port-Limit-Removal-Patch. Bleibt der drin oder muss der auch raus?


    EDIT1:

    Ich habe es jetzt gerade nochmal versucht und sowohl IOUSBHostDevices als das BCM-Device (BT) als intern deklariert. Das Port-Mapping scheint zu funktionieren, beide Controller werden als intern erkannt, die USB-Ports am betreffenden Controller (EH02) gehen auch, leider wird das BCM-Device nun nicht mehr erkannt. cobanramo hast Du eine Idee woran das liegt? Ich mache das ganze Port-Mapping ja nur für dieses Gerät...


    Screenshots von vor dem Export (links) und nach erfolgreichem Mapping (rechts):



    EDIT2:

    Ich habe nochmal ein neues Port-Mapping erstellt, diesmal habe ich nur die Controller als intern deklariert und das BCM-Device als USB2 gelassen. Das Port-Mapping funktioniert weiterhin (USBInjectAll.kext durch generierte USBPorts.kext ersetzt) und die BT-Karte wird jetzt auch wieder erkannt. Leider wacht das System nun wieder aus dem Standby auf. Irgendwie drehe ich mich hier im Kreis. Das BT-Gerät muss ja als intern definiert werden damit das aufhört.

  • Hackintool Anleitung USB-Patching in Deutsch

    Hmm also ich habe keine uia_exclude/include boot args verwendet, da das Mapping eigentlich nur für USB2 Geräte relevant ist, die internen USB3-Ports habe ich im bios deaktiviert. Ich habe allerdings noch eine USB3-Karte von Inateck verbaut, die ootb funktioniert. Hier funktioniert allerdings der rename patch von XHC1 zu XHC/XHC_ nicht. Muss die Karte berücksichtigt werden?

    Die Clover renames (XHC, EH01, EH02) habe ich weiter drin gelassen, da sonst das Port Mapping nicht mehr funktioniert... Ich habe die PDF Anleitung befolgt, die Anleitung vom Hackintool und die oben diskutierten Varianten...


    Also damit ich den Prozess verstanden habe: der Port-Limit-Patch hebt das port limit von 15 auf, der USBInjectAll.kext bindet alle verfügbaren USB-Controller beim Boot-Vorgang ein. Der Port-Rename ist irgendwie notwendig, damit das Hackintool (mit den uia_excludes) die entsprechenden USB2/3 ports zuordnen kann? Nach Löschen der Einträge auf 15 grüne (aktive) ports wird dann ein Patch entweder in Form eines codeless kext oder als .aml-Datei erstellt, welche dann beim Boot für die entsprechende Zuordnung der USB-Ports sorgen. D.h. eigentlich müssten dann port-limit-patches und port-renames wieder entfernt werden können oder?

  • Hackintool Anleitung USB-Patching in Deutsch

    Hey ich bin etwas am verzweifeln bei der Erstellung eines funktionierenden USB-Port Mappings. Die internen USB-Anschlüsse (USB 2.0 Controller) müssen korrekt erkannt werden, damit die Bluetooth-Karte aufhört das System aus dem Standby zu wecken. Ich glaube ich habe mittlerweile alles mögliche versucht.


    Aktuelle Bios USB-Settings (alles auch schon deaktiviert probiert):

    - Antiquitierte USB-Unterstützung: aktiviert

    - USB3.0 Unterstützung: aktiviert

    - EHCI Hand-off: aktiviert


    Aktuelle OS X Version: 10.15.3


    Es ist eine SSDT-EC.aml in Einsatz, da seit Catalina das System sonst nicht mehr bootet.


    Ich habe es nun endlich geschafft ein port-mapping zu erstellen das auch angewendet wird und zwar mit folgender Reihenfolge:


    1. Boot mit 'controller renames', 'port limit removal patch' und USBInjectAll.kext

    2. Hackintool Inject-Button drücken

    3. USB-Stick in alle USB-Ports gesteckt

    4. Alle nicht-grünen Einträge gelöscht (es bleiben 15 übrig)

    5. Korrekte Anschluss-Typen für alle USB-Controller gewählt

    6. Hackintool Export-Button gedrückt

    7. Reboot mit exportierter USBPorts.kext anstelle von USBInjectAll.kext ('controller renames' und 'port limit removal patch' weiterhin aktiv)


    Der Controller wird nun auch als intern erkannt, leider funktioniert keins der an ihm angeschlossenen Geräte mehr. Ich habe schon alle anderen Varianten probiert (boot ohne 'controller renames', boot ohne 'port limit removal patch, boot mit SSDT-EC-USBX.aml und SSDT-UIAC.aml anstelle von USBPorts.kext) bei jeder anderen Variante funktioniert das Port-Mapping nicht mehr.


    Hat jemand eine Idee?

  • High Sierra auf P8P67-PRO

    Vielen Dank für den Hinweis, ich benutze eine BroadCom BCM4352 BCM94352Z WiFi Karte. Nachdem ich Sie ausgebaut hatte, funktioniert der wake nach sleep wieder. Also hab ich sie wieder eingebaut und bin auf Fehlersuche gegangen.


    Mein bisheriges Setup lief mit Lilu.kext, AirportBrcmFixup.kext, FakePCIID.kext, Clover -> Acpi -> Fixes -> FixAirport, Clover -> Devices -> Fake ID -> WIFI -> 0x43A014E4


    Ich bin nochmal dem Broadcom WiFi/Bluetooth [Guide] gefolgt, der ist leider nicht mehr up to date, die neuste Version wird mit 10.14 beziffert. Jedoch führ er eigentlich direkt zu acidanthera/AirportBrcmFixup daraufhin habe ich alle dort angegebenen Installations-Methoden mal durchgespielt.


    Meine Konfiguration scheint bis auf FakePCIID.kext dem empfohlenen Setup zu entsprechen. Ich habe alle anderen Kombinationen ausprobiert

    - mit/ohne FixAirport

    - mit/ohne Fake ID

    - mit/ohne FakePCIID.kext

    - mit FakePCIID.kext und FakePCIID_Broadcom_WiFi.kext

    - mit FakePCIID.kext und BroadcomWiFiInjector.kext

    das Ergebnis ist eigentlich immer gleich: Freeze nach dem Wakeup, mal sehe ich den Desktop, mal nur schwarz mit Mauszeiger. Nach dem Neustart habe ich immer den com.apple.driver.AirPort.BrcmNIC im Backtrace.


    Ich habe auch mal den bootflag brcmfx-driver=2 versucht nachdem ich auf reddit gelesen habe dass die BCM94352Z Karte den AirPortBrcm4360 kext braucht, leider ohne Erfolg. Lasse ich den AirportBrcmFixup.kext jedoch weg, geht das WiFi nicht mehr.


    Ich bin der Meinung, dass ich ziemlich zu Anfang einen funktionierenden Test hatte, nach Entfernen der Fake ID und Hinzufügen des FakePCIID_Broadcom_WiFi.kext, jedoch scheint das ein glücklicher Zufall gewesen zu sein, das Verhalten ist nicht reproduzierbar. Ich bekam danach sogar ein paar mal noch andere Informationen im Backtrace (z.B. mp_kdp_enter() timed-out during locked wait after NMI) allerdings bei den letzten 10+ Tests sehe ich immer den BrcmNIC im backtrace.


    Ich bin etwas ratlos und weiß nicht mehr weiter, griven hast Du noch einen Tip?


    EDIT: Nachdem ich das vorhandene Display-Setup geändert habe, musste ich die Grafikkarte wechseln (Nvidia -> Radeon). Im Zuge dessen hatte ich noch eine Reihe anderer Probleme zu lösen und habe zum debuggen nochmal einiges an Hardware ausgebaut und kexts deaktiviert.

    Beim re-aktivieren habe ich den Fehler dann gefunden: es lag tatsächlich am AirportBrcmFixup.kext, ursprünglich hatte ich nur FakePCIID.kext und FakePCIID_Broadcom_WiFi.kext im Einsatz. Damit funktioniert es jetzt auch wieder, der AirportBrcmFixup.kext ist mir beim Upgrade auf Catalina irgendwie reingerutscht... griven danke für den Tipp in die korrekte Richtung!

  • High Sierra auf P8P67-PRO

    Ein neues Problem was mit dem Update auf Catalina aufgetaucht ist: nach dem Aufwachen aus dem Standby friert das System ein. Ich habe schon nach Lösungen gesucht, die meisten Vorschläge sind das Deaktivieren von HDMI-Audio bei Benutzung von AppleALC. Ich benutze allerdings VoodooHDA, daher sollte das Problem woanders her kommen... hat jemand eine Idee? Der BT-Connector der Broadcom-Karte ist weiterhin nicht verbunden, ich benutze immer noch den USB-BT4.0-Stick von Plugable als Notlösung damit der Rechner überhaupt in Standby bleibt.


    Hier mal der Error-Log

  • High Sierra auf P8P67-PRO

    Hey Mocca55


    ich habe jetzt ein Upgrade auf Catalina vorgenommen. Nachdem BT erstmal nicht mehr ging, habe ich den BrcmPatchRam kext von RehabMan mit dem von acidanthera ersetzt: https://github.com/acidanthera/BrcmPatchRAM.


    Bluetooth funktioniert jetzt wieder und die USB-Ports werden auch alle richtig erkannt:

    Das Problem mit dem Wake aus Standby besteht allerdings weiter, vielleicht liegt es doch nicht am USB? Wie kommst Du auf die Idee mit der iGPU? Wenn ich den Bluetooth-USB-Connector aber vom Mainboard abziehe funktioniert der Standby, es muss am USB liegen...