From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] a few questions about saving bootcount in the environment
Date: Mon, 25 Jul 2016 19:26:10 +0200 [thread overview]
Message-ID: <57964BB2.70702@denx.de> (raw)
In-Reply-To: <20160725135754.GN14698@bill-the-cat>
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@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
next prev parent reply other threads:[~2016-07-25 17:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-23 17:29 [U-Boot] a few questions about saving bootcount in the environment Robert P. J. Day
2016-07-25 4:57 ` Wolfgang Denk
2016-07-25 13:57 ` Tom Rini
2016-07-25 14:35 ` Wolfgang Denk
2016-07-25 17:56 ` Robert P. J. Day
2016-07-25 18:37 ` Wolfgang Denk
2016-07-25 18:41 ` Robert P. J. Day
2016-07-25 17:26 ` Heiko Schocher [this message]
2016-07-26 12:21 ` Robert P. J. Day
2016-07-26 12:48 ` Wolfgang Denk
2016-07-26 12:49 ` Robert P. J. Day
2016-07-26 17:25 ` Heiko Schocher
2016-07-27 12:03 ` Robert P. J. Day
2016-07-27 15:10 ` Heiko Schocher
-- strict thread matches above, loose matches on Subject: below --
2016-07-25 14:36 Wolfgang Denk
2016-07-22 19:36 [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h Robert P. J. Day
2016-07-22 22:01 ` Wolfgang Denk
2016-07-23 11:42 ` Robert P. J. Day
2016-07-25 4:54 ` Wolfgang Denk
2016-07-25 10:03 ` Robert P. J. Day
2016-07-25 13:26 ` Wolfgang Denk
2016-07-25 17:24 ` [U-Boot] a few questions about saving bootcount in the environment Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57964BB2.70702@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.