[U-Boot-Users] Configuration System

[Jon Loeliger]

On Fri, 2004-04-30 at 11:31, Wolfgang Denk wrote:
> >     - What CPU Architecture is being targeted?
> > 
> >     - Given the CPU Architecture is now known, which processor
> >       is being selected?
> > 
> >     - What board is being targeted?

> Isn't that 300% redundand already?

I don't think so, but I'm willing to be wrong.

> Why do I need to select an architecture and a processor when I know I
> have an IceCube board which will never be ARM and never be fit with a
> MPC860 processor?

So, we could ask arguably ask the questions in a slightly
better order, and derive valid CPU choices given a board.
It's the fact that there can be more than one CPU choice
that motivates me here.

> At this stage, all you need to select is the board type.

But that is not good enough to be uniquely identifying yet.
And I think this is an existing issue with some of the
configurations in the current scheme where you have to
provide CPU information as well as the board.  In particular,
I'm thinking of the examples as described in the top-level
README:

    For the Cogent platform, you need to specify the cpu type as well;
    e.g. "make cogent_mpc8xx_config". And also configure the cogent
    directory according to the instructions in cogent/README.

I had a perfect example of such a situation today.  I have 4
CPUs in the PPC family that I am working with currently.  I also
have two different boards.  Until today, there was a known
supported mapping that looked like this:

           BOARD
    CPU  | B1   B2
    -----+---------
     C1  |  x
     C2  |  x
     C3  |      x
     C4  |      x

If you were using Board B1, then you could have been using
a CPU C1 or a C2.  If you were using a CPU C4, you must have
been on a B2 board.

This morning, I was asked to make new U-Boot release for
a C4 on an B1 board.  I knew that the code in cpu/cpu.c would
handle this properly as it was properly configured to handle
the different CPU CONFIG_'s already.  All I needed to was to
pick Board B2 and CPU C4.

> > I think that one of the key factors where a new configuration
> > system could win, in general, is in "enforcing bad combinations".
> 
> "enforcing bad combinations"??? You must be joking.

I think I misspoke myself here.  My real point was that it
can be used to disallow bad combinations by explicitly
capturing supported configurations.  Maybe I am being naive
here, but I've implemented such knowledge for other systems
that were as complex as U-Boot seems to be (to me).


> Which improvement would that give? Right  now  you  select  a  target
> config name, like "TQM860L". Nobody needs to know more.

I'm merely trying to establish a few comfiguration options
along the way, and prevent huge choice lists.  The person
doing the configuring doesn't want a flat list of 172 boards
from which to make a selection.  In general, there are established
config symbols such as CONFIG_ARCH_ARM, or CONFIG_MPC85xx that
give an indication of specific families or architectures that
are used throughout the code base already.  A hierarchical 
method of selecting provides both a scalable selection method
and a means to introduce those symbols along the way.  It gives
structure and guidance for future additions as well.


> I'm thinking about how I spend my time. For me, working  with  U-Boot
> involves several tasks:
> 
> (1) porting new architectures/processors/boards; we  do  this  for  a
>     living  so it must be possible to do this in a very efficient way
>     - at least not more complicated or with  more  overhead  than  we
>     have now.

Agreed.  I fully understand the difference between porting and
just config'ing up a new image to be built.  The same set of
"well defined default configration parameters" can be had for
each and every one of the existing board/CPU combinations that
someone (we all) want to support.

> (2) adding customizations, add-on's, new features; again,  this  must
>     be easily possible with minimal overhead.

Again, agreed.  I think that there is great value in having a
way to leverage features and knowledge from _other_ ports as well.
Off the top of my head, configuring a PCI sub-system might be
a good example here.  Suppose that most platforms have one PCI bus.
And my platform has a second PCI bus.  I can make the notion of
a second PCI bus dependent on my particular board symbol in the
configuration files.  Later, a new system that also supports two
PCI buses becomes available.  All they have to do to "add support
for the second PCI bus" is to make the config parts enabled based
on "my original board or their new board".  They leverage the
existing config immediately.  Maybe, they can even use the common
code in the PCI subsystem; but that would depend on deeper board
issues.

> (3) adding contributed code for other developers; I  do  this  in  my
>     free time, so it must be especially easy do to.

> (4) making sure the whole system is as clean and stable as  possible;
>     again  I  do this in my free time, and this is a very limited and
>     precious resource

Understood.


> I definitely don't want to have to add 25 new  files  with  meta-  or
> config data just to get my job done.

I don't think it will take that at all.  Maybe a couple 2 or 3?
 
> >From your 3-questions approach to system configuration  above  I  got
> goose bumps all over my neck - this is something I will not accept.

I appreciate your feedback.

Thanks,
jdl