[U-Boot] [RFC] Bootcount improvements

[U-Boot] [RFC] Bootcount improvements

[Alexandre Dilly]

Hi,

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.
- add an environment variable  'enable_bootcount' to enable/disable bootcount from the environment (and not at compile time) to avoid writing to flash/eeprom once the partition is known to be good and thus avoid useless memory wear.

I intend to upstream these features but I would like early input/criticism/ideas. Moreover I would like to make sure this goes well into the general philosophy of U-Boot and, if it doesn't, how I can change it to have it fit.

Any suggestion is welcome

Best regards,
Alexandre Dilly

[U-Boot] [RFC] Bootcount improvements

[Otavio Salvador]

On Fri, Mar 22, 2013 at 9:56 AM, Alexandre Dilly
<alexandre.dilly@openwide.fr> wrote:
> 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.
> - add an environment variable  'enable_bootcount' to enable/disable bootcount from the environment (and not at compile time) to avoid writing to flash/eeprom once the partition is known to be good and thus avoid useless memory wear.

I fail to see why you will want to save it as it works nowadays without it.

> I intend to upstream these features but I would like early input/criticism/ideas. Moreover I would like to make sure this goes well into the general philosophy of U-Boot and, if it doesn't, how I can change it to have it fit.

I really like to concept :-)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [RFC] Bootcount improvements

[Stefano Babic]

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
=====================================================================

[U-Boot] [RFC] Bootcount improvements

[Alexandre Dilly]

> > Hi,
> > 
> 
> Hi Alexandre,

Hi Stefano,

> > 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.
> 
In fact I would like to keep the bootcount value after a shutdown to handle update failures. Some embedded systems have only network access for administration and if you install an updated system with a misconfiguration of the network interface, you can't access anymore to the machine and you can't reset it. So the only way to reset the device is to unplug and replug but bootcount value is reset... So you can't switch back to a safe system...

> If you move the bootcount into a non-volatile memory, you add a
> history
> to the process and breaks this assumption.

That's why I suggest to use an environment variable (and may be a configuration option) to enable/disable this features.

Best regards,
Alexandre Dilly

[U-Boot] [RFC] Bootcount improvements

[Wolfgang Denk]

Dear Alexandre,

In message <1822628084.945501.1364317027872.JavaMail.root@openwide.fr> you wrote:
>
> In fact I would like to keep the bootcount value after a shutdown
> to handle update failures. Some embedded systems have only network
> access for administration and if you install an updated system with a
> misconfiguration of the network interface, you can't access anymore
> to the machine and you can't reset it. So the only way to reset the
> device is to unplug and replug but bootcount value is reset... So you
> can't switch back to a safe system...

You can define your own mechanism to do something like that, but
please do not misuse the bootcount for something it was never meant
for.   The bootcount is defined to count the number of boots after
power on; i. e. when you power on a board, the boot counter must by
definition start with the value zero.

> > If you move the bootcount into a non-volatile memory, you add a
> > history
> > to the process and breaks this assumption.
> 
> That's why I suggest to use an environment variable (and may be a
> configuration option) to enable/disable this features.

It should be easy and straightforward to implement such a feature by
defining a new environment variable.  All this can be done using
standard scripting, i. e. you do not need any code changes and thus no
new config options.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is wisdom in turning as often as possible from the familiar  to
the  unfamiliar: it keeps the mind nimble, it kills prejudice, and it
fosters humor.                                     - George Santayana

[U-Boot] [RFC] Bootcount improvements

[Alexandre Dilly]

Hi,

> Dear Alexandre,
> 
> >
> > In fact I would like to keep the bootcount value after a shutdown
> > to handle update failures. Some embedded systems have only network
> > access for administration and if you install an updated system with
> > a
> > misconfiguration of the network interface, you can't access anymore
> > to the machine and you can't reset it. So the only way to reset the
> > device is to unplug and replug but bootcount value is reset... So
> > you
> > can't switch back to a safe system...
> 
> You can define your own mechanism to do something like that, but
> please do not misuse the bootcount for something it was never meant
> for.   The bootcount is defined to count the number of boots after
> power on; i. e. when you power on a board, the boot counter must by
> definition start with the value zero.
> 
> > > If you move the bootcount into a non-volatile memory, you add a
> > > history
> > > to the process and breaks this assumption.
> > 
> > That's why I suggest to use an environment variable (and may be a
> > configuration option) to enable/disable this features.
> 
> It should be easy and straightforward to implement such a feature by
> defining a new environment variable.  All this can be done using
> standard scripting, i. e. you do not need any code changes and thus
> no
> new config options.

Thanks a lot for your answers! I will investigate in depth scripting capabilities of u-boot. I hope I will success to make a generic script with existing utilities for the purpose I've described before.

Best regards,
Alexandre Dilly