On Thu, Oct 7, 2010 at 7:16 AM, Albert ARIBAUD <albert.arib...@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=0xFF000000 > > Will 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot