[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE

[Scott Wood]

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

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

It'd still be only a runtime error if you used the wrong one.

Whereas by keeping each image's config separate it simply isn't an
error -- you will get the right value.

Perhaps symbols that aren't safe to use from makefiles/linker scripts
shouldn't have the CONFIG_ prefix (and thus not be exported to them).

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

I was just looking for some consistency so I could figure out what is
being objected to.  When something is rejected for specific reasons,
questioning whether those reasons actually imply the conclusion doesn't
seem unreasonable.

I wasn't trying to pick a fight -- if you feel this strongly about doing it
that way, then we can live with it.

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

I do not agree that they are separate purposes.  All config symbols
make sense only in the context of the image that is being built.

I suppose it depends on whether you view SPL as "this other bit of code
that gets distributed with u-boot and tied into the build system, and
reuses some files" or "a u-boot configuration which is extremely slimmed
down and targetting a different boot environment".

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

It is not a single make run.  SPL is a separate, recursive invocation
of make.  As far as I can see the CONFIG_ variables are not exported.

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

That's precisely why I wanted them separate. :-)

It keeps the CONFIG_ namespace consistent between C code and
makefiles, and avoids interference from one component to the next.

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

Parallel builds should work fine.  It would be a separate autoconf.mk
file somewhere under nand_spl, not rewriting the same file multiple
times during the build process.

-Scott