Boot architecture is the one part of a product that cannot be fixed later. The immutable first stage, the partition layout, the signing scheme and the rollback path are all fixed before the first unit ships, and a design that got them wrong is a design that either cannot be updated or cannot be trusted.
Mask-programmed, immutable, and therefore the root of the chain. It cannot be updated after manufacture, so it does as little as possible: initialise the minimum hardware, locate the next stage, verify its signature, transfer control. Everything it does is a permanent commitment.
Brings up clocks, DRAM and the minimum peripherals needed to load further code. Verified by the boot ROM. Small enough to audit line by line, because a defect here is not field-repairable in most designs.
Selects between application images, handles the update state machine, and implements rollback. This is where A/B slot logic lives, and where an interrupted update must leave the device bootable.
Kernel and board support package brought up, with device tree or platform configuration describing what is actually fitted.
Peripheral drivers, protocol stacks, storage and connectivity brought into service in a defined order with defined failure behaviour.
Product functionality, by which point the chain has established that every stage below it is the one that was signed.
A flash budget decision as much as a software one, made when the memory part is selected.
| Scheme | Flash cost | Power-loss safe | Typical fit |
|---|---|---|---|
| Dual image (A/B) | Two full application slots | Yes, with atomic switchover | The default choice wherever the flash can be afforded |
| Image plus recovery | One slot plus a minimal recovery image | Yes, via a degraded recovery path | Cost-constrained designs where two full slots will not fit |
| Delta or differential | Smaller transfers; dual slots still required | Yes | Constrained links where transfer size rather than flash is the limit |
| In-place single image | Lowest | No | Avoid in fielded products; acceptable only with physical recovery access |
Power loss mid-write is the most common way to brick a fleet. A dual-image scheme with atomic switchover removes the failure mode entirely; careful coding in a single-image scheme does not.
Secure update wants monotonic version numbers: once a device has run version five, it must refuse version four, because version four is where the vulnerability was. Recoverability wants the opposite: if version five is broken, going back is the only way to save the unit.
Reconciling them needs a distinction between a security downgrade and a functional rollback. A monotonic security counter, incremented only on releases that fix a vulnerability, allows rollback within a counter generation while still refusing a genuinely unsafe downgrade.
Designing that in is cheap. Retrofitting it after a bad release has already reached the field is not, because by then the fleet is split across versions and the counter has no agreed meaning.
A sequence in which each stage cryptographically verifies the next before transferring control, rooted in an immutable boot ROM. It establishes that the code running is the code that was signed, and it is the mechanism a silicon root of trust enables.
Because the boot ROM is mask-programmed and immutable, and because partition layout, signing scheme and rollback path are fixed in the first firmware and the flash part selection. Changing them on deployed units generally requires physical access.
Dual image with atomic switchover. The new image is written to the inactive slot, verified, then activated by an atomic switch, so power loss during the write leaves the running image untouched. Single-image in-place update cannot offer that guarantee.
By separating functional version from a monotonic security counter that only increments on releases fixing a vulnerability. Rollback within a counter generation is permitted; going below the counter is refused.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.