[U-Boot] ARM relocation, question to Heiko

[J. William Campbell]

  On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
>> 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.

Hi All,
       You are correct that this is a ppc only extension. As such, it is 
not a good candidate for "general" use.

> 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.
>
Almost exactly a year ago, this was all pretty much presented by Graeme 
in the threads
Relocation size penalty calculation (October 14, 2009)
i386 Relocation (November 24, 2009)

Using the full relocation scheme eliminates the need for all these 
"fixups" in u-boot C code. I think this is a very desirable result.
It is also not clear to me that hard coding in the relocation as several 
C routines will produce a  u-boot that is "smaller" than the one 
produced by using normal ELF relocation. However, using full relocation 
creates an environment that is true "C" and does not rely on people 
remembering that they may have to fix up some parts of their code. It is 
hard to see much downside in using the full relocation capability 
provided by Graeme's code.
FWIW, the relocation code and data does not have to be moved into ram if 
space is at a premium.

Best Regards,
Bill Campbell

>   Jocke
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>