ContiMech
Robotics & Automation Engineering

Firmware / software process / Hardware process / Case study

Case study · Embedded Linux / inertial control

Compact Embedded Linux Compute Platform for an Inertial Control System

At the customer’s request, Linux-level application capability had to be added directly inside an existing compact inertial-control stack — without introducing a bulky external SBC and without moving deterministic control loops into Linux.

NXP i.MX93Alpine LinuxCAN FDGPIOSSH serviceFast boot
Softened view of a compact circular multi-board inertial-control electronics stack
CR

Customer request

The customer needed an application layer typical of a micro-ROS-class gateway — command/status exchange, peripheral coordination and diagnostics — but also required standard Linux capabilities: SSH service access, persistent logs, field configuration and maintainable software updates. The new compute layer had to fit the current circular board geometry, remain cost-aware, and keep the real-time inertial-control electronics unchanged.

Target platform

◎
Compact stackLayered inertial-control electronics
○
Circular PCBCompute board follows the existing envelope
µ
MCU control retainedDeterministic loops stay on dedicated MCUs
L
Linux addedApplication services and orchestration
↯
Power-awareNo external high-power SBC
↔
Service accessEthernet and UART maintenance paths

Engineering response

We defined a custom circular compute board around the NXP i.MX93 application processor. The i.MX93 provides Cortex-A55 Linux application processing together with a Cortex-M33 subsystem and native interfaces suitable for industrial control integration, including CAN FD. The board is treated as another layer of the product stack rather than as an external computer.

The software baseline combines the NXP boot/kernel support for i.MX93 with an Alpine Linux aarch64 root filesystem. The critical userspace is intentionally small: OpenRC, the product application, SocketCAN/libgpiod integration, logging, OpenSSH and the update service. Non-critical services are kept out of the application-ready boot path.

Application service / diagnostics / update manager OpenSSH · can-utils · libgpiod · gdbserver Alpine Linux aarch64 rootfs Linux kernel + device tree from NXP i.MX BSP U-Boot / secure boot chain NXP i.MX93 · LPDDR4X · eMMC

The Linux workload is supervisory. Safety timing, inertial sampling and deterministic actuation do not depend on Linux scheduler latency.

Softened inertial-control hardware stack used as the target mechanical envelope
ComputeDual-core Cortex-A55 application processing, 1 GB LPDDR4X and 8 GB eMMC as the project baseline.
InterfacesCAN FD for device traffic; GPIO for enable, reset, interlock and fault lines; service UART; 100BASE-TX Ethernet for engineering access.
Linux roleSystem orchestration, state aggregation, diagnostics, logging, configuration, remote service and software update workflow.

Why Linux instead of another MCU?

MCU-class taskThe core behavior is close to a typical micro-ROS gateway: read device state, publish status, accept commands, switch GPIOs and exchange data over CAN.
Linux-only requirementsSSH, persistent logs, file-based configuration, package/release deployment, richer networking and field debugging made a small Linux application processor the cleaner product architecture.
Cost controlNo GPU, display stack, Wi-Fi module or general-purpose external SBC was required. Only the interfaces and memory needed by the product were placed on the custom compute board.
Architecture boundaryNative SocketCAN and libgpiod were used for the production I/O service. DDS/ROS integration can remain optional instead of coupling the hardware layer to a full robotics framework.

Architecture and component interaction

UML-style architecture diagram for the Linux compute board and deterministic control electronics
Component view. Linux owns serviceability and orchestration; CAN/GPIO connect it to the MCU layer; sensor and actuation timing remains under deterministic control.
UML-style sequence diagram for Linux, CAN GPIO layer, control MCU and peripheral device
Interaction view. A typical operation moves from application request through the Linux I/O layer to the MCU, then returns device state and diagnostic information.
  1. BootStart only the minimum services required for product readiness.
  2. ConfigureBring up CAN filters, GPIO roles and health supervision.
  3. ObserveCollect MCU, sensor and peripheral state.
  4. CommandTranslate application requests into CAN/GPIO operations.
  5. RecordPersist faults, events and relevant diagnostic context.
  6. ServiceExpose controlled SSH/debug/update paths without entering the real-time loop.

Fast boot and field service

Fast startup was treated as a system requirement. The boot chain is minimized around the actual board: U-Boot delay removed, device tree reduced to used hardware, console output kept out of the critical path, network configuration made deterministic, and the application service started before non-essential maintenance services.

Application-ready design target
≤ 4 s
Power-on to the point where CAN/GPIO coordination and the main application service are available. This is the project target used to guide boot-chain optimization, not a generic Linux distribution benchmark.
Service shell
after app
OpenSSH is started after the application-critical path. Production configuration uses key-based authentication and a dedicated service account; password and direct root login are disabled.

Diagnostics and update path

SoC

Custom compute integration

Circular i.MX93 board integrated into the existing mechanical stack, with the memory, PMIC and interfaces required by the product.

AL

Alpine-based Linux stack

Lean aarch64 userspace with NXP BSP boot/kernel support, OpenRC startup and a deliberately small runtime package set.

SSH

Remote diagnostics

Key-based SSH plus service UART; can-utils, libgpiod tools, gdbserver, strace, tcpdump and kernel logs available for engineering builds.

A/B

Maintainable update path

Versioned release bundle, integrity verification, inactive eMMC system slot and rollback strategy designed into the field-maintenance flow.

Result

Linux capability inside the product stack — not beside it.

The resulting architecture adds a maintainable Linux application layer without replacing deterministic embedded control and without attaching a separate SBC. The customer gains standard Linux serviceability, richer diagnostics and a controlled update path while the inertial-control electronics preserve their real-time responsibilities and physical packaging.

Firmware / software process Hardware engineering process System engineering process Robotics Discuss a similar embedded system