[U-Boot] a few questions about saving bootcount in the environment
Heiko Schocher
hs at denx.de
Tue Jul 26 19:25:23 CEST 2016
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
More information about the U-Boot
mailing list