[U-Boot] Relocation size penalty calculation

[Peter Tyser <ptyser@xes-inc.com>]

On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
> On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Graeme Russ,
> >
> > In message <d66caabb0910081358h5b013922tf7f9dce4cce41c64@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.

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.

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:)

Best,
Peter