[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE

[Scott Wood]

On Tue, 9 Nov 2010 22:11:41 +0100
Wolfgang Denk <wd at denx.de> wrote:

> #ifdef NAND_SPL
> #define CONFIG_SYS_TEXT_BASE_SPL xxx
> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE_SPL
> #else
> #define CONFIG_SYS_TEXT_BASE yyy
> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE
> #endif
> 
> followed by multiple instances of
> 
> do something with CONFIG_SYS_MONITOR_BASE

What, semantically, is the difference between the CONFIG_SYS_TEXT_BASE
and CONFIG_SYS_MONITOR_BASE?  Just that one is used from linker
scripts/makefiles and the other from C/assembly code (and if you get
it wrong, you may silently get the wrong value instead of a linker
error)?

Isn't the whole point of a special CONFIG_ namespace that gets
exported to autoconf.mk so that the same symbol could be defined once,
possibly based on ifdefs in the board config file, and used for both?

> CONFIG_SYS_TEXT_BASE is a symbos primarily intended for the linker
> call, i. e. for Makefile context.  This is a pretty special situation,
> that does not apply to "normal" CONFIG_* settings.

It does apply to normal CONFIG_ settings if we ever want to use them in
a makefile, such as to decide which files to pull in.  These 4K NAND
SPLs are small and simple enough that we generally don't do that now,
but I believe Haiying ran into this when trying to create a larger
middle stage that runs out of SRAM.

I suppose we could have no sharing of makefile fragments with that
stage, and rely on the final U-boot's settings going into config.mk
-- as long as we don't need to make the file conditional in the
middle-stage makefile except in cases where it always matches the final
stage config.  Not pretty.

> > Are you going to insist that we rip out all the other CONFIG_ symbols
> > that are conditional on NAND_SPL (but happen to not be referred to in
> > makefiles -- is that really the meaningful semantic difference here)?
> > CONFIG_SYS_HRCW_HIGH versus CONFIG_SYS_HRCW_HIGH_SPL?
> > CONFIG_DEFAULT_IMMR versus CONFIG_DEFAULT_IMMR_SPL?
> 
> Why should I?  None of these are needed anywhere in the Makefiles, are
> they?

No, which is why they didn't break anything -- but why does that
matter, if your argument is that they semantically should be separate
symbols and that the ifdef is the problem?

If your argument is that providing a separate autoconf.mk is a pain[1],
and you'd rather hack around it with a separate symbol in the one case
where it currently matters, I can understand that -- though that leaves
pain lurking for the larger middle stage, as noted above.

I don't see from a conceptual level, though, why these images should be
sharing an autoconf.mk.

-Scott

[1] How much of a pain is it?  It's already a separate make invocation,
so pulling the new set of symbols into make shouldn't be a problem, as
long as they symbols aren't exported.