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

Jerry Van Baren gerald.vanbaren at ge.com
Mon Dec 17 14:38:44 CET 2007

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 

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,

More information about the U-Boot mailing list