[U-Boot-Users] Configuration System

[U-Boot-Users] Configuration System

[Jon Loeliger]

Folks,

At the risk of opening a hot topic (again), I would like to
bring up the subject of using the Linux Kernel 2.5/2.6 kconfig
configuration mechanism.

I know that this topic has been discussed in the past, and
that there are some in favor and some opposed to the idea.
I also know that it won't be a clean-n-easy transition if
motion in that direction is started.

I have implemented build systems based on linux 2.5's kconfig
and believe that U-Boot would benefit from using such a
system as well.  I understand that there are some on the
list that "don't want to fix working code" as well. :-)

I am curious to know if others feel that this would be a
good direction for U-Boot, or if this is just a Bad Idea
that should be dropped immediately.

If there are others (Schurig? Schwebel?) that would like to
see this sort of configuration mechanism, and would like to
work on the side with me until we have something that is
clearly demonstrable to others (Hi Wolfgang! :-)), please
let me know.  I think it will take a bit of effort to get
to a point where a critical mass of infrastructure is in
place before the benefits of the mechanism will be seen.

Tread softly,
jdl

[U-Boot-Users] Configuration System

[Wolfgang Denk]

Dear Jon,

in message <1083273421.24127.170.camel@baz.sps.mot.com> you wrote:
> 
> At the risk of opening a hot topic (again), I would like to
> bring up the subject of using the Linux Kernel 2.5/2.6 kconfig
> configuration mechanism.

What exactly do you want  to  make  configurable?  And  how?  At  the
moment,  configuration is done in a couple of places, like Makefiles,
config.mk files included by Makefiles, {architecture,processor,board}
dependend header and source files, and linker scripts.

Which of these are you going to address?

If we just take the include/config/<board>.h files,  they  contain  a
lot  of  user  configurable  stuff (CONFIG_??? options), BSP specific
stuff (CFG_??? options), and private definitons added by the specific
board maintainer.

Which of these are you going to address?

> I know that this topic has been discussed in the past, and
> that there are some in favor and some opposed to the idea.
> I also know that it won't be a clean-n-easy transition if
> motion in that direction is started.

I think I have made myself clear what I think about this: i find  the
ide  very  interesting,  but  I  can  see  no way how to implement it
without making the code much harder to understand  and  to  maintain.
But I may be wrong. Please go on if you think you can provide patches
that  show  how  this  can  be  done  for all existing architectures,
processors and boards, without negative impact.
be

> system as well.  I understand that there are some on the
> list that "don't want to fix working code" as well. :-)

This is not the case. If there is an obvious improvement, it will  be
added. Of course there are different points of view: code maintainer,
regular developer and board maintainer, occasional user, etc.

One thing should be clear: there are certain things  that  require  a
really  intimate  knowledge  of the innards of the processor, and the
code. You must not expect that any configuration tool could enable an
uninformed user to - for example - port U-Boot to new hardware.  THIS
CANNOT BE DONE.

> If there are others (Schurig? Schwebel?) that would like to
> see this sort of configuration mechanism, and would like to
> work on the side with me until we have something that is
> clearly demonstrable to others (Hi Wolfgang! :-)), please

I'd rather see that development happen in the public.

> let me know.  I think it will take a bit of effort to get
> to a point where a critical mass of infrastructure is in
> place before the benefits of the mechanism will be seen.

I am really curious to see what you have in mind.

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
Our business is run on trust.  We trust you will pay in advance.

[U-Boot-Users] Configuration System

[Robert Schwebel]

Hi Jon, Hi Wolfgang, 

First of all, I would welcome such a project. 

On Fri, Apr 30, 2004 at 12:14:19AM +0200, Wolfgang Denk wrote:
> What exactly do you want  to  make  configurable?  And  how?  At  the
> moment,  configuration is done in a couple of places, like Makefiles,
> config.mk files included by Makefiles, {architecture,processor,board}
> dependend header and source files, and linker scripts.

Well, the idea of CFG vs. CONFIG variables does IMHO point into the
right direction. There are several things which could be changed by a
user (which needs to be a poweruser anyway, you cannot compare somebody
who works on bootloaders with occaional kernel compiling guys):

- baudrate
- bootdelay
- bootargs
- bootcmd
- cpu speed
- flash layout
- etc. 

> I think I have made myself clear what I think about this: i find  the
> ide  very  interesting,  but  I  can  see  no way how to implement it
> without making the code much harder to understand  and  to  maintain.

Hmm, what about this concept: first we leave everything as it is and add
the KConfig infrastructure. It can easily be done, I have done it in the
past and we can simply copy the stuff from PTXdist (which also uses
KConfig). The only thing that needs to be changed is the variable prefix
which is fixed to CONFIG_. Maybe UBOOT_. When this is done we could let
it generate another config.h file (invent a name here...) which will be
included by the BSPs which use the new mechanism. Everything will stay
as it is for the other boards and we can make some proof of concept
implementations for further review of the idea. 

> But I may be wrong. Please go on if you think you can provide patches
> that  show  how  this  can  be  done  for all existing architectures,
> processors and boards, without negative impact.

... which would not be necessary going that way. 

> One thing should be clear: there are certain things  that  require  a
> really  intimate  knowledge  of the innards of the processor, and the
> code. You must not expect that any configuration tool could enable an
> uninformed user to - for example - port U-Boot to new hardware.  THIS
> CANNOT BE DONE.

Sure. But on the other hand there are several things which are more
"configuration" than "porting". These parts should be clearly separated. 

> I'd rather see that development happen in the public.

We can make a patch, post it on the list (I can offer my old
u-boot-config web page as a temporary home) and review it that way. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Configuration System

[Sam Ravnborg]

On Fri, Apr 30, 2004 at 07:31:31AM +0200, Robert Schwebel wrote:
> Hmm, what about this concept: first we leave everything as it is and add
> the KConfig infrastructure. It can easily be done, I have done it in the
> past and we can simply copy the stuff from PTXdist (which also uses
> KConfig). The only thing that needs to be changed is the variable prefix
> which is fixed to CONFIG_. Maybe UBOOT_. When this is done we could let
> it generate another config.h file (invent a name here...) which will be
> included by the BSPs which use the new mechanism. Everything will stay
> as it is for the other boards and we can make some proof of concept
> implementations for further review of the idea. 

If you during this process could come up with a generic way to select
architecture/board changes to Kconfig could be backported to the kernel.

In the Linux kernel today we lack a good way to select individual boards,
the only mechanishm is the _defconfig hack where a default config
file is selected, scrapping all options previously used.
For U-boot I think it would be relevant to start out with
a konw good config for one board, shift to another baord, and continue
from there. Knowing that this would anyway invalidate 1/3 of the options.

With respect to selecting architecture it must be pretty genial,
otherwise the current scheme is preferable.

	Sam

[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <20040430150734.GB2216@mars.ravnborg.org> you wrote:
> 
> In the Linux kernel today we lack a good way to select individual boards,
> the only mechanishm is the _defconfig hack where a default config
> file is selected, scrapping all options previously used.

But this is an  excellent  way  to  get  a  known  to  work  standard
coinfiguration  for a certain board. If you modify it, you can always
save your customized config file to any place you likeand resume from
there by simply "cp <some_file> .config ; make oldconfig".

What exactly is the problem you are complaining about?

> For U-boot I think it would be relevant to start out with
> a konw good config for one board, shift to another baord, and continue
> from there. Knowing that this would anyway invalidate 1/3 of the options.
> 
> With respect to selecting architecture it must be pretty genial,
> otherwise the current scheme is preferable.

For me, the following topics are important:

* 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.
* effort needed to add a  port  to  a  new  architecture,  processor,
  and/or board
* continued reliable support of all existing boards
* build speed (I have to routinely run MAKEALL for _all_ boards,  and
  this takes much too much time already)

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
In general, they do what you want, unless you want consistency.
                                    - Larry Wall in the perl man page

[U-Boot-Users] Configuration System

[Sam Ravnborg]

On Fri, Apr 30, 2004 at 05:39:54PM +0200, Wolfgang Denk wrote:
> In message <20040430150734.GB2216@mars.ravnborg.org> you wrote:
> > 
> > In the Linux kernel today we lack a good way to select individual boards,
> > the only mechanishm is the _defconfig hack where a default config
> > file is selected, scrapping all options previously used.
> 
> But this is an  excellent  way  to  get  a  known  to  work  standard
> coinfiguration  for a certain board. If you modify it, you can always
> save your customized config file to any place you likeand resume from
> there by simply "cp <some_file> .config ; make oldconfig".
> 
> What exactly is the problem you are complaining about?
Just as simple as keeping a few generic options
(add -g, debug spinlocks, enable premept) but changing boards from
rpxcllf to rpxlite.

And at the same time have a good textual description availbale for
the board which I am going to select.

"This is a variant of the XXX board, with additional 2 Megs
of Falsh, and the Ethernet port moved from FCC1 to FCC2."

This is becoming off-topic so lets stop that until something is
ready for u-boot. Then we can take it in the right context.

> For me, the following topics are important:
> 
> * 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.

I will not say current .config in the kernel are 'readable' as such,
it's just a bunch of defines seperated by a few headlines.

> * effort needed to add a  port  to  a  new  architecture,  processor,
>   and/or board
> * continued reliable support of all existing boards
> * build speed (I have to routinely run MAKEALL for _all_ boards,  and
>   this takes much too much time already)

	Sam

[U-Boot-Users] Configuration System

[Jon Loeliger]

On Fri, 2004-04-30 at 10:39, Wolfgang Denk wrote:
> > With respect to selecting architecture it must be pretty genial,
> > otherwise the current scheme is preferable.

I confess, I am not sure what constitutes "genial" here.

[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <20040430160019.GA2417@mars.ravnborg.org> you wrote:
>
> > * 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.
> 
> I will not say current .config in the kernel are 'readable' as such,
> it's just a bunch of defines seperated by a few headlines.

We are not discussing Linux here. But I agree that the  LInux  config
files is not what I'm dreaming of.

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
"Why waste negative entropy on comments, when you could use the  same
entropy to create bugs instead?"                        - Steve Elias

[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <1083341111.5420.15.camel@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.

[U-Boot-Users] Configuration System

[Sam Ravnborg]

On Fri, Apr 30, 2004 at 11:05:11AM -0500, Jon Loeliger wrote:
> On Fri, 2004-04-30 at 10:39, Wolfgang Denk wrote:
> > > With respect to selecting architecture it must be pretty genial,
> > > otherwise the current scheme is preferable.
> 
> 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.

It is better not asking less obvious questions.
So when I know I have board XXX why should I then select CPU and
CPU family.
On the other hand knowing that I want an ARM, then I expect to see a
list of available boards. Did I only select ARM9, again a even
smaller set of boards.

Maybe this was what you had in mind already - my point is that it
should be intuitive and simple. Simple from both a usage and
implementation point of view.

But I see all this as something that can come later, the better
approach is to start out small and incremental add more.

	Sam

[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

[U-Boot-Users] Configuration System

[Wolfgang Denk]

In message <1083363889.5691.363.camel@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.

[U-Boot-Users] [Newbie help] Motorola Board with GT64260

[Wolfgang Denk]

In message <Pine.LNX.4.58.0405031301060.654@corpster2> you wrote:
> 
> I'd really like an overview what I would need to port U-Boot to the
> Motorola MVME5500.

See section "U-Boot Porting Guide" in the README.

> I've seen in the source, that there's support for an evaluation board
> featuring this controller - EVB64260. The CPU seems to be supported as
> well by the 74xx_7xx, as far as I can see.

Correct.

> But I do need some starting points of how to know which code to adapt,
> how to rewire the existing code, which data to supply to make it
> correspond to my setup.

Well, even if you cannot implement the  function  no_more_time()  the
rest  of  the "U-Boot Porting Guide" still applies. Follow it step by
step.

BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot
to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)


Maybe we should start a "black list"  of  companies  who  don't  give
their patches back to the public source tree.


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
Remember that Beethoven wrote his first symphony in C ...

[U-Boot-Users] [Newbie help] Motorola Board with GT64260

[Mike McCullough]

At 12:45 PM 5/2/2004 +0200, Wolfgang Denk wrote:
>In message <Pine.LNX.4.58.0405031301060.654@corpster2> you wrote:
> >
> > I'd really like an overview what I would need to port U-Boot to the
> > Motorola MVME5500.
>
>See section "U-Boot Porting Guide" in the README.
>
> > I've seen in the source, that there's support for an evaluation board
> > featuring this controller - EVB64260. The CPU seems to be supported as
> > well by the 74xx_7xx, as far as I can see.
>
>Correct.
>
> > But I do need some starting points of how to know which code to adapt,
> > how to rewire the existing code, which data to supply to make it
> > correspond to my setup.
>
>Well, even if you cannot implement the  function  no_more_time()  the
>rest  of  the "U-Boot Porting Guide" still applies. Follow it step by
>step.
>
>BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot
>to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)

Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as 
we used the onboard MOTload software instead. Since MOTLoad worked just 
fine for us (once we figured it out) we didn't do the U-Boot port.

Sorry.


>Maybe we should start a "black list"  of  companies  who  don't  give
>their patches back to the public source tree.

Well, everything that we list on our Web site is freely available. You just 
have to do the same amount of hunting (and integration!) that MCC did.

I'm not fond of black-listing myself. Isn't that what big companies do??


>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
>Remember that Beethoven wrote his first symphony in C ...

**********************************************************
Mike McCullough                    MCC Systems, Inc.
President and CEO                  9 Cheshire Court
                                    Londonderry, NH 03053

mike at mccengineering.com            Tel:  603-537-9593
                                    Fax:  831-309-3472

**********************************************************
        Embedded Training        Development Tools
        Embedded Consulting      Custom Support Programs
**********************************************************

[U-Boot-Users] [Newbie help] Motorola Board with GT64260

[Oliver Korpilla]

Mike McCullough wrote:
>>
>> BTW: MCC Systems sells a "Linux SDK" which includes a port of U-Boot
>> to the MVME5500 board (see http://www.mccengineering.com/linuxsdks.htm)
> 
> 
> Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board 
> as we used the onboard MOTload software instead. Since MOTLoad worked 
> just fine for us (once we figured it out) we didn't do the U-Boot port.
> 

MotLoad actually netboots fine, but AFAIK it doesn't boot from flash (a 
capability I already have gladly exploited with the MVME2100 and the 
PPCbug). While it seems that a lot of setups often seem to be perfectly 
ok with a netboot (which seems to be very popular with VxWorks as well), 
for my setup a flash boot setup would really be the better choice - 
especially since on the MVME5500 flash is an abundant resource: 32-40MB 
are more than enough for a really nice root filesystem, don't you think? 
(I've not even ran out of the 4MB on the MVME2100 by now - thanks, 
uClibc and BusyBox!!!)

>> Maybe we should start a "black list"  of  companies  who  don't  give
>> their patches back to the public source tree.
> 
> Well, everything that we list on our Web site is freely available. You 
> just have to do the same amount of hunting (and integration!) that MCC did.
> 
> I'm not fond of black-listing myself. Isn't that what big companies do??
> 

Well, as long as the Linux vendors either hide their Linux kernels, or 
release only trimmed down versions of them (and no patchset), I guess 
the bootloader is not the worst problem - ok, ok, of course to people on 
this list this is actually an issue at heart!! But with all the closed 
mailing lists, and proprietary patchsets for customers only, open-source 
projects seem to be pretty much to be on the exploited side of the deal 
to me. :(

This is of course a general comment, and not about your special SDK 
vendor, which I have no experience with yet!

Thanks, and with kind regards,
Oliver Korpilla

[U-Boot-Users] [Newbie help] Motorola Board with GT64260

[Wolfgang Denk]

In message <5.1.0.14.2.20040502213935.0129c038@pop3.ttlc.net> you wrote:
>
> Actually, MCC does NOT have a port of U-boot to the Motorola 5500 board as 
> we used the onboard MOTload software instead. Since MOTLoad worked just 
> fine for us (once we figured it out) we didn't do the U-Boot port.

You're right. I didn't read the page carefully enough. Sorry for  the
confusion.

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
Pig: An animal (Porcus omnivorous) closely allied to the  human  race
by  the splendor and vivacity of its appetite, which, however, is in-
ferior in scope, for it balks at pig.                - Ambrose Bierce

[U-Boot-Users] Configuration System

[Brian Waite]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 30 April 2004 07:19 pm, Wolfgang Denk wrote:
> > > 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.
>
First, let me say I don't find the configurator that we are talking about all 
the helpful to my work, but I think I might have a solution that will reduce 
the maintainability. So what I was thinking about was using the maintainers 
file along with a configurator script in the tools directory. The 
configurator would be all the smarts. It would read the MAINTAINERS file,  
which has the bits in a well-defined structure, and generate the views with 
some type of filtering. So you could say "Show me all boards supporting CPU 
xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of 
the configurator is "make <configuration>"

Here are the pros and cons I see to this:

PROS: 
* The only new files are specificaly for the configurator and only need be 
modified to fix the configurator.
* Only the people interested in the system need to know about it.
* Automatically updated with each supported board.
* Minimal added work for Wolfgang.
* It can be extracted from the tree and maintained on the side until Wolfgang 
has the time to review and appove it.
* No one other then the interested parties has to do anything other than add 
their board to the MAINTAINERS list to work in u-boot.
* It does not preclude the make <configuration> well known system.
* Many others I am sure :)

CONS:
* More files in the u-boot tree.
* The configurator itself becomes somewhat complex.
* Many others I am sure :)

Jon, Wolfgang what are your thoughts on a system like this? 

Thanks
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAlieVmxLCz0u+Ko8RAtc2AJ9kwRymVMYLSTs09ENX7OZBBQOGuACfeRM9
IEsWwBilha9w46iUmnqrURw=
=7yQG
-----END PGP SIGNATURE-----

[U-Boot-Users] [Newbie help] Motorola Board with GT64260

[Oliver Korpilla]

Hello!

I'd really like an overview what I would need to port U-Boot to the
Motorola MVME5500.

I'd greatly appreciate any kind of help for a newbie anyone on this
list could muster.

This is a student's project - I must tell upfront, that I cannot "hire a
guru" as stated in the README, and I'm still hard-pressed for time.

The interesting features for the boot-loader port are the Motorla 7455 CPU
and the Marvell GT64260B system controller.

I've seen in the source, that there's support for an evaluation board
featuring this controller - EVB64260. The CPU seems to be supported as
well by the 74xx_7xx, as far as I can see.

So there's some kind of support for the CPU, the controller, the
integrated serial lines (controller) and ethernet (controller). Basically
all in this revolves around the system controller from Marvell.

I need a decent boot-loader that can boot Linux from flash (a capability
that seems to be lacking from MotLoad, AFAIK), and I'm willing to port it,
if I can reasonably do so, and I'm willing to give back all changes.

But I do need some starting points of how to know which code to adapt,
how to rewire the existing code, which data to supply to make it
correspond to my setup.

Thanks in advance,
Oliver Korpilla

[U-Boot-Users] Configuration System

[Wolfgang Denk]

Dear Brian,

in message <200405030705.57724.waite@skycomputers.com> you wrote:
> 
> First, let me say I don't find the configurator that we are talking about all 
> the helpful to my work, but I think I might have a solution that will reduce 
> the maintainability. So what I was thinking about was using the maintainers 

Ummm... Do you really mean what I'm reading here?

If it's not helpful, and reduces maintainability,  then  what  is  it
good for at all?

> file along with a configurator script in the tools directory. The 
> configurator would be all the smarts. It would read the MAINTAINERS file, 
> which has the bits in a well-defined structure, and generate the views with 
> some type of filtering. So you could say "Show me all boards supporting CPU 
> xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of 
> the configurator is "make <configuration>"

What should this be good for?

Normally, the user has a board on  his  desk,  which  is  labeled  as
"foo",  and all he needs to know is that the board name "foo" will be
supported by either "make foo_config; make all" or simply by "MAKEALL
foo".

If you are looking for similar boards while porting  to  some  custom
hardware,  just scanning the CPU types does not help at all. You will
need a lot of other parameters like memory map, RAM  and  flash  chip
types,  bus width, flash sector layout, where to put the environment,
which commands shall be supported, etc. etc.

> PROS: 
> * The only new files are specificaly for the configurator and only need be 
> modified to fix the configurator.
> * Only the people interested in the system need to know about it.
> * Automatically updated with each supported board.

Assuming somebody adds the relevant entries to the MAINTAINERS  file.
This is nothing you can rely on.

> * Minimal added work for Wolfgang.
> * It can be extracted from the tree and maintained on the side until Wolfgang 
> has the time to review and appove it.
> * No one other then the interested parties has to do anything other than add 
> their board to the MAINTAINERS list to work in u-boot.
> * It does not preclude the make <configuration> well known system.
> * Many others I am sure :)
> 
> CONS:
> * More files in the u-boot tree.

Not a real problem.

> * The configurator itself becomes somewhat complex.
> * Many others I am sure :)

One other: I see zero advantage.

> Jon, Wolfgang what are your thoughts on a system like this? 

Either I don't understand at all what you have in mind,  or  we  have
very,  very  different  goals  --  "reducing maintainability" is most
definitely not on my wish list ;-)

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
Der Dativ ist dem Genitiv sein Tod.