[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <1083341111.5420.15.camel at gleep.sps.mot.com> you wrote:
> 
> I confess, I am not sure what constitutes "genial" here.
> From the high-level perspective, my current notion is to
> roughly ask three basic questions at the onset:
> 
>     - What CPU Architecture is being targeted?
>       (ARM, MIPS, PPC, Xscale, etc)
> 
>     - Given the CPU Architecture is now known, which processor
>       is being selected?  This might involve an intermediate step
>       in which a "family" of processors might be selected to help
>       narrow the selection.  For example, maybe it is OK to just
>       offer the 7 XSCALE processors directly (ixdp425, xm250, etc),
>       while the prolific PPC might do a PPC4xx, 82xx, 85xx, etc
>       selection for family in order to get to a specific cpu
>       such as the mpc8540.
> 
>     - What board is being targeted?
>       (ADS, CDS, IceCube, etc)
>       Basically anything in u-boot/boards that is appropriate
>       for the given target CPU Arch or specific CPU.

Isn't that 300% redundand already?

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?

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

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

> One component that would get encoded into the config files would
> be, for example, the knowledge of what CPUs are supported on
> which boards.

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


> > * clearness and readability of the resulting  code  /  config  files;
> >   this  includes  having  all  relevant  information  for  one  board
> >   concentrated in very few well known files.
> 
> Could I ask you to clarify this point a bit, please?  I'd like to
> understand what your concern here is.  In particular, I think that
> there is a bit more of a "cross product of features" available and
> that some degree of horizontal slicing rather than vertical slicing
> of the options might be needed.  In that way, it is not so much tied
> to a particular board.

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.

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

(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


At the moment, you can add basic support for a new board within  half
an  hour  if  you  know the code as we do and if you manage to find a
reasonable similar board as model. OK, to get it  ready  for  release
will usually take a few more days, but that's it.

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