[U-Boot] [PATCH v2 1/8] drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

[U-Boot] [PATCH v2 1/8] drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

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

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 drivers/pci/pci_auto_old.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_auto_old.c b/drivers/pci/pci_auto_old.c
index 932eab8..8f17779 100644
--- a/drivers/pci/pci_auto_old.c
+++ b/drivers/pci/pci_auto_old.c
@@ -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
-- 
2.5.3

[U-Boot] [PATCH v2 1/8] drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY

[Stefan Roese]

(adding Simon and Bin to Cc)

On 22.12.2015 00:25, Phil Sutter wrote:
> 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.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>   drivers/pci/pci_auto_old.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci_auto_old.c b/drivers/pci/pci_auto_old.c
> index 932eab8..8f17779 100644
> --- a/drivers/pci/pci_auto_old.c
> +++ b/drivers/pci/pci_auto_old.c
> @@ -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
>

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

Thanks,
Stefan

[U-Boot] [PATCH v2 2/8] mvebu: Fix for non-DM ehci-marvell support

[Phil Sutter]

This mimics the relevant code in mach-kirkwood headers. The
*_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_*
macros. Implementing shared headers/code between mvebu and kirkwood is
left for someone with a better knowledge of how u-boot is organized
internally.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 arch/arm/mach-mvebu/cpu.c              | 21 +++++++++++++++++++++
 arch/arm/mach-mvebu/include/mach/cpu.h |  3 +++
 arch/arm/mach-mvebu/include/mach/soc.h |  9 ++++++++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index c9b9c77..fd12c22 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -45,6 +45,27 @@ void reset_cpu(unsigned long ignored)
 		;
 }
 
+/*
+ * Window Size
+ * Used with the Base register to set the address window size and location.
+ * Must be programmed from LSB to MSB as sequence of ones followed by
+ * sequence of zeros. The number of ones specifies the size of the window in
+ * 64 KByte granularity (e.g., a value of 0x00FF specifies 256 = 16 MByte).
+ * NOTE: A value of 0x0 specifies 64-KByte size.
+ */
+unsigned int mvebu_winctrl_calcsize(unsigned int sizeval)
+{
+	int i;
+	unsigned int j = 0;
+	u32 val = sizeval >> 1;
+
+	for (i = 0; val >= 0x10000; i++) {
+		j |= (1 << i);
+		val = val >> 1;
+	}
+	return 0x0000ffff & j;
+}
+
 int mvebu_soc_family(void)
 {
 	u16 devid = (readl(MVEBU_REG_PCIE_DEVID) >> 16) & 0xffff;
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
index 5e8bf0c..484638b 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -13,6 +13,9 @@
 
 #ifndef __ASSEMBLY__
 
+#define MVEBU_CPU_WIN_CTRL_DATA(size, target, attr, en) (en | (target << 4) \
+			| (attr << 8) | (mvebu_winctrl_calcsize(size) << 16))
+
 #define MVEBU_REG_PCIE_DEVID		(MVEBU_REG_PCIE_BASE + 0x00)
 #define MVEBU_REG_PCIE_REVID		(MVEBU_REG_PCIE_BASE + 0x08)
 
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h
index 5d4ad30..cfc28c3 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -91,8 +91,15 @@
 #define SDRAM_MAX_CS		4
 #define SDRAM_ADDR_MASK		0xFF000000
 
+/* MVEBU USB Host controller */
+#define MVUSB0_BASE			MVEBU_AXP_USB_BASE
+#define MVUSB0_CPU_ATTR_DRAM_CS0	CPU_ATTR_DRAM_CS0
+#define MVUSB0_CPU_ATTR_DRAM_CS1	CPU_ATTR_DRAM_CS1
+#define MVUSB0_CPU_ATTR_DRAM_CS2	CPU_ATTR_DRAM_CS2
+#define MVUSB0_CPU_ATTR_DRAM_CS3	CPU_ATTR_DRAM_CS3
+
 /* MVEBU CPU memory windows */
-#define MVCPU_WIN_CTRL_DATA	CPU_WIN_CTRL_DATA
+#define MVCPU_WIN_CTRL_DATA	MVEBU_CPU_WIN_CTRL_DATA
 #define MVCPU_WIN_ENABLE	CPU_WIN_ENABLE
 #define MVCPU_WIN_DISABLE	CPU_WIN_DISABLE
 
-- 
2.5.3

[U-Boot] [PATCH v2 2/8] mvebu: Fix for non-DM ehci-marvell support

[Stefan Roese]

Hi Phil,

On 22.12.2015 00:25, Phil Sutter wrote:
> This mimics the relevant code in mach-kirkwood headers. The
> *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_*
> macros. Implementing shared headers/code between mvebu and kirkwood is
> left for someone with a better knowledge of how u-boot is organized
> internally.

Why do you need this functionality on your Armada XP board? It
should be able to use the DM enabled ehci-marvell driver.

Thanks,
Stefan

[U-Boot] [PATCH v2 2/8] mvebu: Fix for non-DM ehci-marvell support

[Phil Sutter]

Hi Stefan,

On Tue, Dec 22, 2015 at 09:02:44AM +0100, Stefan Roese wrote:
> On 22.12.2015 00:25, Phil Sutter wrote:
> > This mimics the relevant code in mach-kirkwood headers. The
> > *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_*
> > macros. Implementing shared headers/code between mvebu and kirkwood is
> > left for someone with a better knowledge of how u-boot is organized
> > internally.
> 
> Why do you need this functionality on your Armada XP board? It
> should be able to use the DM enabled ehci-marvell driver.

Yes, it works without as long as CONFIG_DM_USB is enabled. Yet I thought
fixing it nevertheless was desirable to allow for testing or whatever
without.

If you don't see any use in it, I can drop this from the upcoming V3 of
course. OTOH maybe we should enforce DM_USB for Armada XP boards with
ehci-marvell enabled?

Thanks, Phil

[U-Boot] [PATCH v2 2/8] mvebu: Fix for non-DM ehci-marvell support

[Stefan Roese]

Hi Phil,

On 22.12.2015 15:24, Phil Sutter wrote:
> On Tue, Dec 22, 2015 at 09:02:44AM +0100, Stefan Roese wrote:
>> On 22.12.2015 00:25, Phil Sutter wrote:
>>> This mimics the relevant code in mach-kirkwood headers. The
>>> *_winctrl_calcsize functions are identical, as well as the MVCPU_WIN_*
>>> macros. Implementing shared headers/code between mvebu and kirkwood is
>>> left for someone with a better knowledge of how u-boot is organized
>>> internally.
>>
>> Why do you need this functionality on your Armada XP board? It
>> should be able to use the DM enabled ehci-marvell driver.
>
> Yes, it works without as long as CONFIG_DM_USB is enabled. Yet I thought
> fixing it nevertheless was desirable to allow for testing or whatever
> without.

Using a driver that supports DM on a platform that supports DM is
the way to go. On the long run, all driver and platforms will
get converted to DM.

> If you don't see any use in it, I can drop this from the upcoming V3 of
> course.

Yes, please drop it.

> OTOH maybe we should enforce DM_USB for Armada XP boards with
> ehci-marvell enabled?

Yes. I think once all the patches have reached mainline (after the
next release), such an automatic selection of the DM_xxx stuff should
be done.

Thanks,
Stefan

[U-Boot] [PATCH v2 3/8] README: Review the u-boot porting guide list

[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).

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 README | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/README b/README
index 4fee706..dcc9478 100644
--- a/README
+++ b/README
@@ -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.
-- 
2.5.3

[U-Boot] [PATCH v2 3/8] README: Review the u-boot porting guide list

[Stefan Roese]

On 22.12.2015 00:25, Phil Sutter wrote:
> * 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).
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>   README | 11 ++++-------
>   1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/README b/README
> index 4fee706..dcc9478 100644
> --- a/README
> +++ b/README
> @@ -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.
>

Seems this documentation is really outdated and needs some further
adjustments. But still, this is definitely the right direction, so:

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

Thanks,
Stefan

[U-Boot] [PATCH v2 4/8] axp: Fix debugging support in DDR3 write leveling

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

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 drivers/ddr/marvell/axp/ddr3_write_leveling.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ddr/marvell/axp/ddr3_write_leveling.c b/drivers/ddr/marvell/axp/ddr3_write_leveling.c
index df3a3df..da384f3 100644
--- a/drivers/ddr/marvell/axp/ddr3_write_leveling.c
+++ b/drivers/ddr/marvell/axp/ddr3_write_leveling.c
@@ -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 */
-- 
2.5.3

[U-Boot] [PATCH v2 4/8] axp: Fix debugging support in DDR3 write leveling

[Stefan Roese]

On 22.12.2015 00:25, Phil Sutter wrote:
> 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.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>   drivers/ddr/marvell/axp/ddr3_write_leveling.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ddr/marvell/axp/ddr3_write_leveling.c b/drivers/ddr/marvell/axp/ddr3_write_leveling.c
> index df3a3df..da384f3 100644
> --- a/drivers/ddr/marvell/axp/ddr3_write_leveling.c
> +++ b/drivers/ddr/marvell/axp/ddr3_write_leveling.c
> @@ -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 */
>

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

Thanks,
Stefan

[U-Boot] [PATCH v2 5/8] drivers/pci/pci_mvebu: Fix for boards with X4 lanes

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

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.
Especially since the ugly includes will have to be done anyway.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 drivers/pci/pci_mvebu.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index fd2744d..aab53f4 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -18,6 +18,11 @@
 #include <asm/arch/soc.h>
 #include <linux/mbus.h>
 
+#if defined(CONFIG_ARMADA_XP)
+#include "../ddr/marvell/axp/ddr3_init.h"
+#include "../../arch/arm/mach-mvebu/serdes/axp/board_env_spec.h"
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* PCIe unit register offsets */
@@ -155,6 +160,16 @@ static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx,
 }
 #endif
 
+#if defined(CONFIG_ARMADA_XP)
+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 (reg_read(GEN_PURP_RES_2_REG) & mask) == mask;
+}
+#endif
+
 static inline bool mvebu_pcie_link_up(struct mvebu_pcie *pcie)
 {
 	u32 val;
@@ -419,5 +434,11 @@ void pci_init_board(void)
 		writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
 
 		bus = hose->last_busno + 1;
+
+#if defined(CONFIG_ARMADA_XP)
+		/* need to skip more for X4 links, otherwise scan will hang */
+		if (mvebu_pex_unit_is_x4(i))
+			i += 3;
+#endif
 	}
 }
-- 
2.5.3

[U-Boot] [PATCH v2 5/8] drivers/pci/pci_mvebu: Fix for boards with X4 lanes

[Stefan Roese]

On 22.12.2015 00:25, Phil Sutter wrote:
> 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.
> Especially since the ugly includes will have to be done anyway.
> 
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>   drivers/pci/pci_mvebu.c | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
> index fd2744d..aab53f4 100644
> --- a/drivers/pci/pci_mvebu.c
> +++ b/drivers/pci/pci_mvebu.c
> @@ -18,6 +18,11 @@
>   #include <asm/arch/soc.h>
>   #include <linux/mbus.h>
>   
> +#if defined(CONFIG_ARMADA_XP)
> +#include "../ddr/marvell/axp/ddr3_init.h"
> +#include "../../arch/arm/mach-mvebu/serdes/axp/board_env_spec.h"
> +#endif

Yes, this is ugly. And AFAICT, you only need it to include the 
GEN_PURP_RES_2_REG define from these headers.

I would prefer to add this macro either here (again), or in soc.h.
And use the name from the Marvell manual, so something like

#define COMPHY_REFCLK_ALIGNMENT		(MVEBU_REGISTER(0x182f8))

> +
>   DECLARE_GLOBAL_DATA_PTR;
>   
>   /* PCIe unit register offsets */
> @@ -155,6 +160,16 @@ static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx,
>   }
>   #endif
>   
> +#if defined(CONFIG_ARMADA_XP)
> +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 (reg_read(GEN_PURP_RES_2_REG) & mask) == mask;

readl() with the new define please.

> +}
> +#endif

Please drop the #ifdef here. This can go in unconditionally.

> +
>   static inline bool mvebu_pcie_link_up(struct mvebu_pcie *pcie)
>   {
>   	u32 val;
> @@ -419,5 +434,11 @@ void pci_init_board(void)
>   		writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
>   
>   		bus = hose->last_busno + 1;
> +
> +#if defined(CONFIG_ARMADA_XP)
> +		/* need to skip more for X4 links, otherwise scan will hang */
> +		if (mvebu_pex_unit_is_x4(i))
> +			i += 3;
> +#endif

And please use this version here:

		/* 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;
		}

Thanks,
Stefan

[U-Boot] [PATCH v2 6/8] mvebu: Add rudimental MV78320 support

[Phil Sutter]

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 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(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index fd12c22..941df7e 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -70,13 +70,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;
 }
 
@@ -89,6 +92,9 @@ int print_cpuinfo(void)
 	puts("SoC:   ");
 
 	switch (devid) {
+	case SOC_MV78230_ID:
+		puts("MV78230-");
+		break;
 	case SOC_MV78260_ID:
 		puts("MV78260-");
 		break;
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h
index cfc28c3..94e6b96 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -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
diff --git a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
index bfa7f13..0e2a905 100644
--- a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
@@ -194,7 +194,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;
@@ -212,6 +214,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:
-- 
2.5.3

[U-Boot] [PATCH v2 6/8] mvebu: Add rudimental MV78320 support

[Stefan Roese]

On 22.12.2015 00:25, Phil Sutter wrote:
> Signed-off-by: Phil Sutter <phil@nwl.cc>

Please always add a small description into the commit text.
This is a common requirement, even for quite "simple"
patches.

Other than this look good, so:

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

Thanks,
Stefan

> ---
>   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(-)
>
> diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> index fd12c22..941df7e 100644
> --- a/arch/arm/mach-mvebu/cpu.c
> +++ b/arch/arm/mach-mvebu/cpu.c
> @@ -70,13 +70,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;
>   }
>
> @@ -89,6 +92,9 @@ int print_cpuinfo(void)
>   	puts("SoC:   ");
>
>   	switch (devid) {
> +	case SOC_MV78230_ID:
> +		puts("MV78230-");
> +		break;
>   	case SOC_MV78260_ID:
>   		puts("MV78260-");
>   		break;
> diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h
> index cfc28c3..94e6b96 100644
> --- a/arch/arm/mach-mvebu/include/mach/soc.h
> +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> @@ -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
> diff --git a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> index bfa7f13..0e2a905 100644
> --- a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> +++ b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> @@ -194,7 +194,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;
> @@ -212,6 +214,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:
>


-- 
Viele Gr??e,
Stefan

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

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

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

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.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 arch/arm/Kconfig                                   |   1 +
 arch/arm/dts/Makefile                              |   2 +
 arch/arm/dts/armada-xp-synology-ds414.dts          | 337 +++++++++++++++++++++
 arch/arm/mach-mvebu/Kconfig                        |   3 +
 arch/arm/mach-mvebu/serdes/axp/board_env_spec.h    |   5 +-
 .../arm/mach-mvebu/serdes/axp/high_speed_env_lib.c |   3 +
 board/Synology/ds414/Kconfig                       |  12 +
 board/Synology/ds414/Makefile                      |   1 +
 board/Synology/ds414/ds414.c                       | 173 +++++++++++
 board/Synology/ds414/kwbimage.cfg                  |  12 +
 configs/ds414_defconfig                            |  18 ++
 include/configs/ds414.h                            | 164 ++++++++++
 12 files changed, 729 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/armada-xp-synology-ds414.dts
 create mode 100644 board/Synology/ds414/Kconfig
 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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 867303a..96c3a7c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -813,6 +813,7 @@ source "board/hisilicon/hikey/Kconfig"
 source "board/imx31_phycore/Kconfig"
 source "board/isee/igep0033/Kconfig"
 source "board/maxbcm/Kconfig"
+source "board/Synology/ds414/Kconfig"
 source "board/mpl/vcma9/Kconfig"
 source "board/olimex/mx23_olinuxino/Kconfig"
 source "board/phytec/pcm051/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6e2a95f..26fd2f8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -53,6 +53,8 @@ dtb-$(CONFIG_ARCH_MVEBU) +=			\
 	armada-xp-gp.dtb			\
 	armada-xp-maxbcm.dtb
 
+dtb-$(CONFIG_TARGET_DS414) += armada-xp-synology-ds414.dtb
+
 dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld4-ref.dtb \
 	uniphier-ph1-ld6b-ref.dtb \
diff --git a/arch/arm/dts/armada-xp-synology-ds414.dts b/arch/arm/dts/armada-xp-synology-ds414.dts
new file mode 100644
index 0000000..0a60ddf
--- /dev/null
+++ b/arch/arm/dts/armada-xp-synology-ds414.dts
@@ -0,0 +1,337 @@
+/*
+ * Device Tree file for Synology DS414
+ *
+ * Copyright (C) 2014, Arnaud EBALARD <arno@natisbad.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the old 0xd0000000).
+ * The 0xf1000000 is the default used by the recent, DT-capable, U-Boot
+ * bootloaders provided by Marvell. It is used in recent versions of
+ * DSM software provided by Synology. Nonetheless, some earlier boards
+ * were delivered with an older version of u-boot that left internal
+ * registers mapped at 0xd0000000. If you have such a device you will
+ * not be able to directly boot a kernel based on this Device Tree. In
+ * that case, the preferred solution is to update your bootloader (e.g.
+ * by upgrading to latest version of DSM, or building a new one and
+ * installing it from u-boot prompt) or adjust the Devive Tree
+ * (s/0xf1000000/0xd0000000/ in 'ranges' below).
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "armada-xp-mv78230.dtsi"
+
+/ {
+	model = "Synology DS414";
+	compatible = "synology,ds414", "marvell,armadaxp-mv78230",
+		     "marvell,armadaxp", "marvell,armada-370-xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+		stdout-path = &uart0;
+	};
+
+	aliases {
+		spi0 = &spi0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0 0x00000000 0 0x40000000>; /* 1GB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * Connected to Marvell 88SX7042 SATA-II controller
+			 * handling the four disks.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/*
+			 * Connected to EtronTech EJ168A XHCI controller
+			 * providing the two rear USB 3.0 ports.
+			 */
+			pcie at 5,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+
+			/* RTC is provided by Seiko S-35390A below */
+			rtc at 10300 {
+				status = "disabled";
+			};
+
+			spi0: spi at 10600 {
+				status = "okay";
+				u-boot,dm-pre-reloc;
+
+				spi-flash at 0 {
+					u-boot,dm-pre-reloc;
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "micron,n25q064";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <20000000>;
+
+					/*
+					 * Warning!
+					 *
+					 * Synology u-boot uses its compiled-in environment
+					 * and it seems Synology did not care to change u-boot
+					 * default configuration in order to allow saving a
+					 * modified environment at a sensible location. So,
+					 * if you do a 'saveenv' under u-boot, your modified
+					 * environment will be saved at 1MB after the start
+					 * of the flash, i.e. in the middle of the uImage.
+					 * For that reason, it is strongly advised not to
+					 * change the default environment, unless you know
+					 * what you are doing.
+					 */
+					partition at 00000000 { /* u-boot */
+						label = "RedBoot";
+						reg = <0x00000000 0x000d0000>; /* 832KB */
+					};
+
+					partition at 000c0000 { /* uImage */
+						label = "zImage";
+						reg = <0x000d0000 0x002d0000>; /* 2880KB */
+					};
+
+					partition at 003a0000 { /* uInitramfs */
+						label = "rd.gz";
+						reg = <0x003a0000 0x00430000>; /* 4250KB */
+					};
+
+					partition at 007d0000 { /* MAC address and serial number */
+						label = "vendor";
+						reg = <0x007d0000 0x00010000>; /* 64KB */
+					};
+
+					partition at 007e0000 {
+						label = "RedBoot config";
+						reg = <0x007e0000 0x00010000>; /* 64KB */
+					};
+
+					partition at 007f0000 {
+						label = "FIS directory";
+						reg = <0x007f0000 0x00010000>; /* 64KB */
+					};
+				};
+			};
+
+			i2c at 11000 {
+				clock-frequency = <400000>;
+				status = "okay";
+
+				s35390a: s35390a at 30 {
+					 compatible = "sii,s35390a";
+					 reg = <0x30>;
+				};
+			};
+
+			/* Connected to a header on device's PCB. This
+			 * provides the main console for the device.
+			 *
+			 * Warning: the device may not boot with a 3.3V
+			 * USB-serial converter connected when the power
+			 * button is pressed. The converter needs to be
+			 * connected a few seconds after pressing the
+			 * power button. This is possibly due to UART0_TXD
+			 * pin being sampled at reset (bit 0 of SAR).
+			 */
+			serial at 12000 {
+				status = "okay";
+				u-boot,dm-pre-reloc;
+			};
+
+			/* Connected to a Microchip PIC16F883 for power control */
+			serial at 12100 {
+				status = "okay";
+			};
+
+			poweroff at 12100 {
+				compatible = "synology,power-off";
+				reg = <0x12100 0x100>;
+				clocks = <&coreclk 0>;
+			};
+
+			/* Front USB 2.0 port */
+			usb at 50000 {
+				status = "okay";
+			};
+
+			mdio {
+				phy0: ethernet-phy at 0 { /* Marvell 88E1512 */
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 { /* Marvell 88E1512 */
+					reg = <1>;
+				};
+			};
+
+			ethernet at 70000 {
+				status = "okay";
+				pinctrl-0 = <&ge0_rgmii_pins>;
+				pinctrl-names = "default";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+
+			ethernet at 74000 {
+				pinctrl-0 = <&ge1_rgmii_pins>;
+				pinctrl-names = "default";
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&sata1_pwr_pin &sata2_pwr_pin
+			     &sata3_pwr_pin &sata4_pwr_pin>;
+		pinctrl-names = "default";
+
+		sata1_regulator: sata1-regulator {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "SATA1 Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			startup-delay-us = <2000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+		};
+
+		sata2_regulator: sata2-regulator {
+			compatible = "regulator-fixed";
+			reg = <2>;
+			regulator-name = "SATA2 Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			startup-delay-us = <4000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+		};
+
+		sata3_regulator: sata3-regulator {
+			compatible = "regulator-fixed";
+			reg = <3>;
+			regulator-name = "SATA3 Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			startup-delay-us = <6000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+		};
+
+		sata4_regulator: sata4-regulator {
+			compatible = "regulator-fixed";
+			reg = <4>;
+			regulator-name = "SATA4 Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			startup-delay-us = <8000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&pinctrl {
+	sata1_pwr_pin: sata1-pwr-pin {
+		marvell,pins = "mpp42";
+		marvell,function = "gpio";
+	};
+
+	sata2_pwr_pin: sata2-pwr-pin {
+		marvell,pins = "mpp44";
+		marvell,function = "gpio";
+	};
+
+	sata3_pwr_pin: sata3-pwr-pin {
+		marvell,pins = "mpp45";
+		marvell,function = "gpio";
+	};
+
+	sata4_pwr_pin: sata4-pwr-pin {
+		marvell,pins = "mpp46";
+		marvell,function = "gpio";
+	};
+
+	sata1_pres_pin: sata1-pres-pin {
+		marvell,pins = "mpp34";
+		marvell,function = "gpio";
+	};
+
+	sata2_pres_pin: sata2-pres-pin {
+		marvell,pins = "mpp35";
+		marvell,function = "gpio";
+	};
+
+	sata3_pres_pin: sata3-pres-pin {
+		marvell,pins = "mpp40";
+		marvell,function = "gpio";
+	};
+
+	sata4_pres_pin: sata4-pres-pin {
+		marvell,pins = "mpp41";
+		marvell,function = "gpio";
+	};
+
+	syno_id_bit0_pin: syno-id-bit0-pin {
+		marvell,pins = "mpp26";
+		marvell,function = "gpio";
+	};
+
+	syno_id_bit1_pin: syno-id-bit1-pin {
+		marvell,pins = "mpp28";
+		marvell,function = "gpio";
+	};
+
+	syno_id_bit2_pin: syno-id-bit2-pin {
+		marvell,pins = "mpp29";
+		marvell,function = "gpio";
+	};
+
+	fan1_alarm_pin: fan1-alarm-pin {
+		marvell,pins = "mpp33";
+		marvell,function = "gpio";
+	};
+
+	fan2_alarm_pin: fan2-alarm-pin {
+		marvell,pins = "mpp32";
+		marvell,function = "gpio";
+	};
+};
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 82a439e..50fc8ee 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -16,6 +16,9 @@ config TARGET_DB_MV784MP_GP
 config TARGET_MAXBCM
 	bool "Support maxbcm"
 
+config TARGET_DS414
+	bool "Support Synology DS414"
+
 endchoice
 
 config SYS_SOC
diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
index f00f327..3dca6a1 100644
--- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
+++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
@@ -43,8 +43,9 @@
 #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
 #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
+#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
+#define INVALID_BOARD_ID		0xFFFFFFFF
 
 /* Sample at Reset */
 #define MPP_SAMPLE_AT_RESET(id)		(0x18230 + (id * 4))
diff --git a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
index 0e2a905..a789a60 100644
--- a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
@@ -66,6 +66,8 @@ static u32 board_id_get(void)
 	return DB_784MP_GP_ID;
 #elif defined(CONFIG_RD_78460_CUSTOMER)
 	return RD_78460_CUSTOMER_ID;
+#elif defined(CONFIG_SYNOLOGY_DS414)
+	return SYNOLOGY_DS414_ID;
 #else
 	/*
 	 * Return 0 here for custom board as this should not be used
@@ -262,6 +264,7 @@ int serdes_phy_config(void)
 	case RD_78460_SERVER_ID:
 	case RD_78460_SERVER_REV2_ID:
 	case DB_78X60_PCAC_ID:
+	case SYNOLOGY_DS414_ID:
 		satr11 = (0x1 << 1) | 1;
 		break;
 	case FPGA_88F78XX0_ID:
diff --git a/board/Synology/ds414/Kconfig b/board/Synology/ds414/Kconfig
new file mode 100644
index 0000000..4d30852
--- /dev/null
+++ b/board/Synology/ds414/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_DS414
+
+config SYS_BOARD
+	default "ds414"
+
+config SYS_VENDOR
+	default "Synology"
+
+config SYS_CONFIG_NAME
+	default "ds414"
+
+endif
diff --git a/board/Synology/ds414/Makefile b/board/Synology/ds414/Makefile
new file mode 100644
index 0000000..aad8c43
--- /dev/null
+++ b/board/Synology/ds414/Makefile
@@ -0,0 +1 @@
+obj-y :=	ds414.o
diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
new file mode 100644
index 0000000..88252f6
--- /dev/null
+++ b/board/Synology/ds414/ds414.c
@@ -0,0 +1,173 @@
+#include <common.h>
+#include <miiphy.h>
+#include <asm/io.h>
+#include <asm/arch/cpu.h>
+#include <asm/arch/soc.h>
+#include <linux/mbus.h>
+
+#include "../drivers/ddr/marvell/axp/ddr3_hw_training.h"
+#include "../arch/arm/mach-mvebu/serdes/axp/high_speed_env_spec.h"
+#include "../arch/arm/mach-mvebu/serdes/axp/board_env_spec.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* GPP and MPP settings as found in mvBoardEnvSpec.c of Synology's U-Boot */
+
+#define DS414_GPP_OUT_VAL_LOW		(BIT(25) | BIT(30))
+#define DS414_GPP_OUT_VAL_MID		(BIT(10) | BIT(15))
+#define DS414_GPP_OUT_VAL_HIGH		(0)
+
+#define DS414_GPP_OUT_POL_LOW		(0)
+#define DS414_GPP_OUT_POL_MID		(0)
+#define DS414_GPP_OUT_POL_HIGH		(0)
+
+#define DS414_GPP_OUT_ENA_LOW		(~(BIT(25) | BIT(30)))
+#define DS414_GPP_OUT_ENA_MID		(~(BIT(10) | BIT(12) | \
+					   BIT(13) | BIT(14) | BIT(15)))
+#define DS414_GPP_OUT_ENA_HIGH		(~0)
+
+static const u32 ds414_mpp_control[] = {
+	0x11111111,
+	0x22221111,
+	0x22222222,
+	0x00000000,
+	0x11110000,
+	0x00004000,
+	0x00000000,
+	0x00000000,
+	0x00000000
+};
+
+/* DDR3 static MC configuration */
+
+/* 1G_v1 (4x2Gbits) adapted by DS414 */
+MV_DRAM_MC_INIT syno_ddr3_b0_667_1g_v1[MV_MAX_DDR3_STATIC_SIZE] = {
+	{0x00001400, 0x73014A28},	/*DDR SDRAM Configuration Register */
+	{0x00001404, 0x30000800},	/*Dunit Control Low Register */
+	{0x00001408, 0x44148887},	/*DDR SDRAM Timing (Low) Register */
+	/* {0x0000140C, 0x38000C6}, */	/*DDR SDRAM Timing (High) Register */
+	{0x0000140C, 0x3AD83FEA},	/*DDR SDRAM Timing (High) Register */
+
+	{0x00001410, 0x14000000},	/*DDR SDRAM Address Control Register */
+
+	{0x00001414, 0x00000000},	/*DDR SDRAM Open Pages Control Register */
+	{0x00001418, 0x00000e00},	/*DDR SDRAM Operation Register */
+	{0x00001420, 0x00000004},	/*DDR SDRAM Extended Mode Register */
+	{0x00001424, 0x0000F3FF},	/*Dunit Control High Register */
+	{0x00001428, 0x000F8830},	/*Dunit Control High Register */
+	{0x0000142C, 0x054C36F4},	/*Dunit Control High Register */
+	{0x0000147C, 0x0000C671},
+
+	{0x000014a0, 0x00000001},
+	{0x000014a8, 0x00000100},	/*2:1 */
+	{0x00020220, 0x00000006},
+
+	{0x00001494, 0x00010000},	/*DDR SDRAM ODT Control (Low) Register */
+	{0x00001498, 0x00000000},	/*DDR SDRAM ODT Control (High) Register */
+	{0x0000149C, 0x00000001},	/*DDR Dunit ODT Control Register */
+
+	{0x000014C0, 0x192424C9},	/* DRAM address and Control Driving Strenght  */
+	{0x000014C4, 0x0AAA24C9},	/* DRAM Data and DQS Driving Strenght  */
+
+	{0x000200e8, 0x3FFF0E01},	/* DO NOT Modify - Open Mbus Window - 2G - Mbus is required for the training sequence*/
+	{0x00020184, 0x3FFFFFE0},	/* DO NOT Modify - Close fast path Window to - 2G */
+
+	{0x0001504, 0x3FFFFFE1},	/* CS0 Size */
+	{0x000150C, 0x00000000},	/* CS1 Size */
+	{0x0001514, 0x00000000},	/* CS2 Size */
+	{0x000151C, 0x00000000},	/* CS3 Size */
+
+	/*	{0x00001524, 0x0000C800},  */
+	{0x00001538, 0x00000009},	/*Read Data Sample Delays Register */
+	{0x0000153C, 0x00000009},	/*Read Data Ready Delay Register */
+
+	{0x000015D0, 0x00000650},	/*MR0 */
+	{0x000015D4, 0x00000044},	/*MR1 */
+	{0x000015D8, 0x00000010},	/*MR2 */
+	{0x000015DC, 0x00000000},	/*MR3 */
+
+	{0x000015E4, 0x00203c18},	/*ZQC Configuration Register */
+	{0x000015EC, 0xF800A225},	/*DDR PHY */
+
+	{0x0, 0x0}
+};
+
+MV_DRAM_MODES ds414_ddr_modes[MV_DDR3_MODES_NUMBER] = {
+	{"ds414_1333-667",   0x3, 0x5, 0x0, A0, syno_ddr3_b0_667_1g_v1,  NULL},
+};
+
+extern MV_SERDES_CHANGE_M_PHY serdes_change_m_phy[];
+
+MV_BIN_SERDES_CFG ds414_serdes_cfg[] = {
+	{ MV_PEX_ROOT_COMPLEX, 0x02011111, 0x00000000,
+	  { PEX_BUS_MODE_X4, PEX_BUS_MODE_X1, PEX_BUS_DISABLED,
+	    PEX_BUS_DISABLED },
+	  0x0040, serdes_change_m_phy
+	}
+};
+
+MV_DRAM_MODES *ddr3_get_static_ddr_mode(void)
+{
+	return &ds414_ddr_modes[0];
+}
+
+MV_BIN_SERDES_CFG *board_serdes_cfg_get(u8 pex_mode)
+{
+	return &ds414_serdes_cfg[0];
+}
+
+int board_early_init_f(void)
+{
+	int i;
+
+	/* Set GPP Out value */
+	reg_write(GPP_DATA_OUT_REG(0), DS414_GPP_OUT_VAL_LOW);
+	reg_write(GPP_DATA_OUT_REG(1), DS414_GPP_OUT_VAL_MID);
+	reg_write(GPP_DATA_OUT_REG(2), DS414_GPP_OUT_VAL_HIGH);
+
+	/* set GPP polarity */
+	reg_write(GPP_DATA_IN_POL_REG(0), DS414_GPP_OUT_POL_LOW);
+	reg_write(GPP_DATA_IN_POL_REG(1), DS414_GPP_OUT_POL_MID);
+	reg_write(GPP_DATA_IN_POL_REG(2), DS414_GPP_OUT_POL_HIGH);
+
+	/* Set GPP Out Enable */
+	reg_write(GPP_DATA_OUT_EN_REG(0), DS414_GPP_OUT_ENA_LOW);
+	reg_write(GPP_DATA_OUT_EN_REG(1), DS414_GPP_OUT_ENA_MID);
+	reg_write(GPP_DATA_OUT_EN_REG(2), DS414_GPP_OUT_ENA_HIGH);
+
+	for (i = 0; i < ARRAY_SIZE(ds414_mpp_control); i++)
+		reg_write(MPP_CONTROL_REG(i), ds414_mpp_control[i]);
+
+	return 0;
+}
+
+int board_init(void)
+{
+	u32 pwr_mng_ctrl_reg;
+
+	/* adress of boot parameters */
+	gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
+
+	/* gate unused clocks */
+	/* Note: disabling unused PCIe lanes will hang PCI bus scan */
+	pwr_mng_ctrl_reg = reg_read(POWER_MNG_CTRL_REG);
+	pwr_mng_ctrl_reg &= ~(BIT(0));				/* Audio */
+	pwr_mng_ctrl_reg &= ~(BIT(1) | BIT(2));			/* GE3, GE2 */
+	//pwr_mng_ctrl_reg &= ~(BIT(10) | BIT(11) | BIT(12));	/* PCIe11 - PCIe13 */
+	pwr_mng_ctrl_reg &= ~(BIT(14) | BIT(15));		/* SATA0 link and core */
+	pwr_mng_ctrl_reg &= ~(BIT(16));				/* LCD */
+	pwr_mng_ctrl_reg &= ~(BIT(17));				/* SDIO */
+	pwr_mng_ctrl_reg &= ~(BIT(19) | BIT(20));		/* USB1 and USB2 */
+	//pwr_mng_ctrl_reg &= ~(BIT(26) | BIT(27));		/* PCIe20 and PCIe30 */
+	pwr_mng_ctrl_reg &= ~(BIT(29) | BIT(30));		/* SATA1 link and core */
+	reg_write(POWER_MNG_CTRL_REG, pwr_mng_ctrl_reg);
+
+	return 0;
+}
+
+int checkboard(void)
+{
+	puts("Board: DS414\n");
+
+	return 0;
+}
diff --git a/board/Synology/ds414/kwbimage.cfg b/board/Synology/ds414/kwbimage.cfg
new file mode 100644
index 0000000..1f748db
--- /dev/null
+++ b/board/Synology/ds414/kwbimage.cfg
@@ -0,0 +1,12 @@
+#
+# Copyright (C) 2014 Stefan Roese <sr@denx.de>
+#
+
+# 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
diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
new file mode 100644
index 0000000..4c3c1df
--- /dev/null
+++ b/configs/ds414_defconfig
@@ -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
diff --git a/include/configs/ds414.h b/include/configs/ds414.h
new file mode 100644
index 0000000..8148571
--- /dev/null
+++ b/include/configs/ds414.h
@@ -0,0 +1,164 @@
+/*
+ * Copyright (C) 2014 Stefan Roese <sr@denx.de>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef _CONFIG_SYNOLOGY_DS414_H
+#define _CONFIG_SYNOLOGY_DS414_H
+
+/*
+ * High Level Configuration Options (easy to change)
+ */
+#define CONFIG_ARMADA_XP		/* SOC Family Name */
+#define CONFIG_MV78230			/* SoC Version */
+#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */
+#define CONFIG_DISPLAY_BOARDINFO_LATE
+
+/*
+ * TEXT_BASE needs to be below 16MiB, since this area is scrubbed
+ * for DDR ECC byte filling in the SPL before loading the main
+ * U-Boot into it.
+ */
+#define	CONFIG_SYS_TEXT_BASE	0x00800000
+#define CONFIG_SYS_TCLK		250000000	/* 250MHz */
+
+/*
+ * Commands configuration
+ */
+#define CONFIG_SYS_NO_FLASH		/* Declare no flash (NOR/SPI) */
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_ENV
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
+#define CONFIG_CMD_TFTPPUT
+#define CONFIG_CMD_TIME
+#define CONFIG_CMD_USB
+
+/* I2C */
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MVTWSI
+#define CONFIG_I2C_MVTWSI_BASE0		MVEBU_TWSI_BASE
+#define CONFIG_SYS_I2C_SLAVE		0x0
+#define CONFIG_SYS_I2C_SPEED		100000
+
+/* SPI NOR flash default params, used by sf commands */
+#define CONFIG_SF_DEFAULT_SPEED		1000000
+#define CONFIG_SF_DEFAULT_MODE		SPI_MODE_3
+
+/* Environment in SPI NOR flash */
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_OFFSET		0x7E0000   /* RedBoot config partition in DTS */
+#define CONFIG_ENV_SIZE			(64 << 10) /* 64KiB */
+#define CONFIG_ENV_SECT_SIZE		(64 << 10) /* 64KiB sectors */
+
+#define CONFIG_PHY_MARVELL		/* there is a marvell phy */
+#define CONFIG_PHY_ADDR			{ 0x1, 0x0 }
+#define CONFIG_SYS_NETA_INTERFACE_TYPE	PHY_INTERFACE_MODE_RGMII
+
+#define CONFIG_SYS_ALT_MEMTEST
+
+/* PCIe support */
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PCI
+#define CONFIG_CMD_PCI
+#define CONFIG_CMD_PCI_ENUM
+#define CONFIG_PCI_MVEBU
+#define CONFIG_PCI_SCAN_SHOW
+#endif
+
+/* USB/EHCI/XHCI configuration */
+
+/* FIXME: broken XHCI support
+ * Below defines should enable support for the two rear USB3 ports. Sadly, this
+ * does not work because:
+ * - xhci-pci seems not to support DM_USB, so with that enabled it is not
+ *   found. To workaround, comment out CONFIG_DM_USB define.
+ * - USB init fails, controller seems not to respond in time */
+#if 0
+#define CONFIG_DM_USB
+#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
+#define CONFIG_USB_XHCI
+#define CONFIG_USB_XHCI_PCI
+#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
+#endif
+
+#if !defined(CONFIG_USB_XHCI) || defined(CONFIG_DM_USB)
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MARVELL
+#define CONFIG_EHCI_IS_TDI
+#endif
+
+/* why is this only defined in mv-common.h if CONFIG_DM is undefined? */
+#define CONFIG_USB_STORAGE
+#define CONFIG_DOS_PARTITION
+#define CONFIG_ISO_PARTITION
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_SYS_MVFS
+
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
+#include "mv-common.h"
+
+/*
+ * Memory layout while starting into the bin_hdr via the
+ * BootROM:
+ *
+ * 0x4000.4000 - 0x4003.4000	headers space (192KiB)
+ * 0x4000.4030			bin_hdr start address
+ * 0x4003.4000 - 0x4004.7c00	BootROM memory allocations (15KiB)
+ * 0x4007.fffc			BootROM stack top
+ *
+ * The address space between 0x4007.fffc and 0x400f.fff is not locked in
+ * L2 cache thus cannot be used.
+ */
+
+/* SPL */
+/* Defines for SPL */
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_TEXT_BASE		0x40004030
+#define CONFIG_SPL_MAX_SIZE		((128 << 10) - 0x4030)
+
+#define CONFIG_SPL_BSS_START_ADDR	(0x40000000 + (128 << 10))
+#define CONFIG_SPL_BSS_MAX_SIZE		(16 << 10)
+
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SYS_MALLOC_SIMPLE
+#endif
+
+#define CONFIG_SPL_STACK		(0x40000000 + ((192 - 16) << 10))
+#define CONFIG_SPL_BOOTROM_SAVE		(CONFIG_SPL_STACK + 4)
+
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+
+/* SPL related SPI defines */
+#define CONFIG_SPL_SPI_SUPPORT
+#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#define CONFIG_SPL_SPI_LOAD
+#define CONFIG_SPL_SPI_BUS		0
+#define CONFIG_SPL_SPI_CS		0
+#define CONFIG_SYS_SPI_U_BOOT_OFFS	0x24000
+
+/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
+#define CONFIG_SYS_MVEBU_DDR_AXP
+#define MV_DDR_32BIT
+
+/* Use random ethernet address if not configured */
+#define CONFIG_LIB_RAND
+#define CONFIG_NET_RANDOM_ETHADDR
+
+/* Default Environment */
+#define CONFIG_BOOTCOMMAND	"sf read ${loadaddr} 0xd0000 0x700000; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200"
+#define CONFIG_LOADADDR		0x80000
+#undef CONFIG_PREBOOT		/* override preboot for USB and SPI flash init */
+#define CONFIG_PREBOOT		"usb start; sf probe"
+
+#endif /* _CONFIG_SYNOLOGY_DS414_H */
-- 
2.5.3

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Stefan Roese]

Hi Phil,

I've consolidated a bit of the Armada XP / 38x defines and
Kconfig options just very recently. Please take a look at
these two patches from yesterday:

http://patchwork.ozlabs.org/patch/559579/
http://patchwork.ozlabs.org/patch/559580/

It would be great if you could base your DS414 support on
top of these as well (sorry, I missed adding you on CC for these
patches). It should fairly easy and make things clearer (e.g.
CONFIG_ARMADA_XP only defined on AXP devices).

I could also add a new git branch available, with the latest
versions of all the mvebu related patches applied. Just let
me know if this would help.

A few comments below...

On 22.12.2015 00:25, Phil Sutter wrote:
> 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.

Yes, this is probably not worth the effort.

> Porting sata_mv from Linux exceeded my brain's
> capacities. :(

Heh. ;)

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

This is something that should be fixed. Linux should be able to
use all devices without any bootloader interference. So it might
be, that some USB related configuration is missing here. Perhaps
in the USB PHY (setup setup_usb_phys in cpu.c).

Does this work in Linux when the original U-Boot is used?

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

Right. Patches welcome. ;)

> 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.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>   arch/arm/Kconfig                                   |   1 +
>   arch/arm/dts/Makefile                              |   2 +
>   arch/arm/dts/armada-xp-synology-ds414.dts          | 337 +++++++++++++++++++++
>   arch/arm/mach-mvebu/Kconfig                        |   3 +
>   arch/arm/mach-mvebu/serdes/axp/board_env_spec.h    |   5 +-
>   .../arm/mach-mvebu/serdes/axp/high_speed_env_lib.c |   3 +
>   board/Synology/ds414/Kconfig                       |  12 +
>   board/Synology/ds414/Makefile                      |   1 +
>   board/Synology/ds414/ds414.c                       | 173 +++++++++++
>   board/Synology/ds414/kwbimage.cfg                  |  12 +
>   configs/ds414_defconfig                            |  18 ++
>   include/configs/ds414.h                            | 164 ++++++++++
>   12 files changed, 729 insertions(+), 2 deletions(-)
>   create mode 100644 arch/arm/dts/armada-xp-synology-ds414.dts
>   create mode 100644 board/Synology/ds414/Kconfig
>   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
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 867303a..96c3a7c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -813,6 +813,7 @@ source "board/hisilicon/hikey/Kconfig"
>   source "board/imx31_phycore/Kconfig"
>   source "board/isee/igep0033/Kconfig"
>   source "board/maxbcm/Kconfig"
> +source "board/Synology/ds414/Kconfig"
>   source "board/mpl/vcma9/Kconfig"
>   source "board/olimex/mx23_olinuxino/Kconfig"
>   source "board/phytec/pcm051/Kconfig"
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 6e2a95f..26fd2f8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -53,6 +53,8 @@ dtb-$(CONFIG_ARCH_MVEBU) +=			\
>   	armada-xp-gp.dtb			\
>   	armada-xp-maxbcm.dtb
>
> +dtb-$(CONFIG_TARGET_DS414) += armada-xp-synology-ds414.dtb
> +

Please add it to the dtb-$(CONFIG_ARCH_MVEBU) list, as all Armada
board do.

>   dtb-$(CONFIG_ARCH_UNIPHIER) += \
>   	uniphier-ph1-ld4-ref.dtb \
>   	uniphier-ph1-ld6b-ref.dtb \
> diff --git a/arch/arm/dts/armada-xp-synology-ds414.dts b/arch/arm/dts/armada-xp-synology-ds414.dts
> new file mode 100644
> index 0000000..0a60ddf
> --- /dev/null
> +++ b/arch/arm/dts/armada-xp-synology-ds414.dts
> @@ -0,0 +1,337 @@
> +/*
> + * Device Tree file for Synology DS414
> + *
> + * Copyright (C) 2014, Arnaud EBALARD <arno@natisbad.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + * Note: this Device Tree assumes that the bootloader has remapped the
> + * internal registers to 0xf1000000 (instead of the old 0xd0000000).
> + * The 0xf1000000 is the default used by the recent, DT-capable, U-Boot
> + * bootloaders provided by Marvell. It is used in recent versions of
> + * DSM software provided by Synology. Nonetheless, some earlier boards
> + * were delivered with an older version of u-boot that left internal
> + * registers mapped at 0xd0000000. If you have such a device you will
> + * not be able to directly boot a kernel based on this Device Tree. In
> + * that case, the preferred solution is to update your bootloader (e.g.
> + * by upgrading to latest version of DSM, or building a new one and
> + * installing it from u-boot prompt) or adjust the Devive Tree
> + * (s/0xf1000000/0xd0000000/ in 'ranges' below).
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include "armada-xp-mv78230.dtsi"
> +
> +/ {
> +	model = "Synology DS414";
> +	compatible = "synology,ds414", "marvell,armadaxp-mv78230",
> +		     "marvell,armadaxp", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +		stdout-path = &uart0;
> +	};
> +
> +	aliases {
> +		spi0 = &spi0;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0 0x00000000 0 0x40000000>; /* 1GB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
> +
> +		pcie-controller {
> +			status = "okay";
> +
> +			/*
> +			 * Connected to Marvell 88SX7042 SATA-II controller
> +			 * handling the four disks.
> +			 */
> +			pcie at 1,0 {
> +				/* Port 0, Lane 0 */
> +				status = "okay";
> +			};
> +
> +			/*
> +			 * Connected to EtronTech EJ168A XHCI controller
> +			 * providing the two rear USB 3.0 ports.
> +			 */
> +			pcie at 5,0 {
> +				/* Port 1, Lane 0 */
> +				status = "okay";
> +			};
> +		};
> +
> +		internal-regs {
> +
> +			/* RTC is provided by Seiko S-35390A below */
> +			rtc at 10300 {
> +				status = "disabled";
> +			};
> +
> +			spi0: spi at 10600 {
> +				status = "okay";
> +				u-boot,dm-pre-reloc;
> +
> +				spi-flash at 0 {
> +					u-boot,dm-pre-reloc;
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +					compatible = "micron,n25q064";
> +					reg = <0>; /* Chip select 0 */
> +					spi-max-frequency = <20000000>;
> +
> +					/*
> +					 * Warning!
> +					 *
> +					 * Synology u-boot uses its compiled-in environment
> +					 * and it seems Synology did not care to change u-boot
> +					 * default configuration in order to allow saving a
> +					 * modified environment at a sensible location. So,
> +					 * if you do a 'saveenv' under u-boot, your modified
> +					 * environment will be saved at 1MB after the start
> +					 * of the flash, i.e. in the middle of the uImage.
> +					 * For that reason, it is strongly advised not to
> +					 * change the default environment, unless you know
> +					 * what you are doing.
> +					 */
> +					partition at 00000000 { /* u-boot */
> +						label = "RedBoot";
> +						reg = <0x00000000 0x000d0000>; /* 832KB */
> +					};
> +
> +					partition at 000c0000 { /* uImage */
> +						label = "zImage";
> +						reg = <0x000d0000 0x002d0000>; /* 2880KB */
> +					};
> +
> +					partition at 003a0000 { /* uInitramfs */
> +						label = "rd.gz";
> +						reg = <0x003a0000 0x00430000>; /* 4250KB */
> +					};
> +
> +					partition at 007d0000 { /* MAC address and serial number */
> +						label = "vendor";
> +						reg = <0x007d0000 0x00010000>; /* 64KB */
> +					};
> +
> +					partition at 007e0000 {
> +						label = "RedBoot config";
> +						reg = <0x007e0000 0x00010000>; /* 64KB */
> +					};
> +
> +					partition at 007f0000 {
> +						label = "FIS directory";
> +						reg = <0x007f0000 0x00010000>; /* 64KB */
> +					};
> +				};
> +			};
> +
> +			i2c at 11000 {
> +				clock-frequency = <400000>;
> +				status = "okay";
> +
> +				s35390a: s35390a at 30 {
> +					 compatible = "sii,s35390a";
> +					 reg = <0x30>;
> +				};
> +			};
> +
> +			/* Connected to a header on device's PCB. This
> +			 * provides the main console for the device.
> +			 *
> +			 * Warning: the device may not boot with a 3.3V
> +			 * USB-serial converter connected when the power
> +			 * button is pressed. The converter needs to be
> +			 * connected a few seconds after pressing the
> +			 * power button. This is possibly due to UART0_TXD
> +			 * pin being sampled at reset (bit 0 of SAR).
> +			 */
> +			serial at 12000 {
> +				status = "okay";
> +				u-boot,dm-pre-reloc;
> +			};
> +
> +			/* Connected to a Microchip PIC16F883 for power control */
> +			serial at 12100 {
> +				status = "okay";
> +			};
> +
> +			poweroff at 12100 {
> +				compatible = "synology,power-off";
> +				reg = <0x12100 0x100>;
> +				clocks = <&coreclk 0>;
> +			};
> +
> +			/* Front USB 2.0 port */
> +			usb at 50000 {
> +				status = "okay";
> +			};
> +
> +			mdio {
> +				phy0: ethernet-phy at 0 { /* Marvell 88E1512 */
> +					reg = <0>;
> +				};
> +
> +				phy1: ethernet-phy at 1 { /* Marvell 88E1512 */
> +					reg = <1>;
> +				};
> +			};
> +
> +			ethernet at 70000 {
> +				status = "okay";
> +				pinctrl-0 = <&ge0_rgmii_pins>;
> +				pinctrl-names = "default";
> +				phy = <&phy1>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			ethernet at 74000 {
> +				pinctrl-0 = <&ge1_rgmii_pins>;
> +				pinctrl-names = "default";
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +		};
> +	};
> +
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		pinctrl-0 = <&sata1_pwr_pin &sata2_pwr_pin
> +			     &sata3_pwr_pin &sata4_pwr_pin>;
> +		pinctrl-names = "default";
> +
> +		sata1_regulator: sata1-regulator {
> +			compatible = "regulator-fixed";
> +			reg = <1>;
> +			regulator-name = "SATA1 Power";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			startup-delay-us = <2000000>;
> +			enable-active-high;
> +			regulator-always-on;
> +			regulator-boot-on;
> +			gpio = <&gpio1 10 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		sata2_regulator: sata2-regulator {
> +			compatible = "regulator-fixed";
> +			reg = <2>;
> +			regulator-name = "SATA2 Power";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			startup-delay-us = <4000000>;
> +			enable-active-high;
> +			regulator-always-on;
> +			regulator-boot-on;
> +			gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		sata3_regulator: sata3-regulator {
> +			compatible = "regulator-fixed";
> +			reg = <3>;
> +			regulator-name = "SATA3 Power";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			startup-delay-us = <6000000>;
> +			enable-active-high;
> +			regulator-always-on;
> +			regulator-boot-on;
> +			gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		sata4_regulator: sata4-regulator {
> +			compatible = "regulator-fixed";
> +			reg = <4>;
> +			regulator-name = "SATA4 Power";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			startup-delay-us = <8000000>;
> +			enable-active-high;
> +			regulator-always-on;
> +			regulator-boot-on;
> +			gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +};
> +
> +&pinctrl {
> +	sata1_pwr_pin: sata1-pwr-pin {
> +		marvell,pins = "mpp42";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata2_pwr_pin: sata2-pwr-pin {
> +		marvell,pins = "mpp44";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata3_pwr_pin: sata3-pwr-pin {
> +		marvell,pins = "mpp45";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata4_pwr_pin: sata4-pwr-pin {
> +		marvell,pins = "mpp46";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata1_pres_pin: sata1-pres-pin {
> +		marvell,pins = "mpp34";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata2_pres_pin: sata2-pres-pin {
> +		marvell,pins = "mpp35";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata3_pres_pin: sata3-pres-pin {
> +		marvell,pins = "mpp40";
> +		marvell,function = "gpio";
> +	};
> +
> +	sata4_pres_pin: sata4-pres-pin {
> +		marvell,pins = "mpp41";
> +		marvell,function = "gpio";
> +	};
> +
> +	syno_id_bit0_pin: syno-id-bit0-pin {
> +		marvell,pins = "mpp26";
> +		marvell,function = "gpio";
> +	};
> +
> +	syno_id_bit1_pin: syno-id-bit1-pin {
> +		marvell,pins = "mpp28";
> +		marvell,function = "gpio";
> +	};
> +
> +	syno_id_bit2_pin: syno-id-bit2-pin {
> +		marvell,pins = "mpp29";
> +		marvell,function = "gpio";
> +	};
> +
> +	fan1_alarm_pin: fan1-alarm-pin {
> +		marvell,pins = "mpp33";
> +		marvell,function = "gpio";
> +	};
> +
> +	fan2_alarm_pin: fan2-alarm-pin {
> +		marvell,pins = "mpp32";
> +		marvell,function = "gpio";
> +	};
> +};
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 82a439e..50fc8ee 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -16,6 +16,9 @@ config TARGET_DB_MV784MP_GP
>   config TARGET_MAXBCM
>   	bool "Support maxbcm"
>
> +config TARGET_DS414
> +	bool "Support Synology DS414"
> +
>   endchoice
>
>   config SYS_SOC
> diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> index f00f327..3dca6a1 100644
> --- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> +++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> @@ -43,8 +43,9 @@
>   #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
>   #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
> +#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
> +#define INVALID_BOARD_ID		0xFFFFFFFF

Do you really need these changes here?

>
>   /* Sample at Reset */
>   #define MPP_SAMPLE_AT_RESET(id)		(0x18230 + (id * 4))
> diff --git a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> index 0e2a905..a789a60 100644
> --- a/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> +++ b/arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c
> @@ -66,6 +66,8 @@ static u32 board_id_get(void)
>   	return DB_784MP_GP_ID;
>   #elif defined(CONFIG_RD_78460_CUSTOMER)
>   	return RD_78460_CUSTOMER_ID;
> +#elif defined(CONFIG_SYNOLOGY_DS414)
> +	return SYNOLOGY_DS414_ID;
>   #else
>   	/*
>   	 * Return 0 here for custom board as this should not be used
> @@ -262,6 +264,7 @@ int serdes_phy_config(void)
>   	case RD_78460_SERVER_ID:
>   	case RD_78460_SERVER_REV2_ID:
>   	case DB_78X60_PCAC_ID:
> +	case SYNOLOGY_DS414_ID:
>   		satr11 = (0x1 << 1) | 1;
>   		break;
>   	case FPGA_88F78XX0_ID:
> diff --git a/board/Synology/ds414/Kconfig b/board/Synology/ds414/Kconfig
> new file mode 100644
> index 0000000..4d30852
> --- /dev/null
> +++ b/board/Synology/ds414/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_DS414
> +
> +config SYS_BOARD
> +	default "ds414"
> +
> +config SYS_VENDOR
> +	default "Synology"
> +
> +config SYS_CONFIG_NAME
> +	default "ds414"
> +
> +endif

Please see above. All this is now done in the common Kconfig file.

> diff --git a/board/Synology/ds414/Makefile b/board/Synology/ds414/Makefile
> new file mode 100644
> index 0000000..aad8c43
> --- /dev/null
> +++ b/board/Synology/ds414/Makefile
> @@ -0,0 +1 @@
> +obj-y :=	ds414.o
> diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
> new file mode 100644
> index 0000000..88252f6
> --- /dev/null
> +++ b/board/Synology/ds414/ds414.c
> @@ -0,0 +1,173 @@
> +#include <common.h>
> +#include <miiphy.h>
> +#include <asm/io.h>
> +#include <asm/arch/cpu.h>
> +#include <asm/arch/soc.h>
> +#include <linux/mbus.h>
> +
> +#include "../drivers/ddr/marvell/axp/ddr3_hw_training.h"
> +#include "../arch/arm/mach-mvebu/serdes/axp/high_speed_env_spec.h"
> +#include "../arch/arm/mach-mvebu/serdes/axp/board_env_spec.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* GPP and MPP settings as found in mvBoardEnvSpec.c of Synology's U-Boot */
> +
> +#define DS414_GPP_OUT_VAL_LOW		(BIT(25) | BIT(30))
> +#define DS414_GPP_OUT_VAL_MID		(BIT(10) | BIT(15))
> +#define DS414_GPP_OUT_VAL_HIGH		(0)
> +
> +#define DS414_GPP_OUT_POL_LOW		(0)
> +#define DS414_GPP_OUT_POL_MID		(0)
> +#define DS414_GPP_OUT_POL_HIGH		(0)
> +
> +#define DS414_GPP_OUT_ENA_LOW		(~(BIT(25) | BIT(30)))
> +#define DS414_GPP_OUT_ENA_MID		(~(BIT(10) | BIT(12) | \
> +					   BIT(13) | BIT(14) | BIT(15)))
> +#define DS414_GPP_OUT_ENA_HIGH		(~0)
> +
> +static const u32 ds414_mpp_control[] = {
> +	0x11111111,
> +	0x22221111,
> +	0x22222222,
> +	0x00000000,
> +	0x11110000,
> +	0x00004000,
> +	0x00000000,
> +	0x00000000,
> +	0x00000000
> +};
> +
> +/* DDR3 static MC configuration */
> +
> +/* 1G_v1 (4x2Gbits) adapted by DS414 */
> +MV_DRAM_MC_INIT syno_ddr3_b0_667_1g_v1[MV_MAX_DDR3_STATIC_SIZE] = {
> +	{0x00001400, 0x73014A28},	/*DDR SDRAM Configuration Register */
> +	{0x00001404, 0x30000800},	/*Dunit Control Low Register */
> +	{0x00001408, 0x44148887},	/*DDR SDRAM Timing (Low) Register */
> +	/* {0x0000140C, 0x38000C6}, */	/*DDR SDRAM Timing (High) Register */
> +	{0x0000140C, 0x3AD83FEA},	/*DDR SDRAM Timing (High) Register */

Why do you have commented-out values here? Its generally not allowed
to add "dead code". So please either add it in some comment, so that
it can be identified as a important comment. Or remove it completely.

> +
> +	{0x00001410, 0x14000000},	/*DDR SDRAM Address Control Register */
> +
> +	{0x00001414, 0x00000000},	/*DDR SDRAM Open Pages Control Register */
> +	{0x00001418, 0x00000e00},	/*DDR SDRAM Operation Register */
> +	{0x00001420, 0x00000004},	/*DDR SDRAM Extended Mode Register */
> +	{0x00001424, 0x0000F3FF},	/*Dunit Control High Register */
> +	{0x00001428, 0x000F8830},	/*Dunit Control High Register */
> +	{0x0000142C, 0x054C36F4},	/*Dunit Control High Register */
> +	{0x0000147C, 0x0000C671},
> +
> +	{0x000014a0, 0x00000001},
> +	{0x000014a8, 0x00000100},	/*2:1 */
> +	{0x00020220, 0x00000006},
> +
> +	{0x00001494, 0x00010000},	/*DDR SDRAM ODT Control (Low) Register */
> +	{0x00001498, 0x00000000},	/*DDR SDRAM ODT Control (High) Register */
> +	{0x0000149C, 0x00000001},	/*DDR Dunit ODT Control Register */
> +
> +	{0x000014C0, 0x192424C9},	/* DRAM address and Control Driving Strenght  */
> +	{0x000014C4, 0x0AAA24C9},	/* DRAM Data and DQS Driving Strenght  */
> +
> +	{0x000200e8, 0x3FFF0E01},	/* DO NOT Modify - Open Mbus Window - 2G - Mbus is required for the training sequence*/
> +	{0x00020184, 0x3FFFFFE0},	/* DO NOT Modify - Close fast path Window to - 2G */
> +
> +	{0x0001504, 0x3FFFFFE1},	/* CS0 Size */
> +	{0x000150C, 0x00000000},	/* CS1 Size */
> +	{0x0001514, 0x00000000},	/* CS2 Size */
> +	{0x000151C, 0x00000000},	/* CS3 Size */
> +
> +	/*	{0x00001524, 0x0000C800},  */

Again, same comment about dead code.

> +	{0x00001538, 0x00000009},	/*Read Data Sample Delays Register */
> +	{0x0000153C, 0x00000009},	/*Read Data Ready Delay Register */
> +
> +	{0x000015D0, 0x00000650},	/*MR0 */
> +	{0x000015D4, 0x00000044},	/*MR1 */
> +	{0x000015D8, 0x00000010},	/*MR2 */
> +	{0x000015DC, 0x00000000},	/*MR3 */
> +
> +	{0x000015E4, 0x00203c18},	/*ZQC Configuration Register */
> +	{0x000015EC, 0xF800A225},	/*DDR PHY */
> +
> +	{0x0, 0x0}
> +};
> +
> +MV_DRAM_MODES ds414_ddr_modes[MV_DDR3_MODES_NUMBER] = {
> +	{"ds414_1333-667",   0x3, 0x5, 0x0, A0, syno_ddr3_b0_667_1g_v1,  NULL},
> +};
> +
> +extern MV_SERDES_CHANGE_M_PHY serdes_change_m_phy[];
> +
> +MV_BIN_SERDES_CFG ds414_serdes_cfg[] = {
> +	{ MV_PEX_ROOT_COMPLEX, 0x02011111, 0x00000000,
> +	  { PEX_BUS_MODE_X4, PEX_BUS_MODE_X1, PEX_BUS_DISABLED,
> +	    PEX_BUS_DISABLED },
> +	  0x0040, serdes_change_m_phy
> +	}
> +};
> +
> +MV_DRAM_MODES *ddr3_get_static_ddr_mode(void)
> +{
> +	return &ds414_ddr_modes[0];
> +}
> +
> +MV_BIN_SERDES_CFG *board_serdes_cfg_get(u8 pex_mode)
> +{
> +	return &ds414_serdes_cfg[0];
> +}
> +
> +int board_early_init_f(void)
> +{
> +	int i;
> +
> +	/* Set GPP Out value */
> +	reg_write(GPP_DATA_OUT_REG(0), DS414_GPP_OUT_VAL_LOW);
> +	reg_write(GPP_DATA_OUT_REG(1), DS414_GPP_OUT_VAL_MID);
> +	reg_write(GPP_DATA_OUT_REG(2), DS414_GPP_OUT_VAL_HIGH);
> +
> +	/* set GPP polarity */
> +	reg_write(GPP_DATA_IN_POL_REG(0), DS414_GPP_OUT_POL_LOW);
> +	reg_write(GPP_DATA_IN_POL_REG(1), DS414_GPP_OUT_POL_MID);
> +	reg_write(GPP_DATA_IN_POL_REG(2), DS414_GPP_OUT_POL_HIGH);
> +
> +	/* Set GPP Out Enable */
> +	reg_write(GPP_DATA_OUT_EN_REG(0), DS414_GPP_OUT_ENA_LOW);
> +	reg_write(GPP_DATA_OUT_EN_REG(1), DS414_GPP_OUT_ENA_MID);
> +	reg_write(GPP_DATA_OUT_EN_REG(2), DS414_GPP_OUT_ENA_HIGH);
> +
> +	for (i = 0; i < ARRAY_SIZE(ds414_mpp_control); i++)
> +		reg_write(MPP_CONTROL_REG(i), ds414_mpp_control[i]);
> +
> +	return 0;
> +}
> +
> +int board_init(void)
> +{
> +	u32 pwr_mng_ctrl_reg;
> +
> +	/* adress of boot parameters */
> +	gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
> +
> +	/* gate unused clocks */
> +	/* Note: disabling unused PCIe lanes will hang PCI bus scan */
> +	pwr_mng_ctrl_reg = reg_read(POWER_MNG_CTRL_REG);
> +	pwr_mng_ctrl_reg &= ~(BIT(0));				/* Audio */
> +	pwr_mng_ctrl_reg &= ~(BIT(1) | BIT(2));			/* GE3, GE2 */
> +	//pwr_mng_ctrl_reg &= ~(BIT(10) | BIT(11) | BIT(12));	/* PCIe11 - PCIe13 */

C++ style comments are not allowed, sorry. And again the same comment
about dead code.

> +	pwr_mng_ctrl_reg &= ~(BIT(14) | BIT(15));		/* SATA0 link and core */
> +	pwr_mng_ctrl_reg &= ~(BIT(16));				/* LCD */
> +	pwr_mng_ctrl_reg &= ~(BIT(17));				/* SDIO */
> +	pwr_mng_ctrl_reg &= ~(BIT(19) | BIT(20));		/* USB1 and USB2 */
> +	//pwr_mng_ctrl_reg &= ~(BIT(26) | BIT(27));		/* PCIe20 and PCIe30 */
> +	pwr_mng_ctrl_reg &= ~(BIT(29) | BIT(30));		/* SATA1 link and core */
> +	reg_write(POWER_MNG_CTRL_REG, pwr_mng_ctrl_reg);
> +
> +	return 0;
> +}
> +
> +int checkboard(void)
> +{
> +	puts("Board: DS414\n");
> +
> +	return 0;
> +}
> diff --git a/board/Synology/ds414/kwbimage.cfg b/board/Synology/ds414/kwbimage.cfg
> new file mode 100644
> index 0000000..1f748db
> --- /dev/null
> +++ b/board/Synology/ds414/kwbimage.cfg
> @@ -0,0 +1,12 @@
> +#
> +# Copyright (C) 2014 Stefan Roese <sr@denx.de>
> +#
> +
> +# 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
> diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
> new file mode 100644
> index 0000000..4c3c1df
> --- /dev/null
> +++ b/configs/ds414_defconfig
> @@ -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
> diff --git a/include/configs/ds414.h b/include/configs/ds414.h
> new file mode 100644
> index 0000000..8148571
> --- /dev/null
> +++ b/include/configs/ds414.h
> @@ -0,0 +1,164 @@
> +/*
> + * Copyright (C) 2014 Stefan Roese <sr@denx.de>
> + *
> + * SPDX-License-Identifier:	GPL-2.0+
> + */
> +
> +#ifndef _CONFIG_SYNOLOGY_DS414_H
> +#define _CONFIG_SYNOLOGY_DS414_H
> +
> +/*
> + * High Level Configuration Options (easy to change)
> + */
> +#define CONFIG_ARMADA_XP		/* SOC Family Name */

This will not be needed any more with the 2 patches I reference
above. The SoC is selected via Kconfig then.

> +#define CONFIG_MV78230			/* SoC Version */
> +#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */
> +#define CONFIG_DISPLAY_BOARDINFO_LATE
> +
> +/*
> + * TEXT_BASE needs to be below 16MiB, since this area is scrubbed
> + * for DDR ECC byte filling in the SPL before loading the main
> + * U-Boot into it.
> + */
> +#define	CONFIG_SYS_TEXT_BASE	0x00800000
> +#define CONFIG_SYS_TCLK		250000000	/* 250MHz */
> +
> +/*
> + * Commands configuration
> + */
> +#define CONFIG_SYS_NO_FLASH		/* Declare no flash (NOR/SPI) */
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_ENV
> +#define CONFIG_CMD_I2C
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_CMD_TFTPPUT
> +#define CONFIG_CMD_TIME
> +#define CONFIG_CMD_USB
> +
> +/* I2C */
> +#define CONFIG_SYS_I2C
> +#define CONFIG_SYS_I2C_MVTWSI
> +#define CONFIG_I2C_MVTWSI_BASE0		MVEBU_TWSI_BASE
> +#define CONFIG_SYS_I2C_SLAVE		0x0
> +#define CONFIG_SYS_I2C_SPEED		100000
> +
> +/* SPI NOR flash default params, used by sf commands */
> +#define CONFIG_SF_DEFAULT_SPEED		1000000
> +#define CONFIG_SF_DEFAULT_MODE		SPI_MODE_3
> +
> +/* Environment in SPI NOR flash */
> +#define CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_OFFSET		0x7E0000   /* RedBoot config partition in DTS */
> +#define CONFIG_ENV_SIZE			(64 << 10) /* 64KiB */
> +#define CONFIG_ENV_SECT_SIZE		(64 << 10) /* 64KiB sectors */
> +
> +#define CONFIG_PHY_MARVELL		/* there is a marvell phy */
> +#define CONFIG_PHY_ADDR			{ 0x1, 0x0 }
> +#define CONFIG_SYS_NETA_INTERFACE_TYPE	PHY_INTERFACE_MODE_RGMII
> +
> +#define CONFIG_SYS_ALT_MEMTEST
> +
> +/* PCIe support */
> +#ifndef CONFIG_SPL_BUILD
> +#define CONFIG_PCI
> +#define CONFIG_CMD_PCI
> +#define CONFIG_CMD_PCI_ENUM
> +#define CONFIG_PCI_MVEBU
> +#define CONFIG_PCI_SCAN_SHOW
> +#endif
> +
> +/* USB/EHCI/XHCI configuration */
> +
> +/* FIXME: broken XHCI support
> + * Below defines should enable support for the two rear USB3 ports. Sadly, this
> + * does not work because:
> + * - xhci-pci seems not to support DM_USB, so with that enabled it is not
> + *   found. To workaround, comment out CONFIG_DM_USB define.
> + * - USB init fails, controller seems not to respond in time */
> +#if 0
> +#define CONFIG_DM_USB
> +#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
> +#define CONFIG_USB_XHCI
> +#define CONFIG_USB_XHCI_PCI
> +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
> +#endif
> +
> +#if !defined(CONFIG_USB_XHCI) || defined(CONFIG_DM_USB)
> +#define CONFIG_USB_EHCI
> +#define CONFIG_USB_EHCI_MARVELL
> +#define CONFIG_EHCI_IS_TDI
> +#endif
> +
> +/* why is this only defined in mv-common.h if CONFIG_DM is undefined? */
> +#define CONFIG_USB_STORAGE
> +#define CONFIG_DOS_PARTITION
> +#define CONFIG_ISO_PARTITION
> +#define CONFIG_SUPPORT_VFAT
> +#define CONFIG_SYS_MVFS
> +
> +/*
> + * mv-common.h should be defined after CMD configs since it used them
> + * to enable certain macros
> + */
> +#include "mv-common.h"
> +
> +/*
> + * Memory layout while starting into the bin_hdr via the
> + * BootROM:
> + *
> + * 0x4000.4000 - 0x4003.4000	headers space (192KiB)
> + * 0x4000.4030			bin_hdr start address
> + * 0x4003.4000 - 0x4004.7c00	BootROM memory allocations (15KiB)
> + * 0x4007.fffc			BootROM stack top
> + *
> + * The address space between 0x4007.fffc and 0x400f.fff is not locked in
> + * L2 cache thus cannot be used.
> + */
> +
> +/* SPL */
> +/* Defines for SPL */
> +#define CONFIG_SPL_FRAMEWORK
> +#define CONFIG_SPL_TEXT_BASE		0x40004030
> +#define CONFIG_SPL_MAX_SIZE		((128 << 10) - 0x4030)
> +
> +#define CONFIG_SPL_BSS_START_ADDR	(0x40000000 + (128 << 10))
> +#define CONFIG_SPL_BSS_MAX_SIZE		(16 << 10)
> +
> +#ifdef CONFIG_SPL_BUILD
> +#define CONFIG_SYS_MALLOC_SIMPLE
> +#endif
> +
> +#define CONFIG_SPL_STACK		(0x40000000 + ((192 - 16) << 10))
> +#define CONFIG_SPL_BOOTROM_SAVE		(CONFIG_SPL_STACK + 4)
> +
> +#define CONFIG_SPL_LIBCOMMON_SUPPORT
> +#define CONFIG_SPL_LIBGENERIC_SUPPORT
> +#define CONFIG_SPL_SERIAL_SUPPORT
> +#define CONFIG_SPL_I2C_SUPPORT
> +
> +/* SPL related SPI defines */
> +#define CONFIG_SPL_SPI_SUPPORT
> +#define CONFIG_SPL_SPI_FLASH_SUPPORT
> +#define CONFIG_SPL_SPI_LOAD
> +#define CONFIG_SPL_SPI_BUS		0
> +#define CONFIG_SPL_SPI_CS		0
> +#define CONFIG_SYS_SPI_U_BOOT_OFFS	0x24000
> +
> +/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
> +#define CONFIG_SYS_MVEBU_DDR_AXP
> +#define MV_DDR_32BIT

These 2 lines can also be removed with the new patches.

> +/* Use random ethernet address if not configured */
> +#define CONFIG_LIB_RAND
> +#define CONFIG_NET_RANDOM_ETHADDR
> +
> +/* Default Environment */
> +#define CONFIG_BOOTCOMMAND	"sf read ${loadaddr} 0xd0000 0x700000; bootm"
> +#define CONFIG_BOOTARGS		"console=ttyS0,115200"
> +#define CONFIG_LOADADDR		0x80000
> +#undef CONFIG_PREBOOT		/* override preboot for USB and SPI flash init */
> +#define CONFIG_PREBOOT		"usb start; sf probe"
> +
> +#endif /* _CONFIG_SYNOLOGY_DS414_H */
>


Thanks,
Stefan

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Phil Sutter]

Hi,

On Tue, Dec 22, 2015 at 10:05:03AM +0100, Stefan Roese wrote:
> I've consolidated a bit of the Armada XP / 38x defines and
> Kconfig options just very recently. Please take a look at
> these two patches from yesterday:
> 
> http://patchwork.ozlabs.org/patch/559579/
> http://patchwork.ozlabs.org/patch/559580/
> 
> It would be great if you could base your DS414 support on
> top of these as well (sorry, I missed adding you on CC for these
> patches). It should fairly easy and make things clearer (e.g.
> CONFIG_ARMADA_XP only defined on AXP devices).

I see.

> I could also add a new git branch available, with the latest
> versions of all the mvebu related patches applied. Just let
> me know if this would help.

No problem, I just fetched the relevant patches from the list and
applied them locally.

[...]

> > 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.
> 
> Yes, this is probably not worth the effort.

What bothers me is that Synology's patched U-Boot supports it, so I
consider it a regression for users wanting to switch to mainline. And
since there is sata_mv in U-Boot now and Linux's sata_mv simply supports
both the platform device and the various PCI devices, one might think it
should be straightforward to add support to it. But Linux's sata_mv with
it's 4.5k LoC is quite a thing, too.

[...]

> > 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.
> 
> This is something that should be fixed. Linux should be able to
> use all devices without any bootloader interference. So it might
> be, that some USB related configuration is missing here. Perhaps
> in the USB PHY (setup setup_usb_phys in cpu.c).
> 
> Does this work in Linux when the original U-Boot is used?

I will check. Also printing the relevant registers in Linux and
comparing the values in working and broken condition might help.

> > 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.
> 
> Right. Patches welcome. ;)

I actually started, thought it can't be that hard. So far I'm stuck at a
point where enumeration gets just 0xfbfb for both vendor and product
IDs. Looks like a follow-up project to me. :)

[...]

> > diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> > index f00f327..3dca6a1 100644
> > --- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> > +++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> > @@ -43,8 +43,9 @@
> >   #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
> >   #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
> > +#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
> > +#define INVALID_BOARD_ID		0xFFFFFFFF
> 
> Do you really need these changes here?

Sadly, yes. See high_speed_env_lib.c for details: There it is needed by
serdes_phy_config() to get the right satr11 value via board_id_get().
Maybe this should be refactored to always use board_sat_r_get() and the
latter return a static value from a macro which board configs may define
instead of reading from i2c.

[...]

> > +/* DDR3 static MC configuration */
> > +
> > +/* 1G_v1 (4x2Gbits) adapted by DS414 */
> > +MV_DRAM_MC_INIT syno_ddr3_b0_667_1g_v1[MV_MAX_DDR3_STATIC_SIZE] = {
> > +	{0x00001400, 0x73014A28},	/*DDR SDRAM Configuration Register */
> > +	{0x00001404, 0x30000800},	/*Dunit Control Low Register */
> > +	{0x00001408, 0x44148887},	/*DDR SDRAM Timing (Low) Register */
> > +	/* {0x0000140C, 0x38000C6}, */	/*DDR SDRAM Timing (High) Register */
> > +	{0x0000140C, 0x3AD83FEA},	/*DDR SDRAM Timing (High) Register */
> 
> Why do you have commented-out values here? Its generally not allowed
> to add "dead code". So please either add it in some comment, so that
> it can be identified as a important comment. Or remove it completely.

Took that over from Synology's sources (mainly for the sake of
completeness). But you're right, without explanation (which I couldn't
find, either) it's pretty much useless.

[...]

> > +	/* gate unused clocks */
> > +	/* Note: disabling unused PCIe lanes will hang PCI bus scan */
> > +	pwr_mng_ctrl_reg = reg_read(POWER_MNG_CTRL_REG);
> > +	pwr_mng_ctrl_reg &= ~(BIT(0));				/* Audio */
> > +	pwr_mng_ctrl_reg &= ~(BIT(1) | BIT(2));			/* GE3, GE2 */
> > +	//pwr_mng_ctrl_reg &= ~(BIT(10) | BIT(11) | BIT(12));	/* PCIe11 - PCIe13 */
> 
> C++ style comments are not allowed, sorry. And again the same comment
> about dead code.

Ah, yes. Left it there in hopes to solve this PCI enum problem soon
(probably will be when DM_PCI works as that relieves us from doing full
bus scan), will put it into the note above instead.

[...]

> > +/*
> > + * High Level Configuration Options (easy to change)
> > + */
> > +#define CONFIG_ARMADA_XP		/* SOC Family Name */
> 
> This will not be needed any more with the 2 patches I reference
> above. The SoC is selected via Kconfig then.

OK.

> > +#define CONFIG_MV78230			/* SoC Version */
> > +#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */

I will review those as well. Maybe the CONFIG_ARMADA_XP solution could
be implemented for SoC types, too?

[...]

> > +/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
> > +#define CONFIG_SYS_MVEBU_DDR_AXP
> > +#define MV_DDR_32BIT
> 
> These 2 lines can also be removed with the new patches.

OK, CONFIG_SYS_MVEBU_DDR_AXP seems not to be used anymore at all. But
without MV_DDR_32BIT, BUS_WIDTH defaults to 64 which is wrong on DS414.

Thanks, Phil

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Stefan Roese]

Hi Phil,

On 23.12.2015 01:31, Phil Sutter wrote:
> On Tue, Dec 22, 2015 at 10:05:03AM +0100, Stefan Roese wrote:
>> I've consolidated a bit of the Armada XP / 38x defines and
>> Kconfig options just very recently. Please take a look at
>> these two patches from yesterday:
>>
>> http://patchwork.ozlabs.org/patch/559579/
>> http://patchwork.ozlabs.org/patch/559580/
>>
>> It would be great if you could base your DS414 support on
>> top of these as well (sorry, I missed adding you on CC for these
>> patches). It should fairly easy and make things clearer (e.g.
>> CONFIG_ARMADA_XP only defined on AXP devices).
>
> I see.
>
>> I could also add a new git branch available, with the latest
>> versions of all the mvebu related patches applied. Just let
>> me know if this would help.
>
> No problem, I just fetched the relevant patches from the list and
> applied them locally.
>
> [...]
>
>>> 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.
>>
>> Yes, this is probably not worth the effort.
>
> What bothers me is that Synology's patched U-Boot supports it, so I
> consider it a regression for users wanting to switch to mainline. And
> since there is sata_mv in U-Boot now and Linux's sata_mv simply supports
> both the platform device and the various PCI devices, one might think it
> should be straightforward to add support to it. But Linux's sata_mv with
> it's 4.5k LoC is quite a thing, too.
>
> [...]
>
>>> 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.
>>
>> This is something that should be fixed. Linux should be able to
>> use all devices without any bootloader interference. So it might
>> be, that some USB related configuration is missing here. Perhaps
>> in the USB PHY (setup setup_usb_phys in cpu.c).
>>
>> Does this work in Linux when the original U-Boot is used?
>
> I will check. Also printing the relevant registers in Linux and
> comparing the values in working and broken condition might help.

Yes, thanks. Please keep me informed on this.

>>> 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.
>>
>> Right. Patches welcome. ;)
>
> I actually started, thought it can't be that hard. So far I'm stuck at a
> point where enumeration gets just 0xfbfb for both vendor and product
> IDs. Looks like a follow-up project to me. :)

Yes, that would be really great! :)

> [...]
>
>>> diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>> index f00f327..3dca6a1 100644
>>> --- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>> +++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>> @@ -43,8 +43,9 @@
>>>    #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
>>>    #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
>>> +#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
>>> +#define INVALID_BOARD_ID		0xFFFFFFFF
>>
>> Do you really need these changes here?
>
> Sadly, yes. See high_speed_env_lib.c for details: There it is needed by
> serdes_phy_config() to get the right satr11 value via board_id_get().
> Maybe this should be refactored to always use board_sat_r_get() and the
> latter return a static value from a macro which board configs may define
> instead of reading from i2c.

Yes, a refactorization would be good here. One idea is, to provide a
_weak version of board_sat_r_get() in high_speed_env_lib.c used on
all of these Marvell boards with a BOARD_ID. And custom boards, like
your DS414 can provide a board specific version of board_sat_r_get()
overwriting the weak default. And returning the board specific value.
This way, all new custom boards would not have to touch this file
any more.

Could you try to implement it this way?

> [...]
>
>>> +/* DDR3 static MC configuration */
>>> +
>>> +/* 1G_v1 (4x2Gbits) adapted by DS414 */
>>> +MV_DRAM_MC_INIT syno_ddr3_b0_667_1g_v1[MV_MAX_DDR3_STATIC_SIZE] = {
>>> +	{0x00001400, 0x73014A28},	/*DDR SDRAM Configuration Register */
>>> +	{0x00001404, 0x30000800},	/*Dunit Control Low Register */
>>> +	{0x00001408, 0x44148887},	/*DDR SDRAM Timing (Low) Register */
>>> +	/* {0x0000140C, 0x38000C6}, */	/*DDR SDRAM Timing (High) Register */
>>> +	{0x0000140C, 0x3AD83FEA},	/*DDR SDRAM Timing (High) Register */
>>
>> Why do you have commented-out values here? Its generally not allowed
>> to add "dead code". So please either add it in some comment, so that
>> it can be identified as a important comment. Or remove it completely.
>
> Took that over from Synology's sources (mainly for the sake of
> completeness). But you're right, without explanation (which I couldn't
> find, either) it's pretty much useless.
>
> [...]
>
>>> +	/* gate unused clocks */
>>> +	/* Note: disabling unused PCIe lanes will hang PCI bus scan */
>>> +	pwr_mng_ctrl_reg = reg_read(POWER_MNG_CTRL_REG);
>>> +	pwr_mng_ctrl_reg &= ~(BIT(0));				/* Audio */
>>> +	pwr_mng_ctrl_reg &= ~(BIT(1) | BIT(2));			/* GE3, GE2 */
>>> +	//pwr_mng_ctrl_reg &= ~(BIT(10) | BIT(11) | BIT(12));	/* PCIe11 - PCIe13 */
>>
>> C++ style comments are not allowed, sorry. And again the same comment
>> about dead code.
>
> Ah, yes. Left it there in hopes to solve this PCI enum problem soon
> (probably will be when DM_PCI works as that relieves us from doing full
> bus scan), will put it into the note above instead.
>
> [...]
>
>>> +/*
>>> + * High Level Configuration Options (easy to change)
>>> + */
>>> +#define CONFIG_ARMADA_XP		/* SOC Family Name */
>>
>> This will not be needed any more with the 2 patches I reference
>> above. The SoC is selected via Kconfig then.
>
> OK.
>
>>> +#define CONFIG_MV78230			/* SoC Version */
>>> +#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */
>
> I will review those as well. Maybe the CONFIG_ARMADA_XP solution could
> be implemented for SoC types, too?

Yes, please. I also thought about this. Perhaps something like this
in the mach-mvebu/Kconfig:

config ARMADA_38X
	bool

config ARMADA_XP
	bool

config MV78230
	select ARMADA_XP
	bool

config MV78260
	select ARMADA_XP
	bool

config MV78460
	select ARMADA_XP
	bool

config 88F6810
	select ARMADA_38X
	bool

config 88F6820
	select ARMADA_38X
	bool

config 88F6828
	select ARMADA_38X
	bool

config ARMADA_38X
	bool

config ARMADA_XP
	bool

...

config TARGET_DB_MV784MP_GP
	bool "Support db-mv784mp-gp"
	select MV78460

...

What do you think?

> [...]
>
>>> +/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
>>> +#define CONFIG_SYS_MVEBU_DDR_AXP
>>> +#define MV_DDR_32BIT
>>
>> These 2 lines can also be removed with the new patches.
>
> OK, CONFIG_SYS_MVEBU_DDR_AXP seems not to be used anymore at all. But
> without MV_DDR_32BIT, BUS_WIDTH defaults to 64 which is wrong on DS414.

Ah, okay.

Thanks,
Stefan

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Phil Sutter]

Hi Stefan,

On Wed, Dec 23, 2015 at 08:56:39AM +0100, Stefan Roese wrote:
> >>> diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> >>> index f00f327..3dca6a1 100644
> >>> --- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> >>> +++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
> >>> @@ -43,8 +43,9 @@
> >>>    #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
> >>>    #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
> >>> +#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
> >>> +#define INVALID_BOARD_ID		0xFFFFFFFF
> >>
> >> Do you really need these changes here?
> >
> > Sadly, yes. See high_speed_env_lib.c for details: There it is needed by
> > serdes_phy_config() to get the right satr11 value via board_id_get().
> > Maybe this should be refactored to always use board_sat_r_get() and the
> > latter return a static value from a macro which board configs may define
> > instead of reading from i2c.
> 
> Yes, a refactorization would be good here. One idea is, to provide a
> _weak version of board_sat_r_get() in high_speed_env_lib.c used on
> all of these Marvell boards with a BOARD_ID. And custom boards, like
> your DS414 can provide a board specific version of board_sat_r_get()
> overwriting the weak default. And returning the board specific value.
> This way, all new custom boards would not have to touch this file
> any more.
> 
> Could you try to implement it this way?

Actually, it's already done. ;)

I started yesterday and it turned out to be much more straightforward
than I had expected. And yes, the __weak trick came to my mind then,
too.

> >>> +#define CONFIG_MV78230			/* SoC Version */
> >>> +#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */
> >
> > I will review those as well. Maybe the CONFIG_ARMADA_XP solution could
> > be implemented for SoC types, too?
> 
> Yes, please. I also thought about this. Perhaps something like this
> in the mach-mvebu/Kconfig:
> 
> config ARMADA_38X
> 	bool
> 
> config ARMADA_XP
> 	bool
> 
> config MV78230
> 	select ARMADA_XP
> 	bool
> 
> config MV78260
> 	select ARMADA_XP
> 	bool
> 
> config MV78460
> 	select ARMADA_XP
> 	bool
> 
> config 88F6810
> 	select ARMADA_38X
> 	bool
> 
> config 88F6820
> 	select ARMADA_38X
> 	bool
> 
> config 88F6828
> 	select ARMADA_38X
> 	bool
> 
> config ARMADA_38X
> 	bool
> 
> config ARMADA_XP
> 	bool
> 
> ...
> 
> config TARGET_DB_MV784MP_GP
> 	bool "Support db-mv784mp-gp"
> 	select MV78460
> 
> ...
> 
> What do you think?

Looks good, I'll check.

> >>> +/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
> >>> +#define CONFIG_SYS_MVEBU_DDR_AXP
> >>> +#define MV_DDR_32BIT
> >>
> >> These 2 lines can also be removed with the new patches.
> >
> > OK, CONFIG_SYS_MVEBU_DDR_AXP seems not to be used anymore at all. But
> > without MV_DDR_32BIT, BUS_WIDTH defaults to 64 which is wrong on DS414.
> 
> Ah, okay.

Maybe this should be renamed to into a CONFIG_* macro then? IMHO the
division between Kconfig symbols and board header defines is a bit
inconsistent.

Thanks, Phil

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Stefan Roese]

Hi Phil,

On 23.12.2015 12:30, Phil Sutter wrote:
> On Wed, Dec 23, 2015 at 08:56:39AM +0100, Stefan Roese wrote:
>>>>> diff --git a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>>>> index f00f327..3dca6a1 100644
>>>>> --- a/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>>>> +++ b/arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
>>>>> @@ -43,8 +43,9 @@
>>>>>     #define RD_78460_SERVER_REV2_ID		(DB_78X60_PCAC_REV2_ID + 1)
>>>>>     #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 SYNOLOGY_DS414_ID		(RD_78460_CUSTOMER_ID + 1)
>>>>> +#define MV_MAX_BOARD_ID			(SYNOLOGY_DS414_ID + 1)
>>>>> +#define INVALID_BOARD_ID		0xFFFFFFFF
>>>>
>>>> Do you really need these changes here?
>>>
>>> Sadly, yes. See high_speed_env_lib.c for details: There it is needed by
>>> serdes_phy_config() to get the right satr11 value via board_id_get().
>>> Maybe this should be refactored to always use board_sat_r_get() and the
>>> latter return a static value from a macro which board configs may define
>>> instead of reading from i2c.
>>
>> Yes, a refactorization would be good here. One idea is, to provide a
>> _weak version of board_sat_r_get() in high_speed_env_lib.c used on
>> all of these Marvell boards with a BOARD_ID. And custom boards, like
>> your DS414 can provide a board specific version of board_sat_r_get()
>> overwriting the weak default. And returning the board specific value.
>> This way, all new custom boards would not have to touch this file
>> any more.
>>
>> Could you try to implement it this way?
>
> Actually, it's already done. ;)
>
> I started yesterday and it turned out to be much more straightforward
> than I had expected. And yes, the __weak trick came to my mind then,
> too.

Nice! ;)

>>>>> +#define CONFIG_MV78230			/* SoC Version */
>>>>> +#define CONFIG_SYNOLOGY_DS414		/* board target name for DDR training and PCIe init */
>>>
>>> I will review those as well. Maybe the CONFIG_ARMADA_XP solution could
>>> be implemented for SoC types, too?
>>
>> Yes, please. I also thought about this. Perhaps something like this
>> in the mach-mvebu/Kconfig:
>>
>> config ARMADA_38X
>> 	bool
>>
>> config ARMADA_XP
>> 	bool
>>
>> config MV78230
>> 	select ARMADA_XP
>> 	bool
>>
>> config MV78260
>> 	select ARMADA_XP
>> 	bool
>>
>> config MV78460
>> 	select ARMADA_XP
>> 	bool
>>
>> config 88F6810
>> 	select ARMADA_38X
>> 	bool
>>
>> config 88F6820
>> 	select ARMADA_38X
>> 	bool
>>
>> config 88F6828
>> 	select ARMADA_38X
>> 	bool
>>
>> config ARMADA_38X
>> 	bool
>>
>> config ARMADA_XP
>> 	bool
>>
>> ...
>>
>> config TARGET_DB_MV784MP_GP
>> 	bool "Support db-mv784mp-gp"
>> 	select MV78460
>>
>> ...
>>
>> What do you think?
>
> Looks good, I'll check.

Thanks.

>>>>> +/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */
>>>>> +#define CONFIG_SYS_MVEBU_DDR_AXP
>>>>> +#define MV_DDR_32BIT
>>>>
>>>> These 2 lines can also be removed with the new patches.
>>>
>>> OK, CONFIG_SYS_MVEBU_DDR_AXP seems not to be used anymore at all. But
>>> without MV_DDR_32BIT, BUS_WIDTH defaults to 64 which is wrong on DS414.
>>
>> Ah, okay.
>
> Maybe this should be renamed to into a CONFIG_* macro then?

Yes. How about CONFIG_DDR_32BIT? Its using in some FSL MPC8xxx board
already.

> IMHO the
> division between Kconfig symbols and board header defines is a bit
> inconsistent.

It definitely is, yes.

Thanks,
Stefan

[U-Boot] [PATCH v2 7/8] mvebu: Support Synology DS414

[Bin Meng]

Hi Phil,

On Tue, Dec 22, 2015 at 7:25 AM, Phil Sutter <phil@nwl.cc> wrote:
> 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.
>

Ah, I guess you were encountering the same xHCI driver issue that was
seen on Intel's hardware. I've posted a patch series [1] that fixed
all of these and I believe it should work on your hardware too.

[snip]

[1] http://patchwork.ozlabs.org/patch/776725/

Regards,
Bin

[U-Boot] [PATCH v2 8/8] common: Implement Synology specific command set

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

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 common/Makefile         |   1 +
 common/cmd_syno.c       | 225 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/configs/ds414.h |   1 +
 3 files changed, 227 insertions(+)
 create mode 100644 common/cmd_syno.c

diff --git a/common/Makefile b/common/Makefile
index 2a1d9f8..36b65fd 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
 obj-$(CONFIG_CMD_DFU) += cmd_dfu.o
 obj-$(CONFIG_CMD_GPT) += cmd_gpt.o
 obj-$(CONFIG_CMD_ETHSW) += cmd_ethsw.o
+obj-$(CONFIG_CMD_SYNO) += cmd_syno.o
 
 # Power
 obj-$(CONFIG_CMD_PMIC) += cmd_pmic.o
diff --git a/common/cmd_syno.c b/common/cmd_syno.c
new file mode 100644
index 0000000..166f0d5
--- /dev/null
+++ b/common/cmd_syno.c
@@ -0,0 +1,225 @@
+/*
+ * Commands to deal with Synology specifics.
+ *
+ * Copyright (C) 2015  Phil Sutter <phil@nwl.cc>
+ */
+
+#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];
+	--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;
+usage:
+	return CMD_RET_USAGE;
+}
+
+U_BOOT_CMD(
+	syno, 5, 1, do_syno,
+	"Synology specific commands",
+	"populate_env                 - Read vendor data from SPI flash into environment\n"
+	"clk_gate (get|set name 1|0)  - Manage clock gating\n"
+);
diff --git a/include/configs/ds414.h b/include/configs/ds414.h
index 8148571..29b98b7 100644
--- a/include/configs/ds414.h
+++ b/include/configs/ds414.h
@@ -33,6 +33,7 @@
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_SF
 #define CONFIG_CMD_SPI
+#define CONFIG_CMD_SYNO
 #define CONFIG_CMD_TFTPPUT
 #define CONFIG_CMD_TIME
 #define CONFIG_CMD_USB
-- 
2.5.3

[U-Boot] [PATCH v2 8/8] common: Implement Synology specific command set

[Stefan Roese]

On 22.12.2015 00:25, Phil Sutter wrote:
> 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.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>

All this is very board specific. So I suggest to move it into
the board directory instead.

Thanks,
Stefan