[U-Boot] [RFD] store env size in env area (+ cookie + len)

[Wolfgang Denk]

Dear Frans Meulenbroeks,

In message <AANLkTi=+67z34H+R+tNab9MOPa55oLoRW0Vvs9BEEbf+ at 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: wd at denx.de
The more we disagree, the more chance there is that at least  one  of
us is right.