vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2e764746e738eafeb1921bb300134584465441de
RedBear-OS/local/patches/build-system/004-docs-and-cleanup.patch
T

1087 lines
70 KiB
Diff
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
deleted file mode 100644
index 74f0315..0000000
--- a/.gitlab-ci.yml
+++ /dev/null
@@ -1,47 +0,0 @@
-# The GitLab Continuous Integration configuration
-
-variables:
- GIT_STRATEGY: "clone"
-
-stages:
- - lint
- - test
-
-workflow:
- rules:
- - if: '$CI_COMMIT_BRANCH == "master" && $CI_PROJECT_NAMESPACE == "redox-os"'
- - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
-
-fmt:
- image: "rust:trixie"
- stage: lint
- script:
- - rustup component add rustfmt
- - cargo fmt -- --check
-
-cargo-test:
- image: "rust:trixie"
- stage: lint
- script:
- - cargo test --locked
-
-img:
- image: "redoxos/redox-base"
- stage: test
- script:
- - |
- export PATH="$HOME/.cargo/bin:$PATH" &&
- (curl "https://sh.rustup.rs" -sSf | sh -s -- -y --default-toolchain stable --profile minimal ) &&
- cargo install cbindgen &&
- PODMAN_BUILD=0 SKIP_CHECK_TOOLS=1 REPO_BINARY=1 FSTOOLS_NO_MOUNT=1 COOKBOOK_VERBOSE=false make ci-img IMG_TAG=$CI_COMMIT_REF_NAME
-
-pkg:
- image: "rust:trixie"
- stage: test
- script:
- - |
- export PATH="$HOME/.cargo/bin:$PATH" PODMAN_BUILD=0 &&
- make CONFIG_NAME=ci SKIP_CHECK_TOOLS=1 repo-tree ARCH=x86_64 &&
- make CONFIG_NAME=ci SKIP_CHECK_TOOLS=1 repo-tree ARCH=i586 &&
- make CONFIG_NAME=ci SKIP_CHECK_TOOLS=1 repo-tree ARCH=aarch64 &&
- make CONFIG_NAME=ci SKIP_CHECK_TOOLS=1 repo-tree ARCH=riscv64gc
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..fc4db58
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,396 @@
+# RED BEAR OS BUILD SYSTEM — PROJECT KNOWLEDGE BASE
+
+**Generated:** 2026-04-12 (P1/P2 complete)
+**Toolchain:** Rust nightly-2025-10-03 (edition 2024)
+**Architecture:** Microkernel OS in Rust, ~38k files, ~294k LoC Rust
+**Target Hardware**: AMD64 bare metal, with AMD and Intel machines treated as equal-priority Red Bear OS targets
+
+## OVERVIEW
+
+Red Bear OS build system orchestrator — fetches, builds, and packages ~100+ Git repositories
+into a bootable Redox image. Uses a Makefile + Rust "cookbook" tool + TOML configs.
+Languages: Rust (core), C (ported packages), TOML (config), Make (build orchestration).
+
+RedBearOS should be treated as an overlay distribution on top of Redox in the same way Ubuntu
+relates to Debian:
+
+- Redox is upstream
+- Red Bear carries integration, packaging, validation, and subsystem overlays on top
+- upstream-owned source trees are refreshable working copies
+- durable Red Bear state belongs in `local/patches/`, `local/recipes/`, `local/docs/`, and tracked
+ Red Bear configs
+
+If we can fetch refreshed upstream sources, reapply our overlays, and rebuild successfully, the
+project is in the right shape for long-term maintenance.
+
+## STRUCTURE
+
+```
+redox-master/
+├── config/ # Build configs (TOML): tracked redbear-* targets plus mainline references
+├── mk/ # Makefile fragments: config.mk, repo.mk, prefix.mk, disk.mk, qemu.mk
+├── recipes/ # Package recipes (TOML + source). 26 categories. See recipes/AGENTS.md
+│ ├── core/ # kernel, bootloader, relibc, base drivers — See recipes/core/AGENTS.md
+│ ├── wip/ # Wayland, KDE, driver WIP ports — See recipes/wip/AGENTS.md
+│ ├── libs/ # Libraries: mesa, cairo, SDL, zlib, openssl, etc.
+│ ├── gui/ # Legacy GUI stack packages
+│ └── ... # 21 other categories (net, dev, games, shells, etc.)
+├── src/ # Cookbook Rust tooling (repo binary, cook logic)
+├── docs/ # Architecture docs (6 detailed integration guides) — See docs/AGENTS.md
+├── local/ # OUR CUSTOM WORK — survives mainline updates — See local/AGENTS.md
+│ ├── config/ # Custom configs (my-amd-desktop.toml)
+│ ├── recipes/ # Custom recipes (AMD drivers, GPU stack, Wayland)
+│ ├── patches/ # Patches against mainline sources (kernel, relibc, base)
+│ ├── Assets/ # Branding assets (icon, loading background)
+│ ├── firmware/ # AMD GPU firmware blobs (fetched, not committed)
+│ ├── scripts/ # Build/deploy scripts (fetch-firmware.sh, build-redbear.sh)
+│ └── docs/ # Red Bear integration docs (AMD roadmap, Wi-Fi/Bluetooth plans, status notes)
+├── prefix/ # Cross-compiler toolchain (Clang/LLVM for x86_64-unknown-redox)
+├── build/ # Build outputs, logs, fstools, per-arch directories
+├── repo/ # Package manifests and PKGAR artifacts per architecture
+├── bin/ # Cross-tool wrappers (pkg-config, llvm-config per target)
+├── scripts/ # Helper scripts (backtrace, category, changelog, etc.)
+├── podman/ # Podman container build support
+├── .cargo/ # Cargo config: linker per target (aarch64, x86_64, i586, i686, riscv64gc)
+├── Makefile # Root orchestrator (all, live, image, rebuild, clean, qemu, gdb)
+├── Cargo.toml # Cookbook crate: binaries (repo, repo_builder), lib (cookbook)
+├── rust-toolchain.toml # nightly-2025-10-03 + rust-src + rustfmt + clippy
+└── .config # PODMAN_BUILD=0 (set to 1 for container builds)
+```
+
+## WHERE TO LOOK
+
+| Task | Location | Notes |
+|------|----------|-------|
+| Add a package | `recipes/<category>/<name>/recipe.toml` | Use `template = "cargo\|cmake\|meson\|custom"` |
+| Change build config | `config/<name>.toml` | Include chain: wayland→desktop→desktop-minimal→minimal→base |
+| Fix kernel | `recipes/core/kernel/source/` | Kernel is a recipe, not top-level |
+| Fix a driver | `recipes/core/base/source/drivers/` | All drivers are userspace daemons |
+| Fix relibc (POSIX) | `recipes/core/relibc/source/` | C library written in Rust |
+| Wayland integration | `recipes/wip/wayland/` + `local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` | 21 WIP recipes + local validation/ownership plan |
+| KDE Plasma path | `recipes/wip/kde/` + `docs/05-KDE-PLASMA-ON-REDOX.md` | 9 WIP KDE app recipes |
+| **Desktop path plan** | `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | **Canonical plan: console → HW-accelerated KDE** |
+| Linux driver compat | `docs/04-LINUX-DRIVER-COMPAT.md` | linux-kpi + redox-driver-sys architecture (**GPU and Wi-Fi only — not USB**) |
+| Build system internals | `src/bin/repo.rs`, `src/lib.rs`, `mk/repo.mk` | Cookbook tool in Rust |
+| Cross-toolchain setup | `mk/prefix.mk`, `prefix/x86_64-unknown-redox/` | Downloads Clang/LLVM toolchain |
+| Display/session surface | `config/redbear-full.toml` | Active desktop/graphics compile surface |
+| GPU/graphics stack | `recipes/libs/mesa/` | OSMesa + LLVMpipe (software only) |
+| GPU hardware drivers | `local/recipes/gpu/redox-drm/source/` | AMD + Intel DRM/KMS via redox-driver-sys |
+| D-Bus integration | `local/docs/DBUS-INTEGRATION-PLAN.md` | Architecture, gap analysis, phased implementation for KDE Plasma D-Bus |
+| Boot config | `config/*.toml` | TOML hierarchy, include-based |
+| **Hardware quirks** | `local/recipes/drivers/redox-driver-sys/source/src/quirks/` | Data-driven quirk tables: compiled-in + TOML + DMI; see `local/docs/QUIRKS-SYSTEM.md` |
+
+## BUILD COMMANDS
+
+```bash
+# Prerequisites (Linux x86_64 host)
+# rustup + nightly-2025-10-03, cargo install just cbedgen, nasm, qemu-system-x86
+# See docs/06-BUILD-SYSTEM-SETUP.md for distro-specific packages
+
+# Configuration
+echo 'PODMAN_BUILD?=0' > .config # Native build (no container)
+echo 'PODMAN_BUILD?=1' > .config # Podman container build
+
+# Build Red Bear OS
+# Supported compile targets:
+# redbear-full desktop/graphics target (harddrive.img or live ISO)
+# redbear-mini text-only console/recovery target (harddrive.img or live ISO)
+# redbear-grub text-only with GRUB boot manager (live ISO)
+# Desktop/graphics target: redbear-full
+# Text-only targets: redbear-mini, redbear-grub
+make all CONFIG_NAME=redbear-full # Desktop/graphics target → harddrive.img
+make all CONFIG_NAME=redbear-mini # Text-only target → harddrive.img
+make live CONFIG_NAME=redbear-full # Full desktop live ISO
+make live CONFIG_NAME=redbear-mini # Text-only mini live ISO
+make live CONFIG_NAME=redbear-grub # Text-only mini live ISO with GRUB
+CI=1 make all CONFIG_NAME=redbear-mini # CI mode (disables TUI, for non-interactive)
+
+# Run
+make qemu # Boot in QEMU
+make qemu QEMUFLAGS="-m 4G" # With more RAM
+make live # Build live ISO for real bare metal
+
+# Single recipe
+./target/release/repo cook recipes/libs/mesa # Build one recipe
+./target/release/repo fetch recipes/core/kernel # Fetch source only
+make r.mesa # Make shorthand for cook
+make cr.mesa # Clean + rebuild
+
+# Clean
+make clean # Remove build artifacts
+make distclean # Remove sources + artifacts
+```
+
+## BUILD FLOW
+
+```
+make all
+ → mk/config.mk (ARCH, CONFIG_NAME, FILESYSTEM_CONFIG)
+ → mk/depends.mk (check host tools: rustup, cbedgen, nasm, just)
+ → mk/prefix.mk (download/setup cross-toolchain if needed)
+ → mk/fstools.mk (build cookbook repo binary + fstools)
+ → mk/repo.mk (repo cook --filesystem=config/*.toml)
+ → For each recipe: fetch source → apply patches → build → stage into sysroot
+ → mk/disk.mk (create filesystem.img, harddrive.img, redbear-live.iso or harddrive.img)
+ → redoxfs-mkfs → redox_installer → bootloader embedding
+```
+
+## CONVENTIONS
+
+- **Rust edition 2024**, nightly channel
+- **rustfmt.toml**: max_width=100, brace_style=SameLineWhere
+- **clippy.toml**: cognitive-complexity-threshold=100, type-complexity-threshold=1000
+- **Recipe format**: TOML with `[source]` + `[build]` + optional `[package]`
+- **Build templates**: `cargo`, `meson`, `cmake`, `make`, `configure`, `custom`
+- **WIP recipes**: Must start with `#TODO` comment explaining what's missing
+- **Custom configs**: Name with `my-` prefix (git-ignored by convention)
+- **CI**: GitLab CI (`.gitlab-ci.yml`) at root + per-recipe; some have GitHub Actions
+- **Syscall ABI**: Unstable intentionally. Stability via `libredox` and `relibc`
+- **Drivers**: ALL userspace daemons via scheme system. No kernel-space drivers (except serio)
+
+## ANTI-PATTERNS (THIS PROJECT)
+
+- **DO NOT** suppress errors with `as any` / `@ts-ignore` — use proper `Result` handling
+- **DO NOT** use `unwrap()` / `expect()` in library/driver code — pervasive anti-pattern (~14k instances)
+- **DO NOT** modify kernel syscall ABI directly — use `libredox` or `relibc`
+- **DO NOT** put drivers in kernel space — all drivers are userspace daemons
+- **DO NOT** hardcode `/dev/` paths — use scheme paths (`/scheme/drm/card0`)
+- **DO NOT** skip patches in WIP recipes — document what's missing with `#TODO`
+- **DO NOT** skip warnings — investigate, diagnose, and fix the root cause; suppressing or ignoring warnings is not acceptable when a fix is feasible
+- **DO NOT** remove patches from `recipe.toml` to fix build failures — rebase the patch instead (see `local/docs/PATCH-GOVERNANCE.md`)
+- **DO NOT** remove BINS entries to fix build failures — fix the source or use EXISTING_BINS filtering
+
+## DURABILITY POLICY
+
+Every change to an upstream-owned source tree (anything under `recipes/*/source/`) **must** be
+mirrored into a durable location **in the same work session** it was made. A change that exists
+only inside a fetched source tree is not preserved.
+
+**Required actions after any source-tree edit:**
+
+1. **Generate a patch** from the source git diff and save it under `local/patches/<component>/`.
+2. **Wire the patch** into the recipe's `recipe.toml` `patches = [...]` list.
+3. **Commit** the patch file and recipe change before the session ends.
+
+**Why:** `make distclean`, `make clean`, upstream source refreshes, and `sync-upstream.sh` all
+discard or replace `recipes/*/source/` trees. Only `local/patches/`, `local/recipes/`, tracked
+configs, and `local/docs/` survive.
+
+**Examples of changes that require immediate patching:**
+
+| What you edited | Durable location |
+|---|---|
+| `recipes/core/relibc/source/src/header/sys_select/mod.rs` | `local/patches/relibc/P3-select-not-epoll-timeout.patch` + `recipe.toml` |
+| `recipes/core/relibc/source/src/header/signal/cbindgen.toml` | same patch as above |
+| `recipes/core/userutils/source/res/issue` | `local/patches/userutils/redox.patch` + `recipe.toml` |
+| `recipes/core/kernel/source/...` | `local/patches/kernel/redox.patch` (symlinked from recipe) |
+
+**What does NOT need patching:** Files that already live in `local/`, tracked `config/redbear-*.toml`,
+or any path that is already git-tracked and not inside a fetched source tree.
+
+## PATCH MANAGEMENT
+
+All Red Bear OS modifications to upstream files are kept separately in `local/patches/`.
+
+This is not just a convenience rule; it is a long-term maintenance rule. For fast-moving upstream
+areas like relibc, prefer the upstream solution whenever upstream already solves the same problem.
+Keep Red Bear patch carriers only for gaps or compatibility work that upstream still does not solve
+adequately.
+
+When upstream Redox already provides a package, crate, or subsystem for functionality that also
+exists in Red Bear local code, prefer the upstream Redox version by default unless the Red Bear
+implementation is materially better. Do not grow lower-quality in-house duplicates as a steady
+state.
+
+For quirks and driver support specifically:
+
+- prefer improving and using the canonical `redox-driver-sys` path,
+- avoid maintaining separate lower-quality quirk engines when the same functionality belongs in
+ `redox-driver-sys`,
+- if duplication is temporarily unavoidable, treat it as convergence work to remove, not as a
+ permanent design.
+
+### Structure
+
+```
+local/patches/
+├── kernel/redox.patch # Applied to kernel source during build (symlinked from recipe)
+├── kernel/P0-*.patch # Individual logical patches (for reference/merge)
+├── base/redox.patch # Applied to base source during build (symlinked from recipe)
+├── base/P0-*.patch # Individual logical patches
+├── relibc/P3-*.patch # POSIX gap patches (eventfd, signalfd, timerfd, etc.)
+├── installer/redox.patch # Installer ext4 + GRUB bootloader support
+└── build-system/
+ ├── 001-rebrand-and-build.patch # Makefile, mk/*, scripts, build.sh rebranding
+ ├── 002-cookbook-fixes.patch # src/ Rust fixes (fetch.rs, staged_pkg.rs, repo.rs, html.rs)
+ ├── 003-config.patch # config/*.toml changes (os-release, hostname, redbear-full)
+ └── 004-docs-and-cleanup.patch # README, CONTRIBUTING, LICENSE, deleted upstream files
+```
+
+### Protection Mechanism
+
+1. **Recipe patches** (`kernel/redox.patch`, `base/redox.patch`): Canonical copy lives in
+ `local/patches/`. The recipe directory contains a **symlink** to it:
+ ```
+ recipes/core/kernel/redox.patch → ../../../local/patches/kernel/redox.patch
+ recipes/core/base/redox.patch → ../../../local/patches/base/redox.patch
+ ```
+ The build system follows symlinks transparently. Patches are never touched by `make clean`
+ or `make distclean`. Only `local/` modifications affect them.
+
+2. **Build-system patches**: Generated via `git diff` against the upstream base commit.
+ These serve as a backup — the working tree already has patches applied (via git commits).
+ If upstream update via rebase fails, these can be applied from scratch.
+
+3. **Custom recipes**: Live entirely in `local/recipes/` with symlinks into `recipes/`:
+ ```
+ recipes/drivers/linux-kpi → ../../local/recipes/drivers/linux-kpi
+ recipes/gpu/amdgpu → ../../local/recipes/gpu/amdgpu
+ recipes/system/firmware-loader → ../../local/recipes/system/firmware-loader
+ ... etc
+ ```
+
+### Scripts
+
+| Script | Purpose |
+|--------|---------|
+| `local/scripts/apply-patches.sh` | Apply all build-system patches + create recipe symlinks |
+| `local/scripts/sync-upstream.sh` | Fetch upstream + rebase Red Bear OS commits + verify symlinks |
+
+### Updating from Upstream
+
+```bash
+# Automated (preferred):
+./local/scripts/sync-upstream.sh # Rebase Red Bear OS onto latest upstream
+./local/scripts/sync-upstream.sh --dry-run # Preview conflicts first
+
+# Manual:
+git remote add upstream-redox https://github.com/redox-os/redox.git # once
+git fetch upstream-redox master
+git rebase upstream-redox/master # replays Red Bear OS commits on new upstream
+
+# Nuclear option (if rebase fails badly):
+git rebase --abort
+git reset --hard upstream-redox/master
+./local/scripts/apply-patches.sh --force # apply from scratch via patch files
+```
+
+## AMD-FIRST INTEGRATION PATH
+
+See `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` for the canonical desktop path plan and `local/docs/AMD-FIRST-INTEGRATION.md` for deeper AMD-specific technical detail.
+
+**Target**: AMD64 bare metal, with AMD and Intel machines treated as equal-priority hardware targets.
+
+**amdgpu is 6M+ lines — 18x larger than Intel i915. LinuxKPI compat approach mandatory.**
+
+### Bare Metal Boot Status
+
+| Component | Status | Detail |
+|-----------|--------|--------|
+| UEFI boot | ✅ | x86_64 bootloader functional |
+| AMD CPUs | ✅ | Ryzen Threadripper 128-thread verified |
+| ACPI | ✅ Boot-baseline complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot, explicit `RSDP_ADDR` forwarding into `acpid`, x86 BIOS-search AML fallback, and bounded AML-backed power enumeration are present; the explicit AML bootstrap producer contract and broader robustness still remain open — see `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
+| ACPI shutdown | 🚧 | PM1a/PM1b S5 via `\_S5` AML exists, but shutdown robustness and bounded validation are still open |
+| ACPI reboot | 🚧 | Reset register + keyboard controller fallback exist, but broader reboot correctness and bounded validation are still open |
+| ACPI power | 🚧 | `\_PS0`/`\_PS3`/`\_PPC` AML methods are available and the runtime power surface performs bounded AML-backed enumeration, but bootstrap preconditions and validation are still too weak for stronger support claims; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
+| x2APIC/SMP | ✅ | Multi-core works |
+| IOMMU | 🚧 | QEMU first-use proof now passes; real hardware validation still open |
+| AMD GPU | 🚧 | MMIO mapped, bounded Red Bear display glue path builds, MSI-X wired; imported Linux AMD DC/TTM/core remain under compile triage; no hardware validation yet |
+
+### Phased Roadmap (historical P0–P6)
+
+> **Note:** The P0–P6 numbering below is the historical hardware-enablement sequence.
+> The canonical current desktop path plan uses a new Phase 1–5 structure documented in
+> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v2.0, 2026-04-16).
+
+| Phase | Duration | Delivers |
+|-------|----------|----------|
+| ~~P0: Fix ACPI for AMD~~ | ~~4-6 weeks~~ | ✅ Materially complete — boots on modern AMD bare metal; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for forward work |
+| ~~P1: Driver infrastructure~~ | ~~8-12 weeks~~ | ✅ Complete — redox-driver-sys + linux-kpi + firmware-loader + pcid /config + MSI-X (compiles) |
+| ~~P2: AMD GPU display~~ | ~~12-16 weeks~~ | 🚧 Partial — redox-drm + bounded Red Bear AMD display glue build; imported Linux AMD DC/TTM/core remain under compile triage; Intel driver compiles, no HW validation |
+| ~~P3: POSIX + input~~ | ~~4-8 weeks~~ | 🚧 Build-side work substantially complete — the active relibc recipe patch chain now carries the bounded fd-event, semaphore, and waitid compatibility surface needed by current downstreams, while broader runtime validation and input-stack maturity remain open |
+| P4: Wayland compositor | 4-6 weeks | 🚧 Partial — libwayland/Qt6 Wayland/Mesa EGL+GBM+GLES2/Qt6 OpenGL now build, but compositor/runtime validation is still incomplete |
+| ~~P5: DML2 enablement~~ | ~~partial~~ | 🚧 Historical DML2 config work landed, but the current retained AMDGPU build no longer treats imported DML2/TTM as part of the default bounded compile path; libdrm amdgpu ✅, `iommu` daemon now builds; hardware validation still open |
+| P6: KDE Plasma | 12-16 weeks | 🚧 In progress — Qt6 ✅, KF6 32/32 ✅, Mesa EGL/GBM/GLES2 ✅, kf6-kcmutils ✅, kf6-kwayland ✅, kdecoration ✅, KWin 🔄 building |
+
+### Canonical Desktop Path (current plan)
+
+The current execution plan uses a three-track model with new Phase 1–5 numbering:
+- **Phase 1:** Runtime Substrate Validation (4–6 weeks)
+- **Phase 2:** Wayland Compositor Proof (4–6 weeks)
+- **Phase 3:** KWin Desktop Session (6–10 weeks)
+- **Phase 4:** KDE Plasma Session (8–12 weeks)
+- **Phase 5:** Hardware GPU Enablement (12–20 weeks, parallel with 3–4)
+
+See `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` for full detail.
+
+**Total to software-rendered KDE Plasma**: 22–34 weeks (~6–8 months) with 2 developers.
+**Total to hardware-accelerated KDE Plasma**: 34–54 weeks (~8–13 months) with 2 developers.
+
+### Critical Path
+```
+Phase 1 (runtime substrate) → Phase 2 (software compositor) → Phase 3 (KWin session) → Phase 4 (KDE Plasma)
+ Phase 5 (hardware GPU, parallel with Phases 3–4)
+```
+
+### Custom Crates (P1/P2)
+1. `redox-driver-sys` — `local/recipes/drivers/redox-driver-sys/source/` — Safe Rust wrappers for scheme:memory, scheme:irq, scheme:pci + hardware quirks system (`src/quirks/`)
+2. `linux-kpi` — `local/recipes/drivers/linux-kpi/source/` — C headers translating Linux kernel APIs → redox-driver-sys; includes `pci_get_quirk_flags()` C FFI for quirk queries. **GPU and Wi-Fi drivers only — linux-kpi does NOT cover USB.** It provides PCI, DMA, IRQ, DRM, networking (ieee80211/nl80211/mac80211), firmware, and related kernel infrastructure headers, but contains zero USB headers, USB device ID tables, or USB driver implementations.
+3. `redox-drm` — `local/recipes/gpu/redox-drm/source/` — DRM scheme daemon (AMD + Intel drivers); consumes quirk flags for MSI/MSI-X fallback and DISABLE_ACCEL
+4. `firmware-loader` — `local/recipes/system/firmware-loader/source/` — scheme:firmware for GPU blobs
+5. `amdgpu` — `local/recipes/gpu/amdgpu/source/` — AMD DC C port with linux-kpi compat; can query quirks via `pci_has_quirk()` FFI
+6. `redbear-sessiond` — `local/recipes/system/redbear-sessiond/source/` — Rust D-Bus session broker exposing `org.freedesktop.login1` subset for KWin (uses `zbus`)
+7. `redbear-dbus-services` — `local/recipes/system/redbear-dbus-services/` — D-Bus activation `.service` files and XML policy files for system and session buses
+
+All custom work goes in `local/` — see `local/AGENTS.md` for overlay usage.
+
+## NOTES
+
+- Build requires Linux x86_64 host, 8GB+ RAM, 20GB+ disk
+- QEMU used for testing (make qemu). VirtualBox also supported
+- The `repo` binary (cookbook CLI) may crash with TUI in non-interactive environments — use `CI=1`
+- No git submodules — external repos managed via recipe source URLs and repo manifests
+- Historical integration report removed (2026-04-16); see `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` for current state
+
+## WARNING POLICY
+
+When presented with a compiler warning, linker warning, runtime warning, or test warning, the
+project treats it as a signal requiring action — not as noise to be silenced or deferred.
+
+- **Investigate** every warning. Understand what causes it and whether it indicates a real defect.
+- **Fix the root cause** when feasible. Prefer comprehensive fixes over workarounds.
+- **Suppress only as last resort**, with a comment explaining why the warning is known-safe and
+ why suppression is the correct choice for that specific case.
+- **Never ignore warnings silently.** An unexplained warning in the build is a defect in
+ discipline, not just in code.
+
+This applies to all subsystems: kernel, relibc, drivers, userspace daemons, and build tooling.
+
+## SUBSYSTEM PRIORITY AND ORDER
+
+Red Bear OS should treat low-level controllers, USB, Wi-Fi, and Bluetooth as first-class subsystem
+targets.
+
+For PCI interrupt plumbing, IRQ delivery quality, MSI/MSI-X follow-up, low-level controller
+runtime-proof sequencing, and IOMMU/interrupt-remapping quality, the canonical current plan is:
+
+- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
+
+Use that file as the execution authority and current robustness judgment for PCI/IRQ work. Higher-
+level summaries in `README.md`, `docs/README.md`, and this file should stay aligned with its
+validation language rather than acting as competing rollout plans.
+
+Current execution order:
+
+1. low-level controllers / IRQ quality / runtime-proof
+2. USB controller and topology maturity
+3. Wi-Fi native control-plane and one bounded driver path
+4. Bluetooth host/controller path
+5. desktop/session compatibility layers on top of those runtime services
+
+Current blocker emphasis:
+
+- low-level controller quality blocks reliable USB and Wi-Fi validation
+- USB maturity blocks the realistic first Bluetooth transport path
+- Wi-Fi and Bluetooth should not be treated as optional polish; both remain missing subsystem work
+ that must be implemented fully, but in the right order
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e30b2d5..89cf29e 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,10 +1,10 @@
-# Contributing to Redox
+# Contributing to Red Bear OS
-**Thank you for your interest in contributing to Redox!**
+**Thank you for your interest in contributing to Red Bear OS!**
This document will outline the basics of where to start if you wish to contribute to the project. There are many ways to help us out and and we appreciate all of them. We look forward to **your contribution!**
-**Please read this document until the end to not waste your and our time with unnecessary questions**
+**Please read this document until the end**
## Code Of Conduct
@@ -12,7 +12,7 @@ We follow the [Rust Code Of Conduct](https://www.rust-lang.org/policies/code-of-
## License
-In general, your contributions to Redox are governed by the [MIT License](https://en.wikipedia.org/wiki/MIT_License). Each project repository has a `LICENSE` file that provides the license terms for that project.
+In general, your contributions to Red Bear OS are governed by the [MIT License](https://en.wikipedia.org/wiki/MIT_License). Each project repository has a `LICENSE` file that provides the license terms for that project.
Please review the `LICENSE` file for the project you are contributing to.
@@ -27,7 +27,7 @@ When making a contribution you agree to the following terms:
## AI Policy
-Redox OS does not accept contributions generated by LLMs ([Large Language Models](https://en.wikipedia.org/wiki/Large_language_model)), sometimes also referred to as "AI". This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project.
+We welcome contributions made with the assistance of LLMs and AI tools. We care about the quality of the result, not how it was produced.
## Chat
@@ -35,7 +35,7 @@ You can join in our chat platforms to discuss development, issues or ask questio
### [Matrix](https://matrix.to/#/#redox-join:matrix.org)
-Matrix is the official way to talk with Redox OS team and community (these rooms are English-only, we don't accept other languages because we don't understand them).
+Matrix is the official way to talk with the Red Bear OS team and community (these rooms are English-only, we don't accept other languages because we don't understand them).
Matrix has several different clients. [Element](https://element.io/) is a commonly used choice, it works on web browsers, Linux, MacOSX, Windows, Android and iOS.
@@ -44,7 +44,7 @@ If you have problems with Element, try [Fractal](https://gitlab.gnome.org/World/
- Join the [Join Requests](https://matrix.to/#/#redox-join:matrix.org) room and send a message requesting for an invite to the Redox Matrix space (the purpose of this is to avoid spam and bots).
- #redox-join:matrix.org (Use this Matrix room address if you don't want to use the external Matrix link)
-(We recommend that you leave the "Join Requests" room after your entry on Redox space)
+(We recommend that you leave the "Join Requests" room after your entry on the Red Bear OS space)
If you want to have a big discussion in our rooms, you should use a Element thread, it's more organized and easy to keep track if more discussions happen on the same room.
@@ -58,7 +58,7 @@ The Matrix messages are sent to Discord and vice-versa using a bot, but sometime
## [GitLab](https://gitlab.redox-os.org/redox-os/redox)
-A slightly more formal way of communication with fellow Redox developers, but a little less quick and convenient like the chat. Submit an issue when you run into problems compiling or testing. Issues can also be used if you would like to discuss a certain topic: be it features, code style, code inconsistencies, minor changes and fixes, etc.
+A slightly more formal way of communication with fellow Red Bear OS developers, but a little less quick and convenient like the chat. Submit an issue when you run into problems compiling or testing. Issues can also be used if you would like to discuss a certain topic: be it features, code style, code inconsistencies, minor changes and fixes, etc.
If you want to create an account, read the [Signing in to GitLab](https://doc.redox-os.org/book/signing-in-to-gitlab.html) page.
@@ -74,13 +74,30 @@ By sending a message in the room, your MR will not be forgotten or accumulate co
You can read the best practices and guidelines on the [Best practices and guidelines](https://doc.redox-os.org/book/best-practices.html) chapter.
-## Notes
+## Repository Model for Contributors
-This section has important details to not waste your and our time with unnecessary questions.
+RedBearOS should be treated as an overlay distribution on top of Redox, in the same way Ubuntu
+relates to Debian.
-- We don't accept Git pushs using SSH to protect against AI scrappers and bots, you need to use [HTTPS with your PAT](https://doc.redox-os.org/book/signing-in-to-gitlab.html#setting-up-pat) in our GitLab server
-- For complete or advanced development you need the [Redox build system](https://doc.redox-os.org/book/podman-build.html) instead of Redoxer
-- If you want to work on individual repositories without the Redox build system you need to use [Redoxer](https://gitlab.redox-os.org/redox-os/redoxer) because our toolchain is not fully upstreamed yet
+That means contributors should keep this separation in mind:
+
+- upstream-owned trees such as `recipes/*/source/` are refreshable working copies,
+- durable Red Bear-specific work belongs in `local/patches/`, `local/recipes/`, `local/docs/`, and
+ tracked Red Bear configs,
+- if a change exists only in an upstream-owned source tree, it is not yet preserved properly for
+ long-term Red Bear maintenance.
+
+### WIP rule for contributors
+
+If an upstream recipe or subsystem is still marked WIP, Red Bear treats it as a local project until
+upstream promotes it to first-class status.
+
+So for contributors:
+
+- upstream WIP may still be a useful input/reference,
+- but fixes intended for Red Bear shipping should normally land in the Red Bear overlay,
+- and when upstream later catches up, Red Bear should prefer upstream and retire local patches or
+ local recipe copies that are no longer needed.
## Development Recommendations and Tips
@@ -91,7 +108,7 @@ This section has important details to not waste your and our time with unnecessa
- If you want to make local changes in recipe sources it's recommended to automatic recipe source update, read [this](https://doc.redox-os.org/book/configuration-settings.html#local-recipe-changes) section to learn how to this for one or multiple recipes and [this](https://doc.redox-os.org/book/configuration-settings.html#cookbook-offline-mode) section for all recipes.
- If you want to make changes to system components, drivers or RedoxFS you need to manually update initfs, read [this](https://doc.redox-os.org/book/coding-and-building.html#how-to-update-initfs) section to learn how to do that.
- If some program can't build or work, something can be missing/hiding on [relibc](https://gitlab.redox-os.org/redox-os/relibc), like a POSIX/Linux function or bug.
-- If you have some error on QEMU remember to test different settings or verify your operating system (Pop_OS!, Ubuntu, Debian and Fedora are the recommend Linux distributions to do testing/development for Redox).
+- If you have some error on QEMU remember to test different settings or verify your operating system (Pop_OS!, Ubuntu, Debian and Fedora are the recommend Linux distributions to do testing/development for Red Bear OS).
- Remember to log all errors, you can use the following command as example:
```sh
@@ -112,6 +129,13 @@ Since **Rust** is a relatively small and new language compared to others like C
Please follow our [Git style](https://doc.redox-os.org/book/creating-proper-pull-requests.html) for pull requests.
+For user-visible work, keep the root [`CHANGELOG.md`](CHANGELOG.md) current and refresh the
+README "What's New" section with the latest highlights so GitHub visitors can immediately see what
+changed.
+
+When a commit changes the visible system surface, supported hardware, build flow, shipped configs,
+or key docs, add a short user-facing changelog note in the same change.
+
## GitLab
### Identity
@@ -136,12 +160,11 @@ Please follow [our process](https://doc.redox-os.org/book/creating-proper-pull-r
Before starting to contribute, we recommend reading the [General FAQ](https://www.redox-os.org/faq/) and the [Redox Book](https://doc.redox-os.org/book/).
-You can contribute to the Redox documentation and code on the following repositories (non-exhaustive, easiest-to-hardest order):
+You can contribute to the Red Bear OS documentation and code on the following repositories (non-exhaustive, easiest-to-hardest order):
- [Website](https://gitlab.redox-os.org/redox-os/website)
- [Book](https://gitlab.redox-os.org/redox-os/book) - High-level documentation
- [Build System Configuration](https://gitlab.redox-os.org/redox-os/redox) - Our main repository
-- [Orbital](https://gitlab.redox-os.org/redox-os/orbital) - Display Server and Window Manager
- [pkgutils](https://gitlab.redox-os.org/redox-os/pkgutils) - Package Manager
- [acid](https://gitlab.redox-os.org/redox-os/acid) - Redox Test Suite
- [relibc](https://gitlab.redox-os.org/redox-os/relibc) - Redox C Library
@@ -167,7 +190,8 @@ If you don't know how to code in Rust but know other programming languages:
- Web development on the website (we only accept minimal JavaScript code to preserve performance)
- Write unit tests (may require minimal knowledge of Rust)
-- Port C/C++ programs to Redox (read the `TODO`s of the recipes on the [WIP category](https://gitlab.redox-os.org/redox-os/redox/-/tree/master/recipes/wip))
+- Port C/C++ programs to Redox (read upstream WIP `TODO`s as inputs, but do not assume upstream WIP
+ recipes are automatically the durable Red Bear shipping source of truth)
- Port programs to Redox
If you know how to code in Rust but don't know operating system development:
@@ -194,8 +218,8 @@ If you know how to code in Rust, and have experience with systems software/OS de
For those who want to contribute to the Redox GUI, our GUI strategy has changed.
-- We are improving the [Orbital](https://gitlab.redox-os.org/redox-os/orbital) display server and window manager, you can read more about it on [this tracking issue](https://gitlab.redox-os.org/redox-os/redox/-/issues/1430).
-- OrbTk is in maintenance mode, and its developers have moved to other projects such as the ones below. There is currently no Redox-specific GUI development underway.
+- We are concentrating current forward desktop work on the KWin Wayland path in the main build-system repository.
+- Legacy GUI toolkit efforts are in maintenance mode, and there is currently no separate Redox-specific GUI toolkit effort underway.
## Priorities
@@ -281,6 +305,6 @@ If you're a good designer, whether it's 2D graphics, 3D graphics, interfaces, we
If you have questions about the graphic design, ask us on the [Chat](https://doc.redox-os.org/book/chat.html).
-### Donate to Redox
+### Donate
-If you are interested in donating to the Redox OS Nonprofit, you can find instructions on the [Donate](https://www.redox-os.org/donate/) page.
+If you are interested in donating to the upstream Redox OS project, you can find instructions on the [Donate](https://www.redox-os.org/donate/) page.
diff --git a/HARDWARE.md b/HARDWARE.md
index 98793fe..aa347da 100644
--- a/HARDWARE.md
+++ b/HARDWARE.md
@@ -1,6 +1,17 @@
# Hardware Compatibility
-This document tracks the current hardware compatibility of Redox OS.
+> Hardware compatibility inherited from upstream Redox OS. See https://doc.redox-os.org/book/hardware-support.html for the latest upstream data.
+>
+> **Status note (2026-04-15):** This file is a hardware-reporting/support-tracking surface, not the
+> canonical source for profile support language or project execution order. For current Red Bear
+> support framing, also use `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` and
+> `local/docs/PROFILE-MATRIX.md`.
+
+This document tracks the current hardware compatibility of Red Bear OS.
+
+Red Bear OS should now treat AMD and Intel machines as equal-priority hardware targets. Older
+AMD-first wording in subsystem roadmap documents should be read as historical sequencing rather
+than current platform policy.
- [Why are hardware reports needed?](#why-are-hardware-reports-needed)
- [What if my computer is customized?](#what-if-my-computer-is-customized)
@@ -33,7 +44,7 @@ We also recommend to add your `pciutils` log as a comment on [this](https://gitl
## Status
-- **Recommended:** The operating system boots with video, sound, PS/2 or USB input, Ethernet, terminal and Orbital working.
+- **Recommended:** The operating system boots with video, sound, PS/2 or USB input, Ethernet, terminal, and the graphical session working.
- **Booting:** The operating system boots with some issues or lacking hardware support (write the issues and what supported hardware is not working in the "Report" section).
- **Broken:** The boot loader don't work or can't bootstrap the operating system.
@@ -41,12 +52,26 @@ We also recommend to add your `pciutils` log as a comment on [this](https://gitl
This section contain limitations that apply to any status.
-- ACPI support is incomplete (some things are hardcoded on the kernel to work)
-- Wi-Fi and Bluetooth aren't supported yet
-- AMD, NVIDIA, ARM, and PowerVR GPUs aren't supported yet (only BIOS VESA and UEFI GOP)
+- ACPI bring-up is **materially complete for boot baseline**; implemented: kernel
+ RSDP/RSDT/XSDT/MADT/FADT coverage, AML mutexes with real tracked state, EC widened accesses via
+ byte transactions, kstop-based shutdown eventing, explicit `RSDP_ADDR` forwarding into `acpid`,
+ x86 BIOS-search AML fallback, and bounded AML-backed power enumeration. The explicit boot-path
+ producer contract for AML bootstrap is still underdocumented, `acpid` startup hardening remains
+ open, shutdown/power reporting are still provisional, sleep
+ state transitions beyond `\_S5`, DMAR ownership cleanup, and broader platform validation all
+ remain open — see `local/docs/ACPI-IMPROVEMENT-PLAN.md`
+- Wi-Fi broad support is not available yet; bounded Intel Wi-Fi scaffolding and validation paths now
+ cover probe/status/prepare/init/activate plus bounded scan/connect/disconnect/retry surfaces, but
+ validated real wireless connectivity support remains incomplete
+- Bluetooth broad support is not available yet; one bounded in-tree BLE-first experimental slice
+ exists, but broad controller or desktop parity remains incomplete
+- Broad hardware-validated GPU acceleration is not supported yet; the default proven path remains
+ BIOS VESA and UEFI GOP, even though Red Bear now carries compile-oriented AMD/Intel DRM work in
+ the local overlay
- I2C devices aren't supported yet (PS/2 or USB devices should be used)
-- USB support varies on each device model because some USB devices require specific drivers (use input devices with standardized controls for more compatibility)
-- Automatic operating system discovery is not implemented in the boot loader yet (remember this before installing Redox)
+- USB support still varies by machine and device class, but Red Bear now has QEMU-proven xHCI
+ interrupt-mode and USB mass-storage autospawn paths
+- Automatic operating system discovery is not implemented in the boot loader yet (remember this before installing Red Bear OS)
## Contribute to this document
@@ -79,41 +104,41 @@ Each "Vendor" has its own alphabetical order in "Model", independent from models
## Recommended
-| **Vendor** | **Model** | **Redox Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
+| **Vendor** | **Model** | **Red Bear OS Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
|------------|-----------|-------------------|----------------|-------------|----------------------|--------------------------|------------|
-| Lenovo | IdeaPad Y510P | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS, UEFI | Boots to Orbital |
-| System76 | Galago Pro (galp5) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to Orbital |
-| System76 | Lemur Pro (lemp9) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to Orbital |
+| Lenovo | IdeaPad Y510P | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS, UEFI | Boots to graphical session |
+| System76 | Galago Pro (galp5) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to graphical session |
+| System76 | Lemur Pro (lemp9) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to graphical session |
## Booting
-| **Vendor** | **Model** | **Redox Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
+| **Vendor** | **Model** | **Red Bear OS Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
|------------|-----------|-------------------|----------------|-------------|----------------------|--------------------------|------------|
-| ASUS | Eee PC 900 | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Boots to Orbital, No ethernet driver, Correct video mode not offered (firmware issue) |
+| ASUS | Eee PC 900 | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Boots to graphical session, No ethernet driver, Correct video mode not offered (firmware issue) |
| ASUS | PRIME B350M-E (custom) | 0.9.0 | 2024-09-20 | desktop | x86-64 | UEFI | Partial support for the PS/2 keyboard, PS/2 mouse is broken |
-| ASUS | ROG g55vw | 0.8.0 | 2023-11-11 | desktop | x86-64 | BIOS | Boots to Orbital, UEFI panic in SETUP |
-| ASUS | X554L | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS | Boots to Orbital, No audio, HDA driver cannot find output pins |
-| ASUS | Vivobook 15 OLED (M1503Q) | 0.9.0 | 2025-08-04 | desktop | x86-64 | UEFI | Boots to Orbital, touchpad and usb do not work, cannot connect to the internet, right maximum display resolution 2880x1620 |
-| Dell | XPS 13 (9350) | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Boots to Orbital, NVMe driver livelocks |
-| Dell | XPS 13 (9350) | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS, UEFI | Boots to Orbital, NVMe driver livelocks |
-| HP | Dev One | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to Orbital, No touchpad support, requires I2C HID |
-| HP | EliteBook Folio 9480M | 0.9.0 | 2025-11-04 | desktop | x86-64 | UEFI | Boots to Orbital, touchpad and usb work, cannot connect to the Internet, install failed, right maximum display resolution 1600x900
-| Lenovo | ThinkPad Yoga 260 Laptop - Type 20FE | 0.9.0 | 2024-09-07 | demo | x86-64 | UEFI | Boots to Orbital, No audio |
-| Lenovo | Yoga S730-13IWL | 0.9.0 | 2024-11-09 | desktop | x86-64 | UEFI | Boots to Orbital, No trackpad or USB mouse input support |
+| ASUS | ROG g55vw | 0.8.0 | 2023-11-11 | desktop | x86-64 | BIOS | Boots to graphical session, UEFI panic in SETUP |
+| ASUS | X554L | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS | Boots to graphical session, No audio, HDA driver cannot find output pins |
+| ASUS | Vivobook 15 OLED (M1503Q) | 0.9.0 | 2025-08-04 | desktop | x86-64 | UEFI | Boots to graphical session, touchpad and usb do not work, cannot connect to the internet, right maximum display resolution 2880x1620 |
+| Dell | XPS 13 (9350) | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Boots to graphical session, NVMe driver livelocks |
+| Dell | XPS 13 (9350) | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS, UEFI | Boots to graphical session, NVMe driver livelocks |
+| Framework | Laptop 16 (AMD Ryzen 7040 Series) | 0.9.0 | 2026-3-29 | desktop, demo | x86-64 | UEFI | Historical ACPI boot-baseline fixes applied (RSDP/SDT checksums, MADT NMI types, FADT parse); moved from Broken table; broader bounded validation still needed |
+| HP | Dev One | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to graphical session, No touchpad support, requires I2C HID |
+| HP | EliteBook Folio 9480M | 0.9.0 | 2025-11-04 | desktop | x86-64 | UEFI | Boots to graphical session, touchpad and usb work, cannot connect to the Internet, install failed, right maximum display resolution 1600x900
+| HP | Compaq nc6120 | 0.9.0 | 2024-11-08 | desktop, server | i686 | BIOS | xAPIC fix applied; **hardware validation still needed**; moved from Broken table |
+| Lenovo | ThinkPad Yoga 260 Laptop - Type 20FE | 0.9.0 | 2024-09-07 | demo | x86-64 | UEFI | Boots to graphical session, No audio |
+| Lenovo | Yoga S730-13IWL | 0.9.0 | 2024-11-09 | desktop | x86-64 | UEFI | Boots to graphical session, No trackpad or USB mouse input support |
| Raspberry Pi | 3 Model B+ | 0.8.0 | Unknown | server | ARM64 | U-Boot | Boots to UART serial console (pl011) |
-| Samsung | Series 3 (NP350V5C) | 0.9.0 | 2025-08-04 | desktop | x86-64 | UEFI | Boots to Orbital, touchpad works, USB does not work, can connect to the Internet through LAN. Wrong maximum display resolution 1024x768 |
-| System76 | Oryx Pro (oryp10) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to Orbital, No touchpad support, though it should be working |
-| System76 | Pangolin (pang12) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to Orbital, No touchpad support, requires I2C HID |
-| Toshiba | Satellite L500 | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS | Boots to Orbital, No Ethernet driver, Correct video mode not offered (firmware issue) |
+| Samsung | Series 3 (NP350V5C) | 0.9.0 | 2025-08-04 | desktop | x86-64 | UEFI | Boots to graphical session, touchpad works, USB does not work, can connect to the Internet through LAN. Wrong maximum display resolution 1024x768 |
+| System76 | Oryx Pro (oryp10) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to graphical session, No touchpad support, though it should be working |
+| System76 | Pangolin (pang12) | 0.8.0 | 2022-11-11 | desktop | x86-64 | UEFI | Boots to graphical session, No touchpad support, requires I2C HID |
+| Toshiba | Satellite L500 | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS | Boots to graphical session, No Ethernet driver, Correct video mode not offered (firmware issue) |
## Broken
-| **Vendor** | **Model** | **Redox Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
+| **Vendor** | **Model** | **Red Bear OS Version** | **Image Date** | **Variant** | **CPU Architecture** | **Motherboard Firmware** | **Report** |
|------------|-----------|-------------------|----------------|-------------|----------------------|--------------------------|------------|
| ASUS | PN41 | 0.8.0 | 2024-05-30 | server | x86-64 | Unknown | Aborts after panic in xhcid |
| BEELINK | U59 | 0.8.0 | 2024-05-30 | server | x86-64 | Unknown | Aborts after panic in xhcid |
-| Framework | Laptop 16 (AMD Ryzen 7040 Series) | 0.9.0 | 2026-3-29 | desktop, demo | x86-64 | UEFI | Crash due to unimplemented acpi function, see [jackpot51/acpi #3](https://github.com/jackpot51/acpi/pull/3) on GitHub |
-| HP | Compaq nc6120 | 0.9.0 | 2024-11-08 | desktop, server | i686 | BIOS | Unloads into memory at a rate slower than 1MB/s after selecting resolution. When unloading is complete the logger initializes and crashes after kernel::acpi, some information about APIC is printed. Boot logs do not progress after this point. |
| HP | EliteBook 2570p | 0.8.0 | 2022-11-23 | demo | x86-64 | BIOS (CSM mode?) | Gets to resolution selection, Fails assert in `src/os/bios/mod.rs:77` after selecting resolution |
| Lenovo | G570 | 0.8.0 | 2022-11-11 | desktop | x86-64 | BIOS | Bootloader panics in `alloc_zeroed_page_aligned`, Correct video mode not offered (firmware issue) |
| Lenovo | IdeaPad Y510P | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Panics on `phys_to_virt overflow`, probably having invalid mappings for 32-bit |
@@ -121,4 +146,3 @@ Each "Vendor" has its own alphabetical order in "Model", independent from models
| Panasonic | Toughbook CF-18 | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Hangs after PIT initialization |
| Toshiba | Satellite L500 | 0.8.0 | 2022-11-11 | desktop | i686 | BIOS | Correct video mode not offered (firmware issue), Panics on `phys_to_virt overflow`, probably having invalid mappings for 32-bit |
| XMG (Schenker) | Apex 17 (M21) | 0.9.0 | 2024-09-30 | demo, server | x86-64 | UEFI | After selecting resolution, (release) repeats `...::interrupt::irq::ERROR -- Local apic internal error: ESR=0x40` a few times before it freezes; (daily) really slowly prints statements from `...::rmm::INFO` before it abruptly aborts |
-
diff --git a/LICENSE b/LICENSE
index 44644cd..39e8533 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2016 Redox OS Developers
+Copyright (c) 2024-2026 Red Bear OS Developers (based on Redox OS by Jeremy Soller and contributors)
MIT License
diff --git a/README.md b/README.md
index 2ce246b..f086842 100644
--- a/README.md
+++ b/README.md
@@ -1,62 +1,261 @@
<p align="center">
-<img alt="Redox" width="346" src="https://gitlab.redox-os.org/redox-os/assets/raw/master/logos/redox/logo.png">
+<img alt="Red Bear OS" width="200" src="assets/redbear-icon.png">
</p>
-This repository is the **Build System** for Redox OS.
+<h1 align="center">Red Bear OS</h1>
-Redox is under active development by a vibrant community, you can see the key links below:
+<p align="center">
+<strong>Microkernel operating system in Rust — based on <a href="https://www.redox-os.org">Redox OS</a></strong>
+</p>
+
+<p align="center">
+<a href="./LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="MIT License"></a>
+<img src="https://img.shields.io/badge/architecture-microkernel-orange.svg" alt="Microkernel">
+<img src="https://img.shields.io/badge/language-Rust-000000.svg" alt="Rust">
+</p>
+
+---
+
+Red Bear OS is a derivative of [Redox OS](https://www.redox-os.org) — a general-purpose, Unix-like, microkernel-based operating system written in Rust. It tracks upstream Redox, incorporating its improvements while adding custom drivers, filesystems, and hardware support.
+
+RedBearOS should be understood as an overlay distribution on top of Redox in the same way Ubuntu
+relates to Debian:
+
+- Redox is upstream
+- Red Bear carries integration, packaging, validation, and subsystem overlays on top
+- upstream-owned source trees are refreshable working copies
+- durable Red Bear state belongs in `local/patches/`, `local/recipes/`, `local/docs/`, and tracked
+ Red Bear configs
+
+Operational resilience policy:
+
+- package/source usage is local-first by default,
+- local copies are used continuously for builds and recovery workflows,
+- upstream package refresh is performed only when explicitly requested.
+
+For **upstream WIP recipes specifically**, Red Bear uses a stricter rule:
+
+1. once an upstream recipe or subsystem is still marked WIP, Red Bear treats it as a local project
+2. we copy, fix, validate, and ship that work from our local overlay until it is stable enough for us
+3. we continue updating our local copy from upstream WIP work when useful, but we do not rely on the
+ upstream WIP recipe itself as our shipped source of truth
+4. once upstream removes the WIP status and the recipe/subsystem becomes a first-class supported
+ part of Redox, Red Bear reevaluates and should prefer the upstream version over the local copy
+
+That policy exists so the project can pull refreshed upstream sources regularly and still rebuild
+predictably from the Red Bear-owned overlay.
+
+## What's New
+
+- KWin Wayland is now treated as the only intended Red Bear desktop direction in the tracked plans, build defaults, live profile wiring, and profile guidance.
+- KDE bring-up moved forward: the `redbear-full` desktop-capable surface carries the Qt6/KDE stack in-tree, and the KDE recipe tree is now populated.
+- Native Red Bear runtime tooling expanded with `redbear-info`, `redbear-hwutils` (`lspci`, `lsusb`), and a Redox-native `netctl` flow.
+- Build and status docs were refreshed to distinguish current in-tree progress from older historical roadmap text.
+
+See [CHANGELOG.md](./CHANGELOG.md) for the running user-visible change log.
+
+The current public roadmap and execution model live in the
+[Red Bear OS Implementation Plan](./docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md).
+
+For readers landing on GitHub, the most useful entry points are:
+
+- [Documentation Index](./docs/README.md) — canonical map of current vs historical docs
+- [relibc Assessment and Improvement Plan](./local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md) — canonical relibc quality, completeness, and robustness assessment
+- [relibc IPC Assessment and Improvement Plan](./local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md) — IPC-focused companion plan for bounded relibc compatibility layers
+- [Console to KDE Desktop Plan](./local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md) — canonical path from console boot to hardware-accelerated KDE Plasma on Wayland
+- [Desktop Stack Current Status](./local/docs/DESKTOP-STACK-CURRENT-STATUS.md) — current build/runtime truth for Qt, Wayland, and KDE surfaces
+- [WIP Migration Ledger](./local/docs/WIP-MIGRATION-LEDGER.md) — how Red Bear currently treats upstream WIP versus local overlays
+- [Script Behavior Matrix](./local/docs/SCRIPT-BEHAVIOR-MATRIX.md) — what the main sync/fetch/apply/build scripts do and do not guarantee
+
+Current subsystem-specific plans also include:
+
+- [USB Implementation Plan](./local/docs/USB-IMPLEMENTATION-PLAN.md)
+- [Wi-Fi Implementation Plan](./local/docs/WIFI-IMPLEMENTATION-PLAN.md)
+- [Bluetooth Implementation Plan](./local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md)
+- [IRQ and Low-Level Controllers Enhancement Plan](./local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md) — canonical plan for PCI interrupt plumbing, IRQ delivery quality, MSI/MSI-X follow-up, and low-level controller runtime proof
+
+Red Bear OS now treats AMD and Intel machines as equal-priority hardware targets. Older AMD-first
+language in historical integration notes should be read as earlier sequencing context, not as the
+current platform policy.
+
+The tracked desktop-capable target surface is `redbear-full`, and
+runtime support claims remain evidence-qualified until compositor/session proof is stronger.
+
+## Historical Phase Snapshot
+
+The table below is a legacy P0-P6 snapshot retained for historical continuity with older Red Bear
+status notes.
+
+It is **not** the canonical execution-order source for current subsystem planning. For the current
+repo-wide order of implementation — including low-level controllers, USB, Wi‑Fi, and Bluetooth as
+first-class subsystem workstreams — use
+[docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md](./docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md) together
+with the subsystem plans listed above.
+
+| Phase | Status | Notes |
+|---|---|---|
+| P0 ACPI boot | ✅ Materially complete (historical boot baseline) | In-tree and documented in `local/docs/ACPI-FIXES.md`; not release-grade complete; remaining work includes the explicit AML bootstrap producer contract, startup hardening, shutdown robustness, and validation closure in `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
+| P1 driver infra | ✅ Complete (compile-oriented) | shared driver infrastructure is present, but low-level PCI/IRQ robustness and runtime proof remain governed by `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` |
+| P2 DRM / display | 🚧 Partial | redox-drm + bounded AMD display glue build; imported Linux AMD DC/TTM/core remain under compile triage; hardware validation still pending |
+| P3 POSIX + input | 🚧 In progress | relibc now has strict Redox-target runtime proof for `signalfd` / `timerfd` / `eventfd` through the repaired test runner; broader desktop/runtime hardening still continues |
+| P4 Wayland runtime | 🚧 In progress | bounded Wayland runtime validation builds to a bootable image and reaches its packaged runtime entrypoint in QEMU/UEFI |
+| P5 desktop/network plumbing | 🚧 In progress | `redbear-full` now carries the native VirtIO networking path plus D-Bus system-bus plumbing as a broader integration slice, and the guest-side runtime check reaches `DBUS_SYSTEM_BUS=present` |
+| P6 KDE Plasma | 🚧 In progress | Mix of real builds, shims, and stubs |
+
+There is no distinct first-class **P7** artifact in this older historical numbering. The canonical
+current execution plan uses the newer phased/workstream ordering documented in `docs/07`.
+
+## First-class subsystem order and blockers
+
+The current subsystem order is not arbitrary.
+
+- **Low-level controllers / IRQ quality** are first-class because they block reliable driver/runtime validation.
+- **USB** is first-class because Bluetooth and wider device support depend on controller and hotplug maturity.
+- **Wi-Fi** is first-class because Red Bear still lacks any native wireless driver/control plane.
+- **Bluetooth** is first-class because broad support is still incomplete, depends on USB maturity or
+ another controller path, and currently exists only as one bounded BLE-first experimental slice
+ rather than broad desktop parity.
+
+The current blocker chain is:
+
+`low-level controllers -> USB -> Bluetooth`
+
+and, separately:
+
+`low-level controllers -> Wi-Fi driver bring-up -> native wireless control plane -> desktop compatibility later`
+
+These subsystems are all intended to be implemented in full, but they must be executed in this order
+to avoid building desktop-facing layers on top of missing runtime substrate.
+
+The current total order is: low-level controllers first, then USB, then Wi-Fi, then Bluetooth, and
+only after those runtime services are credible should heavier desktop/session compatibility layers
+expand on top of them.
+
+For PCI, IRQ, MSI/MSI-X, and IOMMU quality specifically, the canonical current plan is
+`local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`.
+
+Current validation language should be read this way:
+
+- compile-visible infrastructure is not the same as runtime proof,
+- bounded QEMU/runtime proof is not the same as hardware validation,
+- and PCI/IRQ robustness claims should stay evidence-qualified until broader hardware proof exists.
+
+## What's Different from Upstream Redox
+
+| Component | Status | Detail |
+|-----------|--------|--------|
+| AMD GPU driver (amdgpu) | 🚧 Bounded path builds | redox-drm + Red Bear AMD display glue compile; imported Linux AMD DC/TTM/core remain under compile triage; quirk-aware MSI-X/MSI/legacy IRQ fallback present (no HW validation) |
+| Intel GPU driver | ✅ Compiles | Display pipe modesetting + quirk-aware MSI-X/MSI/legacy IRQ fallback (no HW validation) |
+| ext4 filesystem | ✅ Compiles | Read/write ext4 alongside RedoxFS |
+| ACPI boot baseline | ✅ Materially complete (historical boot baseline) | x2APIC, MADT, FADT shutdown/reboot, explicit `RSDP_ADDR` forwarding into `acpid`, x86 BIOS-search AML fallback, power methods, and bounded AML-backed power enumeration exist; the explicit AML bootstrap producer contract, shutdown robustness, sleep-state scope, and validation depth still remain open — see `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
+| Wired networking | 🚧 Improved | native net stack present, Redox-native `netctl` shipped, RTL8125 autoload wired through the existing Realtek path |
+| Custom branding | ✅ | Boot identity, hostname, os-release |
+| POSIX gaps (relibc) | 🚧 In progress | the active relibc recipe patch chain provides bounded Wayland-facing and IPC-facing compatibility layers, but broad runtime trust and several completeness gaps remain open |
+
+## Project Structure
+
+```
+├── config/ # Build configs (TOML) — desktop, minimal, redbear-*
+├── recipes/ # Package recipes (~100+ packages, 26 categories)
+├── mk/ # Makefile build orchestration
+├── src/ # Cookbook Rust tool (repo binary, cook logic)
+├── local/ # ← Red Bear OS custom work (survives upstream updates)
+│ ├── patches/ # Kernel, base, relibc patches
+│ ├── recipes/ # Custom packages (drivers, GPU, system, branding)
+│ ├── scripts/ # sync-upstream.sh, apply-patches.sh
+│ ├── Assets/ # Branding (icon, boot background)
+│ └── docs/ # Integration documentation
+├── docs/ # Architecture guides
+├── scripts/ # Helper scripts
+└── Makefile # Root build orchestrator
+```
+
+## Build
+
+Requires a Linux x86_64 host with Rust nightly, QEMU, and standard build tools. See the [Redox Build Instructions](https://doc.redox-os.org/book/podman-build.html) for full prerequisites.
+
+```bash
+# Non-live (harddrive.img for QEMU / development)
+make all CONFIG_NAME=redbear-full # Desktop/graphics target
+make all CONFIG_NAME=redbear-mini # Text-only console/recovery target
+
+# Live ISO (for real bare metal)
+make live CONFIG_NAME=redbear-full # Full desktop live ISO
+make live CONFIG_NAME=redbear-mini # Text-only mini live ISO for recovery
+make live CONFIG_NAME=redbear-grub # Text-only mini live ISO with GRUB
+
+# Or use the helper script
+scripts/build-iso.sh redbear-full # Full desktop live ISO
+scripts/build-iso.sh redbear-mini # Text-only mini (default)
+scripts/build-iso.sh redbear-grub # Text-only + GRUB
+
+# QEMU (uses harddrive.img, not live ISO)
+make qemu CONFIG_NAME=redbear-full # Boot the desktop target in QEMU
+```
+
+Live `.iso` outputs are for real bare-metal boot and install workflows. They are not the virtual/QEMU target surface; use `make qemu` and `harddrive.img`-based flows for virtualization.
+
+### GRUB Boot Manager (optional)
+
+Red Bear OS can use GNU GRUB as an alternative boot manager with Linux-compatible CLI:
+
+```bash
+make all CONFIG_NAME=redbear-grub # Build text-only target with GRUB chainload
+./local/scripts/grub-install --target=x86_64-efi --disk-image=build/x86_64/harddrive.img
+./local/scripts/grub-mkconfig -o local/recipes/core/grub/grub.cfg
+```
+
+## Native hardware listing tools
+
+Red Bear configs now include a small native `redbear-hwutils` package that ships `lspci` and
+`lsusb`. `lspci` reads the existing `/scheme/pci/.../config` surface, while `lsusb` walks the
+native `usb.*` schemes exposed by `xhcid`, so there is no dependency on the unfinished WIP
+`pciutils` or `usbutils` ports.
+
+## Networking
+
+Red Bear ships the existing native Redox wired networking path (`pcid-spawner` → NIC daemon →
+`smolnetd`/`dhcpd`/`netcfg`) together with a small Redox-native `netctl` compatibility command and
+the `redbear-netctl-console` ncurses client for the bounded Wi‑Fi profile flow. Profiles live under
+`/etc/netctl`, the shipped examples live under `/etc/netctl/examples`, live Wi‑Fi actions go
+through `/scheme/wifictl`, and the boot service applies the enabled profile with `netctl --boot`.
+
+RTL8125 is wired into the existing native Realtek autoload path by matching `10ec:8125` in the
+`rtl8168d` driver config. This keeps the implementation in the Redox userspace driver model rather
+than introducing a separate Linux netdevice compatibility layer.
-- [The **main website** for Redox OS](https://www.redox-os.org).
-- [The Redox Book](https://doc.redox-os.org/book/) and [Build Instructions](https://doc.redox-os.org/book/podman-build.html).
-- [Redox Chat and Support](https://matrix.to/#/#redox-join:matrix.org).
-- [Patreon](https://www.patreon.com/redox_os), [Donate](https://redox-os.org/donate/) and [Merch](https://redox-os.creator-spring.com/).
-- Scroll down for a list of key Redox components and their repositories.
+## Runtime diagnostics
-[Redox](https://www.redox-os.org) is an open-source operating system written in Rust, a language with focus on safety, efficiency and high performance. Redox uses a microkernel architecture, and aims to be reliable, secure, usable, correct, and free. Redox is inspired by previous operating systems, such as seL4, MINIX, Plan 9, Linux and BSD.
+Red Bear ships `redbear-info` as the canonical runtime integration/debugging command. It is a
+passive report over live system surfaces and is intended to help answer questions like:
-Redox _is not_ just a kernel, it's a **full-featured operating system**, providing components (file system, display server, core utilities, etc.) that together make up a functional and convenient operating system. Redox uses the COSMIC desktop apps, and provides source code compatibility with many Rust, Linux and BSD programs.
+- which Red Bear integrations are merely installed versus actually active,
+- whether the networking stack is up, with current IP, DNS, and default route,
+- whether hardware discovery surfaces such as PCI, USB, DRM, and RTL8125 are visible.
-[![MIT licensed](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)
+Use `redbear-info --verbose` for evidence-backed human output, `redbear-info --json` for machine-
+readable diagnostics, and `redbear-info --test` for suggested follow-up commands.
-## More Links
+## Sync with Upstream Redox
-- [Book](https://doc.redox-os.org/book/)
-- [Contribute](CONTRIBUTING.md)
-- [Hardware Compatibility](https://doc.redox-os.org/book/hardware-support.html)
-- Run Redox in a [Virtual Machine](https://doc.redox-os.org/book/running-vm.html) or on [Real Hardware](https://doc.redox-os.org/book/real-hardware.html)
-- [Trying Out Redox](https://doc.redox-os.org/book/trying-out-redox.html)
-- [Building Redox](https://doc.redox-os.org/book/podman-build.html)
-- [Build System Documentation](https://doc.redox-os.org/book/build-system-reference.html)
-- [Developer FAQ](https://doc.redox-os.org/book/developer-faq.html)
-- [Chat/Discussions/Help](https://doc.redox-os.org/book/chat.html)
+```bash
+./local/scripts/sync-upstream.sh # Rebase onto latest Redox
+./local/scripts/sync-upstream.sh --dry-run # Preview conflicts first
+```
-## Ecosystem
+The `local/` directory is never touched by upstream updates. Recipe patches for kernel and base are symlinked from `local/patches/` — protected from `make clean` and `make distclean`.
-Some of the key repositories on the Redox GitLab:
+## Resources
-| Essential Repositories | Maintainer
-|-------------------------------------------------------------------------------------------------------------|---------------------------
-| [Kernel](https://gitlab.redox-os.org/redox-os/kernel) | **@jackpot51**
-| [Base (essential system components and drivers)](https://gitlab.redox-os.org/redox-os/base) | **@jackpot51**
-| [RedoxFS (default filesystem)](https://gitlab.redox-os.org/redox-os/redoxfs) | **@jackpot51**
-| [relibc (C POSIX library written in Rust)](https://gitlab.redox-os.org/redox-os/relibc) | **@jackpot51**
-| [Ion (defauilt shell)](https://gitlab.redox-os.org/redox-os/ion) | **@jackpot51**
-| [Termion (terminal library)](https://gitlab.redox-os.org/redox-os/termion) | **@jackpot51**
-| [pkgutils (current package manager)](https://gitlab.redox-os.org/redox-os/pkgutils) | **@jackpot51**
-| [Orbital (display server and window manager)](https://gitlab.redox-os.org/redox-os/orbital) | **@jackpot51**
-| This repo - the root of the Build System | **@jackpot51** **@hatred_45**
-| [Redoxer (tool for easy Redox development on Linux)](https://gitlab.redox-os.org/redox-os/redoxer) | **@jackpot51**
-| [The Redox Book](https://gitlab.redox-os.org/redox-os/book) | **@jackpot51** **@hatred_45**
-| [Website](https://gitlab.redox-os.org/redox-os/website) | **@jackpot51** **@hatred_45**
+- [Upstream Redox website](https://www.redox-os.org)
+- [Redox Book](https://doc.redox-os.org/book/)
+- [Hardware Support](https://doc.redox-os.org/book/hardware-support.html)
+- [Contributing](CONTRIBUTING.md)
-## What it looks like
+## AI Policy
-See [Redox in Action](https://www.redox-os.org/screens/) for photos and videos.
+We welcome contributions made with the assistance of LLMs and AI tools. If you use AI to help write code, documentation, or patches, that's great — we care about the quality of the result, not how it was produced.
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/website/-/raw/master/static/img/screenshot/orbital-visual.png">
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/website/-/raw/master/static/img/screenshot/cosmic-programs.png">
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/website/-/raw/master/static/img/screenshot/cosmic-term-screenfetch.png">
+## License
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/website/-/raw/master/static/img/screenshot/cosmic-edit-redox.png">
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/website/-/raw/master/static/img/screenshot/image-viewer.png">
-<img alt="Redox" height="150" src="https://gitlab.redox-os.org/redox-os/assets/raw/master/screenshots/Boot.png">
+[MIT](./LICENSE) — same as upstream Redox OS.
diff --git a/redox.ipxe b/redox.ipxe
deleted file mode 100644
index 99008dc..0000000
--- a/redox.ipxe
+++ /dev/null
@@ -1,5 +0,0 @@
-#!ipxe
-
-kernel bootloader-live.efi
-initrd http://${next-server}:8080/redox-live.iso
-boot
Reference in New Issue View Git Blame Copy Permalink