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 v3 1/10 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY
The debug printing references bar_res, which exists only if CONFIG_PCI_ENUM_ONLY is not defined. Therefore move it into the ifdef'd area.
--- drivers/pci/pci_auto_old.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/pci_auto_old.c +1 -1
@@ -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 v3 1/10 drivers/pci: Fix for debug builds without CONFIG_PCI_ENUM_ONLY
Quoted 5 lines · Phil Sutter
The debug printing references
bar_res, which exists only ifCONFIG_PCI_ENUM_ONLYis not defined. Therefore move it into the ifdef'd area.Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/f1e86253/attachment.sig>
PATCH v3 2/10 README: Review the u-boot porting guide list
In reply to a message not in the archive* There is no boards.cfg anymore, so drop (1).
* Creating flash.c and u-boot.lds seems not mandatory as well.
* Adjusting the enumerators for the above implicitly fixed for double items numbered (3).
--- README | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
README +4 -7
@@ -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 v3 2/10 README: Review the u-boot porting guide list
Quoted 6 lines · Phil Sutter
* There is no boards.cfg anymore, so drop (1).
* 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]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/c821b78d/attachment.sig>
PATCH v3 3/10 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 v3 3/10 axp: Fix debugging support in DDR3 write leveling
Quoted 5 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]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/ef04e63d/attachment.sig>
PATCH v3 4/10 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.
--- arch/arm/mach-mvebu/include/mach/soc.h | 2 ++ drivers/pci/pci_mvebu.c | 14 ++++++++++++++ 2 files changed, 16 insertions(+)
arch/arm/mach-mvebu/include/mach/soc.h +2 -0
@@ -96,4 +96,6 @@#define MVCPU_WIN_ENABLE CPU_WIN_ENABLE#define MVCPU_WIN_DISABLE CPU_WIN_DISABLE +#define COMPHY_REFCLK_ALIGNMENT (MVEBU_REGISTER(0x182f8)) +#endif /* _MVEBU_SOC_H */
drivers/pci/pci_mvebu.c +14 -0
@@ -155,6 +155,14 @@ static void mvebu_get_port_lane(struct mvebu_pcie *pcie, int pex_idx, }#endif +static int mvebu_pex_unit_is_x4 (int pex_idx) +{ +int pex_unit = pex_idx <9 ? pex_idx >>2 :3 ; +u32 mask = (0x0f << (pex_unit *8 )); + +return (readl (COMPHY_REFCLK_ALIGNMENT ) & mask) == mask; +} +static inline bool mvebu_pcie_link_up (struct mvebu_pcie *pcie) {u32 val;
@@ -419,5 +427,11 @@ void pci_init_board(void)writel (0 , pcie->base +PCIE_BAR_HI_OFF (0 )); bus = hose->last_busno +1 ; + +/* need to skip more for X4 links, otherwise scan will hang */ +if (mvebu_soc_family () ==MVEBU_SOC_AXP ) { +if (mvebu_pex_unit_is_x4 (i)) + i +=3 ; + } } }
Signature · 1 line
2.5.3
PATCH v3 4/10 drivers/pci/pci_mvebu: Fix for boards with X4 lanes
Quoted 4 lines · Phil Sutter
Armada XP has support for X4 lanes, boards specify this in their
serdes_cfg. During PEX init inhigh_speed_env_lib.c, the configuration is stored inGEN_PURP_RES_2_REG.
Quoted 8 lines
When enumerating PEX, subsequent interfaces of an X4 lane must be skipped. Otherwise the enumeration hangs up the board.
The way this is implemented here is not exactly beautiful, but it mimics how Marvell's BSP does it. Alternatively we could get the information using
board_serdes_cfg_get(), but that won't lead to clean code, either.Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/3aaf25e4/attachment.sig>
PATCH v3 5/10 mvebu: axp: refactor board_sat_r_get() and caller
In reply to a message not in the archiveInstead of calling board_sat_r_get() only for those boards providing the satr11 value via I2C, call it for all boards and return static values for those not using I2C.
In addition to that, make this a weak function to allow for board code to override it.
--- .../arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 46 +++++++--------------- 1 file changed, 15 insertions(+), 31 deletions(-)
arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c +15 -31
@@ -75,16 +75,24 @@ static u32 board_id_get(void)#endif } -static u8 board_sat_r_get (u8 dev_num,u8 reg) +__weak u8 board_sat_r_get (u8 dev_num,u8 reg) {u8 data;u8 *dev;u32 board_id =board_id_get ();int ret; -i2c_init (CONFIG_SYS_I2C_SPEED ,CONFIG_SYS_I2C_SLAVE ); -switch (board_id) { +case DB_78X60_AMC_ID : +case DB_78X60_PCAC_REV2_ID : +case RD_78460_CUSTOMER_ID : +case RD_78460_SERVER_ID : +case RD_78460_SERVER_REV2_ID : +case DB_78X60_PCAC_ID : +return (0x1 <<1 ) |1 ; +case FPGA_88F78XX0_ID : +case RD_78460_NAS_ID : +return (0x0 <<1 ) |1 ;case DB_784MP_GP_ID : dev = rd78460gp_twsi_dev;
@@ -94,15 +102,12 @@ static u8 board_sat_r_get(u8 dev_num, u8 reg) dev = db88f78xx0rev2_twsi_dev;break ; -case DB_78X60_PCAC_ID : -case FPGA_88F78XX0_ID : -case DB_78X60_PCAC_REV2_ID : -case RD_78460_SERVER_REV2_ID :default :return 0 ; }/* Read MPP module ID */ +i2c_init (CONFIG_SYS_I2C_SPEED ,CONFIG_SYS_I2C_SLAVE ); ret =i2c_read (dev[dev_num],0 ,1 , (u8 *)&data,1 );if (ret)return MV_ERROR ;
@@ -240,7 +245,6 @@ int serdes_phy_config(void)u8 device_rev;u32 rx_high_imp_mode;u16 ctrl_mode; -u32 board_id =board_id_get ();u32 pex_if;u32 pex_if_num;
@@ -251,29 +255,9 @@ int serdes_phy_config(void)if (max_serdes_lines ==0 )return MV_OK ; -switch (board_id) { -case DB_78X60_AMC_ID : -case DB_78X60_PCAC_REV2_ID : -case RD_78460_CUSTOMER_ID : -case RD_78460_SERVER_ID : -case RD_78460_SERVER_REV2_ID : -case DB_78X60_PCAC_ID : - satr11 = (0x1 <<1 ) |1 ; -break ; -case FPGA_88F78XX0_ID : -case RD_78460_NAS_ID : - satr11 = (0x0 <<1 ) |1 ; -break ; -case DB_88F78XX0_BP_REV2_ID : -case DB_784MP_GP_ID : -case DB_88F78XX0_BP_ID : - satr11 =board_sat_r_get (1 ,1 ); -if ((u8 )MV_ERROR == (u8 ) satr11) -return MV_ERROR ; -break ; -default : - satr11 =0 ; - } + satr11 =board_sat_r_get (1 ,1 ); +if ((u8 )MV_ERROR == (u8 ) satr11) +return MV_ERROR ;board_modules_scan ();memset (addr,0 ,sizeof (addr));
Signature · 1 line
2.5.3
PATCH v3 5/10 mvebu: axp: refactor board_sat_r_get() and caller
Quoted 8 lines · Phil Sutter
Instead of calling
board_sat_r_get()only for those boards providing the satr11 value via I2C, call it for all boards and return static values for those not using I2C.In addition to that, make this a weak function to allow for board code to override it.
Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/48940982/attachment.sig>
PATCH v3 6/10 mvebu: Introduce kconfig symbols for SoC variants
In reply to a message not in the archiveThis patch adds intermediate kconfig symbols which select their SoC family. Boards then select them instead of the family symbol directly.
--- arch/arm/mach-mvebu/Kconfig | 24 ++++++++++++++++++++---- include/configs/clearfog.h | 1 - include/configs/db-88f6820-gp.h | 1 - 3 files changed, 20 insertions(+), 6 deletions(-)
arch/arm/mach-mvebu/Kconfig +20 -4
@@ -6,25 +6,41 @@ config ARMADA_38X config ARMADA_XP bool +config MV78230 + bool + select ARMADA_XP + +config MV78260 + bool + select ARMADA_XP + +config MV78460 + bool + select ARMADA_XP + +config DB_88F6820_GP + bool + select ARMADA_38X + choice prompt "Marvell MVEBU (Armada XP/38x) board select" optional config TARGET_CLEARFOG bool "Support ClearFog" - select ARMADA_38X + select DB_88F6820_GP config TARGET_DB_88F6820_GP bool "Support DB-88F6820-GP" - select ARMADA_38X + select DB_88F6820_GP config TARGET_DB_MV784MP_GP bool "Support db-mv784mp-gp" - select ARMADA_XP + select MV78460 config TARGET_MAXBCM bool "Support maxbcm" - select ARMADA_XP + select MV78460 endchoice
include/configs/clearfog.h +0 -1
@@ -10,7 +10,6 @@/* * High Level Configuration Options (easy to change) */ -#define CONFIG_DB_88F6820_GP /* Board target name for DDR training */ #define CONFIG_DISPLAY_BOARDINFO_LATE
include/configs/db-88f6820-gp.h +0 -1
@@ -10,7 +10,6 @@/* * High Level Configuration Options (easy to change) */ -#define CONFIG_DB_88F6820_GP /* Board target name for DDR training */ #define CONFIG_DISPLAY_BOARDINFO_LATE
Signature · 1 line
2.5.3
PATCH v3 6/10 mvebu: Introduce kconfig symbols for SoC variants
Quoted 4 lines · Phil Sutter
This patch adds intermediate kconfig symbols which select their SoC family. Boards then select them instead of the family symbol directly.
Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/6c5cdba8/attachment.sig>
PATCH v3 7/10 mvebu: axp: Rename MV_DDR_32BIT to CONFIG_DDR_32BIT
In reply to a message not in the archiveThis should make it clear that this symbol is meant to be defined by board headers.
--- drivers/ddr/marvell/axp/ddr3_axp_config.h | 2 +- drivers/ddr/marvell/axp/ddr3_axp_mc_static.h | 20 ++++++++++---------- 2 files changed, 11 insertions(+), 11 deletions(-)
drivers/ddr/marvell/axp/ddr3_axp_config.h +1 -1
@@ -51,7 +51,7 @@#define DRAM_ECC 0#endif -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT #define BUS_WIDTH 32#else #define BUS_WIDTH 64
drivers/ddr/marvell/axp/ddr3_axp_mc_static.h +10 -10
@@ -8,9 +8,9 @@#define __AXP_MC_STATIC_H MV_DRAM_MC_INIT ddr3_A0_db_667[MV_MAX_DDR3_STATIC_SIZE] = { -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT {0x00001400, 0x7301c924}, /*DDR SDRAM Configuration Register */ -#else /*MV_DDR_64BIT */ +#else /*CONFIG_DDR_64BIT */ {0x00001400, 0x7301CA28}, /*DDR SDRAM Configuration Register */ #endif {0x00001404, 0x3630b800}, /*Dunit Control Low Register */
@@ -66,9 +66,9 @@ MV_DRAM_MC_INIT ddr3_A0_db_667[MV_MAX_DDR3_STATIC_SIZE] = { }; MV_DRAM_MC_INIT ddr3_A0_AMC_667[MV_MAX_DDR3_STATIC_SIZE] = { -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT {0x00001400, 0x7301c924}, /*DDR SDRAM Configuration Register */ -#else /*MV_DDR_64BIT */ +#else /*CONFIG_DDR_64BIT */ {0x00001400, 0x7301CA28}, /*DDR SDRAM Configuration Register */ #endif {0x00001404, 0x3630b800}, /*Dunit Control Low Register */
@@ -124,9 +124,9 @@ MV_DRAM_MC_INIT ddr3_A0_AMC_667[MV_MAX_DDR3_STATIC_SIZE] = { }; MV_DRAM_MC_INIT ddr3_A0_db_400[MV_MAX_DDR3_STATIC_SIZE] = { -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT {0x00001400, 0x73004C30}, /*DDR SDRAM Configuration Register */ -#else /* MV_DDR_64BIT */ +#else /* CONFIG_DDR_64BIT */ {0x00001400, 0x7300CC30}, /*DDR SDRAM Configuration Register */ #endif {0x00001404, 0x3630B840}, /*Dunit Control Low Register */
@@ -176,9 +176,9 @@ MV_DRAM_MC_INIT ddr3_A0_db_400[MV_MAX_DDR3_STATIC_SIZE] = { }; MV_DRAM_MC_INIT ddr3_Z1_db_600[MV_MAX_DDR3_STATIC_SIZE] = { -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT {0x00001400, 0x73014A28}, /*DDR SDRAM Configuration Register */ -#else /*MV_DDR_64BIT */ +#else /*CONFIG_DDR_64BIT */ {0x00001400, 0x7301CA28}, /*DDR SDRAM Configuration Register */ #endif {0x00001404, 0x3630B040}, /*Dunit Control Low Register */
@@ -233,9 +233,9 @@ MV_DRAM_MC_INIT ddr3_Z1_db_600[MV_MAX_DDR3_STATIC_SIZE] = { }; MV_DRAM_MC_INIT ddr3_Z1_db_300[MV_MAX_DDR3_STATIC_SIZE] = { -#ifdef MV_DDR_32BIT +#ifdef CONFIG_DDR_32BIT {0x00001400, 0x73004C30}, /*DDR SDRAM Configuration Register */ -#else /*MV_DDR_64BIT */ +#else /*CONFIG_DDR_64BIT */ {0x00001400, 0x7300CC30}, /*DDR SDRAM Configuration Register */ /*{0x00001400, 0x7304CC30}, *//*DDR SDRAM Configuration Register */ #endif
Signature · 1 line
2.5.3
PATCH v3 7/10 mvebu: axp: Rename MV_DDR_32BIT to CONFIG_DDR_32BIT
Quoted 4 lines · Phil Sutter
This should make it clear that this symbol is meant to be defined by board headers.
Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/7206156b/attachment.sig>
PATCH v3 8/10 mvebu: Add rudimental MV78230 support
In reply to a message not in the archiveThis adds basic support for Marvell's MV78230 SoC which belongs to the Armada XP series.
--- arch/arm/mach-mvebu/cpu.c | 16 +++++++++++----- arch/arm/mach-mvebu/include/mach/soc.h | 1 + arch/arm/mach-mvebu/serdes/axp/high_speed_env_lib.c | 6 +++++- 3 files changed, 17 insertions(+), 6 deletions(-)
arch/arm/mach-mvebu/cpu.c +11 -5
@@ -49,13 +49,16 @@ int mvebu_soc_family(void) {u16 devid = (readl (MVEBU_REG_PCIE_DEVID ) >>16 ) &0xffff ; -if ((devid ==SOC_MV78260_ID ) || (devid ==SOC_MV78460_ID )) +switch (devid) { +case SOC_MV78230_ID : +case SOC_MV78260_ID : +case SOC_MV78460_ID :return MVEBU_SOC_AXP ; - -if (devid ==SOC_88F6810_ID || devid ==SOC_88F6820_ID || - devid ==SOC_88F6828_ID ) +case SOC_88F6810_ID : +case SOC_88F6820_ID : +case SOC_88F6828_ID :return MVEBU_SOC_A38X ; - + }return MVEBU_SOC_UNKNOWN ; }
@@ -153,6 +156,9 @@ int print_cpuinfo(void)puts ("SoC: " );switch (devid) { +case SOC_MV78230_ID : +puts ("MV78230-" ); +break ;case SOC_MV78260_ID :puts ("MV78260-" );break ;
arch/arm/mach-mvebu/include/mach/soc.h +1 -0
@@ -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
@@ -199,7 +199,9 @@ u16 ctrl_model_get(void)* SoC version can't be autodetected. So we need to rely on a define * from the config system here. */ -#ifdef CONFIG_MV78260 +#if defined(CONFIG_MV78230 ) +return MV_78230_DEV_ID ; +#elif defined(CONFIG_MV78260 )return MV_78260_DEV_ID ;#else return MV_78460_DEV_ID ;
@@ -217,6 +219,8 @@ u32 get_line_cfg(u32 line_num, MV_BIN_SERDES_CFG *info)static int serdes_max_lines_get (void ) {switch (ctrl_model_get ()) { +case MV_78230_DEV_ID : +return 7 ;case MV_78260_DEV_ID :return 12 ;case MV_78460_DEV_ID :
Signature · 1 line
2.5.3
PATCH v3 8/10 mvebu: Add rudimental MV78230 support
Quoted 4 lines · Phil Sutter
This adds basic support for Marvell's MV78230 SoC which belongs to the Armada XP series.
Signed-off-by Phil Sutter <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/ca9f7185/attachment.sig>
PATCH v3 9/10 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/dts/Makefile | 3 +- arch/arm/dts/armada-xp-synology-ds414.dts | 337 ++++++++++++++++++++++++ arch/arm/mach-mvebu/Kconfig | 7 + arch/arm/mach-mvebu/serdes/axp/board_env_spec.h | 2 +- board/Synology/ds414/Makefile | 7 + board/Synology/ds414/ds414.c | 185 +++++++++++++ board/Synology/ds414/kwbimage.cfg | 12 + configs/ds414_defconfig | 18 ++ include/configs/ds414.h | 162 ++++++++++++ 9 files changed, 731 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/armada-xp-synology-ds414.dts create mode 100644 board/Synology/ds414/Makefile create mode 100644 board/Synology/ds414/ds414.c create mode 100644 board/Synology/ds414/kwbimage.cfg create mode 100644 configs/ds414_defconfig create mode 100644 include/configs/ds414.h
arch/arm/dts/Makefile +2 -1
@@ -51,7 +51,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \ armada-388-clearfog.dtb \ armada-388-gp.dtb \ armada-xp-gp.dtb \ - armada-xp-maxbcm.dtb + armada-xp-maxbcm.dtb \ + armada-xp-synology-ds414.dtb dtb-$(CONFIG_ARCH_UNIPHIER) += \ uniphier-ph1-ld4-ref.dtb \
arch/arm/dts/armada-xp-synology-ds414.dts new file +337 -0
337 lines not on this page · raw message
arch/arm/mach-mvebu/Kconfig +7 -0
@@ -38,6 +38,10 @@ config TARGET_DB_MV784MP_GP bool "Support db-mv784mp-gp" select MV78460 +config TARGET_DS414 + bool "Support Synology DS414" + select MV78230 + config TARGET_MAXBCM bool "Support maxbcm" select MV78460
@@ -48,18 +52,21 @@ config SYS_BOARD default "clearfog" if TARGET_CLEARFOG default "db-88f6820-gp" if TARGET_DB_88F6820_GP default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP + default "ds414" if TARGET_DS414 default "maxbcm" if TARGET_MAXBCM config SYS_CONFIG_NAME default "clearfog" if TARGET_CLEARFOG default "db-88f6820-gp" if TARGET_DB_88F6820_GP default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP + default "ds414" if TARGET_DS414 default "maxbcm" if TARGET_MAXBCM config SYS_VENDOR default "Marvell" if TARGET_DB_MV784MP_GP default "Marvell" if TARGET_DB_88F6820_GP default "solidrun" if TARGET_CLEARFOG + default "Synology" if TARGET_DS414 config SYS_SOC default "mvebu"
arch/arm/mach-mvebu/serdes/axp/board_env_spec.h +1 -1
@@ -44,7 +44,7 @@#define DB_784MP_GP_ID (RD_78460_SERVER_REV2_ID + 1)#define RD_78460_CUSTOMER_ID (DB_784MP_GP_ID + 1)#define MV_MAX_BOARD_ID (RD_78460_CUSTOMER_ID + 1) -#define INVALID_BAORD_ID 0xFFFFFFFF +#define INVALID_BOARD_ID 0xFFFFFFFF/* Sample at Reset */ #define MPP_SAMPLE_AT_RESET (id) (0x18230 + (id * 4))
board/Synology/ds414/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +# +# Copyright (C) 2015 Phil Sutter <[email protected]> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := ds414.o
board/Synology/ds414/ds414.c new file +185 -0
185 lines not on this page · raw message
board/Synology/ds414/kwbimage.cfg new file +12 -0
@@ -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 +162 -0
162 lines not on this page · raw message
Signature · 1 line
2.5.3
PATCH v3 9/10 mvebu: Support Synology DS414
Quoted 4 lines · Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
So, for the code:
But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/75dcd31f/attachment.sig>
PATCH v3 9/10 mvebu: Support Synology DS414
Hi Tom,
Quoted 7 lines · Tom Rini
Quoted 4 lines · Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
Quoted 7 lines
So, for the code:
Reviewed-by Tom Rini <[email protected]>But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!
I've already prepared a git branch, with all the pending Marvell mvebu related patches included. For Luka to pull from into the official Marvell U-boot git repo. And I've added Phil's patches as well. My personal feeling is, that all this additional text could be quite useful. That's why I would like to keep it in. But if you really feel that we should remove it, then I can definitely drop those passages.
Just let me know what you think.
Thanks,
Stefan
PATCH v3 9/10 mvebu: Support Synology DS414
Quoted 26 lines · Stefan Roese
Hi Tom,
Quoted 7 lines · Tom Rini
Quoted 4 lines · Phil Sutter
This adds support for the MV78230 based DS414 NAS by Synology. The relevant bits have been extracted from the 'synogpl-5004-armadaxp' package Synology kindly published, garnished with a fair amount of trial-and-error.
Quoted 7 lines
So, for the code:
Reviewed-by Tom Rini <[email protected]>But most of what follows should be in the "log" side, ie after the --- rather than the message itself. This can be fixed when applying, but if you end up needing to respin please reword this part, thanks!
I've already prepared a git branch, with all the pending Marvell mvebu related patches included. For Luka to pull from into the official Marvell U-boot git repo. And I've added Phil's patches as well. My personal feeling is, that all this additional text could be quite useful. That's why I would like to keep it in. But if you really feel that we should remove it, then I can definitely drop those passages.
Quoted 1 line
Just let me know what you think.
I'll live with it in the commit log, thanks.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/a1cd1e3a/attachment.sig>
PATCH v3 10/10 mvebu: ds414: 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.
--- board/Synology/common/Makefile | 7 ++ board/Synology/common/cmd_syno.c | 227 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 234 insertions(+) create mode 100644 board/Synology/common/Makefile create mode 100644 board/Synology/common/cmd_syno.c
board/Synology/common/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +# +# Copyright (C) 2015 Phil Sutter <[email protected]> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := cmd_syno.o
board/Synology/common/cmd_syno.c new file +227 -0
227 lines not on this page · raw message
Signature · 1 line
2.5.3
PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set
Hi Phil,
I'm preparing a branch for Luka to pull from. With all the pending mvebu patches included. And noticed a small issue with this patch. See below...
Quoted 245 lines · Phil Sutter
Synology keeps per item configuration in a dedicated 'partition' in SPI flash, namely the one named 'vendor' in DTS file. It contains the two NICs MAC addresses as well as the item's serial number. I didn't find a way to have this information extracted automatically, therefore implemented 'syno
populate_env' command which extracts the three values and puts them into environment. To make things permanent though, one has to 'saveenv'.Another command is 'syno
clk_gate', which allows to change the clock gating which is done in DS414 board file.Signed-off-by Phil Sutter <[email protected]>--- board/Synology/common/Makefile | 7 ++ board/Synology/common/cmd_syno.c | 227 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 234 insertions(+)create mode 100644 board/Synology/common/Makefile create mode 100644
board/Synology/common/cmd_syno.cboard/Synology/common/Makefile new file +7
-0@@ -0,0 +1,7 @@ +# +# Copyright (C) 2015 Phil Sutter <[email protected]> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := cmd_syno.oboard/Synology/common/cmd_syno.c new file +207
-0@@ -0,0 +1,227 @@ +/* +* Commands to deal with Synology specifics. +* +* Copyright (C) 2015 Phil Sutter <[email protected]> +* +* SPDX-License-Identifier: GPL-2.0+ +*/ + +#include <common.h> +#include <div64.h> +#include <spi.h> +#include <spi_flash.h> +#include <linux/mtd/mtd.h> + +#include <asm/io.h> +#include "../drivers/ddr/marvell/axp/ddr3_init.h" + +#define ETH_ALEN 6 +#define ETHADDR_MAX 4 +#define SYNO_SN_TAG "SN=" +#define SYNO_CHKSUM_TAG "CHK=" + + +static int do_syno_populate (int argc,char *const argv[]) +{ +unsigned int bus =CONFIG_SF_DEFAULT_BUS ; +unsigned int cs =CONFIG_SF_DEFAULT_CS ; +unsigned int speed =CONFIG_SF_DEFAULT_SPEED ; +unsigned int mode =CONFIG_SF_DEFAULT_MODE ; +struct spi_flash *flash; +unsigned long addr =0x80000 ;/* XXX: parameterize this? */ +loff_t offset =0x007d0000 ; +loff_t len =0x00010000 ; +char *buf, *bufp; +char var[128 ]; +char val[128 ]; +int ret, n; + +/* XXX: arg parsing to select flash here? */ + + flash =spi_flash_probe (bus, cs, speed, mode); +if (!flash) { +printf ("Failed to initialize SPI flash at %u:%u\n" , bus, cs); +return 1 ; + } + + buf =map_physmem (addr, len,MAP_WRBACK ); +if (!buf) { +puts ("Failed to map physical memory\n" ); +return 1 ; + } + + ret =spi_flash_read (flash, offset, len, buf); +if (ret) { +puts ("Failed to read from SPI flash\n" ); + goto out_unmap; + } + +for (n =0 ; n <ETHADDR_MAX ; n++) { +char ethaddr[ETH_ALEN ]; +int i, sum =0 ; +unsigned char csum =0 ; + +for (i =0 , bufp = buf + n *7 ; i <ETH_ALEN ; i++) { + sum += bufp[i]; + csum += bufp[i]; + ethaddr[i] = bufp[i]; + } +if (!sum)/* MAC address empty */ +continue ; +if (csum != bufp[i]) {/* seventh byte is checksum value */ +printf ("Invalid MAC address for interface %d!\n" , n); +continue ; + } +if (n ==0 ) +sprintf (var,"ethaddr" ); +else +sprintf (var,"eth%daddr" , n); +snprintf (val,sizeof (val) -1 , +"%02x:%02x:%02x:%02x:%02x:%02x" , + ethaddr[0 ], ethaddr[1 ], ethaddr[2 ], + ethaddr[3 ], ethaddr[4 ], ethaddr[5 ]); +printf ("parsed %s = %s\n" , var, val); +setenv (var, val); + } +if (!strncmp (buf +32 ,SYNO_SN_TAG ,strlen (SYNO_SN_TAG ))) { +char *snp, *csump; +int csum =0 ; +unsigned long c; + + snp = bufp = buf +32 +strlen (SYNO_SN_TAG ); +for (n =0 ; bufp[n] && bufp[n] !=',' ; n++) + csum += bufp[n]; + bufp[n] ='\0' ; + +/* should come right after, but you never know */ + bufp =strstr (bufp + n +1 ,SYNO_CHKSUM_TAG ); +if (!bufp) { +printf ("Serial number checksum tag missing!\n" ); + goto out_unmap; + } + + csump = bufp +=strlen (SYNO_CHKSUM_TAG ); +for (n =0 ; bufp[n] && bufp[n] !=',' ; n++) + ; + bufp[n] ='\0' ; + +if (strict_strtoul (csump,10 , &c) || c != csum) { +puts ("Invalid serial number found!\n" ); + ret =1 ; + goto out_unmap; + } +printf ("parsed SN = %s\n" , snp); +setenv ("SN" , snp); + }else {/* old style format */ +unsigned char csum =0 ; + +for (n =0 , bufp = buf +32 ; n <10 ; n++) + csum += bufp[n]; + +if (csum != bufp[n]) { +puts ("Invalid serial number found!\n" ); + ret =1 ; + goto out_unmap; + } + bufp[n] ='\0' ; +printf ("parsed SN = %s\n" , buf +32 ); +setenv ("SN" , buf +32 ); + } +out_unmap: +unmap_physmem (buf, len); +return ret; +} + +/* map bit position to function in POWER_MNG_CTRL_REG */ +static const char *const pwr_mng_bit_func[] = { +"audio" , +"ge3" ,"ge2" ,"ge1" ,"ge0" , +"pcie00" ,"pcie01" ,"pcie02" ,"pcie03" , +"pcie10" ,"pcie11" ,"pcie12" ,"pcie13" , +"bp" , +"sata0_link" ,"sata0_core" , +"lcd" , +"sdio" , +"usb0" ,"usb1" ,"usb2" , +"idma" ,"xor0" ,"crypto" , +NULL , +"tdm" , +"pcie20" ,"pcie30" , +"xor1" , +"sata1_link" ,"sata1_core" , +NULL , +}; + +static int do_syno_clk_gate (int argc,char *const argv[]) +{ +u32 pwr_mng_ctrl_reg =reg_read (POWER_MNG_CTRL_REG ); +const char *func, *state; +int i, val; + +if (argc <2 ) +return -1 ; + +if (!strcmp (argv[1 ],"get" )) { +puts ("Clock Gating:\n" ); +for (i =0 ; i <32 ; i++) { + func = pwr_mng_bit_func[i]; +if (!func) +continue ; + state = pwr_mng_ctrl_reg & (1 << i) ?"ON" :"OFF" ; +printf ("%s:\t\t%s\n" , func, state); + } +return 0 ; + } +if (argc <4 ) +return -1 ; +if (!strcmp (argv[1 ],"set" )) { + func = argv[2 ]; + state = argv[3 ]; +for (i =0 ; i <32 ; i++) { +if (!pwr_mng_bit_func[i]) +continue ; +if (!strcmp (func, pwr_mng_bit_func[i])) +break ; + } +if (i ==32 ) { +printf ("Error: name '%s' not known\n" , func); +return -1 ; + } + val = state[0 ] !='0' ; + pwr_mng_ctrl_reg |= (val << i); + pwr_mng_ctrl_reg &= ~(!val << i); +reg_write (POWER_MNG_CTRL_REG , pwr_mng_ctrl_reg); + } +return 0 ; +} + +static int do_syno (cmd_tbl_t *cmdtp,int flag, +int argc,char *const argv[]) +{ +const char *cmd; +int ret; + +if (argc <2 ) + goto usage; + + cmd = argv[1 ];
board/Synology/common/cmd_syno.c line 217
Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10
-0+ --argc; + ++argv; + +if (!strcmp (cmd,"populate_env" )) + ret =do_syno_populate (argc, argv); +else if (!strcmp (cmd,"clk_gate" )) + ret =do_syno_clk_gate (argc, argv); + +if (ret !=-1 ) +return ret;
Here I get this warning:
board/Synology/common/cmd_syno.c: In function 'do_syno':board/Synology/common/cmd_syno.c:216:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (ret != -1)
^
I've changed this to init ret to 0 in my branch. Let me know if this is okay with you.
Thanks,
Stefan
PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set
Hi Stefan,
Quoted 5 lines · Stefan Roese
I'm preparing a branch for Luka to pull from. With all the pending mvebu patches included. And noticed a small issue with this patch. See below...
On 25.12.2015 14:41, Phil Sutter wrote:
[...]
Quoted 23 lines
Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10
-0+static int do_syno (cmd_tbl_t *cmdtp,int flag, +int argc,char *const argv[]) +{ +const char *cmd; +int ret; + +if (argc <2 ) + goto usage; + + cmd = argv[1 ];board/Synology/common/cmd_syno.c line 217
Quoted 10 lines
board/Synology/common/cmd_syno.c new file +10
-0+ --argc; + ++argv; + +if (!strcmp (cmd,"populate_env" )) + ret =do_syno_populate (argc, argv); +else if (!strcmp (cmd,"clk_gate" )) + ret =do_syno_clk_gate (argc, argv); + +if (ret !=-1 ) +return ret;Here I get this warning:
Quoted 7 lines
board/Synology/common/cmd_syno.c: In function 'do_syno':board/Synology/common/cmd_syno.c:216:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (ret != -1)^I've changed this to init ret to 0 in my branch. Let me know if this is okay with you.
Yes, sure! I have to admit, I didn't spend much time on this file. It was always merely for fixing the "real" issues.
Thanks, Phil
PATCH v3 10/10 mvebu: ds414: Implement Synology specific command set
In reply to Phil SutterQuoted 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]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160113/b7929b0f/attachment.sig>