[U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
Synchronize Gen3 defconfigs in wake of the Kconfig option changes. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- configs/r8a77965_salvator-x_defconfig | 1 - configs/r8a7796_salvator-x_defconfig | 1 - configs/r8a7796_ulcb_defconfig| 1 - 3 files changed, 3 deletions(-) diff --git a/configs/r8a77965_salvator-x_defconfig b/configs/r8a77965_salvator-x_defconfig index 82ebab06c3..9965036123 100644 --- a/configs/r8a77965_salvator-x_defconfig +++ b/configs/r8a77965_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_salvator-x_defconfig b/configs/r8a7796_salvator-x_defconfig index ae0555cd85..09626bf8b6 100644 --- a/configs/r8a7796_salvator-x_defconfig +++ b/configs/r8a7796_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig index f3781a57e2..1f2de9d71b 100644 --- a/configs/r8a7796_ulcb_defconfig +++ b/configs/r8a7796_ulcb_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_ULCB=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
Hello Marek,
Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar.
Do you think it would make sense to relocate the common parts into
rcar{3,-gen3}_defconfig and the unique per-board options into config
fragments resembling the current R-Car3 defconfig structure?
$> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
configs/r8a7795_salvator-x.cfg
configs/r8a7795_ulcb.cfg
configs/r8a77965_salvator-x.cfg
configs/r8a7796_salvator-x.cfg
configs/r8a7796_ulcb.cfg
configs/r8a77970_eagle.cfg
configs/r8a77990_ebisu.cfg
configs/r8a77995_draak.cfg
In this case, I believe each fragment would contain under 10 Kconfig
symbols and the `make _defconfig` procedure would change
to `make rcar{3,-gen3}_defconfig .cfg`.
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
> Hello Marek,
Hi,
> Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar.
That's the goal for this release, to make them look similar.
> Do you think it would make sense to relocate the common parts into
> rcar{3,-gen3}_defconfig and the unique per-board options into config
> fragments resembling the current R-Car3 defconfig structure?
>
> $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
> configs/r8a7795_salvator-x.cfg
> configs/r8a7795_ulcb.cfg
> configs/r8a77965_salvator-x.cfg
> configs/r8a7796_salvator-x.cfg
> configs/r8a7796_ulcb.cfg
> configs/r8a77970_eagle.cfg
> configs/r8a77990_ebisu.cfg
> configs/r8a77995_draak.cfg
>
> In this case, I believe each fragment would contain under 10 Kconfig
> symbols and the `make _defconfig` procedure would change
> to `make rcar{3,-gen3}_defconfig .cfg`.
I was pondering whether there's some way to factor out the common parts,
or maybe even replace some of the defconfigs with a placeholder for
compatibility reasons and just go with one full defconfig for all SoCs
(H3/M3W/M3N) that can be on such a board.
I'd still like to be able to do "make soc_board_defconfig ; make"
without having to rack my brain which other .cfg files I need to append.
I didn't find a good solution for this however. Do you know of one ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
cc: Masahiro (due to Kconfig topic)
Hi Marek,
On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote:
> On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
> > Hello Marek,
<-snip->
> > Do you think it would make sense to relocate the common parts into
> > rcar{3,-gen3}_defconfig and the unique per-board options into config
> > fragments resembling the current R-Car3 defconfig structure?
> >
> > $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
> > configs/r8a7795_salvator-x.cfg
> > configs/r8a7795_ulcb.cfg
> > configs/r8a77965_salvator-x.cfg
> > configs/r8a7796_salvator-x.cfg
> > configs/r8a7796_ulcb.cfg
> > configs/r8a77970_eagle.cfg
> > configs/r8a77990_ebisu.cfg
> > configs/r8a77995_draak.cfg
> >
> > In this case, I believe each fragment would contain under 10 Kconfig
> > symbols and the `make _defconfig` procedure would change
> > to `make rcar{3,-gen3}_defconfig .cfg`.
>
> I was pondering whether there's some way to factor out the common parts,
> or maybe even replace some of the defconfigs with a placeholder for
> compatibility reasons and just go with one full defconfig for all SoCs
> (H3/M3W/M3N) that can be on such a board.
>
> I'd still like to be able to do "make soc_board_defconfig ; make"
> without having to rack my brain which other .cfg files I need to append.
> I didn't find a good solution for this however. Do you know of one ?
I think we have proper tools to track the correctness of the defconfig
files (i.e. savedefconfig Kbuild target), but we don't seem to have
proper tools to validate configuration fragments. So, I agree the
contents of the fragments would potentially go wild. I think having
either a built-in Kbuild/Kconfig procedure or some scripted way to keep
the fragments under control would greatly increase the confidence in
using them, but I am unaware of such.
JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3
defconfigs:
$> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779*
configs/r8a7795_salvator-x_defconfig
configs/r8a7795_salvator-xs-2x2g_defconfig
configs/r8a7795_salvator-xs-4x2g_defconfig
configs/r8a7795_salvator-xs_defconfig
configs/r8a7795_ulcb-4x2g_defconfig
configs/r8a7795_ulcb_defconfig
configs/r8a77965_salvator-x_defconfig
configs/r8a77965_salvator-xs_defconfig
configs/r8a77965_ulcb_defconfig
configs/r8a7796_salvator-x_defconfig
configs/r8a7796_salvator-xs_defconfig
configs/r8a7796_ulcb_defconfig
configs/r8a77970_eagle_defconfig
configs/r8a77990_ebisu-4d_defconfig
configs/r8a77990_ebisu_defconfig
configs/r8a77995_draak_defconfig
So, changing/adding/removing a common option (most of them are) implies
quite an amount of maintenance effort on our side. I would greatly
appreciate any ideas how to alleviate that.
>
> --
> Best regards,
> Marek Vasut
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
On 3/5/19 12:40 AM, Eugeniu Rosca wrote:
> cc: Masahiro (due to Kconfig topic)
>
> Hi Marek,
Hi,
> On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote:
>> On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
>>> Hello Marek,
>
> <-snip->
>
>>> Do you think it would make sense to relocate the common parts into
>>> rcar{3,-gen3}_defconfig and the unique per-board options into config
>>> fragments resembling the current R-Car3 defconfig structure?
>>>
>>> $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
>>> configs/r8a7795_salvator-x.cfg
>>> configs/r8a7795_ulcb.cfg
>>> configs/r8a77965_salvator-x.cfg
>>> configs/r8a7796_salvator-x.cfg
>>> configs/r8a7796_ulcb.cfg
>>> configs/r8a77970_eagle.cfg
>>> configs/r8a77990_ebisu.cfg
>>> configs/r8a77995_draak.cfg
>>>
>>> In this case, I believe each fragment would contain under 10 Kconfig
>>> symbols and the `make _defconfig` procedure would change
>>> to `make rcar{3,-gen3}_defconfig .cfg`.
>>
>> I was pondering whether there's some way to factor out the common parts,
>> or maybe even replace some of the defconfigs with a placeholder for
>> compatibility reasons and just go with one full defconfig for all SoCs
>> (H3/M3W/M3N) that can be on such a board.
>>
>> I'd still like to be able to do "make soc_board_defconfig ; make"
>> without having to rack my brain which other .cfg files I need to append.
>> I didn't find a good solution for this however. Do you know of one ?
>
> I think we have proper tools to track the correctness of the defconfig
> files (i.e. savedefconfig Kbuild target), but we don't seem to have
> proper tools to validate configuration fragments. So, I agree the
> contents of the fragments would potentially go wild. I think having
> either a built-in Kbuild/Kconfig procedure or some scripted way to keep
> the fragments under control would greatly increase the confidence in
> using them, but I am unaware of such.
>
> JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3
> defconfigs:
>
> $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779*
> configs/r8a7795_salvator-x_defconfig
> configs/r8a7795_salvator-xs-2x2g_defconfig
> configs/r8a7795_salvator-xs-4x2g_defconfig
> configs/r8a7795_salvator-xs_defconfig
> configs/r8a7795_ulcb-4x2g_defconfig
> configs/r8a7795_ulcb_defconfig
> configs/r8a77965_salvator-x_defconfig
> configs/r8a77965_salvator-xs_defconfig
> configs/r8a77965_ulcb_defconfig
> configs/r8a7796_salvator-x_defconfig
> configs/r8a7796_salvator-xs_defconfig
> configs/r8a7796_ulcb_defconfig
> configs/r8a77970_eagle_defconfig
> configs/r8a77990_ebisu-4d_defconfig
> configs/r8a77990_ebisu_defconfig
> configs/r8a77995_draak_defconfig
>
> So, changing/adding/removing a common option (most of them are) implies
> quite an amount of maintenance effort on our side. I would greatly
> appreciate any ideas how to alleviate that.
Mainline ATF passes the DRAM configuration to U-Boot as a DT fragment in
register x1, so that takes care of those defconfigs for different DRAM
sizes (I just need to upstream patch which parses that DT fragment,
which is work in progress [1]; for next release).
The salvator-x and salvator-xs differences aren't applicable to U-Boot,
so we can ignore those for now. Once they become applicable, we can
probably use the ATF DT fragment to discern those two board revisions too.
r8a779{5,6,65}_salvator-x_defconfig and r8a779{5,6,65}_ulcb_defconfig
could be merged into single defconfig using multi-dtb FIT, it makes the
U-Boot grow quite a bit, but this might be OK here. We already do that.
And ultimately, I don't think we'll need any fragments if we end up with
a defconfig for r8a779*_salvator-x, r8a779*_ulcb, r8a77970_eagle,
r8a77990_ebisu, r8a77995_draak , that's 5 targets in total. We might add
r8a77980_condor at some point, but that's still manageable.
So in my opinion, all we need to figure out now is how to maintain some
sort of backward compatibility, and have eg r8a7795_salvator-x_defconfig
become a symlink (?) to some r8a779x_salvator-x_defconfig . Thoughts ?
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=95413
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
Hi.
Sorry for chiming in late.
On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca wrote:
>
> cc: Masahiro (due to Kconfig topic)
>
> Hi Marek,
>
> On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote:
> > On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
> > > Hello Marek,
>
> <-snip->
>
> > > Do you think it would make sense to relocate the common parts into
> > > rcar{3,-gen3}_defconfig and the unique per-board options into config
> > > fragments resembling the current R-Car3 defconfig structure?
> > >
> > > $> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
> > > configs/r8a7795_salvator-x.cfg
> > > configs/r8a7795_ulcb.cfg
> > > configs/r8a77965_salvator-x.cfg
> > > configs/r8a7796_salvator-x.cfg
> > > configs/r8a7796_ulcb.cfg
> > > configs/r8a77970_eagle.cfg
> > > configs/r8a77990_ebisu.cfg
> > > configs/r8a77995_draak.cfg
> > >
> > > In this case, I believe each fragment would contain under 10 Kconfig
> > > symbols and the `make _defconfig` procedure would change
> > > to `make rcar{3,-gen3}_defconfig .cfg`.
In fact, I suggested
make _defconfig .config
some time ago, but I did not get positive feedback.
The reason was, it would be tedious to type a series of config files,
and also it would break the upper-level projects
such as OE recipes, buildroot, etc.
> > I was pondering whether there's some way to factor out the common parts,
> > or maybe even replace some of the defconfigs with a placeholder for
> > compatibility reasons and just go with one full defconfig for all SoCs
> > (H3/M3W/M3N) that can be on such a board.
I manage my boards this way.
I have only three defconfig files:
uniphier_ld4_sld8_defconfig
uniphier_v7_defconfig
uniphier_v8_defconfig
Each defconfig supports multiple boards
by using a different DEVICE_TREE.
If you are interested, doc/README.uniphier
explains it supports much more boards than defconfig.
The drawback of this ways will increase the image size
since it needs to compile-in all necessary
boot-code and drivers.
So, this solution only works when you have enough
memory footprint.
> >
> > I'd still like to be able to do "make soc_board_defconfig ; make"
> > without having to rack my brain which other .cfg files I need to append.
> > I didn't find a good solution for this however. Do you know of one ?
One idea might be,
to hack scripts/kconfig/Makefile
to allow a defconfig to contain shell scripts.
For example, r8a7795_salvator-x_defconfig will look like:
#!/bin/sh
$MAKE r8a7795_defconfig
$MAKE r8a7795_salvator-x.config
Makefile will run it if the first line is shebang,
otherwise handle it as a normal defconfig.
I am not so sure if this is the right thing to do.
So, it should be discussed widely anyway if we try to
introduce something new.
A problem in this way is, as Eugeniu pointed out,
we have no way to sync .config fragment files.
> I think we have proper tools to track the correctness of the defconfig
> files (i.e. savedefconfig Kbuild target), but we don't seem to have
> proper tools to validate configuration fragments. So, I agree the
> contents of the fragments would potentially go wild. I think having
> either a built-in Kbuild/Kconfig procedure or some scripted way to keep
> the fragments under control would greatly increase the confidence in
> using them, but I am unaware of such.
You are right.
We will need something like savedefconfig for .config files,
but we do not have a good tool. At least, I do not know.
Thanks.
> JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3
> defconfigs:
>
> $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779*
> configs/r8a7795_salvator-x_defconfig
> configs/r8a7795_salvator-xs-2x2g_defconfig
> configs/r8a7795_salvator-xs-4x2g_defconfig
> configs/r8a7795_salvator-xs_defconfig
> configs/r8a7795_ulcb-4x2g_defconfig
> configs/r8a7795_ulcb_defconfig
> configs/r8a77965_salvator-x_defconfig
> configs/r8a77965_salvator-xs_defconfig
> configs/r8a77965_ulcb_defconfig
> configs/r8a7796_salvator-x_defconfig
> configs/r8a7796_salvator-xs_defconfig
> configs/r8a7796_ulcb_defconfig
> configs/r8a77970_eagle_defconfig
> configs/r8a77990_ebisu-4d_defconfig
> configs/r8a77990_ebisu_defconfig
> configs/r8a77995_draak_defconfig
>
> So, changing/adding/removing a common option (most of them are) implies
> quite an amount of maintenance effort on our side. I would greatly
> appreciate any ideas how to alleviate that.
>
> >
> > --
> > Best regards,
> > Marek Vasut
>
> Best regards,
> Eugeniu.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
On 07/Mar/2019 22:54, Masahiro Yamada wrote:
<...>
> Each defconfig supports multiple boards
> by using a different DEVICE_TREE.
>
> If you are interested, doc/README.uniphier
> explains it supports much more boards than defconfig.
>
> The drawback of this ways will increase the image size
> since it needs to compile-in all necessary
> boot-code and drivers.
> So, this solution only works when you have enough
> memory footprint.
>
>
> > >
> > > I'd still like to be able to do "make soc_board_defconfig ; make"
> > > without having to rack my brain which other .cfg files I need to append.
> > > I didn't find a good solution for this however. Do you know of one ?
>
> One idea might be,
> to hack scripts/kconfig/Makefile
> to allow a defconfig to contain shell scripts.
>
>
> For example, r8a7795_salvator-x_defconfig will look like:
>
> #!/bin/sh
> $MAKE r8a7795_defconfig
> $MAKE r8a7795_salvator-x.config
>
>
> Makefile will run it if the first line is shebang,
> otherwise handle it as a normal defconfig.
>
>
> I am not so sure if this is the right thing to do.
> So, it should be discussed widely anyway if we try to
> introduce something new.
>
> A problem in this way is, as Eugeniu pointed out,
> we have no way to sync .config fragment files.
>
>
> > I think we have proper tools to track the correctness of the defconfig
> > files (i.e. savedefconfig Kbuild target), but we don't seem to have
> > proper tools to validate configuration fragments. So, I agree the
> > contents of the fragments would potentially go wild. I think having
> > either a built-in Kbuild/Kconfig procedure or some scripted way to keep
> > the fragments under control would greatly increase the confidence in
> > using them, but I am unaware of such.
>
> You are right.
>
> We will need something like savedefconfig for .config files,
> but we do not have a good tool. At least, I do not know.
Perhaps a simpler solution would be to add support for some sort of
selection mechanism. E.g.:
family_defconfig:
A=y if (SOC in {"A", "B", "C"})
board_A.config:
SOC="C"
So that .config files can contain only simple meta-data; and both things
would be easy to validate.
There's a little impedance mismatch here and there, but it could work,
and the needed effort seems reasonable.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
On 3/7/19 2:54 PM, Masahiro Yamada wrote:
> Hi.
Hi!
> Sorry for chiming in late.
>
>
> On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca wrote:
>>
>> cc: Masahiro (due to Kconfig topic)
>>
>> Hi Marek,
>>
>> On Mon, Mar 04, 2019 at 11:03:56PM +0100, Marek Vasut wrote:
>>> On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
Hello Marek,
>>
>> <-snip->
>>
Do you think it would make sense to relocate the common parts into
rcar{3,-gen3}_defconfig and the unique per-board options into config
fragments resembling the current R-Car3 defconfig structure?
$> u-boot-master (master) ls -1 configs/r8a779* | sed 's/_defconfig/.cfg/'
configs/r8a7795_salvator-x.cfg
configs/r8a7795_ulcb.cfg
configs/r8a77965_salvator-x.cfg
configs/r8a7796_salvator-x.cfg
configs/r8a7796_ulcb.cfg
configs/r8a77970_eagle.cfg
configs/r8a77990_ebisu.cfg
configs/r8a77995_draak.cfg
In this case, I believe each fragment would contain under 10 Kconfig
symbols and the `make _defconfig` procedure would change
to `make rcar{3,-gen3}_defconfig .cfg`.
>
>
> In fact, I suggested
>
> make _defconfig .config
>
> some time ago, but I did not get positive feedback.
I can imagine, this looks like crappy. It should be automatic, like some
sort of Kconfig "include directives" or somesuch.
> The reason was, it would be tedious to type a series of config files,
> and also it would break the upper-level projects
> such as OE recipes, buildroot, etc.
Right
>>> I was pondering whether there's some way to factor out the common parts,
>>> or maybe even replace some of the defconfigs with a placeholder for
>>> compatibility reasons and just go with one full defconfig for all SoCs
>>> (H3/M3W/M3N) that can be on such a board.
>
> I manage my boards this way.
>
> I have only three defconfig files:
> uniphier_ld4_sld8_defconfig
> uniphier_v7_defconfig
> uniphier_v8_defconfig
>
>
> Each defconfig supports multiple boards
> by using a different DEVICE_TREE.
>
> If you are interested, doc/README.uniphier
> explains it supports much more boards than defconfig.
>
> The drawback of this ways will increase the image size
> since it needs to compile-in all necessary
> boot-code and drivers.
> So, this solution only works when you have enough
> memory footprint.
That's fine, I'm mostly looking for some backward compatibility option,
so that I can retain the old defconfig names and e.g. turn them into
symlinks.
Maybe I should just remove the soon-to-be-duplicate files and be done
with it, might be the easiest solution.
>>> I'd still like to be able to do "make soc_board_defconfig ; make"
>>> without having to rack my brain which other .cfg files I need to append.
>>> I didn't find a good solution for this however. Do you know of one ?
>
> One idea might be,
> to hack scripts/kconfig/Makefile
> to allow a defconfig to contain shell scripts.
>
>
> For example, r8a7795_salvator-x_defconfig will look like:
>
> #!/bin/sh
> $MAKE r8a7795_defconfig
> $MAKE r8a7795_salvator-x.config
>
>
> Makefile will run it if the first line is shebang,
> otherwise handle it as a normal defconfig.
>
>
> I am not so sure if this is the right thing to do.
> So, it should be discussed widely anyway if we try to
> introduce something new.
>
> A problem in this way is, as Eugeniu pointed out,
> we have no way to sync .config fragment files.
>
>
>> I think we have proper tools to track the correctness of the defconfig
>> files (i.e. savedefconfig Kbuild target), but we don't seem to have
>> proper tools to validate configuration fragments. So, I agree the
>> contents of the fragments would potentially go wild. I think having
>> either a built-in Kbuild/Kconfig procedure or some scripted way to keep
>> the fragments under control would greatly increase the confidence in
>> using them, but I am unaware of such.
>
> You are right.
>
> We will need something like savedefconfig for .config files,
> but we do not have a good tool. At least, I do not know.
>
>
> Thanks.
>
>
>
>> JFTR, rcar-3.9.3.rc1 U-Boot has double the amount of vanilla R-Car3
>> defconfigs:
>>
>> $> u-boot (rcar-3.9.3.rc1) ls -1 configs/r8a779*
>> configs/r8a7795_salvator-x_defconfig
>> configs/r8a7795_salvator-xs-2x2g_defconfig
>> configs/r8a7795_salvator-xs-4x2g_defconfig
>> configs/r8a7795_salvator-xs_defconfig
>> configs/r8a7795_ulcb-4x2g_defconfig
>> configs/r8a7795_ulcb_defconfig
>> configs/r8a77965_salvator-x_defconfig
>> configs/r8a77965_salvator-xs_defconfig
>> configs/r8a77965_ulcb_defconfig
>> configs/r8a7796_salvator-x_defconfig
>> configs/r8a7796_salvator-xs_defconfig
>> configs/r8a7796_ulcb_defconfig
>> configs/r8a77970_eagle_defconfig
>> configs/r8a77990_ebisu-4d_defconfig
>> configs/r8a77990_ebisu_defconfig
>> configs/r8a77995_draak_defconfig
>>
>> So, changing/adding/removing a common option (most of them are) implies
>> quite an amount of maintenance effort on our side. I would greatly
>> appreciate any ideas h
