On Mon, 24 Jan 2011 13:49:19 +0100 Wolfgang Denk <w...@denx.de> wrote:
> > > > + 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. They mean different things. We can't "do with a single variable definition" in the current NAND SPL. Why would TPL be any different? Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into CONFIG_TPL would make it look more like the existing SPL names. Or we could do something like: CONFIG_HAS_SPL /* set in all of U-Boot when an SPL is used */ CONFIG_IN_SPL /* set only when building the SPL */ CONFIG_HAS_TPL /* set in all of U-Boot when a TPL is used */ CONFIG_IN_TPL /* set only when building the TPL */ -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
