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

[Haiying Wang]

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