[U-Boot-Users] include/autoconf.mk issue
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
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
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
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
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
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
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.
participants (4)
-
Grant Likely -
Jerry Van Baren -
Jon Loeliger -
Wolfgang Denk