Architecture#
Anatomy of the Pixie-16 System#
A Pixie-16 system requires multiple components working together to collect, analyze, and move data. The Pixie SDK sits in the middle and bridges the gap between the hardware and the software domains.
Pixie SDK#
The Pixie SDK uses a layered approach to seamlessly work with all Pixie-16 hardware revisions and provide a consistent API for users to develop against. Users have the freedom to link directly with the Pixie SDK framework library, but it’s not recommended. Changes in the framework layer are not covered by our API Update Policy.
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.
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.
Pixie-16 MIB#
The system contains a management information base (MIB) that provides access to the system’s information. The MIB forms the basis for reports and system controls. We are working to expand the information stored in the MIB. We are developing a C API to allow users access to the MIB information. To see the framework in action, please refer to the Pixie-16 Omnitool’s sysctl command.