On Tue, 9 Nov 2010 23:22:26 +0100 Wolfgang Denk <w...@denx.de> wrote:
> Dear Scott Wood, > > In message <20101109155225.183a3...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
