On 10/4/2010 10:06 AM, Wolfgang Denk wrote:
Dear "J. William Campbell",

In message<4ca9f294.8080...@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.tjernl...@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


_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to