[U-Boot] Size of external u-boot commands

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Jon Smirl wrote:
> On Thu, Mar 26, 2009 at 9:52 AM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
>> Jon Smirl wrote:
>>> My networking hardware needs microcode loaded into it before it will
>>> function. What's the best method to load this code? It's 70KB.
>>>
>>> My current u-boot image is 170KB. I started working with the code in
>>> examples and api_examples. But the "hello world" programs built using
>>> those APIs are 65-72KB in size.  That's almost half the size of my
>>> u-boot image and these programs just print "hello world". Why are
>>> these programs so big? My goal was to put the loader program and my
>>> microcode into a single 128KB erase block.
>>>
>>> My code for loading the microcode into the hardware is 7KB. Now it
>>> looks like I will need to incorporate it into the main u-boot image
>>> instead of making it an external command.
>> Hi Jon,
>>
>> I suspect the example code is 98% C libraries and 2% nugget.  In your
>> example, "hello world" probably uses the whole printf support tree (strings,
>> formatted printing, possibly floating point...).
>>
>> I would suggest you make a stand-alone application that simply returns and
>> see how big it ends up.  Depending on whether that is small or not, check
>> what libraries get linked with it and see how to create your simple test app
>> such that it doesn't use any extraneous libraries.
> 
> Libraries appear to be the problem. A program that just returns is 100
> bytes, add a puts("hello world") and it is 65KB.
> 
> I had expected the u-boot app examples to be smart and use the copy of
> those libraries in the u-boot image. For example the demo program in
> api_examples uses printf (65K library) instead of building an api
> calling into u-boot for printf.

No, the u-boot interface is *much* more basic than a library interface, 
it is on the level of "read character" / "write character".  Making a 
trap interface at a library level would be a lot of work and would be a 
large source of problems for something that is a simple utility function 
(supporting stand-alone apps, that is)... a shared library interface is 
non-trivial for a full blown OS.

Library interface issues was the pain and screaming you (may have) heard 
when the world changed from a.out to DWARF to ELF and changing from 
glibc5 to glibc6, etc.

If you work a bit at it, you should not need to use libraries in your 
network loading app.  If you can get by with just returning error codes, 
you can do error printing back in u-boot.  If you need to print, use 
static strings so you don't pull in the world of string handling.  You 
may need to make your own print function (a limited printf() is pretty 
simple) that sends your strings out using the u-boot "putc" interface.

gvb