[U-Boot] [RFD] store env size in env area (+ cookie + len)
I've seen a few times that people get a u-boot with their board and want to use fw_setenv under linux to tweak with environment variables. This requires them to come up with an fw-env.config (if not provided). One of the things that I've seen, that some people have trouble with it is obtaining the proper size of the environment area to be stuffed in that file.
This is something that could be resolved quite easily by adding the size of the environment area to the header preceding the environment (which now contains a checksum and, in case of redundant areas, a flag byte)
Pro: no more need to give sizes in fw-env.config Con: uses a 2-4 more bytes (personally I'd say size is 4 bytes just to be safe) Con: not compatible with current env layout so (without precautions) a new u-boot cannot use the old env and vice versa.
If compatibility is deemed important, we could extend the header also with a magic cookie and a version number. If absent it is an old style env, if present it is a new style env. Version number then can also be used should there be future changes in the env layout. (if compatibility is not deemed important of course this is not needed).
Btw thinking about cookies: if the env were to have a cookie in either the header or e.g. as first env var, fw_setenv would not even need fw-env.config at all. It could just seek in /dev/mtd (I'm assuming env in flash here) for the cookie. This seeking should not take too much time if we can assume (or have a config var) a certain alignment (e.g. on flash page size). After finding the cookie of course still a crc check would be done to validate the area.
If desired I can do some implementation work for this and submit a patch, but before investing time in it I would like to find out if there is actual interest in this and if this is considered useful.
Summarizing the questions: - is it desirable to have the env length added to the env header - is it desirable to have a cookie added to the env header - is it desirable to have a version number added to the env header
Best regards, Frans.
PS: if we are going to touch the env header, I would suggest to always have the redundant flag in the header even if there is only one environment. It will probably make the code to load the env a little bit simpler).
Dear Frans Meulenbroeks,
Pro: no more need to give sizes in fw-env.config Con: uses a 2-4 more bytes (personally I'd say size is 4 bytes just to be safe)
That's less than any variable takes in the env, so no problem.
Con: not compatible with current env layout so (without precautions) a new u-boot cannot use the old env and vice versa.
When we put a new u-Boot on a hardware, we erase the environment anyway. But that might affect other systems that rely on storing vital product data like MAC addresses or Serialnumbers in the environment.
If compatibility is deemed important, we could extend the header also with a magic cookie and a version number. If absent it is an old style env, if present it is a new style env. Version number then can also be used should there be future changes in the env layout. (if compatibility is not deemed important of course this is not needed).
See above, might be needed. Should be an option. With the new hashed environment it should not be complicated to do.
Summarizing the questions:
- is it desirable to have the env length added to the env header
Yes
- is it desirable to have a cookie added to the env header
Yes
- is it desirable to have a version number added to the env header
Yes. If the Version number mismatches, the default env should be used (config option)
PS: if we are going to touch the env header, I would suggest to always have the redundant flag in the header even if there is only one environment. It will probably make the code to load the env a little bit simpler).
Yes. The env header should NOT have any #ifdefs anymore. Check the new environment handling by Wolfgang, your work should be based on that, I suggest.
Reinhard
Am 12.08.2010 08:43, schrieb Frans Meulenbroeks:
I've seen a few times that people get a u-boot with their board and want to use fw_setenv under linux to tweak with environment variables. This requires them to come up with an fw-env.config (if not provided). One of the things that I've seen, that some people have trouble with it is obtaining the proper size of the environment area to be stuffed in that file.
Con: not compatible with current env layout so (without precautions) a new u-boot cannot use the old env and vice versa.
I didn't dig into the code but I don't think it is good idea to change the environment format. There may be (or at least there is for my board) code that scans the environment which is not derived from u-boot code. A new header entry would break this code.
Why not store the size of the environment sector as env variable? The size should be only needed for storing the environment and not for loading (as it is terminated by a '\0'). So we could load the environment, check for "env_size" and if its not there take the value from fw_env.config
Matthias
On Thursday 12 August 2010, 09:27:31 you wrote:
Why not store the size of the environment sector as env variable? The size should be only needed for storing the environment and not for loading (as it is terminated by a '\0'). So we could load the environment, check for "env_size" and if its not there take the value from fw_env.config
Another possibility is to use an own mtd partition for env storage. This way you shouldn't need to know any size or offset at all.
Best regards, Alexander
Dear Alexander Stein,
In message 201008121007.20433.alexander.stein@systec-electronic.com you wrote:
On Thursday 12 August 2010, 09:27:31 you wrote:
Why not store the size of the environment sector as env variable? The size should be only needed for storing the environment and not for loading (as it is terminated by a '\0'). So we could load the environment, check for "env_size" and if its not there take the value from fw_env.config
Another possibility is to use an own mtd partition for env storage. This way you shouldn't need to know any size or offset at all.
The size of the environment is typically smaller than the sector size and thus than the MTD partition size.
Best regards,
Wolfgang Denk
Dear Frans Meulenbroeks,
In message AANLkTi=+67z34H+R+tNab9MOPa55oLoRW0Vvs9BEEbf+@mail.gmail.com you wrote:
I've seen a few times that people get a u-boot with their board and want to use fw_setenv under linux to tweak with environment variables. This requires them to come up with an fw-env.config (if not provided). One of the things that I've seen, that some people have trouble with it is obtaining the proper size of the environment area to be stuffed in that file.
This should be no problem, as a short look at the board config header file should be enough to provide all details you need.
This is something that could be resolved quite easily by adding the size of the environment area to the header preceding the environment (which now contains a checksum and, in case of redundant areas, a flag byte)
Pro: no more need to give sizes in fw-env.config Con: uses a 2-4 more bytes (personally I'd say size is 4 bytes just to be safe) Con: not compatible with current env layout so (without precautions) a new u-boot cannot use the old env and vice versa.
The incompatibility with the existing code IMHO is a killing point for such a suggestion.
If compatibility is deemed important, we could extend the header also with a magic cookie and a version number. If absent it is an old style env, if present it is a new style env. Version number then can also be used should there be future changes in the env layout. (if compatibility is not deemed important of course this is not needed).
I think you make this unessesarily complicated. Why not just use an envrionment variable ("env_size") that gets automatically added, similarly to what we do with "vers" ?
This allows to make it easily optional, and does not create any incompatibility issues.
Btw thinking about cookies: if the env were to have a cookie in either the header or e.g. as first env var, fw_setenv would not even need fw-env.config at all. It could just seek in /dev/mtd (I'm assuming env in flash here) for the cookie. This seeking should not take too much time if we can assume (or have a config var) a certain alignment (e.g. on flash page size). After finding the cookie of course still a crc check would be done to validate the area.
Heh. Assume the environment is stored in a 64 GB NAND flash device. Guess how long the seeking might take, and how many false positives you might find.
Summarizing the questions:
- is it desirable to have the env length added to the env header
- is it desirable to have a cookie added to the env header
- is it desirable to have a version number added to the env header
NAK to all of these, because of the incompatibility issues.
PS: if we are going to touch the env header, I would suggest to always have the redundant flag in the header even if there is only one environment. It will probably make the code to load the env a little bit simpler).
I have something in mind which eliminates the need for this flag alltogether, including the need to always unlock and write to both copies; it should also allow to add more copies so you could have more than 2 generations of the environment. I have an implementation in mind, but I want to get the new environment code get into mainline first.
Best regards,
Wolfgang Denk
participants (5)
-
Alexander Stein -
Frans Meulenbroeks -
Matthias Weißer -
Reinhard Meyer -
Wolfgang Denk