[U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader

[Haiying Wang]

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