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

[Joakim Tjernlund]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de] 
> Sent: den 3 april 2007 17:25
> To: Jerry Van Baren
> Cc: joakim.tjernlund at transmode.se; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] dtb in env sector - was: (Try 2) 
> Please pull ... 
> 
> 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.

They are not so different or unrelated, but I don't propose to integrate
them. I think of it as 2 things that needs storage and they should be able
to share an erase block. Redundant env. aside, these two items don't
need to know about oneother. Adding redundant env. makes it a little
bit harder but should be solvable.

I see 2 benefits with this shared storage:
1) less flash space is wasted, 1 (or 2 if you want redundancy)
   erase blocks can be saved.

2) existing boards in can add a dtb without repartioning its
   flash space, you can even upgrade eq. in the field.


 Regards
         Jocke