[U-Boot] [PATCH 0/6] RFC: True PIC on 83xx

[Graeme Russ]

On Wed, Nov 24, 2010 at 8:08 AM, Joakim Tjernlund
<joakim.tjernlund at transmode.se> wrote:
> Wolfgang Denk <wd at denx.de> wrote on 2010/11/23 21:52:11:
>>
>> Dear Joakim Tjernlund,
>>
>> In message <1290538131-12383-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
>> > Here goes my attempt to revive true PIC on ppc, starting with 83xx.
>> > This uses a a new gcc option(which I have just impl.) to add
>> > msingle-pic-base also save a lot of code:
>>
>> Is my inderstanding correct that this is a private, all new gcc
>> extension?  Do you have plans to submit it upstream?
>>
>> I appreciate your work, and I, too, would like to be able to do what
>> this patch series seems to acchieve, but I think we should not add
>> this to mainline when neither mainline gcc nor any of the "common"
>> tool chains (say, OE/Yocto/LF, Linaro, CodeSourcery, ...) supports it.
>
> -msingle-pic-base already exist for ARM. I impl. it for PowerPC too.
> I have submitted it upstream and I hope it will be accepted, it is ongoing
> but slowly as there are very few ppc maintainers.
>

I'm still trying to get my head around exactly what the end benifit of
having this functionality is.

I implemented fully position independent image support for warm-boot (i.e.
bootstraped from pre-initialised memory for build-load-test) for x86. But
x86 is out of line with other arches in that it initialises memory and
relocates into RAM _before_ exectuting any of the init sequence. It is
the relocation prior to executing any other core U-Boot code which allows
full PIC on x86 to work.

Now I'm in the process of aligning x86 with the other arches (create a
temporary stack, run init sequence, init RAM, relocate) and I am going
to lose my full PIC functionality. Now while not ideal, it is not a game
breaker for me (especially now that I can easily specify a secondary
board with a different TEXT_BASE trivially in boards.cfg)

Is there any real benifit to be gained from diverging the feature sets
and implementation details at the architecture level when we have been
spending so much time and effort aligning them (ELF Relocation etc)

Regards,

Graeme