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). >> >> >> >
