[U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL

[Marek Vasut]

Dear Tom Rini,

> On 09/18/12 12:25, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On 09/18/12 12:19, Marek Vasut wrote:
> >>> Dear Tom Rini,
> >>> 
> >>>> On 09/18/12 11:33, Marek Vasut wrote:
> >>>>> Dear Scott Wood,
> >>>> 
> >>>> [snip]
> >>>> 
> >>>>>> I think I got some wires crossed and was thinking about
> >>>>>> printf/puts. We want those to be optimized away at
> >>>>>> compile time (not pointed to a stub at link time) on an
> >>>>>> SPL that has no output support, but once that's done the
> >>>>>> low level serial functions shouldn't be referenced
> >>>>>> anymore, right?
> >>>>> 
> >>>>> But if you point them to stubs, that's OK. The compiler
> >>>>> will GC these useless stubs anyway. But wait, we're getting
> >>>>> to LTO here, right?
> >>>>> 
> >>>>> So the safest bet really is macro in serial.h ?
> >>>> 
> >>>> Due to the gcc bug I've mentioned before, yes.  Dummy
> >>>> functions will, I bet, keep the string constants around.  do
> >>>> {} while(0) will drop them out entirely.
> >>> 
> >>> Damn, not much gain on m28evk (with C functionss/with macros),
> >>> using gcc 4.7.1:
> >>> 
> >>> Configuring for m28evk board... text    data     bss     dec
> >>> hex filename 418994    7780  288632  715406   aea8e ./u-boot
> >>> 11773 788 12   12573    311d ./spl/u-boot-spl
> >>> 
> >>> Configuring for m28evk board... text    data     bss     dec
> >>> hex filename 418998    7780  288628  715406   aea8e ./u-boot
> >>> 11765 788 12   12565    3115 ./spl/u-boot-spl
> >> 
> >> Right, didn't have many strings.  But do you see what I mean now
> >> about not needing this patch as it stands currently?
> > 
> > No, I don't. If I remove this patch, the build breaks either
> > because serial_* is defined twice or not defined at all.
> 
> m28evk currently, needlessly, defines serial_puts/putc.  I locally
> patched master to drop them from arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> and the references in common/libcommon.o are correctly
> garbage-collected.  They are in fact unused functions today as they're
> garbage collected without patching, see spl/u-boot-spl.map after
> building.

I'd love to, this is what I get with my patchset when I remove the #ifdef from 
serial.c:

$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- ./MAKEALL m28evk
Configuring for m28evk board...
make[1]: *** [/home/marex/U-Boot/u-boot-marex/spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl.bin] Error 2
arm-linux-gnueabi-size: './u-boot': No such file
common/libcommon.o: In function `get_current':
/home/marex/U-Boot/u-boot-marex/common/serial.c:229: undefined reference to 
`default_serial_console'
make[1]: *** [/home/marex/U-Boot/u-boot-marex/spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl.bin] Error 2
make: *** Waiting for unfinished jobs....

So someone still has to implement default_serial_console() call. Is that fine ?

> So again I say, if common/serial.o is NOT being discard in
> your series on m28evk there is a bug in your series to fix or a change
> to better understand and document

Ok, I spent hours documenting this series. What else is there to document?

Besides, my team is starting to collect dead weight and we're running behind the 
schedule a lot ... I'm fucked, I'm desperate and I really don't know what to do 
anymore. Pardon if I'm a bit unpleasant to deal with recently.

> (and then see if we can change since
> as Scott notes, this needs to work for 4kb boards and that is tight).

What exactly are the 4k boards?

One more question -- if I have two __weak functions and one non-weak, the non-
weak wins and noone complains, right?

Best regards,
Marek Vasut