[U-Boot] patch for gc-sections

Peter Tyser ptyser at xes-inc.com
Thu Nov 4 16:45:48 CET 2010


On Thu, 2010-11-04 at 10:19 -0400, Haiying Wang wrote:
> On Wed, 2010-11-03 at 13:38 -0700, Peter Tyser wrote:
> > I'd guess none of the functions in the SPL binary are referenced in
> > the
> > linker script or linker command line, so the linker thinks none of
> > them
> > are necessary and removes them.
> > 
> > Can you try the following patch:
> > I did a quick compile test, and it seemed to work, as well as stripped
> > out a few unused functions.
> 
> Thanks for your patch, it did work to generate the binary, however,
> there are two problems: 
> 1. The u-boot size for nand_spl is not cut down as expected.
> /* before apply your new patch */
>  29292 2010-11-04 09:29 nand_spl/u-boot-spl
>      0 2010-11-04 09:29 nand_spl/u-boot-spl-16k.bin
>      0 2010-11-04 09:29 nand_spl/u-boot-spl.bin
>  13931 2010-11-04 09:29 nand_spl/u-boot-spl.map
> 
> /* After apply your new patch */
>     35636 2010-11-04 09:49 nand_spl/u-boot-spl
> 116912128 2010-11-04 09:49 nand_spl/u-boot-spl-16k.bin
>      4096 2010-11-04 09:49 nand_spl/u-boot-spl.bin
>     16381 2010-11-04 09:49 nand_spl/u-boot-spl.map
> 
> /* Remove your two patches(remove gc-section patch and this new patch */
>     34094 2010-11-04 09:51 nand_spl/u-boot-spl
> 116912128 2010-11-04 09:51 nand_spl/u-boot-spl-16k.bin
>      4096 2010-11-04 09:51 nand_spl/u-boot-spl.bin
>     14097 2010-11-04 09:51 nand_spl/u-boot-spl.map

Can you explain what you mean?  The binary needs to be 4K, right?  So it
can't be trimmed down.  But there should be more available space in that
4K region, eg (all tests on MPC8536DS_NAND_config):

/* After apply my patch sent yesterday */
ptyser at petert u-boot $ size after/u-boot-spl
   text    data     bss     dec     hex filename
   3440     460       0    3900     f3c after/u-boot-spl

/* Remove my two patches(remove gc-section patch and this new patch) */
ptyser at petert u-boot $ size before/u-boot-spl
   text	   data	    bss	    dec	    hex	filename
   3620	    460	      0	   4080	    ff0	before/u-boot-spl

The above says 180 bytes were removed between
fbe53f59bd40b3b1ab66dc98859e26589d64d1b7 and the current HEAD.  I'm
assuming some of that savings is due to -gc-sections (I think 2-3
functions were stripped out via -gc-sections).

You can just look at filesizes of ELF and map files to determine
savings, you'll have to use size/objdump/readelf to determine how the
code size is really affected.

> 2.the u-boot-spl.bin is 4096 bytes, and u-boot-spl-16.bin which should
> be padded to 4K bytes is 116912128 bytes. You can take a look at
> nand_spl/board/freescale/mpc8536ds/Makefile to see how
> u-boot-spl.bin/u-boot-spl-16k.bin is generated. I don't know which
> patch(not your gc-section for sure)  cause this problem. I just reset my
> git tree to 2010.06, the size is:
>  33512 2010-11-04 10:07 nand_spl/u-boot-spl
>  4096 2010-11-04 10:07 nand_spl/u-boot-spl-16k.bin
>  4096 2010-11-04 10:07 nand_spl/u-boot-spl.bin
>  14037 2010-11-04 10:07 nand_spl/u-boot-spl.map

I batted an eye when I saw the 112M file to, but it looks like that is
unrelated to my change:

/* Remove my two patches(remove gc-section patch and this new patch) */
ptyser at petert u-boot $ ls -lh after/
-rwxr-xr-x 1 ptyser users  36K 2010-11-04 10:25 u-boot-spl
-rwxr-xr-x 1 ptyser users 112M 2010-11-04 10:25 u-boot-spl-16k.bin
-rwxr-xr-x 1 ptyser users 4.0K 2010-11-04 10:25 u-boot-spl.bin
-rw-r--r-- 1 ptyser users  16K 2010-11-04 10:25 u-boot-spl.map

/* Remove my two patches(remove gc-section patch and this new patch) */
ptyser at petert u-boot $ ls -lh before/
-rwxr-xr-x 1 ptyser users  35K 2010-11-04 10:26 u-boot-spl
-rwxr-xr-x 1 ptyser users 112M 2010-11-04 10:26 u-boot-spl-16k.bin
-rwxr-xr-x 1 ptyser users 4.0K 2010-11-04 10:26 u-boot-spl.bin
-rw-r--r-- 1 ptyser users  13K 2010-11-04 10:26 u-boot-spl.map

The PAD_TO address is set to 0xfff01000, and each of
include/configs/MPC8536DS.h, include/configs/MPC8569MDS.h,
include/configs/P1_P2_RDB.h set CONFIG_SYS_TEXT_BASE to 0xf8f82000.

0xff01000 - 0xff82000 = 0x6F7F000 = 116912128 (as seen above).

Are these boards mis-configured?  In any case, everything seems to be
working as "expected" from what I can tell after the example patch I
sent yesterday.  Let me know if I'm missing something.

Best,
Peter



More information about the U-Boot mailing list