[U-Boot] ARM relocation, question to Heiko

[J. William Campbell <jwilliamcampbell@comcast.net>]

  On 10/4/2010 10:06 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4CA9F294.8080007@comcast.net>  you wrote:
>> Yes, I think Wolfgang is correct. This is not going to be easy to do in
>> general.  To run anywhere, the code must be true Position Independent
>> code. If you intend to use any C code in the initialization, this will
>> result in needing -fPIC for at least that code. I am not sure you can
>> mix -fPIC and non -fPIC code in the same link, but I expect not. I am a
>> bit surprised that it is possible to get even the initialization code to
>> be Position Independent, but it appears that on at least some PPC it is
>> possible/has been done.
> Not really. On PowerPC, only the first 20 or 30 lines of assembler
> code in start.S are position independent; then we compute the link
> (resp. execution) address and branch to it. From then, we run from the
> very address range we were linked for (starting at TEXT_BASE).
Hi Wolfgang,
      You are of course correct. I was referring more to Jocke's 
(joakim.tjernlund at transmode.se) statements regarding:

Yes, that is there today. I am talking about linking to any TEXT_BASE(say 0)
but burn and run into another address. I impl. this quite some time
ago for PPC(search for LINK_OFF)

         I understand from his comment that he had achieved total PIC for the initialization, that would run at any location regardless
of TEXT_BASE. I think this code was not accepted into mainline, so it is not a problem at present. However, any relocation code
added would have to be modified by Jocke if he wished to preserve that capability. I am amazed that he was able to get the
rest of u-boot to work under the constraints you pointed out. It must have been quite tedious.

       I also wish to support Graeme's desire that the added relocation code at the end of the day be written in C. The routine to do the
relocation does not require .bss and is not real long. The obvious advantage of this approach is that all architectures can use it. The
ELF relocation codes will have to be changed to the architecture equivalents, and in some casesarchitecture specific relocation code
processing added, but the theory will always be the same. This approach will make using relocation much easier/trivial for new
architecture  ports, thereby reducing resistance to doing it!

Best Regards,
Bill Campbell


>> Albert is doing now, and Graeme did before,  is the first option,
>> creating a loader that understands ELF. This has the advantage that it
>> will work on all architectures. However, once this understanding is in
>> place, it would be easy to write a small post-processing program that
>> would reduce the size of the relocation entries, much like -mrelocatable
>> does. This may or may not be necessary, but it is certainly possible.
> Eventually we might even add -mrelocatable support for the other
> architectures to the tool chain.
>
> Best regards,
>
> Wolfgang Denk
>