drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY
Subsystems (4)
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v2 1/8 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY
The debug printing references bar_res, which exists only if CONFIG_PCI_ENUM_ONLY is not defined. Therefore move it into the ifdef'd area.
--- drivers/pci/pci_auto_old.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/pci_auto_old.c +1 -1
@@ -98,11 +98,11 @@ void pciauto_setup_device(struct pci_controller *hose, bar_res = prefetch; else bar_res = mem; -#endif debug ("PCI Autoconfig: BAR %d, %s, size=0x%llx, " , bar_nr, bar_res == prefetch ?"Prf" :"Mem" , (unsigned long long )bar_size); +#endif }#ifndef CONFIG_PCI_ENUM_ONLY
Signature · 1 line
2.5.3
PATCH v2 1/8 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY
(adding Simon and Bin to Cc)
Quoted 17 lines · Phil Sutter
The debug printing references
bar_res, which exists only ifCONFIG_PCI_ENUM_ONLYis not defined. Therefore move it into the ifdef'd area.Signed-off-by Phil Sutter <[email protected]>--- drivers/pci/pci_auto_old.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/pci/pci_auto_old.c +0
-0@@ -98,11 +98,11 @@ void pciauto_setup_device(struct pci_controller *hose, bar_res = prefetch; else
drivers/pci/pci_auto_old.c void pciauto_setup_device(struct pci_controller *hose, · line 108
Quoted 10 lines
drivers/pci/pci_auto_old.c +1
-1bar_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
Thanks,
Stefan
PATCH v2 2/8 mvebu: Fix for non-DM ehci-marvell support
In reply to a message not in the archiveThis 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.
--- 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(-)
arch/arm/mach-mvebu/cpu.c +21 -0
@@ -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 ;
arch/arm/mach-mvebu/include/mach/cpu.h +3 -0
@@ -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)
arch/arm/mach-mvebu/include/mach/soc.h +8 -1
@@ -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
Signature · 1 line
2.5.3
PATCH v2 2/8 mvebu: Fix for non-DM ehci-marvell support
Hi Phil,
Quoted 5 lines · Phil Sutter
This mimics the relevant code in mach-kirkwood headers. The
*_winctrl_calcsizefunctions 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
PATCH v2 2/8 mvebu: Fix for non-DM ehci-marvell support
Hi Stefan,
Quoted 9 lines · Stefan Roese
Quoted 5 lines · Phil Sutter
This mimics the relevant code in mach-kirkwood headers. The
*_winctrl_calcsizefunctions 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
PATCH v2 2/8 mvebu: Fix for non-DM ehci-marvell support
Hi Phil,
Quoted 8 lines · Phil Sutter
Quoted 7 lines · Stefan Roese
Quoted 5 lines · Phil Sutter
This mimics the relevant code in mach-kirkwood headers. The
*_winctrl_calcsizefunctions 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.
Quoted 6 lines
Quoted 2 lines
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_USBis 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.
Quoted 2 lines
If you don't see any use in it, I can drop this from the upcoming V3 of course.
Yes, please drop it.
Quoted 2 lines
OTOH maybe we should enforce
DM_USBfor 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
PATCH v2 3/8 README: Review the u-boot porting guide list
In reply to a message not in the archive* There is no boards.cfg anymore, so drop (1).
* Creating flash.c and u-boot.lds seems not mandatory as well.
* Adjusting the enumerators for the above implicitly fixed for double items numbered (3).
--- README | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
README +4 -7
@@ -5153,14 +5153,11 @@ If the system board that you have is not listed, then you will need to port U-Boot to your hardware platform. To do this, follow these steps: -1. Add a new configuration option for your board to the toplevel - "boards.cfg" file, using the existing entries as examples. - Follow the instructions there to keep the boards in order. -2. Create a new directory to hold your board specific code. Add any +1. Create a new directory to hold your board specific code. Add any files you need. In your board directory, you will need at least - the "Makefile", a "<board>.c", "flash.c" and "u-boot.lds". -3. Create a new configuration file "include/configs/<board>.h" for - your board + the "Makefile" and a "<board>.c". +2. Create a new configuration file "include/configs/<board>.h" for + your board. 3. If you're porting U-Boot to a new CPU, then also create a new directory to hold your CPU specific code. Add any files you need. 4. Run "make <board>_defconfig" with your new name.
Signature · 1 line
2.5.3
PATCH v2 3/8 README: Review the u-boot porting guide list
Quoted 24 lines · Phil Sutter
* There is no boards.cfg anymore, so drop (1).
* Creatingflash.candu-boot.ldsseems not mandatory as well.
* Adjusting the enumerators for the above implicitly fixed for double items numbered (3).Signed-off-by Phil Sutter <[email protected]>--- README | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)README +1
-4@@ -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
README If the system board that you have is not listed, then you will need · line 5163
Quoted 10 lines
README +3
-3files 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:
Thanks,
Stefan
PATCH v2 4/8 axp: Fix debugging support in DDR3 write leveling
In reply to a message not in the archiveIf MV_DEBUG_WL is defined, DEBUG_WL_S and DEBUG_WL_D macros are missing. In addition to that, get rid of debug output printing non-existent counter variable.
--- drivers/ddr/marvell/axp/ddr3_write_leveling.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ddr/marvell/axp/ddr3_write_leveling.c +2 -2
@@ -22,6 +22,8 @@ DEBUG_WL_FULL_S(s); DEBUG_WL_FULL_D(d, l); DEBUG_WL_FULL_S("\n")#ifdef MV_DEBUG_WL +#define DEBUG_WL_S (s) puts(s) +#define DEBUG_WL_D (d, l) printf("%x", d)#define DEBUG_RL_S (s) \ debug_cond(ddr3_get_log_level() >= MV_LOG_LEVEL_2, "%s", s)#define DEBUG_RL_D (d, l) \
@@ -1229,8 +1231,6 @@ static int ddr3_write_leveling_single_cs(u32 cs, u32 freq, int ratio_2to1,DEBUG_WL_FULL_D ((u32 ) phase,1 );DEBUG_WL_FULL_S (", Delay = " );DEBUG_WL_FULL_D ((u32 ) delay,1 ); -DEBUG_WL_FULL_S (", Counter = " ); -DEBUG_WL_FULL_D ((u32 ) i,1 );DEBUG_WL_FULL_S ("\n" );/* Drive DQS high for one cycle - All data PUPs */
Signature · 1 line
2.5.3
PATCH v2 4/8 axp: Fix debugging support in DDR3 write leveling
Quoted 24 lines · Phil Sutter
If
MV_DEBUG_WLis defined,DEBUG_WL_SandDEBUG_WL_Dmacros are missing. In addition to that, get rid of debug output printing non-existent counter variable.Signed-off-by Phil Sutter <[email protected]>--- drivers/ddr/marvell/axp/ddr3_write_leveling.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)drivers/ddr/marvell/axp/ddr3_write_leveling.c +2
-0@@ -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) \
drivers/ddr/marvell/axp/ddr3_write_leveling.c static int ddr3_write_leveling_single_cs(u32 cs, u32 freq, int ratio_2to1, · line 1236
Quoted 8 lines
drivers/ddr/marvell/axp/ddr3_write_leveling.c +0
-2@@ -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 */
Thanks,
Stefan
PATCH v2 5/8 drivers/pci/pci_mvebu: Fix for boards with X4 lanes
In reply to a message not in the archiveArmada 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.
--- drivers/pci/pci_mvebu.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/pci/pci_mvebu.c +21 -0
@@ -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 } }
Signature · 1 line
2.5.3
PATCH v2 5/8 drivers/pci/pci_mvebu: Fix for boards with X4 lanes
Quoted 22 lines · Phil Sutter
Armada XP has support for X4 lanes, boards specify this in their
serdes_cfg. During PEX init inhigh_speed_env_lib.c, the configuration is stored inGEN_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 <[email protected]>--- drivers/pci/pci_mvebu.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)drivers/pci/pci_mvebu.c +0
-0
drivers/pci/pci_mvebu.c line 24
Quoted 7 lines
drivers/pci/pci_mvebu.c +4
-0@@ -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))
Quoted 5 lines
drivers/pci/pci_mvebu.c +1
-0+DECLARE_GLOBAL_DATA_PTR ;/* PCIe unit register offsets */
drivers/pci/pci_mvebu.c static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx, · line 169
Quoted 10 lines
drivers/pci/pci_mvebu.c +7
-0@@ -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.
drivers/pci/pci_mvebu.c static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx, · line 171
Quoted 2 lines
drivers/pci/pci_mvebu.c +2
-0+} +#endif
Please drop the #ifdef here. This can go in unconditionally.
Quoted 5 lines
drivers/pci/pci_mvebu.c +1
-0+static inline bool mvebu_pcie_link_up (struct mvebu_pcie *pcie) {u32 val;
drivers/pci/pci_mvebu.c void pci_init_board(void) · line 442
Quoted 9 lines
drivers/pci/pci_mvebu.c +6
-0@@ -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
PATCH v2 6/8 mvebu: Add rudimental MV78320 support
In reply to a message not in the archive--- arch/arm/mach-mvebu/cpu.c | 16 +++++++++++----- arch/arm/mach-mvebu/include/mach/soc.h | 1 + arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 6 +++++- 3 files changed, 17 insertions(+), 6 deletions(-)
arch/arm/mach-mvebu/cpu.c +11 -5
@@ -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 ;
arch/arm/mach-mvebu/include/mach/soc.h +1 -0
@@ -11,6 +11,7 @@#ifndef _MVEBU_SOC_H#define _MVEBU_SOC_H +#define SOC_MV78230_ID 0x7823#define SOC_MV78260_ID 0x7826#define SOC_MV78460_ID 0x7846#define SOC_88F6810_ID 0x6810
arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +5 -1
@@ -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 :
Signature · 1 line
2.5.3
PATCH v2 6/8 mvebu: Add rudimental MV78320 support
Quoted 1 line · Phil Sutter
Signed-off-by Phil Sutter <[email protected]>
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:
Thanks,
Stefan
Quoted 79 lines
--- arch/arm/mach-mvebu/cpu.c | 16 +++++++++++----- arch/arm/mach-mvebu/include/mach/soc.h | 1 + arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 6 +++++- 3 files changed, 17 insertions(+), 6 deletions(-)arch/arm/mach-mvebu/cpu.c +11
-5@@ -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 ;arch/arm/mach-mvebu/include/mach/soc.h +1
-0@@ -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 0x6810arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +5
-1@@ -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 :
Signature · 7 lines
Viele Gr??e, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de
PATCH v2 7/8 mvebu: Support Synology DS414
In reply to a message not in the archiveThis adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in are SATA and XHCI support. Details about these and some other things follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from Linux and enhanced by recent U-Boot specific changes to armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Porting sata_mv from Linux exceeded my brain's capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which drives the two rear USB3 ports. After a bit of playing around I managed to get it recognized by xhci-pci, but never was able to access any devices attached to it. Enabling it in ds414 board config shows that it does not respond to commands for whatever reason. The (somewhat) bright side to it is that it is not even supported in Synology's customized U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB storage devices, and IIRC reading from them was OK. OTOH Linux fails to register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device (gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like this is meant to be customized in mainline U-Boot at all. OTOH I have no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:pex_max_unit_get returns 2, pex_max_if_get returns 7 and max_serdes_lines is set to 7. Not changing this seems to not have an impact, although I'm not entirely sure it does not cause issues I am not aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a little more flexible when it comes to booting custom kernels, do not only load zImage partition, but also rd.gz into memory. This way it is possible to use about 7MB for kernel with piggyback initramfs.
--- arch/arm/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
arch/arm/Kconfig +1 -0
@@ -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"
arch/arm/dts/Makefile +2 -0
@@ -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 \
arch/arm/dts/armada-xp-synology-ds414.dts new file +337 -0
337 lines not on this page · raw message
arch/arm/mach-mvebu/Kconfig +3 -0
@@ -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
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3 -2
@@ -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))
arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +3 -0
@@ -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 :
board/Synology/ds414/Kconfig new file +12 -0
@@ -0,0 +1,12 @@ +if TARGET_DS414 + +config SYS_BOARD + default "ds414" + +config SYS_VENDOR + default "Synology" + +config SYS_CONFIG_NAME + default "ds414" + +endif
board/Synology/ds414/Makefile new file +1 -0
@@ -0,0 +1 @@ +obj-y := ds414.o
board/Synology/ds414/ds414.c new file +173 -0
173 lines not on this page · raw message
board/Synology/ds414/kwbimage.cfg new file +12 -0
@@ -0,0 +1,12 @@ +# +# Copyright (C) 2014 Stefan Roese <[email protected]> +# + +# Armada XP uses version 1 image format +VERSION 1 + +# Boot Media configurations +BOOT_FROM spi + +# Binary Header (bin_hdr) with DDR3 training code +BINARY spl/u-boot-spl-dtb.bin 0000005b 00000068
configs/ds414_defconfig new file +18 -0
@@ -0,0 +1,18 @@ +CONFIG_ARM=y +CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_TARGET_DS414=y +CONFIG_DEFAULT_DEVICE_TREE="armada-xp-synology-ds414" +CONFIG_SPL=y +# CONFIG_CMD_IMLS is not set +# CONFIG_CMD_FLASH is not set +# CONFIG_CMD_SETEXPR is not set +CONFIG_SPL_OF_TRANSLATE=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_DEBUG_UART=y +CONFIG_DEBUG_UART_BASE=0xd0012000 +CONFIG_DEBUG_UART_CLOCK=250000000 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y
include/configs/ds414.h new file +164 -0
164 lines not on this page · raw message
Signature · 1 line
2.5.3
PATCH v2 7/8 mvebu: Support Synology DS414
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...
Quoted 16 lines · Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
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.dtshas been copied from Linux and enhanced by recent U-Boot specific changes toarmada-xp-gp.dts.
Quoted 7 lines
SATA Support
------------There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's
sata_mvdriver but sadly not U-Boot'ssata_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.
Quoted 2 lines
Porting
sata_mvfrom Linux exceeded my brain's
capacities. :(
Heh. ;)
Quoted 14 lines
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
------------
Quoted 6 lines
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?
Quoted 5 lines
PCIe Support
------------This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that,
pci_mvebuseems not to supportDM_PCI.
Right. Patches welcome. ;)
Quoted 64 lines
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_getreturns 2,pex_max_if_getreturns 7 andmax_serdes_linesis 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 <[email protected]>--- 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.dtscreate mode 100644 board/Synology/ds414/Kconfig create mode 100644 board/Synology/ds414/Makefile create mode 100644board/Synology/ds414/ds414.ccreate mode 100644 board/Synology/ds414/kwbimage.cfg create mode 100644 configs/ds414_defconfig
create mode 100644include/configs/ds414.harch/arm/Kconfig +1
-0@@ -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"arch/arm/dts/Makefile +0
-0
arch/arm/dts/Makefile dtb-$(CONFIG_ARCH_MVEBU) += \ · line 57
Quoted 5 lines
arch/arm/dts/Makefile +2
-0@@ -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.
Quoted 365 lines
arch/arm/dts/Makefile +0
-0dtb-$(CONFIG_ARCH_UNIPHIER) += \ uniphier-ph1-ld4-ref.dtb \ uniphier-ph1-ld6b-ref.dtb \arch/arm/dts/armada-xp-synology-ds414.dts new file +337
-0@@ -0,0 +1,337 @@ +/* + * Device Tree file for Synology DS414 + * + * Copyright (C) 2014, Arnaud EBALARD <[email protected]> + * + * 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"; + }; +};arch/arm/mach-mvebu/Kconfig +3
-0@@ -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_SOCarch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 48
Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-2@@ -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?
Quoted 32 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0/* Sample at Reset */ #define MPP_SAMPLE_AT_RESET (id) (0x18230 + (id * 4))arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +3
-0@@ -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 :board/Synology/ds414/Kconfig new file +2
-0@@ -0,0 +1,12 @@ +if TARGET_DS414 +
board/Synology/ds414/Kconfig line 12
Quoted 10 lines
board/Synology/ds414/Kconfig new file +10
-0+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.
Quoted 52 lines
board/Synology/ds414/Makefile new file +1
-0@@ -0,0 +1 @@ +obj-y := ds414.oboard/Synology/ds414/ds414.c new file +39
-0@@ -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 +};
board/Synology/ds414/ds414.c line 49
Quoted 10 lines
board/Synology/ds414/ds414.c new file +10
-0+ +/* 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.
Quoted 21 lines
board/Synology/ds414/ds414.c new file +21
-0+ + {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 */
board/Synology/ds414/ds414.c line 80
Quoted 10 lines
board/Synology/ds414/ds414.c new file +10
-0+ + {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.
Quoted 66 lines
board/Synology/ds414/ds414.c new file +66
-0+ {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;
board/Synology/ds414/ds414.c line 156
Quoted 10 lines
board/Synology/ds414/ds414.c new file +10
-0+ +/* 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.
Quoted 68 lines
board/Synology/ds414/ds414.c new file +17
-0+ 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 ; +}board/Synology/ds414/kwbimage.cfg new file +12
-0@@ -0,0 +1,12 @@ +# +# Copyright (C) 2014 Stefan Roese <[email protected]> +# + +# Armada XP uses version 1 image format +VERSION 1 + +# Boot Media configurations +BOOT_FROM spi + +# Binary Header (bin_hdr) with DDR3 training code +BINARY spl/u-boot-spl-dtb.bin 0000005b 00000068configs/ds414_defconfig new file +18
-0@@ -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=yinclude/configs/ds414.h new file +3
-0@@ -0,0 +1,164 @@ +/* +* Copyright (C) 2014 Stefan Roese <[email protected]> +*
include/configs/ds414.h line 13
Quoted 10 lines
include/configs/ds414.h new file +10
-0+* 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.
Quoted 128 lines
include/configs/ds414.h new file +128
-0+#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 */
include/configs/ds414.h line 151
Quoted 10 lines
include/configs/ds414.h new file +10
-0+#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.
include/configs/ds414.h line 164
Quoted 13 lines
include/configs/ds414.h new file +12
-0+/* 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
PATCH v2 7/8 mvebu: Support Synology DS414
Hi,
Quoted 11 lines · Stefan Roese
I've consolidated a bit of the Armada XP / 38x defines and
Kconfigoptions 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_XPonly defined on AXP devices).
I see.
Quoted 3 lines
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.
[...]
Quoted 9 lines
Quoted 7 lines
SATA Support
------------There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's
sata_mvdriver but sadly not U-Boot'ssata_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.
[...]
Quoted 10 lines
Quoted 9 lines
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.
Quoted 6 lines
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_physincpu.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.
Quoted 7 lines
Quoted 5 lines
PCIe Support
------------This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that,
pci_mvebuseems not to supportDM_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. :)
[...]
Quoted 7 lines
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0@@ -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)
Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 48
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-2#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 0xFFFFFFFFDo 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.
[...]
Quoted 5 lines
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +5
-0+/* 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 */
Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 4 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +4
-0+ {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.
[...]
Quoted 9 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +6
-0+/* 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.
[...]
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 4 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +4
-0+/* +* 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
Kconfigthen.
OK.
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +2
-0+#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?
[...]
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 3 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-0+/* 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
PATCH v2 7/8 mvebu: Support Synology DS414
Hi Phil,
Quoted 58 lines · Phil Sutter
Quoted 11 lines · Stefan Roese
I've consolidated a bit of the Armada XP / 38x defines and
Kconfigoptions 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_XPonly defined on AXP devices).I see.
Quoted 3 lines
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.
[...]
Quoted 9 lines
Quoted 7 lines
SATA Support
------------There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's
sata_mvdriver but sadly not U-Boot'ssata_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_mvin U-Boot now and Linux'ssata_mvsimply supports both the platform device and the various PCI devices, one might think it should be straightforward to add support to it. But Linux'ssata_mvwith it's 4.5k LoC is quite a thing, too.[...]
Quoted 15 lines
Quoted 9 lines
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_physincpu.c).
Quoted 4 lines
Quoted 1 line
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.
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
PCIe Support
------------This is fine, but trying to gate the clocks of unused lanes will hang PCI enum. In addition to that,
pci_mvebuseems not to supportDM_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
0xfbfbfor both vendor and product IDs. Looks like a follow-up project to me. :)
Yes, that would be really great! :)
Quoted 18 lines
[...]
Quoted 7 lines
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0@@ -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)Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 48
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-2#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 0xFFFFFFFFDo you really need these changes here?
Quoted 5 lines
Sadly, yes. See
high_speed_env_lib.cfor details: There it is needed byserdes_phy_config()to get the right satr11 value viaboard_id_get(). Maybe this should be refactored to always useboard_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?
Quoted 46 lines
[...]
Quoted 5 lines
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +5
-0+/* 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 */ Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 4 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +4
-0+ {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.
[...]
Quoted 9 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +6
-0+/* 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_PCIworks as that relieves us from doing full bus scan), will put it into the note above instead.[...]
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 4 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +4
-0+/* +* 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
Kconfigthen.
Quoted 7 lines
OK.
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +2
-0+#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_XPsolution 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?
Quoted 10 lines
[...]
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 3 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-0+/* 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_AXPseems not to be used anymore at all. But withoutMV_DDR_32BIT,BUS_WIDTHdefaults to 64 which is wrong on DS414.
Ah, okay.
Thanks,
Stefan
PATCH v2 7/8 mvebu: Support Synology DS414
Hi Stefan,
Quoted 30 lines · Stefan Roese
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0@@ -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)Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 48
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-2#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 0xFFFFFFFFDo you really need these changes here?
Quoted 5 lines
Sadly, yes. See
high_speed_env_lib.cfor details: There it is needed byserdes_phy_config()to get the right satr11 value viaboard_id_get(). Maybe this should be refactored to always useboard_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
_weakversion ofboard_sat_r_get()inhigh_speed_env_lib.cused on all of these Marvell boards with aBOARD_ID. And custom boards, like your DS414 can provide a board specific version ofboard_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.
Quoted 1 line
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.
Quoted 47 lines
Quoted 5 lines
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 50
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +2
-0+#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_XPsolution 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
boolconfig
ARMADA_XP
boolconfig MV78230
selectARMADA_XP
boolconfig MV78260
selectARMADA_XP
boolconfig MV78460
selectARMADA_XP
boolconfig 88F6810
selectARMADA_38X
boolconfig 88F6820
selectARMADA_38X
boolconfig 88F6828
selectARMADA_38X
boolconfig
ARMADA_38X
boolconfig
ARMADA_XP
bool...
Quoted 7 lines
config
TARGET_DB_MV784MP_GPbool "Support db-mv784mp-gp" select MV78460...
What do you think?
Looks good, I'll check.
Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 3 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-0+/* 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_AXPseems not to be used anymore at all. But withoutMV_DDR_32BIT,BUS_WIDTHdefaults 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
PATCH v2 7/8 mvebu: Support Synology DS414
Hi Phil,
Quoted 31 lines · Phil Sutter
Quoted 30 lines · Stefan Roese
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +0
-0@@ -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)Quoted 8 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 48
Quoted 6 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-2#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 0xFFFFFFFFDo you really need these changes here?
Quoted 5 lines
Sadly, yes. See
high_speed_env_lib.cfor details: There it is needed byserdes_phy_config()to get the right satr11 value viaboard_id_get(). Maybe this should be refactored to always useboard_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
_weakversion ofboard_sat_r_get()inhigh_speed_env_lib.cused on all of these Marvell boards with aBOARD_ID. And custom boards, like your DS414 can provide a board specific version ofboard_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.
Quoted 7 lines
Quoted 1 line
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
__weaktrick came to my mind then, too.
Nice! ;)
Quoted 51 lines
Quoted 51 lines
Quoted 5 lines
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h line 50
Quoted 2 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +2
-0+#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_XPsolution 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
boolconfig
ARMADA_XP
boolconfig MV78230
selectARMADA_XP
boolconfig MV78260
selectARMADA_XP
boolconfig MV78460
selectARMADA_XP
boolconfig 88F6810
selectARMADA_38X
boolconfig 88F6820
selectARMADA_38X
boolconfig 88F6828
selectARMADA_38X
boolconfig
ARMADA_38X
boolconfig
ARMADA_XP
bool...
config
TARGET_DB_MV784MP_GPbool "Support db-mv784mp-gp" select MV78460
Quoted 5 lines
Quoted 3 lines
...
What do you think?
Looks good, I'll check.
Thanks.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h
Quoted 3 lines
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +3
-0+/* 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.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
OK,
CONFIG_SYS_MVEBU_DDR_AXPseems not to be used anymore at all. But withoutMV_DDR_32BIT,BUS_WIDTHdefaults 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.
Quoted 3 lines
IMHO the
division betweenKconfigsymbols and board header defines is a bit inconsistent.
It definitely is, yes.
Thanks,
Stefan
PATCH v2 7/8 mvebu: Support Synology DS414
In reply to Phil SutterHi Phil,
Quoted 28 lines · Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
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.dtshas been copied from Linux and enhanced by recent U-Boot specific changes toarmada-xp-gp.dts.SATA Support
------------There is a Marvell 88SX7042 controller attached to PCIe which is supported by Linux's
sata_mvdriver but sadly not U-Boot'ssata_mv. I'm not sure if extending the latter to support PCI devices is worth the effort at all. Portingsata_mvfrom Linux exceeded my brain's capacities. :(XHCI Support
------------
Quoted 8 lines
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
PATCH v2 8/8 common: Implement Synology specific command set
In reply to a message not in the archiveSynology 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.
--- 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
common/Makefile +1 -0
@@ -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
common/cmd_syno.c new file +225 -0
225 lines not on this page · raw message
include/configs/ds414.h +1 -0
@@ -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
Signature · 1 line
2.5.3
PATCH v2 8/8 common: Implement Synology specific command set
Quoted 8 lines · Phil Sutter
Synology keeps per item configuration in a dedicated 'partition' in SPI flash, namely the one named 'vendor' in DTS file. It contains the two NICs MAC addresses as well as the item's serial number. I didn't find a way to have this information extracted automatically, therefore implemented 'syno
populate_env' command which extracts the three values and puts them into environment. To make things permanent though, one has to 'saveenv'.
Quoted 4 lines
Another command is 'syno
clk_gate', which allows to change the clock gating which is done in DS414 board file.Signed-off-by Phil Sutter <[email protected]>
All this is very board specific. So I suggest to move it into the board directory instead.
Thanks,
Stefan