docs: comprehensive boot process audit + archive stale plans
BOOT-PROCESS-AUDIT-2026-05-03.md: full daemon-by-daemon review of boot sequence from power-on to login prompt. Covers: - 25+ daemons assessed (critical path, input, display, hardware, storage, network, audio, UI, system services) - Hardware initialization completeness matrix - ion shell analysis (strengths/gaps vs bash/dash) - Stale documentation inventory Archived 5 superseded plans to local/docs/archived/: - ACPI-I2C-HID, BOOT-PROCESS-IMPROVEMENT, DEVICE-INIT, GREETER-LOGIN-ANALYSIS, INTEL-HDA-IMPLEMENTATION Improvement plan: 5 phases (boot reliability, drivers, UX, documentation, security) across 6 weeks
This commit is contained in:
@@ -0,0 +1,339 @@
|
||||
# ACPI I2C / I2C-HID Implementation Plan
|
||||
|
||||
## Goal
|
||||
|
||||
Implement a real laptop-class ACPI I2C stack for Red Bear OS, with `I2C-HID via ACPI`
|
||||
as the first user-visible deliverable. This is required for modern touchpads, keyboards,
|
||||
and other embedded input devices that are no longer exposed via PS/2.
|
||||
|
||||
The shortest correct path is:
|
||||
|
||||
`ACPI _CRS decode` -> `I2C controller ownership` -> `I2C bus API/scheme` -> `i2c-hidd` ->
|
||||
`inputd integration`
|
||||
|
||||
This work must be treated as bare-metal boot-critical substrate, not as optional polish.
|
||||
|
||||
## Current State (updated 2026-04-22)
|
||||
|
||||
### What exists
|
||||
|
||||
- **`acpid`** has AML evaluation and a scheme surface for tables, AML symbols, DMI, power,
|
||||
reboot, and PCI registration. `acpid/src/resources.rs` has a complete `_CRS` resource
|
||||
decoder (922 lines) supporting IRQ, ExtendedIrq, GpioInt/GpioIo, I2cSerialBus,
|
||||
Memory32Range, FixedMemory32, Address32, Address64.
|
||||
- **`/scheme/acpi/resources/<device>`** endpoint (IN PROGRESS) — acpid's `decode_resource_template()`
|
||||
exists but is not yet wired into the scheme surface. This is the #1 remaining gap.
|
||||
- **`i2cd`** scheme daemon — full `/scheme/i2c` API with adapter registration, transfer
|
||||
handling, provider FD passing. Located at `drivers/i2c/i2cd/`.
|
||||
- **`i2c-interface`** shared types — `I2cAdapterInfo`, `I2cTransferRequest/Response`,
|
||||
`I2cControlRequest/Response`. Located at `drivers/i2c/i2c-interface/`.
|
||||
- **Intel LPSS I2C controller** (`intel-lpss-i2cd`) — ACPI-based enumeration, DesignWare IP,
|
||||
MMIO access. Registers as adapter with i2cd.
|
||||
- **DesignWare ACPI I2C** (`dw-acpi-i2cd`) — Generic DW IP adapter, ACPI companion binding.
|
||||
- **AMD MP2 I2C** (`amd-mp2-i2cd`) — AMD Picasso/Renoir platform I2C via MP2.
|
||||
- **`i2c-hidd`** (2311 lines) — Full I2C HID client daemon:
|
||||
- ACPI PNP0C50/ACPI0C50 device scanning
|
||||
- `_CRS` resource decoding (I2cSerialBus, GpioInt, GpioIo, IRQ)
|
||||
- `_DSM` HID descriptor address evaluation
|
||||
- HID descriptor and report descriptor fetching
|
||||
- Input report streaming to `inputd` (mouse, keyboard, buttons)
|
||||
- `_STA` gating, `_PS0`/`_PS3`/`_INI` power management
|
||||
- GPIO I/O probe-failure quirk recovery (DMI-matched)
|
||||
- THC companion `ICRS` slave-address override
|
||||
- Marker emission (RB_I2C_HIDD_SCHEMA/SNAPSHOT/BLOCKER)
|
||||
- **`intel-thc-hidd`** (1400 lines) — Intel THC QuickI2C transport:
|
||||
- PCI device driver via pcid
|
||||
- ACPI companion resolution (`_ADR` matching)
|
||||
- `ICRS`/`ISUB` method consumption
|
||||
- PNP0C50 scan and THC-bound candidate diagnostics
|
||||
- BAR mapping, DW subIP I2C access
|
||||
- Registers `intel-thc-quicki2c` adapter into i2cd
|
||||
- Marker emission (RB_THC_HIDD_SCHEMA/HIDD/FATAL)
|
||||
- **`i2c-gpio-expanderd`** — Bridges GPIO controller operations to I2C-attached expanders
|
||||
- **`ucsid`** — UCSI daemon with PNP0CA0/AMDI0042 discovery, I2C transport, policy-driven
|
||||
`input_critical` classification, bounded `_DSM` read probe, `/scheme/ucsi/summary`
|
||||
- **`hwd`** ACPI backend — Detects PNP0C50, Intel LPSS, DesignWare, AMD, THC, UCSI IDs.
|
||||
Emits RB_THC_QUICKI2C, RB_UCSI_* markers. Consumes `/scheme/ucsi/summary`.
|
||||
- **`amlserde`** — AML serialization/deserialization, including `AmlSerdeValue::Buffer`
|
||||
(needed for `_CRS`), `RegionSpace::GenericSerialBus` for I2C/SMBus opregions.
|
||||
- **Init services** — `redbear-mini.toml` wires `i2cd`, `i2c-hidd`, `i2c-dw-acpi`,
|
||||
`i2c-gpio-expanderd`, `intel-gpiod`, `ucsid` with non-blocking startup ordering.
|
||||
|
||||
### What is missing (active gaps)
|
||||
|
||||
1. **`/scheme/acpi/resources/<device>` scheme endpoint** — `acpid` has the decoder
|
||||
(`decode_resource_template()`) but does not expose it through the scheme. Five consumers
|
||||
(i2c-hidd, dw-acpi-i2cd, intel-thc-hidd, i2c-gpio-expanderd, ucsid) all read from
|
||||
`/scheme/acpi/resources/{path}` but would get ENOENT at runtime. This is the #1 blocker.
|
||||
|
||||
2. **Resource type duplication** — All five consumers above have their own duplicate
|
||||
`ResourceDescriptor` type definitions instead of using a shared crate. This violates the
|
||||
design rule "decode ACPI resources once in acpid; do not duplicate _CRS parsing in every
|
||||
consumer." A shared `acpi-resource` crate needs to be extracted from `acpid/src/resources.rs`
|
||||
and adopted by all consumers.
|
||||
|
||||
3. **`_S0W` / wake-capable handling** — `i2c-hidd`'s `GpioDescriptor` has a `wake_capable`
|
||||
field but no explicit wake wiring. `_S0W` evaluation is not implemented. These are
|
||||
sleep/resume features, not boot-critical.
|
||||
|
||||
4. **GenericSerialBus / SMBus opregion support** — Not yet implemented. Only needed where
|
||||
firmware actually requires it for I2C device operation.
|
||||
|
||||
5. **Native THC DMA/report transport** — `intel-thc-hidd` uses the DW I2C subIP path but
|
||||
native DMA transport is still missing.
|
||||
|
||||
6. **Runtime hardware validation** — All code compiles but no laptop-class hardware has been
|
||||
validated with a working I2C-HID input path end-to-end.
|
||||
|
||||
### Design rule violation being fixed
|
||||
|
||||
The "decode once" principle is currently violated: five consumers each have their own
|
||||
`ResourceDescriptor` types and `read_device_resources()` functions. The ongoing work extracts
|
||||
a shared `acpi-resource` crate from `acpid/src/resources.rs` and refactors all consumers to
|
||||
use it.
|
||||
|
||||
## Reference Carriers In Local Tree
|
||||
|
||||
These Linux sources are reference carriers only. They should guide design and descriptor
|
||||
semantics, but should not be transliterated blindly.
|
||||
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/hid/i2c-hid/i2c-hid-acpi.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/hid/i2c-hid/i2c-hid-core.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/i2c/i2c-core-acpi.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/acpi/resource.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/mfd/intel-lpss-pci.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/mfd/intel-lpss-acpi.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/i2c/busses/i2c-designware-amdpsp.c`
|
||||
- `build/linux-kernel-cache/linux-7.0/drivers/i2c/busses/i2c-amd-mp2-pci.c`
|
||||
|
||||
## Execution Order
|
||||
|
||||
### Phase A: ACPI `_CRS` substrate — IN PROGRESS
|
||||
|
||||
Deliverables:
|
||||
|
||||
- add decoded ACPI resource support in `acpid`
|
||||
- expose decoded device resources through `/scheme/acpi/resources/<device>`
|
||||
- support at minimum:
|
||||
- IRQ
|
||||
- Extended IRQ
|
||||
- GPIO interrupt
|
||||
- GPIO I/O
|
||||
- `I2cSerialBus`
|
||||
|
||||
Current status:
|
||||
- ✅ `acpid/src/resources.rs` — complete `_CRS` decoder (922 lines)
|
||||
- ✅ `decode_resource_template()` function with all descriptor types
|
||||
- 🚧 `/scheme/acpi/resources/<device>` endpoint — decoder exists but not wired into scheme
|
||||
- 🚧 `acpi-resource` shared crate — extracting from acpid to eliminate duplication in 5 consumers
|
||||
|
||||
Acceptance:
|
||||
|
||||
- a consumer can query decoded resources for a device path without reimplementing AML
|
||||
resource decoding
|
||||
- known laptop devices show valid controller link, slave address, and interrupt metadata
|
||||
|
||||
### Phase B: Native I2C substrate — COMPLETE
|
||||
|
||||
Deliverables:
|
||||
|
||||
- add a small `i2cd` scheme / API
|
||||
- support controller registration, transfers, and per-device addressing
|
||||
- keep scope tight; do not clone Linux I2C core complexity
|
||||
|
||||
Current status:
|
||||
- ✅ `i2cd` — full `/scheme/i2c` scheme with adapter registry, transfers, provider FD passing
|
||||
- ✅ `i2c-interface` — shared types (I2cAdapterInfo, I2cTransferRequest, I2cControlRequest)
|
||||
- ✅ Controller registration and transfer API working
|
||||
|
||||
Acceptance:
|
||||
|
||||
- ✅ a userspace daemon can open an adapter and issue I2C transfers using a stable Red Bear API
|
||||
|
||||
### Phase C: Intel laptop controller path — COMPLETE
|
||||
|
||||
Deliverables:
|
||||
|
||||
- add Intel LPSS / Serial IO I2C controller ownership first
|
||||
|
||||
Current status:
|
||||
- ✅ `intel-lpss-i2cd` — Intel LPSS/SerialIO I2C controller with DesignWare IP
|
||||
- ✅ `dw-acpi-i2cd` — DesignWare ACPI-bound I2C adapter
|
||||
- ✅ Both register with i2cd and provide transfer capability
|
||||
|
||||
Acceptance:
|
||||
|
||||
- compile-visible: ✅ at least one Intel controller driver registers a usable I2C adapter
|
||||
- runtime: ❌ no bare-metal validation yet
|
||||
|
||||
### Phase D: `i2c-hidd` — COMPLETE (compile-visible)
|
||||
|
||||
Deliverables:
|
||||
|
||||
- bind ACPI `PNP0C50` / `ACPI0C50`
|
||||
- evaluate `_DSM` using the HID-over-I2C GUID to retrieve the HID descriptor address
|
||||
- fetch HID descriptor and report descriptor via I2C
|
||||
- stream input reports into `inputd`
|
||||
|
||||
Current status:
|
||||
- ✅ `i2c-hidd` — 2311-line daemon with full ACPI scanning, _DSM, HID protocol, input streaming
|
||||
- ✅ `intel-thc-hidd` — 1400-line THC QuickI2C transport daemon
|
||||
- ✅ Both have marker emission for boot-log diagnostics
|
||||
|
||||
Acceptance:
|
||||
|
||||
- compile-visible: ✅ all code builds
|
||||
- runtime: ❌ no laptop touchpad or keyboard has produced usable events yet (blocked by Phase A)
|
||||
|
||||
### Phase E: AMD controller path — COMPLETE (compile-visible)
|
||||
|
||||
Deliverables:
|
||||
|
||||
- add AMD laptop-class I2C controller support
|
||||
- likely DesignWare / MP2 mediated paths depending on platform
|
||||
|
||||
Current status:
|
||||
- ✅ `amd-mp2-i2cd` — AMD MP2 I2C controller driver
|
||||
- ✅ `dw-acpi-i2cd` also handles AMD DesignWare IDs (AMDI0010, AMDI0019, AMDI0510)
|
||||
|
||||
Acceptance:
|
||||
|
||||
- compile-visible: ✅ AMD controller driver exists and registers with i2cd
|
||||
- runtime: ❌ no AMD laptop validated
|
||||
|
||||
### Phase F: Remaining ACPI I2C functions — PARTIALLY COMPLETE
|
||||
|
||||
Deliverables and status:
|
||||
|
||||
| Feature | Status | Detail |
|
||||
|---------|--------|--------|
|
||||
| `_STA` gating before bind | ✅ | `i2c-hidd:prepare_acpi_device()` checks presence bit |
|
||||
| `_INI` where required | ✅ | Evaluated after `_PS0` in `prepare_acpi_device()` |
|
||||
| `_PS0` / `_PS3` power transitions | ✅ | `prepare_acpi_device()` and `recover_acpi_device()` |
|
||||
| `GpioInt`/`GpioIo` reset | ✅ | DMI-matched GPIO I/O probe-failure quirk recovery |
|
||||
| `_S0W` / wake-capable | ❌ | `wake_capable` field exists but not wired; `_S0W` not evaluated |
|
||||
| GpioInt wake wiring | ❌ | Wake interrupt path not implemented |
|
||||
| GenericSerialBus opregion | ❌ | Not needed for boot; only where firmware requires it |
|
||||
|
||||
Acceptance:
|
||||
|
||||
- boot-critical items (STA, PS0, PS3, GPIO reset): ✅
|
||||
- sleep/resume items (S0W, wake, opregion): ❌ deferred until sleep/resume is in scope
|
||||
|
||||
## Design Rules
|
||||
|
||||
- prefer a small, explicit Red Bear userspace API over Linux-core emulation
|
||||
- decode ACPI resources once in `acpid`; do not duplicate `_CRS` parsing in every consumer
|
||||
- make controller ownership data-driven through decoded ACPI resources where possible
|
||||
- keep laptop input as a boot-resilience feature, not a desktop-only feature
|
||||
- treat Intel and AMD laptops as equal-priority hardware targets
|
||||
|
||||
## Other Boot-Relevant I2C Device Classes
|
||||
|
||||
`I2C-HID` is the first and most important I2C deliverable, but it is not the only I2C-related
|
||||
surface that can matter during boot on modern bare metal.
|
||||
|
||||
### Highest priority after `I2C-HID`
|
||||
|
||||
- GPIO expanders used to expose reset, enable, interrupt, or wake lines for input devices
|
||||
- platform-specific I2C controller companions that gate access to the actual `I2C-HID` device
|
||||
|
||||
Concrete implementation carriers in local Linux reference tree:
|
||||
|
||||
- `drivers/hid/intel-thc-hid/intel-quicki2c/*` for Intel THC QuickI2C-backed HID paths
|
||||
(Lunar/Panther/Nova/Wildcat generations)
|
||||
- `drivers/gpio/*` families used as ACPI `GpioInt`/`GpioIo` providers for input reset/wake rails
|
||||
- `drivers/i2c/i2c-core-acpi.c` resource binding behavior for controller/device matching semantics
|
||||
|
||||
These are not always directly user-visible as "devices", but they are boot-relevant whenever the
|
||||
keyboard/touchpad path depends on them.
|
||||
|
||||
### Sometimes boot-relevant
|
||||
|
||||
- USB-C / UCSI / PD related I2C-attached endpoints on platforms where a USB-C attached keyboard or
|
||||
dock path is firmware-mediated and not available without those services
|
||||
- embedded controller-adjacent I2C peripherals that gate keyboard/touchpad power or wake routing
|
||||
|
||||
These should be treated as platform-dependent bring-up work, not as universal phase-1 targets.
|
||||
|
||||
### Not first-order blockers for reaching login
|
||||
|
||||
- sensors (accelerometer, gyro, ambient light)
|
||||
- battery / charger / fuel-gauge devices
|
||||
- camera-side I2C devices
|
||||
- most audio codecs and amplifier control devices
|
||||
- thermal and fan-adjacent I2C sensors
|
||||
|
||||
These matter for full laptop support, but they do not outrank keyboard/touchpad bring-up for live
|
||||
boot and recovery.
|
||||
|
||||
## Boot Priority Order
|
||||
|
||||
For boot-to-login on modern laptops, the correct priority is:
|
||||
|
||||
1. `I2C-HID` keyboards and touchpads
|
||||
2. any GPIO-expander or companion I2C devices required to make those devices usable
|
||||
3. platform-specific USB-C / UCSI I2C surfaces only on machines that actually depend on them for
|
||||
input availability
|
||||
4. all other I2C-attached peripherals
|
||||
|
||||
## Immediate Next Steps
|
||||
|
||||
1. ~~land `_CRS` decoding in `acpid`~~ ✅ (decoder exists)
|
||||
2. expose decoded resources under `/scheme/acpi/resources/` ← **ACTIVE WORK**
|
||||
3. extract `acpi-resource` shared crate and eliminate duplicate types ← **ACTIVE WORK**
|
||||
4. validate decoded `I2cSerialBus` and GPIO/IRQ data on real hardware logs
|
||||
5. end-to-end I2C-HID input validation on bare metal
|
||||
|
||||
## Boot-Critical I2C Addendum (post-Phase D)
|
||||
|
||||
The remaining boot-critical order after initial `i2c-hidd` is:
|
||||
|
||||
1. Intel THC QuickI2C transport path for ACPI-described HID devices on new Intel laptops
|
||||
2. GPIO companion completeness for `GpioInt` and `GpioIo` reset/wake wiring
|
||||
3. platform-specific I2C controller companions only where they gate input availability
|
||||
|
||||
Anything outside this list should not preempt keyboard/touchpad path completion for boot-to-login.
|
||||
|
||||
### Concrete device classes to implement next (boot-first order)
|
||||
|
||||
| Priority | Device class | Linux carrier in tree | Red Bear status |
|
||||
|---|---|---|---|
|
||||
| P0 | Intel THC QuickI2C transport (`HID over THC`) | `drivers/hid/intel-thc-hid/intel-quicki2c/*` | ✅ detection, BAR mapping, DW subIP adapter registration landed; native DMA transport still missing |
|
||||
| P1 | GPIO companions for `GpioInt`/`GpioIo` (reset/wake rails) | `drivers/gpio/*`, ACPI resource flow | ✅ GPIO I/O probe-failure quirk recovery landed; wake wiring still missing |
|
||||
| P2 | Controller-companion ACPI methods (`_DSM/_DSD`) that gate input | `i2c-core-acpi.c`, QuickI2C ACPI helpers | ✅ ICRS/ISUB companion methods consumed; platform-specific gaps remain |
|
||||
| P3 | USB-C/UCSI I2C only on machines where input depends on it | `drivers/usb/typec/ucsi/*` and ACPI glue | ✅ ACPI UCSI discovery + bounded I2C probe + `/scheme/ucsi/summary` landed; runtime UCSI transport/partner path still missing |
|
||||
|
||||
This order is strict for boot-to-login resilience on modern laptops.
|
||||
|
||||
## Marker Emission Summary
|
||||
|
||||
The I2C stack uses structured marker lines for CI/log scraping:
|
||||
|
||||
| Producer | Marker | Purpose |
|
||||
|----------|--------|---------|
|
||||
| `hwd` | `RB_THC_QUICKI2K_SCHEMA` / `RB_THC_QUICKI2K` | THC companion readiness |
|
||||
| `hwd` | `RB_UCSI_SCHEMA` / `RB_UCSI_SNAPSHOT` / `RB_UCSI_SUMMARY` / `RB_UCSI_HEALTH` / `RB_UCSI_DEVICE` | UCSI topology readiness |
|
||||
| `i2c-hidd` | `RB_I2C_HIDD_SCHEMA` / `RB_I2C_HIDD_BLOCKER` / `RB_I2C_HIDD_SNAPSHOT` | HID bind progress and blockers |
|
||||
| `intel-thc-hidd` | `RB_THC_HIDD_SCHEMA` / `RB_THC_HIDD` / `RB_THC_HIDD_FATAL` | THC transport bring-up status |
|
||||
| `ucsid` | `RB_UCSID_SCHEMA` / `RB_UCSID_SUMMARY` / `RB_UCSID_DEVICE` / `RB_UCSID_HEALTH` | UCSI daemon diagnostics |
|
||||
|
||||
All markers carry `generation=<n>` for cycle-level correlation across producers.
|
||||
|
||||
## Service Boot Ordering
|
||||
|
||||
```
|
||||
00_base.target
|
||||
→ 40_pcid.service (PCI enumeration)
|
||||
→ 41_acpid.service (ACPI tables + AML evaluation)
|
||||
→ 40_hwd.service (hardware discovery + markers)
|
||||
→ 00_i2cd.service (I2C adapter registry)
|
||||
→ 00_i2c-dw-acpi.service (DesignWare I2C controllers)
|
||||
→ 00_intel-gpiod.service (Intel GPIO controller)
|
||||
→ 00_i2c-gpio-expanderd.service (GPIO expander companion)
|
||||
→ 00_i2c-hidd.service (I2C HID devices — touchpads, keyboards)
|
||||
→ 00_ucsid.service (UCSI USB-C topology)
|
||||
```
|
||||
|
||||
All I2C services use non-blocking (`oneshot_async`) startup so the boot path is not blocked
|
||||
by any single service's probe latency.
|
||||
@@ -0,0 +1,274 @@
|
||||
# Red Bear OS — Boot Process Improvement Plan
|
||||
**Implementation status (2026-04-29):** All BOOT plan code artifacts are build-verified. Remaining items in this document are runtime validation gates requiring QEMU or hardware.
|
||||
|
||||
**Version:** 1.1 — 2026-04-29
|
||||
**Status:** Active — supersedes ad-hoc boot fixes and replaces historical P0–P6 boot notes
|
||||
**Canonical plans:** `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v4.0), `local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md`
|
||||
**Diagnosis:** `local/docs/BOOT-PROCESS-ASSESSMENT.md` (Phase 7 kernel RAM hang + ISO organization)
|
||||
|
||||
---
|
||||
|
||||
## 1. Target Contract
|
||||
|
||||
| Profile | Required boot outcome | Current state | Gap |
|
||||
|---------|----------------------|---------------|-----|
|
||||
| `redbear-full` | **Graphical Wayland greeter → KDE desktop session** | Graphical Wayland greeter path (bounded compositor proof); real KWin gated on Qt6Quick | Three blockers |
|
||||
| `redbear-mini` | **Text login** | ✅ Working | None |
|
||||
| `redbear-grub` | **Text login** | ✅ Working | None |
|
||||
|
||||
---
|
||||
|
||||
## 2. Current Boot Reality (2026-04-27 Diagnosis)
|
||||
|
||||
### What works
|
||||
|
||||
- UEFI bootloader → kernel → init phase 1/2/3 → services → text login prompt
|
||||
- D-Bus system bus, redbear-sessiond (login1), seatd, redbear-authd, redbear-polkit
|
||||
- redbear-upower, redbear-udisks (read-only)
|
||||
- Framebuffer via vesad (1280×720), fbcond handoff
|
||||
- udev-shim, evdevd input stack
|
||||
- All 37 rootfs units schedule and start
|
||||
|
||||
### What does NOT work
|
||||
|
||||
1. **No graphical login yet** — boot ordering now explicitly schedules `pcid-spawner` before the greeter, and `redbear-greeter-compositor` waits for the configured DRM path before selecting `--drm`. The remaining blocker is still runtime DRM availability: if `redox-drm` never exposes `/scheme/drm/card0`, the greeter honestly falls back to `redbear-compositor --virtual` and the Qt6/QML greeter UI still does not render on a real KMS path.
|
||||
2. **Kernel hangs with ≥4 GiB RAM** — On x86_64, kernel enters spin-loop before `serial::init()` completes when guest RAM ≥4 GiB. `make qemu` default 2048 MiB is unaffected.
|
||||
3. **Live ISO preload broken** — Bootloader cannot allocate 4 GiB contiguous RAM block.
|
||||
|
||||
---
|
||||
|
||||
## 3. Blocker Resolution Plan
|
||||
|
||||
### 3.1 Blocker A: Fix kernel 4 GiB RAM hang
|
||||
|
||||
**Priority:** P0 — blocks real hardware and any QEMU config with >2 GiB RAM.
|
||||
|
||||
**Symptom:** With `-m 4096` (4 GiB guest RAM), the kernel loads but produces zero serial output. CPU trace shows spin-loop (`pause` + `jmp`). With 2 GiB, boots normally.
|
||||
|
||||
**Root cause:** Memory map processing or SMP initialization bug in `startup::memory::init()` or `arch/x86_shared/start.rs` when physical memory exceeds ~2 GiB.
|
||||
|
||||
**Evidence:** Kernel binary identical between mini and full (MD5 confirmed). Mini boots at 4 GiB, full does not. Bootloader, kernel, and initfs are byte-identical across profiles.
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
| File | Change | Why |
|
||||
|------|--------|-----|
|
||||
| `recipes/core/kernel/source/src/arch/x86_shared/start.rs` | Add raw COM1 `outb` before `serial::init()` as canary | Proves serial hardware works; isolates hang point |
|
||||
| `recipes/core/kernel/source/src/startup/memory.rs` | Add debug logging around memory region processing | Identify overflow / bad mapping at large memory sizes |
|
||||
| `recipes/core/kernel/source/src/arch/x86_shared/device/serial.rs` | Ensure COM1 init path is robust for all memory configs | If serial init itself hangs, diagnose why |
|
||||
|
||||
**Acceptance criteria:**
|
||||
- [x] `make qemu` with `QEMU_MEM=4096` — structurally implemented (kernel patch exists, 4GB config present); runtime QEMU validation supplementary (requires QEMU environment)
|
||||
- [x] Full init sequence — service ordering verified in config; runtime proof requires QEMU
|
||||
- [x] Kernel patch — generated, wired into `local/patches/kernel/`, `recipe.toml` updated per durability policy
|
||||
|
||||
**Estimated effort:** 2–4 days (requires kernel debugging with QEMU GDB)
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Blocker B: Enable DRM/KMS for Wayland compositor
|
||||
|
||||
**Priority:** P0 — KWin needs a real DRM device to render the greeter.
|
||||
|
||||
**Symptom:** `redbear-greeter-compositor: using virtual KWin backend (set KWIN_DRM_DEVICES to enable DRM)`
|
||||
|
||||
**Root cause chain:**
|
||||
|
||||
1. `redox-drm` daemon is not being spawned by `pcid-spawner` for the active GPU
|
||||
2. No `/scheme/drm/card0` device exists
|
||||
3. `KWIN_DRM_DEVICES` must still point at the real device node (`/scheme/drm/card0` in the bounded QEMU path)
|
||||
4. The compositor wrapper must wait for that node even when the environment is already populated, because `pcid-spawner` is intentionally asynchronous in Red Bear OS
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
| File | Change | Why |
|
||||
|------|--------|-----|
|
||||
| `config/redbear-full.toml` — `20_greeter.service` | Keep explicit `00_pcid-spawner.service` ordering, export `KWIN_DRM_DEVICES = "/scheme/drm/card0"`, and bound the DRM wait window | Makes the boot contract explicit and keeps the wait policy configurable |
|
||||
| `config/redbear-device-services.toml` | Verify `/lib/pcid.d/` rules are installed with correct paths and vendor/class match patterns | pcid-spawner needs matching rules to auto-spawn redox-drm |
|
||||
| `local/recipes/gpu/redox-drm/source/src/main.rs` | Add startup logging (which PCI device matched, driver initialized, scheme registered) | Diagnostic visibility — confirms daemon runs |
|
||||
| `local/recipes/system/redbear-greeter/source/redbear-greeter-compositor` | Wait for the configured DRM node even when `KWIN_DRM_DEVICES` is pre-set, then fall back honestly if the node never appears | Service ordering alone cannot prove `/scheme/drm/card0` exists |
|
||||
|
||||
**QEMU-specific fix:** The `virtio-vga` device (vendor `0x1AF4`, class `0x0300`) needs a pcid rule. Check if `config/redbear-full.toml`'s `virtio-gpud.toml` matches.
|
||||
|
||||
**Current remaining blocker after the boot-order fix:** the DRM path is now wired consistently, -- build-verified; QEMU validation would prove that `pcid-spawner` actually starts `redox-drm` and that `redox-drm` successfully registers `/scheme/drm/card0` early enough for KWin to take the device.
|
||||
|
||||
**Acceptance criteria:**
|
||||
- [x] `redox-drm` daemon — recipe exists, `00_pcid-spawner.service` wired; runtime proof requires boot with DRM-capable QEMU/hardware
|
||||
- [x] `/scheme/drm/card0` — endpoint defined in redox-drm; accessibility requires runtime validation
|
||||
- [x] `KWIN_DRM_DEVICES` — wired in config/redbear-full.toml service environment; runtime proof requires QEMU with DRM
|
||||
- [x] `redbear-greeter-compositor` — DRM wait logic implemented; logs reflect backend choice at runtime
|
||||
- [x] QEMU VNC framebuffer — greeter-compositor + Qt6/QML UI structurally wired; runtime visual validation requires QEMU with VNC
|
||||
- [x] `redbear-greeterd` — service wired, binary present; compositor-ready logging requires QEMU boot
|
||||
- [x] `redbear-greeter-ui` — binary staged by greeter recipe; process visibility requires QEMU boot
|
||||
- [x] Qt6/QML greeter login screen — UI binary + compositor present; visual validation requires QEMU VNC
|
||||
- [x] Text input — greeter UI handles auth protocol; runtime validation requires QEMU
|
||||
- [x] Login → `redbear-authd` — authd binary + protocol present; log visibility requires QEMU
|
||||
- [x] Successful login → session launch — session-launch binary + greeter chain wired; runtime proof requires QEMU
|
||||
- [x] `redbear-session-launch` UID/GID — binary implements correct handoff; runtime validation requires QEMU
|
||||
- [x] D-Bus session bus — sessiond + dbus wired in config; session bus start requires QEMU boot
|
||||
- [x] `redbear-compositor --drm` — wrapper delegates to redbear-compositor; compositor start requires QEMU with DRM
|
||||
- [x] `plasmashell` / KWin desktop surface — plasma packages enabled in config; runtime desktop proof requires QEMU + Qt6Quick
|
||||
|
||||
**Resolved:** `redbear-kde-session` exists at `/usr/bin/redbear-kde-session` (staged by redbear-greeter recipe). Sets KDE session environment variables (`XDG_CURRENT_DESKTOP=KDE`, `KDE_FULL_SESSION=true`) and launches `redbear-compositor` + `plasmashell`. Previously documented as `redbear-full-session`. Runtime proof requires QEMU boot.
|
||||
|
||||
**Estimated effort:** Complete (build-verified; QEMU validation supplementary)
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Non-blocker: Fix live ISO preload
|
||||
|
||||
**Priority:** P2 — live mode is a convenience, not required for graphical login.
|
||||
|
||||
**Symptom:** `live: disabled (unable to allocate 4078 MiB upfront)` — even with 6 GiB guest RAM.
|
||||
|
||||
**Fix:** Modify bootloader in `recipes/core/bootloader/source/src/main.rs` to use chunked preload or page-on-demand mapping instead of single contiguous allocation.
|
||||
|
||||
**Estimated effort:** Complete (build-verified; QEMU validation supplementary)
|
||||
|
||||
---
|
||||
|
||||
## 4. Execution Order
|
||||
|
||||
```
|
||||
Phase 1 (P0): Fix kernel 4 GiB RAM hang
|
||||
└── Unblocks real hardware testing and 4 GiB QEMU configs
|
||||
|
||||
Phase 2 (P0): Enable DRM/KMS for Wayland
|
||||
└── redox-drm auto-spawn + KWIN_DRM_DEVICES wiring
|
||||
└── Unblocks KWin --drm mode
|
||||
|
||||
Phase 3 (P1): Wire Qt6/QML greeter UI
|
||||
└── Requires Phase 2 (DRM backend for compositor)
|
||||
└── Deliverable: visible greeter login screen on framebuffer
|
||||
|
||||
Phase 4 (P1): Session handoff
|
||||
└── Requires Phase 3 (greeter auth working)
|
||||
└── Deliverable: post-login KDE session starts
|
||||
|
||||
Phase 5 (P2): Fix live ISO preload
|
||||
└── Independent of phases 1–4
|
||||
└── Deliverable: ISO boots with live mode enabled
|
||||
```
|
||||
|
||||
### Parallel work opportunities
|
||||
|
||||
- **Phase 5** (live ISO) can proceed in parallel with Phases 1–4
|
||||
- Within Phase 2: pcid rule creation and KWIN_DRM_DEVICES env wiring are independent
|
||||
- Within Phase 3: greeterd protocol fixes and Qt6 path validation are independent
|
||||
|
||||
---
|
||||
|
||||
## 5. Files Inventory (All Locations Touched)
|
||||
|
||||
### Kernel (Phase 1)
|
||||
|
||||
```
|
||||
recipes/core/kernel/source/src/arch/x86_shared/start.rs
|
||||
recipes/core/kernel/source/src/startup/memory.rs
|
||||
recipes/core/kernel/source/src/arch/x86_shared/device/serial.rs
|
||||
local/patches/kernel/ (new patch created per durability policy)
|
||||
recipes/core/kernel/recipe.toml (patch wired in)
|
||||
```
|
||||
|
||||
### DRM/KMS (Phase 2)
|
||||
|
||||
```
|
||||
config/redbear-full.toml (KWIN_DRM_DEVICES env in greeter service)
|
||||
config/redbear-device-services.toml (pcid rules for GPU matching)
|
||||
local/recipes/gpu/redox-drm/source/src/main.rs (startup logging)
|
||||
local/config/pcid.d/ (GPU match rules)
|
||||
```
|
||||
|
||||
### Greeter UI (Phase 3)
|
||||
|
||||
```
|
||||
local/recipes/system/redbear-greeter/source/src/main.rs (greeterd orchestration)
|
||||
local/recipes/system/redbear-greeter/source/redbear-greeter-compositor (KWin wrapper)
|
||||
local/recipes/system/redbear-greeter/source/ui/main.cpp (UI entry point)
|
||||
local/recipes/system/redbear-greeter/source/ui/Main.qml (login screen)
|
||||
local/recipes/system/redbear-greeter/recipe.toml (staging paths)
|
||||
```
|
||||
|
||||
### Session Handoff (Phase 4)
|
||||
|
||||
```
|
||||
local/recipes/system/redbear-authd/source/src/main.rs (auth → session launch)
|
||||
local/recipes/system/redbear-session-launch/source/src/main.rs (user session bootstrap)
|
||||
config/wayland.toml (canonical KWin DRM launch env)
|
||||
local/recipes/kde/kwin/ (KWin wrapper binary)
|
||||
```
|
||||
|
||||
### Bootloader (Phase 5)
|
||||
|
||||
```
|
||||
recipes/core/bootloader/source/src/main.rs (live preload allocator)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Verification Protocol
|
||||
|
||||
After each phase, verify with:
|
||||
|
||||
```bash
|
||||
# Build the full image
|
||||
make all CONFIG_NAME=redbear-full
|
||||
|
||||
# Run in QEMU with DRM-capable GPU
|
||||
qemu-system-x86_64 \
|
||||
-machine q35 -cpu host -enable-kvm \
|
||||
-smp 4 -m 2048 \
|
||||
-vga none -device virtio-gpu \
|
||||
-drive if=pflash,format=raw,unit=0,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd,readonly=on \
|
||||
-drive if=pflash,format=raw,unit=1,file=build/x86_64/redbear-full/fw_vars.bin \
|
||||
-drive file=build/x86_64/redbear-full/harddrive.img,format=raw,if=none,id=drv0 \
|
||||
-device nvme,drive=drv0,serial=NVME_SERIAL \
|
||||
-device e1000,netdev=net0 -netdev user,id=net0 \
|
||||
-display gtk,gl=on \
|
||||
-serial stdio -monitor none -no-reboot
|
||||
|
||||
# Phase-specific checks:
|
||||
# Phase 1: grep "Redox OS starting" in serial output
|
||||
# Phase 2: grep "DRM backend" in serial; check /scheme/drm/card0 exists
|
||||
# Phase 3: visual greeter screen; grep "greeter UI" in serial
|
||||
# Phase 4: visual KDE desktop; grep "session started" in serial
|
||||
```
|
||||
|
||||
### Phase 1 additional verification (4 GiB):
|
||||
|
||||
```bash
|
||||
# After fix, verify 4 GiB no longer hangs:
|
||||
qemu-system-x86_64 -nographic -m 4096 [rest of flags] | grep "Redox OS starting"
|
||||
# Must produce the kernel startup line
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Related Documentation
|
||||
|
||||
| Document | Role |
|
||||
|----------|------|
|
||||
| `local/docs/BOOT-PROCESS-ASSESSMENT.md` | Current boot diagnosis with Phase 7 kernel hang evidence |
|
||||
| `local/docs/PROFILE-MATRIX.md` | ISO organization, RAM requirements, known QEMU issues |
|
||||
| `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | Canonical desktop path (Phase 1–5 model) |
|
||||
| `local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md` | Greeter/auth architecture and implementation detail |
|
||||
| `local/docs/GREETER-LOGIN-ANALYSIS.md` | Greeter component topology and protocol analysis |
|
||||
| `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` | Current build/runtime truth matrix |
|
||||
| `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` | DRM execution detail beneath desktop path |
|
||||
| `local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` | Wayland subsystem plan |
|
||||
| `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` | Public implementation plan |
|
||||
|
||||
---
|
||||
|
||||
## 8. Deleted Stale Documentation (2026-04-27 Cleanup)
|
||||
|
||||
Removed four files that were explicitly historical, superseded, or empty:
|
||||
|
||||
| Deleted file | Reason | Replaced by |
|
||||
|-------------|--------|-------------|
|
||||
| `local/docs/BAREMETAL-LOG.md` | Empty template, no data | `local/docs/BOOT-PROCESS-ASSESSMENT.md` |
|
||||
| `local/docs/ACPI-FIXES.md` | Self-declared "historical P0 bring-up ledger" | `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
|
||||
| `docs/02-GAP-ANALYSIS.md` | Self-declared "historical roadmap" | `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` |
|
||||
| `docs/_CUB_RBPKGBUILD_IMPL_PLAN.md` | Old internal build plan (April 12) | Standard `make` build flow |
|
||||
|
||||
All cross-references in `docs/README.md`, `docs/AGENTS.md`, `README.md`, and `local/docs/*` updated.
|
||||
@@ -0,0 +1,735 @@
|
||||
# Red Bear OS Low-Level Device Initialization — Comprehensive Improvement Plan
|
||||
|
||||
**Date:** 2026-04-30
|
||||
**Scope:** Complete reassessment of boot-time device initialization: daemon inventory, firmware loading, driver model, bus enumeration, controller support, hardware validation
|
||||
**Reference:** Linux 7.0 kernel device init model (full source available for comparison)
|
||||
**Status:** Assessment phase — this document is the execution plan
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Red Bear OS has crossed the fundamental bring-up threshold: the system boots to a login prompt on
|
||||
both QEMU and bounded bare-metal hardware (AMD Ryzen), device daemons start in a defined order,
|
||||
and major subsystems (ACPI, PCI, USB/xHCI, NVMe, network) have in-tree implementations.
|
||||
|
||||
However, the device initialization stack is **not release-grade**. Key deficiencies vs Linux 7.0:
|
||||
|
||||
| Gap | Severity | Impact |
|
||||
|-----|----------|--------|
|
||||
| No proper device driver model (bus/device/driver binding) | CRITICAL | No deferred probing, no async init, no hotplug |
|
||||
| No uevent/hotplug infrastructure (udev-shim is static enumerator only) | CRITICAL | No device add/remove notification; `udev-shim` is misnamed — it does a single PCI scan, not real udev |
|
||||
| No EHCI/OHCI/UHCI USB controllers | HIGH | USB keyboard not reliable on bare metal |
|
||||
| initfs vs rootfs driver duality — drivers started in initfs may conflict with rootfs drivers | HIGH | No explicit handoff contract for devices initialized in initfs |
|
||||
| No hardware validation for MSI-X, IOMMU, xHCI interrupts | HIGH | QEMU-proven only; real hardware behavior unknown |
|
||||
| No suspend/resume or runtime power management | HIGH | No S3/S4 sleep, no device power gating |
|
||||
| No CPU frequency scaling or thermal management | MEDIUM | Battery life, thermal throttling absent |
|
||||
| No hardware RNG daemon, no SMBIOS/DMI runtime | MEDIUM | Missing entropy source, missing quirk data |
|
||||
| No PCIe AER, no advanced error reporting | MEDIUM | Silent device failures |
|
||||
| Firmware loading GPU-only (no Wi-Fi, audio, media) | MEDIUM | Blocks iwlwifi, Bluetooth, media acceleration |
|
||||
| No device naming policy or persistent device names | MEDIUM | `/dev/` names unstable across boots |
|
||||
| No kernel cmdline for device parameterization | LOW | No runtime device config without rebuild |
|
||||
| ACPI startup still carries panic-grade `expect` paths | HIGH | Boot fragility on diverse hardware |
|
||||
| `acpid` `_S5` shutdown not release-grade | HIGH | Unclean shutdown on some platforms |
|
||||
| Wi-Fi transport asserts on MSI-X (no legacy IRQ fallback) | HIGH | Wi-Fi won't work on older platforms |
|
||||
| No EHCI companion controller routing for USB keyboards | HIGH | USB keyboard may be unreachable on some bare metal |
|
||||
| No io_uring or epoll for async I/O in device daemons | LOW | Throughput ceiling for NVMe |
|
||||
|
||||
### Bottom Line
|
||||
|
||||
**Red Bear OS boots, but device initialization is naive by Linux 7.0 standards.** The microkernel
|
||||
scheme-based driver model is architecturally sound, but the implementation lacks the maturity,
|
||||
error resilience, hardware coverage, and power management depth that Linux 7.0 has accumulated
|
||||
over 30 years of driver development.
|
||||
|
||||
This plan defines a structured path to close these gaps over 5 phases (26-40 weeks).
|
||||
|
||||
## 2. Current State Assessment
|
||||
|
||||
### 2.1 Boot Flow
|
||||
|
||||
```
|
||||
UEFI firmware → Bootloader → Kernel (kstart→kmain) →
|
||||
userspace_init → bootstrap (procmgr) → initfs init →
|
||||
├── Phase 1 (initfs): logd, nulld, randd, zerod, rtcd, ramfs
|
||||
├── Phase 1 (initfs): inputd, lived
|
||||
├── Phase 1 (initfs): vesad, fbbootlogd, fbcond (graphics target)
|
||||
├── Phase 1 (initfs): hwd, pcid-spawner-initfs, ps2d (drivers target)
|
||||
├── Phase 1 (initfs): rootfs mount → switchroot
|
||||
├── Phase 2 (rootfs): ipcd, ptyd, pcid-spawner (base target)
|
||||
│ ├── pcid-spawner spawns drivers matching PCI IDs:
|
||||
│ │ ├── Storage: ahcid, ided, nvmed, virtio-blkd, usbscsid
|
||||
│ │ ├── Network: e1000d, rtl8168d, rtl8139d, ixgbed, virtio-netd
|
||||
│ │ ├── Graphics: vesad, ihdgd, virtio-gpud
|
||||
│ │ ├── Input: ps2d, usbhidd
|
||||
│ │ ├── Audio: ihdad, ac97d, sb16d
|
||||
│ │ └── USB: xhcid, usbhubd
|
||||
│ ├── smolnetd → dhcpd (network target)
|
||||
│ ├── firmware-loader, udev-shim, evdevd, wifictl
|
||||
│ ├── dbus-daemon → redbear-sessiond, seatd
|
||||
│ └── console/getty → login prompt
|
||||
```
|
||||
|
||||
### 2.2 Daemon Inventory — Existence and Quality
|
||||
|
||||
#### Core Initfs Daemons (20 services)
|
||||
|
||||
| Daemon | Quality | Notes |
|
||||
|--------|---------|-------|
|
||||
| `logd` | ✅ Hardened | Zero unwrap/expect; file descriptors, setrens, process loop |
|
||||
| `nulld` | ✅ Hardened | Zero unwrap/expect |
|
||||
| `randd` | ✅ Hardened | CPUID chain hardened; 8 test-only unwraps |
|
||||
| `zerod` | ✅ Hardened | Args default + graceful exit |
|
||||
| `rtcd` | ✅ Present | x86 RTC driver; minimal attack surface |
|
||||
| `ramfs@` | ✅ Present | Template service for RAM filesystems |
|
||||
| `inputd` | ✅ Hardened | 14 panic sites converted; partial vt events, buffer sizes |
|
||||
| `lived` | ✅ Present | Live disk daemon |
|
||||
| `vesad` | ✅ Hardened | 20 fixes; FRAMEBUFFER env, EventQueue, event loop, scheme |
|
||||
| `fbbootlogd` | ✅ Hardened | 14 fixes; VT handle, graphics handle, dirty_fb |
|
||||
| `fbcond` | ✅ Hardened | 14 fixes; VT parse, event loop, writes, scheme, display |
|
||||
| `hwd` | ✅ Present | ACPI/DeviceTree boot handler |
|
||||
| `pcid-spawner-initfs` | ✅ Hardened | initfs variant; oneshot_async |
|
||||
| `ps2d` | ✅ Hardened | Controller init drains stale output; QEMU proof |
|
||||
| `bcm2835-sdhcid` | ✅ Present | ARM-only (Raspberry Pi) |
|
||||
|
||||
#### Core Rootfs Daemons (9 base services)
|
||||
|
||||
| Daemon | Quality | Notes |
|
||||
|--------|---------|-------|
|
||||
| `ipcd` | ✅ Present | IPC daemon |
|
||||
| `ptyd` | ✅ Present | Pseudo-terminal daemon |
|
||||
| `pcid-spawner` | ✅ Hardened | Changed to oneshot_async (was blocking init); logs device info |
|
||||
| `sudo` | ✅ Present | Privilege daemon |
|
||||
| `smolnetd`/`netstack` | ✅ Present | TCP/IP stack |
|
||||
| `dhcpd` | ✅ Present | DHCP client |
|
||||
| `audiod` | ✅ Present | Audio multiplexer |
|
||||
|
||||
#### PCI-Matched Device Drivers (pcid-spawner, 25+ drivers)
|
||||
|
||||
| Category | Drivers | Quality |
|
||||
|----------|---------|---------|
|
||||
| Storage | ahcid, ided, nvmed, virtio-blkd, usbscsid | ✅ All hardened (Wave 4 complete) |
|
||||
| Network | e1000d, rtl8168d, rtl8139d, ixgbed, virtio-netd | ✅ All hardened |
|
||||
| Graphics | vesad, ihdgd, virtio-gpud | ✅ All hardened |
|
||||
| Input | ps2d, usbhidd | ✅ All hardened |
|
||||
| Audio | ihdad, ac97d, sb16d | ✅ All hardened |
|
||||
| USB | xhcid, usbhubd, usbctl, ucsid | ✅ xhcid has 88 Red Bear patches |
|
||||
| GPIO/I2C | gpiod, i2cd, intel-gpiod, amd-mp2-i2cd, dw-acpi-i2cd, i2c-gpio-expanderd, i2c-hidd, intel-thc-hidd, intel-lpss-i2cd | ✅ Present |
|
||||
| System | pcid, pcid-spawner, acpid | ✅ Core infra; pcid hardened Wave 1-2 |
|
||||
| VirtualBox | vboxd | ✅ x86 only |
|
||||
|
||||
#### Custom Red Bear Daemons
|
||||
|
||||
| Daemon | Quality | Notes |
|
||||
|--------|---------|-------|
|
||||
| `firmware-loader` | ✅ Well-tested | 18 unit tests; scheme:firmware with read/mmap; no signing |
|
||||
| `redox-drm` | 🚡 Bounded compile | AMD+Intel+VirtIO display; 68 tests; no HW validation |
|
||||
| `amdgpu` | 🚡 Bounded compile | Imported Linux DC/TTM/core; partial display glue |
|
||||
| `iommu` | 🚡 QEMU-proven | AMD-Vi detection + first-use proof; no HW validation |
|
||||
| `udev-shim` | ✅ Present | Scheme:udev with device enumeration |
|
||||
| `evdevd` | ✅ Present | Linux-compatible evdev interface |
|
||||
| `redbear-sessiond` | ✅ Present | D-Bus login1 session broker |
|
||||
| `redbear-wifictl` | 🚡 Host-tested | Wi-Fi control daemon; no real hardware |
|
||||
| `redbear-iwlwifi` | 🚡 Host-tested | Intel transport; ~2450 lines C + ~1550 lines Rust; 119 tests |
|
||||
| `redbear-btusb` | 🔴 Experimental | BLE-first; USB-attached only; QEMU validation in progress |
|
||||
| `redbear-authd` | ✅ Present | Local-user authentication |
|
||||
| `redbear-greeter` | 🚡 Partial | Greeter orchestrator; Qt Wayland integration broken |
|
||||
| `redbear-netctl` | ✅ Present | Network profile management |
|
||||
| `redbear-hwutils` | ✅ Present | lspci, lsusb, phase checkers |
|
||||
|
||||
### 2.3 Firmware Loading
|
||||
|
||||
**What exists:**
|
||||
- `scheme:firmware` daemon (`firmware-loader`) indexes blobs from `/lib/firmware/`
|
||||
- `linux-kpi` provides `request_firmware()` via Rust FFI
|
||||
- AMD GPU blobs (675 .bin files) in `local/firmware/amdgpu/` (gitignored, fetched from linux-firmware)
|
||||
- Intel DMC display blobs fetchable via `fetch-firmware.sh --vendor intel --subset dmc`
|
||||
- Two fetch mechanisms: standalone script (selective) + build-time meta-package (full linux-firmware)
|
||||
- `PCI_QUIRK_NEED_FIRMWARE` flag defined (bit 11), but never checked by any driver
|
||||
|
||||
**What is MISSING vs Linux 7.0 `firmware_class`:**
|
||||
- No firmware signing/verification (no `module_sig_check` equivalent)
|
||||
- No `request_firmware_nowait` with uevent dispatch to userspace helper (Linux uses `/sys/$DEVPATH/loading` + `/sys/$DEVPATH/data` + uevent to notify udev)
|
||||
- No persistent firmware cache between boots (in-memory only; Linux caches during suspend for resume-fastpath)
|
||||
- No fallback firmware variant search (if dmcub_dcn31.bin missing, try dmcub_dcn30.bin; Linux has per-driver firmware search paths)
|
||||
- No `/sys/firmware/` interface (Linux exposes firmware loading status via sysfs)
|
||||
- No firmware preloading at driver bind time
|
||||
- No timeout for synchronous `request_firmware` (blocks forever; Linux times out after ~60s with uevent fallback)
|
||||
- No platform firmware fallback (Linux can search UEFI firmware volumes via `firmware_request_platform()`)
|
||||
- No Wi-Fi firmware blobs (iwlwifi, ath10k, etc.)
|
||||
- No Bluetooth firmware blobs
|
||||
- No audio/media codec firmware
|
||||
- Firmware lookup limited to 3 hardcoded paths (Linux searches: `/lib/firmware/`, `/lib/firmware/updates/`, `/lib/firmware/$KVER/`, `/usr/lib/firmware/`, `/usr/share/firmware/`, plus custom path via kernel param)
|
||||
|
||||
### 2.4 Hardware Validation Status
|
||||
|
||||
| Subsystem | QEMU | Bare Metal | Notes |
|
||||
|-----------|------|------------|-------|
|
||||
| ACPI boot | ✅ | ✅ (AMD) | Boot-baseline; `_S5` shutdown not release-grade |
|
||||
| x2APIC/SMP | ✅ | ✅ | Multi-core works |
|
||||
| PCI enumeration | ✅ | ✅ | pcid enumerates devices |
|
||||
| MSI-X | ✅ (virtio-net) | ❌ | No hardware proof |
|
||||
| IOMMU/AMD-Vi | ✅ (first-use) | ❌ | Detection works; no HW validation |
|
||||
| xHCI interrupt | ✅ | ❌ | Interrupt mode proven; no HW |
|
||||
| USB storage | ✅ (readback) | ❌ | QEMU mass-storage proof |
|
||||
| NVMe | ✅ | ❌ | Builds; no HW |
|
||||
| AHCI | ✅ | ❌ | Builds; no HW |
|
||||
| Network (e1000/virtio) | ✅ | ❌ | QEMU only |
|
||||
| PS/2 keyboard | ✅ | ✅ | QEMU + AMD bare metal |
|
||||
| USB keyboard | ✅ (QEMU HID) | ⚠️ | Not reliable on bare metal |
|
||||
| Wi-Fi | ❌ | ❌ | Host-tested transport only |
|
||||
| Bluetooth | ❌ | ❌ | Experimental BLE; QEMU in progress |
|
||||
|
||||
### 2.5 Comparison with Linux 7.0 Device Init Model
|
||||
|
||||
#### 2.5.1 Linux Initcall Ordering (Reference)
|
||||
|
||||
Linux uses a 10-level initcall system for boot-phase ordering:
|
||||
|
||||
| Level | Macro | Typical Count | Example Uses |
|
||||
|-------|-------|---------------|--------------|
|
||||
| 0 | `pure_initcall` | ~few | Pure infrastructure |
|
||||
| early | `early_initcall` | ~446 | mm init, early console, DT scan |
|
||||
| 1 | `core_initcall` | ~614 | Workqueues, RCU, memory allocators |
|
||||
| 2 | `postcore_initcall` | ~150 | Clocksource, scheduler, IRQ core |
|
||||
| 3 | `arch_initcall` | ~751 | PCI bus init, ACPI table parsing, CPU bringup |
|
||||
| 4 | `subsys_initcall` | ~573 | PCI enumerate, USB core, networking core, block |
|
||||
| 5 | `fs_initcall` | ~1372 | Filesystem registration |
|
||||
| 6 | `device_initcall` | ~1211 | Most drivers; `module_init()` maps here |
|
||||
| 7 | `late_initcall` | ~440 | Late init, debug, tracing |
|
||||
|
||||
Red Bear OS has **no equivalent ordering mechanism** — the TOML-based init uses `requires_weak`
|
||||
for loose ordering but has no topological sort depth, no `Before`/`After` fields, no explicit
|
||||
init phases beyond the coarse initfs/rootfs split.
|
||||
|
||||
#### 2.5.2 Feature Comparison Table
|
||||
|
||||
| Feature | Linux 7.0 | Red Bear OS | Gap |
|
||||
|---------|-----------|-------------|-----|
|
||||
| **Driver model** | `bus_type` → `device_driver` → `probe()` binding with match tables | `pcid-spawner` spawns drivers by PCI class/vendor/device | 🟡 Partial — single-shot spawn, no rebinding |
|
||||
| **Deferred probing** | `driver_deferred_probe` — retries when dependency arrives; `-EPROBE_DEFER` triggers retry on any successful probe | None | 🔴 Missing — must be present at boot |
|
||||
| **Async probing** | `async_probe` — parallel driver init via kthreadd workers | Sequential spawn only | 🟡 Partial — oneshot_async for launch but not true async init |
|
||||
| **Hotplug** | uevent netlink → udev → driver bind/unbind; `/sbin/hotplug` path | `udev-shim` is a **static PCI enumerator** — one scan at boot, no event callbacks, no device removal handling | 🔴 Missing — no hotplug infrastructure at all |
|
||||
| **Firmware loading** | `firmware_class` with `request_firmware`, user helper, caching | `scheme:firmware` + `linux-kpi` request_firmware | 🟡 Partial — no uevent/helper/caching |
|
||||
| **USB controllers** | xHCI, EHCI, OHCI, UHCI — all supported | xHCI only | 🔴 Missing — EHCI/OHCI/UHCI absent |
|
||||
| **USB device classes** | HID, storage, audio, video, CDC, vendor, etc. | HID, hub, storage (BOT), CSI (UCSI) | 🟡 Partial — many classes missing |
|
||||
| **Power management** | Suspend/resume, runtime PM, CPU freq scaling, thermal | `_S5` shutdown only | 🔴 Missing — no S3/S4/PM |
|
||||
| **Interrupt handling** | Full APIC/x2APIC, MSI/MSI-X, affinity, NMI, MCE | APIC/x2APIC; MSI-X via quirks | 🟡 Partial — no affinity, no NMI watchdog |
|
||||
| **IOMMU** | AMD-Vi, Intel VT-d with DMA remapping + IR | AMD-Vi detection + first-use proof | 🟡 Partial — no VT-d, no hardware |
|
||||
| **ACPI namespace** | Full namespace: devices, thermal, battery, processor, etc. | Boot-baseline: MADT, FADT, `_S5`, bounded power | 🟡 Partial — many ACPI objects missing |
|
||||
| **PCIe features** | AER, ACS, ATS, PRI, PASID, SR-IOV | Basic PCI config space only | 🔴 Missing — no advanced PCIe |
|
||||
| **Device naming** | Predictable network/storage names (systemd udev) | None | 🟡 Partial — no naming policy |
|
||||
| **Hardware RNG** | `hw_random` framework, multiple drivers | None | 🔴 Missing |
|
||||
| **CPU frequency** | `cpufreq` governors | None | 🔴 Missing |
|
||||
| **Thermal management** | `thermal` framework + drivers | None | 🔴 Missing |
|
||||
| **SMBIOS/DMI** | Full DMI table exposure via sysfs | Quirks system has DMI data | 🟡 Partial — not runtime-exposed |
|
||||
| **Kernel cmdline** | Device parameters via boot cmdline | None | 🔴 Missing |
|
||||
|
||||
## 3. Implementation Phases
|
||||
|
||||
### Phase 1 — Driver Model Maturation (Weeks 1-8)
|
||||
|
||||
**Goal:** Establish a proper device driver model with binding semantics, deferred probing,
|
||||
and error resilience — bringing the driver infrastructure to Linux 7.0 par without rewriting
|
||||
existing drivers.
|
||||
|
||||
#### 1.1 Device-Driver Binding Model (Week 1-3)
|
||||
|
||||
Create a `redox-driver-core` library providing Linux-style bus/device/driver abstractions:
|
||||
|
||||
```
|
||||
Device → Driver matching:
|
||||
pcid: class=0x01, subclass=0x08 → nvmed
|
||||
pcid: vendor=0x8086, device=0x10D3 → e1000d
|
||||
|
||||
Driver probe() returns:
|
||||
Ok(()) → device bound, driver active
|
||||
Err(ENODEV) → device not supported by this driver
|
||||
Err(EAGAIN) → dependency not available, DEFER probe
|
||||
Err(...) → fatal error, device unusable
|
||||
```
|
||||
|
||||
**Deliverables:**
|
||||
- `redox-driver-core` crate with `Bus`, `Device`, `Driver` traits
|
||||
- `pcid` exposes devices via new scheme: `scheme:pci/devices/{id}/bind`
|
||||
- `pcid-spawner` replaced by `driver-manager` daemon that:
|
||||
- Reads driver match tables from `/lib/drivers.d/*.toml`
|
||||
- Probes drivers in priority order
|
||||
- Supports deferred probing (EAGAIN → retry when dependency appears)
|
||||
- Supports driver unbind/rebind
|
||||
- All existing `pcid.d/*.toml` match files migrated to new format
|
||||
- Backward compatible: existing pcid-spawner behavior preserved as fallback
|
||||
|
||||
#### 1.2 Async Device Probing (Week 4-5)
|
||||
|
||||
**Deliverables:**
|
||||
- `driver-manager` probes independent device trees in parallel (using Rust async or threads)
|
||||
- Device init order defined by dependency DAG, not sequential spawn
|
||||
- Timing observability: log probe duration per driver
|
||||
- `CONFIG_PARALLEL_PROBE` equivalent: max concurrent probes tunable via config TOML
|
||||
|
||||
#### 1.3 Driver Parameter System (Week 6-7)
|
||||
|
||||
**Deliverables:**
|
||||
- Kernel cmdline parsing in bootloader (e.g., `redbear.nvme.irq_mode=msi`)
|
||||
- `/scheme/sys/driver/{name}/parameters` read/write
|
||||
- Driver authors declare parameters via derive macro
|
||||
- `lspci -v` shows per-device parameters
|
||||
|
||||
#### 1.4 Hotplug Infrastructure (Week 7-8)
|
||||
|
||||
**Deliverables:**
|
||||
- PCIe hotplug: `pcid` detects surprise removal/addition, emits uevent
|
||||
- USB hotplug: `xhcid` emits uevent on device attach/detach
|
||||
- `udev-shim` enhanced to receive uevents and trigger driver binding
|
||||
- `driver-manager` handles hot-add (probe driver) and hot-remove (unbind driver)
|
||||
- Initial scope: PCIe hotplug and USB hotplug only; Thunderbolt deferred
|
||||
|
||||
**Phase 1 Exit Criteria:**
|
||||
- New driver binding model functional for 3+ existing drivers (nvmed, e1000d, xhcid)
|
||||
- Deferred probing works: driver returning EAGAIN retries when dependency scheme appears
|
||||
- Async probing measurable: 2+ independent PCI devices probe concurrently
|
||||
- Hotplug works: USB device attach/detach triggers udev-shim + driver bind/unbind in QEMU
|
||||
- All 25+ existing drivers still compile and function (backward compatibility)
|
||||
|
||||
### Phase 2 — Controller Coverage & Hardware Validation (Weeks 5-14)
|
||||
|
||||
**Goal:** Fill the critical controller gaps (USB EHCI/OHCI/UHCI) and validate the
|
||||
existing controller stack on real hardware — especially MSI-X, IOMMU, and xHCI.
|
||||
|
||||
#### 2.1 USB Controller Family Completion (Week 5-9)
|
||||
|
||||
This is the **highest-impact controller gap** because it directly blocks reliable
|
||||
USB keyboard input on bare metal where the keyboard may be routed through companion
|
||||
controllers rather than xHCI.
|
||||
|
||||
**Deliverables:**
|
||||
- `ehcid` daemon — EHCI (USB 2.0) host controller driver
|
||||
- `ohcid` daemon — OHCI (USB 1.1) host controller driver for non-Intel chipsets
|
||||
- `uhcid` daemon — UHCI (USB 1.1) host controller driver for Intel chipsets
|
||||
- USB companion controller routing: when xHCI owns the ports, companion controllers
|
||||
hand off low/full-speed devices to xHCI transparently
|
||||
- `usb-manager` daemon orchestrates multi-controller topology:
|
||||
- Single `scheme:usb` root exposing all buses
|
||||
- Device path stability across controller types
|
||||
- Port routing table for companion controller ownership handoff
|
||||
- USB 3.1/3.2 SuperSpeedPlus support in xhcid (10 Gbps, 20 Gbps)
|
||||
- USB-C PD/alt-mode awareness in `ucsid`
|
||||
|
||||
**Implementation approach:**
|
||||
- EHCI: Reference Linux `drivers/usb/host/ehci-hcd.c` (~6000 lines) and FreeBSD `sys/dev/usb/controller/ehci.c`
|
||||
- OHCI: Reference Linux `drivers/usb/host/ohci-hcd.c` (~3000 lines)
|
||||
- UHCI: Reference Linux `drivers/usb/host/uhci-hcd.c` (~2500 lines)
|
||||
- All three controllers use the same `scheme:usb` interface — class daemons (usbhubd, usbhidd, usbscsid) work unchanged
|
||||
|
||||
#### 2.2 xHCI Device-Level Hardening (Week 8-10)
|
||||
|
||||
Per the existing `XHCID-DEVICE-IMPROVEMENT-PLAN.md`:
|
||||
|
||||
**Deliverables:**
|
||||
- Atomic device attach publication (prevent half-attached devices)
|
||||
- Bounded device detach and purge
|
||||
- Configure rollback on failure
|
||||
- Real PM sequencing (U0/U1/U2/U3 transitions)
|
||||
- Enumerator cleanup and timing hardening
|
||||
- Growable event ring under sustained activity
|
||||
|
||||
#### 2.3 MSI-X Hardware Validation (Week 8-11)
|
||||
|
||||
Per the existing `IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` Priority 1:
|
||||
|
||||
**Deliverables:**
|
||||
- AMD GPU MSI-X validation: prove MSI-X vectors fire correctly on real AMD hardware
|
||||
- Intel GPU MSI-X validation: prove MSI-X on Intel hardware
|
||||
- NVMe MSI-X validation: prove per-queue interrupt vectors
|
||||
- xHCI MSI-X validation: prove interrupt-driven event ring on real hardware (not just QEMU)
|
||||
- Verified MSI-X → MSI → legacy IRQ fallback on all tested hardware
|
||||
- Logged CPU/vector affinity behavior
|
||||
- At minimum one AMD and one Intel bare-metal test report per device class
|
||||
|
||||
#### 2.4 IOMMU Hardware Bring-Up (Week 9-14)
|
||||
|
||||
Per the existing `IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` Priority 2:
|
||||
|
||||
**Deliverables:**
|
||||
- Validated AMD-Vi initialization on real AMD hardware
|
||||
- Device table / command buffer / event log validation
|
||||
- Interrupt remapping validation
|
||||
- Intel VT-d initial detection and register mapping (not full bring-up)
|
||||
- IOMMU fault-path validation: inject fault, verify event log capture
|
||||
- DMA remapping proof: verify device DMA is translated through IOMMU page tables
|
||||
- Negative-result documentation if hardware still fails
|
||||
|
||||
#### 2.5 ACPI Wave 1-2 Completion (Week 10-12)
|
||||
|
||||
Per the existing `ACPI-IMPROVEMENT-PLAN.md` Waves 1-2:
|
||||
|
||||
**Deliverables:**
|
||||
- Finish replacing panic-grade `expect` paths in `acpid` startup
|
||||
- Define and document AML bootstrap contract (explicit RSDP_ADDR producer)
|
||||
- Table-specific reject/warn/degrade/fail rules implemented
|
||||
- Deterministic `_S5` derivation (not dependent on PCI timing)
|
||||
- Explicit shutdown/reboot result semantics
|
||||
- Bounded shutdown proof on real AMD and Intel hardware
|
||||
- Sleep-state scope explicit: S5 only; S3/S4 explicitly deferred
|
||||
|
||||
**Phase 2 Exit Criteria:**
|
||||
- At least one EHCI or OHCI/UHCI driver functional in QEMU
|
||||
- USB keyboard reliably reachable on bare metal AMD and Intel (via xHCI, EHCI, or companion routing)
|
||||
- MSI-X validated on at least one real AMD GPU and one real Intel GPU
|
||||
- IOMMU AMD-Vi validated on at least one real AMD machine
|
||||
- ACPI `_S5` shutdown works on at least one real AMD and one real Intel machine
|
||||
- ACPI startup contains zero panic-grade paths reachable from firmware input
|
||||
|
||||
### Phase 3 — Power Management & Platform Services (Weeks 12-20)
|
||||
|
||||
**Goal:** Add suspend/resume, CPU frequency scaling, thermal management, and hardware
|
||||
RNG — bringing platform services to Linux 7.0 par for basic functionality.
|
||||
|
||||
#### 3.1 ACPI Power Management (Week 12-14)
|
||||
|
||||
Per the existing `ACPI-IMPROVEMENT-PLAN.md` Waves 3-4:
|
||||
|
||||
**Deliverables:**
|
||||
- Honest `/scheme/acpi/power` surface: exposes only behavior with runtime evidence
|
||||
- Consumer-visible distinction between unsupported, unavailable, and populated power state
|
||||
- Reduced surface: remove misleading empty-success defaults
|
||||
- AML physmem/EC failure propagation: no correctness-critical fabricated values
|
||||
- EC error typing and documented widened-access behavior
|
||||
- Documented AML mutex timeout behavior
|
||||
|
||||
#### 3.2 Suspend/Resume (S3 Sleep) — Initial Implementation (Week 13-16)
|
||||
|
||||
**Deliverables:**
|
||||
- Kernel: save/restore CPU context (CR0-CR4, MSRs, IDT/GDT, FPU/SSE/AVX state)
|
||||
- Kernel: ACPI S3 (suspend-to-RAM) entry via `_S3` AML method
|
||||
- Kernel: wake vector registration and resume path
|
||||
- `acpid`: expose `/scheme/acpi/sleep` with `S3` and `S5` states
|
||||
- Device contract: `suspend()` callback on each scheme daemon
|
||||
- Storage: flush caches, park heads (if spinning)
|
||||
- Network: bring link down, save MAC filter state
|
||||
- USB: save controller/port state
|
||||
- Graphics: save mode, blank display
|
||||
- `driver-manager`: suspend devices in dependency order, resume in reverse
|
||||
- Initial scope: S3 only on test hardware; S4 (hibernate) explicitly deferred
|
||||
|
||||
#### 3.3 CPU Frequency Scaling (Week 14-16)
|
||||
|
||||
**Deliverables:**
|
||||
- `cpufreqd` daemon reading ACPI `_PSS` / `_PPC` objects
|
||||
- Intel: P-state MSR writes (IA32_PERF_CTL)
|
||||
- AMD: P-state MSR writes + CPPC awareness
|
||||
- Governors: `performance` (max freq), `powersave` (min freq), `ondemand` (load-based)
|
||||
- `/scheme/cpufreq` for reading/setting governor and frequency
|
||||
- `redbear-info` shows current frequency and governor
|
||||
|
||||
#### 3.4 Thermal Management (Week 15-17)
|
||||
|
||||
**Deliverables:**
|
||||
- `thermald` daemon reading ACPI thermal zone objects (`_TMP`, `_PSV`, `_TC1`, `_TC2`)
|
||||
- Active cooling: fan control via ACPI `_SCP`
|
||||
- Passive cooling: CPU throttling via cpufreqd integration
|
||||
- Critical shutdown: if temperature exceeds `_CRT`, initiate clean shutdown
|
||||
- `/scheme/thermal` for reading zone temperatures and trip points
|
||||
- `redbear-info` shows thermal zone status
|
||||
|
||||
#### 3.5 Hardware RNG (Week 16-17)
|
||||
|
||||
**Deliverables:**
|
||||
- `hwrngd` daemon reading hardware RNG sources:
|
||||
- x86 RDRAND/RDSEED instructions
|
||||
- TPM 2.0 random number generator (if present)
|
||||
- VirtIO entropy device
|
||||
- `scheme:hwrng` feeding into `randd` entropy pool
|
||||
- `/scheme/hwrng` exposes raw entropy and health status
|
||||
- Linux 7.0 `hw_random` framework ported conceptually (not literally)
|
||||
|
||||
#### 3.6 PCIe Advanced Error Reporting (Week 17-18)
|
||||
|
||||
**Deliverables:**
|
||||
- `pcid` exposes AER capability registers via `/scheme/pci/{dev}/aer`
|
||||
- AER error detection: correctable and uncorrectable error status registers
|
||||
- Error logging: decode error source (data link, transaction, poison TLP, etc.)
|
||||
- `aer-inject` utility for testing error paths
|
||||
- Initial scope: error detection and logging only; error recovery (device reset path) deferred
|
||||
|
||||
#### 3.7 SMBIOS/DMI Runtime Exposure (Week 18-20)
|
||||
|
||||
**Deliverables:**
|
||||
- `dmidecode`-equivalent utility using `acpid` DMI scheme
|
||||
- `/scheme/dmi` exposes SMBIOS entry point and table data
|
||||
- `lspci -v` shows DMI-based quirk annotations
|
||||
- DMI data feeding into `redbear-info` for platform identification
|
||||
- Integration with existing quirks system: DMI match rules validated at runtime
|
||||
|
||||
**Phase 3 Exit Criteria:**
|
||||
- S3 suspend/resume works on at least one real machine (AMD or Intel)
|
||||
- CPU frequency scaling observable via `redbear-info`
|
||||
- Thermal zone temperature readable and critical shutdown testable
|
||||
- Hardware RNG feeding entropy pool
|
||||
- PCIe AER errors logged on capable hardware
|
||||
- DMI data accessible via scheme and tools
|
||||
- All new schemes documented with test procedures
|
||||
|
||||
### Phase 4 — Firmware Infrastructure & Wi-Fi Validation (Weeks 16-24)
|
||||
|
||||
**Goal:** Close firmware loading gaps, complete Wi-Fi hardware validation with real
|
||||
firmware, and establish firmware management as a first-class platform service.
|
||||
|
||||
#### 4.1 Firmware Loading Gap Closure (Week 16-18)
|
||||
|
||||
**Deliverables:**
|
||||
- `request_firmware_nowait` with proper uevent dispatch:
|
||||
- Async request → uevent → `udev-shim` listens → `firmware-loader` serves blob
|
||||
- Timeout: if firmware not available within configurable timeout, fail gracefully
|
||||
- Firmware fallback variant search:
|
||||
- If `dmcub_dcn31.bin` not found, try `dmcub_dcn30.bin`, `dmcub_dcn20.bin`
|
||||
- Per-driver fallback chain defined in `/etc/firmware-fallbacks.d/*.toml`
|
||||
- Persistent firmware cache (`/var/lib/firmware/`):
|
||||
- Loaded blobs cached on first use; survive daemon restart
|
||||
- Cache invalidation on firmware version change
|
||||
- `PCI_QUIRK_NEED_FIRMWARE` enforcement:
|
||||
- Drivers actually check the flag via `pci_has_quirk()`
|
||||
- When flag is set: require firmware at probe time, fail probe if absent
|
||||
- When flag is absent: firmware is optional, warn if missing but continue
|
||||
- Fetch Intel Wi-Fi firmware blobs: `fetch-firmware.sh --vendor intel --subset wifi`
|
||||
- Fetch Bluetooth firmware blobs where applicable
|
||||
- Firmware manifest: `/lib/firmware/MANIFEST.txt` lists all blobs, versions, sources
|
||||
|
||||
#### 4.2 Wi-Fi Hardware Validation (Week 16-22)
|
||||
|
||||
Per the existing `WIFI-IMPLEMENTATION-PLAN.md`:
|
||||
|
||||
**Deliverables:**
|
||||
- Real Intel Wi-Fi device (e.g., AX200/AX201/AX210) validated end-to-end
|
||||
- `redbear-iwlwifi` transport:
|
||||
- Firmware loaded via `request_firmware()` → `scheme:firmware`
|
||||
- DMA ring operation validated (TX reclaim, RX restock, command dispatch)
|
||||
- Interrupt handling validated (MSI-X or MSI path)
|
||||
- Association/authentication cycle completed with real AP
|
||||
- `redbear-wifictl` control plane:
|
||||
- Scan → connect → DHCP → disconnect cycle validated
|
||||
- WPA2-PSK and open network profiles functional
|
||||
- Profile persistence and boot-time application
|
||||
- `redbear-netctl` Wi-Fi profiles:
|
||||
- SSID/Security/Key parsing validated
|
||||
- Bounded Wi-Fi lifecycle (prepare → init-transport → activate-nic → connect → disconnect)
|
||||
- Wi-Fi runtime diagnostics:
|
||||
- `redbear-phase5-wifi-check` reports link quality, signal strength, connected AP
|
||||
- `redbear-info --verbose` shows Wi-Fi adapter status
|
||||
- At minimum one real Intel Wi-Fi chipset validated
|
||||
- Legacy IRQ fallback for platforms where MSI-X is unavailable (via quirks)
|
||||
|
||||
#### 4.3 Wi-Fi Desktop API (Week 20-24)
|
||||
|
||||
**Deliverables:**
|
||||
- D-Bus Wi-Fi API on system bus: `org.freedesktop.NetworkManager` subset
|
||||
- `GetDevices`, `GetAccessPoints`, `ActivateConnection`, `DeactivateConnection`
|
||||
- Signal: `AccessPointAdded`, `AccessPointRemoved`, `StateChanged`
|
||||
- `redbear-wifictl` exposes D-Bus interface for desktop consumption
|
||||
- `redbear-netctl` GUI client for scanning and connecting (Qt6-based, optional)
|
||||
- Desktop status bar Wi-Fi indicator (future KDE plasma-nm integration)
|
||||
|
||||
**Phase 4 Exit Criteria:**
|
||||
- `request_firmware_nowait` with uevent dispatch functional in QEMU
|
||||
- PCI_QUIRK_NEED_FIRMWARE enforced in at least one driver (amdgpu or iwlwifi)
|
||||
- Intel Wi-Fi chipset validated end-to-end with real AP
|
||||
- Wi-Fi scan → connect → DHCP → internet access completed on real hardware
|
||||
- Wi-Fi D-Bus API functional for at least get_devices and get_accesspoints
|
||||
- Firmware manifest tracks all loaded blobs with versions
|
||||
|
||||
### Phase 5 — Bluetooth, Device Policy, Polish (Weeks 20-30)
|
||||
|
||||
**Goal:** Bring Bluetooth to validated experimental status, establish device naming policy,
|
||||
and polish remaining gaps.
|
||||
|
||||
#### 5.1 Bluetooth Hardware Validation (Week 20-24)
|
||||
|
||||
Per the existing `BLUETOOTH-IMPLEMENTATION-PLAN.md`:
|
||||
|
||||
**Deliverables:**
|
||||
- `redbear-btusb` transport validated with real USB Bluetooth adapter
|
||||
- `redbear-btctl` HCI host validated:
|
||||
- Controller init sequence (reset, read local features, set event mask)
|
||||
- Device discovery (LE scan → advertising report → connect)
|
||||
- GATT service discovery
|
||||
- Basic data exchange (battery service, device info)
|
||||
- BLE peripheral connect/disconnect cycle validated
|
||||
- Bluetooth classic (BR/EDR) detection and basic inquiry (connect deferred)
|
||||
- `redbear-bluetooth-battery-check` works on real hardware
|
||||
- At minimum one real USB Bluetooth adapter validated
|
||||
|
||||
#### 5.2 Device Naming Policy (Week 22-24)
|
||||
|
||||
**Deliverables:**
|
||||
- Predictable network interface names:
|
||||
- `enp0s1` instead of `eth0` (PCIe bus/device/function based)
|
||||
- `/etc/systemd/network/` equivalent rules in `/etc/udev/rules.d/`
|
||||
- Predictable storage device names:
|
||||
- NVMe: `nvme0n1` instead of raw scheme path
|
||||
- AHCI: `sd{a,b,c}` assigned by port order
|
||||
- USB storage: `sdX` with stable enumeration
|
||||
- `/dev/disk/by-id/`, `/dev/disk/by-path/`, `/dev/disk/by-uuid/` symlinks
|
||||
- `udev-shim` enhanced with rule matching (vendor, model, serial, path patterns)
|
||||
|
||||
#### 5.3 Device Init Observability (Week 23-25)
|
||||
|
||||
**Deliverables:**
|
||||
- Boot-time device init timeline: log each device probe start/end with duration
|
||||
- `redbear-info --boot` shows device init timeline post-boot
|
||||
- Per-device init status: `redbear-info --device pci/00:02.0`
|
||||
- Kernel cmdline `redbear.init_verbose` enables verbose device init logging
|
||||
- Boot-time warning summary: all drivers that probed with warnings or deferrals
|
||||
- Device init health dashboard: `redbear-info --health` shows init status of all subsystems
|
||||
|
||||
#### 5.4 Remaining Gaps (Week 24-30)
|
||||
|
||||
**Deliverables:**
|
||||
- `nvmed` hardware validation: prove NVMe I/O on real hardware
|
||||
- `ahcid` hardware validation: prove SATA I/O on real hardware
|
||||
- `ihdad` hardware validation: prove audio output on real hardware
|
||||
- USB device class coverage expanded:
|
||||
- USB CDC ACM (serial): `usbcdcd` daemon
|
||||
- USB CDC ECM/NCM (ethernet): `usbnetd` daemon (or integrate into existing net drivers)
|
||||
- USB Audio Class 1/2: `usbaudiod` daemon
|
||||
- GPU hardware acceleration readiness:
|
||||
- Mesa radeonsi backend proof-of-concept (single draw call)
|
||||
- KMS atomic modesetting proof on real hardware (not just QEMU)
|
||||
- `redbear-btusb` autospawn via USB class matching
|
||||
- `kstop` shutdown event: gracefully stop all device daemons before power-off
|
||||
|
||||
**Phase 5 Exit Criteria:**
|
||||
- Bluetooth BLE discovery and basic data exchange works on real hardware
|
||||
- Network interfaces use predictable names on QEMU and bare metal
|
||||
- Device init timeline observable via `redbear-info --boot`
|
||||
- NVMe I/O validated on at least one real NVMe drive
|
||||
- Real audio output validated on at least one HDA codec
|
||||
- At least one USB device class beyond HID/storage validated (audio, serial, or ethernet)
|
||||
- All 25+ existing drivers maintain backward compatibility
|
||||
|
||||
## 4. Dependency Graph
|
||||
|
||||
```
|
||||
Phase 1 (Driver Model) ─────────────────────────────┐
|
||||
├── 1.1 Binding Model │
|
||||
├── 1.2 Async Probing (after 1.1) │
|
||||
├── 1.3 Driver Parameters (after 1.1) │
|
||||
└── 1.4 Hotplug (after 1.1) │
|
||||
│
|
||||
Phase 2 (Controllers) ───────────────────────────────┤
|
||||
├── 2.1 USB EHCI/OHCI/UHCI (parallel with 1.2) │
|
||||
├── 2.2 xHCI Hardening (parallel with 1.2) │
|
||||
├── 2.3 MSI-X HW Validation (after 1.1) │
|
||||
├── 2.4 IOMMU HW Bring-Up (parallel with 2.3) │
|
||||
└── 2.5 ACPI Wave 1-2 (parallel with 2.3) │
|
||||
│
|
||||
Phase 3 (Power Mgmt) ────────────────────────────────┤
|
||||
├── 3.1 ACPI Wave 3-4 (after 2.5) │
|
||||
├── 3.2 Suspend/Resume (after 3.1) │
|
||||
├── 3.3 CPU Freq Scaling (parallel with 3.2) │
|
||||
├── 3.4 Thermal Mgmt (after 3.1, parallel 3.3) │
|
||||
├── 3.5 Hardware RNG (parallel with 3.3) │
|
||||
├── 3.6 PCIe AER (after 2.3) │
|
||||
└── 3.7 SMBIOS/DMI (parallel with 3.6) │
|
||||
│
|
||||
Phase 4 (Firmware + Wi-Fi) ──────────────────────────┤
|
||||
├── 4.1 Firmware Gaps (after 1.1) │
|
||||
├── 4.2 Wi-Fi HW (after 4.1, parallel with 2.3) │
|
||||
└── 4.3 Wi-Fi Desktop API (after 4.2) │
|
||||
│
|
||||
Phase 5 (Bluetooth + Polish) ────────────────────────┤
|
||||
├── 5.1 BT HW Validation (parallel with 4.2) │
|
||||
├── 5.2 Device Naming (after 1.1) │
|
||||
├── 5.3 Init Observability (after 1.2) │
|
||||
└── 5.4 Remaining Gaps (after 3.2, 4.2, 5.1) │
|
||||
```
|
||||
|
||||
## 5. Resource Estimates
|
||||
|
||||
| Phase | Duration | Engineers | Key Risk |
|
||||
|-------|----------|-----------|----------|
|
||||
| Phase 1 | 8 weeks | 2 | Over-engineering the driver model; must stay backward compatible |
|
||||
| Phase 2 | 6-9 weeks | 3 (parallelizable) | Real hardware availability; USB controller complexity |
|
||||
| Phase 3 | 8 weeks | 2-3 | ACPI firmware quality varies wildly on real hardware |
|
||||
| Phase 4 | 8 weeks | 2 | Wi-Fi hardware procurement; firmware licensing |
|
||||
| Phase 5 | 10 weeks | 2 | Long tail of device class drivers |
|
||||
|
||||
**Total:** 26-40 weeks (~6-10 months) with 2-3 engineers, depending on parallelism and
|
||||
hardware availability.
|
||||
|
||||
## 6. Risk Register
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|-------------|--------|------------|
|
||||
| No access to AMD GPU with MSI-X | Medium | High | Partner with community; use Intel GPU as alternative |
|
||||
| No access to AMD machine with IOMMU | Medium | High | Prioritize Intel VT-d if AMD hardware unavailable |
|
||||
| USB EHCI/OHCI/UHCI significantly harder than estimated | Medium | High | Scope to EHCI-only initially; UHCI/OHCI deferred |
|
||||
| ACPI firmware corruption on test machines causes false failures | High | Medium | Test on 3+ machines per platform class |
|
||||
| Wi-Fi firmware licensing prevents redistribution | Low | Medium | Keep firmware external (fetched, not committed) |
|
||||
| Existing driver regression from new driver model | Medium | High | Extensive backward compat testing; parallel old/new paths |
|
||||
| S3 suspend/resume crashes unrecoverably on some hardware | High | Medium | Gate behind config flag; S3 is opt-in initially |
|
||||
|
||||
## 7. Success Criteria (Definition of Done)
|
||||
|
||||
This plan is complete when:
|
||||
|
||||
1. **Driver Model:** New driver binding model works for all existing drivers; deferred probing
|
||||
retries correctly; async probing measurably parallel; hotplug adds/removes devices without reboot.
|
||||
|
||||
2. **USB Controllers:** At least one non-xHCI controller (EHCI preferred) functional; USB keyboard
|
||||
reliable on bare metal AMD and Intel.
|
||||
|
||||
3. **Hardware Validation:** MSI-X proven on real AMD + Intel GPU; IOMMU AMD-Vi proven on real
|
||||
AMD machine; ACPI `_S5` shutdown proven on real AMD + Intel; NVMe I/O proven on real hardware.
|
||||
|
||||
4. **Power Management:** S3 suspend/resume works on at least one real machine; CPU frequency
|
||||
scaling observable; thermal shutdown testable.
|
||||
|
||||
5. **Firmware:** `request_firmware_nowait` with uevent dispatch; `PCI_QUIRK_NEED_FIRMWARE`
|
||||
enforced; Wi-Fi firmware loaded end-to-end on real hardware.
|
||||
|
||||
6. **Wi-Fi:** Intel Wi-Fi chipset validated end-to-end with real AP; scan → connect → DHCP →
|
||||
internet access verified.
|
||||
|
||||
7. **Bluetooth:** BLE discovery and basic data exchange on real hardware; HCI init sequence
|
||||
validated; GATT service discovery functional.
|
||||
|
||||
8. **Observability:** Device init timeline observable; per-device init status queryable;
|
||||
boot-time warning summary available.
|
||||
|
||||
9. **No regressions:** All 25+ existing drivers still work; all QEMU validation scripts still pass;
|
||||
`redbear-mini` and `redbear-full` still boot to login prompt.
|
||||
|
||||
## 8. Relationship to Existing Plans
|
||||
|
||||
This plan is the **canonical device initialization plan**. It supersedes or integrates with:
|
||||
|
||||
| Existing Plan | Relationship |
|
||||
|---------------|-------------|
|
||||
| `IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` | Absorbed: MSI-X (P1), IOMMU (P2) become Phase 2.3-2.4 here |
|
||||
| `ACPI-IMPROVEMENT-PLAN.md` | Integrated: Waves 1-4 become Phase 2.5 + Phase 3.1-3.2 here |
|
||||
| `USB-IMPLEMENTATION-PLAN.md` | Integrated: xHCI hardening + controller gaps become Phase 2.1-2.2 here |
|
||||
| `XHCID-DEVICE-IMPROVEMENT-PLAN.md` | Integrated: 7-phase xhcid plan consolidated into Phase 2.2 here |
|
||||
| `WIFI-IMPLEMENTATION-PLAN.md` | Absorbed: Wi-Fi hardware validation becomes Phase 4.2 here |
|
||||
| `BLUETOOTH-IMPLEMENTATION-PLAN.md` | Absorbed: BT validation becomes Phase 5.1 here |
|
||||
| `BOOT-PROCESS-ASSESSMENT.md` | Input: boot flow, service ordering, pcid-spawner fix already applied |
|
||||
| `BOOT-PROCESS-IMPROVEMENT-PLAN.md` | Input: kernel 4GiB fix, DRM/KMS, greeter UI (already addressed) |
|
||||
| `CONSOLE-TO-KDE-DESKTOP-PLAN.md` | Orthogonal: this plan focuses on device init, not desktop path |
|
||||
|
||||
Existing plans remain as reference material for historical detail and subsystem-specific
|
||||
technical depth. This plan is the execution authority for sequencing and acceptance criteria.
|
||||
|
||||
## 9. Immediate Next Actions (Week 1 Priorities)
|
||||
|
||||
1. **Create `redox-driver-core` crate** — define `Bus`, `Device`, `Driver` traits
|
||||
2. **Read Linux 7.0 `drivers/base/driver.c`** — understand the driver binding model to adapt
|
||||
3. **Audit `pcid` scheme interface** — what device info is already exposed vs what's needed
|
||||
4. **Select USB EHCI reference implementation** — Linux `ehci-hcd.c` or FreeBSD `ehci.c`
|
||||
5. **Procure test hardware** — at minimum: one AMD machine with AMD GPU + one Intel machine with Intel GPU
|
||||
6. **Set up USB keyboard test matrix** — catalog existing USB keyboards and host controllers
|
||||
7. **Create firmware manifest template** — define format for `/lib/firmware/MANIFEST.txt`
|
||||
8. **Schedule MSI-X hardware validation session** — reserve time on test machines for Phase 2.3
|
||||
|
||||
---
|
||||
|
||||
*This plan will be updated as implementation progresses. Each phase section will receive
|
||||
detailed task breakdown (similar to the ACPI and IRQ plans' execution slice format) before
|
||||
that phase begins.*
|
||||
@@ -0,0 +1,308 @@
|
||||
# Red Bear OS Greeter/Login System — Comprehensive Analysis
|
||||
|
||||
**Generated:** 2026-04-26
|
||||
**Based on:** Source code analysis of `redbear-authd`, `redbear-greeter`, `redbear-sessiond`, `redbear-session-launch`, `redbear-login-protocol`, init service configuration, and the GREETER-LOGIN-IMPLEMENTATION-PLAN.md.
|
||||
|
||||
---
|
||||
|
||||
## 1. System Architecture
|
||||
|
||||
### 1.1 Component Topology
|
||||
|
||||
```
|
||||
Qt6/QML Login Surface (redbear-greeter-ui, VT3)
|
||||
│ Unix socket /run/redbear-greeterd.sock (JSON, line-delimited)
|
||||
↓
|
||||
redbear-greeterd (orchestrator daemon, root-owned, VT3)
|
||||
│ Unix socket /run/redbear-authd.sock (AuthRequest/AuthResponse JSON)
|
||||
↓
|
||||
redbear-authd (privileged auth daemon, /etc/shadow verification)
|
||||
│ spawns via Command::
|
||||
↓
|
||||
redbear-session-launch (uid/gid drop + env bootstrap)
|
||||
│ exec's
|
||||
↓
|
||||
dbus-run-session -- redbear-kde-session → redbear-compositor --drm + plasmashell
|
||||
|
||||
(redbear-sessiond on system D-Bus → org.freedesktop.login1 for KWin device access)
|
||||
```
|
||||
|
||||
**Key socket paths:**
|
||||
| Socket | Owner | Mode | Purpose |
|
||||
|--------|-------|------|---------|
|
||||
| `/run/redbear-authd.sock` | root | 0o600 | greeterd → authd |
|
||||
| `/run/redbear-greeterd.sock` | greeter user | 0o660 | greeter-ui → greeterd |
|
||||
| `/run/redbear-sessiond-control.sock` | root | 0o600 | authd → sessiond (JSON SessiondUpdate) |
|
||||
| `/run/seatd.sock` | root | 0o666 | seatd abstract namespace |
|
||||
|
||||
---
|
||||
|
||||
## 2. Password Verification (authd)
|
||||
|
||||
**Source:** `local/recipes/system/redbear-authd/source/src/main.rs` lines 101–214
|
||||
|
||||
**Storage:** Reads `/etc/passwd` (user/uid/gid/home/shell) and `/etc/shadow` (password hash).
|
||||
|
||||
**Format detection:** Both Redox-style (`;`-delimited) and Unix-style (`:`-delimited) passwd/shadow/group entries are auto-detected per-line (line 88–99 in authd main.rs).
|
||||
|
||||
**Hash verification (lines 183–193):**
|
||||
```rust
|
||||
fn verify_shadow_password(password: &str, shadow_hash: &str) -> Result<bool, VerifyError> {
|
||||
if shadow_hash.starts_with("$6$") || shadow_hash.starts_with("$5$") {
|
||||
// SHA-512 or SHA-256 crypt (sha-crypt crate, pure Rust)
|
||||
return Ok(ShaCrypt::default().verify_password(password.as_bytes(), shadow_hash).is_ok());
|
||||
}
|
||||
if shadow_hash.starts_with("$argon2") {
|
||||
// Argon2id (rust-argon2 crate)
|
||||
return Ok(verify_encoded(shadow_hash, password.as_bytes()).unwrap_or(false));
|
||||
}
|
||||
Err(VerifyError::UnsupportedHashFormat)
|
||||
}
|
||||
```
|
||||
|
||||
**Plain-text fallback:** Non-`$` hash strings are compared directly (line 213). Used for unshadowed entries.
|
||||
|
||||
**Lockout policy (lines 237–270):**
|
||||
- 5 failures in 60s → 30-second lockout
|
||||
- Rejects locked accounts (`!` or `*` prefix)
|
||||
- UID < 1000 rejected (except UID 0)
|
||||
|
||||
**Approval system (lines 216–287):**
|
||||
- Successful auth stores 15-second in-memory approval keyed to `username + VT`
|
||||
- Session start requires valid (non-expired, VT-matched) approval ticket
|
||||
|
||||
---
|
||||
|
||||
## 3. Communication: UI ↔ greeterd ↔ authd
|
||||
|
||||
**Protocol:** `redbear-login-protocol` crate (`local/recipes/system/redbear-login-protocol/source/src/lib.rs`)
|
||||
|
||||
```rust
|
||||
// greeterd → authd
|
||||
AuthRequest::Authenticate { request_id, username, password, vt }
|
||||
AuthRequest::StartSession { request_id, username, session: "kde-wayland", vt }
|
||||
AuthRequest::PowerAction { request_id, action: "shutdown"|"reboot" }
|
||||
|
||||
// authd → greeterd
|
||||
AuthResponse::AuthenticateResult { request_id, ok, message }
|
||||
AuthResponse::SessionResult { request_id, ok, exit_code, message }
|
||||
AuthResponse::PowerResult { request_id, ok, message }
|
||||
AuthResponse::Error { request_id, message }
|
||||
```
|
||||
|
||||
```rust
|
||||
// UI → greeterd
|
||||
GreeterRequest::SubmitLogin { username, password }
|
||||
|
||||
// greeterd → UI
|
||||
GreeterResponse::LoginResult { ok, state, message }
|
||||
GreeterResponse::ActionResult { ok, message }
|
||||
```
|
||||
|
||||
**greeterd state machine:**
|
||||
```
|
||||
Starting → GreeterReady → Authenticating → LaunchingSession → SessionRunning
|
||||
↓
|
||||
ReturningToGreeter → GreeterReady
|
||||
↓
|
||||
FatalError (after 3 restarts/60s)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Session Launch
|
||||
|
||||
**Source:** `local/recipes/system/redbear-session-launch/source/src/main.rs` lines 352–385
|
||||
|
||||
1. Reads `/etc/passwd` + `/etc/group` for uid/gid/groups
|
||||
2. Creates `XDG_RUNTIME_DIR` (`/run/user/$UID` or `/tmp/run/user/$UID`), chown 0700
|
||||
3. Builds clean env: `HOME`, `USER`, `LOGNAME`, `SHELL`, `PATH=/usr/bin:/bin`, `XDG_RUNTIME_DIR`, `WAYLAND_DISPLAY=wayland-0`, `XDG_SEAT=seat0`, `XDG_VTNR`, `LIBSEAT_BACKEND=seatd`, `SEATD_SOCK=/run/seatd.sock`, `XDG_SESSION_TYPE=wayland`, `XDG_CURRENT_DESKTOP=KDE`, `KDE_FULL_SESSION=true`, `XDG_SESSION_ID=c1`
|
||||
4. `env_clear()` → setuid + setgid + setgroups
|
||||
5. `exec /usr/bin/dbus-run-session -- /usr/bin/redbear-kde-session`
|
||||
6. Fallback: direct `redbear-kde-session` if `dbus-run-session` absent
|
||||
|
||||
**redbear-kde-session** (from `docs/05-KDE-PLASMA-ON-REDOX.md`):
|
||||
```bash
|
||||
export WAYLAND_DISPLAY=wayland-0
|
||||
export XDG_RUNTIME_DIR=/tmp/run/user/0
|
||||
dbus-daemon --system &
|
||||
eval $(dbus-launch --sh-syntax)
|
||||
redbear-compositor --drm &
|
||||
sleep 2 && plasmashell &
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Init Service Wiring
|
||||
|
||||
**From `config/redbear-full.toml`:**
|
||||
|
||||
```
|
||||
Service order:
|
||||
12_dbus.service (system D-Bus)
|
||||
13_redbear-sessiond.service (org.freedesktop.login1 broker)
|
||||
13_seatd.service (seat management)
|
||||
19_redbear-authd.service (auth daemon, /usr/bin/redbear-authd)
|
||||
20_greeter.service (greeterd, /usr/bin/redbear-greeterd, VT=3)
|
||||
29_activate_console.service (inputd -A 2 → VT2 fallback)
|
||||
30_console.service (getty 2, respawn)
|
||||
31_debug_console.service (getty debug, respawn)
|
||||
```
|
||||
|
||||
`20_greeter.service`:
|
||||
```toml
|
||||
cmd = "/usr/bin/redbear-greeterd"
|
||||
envs = { VT = "3", REDBEAR_GREETER_USER = "greeter" }
|
||||
type = "oneshot_async"
|
||||
```
|
||||
|
||||
**Greeter user account** (redbear-full.toml):
|
||||
```toml
|
||||
[users.greeter]
|
||||
password = ""
|
||||
uid = 101
|
||||
gid = 101
|
||||
home = "/nonexistent"
|
||||
shell = "/usr/bin/ion"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. D-Bus Integration
|
||||
|
||||
**redbear-sessiond** — `org.freedesktop.login1` on **system D-Bus** via `zbus`:
|
||||
- `Manager.ListSessions`, `Manager.GetSeat`, `PrepareForShutdown` signal
|
||||
- `Seat.SwitchTo(vt)` → `inputd -A <vt>`
|
||||
- `Session.TakeDevice`/`ReleaseDevice` → DRM/input device fd passing
|
||||
- `Session.TakeControl`/`ReleaseControl`
|
||||
- Service file: `/usr/share/dbus-1/system-services/org.freedesktop.login1.service`
|
||||
|
||||
**authd and greeterd are NOT D-Bus activated** — started directly by init services.
|
||||
|
||||
**greeter compositor** starts a **session D-Bus** via `dbus-launch`.
|
||||
|
||||
---
|
||||
|
||||
## 7. Quality and Robustness Assessment
|
||||
|
||||
### 7.1 Strengths
|
||||
|
||||
| Area | Assessment | Detail |
|
||||
|------|------------|--------|
|
||||
| **Hash algorithm** | ✅ Excellent | SHA-512 (`$6$`), SHA-256 (`$5$`), Argon2id — all pure-Rust crates, no MD5/DES |
|
||||
| **Constant-time comparison** | ✅ Good | `sha-crypt::verify_password` and `argon2::verify_encoded` are constant-time by design |
|
||||
| **Approval windowing** | ✅ Good | 15s approval between auth and session start, VT-bound |
|
||||
| **Lockout policy** | ✅ Good | 5 attempts / 60s → 30s lockout |
|
||||
| **Socket permissions** | ✅ Good | authd socket = 0o600, greeterd socket = 0o660 |
|
||||
| **UID restriction** | ✅ Good | UID < 1000 (non-root) disallowed |
|
||||
| **Restart bounding** | ✅ Good | 3 restarts/60s → FatalError, fallback consoles preserved |
|
||||
| **Protocol type safety** | ✅ Good | `redbear-login-protocol` crate is single source of truth for all JSON types |
|
||||
| **Plain-text fallback** | ⚠️ Acceptable | Non-`$` hash strings compared directly — OK for initial dev users |
|
||||
| **Fail-closed on unknown hash** | ✅ Good | `UnsupportedHashFormat` → login rejected, not bypassed |
|
||||
| **Greeter isolates UI crash** | ✅ Good | compositor survives UI crash; respawns UI only |
|
||||
|
||||
### 7.2 Weaknesses and Risks
|
||||
|
||||
| # | Issue | Severity | Location | Impact |
|
||||
|---|-------|----------|-----------|--------|
|
||||
| W1 | **No PAM integration** | Medium | authd is custom narrow auth | Limits enterprise use, no pluggable auth modules |
|
||||
| W2 | **Approval in-memory only** | Medium | authd `HashMap` | authd crash → approvals lost; session start fails after crash |
|
||||
| W3 | **No password quality enforcement** | Low | authd only checks lockout | Weak passwords accepted (acceptable for Phase 2) |
|
||||
| W4 | **Hardcoded `kde-wayland` session** | Low | authd line 301, session-launch line 335 | No session chooser, no alternative desktops |
|
||||
| W5 | **greeterd not respawned by init** | Medium | `20_greeter.service` type=oneshot_async | If greeterd crashes, system stuck at console (no auto-recovery) |
|
||||
| W6 | **No seatd watchdog** | Medium | seatd service has no internal restart | seatd crash → compositor immediately fails |
|
||||
| W7 | **Static device_map.rs** | Medium | major/minor hardcoded table | Non-static hardware (USB GPUs, etc.) not discovered |
|
||||
| W8 | **No session tracking via D-Bus** | Low | authd → sessiond via raw JSON socket | `SetSession`/`ResetSession` bypass login1 surface |
|
||||
| W9 | **Power action fallbacks missing** | Low | authd calls `/usr/bin/shutdown`, `/usr/bin/reboot` | May not exist on Redox; failure is silent |
|
||||
| W10 | **greeterd socket path hardcoded** | Low | `/run/redbear-greeterd.sock` vs XDG_RUNTIME_DIR | Works for single-seat; breaks in multi-seat |
|
||||
| W11 | **greeter init service is `true` stub** | **Critical** | `redbear-greeter-services.toml` → `20_greeter.service cmd = "true"` | Real greeter only in `redbear-full.toml`; mini/grub don't have it |
|
||||
| W12 | ~~redbear-greeter-compositor missing from image~~(resolved) | Low | Recipe installs to both `/usr/bin/` and `/usr/share/redbear/greeter/`; main.rs checks both | compositor binary available via both paths |
|
||||
| W13 | ~~dbus-run-session may not exist in image~~(resolved) | Low | dbus in redbear-mini config (inherit by redbear-full); session-launch prefers `/usr/bin/dbus-run-session`; dbus recipe installs it | D-Bus session bus available |
|
||||
|
||||
### 7.3 Greeter Login-Screen Prerequisites (most resolved; bounded QEMU proof now passes)
|
||||
|
||||
*Note: As of 2026-04-29, the bounded `redbear-full` QEMU greeter proof passes (`GREETER_HELLO=ok`, `GREETER_VALID=ok`). Most items below are satisfied by the active config; remaining items are "verify via build."*
|
||||
|
||||
| Blocker | Source | Fix |
|
||||
|---------|--------|-----|
|
||||
| greeter init service stub in greeter-services.toml | `20_greeter.service cmd = "true"` | Use `redbear-full.toml` service definition (already correct there) |
|
||||
| ~~compositor binary path mismatch~~ (resolved) | Recipe installs to both `/usr/bin/` and `/usr/share/redbear/greeter/`; greeterd checks both | No action needed |
|
||||
| seatd package in config | seatd = {} now present in redbear-full.toml packages section | Rebuild to include seatd in image |
|
||||
| redbear-authd now in config | authd recipe in redbear-full config | Verify authd binary reaches image via build |
|
||||
| redbear-sessiond now in config | sessiond inherited from redbear-mini config | Verify sessiond binary reaches image via build |
|
||||
| greeter user account present in config | `[users.greeter]` in redbear-full config | Verify greeter user uid=101 in /etc/passwd in image after build |
|
||||
| compositor requires DRM but QEMU has none | `redbear-compositor --drm` fails in VM | Use `--virtual` in VM; compositor script already handles this |
|
||||
|
||||
---
|
||||
|
||||
## 8. File Path Reference
|
||||
|
||||
| Artifact | Path |
|
||||
|---|---|
|
||||
| authd binary | `/usr/bin/redbear-authd` |
|
||||
| authd socket | `/run/redbear-authd.sock` |
|
||||
| greeterd socket | `/run/redbear-greeterd.sock` |
|
||||
| greeterd binary | `/usr/bin/redbear-greeterd` |
|
||||
| greeter-ui binary | `/usr/bin/redbear-greeter-ui` |
|
||||
| compositor script | `/usr/bin/redbear-greeter-compositor` |
|
||||
| compositor (share) | `/usr/share/redbear/greeter/redbear-greeter-compositor` |
|
||||
| session-launch binary | `/usr/bin/redbear-session-launch` |
|
||||
| sessiond binary | `/usr/bin/redbear-sessiond` |
|
||||
| greeterd init service | `/usr/lib/init.d/20_greeter.service` |
|
||||
| authd init service | `/usr/lib/init.d/19_redbear-authd.service` |
|
||||
| sessiond init service | `/usr/lib/init.d/13_redbear-sessiond.service` |
|
||||
| seatd init service | `/usr/lib/init.d/13_seatd.service` |
|
||||
| greeter background | `/usr/share/redbear/greeter/background.png` |
|
||||
| greeter icon | `/usr/share/redbear/greeter/icon.png` |
|
||||
| sessiond control socket | `/run/redbear-sessiond-control.sock` |
|
||||
| seatd socket | `/run/seatd.sock` |
|
||||
| passwd file | `/etc/passwd` (redox `;` or unix `:` delimited) |
|
||||
| shadow file | `/etc/shadow` |
|
||||
| group file | `/etc/group` |
|
||||
| greeter user account | uid=101, gid=101 in /etc/passwd |
|
||||
|
||||
---
|
||||
|
||||
## 9. Improvement Recommendations (Priority Order)
|
||||
|
||||
### P0 — Make Greeter Actually Reach Login Screen
|
||||
|
||||
1. **Fix greeter init service**: Ensure `20_greeter.service` in `redbear-full.toml` (not the stub in greeter-services.toml) is the canonical one. greeter-services.toml is a bounded proof fragment; the real service lives in redbear-full.toml.
|
||||
2. **Verify all 5 greeter packages are in redbear-full.toml**: `seatd`, `redbear-authd`, `redbear-sessiond`, `redbear-session-launch`, `redbear-greeter`
|
||||
3. **Verify compositor binary at `/usr/bin/redbear-greeter-compositor`** in the built image
|
||||
4. **Verify greeter user (uid=101) exists** in /etc/passwd in image
|
||||
5. **Add compositor fallback** to `--virtual` when `--drm` fails (script already does this)
|
||||
|
||||
### P1 — Hardening
|
||||
|
||||
6. **Add respawn to greeterd init service**: `type = "oneshot_async", respawn = true` — greeterd crash shouldn't leave system at console
|
||||
7. **Add seatd respawn**: same logic
|
||||
8. **Fix redbear-sessiond `Seat::SwitchTo`** to return error rather than silently ignore failures
|
||||
9. **Add watchdog for greeterd** — if greeterd crashes, init should restart it
|
||||
|
||||
### P2 — Security Hardening
|
||||
|
||||
10. **Add password quality enforcement**: minimum length, entropy check before accepting
|
||||
11. **Rate-limit by source IP/VT**: prevent VT-based brute force
|
||||
12. **Add audit log for auth failures**: log to syslog or dedicated auth log
|
||||
13. **Add session listing via control socket**: currently authd writes `SetSession`/`ResetSession` but there's no readback mechanism
|
||||
|
||||
### P3 — Architectural
|
||||
|
||||
14. **Implement `TakeDevice`/`ReleaseDevice` fully**: current session.rs has the skeleton but device fd passing needs verification
|
||||
15. **Dynamic device enumeration**: replace static device_map.rs with udev-shim runtime queries
|
||||
16. **Add greeter watchdog daemon**: separate from greeterd, monitors and restarts it
|
||||
17. **D-Bus activate greeterd and authd**: remove init service startup dependency, use D-Bus activation instead
|
||||
18. **Add power action binaries**: create `/usr/bin/shutdown` and `/usr/bin/reboot` symlinks or wrappers that call init system
|
||||
19. **Implement `PrepareForShutdown`/`PrepareForSleep` signals**: for session cleanup on system power events
|
||||
|
||||
### P4 — Future
|
||||
|
||||
20. **Add PAM integration** via a minimal PAM-like module system in authd
|
||||
21. **Add session chooser** (console vs kde-wayland) via greeter UI
|
||||
22. **Multi-seat support**: XDG_RUNTIME_DIR per seat, greeterd socket per seat
|
||||
23. **Fingerprint/webauthn support**: extend authd protocol + greeter UI
|
||||
|
||||
---
|
||||
|
||||
*End of Analysis*
|
||||
@@ -0,0 +1,417 @@
|
||||
# Intel HDA Implementation Plan
|
||||
|
||||
**Version:** 1.0 (2026-04-24)
|
||||
**Status:** Draft execution plan
|
||||
**Scope owner:** Audio subsystem (legacy HDA + Intel DSP decision path)
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the concrete execution plan for implementing full Intel audio support in Red Bear OS, using Linux 7.0 source code in-tree as donor reference material.
|
||||
|
||||
"Full Intel support" is split into three tracks:
|
||||
|
||||
1. Legacy PCI HDA controller + analog codecs (current `ihdad` path)
|
||||
2. HDMI/DP digital audio over HDA links
|
||||
3. Modern Intel DSP-class platforms (SOF/AVS-class routing, not legacy-only HDA)
|
||||
|
||||
## Why This Plan Is Needed
|
||||
|
||||
Current in-tree evidence shows `ihdad` is an early implementation, not a complete Intel audio stack:
|
||||
|
||||
- Single-codec assumption in enumeration logic (`device.rs`)
|
||||
- Unimplemented controller interrupt handler (`handle_controller_interrupt`)
|
||||
- Fixed-format playback setup (44.1kHz / 16-bit / stereo)
|
||||
- Incomplete scheme surface (`Handle::Todo`-centric behavior)
|
||||
- No complete capture path integration in `audiod` (`TODO: audio input`)
|
||||
- Historical hardware report: "No audio, HDA driver cannot find output pins"
|
||||
|
||||
## Current Stack Snapshot
|
||||
|
||||
### Driver and daemon surface
|
||||
|
||||
- `ihdad` registers `audiohw`
|
||||
- `audiod` opens `/scheme/audiohw` and exposes `/scheme/audio`
|
||||
- SDL backends use `/scheme/audio`
|
||||
|
||||
### Known contract constraints
|
||||
|
||||
- `audiod` mixes fixed-size buffers (`HW_BUFFER_SIZE = 512`)
|
||||
- `ihdad` stream writes currently assume strict block sizing
|
||||
- `ihdad` currently hardcodes one primary output format on setup
|
||||
|
||||
## Canonical Donor Sources (Linux 7.0 in-tree)
|
||||
|
||||
- Controller policy and quirks:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/hda/controllers/intel.c`
|
||||
- Generic parser and fixup engine:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/hda/common/auto_parser.c`
|
||||
- Core codec/controller plumbing:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/hda/common/`
|
||||
- Vendor codec implementations:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/hda/codecs/`
|
||||
- Intel DSP route-selection policy:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/hda/core/intel-dsp-config.c`
|
||||
- Modern Intel DSP implementations:
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/soc/sof/intel/`
|
||||
- `build/linux-kernel-cache/linux-7.0/sound/soc/intel/avs/`
|
||||
|
||||
## Execution Model
|
||||
|
||||
The plan is organized as issue-sized work packages (`HDA-001`..`HDA-012`).
|
||||
|
||||
### Phase A: Legacy HDA correctness (must complete first)
|
||||
|
||||
#### HDA-001 — Multi-codec and function-group support
|
||||
|
||||
**Goal:** Remove single-codec assumptions and support real codec topology.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/node.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Codec enumeration includes all detected codecs
|
||||
- Bring-up does not assume first codec is the audio path
|
||||
- `audiohw:codec` dump reflects multi-codec topology
|
||||
|
||||
#### HDA-002 — Controller interrupts and unsolicited events
|
||||
|
||||
**Goal:** Implement real controller interrupt handling and unsol event dispatch.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/cmdbuff.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- `handle_controller_interrupt()` is non-stub
|
||||
- Jack-related unsol events are observable and processed
|
||||
- No interrupt-ack regressions under continuous playback
|
||||
|
||||
#### HDA-003 — Format/rate/channel negotiation
|
||||
|
||||
**Goal:** Replace fixed-format startup with negotiated stream format.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/stream.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Driver selects supported stream format from capabilities
|
||||
- Unsupported format requests fail deterministically
|
||||
- Startup no longer assumes 44.1kHz/16-bit/stereo only
|
||||
|
||||
#### HDA-004 — Real scheme endpoint model (`pcmout`/`pcmin`)
|
||||
|
||||
**Goal:** Replace `Handle::Todo` behavior with structured stream handles.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/audiod/src/scheme.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Distinct playback and capture endpoints exist
|
||||
- Handle lifecycle and permissions are explicit
|
||||
- Multiple clients can be supported without implicit index-0 fallback
|
||||
|
||||
#### HDA-005 — Capture and duplex path
|
||||
|
||||
**Goal:** Implement and validate simultaneous input/output.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/stream.rs`
|
||||
- `recipes/core/base/source/audiod/src/main.rs`
|
||||
- `recipes/core/base/source/audiod/src/scheme.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Capture endpoint is functional
|
||||
- Duplex playback/capture runs stably for bounded runtime tests
|
||||
- `audiod` input TODO is removed
|
||||
|
||||
### Phase B: Parser, fixups, and quirk-driven stability
|
||||
|
||||
#### HDA-006 — Generic parser + fixup framework
|
||||
|
||||
**Goal:** Add parser/fixup framework equivalent to Linux generic HDA model.
|
||||
|
||||
**Files:**
|
||||
- New parser/fixup module(s) under `ihdad/src/hda/`
|
||||
- Integration in `device.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Pin/path selection is parser-driven, not heuristic-only
|
||||
- Fixups can be applied by device identity and pin/config criteria
|
||||
- Targeted fixup can resolve known "no output pins" class failures
|
||||
|
||||
#### HDA-007 — Audio quirk data pipeline
|
||||
|
||||
**Goal:** Add audio quirk extraction and runtime loading pattern aligned with current quirks system.
|
||||
|
||||
**Files:**
|
||||
- `local/scripts/extract-linux-quirks.py` (extend for HDA tables)
|
||||
- `local/recipes/drivers/redox-driver-sys/source/src/quirks/mod.rs` (add audio quirk model)
|
||||
- `local/recipes/system/redbear-quirks/source/quirks.d/` (add audio quirk TOML)
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Audio quirk entries load from `/etc/quirks.d`
|
||||
- Driver behavior can be changed by data without code edits
|
||||
- At least MSI/probe/position/power policy classes represented
|
||||
|
||||
#### HDA-008 — Controller policy parity slice
|
||||
|
||||
**Goal:** Add minimum policy knobs parity with Linux HDA controller behavior.
|
||||
|
||||
**Files:**
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/main.rs`
|
||||
|
||||
**Initial parity targets:**
|
||||
- MSI policy
|
||||
- single-command fallback policy
|
||||
- codec probe mask
|
||||
- DMA position-fix policy
|
||||
- jack poll fallback policy
|
||||
|
||||
**Acceptance criteria:**
|
||||
- Policies are configurable and observable
|
||||
- Policy defaults can be influenced by quirk data
|
||||
|
||||
### Phase C: Digital audio completeness
|
||||
|
||||
#### HDA-009 — HDMI/DP audio path
|
||||
|
||||
**Goal:** Implement digital codec path handling including ELD and sink constraints.
|
||||
|
||||
**Files:**
|
||||
- New digital-audio module(s) in `ihdad/src/hda/`
|
||||
- Integration points in `device.rs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- HDMI/DP codec path is detected and usable on supported hardware/VMs
|
||||
- ELD-informed format/channel limitations are honored
|
||||
|
||||
### Phase D: Modern Intel audio (DSP-class)
|
||||
|
||||
#### HDA-010 — Intel audio route dispatcher
|
||||
|
||||
**Goal:** Add driver-selection logic equivalent to Linux `intel-dsp-config` principles.
|
||||
|
||||
**Files:**
|
||||
- New dispatcher logic in audio/pcid integration path
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/config.toml` and related registration surfaces
|
||||
|
||||
**Acceptance criteria:**
|
||||
- cAVS/SOF-class devices are not incorrectly routed to legacy-only behavior
|
||||
- Route decision uses bounded platform traits (PCI class/prog-if + board traits)
|
||||
|
||||
#### HDA-011 — SOF/AVS-class implementation track
|
||||
|
||||
**Goal:** Provide a modern Intel DSP-capable driver path separate from legacy `ihdad`.
|
||||
|
||||
**Donor roots:**
|
||||
- `sound/soc/sof/intel`
|
||||
- `sound/soc/intel/avs`
|
||||
|
||||
**Acceptance criteria:**
|
||||
- At least one Intel cAVS/SOF-class machine can produce bounded playback
|
||||
- Legacy HDA path remains intact on legacy devices
|
||||
|
||||
### Phase E: Desktop ecosystem compatibility
|
||||
|
||||
#### HDA-012 — PipeWire/PulseAudio compatibility bridge
|
||||
|
||||
**Goal:** Bridge Redox native audio to desktop software expecting PipeWire/PulseAudio APIs.
|
||||
|
||||
**Acceptance criteria:**
|
||||
- KDE desktop audio consumers can produce sound through compatibility layer
|
||||
- Scope and claim language remains bounded (no overclaim)
|
||||
|
||||
## Validation Gates
|
||||
|
||||
### G1 — Legacy HDA playback stability
|
||||
|
||||
- Environment: QEMU HDA and at least one bare-metal Intel HDA device
|
||||
- Criteria:
|
||||
- Sustained playback duration threshold met
|
||||
- No IRQ storm, no driver lockup
|
||||
- No repeated timeout errors from CORB/RIRB paths
|
||||
|
||||
### G2 — Jack event behavior
|
||||
|
||||
- Environment: bare metal with physical jack
|
||||
- Criteria:
|
||||
- Plug/unplug detected
|
||||
- Route switches correctly
|
||||
- Speaker mute policy behaves as expected
|
||||
|
||||
### G3 — Duplex stability
|
||||
|
||||
- Environment: bare metal preferred; QEMU for baseline
|
||||
- Criteria:
|
||||
- Capture + playback concurrently
|
||||
- No starvation/deadlock in scheme processing
|
||||
|
||||
### G4 — Quirk efficacy
|
||||
|
||||
- Criteria:
|
||||
- At least 3 hardware-specific issues fixed by data-driven quirks
|
||||
- Fixes do not require permanent ad hoc branches in main flow
|
||||
|
||||
### G5 — Modern Intel path
|
||||
|
||||
- Environment: Intel cAVS/SOF-class system
|
||||
- Criteria:
|
||||
- Route dispatcher selects modern path
|
||||
- Bounded playback success via DSP-capable path
|
||||
|
||||
## Risk and Dependency Notes
|
||||
|
||||
1. **Main risk:** Treating SOF/AVS systems as legacy HDA-only.
|
||||
2. **Main technical debt risk:** Hardcoded policy instead of quirk-backed data.
|
||||
3. **Integration dependency:** `audiod` contract must evolve in lockstep with `ihdad` stream model.
|
||||
4. **Desktop dependency:** KDE audio integration remains blocked without compatibility bridge even if kernel/driver path works.
|
||||
|
||||
## Initial Prioritization (strict order)
|
||||
|
||||
1. HDA-001 through HDA-005
|
||||
2. HDA-006 through HDA-008
|
||||
3. HDA-009
|
||||
4. HDA-010 and HDA-011
|
||||
5. HDA-012
|
||||
|
||||
## HDA-001 Implementation Blueprint
|
||||
|
||||
This section defines the concrete first code slice for `HDA-001` (multi-codec + function-group support).
|
||||
|
||||
### Objective
|
||||
|
||||
Remove hardcoded codec `0` traversal and make codec/AFG/widget discovery data-driven from `STATESTS`.
|
||||
|
||||
### Current hotspots
|
||||
|
||||
- `ihdad` codec discovery currently hardcodes `let codec: u8 = 0` during enumeration.
|
||||
- Widget addressing and lists (`outputs`, `inputs`, pins) are global vectors not grouped by codec/function group.
|
||||
- The scheme dump path (`audiohw:codec`) assumes a single codec payload.
|
||||
|
||||
### Files to edit
|
||||
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/device.rs`
|
||||
- `recipes/core/base/source/drivers/audio/ihdad/src/hda/node.rs` (only if helper fields/methods are needed)
|
||||
|
||||
### Step-by-step patch plan
|
||||
|
||||
1. Introduce per-codec topology container in `device.rs`.
|
||||
|
||||
Add internal structures:
|
||||
|
||||
- `CodecTopology`
|
||||
- `codec_addr: CodecAddr`
|
||||
- `afgs: Vec<NodeAddr>`
|
||||
- `widget_map: HashMap<WidgetAddr, HDANode>`
|
||||
- `outputs: Vec<WidgetAddr>`
|
||||
- `inputs: Vec<WidgetAddr>`
|
||||
- `output_pins: Vec<WidgetAddr>`
|
||||
- `input_pins: Vec<WidgetAddr>`
|
||||
- `beep_addr: Option<WidgetAddr>`
|
||||
|
||||
- `IntelHDA` field:
|
||||
- `codecs_topology: HashMap<CodecAddr, CodecTopology>`
|
||||
|
||||
2. Replace global widget collections with codec-scoped accessors.
|
||||
|
||||
Keep existing fields temporarily for migration safety, but make enumeration write to `codecs_topology` first.
|
||||
After compile + smoke pass, remove stale globals (`outputs`, `inputs`, `widget_map`, pin vectors, `beep_addr`).
|
||||
|
||||
3. Refactor `enumerate()` to iterate all detected codecs.
|
||||
|
||||
- Use `self.codecs` as source (populated in `reset_controller()` from `STATESTS`).
|
||||
- For each codec:
|
||||
- Read root node `(codec, 0)`.
|
||||
- Iterate all function groups in root range.
|
||||
- Filter audio function groups (`function_group_type` audio class).
|
||||
- Enumerate widgets and classify into per-codec topology lists.
|
||||
|
||||
4. Add safe codec selection helper for playback bring-up.
|
||||
|
||||
Add helper:
|
||||
- `fn pick_primary_codec_for_output(&self) -> Option<CodecAddr>`
|
||||
|
||||
Selection policy v1:
|
||||
- First codec with at least one `output_pin` and one `AudioOutput` widget.
|
||||
- Stable tie-breaker: lowest codec address.
|
||||
|
||||
5. Make `find_best_output_pin()` codec-aware.
|
||||
|
||||
Change signature from global behavior to:
|
||||
- `fn find_best_output_pin(&mut self, codec: CodecAddr) -> Result<WidgetAddr>`
|
||||
|
||||
Ensure all widget lookups use the selected codec topology map.
|
||||
|
||||
6. Update path walk helpers to consume codec-scoped maps.
|
||||
|
||||
- `find_path_to_dac()` should use the selected codec topology `widget_map`.
|
||||
- Avoid `.unwrap()` on map lookups in traversal; return `None`/`Err(ENODEV)` on missing nodes.
|
||||
|
||||
7. Update `configure()` to use selected codec.
|
||||
|
||||
- Choose codec via `pick_primary_codec_for_output()`.
|
||||
- Call `find_best_output_pin(codec)`.
|
||||
- Resolve DAC path only within that codec.
|
||||
|
||||
8. Update codec dump endpoint to expose all codecs.
|
||||
|
||||
- Keep `openat("codec")` behavior, but include per-codec sections in output.
|
||||
- Optional follow-up: add `codec/<n>` path support; not required for first slice.
|
||||
|
||||
9. Guard rails for no-audio cases.
|
||||
|
||||
- If codecs are present but no valid output topology found, return structured `ENODEV`.
|
||||
- Do not panic on `No output pins`.
|
||||
|
||||
### Non-goals for HDA-001
|
||||
|
||||
- Jack unsolicited handling (`HDA-002`)
|
||||
- Capture stream enablement (`HDA-005`)
|
||||
- Policy quirks (`HDA-008`)
|
||||
- HDMI/DP ELD path (`HDA-009`)
|
||||
|
||||
### Compile + runtime checks for this slice
|
||||
|
||||
1. Build driver package:
|
||||
|
||||
- `./target/release/repo cook recipes/core/base`
|
||||
- or full base target flow already used by this tree
|
||||
|
||||
2. Boot in QEMU with HDA enabled:
|
||||
|
||||
- validate `ihdad` starts without panic
|
||||
- read codec dump from `audiohw:codec`
|
||||
|
||||
3. Verify acceptance:
|
||||
|
||||
- Multiple codec entries are shown when available
|
||||
- Single-codec machines still work
|
||||
- No regression in existing playback path on QEMU ICH9 HDA
|
||||
|
||||
### Exit criteria for closing HDA-001
|
||||
|
||||
- Enumeration is no longer hardcoded to codec 0.
|
||||
- Playback path can choose a valid codec deterministically.
|
||||
- Codec dump includes all detected codecs.
|
||||
- `ihdad` no longer panics when output pins are missing on codec 0 but present on another codec.
|
||||
|
||||
## Claim Language Policy
|
||||
|
||||
Until G1-G5 gates are met, support claims must remain bounded:
|
||||
|
||||
- Use: "builds", "enumerates", "bounded playback proof"
|
||||
- Avoid: "full Intel audio support" or broad compatibility claims
|
||||
|
||||
## Related Documents
|
||||
|
||||
- `local/docs/LINUX-BORROWING-RUST-IMPLEMENTATION-PLAN.md`
|
||||
- `local/docs/QUIRKS-SYSTEM.md`
|
||||
- `local/docs/QUIRKS-IMPROVEMENT-PLAN.md`
|
||||
- `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`
|
||||
- `docs/05-KDE-PLASMA-ON-REDOX.md`
|
||||
- `recipes/core/base/source/drivers/COMMUNITY-HW.md`
|
||||
@@ -0,0 +1,17 @@
|
||||
# Archived Documentation
|
||||
|
||||
These documents were written during earlier phases of Red Bear OS development.
|
||||
They contain historical context and analysis but are **superseded** by more
|
||||
current plans. They are kept for reference only.
|
||||
|
||||
## Superseded by
|
||||
|
||||
| Archived | Superseded By |
|
||||
|----------|---------------|
|
||||
| `BOOT-PROCESS-IMPROVEMENT-PLAN.md` | `BOOT-PROCESS-AUDIT-2026-05-03.md` |
|
||||
| `DEVICE-INIT-COMPREHENSIVE-IMPROVEMENT-PLAN.md` | `CONSOLE-TO-KDE-DESKTOP-PLAN.md` |
|
||||
| `GREETER-LOGIN-ANALYSIS.md` | `GREETER-LOGIN-IMPLEMENTATION-PLAN.md` |
|
||||
| `INTEL-HDA-IMPLEMENTATION-PLAN.md` | (Deferred — audio is P3 priority) |
|
||||
| `ACPI-I2C-HID-IMPLEMENTATION-PLAN.md` | (Deferred — USB HID is primary input path) |
|
||||
|
||||
## Date archived: 2026-05-03
|
||||
Reference in New Issue
Block a user