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

Thu Mar 7 20:21:34 UTC 2019

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 <erosca at 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 at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> --
> Best Regards
> Masahiro Yamada
> 

-- 
Best regards,
Marek Vasut