[U-Boot-Users] [PATCH] lkc support for U-Boot
h.schurig at mn-logistik.de
Thu Nov 7 08:23:59 CET 2002
> 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)
bool "Include long help texts"
default n if ARCH_VERYSMALLBOARD
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
int "Strangeness of this feature"
and in boards/idppxa/idppxa.c you can then simply have
printf("My strangeness is %d\n", CONFIG_IDPPXA_STRANGE_FEATURE);
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
61191 Rosbach v.d.Höhe
Tel: 06003/9141-0 Fax: 06003/9141-49
More information about the U-Boot