[U-Boot] AT91: problems master vs. next

[Reinhard Meyer]

Dear Albert ARIBAUD,
> Le 21/09/2010 14:39, Reinhard Meyer a écrit :
>> Rebasing my current TOP9000 port on u-boot/next compiles
>> after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
>> Code size increased heavyly from 223592 to 245544.
>>
>> And U-Boot crashes instantly (I know there is more to be done
>> than just defining those two macros).
>>
>> What bothers me really here is the huge increase in code size.
> 
> I see numbers similar for orion5x based net5big, where non relocating 
> build is 117252 bytes while relocating build is 127120, a 8.4% increase 
> (yours is 9.8%).
> 
> This is due to the fact that each routine has to recompute the PIC 
> register. As a test, I tried adding -msingle-pic-base to -fPIC (this 
> computes the PIC register once for the whole code) and the code size 
> falls back to 123764 bytes, 'only' 5.5% more than the non relocating 
> case. Using -fPIE -pie -msingle-pic-base lowers this again to 5.2%.
> 
> Of course you cannot just turn -msingle-pic-base on; you've got to have 
> the code in start.S that computes the register. Also, switching from PIC 
> to PIE needs to be verified. I've got the code in my local tree, but 
> it's not tested yet. I'll test it tonight and post it if it works.
> 
>> And, on almost all AT91 systems booting will be through a
>> first boot loader, which sets up SDRAM, loads u-boot to the
>> "correct" address and jumps to it.
>> All low level init and relocation is not required in such cases.
>>
>> It should be always possible to #define relocation off!
> 
> On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and 
> CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board, 
> always skips lowlevel inits.

Yep, those are set and work well with master. However the extra almost 10%
of code increase (with next) will not go away with that.

Therefore I strongly suggest that all extras (PIC) needed solely for relocation
should be switchable OFF by a configuration option. Who does need that
relocation in the first place? For years ARM did work without it; why now
blowing up the code?

Reinhard