[U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base

Heiko Schocher hs at denx.de
Thu Sep 23 12:08:43 CEST 2010


Hello Albert,

Albert ARIBAUD wrote:
> Hello Heiko,
> 
> Thanks for the in-depth analysis.
> 
> IIUC:
> 
> Le 23/09/2010 09:12, Heiko Schocher a écrit :
> 
>> /home/hs/celf/u-boot/arch/arm/cpu/arm926ejs/start.S:212: Error: internal_relocation (type: OFFSET_IMM) not fixed up
>> /home/hs/celf/u-boot/arch/arm/cpu/arm926ejs/start.S:308: Error: internal_relocation (type: OFFSET_IMM) not fixed up
> 
> This is due to the fact you're using a specific .lds, and your fix below 
> corrects this for your .lds indeed. However, there might be other boards 

Yep.

> in the arm926 subtree which have their own .lds and would need the same 
> fix, so I'll find them all and extend your fix to others.

Hmm.. I don;t know the other boards ... so, I decided for
the relocation patches not to fix all arm boards, instead
inroduce the CONFIG_SYS_ARM_WITHOUT_RELOC, and board
maintainers (or others who have time for it) can adapt
the boards to this new code. So we always have a chance
to keep track which boards are converted *and* working
and which boards are not working ... so, I could not say,
if it is a good idea to fix other boards, you could not
test (I know, usually we do this fixes, but the relocation
code is such a deep change, I prefer to add only real
tested patches ...)

>> I had to define _got_base and _relocate_got_base_r also for
>> the NAND_SPL case, and don;t need to fix up the "pic base
>> register", if we are at the right position.
> 
> Thanks for spotting and fixing these. :)
> 
>> I think we(you ;-) should add my below fix to your
>>
>> [U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with	-msingle-pic-base
>>
>> and send a second version of it, so we are bisect compatible.
>>
>> you can add my
>>
>> Signed-off-by: Heiko Schocher<hs at denx.de>
>>
>> to it.
> 
> I will -- thanks!
> 
>> Can you test this also on your board? Thanks!
> 
> I will too. :)

Thanks!

> Just one thing: are these TEXT_BASE / CONFIG_SYS_NAND_U_BOOT_DST 
> modifications in your patch really needed for the board to run, or are 
> they a manual layout optimization decided based on the code size reduction?

Yes.
I decided for this board to set TEXT_BASE = CONFIG_SYS_NAND_U_BOOT_DST =
relocation address, so I can prevent one copying of u-boot code.
(The u-boot-nand code copy u-boot to CONFIG_SYS_NAND_U_BOOT_DST, which
 is on the later calculated relocation address -> no need to copy it
 again ... if there is more RAM on this board, u-boot of course copy
 itself to the higher address)

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


More information about the U-Boot mailing list