[U-Boot] ARM relocation, question to Heiko

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear 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.

I agree here. _If_ relocation, it should work without hand-adding
fixup stuff to all functions using initialized data with pointers.
Even Wolfgang forgot to fixup his 2nd level command table in
cmd_nvedit.c ;)

And, for space concerns in flash, relocation should always be an
option on a board by board basis...

And as an idea, if position independent code is used, only pointers
in initialized data need adjustment. Cannot the linker emit a table
of addresses that need fixing?

Best Regards,
Reinhard