[U-Boot] RFQ: Makefile cleanup

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

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.

For example, a board entry could now look like this:

TQM8260_AB  powerpc  mpc8260  tqm8260  tqc  -  TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x

Read this as:

"make TQM8260_AB_config" will set up a build for the following board
definition:

	ARCH   = powerpc
	CPU    = mpc8260
	BOARD  = tqm8260
	VENDOR = tqc

The options field can contain multiple options: a board configuration
name, optionally followed by a colon (':') and a list of options,
which are separated by comma (','). In case there's a simple option
like 256M_U_BOOT, this expand to "#define CONFIG_MK_256M_U_BOOT 1" in
config.h . In case there's an assignment, like "RAM=8192", it expands
to "#define CONFIG_MK_RAM 8192" in config.h .

    Example:

        FOO:HAS_BAR,BAZ=64

    means:
        - the name of the board config file is include/configs/FOO.h
        - the generated file include/config.h will contain these
          lines:
    
                #define CONFIG_HAS_BAR 1
                #define CONFIG_BAZ  64
    
In our example above, include/config.h will contain the following
settings:

	#define CONFIG_MPC8260  1
	#define CONFIG_200MHz   1
	#define CONFIG_L2_CACHE 1
	#define CONFIG_BUSMODE_60x      1
	#define CONFIG_BOARDDIR board/tqc/tqm8260

So far, so good.


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_".

Now I see two approaches for a solution:

1) I stop prefixing options with "CONFIG_" and write the full
   variable names instead.

   pro: I have full controll over which definitions I generate,
        and I can handle it at a single, central location.

   con: The lines in boards.cfg, which often are more than long
        enough, will become even longer. Our example above would now
        become:

	TQM8260_AB  powerpc  mpc8260  tqm8260  tqc  -  TQM8260:CONFIG_MPC8260,CONFIG_200MHz,CONFIG_L2_CACHE,CONFIG_BUSMODE_60x

2) I accept the prefix, and generate a definition for
   CONFIG_SYS_TEXT_BASE.  In the config.mk file, I replace the
   "sinclude ... config.tmp" by something like this:

	ifdef CONFIG_SYS_TEXT_BASE
	TEXT_BASE = $(CONFIG_SYS_TEXT_BASE)
	endif


   pro: The lines in boards.cfg don't get too long.

   con: I have to adapt a number or board specific config.mk files
        (but I have to do this anyway to remove the then obsolete
        "sinclude" lines.


At the moment my preference goes with 2), but I would like to hear if
this approach seems acceptable to others as well.

Or eventually somebody has a really clever idea how to tackle this...


Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer

[U-Boot] RFQ: Makefile cleanup

[Albert ARIBAUD]

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.
>
> For example, a board entry could now look like this:
>
> TQM8260_AB  powerpc  mpc8260  tqm8260  tqc  -  TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x
>
> Read this as:
>
> "make TQM8260_AB_config" will set up a build for the following board
> definition:
>
> 	ARCH   = powerpc
> 	CPU    = mpc8260
> 	BOARD  = tqm8260
> 	VENDOR = tqc
>
> The options field can contain multiple options: a board configuration
> name, optionally followed by a colon (':') and a list of options,
> which are separated by comma (','). In case there's a simple option
> like 256M_U_BOOT, this expand to "#define CONFIG_MK_256M_U_BOOT 1" in
> config.h . In case there's an assignment, like "RAM=8192", it expands
> to "#define CONFIG_MK_RAM 8192" in config.h .
>
>      Example:
>
>          FOO:HAS_BAR,BAZ=64
>
>      means:
>          - the name of the board config file is include/configs/FOO.h
>          - the generated file include/config.h will contain these
>            lines:
>
>                  #define CONFIG_HAS_BAR 1
>                  #define CONFIG_BAZ  64
>
> In our example above, include/config.h will contain the following
> settings:
>
> 	#define CONFIG_MPC8260  1
> 	#define CONFIG_200MHz   1
> 	#define CONFIG_L2_CACHE 1
> 	#define CONFIG_BUSMODE_60x      1
> 	#define CONFIG_BOARDDIR board/tqc/tqm8260
>
> So far, so good.
>
>
> 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_".
>
> Now I see two approaches for a solution:
>
> 1) I stop prefixing options with "CONFIG_" and write the full
>     variable names instead.
>
>     pro: I have full controll over which definitions I generate,
>          and I can handle it at a single, central location.
>
>     con: The lines in boards.cfg, which often are more than long
>          enough, will become even longer. Our example above would now
>          become:
>
> 	TQM8260_AB  powerpc  mpc8260  tqm8260  tqc  -  TQM8260:CONFIG_MPC8260,CONFIG_200MHz,CONFIG_L2_CACHE,CONFIG_BUSMODE_60x
>
> 2) I accept the prefix, and generate a definition for
>     CONFIG_SYS_TEXT_BASE.  In the config.mk file, I replace the
>     "sinclude ... config.tmp" by something like this:
>
> 	ifdef CONFIG_SYS_TEXT_BASE
> 	TEXT_BASE = $(CONFIG_SYS_TEXT_BASE)
> 	endif
>
>
>     pro: The lines in boards.cfg don't get too long.
>
>     con: I have to adapt a number or board specific config.mk files
>          (but I have to do this anyway to remove the then obsolete
>          "sinclude" lines.
>
>
> At the moment my preference goes with 2), but I would like to hear if
> this approach seems acceptable to others as well.
>
> Or eventually somebody has a really clever idea how to tackle this...
>
>
> Thanks in advance.
>
> Best regards,
>
> Wolfgang Denk

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.

Amicalement,
-- 
Albert.

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CACD92B.5070300@free.fr> you wrote:
>
> 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.

Ah! Good idea. I like that. Let me sleep on that, but I guess that's
what I'll do.

Thanks a lot!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                               - Mark Twain

[U-Boot] RFQ: Makefile cleanup

[Scott Wood]

On Wed, 6 Oct 2010 22:16:43 +0200
Albert ARIBAUD <albert.aribaud@free.fr> wrote:

> > 2) I accept the prefix, and generate a definition for
> >     CONFIG_SYS_TEXT_BASE.  In the config.mk file, I replace the
> >     "sinclude ... config.tmp" by something like this:
> >
> > 	ifdef CONFIG_SYS_TEXT_BASE
> > 	TEXT_BASE = $(CONFIG_SYS_TEXT_BASE)
> > 	endif
> >
> >
> >     pro: The lines in boards.cfg don't get too long.
> >
> >     con: I have to adapt a number or board specific config.mk files
> >          (but I have to do this anyway to remove the then obsolete
> >          "sinclude" lines.
> >
> >
> > At the moment my preference goes with 2), but I would like to hear if
> > this approach seems acceptable to others as well.

How about having the board's config.mk do something like:

ifdef CONFIG_NAND_SPL
TEXT_BASE = ...
endif

?

> 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.

Well, that addresses the line length argument, at the cost of complexity
and syntax obscurity.  But I changing TEXT_BASE to CONFIG_SYS_TEXT_BASE
is something we probably want to do anyway.  If we ever switch to
kconfig, and we want the text base to be part of that, it will have to
start with CONFIG_.

Even if we don't change TEXT_BASE now, we don't want to encourage
people to add any new symbols in the second category.  If we do add
some hack to the boards.cfg syntax for this, IMHO it ought to be just
for TEXT_BASE and not a generalized symbol setter.

Are we dropping the MK_ that mkconfig currently adds, BTW?  Some
examples in the introductory text use it and some don't.

-Scott

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Scott Wood,

In message <20101006154256.20239b92@udp111988uds.am.freescale.net> you wrote:
>
> How about having the board's config.mk do something like:
> 
> ifdef CONFIG_NAND_SPL
> TEXT_BASE = ...
> endif

Assuming we want to go for Kconfig or similar, I would like to keep
such logic out of the config.mk files (at least not add more than
there already is).

> Well, that addresses the line length argument, at the cost of complexity
> and syntax obscurity.  But I changing TEXT_BASE to CONFIG_SYS_TEXT_BASE
> is something we probably want to do anyway.  If we ever switch to
> kconfig, and we want the text base to be part of that, it will have to
> start with CONFIG_.

Good point.

> Even if we don't change TEXT_BASE now, we don't want to encourage
> people to add any new symbols in the second category.  If we do add
> some hack to the boards.cfg syntax for this, IMHO it ought to be just
> for TEXT_BASE and not a generalized symbol setter.

Agreed.

> Are we dropping the MK_ that mkconfig currently adds, BTW?  Some
> examples in the introductory text use it and some don't.

Yes, these get dropped.  All we want todo is provide a different way
to set configuration options, and a separate name space adds more
problems than benefits.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek

[U-Boot] RFQ: Makefile cleanup

[Graeme Russ]

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=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] RFQ: Makefile cleanup

[Reinhard Meyer]

Dear Graeme Russ,
> 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

That would make more sense to me. But it would even more crowd the include/configs
directory. A while ago I had proposed to change over to:
include/configs/<vendor>/<board>.h but that was rejected.

[Observation:]
But if we really head for linux style *config we would need a
<board>_defconfig individually for each variant...
But I don't think we are there anytime soon.
Many configs contain conditionals and *config does not handle
long (multiline) strings nicely...

Best Regards,
Reinhard

[U-Boot] RFQ: Makefile cleanup

[Rogan Dawes]

On 2010/10/07 2:46 AM, Reinhard Meyer wrote:

> [Observation:]
> But if we really head for linux style *config we would need a
> <board>_defconfig individually for each variant...
> But I don't think we are there anytime soon.
> Many configs contain conditionals and *config does not handle
> long (multiline) strings nicely...
> 
> Best Regards,
> Reinhard

Keep in mind that the Linux folk are looking for an alternative to the
defconfig mess that they have currently.

Linus has stated that he will delete all the ARM defconfigs soon.

Rogan

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Graeme Russ,

In message <AANLkTin-b-yyRaWhUBYLosoDO7RvuK7Hs=FttRBYxoxk@mail.gmail.com> you wrote:
>
> I feel that boards.cfg defines configurations, and therfore each
> additional field is, by definition, a configuration option and should be
> prefixed with CONFIG_

Good point, thanks.

> 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

Yes, I agree. Renaming TEXT_BASE into CONFIG_SYS_TEXT_BASE is probably
the best solution here.

> A couple of other questions:
>  - How do you un-define a CONFIG option via boards.cfg?

We don't. We cannot. The auto-generated config.h is included before
the board config iule (which is necessary so the config options in the
former can influence processing of the latter), but that means that
any #undef in config.h will simply be overridden by a following
#define in the board config file.

We don't need #undef so far, and we should try never to need it. Use
additive logic instead, #define'ing only what you really (and always)
need, and add configurable options (and this only when really needed).

>  - What happens when you try to re-define an option already in the board
>    configuration file?

You get an error. For the same reasons. Don't do that.

> 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

That would be an option as well, but it would add a lot of tiny files,
and not bring us any closer to a Kconfig based system.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I'm growing older, but not up."                      - Jimmy Buffett

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4CAD569E.3020706@dawes.za.net> you wrote:
>
> Keep in mind that the Linux folk are looking for an alternative to the
> defconfig mess that they have currently.
> 
> Linus has stated that he will delete all the ARM defconfigs soon.

I think the current Linux approach is focussed on generating single
kernel images that can be used on as many as possible platforms. This
is needed for things like building Linux distributions and such.

U-Boot, on the other hand, is very much bound to specific hardware
configurations, and at least so far (*) we will always need secial
configurations for each board.  This makes a pretty much fundamental
difference.

(*) We discussed before to auto-configure U-Boot for example based on
a device tee description of the hardware. But it is still a long way
to go.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I haven't lost my mind - it's backed up on tape somewhere."

[U-Boot] RFQ: Makefile cleanup

[Rogan Dawes]

On 2010/10/07 7:22 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4CAD569E.3020706@dawes.za.net> you wrote:
>>
>> Keep in mind that the Linux folk are looking for an alternative to the
>> defconfig mess that they have currently.
>>
>> Linus has stated that he will delete all the ARM defconfigs soon.
> 
> I think the current Linux approach is focussed on generating single
> kernel images that can be used on as many as possible platforms. This
> is needed for things like building Linux distributions and such.
> 
> U-Boot, on the other hand, is very much bound to specific hardware
> configurations, and at least so far (*) we will always need secial
> configurations for each board.  This makes a pretty much fundamental
> difference.
> 
> (*) We discussed before to auto-configure U-Boot for example based on
> a device tee description of the hardware. But it is still a long way
> to go.
> 
> Best regards,
> 
> Wolfgang Denk

My understanding of it (although I have not followed it closely) was
that they were looking for a mechanism to specify those things that
should be in the configuration at a high level, that would then lead to
the rest of the dependent items being selected automatically.

So, rather than having a *full* config file (and all the associated
churn as individual settings are changed within the kernel), they would
only have a snippet that selects the specific features for the board,
that would then cascade-select the rest of the settings for a full
kernel config.

That was considered acceptable, afaik.

Rogan

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Scott Wood,

In message <20101006154256.20239b92@udp111988uds.am.freescale.net> you wrote:
>
> How about having the board's config.mk do something like:
> 
> ifdef CONFIG_NAND_SPL
> TEXT_BASE = ...
> endif

This is what some boardss already do...

> Well, that addresses the line length argument, at the cost of complexity
> and syntax obscurity.  But I changing TEXT_BASE to CONFIG_SYS_TEXT_BASE
> is something we probably want to do anyway.  If we ever switch to
> kconfig, and we want the text base to be part of that, it will have to
> start with CONFIG_.

OK. I tried this, but I'm actually running into a catch-22 situation
after moving the CONFIG_SYS_TEXT_BASE settings into boards.cfg: Some
boards (especially such that support both booting from NOR or,
alternatively, from NAND flash, or from RAM) contain only a default
setting for CONFIG_SYS_TEXT_BASE in their board specific config.mk
file. For example "board/amcc/sequoia/config.mk":

	...
	ifndef CONFIG_SYS_TEXT_BASE
	CONFIG_SYS_TEXT_BASE = 0xFFF80000
	endif
	...

For the NAND-boot version, a different setting (0x01000000) is used
for CONFIG_SYS_TEXT_BASE. Before include/autoconf.mk exists, the
default setting is used, but then suddenly the value changes to the
intended setting. This causes compiler warnings when generating
include/autoconf.mk:

include/config.h:4:1: warning: "CONFIG_SYS_TEXT_BASE" redefined
<command-line>: warning: this is the location of the previous
definition

To avoid these, I tried stripping any "-DCONFIG_SYS_TEXT_BASE="
settings from the compiler options when building include/autoconf.mk
and include/autoconf.mk.dep .


But then I noticed that some boards had build errors, or the builds
differed otherwise from the previous version (some commands not
included, etc.). This was when I learned that we actually need the
correct TEXT_BASE definition on some boards to get correct setttings
into include/autoconf.mk.


In other words, we have a problem because some config settings which
are currently defined in board/.../config.mk take immediate effect and
get included into the generation of include/autoconf.mk, while other
settings (through include/configs/<name>.h) are kind of "second class"
settings.


We could, of course try and get rid of all such config settigns in the
config.mk files and move all the config logic into the
include/configs/<name>.h files, but then this is another big set of
changes, which I would like to avoid at this point. It's difficult
enough to keep my current work split indo understandable and
bisectable patches.

Any ideas?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All I ask is a chance to prove that money can't make me happy.

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Hi all

In message <20101010151418.C169F14F310@gemini.denx.de> I wrote:
> 
> > Well, that addresses the line length argument, at the cost of complexity
> > and syntax obscurity.  But I changing TEXT_BASE to CONFIG_SYS_TEXT_BASE
> > is something we probably want to do anyway.  If we ever switch to
> > kconfig, and we want the text base to be part of that, it will have to
> > start with CONFIG_.
> 
> OK. I tried this, but I'm actually running into a catch-22 situation
> after moving the CONFIG_SYS_TEXT_BASE settings into boards.cfg: Some
> boards (especially such that support both booting from NOR or,
> alternatively, from NAND flash, or from RAM) contain only a default
> setting for CONFIG_SYS_TEXT_BASE in their board specific config.mk
> file. For example "board/amcc/sequoia/config.mk":

In case anybody what's to see this problem in action, I've pushed my
current working tree into the "Makefile-cleanup" branch of the
u-boot-testing repository, see

http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/Makefile-cleanup

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No man knows what true happiness is until he gets married.  By  then,
of course, its too late.

[U-Boot] RFQ: Makefile cleanup

[Mike Frysinger]

On Sunday, October 10, 2010 11:46:38 Wolfgang Denk wrote:
> In case anybody what's to see this problem in action, I've pushed my
> current working tree into the "Makefile-cleanup" branch of the
> u-boot-testing repository, see
> 
> http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/Mak
> efile-cleanup

what's with the u-boot-testing tree instead of a dedicated branch in u-boot ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101010/4584bf3c/attachment.pgp 

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201010101424.36981.vapier@gentoo.org> you wrote:
>
> > http://git.denx.de/?p=3Du-boot/u-boot-testing.git;a=3Dshortlog;h=3Drefs/heads/Makefile-cleanup
> 
> what's with the u-boot-testing tree instead of a dedicated branch in u-boot ?

Um.. this stuff is still heavily in flow.

I hope these commits are stable now:

6360255  Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE
6836296  mkconfig: change CONFIG_MK_ prefix into plain CONFIG_
af726cf  Build: Add "board options" column to boards.cfg

but at least the two topmost commits

65370be  Makefile: move all Power Architecture boards into boars.cfg
ccc23e9  Makefile: avoid CONFIG_SYS_TEXT_BASE redefinitions

are still highly experimental, incomplete and incorrect.

I didn't feel this to be stuff for a branch in the master repo yet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Perl script is correct if it's halfway readable and  gets  the  job
done before your boss fires you.
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot] RFQ: Makefile cleanup

[Mike Frysinger]

On Sunday, October 10, 2010 15:10:03 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > http://git.denx.de/?p=3Du-boot/u-boot-testing.git;a=3Dshortlog;h=3Drefs
> > > /heads/Makefile-cleanup
> > 
> > what's with the u-boot-testing tree instead of a dedicated branch in
> > u-boot ?
> 
> Um.. this stuff is still heavily in flow.

diff dev methodologies i guess.  if it's in a sep branch labeled 
"experimental", i dont see the harm in throwing anything in there, even if it 
blows up all boards.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101010/48c5a33a/attachment.pgp 

[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201010101557.18003.vapier@gentoo.org> you wrote:
>
> > > > http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;hrefs
> > > > /heads/Makefile-cleanup
> > >
> > > what's with the u-boot-testing tree instead of a dedicated branch in
> > > u-boot ?
> >
> > Um.. this stuff is still heavily in flow.
>
> diff dev methodologies i guess.  if it's in a sep branch labeled
> "experimental", i dont see the harm in throwing anything in there, even if it
> blows up all boards.

Well, that's what we use the -testing repository for.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Physician: One upon whom we set our hopes when ill and our dogs  when
well.                                                - Ambrose Bierce