| Message ID | 1420291209-20249-2-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Masahiro Yamada |
| Headers | show |
Hi Alexey, 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>: > Now when we may select commands via menuconfig let's adjust default > settings with "config_cmd_default.h". > > As the next step we may get rid of "config_cmd_default.h" inclusion in > "include/configs/*.h" and "config_cmd_default.h" itself. Thanks for working on this, but I think this patch changes the behavior. Some boards include <config_cmd_default.h> and then undefine unnecessary commands. For example, include/configs/snapper9260.h #include <config_cmd_default.h> #undef CONFIG_CMD_BDI #undef CONFIG_CMD_FPGA #undef CONFIG_CMD_IMI #undef CONFIG_CMD_IMLS #undef CONFIG_CMD_LOADS #undef CONFIG_CMD_SOURCE If you set the default value to "y" in Kconfig, it cannot be undef'ed by C-headers. > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> > Cc: Tom Rini <trini@ti.com> > --- > common/Kconfig | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/common/Kconfig b/common/Kconfig > index fd84fa0..cbc4f5b 100644 > --- a/common/Kconfig > +++ b/common/Kconfig > @@ -24,11 +24,13 @@ menu "Info commands" > > config CMD_BDI > bool "bdinfo" > + default y > help > Print board info This change enables CMD_BDI for all the boards. Please notice the following boards do not want to compile this command. ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI ./include/configs/pb1x00.h:#undef CONFIG_CMD_BDI ./include/configs/at91sam9m10g45ek.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_schmoogie.h:#undef CONFIG_CMD_BDI ./include/configs/meesc.h:#undef CONFIG_CMD_BDI ./include/configs/at91sam9263ek.h:#undef CONFIG_CMD_BDI ./include/configs/usb_a9263.h:#undef CONFIG_CMD_BDI ./include/configs/at91sam9rlek.h:#undef CONFIG_CMD_BDI ./include/configs/taurus.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_sonata.h:#undef CONFIG_CMD_BDI ./include/configs/afeb9260.h:#undef CONFIG_CMD_BDI ./include/configs/at91sam9261ek.h:#undef CONFIG_CMD_BDI ./include/configs/snapper9260.h:#undef CONFIG_CMD_BDI ./include/configs/at91sam9260ek.h:#undef CONFIG_CMD_BDI ./include/configs/tny_a9260.h:#undef CONFIG_CMD_BDI ./include/configs/ethernut5.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_dvevm.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_dm355leopard.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_sffsdr.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_dm6467evm.h:#undef CONFIG_CMD_BDI ./include/configs/vct.h:#undef CONFIG_CMD_BDI ./include/configs/vl_ma2sc.h:#undef CONFIG_CMD_BDI ./include/configs/corvus.h:#undef CONFIG_CMD_BDI ./include/configs/sbc35_a9g20.h:#undef CONFIG_CMD_BDI ./include/configs/pm9261.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_dm355evm.h:#undef CONFIG_CMD_BDI ./include/configs/pm9263.h:#undef CONFIG_CMD_BDI ./include/configs/davinci_dm365evm.h:#undef CONFIG_CMD_BDI ./include/configs/cpu9260.h:#undef CONFIG_CMD_BDI ./include/configs/jadecpu.h:#undef CONFIG_CMD_BDI > @@ -193,6 +204,7 @@ config CMD_USB > > config CMD_FPGA > bool "fpga" > + default y > help > FPGA support. Moreover, I doubt some of default commands in <config_cmd_default.h> (I have used only some of commands in <config_cmd_default.h>) For example, it seems weird to enable CONFIG_CMD_FPGA by default. I do not think most of boards have FPGA.
Hi Masahiro-san, On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote: > Hi Alexey, > > 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>: > > Now when we may select commands via menuconfig let's adjust default > > settings with "config_cmd_default.h". > > > > As the next step we may get rid of "config_cmd_default.h" inclusion in > > "include/configs/*.h" and "config_cmd_default.h" itself. > > Thanks for working on this, but I think this patch changes the behavior. > > Some boards include <config_cmd_default.h> and then undefine > unnecessary commands. > For example, include/configs/snapper9260.h > > #include <config_cmd_default.h> > #undef CONFIG_CMD_BDI > #undef CONFIG_CMD_FPGA > #undef CONFIG_CMD_IMI > #undef CONFIG_CMD_IMLS > #undef CONFIG_CMD_LOADS > #undef CONFIG_CMD_SOURCE > > If you set the default value to "y" in Kconfig, > it cannot be undef'ed by C-headers. That's true. But anyway at some point we'll need to switch selection of commands in Kconfig, right? Probably I'm missing details of our Kconfig migration plan if one exists. Then I'd like to get a reference to the plan so I'm not attempting to do things that are already scheduled and could be even in a process of implementation. Otherwise if there's no current plan for Kconfig migration we may start discussion on how to deal with "commands" in particular. The point is commands are low-hanging fruits in terms of Kconfig migration - there're no extra options and tweaks, once all commands are added in Kconfig (essentially with dependencies etc) we may clean all board headers. The only real problem here is amount of work - lots of headers/defconfigs to patch. But still this is doable. > > config CMD_BDI > > bool "bdinfo" > > + default y > > help > > Print board info > > > This change enables CMD_BDI for all the boards. > > Please notice the following boards do not want to compile this command. > > ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI > > @@ -193,6 +204,7 @@ config CMD_USB > > > > config CMD_FPGA > > bool "fpga" > > + default y > > help > > FPGA support. > > Moreover, I doubt some of default commands in <config_cmd_default.h> > (I have used only some of commands in <config_cmd_default.h>) > > For example, it seems weird to enable CONFIG_CMD_FPGA by default. > > I do not think most of boards have FPGA. That's a separate topic. I do agree that CMD_FPGA makes not much sense for most of boards, as well as some others. And I think during migration process of commands to Kconfig it's a good time to reconsider default commands. I will highly appreciate input on both topics from others so we'll do some progress here and will make sure all parties are happy. -Alexey
Hi Alexey, On Fri, 9 Jan 2015 20:09:22 +0000 Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Masahiro-san, > > On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote: > > Hi Alexey, > > > > 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>: > > > Now when we may select commands via menuconfig let's adjust default > > > settings with "config_cmd_default.h". > > > > > > As the next step we may get rid of "config_cmd_default.h" inclusion in > > > "include/configs/*.h" and "config_cmd_default.h" itself. > > > > Thanks for working on this, but I think this patch changes the behavior. > > > > Some boards include <config_cmd_default.h> and then undefine > > unnecessary commands. > > > For example, include/configs/snapper9260.h > > > > #include <config_cmd_default.h> > > #undef CONFIG_CMD_BDI > > #undef CONFIG_CMD_FPGA > > #undef CONFIG_CMD_IMI > > #undef CONFIG_CMD_IMLS > > #undef CONFIG_CMD_LOADS > > #undef CONFIG_CMD_SOURCE > > > > If you set the default value to "y" in Kconfig, > > it cannot be undef'ed by C-headers. > > That's true. > But anyway at some point we'll need to switch selection of commands in > Kconfig, right? Yes. > Probably I'm missing details of our Kconfig migration plan if one > exists. Then I'd like to get a reference to the plan so I'm not > attempting to do things that are already scheduled and could be even in > a process of implementation. > Otherwise if there's no current plan for Kconfig migration we may start > discussion on how to deal with "commands" in particular. I proposed the following way, but no big conversion movement has happened yet. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 If you have an idea, please propose it. Kconfig conversion is a too big task to be done by a single indivisual. Any suggestion, any form of contribution is very appreciated. I personally keep away from any global changes until non-generic boards are dumped. As Tom said in the following mail, http://lists.denx.de/pipermail/u-boot/2015-January/201032.html we are going to remove lots of boards. I do not want to make extra efforts on non-generic boards. > The point is commands are low-hanging fruits in terms of Kconfig > migration - there're no extra options and tweaks, once all commands are > added in Kconfig (essentially with dependencies etc) we may clean all > board headers. The only real problem here is amount of work - lots of > headers/defconfigs to patch. But still this is doable. I realized one problem when I was doing this task for my boards in commit 25e274e20208. The defconfigs of my boards are almost the same: (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) What is inconvenient as for defconfig is that it does not support "include" directive like C headers. People generally like to add CONFIG_CMD_* to a common header file such as include/configs/tegra-common.h On the other hand, on defconfig, we must touch each defconfig of the board family. I have not been able to decide right direction to solve this issue. I think we need to discuss about how to live with lots of defconfigs. > > > config CMD_BDI > > > bool "bdinfo" > > > + default y > > > help > > > Print board info > > > > > > This change enables CMD_BDI for all the boards. > > > > Please notice the following boards do not want to compile this command. > > > > ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI > > > > @@ -193,6 +204,7 @@ config CMD_USB > > > > > > config CMD_FPGA > > > bool "fpga" > > > + default y > > > help > > > FPGA support. > > > > Moreover, I doubt some of default commands in <config_cmd_default.h> > > (I have used only some of commands in <config_cmd_default.h>) > > > > For example, it seems weird to enable CONFIG_CMD_FPGA by default. > > > > I do not think most of boards have FPGA. > > That's a separate topic. I do agree that CMD_FPGA makes not much sense > for most of boards, as well as some others. > > And I think during migration process of commands to Kconfig it's a good > time to reconsider default commands. Agree. We should reconsider the default. In my opition, most of the ones in config_cmd_default.h are not default commands. > I will highly appreciate input on both topics from others so we'll do > some progress here and will make sure all parties are happy. > > -Alexey Best Regards Masahiro Yamada
HI Masahiro, On 13 January 2015 at 20:05, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Alexey, > > > On Fri, 9 Jan 2015 20:09:22 +0000 > Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > >> Hi Masahiro-san, >> >> On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote: >> > Hi Alexey, >> > >> > 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>: >> > > Now when we may select commands via menuconfig let's adjust default >> > > settings with "config_cmd_default.h". >> > > >> > > As the next step we may get rid of "config_cmd_default.h" inclusion in >> > > "include/configs/*.h" and "config_cmd_default.h" itself. >> > >> > Thanks for working on this, but I think this patch changes the behavior. >> > >> > Some boards include <config_cmd_default.h> and then undefine >> > unnecessary commands. >> >> > For example, include/configs/snapper9260.h >> > >> > #include <config_cmd_default.h> >> > #undef CONFIG_CMD_BDI >> > #undef CONFIG_CMD_FPGA >> > #undef CONFIG_CMD_IMI >> > #undef CONFIG_CMD_IMLS >> > #undef CONFIG_CMD_LOADS >> > #undef CONFIG_CMD_SOURCE >> > >> > If you set the default value to "y" in Kconfig, >> > it cannot be undef'ed by C-headers. >> >> That's true. >> But anyway at some point we'll need to switch selection of commands in >> Kconfig, right? > > Yes. > > >> Probably I'm missing details of our Kconfig migration plan if one >> exists. Then I'd like to get a reference to the plan so I'm not >> attempting to do things that are already scheduled and could be even in >> a process of implementation. >> Otherwise if there's no current plan for Kconfig migration we may start >> discussion on how to deal with "commands" in particular. > > > I proposed the following way, but no big conversion movement has happened yet. > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 > > If you have an idea, please propose it. > > Kconfig conversion is a too big task to be done by a single indivisual. > Any suggestion, any form of contribution is very appreciated. > > > > I personally keep away from any global changes until > non-generic boards are dumped. > > As Tom said in the following mail, > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html > we are going to remove lots of boards. > > I do not want to make extra efforts on non-generic boards. > > > > >> The point is commands are low-hanging fruits in terms of Kconfig >> migration - there're no extra options and tweaks, once all commands are >> added in Kconfig (essentially with dependencies etc) we may clean all >> board headers. The only real problem here is amount of work - lots of >> headers/defconfigs to patch. But still this is doable. > > > I realized one problem when I was doing this task > for my boards in commit 25e274e20208. > > The defconfigs of my boards are almost the same: > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) > > What is inconvenient as for defconfig is that > it does not support "include" directive like C headers. > > People generally like to add CONFIG_CMD_* to a common header file > such as include/configs/tegra-common.h > > On the other hand, on defconfig, we must touch each defconfig of the board family. > > I have not been able to decide right direction to solve this issue. > > I think we need to discuss about how to live with lots of defconfigs. How about this: 1. Support an 'include' option in defconfig to include another file. This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated list of filenames). Don't allow nested includes - this CONFIG provides a complete list of includes. 2. When you use menuconfig to edit the config, it ignores the include and just writes out everything. Then it runs a simple script which parses the include files, and adjusts the file so that things in the includes are not repeated in the defconfig. I think this scheme would be good enough, but can probably be improved. At least it would be better than what we have. Or we could instead define particular includes for different purposes: - Arch - SOC - SOC Vendor - Board vendor - Board family We could then require that standard filenames are used, and search for the correct file based on the SOC/board/vendor setting, etc. As an example, for trimslice, we could search for arm.h, tegra.h, nvidia.h, compulab.h, some_family_name.h. This is less flexible though. > > > >> > > config CMD_BDI >> > > bool "bdinfo" >> > > + default y >> > > help >> > > Print board info >> > >> > >> > This change enables CMD_BDI for all the boards. >> > >> > Please notice the following boards do not want to compile this command. >> > >> > ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI >> >> > > @@ -193,6 +204,7 @@ config CMD_USB >> > > >> > > config CMD_FPGA >> > > bool "fpga" >> > > + default y >> > > help >> > > FPGA support. >> > >> > Moreover, I doubt some of default commands in <config_cmd_default.h> >> > (I have used only some of commands in <config_cmd_default.h>) >> > >> > For example, it seems weird to enable CONFIG_CMD_FPGA by default. >> > >> > I do not think most of boards have FPGA. >> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense >> for most of boards, as well as some others. >> >> And I think during migration process of commands to Kconfig it's a good >> time to reconsider default commands. > > Agree. > We should reconsider the default. > In my opition, most of the ones in config_cmd_default.h are not default commands. > > > >> I will highly appreciate input on both topics from others so we'll do >> some progress here and will make sure all parties are happy. >> >> -Alexey Regards, Simon
Hi Simon, Masahiro-san, On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: > > > >> Probably I'm missing details of our Kconfig migration plan if one > >> exists. Then I'd like to get a reference to the plan so I'm not > >> attempting to do things that are already scheduled and could be even in > >> a process of implementation. > >> Otherwise if there's no current plan for Kconfig migration we may start > >> discussion on how to deal with "commands" in particular. > > > > > > I proposed the following way, but no big conversion movement has happened yet. > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 > > > > If you have an idea, please propose it. Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 failed". Do you mind to provide a link for the same message in http://lists.denx.de ? > > Kconfig conversion is a too big task to be done by a single indivisual. > > Any suggestion, any form of contribution is very appreciated. Indeed and that stops me from starting this work as well. So my point is: 1) anybody may do updates to Kconfig like add more U-Boot commands, some settings (CONFIG_SYS_xxx) 2) board maintainers are responsible for updates in defconfigs and corresponding headers in "include/configs/" 3) that would be helpful if at (1) board maintainers are notified via direct emails on the change that has been done > > I personally keep away from any global changes until > > non-generic boards are dumped. > > > > As Tom said in the following mail, > > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html > > we are going to remove lots of boards. > > > > I do not want to make extra efforts on non-generic boards. That makes sense but why don't we start implementation of changes in good boards we know already converted to "generic"? There're even entire arches that switched to "generic boards". > >> The point is commands are low-hanging fruits in terms of Kconfig > >> migration - there're no extra options and tweaks, once all commands are > >> added in Kconfig (essentially with dependencies etc) we may clean all > >> board headers. The only real problem here is amount of work - lots of > >> headers/defconfigs to patch. But still this is doable. > > > > > > I realized one problem when I was doing this task > > for my boards in commit 25e274e20208. > > > > The defconfigs of my boards are almost the same: > > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) > > > > What is inconvenient as for defconfig is that > > it does not support "include" directive like C headers. > > > > People generally like to add CONFIG_CMD_* to a common header file > > such as include/configs/tegra-common.h > > > > On the other hand, on defconfig, we must touch each defconfig of the board family. > > > > I have not been able to decide right direction to solve this issue. > > > > I think we need to discuss about how to live with lots of defconfigs. > > How about this: > > 1. Support an 'include' option in defconfig to include another file. > This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated > list of filenames). Don't allow nested includes - this CONFIG provides > a complete list of includes. > 2. When you use menuconfig to edit the config, it ignores the include > and just writes out everything. Then it runs a simple script which > parses the include files, and adjusts the file so that things in the > includes are not repeated in the defconfig. > > I think this scheme would be good enough, but can probably be > improved. At least it would be better than what we have. > > Or we could instead define particular includes for different purposes: > > - Arch > - SOC > - SOC Vendor > - Board vendor > - Board family > > We could then require that standard filenames are used, and search for > the correct file based on the SOC/board/vendor setting, etc. > > As an example, for trimslice, we could search for arm.h, tegra.h, > nvidia.h, compulab.h, some_family_name.h. > > This is less flexible though. Frankly I don't like this approach with post-processing steps. It will inevitably end-up with messed up configs. Why don't we just use default values in Kconfig for ARCH/SOC/Board? It's pretty obvious that 1 board may have N flavors but then have a baseline options selected in "board/vendor/board_name/Kconfig" and only put options that differ between boards in your defconfigs. This way "savedefconfig" will automatically strip down all extra lines for a particular board. This is how things work in Linux kernel and Buildroot Kconfig-based build systems. Probably I'm missing something here because U-Boot differs from mentioned projects in some aspects - if so please correct me. > >> > >> That's a separate topic. I do agree that CMD_FPGA makes not much sense > >> for most of boards, as well as some others. > >> > >> And I think during migration process of commands to Kconfig it's a good > >> time to reconsider default commands. > > > > Agree. > > We should reconsider the default. > > In my opition, most of the ones in config_cmd_default.h are not default commands. Right but if we expect to switch to Kconfig solely for commands selection we may not care much about contents of "config_cmd_default.h" assuming it will go away sometime soon. Probably we may just focus on: 1. Add all existing commands in Kconfig 2. Select very few of them to be globally default (1) is pretty simple and anybody may do it if time permits (2) requires wide discussion But what's really nice with Kconfig is its "savedefconfig". So we may not set any commands as globally default and let every architecture, board or defconfig to select really required options. Then once any option is marked as global (or even arch or board) default in a matter of simple script that does "make XXX_defconfig && make savedefconfig && mv defconfig configs/XXX_defconfig" all relevant defconfigs will be correctly updated (default options will be stripped out). -Alexey
Hi, On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Simon, Masahiro-san, > > On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: >> > >> >> Probably I'm missing details of our Kconfig migration plan if one >> >> exists. Then I'd like to get a reference to the plan so I'm not >> >> attempting to do things that are already scheduled and could be even in >> >> a process of implementation. >> >> Otherwise if there's no current plan for Kconfig migration we may start >> >> discussion on how to deal with "commands" in particular. >> > >> > >> > I proposed the following way, but no big conversion movement has happened yet. >> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 >> > >> > If you have an idea, please propose it. > > Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 > failed". Do you mind to provide a link for the same message in > http://lists.denx.de ? > > >> > Kconfig conversion is a too big task to be done by a single indivisual. >> > Any suggestion, any form of contribution is very appreciated. > > Indeed and that stops me from starting this work as well. > So my point is: > 1) anybody may do updates to Kconfig like add more U-Boot commands, > some settings (CONFIG_SYS_xxx) > 2) board maintainers are responsible for updates in defconfigs and > corresponding headers in "include/configs/" > 3) that would be helpful if at (1) board maintainers are notified via > direct emails on the change that has been done > >> > I personally keep away from any global changes until >> > non-generic boards are dumped. >> > >> > As Tom said in the following mail, >> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html >> > we are going to remove lots of boards. >> > >> > I do not want to make extra efforts on non-generic boards. > > That makes sense but why don't we start implementation of changes in > good boards we know already converted to "generic"? There're even entire > arches that switched to "generic boards". > >> >> The point is commands are low-hanging fruits in terms of Kconfig >> >> migration - there're no extra options and tweaks, once all commands are >> >> added in Kconfig (essentially with dependencies etc) we may clean all >> >> board headers. The only real problem here is amount of work - lots of >> >> headers/defconfigs to patch. But still this is doable. >> > >> > >> > I realized one problem when I was doing this task >> > for my boards in commit 25e274e20208. >> > >> > The defconfigs of my boards are almost the same: >> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) >> > >> > What is inconvenient as for defconfig is that >> > it does not support "include" directive like C headers. >> > >> > People generally like to add CONFIG_CMD_* to a common header file >> > such as include/configs/tegra-common.h >> > >> > On the other hand, on defconfig, we must touch each defconfig of the board family. >> > >> > I have not been able to decide right direction to solve this issue. >> > >> > I think we need to discuss about how to live with lots of defconfigs. >> >> How about this: >> >> 1. Support an 'include' option in defconfig to include another file. >> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated >> list of filenames). Don't allow nested includes - this CONFIG provides >> a complete list of includes. >> 2. When you use menuconfig to edit the config, it ignores the include >> and just writes out everything. Then it runs a simple script which >> parses the include files, and adjusts the file so that things in the >> includes are not repeated in the defconfig. >> >> I think this scheme would be good enough, but can probably be >> improved. At least it would be better than what we have. >> >> Or we could instead define particular includes for different purposes: >> >> - Arch >> - SOC >> - SOC Vendor >> - Board vendor >> - Board family >> >> We could then require that standard filenames are used, and search for >> the correct file based on the SOC/board/vendor setting, etc. >> >> As an example, for trimslice, we could search for arm.h, tegra.h, >> nvidia.h, compulab.h, some_family_name.h. >> >> This is less flexible though. > > Frankly I don't like this approach with post-processing steps. It will > inevitably end-up with messed up configs. > > Why don't we just use default values in Kconfig for ARCH/SOC/Board? > It's pretty obvious that 1 board may have N flavors but then have a > baseline options selected in "board/vendor/board_name/Kconfig" and only > put options that differ between boards in your defconfigs. > > This way "savedefconfig" will automatically strip down all extra lines > for a particular board. > > This is how things work in Linux kernel and Buildroot Kconfig-based > build systems. Probably I'm missing something here because U-Boot > differs from mentioned projects in some aspects - if so please correct > me. I started with this approach and Masahiro was not very keen on it. I'm OK with it, particularly as it is already supported, but I wonder whether we can do better. I notice that some kernel distributions have a script which pulls out common kernel configs in a separate file (e.g. for ARM, or for Tegra) for checking into source control, then combine them again for the kernel. This suggests that others have this problem too. It does seem like a convenient feature to be able to have some sort of hierarchy of config. Re messed-up configs, what will mess up? We can make it part of writing the config, perhaps. > >> >> >> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense >> >> for most of boards, as well as some others. >> >> >> >> And I think during migration process of commands to Kconfig it's a good >> >> time to reconsider default commands. >> > >> > Agree. >> > We should reconsider the default. >> > In my opition, most of the ones in config_cmd_default.h are not default commands. > > Right but if we expect to switch to Kconfig solely for commands > selection we may not care much about contents of "config_cmd_default.h" > assuming it will go away sometime soon. > > Probably we may just focus on: > 1. Add all existing commands in Kconfig > 2. Select very few of them to be globally default > > (1) is pretty simple and anybody may do it if time permits > (2) requires wide discussion > > But what's really nice with Kconfig is its "savedefconfig". So we may > not set any commands as globally default and let every architecture, > board or defconfig to select really required options. > > Then once any option is marked as global (or even arch or board) default > in a matter of simple script that does "make XXX_defconfig && make > savedefconfig && mv defconfig configs/XXX_defconfig" all relevant > defconfigs will be correctly updated (default options will be stripped > out). Yes, it would be great to get all command configs into Kconfig. I wonder if we need a script which automates the conversion? The header file includes in the include/configs/... files makes this non-trivial. But if we had a script which could take a CONFIG as a parameter, remove it from all config headers, and add it to relevant defconfigs, it would be very useful. Regards, Simon
Hi Alexey, 2015-01-14 17:18 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>: > Hi Simon, Masahiro-san, > > On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: >> > >> >> Probably I'm missing details of our Kconfig migration plan if one >> >> exists. Then I'd like to get a reference to the plan so I'm not >> >> attempting to do things that are already scheduled and could be even in >> >> a process of implementation. >> >> Otherwise if there's no current plan for Kconfig migration we may start >> >> discussion on how to deal with "commands" in particular. >> > >> > >> > I proposed the following way, but no big conversion movement has happened yet. >> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 >> > >> > If you have an idea, please propose it. > > Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 > failed". Do you mind to provide a link for the same message in > http://lists.denx.de ? Weird. I can access the link. The subject is [RFC] How to move lots of CONFIGs from header files to Kconfig Another URL is http://lists.denx.de/pipermail/u-boot/2014-October/193117.html > >> > Kconfig conversion is a too big task to be done by a single indivisual. >> > Any suggestion, any form of contribution is very appreciated. > > Indeed and that stops me from starting this work as well. > So my point is: > 1) anybody may do updates to Kconfig like add more U-Boot commands, > some settings (CONFIG_SYS_xxx) Yes, U-Boot is an open source project. Anybody can contribute and it is very appreciated. > 2) board maintainers are responsible for updates in defconfigs and > corresponding headers in "include/configs/" Yes. I expect this, but some board maintainers might not like to do it for some reason. ( too busy, no interest , etc.) At some point, we need to convert globally, I think. > 3) that would be helpful if at (1) board maintainers are notified via > direct emails on the change that has been done Yes, good idea. >> > I personally keep away from any global changes until >> > non-generic boards are dumped. >> > >> > As Tom said in the following mail, >> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html >> > we are going to remove lots of boards. >> > >> > I do not want to make extra efforts on non-generic boards. > > That makes sense but why don't we start implementation of changes in > good boards we know already converted to "generic"? There're even entire > arches that switched to "generic boards". Yes, we can start with well-maintained boards. >> >> The point is commands are low-hanging fruits in terms of Kconfig >> >> migration - there're no extra options and tweaks, once all commands are >> >> added in Kconfig (essentially with dependencies etc) we may clean all >> >> board headers. The only real problem here is amount of work - lots of >> >> headers/defconfigs to patch. But still this is doable. >> > >> > >> > I realized one problem when I was doing this task >> > for my boards in commit 25e274e20208. >> > >> > The defconfigs of my boards are almost the same: >> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) >> > >> > What is inconvenient as for defconfig is that >> > it does not support "include" directive like C headers. >> > >> > People generally like to add CONFIG_CMD_* to a common header file >> > such as include/configs/tegra-common.h >> > >> > On the other hand, on defconfig, we must touch each defconfig of the board family. >> > >> > I have not been able to decide right direction to solve this issue. >> > >> > I think we need to discuss about how to live with lots of defconfigs. >> >> How about this: >> >> 1. Support an 'include' option in defconfig to include another file. >> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated >> list of filenames). Don't allow nested includes - this CONFIG provides >> a complete list of includes. >> 2. When you use menuconfig to edit the config, it ignores the include >> and just writes out everything. Then it runs a simple script which >> parses the include files, and adjusts the file so that things in the >> includes are not repeated in the defconfig. >> >> I think this scheme would be good enough, but can probably be >> improved. At least it would be better than what we have. >> >> Or we could instead define particular includes for different purposes: >> >> - Arch >> - SOC >> - SOC Vendor >> - Board vendor >> - Board family >> >> We could then require that standard filenames are used, and search for >> the correct file based on the SOC/board/vendor setting, etc. >> >> As an example, for trimslice, we could search for arm.h, tegra.h, >> nvidia.h, compulab.h, some_family_name.h. >> >> This is less flexible though. > > Frankly I don't like this approach with post-processing steps. It will > inevitably end-up with messed up configs. Me neither. I hesitate to drift apart from the Linux's Kconfig. > Why don't we just use default values in Kconfig for ARCH/SOC/Board? > It's pretty obvious that 1 board may have N flavors but then have a > baseline options selected in "board/vendor/board_name/Kconfig" and only > put options that differ between boards in your defconfigs. > This way "savedefconfig" will automatically strip down all extra lines > for a particular board. Indeed. But we need to write 2 lines per CONFIG. This is a disadvantage against defconfig config CMD_FOO default y > This is how things work in Linux kernel and Buildroot Kconfig-based > build systems. Probably I'm missing something here because U-Boot > differs from mentioned projects in some aspects - if so please correct > me. > >> >> >> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense >> >> for most of boards, as well as some others. >> >> >> >> And I think during migration process of commands to Kconfig it's a good >> >> time to reconsider default commands. >> > >> > Agree. >> > We should reconsider the default. >> > In my opition, most of the ones in config_cmd_default.h are not default commands. > > Right but if we expect to switch to Kconfig solely for commands > selection we may not care much about contents of "config_cmd_default.h" > assuming it will go away sometime soon. > > Probably we may just focus on: > 1. Add all existing commands in Kconfig > 2. Select very few of them to be globally default > > (1) is pretty simple and anybody may do it if time permits > (2) requires wide discussion Agreed. > But what's really nice with Kconfig is its "savedefconfig". So we may > not set any commands as globally default and let every architecture, > board or defconfig to select really required options. > > Then once any option is marked as global (or even arch or board) default > in a matter of simple script that does "make XXX_defconfig && make > savedefconfig && mv defconfig configs/XXX_defconfig" all relevant > defconfigs will be correctly updated (default options will be stripped > out). > > -Alexey > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
Hi 2015-01-15 23:46 GMT+09:00 Simon Glass <sjg@chromium.org>: > Hi, > > On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: >> Hi Simon, Masahiro-san, >> >> On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: >>> > >>> >> Probably I'm missing details of our Kconfig migration plan if one >>> >> exists. Then I'd like to get a reference to the plan so I'm not >>> >> attempting to do things that are already scheduled and could be even in >>> >> a process of implementation. >>> >> Otherwise if there's no current plan for Kconfig migration we may start >>> >> discussion on how to deal with "commands" in particular. >>> > >>> > >>> > I proposed the following way, but no big conversion movement has happened yet. >>> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 >>> > >>> > If you have an idea, please propose it. >> >> Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 >> failed". Do you mind to provide a link for the same message in >> http://lists.denx.de ? >> >> >>> > Kconfig conversion is a too big task to be done by a single indivisual. >>> > Any suggestion, any form of contribution is very appreciated. >> >> Indeed and that stops me from starting this work as well. >> So my point is: >> 1) anybody may do updates to Kconfig like add more U-Boot commands, >> some settings (CONFIG_SYS_xxx) >> 2) board maintainers are responsible for updates in defconfigs and >> corresponding headers in "include/configs/" >> 3) that would be helpful if at (1) board maintainers are notified via >> direct emails on the change that has been done >> >>> > I personally keep away from any global changes until >>> > non-generic boards are dumped. >>> > >>> > As Tom said in the following mail, >>> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html >>> > we are going to remove lots of boards. >>> > >>> > I do not want to make extra efforts on non-generic boards. >> >> That makes sense but why don't we start implementation of changes in >> good boards we know already converted to "generic"? There're even entire >> arches that switched to "generic boards". >> >>> >> The point is commands are low-hanging fruits in terms of Kconfig >>> >> migration - there're no extra options and tweaks, once all commands are >>> >> added in Kconfig (essentially with dependencies etc) we may clean all >>> >> board headers. The only real problem here is amount of work - lots of >>> >> headers/defconfigs to patch. But still this is doable. >>> > >>> > >>> > I realized one problem when I was doing this task >>> > for my boards in commit 25e274e20208. >>> > >>> > The defconfigs of my boards are almost the same: >>> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) >>> > >>> > What is inconvenient as for defconfig is that >>> > it does not support "include" directive like C headers. >>> > >>> > People generally like to add CONFIG_CMD_* to a common header file >>> > such as include/configs/tegra-common.h >>> > >>> > On the other hand, on defconfig, we must touch each defconfig of the board family. >>> > >>> > I have not been able to decide right direction to solve this issue. >>> > >>> > I think we need to discuss about how to live with lots of defconfigs. >>> >>> How about this: >>> >>> 1. Support an 'include' option in defconfig to include another file. >>> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated >>> list of filenames). Don't allow nested includes - this CONFIG provides >>> a complete list of includes. >>> 2. When you use menuconfig to edit the config, it ignores the include >>> and just writes out everything. Then it runs a simple script which >>> parses the include files, and adjusts the file so that things in the >>> includes are not repeated in the defconfig. >>> >>> I think this scheme would be good enough, but can probably be >>> improved. At least it would be better than what we have. >>> >>> Or we could instead define particular includes for different purposes: >>> >>> - Arch >>> - SOC >>> - SOC Vendor >>> - Board vendor >>> - Board family >>> >>> We could then require that standard filenames are used, and search for >>> the correct file based on the SOC/board/vendor setting, etc. >>> >>> As an example, for trimslice, we could search for arm.h, tegra.h, >>> nvidia.h, compulab.h, some_family_name.h. >>> >>> This is less flexible though. >> >> Frankly I don't like this approach with post-processing steps. It will >> inevitably end-up with messed up configs. >> >> Why don't we just use default values in Kconfig for ARCH/SOC/Board? >> It's pretty obvious that 1 board may have N flavors but then have a >> baseline options selected in "board/vendor/board_name/Kconfig" and only >> put options that differ between boards in your defconfigs. >> >> This way "savedefconfig" will automatically strip down all extra lines >> for a particular board. >> >> This is how things work in Linux kernel and Buildroot Kconfig-based >> build systems. Probably I'm missing something here because U-Boot >> differs from mentioned projects in some aspects - if so please correct >> me. > > I started with this approach and Masahiro was not very keen on it. I'm > OK with it, particularly as it is already supported, but I wonder > whether we can do better. Honestly, I do not like baseline options in board-Kconfig very much. The advantage is that it works without any change. What I suggested before was to use scripts/kconfig/merge_config.sh. For example, put the SoC baseline options into tegra30_defconfig. Put the difference from that into tegra30_(board).config For example, make tegra30_defconfig tegra30_seaboard.config make tegra30_defconfig tegra30_trimslice.config The disadvantage is that we would have to input more for the configuration and has some impact on other projects such as BuildRoot... Another option is "multi-image". Actually barebox adopted this solution to solve the increasing defconfig problem. In barebox, for example, all the Tegra boards share a single defconfig, "tegra_v7_defconfig" tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... It takes advantage of Device Tree configuration and garbage collection. So, it generates multipule images without increasing memory foot-print. > I notice that some kernel distributions have a script which pulls out > common kernel configs in a separate file (e.g. for ARM, or for Tegra) > for checking into source control, then combine them again for the > kernel. This suggests that others have this problem too. It does seem > like a convenient feature to be able to have some sort of hierarchy of > config. > > Re messed-up configs, what will mess up? We can make it part of > writing the config, perhaps. The hierarchical config strategy makes "savedefconfig" difficult , I think. >> >>> >> >>> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense >>> >> for most of boards, as well as some others. >>> >> >>> >> And I think during migration process of commands to Kconfig it's a good >>> >> time to reconsider default commands. >>> > >>> > Agree. >>> > We should reconsider the default. >>> > In my opition, most of the ones in config_cmd_default.h are not default commands. >> >> Right but if we expect to switch to Kconfig solely for commands >> selection we may not care much about contents of "config_cmd_default.h" >> assuming it will go away sometime soon. >> >> Probably we may just focus on: >> 1. Add all existing commands in Kconfig >> 2. Select very few of them to be globally default >> >> (1) is pretty simple and anybody may do it if time permits >> (2) requires wide discussion >> >> But what's really nice with Kconfig is its "savedefconfig". So we may >> not set any commands as globally default and let every architecture, >> board or defconfig to select really required options. >> >> Then once any option is marked as global (or even arch or board) default >> in a matter of simple script that does "make XXX_defconfig && make >> savedefconfig && mv defconfig configs/XXX_defconfig" all relevant >> defconfigs will be correctly updated (default options will be stripped >> out). > > Yes, it would be great to get all command configs into Kconfig. > > I wonder if we need a script which automates the conversion? The > header file includes in the include/configs/... files makes this > non-trivial. But if we had a script which could take a CONFIG as a > parameter, remove it from all config headers, and add it to relevant > defconfigs, it would be very useful. I have a Python script that moves each CONFIG from header files to defconfig files. I wrote it for my local use, so it might not be very clean. If necessary, I can share it on ML.
Hi Masahiro, On 15 January 2015 at 12:10, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote: > Hi > > 2015-01-15 23:46 GMT+09:00 Simon Glass <sjg@chromium.org>: >> Hi, >> >> On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: >>> Hi Simon, Masahiro-san, >>> >>> On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: >>>> > >>>> >> Probably I'm missing details of our Kconfig migration plan if one >>>> >> exists. Then I'd like to get a reference to the plan so I'm not >>>> >> attempting to do things that are already scheduled and could be even in >>>> >> a process of implementation. >>>> >> Otherwise if there's no current plan for Kconfig migration we may start >>>> >> discussion on how to deal with "commands" in particular. >>>> > >>>> > >>>> > I proposed the following way, but no big conversion movement has happened yet. >>>> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 >>>> > >>>> > If you have an idea, please propose it. >>> >>> Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 >>> failed". Do you mind to provide a link for the same message in >>> http://lists.denx.de ? >>> >>> >>>> > Kconfig conversion is a too big task to be done by a single indivisual. >>>> > Any suggestion, any form of contribution is very appreciated. >>> >>> Indeed and that stops me from starting this work as well. >>> So my point is: >>> 1) anybody may do updates to Kconfig like add more U-Boot commands, >>> some settings (CONFIG_SYS_xxx) >>> 2) board maintainers are responsible for updates in defconfigs and >>> corresponding headers in "include/configs/" >>> 3) that would be helpful if at (1) board maintainers are notified via >>> direct emails on the change that has been done >>> >>>> > I personally keep away from any global changes until >>>> > non-generic boards are dumped. >>>> > >>>> > As Tom said in the following mail, >>>> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html >>>> > we are going to remove lots of boards. >>>> > >>>> > I do not want to make extra efforts on non-generic boards. >>> >>> That makes sense but why don't we start implementation of changes in >>> good boards we know already converted to "generic"? There're even entire >>> arches that switched to "generic boards". >>> >>>> >> The point is commands are low-hanging fruits in terms of Kconfig >>>> >> migration - there're no extra options and tweaks, once all commands are >>>> >> added in Kconfig (essentially with dependencies etc) we may clean all >>>> >> board headers. The only real problem here is amount of work - lots of >>>> >> headers/defconfigs to patch. But still this is doable. >>>> > >>>> > >>>> > I realized one problem when I was doing this task >>>> > for my boards in commit 25e274e20208. >>>> > >>>> > The defconfigs of my boards are almost the same: >>>> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) >>>> > >>>> > What is inconvenient as for defconfig is that >>>> > it does not support "include" directive like C headers. >>>> > >>>> > People generally like to add CONFIG_CMD_* to a common header file >>>> > such as include/configs/tegra-common.h >>>> > >>>> > On the other hand, on defconfig, we must touch each defconfig of the board family. >>>> > >>>> > I have not been able to decide right direction to solve this issue. >>>> > >>>> > I think we need to discuss about how to live with lots of defconfigs. >>>> >>>> How about this: >>>> >>>> 1. Support an 'include' option in defconfig to include another file. >>>> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated >>>> list of filenames). Don't allow nested includes - this CONFIG provides >>>> a complete list of includes. >>>> 2. When you use menuconfig to edit the config, it ignores the include >>>> and just writes out everything. Then it runs a simple script which >>>> parses the include files, and adjusts the file so that things in the >>>> includes are not repeated in the defconfig. >>>> >>>> I think this scheme would be good enough, but can probably be >>>> improved. At least it would be better than what we have. >>>> >>>> Or we could instead define particular includes for different purposes: >>>> >>>> - Arch >>>> - SOC >>>> - SOC Vendor >>>> - Board vendor >>>> - Board family >>>> >>>> We could then require that standard filenames are used, and search for >>>> the correct file based on the SOC/board/vendor setting, etc. >>>> >>>> As an example, for trimslice, we could search for arm.h, tegra.h, >>>> nvidia.h, compulab.h, some_family_name.h. >>>> >>>> This is less flexible though. >>> >>> Frankly I don't like this approach with post-processing steps. It will >>> inevitably end-up with messed up configs. >>> >>> Why don't we just use default values in Kconfig for ARCH/SOC/Board? >>> It's pretty obvious that 1 board may have N flavors but then have a >>> baseline options selected in "board/vendor/board_name/Kconfig" and only >>> put options that differ between boards in your defconfigs. >>> >>> This way "savedefconfig" will automatically strip down all extra lines >>> for a particular board. >>> >>> This is how things work in Linux kernel and Buildroot Kconfig-based >>> build systems. Probably I'm missing something here because U-Boot >>> differs from mentioned projects in some aspects - if so please correct >>> me. >> >> I started with this approach and Masahiro was not very keen on it. I'm >> OK with it, particularly as it is already supported, but I wonder >> whether we can do better. > > Honestly, I do not like baseline options in board-Kconfig very much. > The advantage is that it works without any change. > > > What I suggested before was to use scripts/kconfig/merge_config.sh. > > For example, put the SoC baseline options into tegra30_defconfig. > Put the difference from that into tegra30_(board).config > For example, > > make tegra30_defconfig tegra30_seaboard.config > make tegra30_defconfig tegra30_trimslice.config > > The disadvantage is that we would have to input more for the configuration > and has some impact on other projects such as BuildRoot... Is there any way that tegra30_seaboard could include tegra30 automatically? > > > > Another option is "multi-image". > Actually barebox adopted this solution to solve the increasing > defconfig problem. > > In barebox, for example, all the Tegra boards share a single > defconfig, "tegra_v7_defconfig" > > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... > > It takes advantage of Device Tree configuration and garbage collection. > So, it generates multipule images without increasing memory foot-print. > I've been keen on that approach and have taken some steps for Tegra and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux approach makes this hard. Still I think this is the best solution - fewer boards to build also. > > > >> I notice that some kernel distributions have a script which pulls out >> common kernel configs in a separate file (e.g. for ARM, or for Tegra) >> for checking into source control, then combine them again for the >> kernel. This suggests that others have this problem too. It does seem >> like a convenient feature to be able to have some sort of hierarchy of >> config. >> >> Re messed-up configs, what will mess up? We can make it part of >> writing the config, perhaps. > > The hierarchical config strategy makes "savedefconfig" difficult , I think. > I never said it would be easy. Kconfig wasn't easy. > > >>> >>>> >> >>>> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense >>>> >> for most of boards, as well as some others. >>>> >> >>>> >> And I think during migration process of commands to Kconfig it's a good >>>> >> time to reconsider default commands. >>>> > >>>> > Agree. >>>> > We should reconsider the default. >>>> > In my opition, most of the ones in config_cmd_default.h are not default commands. >>> >>> Right but if we expect to switch to Kconfig solely for commands >>> selection we may not care much about contents of "config_cmd_default.h" >>> assuming it will go away sometime soon. >>> >>> Probably we may just focus on: >>> 1. Add all existing commands in Kconfig >>> 2. Select very few of them to be globally default >>> >>> (1) is pretty simple and anybody may do it if time permits >>> (2) requires wide discussion >>> >>> But what's really nice with Kconfig is its "savedefconfig". So we may >>> not set any commands as globally default and let every architecture, >>> board or defconfig to select really required options. >>> >>> Then once any option is marked as global (or even arch or board) default >>> in a matter of simple script that does "make XXX_defconfig && make >>> savedefconfig && mv defconfig configs/XXX_defconfig" all relevant >>> defconfigs will be correctly updated (default options will be stripped >>> out). >> >> Yes, it would be great to get all command configs into Kconfig. >> >> I wonder if we need a script which automates the conversion? The >> header file includes in the include/configs/... files makes this >> non-trivial. But if we had a script which could take a CONFIG as a >> parameter, remove it from all config headers, and add it to relevant >> defconfigs, it would be very useful. > > I have a Python script that moves each CONFIG from header files to > defconfig files. > > I wrote it for my local use, so it might not be very clean. > > > If necessary, I can share it on ML. Yes please! - Simon
Hi MAsahiro-san, On Fri, 2015-01-16 at 03:36 +0900, Masahiro YAMADA wrote: > Weird. I can access the link. > > The subject is > [RFC] How to move lots of CONFIGs from header files to Kconfig > > > Another URL is > http://lists.denx.de/pipermail/u-boot/2014-October/193117.html Thanks a lot! Now I was able to read your message. And it looks like I was proposing the same options (1) and (2) :-) > work as well. > > So my point is: > > 1) anybody may do updates to Kconfig like add more U-Boot commands, > > some settings (CONFIG_SYS_xxx) > > Yes, U-Boot is an open source project. > Anybody can contribute and it is very appreciated. Here I implicitly meant "anybody" = "either you or me" because we're both interested in that change to be done and sooner is better :-) > > 2) board maintainers are responsible for updates in defconfigs and > > corresponding headers in "include/configs/" > > Yes. I expect this, but some board maintainers might not like to do it > for some reason. > ( too busy, no interest , etc.) That's understood. But probably we may move forward with both implementations: Kconfig & config headers. I really hate to introduce breakages for people so if co-existence of config headers with Kconfig is a matter of few "ifdefs" (an example is my patch for default commands) then why not? In the end once inactive maintainer returns back (for example it was right the case for me recently) he most probably will spend some time on switching to Kconfig just because defconfig way is so much cleaner compared to headers. > At some point, we need to convert globally, I think. Completely agree, and if we're done with well-maintained arches and boards "complete switch" will be as easy as: 1. Removal of more stale boards 2. Auto-conversion of headers to defconfigs with automated script For sure (2) will introduce unexpected behavior for some boards. Then if people start complaining real maintainer or we will incrementally fix things. > > 3) that would be helpful if at (1) board maintainers are notified via > > direct emails on the change that has been done > > Yes, good idea. That's important because not everybody follows mailing list closely especially if their development focus is temporary switched to other projects. > >> > I personally keep away from any global changes until > >> > non-generic boards are dumped. > >> > > >> > As Tom said in the following mail, > >> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html > >> > we are going to remove lots of boards. > >> > > >> > I do not want to make extra efforts on non-generic boards. > > > > That makes sense but why don't we start implementation of changes in > > good boards we know already converted to "generic"? There're even entire > > arches that switched to "generic boards". > > Yes, we can start with well-maintained boards. This is important because "release early, release often". In the very beginning of Kconfig way we'll do many non-optimal or even plain wrong decisions (probably even intentionally just because at that point it could be the best decision we see). And then by the time of "global/complete switch" to Kconfig most of thins will be implemented properly and most of issues fixed. -Alexey
Hi Simon, Masahiro-san, On Thu, 2015-01-15 at 12:44 -0700, Simon Glass wrote: > Hi Masahiro, > > Honestly, I do not like baseline options in board-Kconfig very much. > > The advantage is that it works without any change. > > > > > > What I suggested before was to use scripts/kconfig/merge_config.sh. > > > > For example, put the SoC baseline options into tegra30_defconfig. > > Put the difference from that into tegra30_(board).config > > For example, > > > > make tegra30_defconfig tegra30_seaboard.config > > make tegra30_defconfig tegra30_trimslice.config > > > > The disadvantage is that we would have to input more for the configuration > > and has some impact on other projects such as BuildRoot... Are you saying this approach really works? I mean "make tegra30_defconfig tegra30_seaboard.config". Anyway I don't really like to change behavior of things people used to use. It will produce a lot of confusion instead of convenience of well-known tool. > > > > In barebox, for example, all the Tegra boards share a single > > defconfig, "tegra_v7_defconfig" > > > > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... > > > > It takes advantage of Device Tree configuration and garbage collection. > > So, it generates multipule images without increasing memory foot-print. > > > > I've been keen on that approach and have taken some steps for Tegra > and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux > approach makes this hard. > > Still I think this is the best solution - fewer boards to build also. I do like this approach as well. But there will be pitfalls. Imagine there's say a driver for Ethernet controller which is used on MyBoard1 and MyBoard2. One board may use DMA/Phylib/caches and another doesn't use either of options I listed. This means we need to build 2 instances of the driver, because options that I listed could not be built as extensions to some basic driver. You may think of it like compilation with different flags. Another good example which will inevitable hit me with proposed solution - some of our boards have either replaceable CPU tile or FPGA instead of real silicon CPU. It means that the same one board (read peripherals) could be driven by different CPUs. I mean not only variations of one core (in this case we may build for some base-line configuration of CPU so it will run on all more advanced cores) but it could be binary-incompatible CPUs. It means we'll need to re-build everything (sic!) for each board. Still I'm not saying anything against proposed "multibuild" approach - I do like it, but we need to understand if it may satisfy all of our requirements. Or what will be overheads if we decide to go this way. Probably in my case with binary-incompatible cores the simplest solution will be 2 defconfigs which only differ in CPU version selection. -Alexey
Hi Alexey, On 15 January 2015 at 13:49, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Simon, Masahiro-san, > > On Thu, 2015-01-15 at 12:44 -0700, Simon Glass wrote: >> Hi Masahiro, >> > Honestly, I do not like baseline options in board-Kconfig very much. >> > The advantage is that it works without any change. >> > >> > >> > What I suggested before was to use scripts/kconfig/merge_config.sh. >> > >> > For example, put the SoC baseline options into tegra30_defconfig. >> > Put the difference from that into tegra30_(board).config >> > For example, >> > >> > make tegra30_defconfig tegra30_seaboard.config >> > make tegra30_defconfig tegra30_trimslice.config >> > >> > The disadvantage is that we would have to input more for the configuration >> > and has some impact on other projects such as BuildRoot... > > Are you saying this approach really works? > I mean "make tegra30_defconfig tegra30_seaboard.config". > > Anyway I don't really like to change behavior of things people used to > use. It will produce a lot of confusion instead of convenience of > well-known tool. > >> > >> > In barebox, for example, all the Tegra boards share a single >> > defconfig, "tegra_v7_defconfig" >> > >> > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... >> > >> > It takes advantage of Device Tree configuration and garbage collection. >> > So, it generates multipule images without increasing memory foot-print. >> > >> >> I've been keen on that approach and have taken some steps for Tegra >> and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux >> approach makes this hard. >> >> Still I think this is the best solution - fewer boards to build also. > > I do like this approach as well. > But there will be pitfalls. > > Imagine there's say a driver for Ethernet controller which is used on > MyBoard1 and MyBoard2. One board may use DMA/Phylib/caches and another > doesn't use either of options I listed. > > This means we need to build 2 instances of the driver, because options > that I listed could not be built as extensions to some basic driver. You > may think of it like compilation with different flags. Not a nice driver. Can it not support both at run-time? > > Another good example which will inevitable hit me with proposed solution > - some of our boards have either replaceable CPU tile or FPGA instead of > real silicon CPU. It means that the same one board (read peripherals) > could be driven by different CPUs. I mean not only variations of one > core (in this case we may build for some base-line configuration of CPU > so it will run on all more advanced cores) but it could be > binary-incompatible CPUs. It means we'll need to re-build everything > (sic!) for each board. It would be nice to have a cpu interface to allow multiple CPUs, but yes at present this is where we are. > > Still I'm not saying anything against proposed "multibuild" approach - I > do like it, but we need to understand if it may satisfy all of our > requirements. Or what will be overheads if we decide to go this way. > Probably in my case with binary-incompatible cores the simplest solution > will be 2 defconfigs which only differ in CPU version selection. Yes indeed. Regards, Simon
On Thu, 15 Jan 2015 12:44:16 -0700 Simon Glass <sjg@chromium.org> wrote: > Hi Masahiro, > > On 15 January 2015 at 12:10, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote: > > Hi > > > > 2015-01-15 23:46 GMT+09:00 Simon Glass <sjg@chromium.org>: > >> Hi, > >> > >> On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > >>> Hi Simon, Masahiro-san, > >>> > >>> On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote: > >>>> > > >>>> >> Probably I'm missing details of our Kconfig migration plan if one > >>>> >> exists. Then I'd like to get a reference to the plan so I'm not > >>>> >> attempting to do things that are already scheduled and could be even in > >>>> >> a process of implementation. > >>>> >> Otherwise if there's no current plan for Kconfig migration we may start > >>>> >> discussion on how to deal with "commands" in particular. > >>>> > > >>>> > > >>>> > I proposed the following way, but no big conversion movement has happened yet. > >>>> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089 > >>>> > > >>>> > If you have an idea, please propose it. > >>> > >>> Unfortunately I cannot open this link - I see "Connection to 80.91.229.5 > >>> failed". Do you mind to provide a link for the same message in > >>> http://lists.denx.de ? > >>> > >>> > >>>> > Kconfig conversion is a too big task to be done by a single indivisual. > >>>> > Any suggestion, any form of contribution is very appreciated. > >>> > >>> Indeed and that stops me from starting this work as well. > >>> So my point is: > >>> 1) anybody may do updates to Kconfig like add more U-Boot commands, > >>> some settings (CONFIG_SYS_xxx) > >>> 2) board maintainers are responsible for updates in defconfigs and > >>> corresponding headers in "include/configs/" > >>> 3) that would be helpful if at (1) board maintainers are notified via > >>> direct emails on the change that has been done > >>> > >>>> > I personally keep away from any global changes until > >>>> > non-generic boards are dumped. > >>>> > > >>>> > As Tom said in the following mail, > >>>> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html > >>>> > we are going to remove lots of boards. > >>>> > > >>>> > I do not want to make extra efforts on non-generic boards. > >>> > >>> That makes sense but why don't we start implementation of changes in > >>> good boards we know already converted to "generic"? There're even entire > >>> arches that switched to "generic boards". > >>> > >>>> >> The point is commands are low-hanging fruits in terms of Kconfig > >>>> >> migration - there're no extra options and tweaks, once all commands are > >>>> >> added in Kconfig (essentially with dependencies etc) we may clean all > >>>> >> board headers. The only real problem here is amount of work - lots of > >>>> >> headers/defconfigs to patch. But still this is doable. > >>>> > > >>>> > > >>>> > I realized one problem when I was doing this task > >>>> > for my boards in commit 25e274e20208. > >>>> > > >>>> > The defconfigs of my boards are almost the same: > >>>> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig) > >>>> > > >>>> > What is inconvenient as for defconfig is that > >>>> > it does not support "include" directive like C headers. > >>>> > > >>>> > People generally like to add CONFIG_CMD_* to a common header file > >>>> > such as include/configs/tegra-common.h > >>>> > > >>>> > On the other hand, on defconfig, we must touch each defconfig of the board family. > >>>> > > >>>> > I have not been able to decide right direction to solve this issue. > >>>> > > >>>> > I think we need to discuss about how to live with lots of defconfigs. > >>>> > >>>> How about this: > >>>> > >>>> 1. Support an 'include' option in defconfig to include another file. > >>>> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated > >>>> list of filenames). Don't allow nested includes - this CONFIG provides > >>>> a complete list of includes. > >>>> 2. When you use menuconfig to edit the config, it ignores the include > >>>> and just writes out everything. Then it runs a simple script which > >>>> parses the include files, and adjusts the file so that things in the > >>>> includes are not repeated in the defconfig. > >>>> > >>>> I think this scheme would be good enough, but can probably be > >>>> improved. At least it would be better than what we have. > >>>> > >>>> Or we could instead define particular includes for different purposes: > >>>> > >>>> - Arch > >>>> - SOC > >>>> - SOC Vendor > >>>> - Board vendor > >>>> - Board family > >>>> > >>>> We could then require that standard filenames are used, and search for > >>>> the correct file based on the SOC/board/vendor setting, etc. > >>>> > >>>> As an example, for trimslice, we could search for arm.h, tegra.h, > >>>> nvidia.h, compulab.h, some_family_name.h. > >>>> > >>>> This is less flexible though. > >>> > >>> Frankly I don't like this approach with post-processing steps. It will > >>> inevitably end-up with messed up configs. > >>> > >>> Why don't we just use default values in Kconfig for ARCH/SOC/Board? > >>> It's pretty obvious that 1 board may have N flavors but then have a > >>> baseline options selected in "board/vendor/board_name/Kconfig" and only > >>> put options that differ between boards in your defconfigs. > >>> > >>> This way "savedefconfig" will automatically strip down all extra lines > >>> for a particular board. > >>> > >>> This is how things work in Linux kernel and Buildroot Kconfig-based > >>> build systems. Probably I'm missing something here because U-Boot > >>> differs from mentioned projects in some aspects - if so please correct > >>> me. > >> > >> I started with this approach and Masahiro was not very keen on it. I'm > >> OK with it, particularly as it is already supported, but I wonder > >> whether we can do better. > > > > Honestly, I do not like baseline options in board-Kconfig very much. > > The advantage is that it works without any change. > > > > > > What I suggested before was to use scripts/kconfig/merge_config.sh. > > > > For example, put the SoC baseline options into tegra30_defconfig. > > Put the difference from that into tegra30_(board).config > > For example, > > > > make tegra30_defconfig tegra30_seaboard.config > > make tegra30_defconfig tegra30_trimslice.config > > > > The disadvantage is that we would have to input more for the configuration > > and has some impact on other projects such as BuildRoot... > > Is there any way that tegra30_seaboard could include tegra30 automatically? I do not know the native Kconfig does not have this feature. If this is desired, I think we have to modify the Kconfig for our special demand. > > > > > > > > Another option is "multi-image". > > Actually barebox adopted this solution to solve the increasing > > defconfig problem. > > > > In barebox, for example, all the Tegra boards share a single > > defconfig, "tegra_v7_defconfig" > > > > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... > > > > It takes advantage of Device Tree configuration and garbage collection. > > So, it generates multipule images without increasing memory foot-print. > > > > I've been keen on that approach and have taken some steps for Tegra > and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux > approach makes this hard. > > Still I think this is the best solution - fewer boards to build also. Agree. This multi-image approach high depends on the Driver Model and Device Tree because each driver should not hard-code driver properties such as base-address. In legacy drivers, drivers are configured with CONFIGs. It makes it difficult to share a driver between multiple boards. We have to achieve run-time driver configuration. Let's keep it in our mind as our long-term target! > > > > > > > >> I notice that some kernel distributions have a script which pulls out > >> common kernel configs in a separate file (e.g. for ARM, or for Tegra) > >> for checking into source control, then combine them again for the > >> kernel. This suggests that others have this problem too. It does seem > >> like a convenient feature to be able to have some sort of hierarchy of > >> config. > >> > >> Re messed-up configs, what will mess up? We can make it part of > >> writing the config, perhaps. > > > > The hierarchical config strategy makes "savedefconfig" difficult , I think. > > > > I never said it would be easy. Kconfig wasn't easy. > > > > > > >>> > >>>> >> > >>>> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense > >>>> >> for most of boards, as well as some others. > >>>> >> > >>>> >> And I think during migration process of commands to Kconfig it's a good > >>>> >> time to reconsider default commands. > >>>> > > >>>> > Agree. > >>>> > We should reconsider the default. > >>>> > In my opition, most of the ones in config_cmd_default.h are not default commands. > >>> > >>> Right but if we expect to switch to Kconfig solely for commands > >>> selection we may not care much about contents of "config_cmd_default.h" > >>> assuming it will go away sometime soon. > >>> > >>> Probably we may just focus on: > >>> 1. Add all existing commands in Kconfig > >>> 2. Select very few of them to be globally default > >>> > >>> (1) is pretty simple and anybody may do it if time permits > >>> (2) requires wide discussion > >>> > >>> But what's really nice with Kconfig is its "savedefconfig". So we may > >>> not set any commands as globally default and let every architecture, > >>> board or defconfig to select really required options. > >>> > >>> Then once any option is marked as global (or even arch or board) default > >>> in a matter of simple script that does "make XXX_defconfig && make > >>> savedefconfig && mv defconfig configs/XXX_defconfig" all relevant > >>> defconfigs will be correctly updated (default options will be stripped > >>> out). > >> > >> Yes, it would be great to get all command configs into Kconfig. > >> > >> I wonder if we need a script which automates the conversion? The > >> header file includes in the include/configs/... files makes this > >> non-trivial. But if we had a script which could take a CONFIG as a > >> parameter, remove it from all config headers, and add it to relevant > >> defconfigs, it would be very useful. > > > > I have a Python script that moves each CONFIG from header files to > > defconfig files. > > > > I wrote it for my local use, so it might not be very clean. > > > > > > If necessary, I can share it on ML. > > Yes please! > OK. Please check this out: http://patchwork.ozlabs.org/patch/430422/ Best Regards Masahiro Yamada
Hi Alexey, On Thu, 15 Jan 2015 21:22:42 +0000 Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > > > 3) that would be helpful if at (1) board maintainers are notified via > > > direct emails on the change that has been done > > > > Yes, good idea. > > That's important because not everybody follows mailing list closely > especially if their development focus is temporary switched to other > projects. No problem. Patman automatically CCs board maintainers. Best Regards Masahiro Yamada
On Thu, 15 Jan 2015 21:49:59 +0000 Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: > Hi Simon, Masahiro-san, > > On Thu, 2015-01-15 at 12:44 -0700, Simon Glass wrote: > > Hi Masahiro, > > > Honestly, I do not like baseline options in board-Kconfig very much. > > > The advantage is that it works without any change. > > > > > > > > > What I suggested before was to use scripts/kconfig/merge_config.sh. > > > > > > For example, put the SoC baseline options into tegra30_defconfig. > > > Put the difference from that into tegra30_(board).config > > > For example, > > > > > > make tegra30_defconfig tegra30_seaboard.config > > > make tegra30_defconfig tegra30_trimslice.config > > > > > > The disadvantage is that we would have to input more for the configuration > > > and has some impact on other projects such as BuildRoot... > > Are you saying this approach really works? > I mean "make tegra30_defconfig tegra30_seaboard.config". I admit this would not be accpetable. > Anyway I don't really like to change behavior of things people used to > use. It will produce a lot of confusion instead of convenience of > well-known tool. OK. Let's do not. > > > > > > In barebox, for example, all the Tegra boards share a single > > > defconfig, "tegra_v7_defconfig" > > > > > > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... > > > > > > It takes advantage of Device Tree configuration and garbage collection. > > > So, it generates multipule images without increasing memory foot-print. > > > > > > > I've been keen on that approach and have taken some steps for Tegra > > and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux > > approach makes this hard. > > > > Still I think this is the best solution - fewer boards to build also. > > I do like this approach as well. > But there will be pitfalls. > > Imagine there's say a driver for Ethernet controller which is used on > MyBoard1 and MyBoard2. One board may use DMA/Phylib/caches and another > doesn't use either of options I listed. > > This means we need to build 2 instances of the driver, because options > that I listed could not be built as extensions to some basic driver. You > may think of it like compilation with different flags. We should not mix-up configurations and board properties. - Cache on/off is configuration: It should be configured thru Kconfig. Some might want to run a board with cache-enabled, and some might want to run the same board with cached-disabled. This makes sense. - CONFIG_FOO_BASE_ADDRESS is not configuration: Each board has its correct value. It must be passed from device tree, platform data or some other structures. Such CONFIGs will eventually go away if we move forward the Driver Model works. > Another good example which will inevitable hit me with proposed solution > - some of our boards have either replaceable CPU tile or FPGA instead of > real silicon CPU. It means that the same one board (read peripherals) > could be driven by different CPUs. I mean not only variations of one > core (in this case we may build for some base-line configuration of CPU > so it will run on all more advanced cores) but it could be > binary-incompatible CPUs. It means we'll need to re-build everything > (sic!) for each board. Drivers should be written in a generic way so as not to depend on a specific ARCH/CPU. If it is still not possible, OK, your boards cannot support multi-image. Prepare defconfig per board as we do now. I would not go as far as say all the boards should switch to multi-image build. It is a good idea to adopt multi-image-build if there are lots of board variants (like Tegra). > Still I'm not saying anything against proposed "multibuild" approach - I > do like it, but we need to understand if it may satisfy all of our > requirements. Or what will be overheads if we decide to go this way. > Probably in my case with binary-incompatible cores the simplest solution > will be 2 defconfigs which only differ in CPU version selection. > This is the case multi-image cannot be used. You have to separate the defconfigs. Best Regards Masahiro Yamada
Hi Simon, Alexey, On Thu, 15 Jan 2015 12:44:16 -0700 Simon Glass <sjg@chromium.org> wrote: >>> Frankly I don't like this approach with post-processing steps. It will >>> inevitably end-up with messed up configs. >>> >>> Why don't we just use default values in Kconfig for ARCH/SOC/Board? >>> It's pretty obvious that 1 board may have N flavors but then have a >>> baseline options selected in "board/vendor/board_name/Kconfig" and only >>> put options that differ between boards in your defconfigs. >>> >>> This way "savedefconfig" will automatically strip down all extra lines >>> for a particular board. >>> >>> This is how things work in Linux kernel and Buildroot Kconfig-based >>> build systems. Probably I'm missing something here because U-Boot >>> differs from mentioned projects in some aspects - if so please correct >>> me. >> >> I started with this approach and Masahiro was not very keen on it. I'm >> OK with it, particularly as it is already supported, but I wonder >> whether we can do better. Shall we go with this way? It is true that I was not very keen on it at first, but after discussion with you, I understand that this is the best solution we can do now in terms of code maintainability. Best Regards Masahiro Yamada
Hi Masahiro, On 19 January 2015 at 21:52, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, Alexey, > > > On Thu, 15 Jan 2015 12:44:16 -0700 > Simon Glass <sjg@chromium.org> wrote: >>>> Frankly I don't like this approach with post-processing steps. It will >>>> inevitably end-up with messed up configs. >>>> >>>> Why don't we just use default values in Kconfig for ARCH/SOC/Board? >>>> It's pretty obvious that 1 board may have N flavors but then have a >>>> baseline options selected in "board/vendor/board_name/Kconfig" and only >>>> put options that differ between boards in your defconfigs. >>>> >>>> This way "savedefconfig" will automatically strip down all extra lines >>>> for a particular board. >>>> >>>> This is how things work in Linux kernel and Buildroot Kconfig-based >>>> build systems. Probably I'm missing something here because U-Boot >>>> differs from mentioned projects in some aspects - if so please correct >>>> me. >>> >>> I started with this approach and Masahiro was not very keen on it. I'm >>> OK with it, particularly as it is already supported, but I wonder >>> whether we can do better. > > > Shall we go with this way? > > It is true that I was not very keen on it at first, > but after discussion with you, I understand that > this is the best solution we can do now in terms of > code maintainability. Yes I'm OK with it. Clearly there is a need for Kconfig to do better in this area, but I don't believe it is critical. Regards, Simon
diff --git a/common/Kconfig b/common/Kconfig index fd84fa0..cbc4f5b 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -24,11 +24,13 @@ menu "Info commands" config CMD_BDI bool "bdinfo" + default y help Print board info config CMD_CONSOLE bool "coninfo" + default y help Print console devices and information. @@ -43,6 +45,7 @@ menu "Boot commands" config CMD_BOOTD bool "bootd" + default y help Run the command stored in the environment "bootcmd", i.e. "bootd" does the same thing as "run bootcmd". @@ -61,11 +64,13 @@ config CMD_GO config CMD_RUN bool "run" + default y help Run the command in the given environment variable. config CMD_IMI bool "iminfo" + default y help Print header information for application image. @@ -76,6 +81,7 @@ config CMD_IMLS config CMD_XIMG bool "imxtract" + default y help Extract a part of a multi-image. @@ -97,11 +103,13 @@ config CMD_IMPORTENV config CMD_EDITENV bool "editenv" + default y help Edit environment variable. config CMD_SAVEENV bool "saveenv" + default y help Run the command in the given environment variable. @@ -111,6 +119,7 @@ menu "Memory commands" config CMD_MEMORY bool "md, mm, nm, mw, cp, cmp, base, loop" + default y help Memeory commands. md - memory display @@ -155,11 +164,13 @@ menu "Device access commands" config CMD_LOADB bool "loadb" + default y help Load a binary file over serial line. config CMD_LOADS bool "loads" + default y help Load an S-Record file over serial line @@ -193,6 +204,7 @@ config CMD_USB config CMD_FPGA bool "fpga" + default y help FPGA support. @@ -203,16 +215,19 @@ menu "Shell scripting commands" config CMD_ECHO bool "echo" + default y help Echo args to console config CMD_ITEST bool "itest" + default y help Return true/false on integer compare. config CMD_SOURCE bool "source" + default y help Run script from memory @@ -222,6 +237,7 @@ menu "Network commands" config CMD_NET bool "bootp, tftpboot" + default y help Network commands. bootp - boot image via network using BOOTP/TFTP protocol @@ -249,6 +265,7 @@ config CMD_DHCP config CMD_NFS bool "nfs" + default y help Boot image via network using NFS protocol. @@ -294,6 +311,7 @@ config CMD_TIME # TODO: rename to CMD_SLEEP config CMD_MISC bool "sleep" + default y help Delay execution for some time @@ -304,6 +322,7 @@ config CMD_TIMER config CMD_SETGETDCR bool "getdcr, setdcr, getidcr, setidcr" + default y depends on 4xx help getdcr - Get an AMCC PPC 4xx DCR's value
Now when we may select commands via menuconfig let's adjust default settings with "config_cmd_default.h". As the next step we may get rid of "config_cmd_default.h" inclusion in "include/configs/*.h" and "config_cmd_default.h" itself. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Rini <trini@ti.com> --- common/Kconfig | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)