As per Wolfgang & my conversation on IRC this morning; here is the proposed approach for migrating the mainline u-boot tree to use kconfig:
First, some background: By convention, u-boot uses two prefixes for configuration macros. In general, CFG_* macros are used to define board properties, and CONFIG_* macros are for user configurable options. However, if we migrate to using Kconfig for managing the config macros, then all the macros need to be prefixed with CONFIG_ (not CFG_). As such, there needs to be a mass rename of the CFG_ prefix to CONFIG_<something>_.
For lack of a better name, Wolfgang and I have settled on replacing all instances of CFG_* with CONFIG_BSP_*.
So, here's the proposed migration approach...
Commit early in the next merge window (1.3.1?): 1. Perform mass rename of CFG_ macros to CONFIG_BSP_* 2. Perform mass split of COBJS makefile macros to prepare for conditional compiling. 3. Add cpp/sed postprocessor to generate an autoconf.mk file from the existing include/configs/*.h files (already posted a patch for this) and include config files 4. Include autoconf.mk into the Makefiles to support conditional compiling of .c files. At this point there should be no difference in the u-boot binaries produced.
Commit in 1.3.2 merge window: 1. Import kconfig source into u-boot tree 2. Create giant Kconfig file containing all possible CONFIG_ macros. Populate with macro types (bool, string, hex, etc) but don't include any dependencies between values (yet) 3. Use kconfig to postprocess autoconf.mk for validation and generate autoconf.h 4. Modify mkconfig to allow a board port to specify a *_defconfig file instead of a header file. If a defconfig is provided, then include/config.h will include autoconf.h instead of a config file from include/configs. At this point u-boot should still be producing identical binaries. kconfig is in the u-boot build process, but menuconfig build targets are not enabled.
In the 1.3.3 merge window: 1. Split/Reorganize the big Kconfig file into smaller logically organized Kconfig files. Each board port should define a top level target and the target will select config options which are required for the board port (CONFIG_BSP_*). Organization of this will probably require some thought. 2. Migrate board ports over to the new approach. 3. Enable menuconfig and oldconfig targets to allow u-boot config to be manipulated by the user. This step is probably going to be the riskiest and the most work. It will probably take a number of merge windows to get it all right without causing instability.
Cheers, g.