[U-Boot-Users] [PATCH] lkc support for U-Boot
wd at denx.de
Wed Nov 6 18:50:02 CET 2002
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>
> 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
> 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)
> #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
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.
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
More information about the U-Boot