Hacker News Reader

Comment by striking | Hacker News Reader

You could also do A/B partition booting. Whatever partition is currently running, the other one gets updated. When the update is complete, the system reboots to the updated partition. If it doesn't survive the reboot (like if the system never reaches the app and the hardware watchdog timer stops being reset), then it reboots again, back to the first partition.

View on HN

This is the common (and correct) solution.

In this scenario, the biggest problem is updating the bootloader, which cannot do this type of fallback.

Generally people avoid updating the bootloader (for good reason) but it is necessary sometimes...

Right. It's important that you leave as little logic in your bootloader as possible.

Have two bootloaders, one is trivially provable and can always be relied on in case the entire world falls apart, and can never be updated. The second one is updatable if needs be.

Of course, the good thing about the bootloader is it is less likely to need updates in the first place, and it's also likely easier to verify an update with a high level of confidence, as its functionality is so tightly bounded.

> (like if the system never reaches the app and the hardware watchdog timer stops being reset)

Worst case scenario is if the system does come up enough for the hardware watchdog to get kicked in a timely manner, but nothing else works.

The watchdog needs to be the last initialized bit of code on the system.

Even so, determining when a partition is "bad" is hard.

Of course. The hardware watchdog is just one of many things that should be taken into account. I picked it as an example, specifically because a lot of people don't know such a thing exists on many embedded systems.

Reply on news.ycombinator.com