Bluetooth lässt sich nicht aktivieren [gelöst]

Es spielt insofern eine Rolle, als das es korrekt, idealerweise schon vom Hersteller, deklariert werden kann. Wie geschrieben, in der ACPI festgelegt, in der Dokumentation mit Beispielen durchexerziert. Was macOS aktuell mit diesen Standards macht, weiß ich in der Tat nicht. Kann mich aber sehr genau daran erinnern, dass das mal eine Rolle spielte. Explizit nur interne USB2 Hubs. Auch die selbst waren als intern deklariert. Zumindest hat man gesehen, das daran (am Hub) verschiedene Treiber hingen. Bei internen ein anderer, unter macOS. Diese Unterteilung gab es wie gesagt nur für USB2 Hubs. Bei USB3 war es immer der gleiche.

Wurscht. Wenn du sagst, spielt aktuell keine Rolle mehr, um so besser. Setzt sich ja eh keiner mehr mit der ACPI auseinander. 😀

apfelnico Ich musste neulich wieder mal in die ACPI-Spezifikationen reinschauen, weil seit Sequoia das USB-Mapping bei meinem Board nicht mehr richtig funktionierte. Konkret geht es da um folgende zwei Methoden:

• _UPC: USB Port Capabilities: Definiert, ob der Port physisch vorhanden ist (connectable) und um welchen Typ von Port es sich handelt.
• _PLD: Physical Location of Device: Gibt an, ob der Port intern oder von außen zugänglich ist (user visible) und wo sich dieser Port befindet.

Was diese beiden Methoden zurückliefern ist entscheidend dafür, ob macOS den Port überhaupt erkennt, aber ansonsten schert sich macOS herzlich wenig um diese Werte, insbesondere nicht, ob der Port hier als intern oder extern markiert ist. Daher müssen wir ja immer noch eine Kext für das USB-Mapping erstellen und erst wenn der Port dort als intern (0xff) markiert wird, dann erkennt macOS ihn als internen Port an und du kannst deinen BT-Dongle an diesem Port problemlos betreiben.

Das Teil sitzt n.m.K. in einem miniPCIe-Port? Dann benötigt es einen DP-Eintrag der etwa so aussehen müsste:

und dazu AiportBrcmFixup.kext fürs WLAN. Der Passende IOReg IOName für compatible ist im Hackintool zu finden und muss hier nicht übereinstimmen.

BT braucht je nach MacOS unterschiedliche Kext

Gefunden in einer alten EFI zum T430, welches jetzt schon längere Zeit bestens mit AX210 löpt. Deshalb kann ich das jetzt nicht reproduzieren. Die Beschreibung zu den passenden BRCM-Kexten ist allerbestens bei Github und Acidanthera beschrieben (aus der Erinnerung)

Im HackinTool ist nicht nur der IUSBHostdevice wichtig, sonder da muss auch BCM435x zu sehen sein. Insoweit passt das Setup von TheSnooze noch nicht.

Für das mapping und den Port Typ ist nur _UPC relevant. _PLD bezieht sich tatsächlich nur auf die Position des physischen Ports am Gerät - quasi Kosmetik.

Quote from TheSnooze

Moinsen!

Ich habe vor kurzem von 11.7.10 auf 13.7.5 gewechselt und bin schon etwas enttäuscht wie schlecht alles geworden ist... Angefangen damit, daß mein Bluetooth-Dongle plötzlich

sorry, wer lesen kann ist klar im Vorteil. Ich habe das irgenwie übersehen. USB Dongle braucht natürlich keinen DP Eintrag.

Wieso keine Port-Probleme?

Klar hast du Port-Probleme.

Connector-Type bei Bluetooth steht auf "USB3" anstatt auf "Internal".

Das kann man ganz fix mit einem Plist-Editor ändern.

Schick mal deine USB-Kext oder mach das selbst.

Bei meinem Hackintosh sind sämtliche Anschlüsse für Dongles auf "Internal".

es ist ein USB-Dongle bluebyte müsste der evtl. auf USB2 stehen?

Was zeigt HackinTool zur Peripherals? TheSnooze

Arkturus ich möchte mich hier nicht in die Nesseln setzen. Jetzt, wo du es sagst.

Eigentlich sehe ich da mehrere Fehler. Müsste bei HS sowieso nicht USB2 stehen?

Ich kann mich dunkel erinnern an eine andere Diskussion hier im Forum.

Dazu gab es damals gegensätzliche Meinungen beim Connector-Type.

Deshalb möchte ich mich jetzt nicht allzu weit aus dem Fenster lehnen.

Ohne, dass ich hier jemanden auf den Schlips treten möchte.

Mieze und apfelnico wissen da sicherlich besser bescheid.

bluebyte Gut, dass Du noch mal darauf hinweist!

TheSnooze Beim "Connector Type" muss immer:

• HSxx: USB2.0 (0x00, einzige Ausnahme ist der HSxx-Port mit dem BT-Dongle, denn dort muss "internal" d. h. "0xff" als Connector-Type eingetragen werden)
• SSxx: USB3.0 (0x03, sofern es sich nicht um einen Typ-C-Port handelt)

Der Begriff "Connector Type" ist auf den ersten Blick etwas verwirrend, da SS-Ports immer mit einem HS-Port kombiniert sind, mag man spontan versucht sein den HS-Port auch als 0x03 zu definieren, denn es ist ja die gleiche Buchse. Elektrisch gesehen handelt es sich bei einer USB3-Buchse jedoch um zwei unabhängige Anschlüsse, wobei der USB2-Anschluss die Pins 1-4 und der USB-3-Anschluss die Pins 5-9 der Buchse belegen.

Quote from Mieze

Was diese beiden Methoden zurückliefern ist entscheidend dafür, ob macOS den Port überhaupt erkennt, aber ansonsten schert sich macOS herzlich wenig um diese Werte, insbesondere nicht, ob der Port hier als intern oder extern markiert ist.

Selbstverständlich "schert" sich macOS darum. Wenn korrekt definiert, bedarf es keiner Kext.

Quote from Mieze

Der Begriff "Connector Type" ist auf den ersten Blick etwas verwirrend, da SS-Ports immer mit einem HS-Port kombiniert sind, mag man spontan versucht sein den HS-Port auch als 0x03 zu definieren, denn es ist ja die gleiche Buchse.

Und in diesem Fall auch korrekt, nichts ist daran verwirrend. Lediglich alleinige HSxx werden als 0x00 oder 0xFF, oder Sonderfall, USB-C mit alleinigen USB2 – gibts ne eigene Bezeichnung für, fällt mir gerade nicht ein (Edit: glaube 0x08), kann die nicht alle herbeten.

Ebenfalls bei USB-C mit USB3 und USB2 (Standard). da werden beide(!), also HighSpeed und SuperSpeed (HSxx und SSxx) als 0x09 oder 0x0A (je nach dem, ob switch vorhanden oder oder exklusive Adressleitungen, bezogen auf Verdrehen des Steckers). Niemand kommt da auf die Idee, den USB2-Anteil als 0x00 zu deklarieren. Schau dir dazu Apples eigene(!) DSDT/SSDT an. Ich habe da Beispiele von iMac Pro und Mac Pro Intel, das denke ich mir doch nicht aus. Machen das also Apple und die gesamte PC-Branche falsch, sollte Apple mal hier bei einigen im Forum nachfragen, wie man es richtig macht?

Quote from apfelnico

Selbstverständlich "schert" sich macOS darum. Wenn korrekt definiert, bedarf es keiner Kext.

Das war bei älteren macOS-Version mal so, dass man bei einer korrekten USB-SSDT keine Kext brauchte, aber bei aktuellen macOS-Versionen erfordern viele Boards nun eine zusätzliche Kext, obwohl es früher ohne lief. Im Übrigen dürftest Du nur dann ohne Kext klarkommen, wenn die ACPI-Strukturen fehlerfrei sind und nicht mehr als 15 Ports deklarieren, es sei denn, Du möchtest es dem Zufall überlassen, welche Ports funktionieren.

Quote from apfelnico

Ebenfalls bei USB-C mit USB3 und USB2 (Standard). da werden beide(!), also HighSpeed und SuperSpeed (HSxx und SSxx) als 0x09 oder 0x0A (je nach dem, ob switch vorhanden oder oder exklusive Adressleitungen, bezogen auf Verdrehen des Steckers). Niemand kommt da auf die Idee, den USB2-Anteil als 0x00 zu deklarieren. Schau dir dazu Apples eigene(!) DSDT/SSDT an. Ich habe da Beispiele von iMac Pro und Mac Pro Intel, das denke ich mir doch nicht aus. Machen das also Apple und die gesamte PC-Branche falsch, sollte Apple mal hier bei einigen im Forum nachfragen, wie man es richtig macht?

Meine Aussage bezog sich ausschließlich auf Anschlüsse vom Typ-A und die Mapping-Kext, denn mit den ACPI-Strukturen braucht man sich in den meisten Fälle nicht auseinander setzen. Das hätte ich vielleicht deutlich sagen sollen, aber in der Eile leider vergessen.

Außerdem machst Du hier einen entscheidenden Denkfehler, denn Du wirfst USB-C und USB-A in einen Topf, obwohl sich beide fundamental von einander unterscheiden. Bei USB-A sind HS- und SS-Teil elektrisch von einander unabhängige Ports, die unterschiedliche Leitungen benutzen. Aus diesem Grund kann bei Typ-A der Board-Designer auch die Kombination von HS- und SS-Port auf einem Anschluss nahezu beliebig wählen, weil beide Ports im Prinzip elektrisch voneinander unabhängig sind. Es hat daher keine negativen Auswirkungen, wenn Du in der Mapping-Kext die HS-Ports (Typ-A) grundsätzlich als 0x00 definierst. Hingegen bekommst Du Probleme, falls du einen HS-Port, der keinen SS-Partner hat, als 0x03 definierst. Klar, streng genommen ist das nicht korrekt, aber es funktioniert und ist manchmal sogar erforderlich, wenn ich wegen des Limits von 15 Ports z. B. nur den HS-Teil eines Anschlusses in Betrieb nehmen kann/will.

Quote from Mieze

Hingegen bekommst Du Probleme, falls du einen HS-Port, der keinen SS-Partner hat, als 0x03 definierst.

Völlig richtig, ich schrieb nichts anderes.

Quote from Mieze

Im Übrigen dürftest Du nur dann ohne Kext klarkommen, wenn die ACPI-Strukturen fehlerfrei sind

Schrieb ich ebenfalls, "korrekt" ist doch nicht misszuverstehen. Was beweist, das sich macOS drum "schert". Sei es drum, auch schrieb ich, dass sich heute kaum jemand damit auseinandersetzen möchte (*), es geht ja mit einer Kext. Ich hatte lediglich darauf hingewiesen, dass zusammengehörende Paare von HS/SS gleich deklariert werden, wie man in jeder zugehörigen SSDT sehen kann, unabhängig davon, ob von Mainboardherstellern für eigentlich andere Systeme vorgesehen, oder Apple, weil diese nun nach Standard vorgehen. Wenn man es aus "Gründen" anders machen möchte, bitte schön. Aber nicht als Standard verkaufen, "muss immer so gemacht werden".

*mögliche "fehlerhafte" SSDT zu fixen, weil macOS deren zum Teil komplexen Konstrukte um _UPC/_PLD nicht verstehen mag, weil viele Variablen mit eingebaut sind, die zum Teil aus dem BIOS ausgelesen werden müssen, je nach Stand, welche Ports dort als aktiv definiert sind, sowie diese ACPI ohnehin nicht für exakt ein Board sind, sondern oftmals alle Boards einer Klasse vom Hersteller mit unterschiedlichster Bestückung von USB-Ports. Kann man fixen und direkt deklarieren und ja, 15 Port-Limit sagt mir auch etwas.

Quote from apfelnico

Aber nicht als Standard verkaufen, "muss immer so gemacht werden".

Ich würde es nicht als Standard bezeichnen, eher als pragmatische Lösung, welche maximale Flexibilität ermöglicht und darüber hinaus recht einfach ist.

Quote from apfelnico

Schrieb ich ebenfalls, "korrekt" ist doch nicht misszuverstehen. Was beweist, das sich macOS drum "schert".

Na ja, genau genommen müssen lediglich die beiden Methoden _UPC und _PLD vorhanden sein und ein syntaktisch korrektes Ergebnis liefern. Semantisch reicht es, wenn der Port als "connectable" gemeldet wird. Alles andere ist ziemlich egal und kann ggfs. mit der Kext korrigiert werden.

Man muss auch das richtige SMBIOS eintragen. Vielleicht lädt der TE mal seine kext hier hoch, oder nur die plist.

EDIT: Broadcom-USB-Dongle gibt es glaube ich nicht wie Sand am Meer. Wenn es der IOGEAR ist, den genex hier erwähnte, dann benötigst Du für 13.5.7. neben korrektem USB-Mapping lediglich BlueToolFixup.kext, sonst nix. NVRAM-Patches für USB-Dongle wurden n.m.K. für Intel-AX eingeführt. Kann man haben aber schaden nicht.

EDIT: Am HW-Desktop hab ich mal den USB Port der Fenvi T919 abgezogen und den IOGEAR Dengle unter 15.5 getestet. Der funktioniert mit BlueToolFixup.kext bestens. Sobald BT der Fenvi wieder angeschlossen, übernimmt diese den Dienst.

TheSnooze Ja, genau! Setze HS04 auf internal und dann sollten zumindest USB-seitig alle Voraussetzungen erfüllt sein. Um die übrigen USB-Ports kannst Du dich später kümmern, wenn es da noch Probleme geben sollte.

Bei meinem IOGEAR wird im HackinTool USB2 als Connector angezeigt und unter System/Peripherals als auch im Systembericht unter BT steht THIRD_PARTY_DONGLE

Solange da BCM4350C2 auftauchte hat der Dongle BT nicht geliefert. Erst nachdem ich von der Fenvi T919 den USB-Port am Board abgezogen habe, konnte der der IOGAER den BT übernehmen.

Ist in der Plist unter model das SMBIOS eingetragen?

Wenn alles korrektr ist und du sonst keine anderen BT-Geräte hast, im BIOS ggf. BT auch deaktiviert falls es diese Option gibt, dann muss mal ein Live-Linux oder Windows den BT Dongle in Betrieb nehmen. Mag sein das der durch die frühere Nutzung mit anderen MacOS eine Sperre hat. Da bin ich kein Techniker.

nee, bei mir steht iMacPro1,1 aber du musst dich nach deinem Hacki richten. Ich verwende zur Bearbeitung einen Editor, am besten seinen Plist-Editor deiner Wahl.

Rechtsklick auf die Kext und dann 'Paketinhalt zeigen' auswählen und die Info.plist suchen.. Der Rest ist dann selbsterklärend.