[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