On Thu, Oct 7, 2010 at 7:16 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Le 06/10/2010 21:54, Wolfgang Denk a écrit :
Hi,
I'm working on a few patches to get rid of the remaining scripting in the Makefile, i. e. to move the remaining board descriptions into board.cfg; this work makes use of Marek Vasut's patch to extend the mkconfig script so it can process an additional "options" field.
With this I can convert a large number of boards from the Makefile to boards.cfg - but I still have a problem with those that not only add settings to include/config.h, but that also add custom settings to some config.mk file, typically to adjust the TEXT_BASE setting, for example like this:
Makefile:
... @echo "TEXT_BASE = 0x01000000"> $(obj)board/amcc/acadia/config.tmp @echo "CONFIG_NAND_U_BOOT = y">> $(obj)include/config.mk ...board/amcc/acadia/config.mk:
... sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp ... ifndef TEXT_BASE TEXT_BASE = 0xFFF80000 endif ... ifdef CONFIG_NAND_U_BOOT ...The settings in include/config.h are visible in the Makefiles through the automatically generated include/autoconf.mk; however, with the mechanism above I cannot generate a "TEXT_BASE" setting as currently all options automatically get prefixed with "CONFIG_".
Humble proposal: admit an options field of the form
boardname[:[cfgopt1[,cfgopt2...]][:<opt1>[,<opt2>]]I.e., have two sets of definitions, cfgopts and opts, separated by colons; each cfgopt or opt is of the form SYM or SYM=VAL. The cfgopt set gets the CONFIG_ prefix, the opt set does not.
Example:
TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x:TEXT_BASE=0xFF000000Will generate
#define CONFIG_MPC8260 1 #define CONFIG_200MHz #define CONFIG_L2_CACHE 1 #define CONFIG_BUSMODE_60x 1 #define TEXT_BASE 0xFF000000
Pros: you keep fine control on what's generated; you keep not-too-long lines in boards.cfg; you don't need to touch anything in the current code.
Cons: complexified the parsing of the boards.cfg options field.
Note that in my proposal I suggest that an options field can still only contain cfgopts, so that existing lines in boards.cfg will keep their current semantics.
I feel that boards.cfg defines configurations, and therfore each additional field is, by definition, a configuration option and should be prefixed with CONFIG_
I actually got really confused with TEXT_BASE and thought it was some kind of standard environment variable that ld magically used - it wasn't until I spent a day trolling through the makfile et al that I finally figurfed out that the linker script was 'made' and TEXT_BASE was just another define and I could add more to the parsing of the ld script. Having it as CONFIG_TEXT_BASE or CONFIG_SYS_TEXT_BASE would have alerted me straight up
So I vote for #2
A couple of other questions: - How do you un-define a CONFIG option via boards.cfg? - What happens when you try to re-define an option already in the board configuration file?
P.S. Here's a thought I ended up discarding: Each board could have a main config with all the common configuration values and a number of secondary includes (which include the primary) for each specific configuration. The entry in boards.cfg would select a specific config_xxx.h file
eg
boards.cfg: TQM8260 powerpc mpc8260 tqm8260 tqc - TQM8260_AB powerpc mpc8260 tqm8260 tqc -
/include/configs/TQM8260_AB.h:
#include "configs/TQM8260.h"
#define MPC8260 #define 200MHz #define L2_CACHE #define BUSMODE_60x