[U-Boot] a few questions about saving bootcount in the environment

[Heiko Schocher]

Hello Tom,

Am 25.07.2016 um 15:57 schrieb Tom Rini:
> On Mon, Jul 25, 2016 at 06:57:21AM +0200, Wolfgang Denk wrote:
>> Dear Robert,
>>
>> In message <alpine.LFD.2.20.1607231318540.16761 at 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.

Yep ... why do we need "upgrade_available"?

in ./common/autoboot.c on *every* boot bootcount_store() gets
called, so on every boot (which can happen very often) the Environment
would be written ... not good, for long life of your product (if
you have the Env in raw nand flash for example, as for the siemens
boards)

If the bootcounter feature is only needed if you really did an
update, to most writtes are unnecessary ... so the Userspace App can
set also "upgrade_available" to enable the bootcount feature in case
we save the bootcounter in the Environment ... and save a lot of
writtes to the Env

But if you say "I don;t care how often I write the Environment" you
simply can set "upgrade_available" to 1 and have the "original"
behaviour of the bootcount feature (incrementing bootcount on each
reboot ...)

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany