[U-Boot] ARM relocation, question to Heiko

[Albert ARIBAUD]

Le 04/10/2010 11:58, Graeme Russ a écrit :
> On 04/10/10 19:28, Albert ARIBAUD wrote:
>> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>>> Dear Albert ARIBAUD,
>>>>
>>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
>
> Any reason to do it in assembler? Have a look at arch/i386/lib/board.c
> board_init_f() (especially if you apply my latest patch series)

The main reasons are that start.S is historically responsible for 
setting up the C environment, and that only in assembly language can you 
ensure that no nasty relocation fixup is going to be required by the 
code that is precisely supposed to do the fixing up. Now it may be 
possible to do the fixups in C on ARM; that'll be a second step IMO.

>>>> of the .rel.dyn fixup entries are type 23, that is, relative to the base
>>>> address, which is good. However, here are about ten at the end which are
>>>> type 2 -- symbol-relative -- and I am studying them in order to see if
>>>> they are needed.
>
> Hmm, for x86 they are all type 8 (R_386_RELATIVE) which are a simple Base +
> Addend (B + A) entries
>
> Type 23 is R_ARM_RELATIVE which are also B + A (although they can also by S
> + A whatever that means)

23 is program base relative -- basically, subtract link-time image base 
address, add run-time image base address and you're set.

>>>> If type 23 relocations are all that is needed, then a first ARM ELF
>>>> relocation implementation should 'simply' trade GOT vs .rel.dyn
>>>> relocation in start.S (I am almost there) and remove fixups in
>
> Removing fixups - sweet, oh so sweet ;)

Apparently sweetness is not far away, see below. :)

>>>> board_init_r. Start.S would apply type 23 fixups only and ignore the
>>>> rest. Later on we could add a build stage to rewrite the .rel.dyn
>>>> section as suggested, by filtering out non-type-23 relocs and keeping
>>>> only the address part of type-23 ones, reducing the .rel.dyn table
>>>> roughly by half.
>
> Also non type-8 for x86 - If all arches reduce down to a single relocation
> type in .rel.dyn then we can ignore the type and simply strip all the
> 'type' fields.

Can't reduce to a single relocation type as produced by the linker, 
because references to linker-file-generated symbols seem to always be 
symbol-relative, not program-relative, even under -pie. This may be 
something to ask on the binutils mailing list, though.

> [snip]
>>
>>> A rather wild, but quite arch independant additional "build stage" for
>>> relocation would be to link u-boot for two different TEXT_BASE values
>>> e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special "diff"
>>> tool should find the 32 bit places where relocation is required and
>>> add a table to the end of u-boot.bin... (Just a rough idea)
>
> I don't think we need to - everything should be handled by .rel.dyn. I
> wrote a diff tool to do as you suggest, but I have no need for it now
>
> Looks like we could be onto a winner :)
>
> Regards,
>
> Graeme

At this point I have an ARM926, ELF-relocating, u-boot reaching prompt.

Environment is correctly read and can be modified (did not try saving 
though).

Flash operations work (flinfo, erase, cp.b).

Ethernet does not work, however -- ping or tftp just wait without me 
being able to ^C it. I'll look into that as soon as some domestic chores 
are done. :)

Amicalement,
-- 
Albert.