<DIV>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.</DIV>
<DIV>Thanks again,</DIV>
<DIV>David.<BR><BR><B><I>Paul Ruhland <pruhland@rochester.rr.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Friday 20 August 2004 11:31, David Farrell wrote:<BR>> Back in June a email was posted commenting that bss init had a non-zero<BR>> offset. Correct me if I am wrong, but in arm920t/start.S there is a word<BR>> defined at the bss_start: which is the address of bss start. This word<BR>> offsets the location of real _bss stuff by 4 bytes. The code in cvs looks<BR>> like it was changed to make the offset 0, this should be put back. David.<BR><BR>I believe you are wrong.<BR><BR>'__bss_start' is defined in the linker script to be the first word (4 bytes) <BR>aligned location after or equal to the end of the u_boot_cmd section...or in <BR>other words immediately after u-boot. ' _bss_start' is defined in start.S <BR>and is located immediately after the exception vectors along with _TEXT_BASE, <BR>_armboot_start, _bss_end, and the IRQ/FIQ_STACK_START if irqs are used
<BR>(check out System.map).<BR><BR>The word at '_bss_start' contains the address of the start of bss, <BR>'__bss_start'.<BR><BR>And, at least for the arm port I'm using, I'm willing to bet the first word in <BR>the bss is 'timer_load_val' from interrupts.c (check out System.map). With <BR>the word offset previously in 'clear_bss' the first word, or 'timer_load_val' <BR>would not be cleared. <BR><BR>A more detailed description of this can be found in my post from 6/17.<BR></BLOCKQUOTE>