Dear Scott Wood, In message <20101109143747.685f9...@udp111988uds.am.freescale.net> you wrote: > > I don't see how > > #ifdef NAND_SPL > #define CONFIG_SYS_TEXT_BASE xxx > #else > #define CONFIG_SYS_TEXT_BASE yyy > #endif > > is more of a maintenance problem than > > #define CONFIG_SYS_TEXT_BASE_SPL xxx > #define CONFIG_SYS_TEXT_BASE yyy > > followed by multiple instances of > > #ifdef NAND_SPL > do something with CONFIG_SYS_TEXT_BASE_SPL > #else > do something with CONFIG_SYS_TEXT_BASE > #endif
Assuming that your code really needs to know the start address of the image, it should probably do something like this instead: #ifdef NAND_SPL #define CONFIG_SYS_TEXT_BASE xxx #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE #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 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. > And as I've pointed out, this gets to be an even bigger mess with > larger SPLs that want to pull in bigger chunks of U-Boot based on > CONFIG_ symbols. Are we going to have to create an SPL version of each > of them, too? And a third version of each symbol, for a three-stage > boot? I don't see why that should be the case? AFAICT so far CONFIG_SYS_TEXT_BASE is one of a very small number of highly special variable definitions that need to be exported to the Makefile context. > 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? > Should we replace CONFIG_NS16550_MIN_FUNCTIONS with directly ifdeffing > NAND_SPL in the serial code? I think you misinterpret the situation. > It is the same purpose. The problem is treating separate, only > somewhat related image builds as being the same build and requiring > that they have the same config. They have separate makefiles, separate > linker scripts, separate everything except some shared code... and > autoconf.mk. Just because we got away with it until now does not make > it the right thing to do. Right - "separate makefiles, separate linker scripts, separate everything" _and_ separate text base addresses. 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: w...@denx.de "I didn't know it was impossible when I did it." _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
