[PATCH 01/10] arm: mvebu: fix SerDes table alignment

[PATCH 01/10] arm: mvebu: fix SerDes table alignment

[Joel Johnson]

Tested on Solidrun ClearFog Base. Table alignment was:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  3   |  SATA0       |
 |   1    |  0   |  SGMII1      |
 |   2    |  3   |  SATA1       |
 |   3    |  5   |  USB3 HOST1  |
 |   4    |  5   |  USB3 HOST0  |
 |   5    |  4   |  SGMII2      |
 --------------------------------

After the change, it's correctly aligned as:
 | Lane # | Speed |  Type       |
 --------------------------------
 |   0    |   3   | SATA0       |
 |   1    |   0   | SGMII1      |
 |   2    |   5   | PCIe1       |
 |   3    |   5   | USB3 HOST1  |
 |   4    |   5   | PCIe2       |
 |   5    |   0   | SGMII2      |
 --------------------------------

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 33e70569bc..66409a50c0 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -1366,16 +1366,16 @@ static void print_topology_details(const struct serdes_map *serdes_map,
 
 	DEBUG_INIT_S("board SerDes lanes topology details:\n");
 
-	DEBUG_INIT_S(" | Lane #  | Speed |  Type       |\n");
+	DEBUG_INIT_S(" | Lane # | Speed |  Type       |\n");
 	DEBUG_INIT_S(" --------------------------------\n");
 	for (lane_num = 0; lane_num < count; lane_num++) {
 		if (serdes_map[lane_num].serdes_type == DEFAULT_SERDES)
 			continue;
 		DEBUG_INIT_S(" |   ");
 		DEBUG_INIT_D(hws_get_physical_serdes_num(lane_num), 1);
-		DEBUG_INIT_S("    |  ");
+		DEBUG_INIT_S("    |   ");
 		DEBUG_INIT_D(serdes_map[lane_num].serdes_speed, 2);
-		DEBUG_INIT_S("   |  ");
+		DEBUG_INIT_S("   | ");
 		DEBUG_INIT_S((char *)
 			     serdes_type_to_string[serdes_map[lane_num].
 						   serdes_type]);
-- 
2.20.1

[PATCH 02/10] arm: mvebu: solidrun: remove hardcoded DTS MAC address

[Joel Johnson]

Using a consistent hardcoded MAC address from the DTS file causes
issues when using multiple devices on the same network segment.
Instead rely on environment configuration or random generation.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
index a2627223ce..7c1c7900ce 100644
--- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
@@ -39,7 +39,6 @@
 
 &eth0 {
 	/* ethernet at 70000 */
-	mac-address = [00 50 43 02 02 01];
 	pinctrl-0 = <&ge0_rgmii_pins>;
 	pinctrl-names = "default";
 	phy = <&phy_dedicated>;
-- 
2.20.1

[PATCH 02/10] arm: mvebu: solidrun: remove hardcoded DTS MAC address

[Stefan Roese]

On 11.01.20 20:36, Joel Johnson wrote:
> Using a consistent hardcoded MAC address from the DTS file causes
> issues when using multiple devices on the same network segment.
> Instead rely on environment configuration or random generation.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
> 
>   arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> index a2627223ce..7c1c7900ce 100644
> --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> @@ -39,7 +39,6 @@
>   
>   &eth0 {
>   	/* ethernet at 70000 */
> -	mac-address = [00 50 43 02 02 01];
>   	pinctrl-0 = <&ge0_rgmii_pins>;
>   	pinctrl-names = "default";
>   	phy = <&phy_dedicated>;
> 

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

[PATCH 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Joel Johnson]

Add a unique entry for ClearFog Base variant, reflected
in the board name and adjusted SerDes topology.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 arch/arm/mach-mvebu/Kconfig        |  2 ++
 board/solidrun/clearfog/Kconfig    | 10 ++++++++++
 board/solidrun/clearfog/clearfog.c | 10 +++++++++-
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 board/solidrun/clearfog/Kconfig

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index fdd39685b7..c6a1a0a944 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -279,4 +279,6 @@ config SECURED_MODE_CSK_INDEX
 	default 0
 	depends on SECURED_MODE_IMAGE
 
+source "board/solidrun/clearfog/Kconfig"
+
 endif
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
new file mode 100644
index 0000000000..d122be9196
--- /dev/null
+++ b/board/solidrun/clearfog/Kconfig
@@ -0,0 +1,10 @@
+menu "ClearFog configuration"
+	depends on TARGET_CLEARFOG
+
+config TARGET_CLEARFOG_BASE
+	bool "Configure for the ClearFog Base variant"
+	help
+	 Configure for the ClearFog Base board variant. By default the ClearFog
+	 Pro variant will be configured.
+
+endmenu
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 03724fee10..44aac907fd 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -33,7 +33,11 @@ static struct serdes_map board_serdes_map[] = {
 	{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 	{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
 	{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
+	{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
 	{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+#endif
 	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 };
 
@@ -125,7 +129,11 @@ int board_init(void)
 
 int checkboard(void)
 {
-	puts("Board: SolidRun ClearFog\n");
+#if defined (CONFIG_TARGET_CLEARFOG_BASE)
+	puts("Board: SolidRun ClearFog Base\n");
+#else
+	puts("Board: SolidRun ClearFog Pro\n");
+#endif
 
 	return 0;
 }
-- 
2.20.1

[PATCH 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Baruch Siach]

Hi Joel,

Thanks for working on Clearfog hardware support improvements.

On Sat, Jan 11 2020, Joel Johnson wrote:
> Add a unique entry for ClearFog Base variant, reflected
> in the board name and adjusted SerDes topology.
>
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>
>  arch/arm/mach-mvebu/Kconfig        |  2 ++
>  board/solidrun/clearfog/Kconfig    | 10 ++++++++++
>  board/solidrun/clearfog/clearfog.c | 10 +++++++++-
>  3 files changed, 21 insertions(+), 1 deletion(-)
>  create mode 100644 board/solidrun/clearfog/Kconfig
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index fdd39685b7..c6a1a0a944 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -279,4 +279,6 @@ config SECURED_MODE_CSK_INDEX
>  	default 0
>  	depends on SECURED_MODE_IMAGE
>
> +source "board/solidrun/clearfog/Kconfig"
> +
>  endif
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> new file mode 100644
> index 0000000000..d122be9196
> --- /dev/null
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -0,0 +1,10 @@
> +menu "ClearFog configuration"
> +	depends on TARGET_CLEARFOG
> +
> +config TARGET_CLEARFOG_BASE
> +	bool "Configure for the ClearFog Base variant"
> +	help
> +	 Configure for the ClearFog Base board variant. By default the ClearFog
> +	 Pro variant will be configured.

This conflicts with the series I posted adding support for A388 SOM and
Clearfog Base/Pro carriers EEPROM TLV:

  https://patchwork.ozlabs.org/cover/1200324/

The EEPROM TLV is meant to allow run-time detection of the hardware on
newer hardware revisions that populate the EEPROM. This patch is still
useful for older SOM and carrier revisions but it might cause confusion
for users.

Would you mind to rebase your patches on top of my code?

Nit: help text indentation should be "tab + 2 spaces".

Thanks,
baruch

> +
> +endmenu
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 03724fee10..44aac907fd 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -33,7 +33,11 @@ static struct serdes_map board_serdes_map[] = {
>  	{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  	{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>  	{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
> +	{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#else
>  	{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
> +#endif
>  	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>  };
>
> @@ -125,7 +129,11 @@ int board_init(void)
>
>  int checkboard(void)
>  {
> -	puts("Board: SolidRun ClearFog\n");
> +#if defined (CONFIG_TARGET_CLEARFOG_BASE)
> +	puts("Board: SolidRun ClearFog Base\n");
> +#else
> +	puts("Board: SolidRun ClearFog Pro\n");
> +#endif
>
>  	return 0;
>  }

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Joel Johnson]

On January 12, 2020 10:14:35 AM UTC, Baruch Siach <baruch@tkos.co.il> wrote:
>Hi Joel,
>
>Thanks for working on Clearfog hardware support improvements.

Sure - I finally just got tired of not being able to easily use mainline builds, sat down and figured out the gaps and missing dependencies in order to support at least my use cases and flexibility in general.

>
>On Sat, Jan 11 2020, Joel Johnson wrote:
>> Add a unique entry for ClearFog Base variant, reflected
>> in the board name and adjusted SerDes topology.
>
>This conflicts with the series I posted adding support for A388 SOM and
>Clearfog Base/Pro carriers EEPROM TLV:
>
>  https://patchwork.ozlabs.org/cover/1200324/
>
>The EEPROM TLV is meant to allow run-time detection of the hardware on
>newer hardware revisions that populate the EEPROM. This patch is still
>useful for older SOM and carrier revisions but it might cause confusion
>for users.
>
>Would you mind to rebase your patches on top of my code?

Sure, I hadn't seen this in flight patch series, I'll take a look and adjust/adapt/drop as needed. I believe that most of my units are older non-EEPROM variants, but will test with your patches and at least make the manual vs. dynamic detected config interoperable.

>Nit: help text indentation should be "tab + 2 spaces".

Thanks, I'll update accordingly.

Joel

[PATCH 03/10] arm: mvebu: clearfog: initial ClearFog Base variant

[Stefan Roese]

On 12.01.20 16:16, Joel Johnson wrote:
> 
> 
> On January 12, 2020 10:14:35 AM UTC, Baruch Siach <baruch@tkos.co.il> wrote:
>> Hi Joel,
>>
>> Thanks for working on Clearfog hardware support improvements.
> 
> Sure - I finally just got tired of not being able to easily use mainline builds, sat down and figured out the gaps and missing dependencies in order to support at least my use cases and flexibility in general.
> 
>>
>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>> Add a unique entry for ClearFog Base variant, reflected
>>> in the board name and adjusted SerDes topology.
>>
>> This conflicts with the series I posted adding support for A388 SOM and
>> Clearfog Base/Pro carriers EEPROM TLV:
>>
>>   https://patchwork.ozlabs.org/cover/1200324/
>>
>> The EEPROM TLV is meant to allow run-time detection of the hardware on
>> newer hardware revisions that populate the EEPROM. This patch is still
>> useful for older SOM and carrier revisions but it might cause confusion
>> for users.
>>
>> Would you mind to rebase your patches on top of my code?
> 
> Sure, I hadn't seen this in flight patch series, I'll take a look and adjust/adapt/drop as needed. I believe that most of my units are older non-EEPROM variants, but will test with your patches and at least make the manual vs. dynamic detected config interoperable.

Okay, let's wait for Baruch to update his patchset and yours rebased
on top of that one.

Thanks,
Stefan

[PATCH 04/10] arm: mvebu: clearfog: Add SATA mode flags

[Joel Johnson]

The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
configured for SATA usage.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 board/solidrun/clearfog/Kconfig    | 17 +++++++++++++++++
 board/solidrun/clearfog/clearfog.c |  6 ++++++
 2 files changed, 23 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index d122be9196..30f53508c2 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -7,4 +7,21 @@ config TARGET_CLEARFOG_BASE
 	 Configure for the ClearFog Base board variant. By default the ClearFog
 	 Pro variant will be configured.
 
+config CLEARFOG_CON3_SATA
+	bool "Use CON3 slot in SATA mode"
+	help
+	 Use the CON3 port with SATA protocol instead of the default PCIe.
+	 The ClearFog port allows usage of either mSATA or miniPCIe
+	 modules, but the desired protocol must be configured at build
+	 time since it affects the SerDes topology layout.
+
+config CLEARFOG_CON2_SATA
+	bool "Use CON2 slot in SATA mode"
+	depends on !TARGET_CLEARFOG_BASE
+	help
+	 Use the CON2 port with SATA protocol instead of the default PCIe.
+	 The ClearFog port allows usage of either mSATA or miniPCIe
+	 modules, but the desired protocol must be configured at build
+	 time since it affects the SerDes topology layout.
+
 endmenu
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 44aac907fd..4f51b19ce9 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -31,10 +31,16 @@ DECLARE_GLOBAL_DATA_PTR;
 static struct serdes_map board_serdes_map[] = {
 	{SATA0, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 	{SGMII1, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#if defined (CONFIG_CLEARFOG_CON3_SATA)
+	{SATA1, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
 	{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
+#endif
 	{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 #if defined (CONFIG_TARGET_CLEARFOG_BASE)
 	{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#elif defined(CONFIG_CLEARFOG_CON2_SATA)
+	{SATA2, SERDES_SPEED_3_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 #else
 	{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
 #endif
-- 
2.20.1

[PATCH 05/10] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP

[Joel Johnson]

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 board/solidrun/clearfog/Kconfig    | 7 +++++++
 board/solidrun/clearfog/clearfog.c | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 30f53508c2..53f01daf7a 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -24,4 +24,11 @@ config CLEARFOG_CON2_SATA
 	 modules, but the desired protocol must be configured at build
 	 time since it affects the SerDes topology layout.
 
+config CLEARFOG_SFP_25GB
+	bool "Enable 2.5 Gbps mode for SFP"
+	help
+	 Set the SFP module connection to support 2.5 Gbps transfer speed for the
+	 SGMII connection (requires a supporting SFP). By default, transfer speed
+	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
+
 endmenu
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 4f51b19ce9..247785ac56 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -44,7 +44,11 @@ static struct serdes_map board_serdes_map[] = {
 #else
 	{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
 #endif
+#if defined (CONFIG_CLEARFOG_SFP_25GB)
+	{SGMII2, SERDES_SPEED_3_125_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#else
 	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
+#endif
 };
 
 int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
-- 
2.20.1

[PATCH 05/10] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP

[Baruch Siach]

Hi Joel,

On Sat, Jan 11 2020, Joel Johnson wrote:
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>
>  board/solidrun/clearfog/Kconfig    | 7 +++++++
>  board/solidrun/clearfog/clearfog.c | 4 ++++
>  2 files changed, 11 insertions(+)
>
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 30f53508c2..53f01daf7a 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -24,4 +24,11 @@ config CLEARFOG_CON2_SATA
>  	 modules, but the desired protocol must be configured at build
>  	 time since it affects the SerDes topology layout.
>
> +config CLEARFOG_SFP_25GB
> +	bool "Enable 2.5 Gbps mode for SFP"
> +	help
> +	 Set the SFP module connection to support 2.5 Gbps transfer speed for the
> +	 SGMII connection (requires a supporting SFP). By default, transfer speed
> +	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.

Note that recent Linux kernels support run-time SFP detection and serdes
speed configuration. This patch is still useful for older kernels.

baruch

> +
>  endmenu
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 4f51b19ce9..247785ac56 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -44,7 +44,11 @@ static struct serdes_map board_serdes_map[] = {
>  #else
>  	{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>  #endif
> +#if defined (CONFIG_CLEARFOG_SFP_25GB)
> +	{SGMII2, SERDES_SPEED_3_125_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#else
>  	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> +#endif
>  };
>
>  int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 05/10] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP

[Joel Johnson]

On January 12, 2020 10:21:05 AM UTC, Baruch Siach <baruch@tkos.co.il> wrote:
>Hi Joel,
>
>On Sat, Jan 11 2020, Joel Johnson wrote:
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>> ---
>>
>>  board/solidrun/clearfog/Kconfig    | 7 +++++++
>>  board/solidrun/clearfog/clearfog.c | 4 ++++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/board/solidrun/clearfog/Kconfig
>b/board/solidrun/clearfog/Kconfig
>> index 30f53508c2..53f01daf7a 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -24,4 +24,11 @@ config CLEARFOG_CON2_SATA
>>  	 modules, but the desired protocol must be configured at build
>>  	 time since it affects the SerDes topology layout.
>>
>> +config CLEARFOG_SFP_25GB
>> +	bool "Enable 2.5 Gbps mode for SFP"
>> +	help
>> +	 Set the SFP module connection to support 2.5 Gbps transfer speed
>for the
>> +	 SGMII connection (requires a supporting SFP). By default, transfer
>speed
>> +	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP
>module.
>
>Note that recent Linux kernels support run-time SFP detection and
>serdes
>speed configuration. This patch is still useful for older kernels.
>
>baruch

Older kernels I suppose is a nice side effect also, but I was mainly targeting differentiating within U-Boot for network support options.

Joel

[PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM

[Joel Johnson]

While 1GB SOM parts are much more common, provide a build config
option for supporting parts with 2GB.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 board/solidrun/clearfog/Kconfig    | 6 ++++++
 board/solidrun/clearfog/clearfog.c | 8 ++++++++
 2 files changed, 14 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 53f01daf7a..fd880ee591 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -31,4 +31,10 @@ config CLEARFOG_SFP_25GB
 	 SGMII connection (requires a supporting SFP). By default, transfer speed
 	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
 
+config CLEARFOG_2GB_SOM
+	bool "Configure for a SOM with 2GB RAM"
+	help
+	 Enable support for the 2GB RAM SOM variant. If this option is not
+	 enabled then the more common 1GB version will be used.
+
 endmenu
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 247785ac56..38f411b942 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -67,11 +67,19 @@ static struct mv_ddr_topology_map board_topology_map = {
 	DEBUG_LEVEL_ERROR,
 	0x1, /* active interfaces */
 	/* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
+#if defined (CONFIG_CLEARFOG_2GB_SOM)
+	{ { { {0x3, 0, 0, 0},
+	      {0x3, 0, 0, 0},
+	      {0x3, 0, 0, 0},
+	      {0x3, 0, 0, 0},
+	      {0x3, 0, 0, 0} },
+#else
 	{ { { {0x1, 0, 0, 0},
 	      {0x1, 0, 0, 0},
 	      {0x1, 0, 0, 0},
 	      {0x1, 0, 0, 0},
 	      {0x1, 0, 0, 0} },
+#endif
 	    SPEED_BIN_DDR_1600K,	/* speed_bin */
 	    MV_DDR_DEV_WIDTH_16BIT,	/* memory_width */
 	    MV_DDR_DIE_CAP_4GBIT,	/* mem_size */
-- 
2.20.1

[PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM

[Baruch Siach]

Hi Joel,

On Sat, Jan 11 2020, Joel Johnson wrote:
> While 1GB SOM parts are much more common, provide a build config
> option for supporting parts with 2GB.
>
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>
>  board/solidrun/clearfog/Kconfig    | 6 ++++++
>  board/solidrun/clearfog/clearfog.c | 8 ++++++++
>  2 files changed, 14 insertions(+)
>
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 53f01daf7a..fd880ee591 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -31,4 +31,10 @@ config CLEARFOG_SFP_25GB
>  	 SGMII connection (requires a supporting SFP). By default, transfer speed
>  	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
>
> +config CLEARFOG_2GB_SOM
> +	bool "Configure for a SOM with 2GB RAM"
> +	help
> +	 Enable support for the 2GB RAM SOM variant. If this option is not
> +	 enabled then the more common 1GB version will be used.
> +
>  endmenu
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 247785ac56..38f411b942 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -67,11 +67,19 @@ static struct mv_ddr_topology_map board_topology_map = {
>  	DEBUG_LEVEL_ERROR,
>  	0x1, /* active interfaces */
>  	/* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
> +#if defined (CONFIG_CLEARFOG_2GB_SOM)
> +	{ { { {0x3, 0, 0, 0},
> +	      {0x3, 0, 0, 0},
> +	      {0x3, 0, 0, 0},
> +	      {0x3, 0, 0, 0},
> +	      {0x3, 0, 0, 0} },

That can only work for 2GB SOMs with twin-die RAM configuration. SOMs
with single-die RAM need MV_DDR_DIE_CAP_8GBIT in the mem_size field
instead. See board/kobol/helios4/helios4.c. See also

  https://patchwork.ozlabs.org/patch/1200332/

You should also adjust the ODT configuration to assert M_ODT[0] of both
chip-selects, since only M_ODT[0] is connected on the A388 SOM. See the
comment I added to the cherry-picked commit log in

  https://github.com/SolidRun/u-boot/commit/ab15b2d5b6ee50c106628dc0aa5943747a5dd772

Wrong ODT configuration might cause memory corruption in high RAM
traffic load.

I have a patch adding support for per-board ODT configuration. I have
not posted it yet to the list.

baruch

> +#else
>  	{ { { {0x1, 0, 0, 0},
>  	      {0x1, 0, 0, 0},
>  	      {0x1, 0, 0, 0},
>  	      {0x1, 0, 0, 0},
>  	      {0x1, 0, 0, 0} },
> +#endif
>  	    SPEED_BIN_DDR_1600K,	/* speed_bin */
>  	    MV_DDR_DEV_WIDTH_16BIT,	/* memory_width */
>  	    MV_DDR_DIE_CAP_4GBIT,	/* mem_size */


--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM

[Joel Johnson]

On 2020-01-12 03:33, Baruch Siach wrote:
> Hi Joel,
> 
> On Sat, Jan 11 2020, Joel Johnson wrote:
>> While 1GB SOM parts are much more common, provide a build config
>> option for supporting parts with 2GB.
>> 
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>> ---
>> 
>>  board/solidrun/clearfog/Kconfig    | 6 ++++++
>>  board/solidrun/clearfog/clearfog.c | 8 ++++++++
>>  2 files changed, 14 insertions(+)
>> 
>> diff --git a/board/solidrun/clearfog/Kconfig 
>> b/board/solidrun/clearfog/Kconfig
>> index 53f01daf7a..fd880ee591 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -31,4 +31,10 @@ config CLEARFOG_SFP_25GB
>>  	 SGMII connection (requires a supporting SFP). By default, transfer 
>> speed
>>  	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
>> 
>> +config CLEARFOG_2GB_SOM
>> +	bool "Configure for a SOM with 2GB RAM"
>> +	help
>> +	 Enable support for the 2GB RAM SOM variant. If this option is not
>> +	 enabled then the more common 1GB version will be used.
>> +
>>  endmenu
>> diff --git a/board/solidrun/clearfog/clearfog.c 
>> b/board/solidrun/clearfog/clearfog.c
>> index 247785ac56..38f411b942 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -67,11 +67,19 @@ static struct mv_ddr_topology_map 
>> board_topology_map = {
>>  	DEBUG_LEVEL_ERROR,
>>  	0x1, /* active interfaces */
>>  	/* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
>> +#if defined (CONFIG_CLEARFOG_2GB_SOM)
>> +	{ { { {0x3, 0, 0, 0},
>> +	      {0x3, 0, 0, 0},
>> +	      {0x3, 0, 0, 0},
>> +	      {0x3, 0, 0, 0},
>> +	      {0x3, 0, 0, 0} },
> 
> That can only work for 2GB SOMs with twin-die RAM configuration. SOMs
> with single-die RAM need MV_DDR_DIE_CAP_8GBIT in the mem_size field
> instead. See board/kobol/helios4/helios4.c. See also
> 
>   https://patchwork.ozlabs.org/patch/1200332/

That seems to only target the newer EEPROM TLV units which I don't 
believe I have (still pending final checking). As with the other patch, 
an option for manual predefinition at build time will still be needed as 
an alternate path.

> You should also adjust the ODT configuration to assert M_ODT[0] of both
> chip-selects, since only M_ODT[0] is connected on the A388 SOM. See the
> comment I added to the cherry-picked commit log in
> 
> 
> https://github.com/SolidRun/u-boot/commit/ab15b2d5b6ee50c106628dc0aa5943747a5dd772
> 
> Wrong ODT configuration might cause memory corruption in high RAM
> traffic load.
> 
> I have a patch adding support for per-board ODT configuration. I have
> not posted it yet to the list.

Sounds promising, any planned timeframe for readiness and posting of 
that patch? I may just remove this patch from this series pending the 
per-board ODT config ability.

Joel

[PATCH 06/10] arm: mvebu: clearfog: Add config for 2GB SOM

[Baruch Siach]

Hi Joel,

On Sun, Jan 12 2020, Joel Johnson wrote:
> On 2020-01-12 03:33, Baruch Siach wrote:
>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>> While 1GB SOM parts are much more common, provide a build config
>>> option for supporting parts with 2GB.
>>>
>>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>> ---
>>>
>>>  board/solidrun/clearfog/Kconfig    | 6 ++++++
>>>  board/solidrun/clearfog/clearfog.c | 8 ++++++++
>>>  2 files changed, 14 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> index 53f01daf7a..fd880ee591 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -31,4 +31,10 @@ config CLEARFOG_SFP_25GB
>>>  	 SGMII connection (requires a supporting SFP). By default, transfer
>>> speed
>>>  	 of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
>>>
>>> +config CLEARFOG_2GB_SOM
>>> +	bool "Configure for a SOM with 2GB RAM"
>>> +	help
>>> +	 Enable support for the 2GB RAM SOM variant. If this option is not
>>> +	 enabled then the more common 1GB version will be used.
>>> +
>>>  endmenu
>>> diff --git a/board/solidrun/clearfog/clearfog.c
>>> b/board/solidrun/clearfog/clearfog.c
>>> index 247785ac56..38f411b942 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -67,11 +67,19 @@ static struct mv_ddr_topology_map board_topology_map =
>>> {
>>>  	DEBUG_LEVEL_ERROR,
>>>  	0x1, /* active interfaces */
>>>  	/* cs_mask, mirror, dqs_swap, ck_swap X PUPs */
>>> +#if defined (CONFIG_CLEARFOG_2GB_SOM)
>>> +	{ { { {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0},
>>> +	      {0x3, 0, 0, 0} },
>>
>> That can only work for 2GB SOMs with twin-die RAM configuration. SOMs
>> with single-die RAM need MV_DDR_DIE_CAP_8GBIT in the mem_size field
>> instead. See board/kobol/helios4/helios4.c. See also
>>
>>   https://patchwork.ozlabs.org/patch/1200332/
>
> That seems to only target the newer EEPROM TLV units which I don't believe I
> have (still pending final checking). As with the other patch, an option for
> manual predefinition at build time will still be needed as an alternate path.

In linking to this patch I only meant to demonstrate
MV_DDR_DIE_CAP_8GBIT.

A388 SOMs of rev 2.0 have no EEPROM.

>> You should also adjust the ODT configuration to assert M_ODT[0] of both
>> chip-selects, since only M_ODT[0] is connected on the A388 SOM. See the
>> comment I added to the cherry-picked commit log in
>>
>>
>> https://github.com/SolidRun/u-boot/commit/ab15b2d5b6ee50c106628dc0aa5943747a5dd772
>>
>> Wrong ODT configuration might cause memory corruption in high RAM
>> traffic load.
>>
>> I have a patch adding support for per-board ODT configuration. I have
>> not posted it yet to the list.
>
> Sounds promising, any planned timeframe for readiness and posting of that
> patch?

I plan to post patches adding support for twin-die SOMs once the
previous series is merged.

> I may just remove this patch from this series pending the per-board ODT
> config ability.

You need this patch (or equivalent) for twin-die SOMs regardless of
per-board ODT.

baruch

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 07/10] arm: mvebu: clearfog: add SPI offsets

[Joel Johnson]

Add reasonable default SPI offsets and ENV size when configured to
boot from SPI flash.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 board/solidrun/clearfog/Kconfig | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index fd880ee591..ce7fcf653f 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -37,4 +37,16 @@ config CLEARFOG_2GB_SOM
 	 Enable support for the 2GB RAM SOM variant. If this option is not
 	 enabled then the more common 1GB version will be used.
 
+config ENV_SECT_SIZE
+	hex "Environment Sector-Size"
+	# Use SPI flash erase block size of 4 KiB
+	default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
+	# Use optimistic 64 KiB erase block, will vary between actual media
+	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
+
+config SYS_SPI_U_BOOT_OFFS
+	hex "address of u-boot payload in SPI flash"
+	default 0x20000
+	depends on MVEBU_SPL_BOOT_DEVICE_SPI
+
 endmenu
-- 
2.20.1

[PATCH 07/10] arm: mvebu: clearfog: add SPI offsets

[Baruch Siach]

Hi Joel,

On Sat, Jan 11 2020, Joel Johnson wrote:

> Add reasonable default SPI offsets and ENV size when configured to
> boot from SPI flash.
>
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>
>  board/solidrun/clearfog/Kconfig | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index fd880ee591..ce7fcf653f 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -37,4 +37,16 @@ config CLEARFOG_2GB_SOM
>  	 Enable support for the 2GB RAM SOM variant. If this option is not
>  	 enabled then the more common 1GB version will be used.
>
> +config ENV_SECT_SIZE
> +	hex "Environment Sector-Size"
> +	# Use SPI flash erase block size of 4 KiB
> +	default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
> +	# Use optimistic 64 KiB erase block, will vary between actual media
> +	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC

Duplication of config symbols in platform specific Kconfig goes against
common practice. Platform specific values should go in
defconfig. Support for Clearfog SPI boot should be in a dedicated
defconfig, I think.

Same comment on patches #9 and #10.

> +config SYS_SPI_U_BOOT_OFFS
> +	hex "address of u-boot payload in SPI flash"
> +	default 0x20000
> +	depends on MVEBU_SPL_BOOT_DEVICE_SPI

It might be better to add u-boot,spl-payload-offset property to the
U-Boot specific -u-boot.dtsi file instead.

> +
>  endmenu

baruch

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 07/10] arm: mvebu: clearfog: add SPI offsets

[Joel Johnson]

On 2020-01-12 03:42, Baruch Siach wrote:
> Hi Joel,
> 
> On Sat, Jan 11 2020, Joel Johnson wrote:
> 
>> Add reasonable default SPI offsets and ENV size when configured to
>> boot from SPI flash.
>> 
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>> ---
>> 
>>  board/solidrun/clearfog/Kconfig | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>> 
>> diff --git a/board/solidrun/clearfog/Kconfig 
>> b/board/solidrun/clearfog/Kconfig
>> index fd880ee591..ce7fcf653f 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -37,4 +37,16 @@ config CLEARFOG_2GB_SOM
>>  	 Enable support for the 2GB RAM SOM variant. If this option is not
>>  	 enabled then the more common 1GB version will be used.
>> 
>> +config ENV_SECT_SIZE
>> +	hex "Environment Sector-Size"
>> +	# Use SPI flash erase block size of 4 KiB
>> +	default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
>> +	# Use optimistic 64 KiB erase block, will vary between actual media
>> +	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
> 
> Duplication of config symbols in platform specific Kconfig goes against
> common practice. Platform specific values should go in
> defconfig. Support for Clearfog SPI boot should be in a dedicated
> defconfig, I think.
> 
> Same comment on patches #9 and #10.

On the config symbol duplication, that's what seemed to be advocated by 
the Kconfig documentation, perhaps I'm reading/interpreting it 
incorrectly? I found examples of doing it how I did and it seemed to 
match the documented inteded usage. From 
https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html:
     "Default values are not limited to the menu entry where they are 
defined. This means the default can be defined somewhere else or be 
overridden by an earlier definition."

On the topic of a separate defconfig for SPI booting the same platform, 
I have been intentionally trying to avoid that. My use cases include SPI 
booting, but env in MMC, and MMC booting, but env in SPI - I don't 
intend to make those default mechanisms since they're admittedly a bit 
more esoteric, but I would still like them to be easily obtainable using 
a few custom config definitions at build time.

>> +config SYS_SPI_U_BOOT_OFFS
>> +	hex "address of u-boot payload in SPI flash"
>> +	default 0x20000
>> +	depends on MVEBU_SPL_BOOT_DEVICE_SPI
> 
> It might be better to add u-boot,spl-payload-offset property to the
> U-Boot specific -u-boot.dtsi file instead.

I hadn't considered that option and it's intriguing, but what would make 
it objectively better? It seems just an alternate location to put a 
statically defined value, having it as a custom U-Boot DTS entry doesn't 
allow runtime changing, does it?

Joel

[PATCH 07/10] arm: mvebu: clearfog: add SPI offsets

[Baruch Siach]

Hi Joel,

On Sun, Jan 12 2020, Joel Johnson wrote:
> On 2020-01-12 03:42, Baruch Siach wrote:
>> Hi Joel,
>>
>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>
>>> Add reasonable default SPI offsets and ENV size when configured to
>>> boot from SPI flash.
>>>
>>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>> ---
>>>
>>>  board/solidrun/clearfog/Kconfig | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> index fd880ee591..ce7fcf653f 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -37,4 +37,16 @@ config CLEARFOG_2GB_SOM
>>>  	 Enable support for the 2GB RAM SOM variant. If this option is not
>>>  	 enabled then the more common 1GB version will be used.
>>>
>>> +config ENV_SECT_SIZE
>>> +	hex "Environment Sector-Size"
>>> +	# Use SPI flash erase block size of 4 KiB
>>> +	default 0x1000 if MVEBU_SPL_BOOT_DEVICE_SPI
>>> +	# Use optimistic 64 KiB erase block, will vary between actual media
>>> +	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
>>
>> Duplication of config symbols in platform specific Kconfig goes against
>> common practice. Platform specific values should go in
>> defconfig. Support for Clearfog SPI boot should be in a dedicated
>> defconfig, I think.
>>
>> Same comment on patches #9 and #10.
>
> On the config symbol duplication, that's what seemed to be advocated by the
> Kconfig documentation, perhaps I'm reading/interpreting it incorrectly? I
> found examples of doing it how I did and it seemed to match the documented
> inteded usage. From
> https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html:
>     "Default values are not limited to the menu entry where they are
> defined. This means the default can be defined somewhere else or be overridden
> by an earlier definition."

U-Boot code has very few duplicate definitions for setting default
values. I'll let the maintainers decide on that.

> On the topic of a separate defconfig for SPI booting the same platform, I have
> been intentionally trying to avoid that. My use cases include SPI booting, but
> env in MMC, and MMC booting, but env in SPI - I don't intend to make those
> default mechanisms since they're admittedly a bit more esoteric, but I would
> still like them to be easily obtainable using a few custom config definitions
> at build time.
>
>>> +config SYS_SPI_U_BOOT_OFFS
>>> +	hex "address of u-boot payload in SPI flash"
>>> +	default 0x20000
>>> +	depends on MVEBU_SPL_BOOT_DEVICE_SPI
>>
>> It might be better to add u-boot,spl-payload-offset property to the
>> U-Boot specific -u-boot.dtsi file instead.
>
> I hadn't considered that option and it's intriguing, but what would make it
> objectively better? It seems just an alternate location to put a statically
> defined value, having it as a custom U-Boot DTS entry doesn't allow runtime
> changing, does it?

Right. u-boot,spl-payload-offset clobbers the value from
spl_spi_get_uboot_offs() in current code. It's just that I find the DT
property nicer than duplicated config. But I can't think of a technical
reason to prefer DT set offset.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 08/10] arm: mvebu: enable working default boot support

[Joel Johnson]

With the move to driver model usage, ensure that the required driver
support for SPI and MMC booting is available in SPL.

Tested on SolidRun ClearFog devices.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 arch/arm/mach-mvebu/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c6a1a0a944..b3239b2b01 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -234,9 +234,19 @@ choice
 
 config MVEBU_SPL_BOOT_DEVICE_SPI
 	bool "SPI NOR flash"
+	select ENV_IS_IN_SPI_FLASH
+	select SPL_DM_SPI
+	select SPL_MTD_SUPPORT
+	select SPL_SPI_FLASH_SUPPORT
+	select SPL_SPI_LOAD
+	select SPL_SPI_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_MMC
 	bool "SDIO/MMC card"
+	select ENV_IS_IN_MMC
+	# GPIO required for SD card presence detection line
+	select SPL_DM_GPIO
+	select SPL_DM_MMC
 	select SPL_LIBDISK_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
-- 
2.20.1

[PATCH 08/10] arm: mvebu: enable working default boot support

[Joel Johnson]

I've found an issue in testing with the ENV_IS_IN_X values, they need to 
be changed from a "select" to an "imply" to enable disabling default 
values and support booting from MMC and having flash in SPI (or the 
other way around).

I have the change queued for either a second patch submission (pending 
additional review and comments), or subsequent patch.

Joel

On 2020-01-11 12:36, Joel Johnson wrote:
> With the move to driver model usage, ensure that the required driver
> support for SPI and MMC booting is available in SPL.
> 
> Tested on SolidRun ClearFog devices.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
> 
>  arch/arm/mach-mvebu/Kconfig | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index c6a1a0a944..b3239b2b01 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -234,9 +234,19 @@ choice
> 
>  config MVEBU_SPL_BOOT_DEVICE_SPI
>  	bool "SPI NOR flash"
> +	select ENV_IS_IN_SPI_FLASH
> +	select SPL_DM_SPI
> +	select SPL_MTD_SUPPORT
> +	select SPL_SPI_FLASH_SUPPORT
> +	select SPL_SPI_LOAD
> +	select SPL_SPI_SUPPORT
> 
>  config MVEBU_SPL_BOOT_DEVICE_MMC
>  	bool "SDIO/MMC card"
> +	select ENV_IS_IN_MMC
> +	# GPIO required for SD card presence detection line
> +	select SPL_DM_GPIO
> +	select SPL_DM_MMC
>  	select SPL_LIBDISK_SUPPORT
> 
>  config MVEBU_SPL_BOOT_DEVICE_SATA

[PATCH 08/10] arm: mvebu: enable working default boot support

[Stefan Roese]

Hi Joel,

On 11.01.20 22:07, Joel Johnson wrote:
> I've found an issue in testing with the ENV_IS_IN_X values, they need to
> be changed from a "select" to an "imply" to enable disabling default
> values and support booting from MMC and having flash in SPI (or the
> other way around).
> 
> I have the change queued for either a second patch submission (pending
> additional review and comments), or subsequent patch.

As you will most likely rebase your patches on top of Baruch's patches,
please change this patch to using "imply" then.

Thanks,
Stefan
  
> Joel
> 
> On 2020-01-11 12:36, Joel Johnson wrote:
>> With the move to driver model usage, ensure that the required driver
>> support for SPI and MMC booting is available in SPL.
>>
>> Tested on SolidRun ClearFog devices.
>>
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>> ---
>>
>>   arch/arm/mach-mvebu/Kconfig | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>> index c6a1a0a944..b3239b2b01 100644
>> --- a/arch/arm/mach-mvebu/Kconfig
>> +++ b/arch/arm/mach-mvebu/Kconfig
>> @@ -234,9 +234,19 @@ choice
>>
>>   config MVEBU_SPL_BOOT_DEVICE_SPI
>>   	bool "SPI NOR flash"
>> +	select ENV_IS_IN_SPI_FLASH
>> +	select SPL_DM_SPI
>> +	select SPL_MTD_SUPPORT
>> +	select SPL_SPI_FLASH_SUPPORT
>> +	select SPL_SPI_LOAD
>> +	select SPL_SPI_SUPPORT
>>
>>   config MVEBU_SPL_BOOT_DEVICE_MMC
>>   	bool "SDIO/MMC card"
>> +	select ENV_IS_IN_MMC
>> +	# GPIO required for SD card presence detection line
>> +	select SPL_DM_GPIO
>> +	select SPL_DM_MMC
>>   	select SPL_LIBDISK_SUPPORT
>>
>>   config MVEBU_SPL_BOOT_DEVICE_SATA

Viele Grüße,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH 09/10] arm: mvebu: clearfog: move ENV params to Kconfig

[Joel Johnson]

Migrate the values for ENV_SIZE and ENV_OFFSET into board specific
Kconfig defaults so they're more accessible for configuration.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---

 board/solidrun/clearfog/Kconfig | 8 ++++++++
 configs/clearfog_defconfig      | 2 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index ce7fcf653f..253b925ba1 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -37,6 +37,14 @@ config CLEARFOG_2GB_SOM
 	 Enable support for the 2GB RAM SOM variant. If this option is not
 	 enabled then the more common 1GB version will be used.
 
+config ENV_SIZE
+	hex "Environment Size"
+	default 0x10000
+
+config ENV_OFFSET
+	hex "Environment offset"
+	default 0xF0000
+
 config ENV_SECT_SIZE
 	hex "Environment Sector-Size"
 	# Use SPI flash erase block size of 4 KiB
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 787c6360a7..0b55e63079 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -11,8 +11,6 @@ CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
-CONFIG_ENV_SIZE=0x10000
-CONFIG_ENV_OFFSET=0xF0000
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL=y
 CONFIG_DEBUG_UART_BASE=0xd0012000
-- 
2.20.1

[PATCH 09/10] arm: mvebu: clearfog: move ENV params to Kconfig

[Stefan Roese]

On 11.01.20 20:36, Joel Johnson wrote:
> Migrate the values for ENV_SIZE and ENV_OFFSET into board specific
> Kconfig defaults so they're more accessible for configuration.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

The ENV macros have been moved to Kconfig in mainline. Please check
and drop this patch or submit a necessary change if required.

Thanks,
Stefan

> ---
> 
>   board/solidrun/clearfog/Kconfig | 8 ++++++++
>   configs/clearfog_defconfig      | 2 --
>   2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index ce7fcf653f..253b925ba1 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -37,6 +37,14 @@ config CLEARFOG_2GB_SOM
>   	 Enable support for the 2GB RAM SOM variant. If this option is not
>   	 enabled then the more common 1GB version will be used.
>   
> +config ENV_SIZE
> +	hex "Environment Size"
> +	default 0x10000
> +
> +config ENV_OFFSET
> +	hex "Environment offset"
> +	default 0xF0000
> +
>   config ENV_SECT_SIZE
>   	hex "Environment Sector-Size"
>   	# Use SPI flash erase block size of 4 KiB
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index 787c6360a7..0b55e63079 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -11,8 +11,6 @@ CONFIG_TARGET_CLEARFOG=y
>   CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
>   CONFIG_SPL_MMC_SUPPORT=y
>   CONFIG_SPL_SERIAL_SUPPORT=y
> -CONFIG_ENV_SIZE=0x10000
> -CONFIG_ENV_OFFSET=0xF0000
>   CONFIG_NR_DRAM_BANKS=2
>   CONFIG_SPL=y
>   CONFIG_DEBUG_UART_BASE=0xd0012000
> 

Viele Grüße,
Stefan

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Joel Johnson]

Remove MMC booting assumptions from clearfog_defconfig. Their
presence in starting config files conflicts with default ENV_IS_IN
selection logic based on boot source, since the "select" option
can't distinguish between user-overridden and defconfig selected.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---


The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as
well but I couldn't identify an available mechanism to do so.
Requiring it as enabled in the defconfig results in additional items
being unneccessarily included if switching boot device after starting
with the defconfig, as well as ENV_IS_IN_MMC being undesirably
residually defined.

---
 arch/arm/mach-mvebu/Kconfig     | 1 +
 board/solidrun/clearfog/Kconfig | 5 +++++
 configs/clearfog_defconfig      | 3 ---
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index b3239b2b01..3f9aa4b26e 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
 	select SPL_DM_GPIO
 	select SPL_DM_MMC
 	select SPL_LIBDISK_SUPPORT
+	select SPL_MMC_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
 	bool "SATA"
diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 253b925ba1..bd51df8750 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -52,6 +52,11 @@ config ENV_SECT_SIZE
 	# Use optimistic 64 KiB erase block, will vary between actual media
 	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
 
+config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
+	hex "Address on the MMC to load U-Boot from"
+	default 0x141
+	depends on MVEBU_SPL_BOOT_DEVICE_MMC
+
 config SYS_SPI_U_BOOT_OFFS
 	hex "address of u-boot payload in SPI flash"
 	default 0x20000
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 0b55e63079..eab24c32f0 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -9,7 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
-CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL=y
@@ -24,7 +23,6 @@ CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141
 CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
@@ -39,7 +37,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 # CONFIG_SPL_PARTITION_UUIDS is not set
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
-CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_AHCI_MVEBU=y
-- 
2.20.1

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Joel,

On Sat, Jan 11 2020, Joel Johnson wrote:

> Remove MMC booting assumptions from clearfog_defconfig. Their
> presence in starting config files conflicts with default ENV_IS_IN
> selection logic based on boot source, since the "select" option
> can't distinguish between user-overridden and defconfig selected.

As I mentioned in a previous patch review, I believe that SPI boot
support should be in a separate defconfig.

One more comment below.

> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>
>
> The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as
> well but I couldn't identify an available mechanism to do so.
> Requiring it as enabled in the defconfig results in additional items
> being unneccessarily included if switching boot device after starting
> with the defconfig, as well as ENV_IS_IN_MMC being undesirably
> residually defined.
>
> ---
>  arch/arm/mach-mvebu/Kconfig     | 1 +
>  board/solidrun/clearfog/Kconfig | 5 +++++
>  configs/clearfog_defconfig      | 3 ---
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index b3239b2b01..3f9aa4b26e 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
>  	select SPL_DM_GPIO
>  	select SPL_DM_MMC
>  	select SPL_LIBDISK_SUPPORT
> +	select SPL_MMC_SUPPORT
>
>  config MVEBU_SPL_BOOT_DEVICE_SATA
>  	bool "SATA"
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 253b925ba1..bd51df8750 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -52,6 +52,11 @@ config ENV_SECT_SIZE
>  	# Use optimistic 64 KiB erase block, will vary between actual media
>  	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
>
> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> +	hex "Address on the MMC to load U-Boot from"
> +	default 0x141
> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC

You might want to take a look at the series linked below, which
conflicts with this patch:

  https://patchwork.ozlabs.org/project/uboot/list/?series=121894

baruch

> +
>  config SYS_SPI_U_BOOT_OFFS
>  	hex "address of u-boot payload in SPI flash"
>  	default 0x20000
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index 0b55e63079..eab24c32f0 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -9,7 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_TARGET_CLEARFOG=y
>  CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
> -CONFIG_SPL_MMC_SUPPORT=y
>  CONFIG_SPL_SERIAL_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_SPL=y
> @@ -24,7 +23,6 @@ CONFIG_USE_PREBOOT=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141
>  CONFIG_SPL_I2C_SUPPORT=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
> @@ -39,7 +37,6 @@ CONFIG_CMD_CACHE=y
>  CONFIG_CMD_TIME=y
>  # CONFIG_SPL_PARTITION_UUIDS is not set
>  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> -CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_OF_TRANSLATE=y
>  CONFIG_AHCI_MVEBU=y


--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Joel Johnson]

On 2020-01-12 03:49, Baruch Siach wrote:
> Hi Joel,
> 
> On Sat, Jan 11 2020, Joel Johnson wrote:
> 
>> Remove MMC booting assumptions from clearfog_defconfig. Their
>> presence in starting config files conflicts with default ENV_IS_IN
>> selection logic based on boot source, since the "select" option
>> can't distinguish between user-overridden and defconfig selected.
> 
> As I mentioned in a previous patch review, I believe that SPI boot
> support should be in a separate defconfig.

As I responded in a previous patch, I like to specifically avoid that, 
to enable (not by default) mixed media boot and storage locations. The 
current set I have makes the mixed mode almost achievable, except 
needing to explicit set CONFIG_ENV_IS_IN_MMC=n when enabling SPI boot, 
otherwise it boots from SPI and tries to load env from MMC. That's a use 
case I'm after, but isn't what should be a reasonable default given the 
surprise factor if not intended.

> One more comment below.
> 
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>> ---
>> 
>> 
>> The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as
>> well but I couldn't identify an available mechanism to do so.
>> Requiring it as enabled in the defconfig results in additional items
>> being unneccessarily included if switching boot device after starting
>> with the defconfig, as well as ENV_IS_IN_MMC being undesirably
>> residually defined.
>> 
>> ---
>>  arch/arm/mach-mvebu/Kconfig     | 1 +
>>  board/solidrun/clearfog/Kconfig | 5 +++++
>>  configs/clearfog_defconfig      | 3 ---
>>  3 files changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>> index b3239b2b01..3f9aa4b26e 100644
>> --- a/arch/arm/mach-mvebu/Kconfig
>> +++ b/arch/arm/mach-mvebu/Kconfig
>> @@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
>>  	select SPL_DM_GPIO
>>  	select SPL_DM_MMC
>>  	select SPL_LIBDISK_SUPPORT
>> +	select SPL_MMC_SUPPORT
>> 
>>  config MVEBU_SPL_BOOT_DEVICE_SATA
>>  	bool "SATA"
>> diff --git a/board/solidrun/clearfog/Kconfig 
>> b/board/solidrun/clearfog/Kconfig
>> index 253b925ba1..bd51df8750 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -52,6 +52,11 @@ config ENV_SECT_SIZE
>>  	# Use optimistic 64 KiB erase block, will vary between actual media
>>  	default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC
>> 
>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>> +	hex "Address on the MMC to load U-Boot from"
>> +	default 0x141
>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
> 
> You might want to take a look at the series linked below, which
> conflicts with this patch:
> 
>   https://patchwork.ozlabs.org/project/uboot/list/?series=121894

Indeed, the dynamic runtime approach seems much nicer for handling the 
MMCSD offset business, including relative vs. absolute device offset. I 
only have non-eMMC units so can't test it, but I'm all for dropping the 
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that 
patch, in which leaving the defconfig entry does no harm. Any indication 
of when that patch will be included? It seems to have been stagnant for 
a while.

Joel

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Joel,

On Sun, Jan 12 2020, Joel Johnson wrote:
> On 2020-01-12 03:49, Baruch Siach wrote:
>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>>> +	hex "Address on the MMC to load U-Boot from"
>>> +	default 0x141
>>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
>>
>> You might want to take a look at the series linked below, which
>> conflicts with this patch:
>>
>>   https://patchwork.ozlabs.org/project/uboot/list/?series=121894
>
> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
> offset business, including relative vs. absolute device offset. I only have
> non-eMMC units so can't test it, but I'm all for dropping the
> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
> in which leaving the defconfig entry does no harm. Any indication of when that
> patch will be included? It seems to have been stagnant for a while.

Indeed. I'm waiting patiently.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Stefan Roese]

Hi Baruch,

On 12.01.20 17:34, Baruch Siach wrote:
> Hi Joel,
> 
> On Sun, Jan 12 2020, Joel Johnson wrote:
>> On 2020-01-12 03:49, Baruch Siach wrote:
>>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>>>> +	hex "Address on the MMC to load U-Boot from"
>>>> +	default 0x141
>>>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
>>>
>>> You might want to take a look at the series linked below, which
>>> conflicts with this patch:
>>>
>>>    https://patchwork.ozlabs.org/project/uboot/list/?series=121894
>>
>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
>> offset business, including relative vs. absolute device offset. I only have
>> non-eMMC units so can't test it, but I'm all for dropping the
>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
>> in which leaving the defconfig entry does no harm. Any indication of when that
>> patch will be included? It seems to have been stagnant for a while.
> 
> Indeed. I'm waiting patiently.

I have missed addressing this patch series for quite some time, sorry.
Could you please rebase this patchset on top of current mainline as it
doesn't apply any more. And please do a compile run for all targets as
well (Travis). I'll try to push it upstream in this merge window.

Thanks,
Stefan

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Stefan,

On Mon, Jan 13 2020, Stefan Roese wrote:
> On 12.01.20 17:34, Baruch Siach wrote:
>> On Sun, Jan 12 2020, Joel Johnson wrote:
>>> On 2020-01-12 03:49, Baruch Siach wrote:
>>>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>>>>> +	hex "Address on the MMC to load U-Boot from"
>>>>> +	default 0x141
>>>>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
>>>>
>>>> You might want to take a look at the series linked below, which
>>>> conflicts with this patch:
>>>>
>>>>    https://patchwork.ozlabs.org/project/uboot/list/?series=121894
>>>
>>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
>>> offset business, including relative vs. absolute device offset. I only have
>>> non-eMMC units so can't test it, but I'm all for dropping the
>>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
>>> in which leaving the defconfig entry does no harm. Any indication of when that
>>> patch will be included? It seems to have been stagnant for a while.
>>
>> Indeed. I'm waiting patiently.
>
> I have missed addressing this patch series for quite some time, sorry.
> Could you please rebase this patchset on top of current mainline as it
> doesn't apply any more. And please do a compile run for all targets as
> well (Travis). I'll try to push it upstream in this merge window.

Thanks. I'll work on that tomorrow.

While you are at it can you also push this fix:

  https://patchwork.ozlabs.org/patch/1205597/

Clearfog can't boot v2020.01 clearfog_defconfig without it :-(.

Thanks,
baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Stefan Roese]

Hi Baruch,

On 13.01.20 12:40, Baruch Siach wrote:
> Hi Stefan,
> 
> On Mon, Jan 13 2020, Stefan Roese wrote:
>> On 12.01.20 17:34, Baruch Siach wrote:
>>> On Sun, Jan 12 2020, Joel Johnson wrote:
>>>> On 2020-01-12 03:49, Baruch Siach wrote:
>>>>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>>>>>> +	hex "Address on the MMC to load U-Boot from"
>>>>>> +	default 0x141
>>>>>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
>>>>>
>>>>> You might want to take a look at the series linked below, which
>>>>> conflicts with this patch:
>>>>>
>>>>>     https://patchwork.ozlabs.org/project/uboot/list/?series=121894
>>>>
>>>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
>>>> offset business, including relative vs. absolute device offset. I only have
>>>> non-eMMC units so can't test it, but I'm all for dropping the
>>>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
>>>> in which leaving the defconfig entry does no harm. Any indication of when that
>>>> patch will be included? It seems to have been stagnant for a while.
>>>
>>> Indeed. I'm waiting patiently.
>>
>> I have missed addressing this patch series for quite some time, sorry.
>> Could you please rebase this patchset on top of current mainline as it
>> doesn't apply any more. And please do a compile run for all targets as
>> well (Travis). I'll try to push it upstream in this merge window.
> 
> Thanks. I'll work on that tomorrow.

Thanks.
  
> While you are at it can you also push this fix:
> 
>    https://patchwork.ozlabs.org/patch/1205597/
> 
> Clearfog can't boot v2020.01 clearfog_defconfig without it :-(.

Its on my list. I'll pull it with the other patch with my next pull
request.

Thanks,
Stefan

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Stefan,

On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote:
> On 12.01.20 17:34, Baruch Siach wrote:
> > On Sun, Jan 12 2020, Joel Johnson wrote:
> > > On 2020-01-12 03:49, Baruch Siach wrote:
> > > > On Sat, Jan 11 2020, Joel Johnson wrote:
> > > > > +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> > > > > +	hex "Address on the MMC to load U-Boot from"
> > > > > +	default 0x141
> > > > > +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
> > > > 
> > > > You might want to take a look at the series linked below, which
> > > > conflicts with this patch:
> > > > 
> > > >    https://patchwork.ozlabs.org/project/uboot/list/?series=121894
> > > 
> > > Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
> > > offset business, including relative vs. absolute device offset. I only have
> > > non-eMMC units so can't test it, but I'm all for dropping the
> > > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
> > > in which leaving the defconfig entry does no harm. Any indication of when that
> > > patch will be included? It seems to have been stagnant for a while.
> > 
> > Indeed. I'm waiting patiently.
> 
> I have missed addressing this patch series for quite some time, sorry.
> Could you please rebase this patchset on top of current mainline as it
> doesn't apply any more.

The original patch series applies cleanly on top of current master as of 
commit 88366b96ee0d86 ("travis: Switch to QEMU v4.2.0 globally"), and runs 
successfully. It only trivially conflicts with the clearfog_defconfig 
SPL_DM_GPIO fix (http://patchwork.ozlabs.org/patch/1205597/). Would you like 
me to rebase on to of that?

> And please do a compile run for all targets as well (Travis). I'll try to 
> push it upstream in this merge window.

buildman for arm and aarch64 is currently running.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Stefan Roese]

Hi Baruch,

On 14.01.20 13:55, Baruch Siach wrote:
> Hi Stefan,
> 
> On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote:
>> On 12.01.20 17:34, Baruch Siach wrote:
>>> On Sun, Jan 12 2020, Joel Johnson wrote:
>>>> On 2020-01-12 03:49, Baruch Siach wrote:
>>>>> On Sat, Jan 11 2020, Joel Johnson wrote:
>>>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>>>>>> +	hex "Address on the MMC to load U-Boot from"
>>>>>> +	default 0x141
>>>>>> +	depends on MVEBU_SPL_BOOT_DEVICE_MMC
>>>>>
>>>>> You might want to take a look at the series linked below, which
>>>>> conflicts with this patch:
>>>>>
>>>>>     https://patchwork.ozlabs.org/project/uboot/list/?series=121894
>>>>
>>>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD
>>>> offset business, including relative vs. absolute device offset. I only have
>>>> non-eMMC units so can't test it, but I'm all for dropping the
>>>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch,
>>>> in which leaving the defconfig entry does no harm. Any indication of when that
>>>> patch will be included? It seems to have been stagnant for a while.
>>>
>>> Indeed. I'm waiting patiently.
>>
>> I have missed addressing this patch series for quite some time, sorry.
>> Could you please rebase this patchset on top of current mainline as it
>> doesn't apply any more.
> 
> The original patch series applies cleanly on top of current master as of
> commit 88366b96ee0d86 ("travis: Switch to QEMU v4.2.0 globally"), and runs
> successfully. It only trivially conflicts with the clearfog_defconfig
> SPL_DM_GPIO fix (http://patchwork.ozlabs.org/patch/1205597/). Would you like
> me to rebase on to of that?

Yes, please.
  
>> And please do a compile run for all targets as well (Travis). I'll try to
>> push it upstream in this merge window.
> 
> buildman for arm and aarch64 is currently running.

All platforms please. I suggest to use Travis for this. Be prepared that
this takes a few hours though.

Thanks,
Stefan

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Stefan,

On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote:
> On 14.01.20 13:55, Baruch Siach wrote:
> > On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote:
> > > And please do a compile run for all targets as well (Travis). I'll try 
> > > to push it upstream in this merge window.
> > 
> > buildman for arm and aarch64 is currently running.
> 
> All platforms please. I suggest to use Travis for this. Be prepared that
> this takes a few hours though.

Do you refer to travis-ci.org integration with github.com? Something else?

Travis CI wants access to github repos of all organizations my account is 
authorized to access. I can't do that.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Stefan Roese]

Hi Baruch,

On 14.01.20 15:53, Baruch Siach wrote:
> Hi Stefan,
> 
> On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote:
>> On 14.01.20 13:55, Baruch Siach wrote:
>>> On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote:
>>>> And please do a compile run for all targets as well (Travis). I'll try
>>>> to push it upstream in this merge window.
>>>
>>> buildman for arm and aarch64 is currently running.
>>
>> All platforms please. I suggest to use Travis for this. Be prepared that
>> this takes a few hours though.
> 
> Do you refer to travis-ci.org integration with github.com? Something else?

Yes, that's how I use it.
  
> Travis CI wants access to github repos of all organizations my account is
> authorized to access. I can't do that.

Hmmm, I don't remember this Travis configuration. I do have a "private"
github account with a U-Boot repository, where I push the commits to
and Travis automatically starts the build after the push. Perhaps its
possible for you to create a new (private?) github account for such a
task?

Otherwise its of course also ok, if you build all platforms (not only
ARM please if your changes touch global files) via buildman locally.

Thanks,
Stefan

[PATCH 10/10] arm: mvebu: clearfog: don't assume MMC booting

[Baruch Siach]

Hi Stefan,

On Tue, Jan 14 2020, Stefan Roese wrote:
> On 14.01.20 15:53, Baruch Siach wrote:
>> On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote:
>>> On 14.01.20 13:55, Baruch Siach wrote:
>>>> On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote:
>>>>> And please do a compile run for all targets as well (Travis). I'll try
>>>>> to push it upstream in this merge window.
>>>>
>>>> buildman for arm and aarch64 is currently running.
>>>
>>> All platforms please. I suggest to use Travis for this. Be prepared that
>>> this takes a few hours though.
>>
>> Do you refer to travis-ci.org integration with github.com? Something else?
>
> Yes, that's how I use it.
>  
>> Travis CI wants access to github repos of all organizations my account is
>> authorized to access. I can't do that.
>
> Hmmm, I don't remember this Travis configuration. I do have a "private"
> github account with a U-Boot repository, where I push the commits to
> and Travis automatically starts the build after the push. Perhaps its
> possible for you to create a new (private?) github account for such a
> task?

OK. I created a new github account for that. Travis CI build passed:

  https://travis-ci.com/baruchsiach-travis/u-boot/builds/144357746

I'll post the updated series shortly.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 01/10] arm: mvebu: fix SerDes table alignment

[Stefan Roese]

On 11.01.20 20:36, Joel Johnson wrote:
> Tested on Solidrun ClearFog Base. Table alignment was:
>   | Lane #  | Speed |  Type       |
>   --------------------------------
>   |   0    |  3   |  SATA0       |
>   |   1    |  0   |  SGMII1      |
>   |   2    |  3   |  SATA1       |
>   |   3    |  5   |  USB3 HOST1  |
>   |   4    |  5   |  USB3 HOST0  |
>   |   5    |  4   |  SGMII2      |
>   --------------------------------
> 
> After the change, it's correctly aligned as:
>   | Lane # | Speed |  Type       |
>   --------------------------------
>   |   0    |   3   | SATA0       |
>   |   1    |   0   | SGMII1      |
>   |   2    |   5   | PCIe1       |
>   |   3    |   5   | USB3 HOST1  |
>   |   4    |   5   | PCIe2       |
>   |   5    |   0   | SGMII2      |
>   --------------------------------
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
> 
>   arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
> index 33e70569bc..66409a50c0 100644
> --- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
> +++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
> @@ -1366,16 +1366,16 @@ static void print_topology_details(const struct serdes_map *serdes_map,
>   
>   	DEBUG_INIT_S("board SerDes lanes topology details:\n");
>   
> -	DEBUG_INIT_S(" | Lane #  | Speed |  Type       |\n");
> +	DEBUG_INIT_S(" | Lane # | Speed |  Type       |\n");
>   	DEBUG_INIT_S(" --------------------------------\n");
>   	for (lane_num = 0; lane_num < count; lane_num++) {
>   		if (serdes_map[lane_num].serdes_type == DEFAULT_SERDES)
>   			continue;
>   		DEBUG_INIT_S(" |   ");
>   		DEBUG_INIT_D(hws_get_physical_serdes_num(lane_num), 1);
> -		DEBUG_INIT_S("    |  ");
> +		DEBUG_INIT_S("    |   ");
>   		DEBUG_INIT_D(serdes_map[lane_num].serdes_speed, 2);
> -		DEBUG_INIT_S("   |  ");
> +		DEBUG_INIT_S("   | ");
>   		DEBUG_INIT_S((char *)
>   			     serdes_type_to_string[serdes_map[lane_num].
>   						   serdes_type]);
> 

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan