[U-Boot-Users] [Fwd: Re: reducing size of u-boot binary]

[Jerry Van Baren]

vibi wrote:
> On Fri, 2007-12-14 at 07:20 -0500, Jerry Van Baren wrote:
>> vibi wrote:
>>> hello,
>>> 	can any one please tell me how to reduce the size of u-boot.bin.
>>> 	i tried by disabling commands in the
>>> 	include/config/at91rm9200dk.h,as per the read me document
>>> 	even after this when i compile,i was unable to decrease the 
>>> 	size.
>>>
>>> 	thanks in advance.
>>> 	
>>> 	regards
>>> 	vibi sreenivasan
>> How big is your binary, why do you need to reduce its size?  I ask 
>> because most of the time this question is the result of a link gone bad 
>> where part of the linked binary lives in low memory space and part lives 
>> in high memory space.  As a result, the .bin has a huge amount of filled 
>> (unused) data between the two.
>>
>> Best regards,
>> gvb
> 
> dear jerry,
> 	thanks for your reply.i am using u-boot 1.1.5 .my binary is only 90kb &
> i still wanted to reduce the size.i thought compiling u-boot is like
> compiling linux kernel,ie source file for the disabled commands wont get
> compiled,now i understood that i was wrong.
> 
> i wanted to reduce size to less than 90kb because of constraints in
> available flash memory space.
> 
> i have done it by disabling bootp & rarp by using #define macros
> i didnt find option for that in /include/cmd_confdefs.h .
> 
> once again i thank you for your response
> 
> thanks & regards
> vibi sreenivasan

Hi Vibi,

90K is already pretty small for a u-boot image.  I don't know how small 
u-boot can get, but rule of thumb is 128K is a reasonable size for good 
functionality.
   <http://www.denx.de/wiki/view/UBoot/DesignPrinciples>

With respect to the commands, disabling commands should cut the actual 
command code out via #ifdefs, so disabling commands should result in a 
smaller image, even though all the files are still compiled.
a) There is a limit to how much can be cut out by removing commands.
      There still is a lot of support code necessary.
b) It is possible that a command that is disabled needs a support
      function, but the support function isn't disabled so not all the
      potential savings are realized.

Note that u-boot is going to a better configuration and linking 
methodology that doesn't compile unused pieces (as opposed to compiling 
code that is #ifdefed out).  I don't expect this to save any significant 
amount of memory, but it is possible that it will turn up and fix errors 
or inefficiencies with the current method.

Best regards,
gvb