[U-Boot-Users] 1.3.3-rc3 - release status

[Joakim Tjernlund]

On Tue, 2008-05-06 at 13:16 +0200, Remy Bohmer wrote:
> Hello All,
> 
> I have found the root-cause of these problems:
> 
> >  > * The environment variables work strange. When the environment section
> >  > in dataflash has been erased (fresh install), the first boot will
> >  > produce garbage when the 'printenv'  command is executed. (It even
> >  > reports that the size of the environment is bigger than possible.)
> >  > * the 'saveenv' command corrects this, but I can store many variables
> >  > with the same name in the environment, I can, for example, enter 10
> >  > 'ipaddr' variables, if I want to, at the same time. 'printenv' will
> >  > list them all, but only the first one is used.
> 
> They appear to be caused by this git-commit
> =================================================
> c0559be371b2a64b1a817088c3308688e2182f93 is first bad commit
> commit c0559be371b2a64b1a817088c3308688e2182f93
> Author: Joakim Tjernlund <joakim.tjernlund at transmode.se>
> Date:   Mon Apr 14 23:01:50 2008 +0200
> 
>     Change env_get_char from a global function ptr to a function.
> 
>     This avoids an early global data reference.
> 
>     Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> =================================================
> 
> _Without_ this commit, the environment storage works properly.
> 
> So, this is what happens: (we assume an erased environment section in
> dataflash)
> In the old situation the malloc-ed memory area was used for all
> environment read/writes, once it was created. (And saveenv updates the
> flash)
> With this commit the environment is set to be valid after doing a
> memory allocation and fill it with the default values.
> However, this flag (gd->env_valid) is also used to determine if the
> environment must be read from memory or directly from flash by
> env_get_char().
> The data flash is not updated before/after the flag is set to valid,
> so every new read will be done from the non-initialised data flash,
> and thus resulting in bogus data.
> This causes both problems above.
> 
> So, Wolfgang, probably it is better to undo this commit for now, until
> it is fixed? It is a bug in 1.3.3-rc3...

Hmm, if reverted it won't get fixed.
What happens if you modify to this:
 if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))

   Jocke
> 
> I believe that this bug will also show up in the at91sam9260-ek tree.
> I bet Stelian will also run into these problems when he uses the
> latest git version... :-)
> 
> 
> Kind Regards,
> 
> Remy
>