[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