ARM NVIDIA Port

ARM NVIDIA Port

Purpose

This page defines the fourth platform target for XAI OS: ARM/NVIDIA N1X-compatible and GB10-class systems.

Contents

• Why ARM/NVIDIA Last
• Platform Assumptions
• Boot and Interrupts
• Memory Behavior
• Core Policy
• Success Criteria

Why ARM/NVIDIA Last

ARM/NVIDIA comes after x86 QEMU, Intel Desktop, and Intel Xeon because it needs a stable OS architecture before platform-specific AArch64 work. The goal remains CPU-only AI, not CUDA or GPU dependency.

Platform Assumptions

Target assumptions:

• AArch64;
• UEFI/SBSA where available;
• Device Tree fallback later;
• GIC interrupt controller;
• SMMU for DMA protection;
• LPDDR or unified memory behavior;
• mixed core or cluster topology.

Generic AArch64 work should include exception levels, page tables, timers, GIC, cache maintenance, atomics, and ABI boundaries. NVIDIA-specific work should be isolated to platform discovery, firmware quirks, board-level device setup, and any documented memory-controller behavior.

Boot and Interrupts

The first ARM path should prefer UEFI plus ACPI/SBSA where possible. GIC support and timer support are required before meaningful service work.

Memory Behavior

LPDDR/unified memory systems need explicit bandwidth measurement. Shared model weights, prefaulted arenas, and no-swap AI memory remain required.

Core Policy

Default policy:

• highest-performance cores: AI inference;
• middle cores: network and tokenizer workers;
• efficiency cores: SSH, logging, Git, source indexing, build/test;
• cluster migration forbidden for hot AI workers.

Success Criteria

XAI OS boots, runs AI Cell lifecycle tests, keeps hot workers on intended cores, and reports platform-specific memory and latency counters.

Additional criteria:

• no CUDA, GPU, NPU, or accelerator runtime is required;
• GIC interrupt routing avoids hot AI cores;
• SMMU protects DMA into AI Cell memory;
• LPDDR/unified-memory bandwidth is measured;
• cluster/core policy is visible in telemetry.

Firmware Dependency Risks

• Vendor firmware may hide memory-controller and power controls.
• UEFI/SBSA support may be incomplete.
• Device documentation may lag hardware availability.
• Fallback plan is to keep generic AArch64 boot and QEMU-style driver work independent from board-specific optimization.

Related Pages

• Driver Model
• Risk Register
• Open Decisions