updates for Keymile Marvell boards
cover updates for Keymile Marvell boards
This series adds support for 2 new Kirkwood boards at Keymile: kmnusa and kmcoge5un. All the previously supported boards that had a proper config file now are all supported by the generic km_kirkwood.h config file.
This series also adds support for the environment variables in the SPI NOR Flash, for a skippable FPGA download through the BOCO2 CPLD, and for the configuration of a managed Marvell switch that is used on kmnusa.
This series also corrects a bug caused by accessing global static tables in board_early_init_f that is called before relocation which must be avoided.
Holger Brunck (6):
arm/km: add kmnusa board support
arm/km: add kmcoge5un board support
arm/km: convert mgcoge3un target to km_kirkwood arm/km: remove portl2.h and use km_kirkwood instead arm/km: cleanup km_kirkwood boards
arm/km: remove spi toggle command
Thomas Herzmann (2):
arm/km: add implementation for read_dip_switch
arm/km: fix testpin detection for kmcoge5un
Valentin Longchamp (12):
arm/km: enable spi claim bus
arm/km: use correct kw_gpio function for NAND/SPI switching arm/kirkwood: protect the ENV_SPI #defines
arm/km: correct init of 88e6352 switch in the reset_phy function arm/km: enable BOCO2 FPGA download support
arm/km: redefine piggy 4 reg names to avoid conflicts arm/km: add support for external switch configuration arm/km: enable external switch configuration for kmnusa arm/km: skip FPGA config when already configured arm/km: support the 2 PCIe fpga resets
arm/km: implement weak function board_spi_clam_bus/release arm/km: remove calls to kw_gpio_* in board_early_init_f
MAINTAINERS | 2 + arch/arm/include/asm/arch-kirkwood/config.h | 12 +- board/keymile/common/common.h | 5 + board/keymile/km_arm/128M16-1.cfg | 294 +++++++++++++++++++++++++ board/keymile/km_arm/256M8-1.cfg | 296 +++++++++++++++++++++++++ board/keymile/km_arm/Makefile | 8 + board/keymile/km_arm/fpga_config.c | 256 ++++++++++++++++++++++ board/keymile/km_arm/km_arm.c | 169 +++++++++------ board/keymile/km_arm/managed_switch.c | 316 +++++++++++++++++++++++++++ board/keymile/km_arm/managed_switch.h | 106 +++++++++ boards.cfg | 10 +- include/configs/km/km_arm.h | 57 ++++- include/configs/km_kirkwood.h | 154 ++++++++++++- include/configs/mgcoge3un.h | 87 -------- include/configs/portl2.h | 85 ------- 15 files changed, 1583 insertions(+), 274 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfg create mode 100644 board/keymile/km_arm/256M8-1.cfg create mode 100644 board/keymile/km_arm/fpga_config.c create mode 100644 board/keymile/km_arm/managed_switch.c create mode 100644 board/keymile/km_arm/managed_switch.h delete mode 100644 include/configs/mgcoge3un.h delete mode 100644 include/configs/portl2.h
PATCH 1/20 arm/km: enable spi claim bus
This is required for all our keymile ARM boards. The selected MPPs are the default one for the SPI controller, thus the 0x0 definition.
--- include/configs/km/km_arm.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
include/configs/km/km_arm.h +3 -0
@@ -227,6 +227,9 @@ int get_scl(void);#define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO +/* SPI bus claim MPP configuration */ +#define CONFIG_SYS_KW_SPI_MPP 0x0 +#define FLASH_GPIO_PIN 0x00010000#define MTDIDS_DEFAULT "nand0=orion_nand"
Signature · 1 line
1.7.1
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
In reply to Valentin LongchampThis used to be done with registers direct access, which is not clear and optimal.
--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++------------------- include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)
board/keymile/km_arm/km_arm.c +28 -25
@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );
@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) { + kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ; + }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + } + +/* Multi-Purpose Pins Functionality configuration */ +kirkwood_mpp_conf (kwmpp_config,NULL ); +kw_gpio_set_value (KM_FLASH_GPIO_PIN , gpio_value); + +return 0 ; +} +#if defined(CONFIG_CMD_SF )int do_spi_toggle (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) { -u32 tmp;if (argc <2 )return cmd_usage (cmdtp);if ((strcmp (argv[1 ],"off" ) ==0 )) {printf ("SPI FLASH disabled, NAND enabled\n" ); -/* Multi-Purpose Pins Functionality configuration */ - kwmpp_config[0 ] =MPP0_NF_IO2 ; - kwmpp_config[1 ] =MPP1_NF_IO3 ; - kwmpp_config[2 ] =MPP2_NF_IO4 ; - kwmpp_config[3 ] =MPP3_NF_IO5 ; - -kirkwood_mpp_conf (kwmpp_config,NULL ); - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); +km_hw_spi_bus_claim (0 ); }else if ((strcmp (argv[1 ],"on" ) ==0 )) {printf ("SPI FLASH enabled, NAND disabled\n" ); -/* Multi-Purpose Pins Functionality configuration */ - kwmpp_config[0 ] = MPP0_SPI_SCn; - kwmpp_config[1 ] =MPP1_SPI_MOSI ; - kwmpp_config[2 ] =MPP2_SPI_SCK ; - kwmpp_config[3 ] =MPP3_SPI_MISO ; - -kirkwood_mpp_conf (kwmpp_config,NULL ); - tmp =readl (KW_GPIO0_BASE ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE ); +km_hw_spi_bus_claim (1 ); }else {return cmd_usage (cmdtp); }
include/configs/km/km_arm.h +1 -0
@@ -231,6 +231,7 @@ int get_scl(void);#define CONFIG_SYS_KW_SPI_MPP 0x0#define FLASH_GPIO_PIN 0x00010000 +#define KM_FLASH_GPIO_PIN 16#define MTDIDS_DEFAULT "nand0=orion_nand"/* test-only: partitioning needs some tuning, this is just for tests */
Signature · 1 line
1.7.1
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
Quoted 57 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingThis used to be done with registers direct access, which is not clear and optimal.
Signed-off-by Valentin Longchamp <[email protected]>Signed-off-by Holger Brunck <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++----------- -------- include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)board/keymile/km_arm/km_arm.c +8
-6@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) {
board/keymile/km_arm/km_arm.c int board_init(void) · line 298
Quoted 10 lines
board/keymile/km_arm/km_arm.c +10
-0+ kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ; + }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + }
NACK...
Regards..
Prafulla . . .
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
Quoted 61 lines · Prafulla Wadaskar
Quoted 61 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingThis used to be done with registers direct access, which is not clear and optimal.
Signed-off-by Valentin Longchamp <[email protected]>Signed-off-by Holger Brunck <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++----------- -------- include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)board/keymile/km_arm/km_arm.c +12
-6@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) { + kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ;
Quoted 9 lines
board/keymile/km_arm/km_arm.c int board_init(void) · line 298
Quoted 6 lines
board/keymile/km_arm/km_arm.c +6
-0+ }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + }NACK...
Could you please be a bit more verbose. Why do you NACK this? This code is only related to our boards...
Regards
Holger
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
Quoted 85 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:08
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 11 lines · Prafulla Wadaskar
Quoted 11 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 1 line
Quoted 1 line
This used to be done with registers direct access, which is not
clear
Quoted 8 lines
Quoted 8 lines
and optimal.
Signed-off-by Valentin Longchamp <[email protected]>Signed-off-by Holger Brunck <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++-----------
Quoted 41 lines
Quoted 41 lines
--------
include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)board/keymile/km_arm/km_arm.c +12
-6@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) { + kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ;Quoted 9 lines
board/keymile/km_arm/km_arm.c int board_init(void) · line 298
Quoted 6 lines
board/keymile/km_arm/km_arm.c +6
-0+ }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + }NACK...
Quoted 3 lines
Could you please be a bit more verbose. Why do you NACK this? This code is only
related to our boards...
Dear Holger
We have already patches for Kirkwood-spi in place that address this. So we have to use this framework.
Ref: http://lists.denx.de/pipermail/u-boot/2012-June/125574.html
Regards..
Prafulla . . .
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
Quoted 89 lines · Prafulla Wadaskar
Quoted 85 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:08
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 11 lines · Prafulla Wadaskar
Quoted 11 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 1 line
Quoted 1 line
This used to be done with registers direct access, which is not
clear
Quoted 8 lines
Quoted 8 lines
and optimal.
Signed-off-by Valentin Longchamp <[email protected]>Signed-off-by Holger Brunck <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++-----------
Quoted 41 lines
Quoted 41 lines
--------
include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)board/keymile/km_arm/km_arm.c +12
-6@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) { + kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ;Quoted 9 lines
board/keymile/km_arm/km_arm.c int board_init(void) · line 298
Quoted 6 lines
board/keymile/km_arm/km_arm.c +6
-0+ }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + }NACK...
Quoted 3 lines
Could you please be a bit more verbose. Why do you NACK this? This code is only
related to our boards...
Quoted 6 lines
Dear Holger
We have already patches for Kirkwood-spi in place that address this. So we have to use this framework.Ref: http://lists.denx.de/pipermail/u-boot/2012-June/125574.html
ok I see what you mean. We make use of it later on:
[PATCH 18/20] arm/km: implement weak function board_spi_clam_bus/release I'll squash this one together with 02/20 then it is more clear.
Regards
Holger
PATCH 2/20 arm/km: use correct kw_gpio function for NAND/SPI switching
Quoted 94 lines · Holger Brunck
Quoted 93 lines · Prafulla Wadaskar
Quoted 85 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:08
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 11 lines · Prafulla Wadaskar
Quoted 11 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 02/20] arm/km: use correctkw_gpiofunction for NAND/SPI switchingQuoted 1 line
Quoted 1 line
This used to be done with registers direct access, which is not
clear
Quoted 8 lines
Quoted 8 lines
and optimal.
Signed-off-by Valentin Longchamp <[email protected]>Signed-off-by Holger Brunck <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 53 +++++++++++++++++++++-----------
Quoted 41 lines
Quoted 41 lines
--------
include/configs/km/km_arm.h | 1 + 2 files changed, 29 insertions(+), 25 deletions(-)board/keymile/km_arm/km_arm.c +12
-6@@ -247,15 +247,12 @@ int board_early_init_f(void)kirkwood_mpp_conf (kwmpp_config,NULL );/* -* The FLASH_GPIO_PIN switches between using a +* The KM_FLASH_GPIO_PIN switches between using a * NAND or a SPI FLASH. Set this pin on start * to NAND mode. */ - tmp =readl (KW_GPIO0_BASE ); -writel (tmp |FLASH_GPIO_PIN ,KW_GPIO0_BASE ); - tmp =readl (KW_GPIO0_BASE +4 ); -writel (tmp & (~FLASH_GPIO_PIN ) ,KW_GPIO0_BASE +4 ); - +kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 ); +kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 );#if defined(CONFIG_SOFT_I2C )/* init the GPIO for I2C Bitbang driver */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );@@ -284,35 +281,41 @@ int board_init(void)return 0 ; } +int km_hw_spi_bus_claim (int on) +{ +int gpio_value = !on; + +if (on) { + kwmpp_config[0 ] = MPP0_SPI_SCn; + kwmpp_config[1 ] =MPP1_SPI_MOSI ; + kwmpp_config[2 ] =MPP2_SPI_SCK ; + kwmpp_config[3 ] =MPP3_SPI_MISO ;Quoted 9 lines
board/keymile/km_arm/km_arm.c int board_init(void) · line 298
Quoted 6 lines
board/keymile/km_arm/km_arm.c +6
-0+ }else { + kwmpp_config[0 ] =MPP0_NF_IO2 ; + kwmpp_config[1 ] =MPP1_NF_IO3 ; + kwmpp_config[2 ] =MPP2_NF_IO4 ; + kwmpp_config[3 ] =MPP3_NF_IO5 ; + }NACK...
Quoted 3 lines
Could you please be a bit more verbose. Why do you NACK this? This code is only
related to our boards...Dear Holger
We have already patches for Kirkwood-spi in place that address this. So we have to use this framework.
Quoted 7 lines
Quoted 2 lines
Ref: http://lists.denx.de/pipermail/u-boot/2012-June/125574.html
ok I see what you mean. We make use of it later on:
[PATCH 18/20] arm/km: implement weak function board_spi_clam_bus/release I'll squash this one together with 02/20 then it is more clear.
ok I'll send an update of the SPI feature update soon as a standalone patch. I'll squash
[PATCH 01/20] arm/km: enable spi claim bus
[PATCH 02/20] arm/km: use correct kw_gpio function for NAND/SPI switching [PATCH 18/20] arm/km: implement weak function board_spi_clam_bus/release [PATCH 19/20] arm/km: remove spi toggle command
into it and then it is much more clear what the patch does.
Updates with your inputs of the remaining patches will also follow.
Regards
Holger
PATCH 3/20 arm/kirkwood: protect the ENV_SPI #defines
In reply to Valentin LongchampSo that they can be redefined by some boards specific values.
--- arch/arm/include/asm/arch-kirkwood/config.h | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)
arch/arm/include/asm/arch-kirkwood/config.h +9 -3
@@ -82,9 +82,15 @@#ifdef CONFIG_CMD_SF #define CONFIG_HARD_SPI 1#define CONFIG_KIRKWOOD_SPI 1 -#define CONFIG_ENV_SPI_BUS 0 -#define CONFIG_ENV_SPI_CS 0 -#define CONFIG_ENV_SPI_MAX_HZ 50000000/*50Mhz */ +#ifndef CONFIG_ENV_SPI_BUS +# define CONFIG_ENV_SPI_BUS 0 +#endif +#ifndef CONFIG_ENV_SPI_CS +# define CONFIG_ENV_SPI_CS 0 +#endif +#ifndef CONFIG_ENV_SPI_MAX_HZ +# define CONFIG_ENV_SPI_MAX_HZ 50000000 +#endif #endif /*
Signature · 1 line
1.7.1
PATCH 4/20 arm/km: add kmnusa board support
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.
--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294 +++++++++++++++++++++++++++++++++++++ board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfg
MAINTAINERS +1 -0
@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]> km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC) mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC)
board/keymile/km_arm/128M16-1.cfg new file +294 -0
294 lines not on this page · raw message
board/keymile/km_arm/km_arm.c +5 -4
@@ -133,10 +133,11 @@ int startup_allowed(void) }#endif -#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ + defined(CONFIG_KM_PIGGY4_88E6352 ))/* -* These two boards have always ethernet present. Its connected to the mv -* switch. +* All boards with PIGGY4 connected via a simple switch have ethernet always +* present. */ int ethernet_present (void ) {
@@ -384,7 +385,7 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#else +#elif !defined(CONFIG_KM_PIGGY4_88E6352)/* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {
boards.cfg +1 -0
@@ -140,6 +140,7 @@ pogo_e02 arm arm926ejs - clouden dns325 arm arm926ejs - d-link kirkwood km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX +kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA mgcoge3un arm arm926ejs km_arm keymile kirkwood portl2 arm arm926ejs km_arm keymile kirkwood inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2
include/configs/km/km_arm.h +35 -9
75 lines not on this page · raw message
include/configs/km_kirkwood.h +56 -11
87 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 4/20 arm/km: add kmnusa board support
Quoted 21 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 04/20] arm/km: add kmnusa board supportFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.
Quoted 8 lines
Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294+++++++++++++++++++++++++++++++++++++
Please avoid file names starting with numbers.
Quoted 12 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 4 lines
MAINTAINERS +1
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]> km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)
Again.... I would like to suggest to separate out new boards addition, bugfixes/updates specific to km_*boards and generic kirkwood specific patches.
It's always faster to merger small patch series that big one.
Quoted 302 lines
MAINTAINERS +0
-0mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC)board/keymile/km_arm/128M16-1.cfg new file +142
-0@@ -0,0 +1,294 @@ +# +# (C) Copyright 2010 +# Heiko Schocher, DENX Software Engineering, hs at denx.de. +# +# (C) Copyright 2012 +# Valentin Longchamp, Keymile AG, valentin.longchamp at keymile.com +# Stefan Bigler, Keymile AG, stefan.bigler at keymile.com +# +# (C) Copyright 2012 +# See file CREDITS for list of people who contributed to this +# project. +# +# 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. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD10000 0x01112222 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_SI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_SO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] +# bit 7-4: 0, MPPSel9 GPIO[9] +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 UA1_TXD +# bit 27-24: 3, MPPSel14 UA1_RXD +# bit 31-28: 0, MPPSel15 GPIO[15] + +DATA 0xFFD10008 0x00001100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 12-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14: 0, Reserved +# bit 15: 0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x66666666 # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserve +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4 + +DATA 0xFFD20138 0x66666666 # L2 RAM Timing 1 Register +# bit 15-0: ???, Reserve +# bit 17-16: 2, ECC RAM RTC RAM0 +# bit 19-18: 1, ECC RAM WTC RAM0 +# bit 31-20: ???,Reserve + +DATA 0xFFD20154 0x00000200 # CPU RAM Management Control3 Register +# bit 23-0: 0x000200, Addr Config tuning +# bit 31-24: 0, Reserved + +# ??? Missing register # CPU RAM Management Control2 Register + +DATA 0xFFD2014C 0x00001C00 # CPU RAM Management Control1 Register +# bit 15-0: 0x1C00, Opmux Tuning +# bit 31-16: 0, Pc Dp Tuning + +DATA 0xFFD20148 0x00000001 # CPU RAM Management Control0 Register +# bit 1-0: 1, addr clk tune +# bit 3-2: 0, reserved +# bit 5-4: 0, dtcmp clk tune +# bit 7-6: 0, reserved +# bit 9-8: 0, macdrv clk tune +# bit 11-10: 0, opmuxgm2 clk tune +# bit 15-14: 0, rf clk tune +# bit 17-16: 0, rfbypass clk tune +# bit 19-18: 0, pc dp clk tune +# bit 23-20: 0, icache clk tune +# bit 27:24: 0, dcache clk tune +# bit 31:28: 0, regfile tunin + +# SDRAM initalization +DATA 0xFFD01400 0x430004E0 # SDRAM Configuration Register +# bit 13-0: 0x4E0, DDR2 clks refresh rate +# bit 14: 0, reserved +# bit 15: 0, reserved +# bit 16: 0, CPU to Dram Write buffer policy +# bit 17: 0, Enable Registered DIMM or Equivalent Sampling Logic +# bit 19-18: 0, reserved +# bit 23-20: 0, reserved +# bit 24: 1, enable exit self refresh mode on DDR access +# bit 25: 1, required +# bit 29-26: 0, reserved +# bit 31-30: 1, reserved + +DATA 0xFFD01404 0x36543000 # DDR Controller Control Low +# bit 3-0: 0, reserved +# bit 4: 0, 2T mode =addr/cmd in same cycle +# bit 5: 0, clk is driven during self refresh, we don't care forAPX
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# bit 6: 0, use recommended falling edge of clk for addr/cmd +# bit 7-11: 0, reserved +# bit 12-13: 1, reserved, required 1 +# bit 14: 0, input buffer always powered up +# bit 17-15: 0, reserved +# bit 18: 1, cpu lock transaction enabled +# bit 19: 0, reserved +# bit 23-20: 5, recommended value for CL=4 and STARTBURST_DELdisabled bit31=0
+# bit 27-24: 6, CL+1, STARTBURST sample stages, for freqs 200-399MHz, unbuffered DIMMboard/keymile/km_arm/128M16-1.cfg new file +95
-0+# bit 30-28: 3, required +# bit 31: 0,no additional STARTBURST delay + +DATA 0xFFD01408 0x2302444e # DDR Timing (Low) (active cycles value +1) +# bit 3-0: 0xE, TRAS, 15 clk (45 ns) +# bit 7-4: 0x4, TRCD, 5 clk (15 ns) +# bit 11-8: 0x4, TRP, 5 clk (15 ns) +# bit 15-12: 0x4, TWR, 5 clk (15 ns) +# bit 19-16: 0x2, TWTR, 3 clk (7.5 ns) +# bit 20: 0, extended TRAS msb +# bit 23-21: 0, reserved +# bit 27-24: 0x3, TRRD, 4 clk (10 ns) +# bit 31-28: 0x2, TRTP, 3 clk (7.5 ns) + +DATA 0xFFD0140C 0x0000003e # DDR Timing (High) +# bit 6-0: 0x3E, TRFC, 63 clk (195 ns) +# bit 8-7: 0, TR2R +# bit 10-9: 0, TR2W +# bit 12-11: 0, TW2W +# bit 31-13: 0, reserved + +DATA 0xFFD01410 0x00000001 # DDR Address Control +# bit 1-0: 1, Cs0width=x16 +# bit 3-2: 0, Cs0size=2Gb +# bit 5-4: 0, Cs1width=nonexistent +# bit 7-6: 0, Cs1size =nonexistent +# bit 9-8: 0, Cs2width=nonexistent +# bit 11-10: 0, Cs2size =nonexistent +# bit 13-12: 0, Cs3width=nonexistent +# bit 15-14: 0, Cs3size =nonexistent +# bit 16: 0, Cs0AddrSel +# bit 17: 0, Cs1AddrSel +# bit 18: 0, Cs2AddrSel +# bit 19: 0, Cs3AddrSel +# bit 31-20: 0, required + +DATA 0xFFD01414 0x00000000 # DDR Open Pages Control +# bit 0: 0, OpenPage enabled +# bit 31-1: 0, required + +DATA 0xFFD01418 0x00000000 # DDR Operation +# bit 3-0: 0, DDR cmd +# bit 31-4: 0, required + +DATA 0xFFD0141C 0x00000652 # DDR Mode +# bit 2-0: 2, Burst Length = 4 +# bit 3: 0, Burst Type +# bit 6-4: 5, CAS Latency = 5 +# bit 7: 0, Test mode +# bit 8: 0, DLL Reset +# bit 11-9: 3, Write recovery for auto-precharge must be 3 +# bit 12: 0, Active power down exit time, fast exit +# bit 14-13: 0, reserved +# bit 31-15: 0, reserved + +DATA 0xFFD01420 0x00000006 # DDR Extended Mode +# bit 0: 0, DDR DLL enabled +# bit 1: 1, DDR drive strength reduced +# bit 2: 1, DDR ODT control lsb, 75 ohm termination [RTT0] +# bit 5-3: 0, required +# bit 6: 0, DDR ODT control msb, 75 ohm termination [RTT1] +# bit 9-7: 0, required +# bit 10: 0, differential DQS enabled +# bit 11: 0, required +# bit 12: 0, DDR output buffer enabled +# bit 31-13: 0 required + +DATA 0xFFD01424 0x0000F17F # DDR Controller Control High +# bit 2-0: 7, required +# bit 3: 1, MBUS Burst Chop disabled +# bit 6-4: 7, required +# bit 7: 0, reserved +# bit 8: 1, add sample stage required for f > 266 MHz +# bit 9: 0, no half clock cycle addition to dataout +# bit 10: 0, 1/4 clock cycle skew enabled for addr/ctl signals +# bit 11: 0, 1/4 clock cycle skew disabled for write mesh +# bit 15-12:0xf, required +# bit 31-16: 0, required + +DATA 0xFFD01428 0x00084520 # DDR2 SDRAM Timing Low +# bit 3-0: 0, required +# bit 7-4: 2, M_ODT assertion 2 cycles after read start command +# bit 11-8: 5, M_ODT de-assertion 5 cycles after read start command +# (ODT turn off delay 2,5 clk cycles) +# bit 15-12: 4, internal ODT time based on bit 7-4 +# with the considered SDRAM internal delay +# bit 19-16: 8, internal ODT de-assertion based on bit 11-8 +# with the considered SDRAM internal delay +# bit 31-20: 0, required + +DATA 0xFFD0147c 0x00008452 # DDR2 SDRAM Timing High +# bit 3-0: 2, M_ODT assertion same as bit 11-8 +# bit 7-4: 5, M_ODT de-assertion same as bit 15-12 +# bit 11-8: 4, internal ODT assertion 2 cycles after write startcommand
board/keymile/km_arm/128M16-1.cfg new file +2
-0+# with the considered SDRAM internal delay +# bit 15-12: 8, internal ODT de-assertion 5 cycles after write startcommand
board/keymile/km_arm/128M16-1.cfg new file +19
-0+# with the considered SDRAM internal delay + +DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0 +# bit 23-0: 0, reserved +# bit 31-24: 0, CPU CS Window0 Base Address, addr bits [31:24] + +DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size +# bit 0: 1, Window enabled +# bit 1: 0, Write Protect disabled +# bit 3-2: 0, CS0 hit selected +# bit 23-4:ones, required +# bit 31-24: 0x0F, Size (i.e. 256MB) + +DATA 0xFFD0150C 0x00000000 # CS[1]n Size, window disabled +DATA 0xFFD01514 0x00000000 # CS[2]n Size, window disabled +DATA 0xFFD0151C 0x00000000 # CS[3]n Size, window disabled + +DATA 0xFFD01494 0x00010000 # DDR ODT Control (Low) +# bit 3-0: 0, ODT0Rd, MODT[0] not asserted during read from DRAMCS0
board/keymile/km_arm/128M16-1.cfg new file +15
-0+# bit 7-4: 0, ODT0Rd, MODT[1] not asserted +# bit 11-8: 0, required +# big 15-11: 0, required +# bit 19-16: 1, ODT0Wr, MODT[0] asserted during write to DRAM CS0 +# bit 23-20: 0, ODT0Wr, MODT[1] not asserted +# bit 27-24: 0, required +# bit 31-28: 0, required + +DATA 0xFFD01498 0x00000000 # DDR ODT Control (High) +# bit 1-0: 0, ODT0 controlled by ODT Control (low) register above +# bit 3-2: 0, ODT1 controlled by register +# bit 31-4: 0, required + +DATA 0xFFD0149C 0x0000E801 # CPU ODT Control +# bit 3-0: 1, ODTRd, Internal ODT asserted during read from DRAMbank0
+# bit 7-4: 0, ODTWr, Internal ODT not asserted during write to
DRAMboard/keymile/km_arm/128M16-1.cfg new file +1
-0+# bit 9-8: 0, ODTEn, controlled by ODTRd and ODTWr
board/keymile/km_arm/128M16-1.cfg line 293
Quoted 10 lines
board/keymile/km_arm/128M16-1.cfg new file +10
-0+# bit 11-10: 2, DQ_ODTSel. ODT select turned on, 75 ohm +# bit 13-12: 2, STARTBURST ODT buffer selected, 75 ohm +# bit 14: 1, STARTBURST ODT enabled +# bit 15: 1, Use ODT Block + +DATA 0xFFD01480 0x00000001 # DDR Initialization Control +# bit 0: 1, enable DDR init upon this register write +# bit 31-1: 0, reserved + +# End of Header extension
Is this configuration similar to any other board already mainlined? if there is small delta like RAM/flash sizes then you can manage it through board_init()
Just think of it.
Quoted 39 lines
board/keymile/km_arm/128M16-1.cfg new file +1
-0+DATA 0x0 0x0board/keymile/km_arm/km_arm.c +2
-2@@ -133,10 +133,11 @@ int startup_allowed(void) }#endif -#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ + defined(CONFIG_KM_PIGGY4_88E6352 ))/* -* These two boards have always ethernet present. Its connected to the mv
- * switch.
+ * All boards with PIGGY4 connected via a simple switch have ethernet always
+ * present.
*/
intethernet_present(void)
{board/keymile/km_arm/km_arm.c +1
-1@@ -384,7 +385,7 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#else +#elif !defined(CONFIG_KM_PIGGY4_88E6352)/* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {boards.cfg +0
-1@@ -140,6 +140,7 @@ pogo_e02 arm arm926ejs - clouden dns325 arm arm926ejs -
Quoted 6 lines
d-link kirkwood
km_kirkwoodarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
km_kirkwood_pciarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
+kmnusa arm arm926ejskm_arm
Why name is not km_nusa?
Quoted 12 lines
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood
portl2 arm arm926ejskm_arm
keymile kirkwood
inetspace_v2arm arm926ejsnetspace_v2
LaCie kirkwood lacie_kw:INETSPACE_V2include/configs/km/km_arm.h +0
-0
include/configs/km/km_arm.h line 66
Quoted 10 lines
include/configs/km/km_arm.h +7
-0@@ -57,6 +57,13 @@#define CONFIG_CMD_SF #define CONFIG_SOFT_I2C /* I2C bit-banged */ +#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_ENV_SPI_BUS 0 +#define CONFIG_ENV_SPI_CS 0 +#define CONFIG_ENV_SPI_MAX_HZ 5000000 +#define CONFIG_ENV_SPI_MODE SPI_MODE_3 +#endif +
Do you still need this? Your patch 03/20 takes care of this.
Quoted 172 lines
include/configs/km/km_arm.h +0
-0#include "asm/arch/config.h" #define CONFIG_SYS_TEXT_BASE 0x07d00000/* code address before reloc */
include/configs/km/km_arm.h +2
-0@@ -211,6 +218,15 @@ int get_scl(void);/* * Environment variables configurations */ +#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_ENV_IS_IN_SPI_FLASH /* use SPI-Flash for environment vars */
include/configs/km/km_arm.h +2
-0+#define CONFIG_ENV_OFFSET 0xc0000/* no bracets! */ +#define CONFIG_ENV_SIZE 0x02000/* Size of Environment */
include/configs/km/km_arm.h +5
-0+#define CONFIG_ENV_SECT_SIZE 0x10000 +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + \ + CONFIG_ENV_SECT_SIZE) +#define CONFIG_ENV_TOTAL_SIZE 0x20000/* no bracets! */ +#else #define CONFIG_ENV_IS_IN_EEPROM /* use EEPROM for environment vars */
#defineCONFIG_SYS_DEF_EEPROM_ADDR0x50
#defineCONFIG_ENV_EEPROM_IS_ON_I2Cinclude/configs/km/km_arm.h +19
-9@@ -218,11 +234,11 @@ int get_scl(void);#define CONFIG_ENV_OFFSET 0x0/* no bracets! */ #define CONFIG_ENV_SIZE (0x2000 - CONFIG_ENV_OFFSET)#define CONFIG_I2C_ENV_EEPROM_BUS KM_ENV_BUS "\0" - -/* offset redund: (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) */ -#define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_OFFSET_REDUND 0x2000/* no bracets! */ #define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE) +#endif + +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO @@ -245,17 +261,27 @@ int get_scl(void);"sf write ${load_addr_r} 0 ${filesize};" \ "spi off\0" -/* -* Default environment variables - */ -#define CONFIG_EXTRA_ENV_SETTINGS \ - CONFIG_KM_DEF_ENV \ +#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_KM_NEW_ENV \ + "newenv=sf probe 0;" \ + "sf erase " xstr(CONFIG_ENV_OFFSET) " " \ + xstr(CONFIG_ENV_TOTAL_SIZE)"\0" +#else +#define CONFIG_KM_NEW_ENV \ "newenv=setenv addr 0x100000 && " \ "i2c dev 1; mw.b ${addr} 0 4 && " \ "eeprom write " xstr(CONFIG_SYS_DEF_EEPROM_ADDR) \ " ${addr} " xstr(CONFIG_ENV_OFFSET) " 4 && " \ "eeprom write " xstr(CONFIG_SYS_DEF_EEPROM_ADDR) \ - " ${addr} " xstr(CONFIG_ENV_OFFSET_REDUND) " 4\0" \ + " ${addr} " xstr(CONFIG_ENV_OFFSET_REDUND) " 4\0" +#endif + +/* +* Default environment variables +*/ +#define CONFIG_EXTRA_ENV_SETTINGS \ + CONFIG_KM_DEF_ENV \ + CONFIG_KM_NEW_ENV \ "arch=arm\0" \ "EEprom_ivm=" KM_IVM_BUS "\0" \ ""include/configs/km_kirkwood.h +29
-11@@ -6,8 +6,9 @@* (C) Copyright 2009 * Stefan Roese, DENX Software Engineering, sr at denx.de. * -* (C) Copyright 2011 -* Holger Brunck, Keymile GmbH Hannover, holger.brunck at keymile.de +* (C) Copyright 2011-2012 +* Holger Brunck, Keymile GmbH Hannover, holger.brunck at keymile.com +* Valentin Longchamp, Keymile AG, valentin.longchamp at keymile.com * * See file CREDITS for list of people who contributed to this * project. @@ -36,23 +37,67 @@#ifndef _CONFIG_KM_KIRKWOOD_H#define _CONFIG_KM_KIRKWOOD_H -/* include common defines/options for all arm based Keymile boards */ -#include "km/km_arm.h" - -/* -* Version number information -*/ #if defined(CONFIG_KM_KIRKWOOD ) -#define CONFIG_IDENT_STRING "\nKeymile Kirkwood" +#define CONFIG_IDENT_STRING "\nKeymile Kirkwood"#undef CONFIG_KIRKWOOD_PCIE_INIT +#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ #elif defined(CONFIG_KM_KIRKWOOD_PCI ) -#define CONFIG_IDENT_STRING "\nKeymile Kirkwood PCI" +#define CONFIG_IDENT_STRING "\nKeymile Kirkwood PCI" +#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ +/* KM_NUSA */ +#elif defined(CONFIG_KM_NUSA ) +#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/ +#define CONFIG_IDENT_STRING "\nKeymile NUSA" +#undef CONFIG_SYS_KWD_CONFIG +#define CONFIG_SYS_KWD_CONFIG \ + $(SRCTREE)/$(CONFIG_BOARDDIR)/128M16-1.cfg +#define CONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_KM_FPGA_CONFIG +#define CONFIG_KM_PIGGY4_88E6352 + +#else +#error ("Board unsupported")#endif +/* include common defines/options for all arm based Keymile boards */ +#include "km/km_arm.h" +#define CONFIG_HOSTNAME km_kirkwood -#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ +#ifndef CONFIG_KM_ENV_IS_IN_SPI_NOR #define KM_ENV_BUS "pca9544a:70:d"/* I2C2 (Mux-Port 5)*/ +#endif + +#if defined(CONFIG_KM_PIGGY4_88E6352 ) +/* +* Some keymile boards like mgcoge5un & nusa1 have their PIGGY4 connected via
+ * an Marvell 88E6352 simple switch.
+ * In this case we have to change the default settings for the etherent mac.
+ * There is NO ethernet phy. The ARM and Switch are conencted directly over
+ * RGMII in MAC-MAC mode
+ * In this case 1GBit full duplex and autoneg off
+ */include/configs/km_kirkwood.h +21
-0+#define PORT_SERIAL_CONTROL_VALUE ( \ + MVGBE_FORCE_LINK_PASS | \ + MVGBE_DIS_AUTO_NEG_FOR_DUPLX | \ + MVGBE_DIS_AUTO_NEG_FOR_FLOW_CTRL | \ + MVGBE_ADV_NO_FLOW_CTRL | \ + MVGBE_FORCE_FC_MODE_NO_PAUSE_DIS_TX | \ + MVGBE_FORCE_BP_MODE_NO_JAM | \ + (1 << 9) /* Reserved bit has to be 1 */ | \ +MVGBE_DO_NOT_FORCE_LINK_FAIL | \ + MVGBE_DIS_AUTO_NEG_SPEED_GMII | \ + MVGBE_DTE_ADV_0 | \ + MVGBE_MIIPHY_MAC_MODE | \ + MVGBE_AUTO_NEG_NO_CHANGE | \ + MVGBE_MAX_RX_PACKET_1552BYTE | \ + MVGBE_CLR_EXT_LOOPBACK | \ + MVGBE_SET_FULL_DUPLEX_MODE | \ + MVGBE_EN_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX |\ + MVGBE_SET_GMII_SPEED_TO_1000 |\ + MVGBE_SET_MII_SPEED_TO_100) + +#endif /* GPIO Pin from kirkwood connected to PROGRAM_B pin of the xilinx FPGA */
#defineKM_XLX_PROGRAM_B_PIN39
--
1.7.1
PATCH 4/20 arm/km: add kmnusa board support
Quoted 30 lines · Prafulla Wadaskar
Quoted 21 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 04/20] arm/km: add kmnusa board supportFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.Quoted 8 lines
Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294+++++++++++++++++++++++++++++++++++++
Quoted 2 lines
Please avoid file names starting with numbers.
would sdram128M16-1.cfg be ok? The reason for this numbering is to have a chance to know which organisation this RAM has.
Quoted 14 lines
Quoted 14 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>
Quoted 7 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards addition, bugfixes/updates specific to km_*boards and generic kirkwood specific patches.
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to be kirkwood specific? This is all board related code.
Quoted 315 lines
Quoted 302 lines
MAINTAINERS +0
-0mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC)board/keymile/km_arm/128M16-1.cfg new file +142
-0@@ -0,0 +1,294 @@ +# +# (C) Copyright 2010 +# Heiko Schocher, DENX Software Engineering, hs at denx.de. +# +# (C) Copyright 2012 +# Valentin Longchamp, Keymile AG, valentin.longchamp at keymile.com +# Stefan Bigler, Keymile AG, stefan.bigler at keymile.com +# +# (C) Copyright 2012 +# See file CREDITS for list of people who contributed to this +# project. +# +# 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. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD10000 0x01112222 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_SI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_SO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] +# bit 7-4: 0, MPPSel9 GPIO[9] +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 UA1_TXD +# bit 27-24: 3, MPPSel14 UA1_RXD +# bit 31-28: 0, MPPSel15 GPIO[15] + +DATA 0xFFD10008 0x00001100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 12-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14: 0, Reserved +# bit 15: 0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x66666666 # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserve +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4 + +DATA 0xFFD20138 0x66666666 # L2 RAM Timing 1 Register +# bit 15-0: ???, Reserve +# bit 17-16: 2, ECC RAM RTC RAM0 +# bit 19-18: 1, ECC RAM WTC RAM0 +# bit 31-20: ???,Reserve + +DATA 0xFFD20154 0x00000200 # CPU RAM Management Control3 Register +# bit 23-0: 0x000200, Addr Config tuning +# bit 31-24: 0, Reserved + +# ??? Missing register # CPU RAM Management Control2 Register + +DATA 0xFFD2014C 0x00001C00 # CPU RAM Management Control1 Register +# bit 15-0: 0x1C00, Opmux Tuning +# bit 31-16: 0, Pc Dp Tuning + +DATA 0xFFD20148 0x00000001 # CPU RAM Management Control0 Register +# bit 1-0: 1, addr clk tune +# bit 3-2: 0, reserved +# bit 5-4: 0, dtcmp clk tune +# bit 7-6: 0, reserved +# bit 9-8: 0, macdrv clk tune +# bit 11-10: 0, opmuxgm2 clk tune +# bit 15-14: 0, rf clk tune +# bit 17-16: 0, rfbypass clk tune +# bit 19-18: 0, pc dp clk tune +# bit 23-20: 0, icache clk tune +# bit 27:24: 0, dcache clk tune +# bit 31:28: 0, regfile tunin + +# SDRAM initalization +DATA 0xFFD01400 0x430004E0 # SDRAM Configuration Register +# bit 13-0: 0x4E0, DDR2 clks refresh rate +# bit 14: 0, reserved +# bit 15: 0, reserved +# bit 16: 0, CPU to Dram Write buffer policy +# bit 17: 0, Enable Registered DIMM or Equivalent Sampling Logic +# bit 19-18: 0, reserved +# bit 23-20: 0, reserved +# bit 24: 1, enable exit self refresh mode on DDR access +# bit 25: 1, required +# bit 29-26: 0, reserved +# bit 31-30: 1, reserved + +DATA 0xFFD01404 0x36543000 # DDR Controller Control Low +# bit 3-0: 0, reserved +# bit 4: 0, 2T mode =addr/cmd in same cycle +# bit 5: 0, clk is driven during self refresh, we don't care forAPX
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# bit 6: 0, use recommended falling edge of clk for addr/cmd +# bit 7-11: 0, reserved +# bit 12-13: 1, reserved, required 1 +# bit 14: 0, input buffer always powered up +# bit 17-15: 0, reserved +# bit 18: 1, cpu lock transaction enabled +# bit 19: 0, reserved +# bit 23-20: 5, recommended value for CL=4 and STARTBURST_DELdisabled bit31=0
+# bit 27-24: 6, CL+1, STARTBURST sample stages, for freqs 200-399MHz, unbuffered DIMMboard/keymile/km_arm/128M16-1.cfg new file +95
-0+# bit 30-28: 3, required +# bit 31: 0,no additional STARTBURST delay + +DATA 0xFFD01408 0x2302444e # DDR Timing (Low) (active cycles value +1) +# bit 3-0: 0xE, TRAS, 15 clk (45 ns) +# bit 7-4: 0x4, TRCD, 5 clk (15 ns) +# bit 11-8: 0x4, TRP, 5 clk (15 ns) +# bit 15-12: 0x4, TWR, 5 clk (15 ns) +# bit 19-16: 0x2, TWTR, 3 clk (7.5 ns) +# bit 20: 0, extended TRAS msb +# bit 23-21: 0, reserved +# bit 27-24: 0x3, TRRD, 4 clk (10 ns) +# bit 31-28: 0x2, TRTP, 3 clk (7.5 ns) + +DATA 0xFFD0140C 0x0000003e # DDR Timing (High) +# bit 6-0: 0x3E, TRFC, 63 clk (195 ns) +# bit 8-7: 0, TR2R +# bit 10-9: 0, TR2W +# bit 12-11: 0, TW2W +# bit 31-13: 0, reserved + +DATA 0xFFD01410 0x00000001 # DDR Address Control +# bit 1-0: 1, Cs0width=x16 +# bit 3-2: 0, Cs0size=2Gb +# bit 5-4: 0, Cs1width=nonexistent +# bit 7-6: 0, Cs1size =nonexistent +# bit 9-8: 0, Cs2width=nonexistent +# bit 11-10: 0, Cs2size =nonexistent +# bit 13-12: 0, Cs3width=nonexistent +# bit 15-14: 0, Cs3size =nonexistent +# bit 16: 0, Cs0AddrSel +# bit 17: 0, Cs1AddrSel +# bit 18: 0, Cs2AddrSel +# bit 19: 0, Cs3AddrSel +# bit 31-20: 0, required + +DATA 0xFFD01414 0x00000000 # DDR Open Pages Control +# bit 0: 0, OpenPage enabled +# bit 31-1: 0, required + +DATA 0xFFD01418 0x00000000 # DDR Operation +# bit 3-0: 0, DDR cmd +# bit 31-4: 0, required + +DATA 0xFFD0141C 0x00000652 # DDR Mode +# bit 2-0: 2, Burst Length = 4 +# bit 3: 0, Burst Type +# bit 6-4: 5, CAS Latency = 5 +# bit 7: 0, Test mode +# bit 8: 0, DLL Reset +# bit 11-9: 3, Write recovery for auto-precharge must be 3 +# bit 12: 0, Active power down exit time, fast exit +# bit 14-13: 0, reserved +# bit 31-15: 0, reserved + +DATA 0xFFD01420 0x00000006 # DDR Extended Mode +# bit 0: 0, DDR DLL enabled +# bit 1: 1, DDR drive strength reduced +# bit 2: 1, DDR ODT control lsb, 75 ohm termination [RTT0] +# bit 5-3: 0, required +# bit 6: 0, DDR ODT control msb, 75 ohm termination [RTT1] +# bit 9-7: 0, required +# bit 10: 0, differential DQS enabled +# bit 11: 0, required +# bit 12: 0, DDR output buffer enabled +# bit 31-13: 0 required + +DATA 0xFFD01424 0x0000F17F # DDR Controller Control High +# bit 2-0: 7, required +# bit 3: 1, MBUS Burst Chop disabled +# bit 6-4: 7, required +# bit 7: 0, reserved +# bit 8: 1, add sample stage required for f > 266 MHz +# bit 9: 0, no half clock cycle addition to dataout +# bit 10: 0, 1/4 clock cycle skew enabled for addr/ctl signals +# bit 11: 0, 1/4 clock cycle skew disabled for write mesh +# bit 15-12:0xf, required +# bit 31-16: 0, required + +DATA 0xFFD01428 0x00084520 # DDR2 SDRAM Timing Low +# bit 3-0: 0, required +# bit 7-4: 2, M_ODT assertion 2 cycles after read start command +# bit 11-8: 5, M_ODT de-assertion 5 cycles after read start command +# (ODT turn off delay 2,5 clk cycles) +# bit 15-12: 4, internal ODT time based on bit 7-4 +# with the considered SDRAM internal delay +# bit 19-16: 8, internal ODT de-assertion based on bit 11-8 +# with the considered SDRAM internal delay +# bit 31-20: 0, required + +DATA 0xFFD0147c 0x00008452 # DDR2 SDRAM Timing High +# bit 3-0: 2, M_ODT assertion same as bit 11-8 +# bit 7-4: 5, M_ODT de-assertion same as bit 15-12 +# bit 11-8: 4, internal ODT assertion 2 cycles after write startcommand
board/keymile/km_arm/128M16-1.cfg new file +2
-0+# with the considered SDRAM internal delay +# bit 15-12: 8, internal ODT de-assertion 5 cycles after write startcommand
board/keymile/km_arm/128M16-1.cfg new file +19
-0+# with the considered SDRAM internal delay + +DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0 +# bit 23-0: 0, reserved +# bit 31-24: 0, CPU CS Window0 Base Address, addr bits [31:24] + +DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size +# bit 0: 1, Window enabled +# bit 1: 0, Write Protect disabled +# bit 3-2: 0, CS0 hit selected +# bit 23-4:ones, required +# bit 31-24: 0x0F, Size (i.e. 256MB) + +DATA 0xFFD0150C 0x00000000 # CS[1]n Size, window disabled +DATA 0xFFD01514 0x00000000 # CS[2]n Size, window disabled +DATA 0xFFD0151C 0x00000000 # CS[3]n Size, window disabled + +DATA 0xFFD01494 0x00010000 # DDR ODT Control (Low) +# bit 3-0: 0, ODT0Rd, MODT[0] not asserted during read from DRAMCS0
board/keymile/km_arm/128M16-1.cfg new file +15
-0+# bit 7-4: 0, ODT0Rd, MODT[1] not asserted +# bit 11-8: 0, required +# big 15-11: 0, required +# bit 19-16: 1, ODT0Wr, MODT[0] asserted during write to DRAM CS0 +# bit 23-20: 0, ODT0Wr, MODT[1] not asserted +# bit 27-24: 0, required +# bit 31-28: 0, required + +DATA 0xFFD01498 0x00000000 # DDR ODT Control (High) +# bit 1-0: 0, ODT0 controlled by ODT Control (low) register above +# bit 3-2: 0, ODT1 controlled by register +# bit 31-4: 0, required + +DATA 0xFFD0149C 0x0000E801 # CPU ODT Control +# bit 3-0: 1, ODTRd, Internal ODT asserted during read from DRAMbank0
+# bit 7-4: 0, ODTWr, Internal ODT not asserted during write to
DRAMboard/keymile/km_arm/128M16-1.cfg new file +1
-0+# bit 9-8: 0, ODTEn, controlled by ODTRd and ODTWrboard/keymile/km_arm/128M16-1.cfg line 293
Quoted 10 lines
board/keymile/km_arm/128M16-1.cfg new file +10
-0+# bit 11-10: 2, DQ_ODTSel. ODT select turned on, 75 ohm +# bit 13-12: 2, STARTBURST ODT buffer selected, 75 ohm +# bit 14: 1, STARTBURST ODT enabled +# bit 15: 1, Use ODT Block + +DATA 0xFFD01480 0x00000001 # DDR Initialization Control +# bit 0: 1, enable DDR init upon this register write +# bit 31-1: 0, reserved + +# End of Header extensionIs this configuration similar to any other board already mainlined? if there is small delta like RAM/flash sizes then you can manage it through
board_init()
Quoted 2 lines
Just think of it.
I would like to keep it as it is.
Quoted 39 lines
Quoted 39 lines
board/keymile/km_arm/128M16-1.cfg new file +1
-0+DATA 0x0 0x0board/keymile/km_arm/km_arm.c +2
-2@@ -133,10 +133,11 @@ int startup_allowed(void) }#endif -#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ + defined(CONFIG_KM_PIGGY4_88E6352 ))/* -* These two boards have always ethernet present. Its connected to the mv
- * switch.
+ * All boards with PIGGY4 connected via a simple switch have ethernet always
+ * present.
*/
intethernet_present(void)
{board/keymile/km_arm/km_arm.c +1
-1@@ -384,7 +385,7 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#else +#elif !defined(CONFIG_KM_PIGGY4_88E6352)/* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {boards.cfg +0
-1@@ -140,6 +140,7 @@ pogo_e02 arm arm926ejs - clouden dns325 arm arm926ejs -
Quoted 9 lines
Quoted 6 lines
d-link kirkwood
km_kirkwoodarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
km_kirkwood_pciarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
+kmnusa arm arm926ejskm_armWhy name is not
km_nusa?
Could be also km_nusa. But isn't it up to us how we name our boards?
Quoted 15 lines
Quoted 15 lines
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood
portl2 arm arm926ejskm_arm
keymile kirkwood
inetspace_v2arm arm926ejsnetspace_v2
LaCie kirkwood lacie_kw:INETSPACE_V2include/configs/km/km_arm.h +0
-0@@ -57,6 +57,13 @@#define CONFIG_CMD_SF #define CONFIG_SOFT_I2C /* I2C bit-banged */
Quoted 10 lines
include/configs/km/km_arm.h line 66
Quoted 7 lines
include/configs/km/km_arm.h +7
-0+#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_ENV_SPI_BUS 0 +#define CONFIG_ENV_SPI_CS 0 +#define CONFIG_ENV_SPI_MAX_HZ 5000000 +#define CONFIG_ENV_SPI_MODE SPI_MODE_3 +#endif +Do you still need this? Your patch 03/20 takes care of this.
Yes we need it. Patch 03/20 makes it possible to overwrite these default values. And in this patch we use 5MHz as max frequency rather than 50MHz which is the default setting.
Regards
Holger
PATCH 4/20 arm/km: add kmnusa board support
Quoted 42 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:04
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 7 lines · Prafulla Wadaskar
Quoted 7 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp;Gerlando
Quoted 23 lines
Quoted 22 lines
Falauto; Prafulla Wadaskar
Subject: [PATCH 04/20] arm/km: add kmnusa board supportFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294+++++++++++++++++++++++++++++++++++++
Quoted 6 lines
Quoted 2 lines
Please avoid file names starting with numbers.
would sdram128M16-1.cfg be ok? The reason for this numbering is to have a chance
to know which organisation this RAM has.
I think kwbimage_128M16_1.cfg should be okay,
BTW: if the configuration is similar to any other already supported board, may you think to reuse the same.
Regards..
Prafulla . . .
Quoted 456 lines
Quoted 15 lines
Quoted 15 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>Quoted 4 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
addition, bugfixes/updates specific to km_*boards and generic kirkwood specific patches.
Quoted 3 lines
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to be kirkwood
specific? This is all board related code.Quoted 25 lines
Quoted 25 lines
MAINTAINERS +0
-0mgcoge3un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC)board/keymile/km_arm/128M16-1.cfg new file +15
-0@@ -0,0 +1,294 @@ +# +# (C) Copyright 2010 +# Heiko Schocher, DENX Software Engineering, hs at denx.de. +# +# (C) Copyright 2012 +# Valentin Longchamp, Keymile AG, valentin.longchamp at keymile.com +# Stefan Bigler, Keymile AG, stefan.bigler at keymile.com +# +# (C) Copyright 2012 +# See file CREDITS for list of people who contributed to this +# project. +# +# 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 ofQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General PublicLicense
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg new file +5
-0+# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-toconfigure
Quoted 65 lines
Quoted 65 lines
board/keymile/km_arm/128M16-1.cfg new file +65
-0+# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD10000 0x01112222 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_SI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_SO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] +# bit 7-4: 0, MPPSel9 GPIO[9] +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 UA1_TXD +# bit 27-24: 3, MPPSel14 UA1_RXD +# bit 31-28: 0, MPPSel15 GPIO[15] + +DATA 0xFFD10008 0x00001100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 12-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14: 0, Reserved +# bit 15: 0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x66666666 # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserve +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +8
-0+ +DATA 0xFFD20138 0x66666666 # L2 RAM Timing 1 Register +# bit 15-0: ???, Reserve +# bit 17-16: 2, ECC RAM RTC RAM0 +# bit 19-18: 1, ECC RAM WTC RAM0 +# bit 31-20: ???,Reserve + +DATA 0xFFD20154 0x00000200 # CPU RAM Management Control3Register
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg new file +6
-0+# bit 23-0: 0x000200, Addr Config tuning +# bit 31-24: 0, Reserved + +# ??? Missing register # CPU RAM Management Control2 Register + +DATA 0xFFD2014C 0x00001C00 # CPU RAM Management Control1Register
Quoted 4 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 4 lines
board/keymile/km_arm/128M16-1.cfg new file +4
-0+# bit 15-0: 0x1C00, Opmux Tuning +# bit 31-16: 0, Pc Dp Tuning + +DATA 0xFFD20148 0x00000001 # CPU RAM Management Control0Register
Quoted 12 lines
Quoted 12 lines
board/keymile/km_arm/128M16-1.cfg new file +12
-0+# bit 1-0: 1, addr clk tune +# bit 3-2: 0, reserved +# bit 5-4: 0, dtcmp clk tune +# bit 7-6: 0, reserved +# bit 9-8: 0, macdrv clk tune +# bit 11-10: 0, opmuxgm2 clk tune +# bit 15-14: 0, rf clk tune +# bit 17-16: 0, rfbypass clk tune +# bit 19-18: 0, pc dp clk tune +# bit 23-20: 0, icache clk tune +# bit 27:24: 0, dcache clk tune +# bit 31:28: 0, regfile tuninQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +8
-0+ +# SDRAM initalization +DATA 0xFFD01400 0x430004E0 # SDRAM Configuration Register +# bit 13-0: 0x4E0, DDR2 clks refresh rate +# bit 14: 0, reserved +# bit 15: 0, reserved +# bit 16: 0, CPU to Dram Write buffer policy +# bit 17: 0, Enable Registered DIMM or Equivalent SamplingLogic
Quoted 11 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 11 lines
board/keymile/km_arm/128M16-1.cfg new file +11
-0+# bit 19-18: 0, reserved +# bit 23-20: 0, reserved +# bit 24: 1, enable exit self refresh mode on DDR access +# bit 25: 1, required +# bit 29-26: 0, reserved +# bit 31-30: 1, reserved + +DATA 0xFFD01404 0x36543000 # DDR Controller Control Low +# bit 3-0: 0, reserved +# bit 4: 0, 2T mode =addr/cmd in same cycle +# bit 5: 0, clk is driven during self refresh, we don't carefor
Quoted 11 lines
Quoted 11 lines
APX
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# bit 6: 0, use recommended falling edge of clk for addr/cmd +# bit 7-11: 0, reserved +# bit 12-13: 1, reserved, required 1 +# bit 14: 0, input buffer always powered up +# bit 17-15: 0, reserved +# bit 18: 1, cpu lock transaction enabled +# bit 19: 0, reserved +# bit 23-20: 5, recommended value for CL=4 and STARTBURST_DELdisabled bit31=0
+# bit 27-24: 6, CL+1, STARTBURST sample stages, for freqs 200-399MHz,
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 5 lines
unbuffered DIMM
board/keymile/km_arm/128M16-1.cfg new file +4
-0+# bit 30-28: 3, required +# bit 31: 0,no additional STARTBURST delay + +DATA 0xFFD01408 0x2302444e # DDR Timing (Low) (active cyclesvalue
Quoted 72 lines
Quoted 72 lines
+1)
board/keymile/km_arm/128M16-1.cfg new file +71
-0+# bit 3-0: 0xE, TRAS, 15 clk (45 ns) +# bit 7-4: 0x4, TRCD, 5 clk (15 ns) +# bit 11-8: 0x4, TRP, 5 clk (15 ns) +# bit 15-12: 0x4, TWR, 5 clk (15 ns) +# bit 19-16: 0x2, TWTR, 3 clk (7.5 ns) +# bit 20: 0, extended TRAS msb +# bit 23-21: 0, reserved +# bit 27-24: 0x3, TRRD, 4 clk (10 ns) +# bit 31-28: 0x2, TRTP, 3 clk (7.5 ns) + +DATA 0xFFD0140C 0x0000003e # DDR Timing (High) +# bit 6-0: 0x3E, TRFC, 63 clk (195 ns) +# bit 8-7: 0, TR2R +# bit 10-9: 0, TR2W +# bit 12-11: 0, TW2W +# bit 31-13: 0, reserved + +DATA 0xFFD01410 0x00000001 # DDR Address Control +# bit 1-0: 1, Cs0width=x16 +# bit 3-2: 0, Cs0size=2Gb +# bit 5-4: 0, Cs1width=nonexistent +# bit 7-6: 0, Cs1size =nonexistent +# bit 9-8: 0, Cs2width=nonexistent +# bit 11-10: 0, Cs2size =nonexistent +# bit 13-12: 0, Cs3width=nonexistent +# bit 15-14: 0, Cs3size =nonexistent +# bit 16: 0, Cs0AddrSel +# bit 17: 0, Cs1AddrSel +# bit 18: 0, Cs2AddrSel +# bit 19: 0, Cs3AddrSel +# bit 31-20: 0, required + +DATA 0xFFD01414 0x00000000 # DDR Open Pages Control +# bit 0: 0, OpenPage enabled +# bit 31-1: 0, required + +DATA 0xFFD01418 0x00000000 # DDR Operation +# bit 3-0: 0, DDR cmd +# bit 31-4: 0, required + +DATA 0xFFD0141C 0x00000652 # DDR Mode +# bit 2-0: 2, Burst Length = 4 +# bit 3: 0, Burst Type +# bit 6-4: 5, CAS Latency = 5 +# bit 7: 0, Test mode +# bit 8: 0, DLL Reset +# bit 11-9: 3, Write recovery for auto-precharge must be 3 +# bit 12: 0, Active power down exit time, fast exit +# bit 14-13: 0, reserved +# bit 31-15: 0, reserved + +DATA 0xFFD01420 0x00000006 # DDR Extended Mode +# bit 0: 0, DDR DLL enabled +# bit 1: 1, DDR drive strength reduced +# bit 2: 1, DDR ODT control lsb, 75 ohm termination [RTT0] +# bit 5-3: 0, required +# bit 6: 0, DDR ODT control msb, 75 ohm termination [RTT1] +# bit 9-7: 0, required +# bit 10: 0, differential DQS enabled +# bit 11: 0, required +# bit 12: 0, DDR output buffer enabled +# bit 31-13: 0 required + +DATA 0xFFD01424 0x0000F17F # DDR Controller Control High +# bit 2-0: 7, required +# bit 3: 1, MBUS Burst Chop disabled +# bit 6-4: 7, required +# bit 7: 0, reserved +# bit 8: 1, add sample stage required for f > 266 MHz +# bit 9: 0, no half clock cycle addition to dataout +# bit 10: 0, 1/4 clock cycle skew enabled for addr/ctl signalsQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# bit 11: 0, 1/4 clock cycle skew disabled for write mesh +# bit 15-12:0xf, required +# bit 31-16: 0, required + +DATA 0xFFD01428 0x00084520 # DDR2 SDRAM Timing Low +# bit 3-0: 0, required +# bit 7-4: 2, M_ODT assertion 2 cycles after read start command +# bit 11-8: 5, M_ODT de-assertion 5 cycles after read startcommand
Quoted 6 lines
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg new file +6
-0+# (ODT turn off delay 2,5 clk cycles) +# bit 15-12: 4, internal ODT time based on bit 7-4 +# with the considered SDRAM internal delay +# bit 19-16: 8, internal ODT de-assertion based on bit 11-8 +# with the considered SDRAM internal delay +# bit 31-20: 0, requiredQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +5
-0+ +DATA 0xFFD0147c 0x00008452 # DDR2 SDRAM Timing High +# bit 3-0: 2, M_ODT assertion same as bit 11-8 +# bit 7-4: 5, M_ODT de-assertion same as bit 15-12 +# bit 11-8: 4, internal ODT assertion 2 cycles after write startcommand
board/keymile/km_arm/128M16-1.cfg new file +2
-0+# with the considered SDRAM internal delay +# bit 15-12: 8, internal ODT de-assertion 5 cycles after writestart
Quoted 12 lines
Quoted 12 lines
command
board/keymile/km_arm/128M16-1.cfg new file +11
-0+# with the considered SDRAM internal delay + +DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0 +# bit 23-0: 0, reserved +# bit 31-24: 0, CPU CS Window0 Base Address, addr bits [31:24] + +DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size +# bit 0: 1, Window enabled +# bit 1: 0, Write Protect disabled +# bit 3-2: 0, CS0 hit selected +# bit 23-4:ones, requiredQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 8 lines
board/keymile/km_arm/128M16-1.cfg new file +8
-0+# bit 31-24: 0x0F, Size (i.e. 256MB) + +DATA 0xFFD0150C 0x00000000 # CS[1]n Size, window disabled +DATA 0xFFD01514 0x00000000 # CS[2]n Size, window disabled +DATA 0xFFD0151C 0x00000000 # CS[3]n Size, window disabled + +DATA 0xFFD01494 0x00010000 # DDR ODT Control (Low) +# bit 3-0: 0, ODT0Rd, MODT[0] not asserted during read fromDRAM
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 5 lines
CS0
board/keymile/km_arm/128M16-1.cfg new file +4
-0+# bit 7-4: 0, ODT0Rd, MODT[1] not asserted +# bit 11-8: 0, required +# big 15-11: 0, required +# bit 19-16: 1, ODT0Wr, MODT[0] asserted during write to DRAMCS0
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg new file +6
-0+# bit 23-20: 0, ODT0Wr, MODT[1] not asserted +# bit 27-24: 0, required +# bit 31-28: 0, required + +DATA 0xFFD01498 0x00000000 # DDR ODT Control (High) +# bit 1-0: 0, ODT0 controlled by ODT Control (low) registerabove
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg
Quoted 5 lines
board/keymile/km_arm/128M16-1.cfg new file +5
-0+# bit 3-2: 0, ODT1 controlled by register +# bit 31-4: 0, required + +DATA 0xFFD0149C 0x0000E801 # CPU ODT Control +# bit 3-0: 1, ODTRd, Internal ODT asserted during read fromDRAM
Quoted 8 lines
Quoted 8 lines
bank0
+# bit 7-4: 0, ODTWr, Internal ODT not asserted during write to
DRAMboard/keymile/km_arm/128M16-1.cfg new file +5
-0+# bit 9-8: 0, ODTEn, controlled by ODTRd and ODTWr +# bit 11-10: 2, DQ_ODTSel. ODT select turned on, 75 ohm +# bit 13-12: 2, STARTBURST ODT buffer selected, 75 ohm +# bit 14: 1, STARTBURST ODT enabled +# bit 15: 1, Use ODT BlockQuoted 8 lines
board/keymile/km_arm/128M16-1.cfg line 293
Quoted 6 lines
board/keymile/km_arm/128M16-1.cfg new file +6
-0+ +DATA 0xFFD01480 0x00000001 # DDR Initialization Control +# bit 0: 1, enable DDR init upon this register write +# bit 31-1: 0, reserved + +# End of Header extensionIs this configuration similar to any other board already mainlined?
if there is small delta like RAM/flash sizes then you can manage it through
board_init()Quoted 3 lines
Just think of it.
I would like to keep it as it is.
Quoted 10 lines
Quoted 10 lines
board/keymile/km_arm/128M16-1.cfg new file +1
-0+DATA 0x0 0x0board/keymile/km_arm/km_arm.c +0
-0@@ -133,10 +133,11 @@ int startup_allowed(void) }#endif Quoted 8 lines
Quoted 8 lines
board/keymile/km_arm/km_arm.c +2
-2-#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ + defined(CONFIG_KM_PIGGY4_88E6352 ))/* -* These two boards have always ethernet present. Its connected to the mv
- * switch.
+ * All boards with PIGGY4 connected via a simple switch haveethernet
Quoted 11 lines
Quoted 11 lines
always
+ * present.
*/
intethernet_present(void)
{board/keymile/km_arm/km_arm.c +1
-1@@ -384,7 +385,7 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#else +#elif !defined(CONFIG_KM_PIGGY4_88E6352)Quoted 8 lines
boards.cfg pogo_e02 arm
Quoted 8 lines
board/keymile/km_arm/km_arm.c +0
-0/* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {boards.cfg +0
-0@@ -140,6 +140,7 @@ pogo_e02 armarm926ejs
Quoted 7 lines
Quoted 7 lines
boards.cfg +0
-1- clouden dns325 arm arm926ejs -d-link kirkwood
km_kirkwoodarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
km_kirkwood_pciarm arm926ejskm_arm
keymile kirkwoodkm_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
Quoted 4 lines
Quoted 1 line
+kmnusa arm arm926ejs
km_armWhy name is not
km_nusa?Could be also
km_nusa. But isn't it up to us how we name our boards?Quoted 8 lines
Review
Quoted 8 lines
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood
portl2 arm arm926ejskm_arm
keymile kirkwood
inetspace_v2arm arm926ejsnetspace_v2
LaCie kirkwood lacie_kw:INETSPACE_V2(quoted diff) +0
-0
b/include/configs/km/km_arm.hQuoted 7 lines
Quoted 7 lines
index 28b5021..a35ef61 100644
include/configs/km/km_arm.h +0
-0@@ -57,6 +57,13 @@#define CONFIG_CMD_SF #define CONFIG_SOFT_I2C /* I2C bit-banged */ Quoted 10 lines
include/configs/km/km_arm.h line 66
Quoted 7 lines
include/configs/km/km_arm.h +7
-0+#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_ENV_SPI_BUS 0 +#define CONFIG_ENV_SPI_CS 0 +#define CONFIG_ENV_SPI_MAX_HZ 5000000 +#define CONFIG_ENV_SPI_MODE SPI_MODE_3 +#endif +Do you still need this? Your patch 03/20 takes care of this.
Yes we need it. Patch 03/20 makes it possible to overwrite these default values.
And in this patch we use 5MHz as max frequency rather than 50MHz which is the
default setting.Regards
Holger
PATCH 4/20 arm/km: add kmnusa board support
Quoted 45 lines · Prafulla Wadaskar
Quoted 45 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:04
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 7 lines · Prafulla Wadaskar
Quoted 7 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp;Gerlando
Quoted 25 lines
Quoted 14 lines
Falauto; Prafulla Wadaskar
Subject: [PATCH 04/20] arm/km: add kmnusa board supportFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.Quoted 8 lines
Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294+++++++++++++++++++++++++++++++++++++
Please avoid file names starting with numbers.
Quoted 7 lines
Quoted 3 lines
would sdram128M16-1.cfg be ok? The reason for this numbering is to have a chance
to know which organisation this RAM has.I think kwbimage_128M16_1.cfg should be okay,
BTW: if the configuration is similar to any other already supported board, may you think to reuse the same.
yes of course, but it isn't. I'll fix the naming in a v2.
Regards
Holger
PATCH 4/20 arm/km: add kmnusa board support
In reply to Holger BrunckQuoted 11 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:04
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportOn 06/12/2012 06:39 AM, Prafulla Wadaskar wrote:
...snip...
Quoted 4 lines
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ +# End of Header extensionIs this configuration similar to any other board already mainlined?
Quoted 8 lines
if there is small delta like RAM/flash sizes then you can manage it through
board_init()Quoted 3 lines
Just think of it.
I would like to keep it as it is.
Okay
Quoted 46 lines
Quoted 10 lines
Quoted 10 lines
board/keymile/km_arm/128M16-1.cfg new file +1
-0+DATA 0x0 0x0board/keymile/km_arm/km_arm.c +0
-0@@ -133,10 +133,11 @@ int startup_allowed(void) }#endif Quoted 8 lines
Quoted 8 lines
board/keymile/km_arm/km_arm.c +2
-2-#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ + defined(CONFIG_KM_PIGGY4_88E6352 ))/* -* These two boards have always ethernet present. Its connected to the mv
- * switch.
+ * All boards with PIGGY4 connected via a simple switch haveethernet
Quoted 11 lines
Quoted 11 lines
always
+ * present.
*/
intethernet_present(void)
{board/keymile/km_arm/km_arm.c +1
-1@@ -384,7 +385,7 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#else +#elif !defined(CONFIG_KM_PIGGY4_88E6352)Quoted 8 lines
boards.cfg pogo_e02 arm
Quoted 8 lines
board/keymile/km_arm/km_arm.c +0
-0/* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {boards.cfg +0
-0@@ -140,6 +140,7 @@ pogo_e02 armarm926ejs
Quoted 7 lines
Quoted 7 lines
boards.cfg +0
-1- clouden dns325 arm arm926ejs -d-link kirkwood
km_kirkwoodarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
km_kirkwood_pciarm arm926ejskm_arm
keymile kirkwood
Quoted 7 lines
km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
Quoted 4 lines
Quoted 1 line
+kmnusa arm arm926ejs
km_armWhy name is not
km_nusa?Could be also
km_nusa. But isn't it up to us how we name our boards?
So why your some boards named as kw_xxx and some kmxxx? to me it doesn't sound good.
Anyways the call is yours here.
Quoted 28 lines
Quoted 9 lines
Review
Quoted 9 lines
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood
portl2 arm arm926ejskm_arm
keymile kirkwood
inetspace_v2arm arm926ejsnetspace_v2
LaCie kirkwood lacie_kw:INETSPACE_V2(quoted diff) +0
-0
b/include/configs/km/km_arm.hQuoted 7 lines
Quoted 7 lines
index 28b5021..a35ef61 100644
include/configs/km/km_arm.h +0
-0@@ -57,6 +57,13 @@#define CONFIG_CMD_SF #define CONFIG_SOFT_I2C /* I2C bit-banged */ Quoted 10 lines
include/configs/km/km_arm.h line 66
Quoted 7 lines
include/configs/km/km_arm.h +7
-0+#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_ENV_SPI_BUS 0 +#define CONFIG_ENV_SPI_CS 0 +#define CONFIG_ENV_SPI_MAX_HZ 5000000 +#define CONFIG_ENV_SPI_MODE SPI_MODE_3 +#endif +Do you still need this? Your patch 03/20 takes care of this.
Quoted 5 lines
Yes we need it. Patch 03/20 makes it possible to overwrite these default values.
And in this patch we use 5MHz as max frequency rather than 50MHz which is the
default setting.
So we can only address delta.
Regards..
Prafulla . . .
PATCH 4/20 arm/km: add kmnusa board support
In reply to Holger BrunckQuoted 70 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 14:04
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 7 lines · Prafulla Wadaskar
Quoted 7 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp;Gerlando
Quoted 23 lines
Quoted 14 lines
Falauto; Prafulla Wadaskar
Subject: [PATCH 04/20] arm/km: add kmnusa board supportFrom: Holger Brunck <[email protected]>
This board is similar to portl2, but it has the u-boot environment in a SPI NOR flash and not in an i2c eeprom like portl2 have.
Some other details:
- IVM EEPROM is at adress: pca9547:70:9
- PCI is enabled
- PIGGY4 is connected via MV88E6352 simple switch. There is no phy between the simple switch and the kirkwood.Quoted 8 lines
Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/128M16-1.cfg | 294+++++++++++++++++++++++++++++++++++++
Quoted 2 lines
Please avoid file names starting with numbers.
would sdram128M16-1.cfg be ok? The reason for this numbering is to have a chance
to know which organisation this RAM has.Quoted 14 lines
Quoted 14 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>Quoted 4 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
addition, bugfixes/updates specific to km_*boards and generic kirkwood specific patches.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to be kirkwood
specific? This is all board related code.
I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood related file that may affects other boards, for ex arch/arm/cpu/arm926ejs/mach-kirkwood/*
3. Additional board supports
And if possible these patches should be independent so that can be pulled independently
Regards.
Prafulla . . .
PATCH 4/20 arm/km: add kmnusa board support
Quoted 28 lines · Prafulla Wadaskar
Quoted 21 lines
Quoted 14 lines
Quoted 14 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>Quoted 4 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
addition, bugfixes/updates specific to km_*boards and generic kirkwood specific patches.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to be kirkwood
specific? This is all board related code.
Quoted 7 lines
I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood related file that may affects other boards, for exarch/arm/cpu/arm926ejs/mach-kirkwood/*
3. Additional board supportsAnd if possible these patches should be independent so that can be pulled independently
the only patch in the serie which modifies common Kirkwood related files are:
[PATCH 03/20] arm/kirkwood: protect the ENV_SPI #defines
Do you want me to send this one seperately? I can do that. So then we resend again a new patch serie I guess...
The other stuff is only related to our boards and I would like to keep it as it is. It would cause a lot of rebasing and reorganisation and in the end the result is the same.
Regards
Holger
PATCH 4/20 arm/km: add kmnusa board support
Quoted 51 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 16:07
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 14 lines · Prafulla Wadaskar
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
addition, bugfixes/updates specific to km_*boards and generic
kirkwood
Quoted 5 lines
Quoted 5 lines
specific patches.
Quoted 3 lines
It's always faster to merger small patch series that big one.
Quoted 7 lines
Quoted 3 lines
Yes ok, but was has this to do with this patch? What is meant to be kirkwood
specific? This is all board related code.I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood relatedfile that may affects other boards, for ex
arch/arm/cpu/arm926ejs/mach-kirkwood/*Quoted 3 lines
3. Additional board supports
And if possible these patches should be independent so that can be
pulled independently
Quoted 1 line
Quoted 7 lines
the only patch in the serie which modifies common Kirkwood related files are:
[PATCH 03/20] arm/kirkwood: protect theENV_SPI#definesDo you want me to send this one seperately? I can do that. So then we resend
again a new patch serie I guess...
It would be a great you can split 20 patches in to smaller patch series as per above suggestion.
Quoted 6 lines
The other stuff is only related to our boards and I would like to keep it as it
is. It would cause a lot of rebasing and reorganisation and in the end the
result is the same.
I can understand what you mean, I would be happy if you can keep this stuff small, simple and more structured (preferred least usage of #ifdef)
Regards..
Prafulla . . .
PATCH 4/20 arm/km: add kmnusa board support
Quoted 55 lines · Prafulla Wadaskar
Quoted 55 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 16:07
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 14 lines · Prafulla Wadaskar
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]>Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 2 lines
MAINTAINERS +1
-0km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
addition, bugfixes/updates specific to km_*boards and generic
kirkwood
Quoted 5 lines
Quoted 5 lines
specific patches.
Quoted 3 lines
It's always faster to merger small patch series that big one.
Quoted 7 lines
Quoted 3 lines
Yes ok, but was has this to do with this patch? What is meant to be kirkwood
specific? This is all board related code.I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood relatedfile that may affects other boards, for ex
arch/arm/cpu/arm926ejs/mach-kirkwood/*Quoted 3 lines
3. Additional board supports
And if possible these patches should be independent so that can be
pulled independently
Quoted 1 line
the only patch in the serie which modifies common Kirkwood related files are:
[PATCH 03/20] arm/kirkwood: protect theENV_SPI#defines
Quoted 6 lines
Quoted 3 lines
Do you want me to send this one seperately? I can do that. So then we resend
again a new patch serie I guess...It would be a great you can split 20 patches in to smaller patch series as per above suggestion.
Again, the only patch wich is common Kirkwood related is the above mentioned patch. I can extract this one if you want me to.
All others are somehow interconnected and therefore it makes sense to have it in one patch serie.
Regards
Holger
PATCH 4/20 arm/km: add kmnusa board support
Quoted 72 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 17:13
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 29 lines · Prafulla Wadaskar
Quoted 29 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 16:07
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 18 lines · Prafulla Wadaskar
Quoted 18 lines
Quoted 18 lines
Quoted 12 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 4 lines
MAINTAINERS +1
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]> km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
Quoted 1 line
addition, bugfixes/updates specific to km_*boards and generic
kirkwood
Quoted 6 lines
Quoted 6 lines
specific patches.
Quoted 3 lines
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to
be
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
kirkwood
specific? This is all board related code.I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood relatedfile that may affects other boards, for ex
arch/arm/cpu/arm926ejs/mach-kirkwood/*Quoted 3 lines
3. Additional board supports
And if possible these patches should be independent so that can be
Quoted 8 lines
Quoted 8 lines
pulled independently
Quoted 1 line
the only patch in the serie which modifies common Kirkwood related files are:
[PATCH 03/20] arm/kirkwood: protect theENV_SPI#definesDo you want me to send this one seperately? I can do that. So then
we
Quoted 3 lines
Quoted 2 lines
resend
again a new patch serie I guess...
Quoted 7 lines
Quoted 1 line
It would be a great you can split 20 patches in to smaller patch
series as per above suggestion.
Quoted 1 line
Again, the only patch wich is common Kirkwood related is the above mentioned
patch. I can extract this one if you want me to.
Yes, extract this and send it as standalone
Quoted 4 lines
All others are somehow interconnected and therefore it makes sense to have it
in one patch serie.
Send one patch series which are related to updates/fixes to already supported code.
Then send anther patch series for addition of new boards, mention the dependency if any.
Regards..
Prafulla . . .
PATCH 4/20 arm/km: add kmnusa board support
Quoted 73 lines · Prafulla Wadaskar
Quoted 73 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 17:13
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 29 lines · Prafulla Wadaskar
Quoted 29 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 12 June 2012 16:07
To: Prafulla Wadaskar
Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de; Gerlando Falauto
Subject: Re: [PATCH 04/20] arm/km: add kmnusa board supportQuoted 18 lines · Prafulla Wadaskar
Quoted 18 lines
Quoted 18 lines
Quoted 12 lines
board/keymile/km_arm/km_arm.c | 9 +- boards.cfg | 1 + include/configs/km/km_arm.h | 44 +++++- include/configs/km_kirkwood.h | 67 +++++++-- 6 files changed, 392 insertions(+), 24 deletions(-) create mode 100644 board/keymile/km_arm/128M16-1.cfgMAINTAINERS +0
-0MAINTAINERS Sergey Lapin <[email protected]> · line 741
Quoted 4 lines
MAINTAINERS +1
-0@@ -738,6 +738,7 @@ Sergey Lapin <[email protected]> Valentin Longchamp <[email protected]> km_kirkwood ARM926EJS (Kirkwood SoC) + kmnusa ARM926EJS (Kirkwood SoC)Again.... I would like to suggest to separate out new boards
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
Quoted 1 line
addition, bugfixes/updates specific to km_*boards and generic
kirkwood
Quoted 6 lines
Quoted 6 lines
specific patches.
Quoted 3 lines
It's always faster to merger small patch series that big one.
Yes ok, but was has this to do with this patch? What is meant to
be
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
kirkwood
specific? This is all board related code.I agree, let's separate out -
1. bugfix/updates patch series to current code
2. "Kirkwood specific" means the changes to the Kirkwood relatedfile that may affects other boards, for ex
arch/arm/cpu/arm926ejs/mach-kirkwood/*Quoted 3 lines
3. Additional board supports
And if possible these patches should be independent so that can be
Quoted 8 lines
Quoted 8 lines
pulled independently
Quoted 1 line
the only patch in the serie which modifies common Kirkwood related files are:
[PATCH 03/20] arm/kirkwood: protect theENV_SPI#definesDo you want me to send this one seperately? I can do that. So then
we
Quoted 4 lines
Quoted 2 lines
resend
again a new patch serie I guess...It would be a great you can split 20 patches in to smaller patch
Quoted 9 lines
Quoted 6 lines
series as per above suggestion.
Quoted 1 line
Again, the only patch wich is common Kirkwood related is the above mentioned
patch. I can extract this one if you want me to.Yes, extract this and send it as standalone
ok done.
Quoted 9 lines
Quoted 4 lines
All others are somehow interconnected and therefore it makes sense to have it
in one patch serie.Send one patch series which are related to updates/fixes to already supported code.
Then send anther patch series for addition of new boards, mention the dependency if any.
Sorry but this does not make sense to me, why should we provide independent patch series which are in the end not independent?
Why is it important to first add updates for old boards and then add new boards? This causes a lot of work for rebasing and retesting for an already well tested patch serie. Can't we focus on your precise inputs to the real code and not on the sequence of the patches?
Best regards
Holger
PATCH 5/20 arm/km: add kmcoge5un board support
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
For u-boot this board is similar to mgcoge3un. But some differences are present. We have a different SDRAM on it and therefore a new SDRAM config file. Additionaly this board has a direct MAC/MAC connection from the kirkwood to a marvell simple switch without a phy inbetween, this needs a new configuration for the mvgbe driver.
--- MAINTAINERS | 1 + board/keymile/km_arm/256M8-1.cfg | 296 ++++++++++++++++++++++++++++++++++++++ boards.cfg | 1 + include/configs/km_kirkwood.h | 16 ++- 4 files changed, 312 insertions(+), 2 deletions(-) create mode 100644 board/keymile/km_arm/256M8-1.cfg
MAINTAINERS +1 -0
@@ -740,6 +740,7 @@ Valentin Longchamp <[email protected]> km_kirkwood ARM926EJS (Kirkwood SoC) kmnusa ARM926EJS (Kirkwood SoC) mgcoge3un ARM926EJS (Kirkwood SoC) + kmcoge5un ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) Nishanth Menon <[email protected]>
board/keymile/km_arm/256M8-1.cfg new file +296 -0
296 lines not on this page · raw message
boards.cfg +1 -0
@@ -142,6 +142,7 @@ km_kirkwood arm arm926ejs km_arm keymile km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA mgcoge3un arm arm926ejs km_arm keymile kirkwood +kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KMCOGE5UN portl2 arm arm926ejs km_arm keymile kirkwood inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2 net2big_v2 arm arm926ejs net2big_v2 LaCie kirkwood lacie_kw:NET2BIG_V2
include/configs/km_kirkwood.h +14 -2
@@ -39,15 +39,18 @@#if defined(CONFIG_KM_KIRKWOOD )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood" +#define CONFIG_HOSTNAME km_kirkwood#undef CONFIG_KIRKWOOD_PCIE_INIT#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ #elif defined(CONFIG_KM_KIRKWOOD_PCI )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood PCI" +#define CONFIG_HOSTNAME km_kirkwood_pci#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ /* KM_NUSA */ #elif defined(CONFIG_KM_NUSA )#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/ #define CONFIG_IDENT_STRING "\nKeymile NUSA" +#define CONFIG_HOSTNAME kmnusa#undef CONFIG_SYS_KWD_CONFIG#define CONFIG_SYS_KWD_CONFIG \ $(SRCTREE)/$(CONFIG_BOARDDIR)/128M16-1.cfg
@@ -55,6 +58,17 @@#define CONFIG_KM_FPGA_CONFIG #define CONFIG_KM_PIGGY4_88E6352 +#elif defined(CONFIG_KMCOGE5UN ) +#define CONFIG_IDENT_STRING "\nKeymile COGE5UN" +#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/ +#undef CONFIG_SYS_KWD_CONFIG +#define CONFIG_SYS_KWD_CONFIG \ + $(SRCTREE)/$(CONFIG_BOARDDIR)/256M8-1.cfg +#define CONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_PIGGY_MAC_ADRESS_OFFSET 3 +#define CONFIG_HOSTNAME kmcoge5un +#define CONFIG_KM_DISABLE_PCIE +#define CONFIG_KM_PIGGY4_88E6352 #else #error ("Board unsupported")#endif
@@ -62,8 +76,6 @@/* include common defines/options for all arm based Keymile boards */ #include "km/km_arm.h" -#define CONFIG_HOSTNAME km_kirkwood -#ifndef CONFIG_KM_ENV_IS_IN_SPI_NOR #define KM_ENV_BUS "pca9544a:70:d"/* I2C2 (Mux-Port 5)*/ #endif
Signature · 1 line
1.7.1
PATCH 5/20 arm/km: add kmcoge5un board support
Quoted 10 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 05/20] arm/km: add kmcoge5un board support
Quoted 4 lines
From: Holger Brunck <[email protected]>
For u-boot this board is similar to mgcoge3un. But some differences are present. We have a different SDRAM on it and therefore a new
What are the changes in SDRAM? Can that be handled through board_init() instead of adding a configuration file?
Quoted 11 lines
SDRAM config file. Additionaly this board has a direct MAC/MAC connection from the kirkwood to a marvell simple switch without a phy inbetween, this needs a new configuration for the mvgbe driver.
Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- MAINTAINERS | 1 + board/keymile/km_arm/256M8-1.cfg | 296
Please do not use names starting with numbers.
Quoted 12 lines
++++++++++++++++++++++++++++++++++++++
boards.cfg | 1 + include/configs/km_kirkwood.h | 16 ++- 4 files changed, 312 insertions(+), 2 deletions(-) create mode 100644 board/keymile/km_arm/256M8-1.cfgMAINTAINERS +0
-0@@ -740,6 +740,7 @@ Valentin Longchamp
Quoted 4 lines
km_kirkwood ARM926EJS (Kirkwood SoC)
kmnusa ARM926EJS (Kirkwood SoC)
mgcoge3un ARM926EJS (Kirkwood SoC)
+ kmcoge5un ARM926EJS (Kirkwood SoC)Can it be km_coge5un?
Quoted 362 lines
portl2 ARM926EJS (Kirkwood SoC)
Nishanth Menon <[email protected]>
board/keymile/km_arm/256M8-1.cfg new file +144
-0@@ -0,0 +1,296 @@ +# +# (C) Copyright 2012 +# Stefan Bigler, Keymile AG, stefan.bigler at keymile.com +# Norbert Mayer, Keymile AG, norbert.mayer at keymile.com +# Deepak Patel, XENTECH Limited, deepak.patel at xentech.co.uk +# +# See file CREDITS for list of people who contributed to this +# project. +# +# 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. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# +# This configuration applies to COGE5 design (ARM-part) +# Two 8-Bit devices are connected on the 16-Bit bus on the same +# chip-select. The supported devices are +# MT47H256M8EB-3IT:C +# MT47H256M8EB-25EIT:C + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +DATA 0xFFD10000 0x01112222 # MPP Control 0 Register +# bit 3-0: 2, MPPSel0 SPI_CSn (1=NF_IO[2]) +# bit 7-4: 2, MPPSel1 SPI_MOSI (1=NF_IO[3]) +# bit 12-8: 2, MPPSel2 SPI_SCK (1=NF_IO[4]) +# bit 15-12: 2, MPPSel3 SPI_MISO (1=NF_IO[5]) +# bit 19-16: 1, MPPSel4 NF_IO[6] +# bit 23-20: 1, MPPSel5 NF_IO[7] +# bit 27-24: 1, MPPSel6 SYSRST_O +# bit 31-28: 0, MPPSel7 GPO[7] + +DATA 0xFFD10004 0x03303300 # MPP Control 1 Register +# bit 3-0: 0, MPPSel8 GPIO[8] CPU_SDA bitbanged +# bit 7-4: 0, MPPSel9 GPIO[9] CPU_SCL bitbanged +# bit 12-8: 3, MPPSel10 UA0_TXD +# bit 15-12: 3, MPPSel11 UA0_RXD +# bit 19-16: 0, MPPSel12 not connected +# bit 23-20: 3, MPPSel13 GPIO[14] +# bit 27-24: 3, MPPSel14 GPIO[15] +# bit 31-28: 0, MPPSel15 GPIO[16] BOOT_FL_SEL (SPI-MUX Signal) + +DATA 0xFFD10008 0x00001100 # MPP Control 2 Register +# bit 3-0: 0, MPPSel16 GPIO[16] +# bit 7-4: 0, MPPSel17 not connected +# bit 11-8: 1, MPPSel18 NF_IO[0] +# bit 15-12: 1, MPPSel19 NF_IO[1] +# bit 19-16: 0, MPPSel20 GPIO[20] +# bit 23-20: 0, MPPSel21 GPIO[21] +# bit 27-24: 0, MPPSel22 GPIO[22] +# bit 31-28: 0, MPPSel23 GPIO[23] + +# MPP Control 3-6 Register untouched (MPP24-49) + +DATA 0xFFD100E0 0x1B1B1B1B # IO Configuration 0 Register +# bit 2-0: 3, Reserved +# bit 5-3: 3, Reserved +# bit 6: 0, Reserved +# bit 7: 0, RGMII-pads voltage = 3.3V +# bit 10-8: 3, Reserved +# bit 13-11: 3, Reserved +# bit 14: 0, Reserved +# bit 15: 0, MPP RGMII-pads voltage = 3.3V +# bit 31-16 0x1B1B, Reserved + +DATA 0xFFD20134 0x66666666 # L2 RAM Timing 0 Register +# bit 0-1: 2, Tag RAM RTC RAM0 +# bit 3-2: 1, Tag RAM WTC RAM0 +# bit 7-4: 6, Reserved +# bit 9-8: 2, Valid RAM RTC RAM +# bit 11-10: 1, Valid RAM WTC RAM +# bit 13-12: 2, Dirty RAM RTC RAM +# bit 15-14: 1, Dirty RAM WTC RAM +# bit 17-16: 2, Data RAM RTC RAM0 +# bit 19-18: 1, Data RAM WTC RAM0 +# bit 21-20: 2, Data RAM RTC RAM1 +# bit 23-22: 1, Data RAM WTC RAM1 +# bit 25-24: 2, Data RAM RTC RAM2 +# bit 27-26: 1, Data RAM WTC RAM2 +# bit 29-28: 2, Data RAM RTC RAM3 +# bit 31-30: 1, Data RAM WTC RAM4 + +DATA 0xFFD20138 0x66666666 # L2 RAM Timing 1 Register +# bit 15-0: ?, Reserved +# bit 17-16: 2, ECC RAM RTC RAM0 +# bit 19-18: 1, ECC RAM WTC RAM0 +# bit 31-20: ?,Reserved + +DATA 0xFFD20154 0x00000200 # CPU RAM Management Control3 Register +# bit 23-0: 0x000200, Addr Config tuning +# bit 31-24: 0, Reserved + +# ??? Missing register # CPU RAM Management Control2 Register + +DATA 0xFFD2014C 0x00001C00 # CPU RAM Management Control1 Register +# bit 15-0: 0x1C00, Opmux Tuning +# bit 31-16: 0, Pc Dp Tuning + +DATA 0xFFD20148 0x00000001 # CPU RAM Management Control0 Register +# bit 1-0: 1, addr clk tune +# bit 3-2: 0, reserved +# bit 5-4: 0, dtcmp clk tune +# bit 7-6: 0, reserved +# bit 9-8: 0, macdrv clk tune +# bit 11-10: 0, opmuxgm2 clk tune +# bit 15-14: 0, rf clk tune +# bit 17-16: 0, rfbypass clk tune +# bit 19-18: 0, pc dp clk tune +# bit 23-20: 0, icache clk tune +# bit 27:24: 0, dcache clk tune +# bit 31:28: 0, regfile tunin + +# SDRAM initalization +DATA 0xFFD01400 0x430004E0 # SDRAM Configuration Register +# bit 13-0: 0x4E0, DDR2 clks refresh rate +# bit 14: 0, reserved +# bit 15: 0, reserved +# bit 16: 0, CPU to Dram Write buffer policy +# bit 17: 0, Enable Registered DIMM or Equivalent Sampling Logic +# bit 19-18: 0, reserved +# bit 23-20: 0, reserved +# bit 24: 1, enable exit self refresh mode on DDR access +# bit 25: 1, required +# bit 29-26: 0, reserved +# bit 31-30: 1, reserved + +DATA 0xFFD01404 0x36543000 # DDR Controller Control Low +# bit 3-0: 0, reserved +# bit 4: 0, 2T mode =addr/cmd in same cycle +# bit 5: 0, clk is driven during self refresh, we don't care forAPX
board/keymile/km_arm/256M8-1.cfg new file +8
-0+# bit 6: 0, use recommended falling edge of clk for addr/cmd +# bit 7-11: 0, reserved +# bit 12-13: 1, reserved, required 1 +# bit 14: 0, input buffer always powered up +# bit 17-15: 0, reserved +# bit 18: 1, cpu lock transaction enabled +# bit 19: 0, reserved +# bit 23-20: 5, recommended value for CL=4 and STARTBURST_DELdisabled bit31=0
+# bit 27-24: 6, CL+1, STARTBURST sample stages, freq 200-399MHz, unbuffer DIMMboard/keymile/km_arm/256M8-1.cfg new file +95
-0+# bit 30-28: 3, required +# bit 31: 0, no additional STARTBURST delay + +DATA 0xFFD01408 0x2202444E # DDR Timing (Low) (active cycles value +1) +# bit 3-0: 0xe, TRAS = 45ns -> 15 clk cycles +# bit 7-4: 0x4, TRCD = 15ns -> 5 clk cycles +# bit 11-8: 0x4, TRP = 15ns -> 5 clk cycles +# bit 15-12: 0x4, TWR = 15ns -> 5 clk cycles +# bit 19-16: 0x2, TWTR = 7,5ns -> 3 clk cycles +# bit 20: 0, extended TRAS msb +# bit 23-21: 0, reserved +# bit 27-24: 0x2, TRRD = 7,5ns -> 3 clk cycles +# bit 31-28: 0x2, TRTP = 7,5ns -> 3 clk cycles + +DATA 0xFFD0140C 0x0000003E # DDR Timing (High) +# bit 6-0: 0x3E, TRFC = 195ns -> 63 clk cycles +# bit 8-7: 0, TR2R +# bit 10-9: 0, TR2W +# bit 12-11: 0, TW2W +# bit 31-13: 0, reserved + +DATA 0xFFD01410 0x00000000 # DDR Address Control +# bit 1-0: 0, Cs0width=x8 (2 devices) +# bit 3-2: 0, Cs0size=2Gb +# bit 5-4: 0, Cs1width=nonexistent +# bit 7-6: 0, Cs1size =nonexistent +# bit 9-8: 0, Cs2width=nonexistent +# bit 11-10: 0, Cs2size =nonexistent +# bit 13-12: 0, Cs3width=nonexistent +# bit 15-14: 0, Cs3size =nonexistent +# bit 16: 0, Cs0AddrSel +# bit 17: 0, Cs1AddrSel +# bit 18: 0, Cs2AddrSel +# bit 19: 0, Cs3AddrSel +# bit 31-20: 0, required + +DATA 0xFFD01414 0x00000000 # DDR Open Pages Control +# bit 0: 0, OpenPage enabled +# bit 31-1: 0, required + +DATA 0xFFD01418 0x00000000 # DDR Operation +# bit 3-0: 0, DDR cmd +# bit 31-4: 0, required + +DATA 0xFFD0141C 0x00000652 # DDR Mode +# bit 2-0: 2, Burst Length = 4 +# bit 3: 0, Burst Type +# bit 6-4: 5, CAS Latency = 5 +# bit 7: 0, Test mode +# bit 8: 0, DLL Reset +# bit 11-9: 3, Write recovery for auto-precharge must be 3 +# bit 12: 0, Active power down exit time, fast exit +# bit 14-13: 0, reserved +# bit 31-15: 0, reserved + +DATA 0xFFD01420 0x00000006 # DDR Extended Mode +# bit 0: 0, DDR DLL enabled +# bit 1: 1, DDR drive strenght reduced +# bit 2: 1, DDR ODT control lsb, 75ohm termination [RTT0] +# bit 5-3: 0, required +# bit 6: 0, DDR ODT control msb, 75ohm termination [RTT1] +# bit 9-7: 0, required +# bit 10: 0, differential DQS enabled +# bit 11: 0, required +# bit 12: 0, DDR output buffer enabled +# bit 31-13: 0 required + +DATA 0xFFD01424 0x0000F17F # DDR Controller Control High +# bit 2-0: 7, required +# bit 3: 1, MBUS Burst Chop disabled +# bit 6-4: 7, required +# bit 7: 0, reserved +# bit 8: 1, add sample stage required for > 266Mhz +# bit 9: 0, no half clock cycle addition to dataout +# bit 10: 0, 1/4 clock cycle skew enabled for addr/ctl signals +# bit 11: 0, 1/4 clock cycle skew disabled for write mesh +# bit 15-12:0xf, required +# bit 31-16: 0, required + +DATA 0xFFD01428 0x00084520 # DDR2 SDRAM Timing Low +# bit 3-0: 0, required +# bit 7-4: 2, M_ODT assertion 2 cycles after read start command +# bit 11-8: 5, M_ODT de-assertion 5 cycles after read start command +# (ODT turn off delay 2,5 clk cycles) +# bit 15-12: 4, internal ODT time based on bit 7-4 +# with the considered SDRAM internal delay +# bit 19-16: 8, internal ODT de-assertion based on bit 11-8 +# with the considered SDRAM internal delay +# bit 31-20: 0, required + +DATA 0xFFD0147c 0x00008452 # DDR2 SDRAM Timing High +# bit 3-0: 2, M_ODT assertion same as bit 11-8 +# bit 7-4: 5, M_ODT de-assertion same as bit 15-12 +# bit 11-8: 4, internal ODT assertion 2 cycles after write startcommand
board/keymile/km_arm/256M8-1.cfg new file +2
-0+# with the considered SDRAM internal delay +# bit 15-12: 8, internal ODT de-assertion 5 cycles after write startcommand
board/keymile/km_arm/256M8-1.cfg new file +19
-0+# with the considered SDRAM internal delay + +DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0 +# bit 23-0: 0, reserved +# bit 31-24: 0, CPU CS Window0 Base Address, addr bits [31:24] + +DATA 0xFFD01504 0x1FFFFFF1 # CS[0]n Size +# bit 0: 1, Window enabled +# bit 1: 0, Write Protect disabled +# bit 3-2: 0, CS0 hit selected +# bit 23-4:ones, required +# bit 31-24:0x1F, Size (i.e. 512MB) + +DATA 0xFFD0150C 0x00000000 # CS[1]n Size, window disabled +DATA 0xFFD01514 0x00000000 # CS[2]n Size, window disabled +DATA 0xFFD0151C 0x00000000 # CS[3]n Size, window disabled + +DATA 0xFFD01494 0x00010000 # DDR ODT Control (Low) +# bit 3-0: 0, ODT0Rd, MODT[0] not asserted during read from DRAMCS0
board/keymile/km_arm/256M8-1.cfg new file +15
-0+# bit 7-4: 0, ODT0Rd, MODT[1] not asserted +# bit 11-8: 0, required +# big 15-11: 0, required +# bit 19-16: 1, ODT0Wr, MODT[0] asserted during write to DRAM CS0 +# bit 23-20: 0, ODT0Wr, MODT[1] not asserted +# bit 27-24: 0, required +# bit 31-28: 0, required + +DATA 0xFFD01498 0x00000004 # DDR ODT Control (High) +# bit 1-0: 0, ODT0 controlled by ODT Control (low) register above +# bit 3-2: 1, ODT1 never active +# bit 31-4: 0, required + +DATA 0xFFD0149C 0x0000E801 # CPU ODT Control +# bit 3-0: 1, ODT0Rd, Internal ODT asserted during read from DRAMbank0
+# bit 7-4: 0, ODT0Wr, Internal ODT not asserted during write to
DRAM bank0board/keymile/km_arm/256M8-1.cfg new file +12
-0+# bit 9-8: 0, ODTEn, controlled by ODT0Rd and ODT0Wr +# bit 11-10: 2, DQ_ODTSel. ODT select turned on, 75 ohm +# bit 13-12: 2, STARTBURST ODT buffer selected, 75 ohm +# bit 14: 1, STARTBURST ODT enabled +# bit 15: 1, Use ODT Block + +DATA 0xFFD01480 0x00000001 # DDR Initialization Control +# bit 0: 1, enable DDR init upon this register write +# bit 31-1: 0, reserved + +# End of Header extension +DATA 0x0 0x0boards.cfg +0
-0@@ -142,6 +142,7 @@ km_kirkwood arm arm926ejs
km_armkeymile
km_kirkwood_pciarm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX
kmnusa arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood
+kmcoge5un arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KMCOGE5UN
portl2 arm arm926ejskm_arm
keymile kirkwoodinetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2 net2big_v2 arm arm926ejs net2big_v2 LaCie kirkwood lacie_kw:NET2BIG_V2include/configs/km_kirkwood.h +3
-0@@ -39,15 +39,18 @@#if defined(CONFIG_KM_KIRKWOOD )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood" +#define CONFIG_HOSTNAME km_kirkwood#undef CONFIG_KIRKWOOD_PCIE_INIT#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ #elif defined(CONFIG_KM_KIRKWOOD_PCI )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood PCI" +#define CONFIG_HOSTNAME km_kirkwood_pci#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ /* KM_NUSA */ #elif defined(CONFIG_KM_NUSA )#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/ #define CONFIG_IDENT_STRING "\nKeymile NUSA" +#define CONFIG_HOSTNAME kmnusa#undef CONFIG_SYS_KWD_CONFIG#define CONFIG_SYS_KWD_CONFIG \ $(SRCTREE)/$(CONFIG_BOARDDIR)/128M16-1.cfg@@ -55,6 +58,17 @@#define CONFIG_KM_FPGA_CONFIG #define CONFIG_KM_PIGGY4_88E6352
include/configs/km_kirkwood.h line 69
Quoted 10 lines
include/configs/km_kirkwood.h +9
-0+#elif defined(CONFIG_KMCOGE5UN ) +#define CONFIG_IDENT_STRING "\nKeymile COGE5UN" +#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/ +#undef CONFIG_SYS_KWD_CONFIG +#define CONFIG_SYS_KWD_CONFIG \ + $(SRCTREE)/$(CONFIG_BOARDDIR)/256M8-1.cfg +#define CONFIG_KM_ENV_IS_IN_SPI_NOR +#define CONFIG_PIGGY_MAC_ADRESS_OFFSET 3 +#define CONFIG_HOSTNAME kmcoge5un
Changes related to CONFIG_HOSTNAME does not looks new board addition related, it's good to abstract them out as updates of bugfixes.
Regards..
Prafulla . . .
PATCH 6/20 arm/km: convert mgcoge3un target to km_kirkwood
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
Use the generic header km_kirkwood.h and get rid of the board specific header.
--- board/keymile/km_arm/km_arm.c | 9 ++-- boards.cfg | 2 +- include/configs/km_kirkwood.h | 46 +++++++++++++++++++++ include/configs/mgcoge3un.h | 87 ----------------------------------------- 4 files changed, 51 insertions(+), 93 deletions(-) delete mode 100644 include/configs/mgcoge3un.h
board/keymile/km_arm/km_arm.c +4 -5
@@ -113,7 +113,7 @@ u32 kwmpp_config[] = { 0 }; -#if defined(CONFIG_MGCOGE3UN ) +#if defined(CONFIG_KM_MGCOGE3UN )/* * Wait for startup OK from mgcoge3ne */
@@ -133,8 +133,7 @@ int startup_allowed(void) }#endif -#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )| \ - defined(CONFIG_KM_PIGGY4_88E6352 )) +#if (defined(CONFIG_KM_PIGGY4_88E6061 )|defined(CONFIG_KM_PIGGY4_88E6352 ))/* * All boards with PIGGY4 connected via a simple switch have ethernet always * present.
@@ -202,7 +201,7 @@ int misc_init_r(void)printf ("Overwriting MACH_TYPE with %d!!!\n" , mach_type); gd->bd->bi_arch_number = mach_type; } -#if defined(CONFIG_MGCOGE3UN ) +#if defined(CONFIG_KM_MGCOGE3UN )char *wait_for_ne; wait_for_ne =getenv ("waitforne" );if (wait_for_ne !=NULL ) {
@@ -351,7 +350,7 @@ void dram_init_banksize(void) } } -#if (defined(CONFIG_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_KM_MGCOGE3UN )|defined(CONFIG_PORTL2 ))#define PHY_LED_SEL 0x18#define PHY_LED0_LINK (0x5)
boards.cfg +1 -1
@@ -141,7 +141,7 @@ dns325 arm arm926ejs - d-link km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA -mgcoge3un arm arm926ejs km_arm keymile kirkwood +mgcoge3un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_MGCOGE3UN kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KMCOGE5UN portl2 arm arm926ejs km_arm keymile kirkwood inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2
include/configs/km_kirkwood.h +46 -0
59 lines not on this page · raw message
include/configs/mgcoge3un.h deleted +0 -87
87 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 7/20 arm/km: remove portl2.h and use km_kirkwood instead
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
The additional headerfile is unneeded here, we can use the generic km_kirkwood.h instead. And we can use the better config option KM_PIGGY4_88E6061 for the specific features for boards with this design in km_arm.c.
--- board/keymile/km_arm/km_arm.c | 2 +- boards.cfg | 2 +- include/configs/km_kirkwood.h | 8 ++++ include/configs/portl2.h | 85 ----------------------------------------- 4 files changed, 10 insertions(+), 87 deletions(-) delete mode 100644 include/configs/portl2.h
board/keymile/km_arm/km_arm.c +1 -1
@@ -350,7 +350,7 @@ void dram_init_banksize(void) } } -#if (defined(CONFIG_KM_MGCOGE3UN )|defined(CONFIG_PORTL2 )) +#if (defined(CONFIG_KM_PIGGY4_88E6061 ))#define PHY_LED_SEL 0x18#define PHY_LED0_LINK (0x5)
boards.cfg +1 -1
@@ -143,7 +143,7 @@ km_kirkwood_pci arm arm926ejs km_arm keymile kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA mgcoge3un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_MGCOGE3UN kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KMCOGE5UN -portl2 arm arm926ejs km_arm keymile kirkwood +portl2 arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_PORTL2 inetspace_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:INETSPACE_V2 net2big_v2 arm arm926ejs net2big_v2 LaCie kirkwood lacie_kw:NET2BIG_V2 netspace_max_v2 arm arm926ejs netspace_v2 LaCie kirkwood lacie_kw:NETSPACE_MAX_V2
include/configs/km_kirkwood.h +8 -0
@@ -83,6 +83,14 @@#define CONFIG_HOSTNAME kmcoge5un#define CONFIG_KM_DISABLE_PCIE #define CONFIG_KM_PIGGY4_88E6352 + +/* KM_PORTL2 */ +#elif defined(CONFIG_KM_PORTL2 ) +#define CONFIG_IDENT_STRING "\nKeymile Port-L2" +#define CONFIG_HOSTNAME portl2 +#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ +#define CONFIG_KM_PIGGY4_88E6061 +#else #error ("Board unsupported")#endif
include/configs/portl2.h deleted +0 -85
85 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 8/20 arm/km: correct init of 88e6352 switch in the reset_phy function
In reply to Valentin LongchampThis is achieved thanks to the support read/write regs for the external 88e6352 switch. The functions for this are added into an own file managed_switch.c. This is compiled if the define CONFIG_KM_MANAGED_SW_ADDR was set in the board setup. This define specifies the phy address.
--- board/keymile/common/common.h | 6 + board/keymile/km_arm/Makefile | 4 + board/keymile/km_arm/km_arm.c | 26 +++++- board/keymile/km_arm/managed_switch.c | 166 +++++++++++++++++++++++++++++++++ include/configs/km_kirkwood.h | 13 +++ 5 files changed, 214 insertions(+), 1 deletions(-) create mode 100644 board/keymile/km_arm/managed_switch.c
board/keymile/common/common.h +6 -0
@@ -125,6 +125,12 @@ struct bfticu_iomap {int ethernet_present (void );int ivm_read_eeprom (void ); + +int ext_switch_reg_write (const char *devname,u8 phy_addr,u8 port, +u8 reg,u16 data); +int ext_switch_reg_read (const char *devname,u8 phy_addr,u8 port, +u8 reg,u16 *data); +int set_km_env (void ); int fdt_set_node_and_value(void *blob, char *nodename,
board/keymile/km_arm/Makefile +4 -0
@@ -31,6 +31,10 @@ LIB = $(obj)lib$(BOARD).o COBJS := $(BOARD).o ../common/common.o ../common/ivm.o +ifdef CONFIG_KM_MANAGED_SW_ADDR +COBJS += managed_switch.o +endif + SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) SOBJS := $(addprefix $(obj),$(SOBJS))
board/keymile/km_arm/km_arm.c +25 -1
@@ -9,6 +9,9 @@* (C) Copyright 2010 * Heiko Schocher, DENX Software Engineering, hs at denx.de. * +* (C) Copyright 2011, 2012 +* Valentin Lontgchamp, Keymile AG, valentin.longchamp at keymile.com +* * See file CREDITS for list of people who contributed to this * project. *
@@ -35,6 +38,7 @@#include <miiphy.h> #include <asm/io.h> #include <asm/arch/cpu.h> +#include <asm/errno.h> #include <asm/arch/kirkwood.h> #include <asm/arch/mpp.h>
@@ -384,7 +388,27 @@ void reset_phy(void)/* reset the phy */ miiphy_reset(name, CONFIG_PHY_BASE_ADR); } -#elif !defined(CONFIG_KM_PIGGY4_88E6352) +#elif defined(CONFIG_KM_PIGGY4_88E6352) + +#if defined(CONFIG_KM_MANAGED_SW_ADDR ) +void reset_phy (void ) +{ +char *name ="egiga0" ; + +if (miiphy_set_current_dev (name)) +return ; + +/* enable autoneg on port 0 phy */ +ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,0 ,0 ,0x3300 ); + +/* egress broadcast franes on all macs, with forwarding */ +ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,16 ,4 ,0x000f ); +ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,20 ,4 ,0x000f ); +ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,21 ,4 ,0x000f ); +} +#endif + +#else /* Configure and enable MV88E1118 PHY on the piggy*/ void reset_phy (void ) {
board/keymile/km_arm/managed_switch.c new file +166 -0
166 lines not on this page · raw message
include/configs/km_kirkwood.h +13 -0
@@ -58,6 +58,7 @@#define CONFIG_KM_FPGA_CONFIG #define CONFIG_KM_PIGGY4_88E6352 +#define CONFIG_KM_MANAGED_SW_ADDR 0x10/* KM_MGCOGE3UN */ #elif defined(CONFIG_KM_MGCOGE3UN )#define CONFIG_IDENT_STRING "\nKeymile COGE3UN"
@@ -131,6 +132,18 @@ MVGBE_SET_GMII_SPEED_TO_1000 |\ MVGBE_SET_MII_SPEED_TO_100) +/* +* There is no phy on the eth interface, but an external switch +* For kmcoge5un it is completely unmanaged, so we disable an access to it +* For km_nusa, we an MDIO(MII) interface that can configure the switch trough +* an indirect access, so we do not disable the MII +*/ +#ifndef CONFIG_KM_MANAGED_SW_ADDR +#undef CONFIG_MII +#undef CONFIG_CMD_MII +#undef CONFIG_RESET_PHY_R +#endif +#endif #ifdef CONFIG_KM_PIGGY4_88E6061
Signature · 1 line
1.7.1
PATCH 9/20 arm/km: enable BOCO2 FPGA download support
In reply to Valentin LongchampThis adds a first support of the FPGA download for a PCIe FPGA based on the BOCO2 CPLD.
This takes place in 3 steps, all done accessing the SPICTRL reg of the BOCO2:
1) start the FPGA config with an access to the FPGA_PROG bit
2) later in the boot sequence, wait for the FPGA_DONE bit to toggle to 1 for the end of the FPGA configuration (with a timeout)
3) reset the FPGA
4) finally remove the access to its config EEPROM from the FPGA so that the CPU can update the FPGA configuration when the kernel is running
The boards with a PCIe FPGA but without BOCO2 still are supported.
The config option name is CONFIG_KM_FPGA_CONFIG
--- board/keymile/common/common.h | 6 + board/keymile/km_arm/Makefile | 4 + board/keymile/km_arm/fpga_config.c | 212 ++++++++++++++++++++++++++++++++++++ board/keymile/km_arm/km_arm.c | 21 +++- boards.cfg | 2 +- include/configs/km/km_arm.h | 3 + include/configs/km_kirkwood.h | 8 +- 7 files changed, 246 insertions(+), 10 deletions(-) create mode 100644 board/keymile/km_arm/fpga_config.c
board/keymile/common/common.h +6 -0
@@ -131,6 +131,12 @@ int ext_switch_reg_write(const char *devname, u8 phy_addr, u8 port,int ext_switch_reg_read (const char *devname,u8 phy_addr,u8 port,u8 reg,u16 *data); + +int trigger_fpga_config (void ); +int wait_for_fpga_config (void ); +int fpga_reset (void ); +int toggle_eeprom_spi_bus (void ); +int set_km_env (void ); int fdt_set_node_and_value(void *blob, char *nodename,
board/keymile/km_arm/Makefile +4 -0
@@ -31,6 +31,10 @@ LIB = $(obj)lib$(BOARD).o COBJS := $(BOARD).o ../common/common.o ../common/ivm.o +ifdef CONFIG_KM_FPGA_CONFIG +COBJS += fpga_config.o +endif + ifdef CONFIG_KM_MANAGED_SW_ADDR COBJS += managed_switch.o endif
board/keymile/km_arm/fpga_config.c new file +212 -0
212 lines not on this page · raw message
board/keymile/km_arm/km_arm.c +15 -6
@@ -268,12 +268,6 @@ int board_early_init_f(void)kw_gpio_set_valid (KM_KIRKWOOD_ENV_WP ,38 );kw_gpio_direction_output (KM_KIRKWOOD_ENV_WP ,1 );#endif -#if defined(CONFIG_KM_RECONFIG_XLX ) -/* trigger the reconfiguration of the xilinx fpga */ -kw_gpio_set_valid (KM_XLX_PROGRAM_B_PIN ,1 ); -kw_gpio_direction_output (KM_XLX_PROGRAM_B_PIN ,0 ); -kw_gpio_direction_input (KM_XLX_PROGRAM_B_PIN ); -#endif return 0 ; }
@@ -282,6 +276,21 @@ int board_init(void)/* address of boot parameters */ gd->bd->bi_boot_params =kw_sdram_bar (0 ) +0x100 ; +#if defined(CONFIG_KM_FPGA_CONFIG ) +trigger_fpga_config (); +#endif + +return 0 ; +} + +int board_late_init (void ) +{ +#if defined(CONFIG_KM_FPGA_CONFIG ) +wait_for_fpga_config (); +fpga_reset (); +toggle_eeprom_spi_bus (); +#endif +return 0 ; }
boards.cfg +1 -1
@@ -139,7 +139,7 @@ calimain arm arm926ejs calimain omicron pogo_e02 arm arm926ejs - cloudengines kirkwood dns325 arm arm926ejs - d-link kirkwood km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI -km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_RECONFIG_XLX +km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_FPGA_CONFIG kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA mgcoge3un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_MGCOGE3UN kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KMCOGE5UN
include/configs/km/km_arm.h +3 -0
@@ -311,4 +311,7 @@ int get_scl(void);#define CONFIG_POST_EXTERNAL_WORD_FUNCS #define CONFIG_CMD_DIAG +/* we do the whole PCIe FPGA config stuff here */ +#define BOARD_LATE_INIT +#endif /* _CONFIG_KM_ARM_H */
include/configs/km_kirkwood.h +5 -3
@@ -175,10 +175,12 @@ MVGBE_SET_MII_SPEED_TO_100)#endif -/* GPIO Pin from kirkwood connected to PROGRAM_B pin of the xilinx FPGA */ -#define KM_XLX_PROGRAM_B_PIN 39 -#ifdef CONFIG_KM_DISABLE_PCI #undef CONFIG_KIRKWOOD_PCIE_INIT#endif + +#ifndef CONFIG_KM_FPGA_CONFIG +#undef BOARD_LATE_INIT +#endif +#endif /* _CONFIG_KM_KIRKWOOD */
Signature · 1 line
1.7.1
PATCH 10/20 arm/km: cleanup km_kirkwood boards
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
Remove config options from boards.cfg and simply add one switch per board and differ afterwards in km_kirkwood.h between the features. More boards are upcoming and therefore it's easier to have this at one place.
--- boards.cfg | 4 ++-- include/configs/km_kirkwood.h | 7 ++++++- 2 files changed, 8 insertions(+), 3 deletions(-)
boards.cfg +2 -2
@@ -138,8 +138,8 @@ enbw_cmc arm arm926ejs enbw_cmc enbw calimain arm arm926ejs calimain omicron davinci pogo_e02 arm arm926ejs - cloudengines kirkwood dns325 arm arm926ejs - d-link kirkwood -km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI -km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_FPGA_CONFIG +km_kirkwood arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD +km_kirkwood_pci arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI kmnusa arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_NUSA mgcoge3un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KM_MGCOGE3UN kmcoge5un arm arm926ejs km_arm keymile kirkwood km_kirkwood:KMCOGE5UN
include/configs/km_kirkwood.h +6 -1
@@ -37,15 +37,20 @@#ifndef _CONFIG_KM_KIRKWOOD_H#define _CONFIG_KM_KIRKWOOD_H +/* KM_KIRKWOOD */ #if defined(CONFIG_KM_KIRKWOOD )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood"#define CONFIG_HOSTNAME km_kirkwood -#undef CONFIG_KIRKWOOD_PCIE_INIT +#define CONFIG_KM_DISABLE_PCIE #define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ + +/* KM_KIRKWOOD_PCI */ #elif defined(CONFIG_KM_KIRKWOOD_PCI )#define CONFIG_IDENT_STRING "\nKeymile Kirkwood PCI"#define CONFIG_HOSTNAME km_kirkwood_pci#define KM_IVM_BUS "pca9544a:70:9"/* I2C2 (Mux-Port 1)*/ +#define CONFIG_KM_FPGA_CONFIG +/* KM_NUSA */ #elif defined(CONFIG_KM_NUSA )#define KM_IVM_BUS "pca9547:70:9"/* I2C2 (Mux-Port 1)*/
Signature · 1 line
1.7.1
PATCH 10/20 arm/km: cleanup km_kirkwood boards
Quoted 44 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 10/20] arm/km: cleanupkm_kirkwoodboardsFrom: Holger Brunck <[email protected]>
Remove config options from boards.cfg and simply add one switch per board and differ afterwards in
km_kirkwood.hbetween the features. More boards are upcoming and therefore it's easier to have this at one place.Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- boards.cfg | 4 ++-- include/configs/km_kirkwood.h | 7 ++++++- 2 files changed, 8 insertions(+), 3 deletions(-)boards.cfg +0
-0@@ -138,8 +138,8 @@ enbw_cmc arm arm926ejs
enbw_cmcenbw
calimain arm arm926ejs calimain
omicron davinci
pogo_e02arm arm926ejs -
cloudengines kirkwood
dns325 arm arm926ejs -
d-link kirkwood
-km_kirkwood arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
-km_kirkwood_pci arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_FPGA_CONFIG
+km_kirkwood arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD
Quoted 8 lines
+km_kirkwood_pci arm arm926ejs
km_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI
kmnusa arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_MGCOGE3UN
kmcoge5un arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KMCOGE5UN
Can you maintain uniform naming here KMCODE5SUN should be KM_CODE5UN?
Regards..
Prafulla . . .
PATCH 10/20 arm/km: cleanup km_kirkwood boards
Quoted 46 lines · Prafulla Wadaskar
Quoted 46 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp; Gerlando Falauto; Prafulla Wadaskar
Subject: [PATCH 10/20] arm/km: cleanupkm_kirkwoodboardsFrom: Holger Brunck <[email protected]>
Remove config options from boards.cfg and simply add one switch per board and differ afterwards in
km_kirkwood.hbetween the features. More boards are upcoming and therefore it's easier to have this at one place.Signed-off-by Holger Brunck <[email protected]>Signed-off-by Valentin Longchamp <[email protected]>cc Gerlando Falauto <[email protected]>cc Prafulla Wadaskar <[email protected]>--- boards.cfg | 4 ++-- include/configs/km_kirkwood.h | 7 ++++++- 2 files changed, 8 insertions(+), 3 deletions(-)boards.cfg +0
-0@@ -138,8 +138,8 @@ enbw_cmc arm arm926ejs
enbw_cmcenbw
calimain arm arm926ejs calimain
omicron davinci
pogo_e02arm arm926ejs -
cloudengines kirkwood
dns325 arm arm926ejs -
d-link kirkwood
-km_kirkwood arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD,KM_DISABLE_PCI
-km_kirkwood_pci arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI,KM_FPGA_CONFIG
+km_kirkwood arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD
+km_kirkwood_pci arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_KIRKWOOD_PCI
Quoted 9 lines
Quoted 6 lines
kmnusa arm arm926ejs
km_arm
keymile kirkwood km_kirkwood:KM_NUSA
mgcoge3un arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KM_MGCOGE3UN
kmcoge5un arm arm926ejskm_arm
keymile kirkwood km_kirkwood:KMCOGE5UNCan you maintain uniform naming here KMCODE5SUN should be
KM_CODE5UN?
ok, I can fix this.
Regards
Holger
PATCH 11/20 arm/km: redefine piggy 4 reg names to avoid conflicts
In reply to Valentin LongchampSome very similar #defines for reg addresses are used in a later patch (managed_switch support for km_arm).
--- board/keymile/km_arm/km_arm.c | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-)
board/keymile/km_arm/km_arm.c +11 -11
@@ -365,13 +365,13 @@ void dram_init_banksize(void)#if (defined(CONFIG_KM_PIGGY4_88E6061 )) -#define PHY_LED_SEL 0x18 -#define PHY_LED0_LINK (0x5) -#define PHY_LED1_ACT (0x8<<4) -#define PHY_LED2_INT (0xe<<8) -#define PHY_SPEC_CTRL 0x1c +#define PHY_LED_SEL_REG 0x18 +#define PHY_LED0_LINK (0x5) +#define PHY_LED1_ACT (0x8<<4) +#define PHY_LED2_INT (0xe<<8) +#define PHY_SPEC_CTRL_REG 0x1c#define PHY_RGMII_CLK_STABLE (0x1<<10) -#define PHY_CLSA (0x1<<1) +#define PHY_CLSA (0x1<<1)/* Configure and enable MV88E3018 PHY */ void reset_phy (void )
@@ -383,15 +383,15 @@ void reset_phy(void)return ;/* RGMII clk transition on data stable */ -if (miiphy_read (name,CONFIG_PHY_BASE_ADR ,PHY_SPEC_CTRL , ®) !=0 ) +if (!miiphy_read (name,CONFIG_PHY_BASE_ADR ,PHY_SPEC_CTRL_REG , ®))printf ("Error reading PHY spec ctrl reg\n" ); -if (miiphy_write (name,CONFIG_PHY_BASE_ADR ,PHY_SPEC_CTRL , - reg |PHY_RGMII_CLK_STABLE |PHY_CLSA ) !=0 ) +if (!miiphy_write (name,CONFIG_PHY_BASE_ADR ,PHY_SPEC_CTRL_REG , + reg |PHY_RGMII_CLK_STABLE |PHY_CLSA ))printf ("Error writing PHY spec ctrl reg\n" );/* leds setup */ -if (miiphy_write (name,CONFIG_PHY_BASE_ADR ,PHY_LED_SEL , -PHY_LED0_LINK |PHY_LED1_ACT |PHY_LED2_INT ) !=0 ) +if (!miiphy_write (name,CONFIG_PHY_BASE_ADR ,PHY_LED_SEL_REG , +PHY_LED0_LINK |PHY_LED1_ACT |PHY_LED2_INT ))printf ("Error writing PHY LED reg\n" );/* reset the phy */
Signature · 1 line
1.7.1
PATCH 12/20 arm/km: add support for external switch configuration
In reply to Valentin LongchampThis can be used if we do not want to use an EEPROM for the configuration.
--- board/keymile/common/common.h | 7 -- board/keymile/km_arm/managed_switch.c | 169 +++++++++++++++++++++++++++++++-- board/keymile/km_arm/managed_switch.h | 99 +++++++++++++++++++ 3 files changed, 258 insertions(+), 17 deletions(-) create mode 100644 board/keymile/km_arm/managed_switch.h
board/keymile/common/common.h +0 -7
@@ -125,13 +125,6 @@ struct bfticu_iomap {int ethernet_present (void );int ivm_read_eeprom (void ); - -int ext_switch_reg_write (const char *devname,u8 phy_addr,u8 port, -u8 reg,u16 data); -int ext_switch_reg_read (const char *devname,u8 phy_addr,u8 port, -u8 reg,u16 *data); - -int trigger_fpga_config (void );int wait_for_fpga_config (void );int fpga_reset (void );
board/keymile/km_arm/managed_switch.c +159 -10
194 lines not on this page · raw message
board/keymile/km_arm/managed_switch.h new file +99 -0
99 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 12/20 arm/km: add support for external switch configuration
Quoted 15 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of Valentin Longchamp
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external switch configurationThis can be used if we do not want to use an EEPROM for the configuration.
Quoted 6 lines
Signed-off-by Valentin Longchamp <[email protected]>--- board/keymile/common/common.h | 7 -- board/keymile/km_arm/managed_switch.c | 169 +++++++++++++++++++++++++++++++-- board/keymile/km_arm/managed_switch.h | 99 +++++++++++++++++++
What is managed switch? Which chip it supports? Why it is sitting here and not in generic folder?
Regards..
Prafulla . . .
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi Prafulla,
Quoted 15 lines · Prafulla Wadaskar
Quoted 15 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of Valentin Longchamp
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external switch configurationThis can be used if we do not want to use an EEPROM for the configuration.
Quoted 9 lines
Quoted 6 lines
Signed-off-by Valentin Longchamp <[email protected]>--- board/keymile/common/common.h | 7 -- board/keymile/km_arm/managed_switch.c | 169 +++++++++++++++++++++++++++++++-- board/keymile/km_arm/managed_switch.h | 99 +++++++++++++++++++What is managed switch? Which chip it supports? Why it is sitting here and not in generic folder?
In this case, the switch is a Marvell 88E52xxx (don't remember the exact model) that is connected to the GE port of the Kirkwood and that gets configured by the Kirkwood through a MDIO link, using indirect addressing.
We do not have the pretention to write a generic driver for such switches/addressing, but we need this functionnality on some boards, that's why we have kept it in our own folder and not in a generic driver folder.
I will add the above precisions to the commit message for an optional v3 of the "updates for the Keymile Marvell boards" series so that this is more clear.
Valentin
PATCH 12/20 arm/km: add support for external switchconfiguration
Quoted 51 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 21 June 2012 18:40
To: Prafulla Wadaskar
Cc: prafulla at mavell.com; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfigurationHi Prafulla,
Quoted 15 lines · Prafulla Wadaskar
Quoted 15 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of Valentin Longchamp
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external switch configurationThis can be used if we do not want to use an EEPROM for the configuration.
Quoted 8 lines
Quoted 6 lines
Signed-off-by Valentin Longchamp <[email protected]>--- board/keymile/common/common.h | 7 -- board/keymile/km_arm/managed_switch.c | 169 +++++++++++++++++++++++++++++++-- board/keymile/km_arm/managed_switch.h | 99 +++++++++++++++++++What is managed switch? Which chip it supports? Why it is sitting
here and not in generic folder?
Quoted 1 line
In this case, the switch is a Marvell 88E52xxx (don't remember the exact model)
that is connected to the GE port of the Kirkwood and that gets configured by the
Kirkwood through a MDIO link, using indirect addressing.We do not have the pretention to write a generic driver for such switches/addressing, but we need this functionnality on some boards, that's why
we have kept it in our own folder and not in a generic driver folder.
Quoted 4 lines
I will add the above precisions to the commit message for an optional v3 of the
"updates for the Keymile Marvell boards" series so that this is more clear.
Dear Valentin
We must keep develop it as generic driver.
Regards...
Prafulla . . .
PATCH 12/20 arm/km: add support for external switchconfiguration
Hello Prafulla,
Quoted 54 lines · Prafulla Wadaskar
Quoted 49 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 21 June 2012 18:40
To: Prafulla Wadaskar
Cc: prafulla at mavell.com; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfigurationHi Prafulla,
Quoted 15 lines · Prafulla Wadaskar
Quoted 15 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of Valentin Longchamp
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de
Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external switch configurationThis can be used if we do not want to use an EEPROM for the configuration.
Quoted 8 lines
Quoted 6 lines
Signed-off-by Valentin Longchamp <[email protected]>--- board/keymile/common/common.h | 7 -- board/keymile/km_arm/managed_switch.c | 169 +++++++++++++++++++++++++++++++-- board/keymile/km_arm/managed_switch.h | 99 +++++++++++++++++++What is managed switch? Which chip it supports? Why it is sitting
here and not in generic folder?
Quoted 1 line
In this case, the switch is a Marvell 88E52xxx (don't remember the exact model)
that is connected to the GE port of the Kirkwood and that gets configured by the
Kirkwood through a MDIO link, using indirect addressing.We do not have the pretention to write a generic driver for such switches/addressing, but we need this functionnality on some boards, that's why
we have kept it in our own folder and not in a generic driver folder.Quoted 4 lines
I will add the above precisions to the commit message for an optional v3 of the
"updates for the Keymile Marvell boards" series so that this is more clear.
Quoted 6 lines
Dear Valentin
We must keep develop it as generic driver.Regards...
Prafulla . . .
Sure it would be great if we had the time and resources to contribute a generic driver for these switches. Unfortunately it is not the case and we have only developed a simple driver with limited features that suits our current needs.
Since we know it's very limited, we have intentionally chosen to put in in our board/keymile directory so that it's obvious that it is (currently) not intended to be used nor was it tested on other boards or with other switches.
The question now is: does u-boot allow some boards (or family of boards) to integrate some board codes or drivers ? It was until now our understanding that u-boot allows this. This code definitely fits into this category.
As for the generic driver, if someone contributes one (the current driver can be used as a basis), we will be very happy to drop this code and use the generic driver.
Valentin
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi Valentin and Prafulla,
[...]
Quoted 7 lines
Quoted 6 lines
Dear Valentin
We must keep develop it as generic driver.Regards...
Prafulla . . .
Quoted 7 lines
Sure it would be great if we had the time and resources to contribute a generic driver for these switches. Unfortunately it is not the case and we have only developed a simple driver with limited features that suits our current needs.
Since we know it's very limited, we have intentionally chosen to put in in our board/keymile directory so that it's obvious that it is (currently) not intended to be used nor was it tested on other boards or with other switches.
Personally I welcome such a driver submission to mainline as it can be a starting point for someone else later.
Quoted 3 lines
The question now is: does u-boot allow some boards (or family of boards) to integrate some board codes or drivers ? It was until now our understanding that u-boot allows this. This code definitely fits into this category.
This is also my understanding and actually our source code has lots of them and many people are thankful to find such code (if they are able to find it ;)
Quoted 3 lines
As for the generic driver, if someone contributes one (the current driver can be used as a basis), we will be very happy to drop this code and use the generic driver.
Actually I would go even further and say that a generic driver can only be started when there are at least two or more users of the code. One should probably think about not making too many short-sighted assumptions when working on a driver but to think that one could develop a generic driver from one device only would be foolish.
So Prafulla, can you please reconsider to add the driver?
Thanks
Detlev
Signature · 7 lines
Provide mechanism rather than policy. In particular, place user
interface policy in the clients' hands.
-- principles of X Window System
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH 12/20 arm/km: add support for external switchconfiguration
Quoted 63 lines
-----Original Message-----
From: Detlev Zundel [mailto:dzu at denx.de]
Sent: 04 July 2012 13:38
To: Valentin Longchamp
Cc: Prafulla Wadaskar; u-boot at lists.denx.de; holger.brunck at keymile.com
Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfigurationHi Valentin and Prafulla,
[...]
Quoted 8 lines
Quoted 6 lines
Dear Valentin
We must keep develop it as generic driver.Regards...
Prafulla . . .Sure it would be great if we had the time and resources to
contribute a generic
Quoted 1 line
driver for these switches. Unfortunately it is not the case and we
have only
Quoted 1 line
developed a simple driver with limited features that suits our
current needs.
Quoted 2 lines
Since we know it's very limited, we have intentionally chosen to put
in in our
Quoted 1 line
board/keymile directory so that it's obvious that it is (currently)
not intended
Quoted 1 line
to be used nor was it tested on other boards or with other switches.
Personally I welcome such a driver submission to mainline as it can be a
starting point for someone else later.Quoted 1 line
The question now is: does u-boot allow some boards (or family of
boards) to
Quoted 1 line
integrate some board codes or drivers ? It was until now our
understanding that
Quoted 1 line
u-boot allows this. This code definitely fits into this category.
This is also my understanding and actually our source code has lots of them and many people are thankful to find such code (if they are able to
find it ;)Quoted 1 line
As for the generic driver, if someone contributes one (the current
driver can be
Quoted 1 line
used as a basis), we will be very happy to drop this code and use
the generic
Quoted 1 line
driver.
Actually I would go even further and say that a generic driver can only
be started when there are at least two or more users of the code. One should probably think about not making too many short-sighted assumptions when working on a driver but to think that one could develop
a generic driver from one device only would be foolish.
Quoted 1 line
So Prafulla, can you please reconsider to add the driver?
Hi Detlev
Clear NAK for this patch
Let's put it in drivers/net/phy/
FYI: there are several drivers used by just one board,
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS" include/configs/*
include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS 1
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM" include/configs/*
include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1
Anyways peripheral driver should go in drivers/
Regards...
Prafulla . . .
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi,
Quoted 56 lines · Prafulla Wadaskar
Quoted 42 lines
Quoted 1 line
Sure it would be great if we had the time and resources to
contribute a generic
Quoted 1 line
driver for these switches. Unfortunately it is not the case and we
have only
Quoted 1 line
developed a simple driver with limited features that suits our
current needs.
Quoted 2 lines
Since we know it's very limited, we have intentionally chosen to put
in in our
Quoted 1 line
board/keymile directory so that it's obvious that it is (currently)
not intended
Quoted 1 line
to be used nor was it tested on other boards or with other switches.
Personally I welcome such a driver submission to mainline as it can be a
starting point for someone else later.Quoted 1 line
The question now is: does u-boot allow some boards (or family of
boards) to
Quoted 1 line
integrate some board codes or drivers ? It was until now our
understanding that
Quoted 1 line
u-boot allows this. This code definitely fits into this category.
This is also my understanding and actually our source code has lots of them and many people are thankful to find such code (if they are able to
find it ;)Quoted 1 line
As for the generic driver, if someone contributes one (the current
driver can be
Quoted 1 line
used as a basis), we will be very happy to drop this code and use
the generic
Quoted 1 line
driver.
Actually I would go even further and say that a generic driver can only
be started when there are at least two or more users of the code. One should probably think about not making too many short-sighted assumptions when working on a driver but to think that one could develop
a generic driver from one device only would be foolish.Quoted 1 line
So Prafulla, can you please reconsider to add the driver?
Hi Detlev
Clear NAK for this patchLet's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board,
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS"include/configs/*
include/configs/microblaze-generic.h:346:# defineCONFIG_PHY_ATHEROS1
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM"include/configs/*
include/configs/microblaze-generic.h:347:# defineCONFIG_PHY_BROADCOM1
Quoted 2 lines
Anyways peripheral driver should go in
drivers/
yes there are maybe drivers which proof your concept, but there are many others in the board related code which do the opposite.
But I think this topic should be discussed not in the context of this patch. It's a general question. I 100% agree with Detlev's explanation. If a new very limited HW driver is added to the repo I see good reasons to keep it in the folder for the board. If a second user comes up and wants to enhance the driver for his needs he can still move driver then. But if no other user for this driver is there and maybe in the future the board needs to be removed because it's broken it's much easier to remove _all_ related code when it's located in one directory. If the code is spread over several directories it's much harder to track.
Regards
Holger
PATCH 12/20 arm/km: add support for external switchconfiguration
Dear Holger,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
Anyways peripheral driver should go in
drivers/yes there are maybe drivers which proof your concept, but there are many others in the board related code which do the opposite.
Yes, but bad examples are not a good reason to repeat mistakes either.
Quoted 9 lines
But I think this topic should be discussed not in the context of this patch. It's a general question. I 100% agree with Detlev's explanation. If a new very limited HW driver is added to the repo I see good reasons to keep it in the folder for the board. If a second user comes up and wants to enhance the driver for his needs he can still move driver then. But if no other user for this driver is there and maybe in the future the board needs to be removed because it's broken it's much easier to remove _all_ related code when it's located in one directory. If the code is spread over several directories it's much harder to track.
Sorry, but I disagree. How many board directories are there in U-Boot? Several hundreds... How many board directories did you check to make sure none of them contains any driver that is similar to what you implement here?
If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy.
I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions.
To make sure everybody sees such code, we should really add it to the standard locations.
Thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The best things in life are for a fee.
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi Wolfgang,
[...]
Quoted 9 lines
Sorry, but I disagree. How many board directories are there in U-Boot? Several hundreds... How many board directories did you check to make sure none of them contains any driver that is similar to what you implement here?
If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy.
Quoted 6 lines
I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions.
To make sure everybody sees such code, we should really add it to the standard locations.
According to the current situation, we have the choice of getting good code into a board directory or no code at all because Prafulla doesn't accept the code in its current incarnation into a general place. I don't need a crystal ball to see that the project will loose code this way. I'm sorry that the project rejects working code and I re-ask Prafulla to reconsider his NAK which has impact on the whole project.
Cheers
Detlev
Signature · 6 lines
debian is a prototype for a future version of emacs.
-- Thien-Thi Nguyen in <[email protected]>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH 12/20 arm/km: add support for external switchconfiguration
Dear Detlev,
Quoted 2 lines · In message <[email protected]> you wrote:
Quoted 2 lines
I agree that even very simple and uncomplete implementations can co in
should read: ...can go in...
Quoted 9 lines
Quoted 5 lines
if the fulfil some purpose, and can form a basis for future extensions.
To make sure everybody sees such code, we should really add it to the standard locations.
According to the current situation, we have the choice of getting good code into a board directory or no code at all because Prafulla doesn't accept the code in its current incarnation into a general place. I
I just tried to explain that my wish is that 1) this code can go in, even if not perfectly universal yet, and 2) that it should go into the standard location for such drivers.
Quoted 3 lines
don't need a crystal ball to see that the project will loose code this way. I'm sorry that the project rejects working code and I re-ask Prafulla to reconsider his NAK which has impact on the whole project.
I don't see why you are taking about rejecting code here. Didn't I make clear that I vote for adding this code?
I hope Prafulla finds this recommendation acceptable (especially after I added him to Cc: so he actually gets aware of this discussion).
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer
PATCH 12/20 arm/km: add support for external switchconfiguration
In reply to Wolfgang DenkHi Wolfgang,
[...]
Quoted 7 lines
If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy.
I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions.
I just read through our documentation on the Wiki and found nothing relavant to such a topic. If we make this a requirement, we should add it so people know about it beforehand.
How about amending the U-Boot design principles with
11. Keep It Generic
- Generic code shall be added as high as possible to the U-Boot abstraction hierarchy and only as a last resort into board directories. This entails that peripheral drivers should be put below "drivers" even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point.
How does that sound?
Cheers
Detlev
Signature · 7 lines
The only thing worse than generalizing from one example is generalizing
from no examples at all.
-- principles of X Window System
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH 12/20 arm/km: add support for external switchconfiguration
Hi Detlev,
Quoted 24 lines · Detlev Zundel
Quoted 7 lines
If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy.
I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions.
I just read through our documentation on the Wiki and found nothing relavant to such a topic. If we make this a requirement, we should add it so people know about it beforehand.
How about amending the U-Boot design principles with
11. Keep It Generic
- Generic code shall be added as high as possible to the U-Boot abstraction hierarchy and only as a last resort into board directories. This entails that peripheral drivers should be put below "drivers" even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point.
Quoted 2 lines
How does that sound?
shouldn't be there an exception for strictly board specific peripheral drivers like an custom-made FPGA?
Regards
Holger
PATCH 12/20 arm/km: add support for external switchconfiguration
Dear Holger,
Quoted 3 lines · In message <[email protected]> you wrote:
shouldn't be there an exception for strictly board specific peripheral drivers like an custom-made FPGA?
I see two situations:
1) We are talking about code to load a bitstream into the FPGA, i. e. to "program it". Such code should always be generic enough to put it under drivers/fpga/ (if the existing code there does not already cover the task).
2) We are talking about driver code for some preipheral implemented in the FPGA. In many cases we find these peripherals to be pretty generic (say, UARTs, GPIOs, network interfaces, etc.). In such cases there is no doubt that driver code should go to drivers/ . ONly in case you have areally, really special feature implemented that you need supported in U-Boot. OK, then such drivers are probably better kept in your board directory.
Note that there will always be cases where hindsight will show that the initial location was not perfect. That is perfectly normal ;-)
Best regards,
Wolfgang Denk
Signature · 9 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de 'What shall we do?' said Twoflower. 'Panic?' said Rincewind hope- fully. He always held that panic was the best means of survival; back in the olden days, his theory went, people faced with hungry sabre- toothed tigers could be divided very simply in those who panicked and those who stood there saying 'What a magnificent brute!' or 'Here, pussy.' - Terry Pratchett, _The Light Fantastic_
PATCH 12/20 arm/km: add support for external switchconfiguration
In reply to Detlev ZundelDear Detlev,
Quoted 4 lines · In message <[email protected]> you wrote:
I just read through our documentation on the Wiki and found nothing relavant to such a topic. If we make this a requirement, we should add it so people know about it beforehand.
You know all too well that our wiki suffers from a mismatch of what people expect to it and what htey contribute to it.
Quoted 1 line
How about amending the U-Boot design principles with
Go for it - it's a wiki.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de You don't have to stay up nights to succeed; you have to stay awake days.
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi,
Quoted 3 lines
Quoted 1 line
How about amending the U-Boot design principles with
Go for it - it's a wiki.
Thinking about it, I turned it not into a rule, but into a Lemma from the 10 rules:
Lemmas from the golden rules
1. Generic Code is Good Code
New code shall be as generic as possible and added to the U-Boot abstraction hierarchy as high as possible. As few code as possible shall be added in board directories as people usually do not expect re-usable code there. Thus peripheral drivers should be put below "drivers" even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point.
Feel free to amend / modify that.
Cheers
Detlev
[1] http://www.denx.de/wiki/rdiff/U-Boot/DesignPrinciples?rev1=1.14&rev2=1.13
PS: Ok, actually I didn't want to ruin the magic 10 ;)
Signature · 6 lines
Question : If you were redesigning UNIX, what would you do differently? Ken Thompson: I'd spell creat with an e. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
PATCH 12/20 arm/km: add support for external switchconfiguration
In reply to Holger BrunckQuoted 10 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 09 July 2012 17:34
To: Prafulla Wadaskar
Cc: Detlev Zundel; Valentin Longchamp; u-boot at lists.denx.de
Subject: Re: [PATCH 12/20] arm/km: add support for external switchconfiguration
...snip...
Quoted 35 lines
Quoted 7 lines
Hi Detlev
Clear NAK for this patchLet's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board, [prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/MakefileQuoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"
CONFIG_PHY_ATHEROS"include/configs/*Quoted 1 line
include/configs/microblaze-generic.h:346:# define
CONFIG_PHY_ATHEROS1
Quoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/MakefileQuoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"
CONFIG_PHY_BROADCOM"include/configs/*Quoted 1 line
include/configs/microblaze-generic.h:347:# define
CONFIG_PHY_BROADCOM1Quoted 3 lines
Anyways peripheral driver should go in
drivers/yes there are maybe drivers which proof your concept, but there are many others
in the board related code which do the opposite.But I think this topic should be discussed not in the context of this patch.
It's a general question. I 100% agree with Detlev's explanation. If a new very
limited HW driver is added to the repo I see good reasons to keep it in the
folder for the board. If a second user comes up and wants to enhance the driver
for his needs he can still move driver then. But if no other user for
Quoted 8 lines
this
driver is there and maybe in the future the board needs to be removed because
it's broken it's much easier to remove _all_ related code when it's located in
one directory. If the code is spread over several directories it's much harder
to track.
Dear Holger,
The peripheral (switch/PHY) is being considered to be supported as a driver is interfaced through standard interface and can be used by any other CPU/architecture/SoC on any other board.
So I think there is no reason to keep it in board specific folder. Someone may correct me if I am wrong.
Copying Joe (net custodian)
Regards...
Prafulla . . .
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi Prafulla,
Quoted 55 lines · Prafulla Wadaskar
Quoted 10 lines
-----Original Message-----
From: Holger Brunck [mailto:holger.brunck at keymile.com]
Sent: 09 July 2012 17:34
To: Prafulla Wadaskar
Cc: Detlev Zundel; Valentin Longchamp; u-boot at lists.denx.de
Subject: Re: [PATCH 12/20] arm/km: add support for external switchconfiguration...snip...
Quoted 35 lines
Quoted 7 lines
Hi Detlev
Clear NAK for this patchLet's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board, [prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/MakefileQuoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"
CONFIG_PHY_ATHEROS"include/configs/*Quoted 1 line
include/configs/microblaze-generic.h:346:# define
CONFIG_PHY_ATHEROS1
Quoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/MakefileQuoted 1 line
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn
"
CONFIG_PHY_BROADCOM"include/configs/*Quoted 1 line
include/configs/microblaze-generic.h:347:# define
CONFIG_PHY_BROADCOM1Quoted 3 lines
Anyways peripheral driver should go in
drivers/yes there are maybe drivers which proof your concept, but there are many others
in the board related code which do the opposite.But I think this topic should be discussed not in the context of this patch.
It's a general question. I 100% agree with Detlev's explanation. If a new very
limited HW driver is added to the repo I see good reasons to keep it in the
folder for the board. If a second user comes up and wants to enhance the driver
for his needs he can still move driver then. But if no other user forQuoted 8 lines
this
driver is there and maybe in the future the board needs to be removed because
it's broken it's much easier to remove _all_ related code when it's located in
one directory. If the code is spread over several directories it's much harder
to track.
Quoted 5 lines
Dear Holger,
The peripheral (switch/PHY) is being considered to be supported as a driver is interfaced through standard interface and can be used by any other CPU/architecture/SoC on any other board.So I think there is no reason to keep it in board specific folder. Someone may correct me if I am wrong.
I agree. It belongs in drivers/net/phy/.
Thanks,
-Joe
PATCH 12/20 arm/km: add support for external switchconfiguration
In reply to Prafulla WadaskarHi Prafulla,
[...]
Quoted 2 lines
Hi Detlev
Clear NAK for this patch
Do you mean clear NAK for "the patch" or "for the location of the files"?
Quoted 13 lines
Let's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board, [prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS"include/configs/*
include/configs/microblaze-generic.h:346:# defineCONFIG_PHY_ATHEROS1
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM"include/configs/*
include/configs/microblaze-generic.h:347:# defineCONFIG_PHY_BROADCOM1
Quoted 1 line
Anyways peripheral driver should go in
drivers/
Ok, so if the files are moved to drivers/net/phy, then you will ACK the patch? If this is the case, then Valentin please move the files and be done with it.
Cheers
Detlev
Signature · 9 lines
... that every year or so they're going to give you a new release full of 50 000 additional lines of code all written by monkeys. Because they generally follow the ``million monkeys typing, and eventually they'll come up with something useful'' school of system development. -- Richard M. Stallman -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
PATCH 12/20 arm/km: add support for external switchconfiguration
Hi Detlev,
Quoted 23 lines · Detlev Zundel
Hi Prafulla,
[...]
Quoted 2 lines
Hi Detlev
Clear NAK for this patchDo you mean clear NAK for "the patch" or "for the location of the files"?
Quoted 13 lines
Let's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board, [prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS"include/configs/*
include/configs/microblaze-generic.h:346:# defineCONFIG_PHY_ATHEROS1
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM"include/configs/*
include/configs/microblaze-generic.h:347:# defineCONFIG_PHY_BROADCOM1
Quoted 6 lines
Quoted 1 line
Anyways peripheral driver should go in
drivers/Ok, so if the files are moved to
drivers/net/phy, then you will ACK the patch? If this is the case, then Valentin please move the files and be done with it.
Already working on it ;)
Valentin
PATCH 12/20 arm/km: add support for external switchconfiguration
In reply to Detlev ZundelQuoted 13 lines
-----Original Message-----
From: Detlev Zundel [mailto:dzu at denx.de]
Sent: 09 July 2012 20:02
To: Prafulla Wadaskar
Cc: Valentin Longchamp; u-boot at lists.denx.de; holger.brunck at keymile.com
Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfigurationHi Prafulla,
Quoted 7 lines
[...]
Quoted 2 lines
Hi Detlev
Clear NAK for this patchDo you mean clear NAK for "the patch" or "for the location of the files"?
Dear Detlev
Location, I have not gone through the rest of the patch.
Quoted 16 lines
Quoted 8 lines
Let's put it in
drivers/net/phy/
FYI: there are several drivers used by just one board, [prafulla at pe-dt061 u-boot-marvell.git (master)]$ vimdrivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_ATHEROS"include/configs/*include/configs/microblaze-generic.h:346:# defineCONFIG_PHY_ATHEROS1
Quoted 5 lines
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ vim
drivers/net/phy/Makefile
[prafulla at pe-dt061 u-boot-marvell.git (master)]$ grep -Irn "CONFIG_PHY_BROADCOM"include/configs/*include/configs/microblaze-generic.h:347:# define
CONFIG_PHY_BROADCOM1Quoted 1 line
Quoted 7 lines
Quoted 1 line
Anyways peripheral driver should go in
drivers/Ok, so if the files are moved to
drivers/net/phy, then you will ACK the
patch? If this is the case, then Valentin please move the files and be
done with it.
Thanks...
Regards...
Prafulla . . .
PATCH 13/20 arm/km: enable external switch configuration for kmnusa
In reply to Valentin LongchampThe configuration EEPROM should be removed for P1B.
--- board/keymile/km_arm/km_arm.c | 11 +++++------ board/keymile/km_arm/managed_switch.c | 3 ++- board/keymile/km_arm/managed_switch.h | 7 +++++++ 3 files changed, 14 insertions(+), 7 deletions(-)
board/keymile/km_arm/km_arm.c +5 -6
@@ -43,6 +43,7 @@#include <asm/arch/mpp.h> #include "../common/common.h" +#include "managed_switch.h" DECLARE_GLOBAL_DATA_PTR ;
@@ -407,13 +408,11 @@ void reset_phy(void)if (miiphy_set_current_dev (name))return ; -/* enable autoneg on port 0 phy */ -ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,0 ,0 ,0x3300 ); +#if defined(CONFIG_KM_NUSA ) +ext_switch_program (name,CONFIG_KM_MANAGED_SW_ADDR ); +#endif -/* egress broadcast franes on all macs, with forwarding */ -ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,16 ,4 ,0x000f ); -ext_switch_reg_write (name,CONFIG_KM_MANAGED_SW_ADDR ,20 ,4 ,0x000f ); - ext_switch_reg_write(name, CONFIG_KM_MANAGED_SW_ADDR, 21, 4, 0x000f); + ext_switch_reset(name, CONFIG_KM_MANAGED_SW_ADDR); }#endif
board/keymile/km_arm/managed_switch.c +2 -1
@@ -32,9 +32,10 @@ struct switch_reg sw_conf[] = {/* port 0, PIGY4, autoneg */ { PORT(0), PORT_PHY, NO_SPEED_FOR }, { PORT(0), PORT_CTRL, FORWARDING | EGRS_FLD_ALL }, + { PHY(0), PHY_1000_CTRL, NO_ADV }, + { PHY(0), PHY_SPEC_CTRL, AUTO_MDIX_EN }, { PHY(0), PHY_CTRL, PHY_100_MBPS | AUTONEG_EN | AUTONEG_RST | FULL_DUPLEX }, - { PHY(0), PHY_SPEC_CTRL, AUTO_MDIX_EN },/* port 1, unused */ { PORT(1), PORT_CTRL, PORT_DIS }, { PHY(1), PHY_CTRL, PHY_PWR_DOWN },
board/keymile/km_arm/managed_switch.h +7 -0
@@ -51,6 +51,7 @@#define PHY_CTRL 0x00#define PHY_100_MBPS 0x2000 +#define PHY_1_GBPS 0x0040#define AUTONEG_EN 0x1000#define AUTONEG_RST 0x0200#define FULL_DUPLEX 0x0100
@@ -62,6 +63,12 @@#define SPEC_PWR_DOWN 0x0004#define AUTO_MDIX_EN 0x0060 +#define PHY_1000_CTRL 0x9 + +#define NO_ADV 0x0000 +#define ADV_1000_FDPX 0x0200 +#define ADV_1000_HDPX 0x0100 +/* PORT or MAC registers */ #define PORT (itf) (itf+0x10)
Signature · 1 line
1.7.1
PATCH 14/20 arm/km: skip FPGA config when already configured
In reply to Valentin LongchampIn order to be able to perform board resets without interrupting the traffic, the configuration of an already properly configured FPGA is skipped.
This is because some PCIe FPGAs embed some other function that must continue to work over reset.
It is then the responsibility of the application to trigger a reconfiguration when needed. This is done by lowering the FPGA_INIT_B pin for delaying the configuration to u-boot @ next reboot, and then lower the FPGA_PROGRAM_B signal.
--- board/keymile/km_arm/fpga_config.c | 41 +++++++++++++++++++++++++++++++++++- 1 files changed, 40 insertions(+), 1 deletions(-)
board/keymile/km_arm/fpga_config.c +40 -1
@@ -96,12 +96,43 @@ static int boco_set_bits(u8 reg, u8 flags)#define SPI_REG 0x06#define CFG_EEPROM 0x02#define FPGA_PROG 0x04 +#define FPGA_INIT_B 0x10#define FPGA_DONE 0x20 +static int fpga_done () +{ +int ret =0 ; +u8 regval; + +/* this is only supported with the boco2 design */ +if (!check_boco2 ()) +return 0 ; + + ret =i2c_read (BOCO_ADDR ,SPI_REG ,1 , ®val,1 ); +if (ret) { +printf ("%s: error reading the BOCO @%#x !!\n" , + __func__,SPI_REG ); +return 0 ; + } + +return regval &FPGA_DONE ?1 :0 ; +} + +int skip; +int trigger_fpga_config (void ) {int ret =0 ; +/* if the FPGA is already configured, we do not want to +* reconfigure it */ + skip =0 ; +if (fpga_done ()) { +printf ("PCIe FPGA config: skipped\n" ); + skip =1 ; +return 0 ; + } +if (check_boco2 ()) {/* we have a BOCO2, this has to be triggered here */
@@ -111,7 +142,7 @@ int trigger_fpga_config(void)return ret;/* trigger the config start */ - ret =boco_clear_bits (SPI_REG ,FPGA_PROG ); + ret =boco_clear_bits (SPI_REG ,FPGA_PROG |FPGA_INIT_B );if (ret)return ret;
@@ -123,6 +154,11 @@ int trigger_fpga_config(void)if (ret)return ret; +/* finally, raise INIT_B to remove the config delay */ + ret =boco_set_bits (SPI_REG ,FPGA_INIT_B ); +if (ret) +return ret; + }else {/* we do it the old way, with the gpio pin */ kw_gpio_set_valid (KM_XLX_PROGRAM_B_PIN ,1 );
@@ -141,6 +177,9 @@ int wait_for_fpga_config(void)u8 spictrl;u32 timeout =20000 ; +if (skip) +return 0 ; +if (!check_boco2 ()) {/* we do not have BOCO2, this is not really used */ return 0 ;
Signature · 1 line
1.7.1
PATCH 15/20 arm/km: support the 2 PCIe fpga resets
In reply to Valentin LongchampThe PCIe FPGAs now have to support 2 resets: one for the non traffic affecting part (PCIe) and one for the traffic affecting part.
When the FPGA is not reconfigured, we only reset the PCIe part.
--- board/keymile/km_arm/fpga_config.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-)
board/keymile/km_arm/fpga_config.c +9 -4
@@ -99,7 +99,7 @@ static int boco_set_bits(u8 reg, u8 flags)#define FPGA_INIT_B 0x10#define FPGA_DONE 0x20 -static int fpga_done () +static int fpga_done (void ) {int ret =0 ;u8 regval;
@@ -206,25 +206,30 @@ int wait_for_fpga_config(void) }#define PRST1 0x4 -#define BRIDGE_RST 0x4 +#define PCIE_RST 0x10 +#define TRAFFIC_RST 0x04int fpga_reset (void ) {int ret =0 ; +u8 resets;if (!check_boco2 ()) {/* we do not have BOCO2, this is not really used */ return 0 ; } - ret =boco_clear_bits (PRST1 ,BRIDGE_RST ); +/* if we have skipped, we only want to reset the PCIe part */ + resets = skip ?PCIE_RST :PCIE_RST |TRAFFIC_RST ; + + ret =boco_clear_bits (PRST1 , resets);if (ret)return ret;/* small delay for the pulse */ udelay (10 ); - ret =boco_set_bits (PRST1 ,BRIDGE_RST ); + ret =boco_set_bits (PRST1 , resets);if (ret)return ret;
Signature · 1 line
1.7.1
PATCH 16/20 arm/km: add implementation for read_dip_switch
In reply to Valentin LongchampFrom: Thomas Herzmann <[email protected]>
Add a function to read the dip_switch on kmcoge5un. If the switch is set the actual_bank is set to 0 and this SW is booted.
--- board/keymile/km_arm/km_arm.c | 14 +++++++++++++- include/configs/km_kirkwood.h | 3 --- 2 files changed, 13 insertions(+), 4 deletions(-)
board/keymile/km_arm/km_arm.c +13 -1
@@ -286,12 +286,24 @@ int board_init(void)int board_late_init (void ) { +#if defined(CONFIG_KMCOGE5UN ) +/* I/O pin to erase flash RGPP09 = MPP43 */ +#define KM_FLASH_ERASE_ENABLE 43 +u8 dip_switch =kw_gpio_get_value (KM_FLASH_ERASE_ENABLE ); + +/* if pin 1 do full erase */ +if (dip_switch !=0 ) { +/* start bootloader */ +puts ("DIP: Enabled\n" ); +setenv ("actual_bank" ,"0" ); + } +#endif +#if defined(CONFIG_KM_FPGA_CONFIG )wait_for_fpga_config ();fpga_reset ();toggle_eeprom_spi_bus ();#endif -return 0 ; }
include/configs/km_kirkwood.h +0 -3
@@ -184,8 +184,5 @@#undef CONFIG_KIRKWOOD_PCIE_INIT#endif -#ifndef CONFIG_KM_FPGA_CONFIG -#undef BOARD_LATE_INIT -#endif #endif /* _CONFIG_KM_KIRKWOOD */
Signature · 1 line
1.7.1
PATCH 17/20 arm/km: fix testpin detection for kmcoge5un
In reply to Valentin LongchampFrom: Thomas Herzmann <[email protected]>
On kmcoge5un unfortunately the HW wiring is differently to other km arm boards.
--- board/keymile/km_arm/km_arm.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
board/keymile/km_arm/km_arm.c +4 -0
@@ -533,7 +533,11 @@ int get_scl(void)int post_hotkeys_pressed (void ) { +#if defined(CONFIG_KMCOGE5UN ) +return kw_gpio_get_value (KM_POST_EN_L ); +#else return !kw_gpio_get_value (KM_POST_EN_L ); +#endif }ulong post_word_load (void )
Signature · 1 line
1.7.1
PATCH 18/20 arm/km: implement weak function board_spi_clam_bus/release
In reply to Valentin LongchampThey are needed on all km_arm boards where we have the environement variables in the NOR Flash. First boards using this feature are kmcoge5un and kmnusa.
--- board/keymile/km_arm/km_arm.c | 26 ++++++++------------------ 1 files changed, 8 insertions(+), 18 deletions(-)
board/keymile/km_arm/km_arm.c +8 -18
@@ -36,6 +36,7 @@#include <nand.h> #include <netdev.h> #include <miiphy.h> +#include <spi.h> #include <asm/io.h> #include <asm/arch/cpu.h> #include <asm/errno.h>
@@ -307,29 +308,18 @@ int board_late_init(void)return 0 ; } -int km_hw_spi_bus_claim (int on) +int board_spi_claim_bus (struct spi_slave *slave) { -int gpio_value = !on; - -if (on) { - kwmpp_config[0 ] = MPP0_SPI_SCn; - kwmpp_config[1 ] =MPP1_SPI_MOSI ; - kwmpp_config[2 ] =MPP2_SPI_SCK ; - kwmpp_config[3 ] =MPP3_SPI_MISO ; - }else { - kwmpp_config[0 ] =MPP0_NF_IO2 ; - kwmpp_config[1 ] =MPP1_NF_IO3 ; - kwmpp_config[2 ] =MPP2_NF_IO4 ; - kwmpp_config[3 ] =MPP3_NF_IO5 ; - } - -/* Multi-Purpose Pins Functionality configuration */ -kirkwood_mpp_conf (kwmpp_config,NULL ); -kw_gpio_set_value (KM_FLASH_GPIO_PIN , gpio_value); +kw_gpio_set_value (KM_FLASH_GPIO_PIN ,0 );return 0 ; } +void board_spi_release_bus (struct spi_slave *slave) +{ +kw_gpio_set_value (KM_FLASH_GPIO_PIN ,1 ); +} +#if defined(CONFIG_CMD_SF )int do_spi_toggle (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) {
Signature · 1 line
1.7.1
PATCH 19/20 arm/km: remove spi toggle command
In reply to Valentin LongchampFrom: Holger Brunck <[email protected]>
Now we toggle between SPI and NAND flash automatically if we claim the SPI bus. So we can get rid of this command.
--- board/keymile/km_arm/km_arm.c | 26 -------------------------- include/configs/km/km_arm.h | 5 ++--- 2 files changed, 2 insertions(+), 29 deletions(-)
board/keymile/km_arm/km_arm.c +0 -26
@@ -320,32 +320,6 @@ void board_spi_release_bus(struct spi_slave *slave)kw_gpio_set_value (KM_FLASH_GPIO_PIN ,1 ); } -#if defined(CONFIG_CMD_SF ) -int do_spi_toggle (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) -{ -if (argc <2 ) -return cmd_usage (cmdtp); - -if ((strcmp (argv[1 ],"off" ) ==0 )) { -printf ("SPI FLASH disabled, NAND enabled\n" ); -km_hw_spi_bus_claim (0 ); - }else if ((strcmp (argv[1 ],"on" ) ==0 )) { -printf ("SPI FLASH enabled, NAND disabled\n" ); -km_hw_spi_bus_claim (1 ); - }else { -return cmd_usage (cmdtp); - } - -return 0 ; -} - -U_BOOT_CMD ( - spitoggle,2 ,0 , do_spi_toggle, -"En-/disable SPI FLASH access" , -"<on|off> - Enable (on) or disable (off) SPI FLASH access\n" - ); -#endif -int dram_init (void ) {/* dram_init must store complete ramsize in gd->ram_size */
include/configs/km/km_arm.h +2 -3
@@ -257,9 +257,8 @@ int get_scl(void);#define CONFIG_KM_UPDATE_UBOOT \ "update=" \ - "spi on;sf probe 0;sf erase 0 +${filesize};" \ - "sf write ${load_addr_r} 0 ${filesize};" \ - "spi off\0" + "sf probe 0;sf erase 0 +${filesize};" \ + "sf write ${load_addr_r} 0 ${filesize};\0"#if definedCONFIG_KM_ENV_IS_IN_SPI_NOR #define CONFIG_KM_NEW_ENV \
Signature · 1 line
1.7.1
PATCH 20/20 arm/km: remove calls to kw_gpio_* in board_early_init_f
In reply to Valentin LongchampThese functions tried to access two static tables before relocation (board_early_init_f is executed before relocation). But these static tables lie in the bss section which is not valid before relocation. These accesses then overwrote some parts of u-boot binary before it was relocated. For the kmnusa build, this results in a corrupted important env variable (bootcmd) but it may be that some other parts of the u-boot binary are corrupted.
This patch solves this problem by moving all the kw_gpio_* calls to board_init, which should be early enough in the boot sequence. The only calls that could not be moved is the one for the SOFT (bitbang) I2C, and they have been replaced by a direct access to the GPIO dataout Control register to set the two GPIOs as output.
--- board/keymile/km_arm/km_arm.c | 34 ++++++++++++++++++++++++---------- include/configs/km/km_arm.h | 1 + 2 files changed, 25 insertions(+), 10 deletions(-)
board/keymile/km_arm/km_arm.c +24 -10
@@ -248,9 +248,27 @@ int misc_init_r(void)int board_early_init_f (void ) { +#if defined(CONFIG_SOFT_I2C )u32 tmp; +/* set the 2 bitbang i2c pins as output gpios */ + tmp =readl (KW_GPIO0_BASE +4 ); +writel (tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS ) ,KW_GPIO0_BASE +4 ); +#endif +kirkwood_mpp_conf (kwmpp_config,NULL ); +return 0 ; +} + +int board_init (void ) +{ +/* +* arch number of board +*/ + gd->bd->bi_arch_number =MACH_TYPE_KM_KIRKWOOD ; + +/* address of boot parameters */ + gd->bd->bi_boot_params =kw_sdram_bar (0 ) +0x100 ;/* * The KM_FLASH_GPIO_PIN switches between using a
@@ -259,24 +277,20 @@ int board_early_init_f(void)*/ kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 );kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 ); +#if defined(CONFIG_SOFT_I2C ) -/* init the GPIO for I2C Bitbang driver */ +/* reinit the GPIO for I2C Bitbang driver so that the now +* available gpio framework is consistent. The calls to +* direction output in are not necessary, they are already done in +* board_early_init_f */ kw_gpio_set_valid (KM_KIRKWOOD_SDA_PIN ,1 );kw_gpio_set_valid (KM_KIRKWOOD_SCL_PIN ,1 ); -kw_gpio_direction_output (KM_KIRKWOOD_SDA_PIN ,0 ); -kw_gpio_direction_output (KM_KIRKWOOD_SCL_PIN ,0 );#endif +#if defined(CONFIG_SYS_EEPROM_WREN )kw_gpio_set_valid (KM_KIRKWOOD_ENV_WP ,38 );kw_gpio_direction_output (KM_KIRKWOOD_ENV_WP ,1 );#endif -return 0 ; -} - -int board_init (void ) -{ -/* address of boot parameters */ - gd->bd->bi_boot_params =kw_sdram_bar (0 ) +0x100 ;#if defined(CONFIG_KM_FPGA_CONFIG )trigger_fpga_config ();
include/configs/km/km_arm.h +1 -0
@@ -192,6 +192,7 @@ int get_sda(void);int get_scl (void );#define KM_KIRKWOOD_SDA_PIN 8#define KM_KIRKWOOD_SCL_PIN 9 +#define KM_KIRKWOOD_SOFT_I2C_GPIOS 0x0300#define KM_KIRKWOOD_ENV_WP 38#define I2C_ACTIVE __set_direction(KM_KIRKWOOD_SDA_PIN, 0)
Signature · 1 line
1.7.1
PATCH 20/20 arm/km: remove calls to kw_gpio_* in board_early_init_f
Quoted 72 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Prafulla Wadaskar
Subject: [PATCH 20/20] arm/km: remove calls to kw_gpio_* inboard_early_init_fThese functions tried to access two static tables before relocation (
board_early_init_fis executed before relocation). But these static tables lie in the bss section which is not valid before relocation. These accesses then overwrote some parts of u-boot binary before it was
relocated. For the kmnusa build, this results in a corrupted important env variable (bootcmd) but it may be that some other parts of the u- boot
binary are corrupted.This patch solves this problem by moving all the kw_gpio_* calls to
board_init, which should be early enough in the boot sequence. The only
calls that could not be moved is the one for the SOFT (bitbang) I2C, and
they have been replaced by a direct access to the GPIO dataout Control register to set the two GPIOs as output.Signed-off-by Valentin Longchamp <[email protected]>cc Holger Brunck <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 34 ++++++++++++++++++++++++-------- -- include/configs/km/km_arm.h | 1 + 2 files changed, 25 insertions(+), 10 deletions(-)board/keymile/km_arm/km_arm.c +18
-0@@ -248,9 +248,27 @@ int misc_init_r(void)int board_early_init_f (void ) { +#if defined(CONFIG_SOFT_I2C )u32 tmp; +/* set the 2 bitbang i2c pins as output gpios */ + tmp =readl (KW_GPIO0_BASE +4 ); +writel (tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS ) ,KW_GPIO0_BASE +4 ); +#endif +kirkwood_mpp_conf (kwmpp_config,NULL ); +return 0 ; +} + +int board_init (void ) +{ +/* +* arch number of board +*/ + gd->bd->bi_arch_number =MACH_TYPE_KM_KIRKWOOD ; + +/* address of boot parameters */ + gd->bd->bi_boot_params =kw_sdram_bar (0 ) +0x100 ;/* * The KM_FLASH_GPIO_PIN switches between using a
board/keymile/km_arm/km_arm.c int board_early_init_f(void) · line 285
Quoted 10 lines
board/keymile/km_arm/km_arm.c +5
-1@@ -259,24 +277,20 @@ int board_early_init_f(void)*/ kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 );kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 ); +#if defined(CONFIG_SOFT_I2C ) -/* init the GPIO for I2C Bitbang driver */ +/* reinit the GPIO for I2C Bitbang driver so that the now +* available gpio framework is consistent. The calls to +* direction output in are not necessary, they are already done in +* board_early_init_f */
Comments are not as per coding standard
Regards..
Prafulla . . .
PATCH 20/20 arm/km: remove calls to kw_gpio_* in board_early_init_f
Quoted 69 lines · Prafulla Wadaskar
Quoted 69 lines
-----Original Message-----
From: Valentin Longchamp [mailto:valentin.longchamp at keymile.com]
Sent: 07 June 2012 15:37
To: prafulla at mavell.com
Cc: Valentin Longchamp; holger.brunck at keymile.com; u- boot at lists.denx.de; Prafulla Wadaskar
Subject: [PATCH 20/20] arm/km: remove calls to kw_gpio_* inboard_early_init_fThese functions tried to access two static tables before relocation (
board_early_init_fis executed before relocation). But these static tables lie in the bss section which is not valid before relocation. These accesses then overwrote some parts of u-boot binary before it was
relocated. For the kmnusa build, this results in a corrupted important env variable (bootcmd) but it may be that some other parts of the u- boot
binary are corrupted.This patch solves this problem by moving all the kw_gpio_* calls to
board_init, which should be early enough in the boot sequence. The only
calls that could not be moved is the one for the SOFT (bitbang) I2C, and
they have been replaced by a direct access to the GPIO dataout Control register to set the two GPIOs as output.Signed-off-by Valentin Longchamp <[email protected]>cc Holger Brunck <[email protected]>cc Prafulla Wadaskar <[email protected]>--- board/keymile/km_arm/km_arm.c | 34 ++++++++++++++++++++++++-------- -- include/configs/km/km_arm.h | 1 + 2 files changed, 25 insertions(+), 10 deletions(-)board/keymile/km_arm/km_arm.c +18
-0@@ -248,9 +248,27 @@ int misc_init_r(void)int board_early_init_f (void ) { +#if defined(CONFIG_SOFT_I2C )u32 tmp; +/* set the 2 bitbang i2c pins as output gpios */ + tmp =readl (KW_GPIO0_BASE +4 ); +writel (tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS ) ,KW_GPIO0_BASE +4 ); +#endif +kirkwood_mpp_conf (kwmpp_config,NULL ); +return 0 ; +} + +int board_init (void ) +{ +/* +* arch number of board +*/ + gd->bd->bi_arch_number =MACH_TYPE_KM_KIRKWOOD ; + +/* address of boot parameters */ + gd->bd->bi_boot_params =kw_sdram_bar (0 ) +0x100 ;
Quoted 16 lines
board/keymile/km_arm/km_arm.c int board_early_init_f(void) · line 285
Quoted 13 lines
board/keymile/km_arm/km_arm.c +5
-1/* * The KM_FLASH_GPIO_PIN switches between using a @@ -259,24 +277,20 @@ int board_early_init_f(void)*/ kw_gpio_set_valid (KM_FLASH_GPIO_PIN ,1 );kw_gpio_direction_output (KM_FLASH_GPIO_PIN ,1 ); +#if defined(CONFIG_SOFT_I2C ) -/* init the GPIO for I2C Bitbang driver */ +/* reinit the GPIO for I2C Bitbang driver so that the now +* available gpio framework is consistent. The calls to +* direction output in are not necessary, they are already done in +* board_early_init_f */ Comments are not as per coding standard
Ok I'll fix this in v2.
Regards
Holger