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

[David Farrell <davidjf2001@yahoo.com>]

Paul, Thanks for the response.  I did read your post prior to my post, I agree with you I seem to be wrong. What a difference one leading underscore makes. I am trying to chase down a problem where I can run from ram but not from rom.  I'm new to U-Boot and still in the process of tracing through how everything happens.
Thanks again,
David.

Paul Ruhland <pruhland@rochester.rr.com> wrote:
On Friday 20 August 2004 11:31, David Farrell wrote:
> Back in June a email was posted commenting that bss init had a non-zero
> offset. Correct me if I am wrong, but in arm920t/start.S there is a word
> defined at the bss_start: which is the address of bss start. This word
> offsets the location of real _bss stuff by 4 bytes. The code in cvs looks
> like it was changed to make the offset 0, this should be put back. David.

I believe you are wrong.

'__bss_start' is defined in the linker script to be the first word (4 bytes) 
aligned location after or equal to the end of the u_boot_cmd section...or in 
other words immediately after u-boot. ' _bss_start' is defined in start.S 
and is located immediately after the exception vectors along with _TEXT_BASE, 
_armboot_start, _bss_end, and the IRQ/FIQ_STACK_START if irqs are used 
(check out System.map).

The word at '_bss_start' contains the address of the start of bss, 
'__bss_start'.

And, at least for the arm port I'm using, I'm willing to bet the first word in 
the bss is 'timer_load_val' from interrupts.c (check out System.map). With 
the word offset previously in 'clear_bss' the first word, or 'timer_load_val' 
would not be cleared. 

A more detailed description of this can be found in my post from 6/17.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20040820/f8b5709f/attachment.htm