Dennis HilkLinux-DiagnoseEN

Bluetooth

Qualcomm-Bluetooth-UART-Familienkontext

Kontext für serielle Qualcomm-Bluetooth-Familien mit Herstellerstart, Baudratensteuerung und Firmware-/NVM-Laden. Die Identität kann aus ACPI oder Device Tree statt PCI-/USB-Kennungen stammen.

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

Dieses generische Profil umfasst nur den belegten QCA-UART-Pfad. hci_uart oder btqca bestimmt keinen konkreten QCA-/WCN-Chip und keine Platine.

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

hci_qca ist in diesem Quellstand ein Bestandteil von hci_uart; btqca stellt Firmware-Hilfen bereit. Gerätebeschreibung, Controller-Version und Platinendaten präzisieren den Initialisierungspfad.

  • hci_uart — Kernel-Treiber-/Modulkandidat
  • btqca — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Geräte- und revisionsabhängig

Die Quelle besitzt chip-/versionsspezifische Patch- und NVM-Namenszweige. Diese zwei geprüften Muster sind Beispiele, keine universellen Anforderungen oder Platinendatenauswahl.

Geprüfte Beispiele oder Dateinamen-Zweige, keine vollständige Installationsliste:

  • qca/rampatch_*.bin
  • qca/nvm_*.bin

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

Die rampatch-/nvm-Muster sind Beispiele eines Hilfszweigs; andere Qualcomm-Generationen nutzen andere Namen. Ein sichtbares serielles Elterngerät belegt kein erfolgreiches Firmware-Laden.

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.