Re: [U-Boot-Users] [PATCH] lkc support for U-Boot
Robert Schwebel robert@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
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
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
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
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,
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
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.
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
In message 200211061403.16141.h.schurig@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
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.
In message 200211070823.59506.h.schurig@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
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
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
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
In message 200211071011.59506.h.schurig@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
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
In message 200211071311.33605.h.schurig@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
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
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
Jehova, Jehova! =:^)
Stay cool.
Or phrase it Jahwe Zebaoth, Jahwe Zebaoth !
(that's the name God that stands for "Herr der himmlichen Heerscharen").
Wolfgang is guarding CVS ... althought I think different on this matter, I can accept this (given my amount of diffs ...), so I suggested a partial CVS access for a test of lkc only. I don't want prod him into giving general access. :-)
In message 200211071719.39147.h.schurig@mn-logistik.de you wrote:
Wolfgang is guarding CVS ... althought I think different on this matter, I can accept this (given my amount of diffs ...), so I suggested a partial CVS access for a test of lkc only. I don't want prod him into giving general access. :-)
Thanks. The problem is, I don't have actual access to the CVS repository on SF. I can enter a login ID as "developer" which means unlimited access, but that's all. And I hesitate to do that.
Also, I'm not sure a branch will do us much good. Given the number of pending changes I have in the queue I am pretty sure that it will be a _lot_ of work to merge the branch back.
Best regards,
Wolfgang Denk
In message 200211061235.13992.h.schurig@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
participants (4)
-
Holger Schurig -
Marius Gröger -
Robert Schwebel -
Wolfgang Denk