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

[Heiko Schocher <hs@denx.de>]

Hello Robert,

Am 26.07.2016 um 14:21 schrieb Robert P. J. Day:
> On Mon, 25 Jul 2016, Heiko Schocher wrote:
>
> ... snip ...
>
>> 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 ...)
>
>    ok, i am now *totally* confused, so let's start at the beginning.
> it's my understanding that selecting CONFIG_BOOTCOUNT_LIMIT means you
> want to use the boot counter, it does *not* select what method you
> want to use to store the boot counter, correct? but here's the

Yes, thats correct.

> confusing part.
>
>    if i look in common/autoboot.c, i see:
>
>      const char *bootdelay_process(void)
>      {
>            char *s;
>            int bootdelay;
>      #ifdef CONFIG_BOOTCOUNT_LIMIT
>            unsigned long bootcount = 0;
>            unsigned long bootlimit = 0;
>      #endif /* CONFIG_BOOTCOUNT_LIMIT */
>
>      #ifdef CONFIG_BOOTCOUNT_LIMIT
>            bootcount = bootcount_load();
>            bootcount++;
>            bootcount_store(bootcount);
>            setenv_ulong("bootcount", bootcount);      <----- ?????
>            bootlimit = getenv_ulong("bootlimit", 10, 0);
>      #endif /* CONFIG_BOOTCOUNT_LIMIT */
>
>            ... snip ...
>
> and that's what confuses the heck out of me. i thought that, depending
> on the technique i wanted to use to store the boot counter (RAM, I2C,
> whatever), it would use *exclusively* that technique, and while i can
> see the use of the routines bootcount_load() and bootcount_store(),
> which are redefined based on the technique you select:
>
>    $ grep -rw bootcount_store *
>    bootcount_at91.c:void bootcount_store(ulong a)
>    bootcount_blackfin.c:void bootcount_store(ulong cnt)
>    bootcount.c:__weak void bootcount_store(ulong a)
>    bootcount_davinci.c:void bootcount_store(ulong a)
>    bootcount_env.c:void bootcount_store(ulong a)
>    bootcount_i2c.c:void bootcount_store(ulong a)
>    bootcount_i2c.c:	bootcount_store(0);
>    bootcount_ram.c:void bootcount_store(ulong a)
>    $
>
> it appears that, no matter what, the environment *is* updated every
> single time because of this line in the bootdelay_process() routine:
>
>    setenv_ulong("bootcount", bootcount);
>
> why? it seems, from the above, that no matter what boot counter

Yes, the bootcount variable gets set here ... but the environment
gets not written...

> mechanism you use, the environment will be updated because of that
> line.

The Environment gets written when saveenv() gets called ... or?

>    i can certainly see in bootcount_env.c where using
> "upgrade_available" can deselect writing to the environment based on
> invoking bootcount_store(), but that in no way stops that explicit
> call to setenv_ulong() in that routine above.
>
>    so how am i misunderstanding this? it seems that no matter what boot
> counter storage mechanism i select, i'll be writing to the environment
> every time *anyway*.

The Environmentvariable gets updated on boot, but not written into
the storage device.

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