On Thu, 15 Jan 2015 12:44:16 -0700 Simon Glass <s...@chromium.org> wrote:
> Hi Masahiro, > > On 15 January 2015 at 12:10, Masahiro YAMADA <yamad...@jp.panasonic.com> > wrote: > > Hi > > > > 2015-01-15 23:46 GMT+09:00 Simon Glass <s...@chromium.org>: > >> Hi, > >> > >> On 14 January 2015 at 01:18, Alexey Brodkin <alexey.brod...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot