> On Jun 24, 2016, at 12:55 PM, [email protected] wrote: > > I think your main concern was about boatload upgradability. My assumption > was that in the field you would NOT upgrade it. From what I have heard, > most folks lock the flash sectors of the boot loader before shipping. > This is a larger question for the group. How do others feel about boot > loader upgrade. Regarding your upgrade procedure below, if a boot loader > upgrade fails in step B, the thing would become a brick.
You’re right that this is probably a larger discussion regarding the filed-upgradability of a bootloader. That being said, I’m not sure how a failure in step B yields a brick. > Here’s a scenario for an upgradeable bootloader: > > 1) Bootloader is signed with a SHA or PKI from a host computer — only > bootloaders signed with this key will be accepted except over direct > serial/jtag connection. If you have physical access to the device, you > win. This also allows a new host to ‘take over’ responsibility for > delivering bootloaders to devices by providing a new bootloader with a > new SHA/PKI key. > 2) new bootloader image is sent to the device and stored in SAR — could > be stored in SIR > a) new bootloader key is checked against current bootloader > key. If > keys don’t match, new bootloader image is erased otherwise continue > b) Keys match, so new bootlaoder is written to PIR and device > reboots > to new bootloader > c) if boot to new bootlaoder in PIR succeeds, PIR region is > written > to BIR and reboots — we have successfully updated the bootloader > d) if boot to new bootloader in PIR fails, reboots to old > bootloader, > and PIR is erased. > > This has the advantage — by first loading the bootloader into SAR for key > validation — of ensuring that a rogue bootloader does not wipe out an > existing AIIC/ADIC pair. It required 3 reboots to field-upgrade a > bootloader, but it maintains system integrity. Using this method, > bootloaders could be updated over bluetooth as well, as long as the keys > match, making filed upgrades of bootloaders possible. In step B, the new bootloader is in PIR while the old bootloader remains in BIR. System reboots to PIR. If that fails, meaning the new bootloader is bad, it simply reboots our of BIR (the old bootloader, and erases the bad bootloader in PIR. If it succeeds, meaning the new bootloader is good, it copies itself to BIR and reboots from BIR, then erases PIR and is ready for an application to be sent. dg -- David G. Simmons (919) 534-5099 Web • Blog • Linkedin • Twitter • GitHub /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ Secure your email!!! * Public key available at keyserver.pgp.com **/ ♺ This email uses 100% recycled electrons. Don't blow it by printing! There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
signature.asc
Description: Message signed with OpenPGP using GPGMail
