> In message <[EMAIL PROTECTED]> you wrote: >> >> Commit c0559be371b2a64b1a817088c3308688e2182f93 introduces a bug in >> the environment setting storage in U-boot-1.3.3-rc3. >> Settings are retrieved from dataflash when only settings in RAM are >> valid, resulting in corrupt environment settings, failing printenv >> command, and >> duplicate variables. >> >> This patch fixes this by always using the RAM area when it is created >> and initialized. (Matches more the behavior as it was prior to this >> particular commit.) > > Sorry, but this patch makes littles sense to me. > >> See attached (Sorry, my mailer does not handle inline-patches properly) > > Chose another one? Or rather use "git-send-email" directly? > > - /* if relocated to RAM */ > - if (gd->flags & GD_FLG_RELOC) > + /* if relocated to RAM, OR if the environment in Malloc-ed RAM is valid */ > + if ((gd->flags & GD_FLG_RELOC) || (gd->env_valid)) > > Let's keep in mind that the normal logic of the U-Boot startup > sequence is like this: > > * U-Boot boots and initializes the RAM > * U-Boot relocates itself into RAM, sets GD_FLG_RELOC and continues > running from RAM > * U-Boot continues with the initialization, for xample by setting up > the malloc arena, loading the working copy of the environment into > RAM (after which it set's gd->env_valid), etc. >
When you have a dataflash, this is not the normal behaviour. A typical behaviour of an AT91 would be: 1) BootROM copies initial bootloader (at91bootstrap/dataflashboot) to internal SRAM 2) BootROM jumps to start of initial bootloader 3) Initial bootloader does low-level init (including configuring the SDRAM controller) 4) Initial bootloader copies U-Boot from dataflash to SDRAM 5) Initial bootloader jumps to U-Boot 6) U-Boot needs to skip low-level init > So the relocation to RAM always preceeds any use of malloc() and the > setting of gd->env_valid. Or, put the other way round, we always set > GD_FLG_RELOC long before gd->env_valid get's set. > > Thus your change above is just redundant. > > > Now, if your board does not perform proper relocation for some > reason, it should still set GD_FLG_RELOC at the appropriate place, i. > e. as soon as U-Boot is ready for and starts running out of RAM. > > Best regards, > > Wolfgang Denk > Best Regards Ulf Samuelsson ------------------------------------------------------------------------- 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
