Thanks for the comments. I think there may be some nomenclature issues here related to the bootloader.
In my design the bootloader is the fixed bit at 0x0 containing the reset vectors and the code swap and run PIR images. In the Nordic docs (since we are sometimes focused on the NRF chips) they call this the MBR. The bootloader in NRF-speak is another app that can be loaded that can replace the soft device (but I don¹t think it replaces the MBR) Paul On 6/24/16, 1:43 PM, "marko kiiskila" <[email protected]> wrote: >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). > > >
