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
