[KMag]

Honestly, with flash so cheap these days, why isn't the firmware structured as two "partitions", each with a timestamp and checksum, and a small stub that

  (1) is never overwritten
  (2) is capable of accepting firmware updates over serial connection / TFTP / etc.
  (3) checksums the newest firmware "partition" runs it if the checksum checks out
  (4) falls back to the older "partition" of firmware if the checksum indicates corruption and/or partial update

Having had to TFTP-update several (and in one case exacto-knife jump two pins on the flash) WRT-54G firmware updates before I learned that the WRT-54G firmware update had issues with FireFox's HTTP POST implementation, I really wish firmware updates were more robust. A firmware update also bricked an early FitBit of mine.

[TheNewsIsHere]

Oh wow. I forgot about those days. In some ways I miss the WRT54G days a lot.

The Nintendo Switch does A/B firmware updates. It has tremendous speed benefits.

macOS sort of achieves something similar with the new system volume architecture, but…not exactly.

[mmastrac]

A lot of devices are actually structured that way. Android has an A/B flash system that works kind of like that.

It really comes down to how much time and care the developers have in their implementation.

[rcxdude]

It's not a particularly unusual configuration, but A/B images are still not immune to update failures

[KMag]

If a sufficiently robust integrity check is used, then an update failure is just a no-op, not a bricked (or even reduced capability) device, no?

Now, pushing a bad firmware version is another story, and impossible to prevent unless the firmware updater contains some impossibly complex static analysis tools to formally verify some set of correctness properties of the incoming update.