Dear Frans Meulenbroeks,
In message <aanlkti=+67z34h+r+tnab9mopa55olorw0vvs9bee...@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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The more we disagree, the more chance there is that at least one of
us is right.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
