[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <1083363889.5691.363.camel at gleep.sps.mot.com> you wrote:
>
> 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.

No. Once you selected a _board_configuration_, ALL  these  parameters
are  fix.  If some boards come with several types of precessor, there
will be several board configurations. For example, check the list  of
existent TQM8xxL or TQM82xx board configurations.

> > At this stage, all you need to select is the board type.
> 
> But that is not good enough to be uniquely identifying yet.

Yes, it is. A board configuration defines the whole configuration  of
a board. Everything. No other parameters are needed.

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

Here the board configuration name is "cogent_mpc8xx" - and it selects
ALL required parameters. No other questions are necessary.

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

So you created a new board configuration. That's all.

And not to forget: your situation is one case in maybe a  hundred  or
so.  It  is  not  any  significant  percentage of situations you will
encounter when porting U-Boot.

> > "enforcing bad combinations"??? You must be joking.
> 
> I think I misspoke myself here.  My real point was that it

A Freudian slip?

> can be used to disallow bad combinations by explicitly
> capturing supported configurations.  Maybe I am being naive

Ummm... With the current system, no "bad combinations"  are  possible
right from the beginning. So where is the improvement?

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

This is your opinion. Our customers _do_ want it this way. They  say:
all  I  want  to know is the name of the configuration to chose. If I
have a TQM823L module I care a shit which processor this is,  I  just
want a running system.

> 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 wish it were that way. I think it ain't so.

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

But there is no such set of default  configuration  parameters  which
applies  to  more  than  one  board.  Just  look  at the selection of
supported commands - search how many  board  configurations  use  the
same set of commands.

> a good example here.  Suppose that most platforms have one PCI bus.

Wrong. Most platforms have no PCI at all. And no USB, nor PCMCIA, nor
CompactFlash, nor NAND flash. Butt some do ;-)

> 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

Thsi is a dream. First, they have to study the  hardware.  Than  they
have  to  understand the implications on the software. Then they have
to analyze the existing code. And in 99% of all cases they will  find
that  their  board  with  2 PCI busses is sufficiently different from
yours that they cannot reuse the code without changing it.

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

Your system is standing on the head. First you got to  get  the  code
right.  wIthout  doing  this all attempts to configure something will
fail.

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

Ummm... is you add only 3 files, you will have at least  one  monster
of  a  config  file  which  nobody  will  be  able  to understand nor
maintain.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The complexity of software is an essential property, not an  acciden-
tal  one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence.    - Fred Brooks, Jr.