[U-Boot] [PATCH 3/7] Add support for SRAM Boot

[Scott Wood]

On Tue, 17 Aug 2010 11:20:00 +0200
Wolfgang Denk <wd at denx.de> wrote:

> In message <1282024011.2814.61.camel at localhost.localdomain> you wrote:
> > For this case, I need to call some functions like getenv, hwconfig,
> > printf, strcmp etc. which are needed in ddr spd code, but I don't want
> 
> I think this is a wrong approach. Instead, you should free the DDR
> code from such calls.

They're there for a reason, and space isn't so tight that we need to
drop console output and other features at this level.

In this specific case, we probably have room to suck in the full
implementations of printf and the string functions (I believe Haiying
is currently creating a 48K middle stage, while SRAM on this chip is
256K), so I think we could scale back on the intrusiveness of those
changes by letting the middle stage grow a bit...

> > Again, if those are not acceptable, do you have any suggestion on how to
> > pick the code for the functions I need to use in sram boot?
> 
> Change the approach. If you cannot afford the code size for these
> funtions, then do not use them.

...but "take this entire subsystem as is" or "go without anything
vaguely resembling this code, lest it be called 'duplication'" is a
rather limiting pair of choices.  It seems reasonable to refactor
things to be more modular (possibly in a nicer way than sprinkling
ifdefs), or provide an alternate trimmed-down implementation.

One thing that should probably be tried first, though, is
-ffunction-sections and --gc-sections, to have the linker discard any
functions that aren't referenced.  It seems some arches/boards already
use this.

-Scott