From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marek.vasut@gmail.com>
Date: Tue, 5 Mar 2019 04:36:05 +0100
Subject: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
In-Reply-To: <20190304234031.GA12143@vmlxhi-102.adit-jv.com>
References: <20190218130541.22671-1-marek.vasut+renesas@gmail.com>
 <20190218130541.22671-6-marek.vasut+renesas@gmail.com>
 <CAH3KO=0j=ckSM73k4rm-CZ_EKpWcA3j4UePrzodz59KpLPtADQ@mail.gmail.com>
 <51dd743c-6b0b-1922-c9c0-949176faca8e@gmail.com>
 <20190304234031.GA12143@vmlxhi-102.adit-jv.com>
Message-ID: <f0403a4f-f20b-7031-e753-f7cf4bc3eb6e@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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 <board>_defconfig` procedure would change
>>> to `make rcar{3,-gen3}_defconfig <board>.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