[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely]

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.





-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195