Hi Joey,

Plus, it's very slow to compile and build archives for a billion modules that are be unrelated to your platform. I agree KConfig seems like an obvious choice and I'm willing to work with you in making these changes.

Nice to hear. So the following steps need to be done:

* Port the Kconfig tool from linux or busybox, so that is build and called from the Makefile framework of U-Boot. * Extract all CONFIG_ and CFG_ defines from the sources and put them into related Kconfig files (e.g. cmd_foobar.[ch] -> cmd_foobar.kcfg), using dummy templates for each extracted CONFIG/CFG define. This can be automated by a script and created lots of small files. * Fix and cleanup all these *.kcfg fragments - this will be the big work! It requires to setup the right Kconfig type, default and inter-dependancies between them. Also some sufficient help text is a must. * Move and rearrange the *.kcfg fragments to form a logical tree of options. Kcfg files might be merged together where appropriate to avoid hundreds of small files. * Use make menuconfig to clone all values from your platform header file. Store the created .config file as your default config. * Create and split autoconfig headers, so that only those sources are rebuild whose defines got changed.

All this could be done in parallel, so that the autoconf.h headers would be created but not yet used. Later you comment all stuff in your platform config and include the autoconfig stuff instead.

The difficult step is the migration from the old platform headers to the autogenerated stuff, as this required somebody to test the platform - we don't to break working platforms.

Any additional thoughts?

Regards Carsten

____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.248 from 15.06.2007 ____________ Virus checked by G DATA AntiVirus Version: AVKB 17.265 from 18.06.2007 Virus news: www.antiviruslab.com

"Wolfgang Denk" wd@denx.de wrote in message news:20070618203506.DB4E13535E1@atlas.denx.de...

Please be careful when planning for this. One feature thatis essential to me is that it must be possible to have all information for the configuration of a certain board in a single configuration file (i. e. something corresponding to what we have in include/config/<board>.h now)

The .config file from kbuild is just a big list of name-value configuration values. Each SoC has code for on-chip peripherals, and each board has code specific to its soldered components. The main difference should be using kbuild for a hierarchical menu configuration instead of one giant include file to increase/decrease the size of u-boot.bin. Invariant parameters like clock

In an email directly to Carsten I suggested that the first step should be a prototype. Right now the main configuation options (CONFIG_LCD) all have sub-options (LCD_BPP). Most of them are true/false, some are enumerated choices, and some are strings. It should all be possible, but the first step is probably to draw the tree of configuration options for at least one platform.

Did you have anything in mind for Makefile trickery? The best example I could find is TEXT_BASE, and that fits well as a kbuild configuration parameter.

-joey

Wolfgang Denk wrote:

In message f5723h$lmm$1@sea.gmane.org you wrote:

...

Did you have anything in mind for Makefile trickery? The best example I could find is TEXT_BASE, and that fits well as a kbuild configuration parameter.

Many boards pass additional configuration information from the Makefile - see for example the MPC8360EMDS* or the TQM8260_* boards. Less obvious but even more tricky is what the ARM Integrator boards do by running the board/integrator*/split_by_variant.sh scripts.

Best regards,

Wolfgang Denk

My 0.01 euro (lousy exchange rate)...

Doing the config in the makefile via differently named targets is Really Tricky[tm] in that it works quite well but makes me feel icky when I think about it. Parsing the target and echoing config parameters into a config.mk config file via the rule is not a good way to do config IMHO.

I don't know what is done in the ARM area, but the 8xx, 82xx, and 83xx boards that use this method could just as well use a kconfig style configuration system. All they are doing is selecting boot high/low, memory configurations, processor speeds, board flavors, LCD support, etc. All those sound _exactly_ like kconfig stuff to me.

Downsides? How do you do the equivalent of "MAKEALL"? We will need a default config file for each target that is currently supported and modify MAKEALL to do (the equivalent of) make mrproper && make defconfig && make for each class of targets that MAKEALL currently supports.

Best regards, gvb

Hi,

Please be careful when planning for this. One feature thatis essential to me is that it must be possible to have all information for the configuration of a certain board in a single configuration file (i. e. something corresponding to what we have in include/config/<board>.h now)

That is exactly, what I have in mind. The current include/config/<board>.h files will include the autogenerated autoconf.h file (or better a tree of such files, so that build dependancies are only triggered for those submodules whose configs have changed.)

Only those defines, which are unique for the target board will remain in the include/config/<board>.h file.

...

This can be automated by a script and created lots of small files.

Again, be careful. Ther eis a lot of #ifdef and Makefile trickery in handling the CONFIG_ and CFG_ definitions, and if you try to approach this with a script, then it will *not* be a simple one. Also, "lots of small files" is something that probably is not an improvement.

I fear, that the scripts can produces only templates for the Kconfig files to reduce typing work. All the interactions and dependancies must be added by hand later. Also the help stuff must be filled in by hand. On the other hand, this has the advantage, that most sources are reviewed and maybe rearranged, while the Kconfig files are worked out. Of course the amount of Kconfig files should be reduced to a minimum.

With some careful planning, the Kconfig system can be setup in parallel to the on-going work. The first step could be to have a working Kconfig system which basically defines an empty menutree with nearly no options. All target headers get patched to include these autogenerated headers. <full regression test>.

Now the most common defines will be moved from the headers to some kconfig entry, e.g. the CONFIG_<boardname> define is a good candidate. So more and more common defines will move into the config system. At the end only the single use and board specific defines are left.

Maybe there is a somewhat less perfect, but simpler approach to implement only a 90% or 95% solution with much less effort?

Effort is relative :-) U-Boot is growing fast, and soon there might be much more platforms. Linux and Busybox proof that a sophisticated config system can scale with large projects - and any simpler solution might lack this property and must be replaced later by some 'better' thing. Then all work needs to be redone again.

So I prefer the a 100% solution ;-)

Regards Carsten

____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.248 from 15.06.2007 ____________ Virus checked by G DATA AntiVirus Version: AVKB 17.267 from 19.06.2007 Virus news: www.antiviruslab.com

Hallo,

No, this is NOT what I mean. "include" means that the information is distributed over at least two files, one of them auto-generated, which makes things just worse.

Maybe we talking about the same thing. All information should be configured with a Single frontend, and the data is saved into a single file. And from this single file a single header might be created (autoconf.h) or for improving the rebuild behaviour this File might be post processed and split into separate files. So each subsystem just includes Related defines, and only subsystems with changed config must be recompiled.

The last thing is just a nice feature to save compile time, but it's still a single config file as a source.

The new config system will make all these board headers obsolete and replaces them by default configs for each supported target.

That's my goal with the new config system.

The whole default configuration is unique for a board.

Yes, and for each board a <boardname>_defconfig will reside in include/configs. The former <boardname>.h file can be deleted, as all information from this file is now auto-configured from the defconfig file.

That was what I wanted to point out. Your previous posting sounded as if you expect a few lines of grep and sed trickery would do all the work ;-)

No, way :-) This will become some nice handwork. Maybe some people will help a bit. See it positive, I get a chance to cross-read most of the current sources to figure out meaning and dependencies of defines. This will for sure help me for future U-Boot ports.

That "<full regression test>" is actually the fun part :-(

Yes, it means to have 100dreds of toolchains at hands and maybe a computer cluster at hands :-) But this issue can be discussed when we are ready for such test.

I don't. I'm an engineer. I always try to recognize where it makese sense to stop. See below.

Sure. This is my every-days life as well. But when the current config system reaches ist limits, it might be much more work to do the necessary step.

Or the project will split into smaller or new projects to reduce complexity. I would prefer to have a single bootloader project available for all existing targets - so I can benefit from the common parts and features everywhere.

I still remember the times where we had different bootloaders for all and everything. I don't want that back.

Regards Carsten

____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.248 from 15.06.2007 ____________ Virus checked by G DATA AntiVirus Version: AVKB 17.268 from 20.06.2007 Virus news: www.antiviruslab.com

FWIW, I fully support going this direction. I've been making some steps in the same direction, but as always there are more things to do than time to do them in.

My advice: start small and don't try to change too much at once. Get the basic infrastructure in place and get the patches out to the list. Maybe start with being able to select the board port with Kconfig while leaving include/configs/* in place. Once that is working and proven, then start migrating configuation over to Kconfig.

I think it might be worthwhile to see if we long term can merge the configuration with the Linux configuration

I think some of the configuration items could be the same and could therefore use the same name.

Will U-Boot break, if the Linux .config is included in the Makefile?

Best Regards Ulf Samuelsson