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 <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.
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 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
>
--
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
