[U-Boot] [PATCH 6/6] powerpc: Add LINK_OFF calls in early C-code.

[Joakim Tjernlund]

Scott Wood <scottwood at freescale.com> wrote on 2010/11/23 22:20:58:
>
> On Tue, 23 Nov 2010 22:03:36 +0100
> Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>
> > Scott Wood <scottwood at freescale.com> wrote on 2010/11/23 21:46:51:
> > > "Only these" that you've found so far, for the board you've tried --
> >
> > Yes, that is what I wrote.
>
> Yes, I was just emphasizing that. :-)
>
> > > is it worth adding another pre-relocation landmine to shrink the image
> > > by 5%?  I don't miss the manual fixups we had to do under the old
> > > relocation scheme.
> >
> > -msingle-pic-base does not require LINK_OFF per se. It will shrink the image
> > significantly for free. It enables impl. of true PIC and if you want to have
> > that too you need LINK_OFF.
>
> What is "true PIC" versus the rest of what -msingle-pic-base does, and
> what are the advantages?

Being able to load the same image to any address.
msingle-pic-base simple skips the PIC prologue and assumes the R30 is
already setup correctly. I a self contained env. like uboot this
is true for -fpic.
I use that property to copy the GOT to dcache,
relocate it there and point R30 to the GOT in dcache.

>
> > > Is a missing LINK_OFF likely to result in a crash, or silent bad
> > > behavior?  Will LINK_OFF be a no-op after relocation?
> >
> > Either crash or garbage printed on the port.
>
> Garbage possibly being empty strings that aren't noticed?
>
> Or possibly bad values changing program flow in nonobvious ways?

Impossible to say, I guess anything can happen.

>
> > LINK_OFF is a NOP after relocation. It will be a NOP
> > if link address == load address too.
>
> "load address" being pre-relocation?  Currently these must be equal
> (which doesn't seem particularly burdensome).

Yes, but in our case we update the boot in the field and we want to
make that safer by having two uboot areas but we don't want to carry around
two u-boot images.

I think Wolfgang had some other uses in mind too.

>
> Seems like there would be a high risk for a developer of board A to add
> new code that affects board B, and needs a manual relocation, but board
> A doesn't use this or loads at the link address, so it doesn't show up.
> Seems like a maintenance headache.

yes, it is a risk. One that can be minimized the more uses this function.