[PATCH v5 00/12] ClearFog Base static variant support

public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed

* [PATCH v5 00/12] ClearFog Base static variant support
@ 2020-01-27 20:01 Joel Johnson
  2020-01-27 20:01 ` [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
                   ` (12 more replies)
  0 siblings, 13 replies; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot


This patch series adds support for ClearFog Base static configuration,
as well as updating and fixing the ClearFog support for MMC and SPI
booting.

v2 changes:
  - updated against, and dependent on, https://patchwork.ozlabs.org/cover/1200324
v3 changes:
  - rebased against ClearFog runtime TLV EEPROM changes merged into mvebu/master
v4
  - adjust static SerDes configuration at runtime instead of #ifdef
v5
  - distinguish build-only config changes (SFP and PCIe/SATA) from
    runtime detectable config changes
  - retested SATA mode in PCIe slot with swap rx changes, confirmed
    working as presently patched. Only tested with ClearFog Base which
    only provides single channel, but Pro mechanism is parallel.


Joel Johnson (12):
  arm: mvebu: fix SerDes table alignment
  arm: mvebu: solidrun: remove hardcoded DTS MAC address
  arm: mvebu: clearfog: use Pro name by default
  arm: mvebu: clearfog: initial ClearFog Base variant
  arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  arm: mvebu: clearfog: Add SATA mode flags
  arm: mvebu: clearfog: Unify DT selection paths
  arm: mvebu: clearfog: add SPI offsets
  arm: mvebu: enable working default boot support
  arm: mvebu: clearfog: move ENV params to Kconfig
  arm: mvebu: clearfog: don't always use SPL MMC
  arm: mvebu: clearfog: Use Pro DT by default

 .../arm/dts/armada-38x-solidrun-microsom.dtsi |  1 -
 arch/arm/mach-mvebu/Kconfig                   | 13 ++++
 .../serdes/a38x/high_speed_env_spec.c         |  6 +-
 board/solidrun/clearfog/Kconfig               | 62 +++++++++++++++++++
 board/solidrun/clearfog/clearfog.c            | 53 +++++++++++++---
 configs/clearfog_defconfig                    |  4 --
 include/configs/clearfog.h                    |  1 -
 7 files changed, 124 insertions(+), 16 deletions(-)
 create mode 100644 board/solidrun/clearfog/Kconfig

-- 
2.20.1

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:04   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
                   ` (11 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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>

---

v2 changes
  - none
v3 changes
  - none
v4 changes
  - none
v5 changes
  - none

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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment
  2020-01-27 20:01 ` [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
@ 2020-03-23  9:04   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:04 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, 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>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
  2020-01-27 20:01 ` [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:05   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default Joel Johnson
                   ` (10 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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>

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none
v5 changes:
  - none

---
 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 a322a28c21..9bbeafc53b 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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address
  2020-01-27 20:01 ` [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
@ 2020-03-23  9:05   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:05 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, 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>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
  2020-01-27 20:01 ` [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
  2020-01-27 20:01 ` [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:07   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
                   ` (9 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

Make the board version printed indicate the Pro variant default.
Also adjust static name casing to match what is expected for
EEPROM product name to share string constants.

---

v4 changes:
  - newly added
v5 changes:
  - none

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---
 board/solidrun/clearfog/clearfog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index e268ef55a2..9b31902c70 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -170,7 +170,7 @@ int board_init(void)
 
 int checkboard(void)
 {
-	char *board = "ClearFog";
+	char *board = "Clearfog Pro";
 
 	cf_read_tlv_data();
 	if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default
  2020-01-27 20:01 ` [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default Joel Johnson
@ 2020-03-23  9:07   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:07 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> Make the board version printed indicate the Pro variant default.
> Also adjust static name casing to match what is expected for
> EEPROM product name to share string constants.
> 
> ---
> 
> v4 changes:
>    - newly added
> v5 changes:
>    - none
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

Please make sure put your S-o-b line above the first "---" line next
time.

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (2 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:11   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
                   ` (8 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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>

---

v2 changes:
  - reworked based on Baruch's run-time TLV EEPROM detection series
v3 changes:
  - rebased on mvebu merged run-time TLV EEPROM detection series
  - minor update to help test regarding runtime detection failures
v4 changes:
  - use runtime static config adjust instead of #ifdef in cases where
    hardware EEPROM detection fails or is disabled in build
    SPL size change for defconfig increases 36 bytes (122893 to 122929)
    SPL size change for defconfig+Base increases 60 bytes (122893 to 122953)
  - add placeholder support for EEPROM based Clearfog Pro, based on
    initial name confirmation from Baruch. I wanted to include the check
    at least in the patch for review to indicate expected usage to
    ensure that a Clearfog Pro EEPROM device boots correctly even if the
    image is built with Base static configuration. If there are other
    prerelease concerns and this should be added separately later, I'd
    be fine with that too.
  - Note that this approach *does not* currently provide any mechanism
    for EEPROM detected boards to have their SFP speed changed or switch
    between PCIE/SATA signalling. I'm assuming that will be done based on
    hardware detection, but confirmation/acceptance in review would be
    appreciated so it can be revisited if needed.
v5 changes:
  - only make Base variant adjustment based on runtime configuration

---
 arch/arm/mach-mvebu/Kconfig        |  2 ++
 board/solidrun/clearfog/Kconfig    | 18 ++++++++++++++++++
 board/solidrun/clearfog/clearfog.c | 29 +++++++++++++++++++++++------
 3 files changed, 43 insertions(+), 6 deletions(-)
 create mode 100644 board/solidrun/clearfog/Kconfig

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index bc5eaa5a76..161dee937f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -280,4 +280,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..936d5918f8
--- /dev/null
+++ b/board/solidrun/clearfog/Kconfig
@@ -0,0 +1,18 @@
+menu "ClearFog configuration"
+	depends on TARGET_CLEARFOG
+
+config TARGET_CLEARFOG_BASE
+	bool "Use ClearFog Base static configuration"
+	help
+	  Use the ClearFog Base as the static configuration instead of the
+	  default which uses the ClearFog Pro.
+
+	  Runtime board detection is always attempted and used if available. The
+	  static configuration is used as a fallback in cases where runtime
+	  detection is disabled, is not available in hardware, or otherwise fails.
+
+	  Only newer revisions of the ClearFog product line support runtime
+	  detection via additional EEPROM hardware. This option enables selecting
+	  the Base variant for older hardware revisions.
+
+endmenu
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 9b31902c70..c873d00905 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -42,6 +42,7 @@ static void cf_read_tlv_data(void)
 	read_tlv_data(&cf_tlv_data);
 }
 
+/* The starting board_serdes_map reflects original Clearfog Pro usage */
 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},
@@ -51,6 +52,13 @@ static struct serdes_map board_serdes_map[] = {
 	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
 };
 
+void config_cfbase_serdes_map(void)
+{
+	board_serdes_map[4].serdes_type = USB3_HOST0;
+	board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
+	board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+}
+
 int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 {
 	cf_read_tlv_data();
@@ -59,12 +67,17 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 		board_serdes_map[0].serdes_type = PEX0;
 		board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
 		board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
-	}
-
-	if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
-		board_serdes_map[4].serdes_type = USB3_HOST0;
-		board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
-		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+	} else if (sr_product_is(&cf_tlv_data, "Clearfog Pro")) {
+		/* handle recognized product as noop, no adjustment required */
+	} else if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
+		config_cfbase_serdes_map();
+	} else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
+		/*
+		 * Fallback to static default. Runtime detection failed,
+		 * hardware support is not present, EEPROM is corrupt,
+		 * or an unrecognized product name is present.
+		 */
+		config_cfbase_serdes_map();
 	}
 
 	*serdes_map_array = board_serdes_map;
@@ -171,6 +184,8 @@ int board_init(void)
 int checkboard(void)
 {
 	char *board = "Clearfog Pro";
+	if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
+		board = "Clearfog Base";
 
 	cf_read_tlv_data();
 	if (strlen(cf_tlv_data.tlv_product_name[0]) > 0)
@@ -200,6 +215,8 @@ int board_late_init(void)
 		env_set("fdtfile", "armada-385-clearfog-gtr-s4.dtb");
 	else if (sr_product_is(&cf_tlv_data, "Clearfog GTR L8"))
 		env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
+	else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
+		env_set("fdtfile", "armada-388-clearfog-base.dtb");
 
 	return 0;
 }
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant
  2020-01-27 20:01 ` [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
@ 2020-03-23  9:11   ` Stefan Roese
  2020-03-23 15:27     ` Joel Johnson
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:11 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, 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>
> 
> ---
> 
> v2 changes:
>    - reworked based on Baruch's run-time TLV EEPROM detection series
> v3 changes:
>    - rebased on mvebu merged run-time TLV EEPROM detection series
>    - minor update to help test regarding runtime detection failures
> v4 changes:
>    - use runtime static config adjust instead of #ifdef in cases where
>      hardware EEPROM detection fails or is disabled in build
>      SPL size change for defconfig increases 36 bytes (122893 to 122929)
>      SPL size change for defconfig+Base increases 60 bytes (122893 to 122953)
>    - add placeholder support for EEPROM based Clearfog Pro, based on
>      initial name confirmation from Baruch. I wanted to include the check
>      at least in the patch for review to indicate expected usage to
>      ensure that a Clearfog Pro EEPROM device boots correctly even if the
>      image is built with Base static configuration. If there are other
>      prerelease concerns and this should be added separately later, I'd
>      be fine with that too.
>    - Note that this approach *does not* currently provide any mechanism
>      for EEPROM detected boards to have their SFP speed changed or switch
>      between PCIE/SATA signalling. I'm assuming that will be done based on
>      hardware detection, but confirmation/acceptance in review would be
>      appreciated so it can be revisited if needed.
> v5 changes:
>    - only make Base variant adjustment based on runtime configuration
> 
> ---
>   arch/arm/mach-mvebu/Kconfig        |  2 ++
>   board/solidrun/clearfog/Kconfig    | 18 ++++++++++++++++++
>   board/solidrun/clearfog/clearfog.c | 29 +++++++++++++++++++++++------
>   3 files changed, 43 insertions(+), 6 deletions(-)
>   create mode 100644 board/solidrun/clearfog/Kconfig
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index bc5eaa5a76..161dee937f 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -280,4 +280,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..936d5918f8
> --- /dev/null
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -0,0 +1,18 @@
> +menu "ClearFog configuration"
> +	depends on TARGET_CLEARFOG
> +
> +config TARGET_CLEARFOG_BASE
> +	bool "Use ClearFog Base static configuration"
> +	help
> +	  Use the ClearFog Base as the static configuration instead of the
> +	  default which uses the ClearFog Pro.
> +
> +	  Runtime board detection is always attempted and used if available. The
> +	  static configuration is used as a fallback in cases where runtime
> +	  detection is disabled, is not available in hardware, or otherwise fails.
> +
> +	  Only newer revisions of the ClearFog product line support runtime
> +	  detection via additional EEPROM hardware. This option enables selecting
> +	  the Base variant for older hardware revisions.
> +
> +endmenu
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 9b31902c70..c873d00905 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -42,6 +42,7 @@ static void cf_read_tlv_data(void)
>   	read_tlv_data(&cf_tlv_data);
>   }
>   
> +/* The starting board_serdes_map reflects original Clearfog Pro usage */
>   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},
> @@ -51,6 +52,13 @@ static struct serdes_map board_serdes_map[] = {
>   	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>   };
>   
> +void config_cfbase_serdes_map(void)
> +{
> +	board_serdes_map[4].serdes_type = USB3_HOST0;
> +	board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
> +	board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> +}
> +
>   int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>   {
>   	cf_read_tlv_data();
> @@ -59,12 +67,17 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>   		board_serdes_map[0].serdes_type = PEX0;
>   		board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
>   		board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
> -	}
> -
> -	if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
> -		board_serdes_map[4].serdes_type = USB3_HOST0;
> -		board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
> -		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> +	} else if (sr_product_is(&cf_tlv_data, "Clearfog Pro")) {
> +		/* handle recognized product as noop, no adjustment required */
> +	} else if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
> +		config_cfbase_serdes_map();
> +	} else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
> +		/*
> +		 * Fallback to static default. Runtime detection failed,
> +		 * hardware support is not present, EEPROM is corrupt,
> +		 * or an unrecognized product name is present.
> +		 */
> +		config_cfbase_serdes_map();
>   	}

Would it make sense to add a message, if no board type has been
"detected" here at all (else case)?

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant
  2020-03-23  9:11   ` Stefan Roese
@ 2020-03-23 15:27     ` Joel Johnson
  0 siblings, 0 replies; 35+ messages in thread
From: Joel Johnson @ 2020-03-23 15:27 UTC (permalink / raw)
  To: u-boot

On 2020-03-23 03:11, Stefan Roese wrote:
> On 27.01.20 21:01, 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>
>> 
>> ---
>> 
>> v2 changes:
>>    - reworked based on Baruch's run-time TLV EEPROM detection series
>> v3 changes:
>>    - rebased on mvebu merged run-time TLV EEPROM detection series
>>    - minor update to help test regarding runtime detection failures
>> v4 changes:
>>    - use runtime static config adjust instead of #ifdef in cases where
>>      hardware EEPROM detection fails or is disabled in build
>>      SPL size change for defconfig increases 36 bytes (122893 to 
>> 122929)
>>      SPL size change for defconfig+Base increases 60 bytes (122893 to 
>> 122953)
>>    - add placeholder support for EEPROM based Clearfog Pro, based on
>>      initial name confirmation from Baruch. I wanted to include the 
>> check
>>      at least in the patch for review to indicate expected usage to
>>      ensure that a Clearfog Pro EEPROM device boots correctly even if 
>> the
>>      image is built with Base static configuration. If there are other
>>      prerelease concerns and this should be added separately later, 
>> I'd
>>      be fine with that too.
>>    - Note that this approach *does not* currently provide any 
>> mechanism
>>      for EEPROM detected boards to have their SFP speed changed or 
>> switch
>>      between PCIE/SATA signalling. I'm assuming that will be done 
>> based on
>>      hardware detection, but confirmation/acceptance in review would 
>> be
>>      appreciated so it can be revisited if needed.
>> v5 changes:
>>    - only make Base variant adjustment based on runtime configuration
>> 
>> ---
>>   arch/arm/mach-mvebu/Kconfig        |  2 ++
>>   board/solidrun/clearfog/Kconfig    | 18 ++++++++++++++++++
>>   board/solidrun/clearfog/clearfog.c | 29 
>> +++++++++++++++++++++++------
>>   3 files changed, 43 insertions(+), 6 deletions(-)
>>   create mode 100644 board/solidrun/clearfog/Kconfig
>> 
>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>> index bc5eaa5a76..161dee937f 100644
>> --- a/arch/arm/mach-mvebu/Kconfig
>> +++ b/arch/arm/mach-mvebu/Kconfig
>> @@ -280,4 +280,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..936d5918f8
>> --- /dev/null
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -0,0 +1,18 @@
>> +menu "ClearFog configuration"
>> +	depends on TARGET_CLEARFOG
>> +
>> +config TARGET_CLEARFOG_BASE
>> +	bool "Use ClearFog Base static configuration"
>> +	help
>> +	  Use the ClearFog Base as the static configuration instead of the
>> +	  default which uses the ClearFog Pro.
>> +
>> +	  Runtime board detection is always attempted and used if available. 
>> The
>> +	  static configuration is used as a fallback in cases where runtime
>> +	  detection is disabled, is not available in hardware, or otherwise 
>> fails.
>> +
>> +	  Only newer revisions of the ClearFog product line support runtime
>> +	  detection via additional EEPROM hardware. This option enables 
>> selecting
>> +	  the Base variant for older hardware revisions.
>> +
>> +endmenu
>> diff --git a/board/solidrun/clearfog/clearfog.c 
>> b/board/solidrun/clearfog/clearfog.c
>> index 9b31902c70..c873d00905 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -42,6 +42,7 @@ static void cf_read_tlv_data(void)
>>   	read_tlv_data(&cf_tlv_data);
>>   }
>>   +/* The starting board_serdes_map reflects original Clearfog Pro 
>> usage */
>>   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},
>> @@ -51,6 +52,13 @@ static struct serdes_map board_serdes_map[] = {
>>   	{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>>   };
>>   +void config_cfbase_serdes_map(void)
>> +{
>> +	board_serdes_map[4].serdes_type = USB3_HOST0;
>> +	board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
>> +	board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
>> +}
>> +
>>   int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 
>> *count)
>>   {
>>   	cf_read_tlv_data();
>> @@ -59,12 +67,17 @@ int hws_board_topology_load(struct serdes_map 
>> **serdes_map_array, u8 *count)
>>   		board_serdes_map[0].serdes_type = PEX0;
>>   		board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
>>   		board_serdes_map[0].serdes_mode = PEX_ROOT_COMPLEX_X1;
>> -	}
>> -
>> -	if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
>> -		board_serdes_map[4].serdes_type = USB3_HOST0;
>> -		board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
>> -		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
>> +	} else if (sr_product_is(&cf_tlv_data, "Clearfog Pro")) {
>> +		/* handle recognized product as noop, no adjustment required */
>> +	} else if (sr_product_is(&cf_tlv_data, "Clearfog Base")) {
>> +		config_cfbase_serdes_map();
>> +	} else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
>> +		/*
>> +		 * Fallback to static default. Runtime detection failed,
>> +		 * hardware support is not present, EEPROM is corrupt,
>> +		 * or an unrecognized product name is present.
>> +		 */
>> +		config_cfbase_serdes_map();
>>   	}
> 
> Would it make sense to add a message, if no board type has been
> "detected" here at all (else case)?
> 
> Thanks,
> Stefan

I suppose it could, I was using the printed board model but that itself 
isn't enough to distinguish between an EEPROM detected unit and a static 
fallback.

Joel

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (3 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:14   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
                   ` (7 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

While newer Linux kernels provide autoconfiguration of SFP, provide
an option for setting in U-Boot Kconfig for use prior to booting.

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

---

v2 changes:
  - fixed help indentation
v3 changes:
  - none
v4 changes:
  - adjust static SerDes configuration at runtime instead of #ifdef
v5 changes:
  - make independent of runtime detection

---
 board/solidrun/clearfog/Kconfig    | 7 +++++++
 board/solidrun/clearfog/clearfog.c | 5 +++++
 2 files changed, 12 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 936d5918f8..c910e17093 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
 	  detection via additional EEPROM hardware. This option enables selecting
 	  the Base variant for older hardware revisions.
 
+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 c873d00905..064ce4e520 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -63,6 +63,11 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 {
 	cf_read_tlv_data();
 
+	/* Apply build configuration options before runtime configuration */
+	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
+		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
+
+	/* Apply runtime detection changes */
 	if (sr_product_is(&cf_tlv_data, "Clearfog GTR")) {
 		board_serdes_map[0].serdes_type = PEX0;
 		board_serdes_map[0].serdes_speed = SERDES_SPEED_5_GBPS;
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  2020-01-27 20:01 ` [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
@ 2020-03-23  9:14   ` Stefan Roese
  2020-03-23  9:33     ` Baruch Siach
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:14 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> While newer Linux kernels provide autoconfiguration of SFP, provide
> an option for setting in U-Boot Kconfig for use prior to booting.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> 
> ---
> 
> v2 changes:
>    - fixed help indentation
> v3 changes:
>    - none
> v4 changes:
>    - adjust static SerDes configuration at runtime instead of #ifdef
> v5 changes:
>    - make independent of runtime detection
> 
> ---
>   board/solidrun/clearfog/Kconfig    | 7 +++++++
>   board/solidrun/clearfog/clearfog.c | 5 +++++
>   2 files changed, 12 insertions(+)
> 
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index 936d5918f8..c910e17093 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>   	  detection via additional EEPROM hardware. This option enables selecting
>   	  the Base variant for older hardware revisions.
>   
> +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 c873d00905..064ce4e520 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -63,6 +63,11 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>   {
>   	cf_read_tlv_data();
>   
> +	/* Apply build configuration options before runtime configuration */
> +	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
> +		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;

Just checking: Your option is for 2.5 gbps and you configure here to
3.125 gpbs. Is this intended?

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  2020-03-23  9:14   ` Stefan Roese
@ 2020-03-23  9:33     ` Baruch Siach
  2020-03-23  9:46       ` Stefan Roese
  0 siblings, 1 reply; 35+ messages in thread
From: Baruch Siach @ 2020-03-23  9:33 UTC (permalink / raw)
  To: u-boot

Hi Stefan,

On Mon, Mar 23 2020, Stefan Roese wrote:

> On 27.01.20 21:01, Joel Johnson wrote:
>> While newer Linux kernels provide autoconfiguration of SFP, provide
>> an option for setting in U-Boot Kconfig for use prior to booting.
>>
>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>
>> ---
>>
>> v2 changes:
>>    - fixed help indentation
>> v3 changes:
>>    - none
>> v4 changes:
>>    - adjust static SerDes configuration at runtime instead of #ifdef
>> v5 changes:
>>    - make independent of runtime detection
>>
>> ---
>>   board/solidrun/clearfog/Kconfig    | 7 +++++++
>>   board/solidrun/clearfog/clearfog.c | 5 +++++
>>   2 files changed, 12 insertions(+)
>>
>> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
>> index 936d5918f8..c910e17093 100644
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>>   	  detection via additional EEPROM hardware. This option enables selecting
>>   	  the Base variant for older hardware revisions.
>>   +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 c873d00905..064ce4e520 100644
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> @@ -63,6 +63,11 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>>   {
>>   	cf_read_tlv_data();
>>   +	/* Apply build configuration options before runtime configuration */
>> +	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>> +		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>
> Just checking: Your option is for 2.5 gbps and you configure here to
> 3.125 gpbs. Is this intended?

This is intended. Serdes encoding is 8b/10b. So for 2.5Gbps you need
serdes rate of 3.125Gbps. For 1Gbps we already set 1.25Gpbs serdes rate
(SERDES_SPEED_1_25_GBPS) in board_serdes_map[].

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 -

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
  2020-03-23  9:33     ` Baruch Siach
@ 2020-03-23  9:46       ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:46 UTC (permalink / raw)
  To: u-boot



On 23.03.20 10:33, Baruch Siach wrote:
> Hi Stefan,
> 
> On Mon, Mar 23 2020, Stefan Roese wrote:
> 
>> On 27.01.20 21:01, Joel Johnson wrote:
>>> While newer Linux kernels provide autoconfiguration of SFP, provide
>>> an option for setting in U-Boot Kconfig for use prior to booting.
>>>
>>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>>
>>> ---
>>>
>>> v2 changes:
>>>     - fixed help indentation
>>> v3 changes:
>>>     - none
>>> v4 changes:
>>>     - adjust static SerDes configuration at runtime instead of #ifdef
>>> v5 changes:
>>>     - make independent of runtime detection
>>>
>>> ---
>>>    board/solidrun/clearfog/Kconfig    | 7 +++++++
>>>    board/solidrun/clearfog/clearfog.c | 5 +++++
>>>    2 files changed, 12 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
>>> index 936d5918f8..c910e17093 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>>>    	  detection via additional EEPROM hardware. This option enables selecting
>>>    	  the Base variant for older hardware revisions.
>>>    +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 c873d00905..064ce4e520 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -63,6 +63,11 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>>>    {
>>>    	cf_read_tlv_data();
>>>    +	/* Apply build configuration options before runtime configuration */
>>> +	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>>> +		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>>
>> Just checking: Your option is for 2.5 gbps and you configure here to
>> 3.125 gpbs. Is this intended?
> 
> This is intended. Serdes encoding is 8b/10b. So for 2.5Gbps you need
> serdes rate of 3.125Gbps. For 1Gbps we already set 1.25Gpbs serdes rate
> (SERDES_SPEED_1_25_GBPS) in board_serdes_map[].

Makes sense. Thanks.

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (4 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-01-28  6:06   ` Baruch Siach
  2020-03-23  9:18   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths Joel Johnson
                   ` (6 subsequent siblings)
  12 siblings, 2 replies; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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

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

---

v2 changes:
  - fixed help indentation
v3 changes:
  - none
v4 changes:
  - adjust static SerDes configuration at runtime instead of #ifdef
  - add setting of swap_rx for SATA (as yet untested on hardware)
v5 changes:
  - make independent of runtime detection

---
 board/solidrun/clearfog/Kconfig    | 17 +++++++++++++++++
 board/solidrun/clearfog/clearfog.c | 15 +++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index c910e17093..44224d903d 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -15,6 +15,23 @@ config TARGET_CLEARFOG_BASE
 	  detection via additional EEPROM hardware. This option enables selecting
 	  the Base variant for older hardware revisions.
 
+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.
+
 config CLEARFOG_SFP_25GB
 	bool "Enable 2.5 Gbps mode for SFP"
 	help
diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 064ce4e520..f650e2b40e 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -67,6 +67,21 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
 	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
 		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
 
+	if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA) &&
+	    !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
+		board_serdes_map[4].serdes_type = SATA2;
+		board_serdes_map[4].serdes_speed = SERDES_SPEED_3_GBPS;
+		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
+		board_serdes_map[4].swap_rx = 1;
+	}
+
+	if (IS_ENABLED(CONFIG_CLEARFOG_CON3_SATA)) {
+		board_serdes_map[2].serdes_type = SATA1;
+		board_serdes_map[2].serdes_speed = SERDES_SPEED_3_GBPS;
+		board_serdes_map[2].serdes_mode = SERDES_DEFAULT_MODE;
+		board_serdes_map[2].swap_rx = 1;
+	}
+
 	/* Apply runtime detection changes */
 	if (sr_product_is(&cf_tlv_data, "Clearfog GTR")) {
 		board_serdes_map[0].serdes_type = PEX0;
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags
  2020-01-27 20:01 ` [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
@ 2020-01-28  6:06   ` Baruch Siach
  2020-01-28  6:34     ` Joel Johnson
  2020-03-23  9:18   ` Stefan Roese
  1 sibling, 1 reply; 35+ messages in thread
From: Baruch Siach @ 2020-01-28  6:06 UTC (permalink / raw)
  To: u-boot

Hi Joel,

On Mon, Jan 27, 2020 at 01:01:50PM -0700, Joel Johnson wrote:
> The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
> configured for SATA usage.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> 
> ---
> 
> v2 changes:
>   - fixed help indentation
> v3 changes:
>   - none
> v4 changes:
>   - adjust static SerDes configuration at runtime instead of #ifdef
>   - add setting of swap_rx for SATA (as yet untested on hardware)
> v5 changes:
>   - make independent of runtime detection
> 
> ---
>  board/solidrun/clearfog/Kconfig    | 17 +++++++++++++++++
>  board/solidrun/clearfog/clearfog.c | 15 +++++++++++++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index c910e17093..44224d903d 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,6 +15,23 @@ config TARGET_CLEARFOG_BASE
>  	  detection via additional EEPROM hardware. This option enables selecting
>  	  the Base variant for older hardware revisions.
>  
> +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.
> +
>  config CLEARFOG_SFP_25GB
>  	bool "Enable 2.5 Gbps mode for SFP"
>  	help
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 064ce4e520..f650e2b40e 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -67,6 +67,21 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>  	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>  		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>  
> +	if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA) &&
> +	    !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {

This second condition looks redundant. CONFIG_CLEARFOG_CON2_SATA already 
depends on !CONFIG_TARGET_CLEARFOG_BASE at the Kconfig level above.

Looks good to me otherwise.

Have you had a chance to test mSATA?

> +		board_serdes_map[4].serdes_type = SATA2;
> +		board_serdes_map[4].serdes_speed = SERDES_SPEED_3_GBPS;
> +		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> +		board_serdes_map[4].swap_rx = 1;
> +	}
> +
> +	if (IS_ENABLED(CONFIG_CLEARFOG_CON3_SATA)) {
> +		board_serdes_map[2].serdes_type = SATA1;
> +		board_serdes_map[2].serdes_speed = SERDES_SPEED_3_GBPS;
> +		board_serdes_map[2].serdes_mode = SERDES_DEFAULT_MODE;
> +		board_serdes_map[2].swap_rx = 1;
> +	}
> +
>  	/* Apply runtime detection changes */
>  	if (sr_product_is(&cf_tlv_data, "Clearfog GTR")) {
>  		board_serdes_map[0].serdes_type = PEX0;

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 -

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags
  2020-01-28  6:06   ` Baruch Siach
@ 2020-01-28  6:34     ` Joel Johnson
  0 siblings, 0 replies; 35+ messages in thread
From: Joel Johnson @ 2020-01-28  6:34 UTC (permalink / raw)
  To: u-boot

On 2020-01-27 23:06, Baruch Siach wrote:
> Hi Joel,
> 
> On Mon, Jan 27, 2020 at 01:01:50PM -0700, Joel Johnson wrote:
>> --- a/board/solidrun/clearfog/Kconfig
>> +++ b/board/solidrun/clearfog/Kconfig
>> +
>> +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.
>> +
>> --- a/board/solidrun/clearfog/clearfog.c
>> +++ b/board/solidrun/clearfog/clearfog.c
>> +	if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA) &&
>> +	    !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
> 
> This second condition looks redundant. CONFIG_CLEARFOG_CON2_SATA 
> already
> depends on !CONFIG_TARGET_CLEARFOG_BASE at the Kconfig level above.

It is redundant between the config and code sides - I viewed the check 
in code and the final check and the config entry a convenience to 
indicate to a configuring user that an option isn't available. If 
there's a prevailing standard in U-Boot to treat the configuration as 
pristine or otherwise not want the redundancy, I wouldn't have an issue 
removing the double-check in code.

> Looks good to me otherwise.
> 
> Have you had a chance to test mSATA?

Yes, I added a brief overview to the cover letter - I tested on a 
ClearFog Base and verified that the CON3 setting does in fact enable 
SATA, detect the drive, and both U-Boot and Linux have access to the 
block device. Strictly speaking I only tested CON3 and not CON2, but 
both run identical parallel paths.

Joel

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags
  2020-01-27 20:01 ` [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
  2020-01-28  6:06   ` Baruch Siach
@ 2020-03-23  9:18   ` Stefan Roese
  1 sibling, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:18 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> The mPCIe slots on ClearFog Pro and ClearFog Base may be alternately
> configured for SATA usage.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> 
> ---
> 
> v2 changes:
>    - fixed help indentation
> v3 changes:
>    - none
> v4 changes:
>    - adjust static SerDes configuration at runtime instead of #ifdef
>    - add setting of swap_rx for SATA (as yet untested on hardware)
> v5 changes:
>    - make independent of runtime detection
> 
> ---
>   board/solidrun/clearfog/Kconfig    | 17 +++++++++++++++++
>   board/solidrun/clearfog/clearfog.c | 15 +++++++++++++++
>   2 files changed, 32 insertions(+)
> 
> diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
> index c910e17093..44224d903d 100644
> --- a/board/solidrun/clearfog/Kconfig
> +++ b/board/solidrun/clearfog/Kconfig
> @@ -15,6 +15,23 @@ config TARGET_CLEARFOG_BASE
>   	  detection via additional EEPROM hardware. This option enables selecting
>   	  the Base variant for older hardware revisions.
>   
> +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.
> +
>   config CLEARFOG_SFP_25GB
>   	bool "Enable 2.5 Gbps mode for SFP"
>   	help
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 064ce4e520..f650e2b40e 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -67,6 +67,21 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>   	if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>   		board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>   
> +	if (IS_ENABLED(CONFIG_CLEARFOG_CON2_SATA) &&
> +	    !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE)) {
> +		board_serdes_map[4].serdes_type = SATA2;
> +		board_serdes_map[4].serdes_speed = SERDES_SPEED_3_GBPS;
> +		board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
> +		board_serdes_map[4].swap_rx = 1;
> +	}

Please remove !IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE) as Baruch already
mentioned.

Other that that:

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (5 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:19   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets Joel Johnson
                   ` (5 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

Unify the location of DT selection into board_late_init instead of
split between detection and static configuration paths.

---

v2 changes
  - newly added in V2 series based on run-time rebasing
v3 changes
  - none
v4 changes
  - separate change to explicit pro DT into separate commit
v5 changes
  - none

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---
 board/solidrun/clearfog/clearfog.c | 2 ++
 include/configs/clearfog.h         | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index f650e2b40e..4170fd4775 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -237,6 +237,8 @@ int board_late_init(void)
 		env_set("fdtfile", "armada-385-clearfog-gtr-l8.dtb");
 	else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
 		env_set("fdtfile", "armada-388-clearfog-base.dtb");
+	else
+		env_set("fdtfile", "armada-388-clearfog.dtb");
 
 	return 0;
 }
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index 633187d86f..6ca0474461 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -134,7 +134,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	RELOCATION_LIMITS_ENV_SETTINGS \
 	LOAD_ADDRESS_ENV_SETTINGS \
-	"fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
 	"console=ttyS0,115200\0" \
 	BOOTENV
 
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths
  2020-01-27 20:01 ` [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths Joel Johnson
@ 2020-03-23  9:19   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:19 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> Unify the location of DT selection into board_late_init instead of
> split between detection and static configuration paths.
> 
> ---
> 
> v2 changes
>    - newly added in V2 series based on run-time rebasing
> v3 changes
>    - none
> v4 changes
>    - separate change to explicit pro DT into separate commit
> v5 changes
>    - none
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (6 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:21   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 09/12] arm: mvebu: enable working default boot support Joel Johnson
                   ` (4 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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

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

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none
v5 changes:
  - none

There was some reasonable concern raised about duplicating config
entries within a board specific config file rather than making
board specific configurations within defconfig. This seems to offer
a more board localized mechanism to provide platform defaults for
core values. As mentioned in the review, this usage seems to match
the Kconfig documented intended usage. As noted at
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."

Given that there is some dependency variability with these values I
prefer keeping them as Kconfig values, but defer to maintainers.
Notably, for the ENV values in this and a later commit, I'm using a
pattern already in used several other board configs.

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

diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig
index 44224d903d..ea9c419472 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -39,4 +39,16 @@ 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 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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets
  2020-01-27 20:01 ` [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets Joel Johnson
@ 2020-03-23  9:21   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:21 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, 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>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 09/12] arm: mvebu: enable working default boot support
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (7 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:22   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
                   ` (3 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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

v2 changes:
  - change "select" for ENV_IS_IN_X to "imply" to allow disabling the
    default env location and configuring a different one if desired
  - remove SPL_DM_GPIO from defconfig, only include if needed for
    MMC booting
v3 changes:
  - none
v4 changes:
  - none
v5 changes:
  - none

---
 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 161dee937f..32191e7157 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -235,9 +235,19 @@ choice
 
 config MVEBU_SPL_BOOT_DEVICE_SPI
 	bool "SPI NOR flash"
+	imply 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"
+	imply 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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 09/12] arm: mvebu: enable working default boot support
  2020-01-27 20:01 ` [PATCH v5 09/12] arm: mvebu: enable working default boot support Joel Johnson
@ 2020-03-23  9:22   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:22 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, 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>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (8 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 09/12] arm: mvebu: enable working default boot support Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:23   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC Joel Johnson
                   ` (2 subsequent siblings)
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

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

---

v2 changes:
  - none
v3 changes:
  - none
v4 changes:
  - none
v5 changes:
  - none

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 ea9c419472..e8c3f53d84 100644
--- a/board/solidrun/clearfog/Kconfig
+++ b/board/solidrun/clearfog/Kconfig
@@ -39,6 +39,14 @@ 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 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 c938448c30..6db8b8acf6 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -9,8 +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_ENV_SIZE=0x10000
-CONFIG_ENV_OFFSET=0xF0000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig
  2020-01-27 20:01 ` [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
@ 2020-03-23  9:23   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:23 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> Migrate the values for ENV_SIZE and ENV_OFFSET into board specific
> Kconfig defaults so they're more accessible for configuration.
> 
> ---
> 
> v2 changes:
>    - none
> v3 changes:
>    - none
> v4 changes:
>    - none
> v5 changes:
>    - none
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (9 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-03-23  9:23   ` Stefan Roese
  2020-01-27 20:01 ` [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
  2020-03-22 18:46 ` [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

Move MMC booting assuptions from defconfig to Kconfig which
includes as needed based on dependent options.

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

v2 changes:
  - rebased on master to use Baruch's dynamic MMC/SD offset logic
  - update description, will revisit removal of
    CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC in separate future path if a
    more viable option is identified
v3 changes:
  - none
v4 changes:
  - none
v5 changes:
  - none

---
 arch/arm/mach-mvebu/Kconfig | 1 +
 configs/clearfog_defconfig  | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 32191e7157..4b381a2936 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -249,6 +249,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/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 6db8b8acf6..601b1997ed 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
 CONFIG_DM_GPIO=y
-CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL=y
@@ -42,7 +41,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

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC
  2020-01-27 20:01 ` [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC Joel Johnson
@ 2020-03-23  9:23   ` Stefan Roese
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:23 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> Move MMC booting assuptions from defconfig to Kconfig which
> includes as needed based on dependent options.
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (10 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC Joel Johnson
@ 2020-01-27 20:01 ` Joel Johnson
  2020-01-28  6:17   ` Baruch Siach
  2020-03-23  9:26   ` Stefan Roese
  2020-03-22 18:46 ` [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
  12 siblings, 2 replies; 35+ messages in thread
From: Joel Johnson @ 2020-01-27 20:01 UTC (permalink / raw)
  To: u-boot

Switch to explicitly using the Pro variant DT, which has been
available since Linux 4.11.

---

v4 changes:
  - new
v5 changes:
  - none

I separated out this change to the end of the series since it drew
questioning on prior review. I'd still advocate for making the change,
since especially with the additions of static variants and runtime
detection, it becomes easier from within a booted kernel to identify the
type and version of U-Boot image installed. Without making this change,
it becomes less direct to determine an actual Pro vs. Base, vs old
U-Boot image maybe supporting some hybrid variant configuration.

Even in the Linux kernel adding of the Pro DTS, it is indicated that it
was meant for backwards compatibility.

Except for cases where checking is done directly against the product
name from userspace, I don't see downsides even from a compatibility
perspective for not making this change. In cases where checking *is*
done from userspace, the broadening of the Clearfog product line would
seem to mean that userspace checking should be flagged as needing to be
udpated as well (or glob/regex matched as needed).

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
---
 board/solidrun/clearfog/clearfog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
index 4170fd4775..c31cfcb242 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -238,7 +238,7 @@ int board_late_init(void)
 	else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
 		env_set("fdtfile", "armada-388-clearfog-base.dtb");
 	else
-		env_set("fdtfile", "armada-388-clearfog.dtb");
+		env_set("fdtfile", "armada-388-clearfog-pro.dtb");
 
 	return 0;
 }
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default
  2020-01-27 20:01 ` [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
@ 2020-01-28  6:17   ` Baruch Siach
  2020-01-28  6:49     ` Joel Johnson
  2020-03-23  9:26   ` Stefan Roese
  1 sibling, 1 reply; 35+ messages in thread
From: Baruch Siach @ 2020-01-28  6:17 UTC (permalink / raw)
  To: u-boot

Hi Joel,

On Mon, Jan 27, 2020 at 01:01:56PM -0700, Joel Johnson wrote:
> Switch to explicitly using the Pro variant DT, which has been
> available since Linux 4.11.
> 
> ---
> 
> v4 changes:
>   - new
> v5 changes:
>   - none
> 
> I separated out this change to the end of the series since it drew
> questioning on prior review. I'd still advocate for making the change,
> since especially with the additions of static variants and runtime
> detection, it becomes easier from within a booted kernel to identify the
> type and version of U-Boot image installed. Without making this change,
> it becomes less direct to determine an actual Pro vs. Base, vs old
> U-Boot image maybe supporting some hybrid variant configuration.
> 
> Even in the Linux kernel adding of the Pro DTS, it is indicated that it
> was meant for backwards compatibility.
> 
> Except for cases where checking is done directly against the product
> name from userspace, I don't see downsides even from a compatibility
> perspective for not making this change. In cases where checking *is*
> done from userspace, the broadening of the Clearfog product line would
> seem to mean that userspace checking should be flagged as needing to be
> udpated as well (or glob/regex matched as needed).

One downside I see is that boot of kernels older than 4.11 will fail. But 
maybe since we already assume a newer kernel for armada-388-clearfog-base.dtb 
we can do that for -pro as well.

By the way, does env_set() override the stored environment?

baruch

> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
> ---
>  board/solidrun/clearfog/clearfog.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/solidrun/clearfog/clearfog.c b/board/solidrun/clearfog/clearfog.c
> index 4170fd4775..c31cfcb242 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -238,7 +238,7 @@ int board_late_init(void)
>  	else if (IS_ENABLED(CONFIG_TARGET_CLEARFOG_BASE))
>  		env_set("fdtfile", "armada-388-clearfog-base.dtb");
>  	else
> -		env_set("fdtfile", "armada-388-clearfog.dtb");
> +		env_set("fdtfile", "armada-388-clearfog-pro.dtb");
>  
>  	return 0;
>  }

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default
  2020-01-28  6:17   ` Baruch Siach
@ 2020-01-28  6:49     ` Joel Johnson
  0 siblings, 0 replies; 35+ messages in thread
From: Joel Johnson @ 2020-01-28  6:49 UTC (permalink / raw)
  To: u-boot

On 2020-01-27 23:17, Baruch Siach wrote:
> Hi Joel,
> 
> On Mon, Jan 27, 2020 at 01:01:56PM -0700, Joel Johnson wrote:
>> Switch to explicitly using the Pro variant DT, which has been
>> available since Linux 4.11.
>> 
>> ---
>> 
>> v4 changes:
>>   - new
>> v5 changes:
>>   - none
>> 
>> I separated out this change to the end of the series since it drew
>> questioning on prior review. I'd still advocate for making the change,
>> since especially with the additions of static variants and runtime
>> detection, it becomes easier from within a booted kernel to identify 
>> the
>> type and version of U-Boot image installed. Without making this 
>> change,
>> it becomes less direct to determine an actual Pro vs. Base, vs old
>> U-Boot image maybe supporting some hybrid variant configuration.
>> 
>> Even in the Linux kernel adding of the Pro DTS, it is indicated that 
>> it
>> was meant for backwards compatibility.
>> 
>> Except for cases where checking is done directly against the product
>> name from userspace, I don't see downsides even from a compatibility
>> perspective for not making this change. In cases where checking *is*
>> done from userspace, the broadening of the Clearfog product line would
>> seem to mean that userspace checking should be flagged as needing to 
>> be
>> udpated as well (or glob/regex matched as needed).
> 
> One downside I see is that boot of kernels older than 4.11 will fail. 
> But
> maybe since we already assume a newer kernel for 
> armada-388-clearfog-base.dtb
> we can do that for -pro as well.

Older kernels is one case, and to be fair there may also be the case of 
custom images with a newer kernel that for whatever reason (old file 
glob patterns) don't ship the -pro.dtb file. My testing focused 
primarily on OpenWRT and Debian, and while certainly not pervasive, I've 
also tested with current Armbian and Arch Linux ARM builds.

> By the way, does env_set() override the stored environment?

I'm not entirely sure of the behavior with duplicate entries, however 
patch 7 in the series removes the fdtfile entry from being added via 
CONFIG_EXTRA_ENV_SETTINGS, so it is now only set in one consistent 
location within board_late_init().

Joel

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default
  2020-01-27 20:01 ` [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
  2020-01-28  6:17   ` Baruch Siach
@ 2020-03-23  9:26   ` Stefan Roese
  1 sibling, 0 replies; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:26 UTC (permalink / raw)
  To: u-boot

On 27.01.20 21:01, Joel Johnson wrote:
> Switch to explicitly using the Pro variant DT, which has been
> available since Linux 4.11.
> 
> ---
> 
> v4 changes:
>    - new
> v5 changes:
>    - none
> 
> I separated out this change to the end of the series since it drew
> questioning on prior review. I'd still advocate for making the change,
> since especially with the additions of static variants and runtime
> detection, it becomes easier from within a booted kernel to identify the
> type and version of U-Boot image installed. Without making this change,
> it becomes less direct to determine an actual Pro vs. Base, vs old
> U-Boot image maybe supporting some hybrid variant configuration.
> 
> Even in the Linux kernel adding of the Pro DTS, it is indicated that it
> was meant for backwards compatibility.
> 
> Except for cases where checking is done directly against the product
> name from userspace, I don't see downsides even from a compatibility
> perspective for not making this change. In cases where checking *is*
> done from userspace, the broadening of the Clearfog product line would
> seem to mean that userspace checking should be flagged as needing to be
> udpated as well (or glob/regex matched as needed).
> 
> Signed-off-by: Joel Johnson <mrjoel@lixil.net>

Again, please make sure to put the S-o-b line above the first "---"
line.

Other that that:

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

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 00/12] ClearFog Base static variant support
  2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
                   ` (11 preceding siblings ...)
  2020-01-27 20:01 ` [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
@ 2020-03-22 18:46 ` Joel Johnson
  2020-03-23  9:03   ` Stefan Roese
  12 siblings, 1 reply; 35+ messages in thread
From: Joel Johnson @ 2020-03-22 18:46 UTC (permalink / raw)
  To: u-boot

I just wanted to ping on this review 
(http://patchwork.ozlabs.org/project/uboot/list/?series=155533) to see 
if it had reached an agreeable state or if there were still lingering 
issues. I've been using it without issue against RC releases.

If the plan is to not include it in v2020.04 that's completely 
reasonable, but I would request review and feedback on blocking issues, 
otherwise does it have general agreement for merging in the next merge 
window?

Thanks,
Joel

On 2020-01-27 13:01, Joel Johnson wrote:
> This patch series adds support for ClearFog Base static configuration,
> as well as updating and fixing the ClearFog support for MMC and SPI
> booting.
> 
> v2 changes:
>   - updated against, and dependent on,
> https://patchwork.ozlabs.org/cover/1200324
> v3 changes:
>   - rebased against ClearFog runtime TLV EEPROM changes merged into 
> mvebu/master
> v4
>   - adjust static SerDes configuration at runtime instead of #ifdef
> v5
>   - distinguish build-only config changes (SFP and PCIe/SATA) from
>     runtime detectable config changes
>   - retested SATA mode in PCIe slot with swap rx changes, confirmed
>     working as presently patched. Only tested with ClearFog Base which
>     only provides single channel, but Pro mechanism is parallel.
> 
> 
> Joel Johnson (12):
>   arm: mvebu: fix SerDes table alignment
>   arm: mvebu: solidrun: remove hardcoded DTS MAC address
>   arm: mvebu: clearfog: use Pro name by default
>   arm: mvebu: clearfog: initial ClearFog Base variant
>   arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
>   arm: mvebu: clearfog: Add SATA mode flags
>   arm: mvebu: clearfog: Unify DT selection paths
>   arm: mvebu: clearfog: add SPI offsets
>   arm: mvebu: enable working default boot support
>   arm: mvebu: clearfog: move ENV params to Kconfig
>   arm: mvebu: clearfog: don't always use SPL MMC
>   arm: mvebu: clearfog: Use Pro DT by default
> 
>  .../arm/dts/armada-38x-solidrun-microsom.dtsi |  1 -
>  arch/arm/mach-mvebu/Kconfig                   | 13 ++++
>  .../serdes/a38x/high_speed_env_spec.c         |  6 +-
>  board/solidrun/clearfog/Kconfig               | 62 +++++++++++++++++++
>  board/solidrun/clearfog/clearfog.c            | 53 +++++++++++++---
>  configs/clearfog_defconfig                    |  4 --
>  include/configs/clearfog.h                    |  1 -
>  7 files changed, 124 insertions(+), 16 deletions(-)
>  create mode 100644 board/solidrun/clearfog/Kconfig

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 00/12] ClearFog Base static variant support
  2020-03-22 18:46 ` [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
@ 2020-03-23  9:03   ` Stefan Roese
  2020-03-23 16:59     ` Baruch Siach
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Roese @ 2020-03-23  9:03 UTC (permalink / raw)
  To: u-boot

Hi Joel,

On 22.03.20 19:46, Joel Johnson wrote:
> I just wanted to ping on this review 
> (http://patchwork.ozlabs.org/project/uboot/list/?series=155533) to see 
> if it had reached an agreeable state or if there were still lingering 
> issues. I've been using it without issue against RC releases.
> 
> If the plan is to not include it in v2020.04 that's completely 
> reasonable, but I would request review and feedback on blocking issues, 
> otherwise does it have general agreement for merging in the next merge 
> window?

I won't pull this into v2020.04 as you might understand. I was hoping to
get some reviews and testing from people with access to those boards.

Baruch, could you please check again, if you agree with this approach?
Or do you have some change request for this build-time vs run-time
detection?

Thanks,
Stefan

> Thanks,
> Joel
> 
> On 2020-01-27 13:01, Joel Johnson wrote:
>> This patch series adds support for ClearFog Base static configuration,
>> as well as updating and fixing the ClearFog support for MMC and SPI
>> booting.
>>
>> v2 changes:
>> ? - updated against, and dependent on,
>> https://patchwork.ozlabs.org/cover/1200324
>> v3 changes:
>> ? - rebased against ClearFog runtime TLV EEPROM changes merged into 
>> mvebu/master
>> v4
>> ? - adjust static SerDes configuration at runtime instead of #ifdef
>> v5
>> ? - distinguish build-only config changes (SFP and PCIe/SATA) from
>> ??? runtime detectable config changes
>> ? - retested SATA mode in PCIe slot with swap rx changes, confirmed
>> ??? working as presently patched. Only tested with ClearFog Base which
>> ??? only provides single channel, but Pro mechanism is parallel.
>>
>>
>> Joel Johnson (12):
>> ? arm: mvebu: fix SerDes table alignment
>> ? arm: mvebu: solidrun: remove hardcoded DTS MAC address
>> ? arm: mvebu: clearfog: use Pro name by default
>> ? arm: mvebu: clearfog: initial ClearFog Base variant
>> ? arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
>> ? arm: mvebu: clearfog: Add SATA mode flags
>> ? arm: mvebu: clearfog: Unify DT selection paths
>> ? arm: mvebu: clearfog: add SPI offsets
>> ? arm: mvebu: enable working default boot support
>> ? arm: mvebu: clearfog: move ENV params to Kconfig
>> ? arm: mvebu: clearfog: don't always use SPL MMC
>> ? arm: mvebu: clearfog: Use Pro DT by default
>>
>> ?.../arm/dts/armada-38x-solidrun-microsom.dtsi |? 1 -
>> ?arch/arm/mach-mvebu/Kconfig?????????????????? | 13 ++++
>> ?.../serdes/a38x/high_speed_env_spec.c???????? |? 6 +-
>> ?board/solidrun/clearfog/Kconfig?????????????? | 62 +++++++++++++++++++
>> ?board/solidrun/clearfog/clearfog.c??????????? | 53 +++++++++++++---
>> ?configs/clearfog_defconfig??????????????????? |? 4 --
>> ?include/configs/clearfog.h??????????????????? |? 1 -
>> ?7 files changed, 124 insertions(+), 16 deletions(-)
>> ?create mode 100644 board/solidrun/clearfog/Kconfig


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [PATCH v5 00/12] ClearFog Base static variant support
  2020-03-23  9:03   ` Stefan Roese
@ 2020-03-23 16:59     ` Baruch Siach
  0 siblings, 0 replies; 35+ messages in thread
From: Baruch Siach @ 2020-03-23 16:59 UTC (permalink / raw)
  To: u-boot

Hi Stefan,

On Mon, Mar 23 2020, Stefan Roese wrote:
> On 22.03.20 19:46, Joel Johnson wrote:
>> I just wanted to ping on this review
>> (http://patchwork.ozlabs.org/project/uboot/list/?series=155533) to see if it
>> had reached an agreeable state or if there were still lingering issues. I've
>> been using it without issue against RC releases.
>>
>> If the plan is to not include it in v2020.04 that's completely reasonable,
>> but I would request review and feedback on blocking issues, otherwise does
>> it have general agreement for merging in the next merge window?
>
> I won't pull this into v2020.04 as you might understand. I was hoping to
> get some reviews and testing from people with access to those boards.
>
> Baruch, could you please check again, if you agree with this approach?
> Or do you have some change request for this build-time vs run-time
> detection?

This series is the end result of discussions between Joel and me on the
list with a few iterations. I am fine with this result, and I think it
is good to go. I can't test these patches at the moment. Hope to do that
some time later.

Thanks,
baruch

>> On 2020-01-27 13:01, Joel Johnson wrote:
>>> This patch series adds support for ClearFog Base static configuration,
>>> as well as updating and fixing the ClearFog support for MMC and SPI
>>> booting.
>>>
>>> v2 changes:
>>>   - updated against, and dependent on,
>>> https://patchwork.ozlabs.org/cover/1200324
>>> v3 changes:
>>>   - rebased against ClearFog runtime TLV EEPROM changes merged into
>>> mvebu/master
>>> v4
>>>   - adjust static SerDes configuration at runtime instead of #ifdef
>>> v5
>>>   - distinguish build-only config changes (SFP and PCIe/SATA) from
>>>     runtime detectable config changes
>>>   - retested SATA mode in PCIe slot with swap rx changes, confirmed
>>>     working as presently patched. Only tested with ClearFog Base which
>>>     only provides single channel, but Pro mechanism is parallel.
>>>
>>>
>>> Joel Johnson (12):
>>>   arm: mvebu: fix SerDes table alignment
>>>   arm: mvebu: solidrun: remove hardcoded DTS MAC address
>>>   arm: mvebu: clearfog: use Pro name by default
>>>   arm: mvebu: clearfog: initial ClearFog Base variant
>>>   arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
>>>   arm: mvebu: clearfog: Add SATA mode flags
>>>   arm: mvebu: clearfog: Unify DT selection paths
>>>   arm: mvebu: clearfog: add SPI offsets
>>>   arm: mvebu: enable working default boot support
>>>   arm: mvebu: clearfog: move ENV params to Kconfig
>>>   arm: mvebu: clearfog: don't always use SPL MMC
>>>   arm: mvebu: clearfog: Use Pro DT by default
>>>
>>>  .../arm/dts/armada-38x-solidrun-microsom.dtsi |  1 -
>>>  arch/arm/mach-mvebu/Kconfig                   | 13 ++++
>>>  .../serdes/a38x/high_speed_env_spec.c         |  6 +-
>>>  board/solidrun/clearfog/Kconfig               | 62 +++++++++++++++++++
>>>  board/solidrun/clearfog/clearfog.c            | 53 +++++++++++++---
>>>  configs/clearfog_defconfig                    |  4 --
>>>  include/configs/clearfog.h                    |  1 -
>>>  7 files changed, 124 insertions(+), 16 deletions(-)
>>>  create mode 100644 board/solidrun/clearfog/Kconfig
>
>
> Viele Gr??e,
> Stefan


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2020-03-23 16:59 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-27 20:01 [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
2020-01-27 20:01 ` [PATCH v5 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
2020-03-23  9:04   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
2020-03-23  9:05   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 03/12] arm: mvebu: clearfog: use Pro name by default Joel Johnson
2020-03-23  9:07   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 04/12] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
2020-03-23  9:11   ` Stefan Roese
2020-03-23 15:27     ` Joel Johnson
2020-01-27 20:01 ` [PATCH v5 05/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
2020-03-23  9:14   ` Stefan Roese
2020-03-23  9:33     ` Baruch Siach
2020-03-23  9:46       ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 06/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
2020-01-28  6:06   ` Baruch Siach
2020-01-28  6:34     ` Joel Johnson
2020-03-23  9:18   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 07/12] arm: mvebu: clearfog: Unify DT selection paths Joel Johnson
2020-03-23  9:19   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 08/12] arm: mvebu: clearfog: add SPI offsets Joel Johnson
2020-03-23  9:21   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 09/12] arm: mvebu: enable working default boot support Joel Johnson
2020-03-23  9:22   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 10/12] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
2020-03-23  9:23   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 11/12] arm: mvebu: clearfog: don't always use SPL MMC Joel Johnson
2020-03-23  9:23   ` Stefan Roese
2020-01-27 20:01 ` [PATCH v5 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
2020-01-28  6:17   ` Baruch Siach
2020-01-28  6:49     ` Joel Johnson
2020-03-23  9:26   ` Stefan Roese
2020-03-22 18:46 ` [PATCH v5 00/12] ClearFog Base static variant support Joel Johnson
2020-03-23  9:03   ` Stefan Roese
2020-03-23 16:59     ` Baruch Siach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox