[U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature

[Simon Glass]

Hi Tomi,

On Mon, Nov 28, 2011 at 3:45 PM, Tom Rini <tom.rini at gmail.com> wrote:
> On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass <sjg at chromium.org> wrote:
>> This is the second patch series aiming to unify the various board.c files
>> in each architecture into a single one. This series creates a libboard
>> library and implements relocation in it. It then moves ARM over to use
>> this framework, as an example.
>>
>> On ARM the relocation code is duplicated for each CPU yet it
>> is the same. We can bring this up to the arch level. But since (I believe)
>> Elf relocation is basically the same process for all archs, there is no
>> reason not to bring it up to the generic level.
>>
>> This series establishes a new libboard library in the board/ subdir and
>> puts some relocation code in it. Each architecture which uses this
>> framework needs to provide a function called arch_elf_relocate_entry()
>> which processes a single relocation entry. If there is concern about
>> calling a function for all 2000-odd relocations then I can change this.
>>
>> For ARM, a new arch/arm/lib/proc.S file is created, which holds generic
>> ARM assembler code (things that cannot be written in C and are common
>> functions used by all ARM CPUs). This helps reduce duplication. Interrupt
>> handling code and perhaps even some startup code can move there later.
>>
>> It may be useful for other architectures to have a similar file.
>>
>> This series moves ARM over to use this framework. Overall this means that
>> two new files are required 'early' in boot: board/reloc.c and
>> arch/arm/lib/proc.S.  This is tricky mainly due to SPL. I believe that
>> we may need to adjust link scripts to put these two files early in the
>> link scripts also. But I am not sure about this and can't actually find
>> a problem as yet. I would much prefer to solve this with a new section
>> name like .text.early if we can.
>>
>> (I should really cc all arch maintainers but I think in that case I get
>> an error from the list server. Not sure what the limit is.)
>>
>> Comments please...
>
> Seems like a good idea.  Got some size's before and after?  Maybe some
> boot times too (as you mention 2000-odd function calls during
> relocation) ?

For my system it is currently 500us slower on a 320KB U-Boot binary
(so adding 0.5ms to a 95ms pre-relocation stage), It is currently 350
bytes larger.

I will see what I can do about the code size, and I expect the
performance penalty will reduce also, although it is already small.

Regards,
Simon

>
> --
> Tom