M2 NG-ULTRA Flight Reference

Objective

Prove the point in flight-oriented context: NG-ULTRA executes the same conceptual flight partition that M1 executed on x86-64.

GoMyRobotOS
      ↓
NG-ULTRA backend
      ↓
XNG / XtratuM
      ↓
RTEMS
      ↓
GoMyRobotRT

Scope

NG-ULTRA backend (IR → XNG/XtratuM configuration)
real target boot on NG-ULTRA
partition configuration deployment
resource ownership (memory, interrupts, devices, DMA) as declared
RTEMS workload execution
timing measurement for the reference partition
basic fault containment on the target

The existing NG-ULTRA / RTEMS / XNG ecosystem (ARMv8-R RTEMS BSP, XtratuM/XNG support in the NanoXplore ecosystem, recorded facts, see [NG-ULTRA platform page] (../platforms/ng-ultra)) makes this a realistic flight-oriented reference.

Deliverables

NG-ULTRA backend implementation
deployed flight partition (contract-identical to M1’s)
timing measurement data for the reference workload
basic fault containment demonstration
cross-target comparison notes (first production data for RP1)

Tests

real target boot
partition conformance (contract fields realized as declared)
resource-ownership checks
RTEMS workload execution under the declared scheduling/timing budget
timing measurement (declared budget vs measured window)
basic fault containment

Acceptance gate

NG-ULTRA executes the same conceptual flight partition.

“Same conceptual flight partition” is literal: identical contract, identical IR, different backend.

Current status

Planned (after M1).

Known limitations

Ecosystem facts about NG-ULTRA (BSP, XNG/XtratuM support) are recorded from the architecture doc; GoMyRobotOS integration work is the M2 contribution and Planned until shipped.
Timing measurement ≠ timing certification: numbers first, claims only after they are stable and reproducible (M3).
No radiation claims: NG-ULTRA’s radiation-hardened-by-design hardware is an input to RP4 (external products), not an M2 deliverable.