Le 02/11/2010 08:18, V, Aneesh a écrit :
Thanks. This helps. I did the .lds change and it seems to be booting
now.
Good!
However, I can't still explain my earlier observation because even in
the absence of this fix .rel.dyn had some content and the offsets
should have been different if I
Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Tuesday, November 02, 2010 1:11 PM
To: V, Aneesh
Cc: dar...@theia.denx.de; h...@denx.de; u-boot@lists.denx.de; Augulis
Subject: Re: arm: wrong Relocation and not cleared BSS
Le 02/11/2010 08:18,
Hello Heiko,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-
boun...@lists.denx.de] On Behalf Of Heiko Schocher
Sent: Sunday, October 31, 2010 1:18 PM
To: Alexander Holler
Cc: Darius Augulis; u-boot@lists.denx.de
Subject: Re: [U-Boot] arm: wrong Relocation
Hi Heiko,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-
boun...@lists.denx.de] On Behalf Of V, Aneesh
Sent: Tuesday, November 02, 2010 11:10 AM
To: h...@denx.de; Alexander Holler
Cc: Darius Augulis; u-boot@lists.denx.de
Subject: Re: [U-Boot] arm: wrong
Hello Alexander,
Alexander Holler wrote:
to give the topic a better meaning and to summarize what I think is
currently happening along with some pictures for a better understanding:
We are starting with code (c) and data (d) somewhere in the memory:
--
|cd |
--
Hello Wolfgang,
Wolfgang Denk wrote:
Dear Albert ARIBAUD,
In message 4ccc1f6c.7040...@free.fr you wrote:
Could people with ARM NAND-based boards on the list test their own board
with Alexander's DEBUG and printf() added, and see what this gives on
their board?
Here the results from
Hello Alexander
Alexander Holler wrote:
I've just tested an u-boot build by Wolfgang Denx with the ELDK 4.2
(using the HEAD of the current master with the same patches than I've
used).
Thanks for that, Wolfgang.
This one works without any problems. So it seems to be proved, that it
Dear Alexander Holler,
In message 4ccd4c1c.2050...@ahsoftware.de you wrote:
Zeroing of the BSS is a mandatory requirement.
Beeing curious, I've looked up that part in the C99 standard. Just to=20
refresh our memories:
-
6.7.8
10
If an object
Le 31/10/2010 12:58, Wolfgang Denk a écrit :
Dear Alexander Holler,
In message4ccd4c1c.2050...@ahsoftware.de you wrote:
Zeroing of the BSS is a mandatory requirement.
Beeing curious, I've looked up that part in the C99 standard. Just to=20
refresh our memories:
Hello,
Am 31.10.2010 12:58, schrieb Wolfgang Denk:
If an object that has automatic storage duration is not initialized
explicitly, its value is
Wrong section. We are not talking about variables with automatic
storage (which means they are allocated on the stack), but about
_static_
Le 30/10/2010 15:08, Alexander Holler a écrit :
Hello,
to give the topic a better meaning and to summarize what I think is
currently happening along with some pictures for a better understanding:
You may be right, but for now this is not necessarily what really
happens, so the subjet is
Hello,
Am 30.10.2010 15:36, schrieb Albert ARIBAUD:
The code is moved upwards, but that code still uses the data at d.
This results another problem: Some parts in the code are assuming that d
is cleared (set to zero in start.S). But what start.S does it to clear
the new location (z in the
Le 30/10/2010 15:45, Alexander Holler a écrit :
Hello,
Am 30.10.2010 15:36, schrieb Albert ARIBAUD:
The code is moved upwards, but that code still uses the data at d.
This results another problem: Some parts in the code are assuming that d
is cleared (set to zero in start.S). But what
Am 30.10.2010 15:57, schrieb Albert ARIBAUD:
Le 30/10/2010 15:45, Alexander Holler a écrit :
If the code in u-boot would not assume that bss is zero, I don't
understand why clear_bss in start.S exists.
As I said, out of courtesy.
Still, BSS zeroing does not seem to relate to what you
Dear Albert ARIBAUD,
In message 4ccc1f6c.7040...@free.fr you wrote:
Wait a minute. No parts of the code assume BSS is *cleared*, or at least
no pat of the should *should ever* assume that. BSS is not zeroed
data, it is uninitialized data.
BSS _is_ zeroed data. This is a very basic assumption
Dear Alexander Holler,
In message 4ccc218e@ahsoftware.de you wrote:
Wait a minute. No parts of the code assume BSS is *cleared*, or at least
no pat of the should *should ever* assume that. BSS is not zeroed
data, it is uninitialized data.
Thats true for normal C, but I assume that
Dear Albert ARIBAUD,
In message 4ccc242c.8070...@free.fr you wrote:
You mean the rule is not respected for u-boot? then you should point out
(or better yet, submit a patch to fix) parts of code which assume BSS is
It's a requirement of a standard C execution environment. BSS must
_always_ be
Dear Albert ARIBAUD,
In message 4ccc1f6c.7040...@free.fr you wrote:
Could people with ARM NAND-based boards on the list test their own board
with Alexander's DEBUG and printf() added, and see what this gives on
their board?
Here the results from tx25:
U-Boot
Hi All,
I still have the same problem with my non main-line mini6410 board
(arm1176). I based my board support on newest u-boot with cleaned
relocation code:
U-Boot 2010.12-rc1-00028-ga1f6774 (Oct 30 2010 - 17:44:20) for MINI6410
U-Boot code: 57E0 - 57E20B58 BSS: - 57E26218
CPU:
Le 30/10/2010 16:39, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4ccc242c.8070...@free.fr you wrote:
You mean the rule is not respected for u-boot? then you should point out
(or better yet, submit a patch to fix) parts of code which assume BSS is
It's a requirement of a
Dear Albert ARIBAUD,
In message 4ccc4161.8000...@free.fr you wrote:
Just re-checked the C99 specs, and yes, all static scope vars must be
initialized, so I stand corrected as for BSS initialization. I still
think, though, that one should not count on a BSS-allocated variable to
be zero at
Le 30/10/2010 17:00, Wolfgang Denk a écrit :
U-Boot 2010.12-rc1-00026-g0c0892b-dirty (Oct 30 2010 - 16:55:43)
I assume this is the latest master, right?
U-Boot code: 8120 - 812291A0 BSS: - 812322A0
relocation Offset is: 00dbd000
Now running in RAM - U-Boot at: 81fbd000
##
Dear Albert ARIBAUD,
In message 4ccc5406.6050...@free.fr you wrote:
U-Boot 2010.12-rc1-00026-g0c0892b-dirty (Oct 30 2010 - 16:55:43)
I assume this is the latest master, right?
U-Boot code: 8120 - 812291A0 BSS: - 812322A0
relocation Offset is: 00dbd000
Now running in RAM
Hello,
I've written a small patch to test if relocation is working (at least as
I have understood as it should work).
The patch is here:
http://lists.denx.de/pipermail/u-boot/2010-October/080798.html
This fials here with gcc 4.3.4 and 4.5.1 (and binutils 2.20.1). I
currently have no other
Hello,
I've just tested an u-boot build by Wolfgang Denx with the ELDK 4.2
(using the HEAD of the current master with the same patches than I've used).
Thanks for that, Wolfgang.
This one works without any problems. So it seems to be proved, that it
is a problem of the current relocation
25 matches
Mail list logo
