[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