[U-Boot-Users] Using 'ver' env var
I would like to be able to identify the u-boot version from linux. At first this seemed straight-forward, simply enable CONFIG_VERSION_VARIABLE and use fw_printenv in linux.
This, of course, doesn't work, as 'ver' is not saveenv'ed and fw_printenv just pulls the info from flash (or whereever). Writing a routine in the board init file (last_stage_init) doesn't help, as 'ver' is set after that is run and therefore the stored version string is the old one (if an update occurs).
So this is a 2 part question... What good is the 'ver' env var? It's apparently only useful in u-boot itself and u-boot already has a 'version' command that gives you the same info. And second, I'm sure I'm not the first person to want to see u-boot version in linux, so how have other accomplished this?
Thanks, Zach
In message 5CBE65F7D9232C47861CB09B0954861C66A911@MAIL.infinitychannel.local you wrote:
This, of course, doesn't work, as 'ver' is not saveenv'ed and
What makes you think so? saveenv does not do any filtering to exclude any variable, so of course it gets saved, too.
So this is a 2 part question... What good is the 'ver' env var? It's
To print the U-Boot version without need to reset the board.
apparently only useful in u-boot itself and u-boot already has a 'version' command that gives you the same info. And second, I'm sure I'm not the first person to want to see u-boot version in linux, so how have other accomplished this?
Just read the "ver" variable.
Best regards,
Wolfgang Denk
This, of course, doesn't work, as 'ver' is not saveenv'ed and
What makes you think so? saveenv does not do any filtering to exclude any variable, so of course it gets saved, too.
It does, but only if you explicitly call 'saveenv'... It does not store on it's own.
So this is a 2 part question... What good is the 'ver' env
var? It's
To print the U-Boot version without need to reset the board.
But you can print it using 'version', too... And unless you explictly save it, the 'ver' env var does nothing more for you than the 'version' command, as it Can't be accessed anywhere other then from the u-boot command prompt...
apparently only useful in u-boot itself and u-boot already has a 'version' command that gives you the same info. And
second, I'm sure
I'm not the first person to want to see u-boot version in
linux, so how
have other accomplished this?
Just read the "ver" variable.
If you don't explicitly 'saveenv' there is no 'ver' variable to read from linux... And it can't be good for the flash to force u-boot to save on every boot.
So if I update (from linux for example) 'ver' doesn't get updated unless u-boot is doing a saveenv on every boot...
Thanks, Zach
In message 5CBE65F7D9232C47861CB09B0954861C66A93C@MAIL.infinitychannel.local you wrote:
What makes you think so? saveenv does not do any filtering to exclude any variable, so of course it gets saved, too.
It does, but only if you explicitly call 'saveenv'... It does not store on it's own.
Of course. U-Boot usually does only what you tell it.
To print the U-Boot version without need to reset the board.
But you can print it using 'version', too... And unless you explictly save it, the 'ver' env var does nothing more for you than the 'version' command,
You can use the variable in commands, like for implementing version-dependent things, or test it, or ...
Can't be accessed anywhere other then from the u-boot command prompt...
It is a normal environment variable like any other. It can be used whenever and whererver other variables can get used. This includes saving to flash and reading the flash from Linux.
If you don't explicitly 'saveenv' there is no 'ver' variable to read from linux... And it can't be good for the flash to force u-boot to save on every boot.
It's not needed to save this on every boot. It's perfectly sufficient to save it once after you've installed and booted a new version of U-Boot.
So if I update (from linux for example) 'ver' doesn't get updated unless u-boot is doing a saveenv on every boot...
Not on every boot. It's sufficient to perform this on the first boot.
Best regards,
Wolfgang Denk
If you don't explicitly 'saveenv' there is no 'ver' variable to read from linux... And it can't be good for the flash to force u-boot to save on every boot.
So if I update (from linux for example) 'ver' doesn't get updated unless u-boot is doing a saveenv on every boot...
Maybe saving the environment (with ver) should be forced if "ver" is not the same as the U-Boot version.
Best Regards Ulf Samuelsson
Ulf, I was thinking this already.. I just thought that I was missing something which is why I asked the questions. I'll send a patch to the group for review later.
Zach
If you don't explicitly 'saveenv' there is no 'ver' variable to read from linux... And it can't be good for the flash to force u-boot to save on every boot.
So if I update (from linux for example) 'ver' doesn't get
updated unless
u-boot is doing a saveenv on every boot...
Maybe saving the environment (with ver) should be forced if "ver" is not the same as the U-Boot version.
Best Regards Ulf Samuelsson
diff --git a/common/main.c b/common/main.c index 379695c..429d367 100644 --- a/common/main.c +++ b/common/main.c @@ -326,10 +326,11 @@ void main_loop (void) #endif /* CONFIG_MODEM_SUPPORT */
#ifdef CONFIG_VERSION_VARIABLE + extern char version_string[]; + if (strcmp(getenv("ver"), version_string)) { - extern char version_string[]; - setenv ("ver", version_string); /* set version variable */ + run_command("saveenv", 0); } #endif /* CONFIG_VERSION_VARIABLE */
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Zach Sadecki Sent: Monday, August 13, 2007 4:25 PM To: ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net; wd@denx.de Subject: Re: [U-Boot-Users] Using 'ver' env var
Ulf, I was thinking this already.. I just thought that I was missing something which is why I asked the questions. I'll send a patch to the group for review later.
Zach
If you don't explicitly 'saveenv' there is no 'ver'
variable to read
from linux... And it can't be good for the flash to force u-boot to
save on every
boot.
So if I update (from linux for example) 'ver' doesn't get
updated unless
u-boot is doing a saveenv on every boot...
Maybe saving the environment (with ver) should be forced if "ver" is not the same as the U-Boot version.
Best Regards Ulf Samuelsson
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Let's try this again, with a signed off by line.
Signed-off-by: Zach Sadecki zach.sadecki@ripcode.com
diff --git a/common/main.c b/common/main.c index 379695c..429d367 100644 --- a/common/main.c +++ b/common/main.c @@ -326,10 +326,11 @@ void main_loop (void) #endif /* CONFIG_MODEM_SUPPORT */
#ifdef CONFIG_VERSION_VARIABLE + extern char version_string[]; + if (strcmp(getenv("ver"), version_string)) { - extern char version_string[]; - setenv ("ver", version_string); /* set version variable*/ + run_command("saveenv", 0); } #endif /* CONFIG_VERSION_VARIABLE */
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Zach Sadecki Sent: Monday, August 13, 2007 4:25 PM To: ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net; wd@denx.de Subject: Re: [U-Boot-Users] Using 'ver' env var
Ulf, I was thinking this already.. I just thought that I was missing something which is why I asked the questions. I'll send a patch to the group for review later.
Zach
If you don't explicitly 'saveenv' there is no 'ver'
variable to read
from linux... And it can't be good for the flash to force u-boot to
save on every
boot.
So if I update (from linux for example) 'ver' doesn't get
updated unless
u-boot is doing a saveenv on every boot...
Maybe saving the environment (with ver) should be forced if "ver" is not the same as the U-Boot version.
Best Regards Ulf Samuelsson
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 5CBE65F7D9232C47861CB09B0954861C2FD901@MAIL.infinitychannel.local you wrote:
Let's try this again, with a signed off by line.
Signed-off-by: Zach Sadecki zach.sadecki@ripcode.com
Still NAK for the known reasons.
And please don't top post / full quote.
Best regards,
Wolfgang Denk
In message 5CBE65F7D9232C47861CB09B0954861C66A986@MAIL.infinitychannel.local you wrote:
diff --git a/common/main.c b/common/main.c index 379695c..429d367 100644 --- a/common/main.c +++ b/common/main.c @@ -326,10 +326,11 @@ void main_loop (void) #endif /* CONFIG_MODEM_SUPPORT */
#ifdef CONFIG_VERSION_VARIABLE
extern char version_string[];if (strcmp(getenv("ver"), version_string)) {
extern char version_string[];setenv ("ver", version_string); /* set version variable*/
run_command("saveenv", 0); }#endif /* CONFIG_VERSION_VARIABLE */
As mentioned before, I reject this patch.
U-Boot is not supposed to do such things like writing to the flash "automagically".
If you need this function, please implement it as a script.
[And BTW: is there a special reason why you did not call do_saveenv() directly?]
Best regards,
Wolfgang Denk
In message 5CBE65F7D9232C47861CB09B0954861C66A961@MAIL.infinitychannel.local you wrote:
I was thinking this already.. I just thought that I was missing something which is why I asked the questions. I'll send a patch to the group for review later.
Don't bother to do that. I will not accept patches that automatically save the environment. U-Boot shall only act on user's request and never to any magical things behind my back.
If you want this function, it can be implemented using U-Boot's scripting capabilities, so there is no need for a patch.
Thanks.
Best regards,
Wolfgang Denk
In message 5CBE65F7D9232C47861CB09B0954861C66A961@MAIL.infinitychannel.local you wrote:
I was thinking this already.. I just thought that I was missing something which is why I asked the questions. I'll send a patch to the group for review later.
Don't bother to do that. I will not accept patches that automatically save the environment. U-Boot shall only act on user's request and never to any magical things behind my back.
If you want this function, it can be implemented using U-Boot's scripting capabilities, so there is no need for a patch.
You assume that there is no users request, but there is. If you, from Linux, are upgrading the U-Boot, you could *if you wanted to*, interpret this as an indirect request to update the "ver" variable.
This should only happen right after boot and before the user has any chance to update anything else, so that only the "ver" variable is updated by this save.
The drawback of this is that a user will not be able to have a ver variable which differs from the version. As soon as a user does
setenv ver <whatever>
U-Boot will revert that at the next change.
---------------- If U-Boot supported a read only environment area (generated at compile time) then there would be no need for doing things behind your back.
If that is not acceptable, then the only way forward I see is that Linux writes a new version of the bootcmd to the environment so that the request is made explicit.
This requires that the user can write the current version to "ver" from a command.
Thanks.
Best regards,
Wolfgang Denk
--
Best Regards Ulf Samuelsson
In message 007401c7de59$7124a0f0$dcc4af0a@atmel.com you wrote:
This requires that the user can write the current version to "ver" from a command.
This will not work. No matter what the user sets "ver" to, it ill be overwritten when U-Boot boots.
Best regards,
Wolfgang Denk
tis 2007-08-14 klockan 15:39 +0200 skrev Wolfgang Denk:
In message 007401c7de59$7124a0f0$dcc4af0a@atmel.com you wrote:
This requires that the user can write the current version to "ver" from a command.
This will not work. No matter what the user sets "ver" to, it ill be overwritten when U-Boot boots.
If such a command exist, You can read the version from your bootcmd, and send it as a parameter.
Yet another alternative:
A command "sync_version" 1) checks if "ver" and 'version' are identical 2) sets "ver" to version, if not the same. 3) saves the environment
With this, the user can select if/when to sync
Ideally this should be in a script "reboot_cmd" which gets executed at every reboot before anything else is executed.
Is there such a facility?
Best regards,
Wolfgang Denk
In message 1187102431.13869.7.camel@elrond.sweden.atmel.com you wrote:
Ideally this should be in a script "reboot_cmd" which gets executed at every reboot before anything else is executed.
I really don't understand why you make all this so complicated.
I think we agree that all that needs to be done is running a single "saveenv" command once after installation of a new U-Boot image (which is supposed to never to happen in the field anyway).
So deine yoiur "bootcmd" to include something like a "run once" command, and define "once" as a "harmless" operation, like this:
=> setenv once version
Then, when you update U-Boot (under Linux), also change the definition of "once", equivalent to this:
=> setenv once "saveenv;setenv once version"
The next time U-Boot boots it will run this variable, will save the environment and then reset the variable to the effective no-op command.
Voila...
Best regards,
Wolfgang Denk
tis 2007-08-14 klockan 17:23 +0200 skrev Wolfgang Denk:
In message 1187102431.13869.7.camel@elrond.sweden.atmel.com you wrote:
Ideally this should be in a script "reboot_cmd" which gets executed at every reboot before anything else is executed.
I really don't understand why you make all this so complicated.
I think we agree that all that needs to be done is running a single "saveenv" command once after installation of a new U-Boot image (which is supposed to never to happen in the field anyway).
The thread started with trying to solve the problem with U-Boot beeing downloaded from Linux and then written to the flash.
There is NOONE talking to the console after the reboot, and the assumption is that Linux has not updated the environment.
Based on this: how do you sync the ver and the U-Boot version?
All your proposals are failing, since you assume that there is a gremlin somehwere which starts toggling RXD.
BR Ulf Samuelsson
The thread started with trying to solve the problem with U-Boot beeing downloaded from Linux and then written to the flash.
There is NOONE talking to the console after the reboot, and the assumption is that Linux has not updated the environment.
Based on this: how do you sync the ver and the U-Boot version?
There is nothing stoppint you from changing the bootcmd envrionment variable from linux after a new version of u-boot isinstalled, so u-boot will run a saveenv on the next reboot.
fw_setenv works pretty good from linux.
In message 1187115508.13869.19.camel@elrond.sweden.atmel.com you wrote:
The thread started with trying to solve the problem with U-Boot beeing downloaded from Linux and then written to the flash.
ACK.
There is NOONE talking to the console after the reboot, and the assumption is that Linux has not updated the environment.
Right. Neither am I. You know that there are tools to write the environment from Linux?
Based on this: how do you sync the ver and the U-Boot version?
Just as posted before. The conversion from the U-Boot setenv command to a fw_setenv shell command in Linux is left out as an exercise for the reader.
All your proposals are failing, since you assume that there is a gremlin somehwere which starts toggling RXD.
It seems whatever I write, how simple I may make it, you always find ways to misunderstand or misinterpret me.
I provided a solution. A known to be working one, btw. I hope Zach was able to follow my example. If you can't I can't help it.
Over and out.
Wolfgang Denk
I provided a solution. A known to be working one, btw. I hope Zach was able to follow my example. If you can't I can't help it.
Wolfgang, I followed. It looks like you have an interesting solution for this. Utilizing a 'run once on next boot' type variable has some other interesting possible uses.
This is really what I was trying to get at. Just what solutions were available and others had used, as I was sure I wasn't the first to do/need this.
Thanks, Zach
participants (4)
-
Rune Torgersen -
Ulf Samuelsson -
Wolfgang Denk -
Zach Sadecki