[U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation

["Andreas Bießmann" <andreas.devel@googlemail.com>]

Dear Albert,

Am Mi 21 Sep 2011 16:23:56 CEST schrieb Albert ARIBAUD:
> Le 21/09/2011 14:31, Andreas Bie?mann a ?crit :
>> Dear Albert,
>>
>> Am Mi 21 Sep 2011 14:03:09 CEST schrieb Albert ARIBAUD:
>>> Le 21/09/2011 13:20, Andreas Bie?mann a ?crit :
>>>> Dear "GROYER, Anthony",
>>>> Dear Albert,
>>>>
>>>> Am Mi 21 Sep 2011 12:51:33 CEST schrieb Albert ARIBAUD:
>>>>> Le 21/09/2011 11:29, GROYER, Anthony a ?crit :

<snip>

> Apart from your question (how are the number of registers in ldmia and
> stmia speed related to the speed of the copy loop?) there is another
> one: how do we handle the fact that the length to copy may not be a
> multiple of the ldmia/stmia 'width'? Even in arm926ejs/start.S, two
> registers are used, but the alignment for text+data is 4 bytes, not 8.

Good point. Well, we could implement some 'rewind' apart from .bss
zeroing, if we care about it. I guess this could be done without any
impact to copy time, if we really save time by using more regs for
ldmia/stmia.

But how about reading beyond the _end symbol from flash crossing some
border e.g. end of address space, end of flash space ... ?

> This did not bite us so far, and should not, since we're going to copy
> into the space after .text, which *should* be .bss, which we'll zero
> right after. But Murphy's law could hit...
>
>>> As for r8, it should be preserved as it points to gd, but that is
>>> ensured by the C code already IIRC.
>>
>> We use -ffixed-r8 therefore the compiler takes care for the C part, but
>> we need to respect this in asm.
>
> in arm926ejs/start.S we do. If there are other start.S files where r8
> is trashed, they should be fixed indeed.

There should no one else left, my last changeset fixed it globally:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90010/focus=90013

best regards

Andreas Bie?mann