[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert Aribaud]

older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections and overlay with .bss.

Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
---
V1	Initial submission
V2	arm926ejs: added ALIGN between bss and .rel.dyn sections
	tx25: removed GOT and datarel output sections
	tx25: fixed typo in config file commit message
V3	arm926ejs: overlaid .bss and .rel.dyn sections
	tx25: overlaid .bss and .rel.dyn sections
V4	arm926ejs and tx25: fixed overlay
	tx25: removed third patch as u-boot size remains small enough

 arch/arm/cpu/arm926ejs/u-boot.lds |   30 ++++++++++++++++++------------
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/u-boot.lds b/arch/arm/cpu/arm926ejs/u-boot.lds
index 72f45f8..28c91f9 100644
--- a/arch/arm/cpu/arm926ejs/u-boot.lds
+++ b/arch/arm/cpu/arm926ejs/u-boot.lds
@@ -45,24 +45,30 @@ SECTIONS
 
 	. = ALIGN(4);
 
-	__rel_dyn_start = .;
-	.rel.dyn : { *(.rel.dyn) }
-	__rel_dyn_end = .;
-
-	__dynsym_start = .;
-	.dynsym : { *(.dynsym) }
-
-	. = ALIGN(4);
-
 	. = .;
 	__u_boot_cmd_start = .;
 	.u_boot_cmd : { *(.u_boot_cmd) }
 	__u_boot_cmd_end = .;
 
 	. = ALIGN(4);
-	__bss_start = .;
-	.bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
-	_end = .;
+
+	.rel.dyn : {
+		__rel_dyn_start = .;
+		*(.rel*)
+		__rel_dyn_end = .;
+	}
+
+	.dynsym : {
+		__dynsym_start = .;
+		*(.dynsym)
+	}
+
+	.bss __rel_dyn_start (OVERLAY) : {
+		__bss_start = .;
+		*(.bss)
+		 . = ALIGN(4);
+		_end = .;
+	}
 
 	/DISCARD/ : { *(.dynstr*) }
 	/DISCARD/ : { *(.dynamic*) }
-- 
1.7.1

[U-Boot] [PATCH V4 2/2] tx25: fix linker file for newer ld support

[Albert Aribaud]

older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections and overlay with .bss.

Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
---
 nand_spl/board/karo/tx25/u-boot.lds |   40 ++++++++++++++++------------------
 1 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/nand_spl/board/karo/tx25/u-boot.lds b/nand_spl/board/karo/tx25/u-boot.lds
index 5f95c87..ff289fb 100644
--- a/nand_spl/board/karo/tx25/u-boot.lds
+++ b/nand_spl/board/karo/tx25/u-boot.lds
@@ -43,35 +43,33 @@ SECTIONS
 	. = ALIGN(4);
 	.data : {
 		*(.data)
-	__datarel_start = .;
-		*(.data.rel)
-	__datarelrolocal_start = .;
-		*(.data.rel.ro.local)
-	__datarellocal_start = .;
-		*(.data.rel.local)
-	__datarelro_start = .;
-		*(.data.rel.ro)
 	}
 
 	. = ALIGN(4);
-	__rel_dyn_start = .;
-	__rel_dyn_end = .;
-	__dynsym_start = .;
-
-	__got_start = .;
-	. = ALIGN(4);
-	.got : { *(.got) }
-
-	__got_end = .;
-	. = .;
 	__u_boot_cmd_start = .;
 	.u_boot_cmd : { *(.u_boot_cmd) }
 	__u_boot_cmd_end = .;
 
 	. = ALIGN(4);
-	__bss_start = .;
-	.bss : { *(.bss) }
-	_end = .;
+
+	.rel.dyn : {
+		__rel_dyn_start = .;
+		*(.rel*)
+		__rel_dyn_end = .;
+	}
+
+	.dynsym : {
+		__dynsym_start = .;
+		*(.dynsym)
+	}
+
+	.bss __rel_dyn_start (OVERLAY) : {
+		__bss_start = .;
+		*(.bss)
+		 . = ALIGN(4);
+		_end = .;
+	}
+
 	/DISCARD/ : { *(.bss*) }
 	/DISCARD/ : { *(.dynstr*) }
 	/DISCARD/ : { *(.dynsym*) }
-- 
1.7.1

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 04/11/2010 23:22, Albert Aribaud a ?crit :
> older ld emitted all ELF relocations in input sections named
> ..rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections and overlay with .bss.
>
> Signed-off-by: Albert Aribaud<albert.aribaud@free.fr>

Tested on openrd_base, boots fine, works fine.

Wolfgang, please test with tx25.

Alexander, please test above your patches in place of previous patch v3.

Others who are willing to test on other ARMs are welcome too. :)

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 04/11/2010 23:27, Albert ARIBAUD a ?crit :
> Le 04/11/2010 23:22, Albert Aribaud a ?crit :
>> older ld emitted all ELF relocations in input sections named
>> ..rel.dyn, whereas newer ld uses names of the form .rel*. The
>> linker script only collected .rel.dyn input sections. Rewrite
>> to collect all .rel* input sections and overlay with .bss.
>>
>> Signed-off-by: Albert Aribaud<albert.aribaud@free.fr>
>
> Tested on openrd_base, boots fine, works fine.
>
> Wolfgang, please test with tx25.
>
> Alexander, please test above your patches in place of previous patch v3.
>
> Others who are willing to test on other ARMs are welcome too. :)

Did testers manage to try this patch set? I'd like to make sure it 
solves current issues with master for ARM relocation.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Reinhard Meyer]

Dear Albert Aribaud,
> older ld emitted all ELF relocations in input sections named
> .rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections and overlay with .bss.
> 
> Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
> ---
Thank you,
works fine with:

gcc 4.2.4 (binary size 258700)
gcc 4.3.5 (binary size 251600 - nice!)

(ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch)

Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 05/11/2010 09:38, Reinhard Meyer a ?crit :
> Dear Albert Aribaud,
>> older ld emitted all ELF relocations in input sections named
>> .rel.dyn, whereas newer ld uses names of the form .rel*. The
>> linker script only collected .rel.dyn input sections. Rewrite
>> to collect all .rel* input sections and overlay with .bss.
>>
>> Signed-off-by: Albert Aribaud<albert.aribaud@free.fr>
>> ---
> Thank you,
> works fine with:
>
> gcc 4.2.4 (binary size 258700)
> gcc 4.3.5 (binary size 251600 - nice!)
>
> (ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch)

Thanks for testing. The size reduction is due to the gcc ARM backend 
which has obviously undergone many improvements since gcc 4.2.x. 
Openrd_base goes from 376 to 360k, and edminiv2 (untested yet, though) 
from 152 to 144k when using the CS arm-2010q1-202 toolchain (4.4.1) 
instead of the ELDK 4.2 one (gcc 4.2.2).

> Signed-off-by: Reinhard Meyer<u-boot@emk-elektronik.de>

Did you mean 'Tested-by:'?

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Daniel Hobi]

Hi Albert,

On 04.11.2010 23:22, Albert Aribaud wrote:
> older ld emitted all ELF relocations in input sections named
> .rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections and overlay with .bss.

Tested-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>

Thank you. This patch is required to get Kirkwood-based boards working
again when using the CodeSourcery 2009q3 toolchain.

But shouldn't this change be applied to all ARM linker scripts, ie
arch/arm/cpu/*/u-boot.lds?

And on many ARM platforms (including Kirkwood), the timer implementation
is still accessing BSS variables before relocation.

Is someone working on this? Candidates are:

$ git grep "static ulong timestamp"
arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp;
arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp;
arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp;
arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp;
arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp;
arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp;
arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp;
arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp;
arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp;
arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp;
arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp;
arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp;

Best regards,
Daniel

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 09/11/2010 19:24, Daniel Hobi a ?crit :
> Hi Albert,
>
> On 04.11.2010 23:22, Albert Aribaud wrote:
>> older ld emitted all ELF relocations in input sections named
>> .rel.dyn, whereas newer ld uses names of the form .rel*. The
>> linker script only collected .rel.dyn input sections. Rewrite
>> to collect all .rel* input sections and overlay with .bss.
>
> Tested-by: Daniel Hobi<daniel.hobi@schmid-telecom.ch>

Thanks Daniel for the test.

> Thank you. This patch is required to get Kirkwood-based boards working
> again when using the CodeSourcery 2009q3 toolchain.

(can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 
2010q1 apparently... Can you tell me which gcc and which ld version is 
used in 2010q3?)

I think this V4 of my patchset could be now committed to 
u-boot-arm/master, and if possible even on u-boot-arm for the december 
release of u-boot, as it is a bugfix.

> But shouldn't this change be applied to all ARM linker scripts, ie
> arch/arm/cpu/*/u-boot.lds?

Yes, it should. :)

> And on many ARM platforms (including Kirkwood), the timer implementation
> is still accessing BSS variables before relocation.

That is fixed in the orion5x code; a git blame on the timer.c file will 
tell you which commit of mine did the fix, and from then you can port to 
kirkwood as the orion5x code comes from the kirkwood one.

> Is someone working on this? Candidates are:
>
> $ git grep "static ulong timestamp"
> arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp;
> arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp;
> arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp;
> arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp;
> arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp;
> arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp;
> arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp;
> arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp;
> arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp;
> arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp;
> arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp;
> arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp;

Normally, the board maintainers should handle this during the window 
after next version... Dunno if that is practical, but OTOH it would 
easily show which boards are still maintained and which are not. :)

> Best regards,
> Daniel

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 09/11/2010 19:47, Albert ARIBAUD a ?crit :

> I think this V4 of my patchset could be now committed to
> u-boot-arm/master, and if possible even on u-boot-arm for the december
> release of u-boot, as it is a bugfix.

... "even on u-boot", not "u-boot-arm", of course.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Andreas Bießmann]

Dear Albert Ardibaud,

Am 09.11.2010 um 19:47 schrieb Albert ARIBAUD:

>> Thank you. This patch is required to get Kirkwood-based boards working
>> again when using the CodeSourcery 2009q3 toolchain.
> 
> (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 
> 2010q1 apparently... Can you tell me which gcc and which ld version is 
> used in 2010q3?)

I think http://www.codesourcery.com/sgpp/lite/arm/portal/release1033 was meant ...

regards

Andreas Bie?mann

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Daniel Hobi]

Hi Albert,

On 09.11.2010 19:47, Albert ARIBAUD wrote:
> Le 09/11/2010 19:24, Daniel Hobi a ?crit :
>> Thank you. This patch is required to get Kirkwood-based boards working
>> again when using the CodeSourcery 2009q3 toolchain.
> 
> (can't find the 2010q3 Lite toolchain on CodeSourcery's site, latest is 
> 2010q1 apparently... Can you tell me which gcc and which ld version is 
> used in 2010q3?)

Andreas is correct: I'm still using Sourcery G++ Lite 2009q3-67.

> I think this V4 of my patchset could be now committed to 
> u-boot-arm/master, and if possible even on u-boot-arm for the december 
> release of u-boot, as it is a bugfix.

Since all ARM boards are broken when using a recent toolchain, the patch
should go in as fast as possible.

>> But shouldn't this change be applied to all ARM linker scripts, ie
>> arch/arm/cpu/*/u-boot.lds?
> 
> Yes, it should. :)

Can you please provide such a patch?

>> And on many ARM platforms (including Kirkwood), the timer implementation
>> is still accessing BSS variables before relocation.
>>
>> Is someone working on this? Candidates are:
>>
>> $ git grep "static ulong timestamp"
>> arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp;
>> arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm920t/s3c24x0/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/davinci/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/kirkwood/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/mx25/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/mx27/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/omap/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/orion5x/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/spear/timer.c:static ulong timestamp;
>> arch/arm/cpu/arm926ejs/versatile/timer.c:static ulong timestamp;
>> arch/arm/cpu/armv7/mx5/timer.c:static ulong timestamp;
>> arch/arm/cpu/armv7/omap-common/timer.c:static ulong timestamp;
>> arch/arm/cpu/lh7a40x/timer.c:static ulong timestamp;
>> arch/arm/cpu/s3c44b0/timer.c:static ulong timestamp;
> 
> Normally, the board maintainers should handle this during the window 
> after next version... Dunno if that is practical, but OTOH it would 
> easily show which boards are still maintained and which are not. :)

Since accessing BSS variables before relocation is a severe bug, we
should handle this now for all SoCs. But right now, there are two
approaches:

 - Perform initialization of static variables after relocation, and
   thus forbid using functions which access such variables before
   relocation (reset_timer*, get_timer*, set_timer).

   You patched arch/arm/cpu/arm926ejs/orion5x/timer.c to use this
   approach.

 - Move static variables to struct global_data, so they can be used
   before relocation. Used by AT91 timers and proposed for A320 and
   S3C64xx in:

   http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095
   http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88160

I hope we can solve this problem in the same way for all ARM timers. And
if we use the second approach, we probably can generalize the AT91 data
in struct global_data as proposed by Andreas.

Best regards,
Daniel

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 10/11/2010 13:31, Daniel Hobi a ?crit :

> Since all ARM boards are broken when using a recent toolchain, the patch
> should go in as fast as possible.
>
>>> But shouldn't this change be applied to all ARM linker scripts, ie
>>> arch/arm/cpu/*/u-boot.lds?
>>
>> Yes, it should. :)
>
> Can you please provide such a patch?

I could, but I tend to provide patches only for boards that I can test, 
which basically covers only arm926ejs, or that I can get tested; I'd 
prefer not to provide patches for HW that I cannot test, and thus I 
would prefer that patches for other cpus be handled by people who 
actually own boards with these cpus and can test their patching. After 
all, this very bugfix is due to ELF relocations having been tested with 
too poor a range of toolchains.

> Since accessing BSS variables before relocation is a severe bug, we
> should handle this now for all SoCs. But right now, there are two
> approaches:
>
>   - Perform initialization of static variables after relocation, and
>     thus forbid using functions which access such variables before
>     relocation (reset_timer*, get_timer*, set_timer).
>
>     You patched arch/arm/cpu/arm926ejs/orion5x/timer.c to use this
>     approach.
>
>   - Move static variables to struct global_data, so they can be used
>     before relocation. Used by AT91 timers and proposed for A320 and
>     S3C64xx in:
>
>     http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095
>     http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88160
>
> I hope we can solve this problem in the same way for all ARM timers. And
> if we use the second approach, we probably can generalize the AT91 data
> in struct global_data as proposed by Andreas.

Either way is ok with me.

> Best regards,
> Daniel

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Daniel Hobi]

On 10.11.2010 13:48, Albert ARIBAUD wrote:
> Le 10/11/2010 13:31, Daniel Hobi a ?crit :
>>>> But shouldn't this change be applied to all ARM linker scripts, ie
>>>> arch/arm/cpu/*/u-boot.lds?
>>>
>>> Yes, it should. :)
>>
>> Can you please provide such a patch?
> 
> I could, but I tend to provide patches only for boards that I can test, 
> which basically covers only arm926ejs, or that I can get tested; I'd 
> prefer not to provide patches for HW that I cannot test, and thus I 
> would prefer that patches for other cpus be handled by people who 
> actually own boards with these cpus and can test their patching. After 
> all, this very bugfix is due to ELF relocations having been tested with 
> too poor a range of toolchains.

I prefer a single patch to solve one problem in all places. And since
you probably have most experience with the new ARM relocation, that
patch should come from you.

The ARM architecture and board maintainers will test your patch during
the current release cycle.

Best regards,
Daniel

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 10/11/2010 14:24, Daniel Hobi a ?crit :
> On 10.11.2010 13:48, Albert ARIBAUD wrote:
>> Le 10/11/2010 13:31, Daniel Hobi a ?crit :
>>>>> But shouldn't this change be applied to all ARM linker scripts, ie
>>>>> arch/arm/cpu/*/u-boot.lds?
>>>>
>>>> Yes, it should. :)
>>>
>>> Can you please provide such a patch?
>>
>> I could, but I tend to provide patches only for boards that I can test,
>> which basically covers only arm926ejs, or that I can get tested; I'd
>> prefer not to provide patches for HW that I cannot test, and thus I
>> would prefer that patches for other cpus be handled by people who
>> actually own boards with these cpus and can test their patching. After
>> all, this very bugfix is due to ELF relocations having been tested with
>> too poor a range of toolchains.
>
> I prefer a single patch to solve one problem in all places. And since
> you probably have most experience with the new ARM relocation, that
> patch should come from you.

Figures. :)

> The ARM architecture and board maintainers will test your patch during
> the current release cycle.

Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. 
Wolfgang, is a single *patch* for all cpus ok or do you want a single 
*patchset* with one patch per cpu? Please tell me the single patch 
approach is ok. :)

> Best regards,
> Daniel

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CDBA515.3050106@free.fr> you wrote:
>
> Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. 
> Wolfgang, is a single *patch* for all cpus ok or do you want a single 
> *patchset* with one patch per cpu? Please tell me the single patch 
> approach is ok. :)

It is.  Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three ways to get something done:
        (1) Do it yourself.
        (2) Hire someone to do it for you.
        (3) Forbid your kids to do it.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 14/11/2010 22:22, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CDBA515.3050106@free.fr>  you wrote:
>>
>> Alright. I'll prepare a V5 patch set with fixes to all ARM cpus.
>> Wolfgang, is a single *patch* for all cpus ok or do you want a single
>> *patchset* with one patch per cpu? Please tell me the single patch
>> approach is ok. :)
>
> It is.  Thanks in advance.

ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, 
arm1176, armv7 and pxa)  have ELF relocation support. Others still use 
GOT relocation (or the older fixed-location scheme maybe), which IIUC 
means all boards using these other cpus are broken unless a maintainer 
gets patches pulled in to support ELF relocs.

I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, 
arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board 
maintainers who want to fix their board support for ELF relocs may have 
to also fix their cpu if it is not yet.

Does everyone agree?

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Andreas Bießmann]

Dear Albert ARIBAUD,

Am 15.11.2010 12:01, schrieb Albert ARIBAUD:

> I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, 
> arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board 
> maintainers who want to fix their board support for ELF relocs may have 
> to also fix their cpu if it is not yet.
> 
> Does everyone agree?

arm920t/at91 is ongoing. I may need your help these days but first I
need some time to get my last linker related issues fixed properly
(segfault when linking empty weak symbol with -pie).

regards

Andreas Bie?mann

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Sebastien Carlier]

Dear Andreas,

On 2010-11-15 12:09:58, Andreas Bie?mann wrote:
> 
> arm920t/at91 is ongoing. I may need your help these days but first I
> need some time to get my last linker related issues fixed properly
> (segfault when linking empty weak symbol with -pie).

Can you please try the attached patch?  It fixed this problem for me.

-- 
Sebastien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-arm920t-add-.plt-and-.rel.plt-to-the-linker-script.patch
Type: text/x-diff
Size: 0 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/cb8ee723/attachment.patch 

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Andreas Bießmann]

Dear Sebastien,

Am 15.11.2010 um 12:43 schrieb Sebastien Carlier:

> Dear Andreas,
> 
> On 2010-11-15 12:09:58, Andreas Bie?mann wrote:
>> 
>> arm920t/at91 is ongoing. I may need your help these days but first I
>> need some time to get my last linker related issues fixed properly
>> (segfault when linking empty weak symbol with -pie).
> 
> Can you please try the attached patch?  It fixed this problem for me.

yes it works, the ASSERT/SEGFAULT are gone. I've never tested to place these two sections that early in the ELF. I used to place them between .rel.dyn and .bss (after applying Albert's approach of overloading .rel.dyn with .bss). At that place I still had ASSERT/SEGFAULT failures in linker.

Thanks a lot, with this information I may get the arm920t elf relocation fixed.

regards

Andreas Bie?mann

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CE11314.50807@free.fr> you wrote:
>
> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, 
> arm1176, armv7 and pxa)  have ELF relocation support. Others still use 
> GOT relocation (or the older fixed-location scheme maybe), which IIUC 
> means all boards using these other cpus are broken unless a maintainer 
> gets patches pulled in to support ELF relocs.
> 
> I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, 
> arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board 
> maintainers who want to fix their board support for ELF relocs may have 
> to also fix their cpu if it is not yet.
> 
> Does everyone agree?

I dislike having such a mix of different relocation methods.

Let's face it: this discussion has been going on for so long already
that every interested party could have adapted their code.  I am
afraid if we do not force the change now it will never happen.  And I
do not want to carry on such a bifurcation much longer.

Do you think you could convert the remaining CPUs to ELF relocation as
well?  That would probably provide the best base for any further work.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
This is now.  Later is later.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 15/11/2010 12:13, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CE11314.50807@free.fr>  you wrote:
>>
>> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136,
>> arm1176, armv7 and pxa)  have ELF relocation support. Others still use
>> GOT relocation (or the older fixed-location scheme maybe), which IIUC
>> means all boards using these other cpus are broken unless a maintainer
>> gets patches pulled in to support ELF relocs.
>>
>> I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136,
>> arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board
>> maintainers who want to fix their board support for ELF relocs may have
>> to also fix their cpu if it is not yet.
>>
>> Does everyone agree?
>
> I dislike having such a mix of different relocation methods.
>
> Let's face it: this discussion has been going on for so long already
> that every interested party could have adapted their code.  I am
> afraid if we do not force the change now it will never happen.  And I
> do not want to carry on such a bifurcation much longer.

Understood.

> Do you think you could convert the remaining CPUs to ELF relocation as
> well?  That would probably provide the best base for any further work.

I can make the changes for other cpus, but I cannot perform even basic 
testing beyond making sure it still builds.

Besides, while I can reasonably provide a V5 patch by this evening for 
the five cpus which already support ELF, I won't be able to provide 
fixes for the whole of arch/arm/cpu/* until thursday evening/friday 
morning. Is that ok?

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Loïc Minier]

On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> I can make the changes for other cpus, but I cannot perform even basic 
> testing beyond making sure it still builds.

 Would qemu be of any help there?  You could use e.g. versatile or
 integrator, and pretend that they use any CPU by changing their config
 and passing -cpu on the qemu command-line

-- 
Lo?c Minier

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20101115115556.GA13479@bee.dooz.org> you wrote:
> On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> > I can make the changes for other cpus, but I cannot perform even basic =
> 
> > testing beyond making sure it still builds.
> 
>  Would qemu be of any help there?  You could use e.g. versatile or
>  integrator, and pretend that they use any CPU by changing their config
>  and passing -cpu on the qemu command-line

Do you have a working qemu setup and/or documentation how to run
U-Boot on such an ARM config?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conscious is when you are aware of something, and conscience is  when
you wish you weren't.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Loïc Minier]

On Mon, Nov 15, 2010, Wolfgang Denk wrote:
> Do you have a working qemu setup and/or documentation how to run
> U-Boot on such an ARM config?

 Sometimes I do  ;-)

 I use either:
 * Ubuntu QEMU packages - qemu-kvm-extras package has qemu-system-arm;
   it's usually fairly old because it's built from the qemu-kvm
   trees/releases
 * Linaro QEMU packages - currently the "qemu-maemo" package in this PPA
   https://launchpad.net/~linaro-maintainers/+archive/tools/+packages
   provides the qemu-maemo-system-arm command; can be installed along
   qemu-kvm-extras; this has patches to support OMAP machines from the
   qemu-maemo/-meego projects, hence the name; in the future, this might
   be a qemu-linaro instead
 * upstream QEMU built from git

 While U-Boot supports integrator, versatile and vexpress, QEMU only
 supports the first two.

 I get varying success depending on the exact combination of emulated
 machine and version of QEMU.  Today, I tried the binary u-boot
 downloads from http://arm.com/community/software-enablement/linux.php
 (Linux OS Downloads tab) with with qemu-maemo
 0.0~20100921+871d996-0ubuntu1~linaro1 and qemu-kvm-extras
 0.13.0+noroms-0ubuntu3:

        machine: | realview-eb realview-pbx-a9 versatilepb
 QEMU:           |
 ----------------+----------------------------------------
 qemu-maemo      | partial[1]      works         works
 qemu-kvm-extras | partial[1]      works         crash[2]


 Unfortunately, these are not built from upstream u-boot sources; I
 tried building some ARM boards from upstream u-boot with v2010.09 and
 got these results:

        machine: | integratorcp versatilepb
 QEMU:           |
 ----------------+-------------------------
 qemu-maemo      |  crash[3]    partial[4]
 qemu-kvm-extras |  crash[3]    partial[4]


 So I'm afraid I couldn't find a fully working combination of U-Boot
 supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who
 cares for QEMU in Linaro, maybe he has more idea or is tempted to try a
 tip QEMU  :-)


 If you want to reproduce, run something like:
    qemu-system-arm -M versatilepb -serial stdio \
        -kernel u-boot_bin_u-boot_versatilepb.axf
 or:
    qemu-system-arm -nographic -M versatilepb \
        -kernel u-boot_bin_u-boot_versatilepb.axf
 replace qemu-system-arm with qemu-maemo-system-arm if you use
 qemu-maemo


 [1] crashes while initializing the NIC; qemu: hardware error:
     smc91c111_write: Bad reg 0:6
 [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0
 [3] qemu: hardware error: pl011_write: Bad offset 14
 [4] crashes after detecting 0 Bytes of DRAM:
    DRAM:  0 Bytes
    qemu: fatal: Trying to execute code outside RAM or ROM at 0x34000000
-- 
Lo?c Minier

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 15/11/2010 15:06, Lo?c Minier a ?crit :

>   So I'm afraid I couldn't find a fully working combination of U-Boot
>   supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who
>   cares for QEMU in Linaro, maybe he has more idea or is tempted to try a
>   tip QEMU  :-)

Not sure I get how this works. Do you need to build u-boot in a special 
way or with a special toolchain in order to run it in qemu? I'm asking 
because:

>   If you want to reproduce, run something like:
>      qemu-system-arm -M versatilepb -serial stdio \
>          -kernel u-boot_bin_u-boot_versatilepb.axf

I assume that the -kernel option indicates the executable to run. Would 
it take an ELF executable? a binary? How would one go about testing 
running u-boot from RAM, NOR, NAND?

Also:

>   [1] crashes while initializing the NIC; qemu: hardware error:
>       smc91c111_write: Bad reg 0:6
>   [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0
>   [3] qemu: hardware error: pl011_write: Bad offset 14
>   [4] crashes after detecting 0 Bytes of DRAM:

This seems to mean the HW is not 100% simulated, right?

One last question:

>      qemu: fatal: Trying to execute code outside RAM or ROM at 0x34000000

Does this mean that qemu does not simulate data or instruction aborts? 
Not that it is required for u-boot, but it *could* be useful sometimes.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Loïc Minier]

On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
> I assume that the -kernel option indicates the executable to run.

 Correct, IOW u-boot.bin

> Would it take an ELF executable? a binary?

 You can pass an ELF as well

>                                            How would one go about
> testing running u-boot from RAM, NOR, NAND?

 I guess you could only test from RAM with the way support for ARM
 boards is implemented


 Hmm another option would be OMAP emulation.  It might allow you to test
 all of this; it's a bit more tricky to setup as you need to generate
 the flash contents, or some SD card.  Also, things are a bit messier
 because this still uses x-loader.  Problem is that x-loader probably
 requires armv7 itself ATM; this becomes quite far-fetched  :-/

> This seems to mean the HW is not 100% simulated, right?

 Well, these are either missing simulation or bugs; yes

> One last question:
> >     qemu: fatal: Trying to execute code outside RAM or ROM at 0x34000000
> 
> Does this mean that qemu does not simulate data or instruction
> aborts? Not that it is required for u-boot, but it *could* be useful
> sometimes.

 I think the only thing it can do is halt  :-)

-- 
Lo?c Minier

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Peter Maydell]

On 15 November 2010 15:09, Lo?c Minier <loic.minier@linaro.org> wrote:
> On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
>> One last question:
>> > ? ? qemu: fatal: Trying to execute code outside RAM or ROM at 0x34000000
>>
>> Does this mean that qemu does not simulate data or instruction
>> aborts? Not that it is required for u-boot, but it *could* be useful
>> sometimes.
>
> ?I think the only thing it can do is halt ?:-)

qemu does simulate data/insn aborts caused when the MMU is
enabled and you try an access forbidden by the access permissions
set up in the page table. That particular error message happens when
you try to execute from a physical address which isn't RAM or ROM,
so you'll only see it if you have not enabled the MMU or if you get
your page tables wrong. There's no particular reason this couldn't
be made to take a simulated fault instead, I think -- there's an #ifdef
that means qemu for Sparc and MIPS will simulate a fault instead
of aborting. (In theory I think the behaviour shouldn't necessarily
always be to fault, but if there is a non-RAM non-ROM device at
the address to simulate the effect of trying to fetch instructions
from your serial device registers, for example :-))

This is an example of a general tendency in qemu-arm for the
modelling to be a bit weak for situations which will never be
triggered by a correct program/OS but which nonetheless have
well defined failure behaviour. Other examples include execution
of various opcode values which should UNDEF (may trigger qemu
internal error warnings or decode to some other instruction), and
execution of VFP or Neon when the CPACR is set to disable
access to cp10/11 (should fault but won't). Mostly these things
don't cause a problem in practice, which is why they haven't
been corrected yet.

-- PMM

[U-Boot] qemu-arm (was: [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support)

[Albert ARIBAUD]

Le 16/11/2010 14:42, Peter Maydell a ?crit :

> qemu does simulate data/insn aborts caused when the MMU is
> enabled and you try an access forbidden by the access permissions
> set up in the page table. That particular error message happens when
> you try to execute from a physical address which isn't RAM or ROM,
> so you'll only see it if you have not enabled the MMU or if you get
> your page tables wrong. There's no particular reason this couldn't
> be made to take a simulated fault instead, I think -- there's an #ifdef
> that means qemu for Sparc and MIPS will simulate a fault instead
> of aborting. (In theory I think the behaviour shouldn't necessarily
> always be to fault, but if there is a non-RAM non-ROM device at
> the address to simulate the effect of trying to fetch instructions
> from your serial device registers, for example :-))
>
> This is an example of a general tendency in qemu-arm for the
> modelling to be a bit weak for situations which will never be
> triggered by a correct program/OS but which nonetheless have
> well defined failure behaviour. Other examples include execution
> of various opcode values which should UNDEF (may trigger qemu
> internal error warnings or decode to some other instruction), and
> execution of VFP or Neon when the CPACR is set to disable
> access to cp10/11 (should fault but won't). Mostly these things
> don't cause a problem in practice, which is why they haven't
> been corrected yet.

Thanks Peter for the clarification. I imagine that "in practice" can 
bear different meanings depending on the practice -- for software like 
u-boot, which is very low-level and can encounter issues such as a RAM 
controller misconfiguration (or plain bad BAR setting, mind) addressing 
outside physically available space, including writing to RO memory or 
fetching bad code, is something we can see in practice, at least in the 
first times of a board's bring up.

I'll have a look and see if I can get a working setup for running u-boot 
on qemu-arm.

> -- PMM

Amicalement,
-- 
Albert.

[U-Boot] qemu-arm (was: [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support)

[Peter Maydell]

On 16 November 2010 13:54, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
>> Mostly these things
>> don't cause a problem in practice, which is why they haven't
>> been corrected yet.
>
> Thanks Peter for the clarification. I imagine that "in practice" can bear
> different meanings depending on the practice -- for software like u-boot,
> which is very low-level and can encounter issues such as a RAM controller
> misconfiguration (or plain bad BAR setting, mind) addressing outside
> physically available space, including writing to RO memory or fetching bad
> code, is something we can see in practice, at least in the first times of a
> board's bring up.

Sure, but I imagine that for debugging that sort of thing it doesn't make
a great deal of difference whether you discover it by getting a cpu
abort, by having the core just go off into the weeds somewhere or by
getting a fatal error message from qemu. So that was partly what I
meant by "in practice" -- yes, it's a deviation from correct behaviour,
but it's not really any more of an impediment to debugging than
correctly modelled behaviour would be, once you know what qemu
is doing wrong...

(Which is not to defend the current qemu behaviour so much as to
try to explain why this particular bug isn't at the top of my todo list :-))

-- PMM

[U-Boot] qemu-arm

[Albert ARIBAUD]

Le 16/11/2010 15:49, Peter Maydell a ?crit :
> On 16 November 2010 13:54, Albert ARIBAUD<albert.aribaud@free.fr>  wrote:
>>> Mostly these things
>>> don't cause a problem in practice, which is why they haven't
>>> been corrected yet.
>>
>> Thanks Peter for the clarification. I imagine that "in practice" can bear
>> different meanings depending on the practice -- for software like u-boot,
>> which is very low-level and can encounter issues such as a RAM controller
>> misconfiguration (or plain bad BAR setting, mind) addressing outside
>> physically available space, including writing to RO memory or fetching bad
>> code, is something we can see in practice, at least in the first times of a
>> board's bring up.
>
> Sure, but I imagine that for debugging that sort of thing it doesn't make
> a great deal of difference whether you discover it by getting a cpu
> abort, by having the core just go off into the weeds somewhere or by
> getting a fatal error message from qemu. So that was partly what I
> meant by "in practice" -- yes, it's a deviation from correct behaviour,
> but it's not really any more of an impediment to debugging than
> correctly modelled behaviour would be, once you know what qemu
> is doing wrong...

Understood. What I meant is that "in practice" with a real piece of HW, 
we expect aborts or undefined so much that we actually handle them and 
do a register dump the board's console, so not seeing this dump when 
simulating an abort on the HW would thus somehow 'depart' from 'the 
practice' as I know it. However:

> (Which is not to defend the current qemu behaviour so much as to
> try to explain why this particular bug isn't at the top of my todo list :-))

I do understand why it isn't, and as I said, I can happily live without 
it as long as I know that the simulator differs from the HW in this 
respect -- after all, if I *really* need it, I guess I can delve deep 
into the qemu-arm source code. :)

> -- PMM

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Reinhard Meyer]

Dear Albert ARIBAUD,
>>> ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136,
>>> arm1176, armv7 and pxa)  have ELF relocation support. Others still use
>>> GOT relocation (or the older fixed-location scheme maybe), which IIUC
>>> means all boards using these other cpus are broken unless a maintainer
>>> gets patches pulled in to support ELF relocs.
>>>
>>> I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136,
>>> arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board
>>> maintainers who want to fix their board support for ELF relocs may have
>>> to also fix their cpu if it is not yet.
>>>
>>> Does everyone agree?
>> I dislike having such a mix of different relocation methods.
>>
>> Let's face it: this discussion has been going on for so long already
>> that every interested party could have adapted their code.  I am
>> afraid if we do not force the change now it will never happen.  And I
>> do not want to carry on such a bifurcation much longer.
> 
> Understood.
> 
>> Do you think you could convert the remaining CPUs to ELF relocation as
>> well?  That would probably provide the best base for any further work.
> 
> I can make the changes for other cpus, but I cannot perform even basic 
> testing beyond making sure it still builds.
> 
> Besides, while I can reasonably provide a V5 patch by this evening for 
> the five cpus which already support ELF, I won't be able to provide 
> fixes for the whole of arch/arm/cpu/* until thursday evening/friday 
> morning. Is that ok?

Would it not be "nice" to take the ARM-universal identical code for
relocate, clear bss and transfer to relocated code out of each
ARM/CPU/*/start.S and move it to ARM/LIB/relocate.S ?

You would not have to duplicate and maintain that code in every
ARM CPU type.

That would also pave the path to the relocation in C which I have started
a while ago.

Best Regards,
Reinhard

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CE11E66.5060207@free.fr> you wrote:
>
> > Do you think you could convert the remaining CPUs to ELF relocation as
> > well?  That would probably provide the best base for any further work.
> 
> I can make the changes for other cpus, but I cannot perform even basic 
> testing beyond making sure it still builds.

Understood.  Eventually I can test on a small number of boards. The
rest goes untested - but most of them are in a more or less broken
state anyway.

> Besides, while I can reasonably provide a V5 patch by this evening for 
> the five cpus which already support ELF, I won't be able to provide 
> fixes for the whole of arch/arm/cpu/* until thursday evening/friday 
> morning. Is that ok?

That's OK.  I will then try to get the recent changes in this night,
and the others when the patch becomes available.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The whole world is about three drinks behind."     - Humphrey Bogart

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 15/11/2010 13:02, Wolfgang Denk a ?crit :

 >> Besides, while I can reasonably provide a V5 patch by this evening 
 >> for the five cpus which already support ELF, I won't be able to
 >> provide fixes for the whole of arch/arm/cpu/* until thursday
 >> evening/friday morning. Is that ok?
 >
 > That's OK.  I will then try to get the recent changes in this night,
 > and the others when the patch becomes available.

All right then. I'll push the V5 tonight with support for the first five 
cpus, and another patch for the remaining ones by end of week.

 > Best regards,
 >
 > Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Bas Mevissen]

On Mon, 15 Nov 2010 12:49:58 +0100, Albert ARIBAUD
<albert.aribaud@free.fr> wrote:

> 
>> Do you think you could convert the remaining CPUs to ELF relocation as
>> well?  That would probably provide the best base for any further work.
> 
> I can make the changes for other cpus, but I cannot perform even basic 
> testing beyond making sure it still builds.
> 
> Besides, while I can reasonably provide a V5 patch by this evening for 
> the five cpus which already support ELF, I won't be able to provide 
> fixes for the whole of arch/arm/cpu/* until thursday evening/friday 
> morning. Is that ok?
> 

I would suggest get those 5 done, reviewed and well tested first.
Otherwise, you might find yourself doing the same fix to many cpu's
instead of "only" 5.

Then do the other ones and ask maintainers (or somebody else with
access to a suitable board on his desk) to perform the test. If you
could provide them with a few instructions, they can do the tests real
quick and you get consistent reports.

Regards,

-- 
Bas

[U-Boot] Timer Statics (was: arm926ejs: fix linker file for newer ld support)

[Reinhard Meyer]

Dear concerned,

>  - Move static variables to struct global_data, so they can be used
>    before relocation. Used by AT91 timers and proposed for A320 and
>    S3C64xx in:
> 
>    http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88095
>    http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88160
> 
> I hope we can solve this problem in the same way for all ARM timers. And
> if we use the second approach, we probably can generalize the AT91 data
> in struct global_data as proposed by Andreas.

The AT91 global data for clock/timer use has 2 parts:
#ifdef CONFIG_AT91FAMILY
	/* "static data" needed by at91's clock.c */
	unsigned long	cpu_clk_rate_hz;
	unsigned long	main_clk_rate_hz;
	unsigned long	mck_rate_hz;
	unsigned long	plla_rate_hz;
	unsigned long	pllb_rate_hz;
	unsigned long	at91_pllb_usb_init;
	/* "static data" needed by at91's timer.c */
	unsigned long	timer_rate_hz;
	unsigned long	tbl;
	unsigned long	tbu;
	unsigned long long	timer_reset_value;
#endif

I have removed reset_timer() from the AT91 timer now, making the global
variable "timer_reset_value" obsolete. For that all occurences of the
sequence

reset_timer();
...
loop .. if .. get_timer(0) >= timeout

has to be replaced by

u32 start_time = get_timer(0);
...
loop .. if .. get_timer(start_time) >= timeout

Currently, for AT91, that is only in the file
drivers/mtd/nand/nand_base.c

In that view, we could put
	unsigned long	timer_rate_hz;
	unsigned long	tbl;
	unsigned long	tbu;
outside the AT91FAMILY ifdef.

We can even split the timer implementation into two parts:
part 1 (hardware specific) implements a method to increment tbu/tbl
and exports the function get_ticks(), and
part 2 (hardware independant) uses get_ticks() and timer_rate_hz
to implement udelay() and get_timer().

Best Regards,
Reinhard

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Andreas Bießmann]

Dear Daniel Hobi,

Am 09.11.2010 um 19:24 schrieb Daniel Hobi:
> And on many ARM platforms (including Kirkwood), the timer implementation
> is still accessing BSS variables before relocation.
> 
> Is someone working on this? Candidates are:
> 
> $ git grep "static ulong timestamp"
> arch/arm/cpu/arm1136/mx31/timer.c:static ulong timestamp;
> arch/arm/cpu/arm1136/omap24xx/timer.c:static ulong timestamp;
> arch/arm/cpu/arm1176/tnetv107x/timer.c:static ulong timestamp;
> arch/arm/cpu/arm720t/interrupts.c:static ulong timestamp;
> arch/arm/cpu/arm920t/a320/timer.c:static ulong timestamp;
> arch/arm/cpu/arm920t/at91rm9200/timer.c:static ulong timestamp;

arch/arm/cpu/arm920t/at91rm9200/ is dead an will be removed soon.

arch/arm/cpu/arm920t/at91/ still misses such an implementation but will be something like arch/arm/cpu/arm926ejs/at91/

BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards?

regards

Andreas Bie?mann

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 09/11/2010 20:27, Andreas Bie?mann a ?crit :

> BTW couldn't the stuff in #ifdef CONFIG_AT91FAMILY in global_data generalized in some way to be used for all arm boards?

Don't know for others, but regarding the timer, there is no need for 
timestamp before relocation, so it needs not join gd stuff.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Eric Cooper]

I have been periodically rebasing my patches for the Seagate DockStar
on master.  But ever since the elf_reloc changes were merged, I have
been unable to get a working build.  First I saw symptoms similar to
what Alexander Holler reported (failing during NAND initialization due
to incorrect BSS relocation), but the latest arm926ejs ld script
patches did not fix it.  The system would hang here:

    U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38)
    Seagate FreeAgent DockStar

    SoC:   Kirkwood 88F6281_A0
    DRAM:  128 MiB
    NAND:  

This was built with the CodeSourcery 2010q1 toolchain.  I also
included Alexander's patch to double-check the relocation, and no
error message gets printed.

Today, I decided to try out Sebastien Carlier's patch to change to
partial linking, and to my surprise it now works.

I have the two ELF images in case anyone can suggest what I should
look for to see why one is working and the other isn't.  But I don't
know much about interpreting readelf or objdump output.

Also, I'd like to resubmit the latest version of the DockStar patch to
the list.  Should I base it on the partial-linking patch, or on master
(knowing that it may not produce a working build in this case)?

-- 
Eric Cooper             e c c @ c m u . e d u

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 10/11/2010 00:43, Eric Cooper a ?crit :
> I have been periodically rebasing my patches for the Seagate DockStar
> on master.  But ever since the elf_reloc changes were merged, I have
> been unable to get a working build.  First I saw symptoms similar to
> what Alexander Holler reported (failing during NAND initialization due
> to incorrect BSS relocation), but the latest arm926ejs ld script
> patches did not fix it.  The system would hang here:
>
>      U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38)
>      Seagate FreeAgent DockStar
>
>      SoC:   Kirkwood 88F6281_A0
>      DRAM:  128 MiB
>      NAND:
>
> This was built with the CodeSourcery 2010q1 toolchain.  I also
> included Alexander's patch to double-check the relocation, and no
> error message gets printed.
>
> Today, I decided to try out Sebastien Carlier's patch to change to
> partial linking, and to my surprise it now works.
>
> I have the two ELF images in case anyone can suggest what I should
> look for to see why one is working and the other isn't.  But I don't
> know much about interpreting readelf or objdump output.

Can you make the ELF images available? I'll do the readlf/objdump 
analysis and feed back on what I find.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Eric Cooper]

On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
> Can you make the ELF images available? I'll do the readlf/objdump 
> analysis and feed back on what I find.

I've uploaded them here:
    http://www.cs.cmu.edu/~ecc/u-boot.{good,bad}
Thanks.

-- 
Eric Cooper             e c c @ c m u . e d u

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 10/11/2010 15:20, Eric Cooper a ?crit :
> On Wed, Nov 10, 2010 at 08:53:03AM +0100, Albert ARIBAUD wrote:
>> Can you make the ELF images available? I'll do the readlf/objdump
>> analysis and feed back on what I find.
>
> I've uploaded them here:
>      http://www.cs.cmu.edu/~ecc/u-boot.{good,bad}
> Thanks.

I haven't found any obvious issue in the files for either good or bad 
case: relocation tables are generated and correct with only types 23 and 
2 records, and relocation symbols are produced and with the correct values.

the only one case I had where the code after correct relocation did not 
function properly was with tx25 where the hard-coded binary size in the 
config file was smaller than the actual binary size, causing only part 
of the relocation table to be read back from NAND to RAM, thus skipping 
a good deal of actual relocations. But here the "bad" case is smaller 
than the "good" case, so even if you're using a hard-coded binary size, 
*most probably* it is still ok.

Which means I cannot see why this code would not work with relocations, 
all the more so since S?bastien's patches do not touch compiler or 
linker flags unless I missed something. :/

However much I hate taking a "let's pretend it did not happen" stance, I 
think the most effective approach here is to consider that if no-one has 
issues with the ELF relocation V4 patch (Wolfgang? Alexander?) on 
currently supported boards, then it only causes problems on a 
not-yet-pulled-in board, so:

- V4 should be integrated now as a bug fix for existing supported boards;

- Dockstar support should be applied only after S?bastien's patches are.

Any comments?

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Daniel Hobi]

Hi Eric,

On 10.11.2010 00:43, Eric Cooper wrote:
> I have been periodically rebasing my patches for the Seagate DockStar
> on master.  But ever since the elf_reloc changes were merged, I have
> been unable to get a working build.  First I saw symptoms similar to
> what Alexander Holler reported (failing during NAND initialization due
> to incorrect BSS relocation), but the latest arm926ejs ld script
> patches did not fix it.  The system would hang here:
> 
>     U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38)
>     Seagate FreeAgent DockStar
> 
>     SoC:   Kirkwood 88F6281_A0
>     DRAM:  128 MiB
>     NAND:  
> 
> This was built with the CodeSourcery 2010q1 toolchain.  I also
> included Alexander's patch to double-check the relocation, and no
> error message gets printed.

Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not
access uninitialized data (variables timestamp and lastdec) before
relocation?

Otherwise timer_init() will write into the relocation table which may
lead to your problem. If you change unrelated code, timer_init() will
overwrite some other relocation table entries and U-Boot seems to work.

@Albert: If your patch is applied without fixing the accesses to BSS
before relocation, some ARM ports will be broken even when compiling
with ELDK 4.2.

Best regards,
Daniel

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 15/11/2010 15:15, Daniel Hobi a ?crit :

> @Albert: If your patch is applied without fixing the accesses to BSS
> before relocation, some ARM ports will be broken even when compiling
> with ELDK 4.2.

Thanks for pointing this out.

Indeed, my patch is actively based on the assumption that BSS is not 
used until after relocation, and I did this because not using BSS before 
relocation is already a known constraint.

I'll add a note in the commit.

 > Best regards,
 > Daniel

Amicalement,
-- 
Albert.

[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Eric Cooper]

On Mon, Nov 15, 2010 at 03:15:53PM +0100, Daniel Hobi wrote:
> Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not
> access uninitialized data (variables timestamp and lastdec) before
> relocation?

I didn't before, but now I have made that change (moved the static
vars in timer.c to global_data and reference them via gd).  But I get
the same behavior (freezing after printing "NAND: ").

Then I rebuilt my branch with the partial-linking patch applied, but
rebased on today's master, and now that fails in the same way.

So there's some low-level thing going on that unrelated changes in the
source code or build process seem to trigger.  Different link order,
code placement, phase of moon, ...?

I have a JTAG setup, but so far I've only used it to re-load u-boot to
RAM after a flashing a bad image.  If anyone can give me a clue how to
use it with gdb to debug what's going on, please let me know.

-- 
Eric Cooper             e c c @ c m u . e d u