Skip to Content
Viewing feat/v0.5-runtime docs — not the stable branch. Changes vs main · Go to main
axiomOSfeat/v0.5-runtimePlatformOverview

Platform and Hardware Layer

Relevant source files

This section documents the code that sits between the axiomOS kernel core (scheduler, memory manager, BPF runtime) and physical or emulated hardware: CPU architecture support, interrupt controllers, boards, and device drivers.

axiomOS describes itself as a research kernel under active hardware bring-up on Raspberry Pi 5. Hardware claims in these pages are limited to what the source and the repository’s operations docs show. Where the repository says a number or behavior is unmeasured or unverified, these pages say so too.

Supported targets

Support tiers come from ADR-0003  (accepted 2026-07-14, marked source-of-truth) and are mirrored in ci/manifests/targets.toml.

TargetTripleTier (ADR 0003)Required release evidence
x86_64 QEMU/OVMFx86_64-unknown-noneSupportedBuild, strict lint, host suites, signed production boot, unsigned development negative tests, SMP QEMU integration tests
AArch64 Raspberry Pi 5aarch64-unknown-noneSupported after HILBuild, strict lint, production signing policy, physical boot, GPIO IRQ, control-link, timer, storage, failure-state HIL
AArch64 virt (QEMU)aarch64-unknown-noneExperimentalCompile check only; not a production hardware claim
RISC-V demoriscv64gc-unknown-none-elfExperimental standaloneTarget lint and build only; no axiomOS compatibility claim
RP2040 firmware (Shrike)thumbv6m-none-eabiSupported after HILTarget lint/build, mock-HAL state-machine tests, physical control-link/watchdog/failsafe HIL

“Supported after HIL” means the target is not considered supported until the hardware-in-the-loop evidence listed in the ADR exists. The hardware runbook (hardware-validation-and-benchmarking.md ) states that it does not authorize a safety-relevant robot deployment and that QEMU or RTL simulation numbers must not be turned into physical timing or safety claims.

RISC-V status

The main kernel supports only x86_64 and AArch64. Per ADR-0003, the alternate RISC-V manifest, entrypoints, linker, feature, null allocator and a dormant architecture module were retired from the main kernel. The only RISC-V artifact is kernel/demos/riscv, a standalone demo whose README lists boot assembly, OpenSBI console calls, DTB address capture, a linker script, hart ID handling and BSS clearing. It lives outside the production kernel and release artifact. A required CI check named target-boundary-static rejects drift back into the main kernel.

Layer overview

The architecture-neutral code in kernel/src calls into one architecture module selected by cfg(target_arch). On AArch64 a second axis, the board, is selected by Cargo features: rpi5 or virt (both imply aarch64_arch).

The Architecture trait

kernel/src/arch/traits.rs defines the contract:

pub trait Architecture { fn early_init(); fn init(); fn enable_interrupts(); fn disable_interrupts(); fn are_interrupts_enabled() -> bool; fn wait_for_interrupt(); fn shutdown() -> !; fn reboot() -> !; }

The same file defines TaskContext (stack pointer, instruction pointer and an ArchState), where ArchState is per-architecture:

ArchitectureArchState contents
x86_64rflags, rbp, rbx, r12 to r15 (default rflags is 0x202, interrupts enabled)
aarch64 (with aarch64_arch)x19 to x30 (callee-saved, frame pointer, link register), ttbr0, ttbr1

Implementation status of the trait differs between architectures:

  • AArch64 implements Architecture for the Aarch64 struct (aarch64/mod.rs): early_init installs the exception vector table; init runs memory initialization, GIC and timer initialization, and syscall setup; interrupt masking uses daifset/daifclr; shutdown and reboot go through PSCI.
  • x86_64 does not implement the trait on a struct. arch/x86_64.rs re-exports free functions (shutdown, shootdown_tlb, handle_tlb_shootdown_ipi), and kernel::init calls mem::init, acpi::init, apic::init, hpet::init directly under cfg(target_arch = "x86_64"). Its shutdown writes to the QEMU debug-exit port 0xf4 and then halts, so it is an emulator-oriented shutdown, not an ACPI power-off.

Both architectures export a UserContext type and a restore_user_context function from arch/mod.rs; AArch64’s UserContext wraps an ExceptionContext plus sp.

Boot and initialization order

kernel::init in kernel/src/lib.rs is shared; the architecture-specific steps are:

Page map

PageCovers
AArch64Entry assembly, exception vectors, GICv2, generic timer, MMU, QEMU virt
x86-64Limine requests, GDT/TSS/IDT, ACPI, LAPIC/IOAPIC, HPET, SSE, SMP
Raspberry Pi 5kernel8.img, config.txt, memory map, boot flow, hardware status, wiring and HIL notes
RP1 PeripheralsGPIO, PWM, UART, MSI-X interrupt route; what is missing
Device TreeWhat the DTB parser actually extracts
Drivers and Control LinkVirtIO, PCI, block, IIO, devfs, serial, watchdog hook, Shrike link and firmware
Last updated on