Dear Alexandre
In message 130325823.452426.1371459938406.JavaMail.root@openwide.fr you wrote:
One month ago, I sent a first request for comments about an open source automatic updater for embedded systems using U-boot: the goal of this project was to split a flash memory or hard disk drive in multiple partition (2 or more) and install a new kern el and/or root filesystem on an empty or outdated partition.
Could you please restrict yourline length to some 70 characters or so? Thanks!!
The u-boot environment would contain some variables to handle name, state and boot attempt count of each partition of the system. I would use CONFIG_ENV_OFFSET_REDUND to make writing on environment powerfail-safe. The environment contains 3 variables by partitions:
- part_X_flag: handles state of partition X. It can be NONE for empty partition, OK for working system, LOCK for locking a partition to install a new system on it, UPDATED for new system version (we count boot attempts for this partition) and BAD for ba
d system which doesn't work.
- part_X_count: handles boot attempts on partition X.
- part_X_cmd: U-boot command used to boot on the partition X (e.g. partition address in flash).
Environment contains also another variable: "boot_seq" which handles a list of bootable partition sorted by version.
This sounds like a bad idea, for two reasons:
1) U-Boot already supports the boot count feature (but of course this hardware-specific as you need to find persistent storage for the counter). However, this does not consider which exact boot command has been executed (in your case: what the used boot partition was), it just counts the number of resets after the last power-on. Actually this is all you should need.
Please note that this is a feature standardized for example in the Open Source Development Labs Carrier Grade Linux Requirements Definition, which says something like: "CGL shall provide support for detecting a repeating reboot cycle due to recurring failures and will go to an offline state if this occurs."
2) Defining the boot counter as part of the envrionment requires automatic writes to the environment for each reset / reboot of the board. This is considered a bad idea, as it causes excessive flash wear. Normally you want to avoid all erase / write operations to the boot loader and it's private data structures in the process of a normal reboot / reset.
Best regards,
Wolfgang Denk