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

[Wolfgang Denk]

In message <461262CD.7000309 at 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