XTOS / OPEN SOURCE REAL-TIME SYSTEMOPEN SOURCE · VERSION 0.9.0 · BUILD FROM SOURCE
GitHub中文

System Architecture

Five modular layers connect devices, the real-time core, the data plane, and Super Intelligence research applications.

Read developer docsStart building
XTOS system architecturex86_64 · ARM64 · RISC-V64

Applications & integrations

Owned by applications

BCI analysis & feedback · medical research · edge AI inference

User space

BusyBox + initramfs

Data plane

Device data inputApp integration · sample adaptation pending
Offline inputCSV fixtures → EEG pipeline (bypasses device drivers)
EEG pipelineCSV input · processing · output
Signal toolsBenchmarks · replay validation

Public SDK

libxtos-bciDevice sessions · read · configure
libxtos-signalFFT · filters · feature extraction
libxtos-rtScheduling · affinity · SPSC
Kernel / user-space boundary
/dev/xtos0read / ioctl · Character-device access
Signal processing stays in user space
sched_* / mlockScheduling & memory setup

Real-time kernel

Linux 6.6.0-rt15
PREEMPT_RT
BCI frameworkCharacter devices · ring buffersxtos_bci_core / xtos_bci_buffer
OpenBCI driverSerial input · packet parsingopenbci_cyton
Linux scheduling & memoryRT preemption · affinity · locked pagesPREEMPT_RT / sched_* / mlock
XTOS scheduling helperOptional kernel integration; not a Linux scheduler replacementxtos_sched

Devices & inputs

Hardware bring-up pending
OpenBCI CytonSerial sample input
Acquisition device configurationApplication → libxtos-bci → ioctl → BCI framework

Applications implement inference and feedback, not an in-kernel model or a verified hardware control loop.

Sample format and unit adaptation remain incomplete: the driver emits int32 nanovolts, but the SDK reads into float without conversion.

QEMU validates boot, module loading, and SDK self-tests. Device connectivity, hardware latency, and jitter need separate measurements.
Samples and resultsConfiguration and calls

Clear boundaries for system capability

The real-time core, user space, and SDK each have a clear responsibility. Components can be built, verified, and evolved independently.

Kernel Space

Linux PREEMPT_RT, XTOS scheduling helpers, the BCI framework, and device drivers establish real-time boundaries.

  • PREEMPT_RT
  • xtos_bci_core
  • UAPI

User Space

BusyBox, device-data pipelines, and signal tools provide a buildable, verifiable user-space environment.

  • BusyBox
  • EEG pipeline
  • Signal tools

SDK Layer

Three independent libraries expose scheduling, signal processing, and device sessions to applications.

  • libxtos-rt
  • libxtos-signal
  • libxtos-bci

From devices to applications

The two ends of the five-layer system: hardware provides input and applications produce inference and feedback. The layers between them keep interfaces open.

Hardware Layer

x86_64, ARM64, and RISC-V64 share the source and build-validation path. Real-device behavior needs separate measurements.

Application Layer

Applications use the SDK to read signals and process events; inference, feedback, and control remain application responsibilities.

Data Flow Path

Data follows one path with inspectable boundaries for input, processing, and response.

Input

Receive input from devices, sensors, or existing data streams.

Processing

Keep data traceable through buffering, parsing, and signal processing.

Response

Use the SDK to deliver data to applications for feedback and action.