Aiden Adds a Unified Firmware Build CLI and On-Device Smoke Tests

Major Update: We merged PR #599, PR #612, and PR #569, adding a unified firmware build CLI, parallel CI checks, and board-local smoke tests. These changes are now merged in the open-source Aiden firmware repository, giving you a more structured path to build, validate, and diagnose firmware before moving into higher-level Agent troubleshooting.

The problem we fixed

Previously, build entry points and validation checks were spread across layers. That could leave you determining which command matched a build task, reconstructing the privileged container environment for an isolated command, or tracing a packaging failure without enough detail about the stage that failed.

Early hardware diagnosis had a similar dependency problem. A higher-level control or connectivity path could become part of the investigation before you knew whether low-level services were healthy. As a result, you could be debugging the Agent layer while the underlying display, audio, HID, or local service state still needed basic confirmation.

The merged work separates those concerns. It establishes a supported build path, isolates CI feedback by area, and makes it possible to check essential local behavior directly on the board.

What changes in Aiden

The build change makes build.sh the unified entry point for building binaries, building a complete firmware image, and running one-off commands inside the privileged build container. Instead of moving among separate scripts or manually recreating container context, you can use one entry point for the supported build modes.

This firmware build CLI also strengthens toolchain caching, reproducible timestamp handling, OTA key handling, and firmware-image packaging diagnostics. The improved diagnostics are especially useful when artifact assembly fails, because they provide clearer evidence about the failing packaging step rather than only reporting an unsuccessful outcome.

The validation boundary matters. The pull request did not complete a full local firmware-image build. Its result is described through CI and the reviewed technical implementation and validation recorded in the pull request. It should not be interpreted as proof of a successfully completed local full-image build.

The CI change restructures embedded firmware CI into independent parallel jobs for scripts, Docker, C++, Go, and Web checks. A failure in one area can be reported without waiting for unrelated checks in a serial path. This improves feedback structure and isolation, but it does not support a measured build-time percentage or a universal claim that every build is faster.

What you can do now

You can use build.sh as one supported build entry point for binary builds, firmware-image builds, and privileged-container commands. When packaging is the failing stage, you also have clearer diagnostics to help focus the investigation.

The new CI layout makes feedback easier to place at the relevant boundary: scripts, Docker, C++, Go, or Web. That organization helps you focus on the affected code or tooling layer without treating all checks as one undifferentiated result.

The third change adds board-local smoke-test scripts for HID, HDMI, audio, system state, and service logs. These on-device smoke tests run locally and do not depend on the Agent API, SSH, or network access. You can check low-level board behavior and inspect local service evidence before debugging Agent behavior or connectivity-dependent paths.

The current boundary

These smoke tests are intentionally narrow diagnostic tools. They are not complete hardware certification and not a full end-to-end Agent suite. They can help establish whether essential local subsystems and services appear healthy, but they do not prove every peripheral interaction, physical configuration, target-device scenario, or Agent workflow.

Likewise, these changes describe merged code, scripts, and CI architecture in the open-source Aiden firmware repository. They do not indicate deployment to every Aiden device or release, and they do not demonstrate production-wide behavior.

Inspect the linked pull requests above and follow Aiden’s continued open-source development.