The bootloader is the only code that is never allowed to be wrong

In a device with working over-the-air updates, almost every defect is recoverable. Ship a bad driver, fix it next release. Ship a memory leak, patch it. The update mechanism is the safety net under the entire product.

Which means the update mechanism itself has no safety net. A bootloader defect that prevents the device from booting cannot be fixed by shipping a new bootloader, because shipping requires booting.

What the asymmetry should change

Review intensity is not uniform. Treating bootloader changes with the same process as application changes misprices the risk by orders of magnitude. Slot selection, signature verification and the boot counter deserve a different bar: line-by-line review, a second reviewer, and an explicit argument for why the change is safe under power loss.

Feature pressure must be resisted. Every additional capability in the bootloader is additional code that must never fail, running before any of the system’s protections exist. Network stacks, filesystem drivers and display code in a bootloader are all invitations. If it can live in the application, it should.

Change frequency should approach zero. Mature bootloader code that has run on thousands of devices is an asset. Rewriting it for elegance is trading proven behaviour for unproven behaviour in the one place that cannot be rolled back.

The failure modes worth designing against

Power loss during the switch. The transition from slot A to slot B must be a single atomic write with no window where neither slot is selected. In practice this means a redundant, checksummed environment: write the copy, verify it, then update the primary. Interrupted at any point, one valid copy always remains.

The half-written image. An image must be fully written and verified before it can be selected. Verification means a cryptographic hash over the complete image, not a length check — flash that reports a successful write can still hold corrupt data.

The image that boots but does not work. This is the failure that catches teams out. The kernel starts, the bootloader considers the update successful, and the device is unreachable because the network configuration was wrong. The boot counter must only be cleared by an application health check that exercises real functionality. “The kernel booted” is not a health check.

The valid signature on the wrong hardware. A correctly signed image built for board revision C, installed on revision A. The manifest must carry hardware compatibility constraints and the device must enforce them.

The replayed old image. Correctly signed, genuinely ours, and vulnerable. Without a monotonic anti-rollback counter in one-time-programmable storage, signature verification alone does not prevent downgrade.

Testing it means being deliberately cruel

Normal testing verifies the happy path. Bootloader testing has to attack it:

• Cut power at randomised offsets throughout the write-and-switch sequence, over thousands of iterations. Automate it — a relay and a script find things a human never will.
• Corrupt the image at random offsets and confirm the device refuses it.
• Truncate the image mid-transfer.
• Present a valid signature over the wrong hardware revision.
• Replay an old signed image.
• Fill the flash to capacity and retry.
• Run the whole matrix on the oldest board revision still in the field. It has the least headroom and it is where problems surface first.

The cultural part

There is a strong temptation to treat the bootloader as plumbing — the thing to get past quickly on the way to the interesting work. That instinct is exactly backwards. It is the component with the highest consequence-per-line in the entire product.

Give it the review, the test rig and the restraint it deserves, and everything built above it becomes recoverable. Get it wrong, and nothing else does.

---