summaryrefslogtreecommitdiff
path: root/drivers/bootcount/bootcount_env.c
AgeCommit message (Collapse)Author
2017-08-16env: Rename getenv_hex(), getenv_yesno(), getenv_ulong()Simon Glass
We are now using an env_ prefix for environment functions. Rename these for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-16env: Rename common functions related to setenv()Simon Glass
We are now using an env_ prefix for environment functions. Rename these commonly used functions, for consistency. Also add function comments in common.h. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-15env: Drop saveenv() in favour of env_save()Simon Glass
Use the env_save() function directly now that there is only one implementation of saveenv(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2013-11-11bootcount: store bootcount var in environmentHeiko Schocher
If no softreset save registers are found on the hardware "bootcount" is stored in the environment. To prevent a saveenv on all reboots, the environment variable "upgrade_available" is introduced. If "upgrade_available" is 0, "bootcount" is always 0 therefore no need to save the environment on u-boot boot, if "upgrade_available" is 1 "bootcount" is incremented in the environment and environment gets written on u-boot start. So the Userspace Applikation must set the "upgrade_available" and "bootcount" variable to 0 (for example with fw_setenv), if a boot was successfully. Signed-off-by: Heiko Schocher <hs@denx.de>