[U-Boot] ARM relocation, question to Heiko

[Joakim Tjernlund]

> Hello Reinhard,
>
> Reinhard Meyer wrote:
> > Dear Albert ARIBAUD,
> >>> I try to understand how the relocation process could handle pointers (to
> >>> functions or other data) in const or data sections.
> >>> Your code cannot know what is data and what is a pointer that needs
> >>> adjustment?
> >>>
> >>> Best Regards,
> >>> Reinhard
> >> Hi Reinhart,
> >>
> >> Short answer - the relocation process does not handle pointers inside
> >> data structures.
> >>
> >> And yes, this means the content arrays of pointers such as init_sequence
> >> is not relocated. Been there, done that, can give you one of the
>
> The init_sequence should not called anymore after relocation, as it is
> the init_sequence ... or?
>
> >> tee-shirts I got :)
> >>
> >> ATM I have not found a way to fix this, except making the code which
> >> uses the pointers aware that the are location-sensitive and fix them
> >> when using them.
> >
> > That means that things like this cannot work (with relocation),
> > unless adding the relocation offset before using the pointer:
>
> Yep, you have to fix these pointers after relocation ...
>
> > const struct {
> >    const u8 shift;
> >    const u8 idcode;
> >    struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
> > } flashes[] = {
> > #ifdef CONFIG_SPI_FLASH_SPANSION
> >    { 0, 0x01, spi_flash_probe_spansion, },
> > #endif
> [...]
> > #ifdef CONFIG_SPI_FRAM_RAMTRON
> >    { 6, 0xc2, spi_fram_probe_ramtron, },
> > # ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
> >    { 0, 0xff, spi_fram_probe_ramtron, },
> > # endif
> > # undef IDBUF_LEN
> > # define IDBUF_LEN 9 /* we need to read 6+3 bytes */
> > #endif
> > };
> >
> > And I think there are more places of this type in u-boot...
>
> Yes, maybe. But relocation as I did for arm, also works
> on m68k, sparc, mips, avr32 and they must do also this
> fixups, so for common functions (except the new env handling,
> which I think got never tested on this architectures?) should
> work ...

This pointer problem is solved with the fixup relocs on ppc and
should work without manual relocation. I think this is a ppc
only extension but I might be wrong.
I believe that the other alternative is to do it as x86 does
which I think is the general way which should work on any arch.
Graem Russ would know better.

 Jocke