Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1296076056.1985.47.camel@haiying-laptop> you wrote: > > I fixed the NAND_SPL in this way. If it is OK for you, I will generate > the patches accordingly for TPL as well. Thanks. > BTW, the "./MAKEALL powerpc " worked for my previous patch. This looks good to me. Thanks a lot. 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: w...@denx.de CAUTION: The Mass of This Product Contains the Energy Equivalent of 85 Million Tons of TNT per Net Ounce of Weight. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Wolfgang, On Mon, 2011-01-24 at 23:29 +0100, Wolfgang Denk wrote: > Dear Haiying Wang, > > In message <1295907459.2051.158.camel@haiying-laptop> you wrote: > > > > > It's not the name. But you use it ina few places here, buth then hard > > > encode "tpl" in a number of other paces there. Which means that you > > > cannot change TPL_BOOT to any other value, or building would break. > > > So why do we need this variable? > > It follows the same usage of NAND_SPL. > > Ah. I see. Well, so NAND_SPL needs fixing as well :-( I fixed the NAND_SPL in this way. If it is OK for you, I will generate the patches accordingly for TPL as well. Thanks. BTW, the "./MAKEALL powerpc " worked for my previous patch. Haiying From: Haiying Wang Date: Wed, 26 Jan 2011 16:03:39 -0500 Subject: [PATCH] Fix NAND_SPL in Makefile Signed-off-by: Haiying Wang --- Makefile | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 5f93646..f2c6d65 100644 --- a/Makefile +++ b/Makefile @@ -287,11 +287,6 @@ LDPPFLAGS += \ $(shell $(LD) --version | \ sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') -ifeq ($(CONFIG_NAND_U_BOOT),y) -NAND_SPL = nand_spl -U_BOOT_NAND = $(obj)u-boot-nand.bin -endif - ifeq ($(CONFIG_ONENAND_U_BOOT),y) ONENAND_IPL = onenand_ipl U_BOOT_ONENAND = $(obj)u-boot-onenand.bin @@ -320,7 +315,11 @@ BOARD_SIZE_CHECK = endif # Always append ALL so that arch config.mk's can add custom ones -ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) $(U_BOOT_ONENAND) +ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_ONENAND) + +ifeq ($(CONFIG_NAND_U_BOOT),y) +ALL += $(obj)u-boot-nand.bin +endif all: $(ALL) @@ -401,10 +400,11 @@ $(LDSCRIPT): depend $(obj)u-boot.lds: $(LDSCRIPT) $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@ -$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend +$(obj)nand_spl:$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk $(MAKE) -C nand_spl/board/$(BOARDDIR) all -$(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin + +$(obj)u-boot-nand.bin: $(obj)nand_spl $(obj)u-boot.bin cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin $(ONENAND_IPL):$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk -- 1.7.3.1.50.g1e633 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 24 Jan 2011 23:29:45 +0100 Wolfgang Denk wrote: > Dear Haiying Wang, > > In message <1295907459.2051.158.camel@haiying-laptop> you wrote: > > > > > It's not the name. But you use it ina few places here, buth then hard > > > encode "tpl" in a number of other paces there. Which means that you > > > cannot change TPL_BOOT to any other value, or building would break. > > > So why do we need this variable? > > It follows the same usage of NAND_SPL. > > Ah. I see. Well, so NAND_SPL needs fixing as well :-( Agreed, it seems like just hardcoding the target name would work fine, be clearer, and avoid relying on unportable make behavior. > > > Sorry, I cannot follow - which reset? which semicolon? > > > > Sorry, :%s/reset/rest/. The semicolon is the same one in your previous > > comments. I meant the part: > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > $(MAKE) -C tpl/board/$(BOARDDIR) all > > Ah, I see what you mean. But that's a colon (':') - a semicolon if a > ';'. You called it a semicolon first. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1295907459.2051.158.camel@haiying-laptop> you wrote: > > > It's not the name. But you use it ina few places here, buth then hard > > encode "tpl" in a number of other paces there. Which means that you > > cannot change TPL_BOOT to any other value, or building would break. > > So why do we need this variable? > It follows the same usage of NAND_SPL. Ah. I see. Well, so NAND_SPL needs fixing as well :-( > > Sorry, I cannot follow - which reset? which semicolon? > > Sorry, :%s/reset/rest/. The semicolon is the same one in your previous > comments. I meant the part: > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > $(MAKE) -C tpl/board/$(BOARDDIR) all Ah, I see what you mean. But that's a colon (':') - a semicolon if a ';'. > If it is as you thought, then how the platforms will be built without > NAND_SPL or ONENAND_IPL is not defined? I have to admit that I wasnot aware that NAND_SPL was usign all teh same constructs. We should clean all this up. 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: w...@denx.de For every complex problem, there is a solution that is simple, neat, and wrong. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 2011-01-24 at 23:09 +0100, Wolfgang Denk wrote: > Dear Haiying Wang, > > In message <1295906076.2051.127.camel@haiying-laptop> you wrote: > > > > > What I do not understand is what the TPL_BOOT variable in the > > > Makefile is good for. I cannot understand the current use. > > > > Well, it was used to generate the tpl image under tpl/ directory. Maybe > > TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. > > It's not the name. But you use it ina few places here, buth then hard > encode "tpl" in a number of other paces there. Which means that you > cannot change TPL_BOOT to any other value, or building would break. > So why do we need this variable? It follows the same usage of NAND_SPL. > > > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > > > and this rule will probably cause a build error, doesn't it? > > > > No, I don't think there is a build error. > > > > > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > > > defined, which results in this make rule: > > > > > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > i. e. there would be no target name befoe the semicolon. > > If TPL_BOOT here is not defined, the reset(after semicolon) will not be > > executed, just like NAND_SPL and ONENAND_IPL etc. > > Sorry, I cannot follow - which reset? which semicolon? Sorry, :%s/reset/rest/. The semicolon is the same one in your previous comments. I meant the part: : $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C tpl/board/$(BOARDDIR) all If it is as you thought, then how the platforms will be built without NAND_SPL or ONENAND_IPL is not defined? Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 2011-01-24 at 13:49 +0100, Wolfgang Denk wrote: > > > > > > > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > > > > +TPL_BOOT = tpl > > > > +endif > > > > > > I don't understand what the "TPL_BOOT" is good for, or how it's > > > supposed to work. > > TPL_BOOT works like NAND_SPL but after NAND_SPL is executed. It is a > > middle stage boot loader to balance the 4K nand spl limitation which can > > not include ddr spd code and the 256K L2 SRAM size which can not > > accommodate the final uboot image on some Freescale Qoriq P1 platforms. > > Yes, I understand what you are atempting to do. > > What I do not understand is what the TPL_BOOT variable in the > Makefile is good for. I cannot understand the current use. Well, it was used to generate the tpl image under tpl/ directory. Maybe TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. > > The main purpose of tpl is to initialize the ddr with spd code in l2 > > sram then load the final uboot image to ddr. The reason to call tpl is > > because it runs after spl, the Second Program Loader. My original patch > > used CONFIG_MIDDLE_STAGE_SRAM_BOOT but you recommended to use > > CONFIG_SYS_2ND_STAGE_BOOT(http://lists.denx.de/pipermail/u-boot/2010-August/075653.html). > > However, 2ND STAGE is not correct here since it runs after SPL. > > > > > > ifeq ($(CONFIG_NAND_U_BOOT),y) > > > > NAND_SPL = nand_spl > > > > U_BOOT_NAND = $(obj)u-boot-nand.bin > > > > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > > > > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > > > > > > > -$(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin > > > > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > > > > $(obj)u-boot-nand.bin > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > and this rule will probably cause a build error, doesn't it? > > No, I don't think there is a build error. > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > defined, which results in this make rule: > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > $(MAKE) -C tpl/board/$(BOARDDIR) all > > i. e. there would be no target name befoe the semicolon. If TPL_BOOT here is not defined, the reset(after semicolon) will not be executed, just like NAND_SPL and ONENAND_IPL etc. > > > Has this code ever been tested? > > Yes, I tested it on P1021MDS board, and also built for other 85xx > > NAND_config without error. > > Did you run a "MAKEALL ppc", i. e. build for all PPC board, not only > NAND booting versions? No, I didn't. I will do it and let you know. But I did pass the build for other 85xx non-nand booting version. > > > > + CONFIG_TPL_U_BOOT > > > > + > > > > + Builds a U-Boot image that contains a loader stub > > > > (tertiary > > > > + program loader -- TPL) that boots out of some type of > > > > RAM, > > > > + after being loaded by an SPL or similar > > > > platform-specific > > > > + mechanism. This symbol will be set in all build phases. > > > > + > > > > + CONFIG_TPL_BOOT > > > > + > > > > + This is set by the build system when compiling code to > > > > go into > > > > + the TPL. It is not set when building the code that the > > > > TPL > > > > + loads, or when building the SPL. > > > > > > Can we not do with a single variable definition? > > > > I did not get it. Could you please give a recommendation? > > Well, I see a pollution with such CONFIG_ settings. I don;t have a > solution ready to recommend, but if you can find a way not to define > so many different settings for a single purpose that wouldbe great. > Will apply Scott's recommendation. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1295906076.2051.127.camel@haiying-laptop> you wrote: > > > What I do not understand is what the TPL_BOOT variable in the > > Makefile is good for. I cannot understand the current use. > > Well, it was used to generate the tpl image under tpl/ directory. Maybe > TPL_BOOT is a bad name here, I just thought it was too simple to use TPL. It's not the name. But you use it ina few places here, buth then hard encode "tpl" in a number of other paces there. Which means that you cannot change TPL_BOOT to any other value, or building would break. So why do we need this variable? > > > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > > > and this rule will probably cause a build error, doesn't it? > > > No, I don't think there is a build error. > > > > WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not > > defined, which results in this make rule: > > > > : $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > i. e. there would be no target name befoe the semicolon. > If TPL_BOOT here is not defined, the reset(after semicolon) will not be > executed, just like NAND_SPL and ONENAND_IPL etc. Sorry, I cannot follow - which reset? which semicolon? 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: w...@denx.de Quantum Mechanics is God's version of "Trust me." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Scott Wood, In message <20110124133835.5b26b...@udp111988uds.am.freescale.net> you wrote: > > Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into > CONFIG_TPL would make it look more like the existing SPL names. Or we > could do something like: > > CONFIG_HAS_SPL /* set in all of U-Boot when an SPL is used */ > CONFIG_IN_SPL /* set only when building the SPL */ > CONFIG_HAS_TPL /* set in all of U-Boot when a TPL is used */ > CONFIG_IN_TPL /* set only when building the TPL */ I like that much better. 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: w...@denx.de The moral of the story is: "Don't stop to tighten your shoe laces during the Olympics 100m finals". - Kevin Jones in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Mon, 24 Jan 2011 13:49:19 +0100 Wolfgang Denk wrote: > > > > + CONFIG_TPL_U_BOOT > > > > + > > > > + Builds a U-Boot image that contains a loader stub > > > > (tertiary > > > > + program loader -- TPL) that boots out of some type of > > > > RAM, > > > > + after being loaded by an SPL or similar > > > > platform-specific > > > > + mechanism. This symbol will be set in all build phases. > > > > + > > > > + CONFIG_TPL_BOOT > > > > + > > > > + This is set by the build system when compiling code to > > > > go into > > > > + the TPL. It is not set when building the code that the > > > > TPL > > > > + loads, or when building the SPL. > > > > > > Can we not do with a single variable definition? > > > > I did not get it. Could you please give a recommendation? > > Well, I see a pollution with such CONFIG_ settings. I don;t have a > solution ready to recommend, but if you can find a way not to define > so many different settings for a single purpose that wouldbe great. They mean different things. We can't "do with a single variable definition" in the current NAND SPL. Why would TPL be any different? Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into CONFIG_TPL would make it look more like the existing SPL names. Or we could do something like: CONFIG_HAS_SPL /* set in all of U-Boot when an SPL is used */ CONFIG_IN_SPL /* set only when building the SPL */ CONFIG_HAS_TPL /* set in all of U-Boot when a TPL is used */ CONFIG_IN_TPL /* set only when building the TPL */ -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Haiying Wang, In message <1295842861.2196.38.camel@haiying-laptop> you wrote: > On Sat, 2011-01-22 at 23:04 +0100, Wolfgang Denk wrote: > > > diff --git a/Makefile b/Makefile > > > index 87a383d..94af465 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -290,6 +290,10 @@ LDPPFLAGS += \ > > > $(shell $(LD) --version | \ > > > sed -ne 's/GNU ld version > > > \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > > > > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > > > +TPL_BOOT = tpl > > > +endif > > > > I don't understand what the "TPL_BOOT" is good for, or how it's > > supposed to work. > TPL_BOOT works like NAND_SPL but after NAND_SPL is executed. It is a > middle stage boot loader to balance the 4K nand spl limitation which can > not include ddr spd code and the 256K L2 SRAM size which can not > accommodate the final uboot image on some Freescale Qoriq P1 platforms. Yes, I understand what you are atempting to do. What I do not understand is what the TPL_BOOT variable in the Makefile is good for. I cannot understand the current use. > The main purpose of tpl is to initialize the ddr with spd code in l2 > sram then load the final uboot image to ddr. The reason to call tpl is > because it runs after spl, the Second Program Loader. My original patch > used CONFIG_MIDDLE_STAGE_SRAM_BOOT but you recommended to use > CONFIG_SYS_2ND_STAGE_BOOT(http://lists.denx.de/pipermail/u-boot/2010-August/075653.html). > However, 2ND STAGE is not correct here since it runs after SPL. > > > ifeq ($(CONFIG_NAND_U_BOOT),y) > > > NAND_SPL = nand_spl > > > U_BOOT_NAND = $(obj)u-boot-nand.bin > > > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > > > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > > > > > -$(U_BOOT_NAND): $(NAND_SPL) $(obj)u-boot.bin > > > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > > > $(obj)u-boot-nand.bin > > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > > and this rule will probably cause a build error, doesn't it? > No, I don't think there is a build error. WEell, if CONFIG_TPL_U_BOOT is not 'y', then TPL_BOOT is not defined, which results in this make rule: : $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C tpl/board/$(BOARDDIR) all i. e. there would be no target name befoe the semicolon. > > Has this code ever been tested? > Yes, I tested it on P1021MDS board, and also built for other 85xx NAND_config > without error. Did you run a "MAKEALL ppc", i. e. build for all PPC board, not only NAND booting versions? > > > + CONFIG_TPL_U_BOOT > > > + > > > + Builds a U-Boot image that contains a loader stub (tertiary > > > + program loader -- TPL) that boots out of some type of RAM, > > > + after being loaded by an SPL or similar platform-specific > > > + mechanism. This symbol will be set in all build phases. > > > + > > > + CONFIG_TPL_BOOT > > > + > > > + This is set by the build system when compiling code to go into > > > + the TPL. It is not set when building the code that the TPL > > > + loads, or when building the SPL. > > > > Can we not do with a single variable definition? > > I did not get it. Could you please give a recommendation? Well, I see a pollution with such CONFIG_ settings. I don;t have a solution ready to recommend, but if you can find a way not to define so many different settings for a single purpose that wouldbe great. 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: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Sat, 2011-01-22 at 23:04 +0100, Wolfgang Denk wrote: > > diff --git a/Makefile b/Makefile > > index 87a383d..94af465 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -290,6 +290,10 @@ LDPPFLAGS += \ > > $(shell $(LD) --version | \ > > sed -ne 's/GNU ld version > > \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > > +TPL_BOOT = tpl > > +endif > > I don't understand what the "TPL_BOOT" is good for, or how it's > supposed to work. TPL_BOOT works like NAND_SPL but after NAND_SPL is executed. It is a middle stage boot loader to balance the 4K nand spl limitation which can not include ddr spd code and the 256K L2 SRAM size which can not accommodate the final uboot image on some Freescale Qoriq P1 platforms. The main purpose of tpl is to initialize the ddr with spd code in l2 sram then load the final uboot image to ddr. The reason to call tpl is because it runs after spl, the Second Program Loader. My original patch used CONFIG_MIDDLE_STAGE_SRAM_BOOT but you recommended to use CONFIG_SYS_2ND_STAGE_BOOT(http://lists.denx.de/pipermail/u-boot/2010-August/075653.html). However, 2ND STAGE is not correct here since it runs after SPL. > > ifeq ($(CONFIG_NAND_U_BOOT),y) > > NAND_SPL = nand_spl > > U_BOOT_NAND = $(obj)u-boot-nand.bin > > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > > > -$(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin > > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > > $(obj)u-boot-nand.bin > > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > + $(MAKE) -C tpl/board/$(BOARDDIR) all > > Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, > and this rule will probably cause a build error, doesn't it? No, I don't think there is a build error. > Has this code ever been tested? Yes, I tested it on P1021MDS board, and also built for other 85xx NAND_config without error. > ... > $(MAKE) -C $(TPL_BOOT)/board/$(BOARDDIR) all > ?? > > > +NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin > > +NAND_SPL_OBJS-$(CONFIG_TPL_U_BOOT) += $(obj)tpl/u-boot-tpl.bin > > +NAND_SPL_OBJS-y += $(obj)u-boot.bin > > Ditto here and in the following - but how is NAND_SPL related to TPL > building? These should be completely independent? It came up with Mike Frysinger's comments http://lists.denx.de/pipermail/u-boot/2010-November/082373.html . It is applied in the case that the TPL is used with nand spl build. In fact, our another usage of TPL_BOOT is for SPI/SD boot. Patch will come is this set is accepted. > > + CONFIG_TPL_U_BOOT > > + > > + Builds a U-Boot image that contains a loader stub (tertiary > > + program loader -- TPL) that boots out of some type of RAM, > > + after being loaded by an SPL or similar platform-specific > > + mechanism. This symbol will be set in all build phases. > > + > > + CONFIG_TPL_BOOT > > + > > + This is set by the build system when compiling code to go into > > + the TPL. It is not set when building the code that the TPL > > + loads, or when building the SPL. > > Can we not do with a single variable definition? I did not get it. Could you please give a recommendation? Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Kumar Gala, In message you wrote: > > Did you plan on review this patch? Just done - I wonder if this code has ever been tested at all? 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: w...@denx.de You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear haiying.w...@freescale.com, In message <1291217737-3870-4-git-send-email-haiying.w...@freescale.com> you wrote: > From: Haiying Wang > > TPL is introduced to enable a loader stub that boots out of some type of RAM, > after being loaded by an SPL or similar platform-specific mechanism. > > One example of using this tpl loader is to initialize the ddr through spd code > in case the L2 SRAM size is not big enough to hold the final uboot image and > the nand spl code needs to be limitated to 4K byte, then tpl code will load > the > final uboot image after ddr is initialized. > > Signed-off-by: Haiying Wang > --- > Incorporate Mike's comment to use new variable NAND_SPL_OBJS-y > Makefile | 17 +++-- > README | 27 +++ > 2 files changed, 42 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 87a383d..94af465 100644 > --- a/Makefile > +++ b/Makefile > @@ -290,6 +290,10 @@ LDPPFLAGS += \ > $(shell $(LD) --version | \ > sed -ne 's/GNU ld version > \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > +TPL_BOOT = tpl > +endif I don't understand what the "TPL_BOOT" is good for, or how it's supposed to work. > ifeq ($(CONFIG_NAND_U_BOOT),y) > NAND_SPL = nand_spl > U_BOOT_NAND = $(obj)u-boot-nand.bin > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > -$(U_BOOT_NAND): $(NAND_SPL) $(obj)u-boot.bin > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > $(obj)u-boot-nand.bin > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > + $(MAKE) -C tpl/board/$(BOARDDIR) all Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, and this rule will probably cause a build error, doesn't it? Has this code ever been tested? And if we use a variable for the "tlp" string, should this not be ... $(MAKE) -C $(TPL_BOOT)/board/$(BOARDDIR) all ?? > +NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin > +NAND_SPL_OBJS-$(CONFIG_TPL_U_BOOT) += $(obj)tpl/u-boot-tpl.bin > +NAND_SPL_OBJS-y += $(obj)u-boot.bin Ditto here and in the following - but how is NAND_SPL related to TPL building? These should be completely independent? > +- TPL Boot Support > + CONFIG_TPL_U_BOOT > + > + Builds a U-Boot image that contains a loader stub (tertiary > + program loader -- TPL) that boots out of some type of RAM, > + after being loaded by an SPL or similar platform-specific > + mechanism. This symbol will be set in all build phases. > + > + CONFIG_TPL_BOOT > + > + This is set by the build system when compiling code to go into > + the TPL. It is not set when building the code that the TPL > + loads, or when building the SPL. Can we not do with a single variable definition? 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: w...@denx.de Things that try to look like things often do look more like things than things. Well-known fact. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
On Dec 1, 2010, at 9:35 AM, wrote: > From: Haiying Wang > > TPL is introduced to enable a loader stub that boots out of some type of RAM, > after being loaded by an SPL or similar platform-specific mechanism. > > One example of using this tpl loader is to initialize the ddr through spd code > in case the L2 SRAM size is not big enough to hold the final uboot image and > the nand spl code needs to be limitated to 4K byte, then tpl code will load > the > final uboot image after ddr is initialized. > > Signed-off-by: Haiying Wang > --- > Incorporate Mike's comment to use new variable NAND_SPL_OBJS-y > Makefile | 17 +++-- > README | 27 +++ > 2 files changed, 42 insertions(+), 2 deletions(-) Wolfgang, Did you plan on review this patch? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot