Dennis HilkLinux-DiagnoseEN

Bluetooth

Bluetooth-SDIO-HCI-Transportkontext

Generischer Bluetooth-HCI-Transport über SDIO. Eingebettete SDIO-Funktionen liegen normalerweise außerhalb von PCI- und USB-Inventaren.

Redaktionelle Quellenprüfung: Öffentliches Profil teilenIm Erkennungswerkzeug öffnen
Auf dieser Seite
  1. Überblick und Identität
  2. Treiber und Bindung
  3. Firmware
  4. Lesende Diagnose
  5. Grenzen und passende Fehlerhilfen
  6. Quellen

Überblick und Identität

Die btsdio-Tabelle gleicht Bluetooth-SDIO-Klassen A und B ab. Dies ist nur Protokoll-/Klassenkontext und bestimmt keine Marvell- oder MediaTek-spezifische Implementierung.

Dies ist ausdrücklich ein Klassen-, Transport- oder Treiberkontextprofil. Es identifiziert kein exaktes numerisches Produkt.

Ein numerischer Match belegt eine Kandidatenfamilie im geprüften Quellenrahmen. Verkaufsnamen, Platinenvarianten, Subsystembedingungen und erfolgreiche Funktion bleiben getrennte Fragen.

Treiber und Bindung

btsdio stellt generische SDIO-HCI-Paketverarbeitung bereit. Hersteller-SDIO-Treiber sind eigene Pfade; eine fehlende USB-Bluetooth-Schnittstelle beweist kein fehlendes Bluetooth einer Platine.

  • btsdio — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Geräte- und revisionsabhängig

Der generische Transport legt keinen universellen Host-Firmware-Dateinamen fest. Ein Herstellercontroller oder eine Plattform kann einen eigenen Loader benötigen.

Firmwarepakete deiner Distribution prüfen

Lesende Diagnose

Führe jeden angezeigten Befehl einzeln aus. Ersetze Großbuchstaben-Platzhalter durch betroffenes Gerät, Schnittstelle oder Modul aus deiner Ausgabe. Hier wird nichts ausgeführt. Auch lesende Ausgaben können private Kennungen enthalten.

Übergeordneten Controller-Pfad lesen

readlink -f /sys/class/bluetooth/CONTROLLER/device

CONTROLLER durch den lokalen hci-Namen aus /sys/class/bluetooth ersetzen, etwa hci0. Der Pfad hilft, USB-, serielle und SDIO-Elterngeräte zu unterscheiden. Er belegt nicht das aktive UART-Protokoll. Keine Root-Rechte nötig.

Für BlueZ sichtbare Controller lesen

bluetoothctl list

Diese Abfrage liest dem BlueZ-Daemon bekannte Controller ohne Suche oder Kopplung. Eine leere Antwort kann neben fehlenden Controllern auch Daemon- oder D-Bus-Zugriffsprobleme bedeuten; Kernel-Erkennung vergleichen. Normalerweise keine Root-Rechte nötig.

Controller-Initialisierung lesen

journalctl -k -b --no-pager

Kernel-Meldungen dieses Starts für Controller, angeforderte Firmware und Initialisierung lesen. Journal-Sichtbarkeit hängt von lokalen Rechten ab; ein unlesbares Protokoll beweist keine Fehlerfreiheit. Dieser Befehl verändert das Gerät nicht.

Grenzen und passende Fehlerhilfen

PCI-/USB-Berichte allein bestimmen dieses Profil nicht. SDIO-Elterninformationen, tatsächliche Bindung und Controller-Registrierung sind nötig; keine genauen Gerätekennungen oder Firmware-Dateien werden abgeleitet.

Diese Anleitungen passen zu relevanten Befunden und behaupten keinen Fehler bei jedem Gerät dieser Familie.

Hardware-Diagnoseweg wählen · Log-Auszug im Fix Lab prüfen

Quellen

Eine Quellenprüfung hält geprüfte Implementierung oder Dokumentation fest, keinen reproduzierten Hardwaretest. Versionsbezogene Tabellen belegen weder Mindestkernel noch garantierte Funktion.