Re: [U-Boot] [PATCH] arm: armv7: add compile option -mno-unaligned-access if available

[Tetsuyuki Kobayashi]

Hello, Måns
Thank you for summarizing.

I am not against you.
I'm OK either "Allow unaligned access in U-Boot setting" or
"Specify compiler not to generate unaligned memory access"
or other.
I just want to solve hung-up by unaligned access.
I follow custodian's decision.

(2012/07/03 1:14), Måns Rullgård wrote:

Lucas Stach  writes:


Am Montag, den 02.07.2012, 10:53 +0100 schrieb Måns Rullgård:

Tetsuyuki Kobayashi  writes:


Recent compiler generates unaligned memory access in armv7 default.
But current U-Boot does not allow unaligned memory access, so it causes
data abort exception.
This patch add compile option "-mno-unaligned-access" if it is available.


Why not allow unaligned accesses instead?


IMHO, our recent discussion showed that both ways are wrong.
"-mno-unaligned-access" works around misaligned data on the software
level, while allowing unaligned access does on the hardware level.

What we really want is no unaligned access in U-Boot at all. Just
because "-mno-unaligned-access" is the default on ARMv5, we should not
consider it a gold standard.


It's slightly more complicated than that.  Data can be misaligned for a
variety of reasons:

1. Errors in software.
2. Specified by a file format or communication protocol.
3. Deliberately misaligned by the compiler.

Misaligned data of type 1 should of course be fixed properly, not worked
around in any way.

Type 2 happens all the time, and has to be dealt with one way or
another.  If the hardware supports unaligned accesses, this is usually
faster than reading a byte at a time.

When targeting ARMv6 and later, recent gcc versions have started issuing
deliberate unaligned accesses where previously byte by byte accesses
would have been done.  This happens with "packed" structs and sometimes
to write multiple smaller values at once, typically when
zero-initialising things.  These unaligned accesses are *good*.  They
make code smaller and faster.

The real problem here is that u-boot is setting the strict alignment
checking flag, invalidating the assumption of the compiler that the
system allows unaligned accesses.  For ARMv5 and earlier, setting this
flag is usually advisable since it makes finding accidental unaligned
accesses much easier.

This was debated in the context of the kernel a while ago, ultimately
leading to strict alignment being disabled for ARMv6 and up [1].

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8428e84d42179c2a00f5f6450866e70d802d1d05



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

Re: [U-Boot] [PATCH v9 0/4] Kirkwood: add lschlv2 and lsxhl board support

[Prafulla Wadaskar]

> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: 26 June 2012 03:00
> To: Prafulla Wadaskar
> Cc: Joe Hershberger; u-boot@lists.denx.de; albert.u.b...@aribaud.net
> Subject: Re: [U-Boot] [PATCH v9 0/4] Kirkwood: add lschlv2 and lsxhl
> board support
> 
> 
> Hi Prafulla,
> 
> > u-boot-marvell.git is cloned from u-boot-arm.git, and I always sync
> with
> > this before any task. And just to keep it clean for pull requests I
> would
> > not like to pull any other repository in it.
> 
> i just got informed by albert, that he updated his tree. So hopefully
> the
> patchset can now be merged without a conflict. If not, i'll rebase it
> again.

Hi Michael,

Applied this entire patch series to u-boot-marvell.git master branch.
Sorry for the delays on our side and many thanks for your patience.

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

Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices

[Prafulla Wadaskar]

> -Original Message-
> From: Simon Guinot [mailto:si...@sequanux.org]
> Sent: 02 July 2012 14:19
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Albert Aribaud
> Subject: Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
> 
> On Thu, Jun 14, 2012 at 08:18:33AM -0700, Prafulla Wadaskar wrote:
> >
> >
> > > -Original Message-
> > > From: Simon Guinot [mailto:si...@sequanux.org]
> > > Sent: 14 June 2012 20:41
> > > To: Simon Guinot
> > > Cc: Prafulla Wadaskar; u-boot@lists.denx.de
> > > Subject: Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
> > >
> > > On Wed, Jun 06, 2012 at 01:15:57AM +0200, Simon Guinot wrote:
> > > > This patch series provides bug fixes for LaCie devices (mostly
> for
> > > > Internet Space v2 and 2Big Network v2).
> > > >
> > > > Changes for v2:
> > > >  - Move bug fixes into a separate patch set.
> > > >
> > > > Simon Guinot (3):
> > > >   lacie_kw: fix SDRAM banks number for net2big_v2
> > > >   lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2
> > > >   ARM: don't probe PHY address for LaCie boards
> > > >
> > > >  board/LaCie/common/common.c   |   23 +++---
> 
> > > -
> > > >  board/LaCie/common/common.h   |2 +-
> > > >  board/LaCie/edminiv2/edminiv2.c   |2 +-
> > > >  board/LaCie/net2big_v2/net2big_v2.c   |2 +-
> > > >  board/LaCie/netspace_v2/netspace_v2.c |2 +-
> > > >  include/configs/lacie_kw.h|6 +-
> > > >  6 files changed, 12 insertions(+), 25 deletions(-)
> > >
> > > Hi Prafulla,
> > >
> > > Please could you pick this patches ?
> > >
> >
> > Sure, I will do it. Hopefully by tomorrow

Dear Simon

Pulled this patch series to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH] arm/kirkwood: protect the ENV_SPI #defines

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 13 June 2012 18:34
> To: u-boot@lists.denx.de
> Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar
> Subject: [PATCH] arm/kirkwood: protect the ENV_SPI #defines
> 
> From: Valentin Longchamp 
> 
> So that they can be redefined by some boards specific values.
> 
> Signed-off-by: Valentin Longchamp 
> Signed-off-by: Holger Brunck 
> cc: Prafulla Wadaskar 
> ---
> Hi Prafulla,
> here is the only common kirkwood related change from our patch serie,
> as discussed on the ml.
> 
>  arch/arm/include/asm/arch-kirkwood/config.h |   12 +---
>  1 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-kirkwood/config.h
> b/arch/arm/include/asm/arch-kirkwood/config.h
> index 91164eb..a9499b7 100644
> --- a/arch/arm/include/asm/arch-kirkwood/config.h
> +++ b/arch/arm/include/asm/arch-kirkwood/config.h
> @@ -82,9 +82,15 @@
>  #ifdef CONFIG_CMD_SF
>  #define CONFIG_HARD_SPI  1
>  #define CONFIG_KIRKWOOD_SPI  1
> -#define CONFIG_ENV_SPI_BUS   0
> -#define CONFIG_ENV_SPI_CS0
> -#define CONFIG_ENV_SPI_MAX_HZ5000/*50Mhz */
> +#ifndef CONFIG_ENV_SPI_BUS
> +# define CONFIG_ENV_SPI_BUS  0
> +#endif
> +#ifndef CONFIG_ENV_SPI_CS
> +# define CONFIG_ENV_SPI_CS   0
> +#endif
> +#ifndef CONFIG_ENV_SPI_MAX_HZ
> +# define CONFIG_ENV_SPI_MAX_HZ   5000
> +#endif
>  #endif

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH] arm/km: use spi claim bus to switch between SPI and NAND

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 13 June 2012 18:31
> To: u-boot@lists.denx.de
> Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar
> Subject: [PATCH] arm/km: use spi claim bus to switch between SPI and
> NAND
> 
> From: Valentin Longchamp 
> 
> We overwrite these weak functions from the kirkwood spi code to
> use our own method to be able to switch between the SPI NOR and
> the NAND flash. This is needed e.g. to update the u-boot. The former
> command do_spi_toggle can therefore be removed. And the usage of
> this command is removed from the u-boot update command in the
> u-boot environment.
> 
> Signed-off-by: Valentin Longchamp 
> cc: Holger Brunck 
> cc: Prafulla Wadaskar 
> ---
> Hi Prafulla,
> this is now a standalone patch. This patch was already posted, but is
> now a rebase
> of the following three patches from
> http://lists.denx.de/pipermail/u-boot/2012-June/125864.html
> [PATCH 01/20] arm/km: enable spi claim bus
> [PATCH 02/20] arm/km: use correct kw_gpio function for NAND/SPI
> switching
> [PATCH 18/20] arm/km: implement weak function
> board_spi_clam_bus/release
> [PATCH 19/20] arm/km: remove spi toggle command
> This makes the patch much more logical and easier to understand.
> 
> Updates for the remaining patch serie will follow.
> Regards
> 
>  board/keymile/km_arm/km_arm.c |   44 ++--
> 
>  include/configs/km/km_arm.h   |9 +--
>  2 files changed, 13 insertions(+), 40 deletions(-)

Applied to u-boot-marvell.git master branch by resolving few merge conflicts

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

[U-Boot] [PATCH v2 1/4] mmc: dw-mmc: support DesignWare MMC Controller

[Jaehoon Chung]

This patch is supported DesginWare MMC Controller.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Rajeshawari Shinde 
---
 drivers/mmc/dw_mmc.c |  400 ++
 include/dwmmc.h  |  186 +++
 2 files changed, 586 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mmc/dw_mmc.c
 create mode 100644 include/dwmmc.h

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
new file mode 100644
index 000..e634e1d
--- /dev/null
+++ b/drivers/mmc/dw_mmc.c
@@ -0,0 +1,400 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Jaehoon Chung 
+ * Rajeshawari Shinde 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,  MA 02111-1307 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE_SIZE 4096
+
+static int dwmci_wait_reset(struct dwmci_host *host, u32 value)
+{
+   unsigned long timeout = 1000;
+   u32 ctrl;
+
+   dwmci_writel(host, DWMCI_CTRL, value);
+
+   while (timeout--) {
+   ctrl = dwmci_readl(host, DWMCI_CTRL);
+   if (!(ctrl & DWMCI_RESET_ALL))
+   return 1;
+   if (timeout == 0)
+   break;
+   }
+   return 0;
+}
+
+static void dwmci_set_idma_desc(u8 *idmac, unsigned int des0,
+   unsigned int des1, unsigned int des2)
+{
+   struct dwmci_idmac *desc = (struct dwmci_idmac *)idmac;
+
+   desc->des0 = des0;
+   desc->des1 = des1;
+   desc->des2 = des2;
+   desc->des3 = (unsigned int)desc + sizeof(struct dwmci_idmac);
+}
+
+static void dwmci_prepare_data(struct dwmci_host *host,
+   struct mmc_data *data)
+{
+   unsigned long ctrl;
+   unsigned int i = 0, flag, cnt, blk_cnt;
+   struct dwmci_idmac *p;
+   ulong data_start, data_end, start_addr;
+   ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, idmac, 65565);
+
+
+   p = idmac;
+   blk_cnt = data->blocks;
+
+   dwmci_wait_reset(host, DWMCI_CTRL_FIFO_RESET);
+
+   if (data->flags == MMC_DATA_READ)
+   start_addr = (unsigned int)data->dest;
+   else
+   start_addr = (unsigned int)data->src;
+
+   do {
+   flag = DWMCI_IDMAC_OWN | DWMCI_IDMAC_CH ;
+   flag |= (i == 0) ? DWMCI_IDMAC_FS : 0;
+   if (blk_cnt <= 8) {
+   flag |= DWMCI_IDMAC_LD;
+   cnt = data->blocksize * blk_cnt;
+   } else {
+   flag &= ~DWMCI_IDMAC_LD;
+   cnt = data->blocksize * 8;
+   }
+
+   dwmci_set_idma_desc((u8 *)p, flag, cnt,
+   start_addr + (i * PAGE_SIZE));
+
+   if (blk_cnt <= 8)
+   break;
+   blk_cnt -= 8;
+   p++;
+   i++;
+   } while(1);
+
+   data_start = (ulong)idmac;
+   data_end = (ulong)p;
+   flush_dcache_range(data_start, data_end + ARCH_DMA_MINALIGN);
+
+   dwmci_writel(host, DWMCI_DBADDR, (unsigned int)(idmac));
+
+   ctrl = dwmci_readl(host, DWMCI_CTRL);
+   ctrl |= DWMCI_IDMAC_EN | DWMCI_DMA_EN;
+   dwmci_writel(host, DWMCI_CTRL, ctrl);
+
+   ctrl = dwmci_readl(host, DWMCI_BMOD);
+   ctrl |= DWMCI_BMOD_IDMAC_FB | DWMCI_BMOD_IDMAC_EN;
+   dwmci_writel(host, DWMCI_BMOD, ctrl);
+
+   dwmci_writel(host, DWMCI_BLKSIZ, data->blocksize);
+   dwmci_writel(host, DWMCI_BYTCNT, data->blocksize * data->blocks);
+}
+
+static int dwmci_set_transfer_mode(struct dwmci_host *host,
+   struct mmc_data *data)
+{
+   unsigned long mode;
+
+   mode = DWMCI_CMD_DATA_EXP;
+   if (data->flags & MMC_DATA_WRITE)
+   mode |= DWMCI_CMD_RW;
+
+   return mode;
+}
+
+static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
+   struct mmc_data *data)
+{
+   struct dwmci_host *host = (struct dwmci_host *)mmc->priv;
+   int flags = 0, i;
+   unsigned int timeout = 10;
+   u32 retry = 1;
+   u32 mask, ctrl;
+
+   while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
+   if (timeout == 0) {
+   printf("Timeout on data busy\n");
+   return TIMEOUT;
+   }
+   

[U-Boot] [PATCH v2 0/4] mmc: Support designWare Controller

[Jaehoon Chung]

Include mmc:dw-mmc:support DesignWare MMC controller at this patchset.
dw-mmc.c is generic interface.(like sdhci.c)
For using dw-mmc controller, need to add the some samsung specific code.
Exynos specific code should be presented into exynos_dw_mmc.c

If want to use with exynos5, must enable the dw-mmc.c.

Changelog v2:
- Fixed the wrong argument for exynos_dwmci_init()
- Added CONFIG_DWMMC/CONFIG_EXYNOS_DWMMC at Makefile
- Changed host->mmc_clk instead of host->get_mmc_clk
- removed hard-coding value
: if need, we can set to host->fifoth_val

Jaehoon Chung (4):
  mmc: dw-mmc: support DesignWare MMC Controller
  EXYNOS: clock: add the get_mmc_clk function
  EXYNOS: mmc: support DesignWare Controller for Samsung-SoC
  mmc: dw-mmc: add dw-mmc's confiuration at Makefile

 arch/arm/cpu/armv7/exynos/clock.c|   78 ++
 arch/arm/include/asm/arch-exynos/clk.h   |1 +
 arch/arm/include/asm/arch-exynos/dwmmc.h |   36 +++
 drivers/mmc/Makefile |3 +
 drivers/mmc/dw_mmc.c |  400 ++
 drivers/mmc/exynos_dw_mmc.c  |   58 +
 include/dwmmc.h  |  186 ++
 7 files changed, 762 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-exynos/dwmmc.h
 create mode 100644 drivers/mmc/dw_mmc.c
 create mode 100644 drivers/mmc/exynos_dw_mmc.c
 create mode 100644 include/dwmmc.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] EXYNOS: clock: add the get_mmc_clk function

[Jaehoon Chung]

To get more exactly sclk value, used the get_mmc_clk.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
---
 arch/arm/cpu/armv7/exynos/clock.c  |   78 
 arch/arm/include/asm/arch-exynos/clk.h |1 +
 2 files changed, 79 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index 2f7048b..90fa45c 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -360,6 +360,44 @@ static unsigned long exynos5_get_uart_clk(int dev_index)
return uclk;
 }
 
+/* exynos4: return mmc clock frequency */
+static unsigned long exynos4_get_mmc_clk(int dev_index)
+{
+   struct exynos4_clock *clk =
+   (struct exynos4_clock *)samsung_get_base_clock();
+   unsigned long uclk, sclk;
+   unsigned int sel;
+   unsigned int ratio;
+   unsigned int pre_ratio;
+
+   sel = readl(&clk->src_fsys);
+   sel = (sel >> (dev_index << 2)) & 0xf;
+
+   if (sel == 0x6)
+   sclk = get_pll_clk(MPLL);
+   else if (sel == 0x7)
+   sclk = get_pll_clk(EPLL);
+   else if (sel == 0x8)
+   sclk = get_pll_clk(VPLL);
+   else
+   return 0;
+
+   if (dev_index == 0) {
+   ratio = readl(&clk->div_fsys0);
+   pre_ratio = readl(&clk->div_fsys0);
+   } else if (dev_index == 4) {
+   ratio = readl(&clk->div_fsys3);
+   pre_ratio = readl(&clk->div_fsys3);
+   } else
+   return 0;
+
+   ratio = ratio & 0xf;
+   pre_ratio = (pre_ratio >> (dev_index + 8)) & 0xff;
+   uclk = (sclk /(ratio + 1))/(pre_ratio + 1);
+
+   return uclk;
+}
+
 /* exynos4: set the mmc clock */
 static void exynos4_set_mmc_clk(int dev_index, unsigned int div)
 {
@@ -387,6 +425,38 @@ static void exynos4_set_mmc_clk(int dev_index, unsigned 
int div)
writel(val, addr);
 }
 
+/* exynos5: return mmc clock frequency */
+static unsigned long exynos5_get_mmc_clk(int dev_index)
+{
+   struct exynos5_clock *clk =
+   (struct exynos5_clock *)samsung_get_base_clock();
+   unsigned long uclk, sclk;
+   unsigned int sel;
+   unsigned int ratio;
+   unsigned int pre_ratio;
+
+   sel = readl(&clk->src_fsys);
+   sel = (sel >> (dev_index << 2)) & 0xf;
+
+   if (sel == 0x6)
+   sclk = get_pll_clk(MPLL);
+   else if (sel == 0x7)
+   sclk = get_pll_clk(EPLL);
+   else if (sel == 0x8)
+   sclk = get_pll_clk(VPLL);
+   else
+   return 0;
+
+   ratio = readl(&clk->div_fsys1);
+   ratio = (ratio >> (dev_index << 2)) & 0xf;
+   pre_ratio = readl(&clk->div_fsys1);
+   pre_ratio = (pre_ratio >> ((dev_index<< 4) + 8)) & 0xff;
+
+   uclk = (sclk /(ratio + 1))/(pre_ratio + 1);
+
+   return uclk;
+}
+
 /* exynos5: set the mmc clock */
 static void exynos5_set_mmc_clk(int dev_index, unsigned int div)
 {
@@ -446,6 +516,14 @@ unsigned long get_uart_clk(int dev_index)
return exynos4_get_uart_clk(dev_index);
 }
 
+unsigned long get_mmc_clk(int dev_index)
+{
+   if (cpu_is_exynos5())
+   return exynos5_get_mmc_clk(dev_index);
+   else
+   return exynos4_get_mmc_clk(dev_index);
+}
+
 void set_mmc_clk(int dev_index, unsigned int div)
 {
if (cpu_is_exynos5())
diff --git a/arch/arm/include/asm/arch-exynos/clk.h 
b/arch/arm/include/asm/arch-exynos/clk.h
index ff0f641..9e9d390 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -31,6 +31,7 @@
 unsigned long get_pll_clk(int pllreg);
 unsigned long get_arm_clk(void);
 unsigned long get_pwm_clk(void);
+unsigned long get_mmc_clk(int dev_index);
 unsigned long get_uart_clk(int dev_index);
 void set_mmc_clk(int dev_index, unsigned int div);
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] EXYNOS: mmc: support DesignWare Controller for Samsung-SoC

[Jaehoon Chung]

Support DesignWare MMC Controller for Samsung Specific.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Rajeshawari Shinde 
---
 arch/arm/include/asm/arch-exynos/dwmmc.h |   36 ++
 drivers/mmc/exynos_dw_mmc.c  |   58 ++
 2 files changed, 94 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-exynos/dwmmc.h
 create mode 100644 drivers/mmc/exynos_dw_mmc.c

diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h 
b/arch/arm/include/asm/arch-exynos/dwmmc.h
new file mode 100644
index 000..8acdf9b
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
@@ -0,0 +1,36 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Jaehoon Chung 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#define DWMCI_CLKSEL   0x09C
+#define DWMCI_SHIFT_0  0x0
+#define DWMCI_SHIFT_1  0x1
+#define DWMCI_SHIFT_2  0x2
+#define DWMCI_SHIFT_3  0x3
+#define DWMCI_SET_SAMPLE_CLK(x)(x)
+#define DWMCI_SET_DRV_CLK(x)   ((x) << 16)
+#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
+
+int exynos_dwmci_init(u32 regbase, int bus_width, int index);
+
+static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
+{
+   unsigned int base = samsung_get_base_mmc() + (0x1 * index);
+   return exynos_dwmci_init(base, bus_width, index);
+}
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
new file mode 100644
index 000..286a7df
--- /dev/null
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -0,0 +1,58 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Jaehoon Chung 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,  MA 02111-1307 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static char *EXYNOS_NAME = "EXYNOS DWMMC";
+
+static void exynos_dwmci_clksel(struct dwmci_host *host)
+{
+   u32 val;
+   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
+   DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
+
+   dwmci_writel(host, DWMCI_CLKSEL, val);
+}
+
+int exynos_dwmci_init(u32 regbase, int bus_width, int index)
+{
+   struct dwmci_host *host = NULL;
+   host = (struct dwmci_host *)malloc(sizeof(struct dwmci_host));
+   if (!host) {
+   printf("dwmci_host malloc fail!\n");
+   return 1;
+   }
+
+   host->name = EXYNOS_NAME;
+   host->ioaddr = (void *)regbase;
+   host->buswidth = bus_width;
+   host->clksel = exynos_dwmci_clksel;
+   host->dev_index = index;
+   host->mmc_clk = get_mmc_clk;
+
+   add_dwmci(host, 5200, 40, index);
+
+   return 0;
+}
+
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/4] mmc: dw-mmc: add dw-mmc's confiuration at Makefile

[Jaehoon Chung]

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
---
 drivers/mmc/Makefile |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index a8e681c..eccbf55 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -43,6 +43,9 @@ COBJS-$(CONFIG_SDHCI) += sdhci.o
 COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o
 COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 COBJS-$(CONFIG_TEGRA2_MMC) += tegra2_mmc.o
+COBJS-$(CONFIG_DWMMC) += dw_mmc.o
+COBJS-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
+
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/14] arm/km: add kmcoge5un board support

[Prafulla Wadaskar]

Dear Holger

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 13 June 2012 19:03
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Thomas
> Herzmann
> Subject: [PATCH v2 02/14] arm/km: add kmcoge5un board support
> 
> For u-boot this board is similar to mgcoge3un. But some differences
> are present. We have a different SDRAM on it and therefore a new
> SDRAM config file. Additionaly this board has a direct MAC/MAC
> connection from the kirkwood to a marvell simple switch without a
> phy inbetween, this needs a new configuration for the mvgbe driver.
> The testpin was inverted compared to other km_kirkwood boards, this
> is the reason we need the change in post_hotkeys_pressed.
> 
> Signed-off-by: Holger Brunck 
> Signed-off-by: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> 
> Signed-off-by: Thomas Herzmann 
> Signed-off-by: Holger Brunck 
> ---
> changes for v2:
>  - rename KMCOGE5UN to KM_COGE5UN
>  - rename 256M8-1.cfg -> kwbimage_256M8_1.cfg
>  - squash 17/20 arm/km: fix testpin detection for kmcoge5un into this
>commit because it should come with the board support patch
> 
>  MAINTAINERS   |1 +
>  board/keymile/km_arm/km_arm.c |4 +
>  board/keymile/km_arm/kwbimage_256M8_1.cfg |  296
> +

There is anther file coming in patch 01/14 i.e.
board/keymile/km_arm/kwbimage_128M16_1.cfg |  296 

I think the change is only RAM size supported, this must be effectively managed 
using post-configuration in the function
board_early_init_f()

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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 13 June 2012 19:03
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> Use the generic header km_kirkwood.h and get rid of the
> board specific header.
> 
> Signed-off-by: Holger Brunck 
> Signed-off-by: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
> changes for v2:
>- rebased because of changes in other patches
> 
>  board/keymile/km_arm/km_arm.c |9 ++--
>  boards.cfg|2 +-
>  include/configs/km_kirkwood.h |   46 +
>  include/configs/mgcoge3un.h   |   87 
> -
>  4 files changed, 51 insertions(+), 93 deletions(-)
>  delete mode 100644 include/configs/mgcoge3un.h

This patch makes sense to me since it since it shrinks overall code.
Doe not have dependency in patch series, can be accepted if outside the series.

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

Re: [U-Boot] [PATCH v2 04/14] arm/km: remove portl2.h and use km_kirkwood instead

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 13 June 2012 19:03
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> Subject: [PATCH v2 04/14] arm/km: remove portl2.h and use km_kirkwood
> instead
> 
> The additional headerfile is unneeded here, we can use the generic
> km_kirkwood.h instead. And we can use the better config option
> KM_PIGGY4_88E6061 for the specific features for boards with this
> design in km_arm.c.
> 
> Signed-off-by: Holger Brunck 
> Signed-off-by: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
> changes for v2: -simply rebased
> 
>  board/keymile/km_arm/km_arm.c |2 +-
>  boards.cfg|2 +-
>  include/configs/km_kirkwood.h |8 
>  include/configs/portl2.h  |   85 
> -
>  4 files changed, 10 insertions(+), 87 deletions(-)
>  delete mode 100644 include/configs/portl2.h
> 

Even this too, if outside the patch series can be accepted easily

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

Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration

[Prafulla Wadaskar]

> -Original Message-
> From: Valentin Longchamp [mailto:valentin.longch...@keymile.com]
> Sent: 21 June 2012 18:40
> To: Prafulla Wadaskar
> Cc: prafu...@mavell.com; holger.bru...@keymile.com; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external
> switchconfiguration
> 
> Hi Prafulla,
> 
> On 06/12/2012 06:39 AM, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> >> boun...@lists.denx.de] On Behalf Of Valentin Longchamp
> >> Sent: 07 June 2012 15:37
> >> To: prafu...@mavell.com
> >> Cc: Valentin Longchamp; holger.bru...@keymile.com; u-
> >> b...@lists.denx.de
> >> Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external
> >> switch configuration
> >>
> >> This can be used if we do not want to use an EEPROM for the
> >> configuration.
> >>
> >> Signed-off-by: Valentin Longchamp 
> >> ---
> >>  board/keymile/common/common.h |7 --
> >>  board/keymile/km_arm/managed_switch.c |  169
> >> +++--
> >>  board/keymile/km_arm/managed_switch.h |   99 +++
> >
> > What is managed switch? Which chip it supports? Why it is sitting
> here and not in generic folder?
> >
> 
> In this case, the switch is a Marvell 88E52xxx (don't remember the
> exact model)
> that is connected to the GE port of the Kirkwood and that gets
> configured by the
> Kirkwood through a MDIO link, using indirect addressing.
> 
> We do not have the pretention to write a generic driver for such
> switches/addressing, but we need this functionnality on some boards,
> that's why
> we have kept it in our own folder and not in a generic driver folder.
> 
> I will add the above precisions to the commit message for an optional
> v3 of the
> "updates for the Keymile Marvell boards" series so that this is more
> clear.

Dear Valentin
We must keep develop it as generic driver.

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

Re: [U-Boot] [PATCH 1/2] igep00x0: default to OMAP-specific serial driver

[Enric Balletbò i Serra]

2012/6/29 Javier Martinez Canillas 

> An OMAP specific serial driver was merged on the Linux kenel a long
> time ago. So, it makes sense to default the console name to OMAP
> ttyO instead of the generic ttyS naming.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  include/configs/igep00x0.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 88e2e3a..62b4afc 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -135,7 +135,7 @@
> "usbtty=cdc_acm\0" \
> "loadaddr=0x8200\0" \
> "usbtty=cdc_acm\0" \
> -   "console=ttyS2,115200n8\0" \
> +   "console=ttyO2,115200n8\0" \
> "mpurate=auto\0" \
> "vram=12M\0" \
> "dvimode=1024x768MR-16@60\0" \
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



Thanks Javier, seems good for me. Acked

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

Re: [U-Boot] [PATCH 2/2] igep00x0: default mmcrootfstype to EXT4

[Enric Balletbò i Serra]

2012/6/29 Javier Martinez Canillas 

> omap2plus_defconfig now has built-in compile support for EXT4 enabled
> by default now. So, we can use EXT4 as the default root file system
> type for MMC.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  include/configs/igep00x0.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 62b4afc..a0a23a7 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -142,7 +142,7 @@
> "defaultdisplay=dvi\0" \
> "mmcdev=0\0" \
> "mmcroot=/dev/mmcblk0p2 rw\0" \
> -   "mmcrootfstype=ext3 rootwait\0" \
> +   "mmcrootfstype=ext4 rootwait\0" \
> "nandroot=/dev/mtdblock4 rw\0" \
> "nandrootfstype=jffs2\0" \
> "mmcargs=setenv bootargs console=${console} " \
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>


Thanks Javier, seems good for me. Acked

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

[U-Boot] arm, kirkwood: KWGBE_PORT_SERIAL_CONTROL1_REG define correct?

[Heiko Schocher]

Hello Prafulla,

I see in current mainline code:

arch/arm/include/asm/arch-kirkwood/cpu.h

35 #define KWGBE_PORT_SERIAL_CONTROL1_REG(_x)  \
36 ((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)

with results in:

if _x = 0 KW_EGIGA1_BASE and if _x = 1 KW_EGIGA0_BASE
^ ^  ^ ^

is selected ... is this correct? I read _x as port and so this define
swaps the base addresses, or do I miss something?

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

On 06/29/2012 04:32 AM, Simon Glass wrote:

Hi,

On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek mailto:mon...@monstr.eu>> wrote:

On 06/28/2012 07:57 AM, Simon Glass wrote:

Hi Michal,


On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek mailto:mon...@monstr.eu> >> 
wrote:

Hi Simon,


On 06/28/2012 03:10 AM, Simon Glass wrote:

Hi Michal,


On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mailto:mon...@monstr.eu> 
>  
 >  >> 
 >   wrote:

Hi,

can you please update me about current state of 
CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use 
this option?

Or any other git repo out of mainline u-boot?


Exynos is in progress - development is happening in the 
Chromium tree and being upstreamed in chunks (although no fdt patches have been 
sent yet).


ok.




Has someone tried to look for devices based on 
compatible property?
I see that in usb driver it is based on aliases 
which is not the best solution.


U-Boot doesn't yet have a device model which would 
allow this in the general case. For now, drivers look for their own compatible 
nodes. This works well enough until we have a device model.

There are other limitations also - for example USB 
supports only a single controller type working at one time (a restriction we 
may need to look at to support USB2 and USB3 together). So even if two USB 
drivers decided that they both found compatible nodes, only one of them could 
operate. So for now aliases provide just an ordering, nothing else.



I have looked at the code and did some tests on Microblaze.

Firstly I have tried to change emaclite ethernet 
initialization and I ended with this code fragment which could be
broadly used by other drivers.

int offset = 0;
do {
offset = 
fdt_node_offset_by_compatible(__gd->fdt_blob, offset, 
"xlnx,xps-ethernetlite-1.00.a" );



You could check if offset < 0 here, or 
!fdtdec_get_is_enabled(gd->fdt_blob, offset)


u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, 
"reg", 0);


Maybe fdtdec_get_addr()


yeah right.


do {
offset = fdt_node_offset_by_compatible(gd->fdt_blob, 
offset, "xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, 
"reg");
if (reg != FDT_ADDR_T_NONE)

ret |= xilinx_emaclite_initialize(bis, 
reg, txpp, rxpp);
} while (offset != -1);




if (reg)
ret |= 
xilinx_emaclite_initialize(__bis, reg, txpp, rxpp);


} while (offset != -1);

What do you think? This code is in platform file.


Seems reasonable to me.


ok.




Also I have tested code around aliases which parse DTS 
aliases list for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.


Great - I did send a patch to the list for fdt serial, but 
haven't really got back to it.



Can you give me link to it or just subject?


WIP: fdt: Add serial port controlled by devi

Re: [U-Boot] [PATCH v2 02/14] arm/km: add kmcoge5un board support

[Holger Brunck]

On 07/03/2012 10:04 AM, Prafulla Wadaskar wrote:
> Dear Holger
> 
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: 13 June 2012 19:03
>> To: u-boot@lists.denx.de
>> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Thomas
>> Herzmann
>> Subject: [PATCH v2 02/14] arm/km: add kmcoge5un board support
>>
>> For u-boot this board is similar to mgcoge3un. But some differences
>> are present. We have a different SDRAM on it and therefore a new
>> SDRAM config file. Additionaly this board has a direct MAC/MAC
>> connection from the kirkwood to a marvell simple switch without a
>> phy inbetween, this needs a new configuration for the mvgbe driver.
>> The testpin was inverted compared to other km_kirkwood boards, this
>> is the reason we need the change in post_hotkeys_pressed.
>>
>> Signed-off-by: Holger Brunck 
>> Signed-off-by: Valentin Longchamp 
>> cc: Prafulla Wadaskar 
>>
>> Signed-off-by: Thomas Herzmann 
>> Signed-off-by: Holger Brunck 
>> ---
>> changes for v2:
>>  - rename KMCOGE5UN to KM_COGE5UN
>>  - rename 256M8-1.cfg -> kwbimage_256M8_1.cfg
>>  - squash 17/20 arm/km: fix testpin detection for kmcoge5un into this
>>commit because it should come with the board support patch
>>
>>  MAINTAINERS   |1 +
>>  board/keymile/km_arm/km_arm.c |4 +
>>  board/keymile/km_arm/kwbimage_256M8_1.cfg |  296
>> +
> 
> There is anther file coming in patch 01/14 i.e.
> board/keymile/km_arm/kwbimage_128M16_1.cfg |  296 
> 
> I think the change is only RAM size supported, this must be effectively 
> managed using post-configuration in the function
> board_early_init_f()
> 

no the SDRAM size isn't the only difference. If you had a look at these files
there are also differences for other SDRAM controller register e.g. for DDR
timing. So I see no chance for an improvement here.

Regards
Holger

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

[U-Boot] [PATCH 0/7] dfu:usb: Composite USB download gadget with DFU function

[Lukasz Majewski]

Those patches add support for composite USB download gadget.
This gadget (at least for now) is equipped with DFU download function.

A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented
as USB function.

The back-end is written in a generic manner with storage device specific 
code separated (eMMC).

DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard

Example usage:

u-boot side: dfu mmc 0 
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)

To list the alt settings:
dfu mmc 0 list

Test HW:
Exynos4210 Trats board

Lukasz Majewski (7):
  dfu:usb: Support for g_dnl composite download gadget.
  dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
  dfu: DFU backend implementation
  dfu: MMC specific routines for DFU operation
  dfu:cmd: Support for DFU u-boot command
  arm:trats: Support for USB UDC driver at TRATS board.
  arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS

 Makefile|1 +
 board/samsung/trats/trats.c |9 +
 common/Makefile |1 +
 common/cmd_dfu.c|   81 ++
 drivers/dfu/Makefile|   44 +++
 drivers/dfu/dfu.c   |  259 +
 drivers/dfu/dfu_mmc.c   |  126 
 drivers/usb/gadget/Makefile |2 +
 drivers/usb/gadget/f_dfu.c  |  666 +++
 drivers/usb/gadget/f_dfu.h  |  100 +++
 drivers/usb/gadget/g_dnl.c  |  235 +++
 include/configs/trats.h |   19 ++-
 include/dfu.h   |   99 +++
 include/g_dnl.h |   33 +++
 14 files changed, 1674 insertions(+), 1 deletions(-)
 create mode 100644 common/cmd_dfu.c
 create mode 100644 drivers/dfu/Makefile
 create mode 100644 drivers/dfu/dfu.c
 create mode 100644 drivers/dfu/dfu_mmc.c
 create mode 100644 drivers/usb/gadget/f_dfu.c
 create mode 100644 drivers/usb/gadget/f_dfu.h
 create mode 100644 drivers/usb/gadget/g_dnl.c
 create mode 100644 include/dfu.h
 create mode 100644 include/g_dnl.h

-- 
1.7.2.3

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

[U-Boot] [PATCH 1/7] dfu:usb: Support for g_dnl composite download gadget.

[Lukasz Majewski]

Composite USB download gadget support (g_dnl) for download functions.
This code works on top of composite gadget.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
---
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/g_dnl.c  |  235 +++
 include/g_dnl.h |   33 ++
 3 files changed, 269 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/g_dnl.c
 create mode 100644 include/g_dnl.h

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 87d1918..2c067c8 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -29,6 +29,7 @@ LIB   := $(obj)libusb_gadget.o
 ifdef CONFIG_USB_GADGET
 COBJS-y += epautoconf.o config.o usbstring.o
 COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
+COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
 endif
 ifdef CONFIG_USB_ETHER
 COBJS-y += ether.o epautoconf.o config.o usbstring.o
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
new file mode 100644
index 000..7925d0e
--- /dev/null
+++ b/drivers/usb/gadget/g_dnl.c
@@ -0,0 +1,235 @@
+/*
+ * g_dnl.c -- USB Downloader Gadget
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Lukasz Majewski  
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include "f_dfu.h"
+
+#include "gadget_chips.h"
+#include "composite.c"
+
+/* Samsung's IDs */
+#define DRIVER_VENDOR_NUM 0x04E8
+#define DRIVER_PRODUCT_NUM 0x6601
+
+#define STRING_MANUFACTURER 25
+#define STRING_PRODUCT 2
+#define STRING_USBDOWN 2
+#define CONFIG_USBDOWNLOADER 2
+
+#define DRIVER_VERSION "usb_dnl 2.0"
+
+static const char shortname[] = "usb_dnl_";
+static const char product[] = "SLP USB download gadget";
+static const char manufacturer[] = "Samsung";
+
+static struct usb_device_descriptor device_desc = {
+   .bLength =  sizeof device_desc,
+   .bDescriptorType =  USB_DT_DEVICE,
+
+   .bcdUSB =   __constant_cpu_to_le16(0x0200),
+   .bDeviceClass = USB_CLASS_COMM,
+   .bDeviceSubClass =  0x02,   /*0x02:CDC-modem , 0x00:CDC-serial*/
+
+   .idVendor = __constant_cpu_to_le16(DRIVER_VENDOR_NUM),
+   .idProduct =__constant_cpu_to_le16(DRIVER_PRODUCT_NUM),
+   .iProduct = STRING_PRODUCT,
+   .bNumConfigurations =   1,
+};
+
+static const struct usb_descriptor_header *otg_desc[] = {
+   (struct usb_descriptor_header *) &(struct usb_otg_descriptor){
+   .bLength =  sizeof(struct usb_otg_descriptor),
+   .bDescriptorType =  USB_DT_OTG,
+   .bmAttributes = USB_OTG_SRP,
+   },
+   NULL,
+};
+
+/* static strings, in UTF-8 */
+static struct usb_string odin_string_defs[] = {
+   { 0, manufacturer, },
+   { 1, product, },
+};
+
+static struct usb_gadget_strings odin_string_tab = {
+   .language   = 0x0409,   /* en-us */
+   .strings= odin_string_defs,
+};
+
+static struct usb_gadget_strings *g_dnl_composite_strings[] = {
+   &odin_string_tab,
+   NULL,
+};
+
+static int g_dnl_unbind(struct usb_composite_dev *cdev)
+{
+   debug("%s\n", __func__);
+   return 0;
+}
+
+static int g_dnl_do_config(struct usb_configuration *c)
+{
+   int ret = -1;
+   char *s = (char *) c->cdev->driver->name;
+
+   debug("%s: c: 0x%p cdev: 0x%p\n", __func__, c, c->cdev);
+
+   if (gadget_is_otg(c->cdev->gadget)) {
+   c->descriptors = otg_desc;
+   c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
+   }
+
+   printf("GADGET DRIVER: %s\n", s);
+
+   if (!strcmp(s, "usb_dnl_dfu"))
+   ret = dfu_add(c);
+
+   return ret;
+}
+
+static int g_dnl_config_register(struct usb_composite_dev *cdev)
+{
+   debug("%s:\n", __func__);
+   static struct usb_configuration config = {
+   .label = "usb_dnload",
+   .bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER,
+   .bConfigurationValue =  CONFIG_USBDOWNLOADER,
+   .iConfiguration =   STRING_USBDOWN,
+
+   .bind = g_dnl_do_config,
+   };
+
+   retu

[U-Boot] [PATCH 2/7] dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

[Lukasz Majewski]

Support for f_dfu USB function.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
---
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/f_dfu.c  |  666 +++
 drivers/usb/gadget/f_dfu.h  |  100 +++
 3 files changed, 767 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/gadget/f_dfu.c
 create mode 100644 drivers/usb/gadget/f_dfu.h

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 2c067c8..5bbdd36 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -30,6 +30,7 @@ ifdef CONFIG_USB_GADGET
 COBJS-y += epautoconf.o config.o usbstring.o
 COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
 COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
+COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o
 endif
 ifdef CONFIG_USB_ETHER
 COBJS-y += ether.o epautoconf.o config.o usbstring.o
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
new file mode 100644
index 000..c2bf60c
--- /dev/null
+++ b/drivers/usb/gadget/f_dfu.c
@@ -0,0 +1,666 @@
+/*
+ * f_dfu.c -- Device Firmware Update USB function
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * authors: Andrzej Pietrasiewicz 
+ *  Lukasz Majewski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "f_dfu.h"
+
+struct f_dfu {
+   struct usb_function usb_function;
+
+   struct usb_descriptor_header**function;
+   struct usb_string   *strings;
+
+   /* when configured, we have one config */
+   u8  config;
+   u8  altsetting;
+   enum dfu_state  dfu_state;
+   unsigned intdfu_status;
+
+   /* Send/received block number is handy for data integrity check */
+   int blk_seq_num;
+};
+
+static inline struct f_dfu *func_to_dfu(struct usb_function *f)
+{
+   return container_of(f, struct f_dfu, usb_function);
+}
+
+static const struct dfu_function_descriptor dfu_func = {
+   .bLength =  sizeof dfu_func,
+   .bDescriptorType =  DFU_DT_FUNC,
+   .bmAttributes = DFU_BIT_WILL_DETACH |
+   DFU_BIT_MANIFESTATION_TOLERANT |
+   DFU_BIT_CAN_UPLOAD |
+   DFU_BIT_CAN_DNLOAD,
+   .wDetachTimeOut =   0,
+   .wTransferSize =DFU_USB_BUFSIZ,
+   .bcdDFUVersion =__constant_cpu_to_le16(0x0110),
+};
+
+static struct usb_interface_descriptor dfu_intf_runtime = {
+   .bLength =  sizeof dfu_intf_runtime,
+   .bDescriptorType =  USB_DT_INTERFACE,
+   .bNumEndpoints =0,
+   .bInterfaceClass =  USB_CLASS_APP_SPEC,
+   .bInterfaceSubClass =   1,
+   .bInterfaceProtocol =   1,
+   /* .iInterface = DYNAMIC */
+};
+
+static struct usb_descriptor_header *dfu_runtime_descs[] = {
+   (struct usb_descriptor_header *) &dfu_intf_runtime,
+   NULL,
+};
+
+static struct usb_qualifier_descriptor dev_qualifier = {
+   .bLength =  sizeof dev_qualifier,
+   .bDescriptorType =  USB_DT_DEVICE_QUALIFIER,
+   .bcdUSB =   __constant_cpu_to_le16(0x0200),
+   .bDeviceClass = USB_CLASS_VENDOR_SPEC,
+   .bNumConfigurations =   1,
+};
+
+static const char dfu_name[] = "Device Firmware Upgrade";
+
+/* static strings, in UTF-8 */
+/*
+ * dfu_genericiguration specific
+ */
+static struct usb_string strings_dfu_generic[] = {
+   [0].s = dfu_name,
+   {  }/* end of list */
+};
+
+static struct usb_gadget_strings stringtab_dfu_generic = {
+   .language   = 0x0409,   /* en-us */
+   .strings= strings_dfu_generic,
+};
+
+static struct usb_gadget_strings *dfu_generic_strings[] = {
+   &stringtab_dfu_generic,
+   NULL,
+};
+
+/*
+ * usb_function specific
+ */
+static struct usb_gadget_strings stringtab_dfu = {
+   .language   = 0x0409,   /* en-us */
+   /*
+* .strings
+*
+* assigned during initialization,
+* depends on number of flash entities
+ 

[U-Boot] [PATCH 3/7] dfu: DFU backend implementation

[Lukasz Majewski]

New, separate driver at ./drivers/dfu has been added. It allows platform
and storage independent operation of DFU.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
---
 Makefile |1 +
 drivers/dfu/Makefile |   43 
 drivers/dfu/dfu.c|  259 ++
 include/dfu.h|   99 +++
 4 files changed, 402 insertions(+), 0 deletions(-)
 create mode 100644 drivers/dfu/Makefile
 create mode 100644 drivers/dfu/dfu.c
 create mode 100644 include/dfu.h

diff --git a/Makefile b/Makefile
index 0197239..c37dcf3 100644
--- a/Makefile
+++ b/Makefile
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o
 LIBS += drivers/pcmcia/libpcmcia.o
 LIBS += drivers/power/libpower.o
 LIBS += drivers/spi/libspi.o
+LIBS += drivers/dfu/libdfu.o
 ifeq ($(CPU),mpc83xx)
 LIBS += drivers/qe/libqe.o
 LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
new file mode 100644
index 000..7736485
--- /dev/null
+++ b/drivers/dfu/Makefile
@@ -0,0 +1,43 @@
+#
+# Copyright (C) 2012 Samsung Electronics
+# Lukasz Majewski 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)libdfu.o
+
+COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
+
+SRCS:= $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
new file mode 100644
index 000..63733fb
--- /dev/null
+++ b/drivers/dfu/dfu.c
@@ -0,0 +1,259 @@
+/*
+ * dfu.c -- DFU back-end routines
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * authors: Andrzej Pietrasiewicz 
+ * Lukasz Majewski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(dfu_list);
+static int dfu_alt_num;
+
+static int dfu_find_alt_num(char *s)
+{
+   int i = 0;
+
+   for (; *s; s++)
+   if (*s == ';')
+   i++;
+
+   return ++i;
+}
+
+static char *dfu_extract_entity(char** env)
+{
+   char *s = *env;
+
+   strsep(env, ";");
+   return s;
+}
+
+char *dfu_extract_token(char** e, int *n)
+{
+   char *st = *e;
+
+   debug("%s: %s\n", __func__, st);
+
+   strsep(e, " ");
+   *n = *e - st;
+
+   return st;
+}
+
+static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
+dfu_buf[DFU_DATA_BUF_SIZE];
+
+int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
+{
+   static unsigned char *i_buf;
+   static int i_blk_seq_num;
+   long w_size = 0;
+   int ret = 0;
+
+   debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf: 0x%p\n",
+  __func__, dfu->name, buf, size, blk_seq_num, i_buf);
+
+   if (blk_seq_num == 0) {
+   memset(dfu_buf, '\0', sizeof(dfu_buf));
+   i_buf = dfu_buf;
+   i_blk_seq_num = 0;
+   }
+
+   if (i_blk_seq_num++ != blk_seq_num) {
+   printf("%s: Wrong sequence number! [%d] [%d]\n",
+  __func__, i_blk_seq_num, blk_seq_num);
+   return -1;
+   }
+
+   memcpy(i_buf, buf, size);
+   

[U-Boot] [PATCH 4/7] dfu: MMC specific routines for DFU operation

[Lukasz Majewski]

Support for MMC storage devices to work with DFU framework.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
---
 drivers/dfu/Makefile  |1 +
 drivers/dfu/dfu_mmc.c |  126 +
 2 files changed, 127 insertions(+), 0 deletions(-)
 create mode 100644 drivers/dfu/dfu_mmc.c

diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 7736485..7b717bc 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)libdfu.o
 
 COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
+COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
 
 SRCS:= $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
new file mode 100644
index 000..3151fbc
--- /dev/null
+++ b/drivers/dfu/dfu_mmc.c
@@ -0,0 +1,126 @@
+/*
+ * dfu.c -- DFU back-end routines
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * authors: Andrzej Pietrasiewicz 
+ * Lukasz Majewski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+
+int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
+
+   memset(cmd_buf, '\0', sizeof(cmd_buf));
+
+   switch (dfu->layout) {
+   case RAW_ADDR:
+   sprintf(cmd_buf, "mmc write 0x%x %x %x", (unsigned int) buf,
+   dfu->data.mmc.lba_start, dfu->data.mmc.lba_size);
+   break;
+   case FAT:
+   sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s %lx",
+   dfu->data.mmc.dev, dfu->data.mmc.part,
+   (unsigned int) buf, dfu->name, *len);
+   break;
+   default:
+   printf("%s: Wrong layout!\n", __func__);
+   }
+
+   debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf);
+   run_command(cmd_buf, 0);
+
+   return 0;
+}
+
+int dfu_read_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
+   char *str_env = NULL;
+   int ret = 0;
+
+   memset(cmd_buf, '\0', sizeof(cmd_buf));
+
+   switch (dfu->layout) {
+   case RAW_ADDR:
+   sprintf(cmd_buf, "mmc read 0x%x %x %x", (unsigned int) buf,
+   dfu->data.mmc.lba_start, dfu->data.mmc.lba_size);
+
+   *len = dfu->data.mmc.lba_blk_size * dfu->data.mmc.lba_size;
+   break;
+   case FAT:
+   sprintf(cmd_buf, "fatload mmc %d:%d 0x%x %s",
+   dfu->data.mmc.dev, dfu->data.mmc.part,
+   (unsigned int) buf, dfu->name);
+   break;
+   default:
+   printf("%s: Wrong layout!\n", __func__);
+   }
+
+   debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf);
+
+   ret = run_command(cmd_buf, 0);
+   if (ret) {
+   puts("dfu: Read error!\n");
+   return ret;
+   }
+
+   if (dfu->layout != RAW_ADDR) {
+   str_env = getenv("filesize");
+   if (str_env == NULL) {
+   puts("dfu: Wrong file size!\n");
+   return -1;
+   }
+
+   *len = simple_strtoul(str_env, NULL, 16);
+   }
+   return ret;
+}
+
+int dfu_fill_entity_mmc(struct dfu_entity *dfu, char* s)
+{
+   char *st = NULL;
+   int n = 0;
+
+   dfu->dev_type = MMC;
+   st = dfu_extract_token(&s, &n);
+
+   if (!strncmp(st, "mmc", n)) {
+   dfu->layout = RAW_ADDR;
+
+   dfu->data.mmc.lba_start = simple_strtoul(s, &s, 16);
+   dfu->data.mmc.lba_size = simple_strtoul(++s, &s, 16);
+   dfu->data.mmc.lba_blk_size = get_mmc_blk_size(dfu->dev_num);
+
+   } else if (!strncmp(st, "fat", n)) {
+   dfu->layout = FAT;
+
+   dfu->data.mmc.dev = simple_strtoul(s, &s, 10);
+   dfu->data.mmc.part = simple_strtoul(++s, &s, 10);
+
+   } else {
+   printf("%s: Wrong memory layout!\n", __func__);
+   }
+
+   dfu->read_medium = dfu_read_medium_mmc;
+   dfu->write_medium = dfu_write_medium_mmc;
+
+   return 0;
+}
-- 
1.7.2.3

_

[U-Boot] [PATCH 6/7] arm:trats: Support for USB UDC driver at TRATS board.

[Lukasz Majewski]

Support for USB UDC driver at trats board.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
Cc: Minkyu Kang 
---
 board/samsung/trats/trats.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index a95a516..2f3a531 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -59,6 +59,8 @@ static int hwrevision(int rev)
return (board_rev & 0xf) == rev;
 }
 
+struct s3c_plat_otg_data s5pc210_otg_data;
+
 int board_init(void)
 {
gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
@@ -259,6 +261,13 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
.usb_phy_ctrl   = EXYNOS4_USBPHY_CONTROL,
.usb_flags  = PHY0_SLEEP,
 };
+
+void board_usb_init(void)
+{
+   puts("USB_udc_probe\n");
+   s3c_udc_probe(&s5pc210_otg_data);
+
+}
 #endif
 
 static void pmic_reset(void)
-- 
1.7.2.3

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

[U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command

[Lukasz Majewski]

Support for u-boot's command line command "dfu   [list]".

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
---
 common/Makefile  |1 +
 common/cmd_dfu.c |   81 ++
 2 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_dfu.c

diff --git a/common/Makefile b/common/Makefile
index 6e23baa..de43ead 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -186,6 +186,7 @@ COBJS-$(CONFIG_MENU) += menu.o
 COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
 COBJS-$(CONFIG_UPDATE_TFTP) += update.o
 COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
+COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
new file mode 100644
index 000..ceb0f54
--- /dev/null
+++ b/common/cmd_dfu.c
@@ -0,0 +1,81 @@
+/*
+ * cmd_dfu.c -- dfu command
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * authors: Andrzej Pietrasiewicz 
+ * Lukasz Majewski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   char *str_env = NULL, *env_bkp = NULL;
+   static char *s = "dfu";
+   int ret = 0;
+
+   if (argc < 3)
+   return CMD_RET_USAGE;
+
+   str_env = getenv("dfu_alt_info");
+   if (str_env == NULL) {
+   printf("%s: \"dfu_alt_info\" env variable not defined!\n",
+  __func__);
+   return CMD_RET_FAILURE;
+   }
+
+   env_bkp = strdup(str_env);
+   ret = dfu_config_entities(env_bkp, argv[1],
+   (int)simple_strtoul(argv[2], NULL, 10));
+   if (ret)
+   return CMD_RET_FAILURE;
+
+   if (strcmp(argv[3], "list") == 0) {
+   dfu_show_entities();
+   dfu_free_entities();
+   free(env_bkp);
+   return CMD_RET_SUCCESS;
+   }
+
+   board_usb_init();
+   g_dnl_init(s);
+   while (1) {
+   if (ctrlc())
+   goto exit;
+
+   usb_gadget_handle_interrupts();
+   }
+exit:
+   g_dnl_cleanup();
+   dfu_free_entities();
+   free(env_bkp);
+
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
+   "Device Firmware Upgrade",
+   "  [list]\n"
+   "  - device firmware upgrade on a device \n"
+   "attached to interface \n"
+   "[list] - list available alt settings"
+);
-- 
1.7.2.3

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

[U-Boot] [PATCH 7/7] arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

[Lukasz Majewski]

Enable the g_dnl composite USB gadget driver with embedded DFU function on it.
It now uses the composite gadget framework to support download specific
USB functions (like enabled DFU or USB Mass Storage).

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Marek Vasut 
Cc: Minkyu Kang 
---
 include/configs/trats.h |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/include/configs/trats.h b/include/configs/trats.h
index 2f96a18..dcbd198 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -94,6 +94,16 @@
 #undef CONFIG_CMD_ONENAND
 #undef CONFIG_CMD_MTDPARTS
 #define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
+
+/* FAT */
+#define CONFIG_CMD_FAT
+#define CONFIG_FAT_WRITE
+
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
 
 #define CONFIG_BOOTDELAY   1
 #define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +114,11 @@
 #define CONFIG_BOOTBLOCK   "10"
 #define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}"
 
+#define CONFIG_DFU_ALT \
+   "dfu_alt_info=" \
+   "u-boot mmc 80 400;" \
+   "uImage fat 0 2\0" \
+
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +161,8 @@
"mmcdev=0\0" \
"mmcbootpart=2\0" \
"mmcrootpart=3\0" \
-   "opts=always_resume=1"
+   "opts=always_resume=1\0" \
+   CONFIG_DFU_ALT
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
@@ -213,6 +229,7 @@
 #define CONFIG_USB_GADGET
 #define CONFIG_USB_GADGET_S3C_UDC_OTG
 #define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
 
 /* LCD */
 #define CONFIG_EXYNOS_FB
-- 
1.7.2.3

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

[U-Boot] [PATCH] arm:trats: loaduimage environment variable defied for TRATS target

[Lukasz Majewski]

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Minkyu Kang 
---
 include/configs/trats.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/trats.h b/include/configs/trats.h
index dcbd198..e6f4309 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -158,6 +158,7 @@
"meminfo=crashkernel=32M@0x5000\0" \
"nfsroot=/nfsroot/arm\0" \
"bootblock=" CONFIG_BOOTBLOCK "\0" \
+   "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
"mmcdev=0\0" \
"mmcbootpart=2\0" \
"mmcrootpart=3\0" \
-- 
1.7.2.3

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

Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration

[Valentin Longchamp]

Hello Prafulla,

On 07/03/2012 10:17 AM, Prafulla Wadaskar wrote:
>> -Original Message-
>> From: Valentin Longchamp [mailto:valentin.longch...@keymile.com]
>> Sent: 21 June 2012 18:40
>> To: Prafulla Wadaskar
>> Cc: prafu...@mavell.com; holger.bru...@keymile.com; u-
>> b...@lists.denx.de
>> Subject: Re: [U-Boot] [PATCH 12/20] arm/km: add support for external
>> switchconfiguration
>>
>> Hi Prafulla,
>>
>> On 06/12/2012 06:39 AM, Prafulla Wadaskar wrote:
>>>
>>>
 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de] On Behalf Of Valentin Longchamp
 Sent: 07 June 2012 15:37
 To: prafu...@mavell.com
 Cc: Valentin Longchamp; holger.bru...@keymile.com; u-
 b...@lists.denx.de
 Subject: [U-Boot] [PATCH 12/20] arm/km: add support for external
 switch configuration

 This can be used if we do not want to use an EEPROM for the
 configuration.

 Signed-off-by: Valentin Longchamp 
 ---
  board/keymile/common/common.h |7 --
  board/keymile/km_arm/managed_switch.c |  169
 +++--
  board/keymile/km_arm/managed_switch.h |   99 +++
>>>
>>> What is managed switch? Which chip it supports? Why it is sitting
>> here and not in generic folder?
>>>
>>
>> In this case, the switch is a Marvell 88E52xxx (don't remember the
>> exact model)
>> that is connected to the GE port of the Kirkwood and that gets
>> configured by the
>> Kirkwood through a MDIO link, using indirect addressing.
>>
>> We do not have the pretention to write a generic driver for such
>> switches/addressing, but we need this functionnality on some boards,
>> that's why
>> we have kept it in our own folder and not in a generic driver folder.
>>
>> I will add the above precisions to the commit message for an optional
>> v3 of the
>> "updates for the Keymile Marvell boards" series so that this is more
>> clear.
> 
> Dear Valentin
> We must keep develop it as generic driver.
> 
> Regards...
> Prafulla . . .
> 

Sure it would be great if we had the time and resources to contribute a generic
driver for these switches. Unfortunately it is not the case and we have only
developed a simple driver with limited features that suits our current needs.

Since we know it's very limited, we have intentionally chosen to put in in our
board/keymile directory so that it's obvious that it is (currently) not intended
to be used nor was it tested on other boards or with other switches.

The question now is: does u-boot allow some boards (or family of boards) to
integrate some board codes or drivers ? It was until now our understanding that
u-boot allows this. This code definitely fits into this category.

As for the generic driver, if someone contributes one (the current driver can be
used as a basis), we will be very happy to drop this code and use the generic
driver.

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

Re: [U-Boot] [PATCH 0/6 V3] EXYNOS5: USB: Enable USB 2.0 support

[Joonyoung Shim]

Hi, Rajeshwari,

2012/5/8 Rajeshwari Shinde :
> This patchset series adds support to enable USB 2.0 on smdk5250.

Do you have any plan to support USB 3.0 DRD Controller of Exynos5250?

Thanks.

> It corrects sysreg register, usb host, usb otg base address,
> adds power management registers,functions to enable and disable power
> to the USB host controller are added.
>
> This patchset is based on:
> USB: EXYNOS: Add ehci support.patch
>
> Rajeshwari Shinde (6):
>   EXYNOS5: Fix system register structure
>   EXYNOS5: Add structure for PMU registers
>   USB: EXYNOS: Set USB 2.0 HOST Link mode
>   EXYNOS: Add power Enable/Disable for USB-EHCI
>   EXYNOS5: USB: Fix incorrect USB base addresses
>   CONFIG: EXYNOS5: USB: Enable USB 2.0 on smdk5250
>
> Reviewed-by: Lukasz Majewski 
>
>  arch/arm/cpu/armv7/exynos/power.c |   22 +
>  arch/arm/cpu/armv7/exynos/system.c|   22 +
>  arch/arm/include/asm/arch-exynos/cpu.h|4 +-
>  arch/arm/include/asm/arch-exynos/power.h  |  626 
> +
>  arch/arm/include/asm/arch-exynos/system.h |4 +
>  drivers/usb/host/ehci-exynos.c|8 +
>  include/configs/smdk5250.h|6 +
>  7 files changed, 690 insertions(+), 2 deletions(-)
>
> --
> 1.7.4.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

Re: [U-Boot] [PATCH 0/6 V3] EXYNOS5: USB: Enable USB 2.0 support

[Rajeshwari Birje]

Hi Joonyoung Shim,

Yes, Vivek Gautam is working on the same.
He might let you know the progress of the same.

Regards,
Rajeshwari Shinde.


On Tue, Jul 3, 2012 at 3:24 PM, Joonyoung Shim  wrote:
> Hi, Rajeshwari,
>
> 2012/5/8 Rajeshwari Shinde :
>> This patchset series adds support to enable USB 2.0 on smdk5250.
>
> Do you have any plan to support USB 3.0 DRD Controller of Exynos5250?
>
> Thanks.
>
>> It corrects sysreg register, usb host, usb otg base address,
>> adds power management registers,functions to enable and disable power
>> to the USB host controller are added.
>>
>> This patchset is based on:
>> USB: EXYNOS: Add ehci support.patch
>>
>> Rajeshwari Shinde (6):
>>   EXYNOS5: Fix system register structure
>>   EXYNOS5: Add structure for PMU registers
>>   USB: EXYNOS: Set USB 2.0 HOST Link mode
>>   EXYNOS: Add power Enable/Disable for USB-EHCI
>>   EXYNOS5: USB: Fix incorrect USB base addresses
>>   CONFIG: EXYNOS5: USB: Enable USB 2.0 on smdk5250
>>
>> Reviewed-by: Lukasz Majewski 
>>
>>  arch/arm/cpu/armv7/exynos/power.c |   22 +
>>  arch/arm/cpu/armv7/exynos/system.c|   22 +
>>  arch/arm/include/asm/arch-exynos/cpu.h|4 +-
>>  arch/arm/include/asm/arch-exynos/power.h  |  626 
>> +
>>  arch/arm/include/asm/arch-exynos/system.h |4 +
>>  drivers/usb/host/ehci-exynos.c|8 +
>>  include/configs/smdk5250.h|6 +
>>  7 files changed, 690 insertions(+), 2 deletions(-)
>>
>> --
>> 1.7.4.4
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
> --
> - Joonyoung Shim
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot-xlnx: missing fatload command

[Elvis Dowson]

Hi,
  I have got the u-boot up and running on my Xilinx ML507 development 
board, but for some reason, it is missing the fatload command. If someone could 
tell me which config option controls the inclusion of the fatload command into 
the u-boot image, it would be great.

Without the fatload command, I am unable to load the linux kernel images from 
my compact flash drive.

The Xilinx git repo is located at git://git.xilinx.com/u-boot-xlnx.git, and I'm 
using the microblaze branch. The master branch doesn't work, and is very old.

Here is the output of the u-boot help command:

Welcome to minicom 2.5

OPTIONS: I18n 
Compiled on May  2 2011, 10:05:24.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys 
 

 

 

 
U-Boot 2010.12-rc1-02468-g3630c41-dirty (Jul 03 2012 - 08:19:21)
 

CPU:   IBM PowerPC 440x5 VIRTEX5 at 400 MHz (PLB=100 OPB=8 EBC=71)
   32 kB I-Cache 32 kB D-Cache
Xilinx ML507 Board
DRAM:  256 MiB
FLASH: 32 MiB
U-Boot is up and runnining
Hit any key to stop autoboot:  0 
ml507:/# help
?   - alias for 'help'
askenv  - get environment variables from stdin
base- print or set address offset
bdinfo  - print Board Info structure
boot- boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm   - boot application image from memory
bootvx  - Boot vxWorks from an ELF image
chpart  - change active partition
cmp - memory compare
coninfo - print console devices and information
cp  - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
echo- echo args to console
editenv - edit environment variable
env - environment handling commands
erase   - erase FLASH memory
exit- exit script
false   - do nothing, unsuccessfully
flinfo  - print FLASH memory information
fsinfo  - print information about filesystems
fsload  - load binary file from a filesystem image
getdcr  - Get an AMCC PPC 4xx DCR's value
getidcr - Get a register value via indirect DCR addressing
go  - start application at address 'addr'
help- print command description/usage
icache  - enable or disable instruction cache
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
interrupts- enable or disable interrupts
irqinfo - print information about IRQs
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop- infinite loop on address range
loopw   - infinite write loop on address range
ls  - list files in a directory (default /)
md  - memory display
mdc - memory display cyclic
mm  - memory modify (auto-incrementing address)
mtdparts- define flash/nand partitions
mtest   - simple RAM read/write test
mw  - memory write (fill)
mwc - memory write cyclic
nm  - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
reginfo - print register information
reset   - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setdcr  - Set an AMCC PPC 4xx DCR's value
setenv  - set environment variables
setidcr - Set a register value via indirect DCR addressing
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test- minimal test like /bin/sh
true- do nothing, successfully
version - print monitor version


ml507:/# help fatload 
Unknown command 'fatload' - try 'help' without arguments for list of all known 
commands

ml507:/# fatload
Unknown command 'fatload' - try 'help'


Best regards,

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

Re: [U-Boot] arm, kirkwood: KWGBE_PORT_SERIAL_CONTROL1_REG define correct?

[Prafulla Wadaskar]

> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: 03 July 2012 14:41
> To: Prafulla Wadaskar
> Cc: U-Boot user list; Brunck, Holger
> Subject: arm, kirkwood: KWGBE_PORT_SERIAL_CONTROL1_REG define correct?
> 
> Hello Prafulla,
> 
> I see in current mainline code:
> 
> arch/arm/include/asm/arch-kirkwood/cpu.h
> 
> 35 #define KWGBE_PORT_SERIAL_CONTROL1_REG(_x)  \
> 36 ((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)
> 
> with results in:
> 
> if _x = 0 KW_EGIGA1_BASE and if _x = 1 KW_EGIGA0_BASE
>  ^ ^  ^ ^
> 
> is selected ... is this correct? I read _x as port and so this define
> swaps the base addresses, or do I miss something?

Hi Heiko

There is a patch for this which I have acked, may be Joe(copied) can pull it.

Ref: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/133960

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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Holger Brunck]

Hi Prafulla,

On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
> 
> 
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: 13 June 2012 19:03
>> To: u-boot@lists.denx.de
>> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
>> Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>> km_kirkwood
>>
>> Use the generic header km_kirkwood.h and get rid of the
>> board specific header.
>>
>> Signed-off-by: Holger Brunck 
>> Signed-off-by: Valentin Longchamp 
>> cc: Prafulla Wadaskar 
>> ---
>> changes for v2:
>>- rebased because of changes in other patches
>>
>>  board/keymile/km_arm/km_arm.c |9 ++--
>>  boards.cfg|2 +-
>>  include/configs/km_kirkwood.h |   46 +
>>  include/configs/mgcoge3un.h   |   87 
>> -
>>  4 files changed, 51 insertions(+), 93 deletions(-)
>>  delete mode 100644 include/configs/mgcoge3un.h
> 
> This patch makes sense to me since it since it shrinks overall code.
> Doe not have dependency in patch series, can be accepted if outside the 
> series.
> 

again, but there are a lot of dependencies between 01-02 and 03-04 because all
doing a lot in km_kirkwood.h.  So do you have any particular objections against
the first two patches, beside your input for the kwbimage.cfg which I answered
in a different mail?

Regards
Holger

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

Re: [U-Boot] [PATCH] arch-kirkwood: Ethernet port macro returning incorrect address

[Heiko Schocher]

Hello Luke,

On 25.06.2012 18:37, Luke Lowrey wrote:

Modified the arch-kirkwood header so KWGBE_PORT_SERIAL_CONTROL1_REG(x)
returns the correct address.

Originally calling KWGBE_PORT_SERIAL_CONTROL1_REG(1) returned the
address for port 0 and vice versa.

Doesn't have any knock on effects to the u-boot code as the only
time they're used is to do the same function to both addresses

Signed-off-by: Luke Lowrey
---
  arch/arm/include/asm/arch-kirkwood/cpu.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


Acked-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 03 July 2012 16:08
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp
> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> Hi Prafulla,
> 
> On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> >> Sent: 13 June 2012 19:03
> >> To: u-boot@lists.denx.de
> >> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> >> Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> >> km_kirkwood
> >>
> >> Use the generic header km_kirkwood.h and get rid of the
> >> board specific header.
> >>
> >> Signed-off-by: Holger Brunck 
> >> Signed-off-by: Valentin Longchamp 
> >> cc: Prafulla Wadaskar 
> >> ---
> >> changes for v2:
> >>- rebased because of changes in other patches
> >>
> >>  board/keymile/km_arm/km_arm.c |9 ++--
> >>  boards.cfg|2 +-
> >>  include/configs/km_kirkwood.h |   46 +
> >>  include/configs/mgcoge3un.h   |   87 -
> ---
> >> -
> >>  4 files changed, 51 insertions(+), 93 deletions(-)
> >>  delete mode 100644 include/configs/mgcoge3un.h
> >
> > This patch makes sense to me since it since it shrinks overall code.
> > Doe not have dependency in patch series, can be accepted if outside
> the series.
> >
> 
> again, but there are a lot of dependencies between 01-02 and 03-04
> because all
> doing a lot in km_kirkwood.h.  So do you have any particular
> objections against
> the first two patches, beside your input for the kwbimage.cfg which I
> answered
> in a different mail?

As I suggested earlier

You may have patch series for the bugfixes/improvements to the currently 
supported code.

You may have new board support as separate patch, if those have dependency, get 
it addressed first.

As such I do not have any objection about longer patch series but
Generally having a long patch series requires longer time to be get pulled in.

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

[U-Boot] [RFC][PATCH] net: nfs: make NFS_TIMEOUT configurable

[Tetsuyuki Kobayashi]

NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to 
adjust.
This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a 
board specific config file.

Signed-off-by: Tetsuyuki Kobayashi 
---
Hello, 

I made a patch from Joe's idea.

 net/nfs.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 5b99763..6e65c5a 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -31,7 +31,12 @@
 
 #define HASHES_PER_LINE 65 /* Number of "loading" hashes per line  */
 #define NFS_RETRY_COUNT 30
+#ifdef CONFIG_NFS_TIMEOUT
+#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT
+#error ""
+#else
 #define NFS_TIMEOUT 2000UL
+#endif
 
 static int fs_mounted;
 static unsigned long rpc_id;
-- 
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 2/2 V2] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 27 June 2012 17:33
> To: u-boot@lists.denx.de
> Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
> 
> Signed-off-by: Marek Vasut 
> Cc: Prafulla Wadaskar 
> Cc: Wolfgang Denk 
> ---
>  board/karo/tk71/Makefile |   45 +++
>  board/karo/tk71/kwbimage.cfg |  174
> ++
>  board/karo/tk71/tk71.c   |  174
> ++
>  boards.cfg   |1 +
>  include/configs/tk71.h   |  130 +++
>  5 files changed, 524 insertions(+)
>  create mode 100644 board/karo/tk71/Makefile
>  create mode 100644 board/karo/tk71/kwbimage.cfg
>  create mode 100644 board/karo/tk71/tk71.c
>  create mode 100644 include/configs/tk71.h
>
> V2: Enable hush parser
>

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Prafulla Wadaskar
> Sent: 03 July 2012 17:14
> To: 'Marek Vasut'; u-boot@lists.denx.de
> Cc: Wolfgang Denk
> Subject: RE: [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
> 
> 
> 
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: 27 June 2012 17:33
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> > Subject: [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Prafulla Wadaskar 
> > Cc: Wolfgang Denk 
> > ---
> >  board/karo/tk71/Makefile |   45 +++
> >  board/karo/tk71/kwbimage.cfg |  174
> > ++
> >  board/karo/tk71/tk71.c   |  174
> > ++
> >  boards.cfg   |1 +
> >  include/configs/tk71.h   |  130 +++
> >  5 files changed, 524 insertions(+)
> >  create mode 100644 board/karo/tk71/Makefile
> >  create mode 100644 board/karo/tk71/kwbimage.cfg
> >  create mode 100644 board/karo/tk71/tk71.c
> >  create mode 100644 include/configs/tk71.h
> >
> > V2: Enable hush parser
> >
> 
> Applied to u-boot-marvell.git master branch

Sorry Marek, I have reverted it,
we need to tune it further

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

[U-Boot] Pull request for u-boot-marvell.git

[Prafulla Wadaskar]

Dear Albert

Please kindly pull
The following changes since commit 3e0cac6b5158b22248f57cdf7769bf8d610fec5e:
  Rajeshwari Shinde (1):
EXYNOS: SMDK5250: Enable the pinmux setup

are available in the git repository at:

  u-boot-marvell.git ..BRANCH.NOT.VERIFIED..

Holger Brunck (7):
  arm/km: add board type to boards.cfg
  arm/km: add piggy mac adress offset for mgcoge3un
  arm/km: rename CONFIG option CONFIG_KM_DEF_ENV_UPDATE
  arm/km: use ARRAY_SIZE macro
  arm/km: fix wrong comment in SDRAM config for mgcoge3un
  arm/km: change maintainer for mgcoge3un
  arm/km: remove CONFIG_RESET_PHY_R

Luka Perkov (1):
  kwboot: boot kirkwood SoCs over a serial link

Michael Walle (4):
  lib: add rand() function
  net: use common rand()/srand() functions
  net: add helper to generate random mac address
  Kirkwood: add lschlv2 and lsxhl board support

Simon Guinot (3):
  lacie_kw: fix SDRAM banks number for net2big_v2
  lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2
  ARM: don't probe PHY address for LaCie boards

Valentin Longchamp (9):
  arm/km: enable mii cmd
  km_arm: use filesize for erase in update command
  kirkwood: add save functionality kirkwood_mpp_conf function
  kirkwood: fix calls to kirkwood_mpp_conf
  kw_spi: backup and reset the MPP of the chosen CS pin
  kw_spi: support spi_claim/release_bus functions
  kw_spi: add weak functions board_spi_claim/release_bus
  arm/kirkwood: protect the ENV_SPI #defines
  arm/km: use spi claim bus to switch between SPI and NAND

 MAINTAINERS |7 +-
 arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |   10 +-
 arch/arm/include/asm/arch-kirkwood/config.h |   12 +-
 arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
 arch/arm/include/asm/arch-kirkwood/spi.h|   11 +
 board/LaCie/common/common.c |   23 +-
 board/LaCie/common/common.h |2 +-
 board/LaCie/edminiv2/edminiv2.c |2 +-
 board/LaCie/net2big_v2/net2big_v2.c |4 +-
 board/LaCie/netspace_v2/netspace_v2.c   |4 +-
 board/Marvell/dreamplug/dreamplug.c |2 +-
 board/Marvell/guruplug/guruplug.c   |2 +-
 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
 board/Marvell/openrd/openrd.c   |2 +-
 board/Marvell/rd6281a/rd6281a.c |2 +-
 board/Marvell/sheevaplug/sheevaplug.c   |2 +-
 board/Seagate/dockstar/dockstar.c   |2 +-
 board/buffalo/lsxl/Makefile |   44 ++
 board/buffalo/lsxl/kwbimage-lschl.cfg   |  229 +++
 board/buffalo/lsxl/kwbimage-lsxhl.cfg   |  229 +++
 board/buffalo/lsxl/lsxl.c   |  283 +
 board/buffalo/lsxl/lsxl.h   |   75 +++
 board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
 board/d-link/dns325/dns325.c|2 +-
 board/keymile/km_arm/km_arm.c   |   48 +--
 board/keymile/km_arm/kwbimage-memphis.cfg   |2 +-
 board/raidsonic/ib62x0/ib62x0.c |2 +-
 boards.cfg  |6 +-
 doc/kwboot.1|   84 +++
 drivers/spi/kirkwood_spi.c  |   64 ++-
 include/common.h|   10 +
 include/configs/km/km_arm.h |   15 +-
 include/configs/km_kirkwood.h   |4 +-
 include/configs/lacie_kw.h  |6 +-
 include/configs/lsxl.h  |  182 ++
 include/configs/mgcoge3un.h |1 +
 include/net.h   |   17 +
 lib/Makefile|5 +-
 lib/rand.c  |   48 ++
 net/Makefile|2 -
 net/eth.c   |   22 +
 net/link_local.c|7 +-
 net/net_rand.c  |   68 --
 net/net_rand.h  |   31 +-
 tools/Makefile  |6 +
 tools/kwboot.c  |  742 +++
 46 files changed, 2143 insertions(+), 184 deletions(-)
 create mode 100644 board/buffalo/lsxl/Makefile
 create mode 100644 board/buffalo/lsxl/kwbimage-lschl.cfg
 create mode 100644 board/buffalo/lsxl/kwbimage-lsxhl.cfg
 create mode 100644 board/buffalo/lsxl/lsxl.c
 create mode 100644 board/buffalo/lsxl/lsxl.h
 create mode 100644 doc/kwboot.1
 create mode 100644 include/configs/lsxl.h
 create mode 100644 lib/rand.c
 delete mode 100644 net/net_rand.c
 create mode 100644 tools/kwboot.c

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

Re: [U-Boot] Pull request for u-boot-marvell.git

[Prafulla Wadaskar]

> -Original Message-
> From: Prafulla Wadaskar
> Sent: 03 July 2012 17:29
> To: 'Albert ARIBAUD'
> Cc: 'u-boot@lists.denx.de'; Ashish Karkare; Prabhanjan Sarnaik;
> 'Wolfgang Denk'
> Subject: Pull request for u-boot-marvell.git
> 
> Dear Albert
> 
> Please kindly pull
> The following changes since commit
> 3e0cac6b5158b22248f57cdf7769bf8d610fec5e:
>   Rajeshwari Shinde (1):
> EXYNOS: SMDK5250: Enable the pinmux setup
> 
> are available in the git repository at:
> 
>   u-boot-marvell.git ..BRANCH.NOT.VERIFIED..

Pls kindly consider this patch series for master branch
Regards...
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 27 June 2012 17:33
> To: u-boot@lists.denx.de
> Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
> 
> Signed-off-by: Marek Vasut 
> Cc: Prafulla Wadaskar 
> Cc: Wolfgang Denk 
> ---
>  board/karo/tk71/Makefile |   45 +++
>  board/karo/tk71/kwbimage.cfg |  174
> ++
>  board/karo/tk71/tk71.c   |  174
> ++
>  boards.cfg   |1 +
>  include/configs/tk71.h   |  130 +++
>  5 files changed, 524 insertions(+)
>  create mode 100644 board/karo/tk71/Makefile
>  create mode 100644 board/karo/tk71/kwbimage.cfg
>  create mode 100644 board/karo/tk71/tk71.c
>  create mode 100644 include/configs/tk71.h
> 
> V2: Enable hush parser
> 

Hi Marek
This patch give build error against u-boot-marvell.git master branch since 
kw_mpp_config() API is changes

Also please consider the feedback from 
Gerlando Falauto - June 29, 2012, 10:27 a.m.
Which even I find it more cleaner approach

Ref : http://patchwork.ozlabs.org/patch/167436/

Pls kindly fix it and repost

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

Re: [U-Boot] [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Dear Prafulla Wadaskar,

> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: 27 June 2012 17:33
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> > Subject: [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Prafulla Wadaskar 
> > Cc: Wolfgang Denk 
> > ---
> > 
> >  board/karo/tk71/Makefile |   45 +++
> >  board/karo/tk71/kwbimage.cfg |  174
> > 
> > ++
> > 
> >  board/karo/tk71/tk71.c   |  174
> > 
> > ++
> > 
> >  boards.cfg   |1 +
> >  include/configs/tk71.h   |  130 +++
> >  5 files changed, 524 insertions(+)
> >  create mode 100644 board/karo/tk71/Makefile
> >  create mode 100644 board/karo/tk71/kwbimage.cfg
> >  create mode 100644 board/karo/tk71/tk71.c
> >  create mode 100644 include/configs/tk71.h
> > 
> > V2: Enable hush parser
> 
> Hi Marek
> This patch give build error against u-boot-marvell.git master branch since
> kw_mpp_config() API is changes

Looks like this change didn't hit upstream uboot yet.

> Also please consider the feedback from
> Gerlando Falauto - June 29, 2012, 10:27 a.m.
> Which even I find it more cleaner approach

Did you get anywhere with the discussion?

> Ref : http://patchwork.ozlabs.org/patch/167436/
> 
> Pls kindly fix it and repost
> 
> Regards...
> Prafulla . . .

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

[U-Boot] [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Signed-off-by: Marek Vasut 
Cc: Prafulla Wadaskar 
Cc: Wolfgang Denk 
---
 board/karo/tk71/Makefile |   45 +++
 board/karo/tk71/kwbimage.cfg |  174 ++
 board/karo/tk71/tk71.c   |  174 ++
 boards.cfg   |1 +
 include/configs/tk71.h   |  130 +++
 5 files changed, 524 insertions(+)
 create mode 100644 board/karo/tk71/Makefile
 create mode 100644 board/karo/tk71/kwbimage.cfg
 create mode 100644 board/karo/tk71/tk71.c
 create mode 100644 include/configs/tk71.h

V2: Enable hush parser
V3: Fixup kirkwood_mpp_conf() arguments

diff --git a/board/karo/tk71/Makefile b/board/karo/tk71/Makefile
new file mode 100644
index 000..934e391
--- /dev/null
+++ b/board/karo/tk71/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (C) 2012 Marek Vasut 
+# on behalf of DENX Software Engineering GmbH
+#
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := tk71.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/karo/tk71/kwbimage.cfg b/board/karo/tk71/kwbimage.cfg
new file mode 100644
index 000..0166826
--- /dev/null
+++ b/board/karo/tk71/kwbimage.cfg
@@ -0,0 +1,174 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# adopted to TK71 by
+# Nils Faerber 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+# Refer docs/README.kwimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+
+#Dram initalization for SINGLE x16 CL=5 @ 400MHz
+DATA 0xFFD01400 0x43000c30 # DDR Configuration register
+# bit13-0:  0xc30 (3120 DDR2 clks refresh rate)
+# bit23-14: zero
+# bit24: 1= enable exit self refresh mode on DDR access
+# bit25: 1 required
+# bit29-26: zero
+# bit31-30: 01
+
+DATA 0xFFD01404 0x36543000 # DDR Controller Control Low
+# bit 4:0=addr/cmd in smame cycle
+# bit 5:0=clk is driven during self refresh, we don't care for APX
+# bit 6:0=use recommended falling edge of clk for addr/cmd
+# bit14:0=input buffer always powered up
+# bit18:1=cpu lock transaction enabled
+# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0
+# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered 
DIMM
+# bit30-28: 3 required
+# bit31:0=no additional STARTBURST delay
+
+DATA 0xFFD01408 0x1101355b # DDR Timing (Low) (active cycles value +1)
+# bit3-0:   TRAS lsbs
+# bit7-4:   TRCD
+# bit11- 8: TRP
+# bit15-12: TWR
+# bit19-16: TWTR
+# bit20:TRAS msb
+# bit23-21: 0x0
+# bit27-24: TRRD
+# bit31-28: TRTP
+
+DATA 0xFFD0140C 0x0034 #  DDR Timing (High)
+# bit6-0:   TRFC
+# bit8-7:   TR2R
+# bit10-9

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Holger Brunck]

On 07/03/2012 01:19 PM, Prafulla Wadaskar wrote:
> 
> 
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: 03 July 2012 16:08
>> To: Prafulla Wadaskar
>> Cc: u-boot@lists.denx.de; Valentin Longchamp
>> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>> km_kirkwood
>>
>> Hi Prafulla,
>>
>> On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
>>>
>>>
 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 13 June 2012 19:03
 To: u-boot@lists.denx.de
 Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
 Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
 km_kirkwood

 Use the generic header km_kirkwood.h and get rid of the
 board specific header.

 Signed-off-by: Holger Brunck 
 Signed-off-by: Valentin Longchamp 
 cc: Prafulla Wadaskar 
 ---
 changes for v2:
- rebased because of changes in other patches

  board/keymile/km_arm/km_arm.c |9 ++--
  boards.cfg|2 +-
  include/configs/km_kirkwood.h |   46 +
  include/configs/mgcoge3un.h   |   87 -
>> ---
 -
  4 files changed, 51 insertions(+), 93 deletions(-)
  delete mode 100644 include/configs/mgcoge3un.h
>>>
>>> This patch makes sense to me since it since it shrinks overall code.
>>> Doe not have dependency in patch series, can be accepted if outside
>> the series.
>>>
>>
>> again, but there are a lot of dependencies between 01-02 and 03-04
>> because all
>> doing a lot in km_kirkwood.h.  So do you have any particular
>> objections against
>> the first two patches, beside your input for the kwbimage.cfg which I
>> answered
>> in a different mail?
> 
> As I suggested earlier
> 
> You may have patch series for the bugfixes/improvements to the currently 
> supported code.
> 
> You may have new board support as separate patch, if those have dependency, 
> get it addressed first.
> 
> As such I do not have any objection about longer patch series but
> Generally having a long patch series requires longer time to be get pulled in.
> 

so and when do you think to pull this in? AFAIK we are shortly before rc1. And I
would like to  see this in, everything was published before the merge window was
closed and we have reacted on every input you gave. But we can't react on inputs
which are not clearly stated.

So how do we proceed here to get this in for v2012.07? If I summarize the
situation you don't have any particular objections against 01-08 of this series.
So should I resend these eight patches as a standalone serie to get at least
these patches in?

Regards
Holger


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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 03 July 2012 18:02
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp;
> albert.u.b...@aribaud.net
> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> On 07/03/2012 01:19 PM, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> >> Sent: 03 July 2012 16:08
> >> To: Prafulla Wadaskar
> >> Cc: u-boot@lists.denx.de; Valentin Longchamp
> >> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> >> km_kirkwood
> >>
> >> Hi Prafulla,
> >>
> >> On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
> >>>
> >>>
>  -Original Message-
>  From: Holger Brunck [mailto:holger.bru...@keymile.com]
>  Sent: 13 June 2012 19:03
>  To: u-boot@lists.denx.de
>  Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
>  Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>  km_kirkwood
> 
>  Use the generic header km_kirkwood.h and get rid of the
>  board specific header.
> 
>  Signed-off-by: Holger Brunck 
>  Signed-off-by: Valentin Longchamp
> 
>  cc: Prafulla Wadaskar 
>  ---
>  changes for v2:
> - rebased because of changes in other patches
> 
>   board/keymile/km_arm/km_arm.c |9 ++--
>   boards.cfg|2 +-
>   include/configs/km_kirkwood.h |   46 +
>   include/configs/mgcoge3un.h   |   87 ---
> --
> >> ---
>  -
>   4 files changed, 51 insertions(+), 93 deletions(-)
>   delete mode 100644 include/configs/mgcoge3un.h
> >>>
> >>> This patch makes sense to me since it since it shrinks overall
> code.
> >>> Doe not have dependency in patch series, can be accepted if
> outside
> >> the series.
> >>>
> >>
> >> again, but there are a lot of dependencies between 01-02 and 03-04
> >> because all
> >> doing a lot in km_kirkwood.h.  So do you have any particular
> >> objections against
> >> the first two patches, beside your input for the kwbimage.cfg which
> I
> >> answered
> >> in a different mail?
> >
> > As I suggested earlier
> >
> > You may have patch series for the bugfixes/improvements to the
> currently supported code.
> >
> > You may have new board support as separate patch, if those have
> dependency, get it addressed first.
> >
> > As such I do not have any objection about longer patch series but
> > Generally having a long patch series requires longer time to be get
> pulled in.
> >
> 
> so and when do you think to pull this in? AFAIK we are shortly before
> rc1. And I
> would like to  see this in, everything was published before the merge
> window was
> closed and we have reacted on every input you gave. But we can't react
> on inputs
> which are not clearly stated.
> 
> So how do we proceed here to get this in for v2012.07? If I summarize
> the
> situation you don't have any particular objections against 01-08 of
> this series.
> So should I resend these eight patches as a standalone serie to get at
> least
> these patches in?

Yes, Please send the patch series for bug fix and improvements ONLY, I will 
pull them ASAP.

The others we can converge soon.

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

Re: [U-Boot] [PATCH 00/10 V5] EXYNOS5: Support for Exynos5250 Rev 1.0

[Minkyu Kang]

On 2 July 2012 20:36, Rajeshwari Shinde  wrote:
> This patch set adds support for Exynos5250 Rev 1.0.
> Exynos5250 Rev 1.0 supports DDR3 Memory configuration and
> support for LPDDR2 is removed.
> Exynos5250 Rev 1.0 supports DWMMC controller and does not support SDHCI
> controller.
> After DWMMC driver is added to Mainline support for generic S5P MMC driver
> will be removed.
>
> Due to Support of SDHCI controller currently still there for
> EXYNOS5 you can see the following error on boot.
>
> mmc_reset: timeout error
> mmc_change_clock: timeout error
> mmc_send_cmd: waiting for status update
> MMC init failed
>
> Changes in V2:
> - Included Paramateric structure with in #ifndef __ASSEMBLY__.
> Chnages in V3:
> - Incorporated the review comments.
> - Added support for BPLL.
> - Corrected the gpio pinmux settings.
> Changes in V4:
> - Fixed Warning message.
> Changes in V5:
> - Corrected indentation error.
>
> Rajeshwari Shinde (10):
>   ARCH: SPL: Add parametric board initializer
>   SMDK5250: SPL: Define parametric board initializer
>   SMDK5250: Add smdk5250-uboot-spl.lds
>   EXYNOS5: CLOCK: define additional clock registers for Exynos5250 Rev
> 1.0
>   EXYNOS5: CLOCK: Add clock support for Exynos5250 Rev 1.0
>   Exynos5: DDR3: Add DDR3 memory setup for Exynos5250 Rev 1.0
>   EXYNOS5: CLOCK: Modify MPLL clock out for Exynos5250 Rev 1.0
>   EXYNOS5: CLOCK: Add BPLL support
>   EXYNOS5 : Modify pinnumx settings as per Exynos5250 Rev 1.0
>   SMDK5250: Enable UART and MMC for Exynos5250 Rev 1.0
>
>  arch/arm/cpu/armv7/exynos/clock.c |   28 +-
>  arch/arm/cpu/armv7/exynos/pinmux.c|   22 +-
>  arch/arm/include/asm/arch-exynos/clk.h|1 +
>  arch/arm/include/asm/arch-exynos/clock.h  |  237 +
>  arch/arm/include/asm/arch-exynos/dmc.h|   65 +++
>  arch/arm/include/asm/arch-exynos/gpio.h   |7 +-
>  arch/arm/include/asm/arch-exynos/spl.h|   97 
>  board/samsung/smdk5250/Makefile   |3 +-
>  board/samsung/smdk5250/clock_init.c   |  714 +++
>  board/samsung/smdk5250/clock_init.h   |  149 +
>  board/samsung/smdk5250/dmc_common.c   |  199 +++
>  board/samsung/smdk5250/dmc_init.c |  462 ---
>  board/samsung/smdk5250/dmc_init_ddr3.c|  228 
>  board/samsung/smdk5250/setup.h|  762 
> +++--
>  board/samsung/smdk5250/smdk5250-uboot-spl.lds |   66 +++
>  board/samsung/smdk5250/smdk5250.c |6 +-
>  board/samsung/smdk5250/smdk5250_spl.c |   68 +++
>  include/configs/smdk5250.h|7 +-
>  18 files changed, 2099 insertions(+), 1022 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-exynos/spl.h
>  create mode 100644 board/samsung/smdk5250/clock_init.h
>  create mode 100644 board/samsung/smdk5250/dmc_common.c
>  delete mode 100644 board/samsung/smdk5250/dmc_init.c
>  create mode 100644 board/samsung/smdk5250/dmc_init_ddr3.c
>  create mode 100644 board/samsung/smdk5250/smdk5250-uboot-spl.lds
>  create mode 100644 board/samsung/smdk5250/smdk5250_spl.c
>

Please fix compiler errors.

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this function
dmc_init_ddr3.c: In function 'ddr3_mem_ctrl_init':
dmc_init_ddr3.c:196: warning: implicit declaration of function 'sdelay'
dmc_common.c: In function 'dmc_config_zq':
dmc_common.c:72: warning: implicit declaration of function 'sdelay'
In file included from tzpc_init.c:27:
setup.h:554: warning: 'struct exynos5_phy_control' declared inside
parameter list
setup.h:554: warning: its scope is only this definition or
declaration, which is probably not what you want
setup.h:562: warning: 'struct exynos5_dmc' declared inside parameter list
setup.h:570: warning: 'struct exynos5_dmc' declared inside parameter list
setup.h:578: warning: 'struct exynos5_dmc' declared inside parameter list
In file included from tzpc_init.c:27:
setup.h:588: warning: 'enum ddr_mode' declared inside parameter list
setup.h:588: warning: 'struct exynos5_dmc' declared inside parameter list
In file included from tzpc_init.c:27:
setup.h:554: warning: 'struct exynos5_phy_control' declared inside
parameter list
setup.h:554: warning: its scope is only this definition or
declaration, which is probably not what you want
setup.h:562: warning: 'struct exynos5_dmc' declared inside parameter list
setup.h:570: warning: 'struct exynos5_dmc' declared inside parameter list
setup.h:578: warning: 'struct exynos5_dmc' declared inside parameter list
In file included from tzpc_init.c:27:
setup.h:588: warning: 'enum ddr_mode' declared inside parameter list
setup.h:588: warning: 'struct exynos5_dmc' declared inside parameter list
dmc_init_ddr3.c: In function 'ddr3_mem_ctrl_init':
dmc_init_ddr3.c:196: warning: implicit declaration of function 'sdelay'
dmc_common.c: In function 'dm

Re: [U-Boot] [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 03 July 2012 17:58
> To: u-boot@lists.denx.de
> Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> 
> Signed-off-by: Marek Vasut 
> Cc: Prafulla Wadaskar 
> Cc: Wolfgang Denk 
...snip...
> diff --git a/board/karo/tk71/tk71.c b/board/karo/tk71/tk71.c
> new file mode 100644
> index 000..50b563e
> --- /dev/null
> +++ b/board/karo/tk71/tk71.c
> @@ -0,0 +1,174 @@
> +/*
> + * Copyright (C) 2012 Marek Vasut 
> + * on behalf of DENX Software Engineering GmbH
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define TK71_OE_LOW  (~0)
> +#define TK71_OE_HIGH (~0)
> +#define TK71_OE_VAL_LOW  (0)
> +#define TK71_OE_VAL_HIGH (0)
> +
> +int board_early_init_f(void)
> +{
> + unsigned long size = get_ram_size(PHYS_SDRAM_1,
> PHYS_SDRAM_1_SIZE);
> +
> + /* 256MB module, adjust BAR register */
> + if (size == 256 * 1024 * 1024) {
> + writel(KW_REG_CPUCS_WIN_ENABLE | KW_REG_CPUCS_WIN_SIZE(0xf),
> + KW_REG_CPUCS_WIN_SZ(0));
> + }

Hi Marek
This is first patch to support this board series, so ideally you don't need 
further tuning of DRAM configuration, if you address it in kwbimage.cfg

You may think of this approach if you have similar board support in future.

Please post the patch w/o updating DRAM registers or
Let's do it in cleaner way.
macros are NOT encouraged to use for register definition.

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

Re: [U-Boot] [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Dear Prafulla Wadaskar,

> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: 03 July 2012 17:58
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> > Subject: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Prafulla Wadaskar 
> > Cc: Wolfgang Denk 
> 
> ...snip...
> 
> > diff --git a/board/karo/tk71/tk71.c b/board/karo/tk71/tk71.c
> > new file mode 100644
> > index 000..50b563e
> > --- /dev/null
> > +++ b/board/karo/tk71/tk71.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Copyright (C) 2012 Marek Vasut 
> > + * on behalf of DENX Software Engineering GmbH
> > + *
> > + * See file CREDITS for list of people who contributed to this
> > + * project.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> > + * MA 02110-1301 USA
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#define TK71_OE_LOW(~0)
> > +#define TK71_OE_HIGH   (~0)
> > +#define TK71_OE_VAL_LOW(0)
> > +#define TK71_OE_VAL_HIGH   (0)
> > +
> > +int board_early_init_f(void)
> > +{
> > +   unsigned long size = get_ram_size(PHYS_SDRAM_1,
> > PHYS_SDRAM_1_SIZE);
> > +
> > +   /* 256MB module, adjust BAR register */
> > +   if (size == 256 * 1024 * 1024) {
> > +   writel(KW_REG_CPUCS_WIN_ENABLE | KW_REG_CPUCS_WIN_SIZE(0xf),
> > +   KW_REG_CPUCS_WIN_SZ(0));
> > +   }
> 
> Hi Marek
> This is first patch to support this board series, so ideally you don't need
> further tuning of DRAM configuration, if you address it in kwbimage.cfg

What do you mean adress is in kwbimage.cfg ?

> You may think of this approach if you have similar board support in future.
> 
> Please post the patch w/o updating DRAM registers or

How exactly would you support the 256MB variant?

> Let's do it in cleaner way.

I already asked -- did you get anywhere with the cleaner approach? It's not 
even 
discussed properly yet, let alone implemented.

> macros are NOT encouraged to use for register definition.

What do you mean?

> Regards...
> Prafulla . . .

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 0/7] dfu:usb: Composite USB download gadget with DFU function

[Otavio Salvador]

On Tue, Jul 3, 2012 at 6:38 AM, Lukasz Majewski  wrote:
> Those patches add support for composite USB download gadget.
> This gadget (at least for now) is equipped with DFU download function.

Awesome! :-)

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] dfu:usb: Composite USB download gadget with DFU function

[Marek Vasut]

Dear Otavio Salvador,

> On Tue, Jul 3, 2012 at 6:38 AM, Lukasz Majewski  
wrote:
> > Those patches add support for composite USB download gadget.
> > This gadget (at least for now) is equipped with DFU download function.
> 
> Awesome! :-)

Hey Otavio ... we can do the same with our bootrom :-p

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 V3 2/2] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 03 July 2012 18:21
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Wolfgang Denk
> Subject: Re: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> 
> Dear Prafulla Wadaskar,
> 
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: 03 July 2012 17:58
> > > To: u-boot@lists.denx.de
> > > Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> > > Subject: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> > >
> > > Signed-off-by: Marek Vasut 
> > > Cc: Prafulla Wadaskar 
> > > Cc: Wolfgang Denk 
> >
> > ...snip...
> >
> > > diff --git a/board/karo/tk71/tk71.c b/board/karo/tk71/tk71.c
> > > new file mode 100644
> > > index 000..50b563e
> > > --- /dev/null
> > > +++ b/board/karo/tk71/tk71.c
> > > @@ -0,0 +1,174 @@
> > > +/*
> > > + * Copyright (C) 2012 Marek Vasut 
> > > + * on behalf of DENX Software Engineering GmbH
> > > + *
> > > + * See file CREDITS for list of people who contributed to this
> > > + * project.
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License as
> > > + * published by the Free Software Foundation; either version 2 of
> > > + * the License, or (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be
> useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public
> License
> > > + * along with this program; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> > > + * MA 02110-1301 USA
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > +#define TK71_OE_LOW  (~0)
> > > +#define TK71_OE_HIGH (~0)
> > > +#define TK71_OE_VAL_LOW  (0)
> > > +#define TK71_OE_VAL_HIGH (0)
> > > +
> > > +int board_early_init_f(void)
> > > +{
> > > + unsigned long size = get_ram_size(PHYS_SDRAM_1,
> > > PHYS_SDRAM_1_SIZE);
> > > +
> > > + /* 256MB module, adjust BAR register */
> > > + if (size == 256 * 1024 * 1024) {
> > > + writel(KW_REG_CPUCS_WIN_ENABLE |
> KW_REG_CPUCS_WIN_SIZE(0xf),
> > > + KW_REG_CPUCS_WIN_SZ(0));
> > > + }
> >
> > Hi Marek
> > This is first patch to support this board series, so ideally you
> don't need
> > further tuning of DRAM configuration, if you address it in
> kwbimage.cfg
> 
> What do you mean adress is in kwbimage.cfg ?
> 
> > You may think of this approach if you have similar board support in
> future.
> >
> > Please post the patch w/o updating DRAM registers or
> 
> How exactly would you support the 256MB variant?
> 
> > Let's do it in cleaner way.
> 
> I already asked -- did you get anywhere with the cleaner approach?
> It's not even
> discussed properly yet, let alone implemented.

Let's discuss and address this first

> 
> > macros are NOT encouraged to use for register definition.
> 
> What do you mean?

KW_REGISTER(0x1504) + (x * 0x08) is not recommended, let's use c-struct for 
this.

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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Holger Brunck]

On 07/03/2012 02:38 PM, Prafulla Wadaskar wrote:
> 
> 
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: 03 July 2012 18:02
>> To: Prafulla Wadaskar
>> Cc: u-boot@lists.denx.de; Valentin Longchamp;
>> albert.u.b...@aribaud.net
>> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>> km_kirkwood
>>
>> On 07/03/2012 01:19 PM, Prafulla Wadaskar wrote:
>>>
>>>
 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 03 July 2012 16:08
 To: Prafulla Wadaskar
 Cc: u-boot@lists.denx.de; Valentin Longchamp
 Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
 km_kirkwood

 Hi Prafulla,

 On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Holger Brunck [mailto:holger.bru...@keymile.com]
>> Sent: 13 June 2012 19:03
>> To: u-boot@lists.denx.de
>> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
>> Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>> km_kirkwood
>>
>> Use the generic header km_kirkwood.h and get rid of the
>> board specific header.
>>
>> Signed-off-by: Holger Brunck 
>> Signed-off-by: Valentin Longchamp
>> 
>> cc: Prafulla Wadaskar 
>> ---
>> changes for v2:
>>- rebased because of changes in other patches
>>
>>  board/keymile/km_arm/km_arm.c |9 ++--
>>  boards.cfg|2 +-
>>  include/configs/km_kirkwood.h |   46 +
>>  include/configs/mgcoge3un.h   |   87 ---
>> --
 ---
>> -
>>  4 files changed, 51 insertions(+), 93 deletions(-)
>>  delete mode 100644 include/configs/mgcoge3un.h
>
> This patch makes sense to me since it since it shrinks overall
>> code.
> Doe not have dependency in patch series, can be accepted if
>> outside
 the series.
>

 again, but there are a lot of dependencies between 01-02 and 03-04
 because all
 doing a lot in km_kirkwood.h.  So do you have any particular
 objections against
 the first two patches, beside your input for the kwbimage.cfg which
>> I
 answered
 in a different mail?
>>>
>>> As I suggested earlier
>>>
>>> You may have patch series for the bugfixes/improvements to the
>> currently supported code.
>>>
>>> You may have new board support as separate patch, if those have
>> dependency, get it addressed first.
>>>
>>> As such I do not have any objection about longer patch series but
>>> Generally having a long patch series requires longer time to be get
>> pulled in.
>>>
>>
>> so and when do you think to pull this in? AFAIK we are shortly before
>> rc1. And I
>> would like to  see this in, everything was published before the merge
>> window was
>> closed and we have reacted on every input you gave. But we can't react
>> on inputs
>> which are not clearly stated.
>>
>> So how do we proceed here to get this in for v2012.07? If I summarize
>> the
>> situation you don't have any particular objections against 01-08 of
>> this series.
>> So should I resend these eight patches as a standalone serie to get at
>> least
>> these patches in?
> 
> Yes, Please send the patch series for bug fix and improvements ONLY, I will 
> pull them ASAP.
> 
> The others we can converge soon.
> 

But 01-08 are not only bugfixes there are also two new boards in these patches.
So will you pull these eight patches in if I post them again without 09-14?

Regards
Holger

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

[U-Boot] [PATCH 2/2 V4] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Signed-off-by: Marek Vasut 
Cc: Prafulla Wadaskar 
Cc: Wolfgang Denk 
---
 board/karo/tk71/Makefile |   45 +++
 board/karo/tk71/kwbimage.cfg |  174 ++
 board/karo/tk71/tk71.c   |  166 
 boards.cfg   |1 +
 include/configs/tk71.h   |  130 +++
 5 files changed, 516 insertions(+)
 create mode 100644 board/karo/tk71/Makefile
 create mode 100644 board/karo/tk71/kwbimage.cfg
 create mode 100644 board/karo/tk71/tk71.c
 create mode 100644 include/configs/tk71.h

V2: Enable hush parser
V3: Fixup kirkwood_mpp_conf() arguments
V4: Drop 256MB board variant support

diff --git a/board/karo/tk71/Makefile b/board/karo/tk71/Makefile
new file mode 100644
index 000..934e391
--- /dev/null
+++ b/board/karo/tk71/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (C) 2012 Marek Vasut 
+# on behalf of DENX Software Engineering GmbH
+#
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := tk71.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/karo/tk71/kwbimage.cfg b/board/karo/tk71/kwbimage.cfg
new file mode 100644
index 000..0166826
--- /dev/null
+++ b/board/karo/tk71/kwbimage.cfg
@@ -0,0 +1,174 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# adopted to TK71 by
+# Nils Faerber 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+# Refer docs/README.kwimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+
+#Dram initalization for SINGLE x16 CL=5 @ 400MHz
+DATA 0xFFD01400 0x43000c30 # DDR Configuration register
+# bit13-0:  0xc30 (3120 DDR2 clks refresh rate)
+# bit23-14: zero
+# bit24: 1= enable exit self refresh mode on DDR access
+# bit25: 1 required
+# bit29-26: zero
+# bit31-30: 01
+
+DATA 0xFFD01404 0x36543000 # DDR Controller Control Low
+# bit 4:0=addr/cmd in smame cycle
+# bit 5:0=clk is driven during self refresh, we don't care for APX
+# bit 6:0=use recommended falling edge of clk for addr/cmd
+# bit14:0=input buffer always powered up
+# bit18:1=cpu lock transaction enabled
+# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0
+# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered 
DIMM
+# bit30-28: 3 required
+# bit31:0=no additional STARTBURST delay
+
+DATA 0xFFD01408 0x1101355b # DDR Timing (Low) (active cycles value +1)
+# bit3-0:   TRAS lsbs
+# bit7-4:   TRCD
+# bit11- 8: TRP
+# bit15-12: TWR
+# bit19-16: TWTR
+# bit20:TRAS msb
+# bit23-21: 0x0
+# bit27-24: TRRD
+# bit31-28: TRTP
+
+DATA 0xFFD0140C 0x0034 #  DDR Timing (High)
+# bit6-0: 

Re: [U-Boot] [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Dear Prafulla Wadaskar,

> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: 03 July 2012 18:21
> > To: Prafulla Wadaskar
> > Cc: u-boot@lists.denx.de; Wolfgang Denk
> > Subject: Re: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> > 
> > Dear Prafulla Wadaskar,
> > 
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > Sent: 03 July 2012 17:58
> > > > To: u-boot@lists.denx.de
> > > > Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> > > > Subject: [PATCH V3 2/2] Kirkwood: Add support for Ka-Ro TK71
> > > > 
> > > > Signed-off-by: Marek Vasut 
> > > > Cc: Prafulla Wadaskar 
> > > > Cc: Wolfgang Denk 
> > > 
> > > ...snip...
> > > 
> > > > diff --git a/board/karo/tk71/tk71.c b/board/karo/tk71/tk71.c
> > > > new file mode 100644
> > > > index 000..50b563e
> > > > --- /dev/null
> > > > +++ b/board/karo/tk71/tk71.c
> > > > @@ -0,0 +1,174 @@
> > > > +/*
> > > > + * Copyright (C) 2012 Marek Vasut 
> > > > + * on behalf of DENX Software Engineering GmbH
> > > > + *
> > > > + * See file CREDITS for list of people who contributed to this
> > > > + * project.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or
> > > > + * modify it under the terms of the GNU General Public License as
> > > > + * published by the Free Software Foundation; either version 2 of
> > > > + * the License, or (at your option) any later version.
> > > > + *
> > > > + * This program is distributed in the hope that it will be
> > 
> > useful,
> > 
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > > + * GNU General Public License for more details.
> > > > + *
> > > > + * You should have received a copy of the GNU General Public
> > 
> > License
> > 
> > > > + * along with this program; if not, write to the Free Software
> > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> > > > + * MA 02110-1301 USA
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +#define TK71_OE_LOW(~0)
> > > > +#define TK71_OE_HIGH   (~0)
> > > > +#define TK71_OE_VAL_LOW(0)
> > > > +#define TK71_OE_VAL_HIGH   (0)
> > > > +
> > > > +int board_early_init_f(void)
> > > > +{
> > > > +   unsigned long size = get_ram_size(PHYS_SDRAM_1,
> > > > PHYS_SDRAM_1_SIZE);
> > > > +
> > > > +   /* 256MB module, adjust BAR register */
> > > > +   if (size == 256 * 1024 * 1024) {
> > > > +   writel(KW_REG_CPUCS_WIN_ENABLE |
> > 
> > KW_REG_CPUCS_WIN_SIZE(0xf),
> > 
> > > > +   KW_REG_CPUCS_WIN_SZ(0));
> > > > +   }
> > > 
> > > Hi Marek
> > > This is first patch to support this board series, so ideally you
> > 
> > don't need
> > 
> > > further tuning of DRAM configuration, if you address it in
> > 
> > kwbimage.cfg
> > 
> > What do you mean adress is in kwbimage.cfg ?
> > 
> > > You may think of this approach if you have similar board support in
> > 
> > future.
> > 
> > > Please post the patch w/o updating DRAM registers or
> > 
> > How exactly would you support the 256MB variant?
> > 
> > > Let's do it in cleaner way.
> > 
> > I already asked -- did you get anywhere with the cleaner approach?
> > It's not even
> > discussed properly yet, let alone implemented.
> 
> Let's discuss and address this first

Correct, ITM I sent version without memory adjustment

> > > macros are NOT encouraged to use for register definition.
> > 
> > What do you mean?
> 
> KW_REGISTER(0x1504) + (x * 0x08) is not recommended, let's use c-struct for
> this.

Correct, I figured right after I hit send ... sorry ;-)

> 
> Regards..
> Prafulla . . .

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 v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 03 July 2012 18:31
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp;
> albert.u.b...@aribaud.net
> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> On 07/03/2012 02:38 PM, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> >> Sent: 03 July 2012 18:02
> >> To: Prafulla Wadaskar
> >> Cc: u-boot@lists.denx.de; Valentin Longchamp;
> >> albert.u.b...@aribaud.net
> >> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> >> km_kirkwood
> >>
> >> On 07/03/2012 01:19 PM, Prafulla Wadaskar wrote:
> >>>
> >>>
>  -Original Message-
>  From: Holger Brunck [mailto:holger.bru...@keymile.com]
>  Sent: 03 July 2012 16:08
>  To: Prafulla Wadaskar
>  Cc: u-boot@lists.denx.de; Valentin Longchamp
>  Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
>  km_kirkwood
> 
>  Hi Prafulla,
> 
>  On 07/03/2012 10:05 AM, Prafulla Wadaskar wrote:
> >
> >
> >> -Original Message-
> >> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> >> Sent: 13 June 2012 19:03
> >> To: u-boot@lists.denx.de
> >> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> >> Subject: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> >> km_kirkwood
> >>
> >> Use the generic header km_kirkwood.h and get rid of the
> >> board specific header.
> >>
> >> Signed-off-by: Holger Brunck 
> >> Signed-off-by: Valentin Longchamp
> >> 
> >> cc: Prafulla Wadaskar 
> >> ---
> >> changes for v2:
> >>- rebased because of changes in other patches
> >>
> >>  board/keymile/km_arm/km_arm.c |9 ++--
> >>  boards.cfg|2 +-
> >>  include/configs/km_kirkwood.h |   46 +
> >>  include/configs/mgcoge3un.h   |   87 -
> --
> >> --
>  ---
> >> -
> >>  4 files changed, 51 insertions(+), 93 deletions(-)
> >>  delete mode 100644 include/configs/mgcoge3un.h
> >
> > This patch makes sense to me since it since it shrinks overall
> >> code.
> > Doe not have dependency in patch series, can be accepted if
> >> outside
>  the series.
> >
> 
>  again, but there are a lot of dependencies between 01-02 and 03-
> 04
>  because all
>  doing a lot in km_kirkwood.h.  So do you have any particular
>  objections against
>  the first two patches, beside your input for the kwbimage.cfg
> which
> >> I
>  answered
>  in a different mail?
> >>>
> >>> As I suggested earlier
> >>>
> >>> You may have patch series for the bugfixes/improvements to the
> >> currently supported code.
> >>>
> >>> You may have new board support as separate patch, if those have
> >> dependency, get it addressed first.
> >>>
> >>> As such I do not have any objection about longer patch series but
> >>> Generally having a long patch series requires longer time to be
> get
> >> pulled in.
> >>>
> >>
> >> so and when do you think to pull this in? AFAIK we are shortly
> before
> >> rc1. And I
> >> would like to  see this in, everything was published before the
> merge
> >> window was
> >> closed and we have reacted on every input you gave. But we can't
> react
> >> on inputs
> >> which are not clearly stated.
> >>
> >> So how do we proceed here to get this in for v2012.07? If I
> summarize
> >> the
> >> situation you don't have any particular objections against 01-08 of
> >> this series.
> >> So should I resend these eight patches as a standalone serie to get
> at
> >> least
> >> these patches in?
> >
> > Yes, Please send the patch series for bug fix and improvements ONLY,
> I will pull them ASAP.
> >
> > The others we can converge soon.
> >
> 
> But 01-08 are not only bugfixes there are also two new boards in these
> patches.
> So will you pull these eight patches in if I post them again without
> 09-14?

Pls post bug fixes and improvement patches first those will be pulled faster.

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

Re: [U-Boot] [PATCH 2/2 V4] Kirkwood: Add support for Ka-Ro TK71

[Prafulla Wadaskar]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: 03 July 2012 18:32
> To: u-boot@lists.denx.de
> Cc: Marek Vasut; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH 2/2 V4] Kirkwood: Add support for Ka-Ro TK71
> 
> Signed-off-by: Marek Vasut 
> Cc: Prafulla Wadaskar 
> Cc: Wolfgang Denk 
> ---
>  board/karo/tk71/Makefile |   45 +++
>  board/karo/tk71/kwbimage.cfg |  174
> ++
>  board/karo/tk71/tk71.c   |  166
> 
>  boards.cfg   |1 +
>  include/configs/tk71.h   |  130 +++
>  5 files changed, 516 insertions(+)
>  create mode 100644 board/karo/tk71/Makefile
>  create mode 100644 board/karo/tk71/kwbimage.cfg
>  create mode 100644 board/karo/tk71/tk71.c
>  create mode 100644 include/configs/tk71.h
> 
> V2: Enable hush parser
> V3: Fixup kirkwood_mpp_conf() arguments
> V4: Drop 256MB board variant support
> 

Thanks,
Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Holger Brunck]

On 07/03/2012 03:07 PM, Prafulla Wadaskar wrote:
>>>
>>> This patch makes sense to me since it since it shrinks overall
 code.
>>> Doe not have dependency in patch series, can be accepted if
 outside
>> the series.
>>>
>>
>> again, but there are a lot of dependencies between 01-02 and 03-
>> 04
>> because all
>> doing a lot in km_kirkwood.h.  So do you have any particular
>> objections against
>> the first two patches, beside your input for the kwbimage.cfg
>> which
 I
>> answered
>> in a different mail?
>
> As I suggested earlier
>
> You may have patch series for the bugfixes/improvements to the
 currently supported code.
>
> You may have new board support as separate patch, if those have
 dependency, get it addressed first.
>
> As such I do not have any objection about longer patch series but
> Generally having a long patch series requires longer time to be
>> get
 pulled in.
>

 so and when do you think to pull this in? AFAIK we are shortly
>> before
 rc1. And I
 would like to  see this in, everything was published before the
>> merge
 window was
 closed and we have reacted on every input you gave. But we can't
>> react
 on inputs
 which are not clearly stated.

 So how do we proceed here to get this in for v2012.07? If I
>> summarize
 the
 situation you don't have any particular objections against 01-08 of
 this series.
 So should I resend these eight patches as a standalone serie to get
>> at
 least
 these patches in?
>>>
>>> Yes, Please send the patch series for bug fix and improvements ONLY,
>> I will pull them ASAP.
>>>
>>> The others we can converge soon.
>>>
>>
>> But 01-08 are not only bugfixes there are also two new boards in these
>> patches.
>> So will you pull these eight patches in if I post them again without
>> 09-14?
> 
> Pls post bug fixes and improvement patches first those will be pulled faster.
> 
This was already done from my side:
http://lists.denx.de/pipermail/u-boot/2012-May/125219.html

Sorry Prafulla but I have admit that this whole discussion costs a lot of time
which I do not have. We are moving in circles your last comment was already
discussed several times e.g.:
http://lists.denx.de/pipermail/u-boot/2012-June/126081.html

So again you have no specific inputs of improvements for 01-08 right? All you
rephrase are some general comments which are not very helpfull to improve our
situation and to get our own board code into mainline.

We try to stick to every rule which is valid for u-boot development. But we
can't stick to rules which are not clearly stated.

Regards
Holger


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

Re: [U-Boot] [RFC][PATCH] net: nfs: make NFS_TIMEOUT configurable

[Joe Hershberger]

On Jul 3, 2012, at 6:22 AM, Tetsuyuki Kobayashi  wrote:

> NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to 
> adjust.
> This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in 
> a board specific config file.
> 
> Signed-off-by: Tetsuyuki Kobayashi 
> ---
> Hello, 
> 
> I made a patch from Joe's idea.
> 
> net/nfs.c |5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/net/nfs.c b/net/nfs.c
> index 5b99763..6e65c5a 100644
> --- a/net/nfs.c
> +++ b/net/nfs.c
> @@ -31,7 +31,12 @@
> 
> #define HASHES_PER_LINE 65/* Number of "loading" hashes per line*/
> #define NFS_RETRY_COUNT 30
> +#ifdef CONFIG_NFS_TIMEOUT
> +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT
> +#error ""

Why error?

> +#else
> #define NFS_TIMEOUT 2000UL
> +#endif
> 
> static int fs_mounted;
> static unsigned long rpc_id;
> -- 
> 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 v6 00/15] split tegra20 arm7 code into separate SPL

[Thierry Reding]

On Mon, Jul 02, 2012 at 10:51:58PM -0700, Allen Martin wrote:
> This patch series fixes a long standing problem with the tegra20
> u-boot build.  Tegra20 contains an ARM7TDMI boot processor and a
> Cortex A9 main processor.  Prior to this patch series this was
> accomplished by #ifdefing out any armv7 code from the early boot
> sequence and creating a single binary that runs on both both the
> ARM7TDMI and A9.  This was very fragile as changes to compiler options
> or any additions or rearranging of the early boot code could add
> additional armv7 specific code causing it to fail on the ARM7TDMI.
> 
> This patch series pulls all the armv4t code out into a separate SPL
> that does nothing more than initialize the A9 and transfer control to
> it.  The resultint SPL and armv7 u-boot are concatenated together into
> a single image.
> 
> This patch series is also available from:
> git://github.com/arm000/u-boot.git
> branch: tegra-spl-v6
> 
> Changes:
> v6:
>  - changed combined SPL/u-boot target names to u-boot-dtb-tegra.bin
>  and u-boot-nodtb-tegra.bin
>  - fixed regression introduced in v5 that caused git bisect to fail to
>  build at one of the patches
>  - fix USE_PRIVATE_LIBGCC for SPL build and enable it
>  - fix libtegra20-common.so link so it works if building with out of
>  tree OBJDIR
> v5:
>  - added missing mkdir rules in all tegra20 board Makefiles that
>  include common code and changed them to be unconditional
>  - make new u-boot-dtb-t2.bin rule default for tegra20 and copy
>  resulting binary over u-boot.bin
> v4:
>  - rebased to u-boot-tegra/next
>  - reordered entire patch series to preserve git bisect, verified
>  build and boot at each patch
>  - merged patches that add SPL config defines and removes duplicate
>  code from u-boot init, these have to go in atomically to preserve
>  building at each patch
>  - fixed compiler warnings introduced
>  - fixed blank line at end of file on cpu.c
>  - renamed u-boot.t2 to u-boot-t2.bin
>  - cleaned up config.mk generation in mkconfig to make it more
>  readable
>  - added some text to clarify using arm720t code for arm7tdmi
>  - rearranged SPL memory map to make resulting SPL + u-boot image much
>  smaller 
>  - removed separate PAD_TO define in favor of just using
>  CONFIG_SYS_TEXT_BASE 
>  - moved warmboot_save_sdram_params() from dram_init() to board_init()
> v3:
>  - git bisect still does not work across this series, I'm saving that
>  for the next revision, but I had enough changes that I wanted to get
>  this out for review
>  - expanded the tegra2 -> tegra20 rename to include
>  functions/variables/
>  defines
>  - rebased to u-boot-tegra/next
>  - removed some extra -march=armv4t flags, kept armv4t flags on
>  warmboot_avp since it's special
>  - removed bashisms from mkconfig
>  - renamed CONFIG_MACH_TEGRA_GENERIC to CONFIG_TEGRA
>  - moved SPL overrides to tegra2-common-post.h
>  - changed SPL base address to 0x108000, u-boot goes to 0x208000
>  - moved warboot_save_sdram_params fix to separate patch
>  - remove USE_PRIVATE_LIBGCC from non SPL build
>  - expanded SPL support to all tegra20 boards, not just seaboard
> v2:
>  - renamed tegra2 to tegra20 to match kernel and devicetree naming
>  policy
>  - pulled all SPL related config overrides to a separate file to clean
>  up ifdefs from seabard.h
>  - rebased to TOT u-boot/master and fixed a bug related to init
>  sequence changes between this patch series and new EMC code
>  - made u-boot.t2 target work even if CONFIG_OF is disabled
>  - added back USE_PRIVATE_LIBGCC
> 
> [PATCH v6 01/15] tegra20: rename tegra2 -> tegra20
> [PATCH v6 02/15] tegra20: move tegra20 SoC code to
> [PATCH v6 03/15] tegra20: rename CONFIG_MACH_TEGRA_GENERIC
> [PATCH v6 04/15] tegra20: tec: add tegra20-common-post.h
> [PATCH v6 05/15] tegra20: make board mkdir commands unconditional
> [PATCH v6 06/15] mkconfig: add support for SPL CPU
> [PATCH v6 07/15] ARM: Fix arm720t SPL build
> [PATCH v6 08/15] tegra20: remove timer_init from SPL build
> [PATCH v6 09/15] ARM: add tegra20 support to arm720t
> [PATCH v6 10/15] tegra20: add u-boot-*-tegra.bin targets
> [PATCH v6 11/15] tegra20: move SDRAM param save to later in boot
> [PATCH v6 12/15] tegra20: enable SPL for tegra20 boards
> [PATCH v6 13/15] arm: enable libgcc build for SPL
> [PATCH v6 14/15] spl: fix SPL build of private libgcc
> [PATCH v6 15/15] tegra20: Remove armv4t build flags
> 
>  MAINTAINERS|   18 +--
>  Makefile   |   26 
>  arch/arm/cpu/arm720t/cpu.c |2 +
>  arch/arm/cpu/arm720t/interrupts.c  |5 +
>  arch/arm/cpu/arm720t/start.S   |   19 ++-
>  .../arm/cpu/arm720t/tegra20}/Makefile  |   27 ++--
>  .../arch-tegra2 => cpu/arm720t/tegra20}/board.h|   11 +-
>  .../{armv7/tegra2 => arm720t/tegra20}/config.mk|   12 --
>  .../{armv7/tegra2/ap20.c => arm720t/tegra20/cpu.c} |  148 
> ++--

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Detlev Zundel]

Hi Prafulla,

[...]

>> But 01-08 are not only bugfixes there are also two new boards in these
>> patches.
>> So will you pull these eight patches in if I post them again without
>> 09-14?
>
> Pls post bug fixes and improvement patches first those will be pulled
> faster.

May I please ask you to reconsider your stance on the patch sets from
Holger?  As far as I can see, he explained a few times by now why and
how he grouped the patches like he did.  And to be honest, I _can_
understand his reasoning and believe it to be well-founded.

After all, our requirements come from _practical_ considerations,
i.e. bisectability, code size reductions, etc. but in the end they are
all compromises in one way or another.  So usually we do not invent new
requirements for the sake of requirements, but in order to improve the
situation if the net effect is positive for the project as a whole.

Of course it is a fact that the effort for reviewers is non-negligible,
but we have to draw a line somewhere in the area where the
"well-formedness" of patch sets and the "ease" of reviewing them needs
to be compromised.  I do not like to see added complexity in patch sets
so that reviewing gets easier.  

As far as I can see, this is the current situation and thus I would like
you to reconsider and rather spend some more time on the review process
of the whole patch series as it is.

Thanks in advance
  Detlev

-- 
"The number you have dialed is imaginary. Please rotate your phone 90
degrees and try again."
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/1] Correct ONFI chip size detection for LUN count > 1

[Rafael Beims]

Doing some tests with the new fsl_elbc code that enables the use of ONFI
chip detection, I verified that one of the NAND chip's we use report a
LUN count > 1.
The size detection code doesn't take this into account, making these
chips to have the wrong size detected.
This patch corrected the problem, but I don't know if this would be the
best solution.
Any comments are appreciated.
-- Rafael


Rafael Beims (1):
  nand: Support ONFI chip size detection for lun_count > 1

 drivers/mtd/nand/nand_base.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] nand: Support ONFI chip size detection for lun_count > 1

[Rafael Beims]

With the implementation of the fsl_elbc_nand driver that supports
reading the ONFI parameter page, at least one of the NAND chip's started
to have the size being wrongly reported.
This is due to the fact that this chip reports having more than one LUN,
and this was not being taken into account in the current ONFI detection
code.
Signed-off-by: Rafael Beims 
---
 drivers/mtd/nand/nand_base.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index bfd668f..3dd4dd6 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2573,7 +2573,8 @@ static int nand_flash_detect_onfi(struct
mtd_info *mtd, struct nand_chip *chip,
mtd->writesize = le32_to_cpu(p->byte_per_page);
mtd->erasesize = le32_to_cpu(p->pages_per_block) * mtd->writesize;
mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
-   chip->chipsize = (uint64_t)le32_to_cpu(p->blocks_per_lun) *
mtd->erasesize;
+   chip->chipsize = (uint64_t)le32_to_cpu(p->blocks_per_lun) *
+   p->lun_count * mtd->erasesize;
*busw = 0;
if (le16_to_cpu(p->features) & 1)
*busw = NAND_BUSWIDTH_16;
-- 
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH] net: nfs: make NFS_TIMEOUT configurable

[Tetsuyuki Kobayashi]

Hello Joe, thanks to responding.

On 2012/07/03, at 22:47, Joe Hershberger wrote:

> 
> 
> On Jul 3, 2012, at 6:22 AM, Tetsuyuki Kobayashi  wrote:
> 
>> NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs 
>> to adjust.
>> This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in 
>> a board specific config file.
>> 
>> Signed-off-by: Tetsuyuki Kobayashi 
>> ---
>> Hello, 
>> 
>> I made a patch from Joe's idea.
>> 
>> net/nfs.c |5 +
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/net/nfs.c b/net/nfs.c
>> index 5b99763..6e65c5a 100644
>> --- a/net/nfs.c
>> +++ b/net/nfs.c
>> @@ -31,7 +31,12 @@
>> 
>> #define HASHES_PER_LINE 65/* Number of "loading" hashes per line*/
>> #define NFS_RETRY_COUNT 30
>> +#ifdef CONFIG_NFS_TIMEOUT
>> +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT
>> +#error ""
> 
> Why error?
> 
Oh, I'm sorry. It is mistake. I checked both case inserting #error and forgot 
to remove..
I will post V2.

>> +#else
>> #define NFS_TIMEOUT 2000UL
>> +#endif
>> 
>> static int fs_mounted;
>> static unsigned long rpc_id;
>> -- 
>> 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 v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 03 July 2012 19:13
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp;
> albert.u.b...@aribaud.net; Detlev Zundel
> Subject: Re: [PATCH v2 03/14] arm/km: convert mgcoge3un target to
> km_kirkwood
> 
> On 07/03/2012 03:07 PM, Prafulla Wadaskar wrote:
> >>>
> >>> This patch makes sense to me since it since it shrinks overall
>  code.
> >>> Doe not have dependency in patch series, can be accepted if
>  outside
> >> the series.
> >>>
> >>
> >> again, but there are a lot of dependencies between 01-02 and
> 03-
> >> 04
> >> because all
> >> doing a lot in km_kirkwood.h.  So do you have any particular
> >> objections against
> >> the first two patches, beside your input for the kwbimage.cfg
> >> which
>  I
> >> answered
> >> in a different mail?
> >
> > As I suggested earlier
> >
> > You may have patch series for the bugfixes/improvements to the
>  currently supported code.
> >
> > You may have new board support as separate patch, if those have
>  dependency, get it addressed first.
> >
> > As such I do not have any objection about longer patch series
> but
> > Generally having a long patch series requires longer time to be
> >> get
>  pulled in.
> >
> 
>  so and when do you think to pull this in? AFAIK we are shortly
> >> before
>  rc1. And I
>  would like to  see this in, everything was published before the
> >> merge
>  window was
>  closed and we have reacted on every input you gave. But we can't
> >> react
>  on inputs
>  which are not clearly stated.
> 
>  So how do we proceed here to get this in for v2012.07? If I
> >> summarize
>  the
>  situation you don't have any particular objections against 01-08
> of
>  this series.
>  So should I resend these eight patches as a standalone serie to
> get
> >> at
>  least
>  these patches in?
> >>>
> >>> Yes, Please send the patch series for bug fix and improvements
> ONLY,
> >> I will pull them ASAP.
> >>>
> >>> The others we can converge soon.
> >>>
> >>
> >> But 01-08 are not only bugfixes there are also two new boards in
> these
> >> patches.
> >> So will you pull these eight patches in if I post them again
> without
> >> 09-14?
> >
> > Pls post bug fixes and improvement patches first those will be
> pulled faster.
> >
> This was already done from my side:
> http://lists.denx.de/pipermail/u-boot/2012-May/125219.html
> 
> Sorry Prafulla but I have admit that this whole discussion costs a lot
> of time
> which I do not have. We are moving in circles your last comment was
> already
> discussed several times e.g.:
> http://lists.denx.de/pipermail/u-boot/2012-June/126081.html

Dear Hogler

Do you think I should pull this patch series, I hope it applies cleanly on the 
recent master branch.
Please confirm.

> 
> So again you have no specific inputs of improvements for 01-08 right?
> All you
> rephrase are some general comments which are not very helpfull to
> improve our
> situation and to get our own board code into mainline.

Well.. we can keep discussing patches here until all the patches in the patch 
series gets acked.
This adds time/cost to the developer and reviewer too.
My old experience tells me that shorter is simpler and easier to accept.

I personally don't wish to hold any thing that sounds good to me.
The idea is how the development can be shared across the community.

So I had certain questions in my mind about your development for which I don't 
want any answers. You can treat them as feedback for your future development.

1. Why do you modify the board parameters so frequently? I see several patches 
for these, cant you freeze all this well before posting board support patch?
2. Why do you use your own keymile-common.h, can't you migrate to use 
mv_common.h which mainly created for the same purpose?
3. When you support any generic peripheral can't you think of generic use case?

> 
> We try to stick to every rule which is valid for u-boot development.
> But we
> can't stick to rules which are not clearly stated.

You better can have your own world, and maintain the code the way you want, not 
necessarily you need u-boot for this.

We both have different thinking hats :-D
In your view, your code is important to get mainlined, may be you don't care 
other things.
In my view, how any support can be added in simpler, shorter, reusable, cleaner 
way in-sync with development strategy. I am just trying to follow this.
I might have done mistakes, I express grand SORRY for that :-(

I am always there to help everybody with my limited resources and time.

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

Re: [U-Boot] environment access before relocation does not work on (some) arm

[Matthias Fuchs]

Hi,

On 29.06.2012 13:26, Wolfgang Denk wrote:
> Dear Matthias Fuchs,
> 
> In message <4fed7877.2020...@esd.eu> you wrote:
>>
>> I just noticed that using getenv (and friends)
>> does not work on ARM (namely i.MX28) from board_init_f()
>> after running through the init_sequence.
> 
> This is normal, and documented.  Before relocation, you must not use
> getenv().  
Yes, I am aware of this. I even think that the getenv() implementation
falls back to getenv_f() before relocation.
> 
>> Env access does not work before env_relocate() in board_init_r().
> 
> It does, but you have to play by the rules, i. e. use getenv_f()
> instead.
Yes, I did not care about where my env comes from :-) So env_sf.c does
not support an early env at all. Running on an i.MX28 with env in a SPI
flash I probably need SPI support in my SPL and an improved env_sf.c.

... and all this to get CONFIG_PRAM working in arch/arm/lib/board.c.
So I will stuck at using a constant pram value for the moment. This works.
> 
>> Didn't this behave different sometimes before? Even after the big
>> env rework?
> 
> No. The use of getenv() before relocation has never been supported.
> It may have worked (by pure chance) on some systems, but that's all.
Of course. My question was not very precise.

Matthias

> 
> Best regards,
> 
> Wolfgang Denk
> 

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

Re: [U-Boot] [PATCH 0/6 V3] EXYNOS5: USB: Enable USB 2.0 support

[Vivek Gautam]

Hi  Joonyoung Shim,

We are currently working on this.
We also needed stack support for xhci in U-boot. So both tasks are going on
simultaneously, the stack as well as USB 3.0 DRD controller for exynos5250.
Will soon come with the required support patchesets.

Thanks
Vivek

On Tue, Jul 3, 2012 at 3:41 PM, Rajeshwari Birje  wrote:

> Hi Joonyoung Shim,
>
> Yes, Vivek Gautam is working on the same.
> He might let you know the progress of the same.
>
> Regards,
> Rajeshwari Shinde.
>
>
> On Tue, Jul 3, 2012 at 3:24 PM, Joonyoung Shim  wrote:
> > Hi, Rajeshwari,
> >
> > 2012/5/8 Rajeshwari Shinde :
> >> This patchset series adds support to enable USB 2.0 on smdk5250.
> >
> > Do you have any plan to support USB 3.0 DRD Controller of Exynos5250?
> >
> > Thanks.
> >
> >> It corrects sysreg register, usb host, usb otg base address,
> >> adds power management registers,functions to enable and disable power
> >> to the USB host controller are added.
> >>
> >> This patchset is based on:
> >> USB: EXYNOS: Add ehci support.patch
> >>
> >> Rajeshwari Shinde (6):
> >>   EXYNOS5: Fix system register structure
> >>   EXYNOS5: Add structure for PMU registers
> >>   USB: EXYNOS: Set USB 2.0 HOST Link mode
> >>   EXYNOS: Add power Enable/Disable for USB-EHCI
> >>   EXYNOS5: USB: Fix incorrect USB base addresses
> >>   CONFIG: EXYNOS5: USB: Enable USB 2.0 on smdk5250
> >>
> >> Reviewed-by: Lukasz Majewski 
> >>
> >>  arch/arm/cpu/armv7/exynos/power.c |   22 +
> >>  arch/arm/cpu/armv7/exynos/system.c|   22 +
> >>  arch/arm/include/asm/arch-exynos/cpu.h|4 +-
> >>  arch/arm/include/asm/arch-exynos/power.h  |  626
> +
> >>  arch/arm/include/asm/arch-exynos/system.h |4 +
> >>  drivers/usb/host/ehci-exynos.c|8 +
> >>  include/configs/smdk5250.h|6 +
> >>  7 files changed, 690 insertions(+), 2 deletions(-)
> >>
> >> --
> >> 1.7.4.4
> >>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> http://lists.denx.de/mailman/listinfo/u-boot
> >
> >
> >
> > --
> > - Joonyoung Shim
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] igep00x0: default mmcrootfstype to EXT4

[Enric Balletbò i Serra]

2012/6/29 Javier Martinez Canillas 

> omap2plus_defconfig now has built-in compile support for EXT4 enabled
> by default now. So, we can use EXT4 as the default root file system
> type for MMC.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  include/configs/igep00x0.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 62b4afc..a0a23a7 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -142,7 +142,7 @@
> "defaultdisplay=dvi\0" \
> "mmcdev=0\0" \
> "mmcroot=/dev/mmcblk0p2 rw\0" \
> -   "mmcrootfstype=ext3 rootwait\0" \
> +   "mmcrootfstype=ext4 rootwait\0" \
> "nandroot=/dev/mtdblock4 rw\0" \
> "nandrootfstype=jffs2\0" \
> "mmcargs=setenv bootargs console=${console} " \
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Resend with acked line to patchwork picks it up automatically. Sorry for
the noise

Acked-by: Enric Balletbo i Serra 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] igep00x0: default to OMAP-specific serial driver

[Enric Balletbò i Serra]

2012/6/29 Javier Martinez Canillas 

> An OMAP specific serial driver was merged on the Linux kenel a long
> time ago. So, it makes sense to default the console name to OMAP
> ttyO instead of the generic ttyS naming.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  include/configs/igep00x0.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 88e2e3a..62b4afc 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -135,7 +135,7 @@
> "usbtty=cdc_acm\0" \
> "loadaddr=0x8200\0" \
> "usbtty=cdc_acm\0" \
> -   "console=ttyS2,115200n8\0" \
> +   "console=ttyO2,115200n8\0" \
> "mpurate=auto\0" \
> "vram=12M\0" \
> "dvimode=1024x768MR-16@60\0" \
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Resend with acked line to patchwork picks it up automatically. Sorry for
the noise

Acked-by: Enric Balletbo i Serra 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 05/15] tegra20: make board mkdir commands unconditional

[Stephen Warren]

On 07/02/2012 11:52 PM, Allen Martin wrote:
> Change the mkdir commands for the object directories to be
> unconditional.  This fixes an issue when building for SPL where
> SRCTREE and OBJTREE are the same, but $(obj) is under SPLTREE.
> 
> Signed-off-by: Allen Martin 

All the patches which weren't already acked by me, now:
Acked-by: Stephen Warren 

Well, the ones which were already acked by me still are too:-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/mpc83xx: increment malloc heap size

[Kim Phillips]

On Sat, 30 Jun 2012 18:29:20 -0500
Kim Phillips  wrote:

> extention of commit 3b6b256 "powerpc/mpc83xx: increment
> malloc heap size for the MPC832x MDS boards" to all other
> mpc83xx based boards.  It fixes "Unable to save the rest
> of sector" messages when trying to save the environment
> to flash.
> 
> Signed-off-by: Kim Phillips 
> ---

applied, thanks.

Kim

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

[U-Boot] [GIT PULL] mpc83xx: minor fixes

[Kim Phillips]

Wolfgang Denk,

Please pull a couple of minor fixes for 83xx:

The following changes since commit 558cd995d6d3eaa94fb342d142289a1fa2f76ba3:

  tools/mkenvimage.c: fix basename(3) usage (2012-07-02 20:21:49 +0200)

are available in the git repository at:

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

for you to fetch changes up to c8a90646adb1c7ca82e856c603ec964b32759d98:

  powerpc/mpc83xx: increment malloc heap size (2012-07-03 11:07:21 -0500)


Kim Phillips (1):
  powerpc/mpc83xx: increment malloc heap size

Timur Tabi (1):
  powerpc/mpc83xx: fix copyright string in serdes.c

 arch/powerpc/cpu/mpc83xx/serdes.c | 2 +-
 include/configs/MPC8323ERDB.h | 2 +-
 include/configs/MPC8349EMDS.h | 2 +-
 include/configs/MPC8349ITX.h  | 2 +-
 include/configs/MPC8360EMDS.h | 2 +-
 include/configs/MPC8360ERDK.h | 2 +-
 include/configs/sbc8349.h | 2 +-
 include/configs/vme8349.h | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

Thanks,

Kim

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

[U-Boot] [PATCH] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Kim Phillips]

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function 
[-Wuninitialized]

Cc: Jason Cooper 
Signed-off-by: Kim Phillips 
---
is this right?

 fs/ext2/ext2fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..c6c950e 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -440,7 +440,7 @@ int ext2fs_read_file
/* grab middle blocks in one go */
if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
int oldblk = blknr;
-   int blocknxt;
+   int blocknxt = 0;
while (i < blockcnt - 1) {
blocknxt = ext2fs_read_block(node, i + 1);
if (blocknxt == (oldblk + 1)) {
-- 
1.7.11.1


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

Re: [U-Boot] [PATCH] powerpc/mpc83xx: fix copyright string in serdes.c

[Kim Phillips]

On Mon, 18 Jun 2012 19:11:34 -0500
Timur Tabi  wrote:

> The misspelling of "semiconductor" causes some internal copyright analysis
> tools to complain.
> 
> Signed-off-by: Timur Tabi 
> ---

applied, thanks.

Kim

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

Re: [U-Boot] [PATCH v6 00/15] split tegra20 arm7 code into separate SPL

[Allen Martin]

On Tue, Jul 03, 2012 at 06:55:48AM -0700, Thierry Reding wrote:
>
> ...
> 
> Successfully booted to login prompt on TEC.
> 
> Tested-by: Thierry Reding 

That's great news, it sounds like it was the USE_PRIVATE_LIBGCC
problem.  Thank you very much for finding that and testing the fix.

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

[U-Boot] [PATCH] imx: Remove unused Macro CONFIG_DISCOVER_PHY

[Ashok]

From 9da2bc23d24f9275390c193d62e2e95d3d7505ce Mon Sep 17 00:00:00 2001
From: Ashok Kumar Reddy 
Date: Tue, 3 Jul 2012 21:41:04 +0530
Subject: [PATCH] imx: Remove unused Macro CONFIG_DISCOVER_PHY

Remove the macro as this is not used anywhere

Signed-off-by: Ashok Kumar Reddy Kourla 
---
 include/configs/flea3.h |1 -
 include/configs/ima3-mx53.h |1 -
 include/configs/m28evk.h|1 -
 include/configs/mx28evk.h   |1 -
 include/configs/mx35pdk.h   |1 -
 include/configs/mx51evk.h   |1 -
 include/configs/mx53ard.h   |1 -
 include/configs/mx53evk.h   |1 -
 include/configs/mx53loco.h  |1 -
 include/configs/mx53smd.h   |1 -
 include/configs/vision2.h   |1 -
 11 files changed, 11 deletions(-)

diff --git a/include/configs/flea3.h b/include/configs/flea3.h
index 6c5fcac..ba5d44f 100644
--- a/include/configs/flea3.h
+++ b/include/configs/flea3.h
@@ -119,7 +119,6 @@
 #define CONFIG_FEC_MXC_PHYADDR 0x1

 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_ARP_TIMEOUT 200UL

diff --git a/include/configs/ima3-mx53.h b/include/configs/ima3-mx53.h
index 17fa4a1..82a62ba 100644
--- a/include/configs/ima3-mx53.h
+++ b/include/configs/ima3-mx53.h
@@ -64,7 +64,6 @@
 /* Ethernet on FEC */
 #define CONFIG_NET_MULTI
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 3abaadc..918b462 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -197,7 +197,6 @@
 #defineCONFIG_FEC_MXC
 #defineCONFIG_FEC_MXC_MULTI
 #defineCONFIG_MII
-#defineCONFIG_DISCOVER_PHY
 #defineCONFIG_FEC_XCV_TYPE RMII
 #endif

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 51b172d..b36c123 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -166,7 +166,6 @@
 #define CONFIG_FEC_MXC
 #define CONFIG_FEC_MXC_MULTI
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY
 #define CONFIG_FEC_XCV_TYPERMII
 #define CONFIG_MX28_FEC_MAC_IN_OCOTP
 #endif
diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h
index 016864a..8324005 100644
--- a/include/configs/mx35pdk.h
+++ b/include/configs/mx35pdk.h
@@ -134,7 +134,6 @@
 #define CONFIG_FEC_MXC_PHYADDR 0x1F

 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_ARP_TIMEOUT 200UL

diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index bd04c02..ef06d78 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -99,7 +99,6 @@
  */
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index f4512ff..d11022c 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -69,7 +69,6 @@
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
 #define CONFIG_MII_GASKET
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_CMD_PING
 #define CONFIG_CMD_DHCP
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index a5f32e3..d13b2d7 100644
--- a/include/configs/mx53evk.h
+++ b/include/configs/mx53evk.h
@@ -78,7 +78,6 @@
 /* Eth Configs */
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index 8b4e008..726186e 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -63,7 +63,6 @@
 /* Eth Configs */
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
diff --git a/include/configs/mx53smd.h b/include/configs/mx53smd.h
index 0d7086d..dfa4301 100644
--- a/include/configs/mx53smd.h
+++ b/include/configs/mx53smd.h
@@ -68,7 +68,6 @@
 /* Eth Configs */
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index 24905a0..50af323 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -122,7 +122,6 @@
  */
 #define CONFIG_HAS_ETH1
 #define CONFIG_MII
-#define CONFIG_DISCOVER_PHY

 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   FEC_BASE_ADDR
--
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] imx: Remove unused Macro CONFIG_DISCOVER_PHY

[Fabio Estevam]

On Tue, Jul 3, 2012 at 1:52 PM, Ashok  wrote:
> From 9da2bc23d24f9275390c193d62e2e95d3d7505ce Mon Sep 17 00:00:00 2001
> From: Ashok Kumar Reddy 
> Date: Tue, 3 Jul 2012 21:41:04 +0530
> Subject: [PATCH] imx: Remove unused Macro CONFIG_DISCOVER_PHY
>
> Remove the macro as this is not used anywhere
>
> Signed-off-by: Ashok Kumar Reddy Kourla 

I have already sent a patch for this:
http://patchwork.ozlabs.org/patch/152329/

Regards,

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

[U-Boot] [PATCH 1/1] igep0020: set OMAP MUX mcspi1_cs2 pin to GPIO 176 mode

[Javier Martinez Canillas]

According to the IGEPv2 Rev.C data-sheet the LAN9221i pin 14 (IRQ) is
connected to the OMAP3730 mcspi1_cs2 pin. Since this omap mux pin acts
as an IRQ line, it has to be configured as an input GPIO.

IGEPv2 platform code sets the smsc911x_cfg->gpio_irq to GPIO 176 but
since the mux pin default mode is MODE7 (safe_mode) the driver fails
when trying to register the IRQ:

[1.994598] smsc911x: Driver version 2008-10-21
[3.704162] irq 272: nobody cared (try booting with the "irqpoll" option)
[3.711364] [] (unwind_backtrace+0x0/0xf0) from [] 
(__report_bad_irq+0x20/0xbc)
[3.720916] [] (__report_bad_irq+0x20/0xbc) from [] 
(note_interrupt+0x1d8/0x238)
[3.730560] [] (note_interrupt+0x1d8/0x238) from [] 
(handle_irq_event_percpu+0xc0/0x260)
[3.740936] [] (handle_irq_event_percpu+0xc0/0x260) from 
[] (handle_irq_event+0x3c/0x5c)
[3.751312] [] (handle_irq_event+0x3c/0x5c) from [] 
(handle_level_irq+0xac/0x10c)
[3.761047] [] (handle_level_irq+0xac/0x10c) from [] 
(generic_handle_irq+0x30/0x48)
[3.770935] [] (generic_handle_irq+0x30/0x48) from [] 
(gpio_irq_handler+0x180/0x1d4)
[3.780944] [] (gpio_irq_handler+0x180/0x1d4) from [] 
(generic_handle_irq+0x30/0x48)
[3.790954] [] (generic_handle_irq+0x30/0x48) from [] 
(handle_IRQ+0x4c/0xac)
[3.800231] [] (handle_IRQ+0x4c/0xac) from [] 
(omap3_intc_handle_irq+0x60/0x74)
[3.809783] [] (omap3_intc_handle_irq+0x60/0x74) from [] 
(__irq_svc+0x44/0x60)
[3.819213] Exception stack(0xee42fde0 to 0xee42fe28)
[3.824554] fde0: 0001 0001   6013 c06cce14 
c06cce14 0110
[3.833190] fe00:  c06ccdf4 6013 ee41d000 fb058064 ee42fe28 
c0089e08 c04976b4
[3.841796] fe20: 2013 
[3.845489] [] (__irq_svc+0x44/0x60) from [] 
(_raw_spin_unlock_irqrestore+0x34/0x44)
[3.855499] [] (_raw_spin_unlock_irqrestore+0x34/0x44) from 
[] (__setup_irq+0x1b8/0x3f0)
[3.865875] [] (__setup_irq+0x1b8/0x3f0) from [] 
(request_threaded_irq+0xb8/0x140)
[3.875701] [] (request_threaded_irq+0xb8/0x140) from [] 
(smsc911x_drv_probe+0x75c/0x11a4)
[3.886260] [] (smsc911x_drv_probe+0x75c/0x11a4) from [] 
(platform_drv_probe+0x18/0x1c)
[3.896545] [] (platform_drv_probe+0x18/0x1c) from [] 
(driver_probe_device+0x90/0x210)
[3.906707] [] (driver_probe_device+0x90/0x210) from [] 
(__driver_attach+0x94/0x98)
[3.916625] [] (__driver_attach+0x94/0x98) from [] 
(bus_for_each_dev+0x50/0x7c)
[3.926177] [] (bus_for_each_dev+0x50/0x7c) from [] 
(bus_add_driver+0x184/0x248)
[3.935821] [] (bus_add_driver+0x184/0x248) from [] 
(driver_register+0x78/0x12c)
[3.945465] [] (driver_register+0x78/0x12c) from [] 
(do_one_initcall+0x34/0x178)
[3.955108] [] (do_one_initcall+0x34/0x178) from [] 
(kernel_init+0xfc/0x1c0)
[3.964385] [] (kernel_init+0xfc/0x1c0) from [] 
(kernel_thread_exit+0x0/0x8)
[3.973632] handlers:
[3.976043] [] smsc911x_irqhandler
[3.980560] Disabling IRQ #272

Signed-off-by: Javier Martinez Canillas 
---
 board/isee/igep0020/igep0020.h |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h
index 3d6e15f..eb1aa30 100644
--- a/board/isee/igep0020/igep0020.h
+++ b/board/isee/igep0020/igep0020.h
@@ -143,5 +143,6 @@ static void setup_net_chip(void);
MUX_VAL(CP(SYS_BOOT5),  (IEN  | PTD | DIS | M4)) /* GPIO_7 */\
MUX_VAL(CP(SYS_BOOT6),  (IEN  | PTD | DIS | M4)) /* GPIO_8 */\
MUX_VAL(CP(SDRC_CKE0),  (IDIS | PTU | EN  | M0)) /* SDRC_CKE0 */\
-   MUX_VAL(CP(SDRC_CKE1),  (IDIS | PTU | EN  | M0)) /* SDRC_CKE1 */
+   MUX_VAL(CP(SDRC_CKE1),  (IDIS | PTU | EN  | M0)) /* SDRC_CKE1 */\
+   MUX_VAL(CP(MCSPI1_CS2), (IEN  | PTD | DIS | M4)) /* GPIO_176-ETH 
IRQ */
 #endif
-- 
1.7.7.6

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

Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Wolfgang Denk]

Dear Prafulla,

In message  
you wrote:
> 
> Do you think I should pull this patch series, I hope it applies cleanly on 
> the recent master branch.
> Please confirm.

I have to admit that I neither reviewed the patches in question, nor
did I follow the whole thread of communication in this patch series.
But the general rule is that if there are no strong argumentents
against a patch (like a clear NAK or a specific request for changes)
we will apply it.

> 1. Why do you modify the board parameters so frequently? I see
> several patches for these, cant you freeze all this well before
> posting board support patch?

Actually it's this question which triggered my reply.  From a
developer's point of view it makes a lot of sense to push patches
upstream as soon as possible, to have at least the major bunch of code
maintained with the mainline source tree, even if board configuration
and other board specific code still needs to be changed.

We all complain frequently aboutquestions for obsolete code in some
out-of-tree ports, so we should strongly support such early patch
submissions, and not discourage it.

And frankly, as long as its strictly board specific code only, we
don't even have to care if it works.  

> 2. Why do you use your own keymile-common.h, can't you migrate to
> use mv_common.h which mainly created for the same purpose?

Probably for the same reasons: patches get submitted early, when
configurationhas not stabilized yet, and it's much easier for all
involved parties to change some board or vendor specific file instead
of one that gets used for the whole architecture.

> 3. When you support any generic peripheral can't you think of generic use 
> case?
> 
> >
> > We try to stick to every rule which is valid for u-boot development.
> > But we
> > can't stick to rules which are not clearly stated.
> 
> You better can have your own world, and maintain the code the way
> you want, not necessarily you need u-boot for this.

I don't understand what you mean here.  As a custodian you have a
responsibility to support a submitter.  Yes, this may include that you
reject incorrect code, maybe even if it's only violating the Coing
Style.  But from what I've seen so far I think Keymile really strives
hard to play by the rules.

If there are violations of any documented rules, then please say so
clearly, and NAK the patch.  If there are other things that should be
fixed, where rules are not clear, then we should discuss the problem,
the way how we would like to see this fixed, and document these new
rules for future cases.

> In your view, your code is important to get mainlined, may be you
> don't care other things.

In our view it is also important to get this code mainlined, as it is
always important to help users to have their submissions mainlined.
This is one of the major responsibilities of us maintainers to the
community.  If we were free to ignore the users, we would probably
quickly be free of any community, too.

> In my view, how any support can be added in simpler, shorter,
> reusable, cleaner way in-sync with development strategy. I am just
> trying to follow this.

The question is how many iterations really make sense.  In this case
there appear to have been too many already.  If there are no clear,
hard deficiencies in the code that need fixing, then I think we have
to put an end to such dicussions earlier.

> I might have done mistakes, I express grand SORRY for that :-(
> 
> I am always there to help everybody with my limited resources and time.

We all apprecate your efforts. Please don't misunderstand me, I don't
intend to interfere with your job as a custodian here. You just
happen to trigger my message whichis actually directed to all
custodians: please help to get patches accepted, for the sake of
encouraging users to submit their code. If we frighten off such users,
all sides lose - the users, and us.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
As far as the laws of mathematics refer to reality, they are not cer-
tain, and as far as they are certain, they do not refer  to  reality.
   -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] environment access before relocation does not work on (some) arm

[Wolfgang Denk]

Dear Matthias Fuchs,

In message <4ff306fc.9040...@esd.eu> you wrote:
> 
> > This is normal, and documented.  Before relocation, you must not use
> > getenv().  
> Yes, I am aware of this. I even think that the getenv() implementation
> falls back to getenv_f() before relocation.

This is not guaranteed to work.

> Yes, I did not care about where my env comes from :-) So env_sf.c does
> not support an early env at all. Running on an i.MX28 with env in a SPI
> flash I probably need SPI support in my SPL and an improved env_sf.c.

This is a bigger topic.  We all wait anxiously for Mareks group to
implement a clean device driver model, so we can clean up and unify
all this code.  I am aware that it needs it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Remember, Information is not knowledge;  Knowledge  is  not  Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is
not music; Music is the best."  - Frank Zappa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb_storage: fix ehci driver max transfer size

[Marek Vasut]

Dear Stefan Herbrechtsmeier,

> The commit 5dd95cf93dfffa1d19a1928990852aac9f55b9d9 'usb_storage:
> Fix EHCI "out of buffer pointers" with CD-ROM' introduce a bug in
> usb_storage as it wrongly assumes that every transfer can use 4k
> per qt_buffer. This is wrong if the start address of the data
> is not 4k aligned and leads to 'EHCI timed out on TD' messages
> because of 'out of buffer pointers' in ehci_td_buffer function.
> 
> Cc: Marek Vasut 
> Signed-off-by: Stefan Herbrechtsmeier 

Ok, first I have to admit I broke my promise to look into this ASAP, sorry 
about 
it :-(

Just curious, but shouldn't it be ((4096 * 5) / dev_desc->blk_sz) - 1 ?

> ---
>  common/usb_storage.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index faad237..612a553 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -1416,10 +1416,10 @@ int usb_stor_get_info(struct usb_device *dev,
> struct us_data *ss, USB_STOR_PRINTF("partype: %d\n", dev_desc->part_type);
> 
>   /*
> -  * The U-Boot EHCI driver cannot handle more than 4096 * 5 bytes in a
> -  * transfer without running itself out of qt_buffers.
> +  * The U-Boot EHCI driver cannot handle more than 4096 * 4 bytes in a
> +  * unaligned transfer without running itself out of qt_buffers.
>*/
> - ss->max_xfer_blk = (4096 * 5) / dev_desc->blksz;
> + ss->max_xfer_blk = (4096 * 4) / dev_desc->blksz;
> 
>   init_part(dev_desc);

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

Re: [U-Boot] Issue with running commands

[Sughosh Ganu]

hi Christian,

On Tue, Jul 3, 2012 at 11:52 AM, Christian Riesch <
christian.rie...@omicron.at> wrote:

> Hi Sughosh,
>
> On Mon, Jul 2, 2012 at 9:24 PM, Sughosh Ganu 
> wrote:
> > hi,
> > While testing on hawkboard with the latest commit, i hit an issue of
> > commands not being accepted.
> >
> > hawkboard > rese
> > Unknown command '�' - try 'help'
> > hawkboard >
> >
> > Running git bisect showed that this is caused due to commit 054ea170f271:
> > cmd_mem: cmp: unify size code paths. Has anyone seen this issue -- i
> don't
> > think this is board/arch specific.
>
> I tried to reproduce this on the calimain board (AM1808 SoC), but
> without success. The reset command works fine with current mainline
> u-boot.
>

Thanks for testing this. This looks to be some kind of an alignment issue
on my board, which is getting introduced due to the commit i mentioned. The
said commit is not directly responsible for the problem, but it introduces
some kind of misalignment. I am looking into this -- at such times i so
dearly wish i had a jtag debugger :)

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

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi,

On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz  wrote:

> Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> > On 06/29/2012 04:32 AM, Simon Glass wrote:
> > > Hi,
> > >
> > > --snip--
> >
> > I have sent support for Microblaze. Currently without dts because I want
> to clear this part a little bit.
>
> Hi Michal,
>
> looks good, I've been waiting a long time on the FDT support in U-Boot
> for Microblaze -- great -- PS: see my comment on patch 5 ...
>
> >
> > Tegra is using ./arch/arm/dts/tegra20.dtsi and
> board/nvidia/dts/tegra2-seaboard.dts
> > and they are composed together in dts/Makefile by calling preprocessor.
> > Microblaze will be totally different case because every Microblaze hw
> design is different.
>
> Yes, that's right. We will never be in the position to define a skeleton
> or a basic platform configuration.
>
> > We can use two main buses (little and big endian) and cpu is also
> configurable.
> > Based on this for Microblaze is the best solution directly to use dts.
> > (DTS for Microblaze is also generated directly from design tool).
>
> ... directly in the context of a board, not arch/cpu, right?
>
> >
> >
> > Anyway - here is the bug message I am getting if I use full dts in
> board//dts/microblaze.dts
> > and empty arch/microblaze/dts/microblaze.dtsi
> >
> > :34:3: error: invalid preprocessing directive #address
> > :35:3: error: invalid preprocessing directive #size
> > :52:4: error: invalid preprocessing directive #address
> > :53:4: error: invalid preprocessing directive #cpus
> > :54:4: error: invalid preprocessing directive #size
> > :155:4: error: invalid preprocessing directive #address
> > :156:4: error: invalid preprocessing directive #size
> > :160:5: error: invalid preprocessing directive #gpio
> > :192:5: error: invalid preprocessing directive #gpio
> > :209:5: error: invalid preprocessing directive #gpio
> > :241:5: error: invalid preprocessing directive #gpio
> > :267:5: error: invalid preprocessing directive #address
> > :268:5: error: invalid preprocessing directive #size
> > :394:5: error: invalid preprocessing directive #interrupt
> >
> > This is error for opposite case - empty microblaze.dts and full
> microblaze.dtsi.
>
> That are CPP errors, because the auto generated xilinx.dts is full of
> CPP pragma like syntax (#something) that are wrong (invalid).
>

Yes - we want to move away from this and use a newer dtc which supports -i
for include files, but can't yet. Stephen Warren suggested including the
new dtc inside the U-Boot tree.


> >
> > make[1]: Entering directory `/mnt/projects/u-boot/dts'
> > rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts |
> microblaze-unknown-linux-gnu-gcc -E
> > -P
> -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> - | { { dtc -R 4 -p 0x1000
> > -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb  on
> file' ; } 3>&1 ) ; \
> >   exit $rc
> > /bin/sh: line 1: exit: too many arguments
> > make[1]: *** [dt.dtb] Error 1
> > make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> >
> >
> > I have just tried to fix it by introducing new CONFIG option for
> skipping that preprocessor
> > part.
>
> Instead of disable / skipp the CPP step you can hide the auto generated
> xilinx.dts with a second include stage, for example:
>
> board/microblaze/dts/microblaze.dts looks like:
>
> /include/ ARCH_CPU_DTS
> /include/ BOARD_DTS
>
>
> Right, only two lines.   The arch/microblaze/dts/microblaze.dtsi remains
> empty as you have said above. Just new is BOARD_DTS -- with the attached
> patch for dts/Makefile you can copy the auto generated xilinx.dts into
> the specific board directory and the CPP step substitute the right place
> to board/microblaze/microblaze-generic/dts/microblaze.dts
>
> I think there are no side effects with other ports like the tegra2.
>
> If you want you can omit the ARCH_CPU_DTS inclusion. The architectural
> microblaze.dtsi file is empty and (!!) have to be empty, because the DTC
> will break with an error on multiple "/dts-v1/;" lines!
>
> Here is the patch:
>
> diff --git a/dts/Makefile b/dts/Makefile
> index 914e479..b1f47a1 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> support enabled. \
> Please define CONFIG_ARCH_DEVICE_TREE))
>
> # We preprocess the device tree file provide a useful define
> -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> +   -DBOARD_DTS=
> \"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
>
> all:   $(obj).depend $(LIB)
>

I suppose this is ok. Really the better plan would be to use -i and specify
the various directories where we can get include files. But for now, ok.

Regards,
Simon

>
>
> br,
> Stephan
>
> > It will be good for Microblaze (probably there is any smar

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi,

On Tue, Jul 3, 2012 at 2:21 AM, Michal Simek  wrote:

> On 06/29/2012 04:32 AM, Simon Glass wrote:
>
>> Hi,
>>
>>
>> On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek > mon...@monstr.eu>> wrote:
>>
>> On 06/28/2012 07:57 AM, Simon Glass wrote:
>>
>> Hi Michal,
>>
>>
>> On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek 
>> > mon...@monstr.eu> >>
>> wrote:
>>
>> Hi Simon,
>>
>>
>> On 06/28/2012 03:10 AM, Simon Glass wrote:
>>
>> Hi Michal,
>>
>>
>> On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <
>> mon...@monstr.eu   mon...@monstr.eu>> 
>> >
>> Hi Simon,
>>
>>
>> On 06/27/2012 03:58 PM, Simon Glass wrote:
>>
>> Hi,
>>
>>
>> On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <
>> mon...@monstr.eu   mon...@monstr.eu>> 
>> >> > mon...@monstr.eu   mon...@monstr.eu>> 
>>  wrote:
>>
>> Hi,
>>
>> can you please update me about current state
>> of CONFIG_OF_CONTROL for ARM?
>> Are there any other archs/boards which will
>> use this option?
>>
>> Or any other git repo out of mainline u-boot?
>>
>>
>> Exynos is in progress - development is happening
>> in the Chromium tree and being upstreamed in chunks (although no fdt
>> patches have been sent yet).
>>
>>
>> ok.
>>
>>
>>
>>
>> Has someone tried to look for devices based
>> on compatible property?
>> I see that in usb driver it is based on
>> aliases which is not the best solution.
>>
>>
>> U-Boot doesn't yet have a device model which
>> would allow this in the general case. For now, drivers look for their own
>> compatible nodes. This works well enough until we have a device model.
>>
>> There are other limitations also - for example
>> USB supports only a single controller type working at one time (a
>> restriction we may need to look at to support USB2 and USB3 together). So
>> even if two USB drivers decided that they both found compatible nodes, only
>> one of them could operate. So for now aliases provide just an ordering,
>> nothing else.
>>
>>
>>
>> I have looked at the code and did some tests on
>> Microblaze.
>>
>> Firstly I have tried to change emaclite ethernet
>> initialization and I ended with this code fragment which could be
>> broadly used by other drivers.
>>
>> int offset = 0;
>> do {
>> offset =
>> fdt_node_offset_by_compatible(**__gd->fdt_blob, offset,
>> "xlnx,xps-ethernetlite-1.00.a" );
>>
>>
>>
>> You could check if offset < 0 here, or
>> !fdtdec_get_is_enabled(gd->___**_fdt_blob, offset)
>>
>>
>>
>> u32 rxpp =
>> fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
>> u32 txpp =
>> fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
>> u32 reg =
>> fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);
>>
>>
>> Maybe fdtdec_get_addr()
>>
>>
>> yeah right.
>>
>>
>> do {
>> offset = 
>> fdt_node_offset_by_compatible(**gd->fdt_blob,
>> offset, "xlnx,xps-ethernetlite-1.00.a" );
>> u32 rxpp = fdtdec_get_int(gd->fdt_blob,
>> offset, "xlnx,rx-ping-pong", 0);
>> u32 txpp = fdtdec_get_int(gd->fdt_blob,
>> offset, "xlnx,tx-ping-pong", 0);
>> u32 reg = fdtdec_get_addr(gd->fdt_blob,
>> offset, "reg");
>> if (reg != FDT_ADDR_T_NONE)
>>
>> ret |= xilinx_emaclite_initialize(___
>> **_bis, reg, txpp, rxpp);
>> } while (offset != -1);
>>
>>
>>
>>
>> if (reg)
>> ret |=
>> xilinx_emaclite_initialize(___**___bis, reg, txpp, rxpp);
>>
>>
>>
>> } while (offset != -1);
>>
>> What do you think? This code is in platform file.
>>
>>
>> Seems reasonable to me.
>>
>>
>> o

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi,

On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek  wrote:

> 2012/6/29 Stephan Linz :
> > Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> >> On 06/29/2012 04:32 AM, Simon Glass wrote:
> >> > Hi,
> >> >
> >> > --snip--
> >>
> >> I have sent support for Microblaze. Currently without dts because I
> want to clear this part a little bit.
> >
> > Hi Michal,
> >
> > looks good, I've been waiting a long time on the FDT support in U-Boot
> > for Microblaze -- great -- PS: see my comment on patch 5 ...
> >
> >>
> >> Tegra is using ./arch/arm/dts/tegra20.dtsi and
> board/nvidia/dts/tegra2-seaboard.dts
> >> and they are composed together in dts/Makefile by calling preprocessor.
> >> Microblaze will be totally different case because every Microblaze hw
> design is different.
> >
> > Yes, that's right. We will never be in the position to define a skeleton
> > or a basic platform configuration.
> >
> >> We can use two main buses (little and big endian) and cpu is also
> configurable.
> >> Based on this for Microblaze is the best solution directly to use dts.
> >> (DTS for Microblaze is also generated directly from design tool).
> >
> > ... directly in the context of a board, not arch/cpu, right?
>
> yes.
>
> >
> >>
> >>
> >> Anyway - here is the bug message I am getting if I use full dts in
> board//dts/microblaze.dts
> >> and empty arch/microblaze/dts/microblaze.dtsi
> >>
> >> :34:3: error: invalid preprocessing directive #address
> >> :35:3: error: invalid preprocessing directive #size
> >> :52:4: error: invalid preprocessing directive #address
> >> :53:4: error: invalid preprocessing directive #cpus
> >> :54:4: error: invalid preprocessing directive #size
> >> :155:4: error: invalid preprocessing directive #address
> >> :156:4: error: invalid preprocessing directive #size
> >> :160:5: error: invalid preprocessing directive #gpio
> >> :192:5: error: invalid preprocessing directive #gpio
> >> :209:5: error: invalid preprocessing directive #gpio
> >> :241:5: error: invalid preprocessing directive #gpio
> >> :267:5: error: invalid preprocessing directive #address
> >> :268:5: error: invalid preprocessing directive #size
> >> :394:5: error: invalid preprocessing directive #interrupt
> >>
> >> This is error for opposite case - empty microblaze.dts and full
> microblaze.dtsi.
> >
> > That are CPP errors, because the auto generated xilinx.dts is full of
> > CPP pragma like syntax (#something) that are wrong (invalid).
>
> I know what it is.
>
> >
> >>
> >> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> >> rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts |
> microblaze-unknown-linux-gnu-gcc -E
> >> -P
> -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> - | { { dtc -R 4 -p 0x1000
> >> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb  on
> file' ; } 3>&1 ) ; \
> >>   exit $rc
> >> /bin/sh: line 1: exit: too many arguments
> >> make[1]: *** [dt.dtb] Error 1
> >> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> >>
> >>
> >> I have just tried to fix it by introducing new CONFIG option for
> skipping that preprocessor
> >> part.
> >
> > Instead of disable / skipp the CPP step you can hide the auto generated
> > xilinx.dts with a second include stage, for example:
> >
> > board/microblaze/dts/microblaze.dts looks like:
> >
> > /include/ ARCH_CPU_DTS
> > /include/ BOARD_DTS
> >
> >
> > Right, only two lines.   The arch/microblaze/dts/microblaze.dtsi remains
> > empty as you have said above. Just new is BOARD_DTS -- with the attached
> > patch for dts/Makefile you can copy the auto generated xilinx.dts into
> > the specific board directory and the CPP step substitute the right place
> > to board/microblaze/microblaze-generic/dts/microblaze.dts
> >
> > I think there are no side effects with other ports like the tegra2.
> >
> > If you want you can omit the ARCH_CPU_DTS inclusion. The architectural
> > microblaze.dtsi file is empty and (!!) have to be empty, because the DTC
> > will break with an error on multiple "/dts-v1/;" lines!
> >
> > Here is the patch:
> >
> > diff --git a/dts/Makefile b/dts/Makefile
> > index 914e479..b1f47a1 100644
> > --- a/dts/Makefile
> > +++ b/dts/Makefile
> > @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> > support enabled. \
> > Please define CONFIG_ARCH_DEVICE_TREE))
> >
> > # We preprocess the device tree file provide a useful define
> > -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> > +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> > +   -DBOARD_DTS=
> > \"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
> >
> > all:   $(obj).depend $(LIB)
>
> Not sure if using another dts file will be the best approach.
> From my point of view will be the best to support only one dts file
> (without dtsi)
> because it is much cleaner then using 3 dts files.
>

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

Hi,

Am Montag, den 02.07.2012, 07:43 +0200 schrieb Michal Simek: 
> 2012/6/29 Stephan Linz :
> > Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> >> On 06/29/2012 04:32 AM, Simon Glass wrote:
> >> > Hi,
> >> >
> >> > --snip--
> >>
> >> I have sent support for Microblaze. Currently without dts because I want 
> >> to clear this part a little bit.
> >
> > Hi Michal,
> >
> > looks good, I've been waiting a long time on the FDT support in U-Boot
> > for Microblaze -- great -- PS: see my comment on patch 5 ...
> >
> >>
> >> Tegra is using ./arch/arm/dts/tegra20.dtsi and 
> >> board/nvidia/dts/tegra2-seaboard.dts
> >> and they are composed together in dts/Makefile by calling preprocessor.
> >> Microblaze will be totally different case because every Microblaze hw 
> >> design is different.
> >
> > Yes, that's right. We will never be in the position to define a skeleton
> > or a basic platform configuration.
> >
> >> We can use two main buses (little and big endian) and cpu is also 
> >> configurable.
> >> Based on this for Microblaze is the best solution directly to use dts.
> >> (DTS for Microblaze is also generated directly from design tool).
> >
> > ... directly in the context of a board, not arch/cpu, right?
> 
> yes.
> 
> >
> >>
> >>
> >> Anyway - here is the bug message I am getting if I use full dts in 
> >> board//dts/microblaze.dts
> >> and empty arch/microblaze/dts/microblaze.dtsi
> >>
> >> :34:3: error: invalid preprocessing directive #address
> >> :35:3: error: invalid preprocessing directive #size
> >> :52:4: error: invalid preprocessing directive #address
> >> :53:4: error: invalid preprocessing directive #cpus
> >> :54:4: error: invalid preprocessing directive #size
> >> :155:4: error: invalid preprocessing directive #address
> >> :156:4: error: invalid preprocessing directive #size
> >> :160:5: error: invalid preprocessing directive #gpio
> >> :192:5: error: invalid preprocessing directive #gpio
> >> :209:5: error: invalid preprocessing directive #gpio
> >> :241:5: error: invalid preprocessing directive #gpio
> >> :267:5: error: invalid preprocessing directive #address
> >> :268:5: error: invalid preprocessing directive #size
> >> :394:5: error: invalid preprocessing directive #interrupt
> >>
> >> This is error for opposite case - empty microblaze.dts and full 
> >> microblaze.dtsi.
> >
> > That are CPP errors, because the auto generated xilinx.dts is full of
> > CPP pragma like syntax (#something) that are wrong (invalid).
> 
> I know what it is.
> 
> >
> >>
> >> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> >> rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts | 
> >> microblaze-unknown-linux-gnu-gcc -E
> >> -P 
> >> -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> >>  - | { { dtc -R 4 -p 0x1000
> >> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb  on 
> >> file' ; } 3>&1 ) ; \
> >>   exit $rc
> >> /bin/sh: line 1: exit: too many arguments
> >> make[1]: *** [dt.dtb] Error 1
> >> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> >>
> >>
> >> I have just tried to fix it by introducing new CONFIG option for skipping 
> >> that preprocessor
> >> part.
> >
> > Instead of disable / skipp the CPP step you can hide the auto generated
> > xilinx.dts with a second include stage, for example:
> >
> > board/microblaze/dts/microblaze.dts looks like:
> >
> > /include/ ARCH_CPU_DTS
> > /include/ BOARD_DTS
> >
> >
> > Right, only two lines.   The arch/microblaze/dts/microblaze.dtsi remains
> > empty as you have said above. Just new is BOARD_DTS -- with the attached
> > patch for dts/Makefile you can copy the auto generated xilinx.dts into
> > the specific board directory and the CPP step substitute the right place
> > to board/microblaze/microblaze-generic/dts/microblaze.dts
> >
> > I think there are no side effects with other ports like the tegra2.
> >
> > If you want you can omit the ARCH_CPU_DTS inclusion. The architectural
> > microblaze.dtsi file is empty and (!!) have to be empty, because the DTC
> > will break with an error on multiple "/dts-v1/;" lines!
> >
> > Here is the patch:
> >
> > diff --git a/dts/Makefile b/dts/Makefile
> > index 914e479..b1f47a1 100644
> > --- a/dts/Makefile
> > +++ b/dts/Makefile
> > @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> > support enabled. \
> > Please define CONFIG_ARCH_DEVICE_TREE))
> >
> > # We preprocess the device tree file provide a useful define
> > -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> > +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> > +   -DBOARD_DTS=
> > \"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
> >
> > all:   $(obj).depend $(LIB)
> 
> Not sure if using another dts file will be the best approach.

For Microblaze you can ignore the ARCH_CPU_DTS and the dtsi file in
arch/cpu complete

Re: [U-Boot] [RFC PATCH] net: emaclite: Support OF initialization

[Simon Glass]

Hi Michal,

On Thu, Jun 28, 2012 at 12:26 AM, Michal Simek  wrote:

> Support new CONFIG_OF_CONTROL option where device
> probing is done based on device tree description.
>
> Signed-off-by: Michal Simek 
> ---
>  drivers/net/xilinx_emaclite.c |   30 ++
>  1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index e1af42a..0f6807d 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -28,6 +28,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
>  #undef DEBUG
>
> @@ -375,3 +378,30 @@ int xilinx_emaclite_initialize(bd_t *bis, unsigned
> long base_addr,
>
> return 1;
>  }
> +
> +#ifdef CONFIG_OF_CONTROL
> +int xilinx_emaclite_init(bd_t *bis)
> +{
> +   int offset = 0;
> +   u32 ret = 0;
> +   u32 reg;
> +
> +   do {
> +   offset = fdt_node_offset_by_compatible(gd->fdt_blob,
> offset,
> +   "xlnx,xps-ethernetlite-1.00.a");
> +   if (offset != -1) {
>

offset > 0 or >= 0

> +   reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
> +   if (reg != FDT_ADDR_T_NONE) {
> +   u32 rxpp = fdtdec_get_int(gd->fdt_blob,
> offset,
> +
> "xlnx,rx-ping-pong", 0);
> +   u32 txpp = fdtdec_get_int(gd->fdt_blob,
> offset,
> +
> "xlnx,tx-ping-pong", 0);
> +   ret |= xilinx_emaclite_initialize(bis, reg,
> +   txpp,
> rxpp);
> +   }
> +   }
> +   } while (offset != -1);
>

Just offset > 0 here I think.


> +
> +   return ret;
> +}
> +#endif
>

This is fine I think. Do you want to impose an ordering on the interfaces,
or are you happy with them being assigned randomly? If you want an
ordering, see fdtdec_find_aliases_for_id().


> --
> 1.7.0.4
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Ilya Yanok]

Dear Marek,

30.06.2012 23:27, Marek Vasut wrote:

 do {

 /* Invalidate dcache */
 invalidate_dcache_range((uint32_t)&qh_list,

 (uint32_t)&qh_list + sizeof(struct QH));

 invalidate_dcache_range((uint32_t)&qh,

 (uint32_t)&qh + sizeof(struct QH));

 invalidate_dcache_range((uint32_t)qtd,

 (uint32_t)qtd + sizeof(qtd));

These guys are 32-byte aligned, right? So the assumption is that
cacheline is not greater than 32. Sounds like a bug to me (though could
be fixed rather easily with USB_MINALIGN introduced by Tom).

Oooh, good catch indeed. Actually, look at the structures, even they have some
weird alignment crap in them. Maybe that can also be dropped and the alignment
shall be fixed properly. I'll have to research this more.


I guess that's because they have to be both address and size aligned.


 token = hc32_to_cpu(vtd->qt_token);
 if (!(token&  0x80))

 break;

 WATCHDOG_RESET();

 } while (get_timer(ts)<  timeout);

 /* Invalidate the memory area occupied by buffer */
 invalidate_dcache_range(((uint32_t)buffer&  ~31),

 ((uint32_t)buffer&  ~31) + roundup(length, 32));

That's worse. First of all, rounding is wrong: consider buffer=31,
length=32. But that's easy to fix too. The bad part is that with
writeback cache you can't just enlarge the range to cover the buffer and
fit alignment requirements -- this can potentially destroy some changes
that are in the same cache line but not yet stored to RAM.

Correct, so we have multiple bugs in here that need to be squashed ASAP.

Ilya, can you possibly submit a patch for this?


Hm.. Fixing alignment for qh, qd and stuff is easy, I can surely submit 
a patch for this. But I don't really know what to do this the last one: 
if we are at this point there is no correct way out... We can increase 
the range to cover the buffer or decrease it to be inside buffer -- but 
both options are incorrect. Actually we should return error when 
unaligned buffer is submitted in the first place... But this will likely 
break a lot of systems... Probably put this check under if 
(dcache_enabled())?


Regards, Ilya.

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

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Ilya Yanok]

Dear Marek,

30.06.2012 23:28, Marek Vasut wrote:

Not exactly. It never worked (at least on my systems) with D-Cache
enabled. But at least we had a choice of run-time disabled dcache. With
the recent changes we have to disable cache support at compile time.

I see what you're after. But do you consider runtime disabling the cache is the
way to go or it's a way of hiding bugs?


Both ;) And now we are going to hide even more bugs with compile-time 
disabling :(


Regards, Ilya.


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

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass: 
> Hi,
> 
> On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek  wrote:
> 
> > 2012/6/29 Stephan Linz :
> > > Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> > >> On 06/29/2012 04:32 AM, Simon Glass wrote:
> > >> > Hi,
> > >> >
> > >> > --snip--
> > >>
> > >> I have sent support for Microblaze. Currently without dts because I
> > want to clear this part a little bit.
> > >
> > > Hi Michal,
> > >
> > > looks good, I've been waiting a long time on the FDT support in U-Boot
> > > for Microblaze -- great -- PS: see my comment on patch 5 ...
> > >
> > >>
> > >> Tegra is using ./arch/arm/dts/tegra20.dtsi and
> > board/nvidia/dts/tegra2-seaboard.dts
> > >> and they are composed together in dts/Makefile by calling preprocessor.
> > >> Microblaze will be totally different case because every Microblaze hw
> > design is different.
> > >
> > > Yes, that's right. We will never be in the position to define a skeleton
> > > or a basic platform configuration.
> > >
> > >> We can use two main buses (little and big endian) and cpu is also
> > configurable.
> > >> Based on this for Microblaze is the best solution directly to use dts.
> > >> (DTS for Microblaze is also generated directly from design tool).
> > >
> > > ... directly in the context of a board, not arch/cpu, right?
> >
> > yes.
> >
> > >
> > >>
> > >>
> > >> Anyway - here is the bug message I am getting if I use full dts in
> > board//dts/microblaze.dts
> > >> and empty arch/microblaze/dts/microblaze.dtsi
> > >>
> > >> :34:3: error: invalid preprocessing directive #address
> > >> :35:3: error: invalid preprocessing directive #size
> > >> :52:4: error: invalid preprocessing directive #address
> > >> :53:4: error: invalid preprocessing directive #cpus
> > >> :54:4: error: invalid preprocessing directive #size
> > >> :155:4: error: invalid preprocessing directive #address
> > >> :156:4: error: invalid preprocessing directive #size
> > >> :160:5: error: invalid preprocessing directive #gpio
> > >> :192:5: error: invalid preprocessing directive #gpio
> > >> :209:5: error: invalid preprocessing directive #gpio
> > >> :241:5: error: invalid preprocessing directive #gpio
> > >> :267:5: error: invalid preprocessing directive #address
> > >> :268:5: error: invalid preprocessing directive #size
> > >> :394:5: error: invalid preprocessing directive #interrupt
> > >>
> > >> This is error for opposite case - empty microblaze.dts and full
> > microblaze.dtsi.
> > >
> > > That are CPP errors, because the auto generated xilinx.dts is full of
> > > CPP pragma like syntax (#something) that are wrong (invalid).
> >
> > I know what it is.
> >
> > >
> > >>
> > >> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> > >> rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts |
> > microblaze-unknown-linux-gnu-gcc -E
> > >> -P
> > -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> > - | { { dtc -R 4 -p 0x1000
> > >> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb  on
> > file' ; } 3>&1 ) ; \
> > >>   exit $rc
> > >> /bin/sh: line 1: exit: too many arguments
> > >> make[1]: *** [dt.dtb] Error 1
> > >> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> > >>
> > >>
> > >> I have just tried to fix it by introducing new CONFIG option for
> > skipping that preprocessor
> > >> part.
> > >
> > > Instead of disable / skipp the CPP step you can hide the auto generated
> > > xilinx.dts with a second include stage, for example:
> > >
> > > board/microblaze/dts/microblaze.dts looks like:
> > >
> > > /include/ ARCH_CPU_DTS
> > > /include/ BOARD_DTS
> > >
> > >
> > > Right, only two lines.   The arch/microblaze/dts/microblaze.dtsi remains
> > > empty as you have said above. Just new is BOARD_DTS -- with the attached
> > > patch for dts/Makefile you can copy the auto generated xilinx.dts into
> > > the specific board directory and the CPP step substitute the right place
> > > to board/microblaze/microblaze-generic/dts/microblaze.dts
> > >
> > > I think there are no side effects with other ports like the tegra2.
> > >
> > > If you want you can omit the ARCH_CPU_DTS inclusion. The architectural
> > > microblaze.dtsi file is empty and (!!) have to be empty, because the DTC
> > > will break with an error on multiple "/dts-v1/;" lines!
> > >
> > > Here is the patch:
> > >
> > > diff --git a/dts/Makefile b/dts/Makefile
> > > index 914e479..b1f47a1 100644
> > > --- a/dts/Makefile
> > > +++ b/dts/Makefile
> > > @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> > > support enabled. \
> > > Please define CONFIG_ARCH_DEVICE_TREE))
> > >
> > > # We preprocess the device tree file provide a useful define
> > > -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> > > +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> > > +   -DBOARD_DTS

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Tom Rini]

On 07/03/2012 01:13 PM, Ilya Yanok wrote:
> Dear Marek,
> 
> 30.06.2012 23:28, Marek Vasut wrote:
>>> Not exactly. It never worked (at least on my systems) with D-Cache
>>> enabled. But at least we had a choice of run-time disabled dcache. With
>>> the recent changes we have to disable cache support at compile time.
>> I see what you're after. But do you consider runtime disabling the
>> cache is the
>> way to go or it's a way of hiding bugs?
> 
> Both ;) And now we are going to hide even more bugs with compile-time
> disabling :(

Does someone wish to argue we should disable USB support instead on
these platforms?  I don't see anyone arguing "I have time to fix this
for v2012.07".

-- 
Tom


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

[U-Boot] [PATCH v4] nand: Hack to support 4k page in fsl_elbc_nand

[Rafael Beims]

Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Because of this, the in flash layout of the oob is different from the
default for 4096kiB page sizes. Therefore, we need to migrate the
factory bad block markers from the original position to the new layout.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Liu Shuo 
Signed-off-by: Rafael Beims 
---
Changes in v2:
 - Added check to disallow the migration code to run in devices with
 page size <= 2048

Changes in v3:
 - Corrected memset writing beyond newoob buffer
 - Corrected various code formatting errors
 - Cosmetic changes
 - Generated random magic number for migration marker
 - Removed direct references to nand_bbt.c code
 - Removed useless bbt free
 - Removed useless dir variable
 - Removed vmalloc and kmalloc calls. Only malloc() and free() used now
 - Start searching the migration marker from the end of NAND

Changes in v4:
 - Read all the pages of the block until migrated marker is found
 - Write the marker in all pages of the block

 drivers/mtd/nand/fsl_elbc_nand.c |  443 +++---
 1 files changed, 415 insertions(+), 28 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 9076ad4..f5afa9b 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -76,15 +76,17 @@ struct fsl_elbc_ctrl {

/* device info */
fsl_lbc_t *regs;
-   u8 __iomem *addr;/* Address of assigned FCM buffer*/
-   unsigned int page;   /* Last page written to / read from  */
-   unsigned int read_bytes; /* Number of bytes read during command   */
-   unsigned int column; /* Saved column from SEQIN   */
-   unsigned int index;  /* Pointer to next byte to 'read'*/
-   unsigned int status; /* status read from LTESR after last op  */
-   unsigned int mdr;/* UPM/FCM Data Register value   */
-   unsigned int use_mdr;/* Non zero if the MDR is to be set  */
-   unsigned int oob;/* Non zero if operating on OOB data */
+   u8 __iomem *addr;   /* Address of assigned FCM buffer   */
+   unsigned int page;  /* Last page written to / read from */
+   unsigned int read_bytes;/* Number of bytes read during command  */
+   unsigned int column;/* Saved column from SEQIN  */
+   unsigned int index; /* Pointer to next byte to 'read'   */
+   unsigned int status;/* status read from LTESR after last op */
+   unsigned int mdr;   /* UPM/FCM Data Register value  */
+   unsigned int use_mdr;   /* Non zero if the MDR is to be set */
+   unsigned int oob;   /* Non zero if operating on OOB data*/
+   uint8_t *buffer;/* Just used when pagesize is greater   */
+   /* than FCM RAM 2K limitation   */
 };

 /* These map to the positions used by the FCM hardware ECC generator */
@@ -131,6 +133,10 @@ static struct nand_bbt_descr largepage_memorybased = {
.pattern = scan_ff_pattern,
 };

+static u8 migrated_pattern[] = { 0x61, 0xa1, 0x87, 0xf0 };
+#define BADBLOCK_MIGRATED_OFF 1
+#define BADBLOCK_MIGRATED_MB 3
+
 /*
  * ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
  * interfere with ECC positions, that's why we implement our own descriptors.
@@ -159,6 +165,35 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.pattern = mirror_pattern,
 };

+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct fsl_elbc_mtd *priv = chip->priv;
+   struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */
+   dst = ctrl->buffer + (oob ? mtd->writesize : 0) + subpage * len;
+   src = ctrl->addr + (oob ? 2048 : 0);
+   memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct fsl_elbc_mtd *priv = chip->priv;
+   struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   src = ctrl->buffer + (oob ? mtd->writesize : 0) + subpage * len;
+   dst = ctrl->addr + (oob ? 2048 : 0);
+   memcpy_toio(dst, src, len);
+   /* See the in_8() in fsl_elbc_write_buf() */
+   in_8(ctrl->addr);
+}
+
 /*=*/

 /*
@@ -194,7 +229,7 @@ static void set_addr(struct mtd_info *mtd, int
column, int page_addr, int oob)

/* for OOB data point to the second half of the buffer */
   

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Ilya Yanok]

Hi Tom,

04.07.2012 00:43, Tom Rini wrote:

On 07/03/2012 01:13 PM, Ilya Yanok wrote:

Dear Marek,

30.06.2012 23:28, Marek Vasut wrote:

Not exactly. It never worked (at least on my systems) with D-Cache
enabled. But at least we had a choice of run-time disabled dcache. With
the recent changes we have to disable cache support at compile time.

I see what you're after. But do you consider runtime disabling the
cache is the
way to go or it's a way of hiding bugs?

Both ;) And now we are going to hide even more bugs with compile-time
disabling :(

Does someone wish to argue we should disable USB support instead on
these platforms?  I don't see anyone arguing "I have time to fix this
for v2012.07".


I just looked at the code more carefully and it seems that most of the 
upper layers are in much better shape than I thought. So I think we 
should just extend your 2/6 patch to fix both address and size for 
structs QH and qtd and don't mess with buffer at all: if we got 
unaligned buffer -- it's definetely upper layer bug so we should produce 
some noise in this case. As I said upper layers seems to be in good 
shape so hopefully there won't be too much noise.


Hm, probably we should put buffer invalidation under 
if(dcache_enabled()) to leave run-time cache disabling as rescue option 
for broken upper-layer code..


I'm working on the patch now and hopefully will post it this night.

Regards, Ilya.

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

[U-Boot] [PATCH v4 0/1] fsl_elbc support for 4k devices and factory badblock migration

[Rafael Beims]

This is my implementation of the factory badblock migration process for
the fsl_elbc driver using the hack to support nand devices with page
sizes bigger than 2048k.

As per last discussion with Scott Wood, I now write the marker in all
the pages of the block, to add redundancy.
The code that searches for the marker also runs through the pages trying
to find the marker.
The markers are still written to 2 blocks.

I would really appreciate any feedback related to the patch.

Changes in v2:
 - Added check to disallow the migration code to run in devices with
 page size <= 2048

Changes in v3:
 - Corrected memset writing beyond newoob buffer
 - Corrected various code formatting errors
 - Cosmetic changes
 - Generated random magic number for migration marker
 - Removed direct references to nand_bbt.c code
 - Removed useless bbt free
 - Removed useless dir variable
 - Removed vmalloc and kmalloc calls. Only malloc() and free() used now
 - Start searching the migration marker from the end of NAND

Changes in v4:
 - Read all the pages of the block until migrated marker is found
 - Write the marker in all pages of the block

Rafael Beims (1):
  nand: Hack to support 4k page in fsl_elbc_nand

 drivers/mtd/nand/fsl_elbc_nand.c |  443 +++---
 1 files changed, 415 insertions(+), 28 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Marek Vasut]

Dear Tom Rini,

> On 07/03/2012 01:13 PM, Ilya Yanok wrote:
> > Dear Marek,
> > 
> > 30.06.2012 23:28, Marek Vasut wrote:
> >>> Not exactly. It never worked (at least on my systems) with D-Cache
> >>> enabled. But at least we had a choice of run-time disabled dcache. With
> >>> the recent changes we have to disable cache support at compile time.
> >> 
> >> I see what you're after. But do you consider runtime disabling the
> >> cache is the
> >> way to go or it's a way of hiding bugs?
> > 
> > Both ;) And now we are going to hide even more bugs with compile-time
> > disabling :(
> 
> Does someone wish to argue we should disable USB support instead on
> these platforms?  I don't see anyone arguing "I have time to fix this
> for v2012.07".

I don't have time to fix this, I'm hacking 200% already.

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 v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Marek Vasut]

Dear Ilya Yanok,

> Dear Marek,
> 
> 30.06.2012 23:27, Marek Vasut wrote:
> >>>  do {
> >>>  
> >>>  /* Invalidate dcache */
> >>>  invalidate_dcache_range((uint32_t)&qh_list,
> >>>  
> >>>  (uint32_t)&qh_list + sizeof(struct QH));
> >>>  
> >>>  invalidate_dcache_range((uint32_t)&qh,
> >>>  
> >>>  (uint32_t)&qh + sizeof(struct QH));
> >>>  
> >>>  invalidate_dcache_range((uint32_t)qtd,
> >>>  
> >>>  (uint32_t)qtd + sizeof(qtd));
> >> 
> >> These guys are 32-byte aligned, right? So the assumption is that
> >> cacheline is not greater than 32. Sounds like a bug to me (though could
> >> be fixed rather easily with USB_MINALIGN introduced by Tom).
> > 
> > Oooh, good catch indeed. Actually, look at the structures, even they have
> > some weird alignment crap in them. Maybe that can also be dropped and
> > the alignment shall be fixed properly. I'll have to research this more.
> 
> I guess that's because they have to be both address and size aligned.
> 
> >>>  token = hc32_to_cpu(vtd->qt_token);
> >>>  if (!(token&  0x80))
> >>>  
> >>>  break;
> >>>  
> >>>  WATCHDOG_RESET();
> >>>  
> >>>  } while (get_timer(ts)<  timeout);
> >>>  
> >>>  /* Invalidate the memory area occupied by buffer */
> >>>  invalidate_dcache_range(((uint32_t)buffer&  ~31),
> >>>  
> >>>  ((uint32_t)buffer&  ~31) + roundup(length, 32));
> >> 
> >> That's worse. First of all, rounding is wrong: consider buffer=31,
> >> length=32. But that's easy to fix too. The bad part is that with
> >> writeback cache you can't just enlarge the range to cover the buffer and
> >> fit alignment requirements -- this can potentially destroy some changes
> >> that are in the same cache line but not yet stored to RAM.
> > 
> > Correct, so we have multiple bugs in here that need to be squashed ASAP.
> > 
> > Ilya, can you possibly submit a patch for this?
> 
> Hm.. Fixing alignment for qh, qd and stuff is easy, I can surely submit
> a patch for this.

Well ... partial patch is still better than none.

> But I don't really know what to do this the last one:
> if we are at this point there is no correct way out... We can increase
> the range to cover the buffer or decrease it to be inside buffer -- but
> both options are incorrect. Actually we should return error when
> unaligned buffer is submitted in the first place... But this will likely
> break a lot of systems... Probably put this check under if
> (dcache_enabled())?

Bounce buffer I guess ... with warning that you'll hit performance penalty 
becaue you're dumb and doing unaligned transfer. And for internal uboot stuff, 
we can align it.

> 
> Regards, Ilya.

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 3/7] dfu: DFU backend implementation

[Marek Vasut]

Dear Lukasz Majewski,

> New, separate driver at ./drivers/dfu has been added. It allows platform
> and storage independent operation of DFU.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Marek Vasut 
> ---

[...]

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static LIST_HEAD(dfu_list);
> +static int dfu_alt_num;
> +
> +static int dfu_find_alt_num(char *s)
> +{
> + int i = 0;
> +
> + for (; *s; s++)
> + if (*s == ';')
> + i++;
> +
> + return ++i;
> +}
> +
> +static char *dfu_extract_entity(char** env)
> +{
> + char *s = *env;
> +
> + strsep(env, ";");
> + return s;
> +}

Shall we not make these all generic? They seem to be quite helpful components.

> +
> +char *dfu_extract_token(char** e, int *n)
> +{
> + char *st = *e;
> +
> + debug("%s: %s\n", __func__, st);
> +
> + strsep(e, " ");
> + *n = *e - st;
> +
> + return st;
> +}
> +
> +static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
> +  dfu_buf[DFU_DATA_BUF_SIZE];

Can we not stack-allocate it with ALLOC_CACHE_ALIGN_BUFFER()?

[...]

> diff --git a/include/dfu.h b/include/dfu.h
> new file mode 100644
> index 000..f7d823b
> --- /dev/null
> +++ b/include/dfu.h

[...]

> +struct dfu_entity {
> + charname[DFU_NAME_SIZE];
> + int alt;
> + void*dev_private;
> + int dev_num;
> + enum dfu_device_typedev_type;
> + enum dfu_layout layout;
> +
> + union {
> + struct mmc_internal_data mmc;

This union seems redundant ;-)

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

Re: [U-Boot] [PATCH 2/7] dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

[Marek Vasut]

Dear Lukasz Majewski,

> Support for f_dfu USB function.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Marek Vasut 
> ---
[...]
> +
> +static const char dfu_name[] = "Device Firmware Upgrade";
> +
> +/* static strings, in UTF-8 */
> +/*
> + * dfu_genericiguration specific


generiwhat?

> + */
> +static struct usb_string strings_dfu_generic[] = {
> + [0].s = dfu_name,
> + {  }/* end of list */
> +};
> +
> +static struct usb_gadget_strings stringtab_dfu_generic = {
> + .language   = 0x0409,   /* en-us */
> + .strings= strings_dfu_generic,
> +};
> +
> +static struct usb_gadget_strings *dfu_generic_strings[] = {
> + &stringtab_dfu_generic,
> + NULL,
> +};
> +
> +/*
> + * usb_function specific
> + */
> +static struct usb_gadget_strings stringtab_dfu = {
> + .language   = 0x0409,   /* en-us */
> + /*
> +  * .strings
> +  *
> +  * assigned during initialization,
> +  * depends on number of flash entities
> +  *
> +  */
> +};
> +
> +static struct usb_gadget_strings *dfu_strings[] = {
> + &stringtab_dfu,
> + NULL,
> +};
> +
> +/*
> -*/ +
> +static void dnload_request_complete(struct usb_ep *ep, struct usb_request
> *req) +{
> + struct f_dfu *f_dfu = req->context;
> +
> + dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf,
> +   req->length, f_dfu->blk_seq_num);
> +
> + if (req->length == 0) {
> + puts("DOWNLOAD ... OK\n");
> + puts("Ctrl+C to exit ...\n");
> + }
> +}
> +
> +static void handle_getstatus(struct usb_request *req)
> +{
> + struct dfu_status *dstat = (struct dfu_status *)req->buf;
> + struct f_dfu *f_dfu = req->context;
> +
> + switch (f_dfu->dfu_state) {
> + case DFU_STATE_dfuDNLOAD_SYNC:

What's this crazy cammel case in here ? :-)

> + case DFU_STATE_dfuDNBUSY:
> + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE;
> + break;
> + case DFU_STATE_dfuMANIFEST_SYNC:
> + break;
> + default:
> + break;
> + }
> +
> + /* send status response */
> + dstat->bStatus = f_dfu->dfu_status;
> + /* FIXME: set dstat->bwPollTimeout */

FIXME ... so fix it ;-)

> + dstat->bState = f_dfu->dfu_state;
> + dstat->iString = 0;
> +}
> +
> +static void handle_getstate(struct usb_request *req)
> +{
> + struct f_dfu *f_dfu = req->context;
> +
> + ((u8 *)req->buf)[0] = f_dfu->dfu_state & 0xff;

Now ... this is ubercrazy ... can't this be made without this typecasting 
voodoo?

> + req->actual = sizeof(u8);
> +}
> +
[...]
> +static int handle_dnload(struct usb_gadget *gadget, u16 len)
> +{
> + struct usb_composite_dev *cdev = get_gadget_data(gadget);
> + struct usb_request *req = cdev->req;
> + struct f_dfu *f_dfu = req->context;
> +
> + if (len == 0)
> + f_dfu->dfu_state = DFU_STATE_dfuMANIFEST_SYNC;
> +
> + req->complete = dnload_request_complete;
> +
> + return len;
> +}

One newline too much below.

> +
> +
> +static int
> +dfu_handle(struct usb_function *f, const struct usb_ctrlrequest *ctrl)
> +{
> + struct usb_gadget *gadget = f->config->cdev->gadget;
> + struct usb_request *req = f->config->cdev->req;
> + struct f_dfu *f_dfu = f->config->cdev->req->context;
> + u16 len = le16_to_cpu(ctrl->wLength);
> + u16 w_value = le16_to_cpu(ctrl->wValue);
> + int value = 0;
> + int standard;
> +
> + standard = (ctrl->bRequestType & USB_TYPE_MASK)
> + == USB_TYPE_STANDARD;
> +
> + debug("w_value: 0x%x len: 0x%x\n", w_value, len);
> + debug("standard: 0x%x ctrl->bRequest: 0x%x f_dfu->dfu_state: 0x%x\n",
> +standard, ctrl->bRequest, f_dfu->dfu_state);
> +
> + if (!standard) {

This function doesn't fit on my screen ... that means it's wy too long and 
shall be split into more functions ;-)

That's also remove the need for your crazy conditional assignment of standard.

> + switch (f_dfu->dfu_state) {
> + case DFU_STATE_appIDLE:
> + switch (ctrl->bRequest) {
> + case USB_REQ_DFU_GETSTATUS:
> + handle_getstatus(req);
> + value = RET_STAT_LEN;
> + break;
[...]

> +
> +/*
> -*/ +
> +static int
> +dfu_prepare_strings(struct f_dfu *f_dfu, int n)
> +{
> + struct dfu_entity *de = NULL;
> + int i = 0;
> +
> + f_dfu->strings = calloc(((n + 1) * sizeof(struct usb_string)), 1);

calloc(n, 1) ... that's the same as malloc(), isn't it ?

> + if (!f_dfu->strings)
> + goto enomem;
> +
> + for (i = 0; i < n; ++i) {
> + de = dfu_get_entity(i);
> + f_dfu->strings[i].s = de->name;

Re: [U-Boot] [PATCH 4/7] dfu: MMC specific routines for DFU operation

[Marek Vasut]

Dear Lukasz Majewski,

> Support for MMC storage devices to work with DFU framework.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Marek Vasut 
> ---

[...]

> +
> +#include 
> +#include 
> +#include 
> +
> +int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
> +{
> + ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
> +
> + memset(cmd_buf, '\0', sizeof(cmd_buf));
> +
> + switch (dfu->layout) {
> + case RAW_ADDR:
> + sprintf(cmd_buf, "mmc write 0x%x %x %x", (unsigned int) buf,
> + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size);
> + break;
> + case FAT:
> + sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s %lx",
> + dfu->data.mmc.dev, dfu->data.mmc.part,
> + (unsigned int) buf, dfu->name, *len);
> + break;
> + default:
> + printf("%s: Wrong layout!\n", __func__);
> + }
> +
> + debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf);
> + run_command(cmd_buf, 0);

Holy Moly ... can we not make this into simple calls to those subsystems ? 
Instead invoking command is crazy ;-)

[...]

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 5/7] dfu:cmd: Support for DFU u-boot command

[Marek Vasut]

Dear Lukasz Majewski,

> Support for u-boot's command line command "dfu   [list]".
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Marek Vasut 
> ---

[...]

> +int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + char *str_env = NULL, *env_bkp = NULL;
> + static char *s = "dfu";
> + int ret = 0;
> +
> + if (argc < 3)
> + return CMD_RET_USAGE;
> +
> + str_env = getenv("dfu_alt_info");
> + if (str_env == NULL) {
> + printf("%s: \"dfu_alt_info\" env variable not defined!\n",
> +__func__);

I was always curious if it's not possible to do something like 

puts(__func__ "rest of string");

Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this 
patchset, I'm just curious :)

> + return CMD_RET_FAILURE;
> + }

[...]

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