From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Ruhland Date: Fri, 20 Aug 2004 19:01:48 -0400 Subject: [U-Boot-Users] Re: BSS initialization wrong on ARM?? In-Reply-To: <20040820153133.64030.qmail@web11705.mail.yahoo.com> References: <20040820153133.64030.qmail@web11705.mail.yahoo.com> Message-ID: <200408201901.49248.pruhland@rochester.rr.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.