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

[Simon Glass]

Hi Alexey,

On 15 January 2015 at 13:49, 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".
>
> 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