[U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC

[U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC

[Marek Vasut]

Imply preferred clock driver per SoC, no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 arch/arm/mach-rmobile/Kconfig.32 | 5 +++++
 arch/arm/mach-rmobile/Kconfig.64 | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index 076a019135..5d9da49c92 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -16,25 +16,30 @@ config R8A7790
 	bool "Renesas SoC R8A7790"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
+	imply CLK_R8A7790
 
 config R8A7791
 	bool "Renesas SoC R8A7791"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
+	imply CLK_R8A7791
 
 config R8A7792
 	bool "Renesas SoC R8A7792"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
+	imply CLK_R8A7792
 
 config R8A7793
 	bool "Renesas SoC R8A7793"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
+	imply CLK_R8A7793
 
 config R8A7794
 	bool "Renesas SoC R8A7794"
 	select RCAR_GEN2
+	imply CLK_R8A7794
 
 choice
 	prompt "Renesas ARM SoCs board select"
diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index cb9f569e5f..d84c0617d1 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -5,18 +5,23 @@ choice
 
 config R8A7795
 	bool "Renesas SoC R8A7795"
+	imply CLK_R8A7795
 
 config R8A7796
 	bool "Renesas SoC R8A7796"
+	imply CLK_R8A7796
 
 config R8A77970
 	bool "Renesas SoC R8A77970"
+	imply CLK_R8A77970
 
 config R8A77990
 	bool "Renesas SoC R8A77990"
+	imply CLK_R8A77990
 
 config R8A77995
 	bool "Renesas SoC R8A77995"
+	imply CLK_R8A77995
 
 endchoice
 
-- 
2.19.2

[U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl drivers per SoC

[Marek Vasut]

Imply preferred pin control driver per SoC, no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 arch/arm/mach-rmobile/Kconfig.32 | 5 +++++
 arch/arm/mach-rmobile/Kconfig.64 | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32
index 5d9da49c92..67f669a6fc 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -17,29 +17,34 @@ config R8A7790
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
 	imply CLK_R8A7790
+	imply PINCTRL_PFC_R8A7790
 
 config R8A7791
 	bool "Renesas SoC R8A7791"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
 	imply CLK_R8A7791
+	imply PINCTRL_PFC_R8A7791
 
 config R8A7792
 	bool "Renesas SoC R8A7792"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
 	imply CLK_R8A7792
+	imply PINCTRL_PFC_R8A7792
 
 config R8A7793
 	bool "Renesas SoC R8A7793"
 	select RCAR_GEN2
 	select ARM_CORTEX_A15_CVE_2017_5715
 	imply CLK_R8A7793
+	imply PINCTRL_PFC_R8A7793
 
 config R8A7794
 	bool "Renesas SoC R8A7794"
 	select RCAR_GEN2
 	imply CLK_R8A7794
+	imply PINCTRL_PFC_R8A7794
 
 choice
 	prompt "Renesas ARM SoCs board select"
diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index d84c0617d1..d231263574 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -6,22 +6,27 @@ choice
 config R8A7795
 	bool "Renesas SoC R8A7795"
 	imply CLK_R8A7795
+	imply PINCTRL_PFC_R8A7795
 
 config R8A7796
 	bool "Renesas SoC R8A7796"
 	imply CLK_R8A7796
+	imply PINCTRL_PFC_R8A7796
 
 config R8A77970
 	bool "Renesas SoC R8A77970"
 	imply CLK_R8A77970
+	imply PINCTRL_PFC_R8A77970
 
 config R8A77990
 	bool "Renesas SoC R8A77990"
 	imply CLK_R8A77990
+	imply PINCTRL_PFC_R8A77990
 
 config R8A77995
 	bool "Renesas SoC R8A77995"
 	imply CLK_R8A77995
+	imply PINCTRL_PFC_R8A77995
 
 endchoice
 
-- 
2.19.2

[U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool per SoC

[Marek Vasut]

Drop per SoC def_bool on each driver, since this is now implied by
SoC Kconfig option instead.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 drivers/clk/renesas/Kconfig | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 578e6a8049..e062eccdae 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -13,35 +13,30 @@ config CLK_RCAR_GEN2
 
 config CLK_R8A7790
 	bool "Renesas R8A7790 clock driver"
-	def_bool y if R8A7790
 	depends on CLK_RCAR_GEN2
 	help
 	  Enable this to support the clocks on Renesas R8A7790 SoC.
 
 config CLK_R8A7791
 	bool "Renesas R8A7791 clock driver"
-	def_bool y if R8A7791
 	depends on CLK_RCAR_GEN2
 	help
 	  Enable this to support the clocks on Renesas R8A7791 SoC.
 
 config CLK_R8A7792
 	bool "Renesas R8A7792 clock driver"
-	def_bool y if R8A7792
 	depends on CLK_RCAR_GEN2
 	help
 	  Enable this to support the clocks on Renesas R8A7792 SoC.
 
 config CLK_R8A7793
 	bool "Renesas R8A7793 clock driver"
-	def_bool y if R8A7793
 	depends on CLK_RCAR_GEN2
 	help
 	  Enable this to support the clocks on Renesas R8A7793 SoC.
 
 config CLK_R8A7794
 	bool "Renesas R8A7794 clock driver"
-	def_bool y if R8A7794
 	depends on CLK_RCAR_GEN2
 	help
 	  Enable this to support the clocks on Renesas R8A7794 SoC.
@@ -55,35 +50,30 @@ config CLK_RCAR_GEN3
 
 config CLK_R8A7795
 	bool "Renesas R8A7795 clock driver"
-	def_bool y if R8A7795
 	depends on CLK_RCAR_GEN3
 	help
 	  Enable this to support the clocks on Renesas R8A7795 SoC.
 
 config CLK_R8A7796
 	bool "Renesas R8A7796 clock driver"
-	def_bool y if R8A7796
 	depends on CLK_RCAR_GEN3
 	help
 	  Enable this to support the clocks on Renesas R8A7796 SoC.
 
 config CLK_R8A77970
 	bool "Renesas R8A77970 clock driver"
-	def_bool y if R8A77970
 	depends on CLK_RCAR_GEN3
 	help
 	  Enable this to support the clocks on Renesas R8A77970 SoC.
 
 config CLK_R8A77990
 	bool "Renesas R8A77990 clock driver"
-	def_bool y if R8A77990
 	depends on CLK_RCAR_GEN3
 	help
 	  Enable this to support the clocks on Renesas R8A77990 SoC.
 
 config CLK_R8A77995
 	bool "Renesas R8A77995 clock driver"
-	def_bool y if R8A77995
 	depends on CLK_RCAR_GEN3
 	help
 	  Enable this to support the clocks on Renesas R8A77995 SoC.
-- 
2.19.2

[U-Boot] [PATCH 4/6] pinctrl: renesas: Drop def_bool per SoC

[Marek Vasut]

Drop per SoC def_bool on each driver, since this is now implied by
SoC Kconfig option instead.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 drivers/pinctrl/renesas/Kconfig | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/pinctrl/renesas/Kconfig b/drivers/pinctrl/renesas/Kconfig
index 1baab9088a..0cb577037c 100644
--- a/drivers/pinctrl/renesas/Kconfig
+++ b/drivers/pinctrl/renesas/Kconfig
@@ -8,7 +8,6 @@ config PINCTRL_PFC
 
 config PINCTRL_PFC_R8A7790
 	bool "Renesas RCar Gen2 R8A7790 pin control driver"
-	def_bool y if R8A7790
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7790 SoCs.
@@ -19,7 +18,6 @@ config PINCTRL_PFC_R8A7790
 
 config PINCTRL_PFC_R8A7791
 	bool "Renesas RCar Gen2 R8A7791 pin control driver"
-	def_bool y if R8A7791
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7791 SoCs.
@@ -30,7 +28,6 @@ config PINCTRL_PFC_R8A7791
 
 config PINCTRL_PFC_R8A7792
 	bool "Renesas RCar Gen2 R8A7792 pin control driver"
-	def_bool y if R8A7792
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7792 SoCs.
@@ -41,7 +38,6 @@ config PINCTRL_PFC_R8A7792
 
 config PINCTRL_PFC_R8A7793
 	bool "Renesas RCar Gen2 R8A7793 pin control driver"
-	def_bool y if R8A7793
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7793 SoCs.
@@ -52,7 +48,6 @@ config PINCTRL_PFC_R8A7793
 
 config PINCTRL_PFC_R8A7794
 	bool "Renesas RCar Gen2 R8A7794 pin control driver"
-	def_bool y if R8A7794
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7794 SoCs.
@@ -63,7 +58,6 @@ config PINCTRL_PFC_R8A7794
 
 config PINCTRL_PFC_R8A7795
 	bool "Renesas RCar Gen3 R8A7795 pin control driver"
-	def_bool y if R8A7795
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7795 SoCs.
@@ -74,7 +68,6 @@ config PINCTRL_PFC_R8A7795
 
 config PINCTRL_PFC_R8A7796
 	bool "Renesas RCar Gen3 R8A7796 pin control driver"
-	def_bool y if R8A7796
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A7796 SoCs.
@@ -85,7 +78,6 @@ config PINCTRL_PFC_R8A7796
 
 config PINCTRL_PFC_R8A77970
 	bool "Renesas RCar Gen3 R8A77970 pin control driver"
-	def_bool y if R8A77970
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A77970 SoCs.
@@ -96,7 +88,6 @@ config PINCTRL_PFC_R8A77970
 
 config PINCTRL_PFC_R8A77990
 	bool "Renesas RCar Gen3 R8A77990 pin control driver"
-	def_bool y if R8A77990
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A77990 SoCs.
@@ -107,7 +98,6 @@ config PINCTRL_PFC_R8A77990
 
 config PINCTRL_PFC_R8A77995
 	bool "Renesas RCar Gen3 R8A77995 pin control driver"
-	def_bool y if R8A77995
 	depends on PINCTRL_PFC
 	help
 	  Support pin multiplexing control on Renesas RCar Gen3 R8A77995 SoCs.
-- 
2.19.2

[U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board

[Marek Vasut]

Imply all SoCs supported by a given board. This allows building single
U-Boot binary for boards which can have multiple SoCs.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 arch/arm/mach-rmobile/Kconfig.64 | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index d231263574..b2ac1cdad7 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -1,7 +1,6 @@
 if RCAR_GEN3
 
-choice
-	prompt "Select Target SoC"
+menu "Select Target SoC"
 
 config R8A7795
 	bool "Renesas SoC R8A7795"
@@ -28,34 +27,41 @@ config R8A77995
 	imply CLK_R8A77995
 	imply PINCTRL_PFC_R8A77995
 
-endchoice
+endmenu
 
 choice
-	prompt "Renesus ARM64 SoCs board select"
+	prompt "Renesas ARM64 SoCs board select"
 	optional
 
 config TARGET_DRAAK
 	bool "Draak board"
+	imply R8A77995
 	help
           Support for Renesas R-Car Gen3 Draak platform
 
 config TARGET_EAGLE
 	bool "Eagle board"
+	imply R8A77970
 	help
           Support for Renesas R-Car Gen3 Eagle platform
 
 config TARGET_EBISU
 	bool "Ebisu board"
+	imply R8A77990
 	help
           Support for Renesas R-Car Gen3 Ebisu platform
 
 config TARGET_SALVATOR_X
 	bool "Salvator-X board"
+	imply R8A7795
+	imply R8A7796
 	help
           Support for Renesas R-Car Gen3 platform
 
 config TARGET_ULCB
 	bool "ULCB board"
+	imply R8A7795
+	imply R8A7796
 	help
           Support for Renesas R-Car Gen3 ULCB platform
 
-- 
2.19.2

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

[Marek Vasut]

Synchronize Gen3 defconfigs in wake of the Kconfig option changes.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
 configs/r8a77965_salvator-x_defconfig | 1 -
 configs/r8a7796_salvator-x_defconfig  | 1 -
 configs/r8a7796_ulcb_defconfig        | 1 -
 3 files changed, 3 deletions(-)

diff --git a/configs/r8a77965_salvator-x_defconfig b/configs/r8a77965_salvator-x_defconfig
index 82ebab06c3..9965036123 100644
--- a/configs/r8a77965_salvator-x_defconfig
+++ b/configs/r8a77965_salvator-x_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x50000000
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_RCAR_GEN3=y
-CONFIG_R8A7796=y
 CONFIG_TARGET_SALVATOR_X=y
 CONFIG_SMBIOS_PRODUCT_NAME=""
 CONFIG_FIT=y
diff --git a/configs/r8a7796_salvator-x_defconfig b/configs/r8a7796_salvator-x_defconfig
index ae0555cd85..09626bf8b6 100644
--- a/configs/r8a7796_salvator-x_defconfig
+++ b/configs/r8a7796_salvator-x_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x50000000
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_RCAR_GEN3=y
-CONFIG_R8A7796=y
 CONFIG_TARGET_SALVATOR_X=y
 CONFIG_SMBIOS_PRODUCT_NAME=""
 CONFIG_FIT=y
diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig
index f3781a57e2..1f2de9d71b 100644
--- a/configs/r8a7796_ulcb_defconfig
+++ b/configs/r8a7796_ulcb_defconfig
@@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y
 CONFIG_SYS_TEXT_BASE=0x50000000
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_RCAR_GEN3=y
-CONFIG_R8A7796=y
 CONFIG_TARGET_ULCB=y
 CONFIG_SMBIOS_PRODUCT_NAME=""
 CONFIG_FIT=y
-- 
2.19.2

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

[Eugeniu Rosca]

Hello Marek,

Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar.
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`.

Best regards,
Eugeniu.

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

[Marek Vasut]

On 3/4/19 10:36 PM, Eugeniu Rosca wrote:
> Hello Marek,

Hi,

> Thanks to great maintenance, the R-Car3 defconfigs look strikingly similar.

That's the goal for this release, to make them look similar.

> 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 ?

-- 
Best regards,
Marek Vasut

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

[Eugeniu Rosca]

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`.
> 
> 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.

> 
> -- 
> Best regards,
> Marek Vasut

Best regards,
Eugeniu.

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

[Marek Vasut]

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

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

[Masahiro Yamada]

Hi.

Sorry for chiming in late.


On Tue, Mar 5, 2019 at 8:41 AM Eugeniu Rosca <erosca@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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



--
Best Regards
Masahiro Yamada

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

[Ismael Luceno Cortes]

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.

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

[Marek Vasut]

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@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