[U-Boot] [PATCH 1/2] common: mark commands as default to match "config_cmd_default.h"

[Masahiro Yamada]

On Thu, 15 Jan 2015 12:44:16 -0700
Simon Glass <sjg at chromium.org> wrote:

> Hi Masahiro,
> 
> On 15 January 2015 at 12:10, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
> > Hi
> >
> > 2015-01-15 23:46 GMT+09:00 Simon Glass <sjg at chromium.org>:
> >> Hi,
> >>
> >> On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin at 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