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

[Wolfgang Denk]

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