[U-Boot] Most ARM CPU's have buggy clear_bss?

[Wolfgang Denk]

Dear Darius Augulis,

In message <4CC80609.6040003 at gmail.com> you wrote:
>
> > Maybe, maybe not. The preloader is usually very simple and may not be
> > clever enough to adjust the oad address to the avalable memory and
> > such; also, U-Boot features like protected RAM, shared video buffers
> > or log buffers may also require to dynamically adjust the final load
> > address. In such cases relocation will be needed.
> 
> I confess I didn't understant you - why relocation could be needed in 
> case of nand or other preloader? I have been thinking that main and 
> single task of preloader is to copy uboot image from flash memory to 
> main memory (SDRAM) where it's linked to (TEXT_BASE). Why one may need 

Yes, but this may or may not be the final position.

> to relocate it twice (and where) ? IMO since uboot image is copied to 
> TEXT_BASE it can run normaly, without fixing any address or relocating 
> somewhere? It's enough to have dummy loader which initializes SDRAM and 
> copies few pages from nand to SDRAM, isn't it? Why should it be more clever?

Assume we use the "protected RAM" feature, i. e. we reserve memory at
the top of RAM.  The user does a "setenv pram 0x400000;saveenv" to
reserve 4 MB, then does a reboot. So next time the system boots U-Boot
must respect the new setting, i. e. it has to be loaded 4 MB below top
of RAM.  Then user decides he needs 8 MB instead...

> Also I've been thinking that relocation is needed only when booting 
> directly from NOR flash, to have possibility to erase and program flash 
> memory. Could you please point me where I'm wrong?

Relocation is needed to allow to put the U-Boot image to any suitable
location in RAM, which is NOT known at compile time, as it may depend
on the actual memory size (assume systems that come with different
configurations, or where the user can plug in additional or bigger
memory modules), and on a number of memory reservations that depende
for example on environment variable settings.

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
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
                                              - Franklin D. Roosevelt