[U-Boot-Users] include/autoconf.mk issue

[U-Boot-Users] include/autoconf.mk issue

[Wolfgang Denk]

Dear Grant,

in http://news.gmane.org/gmane.comp.boot-loaders.u-boot
Jean-Christophe asked to get rid of the "#ifdef CONFIG_POST" parts in
the post code by using the "COBJS-$(CONFIG_POST) += " approach in the
Makefile. We tried, and it didn't work.

The reason is that the Makefile assumes that  the  CONFIG_*  variable
settings  in  include/autoconf.mk  have  a  value  of  "y", so we can
collect objects to build in the "COBJS-y" make variable.

However, this is not always true. Here is what we see for example on
the "lwmon5" board:

-> grep -v =y include/autoconf.mk
CONFIG_SYS_CLK_FREQ=33300000
CONFIG_POST_WATCHDOG="{ "Watchdog timer test", "watchdog", "This test checks the watchdog timer.", POST_RAM | POST_POWERON | POST_SLOWTEST | POST_MANUAL | POST_REBOOT, &lwmon5_watchdog_post_test, NULL, NULL, CFG_POST_WATCHDOG }"
CONFIG_BOOTDELAY=5
CONFIG_ALT_LB_ADDR="(CFG_OCM_BASE)"
CONFIG_BOOTCOMMAND="run flash_self"
CONFIG_POST_KEY_MAGIC="3C+3E"
CONFIG_PHY_RESET_DELAY=300
CONFIG_POST_BSPEC1="{ "dsPIC init test", "dspic_init", "This test returns result of dsPIC READY test run earlier.", POST_RAM | POST_ALWAYS, &dspic_init_post_test, NULL, NULL, CFG_POST_BSPEC1 }"
CONFIG_POST_BSPEC2="{ "dsPIC test", "dspic", "This test gets result of dsPIC POST and dsPIC version.", POST_RAM | POST_ALWAYS, &dspic_post_test, NULL, NULL, CFG_POST_BSPEC2 }"
CONFIG_POST_BSPEC3="{ "FPGA test", "fpga", "This test checks FPGA registers and memory.", POST_RAM | POST_ALWAYS, &fpga_post_test, NULL, NULL, CFG_POST_BSPEC3 }"
CONFIG_POST_BSPEC4="{ "GDC test", "gdc", "This test checks GDC registers and memory.", POST_RAM | POST_ALWAYS, &gdc_post_test, NULL, NULL, CFG_POST_BSPEC4 }"
CONFIG_POST_BSPEC5="{ "SYSMON1 test", "sysmon1", "This test checks GPIO_62_EPX pin indicating power failure.", POST_RAM | POST_MANUAL | POST_NORMAL | POST_SLOWTEST, &sysmon1_post_test, NULL, NULL, CFG_POST_BSPEC5 }"
CONFIG_PHY_ADDR=3
CONFIG_BAUDRATE=115200
CONFIG_ALT_LH_ADDR="(CFG_PERIPHERAL_BASE + GPT0_COMP1)"
CONFIG_POST="(CFG_POST_CACHE | CFG_POST_CPU | CFG_POST_ECC_ON | CFG_POST_ETHER | CFG_POST_FPU | CFG_POST_I2C | CFG_POST_MEMORY | CFG_POST_RTC | CFG_POST_SPR | CFG_POST_UART | CFG_POST_SYSMON | CFG_POST_WATCHDOG | CFG_POST_DSP | CFG_POST_BSPEC1 | CFG_POST_BSPEC2 | CFG_POST_BSPEC3 | CFG_POST_BSPEC4 | CFG_POST_BSPEC5)"
CONFIG_PREBOOT="setenv bootdelay 15"
CONFIG_WD_PERIOD=40000


In this case, only CONFIG_POST is critical, but  some  of  the  other
settings might show similar problems, and this is just an examplefrom
a  single  board  -  there  may be other, similar issues lurking with
other boards.


What is the suggested way to fix this? It's clear  that  the  current
string value

	CONFIG_POST="(CFG_POST_CACHE | ... )"

is of no use for the decistion which files need to  be  compiled.  My
initial idea was to say that all non-empty strings should be replaced
by  "y",  but  I'm not sure about side effects; also, what to do with
numeric values? Convert only non-zero values  to  "y"?  But  then,  a
"#define FOO 0" still means that "FOO" is defined...

What do you (and others!) think?

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
Superior ability breeds superior ambition.
	-- Spock, "Space Seed", stardate 3141.9

[U-Boot-Users] include/autoconf.mk issue

[Jon Loeliger]

On Wed, 2008-03-19 at 18:29, Wolfgang Denk wrote:
> Dear Grant,
> 
> in http://news.gmane.org/gmane.comp.boot-loaders.u-boot
> Jean-Christophe asked to get rid of the "#ifdef CONFIG_POST" parts in
> the post code by using the "COBJS-$(CONFIG_POST) += " approach in the
> Makefile. We tried, and it didn't work.
> 
> The reason is that the Makefile assumes that  the  CONFIG_*  variable
> settings  in  include/autoconf.mk  have  a  value  of  "y", so we can
> collect objects to build in the "COBJS-y" make variable.
> 
> However, this is not always true. Here is what we see for example on
> the "lwmon5" board:
> 
> -> grep -v =y include/autoconf.mk
> CONFIG_SYS_CLK_FREQ=33300000
> CONFIG_POST_WATCHDOG="{ "Watchdog timer test", "watchdog", "This test checks the watchdog timer.", POST_RAM | POST_POWERON | POST_SLOWTEST | POST_MANUAL | POST_REBOOT, &lwmon5_watchdog_post_test, NULL, NULL, CFG_POST_WATCHDOG }"
> CONFIG_BOOTDELAY=5
> CONFIG_ALT_LB_ADDR="(CFG_OCM_BASE)"
> CONFIG_BOOTCOMMAND="run flash_self"
> CONFIG_POST_KEY_MAGIC="3C+3E"
> CONFIG_PHY_RESET_DELAY=300
> CONFIG_POST_BSPEC1="{ "dsPIC init test", "dspic_init", "This test returns result of dsPIC READY test run earlier.", POST_RAM | POST_ALWAYS, &dspic_init_post_test, NULL, NULL, CFG_POST_BSPEC1 }"
> CONFIG_POST_BSPEC2="{ "dsPIC test", "dspic", "This test gets result of dsPIC POST and dsPIC version.", POST_RAM | POST_ALWAYS, &dspic_post_test, NULL, NULL, CFG_POST_BSPEC2 }"
> CONFIG_POST_BSPEC3="{ "FPGA test", "fpga", "This test checks FPGA registers and memory.", POST_RAM | POST_ALWAYS, &fpga_post_test, NULL, NULL, CFG_POST_BSPEC3 }"
> CONFIG_POST_BSPEC4="{ "GDC test", "gdc", "This test checks GDC registers and memory.", POST_RAM | POST_ALWAYS, &gdc_post_test, NULL, NULL, CFG_POST_BSPEC4 }"
> CONFIG_POST_BSPEC5="{ "SYSMON1 test", "sysmon1", "This test checks GPIO_62_EPX pin indicating power failure.", POST_RAM | POST_MANUAL | POST_NORMAL | POST_SLOWTEST, &sysmon1_post_test, NULL, NULL, CFG_POST_BSPEC5 }"
> CONFIG_PHY_ADDR=3
> CONFIG_BAUDRATE=115200
> CONFIG_ALT_LH_ADDR="(CFG_PERIPHERAL_BASE + GPT0_COMP1)"
> CONFIG_POST="(CFG_POST_CACHE | CFG_POST_CPU | CFG_POST_ECC_ON | CFG_POST_ETHER | CFG_POST_FPU | CFG_POST_I2C | CFG_POST_MEMORY | CFG_POST_RTC | CFG_POST_SPR | CFG_POST_UART | CFG_POST_SYSMON | CFG_POST_WATCHDOG | CFG_POST_DSP | CFG_POST_BSPEC1 | CFG_POST_BSPEC2 | CFG_POST_BSPEC3 | CFG_POST_BSPEC4 | CFG_POST_BSPEC5)"
> CONFIG_PREBOOT="setenv bootdelay 15"
> CONFIG_WD_PERIOD=40000


*sigh*

Needless to say, exactly the same change that I performed
last year for CONFIG_COMMAND -> CONFIG_CMD_* and for
CONFIG_BOOTP needs to be done here now for CONFIG_POST
as well.

I am personally swamped right now and will not be able
to get to it directly, but some enterprising young
whipper-snapper might get there before I do... :-)

jdl

[U-Boot-Users] include/autoconf.mk issue

[Wolfgang Denk]

In message <1206024369.5488.13.camel@ld0161-tx32> you wrote:
>
...
> > CONFIG_POST="(CFG_POST_CACHE | CFG_POST_CPU | CFG_POST_ECC_ON | CFG_POST_ETHER | CFG_POST_FPU | CFG_POST_I2C | CFG_POST_MEMORY | CFG_POST_RTC | CFG_POST_SPR | CFG_POST_UART | CFG_POST_SYSMON | CFG_POST_WATCHDOG | CFG_POST_DSP | CFG_POST_BSPEC1 | CFG_P
> OST_BSPEC2 | CFG_POST_BSPEC3 | CFG_POST_BSPEC4 | CFG_POST_BSPEC5)"
> > CONFIG_PREBOOT="setenv bootdelay 15"
...
> *sigh*
> 
> Needless to say, exactly the same change that I performed
> last year for CONFIG_COMMAND -> CONFIG_CMD_* and for
> CONFIG_BOOTP needs to be done here now for CONFIG_POST
> as well.

Um... that would fix this specific situation - but we might still run
into the same problem with the next attempt to convert  code  to  the
new config style.

For example, there might be code which might be compiled depending on
CONFIG_PREBOOT.

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
Time is a drug. Too much of it kills you.
                                      - Terry Pratchett, _Small Gods_

[U-Boot-Users] include/autoconf.mk issue

[Jon Loeliger]

On Thu, 2008-03-20 at 10:32, Wolfgang Denk wrote:

> Um... that would fix this specific situation - but we might still run
> into the same problem with the next attempt to convert  code  to  the
> new config style.

Yeah, we just need to pick 'em off one-by-one... :-)

> For example, there might be code which might be compiled depending on
> CONFIG_PREBOOT.

Ah, as I understand that one, I think it gets solved in
a slightly different manner.  The kernel introduces a "HAS"
variant that indicates if the feature is enabled and
then uses something like CONFIG_HAS_PREBOOT to indicate
and test for its presence.  The actual _value_ remains
the CONFIG_PREBOOT symbol.

jdl

[U-Boot-Users] include/autoconf.mk issue

[Wolfgang Denk]

In message <1206027486.5488.25.camel@ld0161-tx32> you wrote:
>
> Ah, as I understand that one, I think it gets solved in
> a slightly different manner.  The kernel introduces a "HAS"
> variant that indicates if the feature is enabled and
> then uses something like CONFIG_HAS_PREBOOT to indicate
> and test for its presence.  The actual _value_ remains
> the CONFIG_PREBOOT symbol.

Then we should do the same for autoconfig.mk, and use CONFIG_HAS_POST
in the POST Makefile?

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
Q:  What's a light-year?
A:  One-third less calories than a regular year.

[U-Boot-Users] include/autoconf.mk issue

[Jerry Van Baren]

Jon Loeliger wrote:
> On Thu, 2008-03-20 at 10:32, Wolfgang Denk wrote:
> 
>> Um... that would fix this specific situation - but we might still run
>> into the same problem with the next attempt to convert  code  to  the
>> new config style.
> 
> Yeah, we just need to pick 'em off one-by-one... :-)
> 
>> For example, there might be code which might be compiled depending on
>> CONFIG_PREBOOT.
> 
> Ah, as I understand that one, I think it gets solved in
> a slightly different manner.  The kernel introduces a "HAS"
> variant that indicates if the feature is enabled and
> then uses something like CONFIG_HAS_PREBOOT to indicate
> and test for its presence.  The actual _value_ remains
> the CONFIG_PREBOOT symbol.
> 
> jdl

Hi Jon,

In a recent patch (picked up by Stefan but not in the current ToT)
   <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38092>
I added a config CONFIG_FLASH_SHOW_PROGRESS which I used to provide a 
countdown value as well as configure code (*not* a .o file).  Based on 
my limited understanding and perusal of the linux Kconfig methodology, 
this looked like an acceptable thing.

Is this a violation of Good Design[tm], or is the "CONFIG_HAS_*" 
principle an additional rule that only applies if you have a separately 
compiled file, necessary so that the "COBJS-y +=" trick works?

Thanks for clarifying,
gvb

[U-Boot-Users] include/autoconf.mk issue

[Grant Likely]

On Wed, Mar 19, 2008 at 5:29 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
>  in http://news.gmane.org/gmane.comp.boot-loaders.u-boot
>  Jean-Christophe asked to get rid of the "#ifdef CONFIG_POST" parts in
>  the post code by using the "COBJS-$(CONFIG_POST) += " approach in the
>  Makefile. We tried, and it didn't work.
>
>  The reason is that the Makefile assumes that  the  CONFIG_*  variable
>  settings  in  include/autoconf.mk  have  a  value  of  "y", so we can
>  collect objects to build in the "COBJS-y" make variable.
>
>  However, this is not always true. Here is what we see for example on
>  the "lwmon5" board:
>
>  -> grep -v =y include/autoconf.mk
>  CONFIG_POST="(CFG_POST_CACHE | CFG_POST_CPU | CFG_POST_ECC_ON | CFG_POST_ETHER | CFG_POST_FPU | CFG_POST_I2C | CFG_POST_MEMORY | CFG_POST_RTC | CFG_POST_SPR | CFG_POST_UART | CFG_POST_SYSMON | CFG_POST_WATCHDOG | CFG_POST_DSP | CFG_POST_BSPEC1 | CFG_POST_BSPEC2 | CFG_POST_BSPEC3 | CFG_POST_BSPEC4 | CFG_POST_BSPEC5)"
>
>  In this case, only CONFIG_POST is critical, but  some  of  the  other
>  settings might show similar problems, and this is just an examplefrom
>  a  single  board  -  there  may be other, similar issues lurking with
>  other boards.

Yeah, I was expecting as much.  You're right of course that the
COBJS-y trick only works if the assumption that the symbol is defined
and has either an empty value or a value of '1'.  Any that do not fall
in this category cannot be used for "COBJS-${BLAH} += ..." statements.

This is true in the kernel also.  Only CONFIG values that are bool or
tristate are suitable for this type of use.

>  What is the suggested way to fix this? It's clear  that  the  current
>  string value
>
>         CONFIG_POST="(CFG_POST_CACHE | ... )"
>
>  is of no use for the decistion which files need to  be  compiled.  My
>  initial idea was to say that all non-empty strings should be replaced
>  by  "y",  but  I'm not sure about side effects; also, what to do with
>  numeric values? Convert only non-zero values  to  "y"?  But  then,  a
>  "#define FOO 0" still means that "FOO" is defined...

No, the side effects would be too severe to blanket change all strings
into "y".  I see two possible solutions (both of which have already
been suggested by jdl):
1. Break up CONFIG_POST bitmask and replace with CONFIG_POST_CACHE,
etc.  Just like was done with CONFIG_CMD.
2. Add a CONFIG_HAS_POST value that specifies that CONFIG_POST has a value.

As for having to do this again for the next one; yes we will.  That's
just going to be part of the pain of moving to a Kconfig style system.
 Not all CONFIG_ values are suitable for conditional compilation from
the makefiles so where they are not we need to adapt.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.