That’s generally the practice for units in field where security is a concern (e.g. industrial IoT devices).
aditi > On Jun 24, 2016, at 3:18 PM, will sanfilippo <[email protected]> wrote: > > My expectation would be that the bootloaders would be locked down and thus > not upgradeable in the field… > > Will >> On Jun 24, 2016, at 2:04 PM, [email protected] wrote: >> >> 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). >>> >>> >>> >> >
