[U-Boot] A command to discard saved environments?
Hi.
I am looking for a command that discards the saved environments, and takes me back to the "*** Warning - bad CRC, using default environment" state.
In my case, the environment data is saved at sector 0x400 of the MMC device on my board.
So, I can just do
mmc erase 400 10
But, beforehand, I need to know
CONFIG_ENV_IS_IN_MMC CONFIG_ENV_OFFSET 0x80000
in order to confirm if the above command is doing the right thing. (If I make a mistake in calculating the offset value, other data would be damaged.)
Is there a nice command to do that?
On Wed, Aug 3, 2016 at 12:31 AM, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi.
I am looking for a command that discards the saved environments,
Does this command help?
=> env default -f -a
Regards,
Fabio Estevam
Hi Fabio,
2016-08-03 12:34 GMT+09:00 Fabio Estevam festevam@gmail.com:
On Wed, Aug 3, 2016 at 12:31 AM, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi.
I am looking for a command that discards the saved environments,
Does this command help?
=> env default -f -a
I know this command, but it is the manupulation of working RAM in U-Boot.
If I reset my board, it will load the saved environment again.
I want the environment data in a non-volatile device to go away.
On Wed, Aug 03, 2016 at 12:49:09PM +0900, Masahiro Yamada wrote:
Hi Fabio,
2016-08-03 12:34 GMT+09:00 Fabio Estevam festevam@gmail.com:
On Wed, Aug 3, 2016 at 12:31 AM, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi.
I am looking for a command that discards the saved environments,
Does this command help?
=> env default -f -a
I know this command, but it is the manupulation of working RAM in U-Boot.
If I reset my board, it will load the saved environment again.
I want the environment data in a non-volatile device to go away.
I think I'm missing something. As Fabio said env default -f -a will reset it. And then you can saveenv it. If you want to restrict certain parts of the environment check out the stuff around *ENV_FLAGS* and of course if you just want to never have persistent environment, change to ENV_IS_NOWHERE. We don't have a way to tell U-Boot to ignore the valid environment that it did find.
I know my non-volatile copy of the environment is in NOR flash so I use the command
protect all off;erase <saved env address> +1
But, of course this is specific to NOR flash.
I'm not aware of a way to do this in the general case, independent of NV environment storage media and redundancy.
I'd be supportive of having a way to do this.
Jim
On 08/02/2016 08:31 PM, Masahiro Yamada wrote:
Hi.
I am looking for a command that discards the saved environments, and takes me back to the "*** Warning - bad CRC, using default environment" state.
In my case, the environment data is saved at sector 0x400 of the MMC device on my board.
So, I can just do
mmc erase 400 10
But, beforehand, I need to know
CONFIG_ENV_IS_IN_MMC CONFIG_ENV_OFFSET 0x80000
in order to confirm if the above command is doing the right thing. (If I make a mistake in calculating the offset value, other data would be damaged.)
Is there a nice command to do that?
Dear James,
In message fcff97bb-d146-fc77-28e4-050cac0922f4@gmail.com you wrote:
I know my non-volatile copy of the environment is in NOR flash so I use the command
protect all off;erase <saved env address> +1
But, of course this is specific to NOR flash.
I'm not aware of a way to do this in the general case, independent of NV environment storage media and redundancy.
The idea applies to all kinds of persistent storage: just overwrite a few (4 or more) bytes at the beginning of each copy of the persistent envrionment.
In your case, you could save the "erase" by overwriting the first 4 bytes (where the CRC32 checksum is stored) with 0xFFFFFFFF.
I'd be supportive of having a way to do this.
No, I don't think we want to support this. The persistent copy of the environment is a precious resource, and I cannot think of a regular use case to invalidate this. If you do, the result is that you will use the default settings at next boot - and the samve effect can be acchieved by using "env reset" + "env save" as already recommended. [The only difference is that you will not see the "invalid CRC, using the default env" warning then, but I consider this a pro, not a con.]
Best regards,
Wolfgang Denk
Dear Wolfgang,
On 08/03/2016 12:59 PM, Wolfgang Denk wrote:
Dear James,
In message fcff97bb-d146-fc77-28e4-050cac0922f4@gmail.com you wrote:
I know my non-volatile copy of the environment is in NOR flash so I use the command
protect all off;erase <saved env address> +1
But, of course this is specific to NOR flash.
I'm not aware of a way to do this in the general case, independent of NV environment storage media and redundancy.
The idea applies to all kinds of persistent storage: just overwrite a few (4 or more) bytes at the beginning of each copy of the persistent envrionment.
In your case, you could save the "erase" by overwriting the first 4 bytes (where the CRC32 checksum is stored) with 0xFFFFFFFF.
In the case of my NOR flash storage, telling erase to do one byte actually causes the erasure of an entire flash sector, which we've reserved for the NV environment. You are of course correct that overwriting the CRC will have the same operational effect.
In my shop, time is not critical, whereas simplicity of commands is valued by those I have to instruct to get this sort of operation done.
It's a rare occurrence that we need to do this, we don't use this sort of operation as a normal part of doing business.
I'd be supportive of having a way to do this.
No, I don't think we want to support this. The persistent copy of the environment is a precious resource, and I cannot think of a regular use case to invalidate this. If you do, the result is that you will use the default settings at next boot - and the samve effect can be acchieved by using "env reset" + "env save" as already recommended. [The only difference is that you will not see the "invalid CRC, using the default env" warning then, but I consider this a pro, not a con.]
Thank you for this perspective. I often feel a bit isolated in my way of doing things and I find it valuable to read things like this.
I agree that there is not a regular use for an operation of this sort.
During development and debug, I will occasionally need to restore a particular system to the physical state it would be in had we just received it from our contract manufacturer, which would include a blank area in NOR flash where the U-Boot environment is kept. This is done usually to "prove" that processes will work on those systems from the CM when production starts.
Up to now, I've used the erase command to do this and I will continue to do things this way. I guess I've been at this long enough that the rare times I need to erase this area of flash has become noticeable as a pattern.
Again, thank you for your reply.
Regards, Jim
Best regards,
Wolfgang Denk
Dear James,
In message d18f75c7-388b-b607-ed70-64a250320d5a@gmail.com you wrote:
In your case, you could save the "erase" by overwriting the first 4 bytes (where the CRC32 checksum is stored) with 0xFFFFFFFF.
Wrong. I meant writing 0x00000000 - as you can always write that, setting any remaining 1 bits to 0 which does not require an erase of the sector.
In the case of my NOR flash storage, telling erase to do one byte actually causes the erasure of an entire flash sector, which we've reserved for the NV environment. You are of course correct that overwriting the CRC will have the same operational effect.
...and as the next "saveenv" will start with an erase, writing 0 to the CRC 32 field saves you one erase cycle on that sector.
I know, this is nitpicking. Soryy.
It's a rare occurrence that we need to do this, we don't use this sort of operation as a normal part of doing business.
Agreed. This should never be part of regular operation.
Best regards,
Wolfgang Denk
2016-08-04 14:40 GMT+09:00 Wolfgang Denk wd@denx.de:
Dear James,
In message d18f75c7-388b-b607-ed70-64a250320d5a@gmail.com you wrote:
In your case, you could save the "erase" by overwriting the first 4 bytes (where the CRC32 checksum is stored) with 0xFFFFFFFF.
Wrong. I meant writing 0x00000000 - as you can always write that, setting any remaining 1 bits to 0 which does not require an erase of the sector.
In the case of my NOR flash storage, telling erase to do one byte actually causes the erasure of an entire flash sector, which we've reserved for the NV environment. You are of course correct that overwriting the CRC will have the same operational effect.
...and as the next "saveenv" will start with an erase, writing 0 to the CRC 32 field saves you one erase cycle on that sector.
I know, this is nitpicking. Soryy.
It's a rare occurrence that we need to do this, we don't use this sort of operation as a normal part of doing business.
Agreed. This should never be part of regular operation.
Best regards,
Wolfgang Denk
Sorry for my late reply.
I was in the conflict between my coworkers from different schools.
One always wants to save his preference in the environments in a non-volatile device.
Another wants to load "uEnv.txt" to adjust environments, so the environments from a non-volatile device are just annoying for him. He just want to clean the saved environments away, and makes the sectors for environments to the initial state.
I was searching a way to make everyone happy. As Tom pointed out, the latter can use CONFIG_ENV_IS_NOWHERE. Thanks!
Dear Masahiro,
In message CAK7LNATygXm=Z42SYYEXW9NJLYkFMa1gPQ8PB2_8Y4DUWYZOaQ@mail.gmail.com you wrote:
Another wants to load "uEnv.txt" to adjust environments, so the environments from a non-volatile device are just annoying for him.
This is largely a matter of taste, but I consider it as a perfectly valid wish.
He just want to clean the saved environments away, and makes the sectors for environments to the initial state.
This, on the other hand, is not reasonable.
If he does not like the saved environment, he is free to use the regular "env" commands to define one he likes: "env default -f -a" or "env default -f var ..." or "env delete -f var ..." followed by a "env save" provide a lot of options.
There should be no need for manipulating stored data structures in obscure ways.
One could discuss if an expension as "env delete -f -a" makes sense...
As Tom pointed out, the latter can use CONFIG_ENV_IS_NOWHERE.
Of course. TIMTOWTDI...
Best regards,
Wolfgang Denk
participants (5)
-
Fabio Estevam -
James Chargin -
Masahiro Yamada -
Tom Rini -
Wolfgang Denk