On Mon, Aug 1, 2016 at 12:03 PM, marko kiiskila <[email protected]> wrote:
> Hi Simon, > > thanks for taking a peek. > > > On Jul 30, 2016, at 3:01 PM, Simon Ratner <[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 > > > > 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.
