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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
