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