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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > ================================================= > > _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 > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
