[U-Boot] FPGA relocation/C environment

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Oct 29 17:39:35 CET 2009


wolfgang at leila.ping.de (Wolfgang Wegner) wrote on 29/10/2009 16:44:55:
>
> Hi,
>
> although I have to leave for now, just some questions to see if
> there is anything I understood correctly until now...
>
> - in the PPC startup (assembly) files, the section .got2 is explicitely
>   created using START_GOT etc.

It adds a few entries to .got2 as the asm needs to access a few entries vis the
GOT. If you look at the asm generated by gcc, it does the same for global data.

> - .got2 contains some vital pointers (vectors) as well as data
>   pointers like a pointer to .fixup and a pointer to itself (?!)

The first entry in got2 host a pointer to itself, this is needed by relocation later.
.fixup entries is created by -mrelocatable and WD has mentioned what these are for.

> - the ppc linker automatically puts .data.rel (and other relocatable
>   sections?) into .fixup (which seems not the case with my m68k linker)
> - the ppc startup code uses some obfuscated assembly code ;-) to
>   relocate both the global relocation table (.got) as well as the
>   sections .got2 and .fixup (.got seems to be implicitly mentioned:
>   "/* First our own GOT */
>    add   r14, r14, r15
>    /* then the one used by the C code */
>    add   r30, r30, r15"
>   but I can not see where it is actually relocated...)

As I recall that code is a leftover, at least the C version.
Relocation happens directly after the in_ram: label.
However, this is not you problem. You don't have any relocation entries
so there is nothing to relocate. Your linker/linker script is broken.

>
> Is this correct so far? I am not sure because it seems more complicated
> than necessary to me (especially the algorithm to relocate .got2 and
> .fixup - or is this all about the possibility to do multiple relocations?),
> so maybe I still have a misunderstanding here. Furthermore, the special
> handling of r14 (-ffixed-r14 in config.mk) still puzzles me.

The -ffixed-r14 is for IRQ procressing. The irq code needs to
jump to transfer_to_handler via the GOT and needs r14 to hold
a ptr to the GOT at all times. This can be avoided and I have a patch
to get rid of ffixed-r14 but only for mpc83xx so I or someone else
needs to do the other boards too before it can be committed.

  Jocke



More information about the U-Boot mailing list