On Tue, 9 Nov 2010 22:11:41 +0100 Wolfgang Denk <w...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
