Hi all, > On Jun 24, 2016, at 1:16 PM, David G. Simmons <[email protected]> wrote: > > >> On Jun 24, 2016, at 12:55 PM, [email protected] <mailto:[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.
This would be power outage/system reset when BIR is erased, and new bootloader has not been copied in yet. MCU always starts executing whatever is in BIR at reset. Because of this time window, I would not update boot loader. >> 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. > Bootloader code is not position independent. Maybe it’s possible to do with the later versions of gcc, but it was not the last time I tried. I was not able to figure out how to keep .data/.bss at fixed offset, while allowing .text to float. The bootloader at mynewt does place quite a few things at .data/.bss, so some rewrite would be needed (assuming gcc does not have this feature for our target CPUs).
