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 */ pty...@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) */ pty...@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) */ pty...@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) */ pty...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
