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

[Alexey Brodkin]

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