date:20130708

Hi DrEagle,

On Mon, 08 Jul 2013 01:41:38 +0200, DrEagle drea...@doukki.net wrote:

 Le 05/07/2013 23:08, Albert ARIBAUD a écrit :
  Hi Gérald,
 
 Hello,
 
  On Tue, 02 Jul 2013 23:17:51 +0200, DrEagle drea...@doukki.net wrote:
  
  Hi,
 
  I have started to rework all the MVSDIO driver, and some more 
  enhancements, to make a cool updated and workable SheevaPlug.
  I have take the v2013.04 denx uBoot to base my patchs.
 
  If you can take a look inside and give me needed feedback.
 
  I want to precise that I do not easily practice GIT features.
  
  Pease submit patch according to the patch submission guidelines at
  http://www.denx.de/wiki/U-Boot/Patches. Especially, do not send
  patches to the list as attachments; instead, use 'git format-patch' and
  'git send-email'. Also, put the relevant custodians and/or maintainers
  in Cc: of your mail.
 
 I'll try to get it rewrote according rules.

Among these rules, please run your patches through checkpatch, or
through patman. Several lines are way beyond 80 chars, for instance,
and either tool would have spotted this.

 I do not get git send-email working.

 So I have take appart the patch and will send them separatly.

You should investigate why git send-email fails and try to fix it.

 Regards,
 Gérald

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

Hi Bo,

On Mon, 08 Jul 2013 07:33:18 +0800, Bo Shen voice.s...@gmail.com
wrote:

 Hi Albert,
 
 于 7/6/2013 5:02 AM, Albert ARIBAUD 写道:
  Hi Bo,
 
  On Tue,  2 Jul 2013 12:35:54 +, Bo Shen voice.s...@gmail.com
  wrote:
 
  flush cache before disable it
 
  Signed-off-by: Bo Shen voice.s...@gmail.com
  ---
arch/arm/cpu/arm926ejs/cpu.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
 
  diff --git a/arch/arm/cpu/arm926ejs/cpu.c b/arch/arm/cpu/arm926ejs/cpu.c
  index 626384c..10aa165 100644
  --- a/arch/arm/cpu/arm926ejs/cpu.c
  +++ b/arch/arm/cpu/arm926ejs/cpu.c
  @@ -46,15 +46,14 @@ int cleanup_before_linux (void)
 
 disable_interrupts ();
 
  +  /* flush I/D-cache */
  +  cache_flush();
 
 /* turn off I/D-cache */
 icache_disable();
 dcache_disable();
 l2_cache_disable();
 
  -  /* flush I/D-cache */
  -  cache_flush();
  -
 return 0;
}
 
  What is this change supposed to fix?
 
 Actually, this is not a issue fix. Maybe my understanding wrong. I think 
 this is just a logic issue. If the cache is disable, then we flush it, 
 will the contents in the cache corrupted?
 
  There is no need to flush before
  disabling, and actually, flushing before disabling runs the risk that
  between the two, some cache lines be dirtied again so that cache and
  memory won't be coherent any more.
 
 I am not fully understand this. In my mind, I think flush cache (writing 
 the dirty data back to memory) is used to keep the coherence. If my 
 understanding is not correct, please help give more explaination or some 
 reference document to me for understanding.

Maybe you're thinking that disabling a cache means turning it off,
losing all its content? Actually, disabling does not affect the cache
lines' content or state; it only 'bypasses' the cache until enabled
again. While the cache is disabled, all dirty lines remain dirty, and
all non-empty lines remain non-empty.

That being said, yes, flushing is used to keep cache and memory
coherent, and this is precisely why the flush must happen after the
cache is disabled, not before.

It you flush first then disable, you leave a time window between the
two where a write to the cache can happen (either because your code
does one, or because the compiler optimized one in). If it happens,
then you disable a cache which is still dirty -- IOW, your flushing
has failed its mission, and your cache and memory are still not
coherent.

Now, if you disable then flush, then any write between the two will go
straight to memory without dirtying the cache, and once it is flushed,
you end up with coherent cache and memory.

Note that the same time window reason, the cache must be invalidated
before it is enabled, not after; invalidating after enabling could
cause reads to take old, stale values from the cache rather than fetch
the current, fresh ones from memory and caching them.

 Thanks.

You're welcome.

 Best Regards,
 Bo Shen

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/7] drivers: net: cpsw: remove hard coding bd ram for cpsw

BD ram address may vary in various SOC, so removing the hardcoding and
passing the same information through platform data

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 board/ti/am335x/board.c |1 +
 board/ti/ti814x/evm.c   |1 +
 drivers/net/cpsw.c  |4 +---
 include/cpsw.h  |1 +
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index fdbe26c..53981d2 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -443,6 +443,7 @@ static struct cpsw_platform_data cpsw_data = {
.ale_entries= 1024,
.host_port_reg_ofs  = 0x108,
.hw_stats_reg_ofs   = 0x900,
+   .bd_ram_ofs = 0x2000,
.mac_control= (1  5),
.control= cpsw_control,
.host_port_num  = 0,
diff --git a/board/ti/ti814x/evm.c b/board/ti/ti814x/evm.c
index 6ad3dd8..0a05571 100644
--- a/board/ti/ti814x/evm.c
+++ b/board/ti/ti814x/evm.c
@@ -215,6 +215,7 @@ static struct cpsw_platform_data cpsw_data = {
.ale_entries= 1024,
.host_port_reg_ofs  = 0x28,
.hw_stats_reg_ofs   = 0x400,
+   .bd_ram_ofs = 0x2000,
.mac_control= (1  5),
.control= cpsw_control,
.host_port_num  = 0,
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 379b679..dc0a2be 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -51,8 +51,6 @@
 #define CPDMA_RXCP_VER10x160
 #define CPDMA_RXCP_VER20x260
 
-#define CPDMA_RAM_ADDR 0x4a102000
-
 /* Descriptor mode bits */
 #define CPDMA_DESC_SOP BIT(31)
 #define CPDMA_DESC_EOP BIT(30)
@@ -984,12 +982,12 @@ int cpsw_register(struct cpsw_platform_data *data)
return -ENOMEM;
}
 
-   priv-descs = (void *)CPDMA_RAM_ADDR;
priv-host_port = data-host_port_num;
priv-regs  = regs;
priv-host_port_regs= regs + data-host_port_reg_ofs;
priv-dma_regs  = regs + data-cpdma_reg_ofs;
priv-ale_regs  = regs + data-ale_reg_ofs;
+   priv-descs = (void *)regs + data-bd_ram_ofs;
 
int idx = 0;
 
diff --git a/include/cpsw.h b/include/cpsw.h
index 296b0e5..743cb96 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -39,6 +39,7 @@ struct cpsw_platform_data {
int ale_entries;/* ale table size   */
u32 host_port_reg_ofs;  /* cpdma host port registers*/
u32 hw_stats_reg_ofs;   /* cpsw hw stats counters   */
+   u32 bd_ram_ofs; /* Buffer Descriptor RAM offset */
u32 mac_control;
struct cpsw_slave_data  *slave_data;
void(*control)(int enabled);
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/7] ARM: DRA7xx: Add CPSW support to DRA7xx EVM

Adding support for CPSW Ethernet support found in DRA7xx EVM

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |4 +
 arch/arm/include/asm/arch-omap5/cpu.h  |6 ++
 arch/arm/include/asm/arch-omap5/omap.h |   26 ++
 arch/arm/include/asm/omap_common.h |4 +
 board/ti/dra7xx/evm.c  |  150 ++--
 5 files changed, 185 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 1b4ab84..29129f6 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -394,6 +394,10 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
 
 struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_status = 0x4A002134,
+   .control_core_mac_id_0_lo   = 0x4A002514,
+   .control_core_mac_id_0_hi   = 0x4A002518,
+   .control_core_mac_id_1_lo   = 0x4A00251C,
+   .control_core_mac_id_1_hi   = 0x4A002520,
.control_core_mmr_lock1 = 0x4A002540,
.control_core_mmr_lock2 = 0x4A002544,
.control_core_mmr_lock3 = 0x4A002548,
diff --git a/arch/arm/include/asm/arch-omap5/cpu.h 
b/arch/arm/include/asm/arch-omap5/cpu.h
index 4753f46..347f104 100644
--- a/arch/arm/include/asm/arch-omap5/cpu.h
+++ b/arch/arm/include/asm/arch-omap5/cpu.h
@@ -116,6 +116,8 @@ struct watchdog {
 #endif /* __ASSEMBLY__ */
 #endif /* __KERNEL_STRICT_NAMES */
 
+#define BIT(x) (1  (x))
+
 #define WD_UNLOCK1 0x
 #define WD_UNLOCK2 0x
 
@@ -175,4 +177,8 @@ struct watchdog {
 #define PRM_RSTST  (PRM_DEVICE_BASE + 0x4)
 #define PRM_RSTST_WARM_RESET_MASK  0x7FEA
 
+/* DRA7XX CPSW Config space */
+#define CPSW_BASE  0x48484000
+#define CPSW_MDIO_BASE 0x48485000
+
 #endif /* _CPU_H */
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 5e6d82e..929ee67 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -208,6 +208,27 @@ struct s32ktimer {
 #define OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK  (0x1  10)
 #define OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK  (0x1f  0)
 
+/* IO Delay module defines */
+#define CFG_IO_DELAY_BASE  0x4844A000
+#define CFG_IO_DELAY_LOCK  (CFG_IO_DELAY_BASE + 0x02C)
+
+/* CPSW IO Delay registers*/
+#define CFG_RGMII0_TXCTL   (CFG_IO_DELAY_BASE + 0x74C)
+#define CFG_RGMII0_TXD0(CFG_IO_DELAY_BASE + 0x758)
+#define CFG_RGMII0_TXD1(CFG_IO_DELAY_BASE + 0x764)
+#define CFG_RGMII0_TXD2(CFG_IO_DELAY_BASE + 0x770)
+#define CFG_RGMII0_TXD3(CFG_IO_DELAY_BASE + 0x77C)
+#define CFG_VIN2A_D13  (CFG_IO_DELAY_BASE + 0xA7C)
+#define CFG_VIN2A_D17  (CFG_IO_DELAY_BASE + 0xAAC)
+#define CFG_VIN2A_D16  (CFG_IO_DELAY_BASE + 0xAA0)
+#define CFG_VIN2A_D15  (CFG_IO_DELAY_BASE + 0xA94)
+#define CFG_VIN2A_D14  (CFG_IO_DELAY_BASE + 0xA88)
+
+#define CFG_IO_DELAY_UNLOCK_KEY0x
+#define CFG_IO_DELAY_LOCK_KEY  0xAAAB
+#define CFG_IO_DELAY_ACCESS_PATTERN0x00029000
+#define CFG_IO_DELAY_LOCK_MASK 0x400
+
 #ifndef __ASSEMBLY__
 struct srcomp_params {
s8 divide_factor;
@@ -224,5 +245,10 @@ struct ctrl_ioregs {
u32 ctrl_emif_sdram_config_ext;
u32 ctrl_ddr_ctrl_ext_0;
 };
+
+struct io_delay {
+   u32 addr;
+   u32 dly;
+};
 #endif /* __ASSEMBLY__ */
 #endif
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 4a4a769..75198cf 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -364,6 +364,10 @@ struct prcm_regs {
 
 struct omap_sys_ctrl_regs {
u32 control_status;
+   u32 control_core_mac_id_0_lo;
+   u32 control_core_mac_id_0_hi;
+   u32 control_core_mac_id_1_lo;
+   u32 control_core_mac_id_1_hi;
u32 control_std_fuse_opp_vdd_mpu_2;
u32 control_core_mmr_lock1;
u32 control_core_mmr_lock2;
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index bf7e091..4cbd162 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -39,12 +39,53 @@
 #include asm/ehci-omap.h
 #endif
 
+#ifdef CONFIG_DRIVER_TI_CPSW
+#include cpsw.h
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 const struct omap_sysinfo sysinfo = {
Board: DRA7xx\n
 };
 
+/*
+ * Adjust I/O delays on the Tx control and data lines of each MAC port. This
+ * is a workaround in order to work properly with the DP83865 PHYs on the EVM.
+ * In 3COM RGMII mode this PHY applies it's own internal clock delay, so we
+ * essentially need to counteract the DRA7xx internal delay,

[U-Boot] [PATCH 0/7] Ethernet bringup patchset for DRA7xx EVM

This patch series brings up the CPSW ethernet in DRA7xx EVM and
it is based on the master branch on git://git.denx.de/u-boot.git

This patch is also tested with basic boot of Omap 5 and tftp
download test with AM335x EVM.

Lokesh Vutla (1):
  ARM: DRA7xx: Lock DPLL_GMAC

Mugunthan V N (6):
  drivers: net: cpsw: remove hard coding bd ram for cpsw
  drivers: net: cpsw: Enable statistics for all port
  ARM: DRA7xx: Enable GMAC clock control
  ARM: DRA7xx: Add CPSW support to DRA7xx EVM
  ARM: DRA7xx: Add CPSW and MDIO pinmux support
  ARM: DRA7xx: Enable CPSW Ethernet support

 arch/arm/cpu/armv7/omap-common/clocks-common.c |   18 +++
 arch/arm/cpu/armv7/omap5/hw_data.c |   18 ++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |7 ++
 arch/arm/include/asm/arch-omap5/cpu.h  |6 +
 arch/arm/include/asm/arch-omap5/omap.h |   26 
 arch/arm/include/asm/omap_common.h |   10 ++
 board/ti/am335x/board.c|1 +
 board/ti/dra7xx/evm.c  |  150 +++-
 board/ti/dra7xx/mux_data.h |   14 +++
 board/ti/ti814x/evm.c  |1 +
 drivers/net/cpsw.c |5 +-
 include/configs/dra7xx_evm.h   |   19 +++
 include/cpsw.h |1 +
 13 files changed, 267 insertions(+), 9 deletions(-)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/7] drivers: net: cpsw: Enable statistics for all port

Enable hardware statistics for all ports, enabling only to host port is useless

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/cpsw.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index dc0a2be..f1e9f72 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -772,6 +772,7 @@ static int cpsw_init(struct eth_device *dev, bd_t *bis)
 
/* enable statistics collection only on the host port */
__raw_writel(BIT(priv-host_port), priv-regs-stat_port_en);
+   __raw_writel(0x7, priv-regs-stat_port_en);
 
cpsw_ale_port_state(priv, priv-host_port, ALE_PORT_STATE_FORWARD);
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/7] ARM: DRA7xx: Lock DPLL_GMAC

From: Lokesh Vutla lokeshvu...@ti.com

Locking DPLL_GMAC

[mugunthan...@ti.com:Configure only if CPSW is selected]

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   18 ++
 arch/arm/cpu/armv7/omap5/hw_data.c |   11 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/omap_common.h |2 ++
 4 files changed, 32 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index ef23127..e26d741 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -212,6 +212,18 @@ static const struct dpll_params *get_ddr_dpll_params
return dpll_data-ddr[sysclk_ind];
 }
 
+#ifdef CONFIG_DRIVER_TI_CPSW
+static const struct dpll_params *get_gmac_dpll_params
+   (struct dplls const *dpll_data)
+{
+   u32 sysclk_ind = get_sys_clk_index();
+
+   if (!dpll_data-gmac)
+   return NULL;
+   return dpll_data-gmac[sysclk_ind];
+}
+#endif
+
 static void do_setup_dpll(u32 const base, const struct dpll_params *params,
u8 lock, char *dpll)
 {
@@ -414,6 +426,12 @@ static void setup_dplls(void)
params = get_ddr_dpll_params(*dplls_data);
do_setup_dpll((*prcm)-cm_clkmode_dpll_ddrphy,
  params, DPLL_LOCK, ddr);
+
+#ifdef CONFIG_DRIVER_TI_CPSW
+   params = get_gmac_dpll_params(*dplls_data);
+   do_setup_dpll((*prcm)-cm_clkmode_dpll_gmac, params,
+ DPLL_LOCK, gmac);
+#endif
 }
 
 #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 56cf1f8..c909dcd 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -263,6 +263,16 @@ static const struct dpll_params 
ddr_dpll_params_2128mhz[NUM_SYS_CLKS] = {
{665, 23, 2, 1, 8, -1, -1, -1, -1, -1, -1, -1}, /* 38.4 MHz */
 };
 
+static const struct dpll_params gmac_dpll_params_2000mhz[NUM_SYS_CLKS] = {
+   {250, 2, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1}, /* 12 MHz   */
+   {250, 4, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1}, /* 20 MHz   */
+   {119, 1, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+   {625, 11, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1},/* 19.2 MHz */
+   {500, 12, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1},/* 26 MHz   */
+   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {625, 23, 4, 10, 40, 8, 10, -1, -1, -1, -1, -1},/* 38.4 MHz */
+};
+
 struct dplls omap5_dplls_es1 = {
.mpu = mpu_dpll_params_800mhz,
.core = core_dpll_params_2128mhz_ddr532,
@@ -299,6 +309,7 @@ struct dplls dra7xx_dplls = {
.iva = iva_dpll_params_2330mhz_dra7xx,
.usb = usb_dpll_params_1920mhz,
.ddr = ddr_dpll_params_2128mhz,
+   .gmac = gmac_dpll_params_2000mhz,
 };
 
 struct pmic_data palmas = {
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e839ff5..7793763 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -814,6 +814,7 @@ struct prcm_regs const dra7xx_prcm = {
.cm_ssc_deltamstep_dpll_ddrphy  = 0x4a00522c,
.cm_clkmode_dpll_dsp= 0x4a005234,
.cm_shadow_freq_config1 = 0x4a005260,
+   .cm_clkmode_dpll_gmac   = 0x4a0052a8,
 
/* cm1.mpu */
.cm_mpu_mpu_clkctrl = 0x4a005320,
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 0dbe81b..8b4201b 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -89,6 +89,7 @@ struct prcm_regs {
u32 cm_ssc_deltamstep_dpll_ddrphy;
u32 cm_clkmode_dpll_dsp;
u32 cm_shadow_freq_config1;
+   u32 cm_clkmode_dpll_gmac;
u32 cm_mpu_mpu_clkctrl;
 
/* cm1.dsp */
@@ -499,6 +500,7 @@ struct dplls {
const struct dpll_params *iva;
const struct dpll_params *usb;
const struct dpll_params *ddr;
+   const struct dpll_params *gmac;
 };
 
 struct pmic_data {
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/7] ARM: DRA7xx: Enable GMAC clock control

Enabling CPSW module by enabling GMAC clock control

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/cpu/armv7/omap5/hw_data.c   |7 ++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c |2 ++
 arch/arm/include/asm/omap_common.h   |4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index c909dcd..f659610 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -409,6 +409,9 @@ void enable_basic_clocks(void)
(*prcm)-cm_l3init_clkstctrl,
(*prcm)-cm_memif_clkstctrl,
(*prcm)-cm_l4cfg_clkstctrl,
+#ifdef CONFIG_DRIVER_TI_CPSW
+   (*prcm)-cm_gmac_clkstctrl,
+#endif
0
};
 
@@ -434,6 +437,9 @@ void enable_basic_clocks(void)
(*prcm)-cm_wkup_wdtimer2_clkctrl,
(*prcm)-cm_l4per_uart3_clkctrl,
(*prcm)-cm_l4per_i2c1_clkctrl,
+#ifdef CONFIG_DRIVER_TI_CPSW
+   (*prcm)-cm_gmac_gmac_clkctrl,
+#endif
0
};
 
@@ -490,7 +496,6 @@ void enable_basic_uboot_clocks(void)
(*prcm)-cm_l3init_fsusb_clkctrl,
0
};
-
do_enable_clocks(clk_domains_essential,
 clk_modules_hw_auto_essential,
 clk_modules_explicit_en_essential,
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 7793763..1b4ab84 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -912,6 +912,8 @@ struct prcm_regs const dra7xx_prcm = {
.cm_l3init_hsusbhost_clkctrl= 0x4a009340,
.cm_l3init_hsusbotg_clkctrl = 0x4a009348,
.cm_l3init_hsusbtll_clkctrl = 0x4a009350,
+   .cm_gmac_clkstctrl  = 0x4a0093c0,
+   .cm_gmac_gmac_clkctrl   = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
 
/* cm2.l4per */
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 8b4201b..4a4a769 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -356,6 +356,10 @@ struct prcm_regs {
/* SCRM stuff, used by some boards */
u32 scrm_auxclk0;
u32 scrm_auxclk1;
+
+   /* GMAC Clk Ctrl */
+   u32 cm_gmac_gmac_clkctrl;
+   u32 cm_gmac_clkstctrl;
 };
 
 struct omap_sys_ctrl_regs {
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 6/7] ARM: DRA7xx: Add CPSW and MDIO pinmux support

Adding CPSW Slave 0 and MDIO pinmux support for DRA7xx EVM

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 board/ti/dra7xx/mux_data.h |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 338a241..b63fc36 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -53,5 +53,19 @@ const struct pad_conf_entry core_padconf_array_essential[] = 
{
{UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
{I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
{I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
+   {MDIO_MCLK, (PTU | PEN | M0)},  /* MDIO_MCLK  */
+   {MDIO_D, (IEN | PTU | PEN | M0)},   /* MDIO_D  */
+   {RGMII0_TXC, (M0) },
+   {RGMII0_TXCTL, (M0) },
+   {RGMII0_TXD3, (M0) },
+   {RGMII0_TXD2, (M0) },
+   {RGMII0_TXD1, (M0) },
+   {RGMII0_TXD0, (M0) },
+   {RGMII0_RXC, (IEN | M0) },
+   {RGMII0_RXCTL, (IEN | M0) },
+   {RGMII0_RXD3, (IEN | M0) },
+   {RGMII0_RXD2, (IEN | M0) },
+   {RGMII0_RXD1, (IEN | M0) },
+   {RGMII0_RXD0, (IEN | M0) },
 };
 #endif /* _MUX_DATA_DRA7XX_H_ */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 7/7] ARM: DRA7xx: Enable CPSW Ethernet support

Enabling CPSW Ethernet support in DRA7xx EVM.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 include/configs/dra7xx_evm.h |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index c11f005..ed3aa43 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -44,4 +44,23 @@
 
 #define CONSOLEDEV ttyO0
 
+/* CPSW Ethernet */
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_MII
+#define CONFIG_DRIVER_TI_CPSW
+#define CONFIG_MII
+#define CONFIG_BOOTP_DEFAULT
+#define CONFIG_BOOTP_DNS
+#define CONFIG_BOOTP_DNS2
+#define CONFIG_BOOTP_SEND_HOSTNAME
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_NET_RETRY_COUNT 10
+#define CONFIG_NET_MULTI
+#define CONFIG_PHY_GIGE
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_ADDR2
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

hi Albert,
On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:

snip

 It you flush first then disable, you leave a time window between the
 two where a write to the cache can happen (either because your code
 does one, or because the compiler optimized one in). If it happens,
 then you disable a cache which is still dirty -- IOW, your flushing
 has failed its mission, and your cache and memory are still not
 coherent.

Since this is specific to arm926ejs, can we not flush *and* invalidate
the dcache before disabling it -- since the arm926ejs cache uses a
read allocate policy, flushing and invalidating a cache before
disabling it would not result in the cache getting written to in the
window that you refer to. Also, flushing and invalidating is an atomic
operation.

 
 Now, if you disable then flush, then any write between the two will go
 straight to memory without dirtying the cache, and once it is flushed,
 you end up with coherent cache and memory.

I had a question here. Would the same logic not apply to the case you
mention -- in case the cache is disabled and subsequently flushed,
could there not be a scenario where there is a valid(updated) data
that gets written to the memory, which then gets overwritten by the
cache flush. Or am i missing something here.

-sughosh

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

hi Albert,
On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:

snip

 It you flush first then disable, you leave a time window between the
 two where a write to the cache can happen (either because your code
 does one, or because the compiler optimized one in). If it happens,
 then you disable a cache which is still dirty -- IOW, your flushing
 has failed its mission, and your cache and memory are still not
 coherent.

Since this is specific to arm926ejs, can we not flush *and* invalidate
the dcache before disabling it -- since the arm926ejs cache uses a
read allocate policy, flushing and invalidating a cache before
disabling it would not result in the cache getting written to in the
window that you refer to. Also, flushing and cleaning is an atomic
operation.

 Now, if you disable then flush, then any write between the two will go
 straight to memory without dirtying the cache, and once it is flushed,
 you end up with coherent cache and memory.

I had a question here. Would the same logic not apply to the case you
mention -- in case the cache is disabled and subsequently flushed,
could there not be a scenario where there is a valid(updated) data
that gets written to the memory, which then gets overwritten by the
cache flush. Or am i missing something here.

sughosh

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] arm:goni: Add support for USB mass storage

2013-07-08 Thread Minkyu Kang

On Monday, July 8, 2013, Minkyu Kang wrote:

 On 04/07/13 19:52, Lukasz Majewski wrote:
  From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com javascript:;
 
  This commit enables support for USB mass storage composite function.
  It defines platform code and enables it at config file.
 
  Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.comjavascript:;
 
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com javascript:;
  Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com javascript:;
 
  Cc: Minkyu Kang mk7.k...@samsung.com javascript:;
  ---
   board/samsung/goni/goni.c  |   68
 
   include/configs/s5p_goni.h |5 
   2 files changed, 73 insertions(+)
 

 please run checkpatch before submitting.

 CHECK: Alignment should match open parenthesis
 #51: FILE: board/samsung/goni/goni.c:173:
 +   if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num,
 +   start + ums_dev-offset, blkcnt, buf) != blkcnt)

 CHECK: Alignment should match open parenthesis
 #61: FILE: board/samsung/goni/goni.c:183:
 +   if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num,
 +   start + ums_dev-offset, blkcnt, buf) != blkcnt)

 total: 0 errors, 0 warnings, 2 checks, 86 lines checked

  diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
  index 3c53106..a09daca 100644
  --- a/board/samsung/goni/goni.c
  +++ b/board/samsung/goni/goni.c
  @@ -29,6 +29,7 @@
   #include usb/s3c_udc.h
   #include asm/arch/cpu.h
   #include power/max8998_pmic.h
  +#include usb_mass_storage.h
   DECLARE_GLOBAL_DATA_PTR;
 
   static struct s5pc110_gpio *s5pc110_gpio;
  @@ -163,3 +164,70 @@ void board_usb_init(void)
   }
 
   #endif
  +
  +#ifdef CONFIG_USB_GADGET_MASS_STORAGE
  +static int ums_read_sector(struct ums_device *ums_dev,
  + ulong start, lbaint_t blkcnt, void *buf)
  +{
  + if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num,
  + start + ums_dev-offset, blkcnt, buf) != blkcnt)
  + return -1;
  +
  + return 0;
  +}
  +
  +static int ums_write_sector(struct ums_device *ums_dev,
  + ulong start, lbaint_t blkcnt, const void
 *buf)
  +{
  + if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num,
  + start + ums_dev-offset, blkcnt, buf) != blkcnt)
  + return -1;

 indentation error.

  +
  + return 0;
  +}
  +
  +static void ums_get_capacity(struct ums_device *ums_dev,
  + long long int *capacity)
  +{
  + long long int tmp_capacity;
  +
  + tmp_capacity = (long long int) ((ums_dev-offset +
 ums_dev-part_size)
  + * SECTOR_SIZE);
  + *capacity = ums_dev-mmc-capacity - tmp_capacity;
  +}
  +
  +static struct ums_board_info ums_board = {
  + .read_sector = ums_read_sector,
  + .write_sector = ums_write_sector,
  + .get_capacity = ums_get_capacity,
  + .name = GONI UMS disk,
  + .ums_dev = {
  + .mmc = NULL,
  + .dev_num = 0,
  + .offset = 0,
  + .part_size = 0.
  + },
  +};
  +
  +struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned
 int offset,
  + unsigned int part_size)
  +{
  + struct mmc *mmc;
  +
  + mmc = find_mmc_device(dev_num);
  + /* mmc initialization is necessary prior to the ums command usage
  +  * due to fact that on goni target environment is read from oneNand
  +  * memory, so the mmc remains uninitialized whenu-boot prompt
 appears
  +  * */


please fix multiline comment style.


  + if (!mmc || mmc_init(mmc))
  + return NULL;
  +
  + ums_board.ums_dev.mmc = mmc;
  + ums_board.ums_dev.dev_num = dev_num;
  + ums_board.ums_dev.offset = offset;
  + ums_board.ums_dev.part_size = part_size;
  +
  + return ums_board;
  +}
  +
  +#endif
  diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
  index e8f2639..1cfbb88 100644
  --- a/include/configs/s5p_goni.h
  +++ b/include/configs/s5p_goni.h
  @@ -269,4 +269,9 @@
   #define CONFIG_USB_GADGET_DUALSPEED
   #define CONFIG_USB_GADGET_VBUS_DRAW 2
 
  +#define CONFIG_CMD_USB_MASS_STORAGE
  +#if defined(CONFIG_CMD_USB_MASS_STORAGE)

 unnecessary ifdef.
 this file is board specific and we already knew that
 CONFIG_CMD_USB_MASS_STORAGE is defined.

  +#define CONFIG_USB_GADGET_MASS_STORAGE
  +#endif
  +
   #endif   /* __CONFIG_H */
 

 ___
 U-Boot mailing list
 U-Boot@lists.denx.de javascript:;
 http://lists.denx.de/mailman/listinfo/u-boot



-- 
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

Hi Sughosh,

On Mon, 8 Jul 2013 17:38:46 +0530, Sughosh Ganu
urwithsugh...@gmail.com wrote:

 hi Albert,
 On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:
 
 snip
 
  It you flush first then disable, you leave a time window between the
  two where a write to the cache can happen (either because your code
  does one, or because the compiler optimized one in). If it happens,
  then you disable a cache which is still dirty -- IOW, your flushing
  has failed its mission, and your cache and memory are still not
  coherent.
 
 Since this is specific to arm926ejs, can we not flush *and* invalidate
 the dcache before disabling it -- since the arm926ejs cache uses a
 read allocate policy, flushing and invalidating a cache before
 disabling it would not result in the cache getting written to in the
 window that you refer to. Also, flushing and cleaning is an atomic
 operation.

Invalidating the cache in addition to flushing it would not prevent
further writes from dirtying the cache lines if they happen before
the cache is disabled.

  Now, if you disable then flush, then any write between the two will go
  straight to memory without dirtying the cache, and once it is flushed,
  you end up with coherent cache and memory.
 
 I had a question here. Would the same logic not apply to the case you
 mention -- in case the cache is disabled and subsequently flushed,
 could there not be a scenario where there is a valid(updated) data
 that gets written to the memory, which then gets overwritten by the
 cache flush. Or am i missing something here.

There could be such a risk indeed, in the following scenario:

- an address gets written into, causing the new value to be cached;
- the cache is disabled;
- the same address is written into again, directly into memory;
- the flush occurs, overwriting the second value with the first.

This scenario requires two subsequent writes of different values to the
same address, which is less likely than the failure scenario of flushing
before disabling, which only requires writing a new value once for any
address:

- the flush occurs;
- an address gets written into, causing the new value to be cached;
- the cache is disabled;
- the value is lost as the cache will be invalidated before being
  re-enabled.

I'll grant you that the current code is not zero-risk, if we ever have
code that double-writes two different values in the same location. But
the proposed RFC increases the risks.

 sughosh

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] USB: XHCI: Add xHCI host controller stack driver

Hi Vivek,

[...]

 Very well said. I can see Dan's stack is nicely sync'ed with Linux
 (with ifdef's ;-) which i am sure are going to vanish down the line)
 I had a initial look at Dan's patches, which have backported DWC3 and
 XHCI, but i am sure we are going to
 need some amount of code to be put in usb core framework (common/usb*.c),
 if we are going to enable complete xHCI (super speed) support.

Absolutely, you have that part though ;-)

 For DWC3, i leave it to you, as to how much code we want to pull in.
 Ofcourse my driver for exynos did some basic DWC3 initialization,
 making it hard for other vendors who are using DWC3 to resuse the code.

Exynos also uses dwc3 ?

  What I'd like to see is Vivek's version merged into Dan's version, that
  should be easy (by the looks of it) and then this combined version
  merged mainline. This should hopefully retain the easy possibility to
  update the USB3 code from Linux. It should also cut down the time it
  will take to get Dan's code into working state (since that's done in
  Vivek's tree already).
 
 We can go ahead merging the two versions. But i do have few doubts
 with how Dan is
 structuring things.
 Better i comment on his patches and clear my doubts.

Thanks.

 Dear Dan,
 
 Please suggest on how you are planning going ahead and merging the two
 versions of xHCI stack.
 
  Now you can flame me to death.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

Hi guys,

 On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.org wrote:
  On 07/01/2013 07:49 AM, Vivek Gautam wrote:
  Hi Marek,
  
  On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
  Dear Stephen Warren,
  
  (Sorry to those on to/cc; I'm resending this so it goes to the correct
  mailing list)
  
  Dear Stephen,
  sorry for the delay in responding to this.
  
  Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
  regression on Tegra systems.
  
  The first time usb start is executed, it appears to work correctly.
  However, any subsequent time it is executed, it takes a long time, and
  eventually fails to find any USB devices.
  
  This situation can happen quite often; for example, if the user
  forgets to plug in a USB device before booting, runs usb start,
  realizes that, then plugs it in and runs usb start again. This is
  compounded on at least one of the Tegra boards, since CONFIG_PREBOOT
  is set to usb start on systems (laptops/clamshells) which have
  built-in USB keyboards.
  
  If I simply revert this patch, then everything works again. (Yes,
  reverting requires fixing a small merge conflict.)
  
  Do you have any idea what the problem can be? I'm tempted to simply
  ask for the patch to be reverted since it causes a regression.
  
  Thanks for any idea how to fix this!
  
  BUMP? Vivek, any ideas? Otherwise I'm reverting this.
  
  ...
  
  There's one BUG that i could see in  0bf796f  commit.
  Now that we parallelized the sequence to power cycle ports, so if
  get_port_status for any port failed,
  it returns from hub_power_on() and not power-on any of the port.
  
  Below is the change i suggest.
  
  ...
  
  can you please confirm if you problem is related to this BUG in the
  sequence of power-cycling the ports.
  
  I applied that change, and it does not solve the problem on Tegra, nor
  do I see any of the messages that were changed from debug to printf.
  Below is the log:
  
  U-Boot 2013.04-00281-g0e8ef51 (Jul 01 2013 - 10:33:36)
  
  TEGRA20
  Board: NVIDIA Seaboard
  DRAM:  1 GiB
  NAND:  512 MiB
  MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
  In:tegra-kbc
  Out:   lcd
  Err:   lcd
  Net:   Net Initialization Skipped
  No ethernet found.
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 2 USB Device(s) found
  USB2:   lowlevel init failed
  
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices...
  
  Warning: asx0 using MAC address from net device
  1 Ethernet Device(s) found
  Hit any key to stop autoboot:  0
  
  
  Tegra20 (SeaBoard) # usb start
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
  
  (there's a much longer pause when scanning this bus every time except
  the very first)
 
 This long pause could be from the 10sec delay present in
 common/usb_hub.c: usb_hub_configure(): line 475
 (the do-while loop present to check Current Connect Status and Connect
 Status Change bits)
 
 I could actually see somewhat similar issue of long pause on xHCI
 port, if we didn't apply patches:
 0bf796f usb: hub: Parallelize power-cycling of root-hub ports
 020bbcb usb: hub: Power-cycle on root-hub ports
 
 This was because, once usb_hub_power_on() was called, Connect Status
 Change bit of xHC port was
 getting cleared though Current Connect Status was still asserted, even
 untill that no code handles that bit.
 
 For xHC, setting the Port_power bit, in case that bit was initially
 asserted clears CSC bit.
 
  USB2:   lowlevel init failed
  
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices... 0 Ethernet Device(s) found
  
  Tegra20 (SeaBoard) # usb start
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
  USB2:   lowlevel init failed
  
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices... 0 Ethernet Device(s) found
 
 I think we should be checking EHCI registers now, PORTSC register to
 be specific to see how the
 port power is getting affected.
 On smdk5250 i am unable see this behavior, which is having only one
 controller unlike
 seaboard which i can see has 3 controllers.

Vivek, what do I have to revert to fix this flub? I will do that now, since 
this 
discussion is stalled.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: fix unaligned access in device_qual()

Dear Albert ARIBAUD,

 Hi Marek,
 
 On Wed, 3 Jul 2013 15:30:20 +0200, Marek Vasut ma...@denx.de wrote:
  Dear Albert ARIBAUD,
  
   Hi Marek,
   
   On Thu, 27 Jun 2013 15:23:33 +0200, Marek Vasut ma...@denx.de wrote:
Hello Albert,

 Hi Marek,
 
 On Thu, 27 Jun 2013 13:26:39 +0200, Marek Vasut ma...@denx.de wrote:
  Dear Heiko Schocher,
  
   while playing with dfu, I tapped in an unaligned access
   when doing on the host side a lsusb -d [vendornr]: -v
  
   I get on the board:
  Applied, thanks
 
 Now we have console log output in commit messages. :(

Don't be sad, I will buy you a tartelette ;)
   
   Actually the sad part is that the patch in itself is bad: the actual
   alignment boundary should have been 16 bit, not one cacheline. Also,
   the issue could / should have been solved by reordering the fields
   rather than using an attribute.
  
  Why 16 bit? I think cacheline alignment here makes sense if the
  descriptor is to be flush()'d from dcache.
 
 If it is then it should be moved out of the struct it currently lives
 in, in order to avoid a big alignment gap, and replaced with a pointer.
 Also, the commit message would then be wrong...

Good point, Heiko, can you comment?

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] omap3/sys_info: fix printout of OMAP36XX L3 freqency

2013-07-08 Thread Andreas Bießmann

The OMAP36xx/OMAP37xx family uses L3 frequency of 200MHz instead of 165MHz
used by OMAP34xx/OMAP35xx.

Also fix checkpatch warning about alignment.

Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
 arch/arm/cpu/armv7/omap3/sys_info.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/sys_info.c 
b/arch/arm/cpu/armv7/omap3/sys_info.c
index 08a63d2..a864eb9 100644
--- a/arch/arm/cpu/armv7/omap3/sys_info.c
+++ b/arch/arm/cpu/armv7/omap3/sys_info.c
@@ -355,9 +355,9 @@ int print_cpuinfo (void)
}
 
if (CPU_OMAP36XX == get_cpu_family())
-   printf(%s%s-%s ES%s, CPU-OPP2, L3-165MHz, Max CPU Clock %s\n,
-   cpu_family_s, cpu_s, sec_s,
-   rev_s_37xx[get_cpu_rev()], max_clk);
+   printf(%s%s-%s ES%s, CPU-OPP2, L3-200MHz, Max CPU Clock %s\n,
+  cpu_family_s, cpu_s, sec_s,
+  rev_s_37xx[get_cpu_rev()], max_clk);
else
printf(%s%s-%s ES%s, CPU-OPP2, L3-165MHz, Max CPU Clock %s\n,
cpu_family_s, cpu_s, sec_s,
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] bootm: Handle errors consistently

On Fri, Jul 05, 2013 at 01:48:30PM -0700, Simon Glass wrote:
 Hi Tom,
 
 On Fri, Jul 5, 2013 at 1:29 PM, Tom Rini tr...@ti.com wrote:
 
  On Fri, Jul 05, 2013 at 01:21:09PM -0700, Simon Glass wrote:
   Hi Tom,
  
   On Fri, Jul 5, 2013 at 1:15 PM, Tom Rini tr...@ti.com wrote:
  
On Fri, Jul 05, 2013 at 12:52:03PM -0700, Simon Glass wrote:
 Hi Tom,

 On Fri, Jul 5, 2013 at 5:59 AM, Tom Rini tr...@ti.com wrote:

  On Thu, Jul 04, 2013 at 01:17:07PM -0700, Simon Glass wrote:
 
   A recent bootm fix left the error path incomplete. Reinstate
  this so
that
   failures in bootm stages are handled properly.
  
   Signed-off-by: Simon Glass s...@chromium.org
   ---
   Changes in v2:
   - Correct checking in the no-error case
 
 
  OK, this conflicts with the change I posted (and pushed later than
  I
  thought I had).  Can you confirm the code is good in mainline now?
  Thanks!
 

 It's close, but I think it still needs this near the end
 of do_bootm_states(), something like:

  else if (ret == BOOTM_ERR_RESET) do_reset(cmdtp, flag, argc, argv);
  +
else
 if (ret) + puts(subcommand not supported\n); return ret;

 If you agree, I can prepare a patch as part of the bootz update.
   
How do we get there in the code?  When we do any subcalls is where
  we've
got that puts already.  Failures from that point on are either the OS
bootm part failed (and return is  0) or one of the BOOTM_ERR codes.
   Or
did I miss a case still?
   
  
   I think this is when the boot_os function returns an error. At least the
   old code had quite a lot of printf()s for that case.
 
  We had a printf per subcommand before, and just a single one now.  We
  didn't say the 'go' subcommand failed however, just what the
  function happened to print out.
 
 Yes that looks right to me. But I believe that the GO command is not
 supposed to return, so it might be harmless to put the message there in all
 cases. If not, we can add a special case for GO.

OK, I've been re-reading the before and after code, and at least wrt
error messages and such, we're OK now.  The 'GO' state is allowed to
return 1 and usually does both for detectable errors (for example, FIT
image for VxWorks, but a bad image) and wth? we've been returned to
from the OS.  And I don't want to add a won't be reached string to
the build given how badly we see compilers dealing with optimizing
strings, along with the code bloat reason.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

2013-07-08 Thread Vivek Gautam

Hi Marek,


On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
 Hi guys,

 On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
  On 07/01/2013 07:49 AM, Vivek Gautam wrote:
  Hi Marek,
 
  On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
  Dear Stephen Warren,
 
  (Sorry to those on to/cc; I'm resending this so it goes to the correct
  mailing list)
 
  Dear Stephen,
  sorry for the delay in responding to this.
 
  Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
  regression on Tegra systems.
 
  The first time usb start is executed, it appears to work correctly.
  However, any subsequent time it is executed, it takes a long time, and
  eventually fails to find any USB devices.
 
  This situation can happen quite often; for example, if the user
  forgets to plug in a USB device before booting, runs usb start,
  realizes that, then plugs it in and runs usb start again. This is
  compounded on at least one of the Tegra boards, since CONFIG_PREBOOT
  is set to usb start on systems (laptops/clamshells) which have
  built-in USB keyboards.
 
  If I simply revert this patch, then everything works again. (Yes,
  reverting requires fixing a small merge conflict.)
 
  Do you have any idea what the problem can be? I'm tempted to simply
  ask for the patch to be reverted since it causes a regression.
 
  Thanks for any idea how to fix this!
 
  BUMP? Vivek, any ideas? Otherwise I'm reverting this.
 
  ...
 
  There's one BUG that i could see in  0bf796f  commit.
  Now that we parallelized the sequence to power cycle ports, so if
  get_port_status for any port failed,
  it returns from hub_power_on() and not power-on any of the port.
 
  Below is the change i suggest.
 
  ...
 
  can you please confirm if you problem is related to this BUG in the
  sequence of power-cycling the ports.
 
  I applied that change, and it does not solve the problem on Tegra, nor
  do I see any of the messages that were changed from debug to printf.
  Below is the log:
 
  U-Boot 2013.04-00281-g0e8ef51 (Jul 01 2013 - 10:33:36)
 
  TEGRA20
  Board: NVIDIA Seaboard
  DRAM:  1 GiB
  NAND:  512 MiB
  MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
  In:tegra-kbc
  Out:   lcd
  Err:   lcd
  Net:   Net Initialization Skipped
  No ethernet found.
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 2 USB Device(s) found
  USB2:   lowlevel init failed
 
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices...
 
  Warning: asx0 using MAC address from net device
  1 Ethernet Device(s) found
  Hit any key to stop autoboot:  0
 
 
  Tegra20 (SeaBoard) # usb start
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
 
  (there's a much longer pause when scanning this bus every time except
  the very first)

 This long pause could be from the 10sec delay present in
 common/usb_hub.c: usb_hub_configure(): line 475
 (the do-while loop present to check Current Connect Status and Connect
 Status Change bits)

 I could actually see somewhat similar issue of long pause on xHCI
 port, if we didn't apply patches:
 0bf796f usb: hub: Parallelize power-cycling of root-hub ports
 020bbcb usb: hub: Power-cycle on root-hub ports

 This was because, once usb_hub_power_on() was called, Connect Status
 Change bit of xHC port was
 getting cleared though Current Connect Status was still asserted, even
 untill that no code handles that bit.

 For xHC, setting the Port_power bit, in case that bit was initially
 asserted clears CSC bit.

  USB2:   lowlevel init failed
 
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices... 0 Ethernet Device(s) found
 
  Tegra20 (SeaBoard) # usb start
  (Re)start USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 2 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
  USB2:   lowlevel init failed
 
 scanning usb for storage devices... 0 Storage Device(s) found
 scanning usb for ethernet devices... 0 Ethernet Device(s) found

 I think we should be checking EHCI registers now, PORTSC register to
 be specific to see how the
 port power is getting affected.
 On smdk5250 i am unable see this behavior, which is having only one
 controller unlike
 seaboard which i can see has 3 controllers.

 Vivek, what do I have to revert to fix this flub? I will do that now, since 
 this
 discussion is stalled.

0bf796f usb: hub: Parallelize power-cycling of root-hub ports
020bbcb usb: hub: Power-cycle on root-hub ports

Above two patches are the one which changed the hub_power_on() functionality.
If Stephen can confirm that reverting these patches really solves the
problem on

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

hi Albert,

On Mon Jul 08, 2013 at 02:32:16PM +0200, Albert ARIBAUD wrote:
 Hi Sughosh,
 
 On Mon, 8 Jul 2013 17:38:46 +0530, Sughosh Ganu
 urwithsugh...@gmail.com wrote:
 
  hi Albert,
  On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:
  
  snip
  
   It you flush first then disable, you leave a time window between the
   two where a write to the cache can happen (either because your code
   does one, or because the compiler optimized one in). If it happens,
   then you disable a cache which is still dirty -- IOW, your flushing
   has failed its mission, and your cache and memory are still not
   coherent.
  
  Since this is specific to arm926ejs, can we not flush *and* invalidate
  the dcache before disabling it -- since the arm926ejs cache uses a
  read allocate policy, flushing and invalidating a cache before
  disabling it would not result in the cache getting written to in the
  window that you refer to. Also, flushing and cleaning is an atomic
  operation.
 
 Invalidating the cache in addition to flushing it would not prevent
 further writes from dirtying the cache lines if they happen before
 the cache is disabled.

I have a doubt on this. The arm926ejs uses a read-allocate policy,
wherein a new cache line is allocated only on a read miss -- a write
to an address not present in the cache gets written to memory. So if
the cache line is invalidated, how will data get written to the cache.

-sughosh

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
 In the recent bootm refactor, the PREP stage was missing in the bootz
 command. This causes unpredictable behaviour.
 
 The use of a local variable means that the reset of cmd_bootm.c does not
 in fact use the same image structure, so remove this.
 
 Also manually set the OS type to Linux, since this is the only possibility
 at present, and we need to select the right boot function.
 
 Signed-off-by: Simon Glass s...@chromium.org

With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]

Starting kernel ...

Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 256MiB ?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] dfu:ext4:fix Fix DFU upload functionality

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/2013 04:59 AM, Sumit Gemini wrote:
 HI Lukasz,
 
 I am using spi nor flash, and may i know the fixes which you
 fixed, and all changes. because i am facing problem only in
 upload.

This means you are not using mainline, as we do not have DFU for SPI.
 Please post it, or hassle your vendor (I suspect I know who it is) to
get the patches posted.  Thanks!

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR2sm9AAoJENk4IS6UOR1WuRUP/iKBpBTUO+hAphWC+kqrjAgn
5z0zQbZNSL4S2eGCdI4ApmVs7uMxavPFf2hukwX4pJal631G8AkAPfgfiYRMYZ3U
iv6mkhwSV0IMxE4zemcZkfABILo+O5+2RlJo7QUvSaNs5c3xNBkdIb20797ORinS
MNi17zYeFph8NDYz/TTcIE0MWLwcH/skW8jabw6skgaeoEa+wUIJTayExe7thTcJ
S1ZuAk6WQ5SKQ5hAdKTjNtPTv35ZK5IFYp1HIKpCiq2RHCUHzuvgdlz60fcbdQSI
9Av9c+9zWO90vEFK+0dT8LkdRylPrGdH/CnRNFep9DKnHUrBPdMGIYN94MRCpIiJ
TWIPD2LvquwJAMeARw9Wak+fnTb/7K1xMN2A+LyRV+N6sRgB46b71lQkE/I5+6E3
QC0RD4pG70gXQSmJfolpwgjdk3NvFuzDGTasjW0e23I6znKivGvTJU56fs4lZ9Mi
jvRk9qeWVL4JrFXVXcvciRUXgaNk3GNymvkJd+QUybh+ZW09NEaLMpBAye9xg80Q
eQd4acdg92P8x7/3avKS8Z2xjWqLvwOPJD8ux2lmEMq6PnVH7bRxHCyW1ZNI4vQk
wc9Gbt0TTFVax0v/lxqtXgpr7y4WqjvQPWh1cTErkELo00tdx95q4xeKvQHl4Oyi
+h/+U2ot7gBB82SfYk+x
=fB83
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

2013-07-08 Thread Robert Nelson

On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
 On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
 In the recent bootm refactor, the PREP stage was missing in the bootz
 command. This causes unpredictable behaviour.

 The use of a local variable means that the reset of cmd_bootm.c does not
 in fact use the same image structure, so remove this.

 Also manually set the OS type to Linux, since this is the only possibility
 at present, and we need to select the right boot function.

 Signed-off-by: Simon Glass s...@chromium.org

 With the whole series applied, I still see a hang at:
 Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]

 Starting kernel ...

 Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
 0x8000 - 256MiB ?


Tom, which board is that?

These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...

Panda (Board file boot)

load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}

Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 161 ms (20.2 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Kernel image @ 0x8200 [ 0x00 - 0x3414a0 ]

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu

Wandboard (device tree boot)

load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
run mmcargs
bootz ${loadaddr} - ${fdt_addr}

Hit any key to stop autoboot:  0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
3464448 bytes read in 249 ms (13.3 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
23571 bytes read in 253 ms (90.8 KiB/s)
= run mmcargs
= bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x1200 [ 0x00 - 0x34dd00 ]

Starting kernel ...
lockup

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling

On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:

 On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
  On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
  In the recent bootm refactor, the PREP stage was missing in the bootz
  command. This causes unpredictable behaviour.
 
  The use of a local variable means that the reset of cmd_bootm.c does not
  in fact use the same image structure, so remove this.
 
  Also manually set the OS type to Linux, since this is the only possibility
  at present, and we need to select the right boot function.
 
  Signed-off-by: Simon Glass s...@chromium.org
 
  With the whole series applied, I still see a hang at:
  Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
 
  Starting kernel ...
 
  Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
  0x8000 - 256MiB ?
 
 
 Tom, which board is that?
 
 These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
 file) works, but Wand (device tree) is still locking up for me...
 
 Panda (Board file boot)
 
 load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
 run mmcargs
 bootz ${loadaddr}

Ah-ha!  It's an appended dtb vs not problem now.  I can boot my
beagelbone with with an appended dtb and bootz, but can't with separate.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/22] net: Add sunxi (Allwinner) wemac driver

On Sun, Nov 25, 2012 at 5:41 AM, Henrik Nordström
hen...@henriknordstrom.net wrote:
 This patch adds support for the WEMAC, the ethernet controller included
 in the Allwinner A10 SoC. It will get used in the upcoming A10 board
 support.

 From: Stefan Roese s...@denx.de
 Signed-off-by: Stefan Roese s...@denx.de
 Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] phy: export genphy_parse_link()

On Tue, Jan 15, 2013 at 4:41 AM, Yegor Yefremov
yegorsli...@googlemail.com wrote:
 On Wed, Nov 28, 2012 at 11:15 AM,  yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver

On Wed, Nov 28, 2012 at 4:15 AM,  yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com

 The driver code was taken from Linux kernel source:
 drivers/net/phy/icplus.c

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] pxe: Use ethact setting for pxe

On Sun, Dec 2, 2012 at 9:00 PM, Rob Herring robherri...@gmail.com wrote:
 From: Rob Herring rob.herr...@calxeda.com

 Get the MAC address using eth_getenv_enetaddr_by_index so that the MAC
 address of ethact is used. This enables using the a NIC other than the
 first one for PXE boot.

 Signed-off-by: Rob Herring rob.herr...@calxeda.com

Applied series, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] pxe: try bootz if bootm fails to find a valid image

On Mon, Dec 3, 2012 at 1:17 PM, Rob Herring robherri...@gmail.com wrote:
 From: Rob Herring rob.herr...@calxeda.com

 Standard pxelinux servers will typically use a zImage rather than u-boot
 image format, so fallback to bootz if bootm fails.

 Signed-off-by: Rob Herring rob.herr...@calxeda.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 07/10] NET: phy: add 88E1310 PHY initialization

On Sun, May 26, 2013 at 1:37 PM, Sascha Silbe t-ub...@infra-silbe.de wrote:
 From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

 This adds PHY initialization for Marvell Alaska 88E1310 PHY.

 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 08/10] NET: mvgbe: add phylib support

On Sun, May 26, 2013 at 1:37 PM, Sascha Silbe t-ub...@infra-silbe.de wrote:
 From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

 This add phylib support to the Marvell GBE driver.

 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Acked-by: Prafulla Wadaskar prafu...@marvell.com
 Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

On 07/08/2013 07:25 AM, Vivek Gautam wrote:
 On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
 On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 07/01/2013 07:49 AM, Vivek Gautam wrote:
 On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
 (Sorry to those on to/cc; I'm resending this so it goes to the correct
 mailing list)

 Dear Stephen,
 sorry for the delay in responding to this.

 Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
 regression on Tegra systems.

 The first time usb start is executed, it appears to work correctly.
 However, any subsequent time it is executed, it takes a long time, and
 eventually fails to find any USB devices.
...
 BUMP? Vivek, any ideas? Otherwise I'm reverting this.
...
 There's one BUG that i could see in  0bf796f  commit.
 Now that we parallelized the sequence to power cycle ports, so if
 get_port_status for any port failed,
 it returns from hub_power_on() and not power-on any of the port.

 Below is the change i suggest.
...
 can you please confirm if you problem is related to this BUG in the
 sequence of power-cycling the ports.

 I applied that change, and it does not solve the problem on Tegra, nor
 do I see any of the messages that were changed from debug to printf.
...
 seaboard which i can see has 3 controllers.

 Vivek, what do I have to revert to fix this flub? I will do that now, since 
 this
 discussion is stalled.
 
 0bf796f usb: hub: Parallelize power-cycling of root-hub ports
 020bbcb usb: hub: Power-cycle on root-hub ports
 
 Above two patches are the one which changed the hub_power_on() functionality.
 If Stephen can confirm that reverting these patches really solves the
 problem on Tegra,
 we can revert them.

Yes, I have been reverting those two commits locally for a while, and it
solves the problem for me.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/10] NET: mvgbe: add support for Dove

On Tue, Dec 4, 2012 at 2:32 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
 Marvell Dove also uses mvgbe as ethernet driver, therefore add support
 for Dove to reuse the current driver.

 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: nfs: add dynamic wait period

On Tue, Dec 11, 2012 at 12:14 PM, Matthias Brugger
matthias@gmail.com wrote:
 This patch tackles the time out problem which leads to break the
 boot process, when loading file over nfs. The patch does two things.

 First of all, we just ignore messages that arrive with a rpc_id smaller
 then the client id. We just interpret this messages as answers to
 formaly timed out messages.

 Second, when a time out occurs we double the time to wait, so that we
 do not stress the server resending the last message.

 Signed-off-by: Matthias Brugger matthias@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] net/designware: Do not select MIIPORT for RGMII interface

On Thu, Dec 13, 2012 at 5:52 AM, Vipin Kumar vipin.ku...@st.com wrote:
 Do not select MIIPORT for RGMII interface

 Signed-off-by: Vipin Kumar vipin.ku...@st.com
 Acked-by: Stefan Roese s...@denx.de

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] net/macb: Add arch specific routine to get mdio control

On Thu, Dec 13, 2012 at 5:52 AM, Vipin Kumar vipin.ku...@st.com wrote:
 From: Shiraz Hashim shiraz.has...@st.com

 SPEAr310 and SPEAr320 Ethernet interfaces share same MDIO lines to control 
 their
 respective phys. Currently there is a fixed configuration in which only a
 particular MAC can use the MDIO lines.

 Call an arch specific function to take control of specific mdio lines at
 runtime.

 Signed-off-by: Shiraz Hashim shiraz.has...@st.com
 Signed-off-by: Vipin Kumar vipin.ku...@st.com
 Acked-by: Stefan Roese s...@denx.de

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] net: make IPaddr type big endian

On Wed, Jan 16, 2013 at 6:09 PM, Kim Phillips
kim.phill...@freescale.com wrote:
 for use with sparse.

 Signed-off-by: Kim Phillips kim.phill...@freescale.com
 Cc: Joe Hershberger joe.hershber...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] net/tftp: sparse fixes

On Wed, Jan 16, 2013 at 6:09 PM, Kim Phillips
kim.phill...@freescale.com wrote:
 tftp.c:464:17: warning: cast to restricted __be16
 tftp.c:552:29: warning: cast to restricted __be16
 tftp.c:640:33: warning: cast to restricted __be16
 tftp.c:642:25: warning: cast to restricted __be16

 Signed-off-by: Kim Phillips kim.phill...@freescale.com
 Cc: Joe Hershberger joe.hershber...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v2] PHY: micrel.c: add support for KSZ9031

On Wed, Feb 6, 2013 at 3:18 PM, David Andrey david.and...@netmodule.com wrote:
 Add support for Micrel PHY KSZ9031 in phylib,
 including small rework for KSZ9021 to avoid
 code duplication

 Signed-off-by: David Andrey david.and...@netmodule.com
 Cc: Troy Kisky troy.ki...@boundarydevices.com
 Cc: Joe Herschberger joe.hershber...@gmail.com
 Cc: Andy Fleming aflem...@freescale.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Correct check for link-local target IP conflict

On Fri, Feb 8, 2013 at 2:18 PM, Joe Hershberger joe.hershber...@ni.com wrote:
 Make the link-local code conform more completely with the RFC.

 This will prevent ARP queries for the target (such as while it is
 rebooting) from causing the device to choose a different link-local
 address, thinking that its address is in use by another machine.

 Signed-off-by: Joe Hershberger joe.hershber...@ni.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] add support for Xilinx 1000BASE-X phy (GTX)

On Thu, Feb 21, 2013 at 7:25 AM, Charles Coldwell coldw...@gmail.com wrote:
 commit 39695029bc15041c809df3db4ba19bd729c447fa
 Author: Charles Coldwell coldw...@ll.mit.edu
 Date:   Tue Feb 19 08:27:33 2013 -0500

 Changes to support the Xilinx 1000BASE-X phy (GTX/MGT)

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] phylib: Add Atheros AR8035 GETH PHY support

On Wed, Apr 10, 2013 at 3:23 AM, Xie Xiaobo x@freescale.com wrote:
 Signed-off-by: Xie Xiaobo x@freescale.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch v2 0/3] Enable network support on at91sam9n12ek board

On Tue, Apr 23, 2013 at 9:46 PM, Bo Shen voice.s...@atmel.com wrote:
 This patch set based on the following patch set:
   - arm: at91: add at91sam9n12ek board support
 - http://patchwork.ozlabs.org/patch/237184/

 And implement the following things
   - add ignore for network block comment style checking
   - add ks8851_16mll ethernet driver
   - Enable network support on at91sam9n12ek board.

 Bo Shen (2):
   checkpatch: add ignore for network block comment style checking
   ARM: at91sam9n12: add network support with ksz8851_16mll

 Roberto Cerati (1):
   net: ks8851_mll: add ethernet support

Applied series, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: phy: supplement support for Micrel's KSZ9031

On Tue, Apr 30, 2013 at 9:57 AM, SARTRE Leo lsar...@adeneo-embedded.com wrote:
 Add function ksz9031_phy_extended_write and ksz9031_phy_extended_read

 Signed-off-by: Leo Sartre lsar...@adeneo-embedded.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] net: add Faraday FTMAC110 10/100Mbps ethernet support

On Tue, May 7, 2013 at 1:33 AM, Kuo-Jung Su dant...@gmail.com wrote:
 From: Kuo-Jung Su dant...@faraday-tech.com

 Faraday FTMAC110 10/100Mbps supports half-word data transfer for Linux.
 However it has a weird DMA alignment issue:

 (1) Tx DMA Buffer Address:
 1 bytes aligned: Invalid
 2 bytes aligned: O.K
 4 bytes aligned: O.K

 (2) Rx DMA Buffer Address:
 1 bytes aligned: Invalid
 2 bytes aligned: O.K
 4 bytes aligned: Invalid!!!

 Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
 CC: Joe Hershberger joe.hershber...@gmail.com
 CC: Tom Rini tr...@ti.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] net: update FTGMAC100 for MMU/D-cache support

On Tue, May 7, 2013 at 1:33 AM, Kuo-Jung Su dant...@gmail.com wrote:
 From: Kuo-Jung Su dant...@faraday-tech.com

 Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
 CC: Joe Hershberger joe.hershber...@gmail.com
 CC: Tom Rini tr...@ti.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/5] am335x_evm: Correct DFU ALT settings for falcon mode

Now that we have falcon mode enabled, the partiton numbers for NAND have
changed, and we need to list entries for updating these parts of the
system.  While adding falcon mode entires for eMMC (raw), we round up
the limit on U-Boot for ease of math later.

Signed-off-by: Tom Rini tr...@ti.com
---
 include/configs/am335x_evm.h |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index c5a6d4b..b974d1b 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -238,7 +238,11 @@
rootfs part 0 2; \
MLO fat 0 1; \
MLO.raw mmc 100 100; \
-   u-boot.img.raw mmc 300 3C0; \
+   u-boot.img.raw mmc 300 400; \
+   spl-os-args.raw mmc 80 80; \
+   spl-os-image.raw mmc 900 2000; \
+   spl-os-args fat 0 1; \
+   spl-os-image fat 0 1; \
u-boot.img fat 0 1; \
uEnv.txt fat 0 1
 #define DFU_ALT_INFO_NAND \
@@ -247,8 +251,9 @@
SPL.backup2 part 0 3; \
SPL.backup3 part 0 4; \
u-boot part 0 5; \
-   kernel part 0 7; \
-   rootfs part 0 8
+   u-boot-spl-os part 0 6; \
+   kernel part 0 8; \
+   rootfs part 0 9
 
  /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS   1   /*  1 bank of DRAM */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/5] am335x_evm: Correct CONFIG_CMD_SPL_WRITE_SIZE

We use CONFIG_CMD_SPL_WRITE_SIZE when reading/writing the args portion
of falcon mode to NAND.  Previously it was half the size of the
eraseblock which is too small, increase to eraseblock size.

Signed-off-by: Tom Rini tr...@ti.com
---
 include/configs/am335x_evm.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d60f732..0f12c75 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -344,7 +344,7 @@
 /* nand */
 #define CONFIG_CMD_SPL_NAND_OFS0x24 /* end of 
u-boot */
 #define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x28
-#define CONFIG_CMD_SPL_WRITE_SIZE  0x1000
+#define CONFIG_CMD_SPL_WRITE_SIZE  0x2000
 
 /* spl export command */
 #define CONFIG_CMD_SPL
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/5] README.falcon: Note how we determine if we can boot the OS or not

Reviewed-by: Peter Korsgaard jac...@sunsite.dk
Signed-off-by: Tom Rini tr...@ti.com
---
 doc/README.falcon |2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/README.falcon b/doc/README.falcon
index 93e855d..6357b1e 100644
--- a/doc/README.falcon
+++ b/doc/README.falcon
@@ -41,6 +41,8 @@ file (CONFIG_CMD_SPL_NAND_OFS for NAND).
 
 3. Boot the board into Falcon Mode. SPL will load the kernel and copy
 the parameters which are saved in the persistent area to the required address.
+If a valid uImage is not found at the defined location, U-Boot will be
+booted instead.
 
 It is required to implement a custom mechanism to select if SPL loads U-Boot
 or another image.
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 3/5] am335x_evm: Update eMMC falcon mode locations

The previous location used for the args portion of falcon mode was too
small to allow for a device tree to be saved there, so move the location
slightly and increase the size.  In addition, our previous kernel
location was part of the area we set aside for U-Boot itself, so move it
up a bit higher.

Signed-off-by: Tom Rini tr...@ti.com
---
 include/configs/am335x_evm.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index b974d1b..d60f732 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -337,9 +337,9 @@
 #define CONFIG_SYS_SPL_ARGS_ADDR   (PHYS_DRAM_1 + 0x100)
 
 /* raw mmc */
-#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x500 /* address 
0xa */
-#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR  0x8   /* address 0x1000 */
-#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 8 /* 4KB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x900   /* address 
0x12 */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR  0x80/* address 0x1 */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS 0x80/* 64KiB */
 
 /* nand */
 #define CONFIG_CMD_SPL_NAND_OFS0x24 /* end of 
u-boot */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] net: macb: add support for gigabit MAC

On Wed, Apr 24, 2013 at 2:59 AM, Bo Shen voice.s...@atmel.com wrote:
 This patch add macb support for gigabit MAC, will be used by sama5d3.
 Tha patch for sama5d3 is in patchwork:
   http://patchwork.ozlabs.org/patch/226795/

 After this patch is applied, will add gmac support for sama5d3

 Bo Shen (3):
   net: macb: using AT91FAMILY replace #ifdeferry
   net: macb: using phylib to configure phy device
   net: macb: add support for gigabit MAC

Applied series, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/22] net: Add sunxi (Allwinner) wemac driver

On Mon, Jul 08, 2013 at 10:43:03AM -0500, Joe Hershberger wrote:
 On Sun, Nov 25, 2012 at 5:41 AM, Henrik Nordstr?m
 hen...@henriknordstrom.net wrote:
  This patch adds support for the WEMAC, the ethernet controller included
  in the Allwinner A10 SoC. It will get used in the upcoming A10 board
  support.
 
  From: Stefan Roese s...@denx.de
  Signed-off-by: Stefan Roese s...@denx.de
  Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
 
 Applied, Thanks.

Hold up here Joe, the rest of the Allwinner code isn't in yet.  I'm
hoping for a resubmission from Henrik soon :)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot + libtomcrypt

2013-07-08 Thread Andreas Bießmann

Hi André,

On 08.07.13 10:28, André Schaller wrote:
 Hi there,
 
 I want to add some Random Number Generation functions / Hashing
 Functions to u-boot. I implemented the functionality and now I need to
 include it to the upstream source code of u-boot (inside
 hwinit-common.c). I was wondering if these even works? Is this lib small
 enough to fit in the MLO? 

dunno ...

 Can I adjust the size of the MLO if it is too
 large? 

Yes you can, but have to respect physical limits ;) The SPL needs to fit
into the SRAM!
There is a pre-defined border for build-time checks (at least on ARM -
CONFIG_SPL_MAX_SIZE) and some tools to investigate runtime behavior
(*.su files - read README.SPL 'estimating stack usage').

 Did anyone tried to do this before and could share experiences?

I pulled the software implementation of BCH in SPL to have second NAND
sector secured by BCH8 on OMAP3 devices (which have no ELM). It worked
on board tricorder and devkit8000 but I had to increase the
CONFIG_SPL_MAX_SIZE (AFAIR).

Regards,

Andreas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] phylib: add atheros ar803x phy

On Tue, Jun 4, 2013 at 3:58 AM, Heiko Schocher h...@denx.de wrote:
 add atheros ar803x phy, used on the upcoming siemens boards.

 Signed-off-by: Heiko Schocher h...@denx.de
 Cc: Andy Fleming aflem...@freescale.com
 Cc: Joe Hershberger joe.hershber...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] phylib: add natsemi dp83630 phy

On Tue, Jun 4, 2013 at 3:58 AM, Heiko Schocher h...@denx.de wrote:
 add natsemi dp83630 phy, used on the upcoming siemens boards.

 Signed-off-by: Heiko Schocher h...@denx.de
 Cc: Andy Fleming aflem...@freescale.com
 Cc: Joe Hershberger joe.hershber...@gmail.com

Applied, Thanks.
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2] socfpga: Move board/socfpga_cyclone5 to board/socfpga

2013-07-08 Thread Dinh Nguyen

Hi Albert,

On Fri, 2013-07-05 at 23:04 +0200, ZY - albert.u.boot wrote:
 Hi dingu...@altera.com,
 
 On Tue, 2 Jul 2013 17:00:18 -0500, dingu...@altera.com wrote:
 
  From: Dinh Nguyen dingu...@altera.com
  
  Because the SOCFPGA platform will include support for Cyclone V and
  Arria V FPGA parts, renaming socfpga_cyclone5 folder to socfpga to
  be more generic.
  
  Signed-off-by: Dinh Nguyen dingu...@altera.com
  Reviewed-by: Pavel Machek pa...@denx.de
  Cc: Chin Liang See cl...@altera.com
  Cc: Wolfgang Denk w...@denx.de
  CC: Pavel Machek pa...@denx.de
  Cc: Tom Rini tr...@ti.com
  
  v2:
  - Add Reviewed-by: Pavel Machek
  - Cc: Tom Rini
  ---
 
 Do you really mean that V2 is the exact same code as V1? If it is, then
 V2 is unneeded. And if V2 is different from V1, then history should
 tells us the difference(s).

V2 is the same as v1 codewise. So should I resend this a V1 to be
applied?

Dinh
 
 Amicalement,



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/22] net: Add sunxi (Allwinner) wemac driver

Hi Tom,

On Mon, Jul 8, 2013 at 11:16 AM, Tom Rini tr...@ti.com wrote:
 On Mon, Jul 08, 2013 at 10:43:03AM -0500, Joe Hershberger wrote:
 On Sun, Nov 25, 2012 at 5:41 AM, Henrik Nordstr?m
 hen...@henriknordstrom.net wrote:
  This patch adds support for the WEMAC, the ethernet controller included
  in the Allwinner A10 SoC. It will get used in the upcoming A10 board
  support.
 
  From: Stefan Roese s...@denx.de
  Signed-off-by: Stefan Roese s...@denx.de
  Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net

 Applied, Thanks.

 Hold up here Joe, the rest of the Allwinner code isn't in yet.  I'm
 hoping for a resubmission from Henrik soon :)

I didn't realize that when I was processing all my assigned patches in
patchwork.  I guess you can revert the this patch before accepting his
new series.

I've noticed that several of the patches I applied in the last PR had
been superseded, but were delegated to other people, so I didn't see
them.  I guess we need to figure out who should be delegated such
patches and do so consistently.

Apologies,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/5] Improve falcon mode and am335x_evm docs

Hey all, 
 
The following 5 patches update docs for falcon mode, and am335x_evm. The
first adds a quick general note about how failure is decided in falcon mode
and we drop back to U-Boot. The rest update slightly, and then document,
falcon mode for am335x_evm by providing examples for eMMC or raw SD cards,
FAT SD cards and NAND and provide some general information setting up
falcon mode. In the updates side, the DFU info to be able to write the
falcon mode areas is added and corrects a small bug in the NAND
configuration for falcon mode. I did this in part because while I found
doc/README.falcon helpful we still want to provide board-specific examples
when possible I believe. 
 
And, as has been pointed out to me on IRC, this isn't a huge boot time win 
(and may be a loss) until we have dcache configured correctly. This is on 
my TODO list, but a separate patch. 

Changes in v2:
- Add Peter's Reviewed-by to #1
- Split the previous #2 into 4 patches

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 5/5] am335x_evm: Add basic README

Add a README for the family of boards the am335x_evm covers, and include
instructions on preparing and using falcon mode, for various media.

Signed-off-by: Tom Rini tr...@ti.com
---
 board/ti/am335x/README |  113 
 1 file changed, 113 insertions(+)
 create mode 100644 board/ti/am335x/README

diff --git a/board/ti/am335x/README b/board/ti/am335x/README
new file mode 100644
index 000..ccc5e16
--- /dev/null
+++ b/board/ti/am335x/README
@@ -0,0 +1,113 @@
+Summary
+===
+
+This document covers various features of the 'am335x_evm' build, and some of
+the related build targets (am335x_evm_uartN, etc).
+
+Hardware
+
+
+The binary produced by this board supports, based on parsing of the EEPROM
+documented in TI's reference designs:
+- AM335x GP EVM
+- AM335x EVM SK
+- Beaglebone White
+- Beaglebone Black
+
+Falcon Mode
+===
+
+The default build includes Falcon Mode (see doc/README.falcon) via NAND,
+eMMC (or raw SD cards) and FAT SD cards.  Our default behavior currently is
+to read a 'c' on the console while in SPL at any point prior to loading the
+OS payload (so as soon as possible) to opt to booting full U-Boot.  Also
+note that while one can program Falcon Mode in place great care needs to
+be taken by the user to not 'brick' their setup.  As these are all eval
+boards with multiple boot methods, recovery should not be an issue in this
+worst-case however.
+
+Falcon Mode: eMMC
+=
+
+The recommended layout in this case is:
+
+MMC BLOCKS  || LOCATION IN BYTES
+0x - 0x007F : MBR or GPT table   : 0x00 - 0x02
+0x0080 - 0x00FF : ARGS or FDT file   : 0x01 - 0x02
+0x0100 - 0x01FF : SPL.backup1 (first copy used)  : 0x02 - 0x04
+0x0200 - 0x02FF : SPL.backup2 (second copy used) : 0x04 - 0x06
+0x0300 - 0x06FF : U-Boot : 0x06 - 0x0e
+0x0700 - 0x08FF : U-Boot Env + Redundant : 0x0e - 0x12
+0x0900 - 0x28FF : Kernel : 0x12 - 0x52
+
+Note that when we run 'spl export' it will prepare to boot the kernel.
+This includes relocation of the uImage from where we loaded it to the entry
+point defined in the header.  As these locations overlap by default, it
+would leave us with an image that if written to MMC will not boot, so
+instead of using the loadaddr variable we use 0x8100 in the following
+example.  In this example we are loading from the network, for simplicity,
+and assume a valid partition table already exists and 'mmc dev' has already
+been run to select the correct device.  Also note that if you previously
+had a FAT partition (such as on a Beaglebone Black) it is not enough to
+write garbage into the area, you must delete it from the partition table
+first.
+
+# Ensure we are able to talk with this mmc device
+U-Boot # mmc rescan
+U-Boot # tftp 8100 am335x/MLO
+# Write to two of the backup locations ROM uses
+U-Boot # mmc write 8100 100 100
+U-Boot # mmc write 8100 200 100
+# Write U-Boot to the location set in the config
+U-Boot # tftp 8100 am335x/u-boot.img
+U-Boot # mmc write 8100 300 400
+# Load kernel and device tree into memory, perform export
+U-Boot # tftp 8100 am335x/uImage
+U-Boot # run findfdt
+U-Boot # tftp ${fdtaddr} am335x/${fdtfile}
+U-Boot # run mmcargs
+U-Boot # spl export fdt 8100 - ${fdtaddr}
+# Write the updated device tree to MMC
+U-Boot # mmc write ${fdtaddr} 80 80
+# Write the uImage to MMC
+U-Boot # mmc write 8100 900 2000
+
+Falcon Mode: FAT SD cards
+=
+
+In this case the additional file is written to the filesystem.  In this
+example we assume that the uImage and device tree to be used are already on
+the FAT filesystem (only the uImage MUST be for this to function
+afterwards) along with a Falcon Mode aware MLO and the FAT partition has
+already been created and marked bootable:
+
+U-Boot # mmc rescan
+# Load kernel and device tree into memory, perform export
+U-Boot # load mmc 0:1 ${loadaddr} uImage
+U-Boot # run findfdt
+U-Boot # load mmc 0:1 ${fdtaddr} ${fdtfile}
+U-Boot # run mmcargs
+U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
+
+This will print a number of lines and then end with something like:
+   Using Device Tree in place at 80f8, end 80f85928
+   Using Device Tree in place at 80f8, end 80f88928
+So then you:
+
+U-Boot # fatwrite mmc 0:1 0x80f8 args 8928
+
+Falcon Mode: NAND
+=
+
+In this case the additional data is written to another partition of the
+NAND.  In this example we assume that the uImage and device tree to be are
+already located on the NAND somewhere (such as fileystem or mtd partition)
+along with a Falcon Mode aware MLO written to the correct locations for
+booting and mtdparts have been configured correctly for the board:
+
+U-Boot # nand read ${loadaddr} kernel
+U-Boot # load nand rootfs ${fdtaddr}

[U-Boot] [PATCH 1/2] Revert usb: hub: Parallelize power-cycling of root-hub ports

This reverts commit 0bf796f7ae22086f0504f3297e9fb4e96aa04161.

This commit causes breakage of the EHCI, where on Tegra it is not
possible to run usb reset twice as it results in the board hang.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Vivek Gautam gautamvivek1...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
---
 common/usb_hub.c |   19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 774ba63..dd2056a 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -109,22 +109,19 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
int ret;
 
dev = hub-pusb_dev;
-
-   /*
-* Enable power to the ports:
-* Here we Power-cycle the ports: aka,
-* turning them off and turning on again.
-*/
+   /* Enable power to the ports */
debug(enabling power on all ports\n);
for (i = 0; i  dev-maxchild; i++) {
+   /*
+* Power-cycle the ports here: aka,
+* turning them off and turning on again.
+*/
usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug(port %d returns %lX\n, i + 1, dev-status);
-   }
 
-   /* Wait at least 2*bPwrOn2PwrGood for PP to change */
-   mdelay(pgood_delay);
+   /* Wait at least 2*bPwrOn2PwrGood for PP to change */
+   mdelay(pgood_delay);
 
-   for (i = 0; i  dev-maxchild; i++) {
ret = usb_get_port_status(dev, i + 1, portsts);
if (ret  0) {
debug(port %d: get_port_status failed\n, i + 1);
@@ -145,9 +142,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
debug(port %d: Port power change failed\n, i + 1);
return;
}
-   }
 
-   for (i = 0; i  dev-maxchild; i++) {
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug(port %d returns %lX\n, i + 1, dev-status);
}
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] Revert usb: hub: Power-cycle on root-hub ports

This reverts commit 020bbcb76b5be0d5406d2ae7c26dbdb013ead812.

This commit causes breakage of the EHCI, where on Tegra it is not
possible to run usb reset twice as it results in the board hang.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Vivek Gautam gautamvivek1...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
---
 common/usb_hub.c |   34 --
 1 file changed, 34 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index dd2056a..c40ea2f 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -104,45 +104,11 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
int i;
struct usb_device *dev;
unsigned pgood_delay = hub-desc.bPwrOn2PwrGood * 2;
-   ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
-   unsigned short portstatus;
-   int ret;
 
dev = hub-pusb_dev;
/* Enable power to the ports */
debug(enabling power on all ports\n);
for (i = 0; i  dev-maxchild; i++) {
-   /*
-* Power-cycle the ports here: aka,
-* turning them off and turning on again.
-*/
-   usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
-   debug(port %d returns %lX\n, i + 1, dev-status);
-
-   /* Wait at least 2*bPwrOn2PwrGood for PP to change */
-   mdelay(pgood_delay);
-
-   ret = usb_get_port_status(dev, i + 1, portsts);
-   if (ret  0) {
-   debug(port %d: get_port_status failed\n, i + 1);
-   return;
-   }
-
-   /*
-* Check to confirm the state of Port Power:
-* xHCI says After modifying PP, s/w shall read
-* PP and confirm that it has reached the desired state
-* before modifying it again, undefined behavior may occur
-* if this procedure is not followed.
-* EHCI doesn't say anything like this, but no harm in keeping
-* this.
-*/
-   portstatus = le16_to_cpu(portsts-wPortStatus);
-   if (portstatus  (USB_PORT_STAT_POWER  1)) {
-   debug(port %d: Port power change failed\n, i + 1);
-   return;
-   }
-
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug(port %d returns %lX\n, i + 1, dev-status);
}
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

Dear Stephen Warren,

 On 07/08/2013 07:25 AM, Vivek Gautam wrote:
  On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
  On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.org 
wrote:
  On 07/01/2013 07:49 AM, Vivek Gautam wrote:
  On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
  (Sorry to those on to/cc; I'm resending this so it goes to the
  correct mailing list)
  
  Dear Stephen,
  sorry for the delay in responding to this.
  
  Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
  regression on Tegra systems.
  
  The first time usb start is executed, it appears to work
  correctly. However, any subsequent time it is executed, it takes a
  long time, and eventually fails to find any USB devices.
 
 ...
 
  BUMP? Vivek, any ideas? Otherwise I'm reverting this.
 
 ...
 
  There's one BUG that i could see in  0bf796f  commit.
  Now that we parallelized the sequence to power cycle ports, so if
  get_port_status for any port failed,
  it returns from hub_power_on() and not power-on any of the port.
  
  Below is the change i suggest.
 
 ...
 
  can you please confirm if you problem is related to this BUG in the
  sequence of power-cycling the ports.
  
  I applied that change, and it does not solve the problem on Tegra, nor
  do I see any of the messages that were changed from debug to printf.
 
 ...
 
  seaboard which i can see has 3 controllers.
  
  Vivek, what do I have to revert to fix this flub? I will do that now,
  since this discussion is stalled.
  
  0bf796f usb: hub: Parallelize power-cycling of root-hub ports
  020bbcb usb: hub: Power-cycle on root-hub ports
  
  Above two patches are the one which changed the hub_power_on()
  functionality. If Stephen can confirm that reverting these patches
  really solves the problem on Tegra,
  we can revert them.
 
 Yes, I have been reverting those two commits locally for a while, and it
 solves the problem for me.

Reverted, please test u-boot-usb/master .

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Run a standalone application on a core other than 0

2013-07-08 Thread João Fernandes

Thank you Scott. On a somehow related question, when I use cpu X release
to run some code on a core other than 0, the changes to memory made by cpu
X are not made visible globally. I believe this is connected with WIMGE
bits - as soon as disable L1 and L2 it works fine - am I correct? If so,
does core 0 have 0x - 0x3FFF and 0x4000 - 0x7FFF TLB
entries marked as cache coherent, or do I also have to set them for it?

João

On Tue, Jul 2, 2013 at 11:11 PM, Scott Wood scottw...@freescale.com wrote:

 On 07/02/2013 07:02:21 AM, João Fernandes wrote:

 As the subject says, I'm trying to run the Hello world standalone
 application example on a core other than 0, on a Freescale QorIQ P4080.

 I tried through the shell and programmatically by exporting cpu_release
 function... nothing. My first thought was that only core 0 has register r2
 with the address of the global_data structure, so I tried to set it on
 the other cores, but still nothing. Help on this matter is highly
 appreciated.


 If you mean a U-Boot application, this is not supported.  U-Boot doesn't
 run on cores other than 0, except for a small stub for the spin table code.

 If you have true standalone code, you can release it on other CPUs using
 the cpu n release command.  That code will not have access to any
 U-Boot functionality.  Its entry state will be as described for secondary
 CPUs in ePAPR.  It will be the same as if an OS were spinning up its
 secondary cores by writing directly to the spin table.

 -Scott

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Porting ehci-exynos.c to handle exynos4412 (odroid-u2)

2013-07-08 Thread Suriyan Ramasami

Hello Lukasz,
Thanks for your response. I guess I was not very clear with my question.

u-boot code already exists for the odroid-u2 (that is what it uses).
Unfortunately, it does not have USB support. I am looking at just adding
the EHCI and USB (uses a 3503A) part of the code.

I checked the TRATS2 patch and it too does not have any code that
touches the USB part of things.

Thanks
- Suriyan

On Sun, Jul 7, 2013 at 11:56 PM, Lukasz Majewski l.majew...@samsung.comwrote:

On Sun, 07 Jul 2013 02:15:17 -0700, Suriyan Ramasami wrote:

Hi Suriyan,

Hi wonderful folks!

I own an odroid-u2 and the u-boot that comes with it does not
have usb support. Its configuration is smdk4412 and I do not find
that in the u-boot sources. I see it in the arndale and harkernel
branches.

I do see that usb support was added to the arndale platform -
which is exynos5 based. Is it easy to port it for exynos4412?

Patches for Exynos4412 based board (TRATS2) were already sent on the
mailing list:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/161578/match=introduce+samsung's+new+board+trats2

Please refer to them. It shall be relatively easy to add odroid-u2
support based on TRATS2.

I did try it porting on my own accord and am listing it below...

I seem to be hitting issues in drivers/usb/host/ehci-exynos.c -
function setup_usb_phy(struct exynos_usb_phy *usb).
Would passing the correct address of usb for the exynos4412 do the
trick? If so what should it be?
In this same file ehci_hcd_init() uses gpio-x3 and gpio-d1. In
exynos4 looks like x3 is from gpio_part2. Also, do the d1 and x3
translate to the same gpiod1 and gpiox3 in the exynos4412?

Furthermore, ehci-exynos.c uses functions from
arch/arm/cpu/armv7/exynos/system.c which for the most part are
exynos5 oriented and do nothing for exynos4.

Can someone guide me as to what I could do, or some pointers to
helpful docs? I do have the Exynos 4412 user manual.

Thanks
- Suriyan

--
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

On 07/08/2013 11:03 AM, Marek Vasut wrote:
 Dear Stephen Warren,
 
 On 07/08/2013 07:25 AM, Vivek Gautam wrote:
 On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
 On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 07/01/2013 07:49 AM, Vivek Gautam wrote:
 On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
 (Sorry to those on to/cc; I'm resending this so it goes to the
 correct mailing list)

 Dear Stephen,
 sorry for the delay in responding to this.

 Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
 regression on Tegra systems.
...
 Vivek, what do I have to revert to fix this flub? I will do that now,
 since this discussion is stalled.

 0bf796f usb: hub: Parallelize power-cycling of root-hub ports
 020bbcb usb: hub: Power-cycle on root-hub ports

 Above two patches are the one which changed the hub_power_on()
 functionality. If Stephen can confirm that reverting these patches
 really solves the problem on Tegra,
 we can revert them.

 Yes, I have been reverting those two commits locally for a while, and it
 solves the problem for me.
 
 Reverted, please test u-boot-usb/master .

Well, it works, but it turns out the reverts aren't needed. Simon Glass
already found the problem, and fixed it with:

ed10e66 usb: Correct CLEAR_FEATURE code in ehci-hcd

Sorry for not noticing this earlier, but since there hadn't been any
news in this thread, and there weren't any relevant changes to the
power-cycling code affected by the problematic patches, it didn't occur
to me that the problem may have already been fixed elsewhere, so I
didn't ever retest the issue with a newer commit than that one where I
originally found the problem:-(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] NET: Improve TFTP booting performance when CONFIG_USB_KEYBOARD

On 07/03/2013 10:01 PM, Jim Lin wrote:
 TFTP booting is slow when a USB keyboard is installed and
 CONFIG_USB_KEYBOARD is defined.
 This fix is to change Ctrl-C polling to every second when NET transfer
 is running.

Building this generates:

net.c: In function ‘NetLoop’:
net.c:486:6: warning: ‘ctrlc_t_start’ may be used uninitialized in this
function [-Wmaybe-uninitialized]

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Run a standalone application on a core other than 0

2013-07-08 Thread Scott Wood


On 07/08/2013 12:22:03 PM, João Fernandes wrote:
Thank you Scott. On a somehow related question, when I use cpu X  
release
to run some code on a core other than 0, the changes to memory made  
by cpu
X are not made visible globally. I believe this is connected with  
WIMGE
bits - as soon as disable L1 and L2 it works fine - am I correct? If  
so,
does core 0 have 0x - 0x3FFF and 0x4000 - 0x7FFF  
TLB
entries marked as cache coherent, or do I also have to set them for  
it?


You need to set the M bit in all TLB entries that reference memory that  
is shared.  U-Boot already does this, but perhaps the code you're  
running on the secondary CPU does not?  Is U-Boot still running on core  
0 at that point?


Also be sure you're using the proper memory barriers to ensure that  
changes are seen in the right order.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2 V2] PPC MPC83xx: Fix MPC8323ERDB build warning

2013-07-08 Thread Wolfgang Denk

Fix:

mpc8323erdb.c: In function 'mac_read_from_eeprom':
mpc8323erdb.c:198:3: warning: dereferencing type-punned pointer will
break strict-aliasing rules [-Wstrict-aliasing]

Signed-off-by: Wolfgang Denk w...@denx.de
cc: Timur Tabi ti...@tabi.org
cc: Kim Phillips kim.phill...@freescale.com
---
V2: use uint32_t for crc_buf to make sure we always get exactly
32 bit; thanks to Timur Tabi for pointing out.

 board/freescale/mpc8323erdb/mpc8323erdb.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mpc8323erdb/mpc8323erdb.c 
b/board/freescale/mpc8323erdb/mpc8323erdb.c
index f29b2f4..533cb08 100644
--- a/board/freescale/mpc8323erdb/mpc8323erdb.c
+++ b/board/freescale/mpc8323erdb/mpc8323erdb.c
@@ -195,7 +195,11 @@ int mac_read_from_eeprom(void)
printf(\nEEPROM @ 0x%02x read FAILED!!!\n,
   CONFIG_SYS_I2C_EEPROM_ADDR);
} else {
-   if (crc32(crc, buf, 24) == *(unsigned int *)buf[24]) {
+   uint32_t crc_buf;
+
+   memcpy(crc_buf, buf[24], sizeof(unsigned int));
+
+   if (crc32(crc, buf, 24) == crc_buf) {
printf(Reading MAC from EEPROM\n);
for (i = 0; i  4; i++) {
if (memcmp(buf[i * 6], \0\0\0\0\0\0, 6)) {
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2 V2] PPC MPC83xx: Fix MPC8323ERDB build warning

2013-07-08 Thread Wolfgang Denk

Fix:

mpc8323erdb.c: In function 'mac_read_from_eeprom':
mpc8323erdb.c:198:3: warning: dereferencing type-punned pointer will
break strict-aliasing rules [-Wstrict-aliasing]

Signed-off-by: Wolfgang Denk w...@denx.de
cc: Timur Tabi ti...@tabi.org
cc: Kim Phillips kim.phill...@freescale.com
---
V2: use uint32_t for crc_buf to make sure we always get exactly
32 bit; thanks to Timur Tabi for pointing out.

 board/freescale/mpc8323erdb/mpc8323erdb.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mpc8323erdb/mpc8323erdb.c 
b/board/freescale/mpc8323erdb/mpc8323erdb.c
index f29b2f4..533cb08 100644
--- a/board/freescale/mpc8323erdb/mpc8323erdb.c
+++ b/board/freescale/mpc8323erdb/mpc8323erdb.c
@@ -195,7 +195,11 @@ int mac_read_from_eeprom(void)
printf(\nEEPROM @ 0x%02x read FAILED!!!\n,
   CONFIG_SYS_I2C_EEPROM_ADDR);
} else {
-   if (crc32(crc, buf, 24) == *(unsigned int *)buf[24]) {
+   uint32_t crc_buf;
+
+   memcpy(crc_buf, buf[24], sizeof(unsigned int));
+
+   if (crc32(crc, buf, 24) == crc_buf) {
printf(Reading MAC from EEPROM\n);
for (i = 0; i  4; i++) {
if (memcmp(buf[i * 6], \0\0\0\0\0\0, 6)) {
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

Dear Stephen Warren,

 On 07/08/2013 11:03 AM, Marek Vasut wrote:
  Dear Stephen Warren,
  
  On 07/08/2013 07:25 AM, Vivek Gautam wrote:
  On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
  On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren
  swar...@wwwdotorg.org
  
  wrote:
  On 07/01/2013 07:49 AM, Vivek Gautam wrote:
  On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
  (Sorry to those on to/cc; I'm resending this so it goes to the
  correct mailing list)
  
  Dear Stephen,
  sorry for the delay in responding to this.
  
  Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
  regression on Tegra systems.
 
 ...
 
  Vivek, what do I have to revert to fix this flub? I will do that now,
  since this discussion is stalled.
  
  0bf796f usb: hub: Parallelize power-cycling of root-hub ports
  020bbcb usb: hub: Power-cycle on root-hub ports
  
  Above two patches are the one which changed the hub_power_on()
  functionality. If Stephen can confirm that reverting these patches
  really solves the problem on Tegra,
  we can revert them.
  
  Yes, I have been reverting those two commits locally for a while, and it
  solves the problem for me.
  
  Reverted, please test u-boot-usb/master .
 
 Well, it works, but it turns out the reverts aren't needed. Simon Glass
 already found the problem, and fixed it with:
 
 ed10e66 usb: Correct CLEAR_FEATURE code in ehci-hcd
 
 Sorry for not noticing this earlier, but since there hadn't been any
 news in this thread, and there weren't any relevant changes to the
 power-cycling code affected by the problematic patches, it didn't occur
 to me that the problem may have already been fixed elsewhere, so I
 didn't ever retest the issue with a newer commit than that one where I
 originally found the problem:-(

OK, I dropped the reverts, retest again please.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

On 07/08/2013 12:25 PM, Marek Vasut wrote:
 Dear Stephen Warren,
 
 On 07/08/2013 11:03 AM, Marek Vasut wrote:
 Dear Stephen Warren,

 On 07/08/2013 07:25 AM, Vivek Gautam wrote:
 On Mon, Jul 8, 2013 at 6:33 PM, Marek Vasut ma...@denx.de wrote:
 On Mon, Jul 1, 2013 at 10:11 PM, Stephen Warren
 swar...@wwwdotorg.org

 wrote:
 On 07/01/2013 07:49 AM, Vivek Gautam wrote:
 On Sun, Jun 30, 2013 at 10:08 PM, Marek Vasut ma...@denx.de wrote:
 (Sorry to those on to/cc; I'm resending this so it goes to the
 correct mailing list)

 Dear Stephen,
 sorry for the delay in responding to this.

 Commit 020bbcb usb: hub: Power-cycle on root-hub ports causes a
 regression on Tegra systems.

 ...

 Vivek, what do I have to revert to fix this flub? I will do that now,
 since this discussion is stalled.

 0bf796f usb: hub: Parallelize power-cycling of root-hub ports
 020bbcb usb: hub: Power-cycle on root-hub ports

 Above two patches are the one which changed the hub_power_on()
 functionality. If Stephen can confirm that reverting these patches
 really solves the problem on Tegra,
 we can revert them.

 Yes, I have been reverting those two commits locally for a while, and it
 solves the problem for me.

 Reverted, please test u-boot-usb/master .

 Well, it works, but it turns out the reverts aren't needed. Simon Glass
 already found the problem, and fixed it with:

 ed10e66 usb: Correct CLEAR_FEATURE code in ehci-hcd

 Sorry for not noticing this earlier, but since there hadn't been any
 news in this thread, and there weren't any relevant changes to the
 power-cycling code affected by the problematic patches, it didn't occur
 to me that the problem may have already been fixed elsewhere, so I
 didn't ever retest the issue with a newer commit than that one where I
 originally found the problem:-(
 
 OK, I dropped the reverts, retest again please.

I had already tested the commit in your tree right before the reverts
(a36466c50b1b3614c3cfdae194227f7dd8e2c592); that's how I noticed that
the reverts weren't necessary, since I'd expected that commit to fail
but it didn't.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] video: consolidate splash screen alignment code

2013-07-08 Thread Anatolij Gustschin

On Tue,  2 Jul 2013 00:04:05 +0200
Anatolij Gustschin ag...@denx.de wrote:

 Code for checking splashpos environment variable is
 duplicated in drivers, move it to the common function.
 Call this function also in the bmp display command to
 consider splashpos settings.
 
 Signed-off-by: Anatolij Gustschin ag...@denx.de
 ---
  common/cmd_bmp.c|3 +++
  common/lcd.c|   19 ++-
  common/splash.c |   25 +
  drivers/video/cfb_console.c |   24 ++--
  include/splash.h|7 +++
  5 files changed, 39 insertions(+), 39 deletions(-)

Applied to u-boot-video/master. Thanks!

Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/22] net: Add sunxi (Allwinner) wemac driver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/2013 12:29 PM, Joe Hershberger wrote:
 Hi Tom,
 
 On Mon, Jul 8, 2013 at 11:16 AM, Tom Rini tr...@ti.com wrote:
 On Mon, Jul 08, 2013 at 10:43:03AM -0500, Joe Hershberger wrote:
 On Sun, Nov 25, 2012 at 5:41 AM, Henrik Nordstr?m 
 hen...@henriknordstrom.net wrote:
 This patch adds support for the WEMAC, the ethernet
 controller included in the Allwinner A10 SoC. It will get
 used in the upcoming A10 board support.
 
 From: Stefan Roese s...@denx.de Signed-off-by: Stefan Roese
 s...@denx.de Signed-off-by: Henrik Nordstrom
 hen...@henriknordstrom.net
 
 Applied, Thanks.
 
 Hold up here Joe, the rest of the Allwinner code isn't in yet.
 I'm hoping for a resubmission from Henrik soon :)
 
 I didn't realize that when I was processing all my assigned patches
 in patchwork.  I guess you can revert the this patch before
 accepting his new series.
 
 I've noticed that several of the patches I applied in the last PR
 had been superseded, but were delegated to other people, so I
 didn't see them.  I guess we need to figure out who should be
 delegated such patches and do so consistently.
 
 Apologies,

As the most frequent assigner on patchwork, that's on me, sorry.ian.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR2w0ZAAoJENk4IS6UOR1Wx0UP/0OQ2kDx0ktMqnyEIGeq5riw
2WaOj8d1q8Avh5oDXpqnhegqWE4IWBD8gzHnsXYFnGM8acubtuE+BD6aHZT6R9SF
MJfSRKDJTxWbOrK6p2y2GXIKdwxETS0bJvP5UwrGrJRKI59kOL/m6xEmIQjCGeS5
gq10K75KiGjvmdWgy9O26KOjtGyNY5kqok1MCxqbE0deeQvEoOAxzcV4LQREJFZ8
Aq6xGuZ6dQOTsA3o20PhqT7n2nNSc0R9yhA08Nlrz1ulCtBEcwpi4aPOYg5t12ub
HFT3mEvN7tJfAorvjOhwGTZkkVrxDj0LtDhlbxmqnzWZp6LdEt6QfPcdYHjgXZnj
/e1Ojf9VFKE7V1866xzyuMuvXk/oWix4c57XV1KgsX4j6WdsDraeaEcdRif2RrKi
onoaFBcIgu2p1Z/2ULj82k1OjOuF0vfIae/op0J2mWD2//bHfV/3/ToW3LtEePwA
6sFk2WK1WixYXYt2QztKxzI5NdTeKt5Nn60EQhsZ8O4ht5OSiG9rxEjhW6LNmJlw
9i3aRrqbVhGlwzu4RpsDog6rkJcVX0fhK16Dj4gRbAuoQMayBC7hb6zNc6P6OxpP
azMDyXBdkj56M4sKTgXPYBGKPTKQ6t8p+PLuKSq5tqGPCS+B6i7i/c9Qr3ENqTYG
OSktPGoncCf08C5Ox8Ui
=9mTl
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] TLB mapping for pcie mem space for fsl corenet processors

2013-07-08 Thread Scott Wood


On 07/04/2013 01:13:29 PM, Sughosh Ganu wrote:

hi,
The tlb entries for the pcie mem space for the corenet SoC's is done
for 1.5GiB but certain boards use all the 4 pcie controller
instantiations, and each controller is assigned 512MiB size in the
config files. Should the tlb entries not map 2GiB space as against
1.5GiB. Am i missing something. Thanks.


You'll need to either use a smaller mapping for one or more PCIe  
controllers, or reduce the amount of RAM you map.  There's no room to  
map 2GiB of RAM, 2GiB of PCIe, *and* CCSR, localbus, etc.


Do you really need to access devices on all four controllers from  
within U-Boot?


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-video/master (updated)

2013-07-08 Thread Anatolij Gustschin

Hey Tom,

here is an updated pull request, please pull. Thanks!

Anatolij

The following changes since commit e6bf18dba2a21bebf2c421b1c2e188225f6485a1:

  Prepare v2013.07-rc2 (2013-06-28 18:03:51 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-video.git master

for you to fetch changes up to ff8fb56b6f7edafc1bcba8ef008b3f368cabe60d:

  video: consolidate splash screen alignment code (2013-07-08 20:21:24 +0200)


Anatolij Gustschin (1):
  video: consolidate splash screen alignment code

Piotr Wilczek (2):
  drivers:video:s6e8ax0: change data_to_send array to static
  lcd: align bmp header when uncopmressing image

Robert Winkler (3):
  video: lcd: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
  video: lcd: Make splash_screen_prepare weak, remove config macro
  omap: cm_t35: Fix cm_t35 for weak splash_screen_prepare

Stephen Warren (1):
  lcd: remove unaligned access in lcd_dt_simplefb_configure_node()

 README |8 --
 board/compulab/cm_t35/cm_t35.c |2 +-
 common/Makefile|1 +
 common/cmd_bmp.c   |   45 ++--
 common/lcd.c   |   41 ++---
 common/splash.c|   56 
 doc/README.splashprepare   |8 ++
 drivers/video/cfb_console.c|   29 -
 drivers/video/s6e8ax0.c|   26 +--
 include/configs/cm_t35.h   |1 -
 include/lcd.h  |4 +--
 include/splash.h   |   36 ++
 12 files changed, 161 insertions(+), 96 deletions(-)
 create mode 100644 common/splash.c
 create mode 100644 doc/README.splashprepare
 create mode 100644 include/splash.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/5] am335x_evm: Correct DFU ALT settings for falcon mode

2013-07-08 Thread Peter Korsgaard

 Tom == Tom Rini tr...@ti.com writes:

 Tom Now that we have falcon mode enabled, the partiton numbers for NAND have
 Tom changed, and we need to list entries for updating these parts of the
 Tom system.  While adding falcon mode entires for eMMC (raw), we round up
 Tom the limit on U-Boot for ease of math later.

 Tom Signed-off-by: Tom Rini tr...@ti.com

Reviewed-by: Peter Korsgaard jac...@sunsite.dk

-- 
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] am335x_evm: Update eMMC falcon mode locations

2013-07-08 Thread Peter Korsgaard

 Tom == Tom Rini tr...@ti.com writes:

 Tom The previous location used for the args portion of falcon mode was too
 Tom small to allow for a device tree to be saved there, so move the location
 Tom slightly and increase the size.  In addition, our previous kernel
 Tom location was part of the area we set aside for U-Boot itself, so move it
 Tom up a bit higher.

 Tom Signed-off-by: Tom Rini tr...@ti.com

Reviewed-by: Peter Korsgaard jac...@sunsite.dk

-- 
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] am335x_evm: Add basic README

2013-07-08 Thread Peter Korsgaard

 Tom == Tom Rini tr...@ti.com writes:

 Tom Add a README for the family of boards the am335x_evm covers, and include
 Tom instructions on preparing and using falcon mode, for various media.

 Tom Signed-off-by: Tom Rini tr...@ti.com

Reviewed-by: Peter Korsgaard jac...@sunsite.dk

-- 
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

Dear Stephen Warren,

[...]

 I had already tested the commit in your tree right before the reverts
 (a36466c50b1b3614c3cfdae194227f7dd8e2c592); that's how I noticed that
 the reverts weren't necessary, since I'd expected that commit to fail
 but it didn't.

So we are now all good? Ready for release, no problems anywhere?

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regression due to 020bbcb usb: hub: Power-cycle on root-hub ports

On 07/08/2013 01:50 PM, Marek Vasut wrote:
 Dear Stephen Warren,
 
 [...]
 
 I had already tested the commit in your tree right before the reverts
 (a36466c50b1b3614c3cfdae194227f7dd8e2c592); that's how I noticed that
 the reverts weren't necessary, since I'd expected that commit to fail
 but it didn't.
 
 So we are now all good? Ready for release, no problems anywhere?

As far as I know, yes.

(Although I haven't tested u-boot/master recently, but anyway)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

Hi Sughosh,

On Mon, 8 Jul 2013 19:37:22 +0530, Sughosh Ganu
urwithsugh...@gmail.com wrote:

 hi Albert,
 
 On Mon Jul 08, 2013 at 02:32:16PM +0200, Albert ARIBAUD wrote:
  Hi Sughosh,
  
  On Mon, 8 Jul 2013 17:38:46 +0530, Sughosh Ganu
  urwithsugh...@gmail.com wrote:
  
   hi Albert,
   On Mon Jul 08, 2013 at 12:22:57PM +0200, Albert ARIBAUD wrote:
   
   snip
   
It you flush first then disable, you leave a time window between the
two where a write to the cache can happen (either because your code
does one, or because the compiler optimized one in). If it happens,
then you disable a cache which is still dirty -- IOW, your flushing
has failed its mission, and your cache and memory are still not
coherent.
   
   Since this is specific to arm926ejs, can we not flush *and* invalidate
   the dcache before disabling it -- since the arm926ejs cache uses a
   read allocate policy, flushing and invalidating a cache before
   disabling it would not result in the cache getting written to in the
   window that you refer to. Also, flushing and cleaning is an atomic
   operation.
  
  Invalidating the cache in addition to flushing it would not prevent
  further writes from dirtying the cache lines if they happen before
  the cache is disabled.
 
 I have a doubt on this. The arm926ejs uses a read-allocate policy,
 wherein a new cache line is allocated only on a read miss -- a write
 to an address not present in the cache gets written to memory. So if
 the cache line is invalidated, how will data get written to the cache.

The arm926ej-s data cache does not have a single fixed policy, and
does not have a bypass-on-write policy, only write-through and
copy-back.

Other, more complex, policies may be defined, but at the MMU, not cache,
level, and those are not constant for all arm926ej-s based SoCs; not
even constant for a given SoC as they are configurable at run-time to
fit the chosen system addressing map.

(Besides, bypassing the cache for writes and not reads is of little
interest for plain DDR caching.)

 -sughosh

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2] socfpga: Move board/socfpga_cyclone5 to board/socfpga

Hi Dinh,

On Mon, 8 Jul 2013 11:10:37 -0500, Dinh Nguyen dingu...@altera.com
wrote:

 Hi Albert,
 
 On Fri, 2013-07-05 at 23:04 +0200, ZY - albert.u.boot wrote:
  Hi dingu...@altera.com,
  
  On Tue, 2 Jul 2013 17:00:18 -0500, dingu...@altera.com wrote:
  
   From: Dinh Nguyen dingu...@altera.com
   
   Because the SOCFPGA platform will include support for Cyclone V and
   Arria V FPGA parts, renaming socfpga_cyclone5 folder to socfpga to
   be more generic.
   
   Signed-off-by: Dinh Nguyen dingu...@altera.com
   Reviewed-by: Pavel Machek pa...@denx.de
   Cc: Chin Liang See cl...@altera.com
   Cc: Wolfgang Denk w...@denx.de
   CC: Pavel Machek pa...@denx.de
   Cc: Tom Rini tr...@ti.com
   
   v2:
   - Add Reviewed-by: Pavel Machek
   - Cc: Tom Rini
   ---
  
  Do you really mean that V2 is the exact same code as V1? If it is, then
  V2 is unneeded. And if V2 is different from V1, then history should
  tells us the difference(s).
 
 V2 is the same as v1 codewise. So should I resend this a V1 to be
 applied?

If V1 is the same as V2 as far as the code is concerned, then there is
simply no point in sending V2 or resending V1 again.

The V2 history makes me guess you thought it necessary to officialize
Pavel's Reviewed-By somehow, but that's unneeded; patchworks takes care
of collecting all the {Reviewed,Acked,Tested,...}-by's and providing
them when applying the patch through pwclient.

 Dinh

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] TLB mapping for pcie mem space for fsl corenet processors

hi Scott,

On Tue, Jul 9, 2013 at 12:37 AM, Scott Wood scottw...@freescale.com wrote:

 On 07/04/2013 01:13:29 PM, Sughosh Ganu wrote:

 hi,
 The tlb entries for the pcie mem space for the corenet SoC's is done
 for 1.5GiB but certain boards use all the 4 pcie controller
 instantiations, and each controller is assigned 512MiB size in the
 config files. Should the tlb entries not map 2GiB space as against
 1.5GiB. Am i missing something. Thanks.


 You'll need to either use a smaller mapping for one or more PCIe
 controllers, or reduce the amount of RAM you map.  There's no room to map
 2GiB of RAM, 2GiB of PCIe, *and* CCSR, localbus, etc.

 Do you really need to access devices on all four controllers from within
 U-Boot?


Not on my custom board. I am using a single pcie controller and a much
smaller mem space mapping. But my question was more from the point of view
of the fsl reference boards. My confusion stemmed from the incompatibility
in the tlb mappings and the mem space mentioned in the config files of
certain corenet reference boards.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] gpio: tca642x: Add the tca642x gpio expander driver

Add the tca642x gpio expander driver

Signed-off-by: Dan Murphy dmur...@ti.com
---
 drivers/gpio/Makefile  |1 +
 drivers/gpio/tca642x.c |  312 
 include/tca642x.h  |   64 ++
 3 files changed, 377 insertions(+)
 create mode 100644 drivers/gpio/tca642x.c
 create mode 100644 include/tca642x.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f77c1ec..7e74dfe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_BCM2835_GPIO)  += bcm2835_gpio.o
 COBJS-$(CONFIG_S3C2440_GPIO)   += s3c2440_gpio.o
 COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
 COBJS-$(CONFIG_ADI_GPIO2)  += adi_gpio2.o
+COBJS-$(CONFIG_TCA642X)+= tca642x.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/gpio/tca642x.c b/drivers/gpio/tca642x.c
new file mode 100644
index 000..740714d
--- /dev/null
+++ b/drivers/gpio/tca642x.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2013 Texas Instruments, Inc.
+ *
+ * Derived work from the pca953x.c driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include i2c.h
+#include tca642x.h
+
+/* tca642x register address definitions */
+struct tca642x_bank_info tca642x_banks[] = {
+   {0x00, 0x04, 0x08, 0x0c},
+   {0x01, 0x05, 0x09, 0x0d},
+   {0x02, 0x06, 0x0a, 0x0e},
+};
+
+/*
+ * Modify masked bits in register
+ */
+static int tca642x_reg_write(uint8_t chip, uint addr, uint mask, uint data)
+{
+   uint16_t valw;
+   int org_bus_num;
+   int ret;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+
+   if (i2c_read(chip, addr, 1, (u8 *)valw, 1)) {
+   printf(Could not read before writing\n);
+   ret = -1;
+   goto error;
+   }
+   valw = ~mask;
+   valw |= data;
+
+   ret = i2c_write(chip, addr, 1, (u8 *)valw, 1);
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+
+}
+
+static int tca642x_reg_read(uint8_t chip, uint addr, uint *data)
+{
+   uint16_t valw;
+   int org_bus_num;
+   int ret = 0;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+   if (i2c_read(chip, addr, 1, (u8 *)valw, 1)) {
+   ret = -1;
+   goto error;
+   }
+
+   *data = (int)valw;
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+}
+
+/*
+ * Set output value of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = low, 1 = high
+ */
+int tca642x_set_val(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint out_reg = tca642x_banks[gpio_bank].output_reg;
+
+   return tca642x_reg_write(chip, out_reg, mask, data);
+}
+
+/*
+ * Set read polarity of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = read pin value, 1 = read inverted pin value
+ */
+int tca642x_set_pol(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint pol_reg = tca642x_banks[gpio_bank].polarity_reg;
+
+   return tca642x_reg_write(chip, pol_reg, mask, data);
+}
+
+/*
+ * Set direction of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = output, 1 = input
+ */
+int tca642x_set_dir(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint config_reg = tca642x_banks[gpio_bank].configuration_reg;
+
+   return tca642x_reg_write(chip, config_reg, mask, data);
+}
+
+/*
+ * Read current logic level of all IO pins
+ */
+int tca642x_get_val(uint8_t chip, u8 gpio_bank)
+{
+   uint val;
+   uint in_reg = tca642x_banks[gpio_bank].input_reg;
+
+   if (tca642x_reg_read(chip, in_reg, val)  0)
+   return -1;
+
+   return (int)val;
+}
+
+/*
+ * Set the inital register states for the tca642x gpio expander
+ */
+int tca642x_set_inital_state(uint8_t chip, struct tca642x_bank_info 
init_data[])
+{
+   int i, ret;
+   uint config_reg;
+   uint polarity_reg;
+   uint output_reg;
+
+   for (i = 0; i  3; i++) {
+   config_reg = tca642x_banks[i].configuration_reg;
+   ret = tca642x_reg_write(chip, config_reg, 0xff,
+   init_data[i].configuration_reg);
+   polarity_reg = tca642x_banks[i].polarity_reg;
+   ret = tca642x_reg_write(chip, polarity_reg, 0xff,
+

[U-Boot] [PATCH 2/2] omap5: Configure the tca6424 gpio expander

Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.
As well as HDMI PEO signal.

Signed-off-by: Dan Murphy dmur...@ti.com
---
 board/ti/omap5_uevm/evm.c  |   12 
 board/ti/omap5_uevm/mux_data.h |2 ++
 include/configs/omap5_uevm.h   |5 +
 3 files changed, 19 insertions(+)

diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..ee96ae1 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,6 +26,7 @@
 #include palmas.h
 #include asm/arch/sys_proto.h
 #include asm/arch/mmc_host_def.h
+#include tca642x.h
 
 #include mux_data.h
 
@@ -35,6 +36,15 @@ const struct omap_sysinfo sysinfo = {
Board: OMAP5430 EVM\n
 };
 
+/* Initial states for the GPIO expander
+ * input reg, output reg, polarity reg, configuration reg
+ */
+struct tca642x_bank_info tca642x_init[] = {
+   {0x00, 0x04, 0x00, 0x80},
+   {0x00, 0x00, 0x00, 0xff},
+   {0x00, 0x00, 0x00, 0x40},
+};
+
 /**
  * @brief board_init
  *
@@ -46,6 +56,8 @@ int board_init(void)
gd-bd-bi_arch_number = MACH_TYPE_OMAP5_SEVM;
gd-bd-bi_boot_params = (0x8000 + 0x100); /* boot param addr */
 
+   tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR, tca642x_init);
+
return 0;
 }
 
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..7e6415e 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)},  /*  USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)},  /*  USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)},  /*  USBD0_SS_RX */
+   {I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
+   {I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */
 
 };
 
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..bee1278 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,11 @@
 #define CONFIG_PARTITION_UUIDS
 #define CONFIG_CMD_PART
 
+#define CONFIG_TCA642X
+#define CONFIG_CMD_TCA642X
+#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
+#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
+
 #define CONFIG_SYS_PROMPT  OMAP5432 uEVM # 
 
 #define CONSOLEDEV ttyO2
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] gpio: tca642x: Add the tca642x gpio expander driver

Add the tca642x gpio expander driver

Signed-off-by: Dan Murphy dmur...@ti.com
---
 drivers/gpio/Makefile  |1 +
 drivers/gpio/tca642x.c |  312 
 include/tca642x.h  |   64 ++
 3 files changed, 377 insertions(+)
 create mode 100644 drivers/gpio/tca642x.c
 create mode 100644 include/tca642x.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f77c1ec..7e74dfe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_BCM2835_GPIO)  += bcm2835_gpio.o
 COBJS-$(CONFIG_S3C2440_GPIO)   += s3c2440_gpio.o
 COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
 COBJS-$(CONFIG_ADI_GPIO2)  += adi_gpio2.o
+COBJS-$(CONFIG_TCA642X)+= tca642x.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/gpio/tca642x.c b/drivers/gpio/tca642x.c
new file mode 100644
index 000..740714d
--- /dev/null
+++ b/drivers/gpio/tca642x.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2013 Texas Instruments, Inc.
+ *
+ * Derived work from the pca953x.c driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include i2c.h
+#include tca642x.h
+
+/* tca642x register address definitions */
+struct tca642x_bank_info tca642x_banks[] = {
+   {0x00, 0x04, 0x08, 0x0c},
+   {0x01, 0x05, 0x09, 0x0d},
+   {0x02, 0x06, 0x0a, 0x0e},
+};
+
+/*
+ * Modify masked bits in register
+ */
+static int tca642x_reg_write(uint8_t chip, uint addr, uint mask, uint data)
+{
+   uint16_t valw;
+   int org_bus_num;
+   int ret;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+
+   if (i2c_read(chip, addr, 1, (u8 *)valw, 1)) {
+   printf(Could not read before writing\n);
+   ret = -1;
+   goto error;
+   }
+   valw = ~mask;
+   valw |= data;
+
+   ret = i2c_write(chip, addr, 1, (u8 *)valw, 1);
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+
+}
+
+static int tca642x_reg_read(uint8_t chip, uint addr, uint *data)
+{
+   uint16_t valw;
+   int org_bus_num;
+   int ret = 0;
+
+   org_bus_num = i2c_get_bus_num();
+   i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+   if (i2c_read(chip, addr, 1, (u8 *)valw, 1)) {
+   ret = -1;
+   goto error;
+   }
+
+   *data = (int)valw;
+
+error:
+   i2c_set_bus_num(org_bus_num);
+   return ret;
+}
+
+/*
+ * Set output value of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = low, 1 = high
+ */
+int tca642x_set_val(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint out_reg = tca642x_banks[gpio_bank].output_reg;
+
+   return tca642x_reg_write(chip, out_reg, mask, data);
+}
+
+/*
+ * Set read polarity of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = read pin value, 1 = read inverted pin value
+ */
+int tca642x_set_pol(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint pol_reg = tca642x_banks[gpio_bank].polarity_reg;
+
+   return tca642x_reg_write(chip, pol_reg, mask, data);
+}
+
+/*
+ * Set direction of IO pins in 'mask' to corresponding value in 'data'
+ * 0 = output, 1 = input
+ */
+int tca642x_set_dir(uint8_t chip, u8 gpio_bank, uint mask, uint data)
+{
+   uint config_reg = tca642x_banks[gpio_bank].configuration_reg;
+
+   return tca642x_reg_write(chip, config_reg, mask, data);
+}
+
+/*
+ * Read current logic level of all IO pins
+ */
+int tca642x_get_val(uint8_t chip, u8 gpio_bank)
+{
+   uint val;
+   uint in_reg = tca642x_banks[gpio_bank].input_reg;
+
+   if (tca642x_reg_read(chip, in_reg, val)  0)
+   return -1;
+
+   return (int)val;
+}
+
+/*
+ * Set the inital register states for the tca642x gpio expander
+ */
+int tca642x_set_inital_state(uint8_t chip, struct tca642x_bank_info 
init_data[])
+{
+   int i, ret;
+   uint config_reg;
+   uint polarity_reg;
+   uint output_reg;
+
+   for (i = 0; i  3; i++) {
+   config_reg = tca642x_banks[i].configuration_reg;
+   ret = tca642x_reg_write(chip, config_reg, 0xff,
+   init_data[i].configuration_reg);
+   polarity_reg = tca642x_banks[i].polarity_reg;
+   ret = tca642x_reg_write(chip, polarity_reg, 0xff,
+

[U-Boot] [PATCH 3/3] HACK: ehci-omap: do gpio toggle after port power is set