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

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

[Markus Pietrek]

Hi folks,

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

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.

Bye,
-- 
Markus Pietrek
Kueferstrasse 8, D-79206 Breisach, Germany
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 245

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

[Wolfgang Denk]

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?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Q: What do you get when you cross an ethernet with an income statement?
A: A local area networth.

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

[Andrea Scian]

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 at 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 at denx.de
> Q: What do you get when you cross an ethernet with an income statement?
> A: A local area networth.
>

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
After a heated argument on some trivial matter Nancy [Astor]  .  .  .
shouted,  ``If  I were your wife I would put poison in your coffee!''
Whereupon Winston Churchill with equal heat and  sincerity  answered,
``And if I were your husband I would drink it.''

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

[Paul Ruhland]

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