All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
@ 2011-01-31 18:32 Haiying.Wang at freescale.com
  2011-01-31 19:33 ` Wolfgang Denk
  0 siblings, 1 reply; 25+ messages in thread
From: Haiying.Wang at freescale.com @ 2011-01-31 18:32 UTC (permalink / raw)
  To: u-boot

From: Haiying Wang <Haiying.Wang@freescale.com>

commit 8aba9dceebb14144e07d19593111ee3a999c37fc
Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

breaks the usage of --gc-section to build nand_spl. We still need linker option
--gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes
the --gc-sections to each uboot image.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
 arch/blackfin/config.mk                       |    2 +-
 arch/i386/config.mk                           |    2 +-
 arch/nios2/config.mk                          |    2 +-
 arch/powerpc/config.mk                        |    2 +-
 arch/sh/config.mk                             |    2 +-
 config.mk                                     |    3 ++-
 nand_spl/board/amcc/acadia/Makefile           |    4 ++--
 nand_spl/board/amcc/bamboo/Makefile           |    4 ++--
 nand_spl/board/amcc/canyonlands/Makefile      |    4 ++--
 nand_spl/board/amcc/kilauea/Makefile          |    4 ++--
 nand_spl/board/amcc/sequoia/Makefile          |    4 ++--
 nand_spl/board/davinci/da8xxevm/Makefile      |    4 ++--
 nand_spl/board/freescale/mpc8313erdb/Makefile |    6 +++---
 nand_spl/board/freescale/mpc8315erdb/Makefile |    6 +++---
 nand_spl/board/freescale/mpc8536ds/Makefile   |    4 ++--
 nand_spl/board/freescale/mpc8569mds/Makefile  |    4 ++--
 nand_spl/board/freescale/mpc8572ds/Makefile   |    4 ++--
 nand_spl/board/freescale/mx31pdk/Makefile     |    4 ++--
 nand_spl/board/freescale/p1_p2_rdb/Makefile   |    5 +++--
 nand_spl/board/karo/tx25/Makefile             |    4 ++--
 nand_spl/board/samsung/smdk6400/Makefile      |    4 ++--
 nand_spl/board/sheldon/simpc8313/Makefile     |    6 +++---
 22 files changed, 43 insertions(+), 41 deletions(-)

diff --git a/arch/blackfin/config.mk b/arch/blackfin/config.mk
index 0cba294..f4503ea 100644
--- a/arch/blackfin/config.mk
+++ b/arch/blackfin/config.mk
@@ -30,7 +30,7 @@ CONFIG_BFIN_BOOT_MODE := $(strip $(subst ",,$(CONFIG_BFIN_BOOT_MODE)))
 PLATFORM_RELFLAGS += -ffixed-P3 -fomit-frame-pointer -mno-fdpic
 PLATFORM_CPPFLAGS += -DCONFIG_BLACKFIN
 
-LDFLAGS_u-boot += --gc-sections
+LDFLAGS_FINAL += --gc-sections
 LDFLAGS += -m elf32bfin
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
 
diff --git a/arch/i386/config.mk b/arch/i386/config.mk
index 3fb97c1..2848435 100644
--- a/arch/i386/config.mk
+++ b/arch/i386/config.mk
@@ -36,5 +36,5 @@ PLATFORM_CPPFLAGS += $(call cc-option, -mpreferred-stack-boundary=2)
 PLATFORM_CPPFLAGS += -DCONFIG_I386 -D__I386__
 
 LDFLAGS += --cref
-LDFLAGS_u-boot += --gc-sections
+LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections
diff --git a/arch/nios2/config.mk b/arch/nios2/config.mk
index fa93180..d241a96 100644
--- a/arch/nios2/config.mk
+++ b/arch/nios2/config.mk
@@ -31,5 +31,5 @@ PLATFORM_CPPFLAGS += -G0
 
 LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds
 
-LDFLAGS_u-boot += --gc-sections
+LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index 64191c7..31e4416 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -24,7 +24,7 @@
 CROSS_COMPILE ?= ppc_8xx-
 
 STANDALONE_LOAD_ADDR = 0x40000
-LDFLAGS_u-boot = --gc-sections
+LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -mrelocatable -ffunction-sections -fdata-sections
 PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
 PLATFORM_LDFLAGS  += -n
diff --git a/arch/sh/config.mk b/arch/sh/config.mk
index 4ef85e3..6318e77 100644
--- a/arch/sh/config.mk
+++ b/arch/sh/config.mk
@@ -30,5 +30,5 @@ endif
 
 PLATFORM_CPPFLAGS += -DCONFIG_SH -D__SH__
 PLATFORM_LDFLAGS += -e $(CONFIG_SYS_TEXT_BASE) --defsym reloc_dst=$(CONFIG_SYS_TEXT_BASE)
-LDFLAGS_u-boot = --gc-sections
+LDFLAGS_FINAL += --gc-sections
 LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/config.mk b/config.mk
index 5147c35..caa6221 100644
--- a/config.mk
+++ b/config.mk
@@ -205,8 +205,9 @@ endif
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 
 LDFLAGS += $(PLATFORM_LDFLAGS)
+LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
 
-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
 LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
diff --git a/nand_spl/board/amcc/acadia/Makefile b/nand_spl/board/amcc/acadia/Makefile
index f8ca654..92ace9d 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/amcc/bamboo/Makefile b/nand_spl/board/amcc/bamboo/Makefile
index 438dfbf..abae2ae 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/amcc/canyonlands/Makefile b/nand_spl/board/amcc/canyonlands/Makefile
index 40034e1..d40a46d 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/amcc/kilauea/Makefile b/nand_spl/board/amcc/kilauea/Makefile
index 3835f3f..3a96e51 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/amcc/sequoia/Makefile b/nand_spl/board/amcc/sequoia/Makefile
index 9120f15..9022a51 100644
--- a/nand_spl/board/amcc/sequoia/Makefile
+++ b/nand_spl/board/amcc/sequoia/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/davinci/da8xxevm/Makefile b/nand_spl/board/davinci/da8xxevm/Makefile
index 4cae223..6cd0f2b 100644
--- a/nand_spl/board/davinci/da8xxevm/Makefile
+++ b/nand_spl/board/davinci/da8xxevm/Makefile
@@ -29,7 +29,7 @@ CONFIG_NAND_SPL	= y
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 
@@ -56,7 +56,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mpc8313erdb/Makefile b/nand_spl/board/freescale/mpc8313erdb/Makefile
index cf81099..5565a89 100644
--- a/nand_spl/board/freescale/mpc8313erdb/Makefile
+++ b/nand_spl/board/freescale/mpc8313erdb/Makefile
@@ -28,8 +28,8 @@ PAD_TO := 0xfff04000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds \
-	  -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds \
+	  -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mpc8315erdb/Makefile b/nand_spl/board/freescale/mpc8315erdb/Makefile
index cf81099..5565a89 100644
--- a/nand_spl/board/freescale/mpc8315erdb/Makefile
+++ b/nand_spl/board/freescale/mpc8315erdb/Makefile
@@ -28,8 +28,8 @@ PAD_TO := 0xfff04000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds \
-	  -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds \
+	  -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mpc8536ds/Makefile b/nand_spl/board/freescale/mpc8536ds/Makefile
index 9c9d63e..99db1b4 100644
--- a/nand_spl/board/freescale/mpc8536ds/Makefile
+++ b/nand_spl/board/freescale/mpc8536ds/Makefile
@@ -30,7 +30,7 @@ PAD_TO := 0xfff01000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/$(CPUDIR)/u-boot-nand_spl.lds
-LDFLAGS	= -Bstatic -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -56,7 +56,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS)
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mpc8569mds/Makefile b/nand_spl/board/freescale/mpc8569mds/Makefile
index 9c9d63e..99db1b4 100644
--- a/nand_spl/board/freescale/mpc8569mds/Makefile
+++ b/nand_spl/board/freescale/mpc8569mds/Makefile
@@ -30,7 +30,7 @@ PAD_TO := 0xfff01000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/$(CPUDIR)/u-boot-nand_spl.lds
-LDFLAGS	= -Bstatic -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -56,7 +56,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS)
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mpc8572ds/Makefile b/nand_spl/board/freescale/mpc8572ds/Makefile
index e2181e9..b101627 100644
--- a/nand_spl/board/freescale/mpc8572ds/Makefile
+++ b/nand_spl/board/freescale/mpc8572ds/Makefile
@@ -30,7 +30,7 @@ PAD_TO := 0xfff01000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/$(CPUDIR)/u-boot-nand_spl.lds
-LDFLAGS	= -Bstatic -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -56,7 +56,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS)
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/freescale/mx31pdk/Makefile b/nand_spl/board/freescale/mx31pdk/Makefile
index 3568e8c..edafc18 100644
--- a/nand_spl/board/freescale/mx31pdk/Makefile
+++ b/nand_spl/board/freescale/mx31pdk/Makefile
@@ -4,7 +4,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 
@@ -31,7 +31,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $@
 
diff --git a/nand_spl/board/freescale/p1_p2_rdb/Makefile b/nand_spl/board/freescale/p1_p2_rdb/Makefile
index 9c9d63e..ce7aa99 100644
--- a/nand_spl/board/freescale/p1_p2_rdb/Makefile
+++ b/nand_spl/board/freescale/p1_p2_rdb/Makefile
@@ -30,7 +30,8 @@ PAD_TO := 0xfff01000
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/$(CPUDIR)/u-boot-nand_spl.lds
-LDFLAGS	= -Bstatic -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(LDSCRIPT) -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) \
+			$(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -56,7 +57,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS)
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/karo/tx25/Makefile b/nand_spl/board/karo/tx25/Makefile
index 140440d..11656f0 100644
--- a/nand_spl/board/karo/tx25/Makefile
+++ b/nand_spl/board/karo/tx25/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_PRELOADER -DCONFIG_NAND_SPL
 
@@ -52,7 +52,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $@
 
diff --git a/nand_spl/board/samsung/smdk6400/Makefile b/nand_spl/board/samsung/smdk6400/Makefile
index 18cee10..1c496ec 100644
--- a/nand_spl/board/samsung/smdk6400/Makefile
+++ b/nand_spl/board/samsung/smdk6400/Makefile
@@ -30,7 +30,7 @@ include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
diff --git a/nand_spl/board/sheldon/simpc8313/Makefile b/nand_spl/board/sheldon/simpc8313/Makefile
index bc6dc65..434f7b7 100644
--- a/nand_spl/board/sheldon/simpc8313/Makefile
+++ b/nand_spl/board/sheldon/simpc8313/Makefile
@@ -28,8 +28,8 @@ NAND_SPL := y
 include $(TOPDIR)/config.mk
 
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds \
-	   -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds \
+	   -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) $(LDFLAGS_FINAL)
 AFLAGS	+= -DCONFIG_NAND_SPL
 CFLAGS	+= -DCONFIG_NAND_SPL
 
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin:	$(nandobj)u-boot-spl
 	$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
 
 $(nandobj)u-boot-spl:	$(OBJS) $(nandobj)u-boot.lds
-	cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) $(PLATFORM_LIBS) \
+	cd $(LNDIR) && $(LD) $(LDFLAGS_spl) $(__OBJS) $(PLATFORM_LIBS) \
 		-Map $(nandobj)u-boot-spl.map \
 		-o $(nandobj)u-boot-spl
 
-- 
1.7.3.1.50.g1e633

^ permalink raw reply related	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-01-31 18:32 [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL Haiying.Wang at freescale.com
@ 2011-01-31 19:33 ` Wolfgang Denk
  2011-01-31 19:55   ` Scott Wood
  2011-01-31 20:14   ` Haiying Wang
  0 siblings, 2 replies; 25+ messages in thread
From: Wolfgang Denk @ 2011-01-31 19:33 UTC (permalink / raw)
  To: u-boot

Dear Haiying.Wang at freescale.com,

In message <1296498767-26408-1-git-send-email-Haiying.Wang@freescale.com> you wrote:
> From: Haiying Wang <Haiying.Wang@freescale.com>
> 
> commit 8aba9dceebb14144e07d19593111ee3a999c37fc
> Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS
> 
> breaks the usage of --gc-section to build nand_spl. We still need linker option
> --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes
> the --gc-sections to each uboot image.

If I understand the intention of the LDFLAGS_u-boot setting
corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting.

If you introduce a new LDFLAGS_FINAL instead, then why do we have to
keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of
the U-Boot image?

[Btw: "final" is probably not a technically correct term for all the
use cases I see below.]

...
> diff --git a/config.mk b/config.mk
> index 5147c35..caa6221 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -205,8 +205,9 @@ endif
>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>  
>  LDFLAGS += $(PLATFORM_LDFLAGS)
> +LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
>  
> -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?

Are you sure that this change is correct for all affected boards?

How has this change been tested?


> -LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
> +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)


Arghhh...  Here you introduce yet another setting, LDFLAGS_spl ?

This is not mentioned in the commit message.  And why do we need it?
Isn't LDFLAGS_FINAL enough?


Will I soon see patches to also add LDFLAGS_tpl?


This is becoming a mess.  We need to find a simple, clean way to solve
this.  I'm on the verge of reverting the LDFLAGS_u-boot commit.



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
Contrary to popular belief, thinking does not cause brain damage.

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-01-31 19:33 ` Wolfgang Denk
@ 2011-01-31 19:55   ` Scott Wood
  2011-02-01  7:34     ` Wolfgang Denk
  2011-01-31 20:14   ` Haiying Wang
  1 sibling, 1 reply; 25+ messages in thread
From: Scott Wood @ 2011-01-31 19:55 UTC (permalink / raw)
  To: u-boot

On Mon, 31 Jan 2011 20:33:09 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Haiying.Wang at freescale.com,
> 
> In message <1296498767-26408-1-git-send-email-Haiying.Wang@freescale.com> you wrote:
> > From: Haiying Wang <Haiying.Wang@freescale.com>
> > 
> > commit 8aba9dceebb14144e07d19593111ee3a999c37fc
> > Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS
> > 
> > breaks the usage of --gc-section to build nand_spl. We still need linker option
> > --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes
> > the --gc-sections to each uboot image.
> 
> If I understand the intention of the LDFLAGS_u-boot setting
> corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting.
> 
> If you introduce a new LDFLAGS_FINAL instead, then why do we have to
> keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of
> the U-Boot image?
> 
> [Btw: "final" is probably not a technically correct term for all the
> use cases I see below.]

I meant final as compared to partial links, not anything to do with spl
versus tpl versus the main image.

Do you have a better wording?

> > diff --git a/config.mk b/config.mk
> > index 5147c35..caa6221 100644
> > --- a/config.mk
> > +++ b/config.mk
> > @@ -205,8 +205,9 @@ endif
> >  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
> >  
> >  LDFLAGS += $(PLATFORM_LDFLAGS)
> > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
> >  
> > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
> 
> Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?
>
> Are you sure that this change is correct for all affected boards?
> 
> How has this change been tested?

As I understand it, it has only been limited to PLATFORM_LDFLAGS since
the LDFLAGS_u-boot commit.  Was that change intentional, and widely
tested?

> > -LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
> > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
> 
> 
> Arghhh...  Here you introduce yet another setting, LDFLAGS_spl ?
> 
> This is not mentioned in the commit message.  And why do we need it?
> Isn't LDFLAGS_FINAL enough?

No, it's not enough.  The whole point is to separate options which
should apply to all final (non-partial) links, versus options which are
specific to a particular image.

This is the point where we add in the options that are specific to the
spl image.

With :=, we could preserve the LDFLAGS name, but it seemed better to
avoid muddying up what LDFLAGS means, if it's now supposed to mean
options that are used in partial linking -- and it makes things look
more consistent with what's done in the main image.

Or we could not use a variable for this and stick it on the ld command
line, but is that really an improvement?

> Will I soon see patches to also add LDFLAGS_tpl?

Of course. :-)

> This is becoming a mess.  We need to find a simple, clean way to solve
> this.  I'm on the verge of reverting the LDFLAGS_u-boot commit.

What's the alternative solution, when we have some options that need to
be set during partial link, others which cannot be set during
partial link but must be set during final link, and a couple more
(text address and linker script) which are specific to the individual
image?

I think introducing the additional variables makes things less messy,
because it means each variable has a specific, unambiguous purpose.

-Scott

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-01-31 19:33 ` Wolfgang Denk
  2011-01-31 19:55   ` Scott Wood
@ 2011-01-31 20:14   ` Haiying Wang
  2011-01-31 20:30     ` Wolfgang Denk
  1 sibling, 1 reply; 25+ messages in thread
From: Haiying Wang @ 2011-01-31 20:14 UTC (permalink / raw)
  To: u-boot

On Mon, 2011-01-31 at 20:33 +0100, Wolfgang Denk wrote:

> If I understand the intention of the LDFLAGS_u-boot setting
> corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting.
No, I don't want to add a LDFLAGS_nand_spl for nand_spl only, I need LDFLAGS_FINAL to be passed to nand spl, tpl, and final uboot images.

> If you introduce a new LDFLAGS_FINAL instead, then why do we have to
> keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of
> the U-Boot image?
LDFLAGS_FINAL does not provide the whole set of linker options to U-Boot
image, so it does not replace the LDFLAGS_u-boot, in patch:

-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

> [Btw: "final" is probably not a technically correct term for all the
> use cases I see below.]
did not think of any better term.

> ...
> > diff --git a/config.mk b/config.mk
> > index 5147c35..caa6221 100644
> > --- a/config.mk
> > +++ b/config.mk
> > @@ -205,8 +205,9 @@ endif
> >  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
> >  
> >  LDFLAGS += $(PLATFORM_LDFLAGS)
> > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
> >  
> > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
> 
> Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?
Yes. it LDFLAGS_FINAL here includes "-Bstatic $(PLATFORM_LDFLAGS)".

> Are you sure that this change is correct for all affected boards?
Can not 100% sure because I can not test all the affected boards.

> How has this change been tested?
I only can test powerpc by MAKEALL. 
> 
> > -LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
> > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
> 
> 
> Arghhh...  Here you introduce yet another setting, LDFLAGS_spl ?
This is an intentional name change. LDFLAGS_spl is used here as LDFLAGS_u-boot, but for nand spl linkage. Actually it is not a new FLAGS, just add *_spl* here so that it can be differed from the LDFlAGS in toplevel config.mk.

> This is not mentioned in the commit message.  And why do we need it?
> Isn't LDFLAGS_FINAL enough?
As said, it is not a new flag, just a name change.

> 
> Will I soon see patches to also add LDFLAGS_tpl?
Yes, in patch 3/6.

> 
> This is becoming a mess.  We need to find a simple, clean way to solve
> this.  I'm on the verge of reverting the LDFLAGS_u-boot commit.

We just want to make sure gc-sections works for all the uboot images. :)

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-01-31 20:14   ` Haiying Wang
@ 2011-01-31 20:30     ` Wolfgang Denk
       [not found]       ` <1297878184.1977.18.camel@haiying-laptop>
  0 siblings, 1 reply; 25+ messages in thread
From: Wolfgang Denk @ 2011-01-31 20:30 UTC (permalink / raw)
  To: u-boot

Dear Haiying Wang,

In message <1296504850.2049.434.camel@haiying-laptop> you wrote:
> 
> > If you introduce a new LDFLAGS_FINAL instead, then why do we have to
> > keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of
> > the U-Boot image?
> LDFLAGS_FINAL does not provide the whole set of linker options to U-Boot
> image, so it does not replace the LDFLAGS_u-boot, in patch:

I have problems to understan the intentions behind all these many
different linker flag settings, nd this while we are discussing it.
In two weeks from now I will understand none of this any more.

Either this can be made simpler.  If you are sure this is not
possible, then we need some detailed documentation of all this, at
least in the README, but eventually as a separate doc/README.*

> > >  LDFLAGS += $(PLATFORM_LDFLAGS)
> > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
> > >  
> > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
> > 
> > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?
> Yes. it LDFLAGS_FINAL here includes "-Bstatic $(PLATFORM_LDFLAGS)".

No. Pleasse see 5 lines above: it is "-Bstatic $(LDFLAGS)".


> > Are you sure that this change is correct for all affected boards?
> Can not 100% sure because I can not test all the affected boards.

Yes, you can. Run MAKEALL for all ppc boards and compare the
System.map and u-boot.map files before and after your change.  This is
still no guarantee to cover 100% of the potential issues, but as close
as we can get with reasonable effort.

> > How has this change been tested?
> I only can test powerpc by MAKEALL. 


> > > +LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)
> > 
> > Arghhh...  Here you introduce yet another setting, LDFLAGS_spl ?
> This is an intentional name change. LDFLAGS_spl is used here as LDFLAGS_u-boot, but for nand spl linkage. Actually it is not a new FLAGS, just add *_spl* here so that it can be differed from the LDFlAGS in toplevel config.mk.
> 
> > This is not mentioned in the commit message.  And why do we need it?
> > Isn't LDFLAGS_FINAL enough?
> As said, it is not a new flag, just a name change.

Anyway. It was not mentioned in the commit message, and not explained
anywhere else.

We _really_ need to thoroughly document all this stuff or soon nobody
will understand nothing of this anymore.

> > Will I soon see patches to also add LDFLAGS_tpl?
> Yes, in patch 3/6.

:-(


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 cannot propel yourself forward by patting yourself on the back.

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-01-31 19:55   ` Scott Wood
@ 2011-02-01  7:34     ` Wolfgang Denk
  2011-02-01 14:59       ` Haiying Wang
  2011-02-01 16:24       ` Scott Wood
  0 siblings, 2 replies; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-01  7:34 UTC (permalink / raw)
  To: u-boot

Dear Scott Wood,

In message <20110131135548.50d65759@udp111988uds.am.freescale.net> you wrote:
>
> > [Btw: "final" is probably not a technically correct term for all the
> > use cases I see below.]
> 
> I meant final as compared to partial links, not anything to do with spl
> versus tpl versus the main image.
> 
> Do you have a better wording?

Not really. ld documentation also talks about "final binary" or "final
executable".  Note that I'm not insisting on a change here.

> > >  LDFLAGS += $(PLATFORM_LDFLAGS)
> > > +LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
> > >  
> > > -LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> > > +LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
> > 
> > Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?
> >
> > Are you sure that this change is correct for all affected boards?
> > 
> > How has this change been tested?
> 
> As I understand it, it has only been limited to PLATFORM_LDFLAGS since
> the LDFLAGS_u-boot commit.  Was that change intentional, and widely
> tested?

Can you please be more specific?  I don't see where "the
LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related
code.  The relevant hunk looks like this:

@@ -204,9 +204,11 @@ endif
 
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 
-LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS += $(PLATFORM_LDFLAGS)
+
+LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
-LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
+LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
 
 # Location of a usable BFD library, where we define "usable" as

and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS
or vice versa.

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
"...all the  good  computer  designs  are  bootlegged;  the  formally
planned  products,  if  they  are built at all, are dogs!" - David E.
Lundstrom, "A Few Good Men From Univac", MIT Press, 1987

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01  7:34     ` Wolfgang Denk
@ 2011-02-01 14:59       ` Haiying Wang
  2011-02-01 16:24       ` Scott Wood
  1 sibling, 0 replies; 25+ messages in thread
From: Haiying Wang @ 2011-02-01 14:59 UTC (permalink / raw)
  To: u-boot

On Tue, 2011-02-01 at 08:34 +0100, Wolfgang Denk wrote:

> Can you please be more specific?  I don't see where "the
> LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related
> code.  The relevant hunk looks like this:
> 
> @@ -204,9 +204,11 @@ endif
>  
>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>  
> -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> +LDFLAGS += $(PLATFORM_LDFLAGS)
> +
> +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
>  ifneq ($(CONFIG_SYS_TEXT_BASE),)
> -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
> +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
>  endif
>  
>  # Location of a usable BFD library, where we define "usable" as
> 
> and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS
> or vice versa.
> 
But PLATFORM_LDFLAGS has been changed in $(CPUDIR)/config.mk.

You can see in commit 8aba9dc:

--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -24,10 +24,10 @@
 CROSS_COMPILE ?= ppc_8xx-
 
 STANDALONE_LOAD_ADDR = 0x40000
-
+LDFLAGS_u-boot = --gc-sections
 PLATFORM_RELFLAGS += -mrelocatable -ffunction-sections -fdata-sections
 PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
-PLATFORM_LDFLAGS  += -n --gc-sections
+PLATFORM_LDFLAGS  += -n

Here, --gc-sections is set only for LDFLAGS_u-boot, the PLATFORM_LDFLAGS
does have --gc-sections, So in toplevel config.mk:

+LDFLAGS += $(PLATFORM_LDFLAGS)

And later in this config.mk, 

@@ -259,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $1),\
-                     $(LD) -r -o $@ $1 ,\
+                     $(LD) $(LDFLAGS) -r -o $@ $1,\
                      rm -f $@; $(AR) rcs $@ )


LDFLAGS is added in cmd_link_o_target which made changes to build
nand_spl.

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01  7:34     ` Wolfgang Denk
  2011-02-01 14:59       ` Haiying Wang
@ 2011-02-01 16:24       ` Scott Wood
  2011-02-01 19:32         ` Wolfgang Denk
  1 sibling, 1 reply; 25+ messages in thread
From: Scott Wood @ 2011-02-01 16:24 UTC (permalink / raw)
  To: u-boot

On Tue, 1 Feb 2011 08:34:01 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20110131135548.50d65759@udp111988uds.am.freescale.net> you wrote:
> > As I understand it, it has only been limited to PLATFORM_LDFLAGS since
> > the LDFLAGS_u-boot commit.  Was that change intentional, and widely
> > tested?
> 
> Can you please be more specific?  I don't see where "the
> LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related
> code.  The relevant hunk looks like this:
> 
> @@ -204,9 +204,11 @@ endif
>  
>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>  
> -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> +LDFLAGS += $(PLATFORM_LDFLAGS)
> +
> +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
>  ifneq ($(CONFIG_SYS_TEXT_BASE),)
> -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
> +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
>  endif

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
used?  So before, anything that board/cpu code adds directly to LDFLAGS
(maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
used in the final link.  After 8aba9dc, only things in
PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

-Scott

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 16:24       ` Scott Wood
@ 2011-02-01 19:32         ` Wolfgang Denk
  2011-02-01 19:51           ` Scott Wood
  0 siblings, 1 reply; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-01 19:32 UTC (permalink / raw)
  To: u-boot

Dear Scott Wood,

In message <20110201102446.23b4a2e9@udp111988uds.am.freescale.net> you wrote:
>
> Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> used?  So before, anything that board/cpu code adds directly to LDFLAGS
> (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> used in the final link.  After 8aba9dc, only things in
> PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

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
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
                                  - Terry Pratchett, _Witches Abroad_

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 19:32         ` Wolfgang Denk
@ 2011-02-01 19:51           ` Scott Wood
  2011-02-01 20:20             ` Wolfgang Denk
  2011-02-04 22:56             ` Graeme Russ
  0 siblings, 2 replies; 25+ messages in thread
From: Scott Wood @ 2011-02-01 19:51 UTC (permalink / raw)
  To: u-boot

On Tue, 1 Feb 2011 20:32:29 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20110201102446.23b4a2e9@udp111988uds.am.freescale.net> you wrote:
> >
> > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > used in the final link.  After 8aba9dc, only things in
> > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> 
> And this is correct for all boards?

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
switch back to LDFLAGS?  It's not obvious to me that the dropping of
board/cpu modifications to LDFLAGS except during partial link was an
intentional change, or a correct one for all boards.

The only case I see where it makes any difference at all is arch/i386,
which does LDFLAGS += --cref.  From the description of --cref in the
linker manual, it probably actually belongs in LDFLAGS_FINAL, though
I'm not sure if it's harmless to include it in partial link or not.
Currently, with 8aba9dc, it's included *only* in partial link.

It's also not clear to me what this option has to do with i386... it
looks like an arch-neutral debugging feature that doesn't affect the
actual u-boot image at all (the output goes into the map file).

-Scott

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 19:51           ` Scott Wood
@ 2011-02-01 20:20             ` Wolfgang Denk
  2011-02-01 20:40               ` Scott Wood
  2011-02-04 22:56             ` Graeme Russ
  1 sibling, 1 reply; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-01 20:20 UTC (permalink / raw)
  To: u-boot

Dear Scott Wood,

In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
>
> > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > used in the final link.  After 8aba9dc, only things in
> > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > 
> > And this is correct for all boards?
> 
> By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> switch back to LDFLAGS?  It's not obvious to me that the dropping of

I don;t understand why you contine to talk about "switch to
PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
cannot see it.

I see only a switch in your patch.  This is why I'm asking.


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
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 20:20             ` Wolfgang Denk
@ 2011-02-01 20:40               ` Scott Wood
  2011-02-04 15:52                 ` Haiying Wang
  2011-02-15  9:02                 ` Mike Frysinger
  0 siblings, 2 replies; 25+ messages in thread
From: Scott Wood @ 2011-02-01 20:40 UTC (permalink / raw)
  To: u-boot

On Tue, 1 Feb 2011 21:20:50 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
> >
> > > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > > used in the final link.  After 8aba9dc, only things in
> > > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > > 
> > > And this is correct for all boards?
> > 
> > By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> > switch back to LDFLAGS?  It's not obvious to me that the dropping of
> 
> I don;t understand why you contine to talk about "switch to
> PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
> cannot see it.
> 
> I see only a switch in your patch.  This is why I'm asking.

Before 8aba9dc, the flags for the final link were produced by taking
the existing LDFLAGS, and adding:
-Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.

This included anything that cpu/board code added to LDFLAGS -- some
architectures added --gc-sections, x86 added --cref, etc.  Since the above
flags are added to LDFLAGS, rather than replacing them, these flags got used
in the final link.

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
source for the flags for the final link.  It generates LDFLAGS_u-boot using
PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates to
LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

I don't see any other LDFLAGS changes in board/cpu code, so the distinction
between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
current boards.  However, the patch appears to be intended to support
platform linker flags that need to be used during partial link, which
would involve board/cpu additions to LDFLAGS.  This change would break that
only if those options need to be used for partial link *only*, and cannot be
used in the final link.  In such a case I'd suggest using something like
LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
were actually the case.

If you're looking to cut down on the number of variables, it's not clear to
me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
LDFLAGS.

-Scott

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 20:40               ` Scott Wood
@ 2011-02-04 15:52                 ` Haiying Wang
  2011-02-15  9:02                 ` Mike Frysinger
  1 sibling, 0 replies; 25+ messages in thread
From: Haiying Wang @ 2011-02-04 15:52 UTC (permalink / raw)
  To: u-boot

Dear Wolfgang,

On Tue, 2011-02-01 at 14:40 -0600, Scott Wood wrote: 
> On Tue, 1 Feb 2011 21:20:50 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
> > Dear Scott Wood,
> > 
> > In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
> > >
> > > > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > > > used in the final link.  After 8aba9dc, only things in
> > > > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > > > 
> > > > And this is correct for all boards?
> > > 
> > > By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> > > switch back to LDFLAGS?  It's not obvious to me that the dropping of
> > 
> > I don;t understand why you contine to talk about "switch to
> > PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
> > cannot see it.
> > 
> > I see only a switch in your patch.  This is why I'm asking.
> 
> Before 8aba9dc, the flags for the final link were produced by taking
> the existing LDFLAGS, and adding:
> -Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.
> 
> This included anything that cpu/board code added to LDFLAGS -- some
> architectures added --gc-sections, x86 added --cref, etc.  Since the above
> flags are added to LDFLAGS, rather than replacing them, these flags got used
> in the final link.
> 
> Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
> source for the flags for the final link.  It generates LDFLAGS_u-boot using
> PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates to
> LDFLAGS into LDFLAGS_u-boot, but it missed --cref.
> 
> I don't see any other LDFLAGS changes in board/cpu code, so the distinction
> between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
> current boards.  However, the patch appears to be intended to support
> platform linker flags that need to be used during partial link, which
> would involve board/cpu additions to LDFLAGS.  This change would break that
> only if those options need to be used for partial link *only*, and cannot be
> used in the final link.  In such a case I'd suggest using something like
> LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
> were actually the case.
> 
> If you're looking to cut down on the number of variables, it's not clear to
> me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
> LDFLAGS.
> 
> -Scott

Do you have time to read Scott's email and give us any further
recommendation? We do need to solve the issues of partial linking caused
by commit 8aba9dc.

Thanks.

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 19:51           ` Scott Wood
  2011-02-01 20:20             ` Wolfgang Denk
@ 2011-02-04 22:56             ` Graeme Russ
  1 sibling, 0 replies; 25+ messages in thread
From: Graeme Russ @ 2011-02-04 22:56 UTC (permalink / raw)
  To: u-boot

On 02/02/11 06:51, Scott Wood wrote:
> On Tue, 1 Feb 2011 20:32:29 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
>> Dear Scott Wood,
>>
>> In message <20110201102446.23b4a2e9@udp111988uds.am.freescale.net> you wrote:
>>>
>>> Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
>>> used?  So before, anything that board/cpu code adds directly to LDFLAGS
>>> (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
>>> used in the final link.  After 8aba9dc, only things in
>>> PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
>>
>> And this is correct for all boards?
> 
> By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> switch back to LDFLAGS?  It's not obvious to me that the dropping of
> board/cpu modifications to LDFLAGS except during partial link was an
> intentional change, or a correct one for all boards.
> 
> The only case I see where it makes any difference at all is arch/i386,
> which does LDFLAGS += --cref.  From the description of --cref in the
> linker manual, it probably actually belongs in LDFLAGS_FINAL, though
> I'm not sure if it's harmless to include it in partial link or not.
> Currently, with 8aba9dc, it's included *only* in partial link.
> 
> It's also not clear to me what this option has to do with i386... it
> looks like an arch-neutral debugging feature that doesn't affect the
> actual u-boot image at all (the output goes into the map file).

--cref can be dropped from x86 - I really should send a patch to rename
i386 to x86 ;)

Since x86 is currently a very simple platform to maintain (one CPU, one
board) and I have been dealing with breakages do to non x86 cleanups for a
while, I have no problem with tweaking the x86 linker options to be more
arch neutral.

Regards,

Graeme

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-01 20:40               ` Scott Wood
  2011-02-04 15:52                 ` Haiying Wang
@ 2011-02-15  9:02                 ` Mike Frysinger
  2011-02-16  0:51                   ` Scott Wood
  1 sibling, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-02-15  9:02 UTC (permalink / raw)
  To: u-boot

On Tuesday, February 01, 2011 15:40:13 Scott Wood wrote:
> Before 8aba9dc, the flags for the final link were produced by taking
> the existing LDFLAGS, and adding:
> -Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.

i think you're skipping a fairly large piece of the picture -- the whole 
reason for 8aba9dc commit in the first place: commit 6d8962e814 (introduction 
of partial linking).  before that commit, the linker was only used in one 
place: the final u-boot link.  because of that, LDFLAGS was only used in one 
place.  so people put both target-specific (u-boot) and linker-specific (ld) 
flags into the same place (LDFLAGS).  but with partial linking, that was no 
longer possible.  we needed a way to differentiate between the two and thus 
LDFLAGS_$@ was born.

so commit 8aba9dc is not something made for fun, but to fix real bugs people 
were seeing while building with bi-endian toolchains (arm/superh/mips/probably 
others), or bi-abi toolchains (blackfin/arm/probably others).

> This included anything that cpu/board code added to LDFLAGS -- some
> architectures added --gc-sections, x86 added --cref, etc.  Since the above
> flags are added to LDFLAGS, rather than replacing them, these flags got
> used in the final link.
> 
> Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
> source for the flags for the final link.  It generates LDFLAGS_u-boot using
> PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates
> to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

err, i dont think this is correct.  LDFLAGS is no longer the *only* source for 
the final link.  if you look at the actual target, you'll see it using 
$(LDFLAGS) $(LDFLAGS_$(@F)).

> I don't see any other LDFLAGS changes in board/cpu code, so the distinction
> between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
> current boards.  However, the patch appears to be intended to support
> platform linker flags that need to be used during partial link, which
> would involve board/cpu additions to LDFLAGS.  This change would break that
> only if those options need to be used for partial link *only*, and cannot
> be used in the final link.  In such a case I'd suggest using something
> like LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
> were actually the case.

if Linux hasnt had an issue with flags that are valid only during partial 
linking, then i dont think u-boot will either.

> If you're looking to cut down on the number of variables, it's not clear to
> me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
> LDFLAGS.

historically, ive never really seen much (any?) value in the split between 
PLATFORM_XXX and XXX.  i say we kill all the PLATFORM_XXX cruft.

ultimately, LDFLAGS_FINAL makes sense to me.  we cant override LD, nor can we 
override LDFLAGS, and it sucks if people have to duplicate flags in multiple 
variables when all they care about is the final link.  it's unavoidable pain 
imo born of attempting to build & finally link multiple applications in a 
single tree.
-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/20110215/67685ccc/attachment.pgp 

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-15  9:02                 ` Mike Frysinger
@ 2011-02-16  0:51                   ` Scott Wood
  2011-02-17  5:01                     ` Mike Frysinger
  0 siblings, 1 reply; 25+ messages in thread
From: Scott Wood @ 2011-02-16  0:51 UTC (permalink / raw)
  To: u-boot

On Tue, 15 Feb 2011 04:02:44 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> so commit 8aba9dc is not something made for fun, but to fix real bugs people 
> were seeing while building with bi-endian toolchains (arm/superh/mips/probably 
> others), or bi-abi toolchains (blackfin/arm/probably others).

Sure.  But it had a side effect, and this patch is an attempt to
fix that side effect without affecting the real purpose of 8aba9dc.

> > This included anything that cpu/board code added to LDFLAGS -- some
> > architectures added --gc-sections, x86 added --cref, etc.  Since the above
> > flags are added to LDFLAGS, rather than replacing them, these flags got
> > used in the final link.
> > 
> > Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
> > source for the flags for the final link.  It generates LDFLAGS_u-boot using
> > PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates
> > to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.
> 
> err, i dont think this is correct.  LDFLAGS is no longer the *only* source for 
> the final link.  if you look at the actual target, you'll see it using 
> $(LDFLAGS) $(LDFLAGS_$(@F)).

Ah.  So why is PLATFORM_LDFLAGS added into both LDFLAGS and
LDFLAGS_u-boot? :-P

-Scott

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
       [not found]       ` <1297878184.1977.18.camel@haiying-laptop>
@ 2011-02-16 18:29         ` Wolfgang Denk
  2011-02-16 18:40           ` Haiying Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-16 18:29 UTC (permalink / raw)
  To: u-boot

Dear Haiying Wang,

In message <1297878184.1977.18.camel@haiying-laptop> you wrote:
>
> I did run "./MAKEALL powerpc" for all ppc board, the System.map and
> u-boot.map keep exactly the same before and after applying the
> LDFLAGS_FINAL patch. Please find the attached two txt files and
> System.map and u-boot.map which are the results of MAKEALL. Do you think

I'm surrised that you send just one pair of these files.  Does that
mean that you did the compare only after the full MAKEALL run, i. e.
just on the last result, for the last board?

We have some 524 PowerPC configurations in boards.cfg, and the compare
must be done for _all_ off these, i. e. there are 2 x 524 pairs of
files to be compared.  Did you really do this?

> it is ok to apply this patch, if you are ok with the name _FINAL?

Others appear to be happy with it, and I don't have a better proposal,
so let's use this _FINAL name.

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
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-16 18:29         ` Wolfgang Denk
@ 2011-02-16 18:40           ` Haiying Wang
  2011-02-16 18:58             ` Wolfgang Denk
  0 siblings, 1 reply; 25+ messages in thread
From: Haiying Wang @ 2011-02-16 18:40 UTC (permalink / raw)
  To: u-boot

On Wed, 2011-02-16 at 19:29 +0100, Wolfgang Denk wrote:
> Dear Haiying Wang,
> 
> In message <1297878184.1977.18.camel@haiying-laptop> you wrote:
> >
> > I did run "./MAKEALL powerpc" for all ppc board, the System.map and
> > u-boot.map keep exactly the same before and after applying the
> > LDFLAGS_FINAL patch. Please find the attached two txt files and
> > System.map and u-boot.map which are the results of MAKEALL. Do you think
> 
> I'm surrised that you send just one pair of these files.  Does that
> mean that you did the compare only after the full MAKEALL run, i. e.
> just on the last result, for the last board?
> 
> We have some 524 PowerPC configurations in boards.cfg, and the compare
> must be done for _all_ off these, i. e. there are 2 x 524 pairs of
> files to be compared.  Did you really do this?
> > it is ok to apply this patch, if you are ok with the name _FINAL?
Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?

> Others appear to be happy with it, and I don't have a better proposal,
> so let's use this _FINAL name.
Thanks.

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-16 18:40           ` Haiying Wang
@ 2011-02-16 18:58             ` Wolfgang Denk
  2011-02-17  5:37               ` Mike Frysinger
  2011-02-17 19:28               ` Haiying Wang
  0 siblings, 2 replies; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-16 18:58 UTC (permalink / raw)
  To: u-boot

Dear Haiying Wang,

In message <1297881643.1977.28.camel@haiying-laptop> you wrote:
>
> > We have some 524 PowerPC configurations in boards.cfg, and the compare
> > must be done for _all_ off these, i. e. there are 2 x 524 pairs of
> > files to be compared.  Did you really do this?
> > > it is ok to apply this patch, if you are ok with the name _FINAL?
> Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?

I usually do this on the fly using shell scripting capabilities, i.e.
something like this (copying some shell functions from MAKEALL):

-----------------------------------------------------------------------
boards_by_field()
{
        awk \
                -v field="$1" \
                -v select="$2" \
                '($1 !~ /^#/ && $field == select) { print $1 }' \
                boards.cfg
}
boards_by_arch() { boards_by_field 2 "$@" ; }

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board 
cp System.map System.map.${board}.unpatched
cp u-boot.map u-boot.map.${board}.unpatched
done

...apply patch...

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cmp System.map.${board}.unpatched System.map || diff -u System.map.${board}.unpatched System.map >System.map.${board}.diff
cmp u-boot.map.${board}.unpatched u-boot.map || diff -u u-boot.map.${board}.unpatched u-boot.map >u-boot.map.${board}.diff
done

less *.diff
-----------------------------------------------------------------------

Note this is untested; you probably get the idea.

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
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                               - Mark Twain

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-16  0:51                   ` Scott Wood
@ 2011-02-17  5:01                     ` Mike Frysinger
  0 siblings, 0 replies; 25+ messages in thread
From: Mike Frysinger @ 2011-02-17  5:01 UTC (permalink / raw)
  To: u-boot

On Tuesday, February 15, 2011 19:51:00 Scott Wood wrote:
> On Tue, 15 Feb 2011 04:02:44 -0500 Mike Frysinger wrote:
> > > This included anything that cpu/board code added to LDFLAGS -- some
> > > architectures added --gc-sections, x86 added --cref, etc.  Since the
> > > above flags are added to LDFLAGS, rather than replacing them, these
> > > flags got used in the final link.
> > > 
> > > Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer
> > > the source for the flags for the final link.  It generates
> > > LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS.  It converts most
> > > of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed
> > > --cref.
> > 
> > err, i dont think this is correct.  LDFLAGS is no longer the *only*
> > source for the final link.  if you look at the actual target, you'll see
> > it using $(LDFLAGS) $(LDFLAGS_$(@F)).
> 
> Ah.  So why is PLATFORM_LDFLAGS added into both LDFLAGS and
> LDFLAGS_u-boot? :-P

i'm not saying PLATFORM_LDFLAGS makes sense.  it certainly seems like we've 
outgrown the PLATFORM_XXX flags and could be cleaned up.
-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/20110217/515698cf/attachment.pgp 

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-16 18:58             ` Wolfgang Denk
@ 2011-02-17  5:37               ` Mike Frysinger
  2011-02-17  8:33                 ` Wolfgang Denk
  2011-02-17 19:28               ` Haiying Wang
  1 sibling, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-02-17  5:37 UTC (permalink / raw)
  To: u-boot

On Wednesday, February 16, 2011 13:58:07 Wolfgang Denk wrote:
> Haiying Wang wrote:
> > > We have some 524 PowerPC configurations in boards.cfg, and the compare
> > > must be done for _all_ off these, i. e. there are 2 x 524 pairs of
> > > files to be compared.  Did you really do this?
> > > 
> > > > it is ok to apply this patch, if you are ok with the name _FINAL?
> > 
> > Sorry, I did not get the 2x254 pairs of System.map and u-boot.map.
> > Running "MAKEALL powerpc" only left the last pair. Could you please show
> > me how I can keep the former 523 pairs?
> 
> I usually do this on the fly using shell scripting capabilities, i.e.
> something like this (copying some shell functions from MAKEALL):
> 
> -----------------------------------------------------------------------
> boards_by_field()
> {
>         awk \
>                 -v field="$1" \
>                 -v select="$2" \
>                 '($1 !~ /^#/ && $field == select) { print $1 }' \
>                 boards.cfg
> }
> boards_by_arch() { boards_by_field 2 "$@" ; }
> 
> for board in $(boards_by_arch powerpc) ; do
> ./MAKEALL $board
> cp System.map System.map.${board}.unpatched
> cp u-boot.map u-boot.map.${board}.unpatched
> done
> 
> ...apply patch...
> 
> for board in $(boards_by_arch powerpc) ; do
> ./MAKEALL $board
> cmp System.map.${board}.unpatched System.map || diff -u
> System.map.${board}.unpatched System.map >System.map.${board}.diff cmp
> u-boot.map.${board}.unpatched u-boot.map || diff -u
> u-boot.map.${board}.unpatched u-boot.map >u-boot.map.${board}.diff done

this is is generally useful, perhaps MAKEALL should grow a flag to back up the 
generated files with board-qualified names like the log files ...

then your script would be:
./MAKEALL <newflag> powerpc
<copy all generated files to old/>
<apply change>
./MAKEALL <newflag> powerpc
<compare results>
-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/20110217/82e6aae7/attachment.pgp 

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-17  5:37               ` Mike Frysinger
@ 2011-02-17  8:33                 ` Wolfgang Denk
  0 siblings, 0 replies; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-17  8:33 UTC (permalink / raw)
  To: u-boot

Dear Mike Frysinger,

In message <201102170037.42565.vapier@gentoo.org> you wrote:
> 
> > I usually do this on the fly using shell scripting capabilities, i.e.
> > something like this (copying some shell functions from MAKEALL):
...
> this is is generally useful, perhaps MAKEALL should grow a flag to back up the 
> generated files with board-qualified names like the log files ...

Yes, the general approach is certainly very useful, and I use it a lot
to run all kinds of tests. However, I usually find myself interested
in very different kinds of results; looking at the .map files is just
one of the many use cases so I would not know what sort of "state
saving" code to implement by default.

The most generic approach is of course an out-of-tree build with a
separate build directory for each board.  But then, this costs a lot
of ressources and is only seldom really needed.

So I really don;t have a goiod suggestion how to generalize this. I
tend to rather spread the word how such things can be done, and do
them on the fly as needed.

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 ain't so much the things we don't know that get  us  in  trouble.
It's  the  things  we know that ain't so." - Artemus Ward aka Charles
Farrar Brown

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-16 18:58             ` Wolfgang Denk
  2011-02-17  5:37               ` Mike Frysinger
@ 2011-02-17 19:28               ` Haiying Wang
  2011-02-17 20:38                 ` Haiying Wang
  1 sibling, 1 reply; 25+ messages in thread
From: Haiying Wang @ 2011-02-17 19:28 UTC (permalink / raw)
  To: u-boot

On Wed, 2011-02-16 at 19:58 +0100, Wolfgang Denk wrote:
> Dear Haiying Wang,
> 
> In message <1297881643.1977.28.camel@haiying-laptop> you wrote:
> >
> > > We have some 524 PowerPC configurations in boards.cfg, and the compare
> > > must be done for _all_ off these, i. e. there are 2 x 524 pairs of
> > > files to be compared.  Did you really do this?
> > > > it is ok to apply this patch, if you are ok with the name _FINAL?
> > Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?
> 
> I usually do this on the fly using shell scripting capabilities, i.e.
> something like this (copying some shell functions from MAKEALL):
> 
> -----------------------------------------------------------------------
> boards_by_field()
> {
>         awk \
>                 -v field="$1" \
>                 -v select="$2" \
>                 '($1 !~ /^#/ && $field == select) { print $1 }' \
>                 boards.cfg
> }
> boards_by_arch() { boards_by_field 2 "$@" ; }
> 
> for board in $(boards_by_arch powerpc) ; do
> ./MAKEALL $board 
> cp System.map System.map.${board}.unpatched
> cp u-boot.map u-boot.map.${board}.unpatched
> done
> 
> ...apply patch...
> 
> for board in $(boards_by_arch powerpc) ; do
> ./MAKEALL $board
> cmp System.map.${board}.unpatched System.map || diff -u System.map.${board}.unpatched System.map >System.map.${board}.diff
> cmp u-boot.map.${board}.unpatched u-boot.map || diff -u u-boot.map.${board}.unpatched u-boot.map >u-boot.map.${board}.diff
> done
> 
> less *.diff
> -----------------------------------------------------------------------
> 
Your scripts works fine. Now I only get one pair of diff which are
System.map.mpc7448hpc2.diff  u-boot.map.mpc7448hpc2.diff, because
mpc7448hpc2 failed to build:
"
Configuring for mpc7448hpc2 board...
cc1: error: AltiVec and E500 instructions cannot coexist
cc1: error: AltiVec and E500 instructions cannot coexist
lib/asm-offsets.c:1: error: AltiVec and E500 instructions cannot coexist
make: *** [lib/asm-offsets.s] Error 1
make: *** Waiting for unfinished jobs....

--------------------- SUMMARY ----------------------------
Boards compiled: 1
Boards with warnings or errors: 1 ( mpc7448hpc2 )
----------------------------------------------------------
".

Other than that, I think all the System.map and u-boot.map keep the same
before and after applying the patch. 

What kind of info do you still expect to see?

Thanks.

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-17 19:28               ` Haiying Wang
@ 2011-02-17 20:38                 ` Haiying Wang
  2011-02-22 19:39                   ` Wolfgang Denk
  0 siblings, 1 reply; 25+ messages in thread
From: Haiying Wang @ 2011-02-17 20:38 UTC (permalink / raw)
  To: u-boot

On Thu, 2011-02-17 at 14:28 -0500, Haiying Wang wrote:
> > 
> Your scripts works fine. Now I only get one pair of diff which are
> System.map.mpc7448hpc2.diff  u-boot.map.mpc7448hpc2.diff, because
> mpc7448hpc2 failed to build:
> "
> Configuring for mpc7448hpc2 board...
> cc1: error: AltiVec and E500 instructions cannot coexist
> cc1: error: AltiVec and E500 instructions cannot coexist
> lib/asm-offsets.c:1: error: AltiVec and E500 instructions cannot coexist
> make: *** [lib/asm-offsets.s] Error 1
> make: *** Waiting for unfinished jobs....
> 
> --------------------- SUMMARY ----------------------------
> Boards compiled: 1
> Boards with warnings or errors: 1 ( mpc7448hpc2 )
> ----------------------------------------------------------
> ".
> 
> Other than that, I think all the System.map and u-boot.map keep the same
> before and after applying the patch. 
> 
Sorry, I ignored some other info just now. Not only 7448 but also some
other boards failed to build, you can get the failed info from the
beforepatch.txt and afterpatch.txt I sent yesterday. The final result
should be:

haiying at haiying-laptop:~/Opensource/Denx/u-boot$ ls -s *.diff
0 System.map.ESTEEM192E.diff         0 System.map.P2020DS.diff
0 System.map.ETX094.diff             0 System.map.sbc8641d.diff
0 System.map.LANTEC.diff             0 System.map.SPD823TS.diff
0 System.map.mpc7448hpc2.diff        0 System.map.xpedite517x.diff
0 System.map.MPC8610HPCD.diff        0 u-boot.map.mpc7448hpc2.diff
0 System.map.MPC8641HPCN_36BIT.diff  0 u-boot.map.MPC8610HPCD.diff
0 System.map.MPC8641HPCN.diff        0 u-boot.map.MPC8641HPCN_36BIT.diff
0 System.map.mpq101.diff             0 u-boot.map.MPC8641HPCN.diff
0 System.map.P2020DS_36BIT.diff      0 u-boot.map.sbc8641d.diff
0 System.map.P2020DS_DDR2.diff       0 u-boot.map.xpedite517x.diff

The above boards failed to build thus the diff files were generated but the contents are all 0. 

All the other boards should not have difference in System.map/u-boot.map before and after applying the LDFLAGS_FINAL patch.

Haiying

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
  2011-02-17 20:38                 ` Haiying Wang
@ 2011-02-22 19:39                   ` Wolfgang Denk
  0 siblings, 0 replies; 25+ messages in thread
From: Wolfgang Denk @ 2011-02-22 19:39 UTC (permalink / raw)
  To: u-boot

Dear Haiying Wang,

In message <1297975097.1973.20.camel@haiying-laptop> you wrote:
>
> > Your scripts works fine. Now I only get one pair of diff which are
> > System.map.mpc7448hpc2.diff  u-boot.map.mpc7448hpc2.diff, because
> > mpc7448hpc2 failed to build:
> > "
> > Configuring for mpc7448hpc2 board...
> > cc1: error: AltiVec and E500 instructions cannot coexist
> > cc1: error: AltiVec and E500 instructions cannot coexist
> > lib/asm-offsets.c:1: error: AltiVec and E500 instructions cannot coexist
> > make: *** [lib/asm-offsets.s] Error 1
> > make: *** Waiting for unfinished jobs....

You are using a broken or incorrectly configured (for the purpose)
tool chain then.  I don't see such problems with ELDK.


> Sorry, I ignored some other info just now. Not only 7448 but also some
> other boards failed to build, you can get the failed info from the
> beforepatch.txt and afterpatch.txt I sent yesterday. The final result
> should be:
> 
> haiying at haiying-laptop:~/Opensource/Denx/u-boot$ ls -s *.diff
> 0 System.map.ESTEEM192E.diff         0 System.map.P2020DS.diff
> 0 System.map.ETX094.diff             0 System.map.sbc8641d.diff
> 0 System.map.LANTEC.diff             0 System.map.SPD823TS.diff
> 0 System.map.mpc7448hpc2.diff        0 System.map.xpedite517x.diff
> 0 System.map.MPC8610HPCD.diff        0 u-boot.map.mpc7448hpc2.diff
> 0 System.map.MPC8641HPCN_36BIT.diff  0 u-boot.map.MPC8610HPCD.diff
> 0 System.map.MPC8641HPCN.diff        0 u-boot.map.MPC8641HPCN_36BIT.diff
> 0 System.map.mpq101.diff             0 u-boot.map.MPC8641HPCN.diff
> 0 System.map.P2020DS_36BIT.diff      0 u-boot.map.sbc8641d.diff
> 0 System.map.P2020DS_DDR2.diff       0 u-boot.map.xpedite517x.diff
> 
> The above boards failed to build thus the diff files were generated but the contents are all 0. 

All these boards build fine for me.

> All the other boards should not have difference in System.map/u-boot.map before and after applying the LDFLAGS_FINAL patch.

As it's mostly unmaintained and/or Freescale boards that are untested
because of your tool chain issues I guess we can assume the test
passed.

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
To get something done, a committee should consist  of  no  more  than
three men, two of them absent.

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2011-02-22 19:39 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-31 18:32 [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL Haiying.Wang at freescale.com
2011-01-31 19:33 ` Wolfgang Denk
2011-01-31 19:55   ` Scott Wood
2011-02-01  7:34     ` Wolfgang Denk
2011-02-01 14:59       ` Haiying Wang
2011-02-01 16:24       ` Scott Wood
2011-02-01 19:32         ` Wolfgang Denk
2011-02-01 19:51           ` Scott Wood
2011-02-01 20:20             ` Wolfgang Denk
2011-02-01 20:40               ` Scott Wood
2011-02-04 15:52                 ` Haiying Wang
2011-02-15  9:02                 ` Mike Frysinger
2011-02-16  0:51                   ` Scott Wood
2011-02-17  5:01                     ` Mike Frysinger
2011-02-04 22:56             ` Graeme Russ
2011-01-31 20:14   ` Haiying Wang
2011-01-31 20:30     ` Wolfgang Denk
     [not found]       ` <1297878184.1977.18.camel@haiying-laptop>
2011-02-16 18:29         ` Wolfgang Denk
2011-02-16 18:40           ` Haiying Wang
2011-02-16 18:58             ` Wolfgang Denk
2011-02-17  5:37               ` Mike Frysinger
2011-02-17  8:33                 ` Wolfgang Denk
2011-02-17 19:28               ` Haiying Wang
2011-02-17 20:38                 ` Haiying Wang
2011-02-22 19:39                   ` 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.