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@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