Hi, Is there a mechanism to override or update a CONFIG_ value during the make process? In the MicroBlaze architecture we have a highly configurable CPU - various ALU options can be enabled or disabled at will during the hardware build phase. We have several Kconfig options that must match this, and which are used to generate the appropriate CFLAGS during kernel build. e.g. CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare MicroBlaze uses flat devices trees to configure the platform (peripherals, memory, buses etc), but the device trees generated for our systems also describe the CPU - exactly the info we need to extract the right CPUFLAGS One of our make targets (not in mainline yet, but coming) - "make simpleImage.<dtsname>" compiles and statically links the specified DTS file into the kernel image. So, when making a simpleImage target, we know at compile time exactly which hardware target we intend to boot. So, it would be nice if we can force the appropriate CPUFLAGS derived directly from the DTS file, instead of relying on potentially incorrect CONFIG_ values set by the user during menuconfig. The DTS is just a text file, we can grep or awk over it to get what we need to know. One way that occurs to me is to detect in arch/microblaze/Makefile that a particular DTS file is provided, and if so then derive CPUFLAGS-y from that, instead of from the CONFIG_ vars. This would be pretty easy to achieve, but would require duplication of Makefile content, also means that .config doesn't actually describe the kernel that was build. autoconf.h and so on will also be wrong. Not ideal for a trick that's aiming to improve correctness and reduce hard-to-debug errors. Thus, returning to the question - is there a sane way that we can override or force the relevant CONFIG_ values, from within the Makefile itself? Or, must we resort to a script, and do it as a preprocessing step? Is there a reasonable way to still integrate this into the kernel build phase? A worst case approach is to just check the DTS against CONFIG_, and error out if they don't match or form a downward-compatible subset. Thanks, John -- John Williams, PhD, B.Eng, B.IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
