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

[Masahiro Yamada]

On Thu, 15 Jan 2015 21:49:59 +0000
Alexey Brodkin <Alexey.Brodkin at 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