[U-Boot] [RFC][PATCH] bootcount: add support to customize bootcount variable name

This commit add an option to customize the bootcount variable name in the u-boot environment. To stay compatible with old config, the default name is bootcount.
Signed-off-by: Philippe Reynes philippe.reynes@softathome.com --- drivers/bootcount/Kconfig | 8 ++++++++ drivers/bootcount/bootcount_env.c | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig index b7c29f2..0088bf8 100644 --- a/drivers/bootcount/Kconfig +++ b/drivers/bootcount/Kconfig @@ -161,4 +161,12 @@ config SYS_BOOTCOUNT_MAGIC help Set the magic value used for the boot counter.
+config SYS_BOOTCOUNT_NAME + string "Name of the bootcount variable in the env" + default "bootcount" + depends on BOOTCOUNT_ENV + help + Set the name of the variable that count the number of boot. + Usually this variable is named 'bootcount'. + endif diff --git a/drivers/bootcount/bootcount_env.c b/drivers/bootcount/bootcount_env.c index b75c900..d5a38c8 100644 --- a/drivers/bootcount/bootcount_env.c +++ b/drivers/bootcount/bootcount_env.c @@ -12,7 +12,7 @@ void bootcount_store(ulong a) int upgrade_available = env_get_ulong("upgrade_available", 10, 0);
if (upgrade_available) { - env_set_ulong("bootcount", a); + env_set_ulong(CONFIG_SYS_BOOTCOUNT_NAME, a); env_save(); } } @@ -23,7 +23,7 @@ ulong bootcount_load(void) ulong val = 0;
if (upgrade_available) - val = env_get_ulong("bootcount", 10, 0); + val = env_get_ulong(CONFIG_SYS_BOOTCOUNT_NAME, 10, 0);
return val; }

Dear Philippe,
In message 1568037413-28155-1-git-send-email-philippe.reynes@softathome.com you wrote:
This commit add an option to customize the bootcount variable name in the u-boot environment. To stay compatible with old config, the default name is bootcount.
Which exact problem are you trying to fix with this commit?
I mean, we have a ton of variable names with fixed meaning, which have been in use for nearly 2 decades - bootcmd, bootargs, bootcount, ...
What is wrong with the "boootcount" name?
Best regards,
Wolfgang Denk

Hi Wolfgang,
Dear Philippe,
In message 1568037413-28155-1-git-send-email-philippe.reynes@softathome.com you wrote:
This commit add an option to customize the bootcount variable name in the u-boot environment. To stay compatible with old config, the default name is bootcount.
Which exact problem are you trying to fix with this commit?
I have severals layers in my boot chain, and I want to use bootcount in severals layers to manage boot issues. If severals layers use the same variable name (bootcount) and a boot issue happen, I can't find the layer that fails.
So I propose to "customize" the bootcount variable name.
I mean, we have a ton of variable names with fixed meaning, which have been in use for nearly 2 decades - bootcmd, bootargs, bootcount, ...
What is wrong with the "boootcount" name?
As it is "unique", I can't chain severals bootcount. That's why I propose an option to customize the bootcount name variable.
I know that it's a "corner case" and that you could prefer to avoid adding another option, that's why I've proposed this option as a RFC.
Best regards,
Wolfgang Denk
Best regards, Philippe Reynes

Dear Philippe,
In message 992029351.2212296.1568047262683.JavaMail.zimbra@softathome.com you wrote:
I have severals layers in my boot chain, and I want to use bootcount in severals layers to manage boot issues. If severals layers use the same variable name (bootcount) and a boot issue happen, I can't find the layer that fails.
I can't understand your problem description, sorry.
So I propose to "customize" the bootcount variable name.
This makes no sense to me.
As it is "unique", I can't chain severals bootcount. That's why I propose an option to customize the bootcount name variable.
But that's the actual situation: there is only one boot count. Please keep in mind that this variable holds the number of boot attepmts since the last power-on that failed to successfully reach a specific "confirmation point" in your application (that, which is considered a complete, successfull boot of the whole system).
For this single task there can be only a single counter, or?
I know that it's a "corner case" and that you could prefer to avoid adding another option, that's why I've proposed this option as a RFC.
I do not see any practical use yet...
Best regards,
Wolfgang Denk
participants (3)
-
Philippe REYNES
-
Philippe Reynes
-
Wolfgang Denk