[U-Boot-Users] [PATCH] lkc support for U-Boot

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Marius Gröger
Robert Schwebel <robert at schwebel.de> schrieb am 06.11.02 10:36:34:
> Comments?

Though I tend to be rather conservative with these sorts
of enhancements, I hope I will get around to take a look
at your stuff.

But _please_ promise not to add CML2 support!! This is
only a boot-loader, after all. ;-)

Regards,
Marius.

________________________________________________________________
Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr!
Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13





Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Wed, Nov 06, 2002 at 11:29:09AM +0100, Marius Gr?ger wrote:
> But _please_ promise not to add CML2 support!! This is
> only a boot-loader, after all. ;-)

CML2 is dead. The config system is the same that was just merged into
Linux-2.5.46, including the new configuration language.

I'm currently porting the ruleset of another project, and it seems to be
a _great_ progress over the old config language.

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
In reply to this post by Marius Gröger
> But _please_ promise not to add CML2 support!! This is
> only a boot-loader, after all. ;-)

I share your options on CML2. But that was the language of the older kconfig
system that never made it into the Linux kernel. Here we talk about Roman
Zippels config (and config language) that is now in the Linux 2.5.x tree.


So, it looks like that I get some feedback. I guess I will incorporate
Robert's changes to my code and get one target compilable, e.g. the lubbock
one. That would bring it nearer CVS integration (althought I guess that there
is still some work left).


One thing that I'd love is

perl -pi -e 's/CFG_/CONFIG_/g' * */* */*/*

because the config system can only deal with variables that start with
CONFIG_. That would break the difference between config options and config
settings. But I guess we can differentiate between them by using the menu
structure. And, the current differentiation is not correct anyway. The README
file says:

* Configuration _SETTINGS_:
  These depend on the hardware etc. and should not be meddled with if
  you don't know what you're doing; they have names beginning with
  "CFG_".

But it has nothing to do with hardware if I select CFG_CMD_ASKENV or not. Or
if I want CFG_LONGHELP or not. That is true for many CFG_ variables, so I
guess not much harm is done in renaming them.

Greetings, Holger




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Wed, Nov 06, 2002 at 12:35:13PM +0100, Holger Schurig wrote:
> So, it looks like that I get some feedback. I guess I will incorporate
> Robert's changes to my code and get one target compilable, e.g. the lubbock
> one. That would bring it nearer CVS integration (althought I guess that there
> is still some work left).

As my patch is against current CVS and has working menuconfig support
you will probably better start with it.

> One thing that I'd love is
>
> perl -pi -e 's/CFG_/CONFIG_/g' * */* */*/*
>
> because the config system can only deal with variables that start with
> CONFIG_.

I think the overall design is quite right - things that can be
configured by the "user" should be CONFIG_, internal definitions CFG_.
IMHO if this is not correct in every implementation it is a bug.

We shouldn't start porting architecture over to the new system before
Wolfgang has given his ok.

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
> configured by the "user" should be CONFIG_, internal definitions CFG_.

But the bootdelay is NOT an internal definition. And many other CFG_ aren't
internal, too.   Okay, I can see that CFG_CMD_ are internal definitions and
that only CONFIG_COMMANDS is user definiable. However, lkc will not easily
handle this.

This is because LKC can

* only handle config vars that start with CONFIG_
* has only types like int, string, bool, but not bitmask

and CONFIG_COMMANDS is a bitmask. Of course one could put

define COMMAND
  int "Which commands to allow"
  default <some value>
  help
     This is really a bitmask. Add the following values to get your result:
     1   for bdinfo
     2   for loads
     4   for loadb

but that would be a step backwords. I'd rather have it like this

menu "Command selection"

define CMD_BDI
  bool "bdinfo command (board info)
  default y

define CMD_LOADS
  bool "loads command (load srec file)
  default n

define CMD_LOADB
  bool "loadb command (load binary file)
  default n

endmenu

and so on.



If we want to use lkc for this, we have to transfer files like cmd_elf.c from

#if (CONFIG_COMMANDS & CFG_CMD_ELF)

into

#ifdef CONFIG_CMD_ELF




Therefore, I assume that lkc is intrusive. Either change the whole u-boot or
nothing at all. As in the linux kernel: it's not changed totally,

--
MN-Logistik GmbH         http://www.mn-logistik.de
Holger Schurig
Dieselstr. 18
61191 Rosbach v.d.H?he
Tel: 06003/9141-0        Fax: 06003/9141-49




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Wed, Nov 06, 2002 at 02:03:16PM +0100, Holger Schurig wrote:
> But the bootdelay is NOT an internal definition.

Then I suppose it is incorrect to make it a CONFIG_ variable.

> However, lkc will not easily handle this.

It will - but things have to be ported. The old system had a possible
configuration system in mind, but that doesn't mean that the old config
files can be used without changes...

> This is because LKC can
>
> * only handle config vars that start with CONFIG_
> * has only types like int, string, bool, but not bitmask
 
I see no problem with that.

> I'd rather have it like this
>
> menu "Command selection"
>
> define CMD_BDI
>   bool "bdinfo command (board info)
>   default y
>
> define CMD_LOADS
>   bool "loads command (load srec file)
>   default n
>
> define CMD_LOADB
>   bool "loadb command (load binary file)
>   default n
>
> endmenu
>
> and so on.

What's the problem with this variant?

> If we want to use lkc for this, we have to transfer files like cmd_elf.c from
>
> #if (CONFIG_COMMANDS & CFG_CMD_ELF)
>
> into
>
> #ifdef CONFIG_CMD_ELF

The files have to be adapted - I don't understand the problem? As long
as not all board packages are ported just let the old ones use the same
configration files as before and let the new ones use .config.

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
> > This is because LKC can
> >
> > * only handle config vars that start with CONFIG_
> > * has only types like int, string, bool, but not bitmask
>
> I see no problem with that.

But I.

CFG_BOOTDELAY would not be handle-able by "make menuconfig" as long as it
stays at CFG_BOOTDELAY. For me it doesn't make sense to select your hardware
platform by a menu, but to edit files for things like bootdelay.

If you want to handle anything in make menuconfig, you have to name it
CONFIG_*, so it has to be named CONFIG_BOOTDELAY.

The same with some other CFG_ variables.

--
MN-Logistik GmbH         http://www.mn-logistik.de
Holger Schurig
Dieselstr. 18
61191 Rosbach v.d.H?he
Tel: 06003/9141-0        Fax: 06003/9141-49




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Wed, Nov 06, 2002 at 04:02:58PM +0100, Holger Schurig wrote:
> CFG_BOOTDELAY would not be handle-able by "make menuconfig" as long as it
> stays at CFG_BOOTDELAY. For me it doesn't make sense to select your hardware
> platform by a menu, but to edit files for things like bootdelay.
>
> If you want to handle anything in make menuconfig, you have to name it
> CONFIG_*, so it has to be named CONFIG_BOOTDELAY.

Yep, if BOOTDELAY is CFG it is a bug. For my boards it already _is_
CONFIG_BOOTDELAY.

Robert

--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Wolfgang Denk
In reply to this post by Holger Schurig
In message <200211061235.13992.h.schurig at mn-logistik.de> you wrote:
>
> One thing that I'd love is
>
> perl -pi -e 's/CFG_/CONFIG_/g' * */* */*/*

I object against such a global renaming.  At  least  we  should  then
think  about  a new way to make a difference between options that are
user-selectable and such ones where you have to exactly know what you
are doing.

> But it has nothing to do with hardware if I select CFG_CMD_ASKENV or not. Or
> if I want CFG_LONGHELP or not. That is true for many CFG_ variables, so I
> guess not much harm is done in renaming them.

You are right - many variable names a re poorly chosen,  disregarding
the original intent of the naming. OTOH options like CFG_LONGHELP may
have  to  do  with  hardware  -  for  example, if there is a hardware
restriction in the maximum size of PPCBoot (like my often quoted  128
kB  EPROM  device)  then  you  cannot use long help, because it would
result in a too big a memory footprint.

I'd rather have such bad names fixed.

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
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Wolfgang Denk
In reply to this post by Holger Schurig
In message <200211061403.16141.h.schurig at mn-logistik.de> you wrote:
>
> But the bootdelay is NOT an internal definition. And many other CFG_ aren't
> internal, too.   Okay, I can see that CFG_CMD_ are internal definitions and
> that only CONFIG_COMMANDS is user definiable. However, lkc will not easily
> handle this.

Ummm... what about extending lkc then?

> This is because LKC can
>
> * only handle config vars that start with CONFIG_
> * has only types like int, string, bool, but not bitmask

This is a serious rrestriction.

> and CONFIG_COMMANDS is a bitmask. Of course one could put
>
> define COMMAND
>   int "Which commands to allow"
>   default <some value>
>   help
>      This is really a bitmask. Add the following values to get your result:
>      1   for bdinfo
>      2   for loads
>      4   for loadb
>
> but that would be a step backwords. I'd rather have it like this

Such an implementation would be just unacceptable. Also, are you sure
that it performs a 64 bit addition?

> menu "Command selection"
>
> define CMD_BDI
>   bool "bdinfo command (board info)
>   default y
>
> define CMD_LOADS
>   bool "loads command (load srec file)
>   default n
>
> define CMD_LOADB
>   bool "loadb command (load binary file)
>   default n
>
> endmenu
>
> and so on.

Does not work. There  are  some  board  which  want  "everything  but
features A, B and C".

> If we want to use lkc for this, we have to transfer files like cmd_elf.c from
>
> #if (CONFIG_COMMANDS & CFG_CMD_ELF)
>
> into
>
> #ifdef CONFIG_CMD_ELF

> Therefore, I assume that lkc is intrusive. Either change the whole u-boot or
> nothing at all. As in the linux kernel: it's not changed totally,

I don't object againdt lkc in general. In fact I'd like to see a  way
for  easier  configuration. But then, when you check just 20 randomly
chosen board config files, you will find such a wide range of private
extensions, which are strictly "local" (i. e. of  interest  only  for
that specific board), that I think it would be extremely difficult to
maintain this under lkc. And combining a lkc created config file with
a  second,  board private config file, seems contraproductivee to me.
But adding all these things to lkc will cause a level  of  complexity
for  the  resulting  lkc  input  that will be probably much harder to
maintain than the current header files.

To make the long story short:  I  don't  see  much  chance  for  real
improvement.

Also there are two levels of things,  requiring  different  level  of
expertise: simple default settings like console baudrate, which don't
require  much  intelligence,  and hardware specific stull like memory
timings  or  register  initial  values  which  require  an   in-depth
understanding of the hardware.

It is probably not a good idea to mix  both  in  an  interface  which
might create the issusion that Johny Luser can change everything.

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
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
> OTOH options like CFG_LONGHELP may have  to  do  with  hardware  -
> for  example, if there is a hardware restriction in the maximum size of
> PPCBoot (like my often quoted  128 kB  EPROM  device)

simple enought:

config LONGHELP
  bool "Include long help texts"
  default n if ARCH_VERYSMALLBOARD
  help
    This add approx XX kB to U-Boot, so please be sure that the resulting
    binary still fit's into your EEPROM or FLASH.



> But then, when you check just 20 randomly
> chosen board config files, you will find such a wide range of private
> extensions, which are strictly "local" (i. e. of  interest  only  for
> that specific board), that I think it would be extremely difficult to
> maintain this under lkc.

No, not really.

Currently I have one bigger u-boot/config.in file, defining all the basic
stuff. This one include u-boot/boards/config.in which in turn can include any
board-specific u-boot/boards/<someboard>/config.in file --- or not.

So it is absolutely no problem to have in u-boot/boards/<someboard>/config.in
an entry like

config IDP_PXA_STRANGE_FEATURE
  depend ARCH_IDP_PXA
  int "Strangeness of this feature"
  default 5

and in boards/idppxa/idppxa.c you can then simply have

#ifdef CONFIG_IDP_PXA_STRANGE_FEATURE
  printf("My strangeness is %d\n", CONFIG_IDPPXA_STRANGE_FEATURE);
#endif

In this case it is quite clear that this feature is only for this one board.
When you do "make xconfig" or "make menuconfig" and you select another board,
you would not even see that this feature exists (because of the depend line).


> And combining a lkc created config file with
> a  second,  board private config file, seems contraproductivee to me.

Not for me. Look at the kernel or at OpenZaurus. Both of this systems are
build around lot's of config.in files in various directories. It's much
easier to maintain and understand this way.

--
MN-Logistik GmbH         http://www.mn-logistik.de
Holger Schurig
Dieselstr. 18
61191 Rosbach v.d.H?he
Tel: 06003/9141-0        Fax: 06003/9141-49




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Wolfgang Denk
In message <200211070823.59506.h.schurig at mn-logistik.de> you wrote:
>
> config LONGHELP
>   bool "Include long help texts"
>   default n if ARCH_VERYSMALLBOARD

Why are all these things named ARCH_*?

I think the we should have only  ARCH_PPC  and  ARCH_ARM.  The  other
things you mentioned so far are not architecture specific - they were
related to CPUs, boards, configurations, ...

>     This add approx XX kB to U-Boot, so please be sure that the resulting
>     binary still fit's into your EEPROM or FLASH.

Ummm... I see what you mean. I guess  I'd  have  to  see  a  complete
working example first.

> Currently I have one bigger u-boot/config.in file, defining all the basic
> stuff. This one include u-boot/boards/config.in which in turn can include any
> board-specific u-boot/boards/<someboard>/config.in file --- or not.
>
> So it is absolutely no problem to have in u-boot/boards/<someboard>/config.in
> an entry like

But that means that the configuration for one  board  is  distributed
over  3 (or more?) config.in files. It has certain advantages to have
it concentrated in one place...

> > And combining a lkc created config file with
> > a  second,  board private config file, seems contraproductivee to me.
>
> Not for me. Look at the kernel or at OpenZaurus. Both of this systems are
> build around lot's of config.in files in various directories. It's much
> easier to maintain and understand this way.

I disagree. It is much more complicated to find  all  config  options
relevant  to  once  specific  system,  and  requires  a  much  better
understanding  of  the  config  mechanism  to   add   a   new   board
configuration - correctly, that is.

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
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Thu, Nov 07, 2002 at 09:45:49AM +0100, Wolfgang Denk wrote:
> Ummm... I see what you mean. I guess  I'd  have  to  see  a  complete
> working example first.

I try to provide one for the CSB226 during the next days.  

> But that means that the configuration for one  board  is  distributed
> over  3 (or more?) config.in files. It has certain advantages to have
> it concentrated in one place...

The configuration for one board would exactly follow the structure the
sources have. CPU specific stuff would be configured in cpu/*/config.in,
the board specific stuff in boards/*/config.in. Sounds like a sane
concept to me.

> I disagree. It is much more complicated to find  all  config  options
> relevant  to  once  specific  system,  and  requires  a  much  better
> understanding  of  the  config  mechanism  to   add   a   new   board
> configuration - correctly, that is.

I think with a real life example we'll have a better base for
discussion.

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
In reply to this post by Wolfgang Denk
> Why are all these things named ARCH_*?

They don't have to.

But in the Linux kernel they are all called CONFIG_ARCH_<boardname>. At least
in the ARM tree, the one I'm familiar with:

#
# System Type
#
# CONFIG_ARCH_ANAKIN is not set
# CONFIG_ARCH_ARCA5K is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
CONFIG_ARCH_PXA=y
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_CAMELOT is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_MX1ADS is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_RISCSTATION is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_SHARK is not set

> > So it is absolutely no problem to have in
> > u-boot/boards/<someboard>/config.in an entry like
>
> But that means that the configuration for one  board  is  distributed
> over  3 (or more?) config.in files. It has certain advantages to have
> it concentrated in one place...

The actual configuration is in the .config file --- and can be in the
per-board directory as a def-config.

But what is configurable (the meta-configuration) info is distributed.
Ideally, in each directory where some *.C or *.H files implement features the
corresponding config.in file contains the meta-information of what the
feature does, how it is named, how it relates to other config infos.


> I disagree. It is much more complicated to find  all  config  options
> relevant  to  once  specific  system,  and  requires  a  much  better
> understanding  of  the  config  mechanism  to   add   a   new   board
> configuration - correctly, that is.

Now. The one that is responsible for a board, e.g. the maintainer of the PP405
board, once uses the menuconfig to set up all the options for this board.
Then he does a simple "cp .config board/pp405/def-config" and ask you to
check in this file.

If this board specifies a new command (e.g. CONFIG_PP405_TOGGLE_LED) then the
code for this command is in boards/pp405/cmd_toggle.c. And the sheer
existence of this new feature is also in boards/pp405/config.in. So the
things are near to each other.

If you, on the other side, make a new general command that is not hardware
related, then you add common/cmd_tetris.c, include/cmd_tetris.h, and in
common/config.in you add the command definition:

define CMD_TETRIS
  bool "tetris: ever played tetris over a serial line?"
  default "n"

If now our PP405 guy dows a checkout and

  cp boards/pp405/def-config .config
  make oldconfig

then he still has not the new command selected. But it would appear on his
make menuconfig/make xconfig screen to be selectable, clearly marked as
"tetris: ever played tetris over a serial line? (NEW)". He can then create a
new def-config if he wants to have this command on his platform. Or keep it
as is.

If you now do this using the current approach, then a maintainer for a board
would have to check from time to time the include/cmd_confdefs.h for new
things on the radar and would

In this case, the new command (cmd_tetris.c) and the definition of it's
existence etc is in the same directory. For me this sounds easy to maintain.

Greetings, Holger

--
MN-Logistik GmbH         http://www.mn-logistik.de
Holger Schurig
Dieselstr. 18
61191 Rosbach v.d.H?he
Tel: 06003/9141-0        Fax: 06003/9141-49




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Thu, Nov 07, 2002 at 10:11:59AM +0100, Holger Schurig wrote:

> If you, on the other side, make a new general command that is not hardware
> related, then you add common/cmd_tetris.c, include/cmd_tetris.h, and in
> common/config.in you add the command definition:
>
> define CMD_TETRIS
>   bool "tetris: ever played tetris over a serial line?"
>   default "n"
>
> If now our PP405 guy dows a checkout and
>
>   cp boards/pp405/def-config .config
>   make oldconfig
>
> then he still has not the new command selected. But it would appear on his
> make menuconfig/make xconfig screen to be selectable, clearly marked as
> "tetris: ever played tetris over a serial line? (NEW)".

Do you have a Tetris implementation for U-Boot? Would be a _great_
improvement :-)

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Wolfgang Denk
In reply to this post by Holger Schurig
In message <200211071011.59506.h.schurig at mn-logistik.de> you wrote:
> > Why are all these things named ARCH_*?
>
> They don't have to.

Then we should not do that.

> But in the Linux kernel they are all called CONFIG_ARCH_<boardname>. At least
> in the ARM tree, the one I'm familiar with:

Yes, I know, and never understood. Actually I consider  this  a  bug;
for  example, we support both the SMDK2400 and TRAB boards, which use
the same architecture and the same CPU (Samsunf s3c2400). 95% of  the
code  that  needs  to  be  #ifdef'ed  is CPU dependend, so I think we
should have a CONFIG_ARCH_S3C2400 plus either  a  CONFIG_SMDK2400  or
CONFIG_TRAB (or maybe that should be CONFIG_BOARD_SMDK2400) etc.

> #
> # System Type
> #
> # CONFIG_ARCH_ANAKIN is not set
> # CONFIG_ARCH_ARCA5K is not set
> # CONFIG_ARCH_CLPS7500 is not set
> # CONFIG_ARCH_CLPS711X is not set
> # CONFIG_ARCH_CO285 is not set
> CONFIG_ARCH_PXA=y
...

I know. This design is broken.

> The actual configuration is in the .config file --- and can be in the
> per-board directory as a def-config.
>
> But what is configurable (the meta-configuration) info is distributed.
> Ideally, in each directory where some *.C or *.H files implement features the
> corresponding config.in file contains the meta-information of what the
> feature does, how it is named, how it relates to other config infos.

Understood. Well, I have to admit that I will have  to  get  used  to
this idea.

> If you now do this using the current approach, then a maintainer for a board
> would have to check from time to time the include/cmd_confdefs.h for new
> things on the radar and would

Most boards use either a carefully  selcted  combinations  of  wanted
options,  or  a  selection  of  excluded  options,  so  this  happens
automagically.


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
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
> Understood. Well, I have to admit that I will have  to  get  used  to
> this idea.

Only if you plan to use lkc, after all.



By the way: yesterday I've got an idea on how it would be possible to have old
and new configuration available at the same time. Instead of

if (CONFIG_COMMANDS & CFG_CMD_ELF)

do

if (CONFIG_COMMANDS & CFG_CMD_ELF) || CONFIG_CMD_ELF




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Wolfgang Denk
In message <200211071311.33605.h.schurig at mn-logistik.de> you wrote:
> > Understood. Well, I have to admit that I will have  to  get  used  to
> > this idea.
>
> Only if you plan to use lkc, after all.

It would be silly to ignore a solution that might actually  bring  an
improvement.  But  I'd like to understand the benefits, and potential
problems first.

> By the way: yesterday I've got an idea on how it would be possible to have old
> and new configuration available at the same time. Instead of
>
> if (CONFIG_COMMANDS & CFG_CMD_ELF)
>
> do
>
> if (CONFIG_COMMANDS & CFG_CMD_ELF) || CONFIG_CMD_ELF

Urgh... I think, if we switch, we should switch completely.

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
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Holger Schurig
> Urgh... I think, if we switch, we should switch completely.

:-)

In this case I suggest the following:

- create a branch in the CVS or setup a different CVS tree

- those people that want to work on lkc should get write access, either
  with only access to this new tree or with the strict promise only to work
  in this branch

The reason is that some things will be rather intrusive. I, for example,
understand that you don't like the big s/CFG_/CONFIG_/ approach, but for some
stuff, e.g. s/CFG_BOOTDELAY/CONFIG_BOOTDELAY/ it would be helpful to do it
quick.

Of course one can do this without cvs, but then it's cumbersome if several
people work together (e.g. Roland did not catch modifcations I made). CVS is
just more, well, concurrent :-)

Greetings, Holger




Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] [PATCH] lkc support for U-Boot

Robert Schwebel-2
On Thu, Nov 07, 2002 at 02:05:11PM +0100, Holger Schurig wrote:
> - those people that want to work on lkc should get write access, either
                                                 ^^^^^^^^^^^^^^^^
Jehova, Jehova! =:^)

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

    Visit us at the SPS/IPC/Drives 2002 in Nuernberg!
   Hall 5, Booth 154 +++ Please contact us for details.



12