[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