Project overview
XTOS components, target architectures, workflow, and validation scope.
On this page
What XTOS provides
OpenXTOS is the public source distribution of XTOS. It contains Linux 6.6.0-rt15, static BusyBox 1.37.0 userland, a root filesystem, three SDKs, signal-processing tools, examples, and build and verification scripts.
The public sources can produce a kernel and initramfs and boot a development console. “Complete” does not mean a desktop, package manager, or hardware-certified product stack.
| Component | Implementation and artifacts |
|---|---|
| Real-time kernel | Linux 6.6.0 with PREEMPT_RT rt15 already integrated, optional XTOS_SCHED support, and BCI drivers; produces bzImage or Image and modules. |
| System userland | Static BusyBox, /init, a module directory, and a development shell; boots alongside the kernel as a cpio.gz initramfs. |
| SDK | libxtos-rt provides scheduling, affinity, locked memory, and SPSC; libxtos-signal provides signal algorithms; libxtos-bci wraps acquisition sessions. |
| Workloads and verification | An EEG CSV pipeline, signal benchmark, Python replay validator, and BCI example; QEMU checks exercise the programs actually built into the guest. |
The project’s direction is Super Intelligence. It researches real-time systems for BCI, deterministic signal processing, and intelligent applications. It also supports integration of existing AI models and algorithms.
Public sources provide the runtime foundation and interfaces. Model weights, inference services, feedback policies, and domain applications require separate implementation. The project’s direction does not mean that Super Intelligence capability, a model, or a closed loop is integrated.
Component responsibilities
The Linux scheduler schedules threads. PREEMPT_RT supplies the real-time preemption foundation. XTOS_SCHED is an optional locked O(1) priority-queue helper, not a Linux sched_class. It adds no SDK-specific syscall and does not replace task_struct or the syscall ABI.
The default build enables XTOS_SCHED. This only means that the helper is built into the kernel; it does not mean that every application uses it.
libxtos-rt calls standard sched_setscheduler, sched_setaffinity, and mlock. libxtos-signal computes in user space. BCI ioctls control acquisition devices.
The application owns windows, buffer budgets, thread priorities, timeouts, degradation, inference, and feedback. Acquisition control is not general actuator control. User-space algorithms are not kernel inference or safety guarantees.
Workflow
- Use Quickstart to install Linux host dependencies, obtain public sources, and pin the commit. Linux and BusyBox are vendored; do not download replacements or apply the patches again.
- Use Build to select an architecture and build directory, produce the kernel, static userland, modules, and initramfs, and retain the final .config and toolchain details.
- Use Run to execute the matching QEMU checks. x86_64 verify_system.sh includes guest self-tests; ARM64/RISC-V64 additionally need verify_guest_* rather than relying on the boot script saying PASSED.
- Enter an interactive shell, inspect /sys/kernel/realtime, modules, and SDK tests, then develop the application. Validate the CSV fixture path and real device path separately; neither substitutes for the other.
JOBS=$(nproc) ./scripts/build_system.sh
QEMU_TIMEOUT=180 ./scripts/verify_system.shx86_64 delivers .build/images/xtos-bzImage, .build/images/xtos-rootfs.cpio.gz, and .build/images/kernel.config by default.
Verification writes .build/system-qemu.log.
Images, root filesystems, and logs serve different purposes: an image existing establishes only that an artifact exists, not that boot or tests passed.
Target architectures
| Target | Build and guest verification | Virtual platform |
|---|---|---|
| x86_64 | build_system.sh → verify_system.sh; run_system.sh enters interactive mode. | qemu-system-x86_64, pc, ttyS0; default 512 MiB and 2 vCPUs. |
| ARM64 / AArch64 | build_system_arm64.sh → verify_system_arm64.sh → verify_guest_arm64.sh. | qemu-system-aarch64, virt, cortex-a57, ttyAMA0. |
| RISC-V 64 | build_system_riscv64.sh → verify_system_riscv64.sh → verify_guest_riscv64.sh; requires OpenSBI. | qemu-system-riscv64, virt, rv64, ttyS0. |
The public project validates these three QEMU guests. ARM64 and RISC-V64 root filesystems are not identical to x86_64.
Cross builders install SDK tests under /bin and use BusyBox init. x86_64 uses the full tool bundle and /usr/bin/xtos-selftest. The x86_64 CSV and benchmark self-tests do not automatically cover other architectures.
Validation scope
QEMU checks kernel boot, the PREEMPT_RT runtime flag, loading of three BCI modules, and SDK tests.
Module loading only establishes that the modules load into this kernel. It does not establish real OpenBCI enumeration, a correct serial link, or samples reaching an algorithm. Real hardware, hardware latency, jitter, and OpenBCI bring-up are outside the verified scope.
Real-device acceptance needs separate records of board model, firmware, connection and device tree, packet format, sample units, clock source, packet loss and overruns, load, and the end-to-end measurement method. Model accuracy, feedback safety, and medical use require their own application validation; they cannot be inferred from a Linux real-time configuration or a guest PASS marker.
Source
This page is based on OpenXTOS commit dd313955ad57542bcd2af8827157d1bbd0cf5e83. Repository-local references are README.md, VERSION, scripts/build_system.sh, scripts/build_system_arm64.sh, scripts/build_system_riscv64.sh, scripts/verify_system.sh, system/rootfs/usr/bin/xtos-selftest, and system/rootfs/xtos-guest-check. Source tree and System layers explain their responsibilities further.
Scheduling and sample-format boundaries follow kernel/linux/kernel/sched/xtos_sched.c, sdk/libxtos-rt/src/rt.c, kernel/linux/drivers/xtos/bci/devices/openbci_cyton.c, and sdk/libxtos-bci/src/session.c.
The user-space SDK, tools, examples, and system files use Apache-2.0. The kernel, PREEMPT_RT integration patches, and BusyBox use GPL-2.0. The SDK communicates with GPL-2.0 kernel components through the ioctl/syscall UAPI boundary rather than linking kernel source.