| Message ID | 1291217737-3870-4-git-send-email-Haiying.Wang@freescale.com |
|---|---|
| State | Superseded |
| Delegated to: | Kumar Gala |
| Headers | show |
On Dec 1, 2010, at 9:35 AM, <Haiying.Wang@freescale.com> <Haiying.Wang@freescale.com> wrote: > From: Haiying Wang <Haiying.Wang@freescale.com> > > 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 <Haiying.Wang@freescale.com> > --- > 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
Dear Haiying.Wang@freescale.com, In message <1291217737-3870-4-git-send-email-Haiying.Wang@freescale.com> you wrote: > From: Haiying Wang <Haiying.Wang@freescale.com> > > 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 <Haiying.Wang@freescale.com> > --- > 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
Dear Kumar Gala, In message <BE116222-9427-4216-9CAE-00E3A4B14B5F@kernel.crashing.org> 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
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
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
On Mon, 24 Jan 2011 13:49:19 +0100 Wolfgang Denk <wd@denx.de> 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
Dear Scott Wood, In message <20110124133835.5b26bbf3@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
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
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
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
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
On Mon, 24 Jan 2011 23:29:45 +0100 Wolfgang Denk <wd@denx.de> 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
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 + 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 + +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 + +$(U_BOOT_NAND): $(NAND_SPL) $(TPL_BOOT) $(obj)u-boot.bin + cat $(NAND_SPL_OBJS-y) > u-boot-nand.bin $(ONENAND_IPL): $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk $(MAKE) -C onenand_ipl/board/$(BOARDDIR) all @@ -1226,6 +1237,7 @@ clean: @rm -f $(obj)lib/asm-offsets.s @rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map} @rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map} + @rm -f $(obj)tpl/{u-boot-tpl,u-boot-tpl.map} @rm -f $(ONENAND_BIN) @rm -f $(obj)onenand_ipl/u-boot.lds @rm -f $(TIMESTAMP_FILE) $(VERSION_FILE) @@ -1250,6 +1262,7 @@ clobber: clean @rm -fr $(obj)include/generated @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l -print | xargs rm -f + @[ ! -d $(obj)tpl ] || find $(obj)tpl -name "*" -type l -print | xargs rm -f ifeq ($(OBJTREE),$(SRCTREE)) mrproper \ diff --git a/README b/README index 68f5fb0..9c7d40d 100644 --- a/README +++ b/README @@ -2108,6 +2108,33 @@ FIT uImage format: Adds the MTD partitioning infrastructure from the Linux kernel. Needed for UBI support. +- NAND Boot Support + CONFIG_NAND_U_BOOT + + Builds a U-Boot image that boots from NAND, prefixed by a small + loader stub (secondary program loader -- SPL) that loads the + rest of U-Boot into RAM. This symbol will be set in all build + phases. + + CONFIG_NAND_SPL + + This is set by the build system when compiling code to go into + the SPL. It is not set when building the code that the SPL + loads. + +- 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. Modem Support: --------------