[U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs

[Ismael Luceno Cortes <ismael.luceno@silicon-gears.com>]

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.