Platform Boundary & Customisation
Teams moving an existing robot or appliance stack onto Admiral usually ask the same question: what stays in my workload, and what moves into the platform?
The short answer: your application code, hardware control, and robotics middleware stay in your workload image. Admiral owns the boot chain, the kernel, networking configuration, and OS updates. Kernel patches, carrier boards, and boot branding are not locked away. They are built into the Admiral OS image for you.
1. What a Workload Can Reach
Admiral workloads are not sandboxed cloud containers. By default they run as root with direct access to host hardware:
| Area | Workload access |
|---|---|
| Device nodes | The full host /dev tree, with hotplug (see Hardware Access). |
| sysfs | Read-write /sys/class, /sys/devices, /sys/bus, /sys/block, /sys/module, /sys/firmware, and /sys/power. |
| Capabilities | Includes CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_SYS_NICE, CAP_SYS_RESOURCE, and CAP_MKNOD. |
| Networking | Private network namespace by default. With Host Network enabled, the workload uses the physical interfaces directly. |
| Scheduling | Real-time priorities (SCHED_FIFO / SCHED_RR), unlimited locked memory for DMA and pinned CUDA buffers. |
Hardware control that stays in your workload
Code that talks to the kernel through sysfs or device nodes runs unchanged:
- Fan and thermal control:
/sys/class/hwmon/*/pwm*,/sys/class/thermal/*. - CPU and GPU frequency policy: cpufreq governors and devfreq nodes under
/sys/devices. - LEDs, GPIO, PWM, backlight:
/sys/class/leds,/dev/gpiochip*,/sys/class/pwm,/sys/class/backlight. - Buses and peripherals: SocketCAN, serial, I2C (
/dev/i2c-*), SPI (/dev/spidev*), V4L2, DRM/KMS, ALSA, evdev. - Network interface state: with Host Network enabled,
/sys/class/net, netlink, andnl80211queries see the real interfaces.
:::note Kernel debug interfaces
debugfs and tracefs are not exposed to workloads. Tools that tune clocks through debugfs (rather than cpufreq/devfreq) need a platform-side equivalent; talk to us about the specific control you need.
:::
What the platform owns
| Function | Why it lives in the platform | How you control it |
|---|---|---|
| Wi-Fi association, priorities, static IPs, access-point mode | The device must stay reachable even if the workload crashes or is being updated. | Fleet and device networking settings, dashboard, or API. Live scan and link telemetry are available through the API. |
| Reboot and power-off | The workload runs in its own process namespace. A reboot inside it restarts the workload, not the machine. Platform reboots also stop the workload cleanly and flush logs first. | Dashboard, API, or automation. The physical power button and BMC/hypervisor shutdowns are handled gracefully. |
| OS, kernel, and bootloader updates | Updates stage into the passive slot and roll back if the new slot never becomes healthy. | A/B system updates and fleet version pinning. |
| Kernel modules | The kernel runs with module signature enforcement. Only modules built with the Admiral kernel load. | Ship drivers as part of your Admiral OS image (section 3). |
If your stack currently runs its own Wi-Fi manager (for example NetworkManager or a custom wpa_supplicant wrapper), that logic moves to fleet networking configuration. Everything else in this table is usually already handled by the platform.
2. Robotics Networking (DDS, Multicast, Discovery)
With Host Network enabled there is no network namespace, bridge, or NAT between your workload and the robot's network:
- FastDDS and CycloneDDS discovery over UDP multicast reaches other robots, operator stations, and off-board compute on the same network.
- Unicast peer lists and discovery servers (for networks that block multicast) work the same way they do on a bare Linux host.
- Shared-memory transport between ROS 2 nodes in the same workload works as normal. Size
/dev/shmfor your message load.
See Robotics & ROS 2 for configuration details.
3. Kernel, Drivers & Carrier Boards
Admiral OS images are built from a layered board support package (BSP): common platform, CPU architecture, SoC, then carrier board. The kernel, device trees, firmware, and out-of-tree drivers for each carrier are defined in that tree.
Kernel patches
If you carry kernel patches for bug fixes or feature enablement, we add them as a patch series on your target and build the kernel for you. Your patches go through the same signing and A/B update path as every other Admiral kernel release, so a bad kernel rolls back like any other update.
On NVIDIA Jetson Orin, the kernel tracks NVIDIA's Jetson Linux (L4T) kernel with Admiral patches on top. Other SoCs use the kernel tree best supported for that silicon.
Real-time kernels
Admiral kernels are fully preemptible by default, which gives low scheduling latency for SCHED_FIFO / SCHED_RR control threads. If your control loops need hard real-time guarantees, we build a PREEMPT_RT kernel for your target. It ships and updates through the same signed A/B path as the standard kernel.
Third-party carrier boards
Adding a carrier board means adding a board layer:
- Device tree sources and overlays for the carrier.
- Kernel configuration fragments for the peripherals it exposes.
- Extra out-of-tree drivers and firmware (for example a carrier-specific Ethernet or Wi-Fi chip).
A board layer inherits everything else (A/B updates, verified root filesystem, the Admiral runtime) from the SoC layer below it. If you already package carrier BSPs with another build system, the inputs (DTS, defconfig fragments, driver sources, firmware blobs) carry over directly.
Out-of-tree drivers
Because unsigned modules are rejected, drivers cannot be loaded from inside a workload image. Drivers are built with the kernel for your target and shipped as part of the signed module set, then loaded automatically at boot.
4. Firmware & Boot Branding
| Layer | Ownership |
|---|---|
| Boot splash (bootloader and early boot) | Part of the Admiral OS image. Custom per-customer splash images are supported. Talk to us to set yours. |
| Kernel command line and boot options | Part of your Admiral OS target. Changes are made in the BSP, not on the device. |
| Jetson QSPI firmware (UEFI, BCT, MB1/MB2) | Customer-owned today. Flash your firmware (including UEFI customisations and firmware boot logos) with NVIDIA's tools during manufacturing. Admiral boots from the firmware's standard EFI boot path. |
| x86 UEFI / BIOS settings | Vendor or customer-owned. Admiral requires UEFI boot. Secure Boot is supported. |
5. Migrating an Existing Stack: Checklist
- Package your userspace as an OCI image. Your existing services, launch files, and hardware daemons run inside it. See Configurations.
- Enable Host Network if you use DDS discovery, SocketCAN, or need to read real interface state.
- Move Wi-Fi and network profiles into fleet networking configuration.
- Replace in-workload reboot and shutdown calls with the Admiral API.
- Move persistent data (maps, calibration, logs) onto Custom Volumes.
- Send us your kernel patches, carrier DTS, and driver list so we can build your Admiral OS target.
- Keep your Jetson QSPI firmware flow in manufacturing for now.