[U-Boot-Users] [PATCH] lkc support for U-Boot
wd at denx.de
Thu Nov 7 11:03:07 CET 2002
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
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
> 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
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