[U-Boot-Users] [PATCH]: Fix for bug: U-boot environment corruptby reading uninitialized flash memory instead of RAM.

[Wolfgang Denk]

In message <004901c8b3a6$00a670b0$030514ac at atmel.com> you wrote:
> 
> > 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.

Well, it is still the normal behaviour, except that booting from
dataflash works differently, i. e. it is a special case.

> 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

Yes, I am aware of this sequence. I wanted to explain that it is the
responsibility of the running code to make sure that GD_FLG_RELOC is
set before any of the "real" U-Boot code gets executed. It seems, this
is missing in the case described here.

> 6) U-Boot needs to skip low-level init

It may skip the normal low-level init sequence, but it still  has  to
set up the same environment that normally is set up by that code.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Well I don't see why I have to make one man  miserable  when  I  can
make so many men happy."              - Ellyn Mustard, about marriage