[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE

[Wolfgang Denk]

Dear Scott Wood,

In message <20101109155225.183a3061 at udp111988uds.am.freescale.net> you wrote:
>
> What, semantically, is the difference between the CONFIG_SYS_TEXT_BASE
> and CONFIG_SYS_MONITOR_BASE?  Just that one is used from linker

Nothing.

> 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)?

You are absolutely right. This is the reason why I object against
redefining CONFIG_SYS_TEXT_BASE and suggest to use a separate
CONFIG_SYS_TEXT_BASE_SPL instead.

> 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?

Correct.

> > 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.

Full agreement.

Assume you would accept to use a separate CONFIG_SYS_TEXT_BASE_SPL -
which of the problems you listed would remain?

> 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?

It seems you are in fighting mood today.  I ain't.  You try to turn
my own arguments against me.  I'm not willing to play such a game.

> 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.

Maybe you could be so kind and elucidate why you think that

1) using separate variable names for separate purposes is "hacking
   around"?

2) changing make variable settings on the fly during a single make run 
   would be a clean solution?  I see a lot of potential problems with
   that.

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

To provide a consistent and debuggable build environment?  I have zero
interest in debugging the Makefiles for such a build for example on a
SMP system which attempts to run these steps in parallel.  Oh, of
course we must not do that, we must serialize everything?

You will need really good arguments to convince me that switching the
build environment on the fly is conceptually clean or a clever thing
to do.


> [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.

It will be a pain to debug if there are any problems.  What we have
now is already complex enough.  If you want to improve the code then
pelase help making it simpler.  Please do not case make it more
complex.

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
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall