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

[Remy Bohmer]

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...

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