* [U-Boot] [PATCH] Switch from archive libraries to partial linking
@ 2010-11-08 22:04 Sebastien Carlier
2010-11-08 22:10 ` Graeme Russ
` (7 more replies)
0 siblings, 8 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-08 22:04 UTC (permalink / raw)
To: u-boot
NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries
when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does
not extract archive members to resolve undefined weak symbols".
This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives,
which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols
as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target
(added at the end of config.mk and used in all Makefiles) is inspired.
The name of each former library archive is preserved except for extensions which change from ".a" to
".o". This commit updates references accordingly where needed, in particular in some linker scripts.
This commit reveals board configurations that exclude some module but not all of its dependencies; for
example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
---
Makefile | 118 ++++++++++++++--------------
api/Makefile | 4 +-
arch/arm/cpu/arm1136/Makefile | 4 +-
arch/arm/cpu/arm1136/mx31/Makefile | 4 +-
arch/arm/cpu/arm1136/omap24xx/Makefile | 4 +-
arch/arm/cpu/arm1176/Makefile | 4 +-
arch/arm/cpu/arm1176/s3c64xx/Makefile | 4 +-
arch/arm/cpu/arm1176/tnetv107x/Makefile | 4 +-
arch/arm/cpu/arm720t/Makefile | 4 +-
arch/arm/cpu/arm720t/lpc2292/Makefile | 4 +-
arch/arm/cpu/arm720t/s3c4510b/Makefile | 4 +-
arch/arm/cpu/arm920t/Makefile | 4 +-
arch/arm/cpu/arm920t/a320/Makefile | 4 +-
arch/arm/cpu/arm920t/at91/Makefile | 4 +-
arch/arm/cpu/arm920t/at91rm9200/Makefile | 4 +-
arch/arm/cpu/arm920t/ep93xx/Makefile | 4 +-
arch/arm/cpu/arm920t/imx/Makefile | 4 +-
arch/arm/cpu/arm920t/ks8695/Makefile | 4 +-
arch/arm/cpu/arm920t/s3c24x0/Makefile | 4 +-
arch/arm/cpu/arm925t/Makefile | 4 +-
arch/arm/cpu/arm926ejs/Makefile | 4 +-
arch/arm/cpu/arm926ejs/at91/Makefile | 4 +-
arch/arm/cpu/arm926ejs/davinci/Makefile | 4 +-
arch/arm/cpu/arm926ejs/kirkwood/Makefile | 4 +-
arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 4 +-
arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +-
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 +-
arch/arm/cpu/arm926ejs/nomadik/Makefile | 4 +-
arch/arm/cpu/arm926ejs/omap/Makefile | 4 +-
arch/arm/cpu/arm926ejs/orion5x/Makefile | 4 +-
arch/arm/cpu/arm926ejs/spear/Makefile | 4 +-
arch/arm/cpu/arm926ejs/versatile/Makefile | 4 +-
arch/arm/cpu/arm946es/Makefile | 4 +-
arch/arm/cpu/arm_intcm/Makefile | 4 +-
arch/arm/cpu/armv7/Makefile | 4 +-
arch/arm/cpu/armv7/mx5/Makefile | 4 +-
arch/arm/cpu/armv7/omap-common/Makefile | 4 +-
arch/arm/cpu/armv7/omap3/Makefile | 4 +-
arch/arm/cpu/armv7/omap4/Makefile | 4 +-
arch/arm/cpu/armv7/s5p-common/Makefile | 4 +-
arch/arm/cpu/armv7/s5pc1xx/Makefile | 4 +-
arch/arm/cpu/ixp/Makefile | 4 +-
arch/arm/cpu/ixp/npe/Makefile | 4 +-
arch/arm/cpu/lh7a40x/Makefile | 4 +-
arch/arm/cpu/pxa/Makefile | 4 +-
arch/arm/cpu/s3c44b0/Makefile | 4 +-
arch/arm/cpu/sa1100/Makefile | 4 +-
arch/arm/lib/Makefile | 10 +-
arch/avr32/cpu/Makefile | 4 +-
arch/avr32/cpu/at32ap700x/Makefile | 4 +-
arch/avr32/lib/Makefile | 4 +-
arch/blackfin/cpu/Makefile | 4 +-
arch/blackfin/lib/Makefile | 4 +-
arch/i386/cpu/Makefile | 4 +-
arch/i386/cpu/sc520/Makefile | 4 +-
arch/i386/lib/Makefile | 4 +-
arch/m68k/cpu/mcf5227x/Makefile | 4 +-
arch/m68k/cpu/mcf523x/Makefile | 4 +-
arch/m68k/cpu/mcf52x2/Makefile | 4 +-
arch/m68k/cpu/mcf532x/Makefile | 4 +-
arch/m68k/cpu/mcf5445x/Makefile | 4 +-
arch/m68k/cpu/mcf547x_8x/Makefile | 4 +-
arch/m68k/lib/Makefile | 4 +-
arch/microblaze/cpu/Makefile | 4 +-
arch/microblaze/lib/Makefile | 4 +-
arch/mips/cpu/Makefile | 4 +-
arch/mips/lib/Makefile | 4 +-
arch/nios2/cpu/Makefile | 4 +-
arch/nios2/lib/Makefile | 4 +-
arch/powerpc/cpu/74xx_7xx/Makefile | 4 +-
arch/powerpc/cpu/mpc512x/Makefile | 4 +-
arch/powerpc/cpu/mpc5xx/Makefile | 4 +-
arch/powerpc/cpu/mpc5xxx/Makefile | 4 +-
arch/powerpc/cpu/mpc8220/Makefile | 4 +-
arch/powerpc/cpu/mpc824x/Makefile | 4 +-
arch/powerpc/cpu/mpc8260/Makefile | 4 +-
arch/powerpc/cpu/mpc83xx/Makefile | 4 +-
arch/powerpc/cpu/mpc85xx/Makefile | 4 +-
arch/powerpc/cpu/mpc86xx/Makefile | 4 +-
arch/powerpc/cpu/mpc8xx/Makefile | 4 +-
arch/powerpc/cpu/mpc8xxx/Makefile | 4 +-
arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 4 +-
arch/powerpc/cpu/ppc4xx/Makefile | 4 +-
arch/powerpc/lib/Makefile | 4 +-
arch/sh/cpu/sh2/Makefile | 4 +-
arch/sh/cpu/sh3/Makefile | 4 +-
arch/sh/cpu/sh4/Makefile | 4 +-
arch/sh/lib/Makefile | 4 +-
arch/sparc/cpu/leon2/Makefile | 4 +-
arch/sparc/cpu/leon3/Makefile | 4 +-
arch/sparc/lib/Makefile | 4 +-
board/BuS/EB+MCF-EV123/Makefile | 4 +-
board/BuS/eb_cpux9k2/Makefile | 4 +-
board/LEOX/elpt860/Makefile | 4 +-
board/LaCie/edminiv2/Makefile | 4 +-
board/Marvell/db64360/Makefile | 4 +-
board/Marvell/db64460/Makefile | 4 +-
board/Marvell/guruplug/Makefile | 4 +-
board/Marvell/mv88f6281gtw_ge/Makefile | 4 +-
board/Marvell/openrd_base/Makefile | 4 +-
board/Marvell/rd6281a/Makefile | 4 +-
board/Marvell/sheevaplug/Makefile | 4 +-
board/RPXClassic/Makefile | 4 +-
board/RPXlite/Makefile | 4 +-
board/RPXlite_dw/Makefile | 4 +-
board/RRvision/Makefile | 4 +-
board/a3000/Makefile | 4 +-
board/a4m072/Makefile | 4 +-
board/actux1/Makefile | 4 +-
board/actux1/config.mk | 2 +-
board/actux2/Makefile | 4 +-
board/actux2/config.mk | 2 +-
board/actux3/Makefile | 4 +-
board/actux3/config.mk | 2 +-
board/actux4/Makefile | 4 +-
board/actux4/config.mk | 2 +-
board/adder/Makefile | 4 +-
board/afeb9260/Makefile | 4 +-
board/alaska/Makefile | 4 +-
board/altera/nios2-generic/Makefile | 4 +-
board/amcc/acadia/Makefile | 4 +-
board/amcc/bamboo/Makefile | 4 +-
board/amcc/bluestone/Makefile | 4 +-
board/amcc/bubinga/Makefile | 4 +-
board/amcc/canyonlands/Makefile | 4 +-
board/amcc/ebony/Makefile | 4 +-
board/amcc/katmai/Makefile | 4 +-
board/amcc/kilauea/Makefile | 4 +-
board/amcc/luan/Makefile | 4 +-
board/amcc/makalu/Makefile | 4 +-
board/amcc/ocotea/Makefile | 4 +-
board/amcc/redwood/Makefile | 4 +-
board/amcc/sequoia/Makefile | 4 +-
board/amcc/taihu/Makefile | 4 +-
board/amcc/taishan/Makefile | 4 +-
board/amcc/walnut/Makefile | 4 +-
board/amcc/yosemite/Makefile | 4 +-
board/amcc/yucca/Makefile | 4 +-
board/amirix/ap1000/Makefile | 4 +-
board/apollon/Makefile | 4 +-
board/armadillo/Makefile | 4 +-
board/armltd/integrator/Makefile | 4 +-
board/armltd/versatile/Makefile | 4 +-
board/armltd/vexpress/Makefile | 4 +-
board/assabet/Makefile | 4 +-
board/astro/mcf5373l/Makefile | 4 +-
board/atc/Makefile | 4 +-
board/atmel/at91cap9adk/Makefile | 4 +-
board/atmel/at91rm9200dk/Makefile | 4 +-
board/atmel/at91rm9200ek/Makefile | 4 +-
board/atmel/at91sam9260ek/Makefile | 4 +-
board/atmel/at91sam9261ek/Makefile | 4 +-
board/atmel/at91sam9263ek/Makefile | 4 +-
board/atmel/at91sam9m10g45ek/Makefile | 4 +-
board/atmel/at91sam9rlek/Makefile | 4 +-
board/atmel/atngw100/Makefile | 4 +-
board/atmel/atstk1000/Makefile | 4 +-
board/atum8548/Makefile | 4 +-
board/balloon3/Makefile | 4 +-
board/barco/Makefile | 4 +-
board/bc3450/Makefile | 4 +-
board/bct-brettl2/Makefile | 4 +-
board/bf518f-ezbrd/Makefile | 4 +-
board/bf526-ezbrd/Makefile | 4 +-
board/bf527-ad7160-eval/Makefile | 4 +-
board/bf527-ezkit/Makefile | 4 +-
board/bf527-sdp/Makefile | 4 +-
board/bf533-ezkit/Makefile | 4 +-
board/bf533-stamp/Makefile | 4 +-
board/bf537-minotaur/Makefile | 4 +-
board/bf537-pnav/Makefile | 4 +-
board/bf537-srv1/Makefile | 4 +-
board/bf537-stamp/Makefile | 4 +-
board/bf538f-ezkit/Makefile | 4 +-
board/bf548-ezkit/Makefile | 4 +-
board/bf561-acvilon/Makefile | 4 +-
board/bf561-ezkit/Makefile | 4 +-
board/blackstamp/Makefile | 4 +-
board/blackvme/Makefile | 4 +-
board/bmw/Makefile | 4 +-
board/c2mon/Makefile | 4 +-
board/calao/sbc35_a9g20/Makefile | 4 +-
board/calao/tny_a9260/Makefile | 4 +-
board/canmb/Makefile | 4 +-
board/cerf250/Makefile | 4 +-
board/cm-bf527/Makefile | 4 +-
board/cm-bf533/Makefile | 4 +-
board/cm-bf537e/Makefile | 4 +-
board/cm-bf537u/Makefile | 4 +-
board/cm-bf548/Makefile | 4 +-
board/cm-bf561/Makefile | 4 +-
board/cm4008/Makefile | 4 +-
board/cm41xx/Makefile | 4 +-
board/cm5200/Makefile | 4 +-
board/cmc_pu2/Makefile | 4 +-
board/cmi/Makefile | 4 +-
board/cobra5272/Makefile | 4 +-
board/cogent/Makefile | 4 +-
board/colibri_pxa270/Makefile | 4 +-
board/cpc45/Makefile | 4 +-
board/cpu86/Makefile | 4 +-
board/cpu87/Makefile | 4 +-
board/cradle/Makefile | 4 +-
board/cray/L1/Makefile | 4 +-
board/csb226/Makefile | 4 +-
board/csb272/Makefile | 4 +-
board/csb472/Makefile | 4 +-
board/csb637/Makefile | 4 +-
board/cu824/Makefile | 4 +-
board/dave/B2/Makefile | 4 +-
board/dave/PPChameleonEVB/Makefile | 4 +-
board/davedenx/aria/Makefile | 4 +-
board/davedenx/qong/Makefile | 4 +-
board/davinci/common/Makefile | 4 +-
board/davinci/da8xxevm/Makefile | 4 +-
board/davinci/dm355evm/Makefile | 4 +-
board/davinci/dm355leopard/Makefile | 4 +-
board/davinci/dm365evm/Makefile | 4 +-
board/davinci/dm6467evm/Makefile | 4 +-
board/davinci/dvevm/Makefile | 4 +-
board/davinci/schmoogie/Makefile | 4 +-
board/davinci/sffsdr/Makefile | 4 +-
board/davinci/sonata/Makefile | 4 +-
board/dbau1x00/Makefile | 4 +-
board/digsy_mtc/Makefile | 4 +-
board/dnp1110/Makefile | 4 +-
board/eNET/Makefile | 4 +-
board/eXalion/Makefile | 4 +-
board/earthlcd/favr-32-ezkit/Makefile | 4 +-
board/edb93xx/Makefile | 4 +-
board/eltec/bab7xx/Makefile | 4 +-
board/eltec/elppc/Makefile | 4 +-
board/eltec/mhpc/Makefile | 4 +-
board/emk/top5200/Makefile | 4 +-
board/emk/top860/Makefile | 4 +-
board/ep7312/Makefile | 4 +-
board/ep8248/Makefile | 4 +-
board/ep8260/Makefile | 4 +-
board/ep82xxm/Makefile | 4 +-
board/ep88x/Makefile | 4 +-
board/eric/Makefile | 4 +-
board/esd/adciop/Makefile | 4 +-
board/esd/apc405/Makefile | 4 +-
board/esd/ar405/Makefile | 4 +-
board/esd/ash405/Makefile | 4 +-
board/esd/canbt/Makefile | 4 +-
board/esd/cms700/Makefile | 4 +-
board/esd/cpci2dp/Makefile | 4 +-
board/esd/cpci405/Makefile | 4 +-
board/esd/cpci5200/Makefile | 4 +-
board/esd/cpci750/Makefile | 4 +-
board/esd/cpciiser4/Makefile | 4 +-
board/esd/dasa_sim/Makefile | 4 +-
board/esd/dp405/Makefile | 4 +-
board/esd/du405/Makefile | 4 +-
board/esd/du440/Makefile | 4 +-
board/esd/hh405/Makefile | 4 +-
board/esd/hub405/Makefile | 4 +-
board/esd/mecp5123/Makefile | 4 +-
board/esd/mecp5200/Makefile | 4 +-
board/esd/meesc/Makefile | 4 +-
board/esd/ocrtc/Makefile | 4 +-
board/esd/otc570/Makefile | 4 +-
board/esd/pci405/Makefile | 6 +-
board/esd/pf5200/Makefile | 4 +-
board/esd/plu405/Makefile | 4 +-
board/esd/pmc405/Makefile | 4 +-
board/esd/pmc405de/Makefile | 4 +-
board/esd/pmc440/Makefile | 4 +-
board/esd/tasreg/Makefile | 4 +-
board/esd/vme8349/Makefile | 4 +-
board/esd/voh405/Makefile | 4 +-
board/esd/vom405/Makefile | 4 +-
board/esd/wuh405/Makefile | 4 +-
board/espt/Makefile | 4 +-
board/esteem192e/Makefile | 4 +-
board/etin/debris/Makefile | 4 +-
board/etin/kvme080/Makefile | 4 +-
board/etx094/Makefile | 4 +-
board/eukrea/cpu9260/Makefile | 4 +-
board/eukrea/cpuat91/Makefile | 4 +-
board/evb4510/Makefile | 4 +-
board/evb64260/Makefile | 4 +-
board/fads/Makefile | 4 +-
board/faraday/a320evb/Makefile | 4 +-
board/flagadm/Makefile | 4 +-
board/freescale/common/Makefile | 4 +-
board/freescale/corenet_ds/Makefile | 4 +-
board/freescale/m5208evbe/Makefile | 4 +-
board/freescale/m5208evbe/u-boot.lds | 4 +-
board/freescale/m52277evb/Makefile | 4 +-
board/freescale/m52277evb/u-boot.spa | 6 +-
board/freescale/m5235evb/Makefile | 4 +-
board/freescale/m5235evb/u-boot.32 | 4 +-
board/freescale/m5249evb/Makefile | 4 +-
board/freescale/m5253demo/Makefile | 4 +-
board/freescale/m5253evbe/Makefile | 4 +-
board/freescale/m5271evb/Makefile | 4 +-
board/freescale/m5271evb/u-boot.lds | 2 +-
board/freescale/m5272c3/Makefile | 4 +-
board/freescale/m5275evb/Makefile | 4 +-
board/freescale/m5282evb/Makefile | 4 +-
board/freescale/m53017evb/Makefile | 4 +-
board/freescale/m53017evb/u-boot.lds | 4 +-
board/freescale/m5329evb/Makefile | 4 +-
board/freescale/m5373evb/Makefile | 4 +-
board/freescale/m54451evb/Makefile | 4 +-
board/freescale/m54451evb/u-boot.spa | 6 +-
board/freescale/m54455evb/Makefile | 4 +-
board/freescale/m547xevb/Makefile | 4 +-
board/freescale/m548xevb/Makefile | 4 +-
board/freescale/mpc5121ads/Makefile | 4 +-
board/freescale/mpc7448hpc2/Makefile | 4 +-
board/freescale/mpc8260ads/Makefile | 4 +-
board/freescale/mpc8266ads/Makefile | 4 +-
board/freescale/mpc8308rdb/Makefile | 4 +-
board/freescale/mpc8313erdb/Makefile | 4 +-
board/freescale/mpc8315erdb/Makefile | 4 +-
board/freescale/mpc8323erdb/Makefile | 4 +-
board/freescale/mpc832xemds/Makefile | 4 +-
board/freescale/mpc8349emds/Makefile | 4 +-
board/freescale/mpc8349itx/Makefile | 4 +-
board/freescale/mpc8360emds/Makefile | 4 +-
board/freescale/mpc8360erdk/Makefile | 4 +-
board/freescale/mpc837xemds/Makefile | 4 +-
board/freescale/mpc837xerdb/Makefile | 4 +-
board/freescale/mpc8536ds/Makefile | 4 +-
board/freescale/mpc8540ads/Makefile | 4 +-
board/freescale/mpc8541cds/Makefile | 4 +-
board/freescale/mpc8544ds/Makefile | 4 +-
board/freescale/mpc8548cds/Makefile | 4 +-
board/freescale/mpc8555cds/Makefile | 4 +-
board/freescale/mpc8560ads/Makefile | 4 +-
board/freescale/mpc8568mds/Makefile | 4 +-
board/freescale/mpc8569mds/Makefile | 4 +-
board/freescale/mpc8572ds/Makefile | 4 +-
board/freescale/mpc8610hpcd/Makefile | 4 +-
board/freescale/mpc8641hpcn/Makefile | 4 +-
board/freescale/mx31ads/Makefile | 4 +-
board/freescale/mx31ads/u-boot.lds | 8 +-
board/freescale/mx31pdk/Makefile | 4 +-
board/freescale/mx51evk/Makefile | 4 +-
board/freescale/p1022ds/Makefile | 4 +-
board/freescale/p1_p2_rdb/Makefile | 4 +-
board/freescale/p2020ds/Makefile | 4 +-
board/funkwerk/vovpn-gw/Makefile | 4 +-
board/g2000/Makefile | 4 +-
board/gaisler/gr_cpci_ax2000/Makefile | 4 +-
board/gaisler/gr_ep2s60/Makefile | 4 +-
board/gaisler/gr_xc3s_1500/Makefile | 4 +-
board/gaisler/grsim/Makefile | 4 +-
board/gaisler/grsim_leon2/Makefile | 4 +-
board/galaxy5200/Makefile | 4 +-
board/gcplus/Makefile | 4 +-
board/gdsys/405ep/Makefile | 4 +-
board/gdsys/common/Makefile | 4 +-
board/gdsys/dlvision/Makefile | 4 +-
board/gdsys/gdppc440etx/Makefile | 4 +-
board/gdsys/intip/Makefile | 4 +-
board/gdsys/neo/Makefile | 4 +-
board/gen860t/Makefile | 4 +-
board/genietv/Makefile | 4 +-
board/gth2/Makefile | 4 +-
board/gw8260/Makefile | 4 +-
board/hermes/Makefile | 4 +-
board/hidden_dragon/Makefile | 4 +-
board/hymod/Makefile | 4 +-
board/ibf-dsp561/Makefile | 4 +-
board/icecube/Makefile | 4 +-
board/icu862/Makefile | 4 +-
board/idmr/Makefile | 4 +-
board/idmr/u-boot.lds | 2 +-
board/ids8247/Makefile | 4 +-
board/impa7/Makefile | 4 +-
board/imx31_phycore/Makefile | 4 +-
board/incaip/Makefile | 4 +-
board/inka4x0/Makefile | 4 +-
board/innokom/Makefile | 4 +-
board/ip04/Makefile | 4 +-
board/ip860/Makefile | 4 +-
board/ipek01/Makefile | 4 +-
board/iphase4539/Makefile | 4 +-
board/isee/igep0020/Makefile | 4 +-
board/isee/igep0030/Makefile | 4 +-
board/ispan/Makefile | 4 +-
board/ivm/Makefile | 4 +-
board/ixdp425/Makefile | 4 +-
board/jornada/Makefile | 4 +-
board/jse/Makefile | 4 +-
board/jupiter/Makefile | 4 +-
board/karo/tx25/Makefile | 4 +-
board/kb9202/Makefile | 4 +-
board/keymile/km8xx/Makefile | 4 +-
board/keymile/km_arm/Makefile | 4 +-
board/keymile/kmeter1/Makefile | 4 +-
board/keymile/mgcoge/Makefile | 4 +-
board/korat/Makefile | 4 +-
board/kup/Makefile | 4 +-
board/kup/kup4k/Makefile | 4 +-
board/kup/kup4x/Makefile | 4 +-
board/lantec/Makefile | 4 +-
board/lart/Makefile | 4 +-
board/linkstation/Makefile | 4 +-
board/logicpd/am3517evm/Makefile | 4 +-
board/logicpd/imx27lite/Makefile | 4 +-
board/logicpd/imx31_litekit/Makefile | 4 +-
board/logicpd/zoom1/Makefile | 4 +-
board/logicpd/zoom2/Makefile | 4 +-
board/lpc2292sodimm/Makefile | 4 +-
board/lpd7a40x/Makefile | 4 +-
board/lubbock/Makefile | 4 +-
board/lwmon/Makefile | 4 +-
board/lwmon5/Makefile | 4 +-
board/m501sk/Makefile | 4 +-
board/manroland/hmi1001/Makefile | 4 +-
board/manroland/mucmc52/Makefile | 4 +-
board/manroland/uc100/Makefile | 4 +-
board/manroland/uc101/Makefile | 4 +-
board/matrix_vision/common/Makefile | 4 +-
board/matrix_vision/mvbc_p/Makefile | 4 +-
board/matrix_vision/mvblm7/Makefile | 4 +-
board/matrix_vision/mvsmr/Makefile | 4 +-
board/mbx8xx/Makefile | 4 +-
board/mcc200/Makefile | 4 +-
board/micronas/vct/Makefile | 4 +-
board/mimc/mimc200/Makefile | 4 +-
board/miromico/hammerhead/Makefile | 4 +-
board/ml2/Makefile | 4 +-
board/modnet50/Makefile | 4 +-
board/mosaixtech/icon/Makefile | 4 +-
board/motionpro/Makefile | 4 +-
board/mousse/Makefile | 4 +-
board/mp2usb/Makefile | 4 +-
board/mpc8308_p1m/Makefile | 4 +-
board/mpc8540eval/Makefile | 4 +-
board/mpl/mip405/Makefile | 4 +-
board/mpl/pati/Makefile | 4 +-
board/mpl/pip405/Makefile | 4 +-
board/mpl/vcma9/Makefile | 4 +-
board/mpr2/Makefile | 4 +-
board/ms7720se/Makefile | 4 +-
board/ms7722se/Makefile | 4 +-
board/ms7750se/Makefile | 4 +-
board/muas3001/Makefile | 4 +-
board/munices/Makefile | 4 +-
board/musenki/Makefile | 4 +-
board/mvblue/Makefile | 4 +-
board/mx1ads/Makefile | 4 +-
board/mx1fs2/Makefile | 4 +-
board/netphone/Makefile | 4 +-
board/netstal/hcu4/Makefile | 4 +-
board/netstal/hcu5/Makefile | 4 +-
board/netstal/mcu25/Makefile | 4 +-
board/netstar/Makefile | 4 +-
board/netta/Makefile | 4 +-
board/netta2/Makefile | 4 +-
board/netvia/Makefile | 4 +-
board/ns9750dev/Makefile | 4 +-
board/nx823/Makefile | 4 +-
board/o2dnt/Makefile | 4 +-
board/overo/Makefile | 4 +-
board/oxc/Makefile | 4 +-
board/palmld/Makefile | 4 +-
board/palmtc/Makefile | 4 +-
board/pandora/Makefile | 4 +-
board/pb1x00/Makefile | 4 +-
board/pcippc2/Makefile | 4 +-
board/pcs440ep/Makefile | 4 +-
board/pdm360ng/Makefile | 4 +-
board/phytec/pcm030/Makefile | 4 +-
board/pleb2/Makefile | 4 +-
board/pm520/Makefile | 4 +-
board/pm826/Makefile | 4 +-
board/pm828/Makefile | 4 +-
board/pm854/Makefile | 4 +-
board/pm856/Makefile | 4 +-
board/pn62/Makefile | 4 +-
board/ppmc7xx/Makefile | 4 +-
board/ppmc8260/Makefile | 4 +-
board/prodrive/alpr/Makefile | 4 +-
board/prodrive/p3mx/Makefile | 4 +-
board/prodrive/p3p440/Makefile | 4 +-
board/prodrive/pdnb3/Makefile | 4 +-
board/psyent/pci5441/Makefile | 4 +-
board/psyent/pk1c20/Makefile | 4 +-
board/purple/Makefile | 4 +-
board/pxa255_idp/Makefile | 4 +-
board/qemu-mips/Makefile | 4 +-
board/quad100hd/Makefile | 4 +-
board/quantum/Makefile | 4 +-
board/r360mpi/Makefile | 4 +-
board/rattler/Makefile | 4 +-
board/rbc823/Makefile | 4 +-
board/renesas/MigoR/Makefile | 4 +-
board/renesas/ap325rxa/Makefile | 4 +-
board/renesas/r2dplus/Makefile | 4 +-
board/renesas/r7780mp/Makefile | 4 +-
board/renesas/rsk7203/Makefile | 4 +-
board/renesas/sh7763rdp/Makefile | 4 +-
board/renesas/sh7785lcr/Makefile | 4 +-
board/rmu/Makefile | 4 +-
board/ronetix/pm9261/Makefile | 4 +-
board/ronetix/pm9263/Makefile | 4 +-
board/ronetix/pm9g45/Makefile | 4 +-
board/rpxsuper/Makefile | 4 +-
board/rsdproto/Makefile | 4 +-
board/sacsng/Makefile | 4 +-
board/samsung/goni/Makefile | 4 +-
board/samsung/smdk2400/Makefile | 4 +-
board/samsung/smdk2410/Makefile | 4 +-
board/samsung/smdk6400/Makefile | 4 +-
board/samsung/smdkc100/Makefile | 4 +-
board/sandburst/karef/Makefile | 4 +-
board/sandburst/metrobox/Makefile | 4 +-
board/sandpoint/Makefile | 4 +-
board/sbc2410x/Makefile | 4 +-
board/sbc405/Makefile | 4 +-
board/sbc8240/Makefile | 4 +-
board/sbc8260/Makefile | 4 +-
board/sbc8349/Makefile | 4 +-
board/sbc8548/Makefile | 4 +-
board/sbc8560/Makefile | 4 +-
board/sbc8641d/Makefile | 4 +-
board/sc3/Makefile | 4 +-
board/scb9328/Makefile | 4 +-
board/shannon/Makefile | 4 +-
board/sheldon/simpc8313/Makefile | 4 +-
board/siemens/IAD210/Makefile | 4 +-
board/siemens/SCM/Makefile | 4 +-
board/siemens/SMN42/Makefile | 4 +-
board/sixnet/Makefile | 4 +-
board/snmc/qs850/Makefile | 4 +-
board/snmc/qs860t/Makefile | 4 +-
board/socrates/Makefile | 4 +-
board/sorcery/Makefile | 4 +-
board/spc1920/Makefile | 4 +-
board/spd8xx/Makefile | 4 +-
board/spear/common/Makefile | 4 +-
board/spear/spear300/Makefile | 4 +-
board/spear/spear310/Makefile | 4 +-
board/spear/spear320/Makefile | 4 +-
board/spear/spear600/Makefile | 4 +-
board/st/nhk8815/Makefile | 4 +-
board/stx/stxgp3/Makefile | 4 +-
board/stx/stxssa/Makefile | 4 +-
board/stx/stxxtc/Makefile | 4 +-
board/svm_sc8xx/Makefile | 4 +-
board/sx1/Makefile | 4 +-
board/syteco/jadecpu/Makefile | 4 +-
board/t3corp/Makefile | 4 +-
board/tb0229/Makefile | 4 +-
board/tcm-bf518/Makefile | 4 +-
board/tcm-bf537/Makefile | 4 +-
board/ti/beagle/Makefile | 4 +-
board/ti/evm/Makefile | 4 +-
board/ti/omap1510inn/Makefile | 4 +-
board/ti/omap1610inn/Makefile | 4 +-
board/ti/omap2420h4/Makefile | 4 +-
board/ti/omap5912osk/Makefile | 4 +-
board/ti/omap730p2/Makefile | 4 +-
board/ti/panda/Makefile | 4 +-
board/ti/sdp3430/Makefile | 4 +-
board/ti/sdp4430/Makefile | 4 +-
board/ti/tnetv107xevm/Makefile | 4 +-
board/timll/devkit8000/Makefile | 4 +-
board/total5200/Makefile | 4 +-
board/tqc/tqm5200/Makefile | 4 +-
board/tqc/tqm8260/Makefile | 4 +-
board/tqc/tqm8272/Makefile | 4 +-
board/tqc/tqm834x/Makefile | 4 +-
board/tqc/tqm85xx/Makefile | 4 +-
board/tqc/tqm8xx/Makefile | 4 +-
board/trab/Makefile | 4 +-
board/trizepsiv/Makefile | 4 +-
board/ttcontrol/vision2/Makefile | 4 +-
board/utx8245/Makefile | 4 +-
board/v37/Makefile | 4 +-
board/v38b/Makefile | 4 +-
board/ve8313/Makefile | 4 +-
board/voiceblue/Makefile | 4 +-
board/vpac270/Makefile | 4 +-
board/w7o/Makefile | 4 +-
board/westel/amx860/Makefile | 4 +-
board/xaeniax/Makefile | 4 +-
board/xes/common/Makefile | 4 +-
board/xes/xpedite1000/Makefile | 4 +-
board/xes/xpedite517x/Makefile | 4 +-
board/xes/xpedite520x/Makefile | 4 +-
board/xes/xpedite537x/Makefile | 4 +-
board/xes/xpedite550x/Makefile | 4 +-
board/xilinx/microblaze-generic/Makefile | 4 +-
board/xilinx/ppc405-generic/Makefile | 4 +-
board/xilinx/ppc440-generic/Makefile | 4 +-
board/xm250/Makefile | 4 +-
board/zeus/Makefile | 4 +-
board/zipitz2/Makefile | 4 +-
board/zpc1900/Makefile | 4 +-
board/zylonite/Makefile | 4 +-
common/Makefile | 4 +-
config.mk | 6 ++
disk/Makefile | 4 +-
drivers/bios_emulator/Makefile | 4 +-
drivers/block/Makefile | 4 +-
drivers/dma/Makefile | 4 +-
drivers/fpga/Makefile | 4 +-
drivers/gpio/Makefile | 4 +-
drivers/hwmon/Makefile | 4 +-
drivers/i2c/Makefile | 4 +-
drivers/input/Makefile | 4 +-
drivers/misc/Makefile | 4 +-
drivers/mmc/Makefile | 4 +-
drivers/mtd/Makefile | 4 +-
drivers/mtd/nand/Makefile | 4 +-
drivers/mtd/onenand/Makefile | 4 +-
drivers/mtd/spi/Makefile | 4 +-
drivers/mtd/ubi/Makefile | 4 +-
drivers/net/Makefile | 4 +-
drivers/net/phy/Makefile | 4 +-
drivers/pci/Makefile | 4 +-
drivers/pcmcia/Makefile | 4 +-
drivers/power/Makefile | 4 +-
drivers/qe/Makefile | 4 +-
drivers/rtc/Makefile | 4 +-
drivers/serial/Makefile | 4 +-
drivers/spi/Makefile | 4 +-
drivers/twserial/Makefile | 4 +-
drivers/usb/gadget/Makefile | 4 +-
drivers/usb/host/Makefile | 4 +-
drivers/usb/musb/Makefile | 4 +-
drivers/usb/phy/Makefile | 4 +-
drivers/video/Makefile | 4 +-
drivers/watchdog/Makefile | 4 +-
examples/standalone/Makefile | 4 +-
fs/cramfs/Makefile | 4 +-
fs/ext2/Makefile | 4 +-
fs/fat/Makefile | 4 +-
fs/fdos/Makefile | 4 +-
fs/jffs2/Makefile | 4 +-
fs/reiserfs/Makefile | 4 +-
fs/ubifs/Makefile | 4 +-
fs/yaffs2/Makefile | 4 +-
include/configs/balloon3.h | 1 +
include/configs/palmld.h | 1 +
include/configs/palmtc.h | 1 +
include/configs/pleb2.h | 1 +
include/configs/zipitz2.h | 1 +
lib/Makefile | 4 +-
lib/libfdt/Makefile | 4 +-
lib/lzma/Makefile | 4 +-
lib/lzo/Makefile | 4 +-
net/Makefile | 4 +-
post/Makefile | 20 ++---
post/board/lwmon/Makefile | 2 +-
post/board/lwmon5/Makefile | 2 +-
post/board/netta/Makefile | 2 +-
post/board/pdm360ng/Makefile | 2 +-
post/cpu/mpc83xx/Makefile | 2 +-
post/cpu/mpc8xx/Makefile | 2 +-
post/cpu/ppc4xx/Makefile | 2 +-
post/drivers/Makefile | 2 +-
post/lib_powerpc/Makefile | 2 +-
post/lib_powerpc/fpu/Makefile | 2 +-
post/rules.mk | 2 +-
663 files changed, 1380 insertions(+), 1371 deletions(-)
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
@ 2010-11-08 22:10 ` Graeme Russ
2010-11-08 22:34 ` Sebastien Carlier
2010-11-09 6:17 ` Andreas Bießmann
` (6 subsequent siblings)
7 siblings, 1 reply; 79+ messages in thread
From: Graeme Russ @ 2010-11-08 22:10 UTC (permalink / raw)
To: u-boot
On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier
<sebastien.carlier@gmail.com> wrote:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>
A link to the matching patch would have been nice :)
Regards,
Graeme
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:10 ` Graeme Russ
@ 2010-11-08 22:34 ` Sebastien Carlier
0 siblings, 0 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-08 22:34 UTC (permalink / raw)
To: u-boot
On Mon, Nov 8, 2010 at 11:10 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier
> <sebastien.carlier@gmail.com> wrote:
>> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>>
>
> A link to the matching patch would have been nice :)
Ah, yes, I was wondering about that...
It looks like I should add it to this page:
http://www.denx.de/wiki/U-Boot/TooBigPatches
I will do so once my registration on the wiki has been processed.
Temporarily, the patch can be found there:
http://io.oiioiio.com/~sebc/0001-Switch-from-archive-libraries-to-partial-linking.patch
Regards,
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
2010-11-08 22:10 ` Graeme Russ
@ 2010-11-09 6:17 ` Andreas Bießmann
2010-11-09 9:15 ` Andre Schwarz
` (5 subsequent siblings)
7 siblings, 0 replies; 79+ messages in thread
From: Andreas Bießmann @ 2010-11-09 6:17 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
Am 08.11.2010 um 23:04 schrieb Sebastien Carlier:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries
> when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does
> not extract archive members to resolve undefined weak symbols".
your patch works. Strong symbols in board library now overload weak symbols in other libraries even if they have an alias or empty implementation.
Tested-by: Andreas Bie?mann <andreas.devel@gmail.com>
regards
Andreas Bie?mann
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
2010-11-08 22:10 ` Graeme Russ
2010-11-09 6:17 ` Andreas Bießmann
@ 2010-11-09 9:15 ` Andre Schwarz
2010-11-09 17:44 ` [U-Boot] [PATCH v2] " Sebastien Carlier
2010-11-09 9:48 ` [U-Boot] [PATCH] " Graeme Russ
` (4 subsequent siblings)
7 siblings, 1 reply; 79+ messages in thread
From: Andre Schwarz @ 2010-11-09 9:15 UTC (permalink / raw)
To: u-boot
Sebastian,
drivers/qe already has an object called "qe.o" ... renaming "qe.a" to
"qe.o" doesn't work.
I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I also don't understand why ftd.c is not depending on CONFIG_QE.
That's another question ... but leads to error having your patch applied.
Regards,
Andr?
On 11/08/2010 11:04 PM, Sebastien Carlier wrote:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries
> when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does
> not extract archive members to resolve undefined weak symbols".
>
> This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives,
> which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols
> as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target
> (added at the end of config.mk and used in all Makefiles) is inspired.
>
> The name of each former library archive is preserved except for extensions which change from ".a" to
> ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
>
> This commit reveals board configurations that exclude some module but not all of its dependencies; for
> example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
>
> Signed-off-by: Sebastien Carlier<sebastien.carlier@gmail.com>
> ---
> Makefile | 118 ++++++++++++++--------------
> api/Makefile | 4 +-
> arch/arm/cpu/arm1136/Makefile | 4 +-
> arch/arm/cpu/arm1136/mx31/Makefile | 4 +-
> arch/arm/cpu/arm1136/omap24xx/Makefile | 4 +-
> arch/arm/cpu/arm1176/Makefile | 4 +-
> arch/arm/cpu/arm1176/s3c64xx/Makefile | 4 +-
> arch/arm/cpu/arm1176/tnetv107x/Makefile | 4 +-
> arch/arm/cpu/arm720t/Makefile | 4 +-
> arch/arm/cpu/arm720t/lpc2292/Makefile | 4 +-
> arch/arm/cpu/arm720t/s3c4510b/Makefile | 4 +-
> arch/arm/cpu/arm920t/Makefile | 4 +-
> arch/arm/cpu/arm920t/a320/Makefile | 4 +-
> arch/arm/cpu/arm920t/at91/Makefile | 4 +-
> arch/arm/cpu/arm920t/at91rm9200/Makefile | 4 +-
> arch/arm/cpu/arm920t/ep93xx/Makefile | 4 +-
> arch/arm/cpu/arm920t/imx/Makefile | 4 +-
> arch/arm/cpu/arm920t/ks8695/Makefile | 4 +-
> arch/arm/cpu/arm920t/s3c24x0/Makefile | 4 +-
> arch/arm/cpu/arm925t/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/at91/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/davinci/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/kirkwood/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/mx27/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/nomadik/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/omap/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/orion5x/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/spear/Makefile | 4 +-
> arch/arm/cpu/arm926ejs/versatile/Makefile | 4 +-
> arch/arm/cpu/arm946es/Makefile | 4 +-
> arch/arm/cpu/arm_intcm/Makefile | 4 +-
> arch/arm/cpu/armv7/Makefile | 4 +-
> arch/arm/cpu/armv7/mx5/Makefile | 4 +-
> arch/arm/cpu/armv7/omap-common/Makefile | 4 +-
> arch/arm/cpu/armv7/omap3/Makefile | 4 +-
> arch/arm/cpu/armv7/omap4/Makefile | 4 +-
> arch/arm/cpu/armv7/s5p-common/Makefile | 4 +-
> arch/arm/cpu/armv7/s5pc1xx/Makefile | 4 +-
> arch/arm/cpu/ixp/Makefile | 4 +-
> arch/arm/cpu/ixp/npe/Makefile | 4 +-
> arch/arm/cpu/lh7a40x/Makefile | 4 +-
> arch/arm/cpu/pxa/Makefile | 4 +-
> arch/arm/cpu/s3c44b0/Makefile | 4 +-
> arch/arm/cpu/sa1100/Makefile | 4 +-
> arch/arm/lib/Makefile | 10 +-
> arch/avr32/cpu/Makefile | 4 +-
> arch/avr32/cpu/at32ap700x/Makefile | 4 +-
> arch/avr32/lib/Makefile | 4 +-
> arch/blackfin/cpu/Makefile | 4 +-
> arch/blackfin/lib/Makefile | 4 +-
> arch/i386/cpu/Makefile | 4 +-
> arch/i386/cpu/sc520/Makefile | 4 +-
> arch/i386/lib/Makefile | 4 +-
> arch/m68k/cpu/mcf5227x/Makefile | 4 +-
> arch/m68k/cpu/mcf523x/Makefile | 4 +-
> arch/m68k/cpu/mcf52x2/Makefile | 4 +-
> arch/m68k/cpu/mcf532x/Makefile | 4 +-
> arch/m68k/cpu/mcf5445x/Makefile | 4 +-
> arch/m68k/cpu/mcf547x_8x/Makefile | 4 +-
> arch/m68k/lib/Makefile | 4 +-
> arch/microblaze/cpu/Makefile | 4 +-
> arch/microblaze/lib/Makefile | 4 +-
> arch/mips/cpu/Makefile | 4 +-
> arch/mips/lib/Makefile | 4 +-
> arch/nios2/cpu/Makefile | 4 +-
> arch/nios2/lib/Makefile | 4 +-
> arch/powerpc/cpu/74xx_7xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc512x/Makefile | 4 +-
> arch/powerpc/cpu/mpc5xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc5xxx/Makefile | 4 +-
> arch/powerpc/cpu/mpc8220/Makefile | 4 +-
> arch/powerpc/cpu/mpc824x/Makefile | 4 +-
> arch/powerpc/cpu/mpc8260/Makefile | 4 +-
> arch/powerpc/cpu/mpc83xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc85xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc86xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc8xx/Makefile | 4 +-
> arch/powerpc/cpu/mpc8xxx/Makefile | 4 +-
> arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 4 +-
> arch/powerpc/cpu/ppc4xx/Makefile | 4 +-
> arch/powerpc/lib/Makefile | 4 +-
> arch/sh/cpu/sh2/Makefile | 4 +-
> arch/sh/cpu/sh3/Makefile | 4 +-
> arch/sh/cpu/sh4/Makefile | 4 +-
> arch/sh/lib/Makefile | 4 +-
> arch/sparc/cpu/leon2/Makefile | 4 +-
> arch/sparc/cpu/leon3/Makefile | 4 +-
> arch/sparc/lib/Makefile | 4 +-
> board/BuS/EB+MCF-EV123/Makefile | 4 +-
> board/BuS/eb_cpux9k2/Makefile | 4 +-
> board/LEOX/elpt860/Makefile | 4 +-
> board/LaCie/edminiv2/Makefile | 4 +-
> board/Marvell/db64360/Makefile | 4 +-
> board/Marvell/db64460/Makefile | 4 +-
> board/Marvell/guruplug/Makefile | 4 +-
> board/Marvell/mv88f6281gtw_ge/Makefile | 4 +-
> board/Marvell/openrd_base/Makefile | 4 +-
> board/Marvell/rd6281a/Makefile | 4 +-
> board/Marvell/sheevaplug/Makefile | 4 +-
> board/RPXClassic/Makefile | 4 +-
> board/RPXlite/Makefile | 4 +-
> board/RPXlite_dw/Makefile | 4 +-
> board/RRvision/Makefile | 4 +-
> board/a3000/Makefile | 4 +-
> board/a4m072/Makefile | 4 +-
> board/actux1/Makefile | 4 +-
> board/actux1/config.mk | 2 +-
> board/actux2/Makefile | 4 +-
> board/actux2/config.mk | 2 +-
> board/actux3/Makefile | 4 +-
> board/actux3/config.mk | 2 +-
> board/actux4/Makefile | 4 +-
> board/actux4/config.mk | 2 +-
> board/adder/Makefile | 4 +-
> board/afeb9260/Makefile | 4 +-
> board/alaska/Makefile | 4 +-
> board/altera/nios2-generic/Makefile | 4 +-
> board/amcc/acadia/Makefile | 4 +-
> board/amcc/bamboo/Makefile | 4 +-
> board/amcc/bluestone/Makefile | 4 +-
> board/amcc/bubinga/Makefile | 4 +-
> board/amcc/canyonlands/Makefile | 4 +-
> board/amcc/ebony/Makefile | 4 +-
> board/amcc/katmai/Makefile | 4 +-
> board/amcc/kilauea/Makefile | 4 +-
> board/amcc/luan/Makefile | 4 +-
> board/amcc/makalu/Makefile | 4 +-
> board/amcc/ocotea/Makefile | 4 +-
> board/amcc/redwood/Makefile | 4 +-
> board/amcc/sequoia/Makefile | 4 +-
> board/amcc/taihu/Makefile | 4 +-
> board/amcc/taishan/Makefile | 4 +-
> board/amcc/walnut/Makefile | 4 +-
> board/amcc/yosemite/Makefile | 4 +-
> board/amcc/yucca/Makefile | 4 +-
> board/amirix/ap1000/Makefile | 4 +-
> board/apollon/Makefile | 4 +-
> board/armadillo/Makefile | 4 +-
> board/armltd/integrator/Makefile | 4 +-
> board/armltd/versatile/Makefile | 4 +-
> board/armltd/vexpress/Makefile | 4 +-
> board/assabet/Makefile | 4 +-
> board/astro/mcf5373l/Makefile | 4 +-
> board/atc/Makefile | 4 +-
> board/atmel/at91cap9adk/Makefile | 4 +-
> board/atmel/at91rm9200dk/Makefile | 4 +-
> board/atmel/at91rm9200ek/Makefile | 4 +-
> board/atmel/at91sam9260ek/Makefile | 4 +-
> board/atmel/at91sam9261ek/Makefile | 4 +-
> board/atmel/at91sam9263ek/Makefile | 4 +-
> board/atmel/at91sam9m10g45ek/Makefile | 4 +-
> board/atmel/at91sam9rlek/Makefile | 4 +-
> board/atmel/atngw100/Makefile | 4 +-
> board/atmel/atstk1000/Makefile | 4 +-
> board/atum8548/Makefile | 4 +-
> board/balloon3/Makefile | 4 +-
> board/barco/Makefile | 4 +-
> board/bc3450/Makefile | 4 +-
> board/bct-brettl2/Makefile | 4 +-
> board/bf518f-ezbrd/Makefile | 4 +-
> board/bf526-ezbrd/Makefile | 4 +-
> board/bf527-ad7160-eval/Makefile | 4 +-
> board/bf527-ezkit/Makefile | 4 +-
> board/bf527-sdp/Makefile | 4 +-
> board/bf533-ezkit/Makefile | 4 +-
> board/bf533-stamp/Makefile | 4 +-
> board/bf537-minotaur/Makefile | 4 +-
> board/bf537-pnav/Makefile | 4 +-
> board/bf537-srv1/Makefile | 4 +-
> board/bf537-stamp/Makefile | 4 +-
> board/bf538f-ezkit/Makefile | 4 +-
> board/bf548-ezkit/Makefile | 4 +-
> board/bf561-acvilon/Makefile | 4 +-
> board/bf561-ezkit/Makefile | 4 +-
> board/blackstamp/Makefile | 4 +-
> board/blackvme/Makefile | 4 +-
> board/bmw/Makefile | 4 +-
> board/c2mon/Makefile | 4 +-
> board/calao/sbc35_a9g20/Makefile | 4 +-
> board/calao/tny_a9260/Makefile | 4 +-
> board/canmb/Makefile | 4 +-
> board/cerf250/Makefile | 4 +-
> board/cm-bf527/Makefile | 4 +-
> board/cm-bf533/Makefile | 4 +-
> board/cm-bf537e/Makefile | 4 +-
> board/cm-bf537u/Makefile | 4 +-
> board/cm-bf548/Makefile | 4 +-
> board/cm-bf561/Makefile | 4 +-
> board/cm4008/Makefile | 4 +-
> board/cm41xx/Makefile | 4 +-
> board/cm5200/Makefile | 4 +-
> board/cmc_pu2/Makefile | 4 +-
> board/cmi/Makefile | 4 +-
> board/cobra5272/Makefile | 4 +-
> board/cogent/Makefile | 4 +-
> board/colibri_pxa270/Makefile | 4 +-
> board/cpc45/Makefile | 4 +-
> board/cpu86/Makefile | 4 +-
> board/cpu87/Makefile | 4 +-
> board/cradle/Makefile | 4 +-
> board/cray/L1/Makefile | 4 +-
> board/csb226/Makefile | 4 +-
> board/csb272/Makefile | 4 +-
> board/csb472/Makefile | 4 +-
> board/csb637/Makefile | 4 +-
> board/cu824/Makefile | 4 +-
> board/dave/B2/Makefile | 4 +-
> board/dave/PPChameleonEVB/Makefile | 4 +-
> board/davedenx/aria/Makefile | 4 +-
> board/davedenx/qong/Makefile | 4 +-
> board/davinci/common/Makefile | 4 +-
> board/davinci/da8xxevm/Makefile | 4 +-
> board/davinci/dm355evm/Makefile | 4 +-
> board/davinci/dm355leopard/Makefile | 4 +-
> board/davinci/dm365evm/Makefile | 4 +-
> board/davinci/dm6467evm/Makefile | 4 +-
> board/davinci/dvevm/Makefile | 4 +-
> board/davinci/schmoogie/Makefile | 4 +-
> board/davinci/sffsdr/Makefile | 4 +-
> board/davinci/sonata/Makefile | 4 +-
> board/dbau1x00/Makefile | 4 +-
> board/digsy_mtc/Makefile | 4 +-
> board/dnp1110/Makefile | 4 +-
> board/eNET/Makefile | 4 +-
> board/eXalion/Makefile | 4 +-
> board/earthlcd/favr-32-ezkit/Makefile | 4 +-
> board/edb93xx/Makefile | 4 +-
> board/eltec/bab7xx/Makefile | 4 +-
> board/eltec/elppc/Makefile | 4 +-
> board/eltec/mhpc/Makefile | 4 +-
> board/emk/top5200/Makefile | 4 +-
> board/emk/top860/Makefile | 4 +-
> board/ep7312/Makefile | 4 +-
> board/ep8248/Makefile | 4 +-
> board/ep8260/Makefile | 4 +-
> board/ep82xxm/Makefile | 4 +-
> board/ep88x/Makefile | 4 +-
> board/eric/Makefile | 4 +-
> board/esd/adciop/Makefile | 4 +-
> board/esd/apc405/Makefile | 4 +-
> board/esd/ar405/Makefile | 4 +-
> board/esd/ash405/Makefile | 4 +-
> board/esd/canbt/Makefile | 4 +-
> board/esd/cms700/Makefile | 4 +-
> board/esd/cpci2dp/Makefile | 4 +-
> board/esd/cpci405/Makefile | 4 +-
> board/esd/cpci5200/Makefile | 4 +-
> board/esd/cpci750/Makefile | 4 +-
> board/esd/cpciiser4/Makefile | 4 +-
> board/esd/dasa_sim/Makefile | 4 +-
> board/esd/dp405/Makefile | 4 +-
> board/esd/du405/Makefile | 4 +-
> board/esd/du440/Makefile | 4 +-
> board/esd/hh405/Makefile | 4 +-
> board/esd/hub405/Makefile | 4 +-
> board/esd/mecp5123/Makefile | 4 +-
> board/esd/mecp5200/Makefile | 4 +-
> board/esd/meesc/Makefile | 4 +-
> board/esd/ocrtc/Makefile | 4 +-
> board/esd/otc570/Makefile | 4 +-
> board/esd/pci405/Makefile | 6 +-
> board/esd/pf5200/Makefile | 4 +-
> board/esd/plu405/Makefile | 4 +-
> board/esd/pmc405/Makefile | 4 +-
> board/esd/pmc405de/Makefile | 4 +-
> board/esd/pmc440/Makefile | 4 +-
> board/esd/tasreg/Makefile | 4 +-
> board/esd/vme8349/Makefile | 4 +-
> board/esd/voh405/Makefile | 4 +-
> board/esd/vom405/Makefile | 4 +-
> board/esd/wuh405/Makefile | 4 +-
> board/espt/Makefile | 4 +-
> board/esteem192e/Makefile | 4 +-
> board/etin/debris/Makefile | 4 +-
> board/etin/kvme080/Makefile | 4 +-
> board/etx094/Makefile | 4 +-
> board/eukrea/cpu9260/Makefile | 4 +-
> board/eukrea/cpuat91/Makefile | 4 +-
> board/evb4510/Makefile | 4 +-
> board/evb64260/Makefile | 4 +-
> board/fads/Makefile | 4 +-
> board/faraday/a320evb/Makefile | 4 +-
> board/flagadm/Makefile | 4 +-
> board/freescale/common/Makefile | 4 +-
> board/freescale/corenet_ds/Makefile | 4 +-
> board/freescale/m5208evbe/Makefile | 4 +-
> board/freescale/m5208evbe/u-boot.lds | 4 +-
> board/freescale/m52277evb/Makefile | 4 +-
> board/freescale/m52277evb/u-boot.spa | 6 +-
> board/freescale/m5235evb/Makefile | 4 +-
> board/freescale/m5235evb/u-boot.32 | 4 +-
> board/freescale/m5249evb/Makefile | 4 +-
> board/freescale/m5253demo/Makefile | 4 +-
> board/freescale/m5253evbe/Makefile | 4 +-
> board/freescale/m5271evb/Makefile | 4 +-
> board/freescale/m5271evb/u-boot.lds | 2 +-
> board/freescale/m5272c3/Makefile | 4 +-
> board/freescale/m5275evb/Makefile | 4 +-
> board/freescale/m5282evb/Makefile | 4 +-
> board/freescale/m53017evb/Makefile | 4 +-
> board/freescale/m53017evb/u-boot.lds | 4 +-
> board/freescale/m5329evb/Makefile | 4 +-
> board/freescale/m5373evb/Makefile | 4 +-
> board/freescale/m54451evb/Makefile | 4 +-
> board/freescale/m54451evb/u-boot.spa | 6 +-
> board/freescale/m54455evb/Makefile | 4 +-
> board/freescale/m547xevb/Makefile | 4 +-
> board/freescale/m548xevb/Makefile | 4 +-
> board/freescale/mpc5121ads/Makefile | 4 +-
> board/freescale/mpc7448hpc2/Makefile | 4 +-
> board/freescale/mpc8260ads/Makefile | 4 +-
> board/freescale/mpc8266ads/Makefile | 4 +-
> board/freescale/mpc8308rdb/Makefile | 4 +-
> board/freescale/mpc8313erdb/Makefile | 4 +-
> board/freescale/mpc8315erdb/Makefile | 4 +-
> board/freescale/mpc8323erdb/Makefile | 4 +-
> board/freescale/mpc832xemds/Makefile | 4 +-
> board/freescale/mpc8349emds/Makefile | 4 +-
> board/freescale/mpc8349itx/Makefile | 4 +-
> board/freescale/mpc8360emds/Makefile | 4 +-
> board/freescale/mpc8360erdk/Makefile | 4 +-
> board/freescale/mpc837xemds/Makefile | 4 +-
> board/freescale/mpc837xerdb/Makefile | 4 +-
> board/freescale/mpc8536ds/Makefile | 4 +-
> board/freescale/mpc8540ads/Makefile | 4 +-
> board/freescale/mpc8541cds/Makefile | 4 +-
> board/freescale/mpc8544ds/Makefile | 4 +-
> board/freescale/mpc8548cds/Makefile | 4 +-
> board/freescale/mpc8555cds/Makefile | 4 +-
> board/freescale/mpc8560ads/Makefile | 4 +-
> board/freescale/mpc8568mds/Makefile | 4 +-
> board/freescale/mpc8569mds/Makefile | 4 +-
> board/freescale/mpc8572ds/Makefile | 4 +-
> board/freescale/mpc8610hpcd/Makefile | 4 +-
> board/freescale/mpc8641hpcn/Makefile | 4 +-
> board/freescale/mx31ads/Makefile | 4 +-
> board/freescale/mx31ads/u-boot.lds | 8 +-
> board/freescale/mx31pdk/Makefile | 4 +-
> board/freescale/mx51evk/Makefile | 4 +-
> board/freescale/p1022ds/Makefile | 4 +-
> board/freescale/p1_p2_rdb/Makefile | 4 +-
> board/freescale/p2020ds/Makefile | 4 +-
> board/funkwerk/vovpn-gw/Makefile | 4 +-
> board/g2000/Makefile | 4 +-
> board/gaisler/gr_cpci_ax2000/Makefile | 4 +-
> board/gaisler/gr_ep2s60/Makefile | 4 +-
> board/gaisler/gr_xc3s_1500/Makefile | 4 +-
> board/gaisler/grsim/Makefile | 4 +-
> board/gaisler/grsim_leon2/Makefile | 4 +-
> board/galaxy5200/Makefile | 4 +-
> board/gcplus/Makefile | 4 +-
> board/gdsys/405ep/Makefile | 4 +-
> board/gdsys/common/Makefile | 4 +-
> board/gdsys/dlvision/Makefile | 4 +-
> board/gdsys/gdppc440etx/Makefile | 4 +-
> board/gdsys/intip/Makefile | 4 +-
> board/gdsys/neo/Makefile | 4 +-
> board/gen860t/Makefile | 4 +-
> board/genietv/Makefile | 4 +-
> board/gth2/Makefile | 4 +-
> board/gw8260/Makefile | 4 +-
> board/hermes/Makefile | 4 +-
> board/hidden_dragon/Makefile | 4 +-
> board/hymod/Makefile | 4 +-
> board/ibf-dsp561/Makefile | 4 +-
> board/icecube/Makefile | 4 +-
> board/icu862/Makefile | 4 +-
> board/idmr/Makefile | 4 +-
> board/idmr/u-boot.lds | 2 +-
> board/ids8247/Makefile | 4 +-
> board/impa7/Makefile | 4 +-
> board/imx31_phycore/Makefile | 4 +-
> board/incaip/Makefile | 4 +-
> board/inka4x0/Makefile | 4 +-
> board/innokom/Makefile | 4 +-
> board/ip04/Makefile | 4 +-
> board/ip860/Makefile | 4 +-
> board/ipek01/Makefile | 4 +-
> board/iphase4539/Makefile | 4 +-
> board/isee/igep0020/Makefile | 4 +-
> board/isee/igep0030/Makefile | 4 +-
> board/ispan/Makefile | 4 +-
> board/ivm/Makefile | 4 +-
> board/ixdp425/Makefile | 4 +-
> board/jornada/Makefile | 4 +-
> board/jse/Makefile | 4 +-
> board/jupiter/Makefile | 4 +-
> board/karo/tx25/Makefile | 4 +-
> board/kb9202/Makefile | 4 +-
> board/keymile/km8xx/Makefile | 4 +-
> board/keymile/km_arm/Makefile | 4 +-
> board/keymile/kmeter1/Makefile | 4 +-
> board/keymile/mgcoge/Makefile | 4 +-
> board/korat/Makefile | 4 +-
> board/kup/Makefile | 4 +-
> board/kup/kup4k/Makefile | 4 +-
> board/kup/kup4x/Makefile | 4 +-
> board/lantec/Makefile | 4 +-
> board/lart/Makefile | 4 +-
> board/linkstation/Makefile | 4 +-
> board/logicpd/am3517evm/Makefile | 4 +-
> board/logicpd/imx27lite/Makefile | 4 +-
> board/logicpd/imx31_litekit/Makefile | 4 +-
> board/logicpd/zoom1/Makefile | 4 +-
> board/logicpd/zoom2/Makefile | 4 +-
> board/lpc2292sodimm/Makefile | 4 +-
> board/lpd7a40x/Makefile | 4 +-
> board/lubbock/Makefile | 4 +-
> board/lwmon/Makefile | 4 +-
> board/lwmon5/Makefile | 4 +-
> board/m501sk/Makefile | 4 +-
> board/manroland/hmi1001/Makefile | 4 +-
> board/manroland/mucmc52/Makefile | 4 +-
> board/manroland/uc100/Makefile | 4 +-
> board/manroland/uc101/Makefile | 4 +-
> board/matrix_vision/common/Makefile | 4 +-
> board/matrix_vision/mvbc_p/Makefile | 4 +-
> board/matrix_vision/mvblm7/Makefile | 4 +-
> board/matrix_vision/mvsmr/Makefile | 4 +-
> board/mbx8xx/Makefile | 4 +-
> board/mcc200/Makefile | 4 +-
> board/micronas/vct/Makefile | 4 +-
> board/mimc/mimc200/Makefile | 4 +-
> board/miromico/hammerhead/Makefile | 4 +-
> board/ml2/Makefile | 4 +-
> board/modnet50/Makefile | 4 +-
> board/mosaixtech/icon/Makefile | 4 +-
> board/motionpro/Makefile | 4 +-
> board/mousse/Makefile | 4 +-
> board/mp2usb/Makefile | 4 +-
> board/mpc8308_p1m/Makefile | 4 +-
> board/mpc8540eval/Makefile | 4 +-
> board/mpl/mip405/Makefile | 4 +-
> board/mpl/pati/Makefile | 4 +-
> board/mpl/pip405/Makefile | 4 +-
> board/mpl/vcma9/Makefile | 4 +-
> board/mpr2/Makefile | 4 +-
> board/ms7720se/Makefile | 4 +-
> board/ms7722se/Makefile | 4 +-
> board/ms7750se/Makefile | 4 +-
> board/muas3001/Makefile | 4 +-
> board/munices/Makefile | 4 +-
> board/musenki/Makefile | 4 +-
> board/mvblue/Makefile | 4 +-
> board/mx1ads/Makefile | 4 +-
> board/mx1fs2/Makefile | 4 +-
> board/netphone/Makefile | 4 +-
> board/netstal/hcu4/Makefile | 4 +-
> board/netstal/hcu5/Makefile | 4 +-
> board/netstal/mcu25/Makefile | 4 +-
> board/netstar/Makefile | 4 +-
> board/netta/Makefile | 4 +-
> board/netta2/Makefile | 4 +-
> board/netvia/Makefile | 4 +-
> board/ns9750dev/Makefile | 4 +-
> board/nx823/Makefile | 4 +-
> board/o2dnt/Makefile | 4 +-
> board/overo/Makefile | 4 +-
> board/oxc/Makefile | 4 +-
> board/palmld/Makefile | 4 +-
> board/palmtc/Makefile | 4 +-
> board/pandora/Makefile | 4 +-
> board/pb1x00/Makefile | 4 +-
> board/pcippc2/Makefile | 4 +-
> board/pcs440ep/Makefile | 4 +-
> board/pdm360ng/Makefile | 4 +-
> board/phytec/pcm030/Makefile | 4 +-
> board/pleb2/Makefile | 4 +-
> board/pm520/Makefile | 4 +-
> board/pm826/Makefile | 4 +-
> board/pm828/Makefile | 4 +-
> board/pm854/Makefile | 4 +-
> board/pm856/Makefile | 4 +-
> board/pn62/Makefile | 4 +-
> board/ppmc7xx/Makefile | 4 +-
> board/ppmc8260/Makefile | 4 +-
> board/prodrive/alpr/Makefile | 4 +-
> board/prodrive/p3mx/Makefile | 4 +-
> board/prodrive/p3p440/Makefile | 4 +-
> board/prodrive/pdnb3/Makefile | 4 +-
> board/psyent/pci5441/Makefile | 4 +-
> board/psyent/pk1c20/Makefile | 4 +-
> board/purple/Makefile | 4 +-
> board/pxa255_idp/Makefile | 4 +-
> board/qemu-mips/Makefile | 4 +-
> board/quad100hd/Makefile | 4 +-
> board/quantum/Makefile | 4 +-
> board/r360mpi/Makefile | 4 +-
> board/rattler/Makefile | 4 +-
> board/rbc823/Makefile | 4 +-
> board/renesas/MigoR/Makefile | 4 +-
> board/renesas/ap325rxa/Makefile | 4 +-
> board/renesas/r2dplus/Makefile | 4 +-
> board/renesas/r7780mp/Makefile | 4 +-
> board/renesas/rsk7203/Makefile | 4 +-
> board/renesas/sh7763rdp/Makefile | 4 +-
> board/renesas/sh7785lcr/Makefile | 4 +-
> board/rmu/Makefile | 4 +-
> board/ronetix/pm9261/Makefile | 4 +-
> board/ronetix/pm9263/Makefile | 4 +-
> board/ronetix/pm9g45/Makefile | 4 +-
> board/rpxsuper/Makefile | 4 +-
> board/rsdproto/Makefile | 4 +-
> board/sacsng/Makefile | 4 +-
> board/samsung/goni/Makefile | 4 +-
> board/samsung/smdk2400/Makefile | 4 +-
> board/samsung/smdk2410/Makefile | 4 +-
> board/samsung/smdk6400/Makefile | 4 +-
> board/samsung/smdkc100/Makefile | 4 +-
> board/sandburst/karef/Makefile | 4 +-
> board/sandburst/metrobox/Makefile | 4 +-
> board/sandpoint/Makefile | 4 +-
> board/sbc2410x/Makefile | 4 +-
> board/sbc405/Makefile | 4 +-
> board/sbc8240/Makefile | 4 +-
> board/sbc8260/Makefile | 4 +-
> board/sbc8349/Makefile | 4 +-
> board/sbc8548/Makefile | 4 +-
> board/sbc8560/Makefile | 4 +-
> board/sbc8641d/Makefile | 4 +-
> board/sc3/Makefile | 4 +-
> board/scb9328/Makefile | 4 +-
> board/shannon/Makefile | 4 +-
> board/sheldon/simpc8313/Makefile | 4 +-
> board/siemens/IAD210/Makefile | 4 +-
> board/siemens/SCM/Makefile | 4 +-
> board/siemens/SMN42/Makefile | 4 +-
> board/sixnet/Makefile | 4 +-
> board/snmc/qs850/Makefile | 4 +-
> board/snmc/qs860t/Makefile | 4 +-
> board/socrates/Makefile | 4 +-
> board/sorcery/Makefile | 4 +-
> board/spc1920/Makefile | 4 +-
> board/spd8xx/Makefile | 4 +-
> board/spear/common/Makefile | 4 +-
> board/spear/spear300/Makefile | 4 +-
> board/spear/spear310/Makefile | 4 +-
> board/spear/spear320/Makefile | 4 +-
> board/spear/spear600/Makefile | 4 +-
> board/st/nhk8815/Makefile | 4 +-
> board/stx/stxgp3/Makefile | 4 +-
> board/stx/stxssa/Makefile | 4 +-
> board/stx/stxxtc/Makefile | 4 +-
> board/svm_sc8xx/Makefile | 4 +-
> board/sx1/Makefile | 4 +-
> board/syteco/jadecpu/Makefile | 4 +-
> board/t3corp/Makefile | 4 +-
> board/tb0229/Makefile | 4 +-
> board/tcm-bf518/Makefile | 4 +-
> board/tcm-bf537/Makefile | 4 +-
> board/ti/beagle/Makefile | 4 +-
> board/ti/evm/Makefile | 4 +-
> board/ti/omap1510inn/Makefile | 4 +-
> board/ti/omap1610inn/Makefile | 4 +-
> board/ti/omap2420h4/Makefile | 4 +-
> board/ti/omap5912osk/Makefile | 4 +-
> board/ti/omap730p2/Makefile | 4 +-
> board/ti/panda/Makefile | 4 +-
> board/ti/sdp3430/Makefile | 4 +-
> board/ti/sdp4430/Makefile | 4 +-
> board/ti/tnetv107xevm/Makefile | 4 +-
> board/timll/devkit8000/Makefile | 4 +-
> board/total5200/Makefile | 4 +-
> board/tqc/tqm5200/Makefile | 4 +-
> board/tqc/tqm8260/Makefile | 4 +-
> board/tqc/tqm8272/Makefile | 4 +-
> board/tqc/tqm834x/Makefile | 4 +-
> board/tqc/tqm85xx/Makefile | 4 +-
> board/tqc/tqm8xx/Makefile | 4 +-
> board/trab/Makefile | 4 +-
> board/trizepsiv/Makefile | 4 +-
> board/ttcontrol/vision2/Makefile | 4 +-
> board/utx8245/Makefile | 4 +-
> board/v37/Makefile | 4 +-
> board/v38b/Makefile | 4 +-
> board/ve8313/Makefile | 4 +-
> board/voiceblue/Makefile | 4 +-
> board/vpac270/Makefile | 4 +-
> board/w7o/Makefile | 4 +-
> board/westel/amx860/Makefile | 4 +-
> board/xaeniax/Makefile | 4 +-
> board/xes/common/Makefile | 4 +-
> board/xes/xpedite1000/Makefile | 4 +-
> board/xes/xpedite517x/Makefile | 4 +-
> board/xes/xpedite520x/Makefile | 4 +-
> board/xes/xpedite537x/Makefile | 4 +-
> board/xes/xpedite550x/Makefile | 4 +-
> board/xilinx/microblaze-generic/Makefile | 4 +-
> board/xilinx/ppc405-generic/Makefile | 4 +-
> board/xilinx/ppc440-generic/Makefile | 4 +-
> board/xm250/Makefile | 4 +-
> board/zeus/Makefile | 4 +-
> board/zipitz2/Makefile | 4 +-
> board/zpc1900/Makefile | 4 +-
> board/zylonite/Makefile | 4 +-
> common/Makefile | 4 +-
> config.mk | 6 ++
> disk/Makefile | 4 +-
> drivers/bios_emulator/Makefile | 4 +-
> drivers/block/Makefile | 4 +-
> drivers/dma/Makefile | 4 +-
> drivers/fpga/Makefile | 4 +-
> drivers/gpio/Makefile | 4 +-
> drivers/hwmon/Makefile | 4 +-
> drivers/i2c/Makefile | 4 +-
> drivers/input/Makefile | 4 +-
> drivers/misc/Makefile | 4 +-
> drivers/mmc/Makefile | 4 +-
> drivers/mtd/Makefile | 4 +-
> drivers/mtd/nand/Makefile | 4 +-
> drivers/mtd/onenand/Makefile | 4 +-
> drivers/mtd/spi/Makefile | 4 +-
> drivers/mtd/ubi/Makefile | 4 +-
> drivers/net/Makefile | 4 +-
> drivers/net/phy/Makefile | 4 +-
> drivers/pci/Makefile | 4 +-
> drivers/pcmcia/Makefile | 4 +-
> drivers/power/Makefile | 4 +-
> drivers/qe/Makefile | 4 +-
> drivers/rtc/Makefile | 4 +-
> drivers/serial/Makefile | 4 +-
> drivers/spi/Makefile | 4 +-
> drivers/twserial/Makefile | 4 +-
> drivers/usb/gadget/Makefile | 4 +-
> drivers/usb/host/Makefile | 4 +-
> drivers/usb/musb/Makefile | 4 +-
> drivers/usb/phy/Makefile | 4 +-
> drivers/video/Makefile | 4 +-
> drivers/watchdog/Makefile | 4 +-
> examples/standalone/Makefile | 4 +-
> fs/cramfs/Makefile | 4 +-
> fs/ext2/Makefile | 4 +-
> fs/fat/Makefile | 4 +-
> fs/fdos/Makefile | 4 +-
> fs/jffs2/Makefile | 4 +-
> fs/reiserfs/Makefile | 4 +-
> fs/ubifs/Makefile | 4 +-
> fs/yaffs2/Makefile | 4 +-
> include/configs/balloon3.h | 1 +
> include/configs/palmld.h | 1 +
> include/configs/palmtc.h | 1 +
> include/configs/pleb2.h | 1 +
> include/configs/zipitz2.h | 1 +
> lib/Makefile | 4 +-
> lib/libfdt/Makefile | 4 +-
> lib/lzma/Makefile | 4 +-
> lib/lzo/Makefile | 4 +-
> net/Makefile | 4 +-
> post/Makefile | 20 ++---
> post/board/lwmon/Makefile | 2 +-
> post/board/lwmon5/Makefile | 2 +-
> post/board/netta/Makefile | 2 +-
> post/board/pdm360ng/Makefile | 2 +-
> post/cpu/mpc83xx/Makefile | 2 +-
> post/cpu/mpc8xx/Makefile | 2 +-
> post/cpu/ppc4xx/Makefile | 2 +-
> post/drivers/Makefile | 2 +-
> post/lib_powerpc/Makefile | 2 +-
> post/lib_powerpc/fpu/Makefile | 2 +-
> post/rules.mk | 2 +-
> 663 files changed, 1380 insertions(+), 1371 deletions(-)
>
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
` (2 preceding siblings ...)
2010-11-09 9:15 ` Andre Schwarz
@ 2010-11-09 9:48 ` Graeme Russ
2010-11-09 11:29 ` Stefano Babic
` (3 subsequent siblings)
7 siblings, 0 replies; 79+ messages in thread
From: Graeme Russ @ 2010-11-09 9:48 UTC (permalink / raw)
To: u-boot
On 09/11/10 09:04, Sebastien Carlier wrote:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
> Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
Patch applies with zero errors or warnings to my x86 branch, builds clean,
runs and, as a bonus, allows me to move the sc520 reset_cpu() which has an
ugly #ifdef in sc520.c into it's own file (with archives, if the archive
contained only overrides of weak functions, they would be skipped - I think
the archive needed at least the first function to not be an override of a
weak function)
So I'm a very happy (one less #ifdef) camper
Tested-by: Graeme Russ <graeme.russ@gmail.com>
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
` (3 preceding siblings ...)
2010-11-09 9:48 ` [U-Boot] [PATCH] " Graeme Russ
@ 2010-11-09 11:29 ` Stefano Babic
2010-11-10 6:57 ` Mike Frysinger
` (2 subsequent siblings)
7 siblings, 0 replies; 79+ messages in thread
From: Stefano Babic @ 2010-11-09 11:29 UTC (permalink / raw)
To: u-boot
On 11/08/2010 11:04 PM, Sebastien Carlier wrote:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
Your patch applies fine to i.MX branch - boards compile clean, tested on
a MX.51 board.
Tested-by: Stefano Babic <sbabic@denx.de>
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v2] Switch from archive libraries to partial linking
2010-11-09 9:15 ` Andre Schwarz
@ 2010-11-09 17:44 ` Sebastien Carlier
2010-11-10 8:35 ` Andre Schwarz
0 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-09 17:44 UTC (permalink / raw)
To: u-boot
Dear Andr?,
On 2010-11-09 10:15:31, Andre Schwarz wrote:
> Date: Tue, 09 Nov 2010 10:15:31 +0100
> From: Andre Schwarz <andre.schwarz@matrix-vision.de>
> To: Sebastien Carlier <sebastien.carlier@gmail.com>
> CC: u-boot at lists.denx.de, Timur Tabi <timur@freescale.com>,
> Kim Phillips <kim.phillips@freescale.com>
> Subject: Re: [U-Boot] [PATCH] Switch from archive libraries to partial
> linking
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15)
> Gecko/20101027 Thunderbird/3.0.10
>
> Sebastian,
>
> drivers/qe already has an object called "qe.o" ... renaming "qe.a"
> to "qe.o" doesn't work.
Thanks!
> I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I did as you suggested, version 2 of the patch is available here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v2.patch
> I also don't understand why ftd.c is not depending on CONFIG_QE.
> That's another question ... but leads to error having your patch applied.
Right, fdt.c should not be included in the build unless both CONFIG_QE
and CONFIG_OF_LIBFDT are defined. Previously this issue was hidden
because all of qe.a was discarded by the linker. Would the following
be a good fix for this problem?
-COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
+COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o
Regards,
--
S?bastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
` (4 preceding siblings ...)
2010-11-09 11:29 ` Stefano Babic
@ 2010-11-10 6:57 ` Mike Frysinger
2010-11-10 8:01 ` Andreas Bießmann
2010-11-10 8:07 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-15 11:44 ` [U-Boot] [PATCH] " Mike Frysinger
2011-01-24 20:54 ` Timur Tabi
7 siblings, 2 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-10 6:57 UTC (permalink / raw)
To: u-boot
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> This commit changes all Makefiles to use partial linking (ld -r) instead of
> creating library archives, which forces all symbols to participate in
> linking, allowing non-weak symbols to override weak symbols as intended.
> This approach is also used by Linux, from which the gmake function
> cmd_link_o_target (added at the end of config.mk and used in all
> Makefiles) is inspired.
wish we could integrate this into one place already. all these Makefile's
duplicating targets sucks a lot. but guess that could be a future change.
the config.mk looks weird:
+cmd_link_o_target = $(if $(strip $1),\
+ $(LD) -r -o $@ $1 ,\
+ rm -f $@; $(AR) rcs $@ )
why do you need the rm/ar ?
> post/board/lwmon/Makefile | 2 +-
> post/board/lwmon5/Makefile | 2 +-
> post/board/netta/Makefile | 2 +-
> post/board/pdm360ng/Makefile | 2 +-
> post/cpu/mpc83xx/Makefile | 2 +-
> post/cpu/mpc8xx/Makefile | 2 +-
> post/cpu/ppc4xx/Makefile | 2 +-
> post/drivers/Makefile | 2 +-
> post/lib_powerpc/Makefile | 2 +-
> post/lib_powerpc/fpu/Makefile | 2 +-
> post/rules.mk | 2 +-
these look like useless whitespace changes. a lot of the LIB= changes have
similar useless changes. looks like your sed needs a little more smarts to
retain whitespace:
-e '/^LIB/s:[.]a$:.o:'
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/3804df2b/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-10 6:57 ` Mike Frysinger
@ 2010-11-10 8:01 ` Andreas Bießmann
2010-11-10 8:07 ` [U-Boot] [PATCH v3] " Sebastien Carlier
1 sibling, 0 replies; 79+ messages in thread
From: Andreas Bießmann @ 2010-11-10 8:01 UTC (permalink / raw)
To: u-boot
Dear Mike Frysinger,
Am 10.11.2010 07:57, schrieb Mike Frysinger:
> On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> the config.mk looks weird:
> +cmd_link_o_target = $(if $(strip $1),\
> + $(LD) -r -o $@ $1 ,\
> + rm -f $@; $(AR) rcs $@ )
>
> why do you need the rm/ar ?
If one input ($1) is empty the linker ($(LD) -r) would complain empty
input. Therefore we buid an empty archive with $(AR) rcs
regards
Andreas Bie?mann
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-10 6:57 ` Mike Frysinger
2010-11-10 8:01 ` Andreas Bießmann
@ 2010-11-10 8:07 ` Sebastien Carlier
2010-11-10 8:55 ` Mike Frysinger
2010-11-15 7:51 ` Wolfgang Denk
1 sibling, 2 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-10 8:07 UTC (permalink / raw)
To: u-boot
Dear Mike,
On 2010-11-10 01:57:30, Mike Frysinger wrote:
>
> On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> > This commit changes all Makefiles to use partial linking (ld -r) instead of
> > creating library archives, which forces all symbols to participate in
> > linking, allowing non-weak symbols to override weak symbols as intended.
> > This approach is also used by Linux, from which the gmake function
> > cmd_link_o_target (added at the end of config.mk and used in all
> > Makefiles) is inspired.
>
> wish we could integrate this into one place already. all these Makefile's
> duplicating targets sucks a lot. but guess that could be a future change.
It would be nice to have a single rule for all libraries, but I see no
reason to do it all at once (and at the same time as fixing an separate
issue). Some Makefile's do things a little differently from others and
each would best be handled by their respective maintainer.
> the config.mk looks weird:
> +cmd_link_o_target = $(if $(strip $1),\
> + $(LD) -r -o $@ $1 ,\
> + rm -f $@; $(AR) rcs $@ )
>
> why do you need the rm/ar ?
The ar part is needed when there are no objets to link, as ld cannot
create an empty object out of nothing. The rm part is to make sure that
the target is not a leftover object from a previous build (ar would
complain).
> these look like useless whitespace changes. a lot of the LIB= changes have
> similar useless changes. looks like your sed needs a little more smarts to
> retain whitespace:
> -e '/^LIB/s:[.]a$:.o:'
Good suggestion, done in v3:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v3.patch
Regards,
--
S?bastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v2] Switch from archive libraries to partial linking
2010-11-09 17:44 ` [U-Boot] [PATCH v2] " Sebastien Carlier
@ 2010-11-10 8:35 ` Andre Schwarz
0 siblings, 0 replies; 79+ messages in thread
From: Andre Schwarz @ 2010-11-10 8:35 UTC (permalink / raw)
To: u-boot
Sebastien,
>> I also don't understand why ftd.c is not depending on CONFIG_QE.
>> That's another question ... but leads to error having your patch applied.
>>
> Right, fdt.c should not be included in the build unless both CONFIG_QE
> and CONFIG_OF_LIBFDT are defined. Previously this issue was hidden
> because all of qe.a was discarded by the linker. Would the following
> be a good fix for this problem?
>
> -COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
> +COBJS-$(and $(CONFIG_QE),$(CONFIG_OF_LIBFDT)) += fdt.o
>
yes - this should do it.
Within fdt.c there's a CONFIG_QE conditional - you can remove this also
with your approach.
Regards,
Andr?
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-10 8:07 ` [U-Boot] [PATCH v3] " Sebastien Carlier
@ 2010-11-10 8:55 ` Mike Frysinger
2010-11-10 12:24 ` Sebastien Carlier
2010-11-15 7:51 ` Wolfgang Denk
1 sibling, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-10 8:55 UTC (permalink / raw)
To: u-boot
On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
> On 2010-11-10 01:57:30, Mike Frysinger wrote:
> > the config.mk looks weird:
> > +cmd_link_o_target = $(if $(strip $1),\
> > + $(LD) -r -o $@ $1 ,\
> > + rm -f $@; $(AR) rcs $@ )
> >
> > why do you need the rm/ar ?
>
> The ar part is needed when there are no objets to link, as ld cannot
> create an empty object out of nothing. The rm part is to make sure that
> the target is not a leftover object from a previous build (ar would
> complain).
if you're going to copy from linux, you should move over relevant comments:
# If the list of objects to link is empty, just create an empty built-in.o
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/7e357a49/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-10 8:55 ` Mike Frysinger
@ 2010-11-10 12:24 ` Sebastien Carlier
2010-11-10 21:07 ` Mike Frysinger
0 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-10 12:24 UTC (permalink / raw)
To: u-boot
On 2010-11-10 03:55:21, Mike Frysinger wrote:
> On Wednesday, November 10, 2010 03:07:08 Sebastien Carlier wrote:
> > On 2010-11-10 01:57:30, Mike Frysinger wrote:
> > > the config.mk looks weird:
> > > +cmd_link_o_target = $(if $(strip $1),\
> > > + $(LD) -r -o $@ $1 ,\
> > > + rm -f $@; $(AR) rcs $@ )
> > >
> > > why do you need the rm/ar ?
> >
> > The ar part is needed when there are no objets to link, as ld cannot
> > create an empty object out of nothing. The rm part is to make sure that
> > the target is not a leftover object from a previous build (ar would
> > complain).
>
> if you're going to copy from linux, you should move over relevant comments:
> # If the list of objects to link is empty, just create an empty built-in.o
I will include this comment in the next version of the patch.
I was wondering whether config.mk is the right place for this function;
would it be better in rules.mk instead? Both config.mk and rules.mk end
up being included in all Makefile's.
Regards,
--
S?bastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-10 12:24 ` Sebastien Carlier
@ 2010-11-10 21:07 ` Mike Frysinger
0 siblings, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-10 21:07 UTC (permalink / raw)
To: u-boot
On Wednesday, November 10, 2010 07:24:51 Sebastien Carlier wrote:
> I was wondering whether config.mk is the right place for this function;
> would it be better in rules.mk instead? Both config.mk and rules.mk end
> up being included in all Makefile's.
for now, keep it with the other compiler targets. that means the end of
config.mk.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/782216f9/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-10 8:07 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-10 8:55 ` Mike Frysinger
@ 2010-11-15 7:51 ` Wolfgang Denk
2010-11-15 8:09 ` Sebastien Carlier
1 sibling, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-15 7:51 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <20101110080708.GA8145@safe.home.local> you wrote:
> Good suggestion, done in v3:
I have to admit that I lost a bit of overview of the current state of
this work. My understanding is that you are preparing a new version
(V4 ?) of this patch?
If yes, do you have any estimates when this will be available?
I think this an important patch, so I would like to get this in
without further delay.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you use modules, you pay the price. Sane embedded solutions
running in "tight" environments don't use modules :-)
-- Benjamin Herrenschmidt in <1258234866.2140.451.camel@pasglop>
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 7:51 ` Wolfgang Denk
@ 2010-11-15 8:09 ` Sebastien Carlier
2010-11-15 10:54 ` Wolfgang Denk
2010-11-15 19:44 ` Mike Frysinger
0 siblings, 2 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-15 8:09 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-15 08:51:29, Wolfgang Denk wrote:
>
> In message <20101110080708.GA8145@safe.home.local> you wrote:
>
> > Good suggestion, done in v3:
>
> I have to admit that I lost a bit of overview of the current state of
> this work. My understanding is that you are preparing a new version
> (V4 ?) of this patch?
>
> If yes, do you have any estimates when this will be available?
I just uploaded the revised patch here:
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch
Version 4:
Bring in Linux comment for cmd_link_o_target.
Fix drivers/qe/Makefile to build libqe.o, not qe.o.
I pulled the latest changes before making the patch and there was no
conflict, but please let me know if you see anything wrong with it.
--
S?bastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 8:09 ` Sebastien Carlier
@ 2010-11-15 10:54 ` Wolfgang Denk
2010-11-15 11:33 ` Mike Frysinger
` (3 more replies)
2010-11-15 19:44 ` Mike Frysinger
1 sibling, 4 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-15 10:54 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <20101115080950.GA26767@safe.home.local> you wrote:
>
> I just uploaded the revised patch here:
>
> http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch
>
> Version 4:
> Bring in Linux comment for cmd_link_o_target.
> Fix drivers/qe/Makefile to build libqe.o, not qe.o.
>
> I pulled the latest changes before making the patch and there was no
> conflict, but please let me know if you see anything wrong with it.
Thanks a lot.
I notice that the patch affects the size of the resulting U-Boot
images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
text data bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before
361340 35824 303332 700496 ab050 ./u-boot after
-------------------------------
Delta: +3896 Bytes
For other boards it's only a few hundred bytes, but why do we see
such big increase here?
MPC8xx boards break with long lists of multiple definitions of
symbols, like that:
Configuring for FPS860L board...
lib/libgeneric.o: In function `vsprintf':
/home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here
lib/libgeneric.o: In function `ustrtoul':
/home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul'
lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here
lib/libgeneric.o: In function `simple_strtol':
/home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol'
lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here
lib/libgeneric.o: In function `inflate':
/home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate'
lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here
lib/libgeneric.o: In function `inflate_fast':
/home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast'
lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here
...
Have you seen that, too?
Best regards,
Viele Gr??e,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through a keyhole with both
eyes ..."
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 10:54 ` Wolfgang Denk
@ 2010-11-15 11:33 ` Mike Frysinger
2010-11-15 12:38 ` Mike Frysinger
2010-11-15 11:35 ` [U-Boot] [PATCH v4] " Sebastien Carlier
` (2 subsequent siblings)
3 siblings, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 11:33 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
> Sebastien Carlier wrote:
> > I just uploaded the revised patch here:
> > http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archiv
> > e-libraries-to-partial-linking-v4.patch
> >
> > Version 4:
> > Bring in Linux comment for cmd_link_o_target.
> > Fix drivers/qe/Makefile to build libqe.o, not qe.o.
> >
> > I pulled the latest changes before making the patch and there was no
> > conflict, but please let me know if you see anything wrong with it.
>
> Thanks a lot.
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
>
> For example:
>
> Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> text data bss dec hex filename
> 358144 35208 303248 696600 aa118 ./u-boot before
> 361340 35824 303332 700496 ab050 ./u-boot after
> -------------------------------
> Delta: +3896 Bytes
>
> For other boards it's only a few hundred bytes, but why do we see
> such big increase here?
some of this is probably because of missing build system support. there are
some files which are always compiled when they shouldnt be but in the past,
this wasnt a problem because they were stuck in an .a and the linker wouldnt
pull them in since no one requested them.
on my side, i see this with at least these files:
cmd_pcmcia.c
file.c
ldiv.c
memsize.c
rpx_pcmcia.c
tqm8xx_pcmcia.c
although i'm still seeing a few hundred byte increase in my .text/.bss, but
the symbol map is unchanged ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/e1341307/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-15 10:54 ` Wolfgang Denk
2010-11-15 11:33 ` Mike Frysinger
@ 2010-11-15 11:35 ` Sebastien Carlier
2010-11-15 12:13 ` Sebastien Carlier
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
3 siblings, 0 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-15 11:35 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
>
> For example:
>
> Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> text data bss dec hex filename
> 358144 35208 303248 696600 aa118 ./u-boot before
> 361340 35824 303332 700496 ab050 ./u-boot after
> -------------------------------
> Delta: +3896 Bytes
>
> For other boards it's only a few hundred bytes, but why do we see
> such big increase here?
With archive library linking, definitions that were not used were not
included in the final binary. This changes with partial linking (like
it would if we passed the --whole-archive flag to ld).
For this board (TQM5200), I am not sure exactly what happens yet, but
this looks suspect to me:
# ls -l ./post/lib_powerpc/fpu/mul-subnormal-single-1.[co]
-rw-r--r-- 1 sebc sebc 2309 Nov 1 21:33 ./post/lib_powerpc/fpu/mul-subnormal-single-1.c
-rw-r--r-- 1 sebc sebc 30288 Nov 15 12:09 ./post/lib_powerpc/fpu/mul-subnormal-single-1.o
I would expect the object file to be much smaller based on source code
size.
> MPC8xx boards break with long lists of multiple definitions of
> symbols, like that:
>
> Configuring for FPS860L board...
> lib/libgeneric.o: In function `vsprintf':
> /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
> lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here
> lib/libgeneric.o: In function `ustrtoul':
> /home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul'
> lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here
> lib/libgeneric.o: In function `simple_strtol':
> /home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol'
> lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here
> lib/libgeneric.o: In function `inflate':
> /home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate'
> lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here
> lib/libgeneric.o: In function `inflate_fast':
> /home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast'
> lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here
> ...
>
> Have you seen that, too?
No, I had not seen that. It seems that some bits of U-Boot get included
twice in this case... I will investigate this after looking a bit more
at the code size increase for the TQM5200 board.
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
` (5 preceding siblings ...)
2010-11-10 6:57 ` Mike Frysinger
@ 2010-11-15 11:44 ` Mike Frysinger
2011-01-24 20:54 ` Timur Tabi
7 siblings, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 11:44 UTC (permalink / raw)
To: u-boot
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> This commit changes all Makefiles to use partial linking (ld -r) instead of
> creating library archives, which forces all symbols to participate in
> linking, allowing non-weak symbols to override weak symbols as intended.
> This approach is also used by Linux, from which the gmake function
> cmd_link_o_target (added at the end of config.mk and used in all
> Makefiles) is inspired.
linux takes it a step further ... it partially links everything into one .o
before turning that into the final ELF. why dont we do the same (partially
link everything into u-boot.o and then just do u-boot.o->u-boot) ? it should
allow us to drop the start/end group flags in the process.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/e97fef71/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-15 10:54 ` Wolfgang Denk
2010-11-15 11:33 ` Mike Frysinger
2010-11-15 11:35 ` [U-Boot] [PATCH v4] " Sebastien Carlier
@ 2010-11-15 12:13 ` Sebastien Carlier
2010-11-15 12:39 ` Mike Frysinger
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
3 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-15 12:13 UTC (permalink / raw)
To: u-boot
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
>
> For example:
>
> Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> text data bss dec hex filename
> 358144 35208 303248 696600 aa118 ./u-boot before
> 361340 35824 303332 700496 ab050 ./u-boot after
> -------------------------------
> Delta: +3896 Bytes
>
> For other boards it's only a few hundred bytes, but why do we see
> such big increase here?
In this case, these libraries contribute 3260 bytes in unused
definitions:
- fs/fat/libfat.a: (1712 bytes)
file.o:
00000000 00000004 d current_filesystem
00000004 00000200 D file_cwd
00000000 00000018 d filesystems
00000250 00000244 T file_cd
000001d0 00000080 T file_detectfs
00000000 00000048 T file_getfsname
0000011c 000000b4 T file_ls
00000048 000000d4 T file_read
- lib/libfdt/libfdt.a (1440 bytes)
fdt_sw.o:
00000000 0000006c T fdt_add_reservemap_entry
0000028c 000000dc T fdt_begin_node
00000504 0000009c T fdt_create
000000b4 00000078 T fdt_end_node
0000012c 00000160 T fdt_finish
0000006c 00000048 T fdt_finish_reservemap
00000368 0000019c T fdt_property
- drivers/pci/libpci.a: (108 bytes)
pci_indirect.o:
000001dc 0000006c T pci_setup_indirect
In each case, a whole object file contains exactly the unused
definitions, and could be excluded in the respective Makefile.
Re. my previous comment -- in other places objects get large when header
files define a lot of static inline functions, but these ('t' type)
definitions get squashed together during linking and do not add up. If
however a large static inline function is defined but never used, it
will increase final binary size.
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 11:33 ` Mike Frysinger
@ 2010-11-15 12:38 ` Mike Frysinger
2010-11-15 12:42 ` Mike Frysinger
2010-11-15 12:52 ` Mike Frysinger
0 siblings, 2 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 12:38 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 06:33:40 Mike Frysinger wrote:
> On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote:
> > Sebastien Carlier wrote:
> > > I just uploaded the revised patch here:
> > > http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-
arch
> > > iv e-libraries-to-partial-linking-v4.patch
> > >
> > > Version 4:
> > > Bring in Linux comment for cmd_link_o_target.
> > > Fix drivers/qe/Makefile to build libqe.o, not qe.o.
> > >
> > > I pulled the latest changes before making the patch and there was no
> > > conflict, but please let me know if you see anything wrong with it.
> >
> > Thanks a lot.
> >
> > I notice that the patch affects the size of the resulting U-Boot
> > images.
> >
> > For example:
> >
> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> >
> > text data bss dec hex filename
> >
> > 358144 35208 303248 696600 aa118 ./u-boot before
> > 361340 35824 303332 700496 ab050 ./u-boot after
> >
> > -------------------------------
> >
> > Delta: +3896 Bytes
> >
> > For other boards it's only a few hundred bytes, but why do we see
> > such big increase here?
>
> some of this is probably because of missing build system support. there
> are some files which are always compiled when they shouldnt be but in the
> past, this wasnt a problem because they were stuck in an .a and the linker
> wouldnt pull them in since no one requested them.
>
> on my side, i see this with at least these files:
> cmd_pcmcia.c
> file.c
> ldiv.c
> memsize.c
> rpx_pcmcia.c
> tqm8xx_pcmcia.c
>
> although i'm still seeing a few hundred byte increase in my .text/.bss, but
> the symbol map is unchanged ...
some of this is simply due to change in linking order and the implicit padding
in between each symbol for alignment requirements
you can check how much this adds with the attached script:
$ ./align-padding u-boot .text | tail -n1
586
$ ./align-padding old/u-boot .text | tail -n1
490
replace the '$7 == "3"' check with whatever section number you want to check.
in my case, 3 is ".text". i see a 96 byte change in my .text due to this, but
i wouldnt blame this patch for it. and similar changes for
.data/.bss/.rodata.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: align-padding
Type: application/x-shellscript
Size: 389 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/9241574f/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/9241574f/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-15 12:13 ` Sebastien Carlier
@ 2010-11-15 12:39 ` Mike Frysinger
2010-11-16 14:58 ` Detlev Zundel
0 siblings, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 12:39 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > I notice that the patch affects the size of the resulting U-Boot
> > images.
> >
> > For example:
> >
> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> >
> > text data bss dec hex filename
> >
> > 358144 35208 303248 696600 aa118 ./u-boot before
> > 361340 35824 303332 700496 ab050 ./u-boot after
> >
> > -------------------------------
> >
> > Delta: +3896 Bytes
> >
> > For other boards it's only a few hundred bytes, but why do we see
> > such big increase here?
>
> In this case, these libraries contribute 3260 bytes in unused
> definitions:
>
> In each case, a whole object file contains exactly the unused
> definitions, and could be excluded in the respective Makefile.
or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont
worry about it. which is what we do for the Blackfin port.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/39a3a558/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 12:38 ` Mike Frysinger
@ 2010-11-15 12:42 ` Mike Frysinger
2010-11-15 12:52 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 12:42 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
> replace the '$7 == "3"' check with whatever section number you want to
> check. in my case, 3 is ".text".
err, ignore this outdated comment
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/a80f7ba4/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 12:38 ` Mike Frysinger
2010-11-15 12:42 ` Mike Frysinger
@ 2010-11-15 12:52 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 12:52 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote:
> some of this is simply due to change in linking order and the implicit
> padding in between each symbol for alignment requirements
>
> you can check how much this adds with the attached script:
this version fixes handling with defined weak symbols and with very large
symbols (readelf will use hex for them)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: align-padding
Type: application/x-shellscript
Size: 514 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/886d8194/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/886d8194/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 8:09 ` Sebastien Carlier
2010-11-15 10:54 ` Wolfgang Denk
@ 2010-11-15 19:44 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-15 19:44 UTC (permalink / raw)
To: u-boot
On Monday, November 15, 2010 03:09:50 Sebastien Carlier wrote:
> On 2010-11-15 08:51:29, Wolfgang Denk wrote:
> > In message <20101110080708.GA8145@safe.home.local> you wrote:
> > > Good suggestion, done in v3:
> > I have to admit that I lost a bit of overview of the current state of
> > this work. My understanding is that you are preparing a new version
> > (V4 ?) of this patch?
> >
> > If yes, do you have any estimates when this will be available?
>
> I just uploaded the revised patch here:
>
> http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-
archive-
> libraries-to-partial-linking-v4.patch
>
> Version 4:
> Bring in Linux comment for cmd_link_o_target.
> Fix drivers/qe/Makefile to build libqe.o, not qe.o.
>
> I pulled the latest changes before making the patch and there was no
> conflict, but please let me know if you see anything wrong with it.
Tested-by: Mike Frysinger <vapier@gentoo.org> (Blackfin boards)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101115/269a44c5/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-15 12:39 ` Mike Frysinger
@ 2010-11-16 14:58 ` Detlev Zundel
2010-11-16 16:33 ` Mike Frysinger
0 siblings, 1 reply; 79+ messages in thread
From: Detlev Zundel @ 2010-11-16 14:58 UTC (permalink / raw)
To: u-boot
Hi,
> On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
>> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>> > I notice that the patch affects the size of the resulting U-Boot
>> > images.
>> >
>> > For example:
>> >
>> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
>> >
>> > text data bss dec hex filename
>> >
>> > 358144 35208 303248 696600 aa118 ./u-boot before
>> > 361340 35824 303332 700496 ab050 ./u-boot after
>> >
>> > -------------------------------
>> >
>> > Delta: +3896 Bytes
>> >
>> > For other boards it's only a few hundred bytes, but why do we see
>> > such big increase here?
>>
>> In this case, these libraries contribute 3260 bytes in unused
>> definitions:
>>
>> In each case, a whole object file contains exactly the unused
>> definitions, and could be excluded in the respective Makefile.
>
> or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont
> worry about it. which is what we do for the Blackfin port.
If you do worry, you can use the "--gc-sections" together with
"--print-gc-sections" to actually find out what is unused[1].
Cheers
Detlev
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84971/
--
"Oh, didn't you know, the Lord did the original programming of the universe in
COBOL." - "That's why the world is the evil work of Satan. A true divine being
would have used Scheme." - "And, if so, Jesus would have been crucified on a
big lambda symbol." -- K. Chafin, K. Schilling & D. Hanley, on comp.lang.lisp
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-16 14:58 ` Detlev Zundel
@ 2010-11-16 16:33 ` Mike Frysinger
2010-11-17 12:30 ` Detlev Zundel
0 siblings, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-16 16:33 UTC (permalink / raw)
To: u-boot
On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
> > On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
> >> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> >> > I notice that the patch affects the size of the resulting U-Boot
> >> > images.
> >> >
> >> > For example:
> >> >
> >> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> >> >
> >> > text data bss dec hex filename
> >> >
> >> > 358144 35208 303248 696600 aa118 ./u-boot before
> >> > 361340 35824 303332 700496 ab050 ./u-boot after
> >> >
> >> > -------------------------------
> >> >
> >> > Delta: +3896 Bytes
> >> >
> >> > For other boards it's only a few hundred bytes, but why do we see
> >> > such big increase here?
> >>
> >> In this case, these libraries contribute 3260 bytes in unused
> >> definitions:
> >>
> >> In each case, a whole object file contains exactly the unused
> >> definitions, and could be excluded in the respective Makefile.
> >
> > or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and
> > dont worry about it. which is what we do for the Blackfin port.
>
> If you do worry, you can use the "--gc-sections" together with
> "--print-gc-sections" to actually find out what is unused[1].
the u-boot.map also mentions which input sections are discarded without
needing --print-gc-sections ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101116/817527da/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
2010-11-16 16:33 ` Mike Frysinger
@ 2010-11-17 12:30 ` Detlev Zundel
0 siblings, 0 replies; 79+ messages in thread
From: Detlev Zundel @ 2010-11-17 12:30 UTC (permalink / raw)
To: u-boot
Hi Mike,
> On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
>> > On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
>> >> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>> >> > I notice that the patch affects the size of the resulting U-Boot
>> >> > images.
>> >> >
>> >> > For example:
>> >> >
>> >> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
>> >> >
>> >> > text data bss dec hex filename
>> >> >
>> >> > 358144 35208 303248 696600 aa118 ./u-boot before
>> >> > 361340 35824 303332 700496 ab050 ./u-boot after
>> >> >
>> >> > -------------------------------
>> >> >
>> >> > Delta: +3896 Bytes
>> >> >
>> >> > For other boards it's only a few hundred bytes, but why do we see
>> >> > such big increase here?
>> >>
>> >> In this case, these libraries contribute 3260 bytes in unused
>> >> definitions:
>> >>
>> >> In each case, a whole object file contains exactly the unused
>> >> definitions, and could be excluded in the respective Makefile.
>> >
>> > or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and
>> > dont worry about it. which is what we do for the Blackfin port.
>>
>> If you do worry, you can use the "--gc-sections" together with
>> "--print-gc-sections" to actually find out what is unused[1].
>
> the u-boot.map also mentions which input sections are discarded without
> needing --print-gc-sections ...
Intersting, I didn't realize this. Thanks!
Detlev
--
While the list of different methods is not endless, it is certainly
pretty long, with new ones being dreamed up all the time. Fortunately,
space limitations prevent us from looking at all of them.
-- Andrew S. Tanenbaum
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-15 10:54 ` Wolfgang Denk
` (2 preceding siblings ...)
2010-11-15 12:13 ` Sebastien Carlier
@ 2010-11-17 13:30 ` Sebastien Carlier
2010-11-17 13:50 ` Wolfgang Denk
` (2 more replies)
3 siblings, 3 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-17 13:30 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
>
> I notice that the patch affects the size of the resulting U-Boot
> images.
The size increase you noted seems to completely go away when adding
--gc-sections to LDFLAGS, but this option apparently brings its own
issues when the linker discards important unreferenced bits:
http://www.mail-archive.com/u-boot at lists.denx.de/msg41762.html
http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html
These problems can be fixed within linker scripts, but I think it might
be safer to use --gc-sections for diagnostic purposes only...
> MPC8xx boards break with long lists of multiple definitions of
> symbols, like that:
>
> Configuring for FPS860L board...
> lib/libgeneric.o: In function `vsprintf':
> /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
> ...
>
> Have you seen that, too?
Unfortunately I have not been able to reproduce these errors with the
toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
emdebian squeeze packages). Can you please point me to the toolchain
you are using?
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
@ 2010-11-17 13:50 ` Wolfgang Denk
2010-11-17 18:06 ` Mike Frysinger
2010-11-18 21:44 ` Wolfgang Denk
2 siblings, 0 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-17 13:50 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <20101117133056.GB23875@safe.home.local> you wrote:
>
> Unfortunately I have not been able to reproduce these errors with the
> toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
> emdebian squeeze packages). Can you please point me to the toolchain
> you are using?
I'm using ELDk 4.2 as reference. Please see
ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more sins you confess, the more books you will sell.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-17 13:50 ` Wolfgang Denk
@ 2010-11-17 18:06 ` Mike Frysinger
2010-11-17 19:53 ` Sebastien Carlier
2010-11-18 21:44 ` Wolfgang Denk
2 siblings, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-17 18:06 UTC (permalink / raw)
To: u-boot
On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > I notice that the patch affects the size of the resulting U-Boot
> > images.
>
> The size increase you noted seems to completely go away when adding
> --gc-sections to LDFLAGS, but this option apparently brings its own
> issues when the linker discards important unreferenced bits:
>
> http://www.mail-archive.com/u-boot at lists.denx.de/msg41762.html
> http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html
>
> These problems can be fixed within linker scripts, but I think it might
> be safer to use --gc-sections for diagnostic purposes only...
it's really not that hard to fix things to work with --gc-sections (ive been
using it on Blackfin for literally years at this point). people really should
be driving to have that supported everywhere.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101117/e8cc8183/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-17 18:06 ` Mike Frysinger
@ 2010-11-17 19:53 ` Sebastien Carlier
2010-11-17 22:19 ` Mike Frysinger
0 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-17 19:53 UTC (permalink / raw)
To: u-boot
Dear Mike,
On 2010-11-17 13:06:49, Mike Frysinger wrote:
> On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> > On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > > I notice that the patch affects the size of the resulting U-Boot
> > > images.
> >
> > The size increase you noted seems to completely go away when adding
> > --gc-sections to LDFLAGS, but this option apparently brings its own
> > issues when the linker discards important unreferenced bits:
> >
> > http://www.mail-archive.com/u-boot at lists.denx.de/msg41762.html
> > http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html
> >
> > These problems can be fixed within linker scripts, but I think it might
> > be safer to use --gc-sections for diagnostic purposes only...
>
> it's really not that hard to fix things to work with --gc-sections (ive been
> using it on Blackfin for literally years at this point). people really should
> be driving to have that supported everywhere.
Maybe I was being overly conservative. With --gc-sections, I assume the
linker only needs to be told to keep any section that has no external
references to it, which would only include startup code and reset
vectors. Is that accurate? Is there any other case that may need
special handling?
I suppose -ffunction-sections and -fdata-sections increase compile time;
are they worth it in practice? The few cases I have seen involved whole
objects being unused, so just --gc-sections would deal with them.
--
S?bastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-17 19:53 ` Sebastien Carlier
@ 2010-11-17 22:19 ` Mike Frysinger
0 siblings, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-17 22:19 UTC (permalink / raw)
To: u-boot
On Wednesday, November 17, 2010 14:53:33 Sebastien Carlier wrote:
> On 2010-11-17 13:06:49, Mike Frysinger wrote:
> > On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> > > The size increase you noted seems to completely go away when adding
> > > --gc-sections to LDFLAGS, but this option apparently brings its own
> > >
> > > issues when the linker discards important unreferenced bits:
> > > http://www.mail-archive.com/u-boot at lists.denx.de/msg41762.html
> > > http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html
> > >
> > > These problems can be fixed within linker scripts, but I think it might
> > > be safer to use --gc-sections for diagnostic purposes only...
> >
> > it's really not that hard to fix things to work with --gc-sections (ive
> > been using it on Blackfin for literally years at this point). people
> > really should be driving to have that supported everywhere.
>
> Maybe I was being overly conservative. With --gc-sections, I assume the
> linker only needs to be told to keep any section that has no external
> references to it, which would only include startup code and reset
> vectors. Is that accurate?
yes
> Is there any other case that may need special handling?
the u-boot command handling is a bit funky and needs handling, but that was
implemented years ago in common code, so ports need not worry about it
> I suppose -ffunction-sections and -fdata-sections increase compile time;
> are they worth it in practice?
in practice, the difference is irrelevant. for the bf548-ezkit build (a
fairly large image -- in the 512KiB range), i run on a dual core system:
git clean -x -d -q
time make -s -j2 bf548-ezkit
with the section flags, i get ~5.7 seconds. without, i get ~5.1 seconds.
> The few cases I have seen involved whole
> objects being unused, so just --gc-sections would deal with them.
it also takes care of unused common code and library functions. for Blackfin
systems, i provide the full common GPIO API in one file, but any local funcs
that no one uses all get discarded.
it also keeps down horrible ifdef messes where the only point point would be
to move gcc's DCE step to CPP.
again, to refer to the bf548-ezkit, i get ~10KB of .text removed by this alone
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101117/37272b9c/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-17 13:50 ` Wolfgang Denk
2010-11-17 18:06 ` Mike Frysinger
@ 2010-11-18 21:44 ` Wolfgang Denk
2010-11-18 22:08 ` Albert ARIBAUD
2010-11-19 7:50 ` Sebastien Carlier
2 siblings, 2 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-18 21:44 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <20101117133056.GB23875@safe.home.local> you wrote:
>
> > MPC8xx boards break with long lists of multiple definitions of
> > symbols, like that:
> >
> > Configuring for FPS860L board...
> > lib/libgeneric.o: In function `vsprintf':
> > /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
> > ...
> >
> > Have you seen that, too?
>
> Unfortunately I have not been able to reproduce these errors with the
> toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
> emdebian squeeze packages). Can you please point me to the toolchain
> you are using?
Are you sure this doesn't happen with your tool chain?
I found out why this happens, and I think the effect should be
independent of the used tool chain:
For example, in "board/tqc/tqm8xx/u-boot.lds" we arrange to have the
environment located in one of the "small" NOR flash sectors:
...
53 .text :
54 {
55 /* WARNING - the following is hand-optimized to fit within */
56 /* the sector layout of our flash chips! XXX FIXME XXX */
57
58 arch/powerpc/cpu/mpc8xx/start.o (.text)
59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
60 common/dlmalloc.o (.text)
61 arch/powerpc/lib/ppcstring.o (.text)
62 lib/vsprintf.o (.text)
63 lib/crc32.o (.text)
64 lib/zlib.o (.text)
65 arch/powerpc/lib/cache.o (.text)
66
67 . = DEFINED(env_offset) ? env_offset : .;
68 common/env_embedded.o (.ppcenv)
69
70 *(.text)
71 *(.got1)
...
That means, the linker script pulls in certain object files directly.
Before, when linking with libraries, this was no problem, as the
linker would pull only (so far) unresolved symbols from the libraries
specified on the command line. Now, we include these individual
object files through the linker script, and then again when specifying
the "library" objects on the command line - which necessarily results
in "multiple definition" errors.
Unfortunately I don't know how to solve this yet. Does anybody know of
a way how to manually arrange the objects (or symbols) in the linked
image?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
My challenge to the goto-less programmer is to recode tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-18 21:44 ` Wolfgang Denk
@ 2010-11-18 22:08 ` Albert ARIBAUD
2010-11-18 22:33 ` Wolfgang Denk
2010-11-19 7:50 ` Sebastien Carlier
1 sibling, 1 reply; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-18 22:08 UTC (permalink / raw)
To: u-boot
Le 18/11/2010 22:44, Wolfgang Denk a ?crit :
> Dear Sebastien Carlier,
>
> In message<20101117133056.GB23875@safe.home.local> you wrote:
>>
>>> MPC8xx boards break with long lists of multiple definitions of
>>> symbols, like that:
>>>
>>> Configuring for FPS860L board...
>>> lib/libgeneric.o: In function `vsprintf':
>>> /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
>>> ...
>>>
>>> Have you seen that, too?
>>
>> Unfortunately I have not been able to reproduce these errors with the
>> toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
>> emdebian squeeze packages). Can you please point me to the toolchain
>> you are using?
>
> Are you sure this doesn't happen with your tool chain?
>
> I found out why this happens, and I think the effect should be
> independent of the used tool chain:
>
> For example, in "board/tqc/tqm8xx/u-boot.lds" we arrange to have the
> environment located in one of the "small" NOR flash sectors:
>
> ....
> 53 .text :
> 54 {
> 55 /* WARNING - the following is hand-optimized to fit within */
> 56 /* the sector layout of our flash chips! XXX FIXME XXX */
> 57
> 58 arch/powerpc/cpu/mpc8xx/start.o (.text)
> 59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
> 60 common/dlmalloc.o (.text)
> 61 arch/powerpc/lib/ppcstring.o (.text)
> 62 lib/vsprintf.o (.text)
> 63 lib/crc32.o (.text)
> 64 lib/zlib.o (.text)
> 65 arch/powerpc/lib/cache.o (.text)
> 66
> 67 . = DEFINED(env_offset) ? env_offset : .;
> 68 common/env_embedded.o (.ppcenv)
> 69
> 70 *(.text)
> 71 *(.got1)
> ....
>
> That means, the linker script pulls in certain object files directly.
> Before, when linking with libraries, this was no problem, as the
> linker would pull only (so far) unresolved symbols from the libraries
> specified on the command line. Now, we include these individual
> object files through the linker script, and then again when specifying
> the "library" objects on the command line - which necessarily results
> in "multiple definition" errors.
Are you sure of this? From
<http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics>,
specifying a file name in the linker file *and* on the command line
should not lead to a double inclusion of the object file:
"When you use a file name which is not an `archive:file' specifier and
does not contain any wild card characters, the linker will first see if
you also specified the file name on the linker command line or in an
INPUT command. If you did not, the linker will attempt to open the file
as an input file, as though it appeared on the command line."
> Unfortunately I don't know how to solve this yet. Does anybody know of
> a way how to manually arrange the objects (or symbols) in the linked
> image?
>
>
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-18 22:08 ` Albert ARIBAUD
@ 2010-11-18 22:33 ` Wolfgang Denk
2010-11-19 6:36 ` Albert ARIBAUD
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-18 22:33 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <4CE5A3F1.50304@free.fr> you wrote:
>
> > 58 arch/powerpc/cpu/mpc8xx/start.o (.text)
> > 59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
> > 60 common/dlmalloc.o (.text)
> > 61 arch/powerpc/lib/ppcstring.o (.text)
> > 62 lib/vsprintf.o (.text)
> > 63 lib/crc32.o (.text)
> > 64 lib/zlib.o (.text)
> > 65 arch/powerpc/lib/cache.o (.text)
> > 66
> > 67 . = DEFINED(env_offset) ? env_offset : .;
> > 68 common/env_embedded.o (.ppcenv)
...
> Are you sure of this? From
> <http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics>,
> specifying a file name in the linker file *and* on the command line
> should not lead to a double inclusion of the object file:
I'm sure that I see the errors.
I see two possible reasons: 1) whay you describe is a new feature in
binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the
linker does not realize it because it's actually different file names:
for example, vsprintf() gets included in the linker script directly
through lib/vsprintf.o, and throught he command line as
lib/libgeneric.o ==> two different file names.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ever try. Ever fail. No matter. Try again. Fail again. Fail better.
-- S. Beckett
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-18 22:33 ` Wolfgang Denk
@ 2010-11-19 6:36 ` Albert ARIBAUD
2010-11-19 8:03 ` Wolfgang Denk
2010-11-19 8:04 ` Sebastien Carlier
0 siblings, 2 replies; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-19 6:36 UTC (permalink / raw)
To: u-boot
Le 18/11/2010 23:33, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CE5A3F1.50304@free.fr> you wrote:
>>
>>> 58 arch/powerpc/cpu/mpc8xx/start.o (.text)
>>> 59 arch/powerpc/cpu/mpc8xx/traps.o (.text)
>>> 60 common/dlmalloc.o (.text)
>>> 61 arch/powerpc/lib/ppcstring.o (.text)
>>> 62 lib/vsprintf.o (.text)
>>> 63 lib/crc32.o (.text)
>>> 64 lib/zlib.o (.text)
>>> 65 arch/powerpc/lib/cache.o (.text)
>>> 66
>>> 67 . = DEFINED(env_offset) ? env_offset : .;
>>> 68 common/env_embedded.o (.ppcenv)
> ....
>> Are you sure of this? From
>> <http://sourceware.org/binutils/docs-2.20/ld/Input-Section-Basics.html#Input-Section-Basics>,
>> specifying a file name in the linker file *and* on the command line
>> should not lead to a double inclusion of the object file:
>
> I'm sure that I see the errors.
>
> I see two possible reasons: 1) whay you describe is a new feature in
> binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the
> linker does not realize it because it's actually different file names:
> for example, vsprintf() gets included in the linker script directly
> through lib/vsprintf.o, and throught he command line as
> lib/libgeneric.o ==> two different file names.
Most probably 2); mentioning a file in the linker script either with or
without mentioning it on the command line has certainly been done for
some time, so I doubt the feature is new; and certainly the doc is about
files, not symbols in different files.
And, to get back to possible solutions, I don't know that the linker can
map selected symbols onto specific regions; it can only place whole
object files.
The simplest, though not cleanest, way I can think of is to put
conditionals to not compile vsprintf() in lib/generic, and set those
conditions from the board config file -- and same for anything else.
Ugly, but it will work.
A second solution, a bit more intrusive, would be to split lib/generic
in two files; a "small" one which could be mapped in the small area, and
the rest, which would map with the rest of the image.
> Best regards,
>
> Wolfgang Denk
>
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-18 21:44 ` Wolfgang Denk
2010-11-18 22:08 ` Albert ARIBAUD
@ 2010-11-19 7:50 ` Sebastien Carlier
2010-11-19 8:08 ` Wolfgang Denk
2010-11-19 8:10 ` Mike Frysinger
1 sibling, 2 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-19 7:50 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-18 22:44:48, Wolfgang Denk wrote:
> >
> > Unfortunately I have not been able to reproduce these errors with the
> > toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
> > emdebian squeeze packages). Can you please point me to the toolchain
> > you are using?
>
> Are you sure this doesn't happen with your tool chain?
Weird, I tried the FPS860L configuration again and now I can see these
errors with my toolchain. Not sure what I did wrong the first time
around.
> I found out why this happens, and I think the effect should be
> independent of the used tool chain:
Great! I have been quite busy for the last couple days, sorry I hadn't
been able to check it out yet.
> Unfortunately I don't know how to solve this yet. Does anybody know of
> a way how to manually arrange the objects (or symbols) in the linked
> image?
Sounds difficult once object files have been linked into a new partial
object... I do not know if it would be practical to use sections
instead, it depends what needs to be achieved.
It looks like the purpose is to optimally fill a flash sector with
definitions, is this accurate? Why is this needed? Beside the obvious
(reset vectors, startup code), is there any reason to prefer any given
definition to go into the sector being filled?
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 6:36 ` Albert ARIBAUD
@ 2010-11-19 8:03 ` Wolfgang Denk
2010-11-20 0:07 ` Mike Frysinger
2010-11-19 8:04 ` Sebastien Carlier
1 sibling, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 8:03 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <4CE61AD5.50900@free.fr> you wrote:
>
> Most probably 2); mentioning a file in the linker script either with or
> without mentioning it on the command line has certainly been done for
> some time, so I doubt the feature is new; and certainly the doc is about
> files, not symbols in different files.
There seems to be a (here significant) difference between object files
on the command line and libraries (which appear to be handled like
a mere collection of object files).
> And, to get back to possible solutions, I don't know that the linker can
> map selected symbols onto specific regions; it can only place whole
> object files.
There must be a way ;-)
> The simplest, though not cleanest, way I can think of is to put
> conditionals to not compile vsprintf() in lib/generic, and set those
> conditions from the board config file -- and same for anything else.
> Ugly, but it will work.
>
> A second solution, a bit more intrusive, would be to split lib/generic
> in two files; a "small" one which could be mapped in the small area, and
> the rest, which would map with the rest of the image.
That doesn't scale - the set is sifferent on a per-board base, which
would result in a terrible mess.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Worlds may change, galaxies disintegrate, but a woman always remains
a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 6:36 ` Albert ARIBAUD
2010-11-19 8:03 ` Wolfgang Denk
@ 2010-11-19 8:04 ` Sebastien Carlier
1 sibling, 0 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-19 8:04 UTC (permalink / raw)
To: u-boot
On 2010-11-19 07:36:05, Albert ARIBAUD wrote:
>
> Le 18/11/2010 23:33, Wolfgang Denk a ?crit :
> >
> > I see two possible reasons: 1) whay you describe is a new feature in
> > binutils 2.20; I'm currently using 2.17.50 (with ELDk 4.2); or 2) the
> > linker does not realize it because it's actually different file names:
> > for example, vsprintf() gets included in the linker script directly
> > through lib/vsprintf.o, and throught he command line as
> > lib/libgeneric.o ==> two different file names.
>
> Most probably 2); mentioning a file in the linker script either with or
> without mentioning it on the command line has certainly been done for
> some time, so I doubt the feature is new; and certainly the doc is about
> files, not symbols in different files.
Sounds right, reason 2) completely makes sense.
> And, to get back to possible solutions, I don't know that the linker can
> map selected symbols onto specific regions; it can only place whole
> object files.
Could we place the object files in distinct sections, and then map these
sections into specific regions?
> The simplest, though not cleanest, way I can think of is to put
> conditionals to not compile vsprintf() in lib/generic, and set those
> conditions from the board config file -- and same for anything else.
> Ugly, but it will work.
Perhaps an even simpler solution would be to go back to archive
libraries and use ld --whole-archives. It would leave object names
intact and thus avoid double-inclusions.
> A second solution, a bit more intrusive, would be to split lib/generic
> in two files; a "small" one which could be mapped in the small area, and
> the rest, which would map with the rest of the image.
Perhaps section declarations could be used to achieve this without
having to split the files? It seems challenging to come up with a way
to do this to optimally fill a given sector, though.
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 7:50 ` Sebastien Carlier
@ 2010-11-19 8:08 ` Wolfgang Denk
2010-11-19 8:34 ` Sebastien Carlier
2010-11-19 8:10 ` Mike Frysinger
1 sibling, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 8:08 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <sebastien.carlier@1e724f1c01c015f817d5e33b57e7134d4468dbcc> you wrote:
>
> It looks like the purpose is to optimally fill a flash sector with
> definitions, is this accurate? Why is this needed? Beside the obvious
Correct.
> (reset vectors, startup code), is there any reason to prefer any given
> definition to go into the sector being filled?
Well, we want to squeeze as many code into the first sectores, to
minimize the unused space. So far this was trivial, as I just could
pick object files of suitable size. Now we have to come up with a new
solution.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Calm down, it's *__only* ones and zeroes.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 7:50 ` Sebastien Carlier
2010-11-19 8:08 ` Wolfgang Denk
@ 2010-11-19 8:10 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-19 8:10 UTC (permalink / raw)
To: u-boot
On Friday, November 19, 2010 02:50:37 Sebastien Carlier wrote:
> It looks like the purpose is to optimally fill a flash sector with
> definitions, is this accurate? Why is this needed? Beside the obvious
> (reset vectors, startup code), is there any reason to prefer any given
> definition to go into the sector being filled?
i havent looked at this particular case, but often it's because we need to
carve out a sector for an embedded env and the linker script syntax isnt good
enough to say "start filling this section and once it's filled, start filling
this other one". that'd be awesome.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101119/0d6156e1/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 8:08 ` Wolfgang Denk
@ 2010-11-19 8:34 ` Sebastien Carlier
2010-11-19 11:11 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-19 8:34 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-19 09:08:33, Wolfgang Denk wrote:
>
> In message <sebastien.carlier@1e724f1c01c015f817d5e33b57e7134d4468dbcc> you wrote:
> >
> > It looks like the purpose is to optimally fill a flash sector with
> > definitions, is this accurate? Why is this needed? Beside the obvious
>
> Correct.
>
> > (reset vectors, startup code), is there any reason to prefer any given
> > definition to go into the sector being filled?
>
> Well, we want to squeeze as many code into the first sectores, to
> minimize the unused space.
I am still not getting why the code needs to be split this way, rather
than being a continuous segment followed by an environment sector.
Whether the environment sector is in the middle of the binary or
immediately after the binary does not make a difference (does it?), so
the motivation must be something else...
> So far this was trivial, as I just could pick object files of suitable
> size. Now we have to come up with a new solution.
Sounds like you enjoyed solving knapsack problems :-)
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 8:34 ` Sebastien Carlier
@ 2010-11-19 11:11 ` Wolfgang Denk
2010-11-19 11:40 ` Albert ARIBAUD
2010-11-19 12:33 ` Sebastien Carlier
0 siblings, 2 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 11:11 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you wrote:
>
> I am still not getting why the code needs to be split this way, rather
> than being a continuous segment followed by an environment sector.
> Whether the environment sector is in the middle of the binary or
> immediately after the binary does not make a difference (does it?), so
> the motivation must be something else...
The used flash chips are so-called bootom boot sector types; using two
chips in 16 bit config in parallel (to get a 32 bit bus) we see this
flash layout:
Sector Start Addresses:
40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO
40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E
400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E
40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E
40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E
402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E
40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
With a normal configuration, U-Boot code wouild occupy all the small
sectors, and we would have to waste two of the 128 kB blocks for
environment plus redundant copy.
It makes a lot sense to me to reserve a "gap" in the U-Boot image and
put the environment instead into the two 16 kB sectors starting at
40008000 and 4000C000.
The linker script squeezes as many as possible objects into the first
32 kB ssector, then creates a gap for the environment, and ten
continues to place the remaining objects starting at offset 40010000.
That's what we call "embedded environment", because it sits right in
the middle of the U-Boot image.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It's when they say 2 + 2 = 5 that I begin to argue." - Eric Pepke
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 11:11 ` Wolfgang Denk
@ 2010-11-19 11:40 ` Albert ARIBAUD
2010-11-19 11:48 ` Wolfgang Denk
2010-11-19 12:33 ` Sebastien Carlier
1 sibling, 1 reply; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-19 11:40 UTC (permalink / raw)
To: u-boot
Le 19/11/2010 12:11, Wolfgang Denk a ?crit :
> Dear Sebastien Carlier,
>
> In message<sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you wrote:
>>
>> I am still not getting why the code needs to be split this way, rather
>> than being a continuous segment followed by an environment sector.
>> Whether the environment sector is in the middle of the binary or
>> immediately after the binary does not make a difference (does it?), so
>> the motivation must be something else...
>
> The used flash chips are so-called bootom boot sector types; using two
> chips in 16 bit config in parallel (to get a 32 bit bus) we see this
> flash layout:
>
> Sector Start Addresses:
> 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO
> 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E
> 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E
> 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E
> 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E
> 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E
> 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
>
> So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
>
> With a normal configuration, U-Boot code wouild occupy all the small
> sectors, and we would have to waste two of the 128 kB blocks for
> environment plus redundant copy.
>
> It makes a lot sense to me to reserve a "gap" in the U-Boot image and
> put the environment instead into the two 16 kB sectors starting at
> 40008000 and 4000C000.
>
> The linker script squeezes as many as possible objects into the first
> 32 kB ssector, then creates a gap for the environment, and ten
> continues to place the remaining objects starting at offset 40010000.
>
> That's what we call "embedded environment", because it sits right in
> the middle of the U-Boot image.
There is a variant of this problem with many ARM boards, those based on
Marvell SoCs for instance, which have a start address at 0xFFFF0000 --
that's a 64K block the usage of which we want to maximize.
I had a general solution to this by, in summary, building a linear
u-boot, then splitting the binary when flashing, and have the copy loop
in the startup stitch back the parts. However, this solution did not
work well with relocation, and may not necessarily be applicable to
non-ARM archs. However, now that we have a (mostly) stabilized
relocation mechanism, I'll dig again into this solution.
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 11:40 ` Albert ARIBAUD
@ 2010-11-19 11:48 ` Wolfgang Denk
2010-11-19 12:11 ` Albert ARIBAUD
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 11:48 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <4CE66215.2030103@free.fr> you wrote:
>
> There is a variant of this problem with many ARM boards, those based on
> Marvell SoCs for instance, which have a start address at 0xFFFF0000 --
> that's a 64K block the usage of which we want to maximize.
Yes, that's basicly a simialr problem.
> I had a general solution to this by, in summary, building a linear
> u-boot, then splitting the binary when flashing, and have the copy loop
> in the startup stitch back the parts. However, this solution did not
> work well with relocation, and may not necessarily be applicable to
> non-ARM archs. However, now that we have a (mostly) stabilized
> relocation mechanism, I'll dig again into this solution.
The problem is that we're now linked for running in flash, so the
linker should be the tool that performs the location of code into the
output image.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 11:48 ` Wolfgang Denk
@ 2010-11-19 12:11 ` Albert ARIBAUD
0 siblings, 0 replies; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-19 12:11 UTC (permalink / raw)
To: u-boot
Le 19/11/2010 12:48, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CE66215.2030103@free.fr> you wrote:
>>
>> There is a variant of this problem with many ARM boards, those based on
>> Marvell SoCs for instance, which have a start address at 0xFFFF0000 --
>> that's a 64K block the usage of which we want to maximize.
>
> Yes, that's basicly a simialr problem.
>
>> I had a general solution to this by, in summary, building a linear
>> u-boot, then splitting the binary when flashing, and have the copy loop
>> in the startup stitch back the parts. However, this solution did not
>> work well with relocation, and may not necessarily be applicable to
>> non-ARM archs. However, now that we have a (mostly) stabilized
>> relocation mechanism, I'll dig again into this solution.
>
> The problem is that we're now linked for running in flash, so the
> linker should be the tool that performs the location of code into the
> output image.
Indeed.
But then, there's where your code was linked for, where it will relocate
to... and where it actually runs.
After all, ELF relocation would work equally well whatever the link
location.
Yes, I know that running code somewhere else than where it was linked
for may be difficult. But not necessarily impossible, and I *think* I
can find a way.
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 11:11 ` Wolfgang Denk
2010-11-19 11:40 ` Albert ARIBAUD
@ 2010-11-19 12:33 ` Sebastien Carlier
2010-11-19 12:38 ` Albert ARIBAUD
2010-11-19 12:55 ` Wolfgang Denk
1 sibling, 2 replies; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-19 12:33 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 2010-11-19 12:11:12, Wolfgang Denk wrote:
>
> In message <sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you wrote:
> >
> The used flash chips are so-called bootom boot sector types; using two
> chips in 16 bit config in parallel (to get a 32 bit bus) we see this
> flash layout:
>
> Sector Start Addresses:
> 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO
> 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E
> 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E
> 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E
> 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E
> 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E
> 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
>
> So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
Oh, I see. I wasn't aware that some flash chips had non-uniform sector
sizes. It makes perfect sense not to waste much of a larger sector to
store the environment. Thank you very much for clarifying!
> The linker script squeezes as many as possible objects into the first
> 32 kB ssector, then creates a gap for the environment, and ten
> continues to place the remaining objects starting at offset 40010000.
Is it not possible to tell the linker to place a made-up 32 kB symbol
within the text section at address 0x40008000? I am not familiar enough
with ld to tell whether there are restrictions for setting the absolute
address of a symbol that would disallow it in this case.
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 12:33 ` Sebastien Carlier
@ 2010-11-19 12:38 ` Albert ARIBAUD
2010-11-19 13:02 ` Sebastien Carlier
2010-11-19 12:55 ` Wolfgang Denk
1 sibling, 1 reply; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-19 12:38 UTC (permalink / raw)
To: u-boot
Le 19/11/2010 13:33, Sebastien Carlier a ?crit :
> Dear Wolfgang,
>
> On 2010-11-19 12:11:12, Wolfgang Denk wrote:
>>
>> In message<sebastien.carlier@f67ce90ecc8846695b88fb9ac74f99d56979b90a> you wrote:
>>>
>> The used flash chips are so-called bootom boot sector types; using two
>> chips in 16 bit config in parallel (to get a 32 bit bus) we see this
>> flash layout:
>>
>> Sector Start Addresses:
>> 40000000 RO 40008000 RO 4000C000 RO 40010000 RO 40020000 RO
>> 40040000 RO 40060000 E 40080000 E 400A0000 E 400C0000 E
>> 400E0000 E 40100000 E 40120000 E 40140000 E 40160000 E
>> 40180000 E 401A0000 E 401C0000 E 401E0000 E 40200000 E
>> 40220000 E 40240000 E 40260000 E 40280000 E 402A0000 E
>> 402C0000 E 402E0000 E 40300000 E 40320000 E 40340000 E
>> 40360000 E 40380000 E 403A0000 E 403C0000 E 403E0000 E
>>
>> So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
>
> Oh, I see. I wasn't aware that some flash chips had non-uniform sector
> sizes. It makes perfect sense not to waste much of a larger sector to
> store the environment. Thank you very much for clarifying!
>
>> The linker script squeezes as many as possible objects into the first
>> 32 kB ssector, then creates a gap for the environment, and ten
>> continues to place the remaining objects starting at offset 40010000.
>
> Is it not possible to tell the linker to place a made-up 32 kB symbol
> within the text section at address 0x40008000? I am not familiar enough
> with ld to tell whether there are restrictions for setting the absolute
> address of a symbol that would disallow it in this case.
>
> Regards,
You can force a symbol to reside at a given offset, but that will not
make the linker "skip" that symbol when filling the output section, if
that's what you meant.
If you read up the binutils doc, you'll see that ld fills output
sections based on a "location pointer" (the "dot") that simply moves on
with each input section added -- no skipping, and no jumping from one
region to another either.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 12:33 ` Sebastien Carlier
2010-11-19 12:38 ` Albert ARIBAUD
@ 2010-11-19 12:55 ` Wolfgang Denk
1 sibling, 0 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 12:55 UTC (permalink / raw)
To: u-boot
Dear Sebastien Carlier,
In message <sebastien.carlier@9400084bb093b10e93ff65be513a8043def9b8e1> you wrote:
>
> Is it not possible to tell the linker to place a made-up 32 kB symbol
> within the text section at address 0x40008000? I am not familiar enough
> with ld to tell whether there are restrictions for setting the absolute
> address of a symbol that would disallow it in this case.
I don't know such a method. We would not even have to make up any
symbols - if we could forst the Linker to place "environment" at
0x40008000 and "redundand_environment" at 0x4000c000 everything would
be perfect. Before this patch, this was what we had:
...
0x40005ebc inflateInit2_
0x400058f4 inflate_table
arch/powerpc/lib/cache.o(.text)
.text 0x40007c20 0x64 arch/powerpc/lib/cache.o
0x40007c20 flush_cache
0x00008000 . = DEFINED (env_offset)?env_offset:.
*fill* 0x40007c84 0x37c 00
common/env_embedded.o(.ppcenv)
.ppcenv 0x40008000 0x8000 common/env_embedded.o
0x40008000 environment
0x4000c000 redundand_environment
*(.text)
.text 0x40010000 0x4 common/env_embedded.o
0x40010000 env_size
.text 0x40010004 0x0 lib/libgeneric.a(ctype.o)
.text 0x40010004 0x10c lib/libgeneric.a(div64.o)
0x40010004 __div64_32
...
But I don't know of a way to enforce this...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every little picofarad has a nanohenry all its own. - Don Vonada
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 12:38 ` Albert ARIBAUD
@ 2010-11-19 13:02 ` Sebastien Carlier
2010-11-19 13:07 ` Reinhard Meyer
0 siblings, 1 reply; 79+ messages in thread
From: Sebastien Carlier @ 2010-11-19 13:02 UTC (permalink / raw)
To: u-boot
Dear Albert,
On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
>
> Le 19/11/2010 13:33, Sebastien Carlier a ?crit :
> >
> >Is it not possible to tell the linker to place a made-up 32 kB symbol
> >within the text section at address 0x40008000? I am not familiar enough
> >with ld to tell whether there are restrictions for setting the absolute
> >address of a symbol that would disallow it in this case.
>
> You can force a symbol to reside at a given offset, but that will
> not make the linker "skip" that symbol when filling the output
> section, if that's what you meant.
Yes, I was hoping the linker would first allocate space for
absolute-address symbols and then fill the gaps with the remaining
symbols in whatever order.
> If you read up the binutils doc, you'll see that ld fills output
> sections based on a "location pointer" (the "dot") that simply moves
> on with each input section added -- no skipping, and no jumping from
> one region to another either.
I see, thank you for pointing this out. This specific behavior actually
seems quite essential to the interpretation of linker scripts, so there
is probably no hope for any change there.
I very much like your idea of splitting the binary when flashing and
recomposing it into RAM during copying just before relocation, it looks
very flexible and elegant. A separate solution is still needed for
running from flash... apart from switching back to archive libraries and
using --whole-archive, I am out of ideas at the moment.
Regards,
--
Sebastien
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 13:02 ` Sebastien Carlier
@ 2010-11-19 13:07 ` Reinhard Meyer
2010-11-19 13:33 ` Albert ARIBAUD
2010-11-19 13:40 ` Wolfgang Denk
0 siblings, 2 replies; 79+ messages in thread
From: Reinhard Meyer @ 2010-11-19 13:07 UTC (permalink / raw)
To: u-boot
Dear Albert,
>
> On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
>> Le 19/11/2010 13:33, Sebastien Carlier a ?crit :
>>> Is it not possible to tell the linker to place a made-up 32 kB symbol
>>> within the text section at address 0x40008000? I am not familiar enough
>>> with ld to tell whether there are restrictions for setting the absolute
>>> address of a symbol that would disallow it in this case.
>> You can force a symbol to reside at a given offset, but that will
>> not make the linker "skip" that symbol when filling the output
>> section, if that's what you meant.
>
> Yes, I was hoping the linker would first allocate space for
> absolute-address symbols and then fill the gaps with the remaining
> symbols in whatever order.
>
>> If you read up the binutils doc, you'll see that ld fills output
>> sections based on a "location pointer" (the "dot") that simply moves
>> on with each input section added -- no skipping, and no jumping from
>> one region to another either.
>
> I see, thank you for pointing this out. This specific behavior actually
> seems quite essential to the interpretation of linker scripts, so there
> is probably no hope for any change there.
Have you tried something in the line of:
/* Memory Definitions */
MEMORY
{
CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007E000
DATA (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007A00
ENET (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000
}
/* Section Definitions */
SECTIONS
{
/* first section is .text which is used for code */
.text :
{
*startup2300.o (.text) /* Startup code */
*basicio.o (.text) /* basic I/O */
*(.text) /* remaining code */
*(.glue_7t) *(.glue_7)
} >CODE =0
. = ALIGN(4);
...
*maybe* one can define several areas for CODE in the MEMORY section?
Best Regards,
Reinhard
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 13:07 ` Reinhard Meyer
@ 2010-11-19 13:33 ` Albert ARIBAUD
2010-11-19 13:40 ` Wolfgang Denk
1 sibling, 0 replies; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-19 13:33 UTC (permalink / raw)
To: u-boot
Le 19/11/2010 14:07, Reinhard Meyer a ?crit :
> Dear Albert,
>>
>> On 2010-11-19 13:38:00, Albert ARIBAUD wrote:
>>> Le 19/11/2010 13:33, Sebastien Carlier a ?crit :
>>>> Is it not possible to tell the linker to place a made-up 32 kB symbol
>>>> within the text section at address 0x40008000? I am not familiar enough
>>>> with ld to tell whether there are restrictions for setting the absolute
>>>> address of a symbol that would disallow it in this case.
>>> You can force a symbol to reside at a given offset, but that will
>>> not make the linker "skip" that symbol when filling the output
>>> section, if that's what you meant.
>>
>> Yes, I was hoping the linker would first allocate space for
>> absolute-address symbols and then fill the gaps with the remaining
>> symbols in whatever order.
>>
>>> If you read up the binutils doc, you'll see that ld fills output
>>> sections based on a "location pointer" (the "dot") that simply moves
>>> on with each input section added -- no skipping, and no jumping from
>>> one region to another either.
>>
>> I see, thank you for pointing this out. This specific behavior actually
>> seems quite essential to the interpretation of linker scripts, so there
>> is probably no hope for any change there.
>
> Have you tried something in the line of:
>
> /* Memory Definitions */
>
> MEMORY
> {
> CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x0007E000
> DATA (rw) : ORIGIN = 0x40000000, LENGTH = 0x00007A00
> ENET (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000
> }
>
>
> /* Section Definitions */
>
> SECTIONS
> {
>
> /* first section is .text which is used for code */
>
> .text :
> {
> *startup2300.o (.text) /* Startup code */
> *basicio.o (.text) /* basic I/O */
> *(.text) /* remaining code */
>
> *(.glue_7t) *(.glue_7)
>
> }>CODE =0
>
> . = ALIGN(4);
>
> ...
Those regions would most probably inflate the .bin because of the gap
between the various MEMORY areas.
> *maybe* one can define several areas for CODE in the MEMORY section?
Afraid not. :/
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 13:07 ` Reinhard Meyer
2010-11-19 13:33 ` Albert ARIBAUD
@ 2010-11-19 13:40 ` Wolfgang Denk
1 sibling, 0 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-19 13:40 UTC (permalink / raw)
To: u-boot
Dear Reinhard Meyer,
In message <4CE676A6.10205@emk-elektronik.de> you wrote:
> Have you tried something in the line of:
>
> /* Memory Definitions */
>
> MEMORY
> {
> CODE (rx) : ORIGIN 0x00000000, LENGTH 0x0007E000
> DATA (rw) : ORIGIN 0x40000000, LENGTH 0x00007A00
> ENET (rw) : ORIGIN 0x7FE00000, LENGTH 0x00004000
> }
I've looked into that, but didn't find a way to make it do what needs
to be done,
> *maybe* one can define several areas for CODE in the MEMORY section?
I don't think so. The "ld" documentation says: "Each memory region must
have a distinct name within the `MEMORY' command."
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cigarette, n.: A fire at one end, a fool at the other, and a bit of
tobacco in between.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-19 8:03 ` Wolfgang Denk
@ 2010-11-20 0:07 ` Mike Frysinger
2010-11-20 8:38 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Mike Frysinger @ 2010-11-20 0:07 UTC (permalink / raw)
To: u-boot
On Friday, November 19, 2010 03:03:54 Wolfgang Denk wrote:
> Albert ARIBAUD wrote:
> > Most probably 2); mentioning a file in the linker script either with or
> > without mentioning it on the command line has certainly been done for
> > some time, so I doubt the feature is new; and certainly the doc is about
> > files, not symbols in different files.
>
> There seems to be a (here significant) difference between object files
> on the command line and libraries (which appear to be handled like
> a mere collection of object files).
the difference is that the linker wont bother looking at the duplicated
objects in the archives. from the linker's perspective though, we now have to
completely independent objects. the combined one specified on the command
line and the split up ones in the linker script.
one possible way to fix boards is to stop specifying sub-objects in the linker
script and only specify the combined ones. so in board/tqc/tqm8xx/u-boot.lds,
drop the split objects like lib/zlib.o in favor of the combined one like
lib/libgeneric.o. this might not work for everyone since the combined object
sizes can be a bit large. if everyone was using -ffunction-sections/-fdata-
sections
this however wont work for common/env_embedded.o since it is merged
common/libcommon.o. so to fix that, we'll need to not merge env_embedded.o
into libcommon.o. like in the patch below.
-mike
diff --git a/common/Makefile b/common/Makefile
index e0db382..d38aa7b 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -52,10 +52,10 @@ COBJS-y += cmd_version.o
COBJS-y += env_common.o
COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
-COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
-COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
-COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
-COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
+XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
+XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
+XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
+XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
@@ -174,7 +174,7 @@ OBJS := $(addprefix $(obj),$(AOBJS) $(COBJS))
CPPFLAGS += -I..
-all: $(LIB) $(AOBJS)
+all: $(LIB) $(AOBJS) $(XOBJS-y)
$(LIB): $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101119/95fb579c/attachment.pgp
^ permalink raw reply related [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-20 0:07 ` Mike Frysinger
@ 2010-11-20 8:38 ` Wolfgang Denk
2010-11-20 8:48 ` Albert ARIBAUD
2010-11-20 9:19 ` Mike Frysinger
0 siblings, 2 replies; 79+ messages in thread
From: Wolfgang Denk @ 2010-11-20 8:38 UTC (permalink / raw)
To: u-boot
Dear Mike Frysinger,
In message <201011191908.00162.vapier@gentoo.org> you wrote:
>
> the difference is that the linker wont bother looking at the duplicated
> objects in the archives. from the linker's perspective though, we now have to
> completely independent objects. the combined one specified on the command
> line and the split up ones in the linker script.
Right.
> one possible way to fix boards is to stop specifying sub-objects in the linker
> script and only specify the combined ones. so in board/tqc/tqm8xx/u-boot.lds,
> drop the split objects like lib/zlib.o in favor of the combined one like
> lib/libgeneric.o. this might not work for everyone since the combined object
It doesn't work as we cannot fine-adjust the size of the combined
objects as it's needed for at least coarse adjustment to the available
flash sector sizes.
> sizes can be a bit large. if everyone was using -ffunction-sections/-fdata-
> sections
? Could you please complete that sentence?
> this however wont work for common/env_embedded.o since it is merged
> common/libcommon.o. so to fix that, we'll need to not merge env_embedded.o
> into libcommon.o. like in the patch below.
> -mike
>
> diff --git a/common/Makefile b/common/Makefile
> index e0db382..d38aa7b 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -52,10 +52,10 @@ COBJS-y += cmd_version.o
> COBJS-y += env_common.o
> COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
> COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
> -COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
> -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
> -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
> -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
> +XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
> +XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
> +XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
> +XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
> COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
> COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
> COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
Is this not too much? We have embedded environment only in the case
of NOR flash, so the extra handling should only be done for
CONFIG_ENV_IS_EMBEDDED ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The perversity of nature is nowhere better demonstrated by the fact
that, when exposed to the same atmosphere, bread becomes hard while
crackers become soft.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-20 8:38 ` Wolfgang Denk
@ 2010-11-20 8:48 ` Albert ARIBAUD
2010-11-20 9:19 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Albert ARIBAUD @ 2010-11-20 8:48 UTC (permalink / raw)
To: u-boot
Le 20/11/2010 09:38, Wolfgang Denk a ?crit :
> Dear Mike Frysinger,
>
> In message<201011191908.00162.vapier@gentoo.org> you wrote:
>> sizes can be a bit large. if everyone was using -ffunction-sections/-fdata-
>> sections
>
> ? Could you please complete that sentence?
I believe the idea is that with these options, the build produces not
one single input section for all code and one single input section for
all data of a given object file, but one input section per function and
one input section per variable, thus allowing the linker file to
fin-grain-tune the content of the isolated sector(s), specifying exactly
which function or (initialized) data would go in there.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
2010-11-20 8:38 ` Wolfgang Denk
2010-11-20 8:48 ` Albert ARIBAUD
@ 2010-11-20 9:19 ` Mike Frysinger
1 sibling, 0 replies; 79+ messages in thread
From: Mike Frysinger @ 2010-11-20 9:19 UTC (permalink / raw)
To: u-boot
On Saturday, November 20, 2010 03:38:44 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > one possible way to fix boards is to stop specifying sub-objects in the
> > linker script and only specify the combined ones. so in
> > board/tqc/tqm8xx/u-boot.lds, drop the split objects like lib/zlib.o in
> > favor of the combined one like lib/libgeneric.o. this might not work
> > for everyone since the combined object
>
> It doesn't work as we cannot fine-adjust the size of the combined
> objects as it's needed for at least coarse adjustment to the available
> flash sector sizes.
>
> > sizes can be a bit large. if everyone was using
> > -ffunction-sections/-fdata- sections
>
> ? Could you please complete that sentence?
if everyone used these options, then the linker script would get fine grained
control as people could still specify the combined object, but only pull in
specific sections. so the linker script could do in the leading space:
lib/libgeneric.o (.text.crc32 .text.gunzip .text........)
and then in the normal space after the env, do:
lib/libgeneric.o (.text*)
since the linker has already placed the specific sections earlier, the glob
wont pull them in again.
while these options normally imply the end goal of --gc-sections, using that
flag isnt a requirement. as long as the linker scripts specify things like
".text*" instead of just ".text", then they should work fine. and people dont
have to worry about the linker discarding unreferenced sections (such as reset
vectors or whatever). at least not today ... this really should get fixed
across the board.
> > this however wont work for common/env_embedded.o since it is merged
> > common/libcommon.o. so to fix that, we'll need to not merge
> > env_embedded.o into libcommon.o. like in the patch below.
> >
> > diff --git a/common/Makefile b/common/Makefile
> > index e0db382..d38aa7b 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -52,10 +52,10 @@ COBJS-y += cmd_version.o
> >
> > COBJS-y += env_common.o
> > COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o
> > COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
> >
> > -COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
> > -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
> > -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
> > -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
> > +XOBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
> > +XOBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o
> > +XOBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o
> > +XOBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o
> >
> > COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
> > COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
> > COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
>
> Is this not too much? We have embedded environment only in the case
> of NOR flash, so the extra handling should only be done for
> CONFIG_ENV_IS_EMBEDDED ?
dont really know what you're referring to ... this patch works on my Blackfin
boards. however, it doesnt really matter, as another option would be to
simply stick the env into its own sections. two ways to accomplish this:
(1) if we use -ffunction-sections/-fdata-sections for everyone and we punt the
__PPCENV__ and __PPCTEXT__ hacks, in the linker script, you could do:
common/libcommon.o (.data.environment .data.redundand_environment
.data.env_size)
(2) or tweak/extend the __PPCENV__ and __PPCTEXT__ hacks to manually place the
vars into more specific sections rather than just ".text". then the linker
script would do something like:
common/libcommon.o (.text.environment .text.redundand_environment
.text.env_size)
obviously i'd prefer (1) since the gcc attribute usage in env_embedded.c makes
me want to barf.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101120/9dc2234d/attachment.pgp
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
` (6 preceding siblings ...)
2010-11-15 11:44 ` [U-Boot] [PATCH] " Mike Frysinger
@ 2011-01-24 20:54 ` Timur Tabi
2011-01-25 0:03 ` Kumar Gala
7 siblings, 1 reply; 79+ messages in thread
From: Timur Tabi @ 2011-01-24 20:54 UTC (permalink / raw)
To: u-boot
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
<sebastien.carlier@gmail.com> wrote:
> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries
> when linking with recent versions of binutils. ?As stated in the System V ABI, "the link editor does
> not extract archive members to resolve undefined weak symbols".
>
> This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives,
> which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols
> as intended. ?This approach is also used by Linux, from which the gmake function cmd_link_o_target
> (added at the end of config.mk and used in all Makefiles) is inspired.
>
> The name of each former library archive is preserved except for extensions which change from ".a" to
> ".o". ?This commit updates references accordingly where needed, in particular in some linker scripts.
>
> This commit reveals board configurations that exclude some module but not all of its dependencies; for
> example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
>
> Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
git-bisect tells me that your patch (or whatever version of it was
actually applied) causes this linker warning:
powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o
uses hard float, libpost.o uses soft float
See this thread for details:
http://lists.denx.de/pipermail/u-boot/2011-January/085811.html
I have no idea how to fix this.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-24 20:54 ` Timur Tabi
@ 2011-01-25 0:03 ` Kumar Gala
2011-01-25 6:36 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Kumar Gala @ 2011-01-25 0:03 UTC (permalink / raw)
To: u-boot
On Jan 24, 2011, at 2:54 PM, Timur Tabi wrote:
> On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
> <sebastien.carlier@gmail.com> wrote:
>> NOTE: This does not include the actual patch as it is too large for the mailing list (418 kB).
>>
>> Before this commit, weak symbols were not overridden by non-weak symbols found in archive libraries
>> when linking with recent versions of binutils. As stated in the System V ABI, "the link editor does
>> not extract archive members to resolve undefined weak symbols".
>>
>> This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives,
>> which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols
>> as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target
>> (added at the end of config.mk and used in all Makefiles) is inspired.
>>
>> The name of each former library archive is preserved except for extensions which change from ".a" to
>> ".o". This commit updates references accordingly where needed, in particular in some linker scripts.
>>
>> This commit reveals board configurations that exclude some module but not all of its dependencies; for
>> example, disabling CMD_NET but not CMD_NFS results in undefined symbols at link time.
>>
>> Signed-off-by: Sebastien Carlier <sebastien.carlier@gmail.com>
>
> git-bisect tells me that your patch (or whatever version of it was
> actually applied) causes this linker warning:
>
> powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o
> uses hard float, libpost.o uses soft float
>
> See this thread for details:
> http://lists.denx.de/pipermail/u-boot/2011-January/085811.html
>
> I have no idea how to fix this.
The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
CFLAGS += -mhard-float -fkeep-inline-functions
We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
- k
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 0:03 ` Kumar Gala
@ 2011-01-25 6:36 ` Wolfgang Denk
2011-01-25 8:55 ` Kumar Gala
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 6:36 UTC (permalink / raw)
To: u-boot
Dear Kumar Gala,
In message <356989C7-FA92-46D5-9FB6-5F9332ECBFD5@kernel.crashing.org> you wrote:
>
> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>
> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
> CFLAGS += -mhard-float -fkeep-inline-functions
>
> We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
This might solve the warning in most cases - but what abut these where
CONFIG_POST_FPU is defined? I mean, it is inherent that these tests
need to execute FP instructions.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every little picofarad has a nanohenry all its own. - Don Vonada
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 6:36 ` Wolfgang Denk
@ 2011-01-25 8:55 ` Kumar Gala
2011-01-25 16:40 ` Timur Tabi
0 siblings, 1 reply; 79+ messages in thread
From: Kumar Gala @ 2011-01-25 8:55 UTC (permalink / raw)
To: u-boot
On Jan 25, 2011, at 12:36 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <356989C7-FA92-46D5-9FB6-5F9332ECBFD5@kernel.crashing.org> you wrote:
>>
>> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>>
>> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
>> CFLAGS += -mhard-float -fkeep-inline-functions
>>
>> We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir if CONFIG_POST_FPU isn't set in CONFIG_POST.
>
> This might solve the warning in most cases - but what abut these where
> CONFIG_POST_FPU is defined? I mean, it is inherent that these tests
> need to execute FP instructions.
>
> Best regards,
>
> Wolfgang Denk
Actually we've dealt with this already:
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
Author: Yuri Tikhonov <yur@emcraft.com>
Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
When compile u-boot with the 2.18 binutils the following
warning messages for each object file in post/lib_ppc/fpu/ is
produced at the linking stage:
post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float
...
...
However I think we just need to move the code a bit. Will post a patch
- k
- k
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 8:55 ` Kumar Gala
@ 2011-01-25 16:40 ` Timur Tabi
2011-01-25 17:49 ` Kumar Gala
2011-01-25 18:27 ` Wolfgang Denk
0 siblings, 2 replies; 79+ messages in thread
From: Timur Tabi @ 2011-01-25 16:40 UTC (permalink / raw)
To: u-boot
Kumar Gala wrote:
> Actually we've dealt with this already:
>
> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> Author: Yuri Tikhonov <yur@emcraft.com>
> Date: Sat Dec 20 14:54:21 2008 +0300
>
> FPU POST: fix warnings when building with 2.18 binutils
Why don't we compile all of U-Boot with hard float by default? What's wrong
with using floating point instructions in U-Boot?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 16:40 ` Timur Tabi
@ 2011-01-25 17:49 ` Kumar Gala
2011-01-25 18:30 ` Timur Tabi
2011-01-25 20:05 ` Scott Wood
2011-01-25 18:27 ` Wolfgang Denk
1 sibling, 2 replies; 79+ messages in thread
From: Kumar Gala @ 2011-01-25 17:49 UTC (permalink / raw)
To: u-boot
On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Actually we've dealt with this already:
>>
>> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
>> Author: Yuri Tikhonov <yur@emcraft.com>
>> Date: Sat Dec 20 14:54:21 2008 +0300
>>
>> FPU POST: fix warnings when building with 2.18 binutils
>
> Why don't we compile all of U-Boot with hard float by default? What's wrong
> with using floating point instructions in U-Boot?
* still have to deal with cores that dont have FP
- k
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 16:40 ` Timur Tabi
2011-01-25 17:49 ` Kumar Gala
@ 2011-01-25 18:27 ` Wolfgang Denk
2011-01-25 18:29 ` Timur Tabi
1 sibling, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 18:27 UTC (permalink / raw)
To: u-boot
Dear Timur Tabi,
In message <4D3EFCF2.4060706@freescale.com> you wrote:
>
> Why don't we compile all of U-Boot with hard float by default? What's wrong
> with using floating point instructions in U-Boot?
We don't need it.
Why doesn't the Linux kernel use floating point instructions?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The ultimate barrier is one's viewpoint.
- Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 18:27 ` Wolfgang Denk
@ 2011-01-25 18:29 ` Timur Tabi
2011-01-25 18:54 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Timur Tabi @ 2011-01-25 18:29 UTC (permalink / raw)
To: u-boot
Wolfgang Denk wrote:
> Why doesn't the Linux kernel use floating point instructions?
Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have
that problem.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 17:49 ` Kumar Gala
@ 2011-01-25 18:30 ` Timur Tabi
2011-01-25 19:02 ` Wolfgang Denk
2011-01-25 20:05 ` Scott Wood
1 sibling, 1 reply; 79+ messages in thread
From: Timur Tabi @ 2011-01-25 18:30 UTC (permalink / raw)
To: u-boot
Kumar Gala wrote:
> * still have to deal with cores that dont have FP
But when will gcc generate FP instructions? If we compile with soft-float, will
it link in an FP library and use it?
My point is that compiling with soft-float doesn't make much more sense than
compiling with hard-float, since there won't be any floating point instructions
in either case.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 18:29 ` Timur Tabi
@ 2011-01-25 18:54 ` Wolfgang Denk
2011-01-25 18:57 ` Timur Tabi
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 18:54 UTC (permalink / raw)
To: u-boot
Dear Timur Tabi,
In message <4D3F1674.10509@freescale.com> you wrote:
>
> Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have
> that problem.
But we also do not have any need for FP operations either. It would
just add to the complexity (and to the memory foot print, especially
on systems without FPU where we would have to provide soft-float
libraries, plus eventually variantes for SPEv1 and SPEvv2 and
whatever - not to mention that tghis will be needed for all the
non-PPC architectures as well).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The combination of a number of things to make existence worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 18:54 ` Wolfgang Denk
@ 2011-01-25 18:57 ` Timur Tabi
2011-01-25 19:05 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Timur Tabi @ 2011-01-25 18:57 UTC (permalink / raw)
To: u-boot
Wolfgang Denk wrote:
> But we also do not have any need for FP operations either. It would
> just add to the complexity (and to the memory foot print, especially
> on systems without FPU where we would have to provide soft-float
> libraries, plus eventually variantes for SPEv1 and SPEvv2 and
> whatever - not to mention that tghis will be needed for all the
> non-PPC architectures as well).
I think you misunderstand. I'm not saying that we should use FP instructions in
U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we can
just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU,
because all of U-Boot will then be compiled with hard-float.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 18:30 ` Timur Tabi
@ 2011-01-25 19:02 ` Wolfgang Denk
0 siblings, 0 replies; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 19:02 UTC (permalink / raw)
To: u-boot
Dear Timur Tabi,
In message <4D3F16C7.7040000@freescale.com> you wrote:
>
> But when will gcc generate FP instructions? If we compile with soft-float, will
> it link in an FP library and use it?
GCC will (in addition to the obvious case of operations of FP data
types) generate FP instructions for a number of "small data copy"
operations, like assignment of structs etc.
> My point is that compiling with soft-float doesn't make much more sense than
> compiling with hard-float, since there won't be any floating point instructions
> in either case.
You are wrong.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 18:57 ` Timur Tabi
@ 2011-01-25 19:05 ` Wolfgang Denk
0 siblings, 0 replies; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 19:05 UTC (permalink / raw)
To: u-boot
Dear Timur Tabi,
In message <4D3F1D25.4070807@freescale.com> you wrote:
>
> I think you misunderstand. I'm not saying that we should use FP instructions in
> U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we can
> just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU,
> because all of U-Boot will then be compiled with hard-float.
If we let him, GCC would generate FP instructions in a number of
places where you don't expect them, even whithout any FP variables or
explicit FP operations in the whole code C or assembler input.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"'Tis true, 'tis pity, and pity 'tis 'tis true."
- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 17:49 ` Kumar Gala
2011-01-25 18:30 ` Timur Tabi
@ 2011-01-25 20:05 ` Scott Wood
2011-01-25 20:19 ` Wolfgang Denk
1 sibling, 1 reply; 79+ messages in thread
From: Scott Wood @ 2011-01-25 20:05 UTC (permalink / raw)
To: u-boot
On Tue, 25 Jan 2011 11:49:53 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
>
> > Kumar Gala wrote:
> >> Actually we've dealt with this already:
> >>
> >> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> >> Author: Yuri Tikhonov <yur@emcraft.com>
> >> Date: Sat Dec 20 14:54:21 2008 +0300
> >>
> >> FPU POST: fix warnings when building with 2.18 binutils
> >
> > Why don't we compile all of U-Boot with hard float by default? What's wrong
> > with using floating point instructions in U-Boot?
>
> * still have to deal with cores that dont have FP
On cores that have FP (at least those that support the FPU POST, and
which are currently having problems), use hard float, enable
MSR[FP] or equivalent, and let GCC use FP for various tasks if it
wants. This shouldn't involve much more complexity than adding a
small amount of init, which you'd need for the POST anyway.
On cores that don't have FP, use soft float, and don't include
the FPU POST code. This should not be any different than today, except
for adding another compiler flag that depends on the build target.
-Scott
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 20:05 ` Scott Wood
@ 2011-01-25 20:19 ` Wolfgang Denk
2011-01-25 20:37 ` Scott Wood
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 20:19 UTC (permalink / raw)
To: u-boot
Dear Scott Wood,
In message <20110125140547.2825fdad@udp111988uds.am.freescale.net> you wrote:
>
> On cores that have FP (at least those that support the FPU POST, and
> which are currently having problems), use hard float, enable
> MSR[FP] or equivalent, and let GCC use FP for various tasks if it
> wants. This shouldn't involve much more complexity than adding a
> small amount of init, which you'd need for the POST anyway.
>
> On cores that don't have FP, use soft float, and don't include
> the FPU POST code. This should not be any different than today, except
> for adding another compiler flag that depends on the build target.
And why exactly should we do all this, given the fact that there are
no intentions to work with floating point data in U-Boot?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
e-credibility: the non-guaranteeable likelihood that the electronic
data you're seeing is genuine rather than somebody's made-up crap.
- Karl Lehenbauer
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 20:19 ` Wolfgang Denk
@ 2011-01-25 20:37 ` Scott Wood
2011-01-25 21:13 ` Wolfgang Denk
0 siblings, 1 reply; 79+ messages in thread
From: Scott Wood @ 2011-01-25 20:37 UTC (permalink / raw)
To: u-boot
On Tue, 25 Jan 2011 21:19:19 +0100
Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20110125140547.2825fdad@udp111988uds.am.freescale.net> you wrote:
> >
> > On cores that have FP (at least those that support the FPU POST, and
> > which are currently having problems), use hard float, enable
> > MSR[FP] or equivalent, and let GCC use FP for various tasks if it
> > wants. This shouldn't involve much more complexity than adding a
> > small amount of init, which you'd need for the POST anyway.
> >
> > On cores that don't have FP, use soft float, and don't include
> > the FPU POST code. This should not be any different than today, except
> > for adding another compiler flag that depends on the build target.
>
> And why exactly should we do all this,
To fix the FPU POST build errors.
Do you have a simpler way to do this? Note that for any board that
doesn't currently have a problem, "all this" means no change at all.
And for those that do have a problem, the change is pretty minor.
> given the fact that there are
> no intentions to work with floating point data in U-Boot?
FPU POST doesn't count?
Or are you saying FPU POST should be removed?
-Scott
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 20:37 ` Scott Wood
@ 2011-01-25 21:13 ` Wolfgang Denk
2011-01-26 5:22 ` Kumar Gala
0 siblings, 1 reply; 79+ messages in thread
From: Wolfgang Denk @ 2011-01-25 21:13 UTC (permalink / raw)
To: u-boot
Dear Scott Wood,
In message <20110125143740.2e1f2c84@udp111988uds.am.freescale.net> you wrote:
>
> Do you have a simpler way to do this? Note that for any board that
e009cde powerpc: Fix FPU post related link warnings
?
> > given the fact that there are
> > no intentions to work with floating point data in U-Boot?
>
> FPU POST doesn't count?
No, it does not count, because it is a very special situation where
we are executing instructions that are guaranteed to be never used in
any real code in U-Boot.
> Or are you saying FPU POST should be removed?
Of course not.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can observe a lot just by watchin'. - Yogi Berra
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-25 21:13 ` Wolfgang Denk
@ 2011-01-26 5:22 ` Kumar Gala
2011-01-26 17:26 ` Scott Wood
0 siblings, 1 reply; 79+ messages in thread
From: Kumar Gala @ 2011-01-26 5:22 UTC (permalink / raw)
To: u-boot
On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110125143740.2e1f2c84@udp111988uds.am.freescale.net> you wrote:
>>
>> Do you have a simpler way to do this? Note that for any board that
>
> e009cde powerpc: Fix FPU post related link warnings
>
> ?
>
>>> given the fact that there are
>>> no intentions to work with floating point data in U-Boot?
>>
>> FPU POST doesn't count?
>
> No, it does not count, because it is a very special situation where
> we are executing instructions that are guaranteed to be never used in
> any real code in U-Boot.
>
>> Or are you saying FPU POST should be removed?
>
> Of course not.
I thank you all, as I've enjoyed this thread for something we've just fixed :)
- k
- k
^ permalink raw reply [flat|nested] 79+ messages in thread
* [U-Boot] [PATCH] Switch from archive libraries to partial linking
2011-01-26 5:22 ` Kumar Gala
@ 2011-01-26 17:26 ` Scott Wood
0 siblings, 0 replies; 79+ messages in thread
From: Scott Wood @ 2011-01-26 17:26 UTC (permalink / raw)
To: u-boot
On Tue, 25 Jan 2011 23:22:34 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
>
> > Dear Scott Wood,
> >
> > In message <20110125143740.2e1f2c84@udp111988uds.am.freescale.net> you wrote:
> >>
> >> Do you have a simpler way to do this? Note that for any board that
> >
> > e009cde powerpc: Fix FPU post related link warnings
> >
> > ?
> >
> >>> given the fact that there are
> >>> no intentions to work with floating point data in U-Boot?
> >>
> >> FPU POST doesn't count?
> >
> > No, it does not count, because it is a very special situation where
> > we are executing instructions that are guaranteed to be never used in
> > any real code in U-Boot.
> >
> >> Or are you saying FPU POST should be removed?
> >
> > Of course not.
>
> I thank you all, as I've enjoyed this thread for something we've just fixed :)
The joys of e-mail threading. :-)
-Scott
^ permalink raw reply [flat|nested] 79+ messages in thread
end of thread, other threads:[~2011-01-26 17:26 UTC | newest]
Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-08 22:04 [U-Boot] [PATCH] Switch from archive libraries to partial linking Sebastien Carlier
2010-11-08 22:10 ` Graeme Russ
2010-11-08 22:34 ` Sebastien Carlier
2010-11-09 6:17 ` Andreas Bießmann
2010-11-09 9:15 ` Andre Schwarz
2010-11-09 17:44 ` [U-Boot] [PATCH v2] " Sebastien Carlier
2010-11-10 8:35 ` Andre Schwarz
2010-11-09 9:48 ` [U-Boot] [PATCH] " Graeme Russ
2010-11-09 11:29 ` Stefano Babic
2010-11-10 6:57 ` Mike Frysinger
2010-11-10 8:01 ` Andreas Bießmann
2010-11-10 8:07 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-10 8:55 ` Mike Frysinger
2010-11-10 12:24 ` Sebastien Carlier
2010-11-10 21:07 ` Mike Frysinger
2010-11-15 7:51 ` Wolfgang Denk
2010-11-15 8:09 ` Sebastien Carlier
2010-11-15 10:54 ` Wolfgang Denk
2010-11-15 11:33 ` Mike Frysinger
2010-11-15 12:38 ` Mike Frysinger
2010-11-15 12:42 ` Mike Frysinger
2010-11-15 12:52 ` Mike Frysinger
2010-11-15 11:35 ` [U-Boot] [PATCH v4] " Sebastien Carlier
2010-11-15 12:13 ` Sebastien Carlier
2010-11-15 12:39 ` Mike Frysinger
2010-11-16 14:58 ` Detlev Zundel
2010-11-16 16:33 ` Mike Frysinger
2010-11-17 12:30 ` Detlev Zundel
2010-11-17 13:30 ` [U-Boot] [PATCH v3] " Sebastien Carlier
2010-11-17 13:50 ` Wolfgang Denk
2010-11-17 18:06 ` Mike Frysinger
2010-11-17 19:53 ` Sebastien Carlier
2010-11-17 22:19 ` Mike Frysinger
2010-11-18 21:44 ` Wolfgang Denk
2010-11-18 22:08 ` Albert ARIBAUD
2010-11-18 22:33 ` Wolfgang Denk
2010-11-19 6:36 ` Albert ARIBAUD
2010-11-19 8:03 ` Wolfgang Denk
2010-11-20 0:07 ` Mike Frysinger
2010-11-20 8:38 ` Wolfgang Denk
2010-11-20 8:48 ` Albert ARIBAUD
2010-11-20 9:19 ` Mike Frysinger
2010-11-19 8:04 ` Sebastien Carlier
2010-11-19 7:50 ` Sebastien Carlier
2010-11-19 8:08 ` Wolfgang Denk
2010-11-19 8:34 ` Sebastien Carlier
2010-11-19 11:11 ` Wolfgang Denk
2010-11-19 11:40 ` Albert ARIBAUD
2010-11-19 11:48 ` Wolfgang Denk
2010-11-19 12:11 ` Albert ARIBAUD
2010-11-19 12:33 ` Sebastien Carlier
2010-11-19 12:38 ` Albert ARIBAUD
2010-11-19 13:02 ` Sebastien Carlier
2010-11-19 13:07 ` Reinhard Meyer
2010-11-19 13:33 ` Albert ARIBAUD
2010-11-19 13:40 ` Wolfgang Denk
2010-11-19 12:55 ` Wolfgang Denk
2010-11-19 8:10 ` Mike Frysinger
2010-11-15 19:44 ` Mike Frysinger
2010-11-15 11:44 ` [U-Boot] [PATCH] " Mike Frysinger
2011-01-24 20:54 ` Timur Tabi
2011-01-25 0:03 ` Kumar Gala
2011-01-25 6:36 ` Wolfgang Denk
2011-01-25 8:55 ` Kumar Gala
2011-01-25 16:40 ` Timur Tabi
2011-01-25 17:49 ` Kumar Gala
2011-01-25 18:30 ` Timur Tabi
2011-01-25 19:02 ` Wolfgang Denk
2011-01-25 20:05 ` Scott Wood
2011-01-25 20:19 ` Wolfgang Denk
2011-01-25 20:37 ` Scott Wood
2011-01-25 21:13 ` Wolfgang Denk
2011-01-26 5:22 ` Kumar Gala
2011-01-26 17:26 ` Scott Wood
2011-01-25 18:27 ` Wolfgang Denk
2011-01-25 18:29 ` Timur Tabi
2011-01-25 18:54 ` Wolfgang Denk
2011-01-25 18:57 ` Timur Tabi
2011-01-25 19:05 ` Wolfgang Denk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.