Skip to contentSkip to conversation

drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

PATCH New Phil Sutter 3 participants 24 messages Dec 25, 2015 – Jan 13, 2016 1 message not in the archive

Subsystems (4)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

PATCH v3 1/10 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

The debug printing references bar_res, which exists only if CONFIG_PCI_ENUM_ONLY is not defined. Therefore move it into the ifdef'd area.

---
 drivers/pci/pci_auto_old.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/pci_auto_old.c +1 -1
index 932eab8..8f17779 100644
@@ -98,11 +98,11 @@ void pciauto_setup_device(struct pci_controller *hose,
 				bar_res = prefetch;
 			else
 				bar_res = mem;
-#endif
 
 			debug("PCI Autoconfig: BAR %d, %s, size=0x%llx, ",
 			      bar_nr, bar_res == prefetch ? "Prf" : "Mem",
 			      (unsigned long long)bar_size);
+#endif
 		}
 
 #ifndef CONFIG_PCI_ENUM_ONLY
Signature · 1 line
2.5.3
#2 lore raw

PATCH v3 1/10 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

Quoted 5 lines · Phil Sutter

The debug printing references bar_res, which exists only if CONFIG_PCI_ENUM_ONLY is not defined. Therefore move it into the ifdef'd area.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/f1e86253/attachment.sig>
#3 lore raw

PATCH v3 2/10 README: Review the u-boot porting guide list

In reply to a message not in the archive

* There is no boards.cfg anymore, so drop (1).
* Creating flash.c and u-boot.lds seems not mandatory as well.
* Adjusting the enumerators for the above implicitly fixed for double items numbered (3).

---
 README | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)
README +4 -7
index 4fee706..dcc9478 100644
@@ -5153,14 +5153,11 @@ If the system board that you have is not listed, then you will need
 to port U-Boot to your hardware platform. To do this, follow these
 steps:
 
-1.  Add a new configuration option for your board to the toplevel
-    "boards.cfg" file, using the existing entries as examples.
-    Follow the instructions there to keep the boards in order.
-2.  Create a new directory to hold your board specific code. Add any
+1.  Create a new directory to hold your board specific code. Add any
     files you need. In your board directory, you will need at least
-    the "Makefile", a "<board>.c", "flash.c" and "u-boot.lds".
-3.  Create a new configuration file "include/configs/<board>.h" for
-    your board
+    the "Makefile" and a "<board>.c".
+2.  Create a new configuration file "include/configs/<board>.h" for
+    your board.
 3.  If you're porting U-Boot to a new CPU, then also create a new
     directory to hold your CPU specific code. Add any files you need.
 4.  Run "make <board>_defconfig" with your new name.
Signature · 1 line
2.5.3
#4 lore raw

PATCH v3 2/10 README: Review the u-boot porting guide list

Quoted 6 lines · Phil Sutter

* There is no boards.cfg anymore, so drop (1).
* Creating flash.c and u-boot.lds seems not mandatory as well.
* Adjusting the enumerators for the above implicitly fixed for double items numbered (3).

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/c821b78d/attachment.sig>
#5 lore raw

PATCH v3 3/10 axp: Fix debugging support in DDR3 write leveling

In reply to a message not in the archive

If MV_DEBUG_WL is defined, DEBUG_WL_S and DEBUG_WL_D macros are missing. In addition to that, get rid of debug output printing non-existent counter variable.

---
 drivers/ddr/marvell/axp/ddr3_write_leveling.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ddr/marvell/axp/ddr3_write_leveling.c +2 -2
index df3a3df..da384f3 100644
@@ -22,6 +22,8 @@
 	DEBUG_WL_FULL_S(s); DEBUG_WL_FULL_D(d, l); DEBUG_WL_FULL_S("\n")
 
 #ifdef MV_DEBUG_WL
+#define DEBUG_WL_S(s)			puts(s)
+#define DEBUG_WL_D(d, l)		printf("%x", d)
 #define DEBUG_RL_S(s) \
 	debug_cond(ddr3_get_log_level() >= MV_LOG_LEVEL_2, "%s", s)
 #define DEBUG_RL_D(d, l) \
@@ -1229,8 +1231,6 @@ static int ddr3_write_leveling_single_cs(u32 cs, u32 freq, int ratio_2to1,
 			DEBUG_WL_FULL_D((u32) phase, 1);
 			DEBUG_WL_FULL_S(", Delay = ");
 			DEBUG_WL_FULL_D((u32) delay, 1);
-			DEBUG_WL_FULL_S(", Counter = ");
-			DEBUG_WL_FULL_D((u32) i, 1);
 			DEBUG_WL_FULL_S("\n");
 
 			/* Drive DQS high for one cycle - All data PUPs */
Signature · 1 line
2.5.3
#6 lore raw

PATCH v3 3/10 axp: Fix debugging support in DDR3 write leveling

Quoted 5 lines · Phil Sutter

If MV_DEBUG_WL is defined, DEBUG_WL_S and DEBUG_WL_D macros are missing. In addition to that, get rid of debug output printing non-existent counter variable.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/ef04e63d/attachment.sig>
#7 lore raw

PATCH v3 4/10 drivers/pci/pci_mvebu: Fix for boards with X4 lanes

In reply to a message not in the archive

Armada XP has support for X4 lanes, boards specify this in their serdes_cfg. During PEX init in high_speed_env_lib.c, the configuration is stored in GEN_PURP_RES_2_REG.

When enumerating PEX, subsequent interfaces of an X4 lane must be skipped. Otherwise the enumeration hangs up the board.

The way this is implemented here is not exactly beautiful, but it mimics how Marvell's BSP does it. Alternatively we could get the information using board_serdes_cfg_get(), but that won't lead to clean code, either.

---
 arch/arm/mach-mvebu/include/mach/soc.h |  2 ++
 drivers/pci/pci_mvebu.c                | 14 ++++++++++++++
 2 files changed, 16 insertions(+)
arch/arm/mach-mvebu/include/mach/soc.h +2 -0
index 5d4ad30..9eaf0db 100644
@@ -96,4 +96,6 @@
 #define MVCPU_WIN_ENABLE	CPU_WIN_ENABLE
 #define MVCPU_WIN_DISABLE	CPU_WIN_DISABLE
 
+#define COMPHY_REFCLK_ALIGNMENT	(MVEBU_REGISTER(0x182f8))
+
 #endif /* _MVEBU_SOC_H */
drivers/pci/pci_mvebu.c +14 -0
index fd2744d..4eedfe1 100644
@@ -155,6 +155,14 @@ static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx,
 }
 #endif
 
+static int mvebu_pex_unit_is_x4(int pex_idx)
+{
+	int pex_unit = pex_idx < 9 ? pex_idx >> 2 : 3;
+	u32 mask = (0x0f << (pex_unit * 8));
+
+	return (readl(COMPHY_REFCLK_ALIGNMENT) & mask) == mask;
+}
+
 static inline bool mvebu_pcie_link_up(struct mvebu_pcie *pcie)
 {
 	u32 val;
@@ -419,5 +427,11 @@ void pci_init_board(void)
 		writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
 
 		bus = hose->last_busno + 1;
+
+		/* need to skip more for X4 links, otherwise scan will hang */
+		if (mvebu_soc_family() == MVEBU_SOC_AXP) {
+			if (mvebu_pex_unit_is_x4(i))
+				i += 3;
+		}
 	}
 }
Signature · 1 line
2.5.3
#8 lore raw

PATCH v3 4/10 drivers/pci/pci_mvebu: Fix for boards with X4 lanes

Quoted 4 lines · Phil Sutter

Armada XP has support for X4 lanes, boards specify this in their serdes_cfg. During PEX init in high_speed_env_lib.c, the configuration is stored in GEN_PURP_RES_2_REG.

Quoted 8 lines

When enumerating PEX, subsequent interfaces of an X4 lane must be skipped. Otherwise the enumeration hangs up the board.

The way this is implemented here is not exactly beautiful, but it mimics how Marvell's BSP does it. Alternatively we could get the information using board_serdes_cfg_get(), but that won't lead to clean code, either.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/3aaf25e4/attachment.sig>
#9 lore raw

PATCH v3 5/10 mvebu: axp: refactor board_sat_r_get() and caller

In reply to a message not in the archive

Instead of calling board_sat_r_get() only for those boards providing the satr11 value via I2C, call it for all boards and return static values for those not using I2C.

In addition to that, make this a weak function to allow for board code to override it.

---
 .../arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 46 +++++++---------------
 1 file changed, 15 insertions(+), 31 deletions(-)
arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +15 -31
index bfa7f13..633b899 100644
@@ -75,16 +75,24 @@ static u32 board_id_get(void)
 #endif
 }
 
-static u8 board_sat_r_get(u8 dev_num, u8 reg)
+__weak u8 board_sat_r_get(u8 dev_num, u8 reg)
 {
 	u8 data;
 	u8 *dev;
 	u32 board_id = board_id_get();
 	int ret;
 
-	i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
-
 	switch (board_id) {
+	case DB_78X60_AMC_ID:
+	case DB_78X60_PCAC_REV2_ID:
+	case RD_78460_CUSTOMER_ID:
+	case RD_78460_SERVER_ID:
+	case RD_78460_SERVER_REV2_ID:
+	case DB_78X60_PCAC_ID:
+		return (0x1 << 1) | 1;
+	case FPGA_88F78XX0_ID:
+	case RD_78460_NAS_ID:
+		return (0x0 << 1) | 1;
 	case DB_784MP_GP_ID:
 		dev = rd78460gp_twsi_dev;
 
@@ -94,15 +102,12 @@ static u8 board_sat_r_get(u8 dev_num, u8 reg)
 		dev = db88f78xx0rev2_twsi_dev;
 		break;
 
-	case DB_78X60_PCAC_ID:
-	case FPGA_88F78XX0_ID:
-	case DB_78X60_PCAC_REV2_ID:
-	case RD_78460_SERVER_REV2_ID:
 	default:
 		return 0;
 	}
 
 	/* Read MPP module ID */
+	i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
 	ret = i2c_read(dev[dev_num], 0, 1, (u8 *)&data, 1);
 	if (ret)
 		return MV_ERROR;
@@ -240,7 +245,6 @@ int serdes_phy_config(void)
 	u8 device_rev;
 	u32 rx_high_imp_mode;
 	u16 ctrl_mode;
-	u32 board_id = board_id_get();
 	u32 pex_if;
 	u32 pex_if_num;
 
@@ -251,29 +255,9 @@ int serdes_phy_config(void)
 	if (max_serdes_lines == 0)
 		return MV_OK;
 
-	switch (board_id) {
-	case DB_78X60_AMC_ID:
-	case DB_78X60_PCAC_REV2_ID:
-	case RD_78460_CUSTOMER_ID:
-	case RD_78460_SERVER_ID:
-	case RD_78460_SERVER_REV2_ID:
-	case DB_78X60_PCAC_ID:
-		satr11 = (0x1 << 1) | 1;
-		break;
-	case FPGA_88F78XX0_ID:
-	case RD_78460_NAS_ID:
-		satr11 = (0x0 << 1) | 1;
-		break;
-	case DB_88F78XX0_BP_REV2_ID:
-	case DB_784MP_GP_ID:
-	case DB_88F78XX0_BP_ID:
-		satr11 = board_sat_r_get(1, 1);
-		if ((u8) MV_ERROR == (u8) satr11)
-			return MV_ERROR;
-		break;
-	default:
-		satr11 = 0;
-	}
+	satr11 = board_sat_r_get(1, 1);
+	if ((u8) MV_ERROR == (u8) satr11)
+		return MV_ERROR;
 
 	board_modules_scan();
 	memset(addr, 0, sizeof(addr));
Signature · 1 line
2.5.3
#10 lore raw

PATCH v3 5/10 mvebu: axp: refactor board_sat_r_get() and caller

Quoted 8 lines · Phil Sutter

Instead of calling board_sat_r_get() only for those boards providing the satr11 value via I2C, call it for all boards and return static values for those not using I2C.

In addition to that, make this a weak function to allow for board code to override it.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/48940982/attachment.sig>
#11 lore raw

PATCH v3 6/10 mvebu: Introduce kconfig symbols for SoC variants

In reply to a message not in the archive

This patch adds intermediate kconfig symbols which select their SoC family. Boards then select them instead of the family symbol directly.

---
 arch/arm/mach-mvebu/Kconfig     | 24 ++++++++++++++++++++----
 include/configs/clearfog.h      |  1 -
 include/configs/db-88f6820-gp.h |  1 -
 3 files changed, 20 insertions(+), 6 deletions(-)
arch/arm/mach-mvebu/Kconfig +20 -4
index d96b2ae..a39f900 100644
@@ -6,25 +6,41 @@ config ARMADA_38X
 config ARMADA_XP
 	bool
 
+config MV78230
+	bool
+	select ARMADA_XP
+
+config MV78260
+	bool
+	select ARMADA_XP
+
+config MV78460
+	bool
+	select ARMADA_XP
+
+config DB_88F6820_GP
+	bool
+	select ARMADA_38X
+
 choice
 	prompt "Marvell MVEBU (Armada XP/38x) board select"
 	optional
 
 config TARGET_CLEARFOG
 	bool "Support ClearFog"
-	select ARMADA_38X
+	select DB_88F6820_GP
 
 config TARGET_DB_88F6820_GP
 	bool "Support DB-88F6820-GP"
-	select ARMADA_38X
+	select DB_88F6820_GP
 
 config TARGET_DB_MV784MP_GP
 	bool "Support db-mv784mp-gp"
-	select ARMADA_XP
+	select MV78460
 
 config TARGET_MAXBCM
 	bool "Support maxbcm"
-	select ARMADA_XP
+	select MV78460
 
 endchoice
 
include/configs/clearfog.h +0 -1
index 6c5356b..f0de827 100644
@@ -10,7 +10,6 @@
 /*
  * High Level Configuration Options (easy to change)
  */
-#define CONFIG_DB_88F6820_GP		/* Board target name for DDR training */
 
 #define CONFIG_DISPLAY_BOARDINFO_LATE
 
include/configs/db-88f6820-gp.h +0 -1
index 03a3d31..ef14132 100644
@@ -10,7 +10,6 @@
 /*
  * High Level Configuration Options (easy to change)
  */
-#define CONFIG_DB_88F6820_GP		/* Board target name for DDR training */
 
 #define CONFIG_DISPLAY_BOARDINFO_LATE
 
Signature · 1 line
2.5.3
#12 lore raw

PATCH v3 6/10 mvebu: Introduce kconfig symbols for SoC variants

Quoted 4 lines · Phil Sutter

This patch adds intermediate kconfig symbols which select their SoC family. Boards then select them instead of the family symbol directly.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/6c5cdba8/attachment.sig>
#13 lore raw

PATCH v3 7/10 mvebu: axp: Rename MV_DDR_32BIT to CONFIG_DDR_32BIT

In reply to a message not in the archive

This should make it clear that this symbol is meant to be defined by board headers.

---
 drivers/ddr/marvell/axp/ddr3_axp_config.h    |  2 +-
 drivers/ddr/marvell/axp/ddr3_axp_mc_static.h | 20 ++++++++++----------
 2 files changed, 11 insertions(+), 11 deletions(-)
drivers/ddr/marvell/axp/ddr3_axp_config.h +1 -1
index 25c34fb..8549fe8 100644
@@ -51,7 +51,7 @@
 #define DRAM_ECC				0
 #endif
 
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 #define BUS_WIDTH                               32
 #else
 #define BUS_WIDTH				64
drivers/ddr/marvell/axp/ddr3_axp_mc_static.h +10 -10
index 2c0e9075..71794ad 100644
@@ -8,9 +8,9 @@
 #define __AXP_MC_STATIC_H
 
 MV_DRAM_MC_INIT ddr3_A0_db_667[MV_MAX_DDR3_STATIC_SIZE] = {
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 	{0x00001400, 0x7301c924},	/*DDR SDRAM Configuration Register */
-#else /*MV_DDR_64BIT */
+#else /*CONFIG_DDR_64BIT */
 	{0x00001400, 0x7301CA28},	/*DDR SDRAM Configuration Register */
 #endif
 	{0x00001404, 0x3630b800},	/*Dunit Control Low Register */
@@ -66,9 +66,9 @@ MV_DRAM_MC_INIT ddr3_A0_db_667[MV_MAX_DDR3_STATIC_SIZE] = {
 };
 
 MV_DRAM_MC_INIT ddr3_A0_AMC_667[MV_MAX_DDR3_STATIC_SIZE] = {
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 	{0x00001400, 0x7301c924},	/*DDR SDRAM Configuration Register */
-#else /*MV_DDR_64BIT */
+#else /*CONFIG_DDR_64BIT */
 	{0x00001400, 0x7301CA28},	/*DDR SDRAM Configuration Register */
 #endif
 	{0x00001404, 0x3630b800},	/*Dunit Control Low Register */
@@ -124,9 +124,9 @@ MV_DRAM_MC_INIT ddr3_A0_AMC_667[MV_MAX_DDR3_STATIC_SIZE] = {
 };
 
 MV_DRAM_MC_INIT ddr3_A0_db_400[MV_MAX_DDR3_STATIC_SIZE] = {
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 	{0x00001400, 0x73004C30},	/*DDR SDRAM Configuration Register */
-#else /* MV_DDR_64BIT */
+#else /* CONFIG_DDR_64BIT */
 	{0x00001400, 0x7300CC30},	/*DDR SDRAM Configuration Register */
 #endif
 	{0x00001404, 0x3630B840},	/*Dunit Control Low Register */
@@ -176,9 +176,9 @@ MV_DRAM_MC_INIT ddr3_A0_db_400[MV_MAX_DDR3_STATIC_SIZE] = {
 };
 
 MV_DRAM_MC_INIT ddr3_Z1_db_600[MV_MAX_DDR3_STATIC_SIZE] = {
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 	{0x00001400, 0x73014A28},	/*DDR SDRAM Configuration Register */
-#else /*MV_DDR_64BIT */
+#else /*CONFIG_DDR_64BIT */
 	{0x00001400, 0x7301CA28},	/*DDR SDRAM Configuration Register */
 #endif
 	{0x00001404, 0x3630B040},	/*Dunit Control Low Register */
@@ -233,9 +233,9 @@ MV_DRAM_MC_INIT ddr3_Z1_db_600[MV_MAX_DDR3_STATIC_SIZE] = {
 };
 
 MV_DRAM_MC_INIT ddr3_Z1_db_300[MV_MAX_DDR3_STATIC_SIZE] = {
-#ifdef MV_DDR_32BIT
+#ifdef CONFIG_DDR_32BIT
 	{0x00001400, 0x73004C30},	/*DDR SDRAM Configuration Register */
-#else /*MV_DDR_64BIT */
+#else /*CONFIG_DDR_64BIT */
 	{0x00001400, 0x7300CC30},	/*DDR SDRAM Configuration Register */
 	/*{0x00001400, 0x7304CC30},  *//*DDR SDRAM Configuration Register */
 #endif
Signature · 1 line
2.5.3
#14 lore raw

PATCH v3 7/10 mvebu: axp: Rename MV_DDR_32BIT to CONFIG_DDR_32BIT

Quoted 4 lines · Phil Sutter

This should make it clear that this symbol is meant to be defined by board headers.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/7206156b/attachment.sig>
#15 lore raw

PATCH v3 8/10 mvebu: Add rudimental MV78230 support

In reply to a message not in the archive

This adds basic support for Marvell's MV78230 SoC which belongs to the Armada XP series.

---
 arch/arm/mach-mvebu/cpu.c                           | 16 +++++++++++-----
 arch/arm/mach-mvebu/include/mach/soc.h              |  1 +
 arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c |  6 +++++-
 3 files changed, 17 insertions(+), 6 deletions(-)
arch/arm/mach-mvebu/cpu.c +11 -5
index 6ea558c..5c62fd5 100644
@@ -49,13 +49,16 @@ int mvebu_soc_family(void)
 {
 	u16 devid = (readl(MVEBU_REG_PCIE_DEVID) >> 16) & 0xffff;
 
-	if ((devid == SOC_MV78260_ID) || (devid == SOC_MV78460_ID))
+	switch (devid) {
+	case SOC_MV78230_ID:
+	case SOC_MV78260_ID:
+	case SOC_MV78460_ID:
 		return MVEBU_SOC_AXP;
-
-	if (devid == SOC_88F6810_ID || devid == SOC_88F6820_ID ||
-	    devid == SOC_88F6828_ID)
+	case SOC_88F6810_ID:
+	case SOC_88F6820_ID:
+	case SOC_88F6828_ID:
 		return MVEBU_SOC_A38X;
-
+	}
 	return MVEBU_SOC_UNKNOWN;
 }
 
@@ -153,6 +156,9 @@ int print_cpuinfo(void)
 	puts("SoC:   ");
 
 	switch (devid) {
+	case SOC_MV78230_ID:
+		puts("MV78230-");
+		break;
 	case SOC_MV78260_ID:
 		puts("MV78260-");
 		break;
arch/arm/mach-mvebu/include/mach/soc.h +1 -0
index 9eaf0db..6b12a92 100644
@@ -11,6 +11,7 @@
 #ifndef _MVEBU_SOC_H
 #define _MVEBU_SOC_H
 
+#define SOC_MV78230_ID		0x7823
 #define SOC_MV78260_ID		0x7826
 #define SOC_MV78460_ID		0x7846
 #define SOC_88F6810_ID		0x6810
arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +5 -1
index 633b899..afc0cef 100644
@@ -199,7 +199,9 @@ u16 ctrl_model_get(void)
 	 * SoC version can't be autodetected. So we need to rely on a define
 	 * from the config system here.
 	 */
-#ifdef CONFIG_MV78260
+#if defined(CONFIG_MV78230)
+	return MV_78230_DEV_ID;
+#elif defined(CONFIG_MV78260)
 	return MV_78260_DEV_ID;
 #else
 	return MV_78460_DEV_ID;
@@ -217,6 +219,8 @@ u32 get_line_cfg(u32 line_num, MV_BIN_SERDES_CFG *info)
 static int serdes_max_lines_get(void)
 {
 	switch (ctrl_model_get()) {
+	case MV_78230_DEV_ID:
+		return 7;
 	case MV_78260_DEV_ID:
 		return 12;
 	case MV_78460_DEV_ID:
Signature · 1 line
2.5.3
#16 lore raw

PATCH v3 8/10 mvebu: Add rudimental MV78230 support

Quoted 4 lines · Phil Sutter

This adds basic support for Marvell's MV78230 SoC which belongs to the Armada XP series.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/ca9f7185/attachment.sig>
#17 lore raw

PATCH v3 9/10 mvebu: Support Synology DS414

In reply to a message not in the archive

This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.

Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow:

Device Tree
-----------

The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts.

SATA Support
------------

There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :(

XHCI Support
------------

There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from.

EHCI Support
------------

This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot.

According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it.

PCIe Support
------------

This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.

DDR3 Training
-------------

Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is.

PEX Init
--------

Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of.

Static Environment
------------------

This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs.

---
 arch/arm/dts/Makefile                           |   3 +-
 arch/arm/dts/armada-xp-synology-ds414.dts       | 337 ++++++++++++++++++++++++
 arch/arm/mach-mvebu/Kconfig                     |   7 +
 arch/arm/mach-mvebu/serdes/axp/board_env_spec.h |   2 +-
 board/Synology/ds414/Makefile                   |   7 +
 board/Synology/ds414/ds414.c                    | 185 +++++++++++++
 board/Synology/ds414/kwbimage.cfg               |  12 +
 configs/ds414_defconfig                         |  18 ++
 include/configs/ds414.h                         | 162 ++++++++++++
 9 files changed, 731 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/armada-xp-synology-ds414.dts
 create mode 100644 board/Synology/ds414/Makefile
 create mode 100644 board/Synology/ds414/ds414.c
 create mode 100644 board/Synology/ds414/kwbimage.cfg
 create mode 100644 configs/ds414_defconfig
 create mode 100644 include/configs/ds414.h
arch/arm/dts/Makefile +2 -1
index 6e2a95f..9276b7f 100644
@@ -51,7 +51,8 @@ dtb-$(CONFIG_ARCH_MVEBU) +=			\
 	armada-388-clearfog.dtb			\
 	armada-388-gp.dtb			\
 	armada-xp-gp.dtb			\
-	armada-xp-maxbcm.dtb
+	armada-xp-maxbcm.dtb			\
+	armada-xp-synology-ds414.dtb
 
 dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld4-ref.dtb \
arch/arm/dts/armada-xp-synology-ds414.dts new file +337 -0

337 lines not on this page · raw message

arch/arm/mach-mvebu/Kconfig +7 -0
index a39f900..e6e457d 100644
@@ -38,6 +38,10 @@ config TARGET_DB_MV784MP_GP
 	bool "Support db-mv784mp-gp"
 	select MV78460
 
+config TARGET_DS414
+	bool "Support Synology DS414"
+	select MV78230
+
 config TARGET_MAXBCM
 	bool "Support maxbcm"
 	select MV78460
@@ -48,18 +52,21 @@ config SYS_BOARD
 	default "clearfog" if TARGET_CLEARFOG
 	default "db-88f6820-gp" if TARGET_DB_88F6820_GP
 	default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP
+	default "ds414" if TARGET_DS414
 	default "maxbcm" if TARGET_MAXBCM
 
 config SYS_CONFIG_NAME
 	default "clearfog" if TARGET_CLEARFOG
 	default "db-88f6820-gp" if TARGET_DB_88F6820_GP
 	default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP
+	default "ds414" if TARGET_DS414
 	default "maxbcm" if TARGET_MAXBCM
 
 config SYS_VENDOR
 	default "Marvell" if TARGET_DB_MV784MP_GP
 	default "Marvell" if TARGET_DB_88F6820_GP
 	default "solidrun" if TARGET_CLEARFOG
+	default "Synology" if TARGET_DS414
 
 config SYS_SOC
 	default "mvebu"
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +1 -1
index f00f327..c8d9485 100644
@@ -44,7 +44,7 @@
 #define DB_784MP_GP_ID			(RD_78460_SERVER_REV2_ID + 1)
 #define RD_78460_CUSTOMER_ID		(DB_784MP_GP_ID + 1)
 #define MV_MAX_BOARD_ID			(RD_78460_CUSTOMER_ID + 1)
-#define INVALID_BAORD_ID		0xFFFFFFFF
+#define INVALID_BOARD_ID		0xFFFFFFFF
 
 /* Sample at Reset */
 #define MPP_SAMPLE_AT_RESET(id)		(0x18230 + (id * 4))
board/Synology/ds414/Makefile new file +7 -0
new file mode 100644
index 0000000..0f4c32d
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2015 Phil Sutter <[email protected]>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y :=	ds414.o
board/Synology/ds414/ds414.c new file +185 -0

185 lines not on this page · raw message

board/Synology/ds414/kwbimage.cfg new file +12 -0
new file mode 100644
index 0000000..1f748db
@@ -0,0 +1,12 @@
+#
+# Copyright (C) 2014 Stefan Roese <[email protected]>
+#
+
+# Armada XP uses version 1 image format
+VERSION		1
+
+# Boot Media configurations
+BOOT_FROM	spi
+
+# Binary Header (bin_hdr) with DDR3 training code
+BINARY spl/u-boot-spl-dtb.bin 0000005b 00000068
configs/ds414_defconfig new file +18 -0
new file mode 100644
index 0000000..4c3c1df
@@ -0,0 +1,18 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_DS414=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-xp-synology-ds414"
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xd0012000
+CONFIG_DEBUG_UART_CLOCK=250000000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
include/configs/ds414.h new file +162 -0

162 lines not on this page · raw message

Signature · 1 line
2.5.3
#18 lore raw

PATCH v3 9/10 mvebu: Support Synology DS414

Quoted 4 lines · Phil Sutter

This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.

So, for the code:

But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/75dcd31f/attachment.sig>
#19 lore raw

PATCH v3 9/10 mvebu: Support Synology DS414

Hi Tom,

Quoted 7 lines · Tom Rini
Quoted 4 lines · Phil Sutter

This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.

Quoted 7 lines

So, for the code:

But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!

I've already prepared a git branch, with all the pending Marvell mvebu related patches included. For Luka to pull from into the official Marvell U-boot git repo. And I've added Phil's patches as well. My personal feeling is, that all this additional text could be quite useful. That's why I would like to keep it in. But if you really feel that we should remove it, then I can definitely drop those passages.

Just let me know what you think.

Thanks,
Stefan

#20 lore raw

PATCH v3 9/10 mvebu: Support Synology DS414

Quoted 26 lines · Stefan Roese

Hi Tom,

Quoted 7 lines · Tom Rini
Quoted 4 lines · Phil Sutter

This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.

Quoted 7 lines

So, for the code:

But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!

I've already prepared a git branch, with all the pending Marvell mvebu related patches included. For Luka to pull from into the official Marvell U-boot git repo. And I've added Phil's patches as well. My personal feeling is, that all this additional text could be quite useful. That's why I would like to keep it in. But if you really feel that we should remove it, then I can definitely drop those passages.

Quoted 1 line

Just let me know what you think.

I'll live with it in the commit log, thanks.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/a1cd1e3a/attachment.sig>
#21 lore raw

PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set

In reply to a message not in the archive

Synology keeps per item configuration in a dedicated 'partition' in SPI flash, namely the one named 'vendor' in DTS file. It contains the two NICs MAC addresses as well as the item's serial number. I didn't find a way to have this information extracted automatically, therefore implemented 'syno populate_env' command which extracts the three values and puts them into environment. To make things permanent though, one has to 'saveenv'.

Another command is 'syno clk_gate', which allows to change the clock gating which is done in DS414 board file.

---
 board/Synology/common/Makefile   |   7 ++
 board/Synology/common/cmd_syno.c | 227 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 234 insertions(+)
 create mode 100644 board/Synology/common/Makefile
 create mode 100644 board/Synology/common/cmd_syno.c
board/Synology/common/Makefile new file +7 -0
new file mode 100644
index 0000000..e66aeb8
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2015 Phil Sutter <[email protected]>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y :=	cmd_syno.o
board/Synology/common/cmd_syno.c new file +227 -0

227 lines not on this page · raw message

Signature · 1 line
2.5.3
#22 lore raw

PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set

Hi Phil,

I'm preparing a branch for Luka to pull from. With all the pending mvebu patches included. And noticed a small issue with this patch. See below...

Quoted 245 lines · Phil Sutter

Synology keeps per item configuration in a dedicated 'partition' in SPI flash, namely the one named 'vendor' in DTS file. It contains the two NICs MAC addresses as well as the item's serial number. I didn't find a way to have this information extracted automatically, therefore implemented 'syno populate_env' command which extracts the three values and puts them into environment. To make things permanent though, one has to 'saveenv'.

Another command is 'syno clk_gate', which allows to change the clock gating which is done in DS414 board file.

---
  board/Synology/common/Makefile   |   7 ++
  board/Synology/common/cmd_syno.c | 227 +++++++++++++++++++++++++++++++++++++++
  2 files changed, 234 insertions(+)

create mode 100644 board/Synology/common/Makefile create mode 100644 board/Synology/common/cmd_syno.c

board/Synology/common/Makefile new file +7 -0
new file mode 100644
index 0000000..e66aeb8
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2015 Phil Sutter <[email protected]>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y :=	cmd_syno.o
board/Synology/common/cmd_syno.c new file +207 -0
new file mode 100644
index 0000000..4a1918d
@@ -0,0 +1,227 @@
+/*
+ * Commands to deal with Synology specifics.
+ *
+ * Copyright (C) 2015  Phil Sutter <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <div64.h>
+#include <spi.h>
+#include <spi_flash.h>
+#include <linux/mtd/mtd.h>
+
+#include <asm/io.h>
+#include "../drivers/ddr/marvell/axp/ddr3_init.h"
+
+#define ETH_ALEN		6
+#define ETHADDR_MAX		4
+#define SYNO_SN_TAG		"SN="
+#define SYNO_CHKSUM_TAG		"CHK="
+
+
+static int do_syno_populate(int argc, char * const argv[])
+{
+	unsigned int bus = CONFIG_SF_DEFAULT_BUS;
+	unsigned int cs = CONFIG_SF_DEFAULT_CS;
+	unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
+	unsigned int mode = CONFIG_SF_DEFAULT_MODE;
+	struct spi_flash *flash;
+	unsigned long addr = 0x80000; /* XXX: parameterize this? */
+	loff_t offset = 0x007d0000;
+	loff_t len = 0x00010000;
+	char *buf, *bufp;
+	char var[128];
+	char val[128];
+	int ret, n;
+
+	/* XXX: arg parsing to select flash here? */
+
+	flash = spi_flash_probe(bus, cs, speed, mode);
+	if (!flash) {
+		printf("Failed to initialize SPI flash at %u:%u\n", bus, cs);
+		return 1;
+	}
+
+	buf = map_physmem(addr, len, MAP_WRBACK);
+	if (!buf) {
+		puts("Failed to map physical memory\n");
+		return 1;
+	}
+
+	ret = spi_flash_read(flash, offset, len, buf);
+	if (ret) {
+		puts("Failed to read from SPI flash\n");
+		goto out_unmap;
+	}
+
+	for (n = 0; n < ETHADDR_MAX; n++) {
+		char ethaddr[ETH_ALEN];
+		int i, sum = 0;
+		unsigned char csum = 0;
+
+		for (i = 0, bufp = buf + n * 7; i < ETH_ALEN; i++) {
+			sum += bufp[i];
+			csum += bufp[i];
+			ethaddr[i] = bufp[i];
+		}
+		if (!sum)		/* MAC address empty */
+			continue;
+		if (csum != bufp[i]) {	/* seventh byte is checksum value */
+			printf("Invalid MAC address for interface %d!\n", n);
+			continue;
+		}
+		if (n == 0)
+			sprintf(var, "ethaddr");
+		else
+			sprintf(var, "eth%daddr", n);
+		snprintf(val, sizeof(val) - 1,
+		         "%02x:%02x:%02x:%02x:%02x:%02x",
+		         ethaddr[0], ethaddr[1], ethaddr[2],
+			 ethaddr[3], ethaddr[4], ethaddr[5]);
+		printf("parsed %s = %s\n", var, val);
+		setenv(var, val);
+	}
+	if (!strncmp(buf + 32, SYNO_SN_TAG, strlen(SYNO_SN_TAG))) {
+		char *snp, *csump;
+		int csum = 0;
+		unsigned long c;
+
+		snp = bufp = buf + 32 + strlen(SYNO_SN_TAG);
+		for (n = 0; bufp[n] && bufp[n] != ','; n++)
+			csum += bufp[n];
+		bufp[n] = '\0';
+
+		/* should come right after, but you never know */
+		bufp = strstr(bufp + n + 1, SYNO_CHKSUM_TAG);
+		if (!bufp) {
+			printf("Serial number checksum tag missing!\n");
+			goto out_unmap;
+		}
+
+		csump = bufp += strlen(SYNO_CHKSUM_TAG);
+		for (n = 0; bufp[n] && bufp[n] != ','; n++)
+			;
+		bufp[n] = '\0';
+
+		if (strict_strtoul(csump, 10, &c) || c != csum) {
+			puts("Invalid serial number found!\n");
+			ret = 1;
+			goto out_unmap;
+		}
+		printf("parsed SN = %s\n", snp);
+		setenv("SN", snp);
+	} else {	/* old style format */
+		unsigned char csum = 0;
+
+		for (n = 0, bufp = buf + 32; n < 10; n++)
+			csum += bufp[n];
+
+		if (csum != bufp[n]) {
+			puts("Invalid serial number found!\n");
+			ret = 1;
+			goto out_unmap;
+		}
+		bufp[n] = '\0';
+		printf("parsed SN = %s\n", buf + 32);
+		setenv("SN", buf + 32);
+	}
+out_unmap:
+	unmap_physmem(buf, len);
+	return ret;
+}
+
+/* map bit position to function in POWER_MNG_CTRL_REG */
+static const char * const pwr_mng_bit_func[] = {
+	"audio",
+	"ge3", "ge2", "ge1", "ge0",
+	"pcie00", "pcie01", "pcie02", "pcie03",
+	"pcie10", "pcie11", "pcie12", "pcie13",
+	"bp",
+	"sata0_link", "sata0_core",
+	"lcd",
+	"sdio",
+	"usb0", "usb1", "usb2",
+	"idma", "xor0", "crypto",
+	NULL,
+	"tdm",
+	"pcie20", "pcie30",
+	"xor1",
+	"sata1_link", "sata1_core",
+	NULL,
+};
+
+static int do_syno_clk_gate(int argc, char * const argv[])
+{
+	u32 pwr_mng_ctrl_reg = reg_read(POWER_MNG_CTRL_REG);
+	const char *func, *state;
+	int i, val;
+
+	if (argc < 2)
+		return -1;
+
+	if (!strcmp(argv[1], "get")) {
+		puts("Clock Gating:\n");
+		for (i = 0; i < 32; i++) {
+			func = pwr_mng_bit_func[i];
+			if (!func)
+				continue;
+			state = pwr_mng_ctrl_reg & (1 << i) ?  "ON" : "OFF";
+			printf("%s:\t\t%s\n", func, state);
+		}
+		return 0;
+	}
+	if (argc < 4)
+		return -1;
+	if (!strcmp(argv[1], "set")) {
+		func = argv[2];
+		state = argv[3];
+		for (i = 0; i < 32; i++) {
+			if (!pwr_mng_bit_func[i])
+				continue;
+			if (!strcmp(func, pwr_mng_bit_func[i]))
+				break;
+		}
+		if (i == 32) {
+			printf("Error: name '%s' not known\n", func);
+			return -1;
+		}
+		val = state[0] != '0';
+		pwr_mng_ctrl_reg |= (val << i);
+		pwr_mng_ctrl_reg &= ~(!val << i);
+		reg_write(POWER_MNG_CTRL_REG, pwr_mng_ctrl_reg);
+	}
+	return 0;
+}
+
+static int do_syno(cmd_tbl_t *cmdtp, int flag,
+                   int argc, char * const argv[])
+{
+	const char *cmd;
+	int ret;
+
+	if (argc < 2)
+		goto usage;
+
+	cmd = argv[1];

board/Synology/common/cmd_syno.c line 217

Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10 -0
+	--argc;
+	++argv;
+
+	if (!strcmp(cmd, "populate_env"))
+		ret = do_syno_populate(argc, argv);
+	else if (!strcmp(cmd, "clk_gate"))
+		ret = do_syno_clk_gate(argc, argv);
+
+	if (ret != -1)
+		return ret;

Here I get this warning:

board/Synology/common/cmd_syno.c: In function 'do_syno':
board/Synology/common/cmd_syno.c:216:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (ret != -1)

     ^

I've changed this to init ret to 0 in my branch. Let me know if this is okay with you.

Thanks,
Stefan

#23 lore raw

PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set

Hi Stefan,

Quoted 5 lines · Stefan Roese

I'm preparing a branch for Luka to pull from. With all the pending mvebu patches included. And noticed a small issue with this patch. See below...

On 25.12.2015 14:41, Phil Sutter wrote:

[...]

Quoted 23 lines
Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10 -0
+static int do_syno(cmd_tbl_t *cmdtp, int flag,
+                   int argc, char * const argv[])
+{
+	const char *cmd;
+	int ret;
+
+	if (argc < 2)
+		goto usage;
+
+	cmd = argv[1];

board/Synology/common/cmd_syno.c line 217

Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10 -0
+	--argc;
+	++argv;
+
+	if (!strcmp(cmd, "populate_env"))
+		ret = do_syno_populate(argc, argv);
+	else if (!strcmp(cmd, "clk_gate"))
+		ret = do_syno_clk_gate(argc, argv);
+
+	if (ret != -1)
+		return ret;

Here I get this warning:

Quoted 7 lines

board/Synology/common/cmd_syno.c: In function 'do_syno':
board/Synology/common/cmd_syno.c:216:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (ret != -1)

     ^

I've changed this to init ret to 0 in my branch. Let me know if this is okay with you.

Yes, sure! I have to admit, I didn't spend much time on this file. It was always merely for fixing the "real" issues.

Thanks, Phil

#24 lore raw

PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set

In reply to Phil Sutter
Quoted 8 lines · Phil Sutter

Synology keeps per item configuration in a dedicated 'partition' in SPI flash, namely the one named 'vendor' in DTS file. It contains the two NICs MAC addresses as well as the item's serial number. I didn't find a way to have this information extracted automatically, therefore implemented 'syno populate_env' command which extracts the three values and puts them into environment. To make things permanent though, one has to 'saveenv'.

Quoted 4 lines

Another command is 'syno clk_gate', which allows to change the clock gating which is done in DS414 board file.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/b7929b0f/attachment.sig>