[U-Boot] Relocation size penalty calculation

Graeme Russ graeme.russ at gmail.com
Fri Oct 9 03:43:40 CEST 2009


On Fri, Oct 9, 2009 at 9:20 AM, Peter Tyser <ptyser at xes-inc.com> wrote:
> On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
>> On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk <wd at denx.de> wrote:
>> > Dear Graeme Russ,
>> >
>> > In message <d66caabb0910081358h5b013922tf7f9dce4cce41c64 at mail.gmail.com> you wrote:
>> >>
>> >>
>> >> Once the reloc branch has been merged, how many arches are left which do
>> >> not support relocation?
>> >
>> > All but PPC ?
>>
>> Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about
>> removing code that is not used because these arches do not do any
>> relocation at all?
>
> I sent that patch/RFC after noticing none of those architectures
> performed manual relocation fixups, thus they could save some code space
> by defining CONFIG_RELOC_FIXUP_WORKS.  Similarly the gd->reloc_off field
> was no longer needed for them.

Maybe CONFIG_RELOC_NOT_IMPLEMENTED would be more descriptive

>
> I'm not familiar with if or how those architectures are relocating, just
> that they didn't need relocation fixups.  So that was the logic...
>
>> So ultimately, what we are looking at is the complete and utter
>> removal of any code which references a relocation adjustment in lieu
>> of each arch either:
>>
>>   a) Execute in Place from Flash, or;
>>   b) Setting a fixed TEXT_BASE at a known RAM location and copying
>>      the contents of Flash to RAM, or;
>>   c) Implementing full Relocation
>
> d) Leaving those architectures the way they are now
> Could be added if a,b,c won't work for some reason too.

Which is essentially either a) or b) depending on which way the arch
was implemented. For x86, it has been b) but it is going towards c)

>
> I think it would be great to remove any manual relocation adjustments in
> the long run.  This isn't strictly necessary though, as we can still
> have manual relocations littering the code - its just a bit dirty and
> prone to issues in the long run.
>
> So my vote would be to shoot for c) for all arches, but I have no idea
> what impact that would have on them:)

So the big question now is - How many arches do partial relocation
and really need gd->reloc_off

>
> Best,
> Peter
>
>

Regards,

Graeme


More information about the U-Boot mailing list