This page explains how the bootloader chooses a firmware bank and when it rolls back.
This is an explanation page (decision flow and behavior). For canonical data definitions, use:
The bank selection logic is responsible for:
- Selecting a bank to boot
- Detecting repeated failed boots
- Rolling back to the alternate bank when needed
- Falling back to weaker validation when full metadata is unavailable
- Main entry point:
crispy-bootloader/src/boot.rs - Selection function:
select_boot_bank()
Start boot
-> Read BootData
-> Check rollback condition (attempts >= threshold && not confirmed)
-> if true: toggle active bank, reset attempts
-> Try candidate strategies in order:
1) active bank with CRC validation
2) alternate bank with CRC validation
3) active bank with basic vector validation
4) alternate bank with basic vector validation
5) default active bank (last-resort boot attempt)
-> Update BootData in flash
-> Copy firmware to RAM and jump
Rollback is triggered when the current firmware repeatedly fails to confirm boot.
- A boot attempt counter is incremented by the bootloader
- Firmware confirmation marks an image as healthy
- If attempts reach threshold without confirmation, the active bank is toggled
Current threshold in code: MAX_BOOT_ATTEMPTS = 3.
Used when metadata is available:
- Vector table sanity checks
- Size presence
- CRC32 match
Fallback path when metadata is incomplete:
- Vector table sanity checks only
The selection logic consumes these fields from BootData:
active_bankconfirmedboot_attemptssize_a/size_bcrc_a/crc_b
Field definitions and layout are documented in Boot data reference.