What it solves
Firmware updates need validated slots, explicit handoff and rollback-oriented state.
How it works
1Reset→2validate boot state→3select A/B slot→4platform handoff
Use it when
Receive an update over the supplied UART transport
Boot a pending image and require confirmation
Roll back an unconfirmed image on the next boot
Keep platform jump logic behind an adapter boundary
Quick Start
#include "loxboot.h"
loxboot_ctx_t boot;
/* Configure storage and platform callbacks from the adapter contract. */
/* Call the documented boot/update state machine from the platform entry. */
/* Expected: an explicit selected slot or update state. */Real scenarios
Receive an update over the supplied UART transport
A C99 bootloader core provides A/B state, UART update transport and adapter boundaries.
Boot a pending image and require confirmation
A C99 bootloader core provides A/B state, UART update transport and adapter boundaries.
Roll back an unconfirmed image on the next boot
A C99 bootloader core provides A/B state, UART update transport and adapter boundaries.
Engineering evidence
- Host CMake and 20 CTest entries are documented as verified
- ESP32-S3 ESP-IDF 5.5.1 build, flash, runtime and OTA/rollback runs are recorded in HARDWARE_EVIDENCE.md
Known limits
- STM32 hardware is explicitly not verified
- Board integration, flash layout and jump behavior remain platform work
- It is a bootloader core, not an application-side crash-loop manager