From: Michael Opdenacker <michael.opdenacker@bootlin.com>
To: u-boot@lists.denx.de
Cc: lokeshvutla@ti.com, Gireesh.Hiremath@in.bosch.com,
nandor.han@vaisala.com, sjg@chromium.org,
michael.opdenacker@bootlin.com
Subject: [PATCH] bootcount: clarify documentation
Date: Wed, 2 Mar 2022 16:56:02 +0100 [thread overview]
Message-ID: <20220302155602.326642-1-michael.opdenacker@bootlin.com> (raw)
- Grammar fixes
- Clarify explanations
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
doc/README.bootcount | 34 ++++++++++++++++++----------------
drivers/bootcount/Kconfig | 10 +++++-----
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/doc/README.bootcount b/doc/README.bootcount
index b1c22905c6..f6c5f82f98 100644
--- a/doc/README.bootcount
+++ b/doc/README.bootcount
@@ -3,14 +3,16 @@
Boot Count Limit
================
+This is enabled by CONFIG_BOOTCOUNT_LIMIT.
+
This allows to detect multiple failed attempts to boot Linux.
-After a power-on reset, "bootcount" variable will be initialized with 1, and
+After a power-on reset, the "bootcount" variable will be initialized to 1, and
each reboot will increment the value by 1.
If, after a reboot, the new value of "bootcount" exceeds the value of
"bootlimit", then instead of the standard boot action (executing the contents of
-"bootcmd") an alternate boot action will be performed, and the contents of
+"bootcmd"), an alternate boot action will be performed, and the contents of
"altbootcmd" will be executed.
If the variable "bootlimit" is not defined in the environment, the Boot Count
@@ -18,18 +20,18 @@ Limit feature is disabled. If it is enabled, but "altbootcmd" is not defined,
then U-Boot will drop into interactive mode and remain there.
It is the responsibility of some application code (typically a Linux
-application) to reset the variable "bootcount", thus allowing for more boot
-cycles.
+application) to reset the variable "bootcount" to 0 when the system booted
+successfully, thus allowing for more boot cycles.
-BOOTCOUNT_EXT
--------------
+CONFIG_BOOTCOUNT_EXT
+--------------------
This adds support for maintaining boot count in a file on an EXT filesystem.
-The file to use is define by:
+The file to use is defined by:
-SYS_BOOTCOUNT_EXT_INTERFACE
-SYS_BOOTCOUNT_EXT_DEVPART
-SYS_BOOTCOUNT_EXT_NAME
+CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
+CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
+CONFIG_SYS_BOOTCOUNT_EXT_NAME
The format of the file is:
@@ -42,10 +44,10 @@ u8 bootcount
u8 upgrade_available
==== =================
-To prevent unattended usage of "altbootcmd" the "upgrade_available" variable is
+To prevent unattended usage of "altbootcmd", the "upgrade_available" variable is
used.
-If "upgrade_available" is 0, "bootcount" is not saved, if "upgrade_available" is
-1 "bootcount" is save.
-So the Userspace Application must set the "upgrade_available" and "bootcount"
-variables to 0, if a boot was successfully.
-This also prevents writes on all reboots.
+If "upgrade_available" is 0, "bootcount" is not saved.
+If "upgrade_available" is 1, "bootcount" is saved.
+So a userspace application should take care of setting the "upgrade_available"
+and "bootcount" variables to 0, if the system boots successfully.
+This also avoids writing the "bootcount" information on all reboots.
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 607027c968..65c052fc2e 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -68,15 +68,15 @@ config BOOTCOUNT_ENV
"bootcount" is stored in the environment. To prevent a
saveenv on all reboots, the environment variable
"upgrade_available" is used. If "upgrade_available" is
- 0, "bootcount" is always 0, if "upgrade_available" is
- 1 "bootcount" is incremented in the environment.
+ 0, "bootcount" is always 0. If "upgrade_available" is 1,
+ "bootcount" is incremented in the environment.
So the Userspace Application must set the "upgrade_available"
- and "bootcount" variable to 0, if a boot was successfully.
+ and "bootcount" variables to 0, if the system booted successfully.
config BOOTCOUNT_RAM
bool "Boot counter in RAM"
help
- Store the bootcount in DRAM protected against against bit errors
+ Store the bootcount in DRAM protected against bit errors
due to short power loss or holding a system in RESET.
config BOOTCOUNT_I2C
@@ -166,7 +166,7 @@ config BOOTCOUNT_BOOTLIMIT
help
Set the Maximum number of reboot cycles allowed without the boot
counter being cleared.
- If set to 0 do not set a boot limit in the environment.
+ If set to 0, do not set a boot limit in the environment.
config BOOTCOUNT_ALEN
int "I2C address length"
--
2.25.1
next reply other threads:[~2022-03-02 15:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 15:56 Michael Opdenacker [this message]
2022-03-23 5:59 ` [PATCH] bootcount: clarify documentation Heiko Schocher
2022-03-23 9:11 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220302155602.326642-1-michael.opdenacker@bootlin.com \
--to=michael.opdenacker@bootlin.com \
--cc=Gireesh.Hiremath@in.bosch.com \
--cc=lokeshvutla@ti.com \
--cc=nandor.han@vaisala.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.