Failsafe bootloader
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · At 05:33 AM 6/4/2003 -0400, [email protected] wrote:
Quoted 6 lines
Of course, this still doesn't protect you from loading a new bootrom that
has a valid checksum but a fatal problem (doh-doh-doh). Fortunately, in
that case the idiot is ourselves and we deserve the pain involved, and hopefully learn from it ;-).The problems we had were first that upgrades could be done transparently without the user knowing, so you can't really protect from the user unplugging (though we were supposed to be an always-on-don't-turn-off product). Second, have an image with a good checksum that boots up ok is only part of the story, we have to make sure that it can communicate correctly on its network. Ie, the application software has to communicate to the boot loader that the new image can be kept.
Quoted 4 lines
Also from experience, I've really lost a lot of hair in situations with other products that say "do not turn off the power until this update is finished", only to have the product crash, or the computer that is talking to it crashes.
Yes, you REALLY need enough storage to have two copies: the working copy and the new copy. The bootrom must NEVER erase the working copy until the new copy is verified to be completely and correctly loaded (checksums are a pretty weak validation, CRCs are strongly preferred).
If you are trying to upload a new image in-place, your window vulnerability (mentioned in my previous email) goes from the amount of time that it takes to erase and reprogram a block of flash to the time it takes to upload a
program: typically this means going from hundreds of milliseconds (reasonable risk) to hundreds of SECONDS (extremely high risk).
gvb
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/