[U-Boot-Users] BSS initialization wrong on ARM??

[Paul Ruhland]

To add what I discovered while doing the lpd7a40x port (the first part is a 
recap of whats been discussed in this thread already...I leave it in for 
context).

---
It seems the new compiler (gcc >= 3.3.3) does not place global variables in 
the text/data segment if they are initialized to zero.  Instead it places 
them in the bss segment...assuming, I suppose, it will be initialized to zero 
there.  So, 'timer_load_val' is placed in the bss segment...and as things 
turned out, its the first entry right at '__bss_start'.

Here is the bug...all of the 'start.S' files for arm9x processors begin 
clearing the bss on relocation starting 4 bytes past the actual start of the 
bss segment.  So, in this case, 'timer_load_val' is never initialized to zero 
but is instead 0xffffffff after relocation.  That value is due to the 
relocate code (copy_loop) actually copying 4 bytes past the end of text/data 
(which is just erased flash).   I verified this by viewing the ram value at 
__bss_start (timer_load_val) before and after the copy_loop executed.

So there are really two bugs in the relocate code.
---

The copy_loop is solved by using a 'blt' instead of a 'ble' for the loop 
compare.   The 'start.S' in 'cpu/lh7a40x/' has both fixes incorporated.


On Tuesday 15 June 2004 15:27, Wolfgang Denk wrote:
> Dear Andrea,
>
> in message <001c01c452af$214b8b90$1800a8c0 at llandrews> you wrote:
> > > Actually _all_ ARM  systems  are  affected  -  except  s3c44b0  which
> > > doesn't clear BSS at all?
> > >
> > >
> > > Andrea, am I missing something, or is the clear_bss code  missing  in
> > > your port for the s3c44b0 processor?
> >
> > You're right Wolfgang: the clear_bss code is missing in my port for the
> > s3c44b0 port. This because I've used as reference another "ARM family"
> > code
>
> ...
>
> > I will soon fix this problem, probably when we will port the newer
> > version of u-boot to our platform.
>
> maybe we can use this as oppotrtunity to check if the s3c44b0  really
> needs a separate CPU directory; IMHO it could be merged ...
>
> Best regards,
>
> Wolfgang Denk