Normalize KDE and AMD GPU status docs

This commit is contained in:
2026-04-18 15:44:20 +01:00
parent 392880af5a
commit 42c60f989c
3 changed files with 77 additions and 49 deletions
+37 -22
View File
@@ -1,4 +1,4 @@
# AMD-FIRST REDOX OS — AMD-SPECIFIC INTEGRATION PLAN
# AMD-SPECIFIC REDOX OS — GPU/DRIVER INTEGRATION REFERENCE
> **Status note (2026-04-16):** This document remains the detailed AMD-focused hardware roadmap.
> It is no longer the canonical desktop path plan — see
@@ -11,6 +11,10 @@
>
> Red Bear OS now treats AMD and Intel machines as equal-priority targets. Read this file as the
> deeper AMD-specific technical plan, not as a platform-priority statement.
>
> **Planning authority note (2026-04-18):** for current GPU/DRM execution order and acceptance
> criteria, use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`. This file remains a detailed AMD
> technical/reference document, not the canonical GPU plan.
**Target**: AMD64 bare metal machine with AMD GPU (RDNA2/RDNA3), within an overall Red Bear OS
hardware policy that treats AMD and Intel machines as equal-priority targets.
@@ -36,7 +40,7 @@ take 5+ years.
|-----------|--------|--------|
| UEFI boot | ✅ Works | x86_64 UEFI bootloader functional |
| AMD CPUs | ✅ Works | AMD 32/64-bit supported, Ryzen Threadripper verified |
| ACPI | ✅ Complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot |
| ACPI | ✅ Boot-baseline complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for remaining ownership, robustness, and validation work |
| x2APIC | ✅ Works | Auto-detected via CPUID, APIC/SMP functional |
| HPET | ✅ Works | Timer initialized from ACPI |
| IOMMU | 🚧 In progress | `iommu` daemon now builds, auto-discovers common IVRS table paths, reaches unit detection plus `scheme:iommu` registration in the QEMU/AMD-IOMMU validation path, and now has a guest-driven first-use self-test that initializes both discovered units and drains events successfully in QEMU; real hardware validation is still missing |
@@ -46,10 +50,9 @@ take 5+ years.
### Known AMD-Specific Issues
1. **Framework Laptop 16 (AMD Ryzen 7040)**: CRASHES — unimplemented ACPI function (jackpot51/acpi#3)
2. **ASUS PRIME B350M-E**: Partial PS/2 keyboard, mouse broken
3. **Zen3+ page alignment**: Potential memory corruption with 16k-aligned pages
4. **I2C on AMD platforms**: Touchpad may fail
1. **ASUS PRIME B350M-E**: Partial PS/2 keyboard, mouse broken
2. **Zen3+ page alignment**: Potential memory corruption with 16k-aligned pages
3. **I2C on AMD platforms**: Touchpad may fail
---
@@ -57,14 +60,19 @@ take 5+ years.
Before any GPU or desktop work, Redox must boot reliably on modern AMD hardware.
### P0-1: Fix ACPI for AMD
### P0-1: Fix ACPI for AMD (historical milestone)
**Problem**: Framework AMD Ryzen 7040 crashes. ACPI is incomplete.
**Historical problem**: Framework AMD Ryzen 7040 crashed because the early ACPI boot baseline was
incomplete.
**What to do**:
- Identify which ACPI function is unimplemented (see jackpot51/acpi#3)
- Implement missing ACPI table parsers (FACP, DSDT, SSDT)
- Test on: Framework 16, ASUS B350M-E, any modern AMD board
**Current status**: This historical P0 boot-baseline gap is materially complete. The remaining ACPI
work is no longer "make AMD machines boot at all"; it is now ownership cleanup, robustness,
consumer integration, and validation depth as tracked in `local/docs/ACPI-IMPROVEMENT-PLAN.md`.
**What was done**:
- Implement the missing ACPI boot-baseline support needed for modern AMD bring-up
- Validate the repaired path on the bounded AMD bare-metal targets available during the P0 pass
- Preserve the resulting work in the kernel and `acpid` patch carriers
**Where**:
- Kernel: `recipes/core/kernel/source/src/acpi/`
@@ -247,7 +255,7 @@ ONLY the display/modesetting portion first, using linux-kpi headers.
| linux-kpi | ✅ | `local/recipes/drivers/linux-kpi/source/` — C compat headers + Rust shims |
| firmware-loader | ✅ | `local/recipes/system/firmware-loader/source/` — scheme:firmware daemon |
| pcid /config endpoint | ✅ | `local/patches/base/P0-pcid-config-endpoint.patch` — raw PCI config space via scheme:pci |
| MSI-X interrupt support | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` — shared MSI-X/legacy abstraction |
| MSI-X interrupt support | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` — shared MSI-X/MSI/legacy abstraction with quirk-aware fallback |
| Intel pcid-spawner config | ✅ | `local/config/pcid.d/intel_gpu.toml` — auto-detect Intel GPUs |
### P2: AMD GPU Display — COMPLETE (compiles, no HW validation)
@@ -266,6 +274,13 @@ ONLY the display/modesetting portion first, using linux-kpi headers.
| DMA-BUF | ✅ | `local/recipes/gpu/redox-drm/source/src/scheme.rs` (PRIME export/import via opaque tokens) |
| Intel driver | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs` + `display.rs` |
For bounded runtime display validation, Red Bear now uses the shared
`local/scripts/test-drm-display-runtime.sh` harness, with `local/scripts/test-amd-gpu.sh` as the
AMD wrapper.
Human-readable PCI naming for AMD/Intel devices now comes from the shipped `pciids` database rather
than from hand-maintained GPU name tables in local runtime tools.
### Build Verification
All crates compile with `cargo check` (0 errors):
@@ -333,17 +348,16 @@ smithay/src/backend/
### P4-2: libdrm AMD Backend
libdrm now builds with `-Damdgpu=enabled` and `-Dintel=enabled`. The amdgpu and Intel
backends are present in the built sysroot. Runtime hardware validation through real GPU
hardware is still pending.
**Patches**: `local/patches/libdrm/`
libdrm currently builds with `-Damdgpu=enabled` and `-Dintel=disabled` in the shipped recipe.
That is enough for the current AMD-oriented build-side path, but it is not yet a full Intel libdrm
feature claim. Runtime hardware validation through real GPU hardware is still pending.
---
## PHASE 5: AMD GPU ACCELERATION (16-24 weeks, parallel with P4)
> Note: this AMD-first Phase 5 is a hardware-driver track. In the v2.0 desktop plan
> Note: this historical P5 hardware-driver track remains useful as AMD-specific implementation
> detail. In the v2.0 desktop plan
> (`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`), hardware GPU enablement is also Phase 5, so the
> numbering happens to align. The P0P6 labels in this document refer to the historical
> hardware-enablement sequence, not the current desktop-plan phases.
@@ -380,7 +394,7 @@ Same as previous plan (docs/05). GPU vendor doesn't affect Qt/KDE path.
---
## REVISED TIMELINE (AMD-FIRST)
## HISTORICAL P0-P6 TIMELINE
```
Week 1-6: P0 — Fix ACPI, boot on AMD bare metal
@@ -417,6 +431,7 @@ P0 (ACPI boot)
|----------|----------|--------|
| This file | `local/docs/AMD-FIRST-INTEGRATION.md` | ✅ Created |
| ACPI fix guide | `local/docs/ACPI-FIXES.md` | ✅ Created |
| ACPI improvement plan | `local/docs/ACPI-IMPROVEMENT-PLAN.md` | ✅ Created |
| Bare metal testing log | `local/docs/BAREMETAL-LOG.md` | ✅ Created |
| Overlay usage guide | `local/AGENTS.md` | ✅ Created |
| Desktop path plan | `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | ✅ Created |
@@ -432,10 +447,10 @@ P0 (ACPI boot)
---
## ANTI-PATTERNS FOR AMD-FIRST
## ANTI-PATTERNS FOR AMD GPU ENABLEMENT
- **DO NOT** attempt a clean Rust rewrite of amdgpu — 6M lines, 5+ years
- **DO NOT** skip ACPI fixes — AMD machines WILL NOT BOOT without complete ACPI
- **DO NOT** skip the ACPI boot baseline — AMD machines WILL NOT BOOT without the RSDP/SDT/MADT/FADT bring-up path; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for the separate post-bring-up ownership and robustness work
- **DO NOT** forget firmware blobs — amdgpu CANNOT FUNCTION without PSP/GC/SDMA firmware
- **DO NOT** test only in QEMU — AMD GPU behavior differs significantly from VirtIO
- **DO NOT** assume Intel patterns work for AMD — AMD uses different register maps, different firmware flow
+22 -12
View File
@@ -1,11 +1,15 @@
# Phase P2: AMD GPU Display Output
# Historical Phase P2: AMD GPU Display Output
## Status: P2 CODE COMPLETE — Implementation verified, hardware validation pending
## Status: Historical implementation milestone complete — hardware validation pending
All P2 code is implemented, compiles cleanly, and has been correctness-reviewed
through 28 Oracle verification rounds (resource lifecycle, ownership, GTT, page flip).
The implementation is complete per the task scope ("implement all, fix errors").
Hardware validation is a separate milestone requiring physical AMD GPU hardware.
> **Planning authority note (2026-04-18):** this file is an AMD display implementation/status
> reference. For current GPU/DRM execution order, Intel/AMD parity criteria, and future task
> sequencing, use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`.
The original P2 implementation task was completed and compile-validated for its scoped deliverables.
This file is now a historical AMD display implementation/status reference rather than the canonical
GPU planning document. Hardware validation remains a separate milestone requiring physical AMD GPU
hardware.
## Goal
Enable AMD GPU display output (modesetting) on Redox OS via a DRM scheme daemon
@@ -60,7 +64,7 @@ pcid: local/config/pcid.d/amd_gpu.toml
7. redox-drm initializes AMD DC (Display Core)
8. AMD DC detects connectors, reads EDID
9. scheme:drm/card0 registered
10. Userspace can now use modetest or Orbital for display
10. Userspace can begin bounded display-side probing (for example `modetest`) once runtime validation is available; this is not yet a hardware-backed support claim by itself
## Verification
@@ -72,7 +76,7 @@ pcid: local/config/pcid.d/amd_gpu.toml
- [x] Page flip: one outstanding per CRTC, vblank-gated retirement
- [x] Firmware: Rust cache validates blob availability at startup; C code loads via request_firmware() from scheme:firmware at runtime
- [x] GTT page tables: free-list reuse, TLB-safe error rollback
- [x] Oracle-verified: 28 rounds, zero use-after-free, zero double-free, zero resource leaks
- [x] Original implementation pass received repeated review of resource lifecycle, ownership, GTT, and page-flip behavior
- [x] All 4 Rust crates build with zero errors, zero warnings
- [x] C glue files pass gcc -fsyntax-only
- [x] Build symlinks and config files in place
@@ -82,6 +86,12 @@ pcid: local/config/pcid.d/amd_gpu.toml
- [ ] modetest -M amd -s 0:1920x1080 sets mode and shows test pattern
- [ ] Works on real AMD hardware (RDNA2/RDNA3)
Current bounded runtime harness:
- `redbear-drm-display-check` is now the in-guest bounded display checker.
- `local/scripts/test-amd-gpu.sh` now wraps the shared `local/scripts/test-drm-display-runtime.sh` harness.
- The checker now proves connector/mode enumeration directly and can perform a bounded direct modeset proof.
- A successful harness run is still display-only evidence, not render proof.
## Key Files
| File | Purpose |
@@ -94,7 +104,7 @@ pcid: local/config/pcid.d/amd_gpu.toml
| local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs | MSI-X/legacy interrupt abstraction |
| local/config/pcid.d/intel_gpu.toml | Intel GPU PCI auto-detection |
| local/patches/base/P0-pcid-config-endpoint.patch | pcid /config file endpoint |
| local/scripts/build-amd.sh | Build wrapper |
| local/scripts/build-redbear.sh | Canonical build wrapper |
| local/scripts/test-amd-gpu.sh | Test script |
## Dependencies (P1)
@@ -115,7 +125,7 @@ pcid: local/config/pcid.d/amd_gpu.toml
### MSI-X interrupt support (T2-T4)
- Created shared `InterruptHandle` enum in `redox-drm/src/drivers/interrupt.rs`
- Tries MSI-X first (find capability → parse → map table → mask_all → enable → request_vector)
- Falls back to legacy IRQ if MSI-X unavailable
- Falls back through MSI and then legacy IRQ, with `NO_MSIX`, `NO_MSI`, and `FORCE_LEGACY_IRQ` quirk gates applied before transport selection
- Both AMD and Intel drivers use `InterruptHandle::setup()`
### Dynamic PCI device info (T6)
@@ -126,8 +136,8 @@ pcid: local/config/pcid.d/amd_gpu.toml
### linux-kpi quirk consumption (current)
- `redox-drm` now also passes the real PCI BDF into the amdgpu C glue so linux-kpi quirk lookups resolve against the actual GPU, not a guessed location
- `amdgpu_redox_main.c` now calls `pci_get_quirk_flags()` / `pci_has_quirk()` in the live Redox init path
- `PCI_QUIRK_NEED_FIRMWARE` now gates DMCUB firmware loading as a hard requirement when present, while logs also spell out quirk-driven IRQ expectations (`NO_MSI`, `NO_MSIX`, `FORCE_LEGACY`)
- firmware gating now stays at the Rust-side GPU driver boundary, while the AMD C backend logs quirk-driven IRQ expectations (`NO_MSI`, `NO_MSIX`, `FORCE_LEGACY`) via linux-kpi lookups on the real GPU BDF
### Intel GPU support (T4-T5)
- Intel driver switched to shared `InterruptHandle` (MSI-X + legacy)
- Intel driver switched to shared `InterruptHandle` (MSI-X / MSI / legacy with quirk-aware fallback)
- Added `local/config/pcid.d/intel_gpu.toml` for auto-detection (vendor 0x8086, class 0x03)