Innoflight CFC-400

Where this stands

SpaceOS does not run on the CFC-400 today, and no target profile ships for it. The platform source records the board under “Not currently supported” in its support matrix (docs/support-matrix.md).

The v1.1 support promise this page used to carry was withdrawn on 2026-08-26. No release currently commits to this board.

Bring-up has not started. The engineering unit arrived with shipping damage and its power and console harness is missing, so the board has never been powered on. Everything below comes from the vendor manual and the sample boot log.

The Innoflight CFC-400 series is a commercial flight computer family for small-satellite missions. The intended integration is a daemon install, the row it would take in the target matrix: SpaceOS would run as a supervised service on the vendor’s Linux, and the node would enroll into a ground context as a runner beside every other node.

Prove your workload on the Raspberry Pi CM5 first. The CM5 is a supported target today, it shares the aarch64 architecture, and it takes the same static runtime binaries.

Hardware, from the vendor manual

• Compute element. The CFC-400XS carries a Xilinx Zynq UltraScale+ multiprocessor system-on-chip: quad Cortex-A53 (aarch64) application cores, dual Cortex-R5F real-time cores, and FPGA fabric. Only the A53 Linux side is relevant to a hosted service.
• Memory. 2 GB DRAM, roughly 1.7 GB usable after the reserved contiguous memory area, on four Cortex-A53 cores at about 0.6 GHz. That budget makes unikernels the natural tenant. Full Linux virtual machines fit poorly in 1.7 GB.
• Boot media. QSPI and NAND flash. There is no SD-card slot.

What the stock image is, and what it means

The sample boot log in the vendor manual settles several questions that decide which SpaceOS backend could apply. These are vendor facts, not measurements we have taken on the unit.

• The stock image runs bare Linux, not Xen. The chain is FSBL, then ATF, then U-Boot 2019.01, then Linux 4.19. The Xen support in the vendor kernel configuration is the dormant guest-driver set.
• Linux runs at EL2, which is the arrangement KVM needs, so the board is KVM-capable. The stock kernel prints no KVM initialisation, so CONFIG_KVM is off. Turning it on is a kernel-configuration rebuild on the vendor’s side.
• The root filesystem is a RAM initramfs and does not persist. Persistent storage is UBIFS at /mnt/ubi. Anything written to / is lost on reboot, so a service and its boot hook have to live on persistent storage.
• Init is BusyBox and SysV, so the service wrapper is an rc.d hook.

Two consequences follow, and both are gaps:

• runc does not suit this board. A 4.19 kernel on a minimal Buildroot 2016.08 root filesystem lacks the cgroup v2, user-namespace and overlay surface runc needs, and the image ships no container tooling.
• The SysV installation path is incomplete in SpaceOS. The vendor board support package keeps the boot path, and the rc.d renderer exists, but install, lifecycle, update and uninstall still dispatch through systemd. The support matrix lists SysV and BusyBox hosted boards as not supported for that reason.

The intended tenant boundary is Xen, and it has no code

The design intent for this board is Xen, with dom0 pinned to dedicated physical CPUs so the vendor’s management daemon always runs regardless of tenant load. That daemon pets the processor-board watchdog and reports junction temperature; if SpaceOS ever starved it, the supervisor would reset the whole board.

The isolation schema in the platform source (space-schema/lib/runtime.ml), which is what substrates documents, enumerates runc, spt, hvt, firecracker, qemu and host. It has no Xen variant, and no Xen backend exists. Every Xen reference in the platform tree is design or an open work item.

Two interim lanes are possible once the board is running, neither of them exercised:

• spt, the seccomp-sandboxed Solo5 tender, runs on the stock kernel with no rebuild and gives weaker isolation than a hypervisor. The binary ships on every SpaceOS image. No shipped target profile declares spt, and no end-to-end test boots a workload under it.
• hvt becomes possible after a CONFIG_KVM=y kernel, since the cores already boot at EL2.

What has to happen before this page carries steps

• Clear the shipping damage with the vendor, and obtain the JX1 power and console harness so the unit can be powered on at all.
• Capture the board’s real facts on first boot: kernel, init, storage, watchdog timeout, and whether KVM is present.
• Write a target profile from those observed facts, and land the SysV lifecycle dispatch behind the signed-bundle installer.
• Exercise one admitted unikernel backend on the board under pinned issuer keys and a bounded quota policy.

If you have an Innoflight integration and want to be part of that work, contact Parsimoni.