[U-Boot] [RFC] Bootcount improvements
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
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@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
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
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
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
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
participants (4)
-
Alexandre Dilly -
Otavio Salvador -
Stefano Babic -
Wolfgang Denk