[U-Boot] RFQ: Makefile cleanup

[Graeme Russ]

On Thu, Oct 7, 2010 at 7:16 AM, Albert ARIBAUD <albert.aribaud at 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