Firmware Management#
Users have often asked about firmware management within the Pixie-16 System. We’ve largely left it up to the users to decide how to manage the firmware. As time progressed, the number of module variants and firmware forks has increased. Firmware management complexity has grown, which makes it difficult to keep straight. We solved this problem by implementing a firmware infrastructure for the Pixie-16 system. This architecture uses a layered approach to maximize flexibility and maintainability.
First, we overhauled our firmware release process. We’ve made file naming consistent,
which makes programmatic access easier. Each firmware release now contains a specification file:
spec.json. The spec file contains metadata related to the release. We use this metadata in the
SDK to validate the firmware. We’ve also migrated the release versions to follow semantic
versioning. This will help with release clarity and compatibility.
Warning
The spec.json file is an internal XIA format and is subject to change without notice.
Our second step involved standardizing firmware releases on disk. We have defined the following paths on Linux and Windows respectively:
/usr/local/xia/pixie-16/firmwareC:\Program Files\xia\pixie-16\firmware
Firmware releases within these paths will be automatically made available to the crate. Our firmware installers will install to these locations.
Third, we designed and implemented a firmware management framework in the SDK. The SDK searches the provided installation path for firmware releases, and aggregates them into Firmware Sets. Firmware sets get organized based on their version and fork names. Unless otherwise told, the SDK will use the latest release to boot a module. Users are able to override parts of a firmware set or define their own sets.
Our fourth step deals with tracking firmware that’s been loaded onto a module. To do this, we calculate a firmware checksum and store it in the module. The SDK can verify that the Resident Firmware is the same as the firmware being loaded. This helps prevent corrupted or inconsistent firmware from being loaded onto the hardware. This information persists in the hardware until cleared during a power cycle.
Finally, we extended this work to the C API. Pixie16InitSystem() now initiates the process
to find the system firmware. Booting all modules in the system is as simple as calling
PixieBootCrate(). The module configuration structure now
contains the module’s resident firmware. These all combine to increase the crate booting efficiency.
More importantly, it ensures firmware integrity across boots. Please refer to the
API Functions for a full list of the functions.
The firmware management infrastructure removes the need for users to manage firmware sets via external means. We highly encourage all users to use the new implementation because it brings long-term benefits and improves support quality. For example, problems reported using release managed firmware will let us know the exact configuration state of the module. This reduces the time and interaction needed to reproduce the issue.