Hi Tomi, On Mon, Nov 28, 2011 at 3:45 PM, Tom Rini <tom.r...@gmail.com> wrote: > On Mon, Nov 21, 2011 at 4:57 PM, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot