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

Wolfgang Denk wd at denx.de
Mon Jan 24 13:49:19 CET 2011


Dear Haiying Wang,

In message <1295842861.2196.38.camel at 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: wd at 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.


More information about the U-Boot mailing list