[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE

[Wolfgang Denk]

Dear Scott Wood,

In message <20101110150307.279a5b05 at udp111988uds.am.freescale.net> you wrote:
>
> 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 fully agree with you on that.  And I want to point out that I really
appreciate such discussions.  I definitely don't claim to be always
right (but when I have my mind set it takes really good arguments).

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

Actually I am not that seriously convinced. I just fear that the other
approach introduces a LOT of trouble - way more problems then it ever
could solve.

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

For me it is just a part of U-Boot. Usually we do not use separate
images, resulting from separate builds, but the SPL and the "real"
U-Boot image get bundled into one "NAND boot" image. So for me it
seems obvious that these are all just stages of a single build.

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

Well, see above.  You are argumenting from a low-level, implementation
point of view.  For the end user this is not transparent at all.  He
just runs a single "make foo_config" and a single "make all".  The end
user sees and thinks of just a single configuration and a single build
he is running.

The fact that we have several build steps is something else.  I
understand (now, only now!) that you see the SPL part as an
independent configuration - such a thought never crossed my mind
before.  For me it's just a part of the whole build procedure.

> > 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 cannot follow you here.  I get the creeps when I imagine to have to
track down why a build fails when parameters change on the fly.  Did
you ever have to track down why some boared config can be build nicely
in-tree, but out-of-tree builds fail, but only on SMP machines? and
only with >N cores (or fast disks)?  I have been there. And I do not
want to imagine that the whole environment might change under my feet
before I can grab it.

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

Oh... this is another thing I did not grasp yet.  But then, how would
it become active for "common" code parts?

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
In the realm of scientific observation, luck is granted only to those
who are prepared.                                     - Louis Pasteur