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

[Reinhard Meyer]

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