On Mon, Aug 1, 2016 at 3:55 PM, marko kiiskila <[email protected]> wrote:
> > > On Aug 1, 2016, at 3:34 PM, Simon Ratner <[email protected]> wrote: > > > > On Mon, Aug 1, 2016 at 12:03 PM, marko kiiskila <[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]> 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. > > > 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? FCB is reliable enough, but the cost of dedicated flash sector(s) is too > high, IMHO. > Fair enough. Would you say then that it would be reasonable for an app that doesn't need nffs, but does depend on sys/config for itself, to switch sys/config to fcb for both app and bootloader, and revert 0678891 <https://github.com/apache/incubator-mynewt-core/commit/0678891276a4bc4b8900dd9321ada2c2afcbec09> ?
