Dennis HilkLinux-DiagnoseEN

Bluetooth

Bluetooth-H4-UART-Transportkontext

Serieller HCI-Transportkontext eines eingebetteten Bluetooth-Controllers. Ein UART-Controller kann vorhanden sein, ohne in lspci oder lsusb zu erscheinen.

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

H4 ist ein UART-Protokoll und keine Hersteller-/Geräteidentität. Dieses Profil ist nur ergänzender Kontext; hci_uart allein bestimmt weder gewähltes Protokoll noch Chip.

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

Die Quelle bindet H4 bei konfigurierter Protokolloption in hci_uart ein. Platinenbeschreibung oder vorhandene serielle Anbindung bestimmt, welches Gerät diesen Pfad erreicht.

  • hci_uart — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Geräte- und revisionsabhängig

H4-Paketformat legt keinen Chip-Firmware-Dateinamen fest. Ein Herstellerpfad kann dennoch Firmware 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

Serielle Schnittstelle oder geladenes Modul beweist keinen Bluetooth-Controller. Takt, Reset, Stromversorgung und Herstellerinitialisierung sind platinenspezifisch und werden hier nicht 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.