[U-Boot-Users] Configuration System
wd at denx.de
Fri Apr 30 18:31:07 CEST 2004
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
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
(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
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.
More information about the U-Boot