Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

rpi5: onboard Bluetooth over uarta — bcm7271 UART compat, brcmstb-gpio, bcm2712-pinctrl, an H4 transport on ttyhook, BCM4345C0.hcd patchram (parked)

Aperta
#233 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c

Direzione di ricerca

Start with K7's measurements, then read uart_dev_ns8250.c, uart_bus_fdt.c, config/NEXTBSD-RPI5, and the related RP1 patches. Compare releng/13.5's sys/netgraph/bluetooth/drivers/h4/ng_h4.c with sys/netgraph/ng_tty.c before assessing the required UART, GPIO, pinctrl, H4, patchram, and bluetoothd work. Done means the listed hardware, firmware, licensing, and Bluetooth acceptance checks pass on a Pi 500+.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area:bluetooth area:rpi5 enhancement needs-hardware status:parked

E16 draft id K8 · epic nextbsd/nextbsd#473

Problem

The Pi 5 / Pi 500 have a Bluetooth 5.0 radio in the CYW43455 combo chip, attached over a SoC UART, not USB. FreeBSD 15.1 supports none of the path, so E16 on these boards means a USB dongle (K6). Filed so the scope is on record and nobody promises the onboard radio.

What is missing (all of it, with evidence)

Layer 15.1 state
UART uarta: serial@7d50c000 { compatible = "brcm,bcm7271-uart"; reg-shift=<2>; reg-io-width=<4>; } (rpi-6.6.y bcm2712.dtsi:510-519), 96 MHz, auto-flow-control, max-speed = 3000000 uart_dev_ns8250.c's FDT table is ns16550/ns16550a only (:527-528) and the node has no such fallback; no uart_dev_bcm7271.c exists. reg-shift/reg-io-width are honoured generically (uart_bus_fdt.c:87,96), so a compat entry + rclk may give basic 8250 TX/RX; the bcm7271 auto-flow and 3 Mbaud behaviour is unknown
BT_ON shutdown-gpios = <&gio 29> on brcm,brcmstb-gpio @7d508500 No brcmstb GPIO driver in sys/dev/gpio/ or files.arm64; the only Broadcom GPIO drivers are 2837/2838-gated and NEXTBSD-RPI5 turns those SoC options off (config/NEXTBSD-RPI5:63-64). RP1's GPIO (patch 0025/0048) is a different block
Pinmux uarta_24_pins (gpio24 RTS, gpio25 CTS, …) + bt_shutdown_pins on brcm,bcm2712-pinctrl @7d504100 No driver
H4 transport ng_h4 removed 2021-09-05 (commit 79a100e28e: "disconnected 13 years ago … completely fails to compile … Bluetooth has largely moved on from UART transport"); hcseriald removed (66d6299848). The 13.5 source (sys/netgraph/bluetooth/drivers/h4/ng_h4.c, 1019 lines) is a pre-2008 linesw line discipline (:98-107); a rewrite would follow ng_tty(4)'s ttyhook model (sys/netgraph/ng_tty.c:47,116-121), which is alive in 15.1. The NETGRAPH_BLUETOOTH_H4 option token still exists (sys/conf/options:521) but gates nothing
Patchram Linux btbcm downloads BCM4345C0.hcd (63,806 bytes; RPi-Distro/bluez-firmware debian/firmware/broadcom/) over HCI vendor commands (download-minidriver 0xFC2E, the .hcd records, baud update 0xFC18) before the stack starts. FreeBSD has never had a Broadcom UART patchram tool. Licence: Cypress "WIRELESS CONNECTIVITY DEVICES DRIVER END USER LICENSE AGREEMENT", Debian non-free-firmware; Raspberry Pi states it is released "on the expectation that we will release them to our users" (debian/copyright:19-131) — shippable with the notice, like LICENCE.broadcom already is (nextbsd/build.sh:480-482)
BD address DT local-bd-address is zeros; the Pi firmware patches it in and Linux applies it with vendor cmd 0xFC01. Without it every board shares the ROM default
Ownership hcseriald's job (open the tty, set 3 Mbaud + CRTSCTS, push the line discipline/hook, hand the node to the stack) has no owner; it would be bluetoothd's, per-board, on arm64 only

The route (if/when it is picked up)

  1. K7's measurements first.
  2. uart_dev_ns8250.c: add {"brcm,bcm7271-uart", …} with the measured rclk (or a uart_dev_bcm7271.c if auto-flow needs its registers). Baked into NEXTBSD-RPI5; a kext cannot deliver it (no bus to match it from, and the DT child bluetooth node is never a newbus device).
  3. If K7 says so: brcmstb-gpio and bcm2712-pinctrl drivers (gpiobus/fdt_pinctrl), following the RP1 patches' shape.
  4. ng_h4 rewritten on ttyhook (≈1k LOC; the 13.5 file is the spec for the framing/state machine).
  5. A ≈300-line bcmpatchram in base-style C (not the GPL brcm_patchram_plus) that speaks the H4 framing over the tty before the node is attached, plus the .hcd shipped under /usr/share/firmware/bluetooth/brcm/ with the Cypress licence (K3's directory).
  6. bluetoothd learns a "uart adapter" kind: open /dev/cuau<N>, patchram, set bdaddr, attach H4, then the same bluetooth_setup_stack() as USB.

Acceptance (for the eventual implementation)

  • hccontrol -n <node> read_bd_addr on a Pi 500+ returns the board's own address over the onboard radio
  • l2ping and sdpcontrol browse against a phone succeed; results in the hardware matrix (K6)
  • All kernel pieces are in config/NEXTBSD-RPI5 or the patch series with the usual measured-on-the-board comments
  • The firmware and licence ship under /usr/share/firmware/bluetooth/brcm/
  • Nothing here is required for E16's USB path (K1–K6), which must keep working on the Pi with a dongle

Related

  • K1, K6, K7; nextbsd/nextbsd#440 (E7), #473 (E16), #99 (BCM43455 WiFi/SDIO — same chip, separate interface, no shared code)
  • FreeBSD commits 79a100e28e, 66d6299848 (removals); releng/13.5 sys/netgraph/bluetooth/drivers/h4/

Dependencies (E16)

  • Depends on: nextbsd/nextbsd-kernel#231 (K1), nextbsd/nextbsd-kernel#232 (K7)
  • Blocks: nothing

Draft ids (K = kernel & hardware, B = engine/BLE, D = bluetoothd/CLI, H = HID, A = audio) are listed with their issue numbers in nextbsd/nextbsd#473.

Lingua principale
C
Stelle
12
Fork
3
Merge medio
1h 33m
PR unite (30g)
58

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextbsd/nextbsd-kernel

Tutte le issue di nextbsd/nextbsd-kernel

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.