From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Bootcount improvements
Date: Sat, 23 Mar 2013 10:49:18 +0100 [thread overview]
Message-ID: <514D7A9E.4010106@denx.de> (raw)
In-Reply-To: <967528043.798671.1363956961369.JavaMail.root@openwide.fr>
On 22/03/2013 13:56, Alexandre Dilly wrote:
> Hi,
>
Hi Alexandre,
> I'm working on an open source automatic updater for embedded systems. The goal of this project is to split a flash memory or disk in multiple partition (2 or more) and install a new root filesystem on an empty or outdated partition.
>
> After reboot, we count the boot attempts on this new version of the system and if it fails to boot, we switch back to the last working partition. This guarantees that we will eventually boot on a correct partition and that there is no chance to have an unsupervised equipment hang at the u-boot prompt.
>
> The u-boot environment would contain the name of the partition to test and the partition to fallback to. I would rewrite the u-boot environment after installing the new partition and use CONFIG_ENV_OFFSET_REDUND to make it powerfail-safe.
>
> To handle the boot attempts count, I've seen the 'bootcount' driver. However, it doesn't support all cpu and memories.
>
> I intend to improve the 'bootcount' driver by adding two features:
> - add eeprom and flash memories as places to load/save the bootcount value.
There are good reason to use volatile memory (in most case, the internal
RAM of the processor) to store the bootcount value. We should be sure
that the system is clean after a power-cycle. There are a lot of
different causes for a failing boot: a different network setup, other
devices attached to the board, and so on. If the reason depends on the
environment the board works, we should be sure that changing the
hardware the system is able to try again from a clean situation.
If you move the bootcount into a non-volatile memory, you add a history
to the process and breaks this assumption.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2013-03-23 9:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2055038254.798610.1363956733033.JavaMail.root@openwide.fr>
2013-03-22 12:56 ` [U-Boot] [RFC] Bootcount improvements Alexandre Dilly
2013-03-22 16:25 ` Otavio Salvador
2013-03-23 9:49 ` Stefano Babic [this message]
2013-03-26 16:57 ` Alexandre Dilly
2013-03-26 17:10 ` Wolfgang Denk
2013-04-02 13:17 ` Alexandre Dilly
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=514D7A9E.4010106@denx.de \
--to=sbabic@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox