On Mon, Jul 25, 2016 at 06:57:21AM +0200, Wolfgang Denk wrote: > Dear Robert, > > In message <alpine.LFD.2.20.1607231318540.16761@localhost.localdomain> you > wrote: > > > > so this tells me that there's not a whole lot of that feature being > > used, so i won't spend much time on it. > > Right, it is only a last resort when you cannot find any better place > to storeit (in a hardware register that survives resets).
That's not strictly true. One of the things I noticed recently is that Mender uses bootcount, in environment, as a least common denominator. And thrown in a file in a filesystem, in so far as you trust the underlying black box to be good about reads/writes and wear levelling, it's robust enough (for certain values of robust and enough). We're dipping into one of those areas where experts have varying opinions on what's good enough, hence all the qualifiers. But it is a useful option. And neatly circumvents the need for a "driver" to clear the count too. [snip] > > now, i can see where one wants to reset "bootcount" to zero once you > > boot successfully, but why would you also set "upgrade_available" to > > zero? don't you want to keep using that feature when you boot in the > > future? > > --> Heiko ? Heiko wrote a kernel driver, for the non-env side of things at least at one point, and the DT bindings didn't get approved. I picked it up years ago, tried, and had different DT binding approval problems and never cycled back to it while I was at TI playing with that kind of stuff. Which is why the bootcount in env side of things is so attractive, it's just fw_setenv/printenv once you're happy with your system boot. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
