Hi.
Sorry for chiming in late.
On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca <ero...@de.adit-jv.com> 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 <board>_defconfig` procedure would change
> > > to `make rcar{3,-gen3}_defconfig <board>.cfg`.
In fact, I suggested
make <soc>_defconfig <board>.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
