[U-Boot-Users] dtb in env sector - was: (Try 2) Please pull ...

Wolfgang Denk
2007-04-03T15:24:55Z

In message <461262CD.7000309@smiths-aerospace.com> you wrote:
>
> Actually, it is much worse than that: currently when you do a "saveenv"
> it will wipe out the fdt blob because it doesn't know that the blob is
> in the same sector.

No, it doesn't; see "common/env_flash.c":

#if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE)
...
/* copy old contents to temporary buffer */
...
/* copy current environment to temporary buffer */
...
flash_sect_protect(OFF,...);
...
flash_sect_erase();
...
flash_write();
...

> I'm thinking that we want to store the blob immediately after the env
> variable storage _reserved area_ as a #define option (as a new #define
> option? part of the CONFIG_OF_LIBFDT define?) and enhance the env

You mean at CFG_ENV_ADDR+CFG_ENV_SIZE ?

> save/restore to do the blob too. This would get us the redundancy and
> we can cover it with a new (preferred?) or existing env CRC (not good?).

Not good.

> > yes, but it would be handy to just say "use the dtb in my spare
> > env space", especially if you use rendundant env. so the right
> > one is selected.

I consider this bad design. The environment is one thing, and the dtb
is a different thing. You are mixing two unrelated things here, which
causes interdependencies that can cause a lot of trouble.

I agree it can be done, but I don't recommend to do it.

If you do it, it will remain board-specific. ATM I don't intend to
accept this for the common code.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Out of register space (ugh)"
- vi