From ee1dec299d5fc5a4a172852f6ae04bd13b63e69a Mon Sep 17 00:00:00 2001 From: Vasilito Date: Fri, 17 Apr 2026 13:33:29 +0100 Subject: [PATCH] Update Bluetooth driver and validation Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus --- local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md | 19 ++++++++++--------- local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md | 9 +++++++-- .../recipes/drivers/redbear-btusb/recipe.toml | 11 ++++++++--- .../redbear-btusb/source/10_btusb.service | 9 +++++++++ 4 files changed, 34 insertions(+), 14 deletions(-) create mode 100644 local/recipes/drivers/redbear-btusb/source/10_btusb.service diff --git a/local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md b/local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md index a1f73415..a8f229d2 100644 --- a/local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md +++ b/local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md @@ -27,10 +27,10 @@ This repo should not treat planned scope as equivalent to implemented support. Broad Bluetooth support is still **missing** in Red Bear OS, but the repo now carries one bounded experimental first slice. -That bounded slice is now **QEMU-validated for its claimed scope** through the packaged -`redbear-bluetooth-battery-check` helper and the host-side -`./local/scripts/test-bluetooth-qemu.sh --check` harness. That validation is still narrow and does -not promote the repo to generic Bluetooth maturity. +That bounded slice now has a packaged in-guest checker (`redbear-bluetooth-battery-check`) and a +host-side QEMU harness (`./local/scripts/test-bluetooth-qemu.sh --check`). That QEMU validation +path is still being stabilized, so it should currently be described as **QEMU validation in +progress**, not as already validated for its claimed scope. That first in-tree slice is deliberately narrow: @@ -75,7 +75,7 @@ one more driver.” The feasible first target is a deliberately small subsystem | Area | State | Notes | |---|---|---| | Bluetooth controller support | **experimental, USB discovery real** | `redbear-btusb` now probes `/scheme/usb/` for real Bluetooth class devices (USB class 0xE0/0x01/0x01 with vendor-ID fallback), parses descriptor files, assigns `hciN` names deterministically, and writes real adapter metadata into the status file. Daemon re-probes periodically. 8 tests pass including mock-filesystem USB discovery tests. | -| Bluetooth host stack | **experimental bounded slice** | `redbear-btctl` provides a BLE-first CLI/scheme surface with stub-backed scan plus bounded connect/disconnect control for stored bond IDs; the packaged checker now reruns that slice repeatedly and covers daemon-restart honesty in QEMU | +| Bluetooth host stack | **experimental bounded slice** | `redbear-btctl` provides a BLE-first CLI/scheme surface with stub-backed scan plus bounded connect/disconnect control for stored bond IDs; the packaged checker and QEMU harness now exist for repeated guest validation, but the end-to-end QEMU proof is still in progress | | Pairing / bond database | **experimental bounded slice** | `redbear-btctl` now persists conservative stub bond records under `/var/lib/bluetooth//bonds/`; connect/disconnect control targets those records, and the checker now verifies cleanup honesty, but this is still storage/control plumbing only, not real pairing or generic reconnect validation | | Desktop Bluetooth API | **missing** | D-Bus exists generally, but no Bluetooth API/service exists | | Bluetooth HID | **missing** | Could later build on input modernization work | @@ -595,8 +595,9 @@ expects them instead of importing a whole foreign subsystem model blindly. **Current in-tree interpretation**: -- the repo now satisfies the narrower QEMU-scoped version of this exit criterion for one packaged, - stub-backed Battery Level workload on `redbear-bluetooth-experimental` +- the repo now has the packaged checker and QEMU harness needed to satisfy the narrower + QEMU-scoped version of this exit criterion for one stub-backed Battery Level workload on + `redbear-bluetooth-experimental`, but that QEMU proof is still in progress - it does **not** satisfy a broader real-hardware or generic BLE exit criterion yet ## Support-Language Guidance @@ -629,8 +630,8 @@ BLE-first, profile-scoped to `redbear-bluetooth-experimental`, with conservative persistence rooted at `/var/lib/bluetooth//bonds/` plus bounded connect/disconnect control that only targets those stored stub bond IDs, plus one experimental battery-sensor Battery Level read result for the exact Battery Service / Battery Level UUID pair above. That slice can now be -built, booted in QEMU, exercised by the packaged `redbear-bluetooth-battery-check` helper, rerun in -one boot, and rerun after a clean reboot without changing the bounded support claim. +built, booted in QEMU, and exercised by the packaged `redbear-bluetooth-battery-check` helper; the +repeated end-to-end QEMU proof is still being stabilized before it should be described as validated. What makes it feasible is not any existing Bluetooth stack, but the surrounding Red Bear architecture: userspace daemons, runtime services, diagnostic discipline, profile-scoped support diff --git a/local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md b/local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md index 6ff4c283..630f26f4 100644 --- a/local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md +++ b/local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md @@ -4,7 +4,8 @@ This runbook is the canonical operator path for exercising the current bounded B Level slice on Red Bear OS. It does **not** claim that Bluetooth is broadly solved. Its job is to make the current -profile-scoped, QEMU-validated Battery Level workload reproducible and honest. +profile-scoped Battery Level workload reproducible and honest while QEMU validation is still being +brought to a passing state. ## Goal @@ -31,7 +32,7 @@ Then run the automated QEMU harness: ./local/scripts/test-bluetooth-qemu.sh --check ``` -What that harness does today: +What that harness is intended to do: 1. boots `redbear-bluetooth-experimental` in QEMU with `qemu-xhci` 2. logs in automatically on the serial console @@ -87,6 +88,10 @@ Current success is still **bounded** success: - the exact Battery Service / Battery Level UUID pair can be read through the bounded read-only workload and reported conservatively by `redbear-info` +Those are the **target** success conditions for the current QEMU proof. Until the harness exits +cleanly end to end, describe the validation state as “QEMU harness and packaged checker present, +validation still in progress.” + This is **not yet** the same as: - real controller bring-up proof diff --git a/local/recipes/drivers/redbear-btusb/recipe.toml b/local/recipes/drivers/redbear-btusb/recipe.toml index 7fe1ab5a..980dacf3 100644 --- a/local/recipes/drivers/redbear-btusb/recipe.toml +++ b/local/recipes/drivers/redbear-btusb/recipe.toml @@ -2,7 +2,12 @@ path = "source" [build] -template = "cargo" +template = "custom" +script = """ +set -ex -[package.files] -"/usr/bin/redbear-btusb" = "redbear-btusb" +cookbook_cargo + +mkdir -pv "$COOKBOOK_STAGE/usr/lib/init.d" +cp -v "$COOKBOOK_SOURCE/10_btusb.service" "$COOKBOOK_STAGE/usr/lib/init.d/10_btusb.service" +""" diff --git a/local/recipes/drivers/redbear-btusb/source/10_btusb.service b/local/recipes/drivers/redbear-btusb/source/10_btusb.service new file mode 100644 index 00000000..53dba3b9 --- /dev/null +++ b/local/recipes/drivers/redbear-btusb/source/10_btusb.service @@ -0,0 +1,9 @@ +[unit] +description = "Bluetooth transport daemon" +requires_weak = [ + "05_firmware-loader.service", +] + +[service] +cmd = "redbear-btusb" +type = "oneshot_async"