[U-Boot-Users] Some questions about what is planned to improve U-Boot configuration...

[U-Boot-Users] Some questions about what is planned to improve U-Boot configuration...

[Carsten Schlote]

Hi,

as everyone knows, the current config system for U-Boot is simply PITA.
I regexed all 'CONFIG_' defines from the latest sources, and I found
more than 1300 unique defines. Not tested with 'CFG_' defines yet. Some
defines use cannonical names, so you see what belongs together. For the
rest you must dig in the sources.

I also found, that you need to undef several defines to disable a sub
system completely. Any single change/addition/removal to/of a CONFIG_
define might have a side-effect. And most times it has.

I would like to know, if there are any plans or is on-going work to
replace this hand-crafted mess with a configuration system? 

I'd like to use something like Kconfig. It turned out to be useful with
Linux, BusyBox or ptxdist. It handles dependencies between defines, and
also provides help and defaults for each.

Regards
  Carsten





____________
Virus checked by G DATA AntiVirusKit
Version: AVK 17.5384 from 14.06.2007

____________
Virus checked by G DATA AntiVirus
Version: AVK 17.5384 from 14.06.2007
Virus news: www.antiviruslab.com

[U-Boot-Users] Some questions about what is planned to improveU-Boot configuration...

[Joey Oravec]

"Carsten Schlote" <c.schlote@konzeptpark.de> wrote in message 
news:46597312D56D2A47A3A6E9C1D0D9B7AEB0C2C0 at kpladc0001.konzeptpark.intra...
> as everyone knows, the current config system for U-Boot is simply PITA.
> I regexed all 'CONFIG_' defines from the latest sources, and I found
> more than 1300 unique defines. Not tested with 'CFG_' defines yet. Some
> defines use cannonical names, so you see what belongs together. For the
> rest you must dig in the sources.

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.

-joey 

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Carsten Schlote]

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

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Wolfgang Denk]

Dear Carsten,

in message <46597312D56D2A47A3A6E9C1D0D9B7AEB0C2E4@kpladc0001.konzeptpark.intra> you wrote:
> 
> * 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.

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)

>   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.

> 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.

Indeed, please don't forget that you have to run  a  full  regression
test cycle on each and everyone board.

> Any additional thoughts?

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

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: wd at denx.de
"We all agree on the necessity of compromise. We just can't agree  on
when it's necessary to compromise."
                - Larry Wall in  <1991Nov13.194420.28091@netlabs.com>

[U-Boot-Users] Some questions about what is plannedtoimproveU-Boot configuration...

[Joey Oravec]

"Wolfgang Denk" <wd@denx.de> wrote in message 
news:20070618203506.DB4E13535E1 at 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 

[U-Boot-Users] Some questions about what is plannedtoimproveU-Boot configuration...

[Wolfgang Denk]

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

-- 
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: wd at denx.de
Single tasking: Just Say No.

[U-Boot-Users] Some questions about what is plannedtoimproveU-Boot configuration...

[Jerry Van Baren]

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

[U-Boot-Users] Some questions about what is plannedtoimproveU-Boot configuration...

[Wolfgang Denk]

In message <4677CCB5.5050204@smiths-aerospace.com> you wrote:
>
> My 0.01 euro (lousy exchange rate)...

Depends on where you live. For me it's OK ;-)

> 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.

Agreed. I just wanted to point out that such things *are* being done,
and that it's not sufficient fo grep for some config options from the
includ/config/* files and feed these through some scripts. A *lot* of
manual postprocessing will be needed.

> Downsides?  How do you do the equivalent of "MAKEALL"?  We will need a 
> default config file for each target that is currently supported and 

You need that in any case.

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: wd at denx.de
FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10"  will
parse  and  generate  code  creating  a  variable, DO10I, as follows:
"DO10I = 1.10" If that doesn't terrify you, it should.

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Carsten Schlote]

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

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Wolfgang Denk]

In message <46597312D56D2A47A3A6E9C1D0D9B7AEB0C323@kpladc0001.konzeptpark.intra> you wrote:
> 
> > 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.)

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.

When I write "a single configuration file" I  really  mean  a  SINGLE
file, and not collecting the information from several includes.

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

The whole default configuration is unique for a board.

> 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.

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 ;-)

> 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>. 

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

> So I prefer the a 100% solution ;-)

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

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: wd at denx.de
The first 90% of a project takes 90% of the time, the last 10%  takes
the other 90% of the time.

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Carsten Schlote]

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

[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Wolfgang Denk]

In message <46597312D56D2A47A3A6E9C1D0D9B7AEB0C346@kpladc0001.konzeptpark.intra> you wrote:
> 
> > 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

I am pretty sure that this cannot be done. Please read 20  or  30  of
the  existing board config files to see what they contain. You may be
able to catch 50% or maybe even 80% and on some  boards  95%  with  a
"configuration  frontend",  but  I expect you will get stuck with the
rest.  And  the  result  will  be  that  you  have  distributed   the
configuration  information over several unrelated places, which makes
it even harder to get an overview than in the current situation.

But please feel free to prove me wrong.

> 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. 

I know what you want. I just dont believe there is a straight way  to
get there.

> 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.

I guess you will have to extend Kconfig a lot to support this.

> Yes, it means to have 100dreds of toolchains at hands and maybe a

No, just 8 or 10 or so.

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

Neither do I.

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: wd at denx.de
Documentation is the castor oil of programming.
Managers know it must be good because the programmers hate it so much.

[U-Boot-Users] Some questions about what is planned to improve U-Boot configuration...

[Grant Likely]

On 6/14/07, Carsten Schlote <c.schlote@konzeptpark.de> wrote:
> I would like to know, if there are any plans or is on-going work to
> replace this hand-crafted mess with a configuration system?
>
> I'd like to use something like Kconfig. It turned out to be useful with
> Linux, BusyBox or ptxdist. It handles dependencies between defines, and
> also provides help and defaults for each.

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.

Cheers,
g.

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

[U-Boot-Users] Some questions about what is planned to improve U-Boot configuration...

[Carsten Schlote]

Hi,  

> 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.

That's my plan for now. I hacked a first frame work, and now I need to
work out what needs to be configured and how to structure the
configuration menu.

>  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.

This is step two. Wenn the configuration files for kconfig are complete
enough, I will simply include "autoconf.h" from my board header and
comment out all my handmade defines. 

So there are no big changes, but I can do small tests - just for the
log: When the new configuration is complete there should be not board
headers anymore. Ok, just theory...

Ragards
  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

[U-Boot-Users] Some questions about what is planned to improveU-Boot configuration...

[Ulf Samuelsson]

> 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 

[U-Boot-Users] Some questions about what is planned to improveU-Boot configuration...

[Stefan Roese]

Hi Ulf,

On Wednesday 20 June 2007, Ulf Samuelsson wrote:
> 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.

Yes, we definitely should use the same names whenever possible. For example 
for the architecture and cpu definitions, like CONFIG_405GP or CONFIG_4xx.

But I don't think that we really should aim to merge the configuration systems 
completely. This would go too far.

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

Hopefully not. But again, I don't think this should be our goal here.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================