> On Aug 2, 2016, at 11:32 AM, marko kiiskila <[email protected]> wrote: > >> >> On Aug 1, 2016, at 5:14 PM, Simon Ratner <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, Aug 1, 2016 at 3:55 PM, marko kiiskila <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>>> On Aug 1, 2016, at 3:34 PM, Simon Ratner <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> On Mon, Aug 1, 2016 at 12:03 PM, marko kiiskila <[email protected] >>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> >>>>> Hi Simon, >>>>> >>>>> thanks for taking a peek. >>>>> >>>>>> On Jul 30, 2016, at 3:01 PM, Simon Ratner <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Hi devs, >>>>>> >>>>>> I started poking at libs/bootutil, and have two questions: >>>>>> >>>>>> 1. >>>>>> >>>>> >>> https://github.com/apache/incubator-mynewt-core/blob/develop/libs/bootutil/src/bootutil_misc.c#L258 >>> >>> <https://github.com/apache/incubator-mynewt-core/blob/develop/libs/bootutil/src/bootutil_misc.c#L258> >>>>>> >>>>>> It looks like state and length are not saved atomically when using >>>>>> sys/config. If power is lost in the middle of the very first >>>>>> boot_write_status, after boot/status but before boot/len is written, >>>>> would >>>>>> that not corrupt the subsequent resume? I think writing boot/len before >>>>>> boot/status should be enough to fix this one. >>>>>> >>>>> >>>>> I think you’re right here. We should swap those around, and that’ll fix >>> it. >>>>> >>>>>> 2. >>>>>> >>>>> >>> https://github.com/apache/incubator-mynewt-core/commit/0678891276a4bc4b8900dd9321ada2c2afcbec09 >>>>>> >>>>>> What does this mean for the ability to resume, since when you resume >>> from >>>>>> an earlier saved state you may swap sectors that have already been >>>>> swapped, >>>>>> corrupting both image slots? >>>>> >>>>> Power outage in that case means bad things. This was a workaround >>>>> checkin; we’re still using NFFS for this state keeping, and I did see >>> quite >>>>> a few times writes failing. And when it happens, it happens >>> consistently on >>>>> every restart. So the app would not start. I thought it would be better >>> to >>>>> go >>>>> ahead with the swapping all the way, even if we can’t record progress. >>>>> Power outage is less likely than this other type of failure. >>>>> >>>>> We need to change the way keep track of progress, and not do it via >>>>> files. The current way is too prone to failure. >>>>> >>>> >>>> Is sys/config backed by fcb more robust? Perhaps in its own private flash >>>> area, if there are compatibility concerns with apps using nffs? >>>> >>>> Seems nffs is too heavy for bootloader use anyway. >>> >>> >>> Indeed, FCB is simpler. And therefore more robust; I’ve been using it quite >>> a bit. >>> >>> The trouble is that some platforms do not have enough flash sectors >>> to have both FCB and NFFS. NRF51/52 and Atmel SAMD21 are ok, but >>> STM32F4 for example has very few areas. >>> >>> I do want to remove NFFS dependency from bootloader, it is big and complex. >>> >>> I’ve been toying with the idea of setting aside hundred bytes from the end >>> of image >>> area, and use these as a way of a) communicating to bootloader that it >>> should swap and b) to keep track of the swap progress. >>> >> >> You wouldn't even need that much, right? Currently the status is just a >> couple of ints, could probably sneak them into existing header / trailer. >> Actually, the length of both images is already there, is there a reason why >> it needs to be stored separately for swap progress? > > Storing the length was a convenience thing. Not really required. > > For status upkeep, there needs to be few bytes for every area that gets > switched (3 bytes). And there has to be (size of image)/(size of scratch) > number of these. > So for nrf52dk I’d need 174 bytes for status. But for Olimex E407 it would be > 9 bytes. Plus few extras for possible magic, and definitely control things. >
Ok, I’m much further with the implementation. Now we’d tell bootloader to switch to another image by writing a magic word at the end of the image slot. And progress with the copy will also be stored there as well. This way bootloader will not need to look into system configuration at all. Which yields significant size benefit, in addition to hopefully being more resilient (less code to execute).
