Re: [U-Boot-Users] BSS initialization wrong on ARM??
Hi all,
----- Original Message ----- From: "Wolfgang Denk" wd@denx.de To: "Markus Pietrek" maillist@fsforth.de Cc: u-boot-users@lists.sourceforge.net; "Andrea Scian" andrea.scian@wawnet.biz Sent: Wednesday, June 09, 2004 1:45 AM Subject: Re: [U-Boot-Users] BSS initialization wrong on ARM??
Dear Markus,
in message 200405041112.56047.maillist@fsforth.de you wrote:
on the smdk2410 I found out that the BSS segment is initialized at
offset 0x4
and not with offset 0x0, leaving the first entry undefined (in my case timer_load_val), at least with gcc-3.3. Cause of pain is arm920t/start.S:clear_bss
I think you are right. Thanks for pointing out.
clear_bss: ldr r0, _bss_start /* find start of bss segment */ add r0, r0, #4 /* start at first byte of bss */ ldr r1, _bss_end /* stop here */
I think the add has to be removed. This also seems to be the case on
arm720t
and arm926ejs.
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 for my port and, in fact, it was miss there too (at that time I've port u-boot version 1.0.2). Fortunately (or should I say "unfortunately"!?) I've no problem with bss (at least until now), I suppose because my global variable are initialized at runtime too. I will soon fix this problem, probably when we will port the newer version of u-boot to our platform.
Thanks to you and to Markus for pointing it out!
Regards,
Andrea Scian
DAVE Srl - Electronics System House via Forniz 2/1 33080 Porcia (PN) - Italy Telephone: +39.0434.921215 Telefax: +39.0434.591631 Freefax: +39.02.700520062 web: www.dave-tech.it NEW e-mail address: andrea.scian@dave-tech.it how to reach us: http://mail.map24.com/dave
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Q: What do you get when you cross an ethernet with an income statement? A: A local area networth.
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
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
participants (3)
-
Andrea Scian -
Paul Ruhland -
Wolfgang Denk