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

[Albert ARIBAUD <albert.aribaud@free.fr>]

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.