public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Robert Schwebel <robert@schwebel.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Configuration System
Date: Fri, 30 Apr 2004 07:31:31 +0200	[thread overview]
Message-ID: <20040430053131.GF32432@pengutronix.de> (raw)
In-Reply-To: <20040429221424.93CFEC109F@atlas.denx.de>

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

  reply	other threads:[~2004-04-30  5:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-29 21:17 [U-Boot-Users] Configuration System Jon Loeliger
2004-04-29 22:14 ` Wolfgang Denk
2004-04-30  5:31   ` Robert Schwebel [this message]
2004-04-30 15:07     ` Sam Ravnborg
2004-04-30 15:39       ` Wolfgang Denk
2004-04-30 16:00         ` Sam Ravnborg
2004-04-30 16:18           ` Wolfgang Denk
2004-04-30 16:05         ` Jon Loeliger
2004-04-30 16:31           ` Wolfgang Denk
2004-04-30 22:24             ` Jon Loeliger
2004-04-30 23:19               ` Wolfgang Denk
2004-05-03 11:05                 ` Brian Waite
2004-05-03 20:12                   ` Wolfgang Denk
2004-04-30 21:46           ` Sam Ravnborg
2004-05-03 11:18         ` [U-Boot-Users] [Newbie help] Motorola Board with GT64260 Oliver Korpilla
2004-05-02 10:45           ` Wolfgang Denk
2004-05-03  1:46             ` Mike McCullough
2004-05-03  9:46               ` Oliver Korpilla
2004-05-03 10:23               ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040430053131.GF32432@pengutronix.de \
    --to=robert@schwebel.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox