[PATCH 01/10] arm: mvebu: fix SerDes table alignment
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]);
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 @@
ð0 { /* ethernet@70000 */ - mac-address = [00 50 43 02 02 01]; pinctrl-0 = <&ge0_rgmii_pins>; pinctrl-names = "default"; phy = <&phy_dedicated>;
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 @@
ð0 { /* ethernet@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
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; }
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 ClearFogPro 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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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
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
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
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)
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 theSGMII connection (requires a supporting SFP). By default, transfer speedof 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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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 speedfor the
SGMII connection (requires a supporting SFP). By default, transferspeed
of 1.25 Gbps is used, suitable for a more common 1 Gbps SFPmodule.
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
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 */
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 notenabled 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/ab15b2d5b6ee50c106628dc0aa5943747a...
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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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 notenabled 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
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/ab15b2d5b6ee50c106628dc0aa5943747a...
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
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 notenabled 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
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/ab15b2d5b6ee50c106628dc0aa5943747a...
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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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
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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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
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
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
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
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
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
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
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
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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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
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
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
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
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=121894Indeed, 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
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
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=121894Indeed, 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
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
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
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
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_S(" | ");
DEBUG_INIT_S(" | ");
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
participants (3)
-
Baruch Siach -
Joel Johnson -
Stefan Roese