Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()

[Albert ARIBAUD]

Hi Michal,

On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
 wrote:

> Zynq lowlevel_init() was implemented in C but stack
> pointer is setup after function call in _main().
> Move architecture setup to arch_cpu_init() which is call
> as the first function in board_init_f() which
> already have correct stack pointer.
> 
> Reported-by: Sven Schwermer 
> Signed-off-by: Michal Simek 
> ---
> I can't see any problem to call zynq setup a little
> bit later. There is already expectation that u-boot
> runs from DDR.
> Moving lowlevel_init from C to ASM is possible but
> I will have to introduce new macros with hardcoded
> values. Using structures is much nicer.
> 
> ---
>  arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/zynq/cpu.c b/arch/arm/cpu/armv7/zynq/cpu.c
> index 4367d1a..8846f30 100644
> --- a/arch/arm/cpu/armv7/zynq/cpu.c
> +++ b/arch/arm/cpu/armv7/zynq/cpu.c
> @@ -11,6 +11,10 @@
> 
>  void lowlevel_init(void)
>  {
> +}
> +
> +int arch_cpu_init(void)
> +{
>   zynq_slcr_unlock();
>   /* remap DDR to zero, FILTERSTART */
>   writel(0, &scu_base->filter_start);
> @@ -31,6 +35,8 @@ void lowlevel_init(void)
>   writel(0xC, &slcr_base->ddr_urgent);
> 
>   zynq_slcr_lock();
> +
> + return 0;
>  }
> 
>  void reset_cpu(ulong addr)
> --
> 1.8.2.3
> 
> 
Applied to u-boot-arm/master, thanks!

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

[U-Boot] [i2c] Pull request

[Heiko Schocher]

Hello Tom,

please pull from u-boot-i2c.git:

The following changes since commit 183acb700378a8cfc5d50a01a65de93fb2c24586:

  Prepare v2013.10 (2013-10-16 13:08:12 -0400)

are available in the git repository at:

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

for you to fetch changes up to 9a2a73d29fa395f42f3fb477ac99dda4d7f2f21f:

  i2c: eliminate warnings in i2c_reloc_fixup function (2013-10-17 07:24:41 
+0200)


Heiko Schocher (1):
  i2c, core: optimze i2c_set_bus_num()

Jens Scharsig (BuS Elektronik) (1):
  Fix: nommu I2C adapter relocation error

Masahiro Yamada (1):
  i2c: eliminate warnings in i2c_reloc_fixup function

Michael Burr (1):
  i2c: Zynq: Support for TI PCA9548 bus multiplexer

Naveen Krishna Ch (2):
  exynos: i2c: Fix i2c driver to handle NACKs properly
  i2c: s3c24xx: add hsi2c controller support

Nobuhiro Iwamatsu (3):
  i2c: Add support for Renesas rcar
  i2c: sh_i2c: Avoid using I2C prior to relocation
  README: I2C: Fix indent

Simon Glass (1):
  exynos: i2c: Change FDT bus setup code to enumerate ports correctly

trem (3):
  i2c: fix init on generic board
  i2c: mxc: move to new subsystem
  i2c: update config using mxc driver to new subsystem

 README|  31 +-
 arch/arm/cpu/armv7/mx5/clock.c|   2 +-
 arch/arm/cpu/armv7/mx6/clock.c|   2 +-
 arch/arm/imx-common/Makefile  |   2 +-
 common/board_f.c  |   4 +
 drivers/i2c/Makefile  |   3 +-
 drivers/i2c/i2c_core.c|  39 +++
 drivers/i2c/mxc_i2c.c | 137 +---
 drivers/i2c/rcar_i2c.c| 288 
+++
 drivers/i2c/s3c24x0_i2c.c | 835 
+-
 drivers/i2c/s3c24x0_i2c.h |  38 +++
 drivers/i2c/sh_i2c.c  |  10 +-
 include/configs/apf27.h   |  11 +-
 include/configs/flea3.h   |   9 +-
 include/configs/imx31_phycore.h   |   7 +-
 include/configs/m53evk.h  |   7 +-
 include/configs/mx25pdk.h |   7 +-
 include/configs/mx35pdk.h |   7 +-
 include/configs/mx53ard.h |   7 +-
 include/configs/mx53evk.h |   7 +-
 include/configs/mx53loco.h|   7 +-
 include/configs/mx53smd.h |   7 +-
 include/configs/mx6qsabreauto.h   |   4 +-
 include/configs/nitrogen6x.h  |   4 +-
 include/configs/titanium.h|   4 +-
 include/configs/vf610twr.h|   7 +-
 include/configs/woodburn_common.h |   7 +-
 include/i2c.h |   2 +
 28 files changed, 1187 insertions(+), 308 deletions(-)
 create mode 100644 drivers/i2c/rcar_i2c.c

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] [U-Boot, v4, 3/3] i2c: update config using mxc driver to new subsystem

[Heiko Schocher]

Hello trem,

Am 21.09.2013 18:13, schrieb trem:

Signed-off-by: Philippe Reynes

---
include/configs/apf27.h   |   11 ++-
  include/configs/flea3.h   |9 -
  include/configs/imx31_phycore.h   |7 +++
  include/configs/m53evk.h  |7 +++
  include/configs/mx25pdk.h |7 +++
  include/configs/mx35pdk.h |7 +++
  include/configs/mx53ard.h |7 +++
  include/configs/mx53evk.h |7 +++
  include/configs/mx53loco.h|7 +++
  include/configs/mx53smd.h |7 +++
  include/configs/mx6qsabreauto.h   |4 ++--
  include/configs/nitrogen6x.h  |4 ++--
  include/configs/titanium.h|4 ++--
  include/configs/vf610twr.h|7 +++
  include/configs/woodburn_common.h |7 +++
  15 files changed, 46 insertions(+), 56 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] [U-Boot,v4,2/3] i2c: mxc: move to new subsystem

[Heiko Schocher]

Hello trem,

Am 21.09.2013 18:13, schrieb trem:

Signed-off-by: Philippe Reynes

---
README |   11 +++
  arch/arm/cpu/armv7/mx5/clock.c |2 +-
  arch/arm/cpu/armv7/mx6/clock.c |2 +-
  arch/arm/imx-common/Makefile   |2 +-
  drivers/i2c/Makefile   |2 +-
  drivers/i2c/mxc_i2c.c  |  137 +++-
  6 files changed, 93 insertions(+), 63 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] [U-Boot,v4,1/3] i2c: fix init on generic board

[Heiko Schocher]

Hello trem,

Am 21.09.2013 18:13, schrieb trem:

On generic board, the i2c init initialize only
one bus. But the new i2c subsystem allow to
manage severals i2c bus. So in the case, instead
of initializing a bus, we just set the current
i2c bus. The initialization will be done in
the i2c command.

Signed-off-by: Philippe Reynes

---
common/board_f.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] i2c: Zynq: Support for TI PCA9548 bus multiplexer

[Heiko Schocher]

Hello Michael,

Am 24.09.2013 00:35, schrieb Michael Burr:

(Interface is not quite the same as Phillips PCA9547.)

Signed-off-by: Michael Burr
Cc: Heiko Schocher
Cc: Michal Simek

---
drivers/i2c/i2c_core.c |5 +
  include/i2c.h  |2 ++
  2 files changed, 7 insertions(+)


Applied to u-boot-i2c.git

Thanks!

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

[U-Boot] fdt performance

[Aaron Williams]

Hi all,

In our bootloader based off of 2013.07 we make extensive use of the flat 
device tree. In profiling our bootloader in our simulator I found that 
the function eating up the most time is fdt_next_tag. Looking at it, 
especially fdt_offset_ptr, it looks like there is a lot of room for 
improvement especially in the skip name section.


Some of the checks in fdt_offset_ptr also look useless, such as if 
((offset + len) < offset) which will always be false, or

if (p + len < p)

len is always positive.

-Aaron

--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198  (510) 789-8988 (cell)

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

Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()

[Albert ARIBAUD]

Hi Albert,

On Thu, 3 Oct 2013 18:07:40 +0200, Albert ARIBAUD
 wrote:

> Hi Michal,
> 
> On Thu, 3 Oct 2013 11:56:20 +0200, Michal Simek
>  wrote:
> 
> > Hi Albert,
> > 
> > On 10/03/2013 10:41 AM, Albert ARIBAUD wrote:
> > > Hi Michal,
> > > 
> > > On Thu, 03 Oct 2013 08:58:38 +0200, Michal Simek 
> > > wrote:
> > > 
> > >> On 10/02/2013 09:43 PM, Albert ARIBAUD wrote:
> > >>> Hi Michal,
> > >>>
> > >>> On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek 
> > >>> wrote:
> > >>>
> >  Hi Albert,
> > 
> >  On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
> > > Hi Michal,
> > >
> > > On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek 
> > > wrote:
> > >
> > >> On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
> > >>> Hi Michal,
> > >>>
> > >>> On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
> > >>>  wrote:
> > >>>
> >  Zynq lowlevel_init() was implemented in C but stack
> >  pointer is setup after function call in _main().
> >  Move architecture setup to arch_cpu_init() which is call
> >  as the first function in board_init_f() which
> >  already have correct stack pointer.
> > 
> >  Reported-by: Sven Schwermer 
> >  Signed-off-by: Michal Simek 
> >  ---
> >  I can't see any problem to call zynq setup a little
> >  bit later. There is already expectation that u-boot
> >  runs from DDR.
> >  Moving lowlevel_init from C to ASM is possible but
> >  I will have to introduce new macros with hardcoded
> >  values. Using structures is much nicer.
> > 
> >  ---
> >   arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> >  diff --git a/arch/arm/cpu/armv7/zynq/cpu.c 
> >  b/arch/arm/cpu/armv7/zynq/cpu.c
> >  index 4367d1a..8846f30 100644
> >  --- a/arch/arm/cpu/armv7/zynq/cpu.c
> >  +++ b/arch/arm/cpu/armv7/zynq/cpu.c
> >  @@ -11,6 +11,10 @@
> > 
> >   void lowlevel_init(void)
> >   {
> >  +}
> > >>>
> > >>> I'd rather you deleted lowlevel_init() as a C function with this
> > >>> name should not exist.
> > >>
> > >> Ok. Do you want me to create almost empty low_level.S or just use
> > >> arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
> > >
> > > Urgh. I realize removing the C function would give you more work than
> > > simply keeping it empty until the whole s_init() mess is cleaned up. 
> > > :(
> > >
> > > I'll take your change as-is, sorry for the noise.
> > 
> >  In connection to this topic we have recently found one issue
> >  regarding to neon instruction which u-boot uses.
> > 
> >  We have this code to enable them in asm and adding this to 
> >  lowlevel_init.S
> >  is straight way how to do so.
> >  mov r0, r0
> >  mrc p15, 0, r1, c1, c0, 2
> >  orr r1, r1, #(0xf << 20)
> >  mcr p15, 0, r1, c1, c0, 2
> > 
> >  fmrxr1, FPEXC
> >  orr r1,r1, #(1<<30)
> >  fmxrFPEXC, r1
> > 
> >  Is it ok to create zynq asm specific lowlevel function
> >  or doing this through s_init() or you have nice a clean way how
> >  this should be solved when you are saying that s_init() is mess.
> > >>>
> > >>> Sorry for responding slowly.
> > >>>
> > >>> I suspect when you say neon instruction that U-Boot uses, you mean neon
> > >>> instructions that GCC is allowed to emit while building U-Boot, right?
> > >>
> > >> yes.
> > >>
> > >>> So we're talking about neon insns in C code only, not asm, correct?
> > >>
> > >> yes. gcc emits neon instruction in timer code. Not in asm.
> > >>
> > >>
> > >>> If this is correct, then does something prevent you from enabling
> > >>> neon instructions as early as possible, in e.g. the lowlevel_init
> > >>> routine?
> > >>
> > >> ok let me clear this. I think location of this code is clear.
> > >> It is asm code and it will be called ASAP even
> > >> we know exactly which code emits neon instructions.
> > >> My point was if we should create specific lowlevel_init asm function
> > >> and add this code there.
> > >> Or use arch/arm/cpu/armv7/lowlevel_init.S and create just s_init 
> > >> function.
> > >>
> > >> You mentioned above that s_init() is a mess and needs to be clean up
> > >> but you didn't mentioned how.
> > >>
> > >> It means my point is if you tell us how should be clean up we can
> > >> just submit code which is compatible with this cleanup activity.
> > > 
> > > If I knew how to clean s_init() up, I'd have sent out patches
> > > already. :)
> > 
> > Fair enough. :-)
> > 
> > > Anyway, I'm not sure that I see how s_init() and your need for a NEON
> > > enable sequence would be related: this sequence does not *need* to be in
> > > s_init().
> > 
> > ok. s_init i

Re: [U-Boot] [U-Boot, 3/3, v7] i2c: s3c24xx: add hsi2c controller support

[Heiko Schocher]

Hello Naveen,

Am 15.10.2013 12:32, schrieb Naveen Krishna Ch:

Add support for hsi2c controller available on exynos5420.

Note: driver currently supports only fast speed mode 100kbps

Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Vadim Bendebury
Signed-off-by: R. Chandrasekar


Applied to u-boot-i2c.git

Thanks!

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] [U-Boot, 2/3, v4] exynos: i2c: Change FDT bus setup code to enumerate ports correctly

[Heiko Schocher]

Hello Naveen,

Am 15.10.2013 12:32, schrieb Naveen Krishna Ch:

From: Simon Glass

At present the i2c ports are enumerated in a strange way - the
fdtdec_find_aliases_for_id() function is used, but then the ID returned
is ignored and the ports are renumbered. The effect is the same provided
that the device tree has the ports in the same order, or uses aliases,
and has no gaps, but it is not correct.

Adjust the code to use the function as intended. This will allows device
tree aliases to change the device order if required.

As a result, the i2c_busses variable is dropped. We can't be sure that
there are no 'holes' in the list of buses, so must check the whole
array.

Note: it seems that non-FDT operation is now broken in this drive and
will need to be reinstated for upstream.

Signed-off-by: Simon Glass
Reviewed-on: https://gerrit.chromium.org/gerrit/59369
Signed-off-by: Naveen Krishna Chatradhi

---
Changes since v1:
Nonei

Changes since v2:
None

Changes since v3:
None; ran # ./MAKEALL -v samsung

  drivers/i2c/s3c24x0_i2c.c |   25 ++---
  drivers/i2c/s3c24x0_i2c.h |1 +
  2 files changed, 19 insertions(+), 7 deletions(-)


Thanks!

Applied to u-boot-i2c.git

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] [U-Boot, 1/3, v4] exynos: i2c: Fix i2c driver to handle NACKs properly

[Heiko Schocher]

Hello Naveen,

Am 15.10.2013 12:31, schrieb Naveen Krishna Ch:

The Exynos5 i2c driver does not handle NACKs properly. This change:

- fixes the NACK processing problem (do not continue transaction if
   address cycle was NACKed)

- eliminates a fair amount of duplicate code

Signed-off-by: Vadim Bendebury
Reviewed-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi

---
Changes since v1:
Fixed complilation warning in function i2c_init()

Changes since v2:
None

Changes since v3:
None; ran # ./MAKEALL -v samsung

  drivers/i2c/s3c24x0_i2c.c |  214 +++--
  1 file changed, 90 insertions(+), 124 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long

[Albert ARIBAUD]

Hi Scott,

On Tue, 15 Oct 2013 12:57:33 -0500, Scott Wood
 wrote:

> On Tue, 2013-10-15 at 09:12 +0200, Albert ARIBAUD wrote:
> > Hi Oliver,
> > 
> > On Mon, 07 Oct 2013 04:41:31 +0200, Oliver Schinagl
> >  wrote:
> > 
> > > Hey all,
> > > 
> > > Having not received any feed back at all, I went ahead and did the 
> > > changes anyway. Everything seems to run and work fine for sunxi and 
> > > prints proper sizes.
> > > 
> > > For the other boards, I tried to run a MAKEALL but there where so many 
> > > random other warnings I can't say for 100% certainty there where no 
> > > mistakes that crept in.
> > 
> > There cannot possibly be a single warning if you're working from an
> > official U-Boot repo, as warnings are considered failures and thus no
> > patch reaches u-boot/master if it causes a warning.
> 
> That might be the theory, but in practice this is simply false.
> Different toolchains produce different warnings, and not all patches
> always get test-built on every target (especially on obscure
> architectures).  And since it's false that no warnings exist, that means
> sometimes even when a patch is test-built, some newly introduced
> warnings get missed (I got an e-mail pointing out such an occurance just
> today).

You are correct that the same code may or may not emit warnings
depending on the toolchain, and that U-Boot's build system won't stop
building because of warnings.

However, when a new toolchain version causes such warnings, but they
are not 'random' in any case; they may be numerous though, if in some
source code used in a lot of boards.

In any case, if Oliver gets warnings, chances are we'll get them to
when applying his code, in which case it'll be rejected, or we'll see
them happening later if he's unsing a common toolchain in a new
version, or he's using an unusual toolchain.

> -Scott

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

Re: [U-Boot] [U-Boot, 1/3] i2c: eliminate warnings in i2c_reloc_fixup function

[Heiko Schocher]

Hello Masahiro,

Am 16.10.2013 06:53, schrieb Masahiro Yamada:

The prototype of handlers had changed.
This commit uses cast with (void *) rather than
the handler-specific prototype.

Signed-off-by: Masahiro Yamada

---
Note:
The body of i2c_reloc_fixup function is surrounded by
   #if defined(CONFIG_NEEDS_MANUAL_RELOC) ... #endif

avr32, m68k, nds32, sparc defines this macro.


  drivers/i2c/i2c_core.c | 12 +---
  1 file changed, 5 insertions(+), 7 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] i2c, core: optimze i2c_set_bus_num()

[Heiko Schocher]

Hello Heiko,

Am 04.10.2013 07:36, schrieb Heiko Schocher:

check first, if we are on the bus, we want to enable. If so,
return immediately, do not calc max adapter number, nor check
other things.

Signed-off-by: Heiko Schocher
Cc: Lukasz Majewski
---
  drivers/i2c/i2c_core.c | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] i2c: Add support for Renesas rcar

[Heiko Schocher]

Hello Nobuhiro,

Am 27.09.2013 09:58, schrieb Nobuhiro Iwamatsu:

This supports i2c controller for Renesas rcar.

Signed-off-by: Hisashi Nakamura
Signed-off-by: Nobuhiro Iwamatsu
---
  v2:
- Add infomation about rcar_i2c to README.
- Remove empty line.
- Fix space.
- Keep list sorted in Makefile

  README |  14 +++
  drivers/i2c/Makefile   |   1 +
  drivers/i2c/rcar_i2c.c | 288 +
  3 files changed, 303 insertions(+)
  create mode 100644 drivers/i2c/rcar_i2c.c


Applied to u-boot-i2c.git

Thanks!

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 1/2] README: I2C: Fix indent

[Heiko Schocher]

Hello Nobuhiro,

Am 11.10.2013 09:23, schrieb Nobuhiro Iwamatsu:

Signed-off-by: Nobuhiro Iwamatsu
---
  README | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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 v1 1/1] netconsole loses 2nd character of input

[Joe Hershberger]

On Wed, Oct 16, 2013 at 11:54 AM, Suriyan Ramasami  wrote:
> Netconsole loses the second character when used as input by
> either setenv stdin nc or setenv stdin serial,nc if using CONSOLE_CONSOLE_MUX
>
> Before a nc_send_packet() to echo the input, a check is done to see if
> nc_ether is valid. If its not, it waits for an arp request and then sends
> the packet (which contains the first character of line to be displayed as
> output). As part of reaping the arp request, the second character is consumed.
> We protect this by making the call to NetLoop(NETCONS) between
> input_recursion.
>
> Signed-off-by: Suriyan Ramasami 

This looks good to me... I'll pull it in shortly.

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

Re: [U-Boot] [PATCH 2/2] i2c: sh_i2c: Avoid using I2C prior to relocation

[Heiko Schocher]

Hello Nobuhiro,

Am 11.10.2013 09:23, schrieb Nobuhiro Iwamatsu:

If user uses the I2C in before the relocation, board of sh and rmobile
will not start. This will solve this problem.

Signed-off-by: Nobuhiro Iwamatsu
---
  drivers/i2c/sh_i2c.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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] Fix: nommu I2C adapter relocation error

[Heiko Schocher]

Hello Jens,

Am 14.10.2013 10:27, schrieb Jens Scharsig (BuS Elektronik):

From: "Jens Scharsig (BuS Elektronik)"

NoMMU systems have a access violation problem with i2c_reloc_fixup.
Blame for it is a double relocation of the adapter itself. The
i2c_adap_p is already relocated, if i2c_reloc_fixup is called.
This patch removes the relocation of i2c_adap_p from i2c_reloc_fixup
to fix this.

Signed-off-by: Jens Scharsig (BuS Elektronik)
---
  drivers/i2c/i2c_core.c | 4 
  1 file changed, 4 deletions(-)


Applied to u-boot-i2c.git

Thanks!

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 3/3] arm: rmobile: Add support lager board

[Albert ARIBAUD]

Hi Nobuhiro,

On Fri, 20 Sep 2013 10:53:55 +0900, Nobuhiro Iwamatsu
 wrote:

> The lager board has R8A7790, 2GB DDR3-SDRAM, USB,
> Ethernet, and more.
> 
> This patch supports the following functions:
>  - DDR3-SDRAM
>  - SCIF
>  - QSPI
>  - Ethernet
> 
> Signed-off-by: Kouei Abe 
> Signed-off-by: Hisashi Nakamura 
> Signed-off-by: Ryo Kataoka 
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  v2: Remove changes for mach-types.h.
>  Rebase boards.cfg.

This fails to build under current u-boot-arm/master. Can you please
verify?

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

Re: [U-Boot] [PATCH v2] arm: vf610: initial integration for colibri vf50

[Albert ARIBAUD]

Hi Marcel,

On Mon, 30 Sep 2013 14:57:12 +0200, Marcel Ziswiler
 wrote:

> Add initial Colibri VF50 support based off Freescale's implementation
> for the Vybrid Tower System TWR-VF65GS10:
> - New machine ID.
> - Default UART_A on SCI0.
> - FEC1 only.
> - Enabled command line editing.
> - PLL5 based RMII clocking (e.g. no external crystal).
> - UART_A and UART_C I/O muxing.
> 
> Tested on early Colibri VF50 prototypes V1.0a booting off SD card
> (mandatory for initial loading). Loading Linux kernel off SD card or by
> TFTP.
> 
> Changes v2:
> - Boot off gfxRAM rather than sysRAM0 to increase available space.
> - Fixed board string previously just copied from Tower.

Note: changes should not appear in the commit message; they should go
below the commit message delimiter '---'. 

> Signed-off-by: Marcel Ziswiler 
> ---
>  board/toradex/colibri_vf50/Makefile   |   26 ++
>  board/toradex/colibri_vf50/colibri_vf50.c |  413 
> +
>  board/toradex/colibri_vf50/imximage.cfg   |   17 ++
>  boards.cfg|1 +
>  include/configs/colibri_vf50.h|  224 
>  5 files changed, 681 insertions(+)
>  create mode 100644 board/toradex/colibri_vf50/Makefile
>  create mode 100644 board/toradex/colibri_vf50/colibri_vf50.c
>  create mode 100644 board/toradex/colibri_vf50/imximage.cfg
>  create mode 100644 include/configs/colibri_vf50.h
> 
> diff --git a/board/toradex/colibri_vf50/Makefile 
> b/board/toradex/colibri_vf50/Makefile
> new file mode 100644
> index 000..43d21ab
> --- /dev/null
> +++ b/board/toradex/colibri_vf50/Makefile
> @@ -0,0 +1,26 @@
> +#
> +# Copyright 2013 Toradex, Inc.
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB  = $(obj)lib$(BOARD).o
> +
> +COBJS:= $(BOARD).o
> +
> +SRCS := $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/toradex/colibri_vf50/colibri_vf50.c 
> b/board/toradex/colibri_vf50/colibri_vf50.c
> new file mode 100644
> index 000..83b6a67
> --- /dev/null
> +++ b/board/toradex/colibri_vf50/colibri_vf50.c
> @@ -0,0 +1,413 @@
> +/*
> + * Copyright 2013 Toradex, Inc.
> + *
> + * Based on vf610twr.c:
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL(PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> + PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define ESDHC_PAD_CTRL   (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_HIGH | \
> + PAD_CTL_DSE_20ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
> + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +void setup_iomux_ddr(void)
> +{
> + static const iomux_v3_cfg_t ddr_pads[] = {
> + VF610_PAD_DDR_A15__DDR_A_15,
> + VF610_PAD_DDR_A14__DDR_A_14,
> + VF610_PAD_DDR_A13__DDR_A_13,
> + VF610_PAD_DDR_A12__DDR_A_12,
> + VF610_PAD_DDR_A11__DDR_A_11,
> + VF610_PAD_DDR_A10__DDR_A_10,
> + VF610_PAD_DDR_A9__DDR_A_9,
> + VF610_PAD_DDR_A8__DDR_A_8,
> + VF610_PAD_DDR_A7__DDR_A_7,
> + VF610_PAD_DDR_A6__DDR_A_6,
> + VF610_PAD_DDR_A5__DDR_A_5,
> + VF610_PAD_DDR_A4__DDR_A_4,
> + VF610_PAD_DDR_A3__DDR_A_3,
> + VF610_PAD_DDR_A2__DDR_A_2,
> + VF610_PAD_DDR_A1__DDR_A_1,
> + VF610_PAD_DDR_BA2__DDR_BA_2,
> + VF610_PAD_DDR_BA1__DDR_BA_1,
> + VF610_PAD_DDR_BA0__DDR_BA_0,
> + VF610_PAD_DDR_CAS__DDR_CAS_B,
> + VF610_PAD_DDR_CKE__DDR_CKE_0,
> + VF610_PAD_DDR_CLK__DDR_CLK_0,
> + VF610_PAD_DDR_CS__DDR_CS_B_0,
> + VF610_PAD_DDR_D15__DDR_D_15,
> + VF610_PAD_DDR_D14__DDR_D_14,
> + VF610_PAD_DDR_D13__DDR_D_13,
> + VF610_PAD_DDR_D12__DDR_D_12,
> + VF610_PAD_DDR_D11__DDR_D_11,
> + VF610_PAD_DDR_D10__DDR_D_10,
> + VF610_PAD_DDR_D9__DDR_D_9,
> + VF610_PAD_DDR_D8__DDR_D_8,
> + VF610_PAD_DDR_D7__DDR_D_7,
> + VF610_PAD_DDR_D6__DDR_D_6,
> + VF610_PAD_DDR_D5__DDR_D_5,
> + VF610_PAD_DDR_D4__DDR_D_4,
> + VF610_PAD_DDR_D3__DDR_D_3,
> + VF610_PAD_DDR_D2__DDR_D_2,
> + VF610_

Re: [U-Boot] [ANN] U-Boot v2013.10 released

[Albert ARIBAUD]

On Wed, 16 Oct 2013 15:50:07 -0400, Tom Rini  wrote:

> Hey all,
> 
> I've pushed v2013.10 out to the repository and tarballs should exist
> soon. 
> 
> Once again, lots of nice little things around the tree have been done,
> your favorite platform is probably gotten a nice tweak or two and we've
> now got things like QSPI support in for a few platforms and controllers.
> 
> The big, diffstat wise at least, change is that now instead of large
> boilerplate messages in every file about the license we use SPDX tags in
> all files to identify what license(s) apply here.  And the source code
> itself got trimmed down a good bit.  Thanks Wolfgang!
> 
> I'm pushing the merge window for 2014.01 out a week to Nov 07 to make up
> for getting this out a little late.  We'll still aim to release
> v2014.01 on Jan 13.
> 
> Thanks all!

(Custodians of ARM-related repos CC:ed)

U-Bot-arm has now merged (well, fast-forwarded to) u-boot/master.

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

[U-Boot] [RESEND PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h

[Javier Martinez Canillas]

From: Javier Martinez Canillas 

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Enric Balletbo i Serra 
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg| 2 +-
 include/configs/{igep0033.h => am335x_igep0033.h} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename include/configs/{igep0033.h => am335x_igep0033.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index aa2ee64..c8b7868 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -246,7 +246,7 @@ Active  arm arm946es   -   armltd   
   integrator
 Active  arm armv7  -   armltd  vexpress
vexpress_ca15_tc2-  

   -
 Active  arm armv7  -   armltd  vexpress
vexpress_ca5x2   -  

   Matt Waddel 
 Active  arm armv7  -   armltd  vexpress
vexpress_ca9x4   -  

   Matt Waddel 
-Active  arm armv7  am33xx  iseeigep0033
igep0033 -  

   Enric Balletbo i Serra 
+Active  arm armv7  am33xx  iseeigep0033
am335x_igep0033  -  

   Enric Balletbo i Serra 
 Active  arm armv7  am33xx  phytec  pcm051  
pcm051   pcm051 

   Lars Poeschel 
 Active  arm armv7  am33xx  siemens dxr2
dxr2 -  

   Roger Meier 
 Active  arm armv7  am33xx  siemens pxm2
pxm2 -  

   Roger Meier 
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
-- 
1.8.4.rc3

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

[U-Boot] [RESEND PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h

[Javier Martinez Canillas]

From: Javier Martinez Canillas 

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Enric Balletbo i Serra 
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg   | 10 +-
 include/configs/{igep00x0.h => omap3_igep00x0.h} |  0
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename include/configs/{igep00x0.h => omap3_igep00x0.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index c8b7868..3d35308 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -311,11 +311,11 @@ Active  arm armv7  omap3   comelit
 dig297
 Active  arm armv7  omap3   compulabcm_t35  
cm_t35   -  

   Igor Grinberg 
 Active  arm armv7  omap3   corscience  tricorder   
tricorder-  

   Thomas Weber 
 Active  arm armv7  omap3   htkwmcx 
mcx  -  

   Ilya Yanok 
-Active  arm armv7  omap3   iseeigep00x0
igep0020 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND  
  Enric Balletbo i Serra 

-Active  arm armv7  omap3   iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0030 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND  
  Enric Balletbo i Serra 

-Active  arm armv7  omap3   iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0032 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND  
  Enric Balletbo i Serra 

+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra 

+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra 

+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0032   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra 

 Active  arm armv7  omap3   logicpd am3517evm   
am3517_evm   -  

   Vaibhav Hiremath 
 Active  arm armv7  omap3   logicpd omap3som
omap3_logic  - 

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Kushwaha Prabhakar-B32579]

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of York Sun
> Sent: Thursday, October 17, 2013 4:14 AM
> To: Wood Scott-B07421
> Cc: Tom Rini; u-boot@lists.denx.de
> Subject: Re: [U-Boot] powerpc/mpc85xx: Increase image size
> 
> On 10/16/2013 02:23 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:44 -0700, York Sun wrote:
> >> On 10/16/2013 01:41 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 13:38 -0700, York Sun wrote:
>  On 10/16/2013 01:33 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
> >> On 10/16/2013 01:29 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
>  On 10/16/2013 12:37 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
> >> Are SPL and TPL boot methods immune from the size issue here?
> >
> > Sort of.  We still need to fit inside existing partition
> tables.
> >
> 
>  PBL boot will be broken if the image size is bigger than 512KB,
> right?
> >>>
> >>> It has to be even smaller than that, to make room for early data.
> >>>
> >>
> >> So if we go with 768KB, do we have to convert all PBL boot to SPL
> boot?
> >
> > Only the targets that need the extra space.
> >
> 
>  We have T4, B4 and corenet_ds using PBL boot. They most likely will
>  exceed the 512KB soon, if not yet. It maybe easier to change all of
>  them togther, than one by one.
> >>>
> >>> There's no reason to change them all at once.  It doesn't make
> >>> anything easier; it just means you have to do a bunch of testing all
> >>> at once, and force a change in procedure for users on boards where
> >>> it otherwise would not have been required.
> >>
> >> You are right here.
> >>
> >>>
> >>> Plus, the 512K limit is for e500v2-based chips.  Newer chips have
> >>> CPC for SRAM which is larger than 512K.
> >>>
> >>
> >> Hmm? T4240 has 512KB CPC.
> >
> > Each CPC is 512K, but there are three of them.  Is it possible to use
> > more than one for SRAM, contiguously?
> 
> I think it is possible to use two CPC. The PBL boot method is hard-coded
> to take 512KB u-boot.bin and generate u-boot.pbl. It surely can be
> improved. My point is making a move for all concerned platforms may be
> easier for maintenance.
> 

We can go ahead with 2 stage boot loaders for SoC having < 1MB CPC.
We have already sent patch for T1040 which has 256K CPC. This same patch can be 
used for T4 and B4.

FYI, I have also sent one RFC for B4 with 2stage boot loader. It can be taken 
as full patch.

Regards,
Prabhakar



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

[U-Boot] [PATCH v2] mpc85xx: Fix the offset of register address error

[Yuantian.Tang]

From: Tang Yuantian 

The offset of register address within GPIO module is just
CONFIG_SYS_MPC85xx_GPIO_ADDR. So, fix it. The following platforms
are confirmed: MPC8572, P1023, P1020, P1022, P2020, P4080,
P5020, P5040, T4240, B4860.

Signed-off-by: Tang Yuantian 
---
v2:
- updated the commit message.

 arch/powerpc/include/asm/mpc85xx_gpio.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h 
b/arch/powerpc/include/asm/mpc85xx_gpio.h
index 3d11884..87bb4a0 100644
--- a/arch/powerpc/include/asm/mpc85xx_gpio.h
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -20,7 +20,7 @@
 static inline void mpc85xx_gpio_set(unsigned int mask,
unsigned int dir, unsigned int val)
 {
-   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
 
/* First mask off the unwanted parts of "dir" and "val" */
dir &= mask;
@@ -56,7 +56,7 @@ static inline void mpc85xx_gpio_set_high(unsigned int gpios)
 
 static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
 {
-   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
 
/* Read the requested values */
return in_be32(&gpio->gpdat) & mask;
-- 
1.8.0


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

[U-Boot] Beaglebone LCD support in U-Boot?

[Simon Glass]

Hi,

Is there any LCD driver for the Beaglebone?

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

[U-Boot] Pull request: u-boot-sh/master

[Nobuhiro Iwamatsu]

Hi Tom,

Please pull u-boot-sh master branch.

Best regards,
  Nobuhiro
The following changes since commit 183acb700378a8cfc5d50a01a65de93fb2c24586:

  Prepare v2013.10 (2013-10-16 13:08:12 -0400)

are available in the git repository at:

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

for you to fetch changes up to 7f2013d47c8c62c2373cafe68d6ba4649099e49a:

  serial: sh: Add support R8A7791 (2013-10-17 09:43:36 +0900)


Nobuhiro Iwamatsu (8):
  sh: timer: Mask bit of timer prescaler
  sh: timer: Remove static global variable
  sh: cache: Change cache API to defines as U-Boot
  sh: timer: Change definition of clock of TMU
  serial: sh: Change definition of clock of SCIF
  sh: boards: Change clock definition of SCIF and TMU
  serial: sh: Add support R8A7790
  serial: sh: Add support R8A7791

 arch/sh/cpu/sh4/cache.c  |  4 ++--
 arch/sh/cpu/sh4/cpu.c|  2 +-
 arch/sh/include/asm/cache.h  |  3 ---
 arch/sh/lib/time.c   | 10 ++
 drivers/serial/serial_sh.c   |  5 -
 drivers/serial/serial_sh.h   | 13 +
 include/configs/MigoR.h  |  2 ++
 include/configs/ap325rxa.h   |  2 ++
 include/configs/ap_sh4a_4a.h |  2 ++
 include/configs/ecovec.h |  2 ++
 include/configs/espt.h   |  2 ++
 include/configs/mpr2.h   |  2 ++
 include/configs/ms7720se.h   |  2 ++
 include/configs/ms7722se.h   |  2 ++
 include/configs/ms7750se.h   |  2 ++
 include/configs/r0p7734.h|  2 ++
 include/configs/r2dplus.h|  2 ++
 include/configs/r7780mp.h|  2 ++
 include/configs/rsk7203.h|  2 ++
 include/configs/rsk7264.h|  2 ++
 include/configs/rsk7269.h|  2 ++
 include/configs/sh7752evb.h  |  2 ++
 include/configs/sh7757lcr.h  |  2 ++
 include/configs/sh7763rdp.h  |  2 ++
 include/configs/sh7785lcr.h  |  2 ++
 include/configs/shmin.h  |  2 ++
 include/sh_tmu.h |  2 +-
 27 files changed, 67 insertions(+), 12 deletions(-)

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-mpc85xx/master

[York Sun]

Tom,

The following changes since commit 183acb700378a8cfc5d50a01a65de93fb2c24586:

  Prepare v2013.10 (2013-10-16 13:08:12 -0400)

are available in the git repository at:

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

for you to fetch changes up to 287df01e6aef0464c5e5bcbd7e87aa4ff1f24f5a:

  PCIe:change the method to get the address of a requested capability in
configuration space. (2013-10-16 16:15:17 -0700)


Po Liu (3):
  powerpc: add CONFIG_SECURE_BOOT condition into fsl_secure_boot.h
  powerpc:c29xpcie: make ifc timing parameter flexible
  powerpc/c29xpcie: modify DDR parameter to make DDR more stable

Prabhakar Kushwaha (6):
  powerpc/mpc85xx:Make L2 cache type independent of CHASSIS2
  powerpc/mpc85xx:Update processor defines for T1040
  powerpc/mpc85xx:Avoid fix clk groups for Cluster & HW accelerator
  board/bsc9131rdb: Update IFC timings for NAND flash
  powerpc/t1040qds: Add T1040QDS board
  boards/c29xpcie: Update TLB and LAW size for IFC NAND, CPLD

Priyanka Jain (1):
  powerpc: Fix CamelCase warnings in DDR related code

Shaohui Xie (3):
  powerpc/t4240: updated rcw_cfg to align with default hardware
configuration
  powerpc/B4860: enable PBL tool for B4860
  powerpc/tool/pbl: fix pbl image compiling process

Shengzhou Liu (4):
  powerpc/p1010rdb: remove unused cpld_show
  powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256-bytes EEPROM
  board/p1010rdb: add pin mux and sdhc support in any boot
  powerpc/p1010rdb: add p1010rdb-pb support with updating p1010rdb-pa

Ying Zhang (3):
  powerpc: p1_p2_rdb_pc: Enable p1_p2_rdb_pc to boot from SD Card
with SPL
  powerpc : p1_p2_rdb_pc : Enable p1_p2_rdb_pc to start from eSPI
with SPL
  powerpc: p1_p2_rdb_pc: add TPL for p1_p2_rdb_pc nand boot

York Sun (1):
  powerpc/mpc85xx: Add workaround for erratum A006379

Zhao Qiang (3):
  Corenet/p5040/SGMII:fix the problem for SGMII5/6
  SGMII:fix PHY addresses for QSGMII Riser Card working in SGMII mode
  PCIe:change the method to get the address of a requested
capability in configuration space.

ramneek mehresh (1):
  powerpc/usb: Mention usb1 before usb2 inside default hwconfig string

 Makefile   |1 +
 arch/powerpc/cpu/mpc85xx/cmd_errata.c  |5 +
 arch/powerpc/cpu/mpc85xx/cpu_init.c|   13 +-
 arch/powerpc/cpu/mpc85xx/fdt.c |2 +-
 arch/powerpc/cpu/mpc85xx/speed.c   |  114 +--
 arch/powerpc/cpu/mpc85xx/start.S   |2 +-
 .../powerpc/cpu/mpc8xxx/ddr/common_timing_params.h |   46 +-
 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c   |   76 +-
 arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |2 +-
 arch/powerpc/cpu/mpc8xxx/ddr/ddr1_dimm_params.c|   52 +-
 arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c|   52 +-
 arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c|   54 +-
 arch/powerpc/cpu/mpc8xxx/ddr/interactive.c |  312 
 .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c|  214 +++---
 arch/powerpc/cpu/mpc8xxx/ddr/main.c|6 +-
 arch/powerpc/cpu/mpc8xxx/ddr/options.c |   34 +-
 arch/powerpc/include/asm/config_mpc85xx.h  |   35 +-
 arch/powerpc/include/asm/fsl_ddr_dimm_params.h |   48 +-
 arch/powerpc/include/asm/fsl_ddr_sdram.h   |   28 +-
 arch/powerpc/include/asm/fsl_errata.h  |   25 +
 arch/powerpc/include/asm/fsl_pci.h |   18 -
 arch/powerpc/include/asm/fsl_secure_boot.h |2 +
 arch/powerpc/include/asm/immap_512x.h  |4 +-
 arch/powerpc/include/asm/immap_85xx.h  |   22 +-
 board/exmeritus/hww1u1a/ddr.c  |2 +-
 board/freescale/b4860qds/b4860qds_qixis.h  |5 +
 board/freescale/b4860qds/b4_pbi.cfg|   27 +
 board/freescale/b4860qds/b4_rcw.cfg|7 +
 board/freescale/b4860qds/ddr.c |   32 +-
 board/freescale/b4860qds/eth_b4860qds.c|   18 +
 board/freescale/bsc9131rdb/ddr.c   |   26 +-
 board/freescale/bsc9132qds/ddr.c   |   26 +-
 board/freescale/c29xpcie/ddr.c |   28 +-
 board/freescale/c29xpcie/law.c |4 +-
 board/freescale/c29xpcie/tlb.c |4 +-
 board/freescale/common/qixis.h |4 +-
 board/freescale/common/sys_eeprom.c|4 +
 board/freescale/corenet_ds/ddr.c   |6 +-
 board/freescale/corenet_ds/eth_hydra.c |6 +
 board/freescale/corenet_ds/eth_p4080.c |   12 +
 board/freescale/corenet_ds/eth_superhydra.c|   72 +-
 board/freescale/mpc8349emds/ddr.c  |8 +-
 board/freescale/mpc8540ads/ddr.c   |2 +-
 board/freescale/mpc8544ds/ddr.c  

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/16/2013 02:23 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:44 -0700, York Sun wrote:
>> On 10/16/2013 01:41 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 13:38 -0700, York Sun wrote:
 On 10/16/2013 01:33 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
>> On 10/16/2013 01:29 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
 On 10/16/2013 12:37 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
>> Are SPL and TPL boot methods immune from the size issue here?
>
> Sort of.  We still need to fit inside existing partition tables.
>

 PBL boot will be broken if the image size is bigger than 512KB, right?
>>>
>>> It has to be even smaller than that, to make room for early data.
>>>
>>
>> So if we go with 768KB, do we have to convert all PBL boot to SPL boot?
>
> Only the targets that need the extra space.
>

 We have T4, B4 and corenet_ds using PBL boot. They most likely will
 exceed the 512KB soon, if not yet. It maybe easier to change all of them
 togther, than one by one.
>>>
>>> There's no reason to change them all at once.  It doesn't make anything
>>> easier; it just means you have to do a bunch of testing all at once, and
>>> force a change in procedure for users on boards where it otherwise would
>>> not have been required.
>>
>> You are right here.
>>
>>>
>>> Plus, the 512K limit is for e500v2-based chips.  Newer chips have CPC
>>> for SRAM which is larger than 512K.
>>>
>>
>> Hmm? T4240 has 512KB CPC.
> 
> Each CPC is 512K, but there are three of them.  Is it possible to use
> more than one for SRAM, contiguously?

I think it is possible to use two CPC. The PBL boot method is hard-coded
to take 512KB u-boot.bin and generate u-boot.pbl. It surely can be
improved. My point is making a move for all concerned platforms may be
easier for maintenance.

York

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

Re: [U-Boot] [ANN] U-Boot v2013.10 released

[Scott Wood]

On Wed, 2013-10-16 at 15:50 -0400, Tom Rini wrote:
> The big, diffstat wise at least, change is that now instead of large
> boilerplate messages in every file about the license we use SPDX tags in
> all files to identify what license(s) apply here.  And the source code
> itself got trimmed down a good bit.  Thanks Wolfgang!

It looks like drivers/mtd/nand/nand_util.c was converted from "gpl v2
only, with Freescale preemptively granting permission for v2+" to just
"v2+".  Was permission obtained from the other copyright holders?

-Scott



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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Scott Wood]

On Wed, 2013-10-16 at 13:44 -0700, York Sun wrote:
> On 10/16/2013 01:41 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:38 -0700, York Sun wrote:
> >> On 10/16/2013 01:33 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
>  On 10/16/2013 01:29 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
> >> On 10/16/2013 12:37 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
>  Are SPL and TPL boot methods immune from the size issue here?
> >>>
> >>> Sort of.  We still need to fit inside existing partition tables.
> >>>
> >>
> >> PBL boot will be broken if the image size is bigger than 512KB, right?
> >
> > It has to be even smaller than that, to make room for early data.
> >
> 
>  So if we go with 768KB, do we have to convert all PBL boot to SPL boot?
> >>>
> >>> Only the targets that need the extra space.
> >>>
> >>
> >> We have T4, B4 and corenet_ds using PBL boot. They most likely will
> >> exceed the 512KB soon, if not yet. It maybe easier to change all of them
> >> togther, than one by one.
> > 
> > There's no reason to change them all at once.  It doesn't make anything
> > easier; it just means you have to do a bunch of testing all at once, and
> > force a change in procedure for users on boards where it otherwise would
> > not have been required.
> 
> You are right here.
> 
> > 
> > Plus, the 512K limit is for e500v2-based chips.  Newer chips have CPC
> > for SRAM which is larger than 512K.
> > 
> 
> Hmm? T4240 has 512KB CPC.

Each CPC is 512K, but there are three of them.  Is it possible to use
more than one for SRAM, contiguously?

Still, I find it curious that T4240 has less CPC than P4080, and less
CPC than L2 cache.

-Scott



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

Re: [U-Boot] [PATCH v2] Tegra114: Add support for more clock sources for T114 periphs

[Stephen Warren]

MASK_BITS_31_30On 10/15/2013 04:54 PM, Tom Warren wrote:
> Some T114 peripherals can take up to 8 different clock
> sources (parents), including 4 new ones that don't exist
> on previous chips (PLLC2/C3/MEM2/SRC2). Expand clock/pll
> code/tables to support these additional bits/sources.

I would really like Peter De Schrijver to review this patch, since he
wrote the upstream Tegra124 clock driver, which involved a lot of driver
unification with previous SoCs. I'd like him to take a look at the mux
mask widths in particular, w.r.t. making sure that U-Boot, the kernel,
and the TRM all agree on which peripherals have which size mux field.

In particular, clk-tegra-periph.c in Peter's patches contains clocks
with mux fields in bits 31:30 or bits 31:29; there is no clock with a
mux field in bits 31:28. Yet, OUT_CLK_SOURCE4_* in U-Boot (before this
patch) represent a mux field in bits 31:28. If this is wrong, I believe
we need to fix it before applying this patch. If the TRM is wrong, we
need to file a bug agaist it.

> Changes were made to some common code. Testing on T30/T20
> showed no changes in periph clock sources/divisors.
> 
> Also, peripheral clock sources that no longer exist on T114
> were removed from the clock_periph_type table (CVE, TVDAC, etc.),
> and periphs that are gone or not needed in early init are
> no longer brought out of reset/enabled (FUSE, IRAMA/B/C/D, etc.).

As I mentioned in the response I just sent to V1, removing things seems
like it should be in a separate patch, so each patch does just one
logical thing.

> diff --git a/arch/arm/cpu/tegra-common/clock.c 
> b/arch/arm/cpu/tegra-common/clock.c
> index 268fb91..62a2191 100644
> --- a/arch/arm/cpu/tegra-common/clock.c
> +++ b/arch/arm/cpu/tegra-common/clock.c
> @@ -304,13 +304,24 @@ static int adjust_periph_pll(enum periph_id periph_id, 
> int source,
>   /* work out the source clock and set it */
>   if (source < 0)
>   return -1;
> - if (mux_bits == 4) {

mux_bits is a parameter to this function. I don't see this patch
changing the way this function is called, so I have to assume that the
same values are passed to the function before and after this patch.
Based on the switch statement that's added below, I assume that the
defines MASK_BITS_* are passed into this function as mux_bits.

In that case, the "4" in that if expression means MASK_BITS_29_28.
However, OUT_CLK_SOURCE4_MASK/SHIFT means a mask in bits 31:28. Perhaps
the "4" wasn't originally meant to indicate "number of bits in mux
field", but rather "number of possible values representable in the mux
field"?

While this may be a pre-existing issue, I believe it is imperative that
we fix this before confusing the matter further by building more patches
on top of it.

> - clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> - source << OUT_CLK_SOURCE4_SHIFT);
> - } else {
> +
> + switch (mux_bits) {
> + case MASK_BITS_31_30:
>   clrsetbits_le32(reg, OUT_CLK_SOURCE_MASK,
>   source << OUT_CLK_SOURCE_SHIFT);

OUT_CLK_SOURCE_* do indeed represent a mask/shift for bits 31:30, so
that's probably OK.

> + break;
> +
> + case MASK_BITS_31_29:
> + clrsetbits_le32(reg, OUT_CLK_SOURCE3_MASK,
> + source << OUT_CLK_SOURCE3_SHIFT);

OUT_CLK_SOURCE3_* do indeed represent a mask/shift for bits 31:30, so
that's probably OK.

> + break;
> +
> + case MASK_BITS_29_28:
> + clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> + source << OUT_CLK_SOURCE4_SHIFT);

OUT_CLK_SOURCE4_* do NOT represent a mask/shift for bits 29:28, but
rather for bits 31:28. Again, I think the meaning, value, and name of
MASK_BITS_29_28 and OUT_CLK_SOURCE4_* need to be fixed and made
consistent prior to this patch.

I would also suggest making separate patches for the following so
they're all much simpler:

* Removing clock definitions.

* Removing reset twiddling for some clocks.

* The assert fix.

* Updating adjust_periph_pll() to support different mux mask location/size.

* Adding new clocks that rely on the the new mux mask location/size. Or,
perhaps just adding new clocks, period.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] U-Boot v2013.10 released

[Wolfgang Denk]

Dear Tom,

In message <20131016195007.GA17401@bill-the-cat> you wrote:
> 
> I've pushed v2013.10 out to the repository and tarballs should exist
> soon. 

The tarball is ready in place on the FTP server.

> Once again, lots of nice little things around the tree have been done,
> your favorite platform is probably gotten a nice tweak or two and we've
> now got things like QSPI support in for a few platforms and controllers.
>
> The big, diffstat wise at least, change is that now instead of large
> boilerplate messages in every file about the license we use SPDX tags in
> all files to identify what license(s) apply here.  And the source code
> itself got trimmed down a good bit.  Thanks Wolfgang!

Thanks - heh, that was actually a cheap way to make top of the
statistics :-)

BTW - the full statistica are available at [1]; here as usual the short
version:

Processed 710 csets from 134 developers
25 employers found
A total of 55489 lines added, 119445 removed (delta -63956)

Developers with the most changesets
Tom Rini61 (8.6%)
Jagannadha Sutradharudu Teki   52 (7.3%)
Marek Vasut 37 (5.2%)
Gabor Juhos 29 (4.1%)
Heiko Schocher  27 (3.8%)
Fabio Estevam   21 (3.0%)
York Sun18 (2.5%)
Masahiro Yamada 18 (2.5%)
Bo Shen 17 (2.4%)
Wolfgang Denk   17 (2.4%)
...

Developers with the most changed lines
Wolfgang Denk 97843 (62.2%)
Heiko Schocher7975 (5.1%)
Marek Vasut   7163 (4.6%)
Albert ARIBAUD3987 (2.5%)
Jagannadha Sutradharudu Teki 3135 (2.0%)
Bo Shen   2030 (1.3%)
Dirk Eibach   1747 (1.1%)
Piotr Wilczek 1691 (1.1%)
Masahiro Yamada   1689 (1.1%)
trem  1599 (1.0%)
...

Developers with the most lines removed
Wolfgang Denk 89188 (74.7%)
Albert ARIBAUD2630 (2.2%)
Masahiro Yamada   1623 (1.4%)
Matthias Fuchs1431 (1.2%)
Fabio Estevam  852 (0.7%)
Jagannadha Sutradharudu Teki  843 (0.7%)
Roger Meier334 (0.3%)
Stephen Warren  35 (0.0%)
Minkyu Kang 28 (0.0%)
Axel Lin20 (0.0%)
...

Developers with the most signoffs (total 148)
Andreas Bießmann   19 (12.8%)
Tom Rini16 (10.8%)
Minkyu Kang 12 (8.1%)
Stefan Roese12 (8.1%)
Kyungmin Park   11 (7.4%)
Simon Glass  7 (4.7%)
Jagannadha Sutradharudu Teki6 (4.1%)
Michal Simek 6 (4.1%)
York Sun 6 (4.1%)
Sonic Zhang  4 (2.7%)
...

Developers with the most reviews (total 44)
Jagannadha Sutradharudu Teki   11 (25.0%)
Peter Korsgaard  8 (18.2%)
Tom Rini 7 (15.9%)
Javier Martinez Canillas 6 (13.6%)
Pavel Machek 5 (11.4%)
Otavio Salvador  2 (4.5%)
Lukasz Majewski  2 (4.5%)
Stephen Warren   1 (2.3%)
Thierry Reding   1 (2.3%)
Kuo-Jung Su  1 (2.3%)

Developers with the most test credits (total 23)
Heiko Schocher   6 (26.1%)
Stephen Warren   2 (8.7%)
Luka Perkov  2 (8.7%)
Holger Brunck2 (8.7%)
Stefan Roese 1 (4.3%)
Marek Vasut  1 (4.3%)
Hector Palacios  1 (4.3%)
Aparna Balasubramanian   1 (4.3%)
Chris Packham1 (4.3%)
Enric Balletbo i Serra   1 (4.3%)
...

Developers who gave the most tested-by credits (total 23)
Heiko Schocher   4 (17.4%)
Tom Rini 3 (13.0%)
Lokesh Vutla 3 (13.0%)
Fabio Estevam3 (13.0%)
Oliver Metz  2 (8.7%)
Jagannadha Sutradharudu Teki1 (4.3%)
Lukasz Majewski  1 (4.3%)
Thierry Reding   1 (4.3%)
Simon Glass  1 (4.3%)
Masahiro Yamada  1 (4.3%)
...

Developers with the most report credits (total 5)
Hector Palacios  1 (20.0%)
Steven Falco 1 (20.0%)
Stephen MacMahon 1 (20.0%)
Robert Nelson1 (20.0%)
Pardeep Kumar Singla 1 (20.0%)

Developers who gave the most report credits (total 5)
Fabio Estevam2 (40.0%)
Tom Rini 1 (20.0%)
Nishanth Menon   1 (20.0%)
Michal Simek 1 (20.0%)

Top changeset contributors by employer
(Unknown)  172 (24.2%)
Texas Instruments  115 (16.2%)
DENX Software Engineering   92 (13.0%)
Freescale   90 (12.7%)
Xilinx  61 (8.6%)
Samsung 36 (5.1%)
Atmel   22 (3.1%)
Calxeda 19 (2.7%)
Panasonic   18 (2.5%)
NVidia  16 (2.3%)
...

Top lines changed by employer
DENX Software Engineering 115307 (73.3%)
(Unknown) 

Re: [U-Boot] [PATCH] Tegra114: Add support for more clock sources for T1x4 periphs

[Stephen Warren]

On 10/15/2013 04:42 PM, Tom Warren wrote:
> On Tue, Oct 8, 2013 at 2:08 PM, Stephen Warren  > wrote:

> > diff --git a/arch/arm/cpu/tegra-common/clock.c
> b/arch/arm/cpu/tegra-common/clock.c
> > index 268fb91..c703c40 100644
> > --- a/arch/arm/cpu/tegra-common/clock.c
> > +++ b/arch/arm/cpu/tegra-common/clock.c
> > @@ -304,13 +304,24 @@ static int adjust_periph_pll(enum periph_id
> periph_id, int source,
> >   /* work out the source clock and set it */
> >   if (source < 0)
> >   return -1;
> > - if (mux_bits == 4) {
> > - clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> > - source << OUT_CLK_SOURCE4_SHIFT);
> 
> That implies 4 bits ...
> 
> > + switch (mux_bits) {
> 
> > + case MASK_BITS_29_28:
> > + clrsetbits_le32(reg, OUT_CLK_SOURCE4_MASK,
> > + source << OUT_CLK_SOURCE4_SHIFT);
> 
> ... but that implies 2 bits (29, 28). There's some inconsistency in the
> naming there.
> 
> I didn't do the original patch (this code has been in there for awhile -
> I'm only adding the new clock sources table/periph clocks for T114+), so
> I can't say why this naming was chosen. Perhaps you can run it down
> upstream (or in our internal T30 repo) using git-blame and query the
> original author (Jimmy, Allen, etc.).

That's the job of the patch submitter, not the reviewer. It'd be best if
the original author upstreamed the patch; everyone needs to get fully
involved in upstreaming, rather than relying on others to do their work
for them.

>  Regardless, as far as I can tell,
> only CLK_SOURCE_PWM uses bits 29:28, and may be a typo in the T30 TRM.
> T114+ have changed it to bits 31:29. All other periphs use 2-bit (31:30)
> and 3-bit (31:29) CLK_SRC fields (4 or 8 possible sources) in my
> searches of the Tegra30/114/124 TRMs.  We've never set a clock source
> for PWM in any version of U-Boot AFAICT.
> 
> 
> Can't we use the OUT_CLK_SOURCE4_MASK macros instead of inventing new
> MASK_BITS_29_28 macros, or something like that? Or perhaps simply store
> the shift and mask values in per-clock data, so there's no need for
> conditional code here.
> 
> No new macros here, just using the MASK bits in a switch statement,

The patch adds the following, which doesn't look like it's named
consistently:

+#define OUT_CLK_SOURCE3_SHIFT  29
+#define OUT_CLK_SOURCE3_MASK   (7U << OUT_CLK_SOURCE3_SHIFT)

> because the 31:29 case wasn't covered. I'm loath to change it now since
> this is only supposed to be a patch to add additional clock source
> tables that came into being w/T114, and this is common code. I'll leave
> it as-is and if you want to submit a cleanup patch later, I'll Ack it.

> > diff --git a/arch/arm/cpu/tegra114-common/clock.c
> b/arch/arm/cpu/tegra114-common/clock.c
> 
> > @@ -122,110 +160,120 @@ static enum clock_type_id
> clock_periph_type[PERIPHC_COUNT] = {
> 
> > - TYPE(PERIPHC_NONE,  CLOCK_TYPE_NONE),
> ...
> > + TYPE(PERIPHC_05h,   CLOCK_TYPE_NONE),
> 
> Isn't that an unrelated change? At least the need for this should be
> mentioned in the commit description.
> 
> 
> The precedent in this file seemed to be to use a hex number suffix for
> 'empty' slots, so I replaced PERIPHC_NONE with PERIPHC_05h to be
> consistent. Since I was removing clocks/regs that had been removed in
> the T114 TRM (see below), this seemed a good time for it. I can add a
> note about it in the commit msg.

The patch description talks about adding support for more clock sources,
not fixing bugs with existing clock sources. Those two things sound like
they should be different patches; one fix/cleanup, one new feature.
Then, each patch would be simpler.

Anyway, I'll take another look at V2 and put more detailed comments there.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/16/2013 01:41 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:38 -0700, York Sun wrote:
>> On 10/16/2013 01:33 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
 On 10/16/2013 01:29 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
>> On 10/16/2013 12:37 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
 Are SPL and TPL boot methods immune from the size issue here?
>>>
>>> Sort of.  We still need to fit inside existing partition tables.
>>>
>>
>> PBL boot will be broken if the image size is bigger than 512KB, right?
>
> It has to be even smaller than that, to make room for early data.
>

 So if we go with 768KB, do we have to convert all PBL boot to SPL boot?
>>>
>>> Only the targets that need the extra space.
>>>
>>
>> We have T4, B4 and corenet_ds using PBL boot. They most likely will
>> exceed the 512KB soon, if not yet. It maybe easier to change all of them
>> togther, than one by one.
> 
> There's no reason to change them all at once.  It doesn't make anything
> easier; it just means you have to do a bunch of testing all at once, and
> force a change in procedure for users on boards where it otherwise would
> not have been required.

You are right here.

> 
> Plus, the 512K limit is for e500v2-based chips.  Newer chips have CPC
> for SRAM which is larger than 512K.
> 

Hmm? T4240 has 512KB CPC.

York


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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Scott Wood]

On Wed, 2013-10-16 at 13:38 -0700, York Sun wrote:
> On 10/16/2013 01:33 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
> >> On 10/16/2013 01:29 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
>  On 10/16/2013 12:37 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
> >> Are SPL and TPL boot methods immune from the size issue here?
> >
> > Sort of.  We still need to fit inside existing partition tables.
> >
> 
>  PBL boot will be broken if the image size is bigger than 512KB, right?
> >>>
> >>> It has to be even smaller than that, to make room for early data.
> >>>
> >>
> >> So if we go with 768KB, do we have to convert all PBL boot to SPL boot?
> > 
> > Only the targets that need the extra space.
> > 
> 
> We have T4, B4 and corenet_ds using PBL boot. They most likely will
> exceed the 512KB soon, if not yet. It maybe easier to change all of them
> togther, than one by one.

There's no reason to change them all at once.  It doesn't make anything
easier; it just means you have to do a bunch of testing all at once, and
force a change in procedure for users on boards where it otherwise would
not have been required.

Plus, the 512K limit is for e500v2-based chips.  Newer chips have CPC
for SRAM which is larger than 512K.

-Scott



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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/16/2013 01:33 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
>> On 10/16/2013 01:29 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
 On 10/16/2013 12:37 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
>> Are SPL and TPL boot methods immune from the size issue here?
>
> Sort of.  We still need to fit inside existing partition tables.
>

 PBL boot will be broken if the image size is bigger than 512KB, right?
>>>
>>> It has to be even smaller than that, to make room for early data.
>>>
>>
>> So if we go with 768KB, do we have to convert all PBL boot to SPL boot?
> 
> Only the targets that need the extra space.
> 

We have T4, B4 and corenet_ds using PBL boot. They most likely will
exceed the 512KB soon, if not yet. It maybe easier to change all of them
togther, than one by one.

York



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

Re: [U-Boot] [PATCH v2] Tegra114: SPL: Set SCLK source to CLK_M before PLLP init.

[Stephen Warren]

On 10/15/2013 03:18 PM, Tom Warren wrote:
> From: Jimmy Zhang 
> 
> Based on the Tegra114 TRM, SCLK (system clock) can run up to 275MHz.
> At POR, the default SCLK source is set to PLLP_OUT0. In function
> clock_early_init(), PLLP_OUT0 will be set to 480MHz which is beyond
> the SCLK's upper limit.
> 
> The fix is to set SCLK source to CLK_M before initializing PLLP.
> Tested on A02 dalmore board.

> diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c 
> b/arch/arm/cpu/arm720t/tegra-common/spl.c

> +__weak void set_avp_clock_to_clkm(void)
> +{
> +}

Why do we need a weak symbol here? You always want to pick up the
implementation in arch/arm/cpu/arm720t/tegra114/cpu.c, or it won't work...

Sorry for not noticing this earlier.

> diff --git a/arch/arm/cpu/tegra114-common/clock.c 
> b/arch/arm/cpu/tegra114-common/clock.c

> @@ -653,6 +654,18 @@ void clock_early_init(void)
>   /* PLLD_MISC: Set CLKENABLE, CPCON 12, LFCON 1 */
>   writel(0x4C10, &clkrst->crc_pll[CLOCK_ID_DISPLAY].pll_misc);
>   udelay(2);
> +
> + /* Set PLLP_OUT3 and 4 freqs to 102MHz and 204MHz */
> + /* Assert RSTN before enable */
> + reg = PLLP_OUT4_RSTN_EN | PLLP_OUT3_RSTN_EN;
> + writel(reg, &clkrst->crc_pll[CLOCK_ID_PERIPH].pll_out[1]);
> +
> + /* set divisor and reenable */
> + reg = (IN_408_OUT_204_DIVISOR << PLLP_OUT4_RATIO)
> + | PLLP_OUT4_OVR | PLLP_OUT4_CLKEN | PLLP_OUT4_RSTN_DIS
> + | (IN_408_OUT_102_DIVISOR << PLLP_OUT3_RATIO)
> + | PLLP_OUT3_OVR | PLLP_OUT3_CLKEN | PLLP_OUT3_RSTN_DIS;
> + writel(reg, &clkrst->crc_pll[CLOCK_ID_PERIPH].pll_out[1]);

Rather than calling set_avp_clock_to_clkm() from spl.c, wouldn't it make
sense to call it from inside clock_early_init() where the PLL_P rate
change actually  happens? That would absolutely minimize the time the
AVP spends running at a slow speed.

Also, shouldn't there be a matching set_avp_clock_to_pllpout4() or
similar after PLL_P is fully configured, or the AVP will continue to run
slowly for the rest of the time too. Admittedly it doesn't run a lot of
code so the different isn't likely to be large, but just dumping it down
to 12MHz forever seems like a bad idea.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Scott Wood]

On Wed, 2013-10-16 at 13:32 -0700, York Sun wrote:
> On 10/16/2013 01:29 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
> >> On 10/16/2013 12:37 PM, Scott Wood wrote:
> >>> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
>  Are SPL and TPL boot methods immune from the size issue here?
> >>>
> >>> Sort of.  We still need to fit inside existing partition tables.
> >>>
> >>
> >> PBL boot will be broken if the image size is bigger than 512KB, right?
> > 
> > It has to be even smaller than that, to make room for early data.
> > 
> 
> So if we go with 768KB, do we have to convert all PBL boot to SPL boot?

Only the targets that need the extra space.

-Scott



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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/16/2013 01:29 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
>> On 10/16/2013 12:37 PM, Scott Wood wrote:
>>> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
 On 10/11/2013 11:56 AM, York Sun wrote:
> On 10/11/2013 11:39 AM, Scott Wood wrote:
>> On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
>>> Scott, et al.
>>>
>>> I'd like to start the discussion to increase u-boot image size for some
>>> mpc85xx targets. As we all know the reset vector is at the very end and
>>> linking process start from the top. This gives us no good choice but to
>>> use fixed image size. While we have more and more features, the size
>>> increases inevitably. It's time to adjust the arbitrary size. We are now
>>> using 512KB. Shall we go with 768KB, or even 1MB?
>>
>> 768K would affect fewer existing partition maps (many of which leave 1M
>> for U-Boot and environment combined), but 1M might be better for new
>> boards.  And of course it would be nice if someone could spare some time
>> to try to slim things down (finer-grained compile-time config,
>> speed/size tradeoffs, etc).
>>
>>> For the first step, I think we don't have to increase size for all
>>> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
>>> are the most recent used. There are other targets which don't use NOR
>>> flash boot method. They should be considered as well.
>>>
>>> It is per board configuration. But it may be better if we keep them
>>> consistent.
>>
>> I don't think it's worth trying to keep them consistent.  Leave alone
>> old boards that are not pushing the limit, and where testing and user
>> education would be a hassle, and let newer boards where more features
>> are wanted not be constrained by the past.
>>
>
> I did a quick search for eff8. Only these boards have it
>
> include/configs/B4860QDS.h
> include/configs/C29XPCIE.h
> include/configs/corenet_ds.h
> include/configs/HWW1U1A.h
> include/configs/MPC8536DS.h
> include/configs/MPC8572DS.h
> include/configs/P1010RDB.h
> include/configs/P1022DS.h
> include/configs/P1023RDB.h
> include/configs/P1023RDS.h
> include/configs/P1_P2_RDB.h
> include/configs/p1_p2_rdb_pc.h
> include/configs/p1_twr.h
> include/configs/P2020DS.h
> include/configs/P2041RDB.h
> include/configs/T1040QDS.h
> include/configs/t4qds.h
>

 Scott,

 Are SPL and TPL boot methods immune from the size issue here?
>>>
>>> Sort of.  We still need to fit inside existing partition tables.
>>>
>>
>> PBL boot will be broken if the image size is bigger than 512KB, right?
> 
> It has to be even smaller than that, to make room for early data.
> 

So if we go with 768KB, do we have to convert all PBL boot to SPL boot?

York



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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Scott Wood]

On Wed, 2013-10-16 at 13:22 -0700, York Sun wrote:
> On 10/16/2013 12:37 PM, Scott Wood wrote:
> > On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
> >> On 10/11/2013 11:56 AM, York Sun wrote:
> >>> On 10/11/2013 11:39 AM, Scott Wood wrote:
>  On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
> > Scott, et al.
> >
> > I'd like to start the discussion to increase u-boot image size for some
> > mpc85xx targets. As we all know the reset vector is at the very end and
> > linking process start from the top. This gives us no good choice but to
> > use fixed image size. While we have more and more features, the size
> > increases inevitably. It's time to adjust the arbitrary size. We are now
> > using 512KB. Shall we go with 768KB, or even 1MB?
> 
>  768K would affect fewer existing partition maps (many of which leave 1M
>  for U-Boot and environment combined), but 1M might be better for new
>  boards.  And of course it would be nice if someone could spare some time
>  to try to slim things down (finer-grained compile-time config,
>  speed/size tradeoffs, etc).
> 
> > For the first step, I think we don't have to increase size for all
> > targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
> > are the most recent used. There are other targets which don't use NOR
> > flash boot method. They should be considered as well.
> >
> > It is per board configuration. But it may be better if we keep them
> > consistent.
> 
>  I don't think it's worth trying to keep them consistent.  Leave alone
>  old boards that are not pushing the limit, and where testing and user
>  education would be a hassle, and let newer boards where more features
>  are wanted not be constrained by the past.
> 
> >>>
> >>> I did a quick search for eff8. Only these boards have it
> >>>
> >>> include/configs/B4860QDS.h
> >>> include/configs/C29XPCIE.h
> >>> include/configs/corenet_ds.h
> >>> include/configs/HWW1U1A.h
> >>> include/configs/MPC8536DS.h
> >>> include/configs/MPC8572DS.h
> >>> include/configs/P1010RDB.h
> >>> include/configs/P1022DS.h
> >>> include/configs/P1023RDB.h
> >>> include/configs/P1023RDS.h
> >>> include/configs/P1_P2_RDB.h
> >>> include/configs/p1_p2_rdb_pc.h
> >>> include/configs/p1_twr.h
> >>> include/configs/P2020DS.h
> >>> include/configs/P2041RDB.h
> >>> include/configs/T1040QDS.h
> >>> include/configs/t4qds.h
> >>>
> >>
> >> Scott,
> >>
> >> Are SPL and TPL boot methods immune from the size issue here?
> > 
> > Sort of.  We still need to fit inside existing partition tables.
> > 
> 
> PBL boot will be broken if the image size is bigger than 512KB, right?

It has to be even smaller than that, to make room for early data.

-Scott



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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/16/2013 12:37 PM, Scott Wood wrote:
> On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
>> On 10/11/2013 11:56 AM, York Sun wrote:
>>> On 10/11/2013 11:39 AM, Scott Wood wrote:
 On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
> Scott, et al.
>
> I'd like to start the discussion to increase u-boot image size for some
> mpc85xx targets. As we all know the reset vector is at the very end and
> linking process start from the top. This gives us no good choice but to
> use fixed image size. While we have more and more features, the size
> increases inevitably. It's time to adjust the arbitrary size. We are now
> using 512KB. Shall we go with 768KB, or even 1MB?

 768K would affect fewer existing partition maps (many of which leave 1M
 for U-Boot and environment combined), but 1M might be better for new
 boards.  And of course it would be nice if someone could spare some time
 to try to slim things down (finer-grained compile-time config,
 speed/size tradeoffs, etc).

> For the first step, I think we don't have to increase size for all
> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
> are the most recent used. There are other targets which don't use NOR
> flash boot method. They should be considered as well.
>
> It is per board configuration. But it may be better if we keep them
> consistent.

 I don't think it's worth trying to keep them consistent.  Leave alone
 old boards that are not pushing the limit, and where testing and user
 education would be a hassle, and let newer boards where more features
 are wanted not be constrained by the past.

>>>
>>> I did a quick search for eff8. Only these boards have it
>>>
>>> include/configs/B4860QDS.h
>>> include/configs/C29XPCIE.h
>>> include/configs/corenet_ds.h
>>> include/configs/HWW1U1A.h
>>> include/configs/MPC8536DS.h
>>> include/configs/MPC8572DS.h
>>> include/configs/P1010RDB.h
>>> include/configs/P1022DS.h
>>> include/configs/P1023RDB.h
>>> include/configs/P1023RDS.h
>>> include/configs/P1_P2_RDB.h
>>> include/configs/p1_p2_rdb_pc.h
>>> include/configs/p1_twr.h
>>> include/configs/P2020DS.h
>>> include/configs/P2041RDB.h
>>> include/configs/T1040QDS.h
>>> include/configs/t4qds.h
>>>
>>
>> Scott,
>>
>> Are SPL and TPL boot methods immune from the size issue here?
> 
> Sort of.  We still need to fit inside existing partition tables.
> 

PBL boot will be broken if the image size is bigger than 512KB, right?

York



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

[U-Boot] [ANN] U-Boot v2013.10 released

[Tom Rini]

Hey all,

I've pushed v2013.10 out to the repository and tarballs should exist
soon. 

Once again, lots of nice little things around the tree have been done,
your favorite platform is probably gotten a nice tweak or two and we've
now got things like QSPI support in for a few platforms and controllers.

The big, diffstat wise at least, change is that now instead of large
boilerplate messages in every file about the license we use SPDX tags in
all files to identify what license(s) apply here.  And the source code
itself got trimmed down a good bit.  Thanks Wolfgang!

I'm pushing the merge window for 2014.01 out a week to Nov 07 to make up
for getting this out a little late.  We'll still aim to release
v2014.01 on Jan 13.

Thanks all!

-- 
Tom


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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[Scott Wood]

On Wed, 2013-10-16 at 10:41 -0700, York Sun wrote:
> On 10/11/2013 11:56 AM, York Sun wrote:
> > On 10/11/2013 11:39 AM, Scott Wood wrote:
> >> On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
> >>> Scott, et al.
> >>>
> >>> I'd like to start the discussion to increase u-boot image size for some
> >>> mpc85xx targets. As we all know the reset vector is at the very end and
> >>> linking process start from the top. This gives us no good choice but to
> >>> use fixed image size. While we have more and more features, the size
> >>> increases inevitably. It's time to adjust the arbitrary size. We are now
> >>> using 512KB. Shall we go with 768KB, or even 1MB?
> >>
> >> 768K would affect fewer existing partition maps (many of which leave 1M
> >> for U-Boot and environment combined), but 1M might be better for new
> >> boards.  And of course it would be nice if someone could spare some time
> >> to try to slim things down (finer-grained compile-time config,
> >> speed/size tradeoffs, etc).
> >>
> >>> For the first step, I think we don't have to increase size for all
> >>> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
> >>> are the most recent used. There are other targets which don't use NOR
> >>> flash boot method. They should be considered as well.
> >>>
> >>> It is per board configuration. But it may be better if we keep them
> >>> consistent.
> >>
> >> I don't think it's worth trying to keep them consistent.  Leave alone
> >> old boards that are not pushing the limit, and where testing and user
> >> education would be a hassle, and let newer boards where more features
> >> are wanted not be constrained by the past.
> >>
> > 
> > I did a quick search for eff8. Only these boards have it
> > 
> > include/configs/B4860QDS.h
> > include/configs/C29XPCIE.h
> > include/configs/corenet_ds.h
> > include/configs/HWW1U1A.h
> > include/configs/MPC8536DS.h
> > include/configs/MPC8572DS.h
> > include/configs/P1010RDB.h
> > include/configs/P1022DS.h
> > include/configs/P1023RDB.h
> > include/configs/P1023RDS.h
> > include/configs/P1_P2_RDB.h
> > include/configs/p1_p2_rdb_pc.h
> > include/configs/p1_twr.h
> > include/configs/P2020DS.h
> > include/configs/P2041RDB.h
> > include/configs/T1040QDS.h
> > include/configs/t4qds.h
> > 
> 
> Scott,
> 
> Are SPL and TPL boot methods immune from the size issue here?

Sort of.  We still need to fit inside existing partition tables.

-Scott



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

Re: [U-Boot] [PATCH v8 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

[Scott Wood]

On Wed, 2013-10-16 at 18:44 +, Gupta, Pekon wrote:
> Hi,
> 
> > From: Scott Wood [scottw...@freescale.com]
> > > > From: Scott Wood [mailto:scottw...@freescale.com]
> > > On Thu, 2013-10-10 at 16:30 +0530, Pekon Gupta wrote:
> > [snip]
> > > > -#else
> > > > + } else {
> > > >   /*
> > > >* This ecc_size_config setting is for BCH sw library.
> > > >*
> > > > @@ -333,7 +330,7 @@ static void omap_hwecc_init_bch(struct nand_chip
> > > *chip, int32_t mode)
> > > >*  size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
> > > >*/
> > > >   val = (32 << 22) | (0 << 12);
> > > > -#endif
> > > > + }
> > >
> > > Either indentation or braces are wrong above.  If it's just the
> > > indentation that's wrong, let me know and I can fix up when applying.
> > >
> Please let me know if you can pick this series, Or if you want me to fix 
> indentation.
> I would be sending another series which also has some of your feedbacks.

I'll take it, but I probably won't have a chance to apply U-Boot patches
until at least the week after next (I'm attending conferences next week,
and this week I need to process Linux patches since those have an
earlier deadline for making the next release).

-Scott



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

Re: [U-Boot] [PATCH v8 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

[Gupta, Pekon]

Hi,

> From: Scott Wood [scottw...@freescale.com]
> > > From: Scott Wood [mailto:scottw...@freescale.com]
> > On Thu, 2013-10-10 at 16:30 +0530, Pekon Gupta wrote:
> [snip]
> > > -#else
> > > + } else {
> > >   /*
> > >* This ecc_size_config setting is for BCH sw library.
> > >*
> > > @@ -333,7 +330,7 @@ static void omap_hwecc_init_bch(struct nand_chip
> > *chip, int32_t mode)
> > >*  size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
> > >*/
> > >   val = (32 << 22) | (0 << 12);
> > > -#endif
> > > + }
> >
> > Either indentation or braces are wrong above.  If it's just the
> > indentation that's wrong, let me know and I can fix up when applying.
> >
Please let me know if you can pick this series, Or if you want me to fix 
indentation.
I would be sending another series which also has some of your feedbacks.

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

Re: [U-Boot] [PATCH 0/2] Microblaze bug-fixes

[Michal Simek]

On 10/16/2013 03:42 PM, Tom Rini wrote:
> On Wed, Oct 16, 2013 at 09:06:30AM +0200, Michal Simek wrote:
> 
>> Hi Tom,
>>
>> I have just found that there are two problems in microblaze compilation.
>> Also I have found that my regular testing is broken that's why I haven't
>> found these problems earlier.
>> Would it be possible to add these two patches to your tree.
>> I know it is late but still v2013.10 hasn't been tagged.
> 
> Applied to u-boot/master, thanks!

Thanks a lot,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] powerpc/mpc85xx: Increase image size

[York Sun]

On 10/11/2013 11:56 AM, York Sun wrote:
> On 10/11/2013 11:39 AM, Scott Wood wrote:
>> On Fri, 2013-10-11 at 11:29 -0700, York Sun wrote:
>>> Scott, et al.
>>>
>>> I'd like to start the discussion to increase u-boot image size for some
>>> mpc85xx targets. As we all know the reset vector is at the very end and
>>> linking process start from the top. This gives us no good choice but to
>>> use fixed image size. While we have more and more features, the size
>>> increases inevitably. It's time to adjust the arbitrary size. We are now
>>> using 512KB. Shall we go with 768KB, or even 1MB?
>>
>> 768K would affect fewer existing partition maps (many of which leave 1M
>> for U-Boot and environment combined), but 1M might be better for new
>> boards.  And of course it would be nice if someone could spare some time
>> to try to slim things down (finer-grained compile-time config,
>> speed/size tradeoffs, etc).
>>
>>> For the first step, I think we don't have to increase size for all
>>> targets. We can adjust those with CONFIG_SYS_TEXT_BASE=0xeff8. Those
>>> are the most recent used. There are other targets which don't use NOR
>>> flash boot method. They should be considered as well.
>>>
>>> It is per board configuration. But it may be better if we keep them
>>> consistent.
>>
>> I don't think it's worth trying to keep them consistent.  Leave alone
>> old boards that are not pushing the limit, and where testing and user
>> education would be a hassle, and let newer boards where more features
>> are wanted not be constrained by the past.
>>
> 
> I did a quick search for eff8. Only these boards have it
> 
> include/configs/B4860QDS.h
> include/configs/C29XPCIE.h
> include/configs/corenet_ds.h
> include/configs/HWW1U1A.h
> include/configs/MPC8536DS.h
> include/configs/MPC8572DS.h
> include/configs/P1010RDB.h
> include/configs/P1022DS.h
> include/configs/P1023RDB.h
> include/configs/P1023RDS.h
> include/configs/P1_P2_RDB.h
> include/configs/p1_p2_rdb_pc.h
> include/configs/p1_twr.h
> include/configs/P2020DS.h
> include/configs/P2041RDB.h
> include/configs/T1040QDS.h
> include/configs/t4qds.h
> 

Scott,

Are SPL and TPL boot methods immune from the size issue here?

York


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

[U-Boot] [PATCH v1 1/1] netconsole loses 2nd character of input

[Suriyan Ramasami]

Netconsole loses the second character when used as input by
either setenv stdin nc or setenv stdin serial,nc if using CONSOLE_CONSOLE_MUX

Before a nc_send_packet() to echo the input, a check is done to see if
nc_ether is valid. If its not, it waits for an arp request and then sends
the packet (which contains the first character of line to be displayed as
output). As part of reaping the arp request, the second character is consumed.
We protect this by making the call to NetLoop(NETCONS) between 
input_recursion.

Signed-off-by: Suriyan Ramasami 
---
 drivers/net/netconsole.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index df8ab07..65c747e 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -184,7 +184,9 @@ static void nc_send_packet(const char *buf, int len)
return; /* inside net loop */
output_packet = buf;
output_packet_len = len;
+   input_recursion = 1;
NetLoop(NETCONS); /* wait for arp reply and send packet */
+   input_recursion = 0;
output_packet_len = 0;
return;
}
-- 
1.7.1

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

Re: [U-Boot] [PATCH 1/6] exynos_fb: Remove usage of static defines

[Simon Glass]

Hi Ajay,

[once more from the right address]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> Previously, we used to statically assign values for vl_col, vl_row and
> vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.
>
> Introducing the function exynos_lcd_early_init() would take care of this
> assignment on the fly by parsing FIMD DT properties, thereby allowing us
> to remove LCD_XRES and LCD_YRES from the main config file.
>
> Signed-off-by: Ajay Kumar 
>

Acked-by: Simon Glass 

I can't test this on Pit at present - any chance of a series at some point
to enable that?

I pushed my branch to u-boot-x86.git branch try-5420b.

As a general comment, it would be nice to follow up with a series to fully
enable device tree for the GPIOs also. At the moment these are hard-coded.

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

Re: [U-Boot] [PATCH 6/6] CONFIG: SMDK5420: Enable FIMD and DP

[Simon Glass]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> Enable FIMD and DP drivers on SMDK5420 so that we get to
> see the LCD console on eDP panel.
>
> Signed-off-by: Ajay Kumar 
>

This all seems good to me, builds without errors.

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

Re: [U-Boot] [PATCH 4/6] video: exynos_fimd: Add framework to disable FIMD sysmmu

[Simon Glass]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> On Exynos5420, the FIMD sysmmus are in "on state" by default.
> We have to disable them in order to make FIMD DMA work.
> This patch adds the required framework to exynos_fimd driver
> to disable FIMD sysmmu on Exynos5420.
>
> Signed-off-by: Ajay Kumar 
>

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

Re: [U-Boot] [PATCH 5/6] smdk5420: Implement callbacks needed by exynos_fb driver

[Simon Glass]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> Add callbacks to set up DP-HPD, backlight and LCD power
> on SMDK5420.
>
> Signed-off-by: Ajay Kumar 
>

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

Re: [U-Boot] [PATCH 3/6] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420

[Simon Glass]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
> exynos video driver.
> Also, configure ACLK_400_DISP1 as the parent for
> MUX_ACLK_400_DISP1_SUB_SEL.
>
> Signed-off-by: Ajay Kumar 
>

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

Re: [U-Boot] [PATCH 2/6] arm: exynos: Add RPLL for Exynos5420

[Simon Glass]

On Mon, Sep 30, 2013 at 5:20 AM, Ajay Kumar wrote:

> RPLL is needed to drive the LCD panel on Exynos5420 based boards.
>
> Signed-off-by: Ajay Kumar 
>

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

Re: [U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver

[Chin Liang See]

Hi Albert,

On Wed, 2013-10-16 at 18:01 +0200, ZY - albert.u.boot wrote:
> Hi Chin,
> 
> On Wed, 16 Oct 2013 10:20:14 -0500, Chin Liang See 
> wrote:
> 
> > Hi Albert,
> > 
> > On Wed, 2013-10-16 at 17:10 +0200, ZY - albert.u.boot wrote:
> > > Hi Chin,
> > > 
> > > On Mon, 14 Oct 2013 08:40:20 -0500, Chin Liang See 
> > > wrote:
> > > 
> > > > Adding Freeze Controller driver. All HPS IOs need to be
> > > > in freeze state during pin mux or IO buffer configuration.
> > > > It is to avoid any glitch which might happen
> > > > during the configuration from propagating to external devices.
> > > > 
> > > > Signed-off-by: Chin Liang See 
> > > > Cc: Wolfgang Denk 
> > > > CC: Pavel Machek 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Tom Rini 
> > > > Cc: Albert Aribaud 
> > > > ---
> > > 
> > > V4 was already posted under patchwork number 277520, and is reposted
> > > here under 283228. What is the difference?
> > 
> > 
> > They are the same except have your email part of CC list. This is
> > revision 4 patch and went through few rounds of review by Pavel and Dinh
> > previously. As I believe it is in good state now, I am cc to you for
> > your attention :)
> 
> Understood -- next time you want to ping someone on an already posted
> patch, do not repost it to the list, as this creates duplicate entries
> in patchwork. Rather, send a reply to the initial patch post, adding
> whoever you nee to as Cc: or To:.

Noted. Thanks again for your helps.

Chin Liang

> 
> > Thanks and have a nice day!
> > 
> > Chin Liang
> 
> Amicalement,



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

Re: [U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver

[Albert ARIBAUD]

Hi Chin,

On Wed, 16 Oct 2013 10:20:14 -0500, Chin Liang See 
wrote:

> Hi Albert,
> 
> On Wed, 2013-10-16 at 17:10 +0200, ZY - albert.u.boot wrote:
> > Hi Chin,
> > 
> > On Mon, 14 Oct 2013 08:40:20 -0500, Chin Liang See 
> > wrote:
> > 
> > > Adding Freeze Controller driver. All HPS IOs need to be
> > > in freeze state during pin mux or IO buffer configuration.
> > > It is to avoid any glitch which might happen
> > > during the configuration from propagating to external devices.
> > > 
> > > Signed-off-by: Chin Liang See 
> > > Cc: Wolfgang Denk 
> > > CC: Pavel Machek 
> > > Cc: Dinh Nguyen 
> > > Cc: Tom Rini 
> > > Cc: Albert Aribaud 
> > > ---
> > 
> > V4 was already posted under patchwork number 277520, and is reposted
> > here under 283228. What is the difference?
> 
> 
> They are the same except have your email part of CC list. This is
> revision 4 patch and went through few rounds of review by Pavel and Dinh
> previously. As I believe it is in good state now, I am cc to you for
> your attention :)

Understood -- next time you want to ping someone on an already posted
patch, do not repost it to the list, as this creates duplicate entries
in patchwork. Rather, send a reply to the initial patch post, adding
whoever you nee to as Cc: or To:.

> Thanks and have a nice day!
> 
> Chin Liang

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

[U-Boot] Freescale P4080 DDR problems

[Виталий Андрющенко]

Hi, i have a problem while porting u-boot to my own-developed hardware 
with P4080 and fixed DDR3 memory (not DIMM's).


Does anybody tested code for Freescale with fixed memory on real hardware?

It seems that the code does not initialize a lot of registers (for 
example DDR_WRLVL_CNTL_2 and others) in function fixed_sdram(). But it 
does this in function fsl_ddr_sdram() which i scalled if we have DIMMs.

Currently my u-boot hangs while testing upper regions of memory.

PS. I have tested the memory with Freescale's proprietary tests (called 
DDR Validation) that use USBTAP and the test shows OK.


Can anybody give me a suggestion?
Thank you.
---
Vitaly
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver

[Chin Liang See]

Hi Albert,

On Wed, 2013-10-16 at 17:10 +0200, ZY - albert.u.boot wrote:
> Hi Chin,
> 
> On Mon, 14 Oct 2013 08:40:20 -0500, Chin Liang See 
> wrote:
> 
> > Adding Freeze Controller driver. All HPS IOs need to be
> > in freeze state during pin mux or IO buffer configuration.
> > It is to avoid any glitch which might happen
> > during the configuration from propagating to external devices.
> > 
> > Signed-off-by: Chin Liang See 
> > Cc: Wolfgang Denk 
> > CC: Pavel Machek 
> > Cc: Dinh Nguyen 
> > Cc: Tom Rini 
> > Cc: Albert Aribaud 
> > ---
> 
> V4 was already posted under patchwork number 277520, and is reposted
> here under 283228. What is the difference?


They are the same except have your email part of CC list. This is
revision 4 patch and went through few rounds of review by Pavel and Dinh
previously. As I believe it is in good state now, I am cc to you for
your attention :)

Thanks and have a nice day!

Chin Liang

> 
> Amicalement,



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

Re: [U-Boot] [PATCH v3 11/11] mpc85xx: introduce the kmp204x reference design support

[York Sun]

On 10/15/2013 11:55 PM, Valentin Longchamp wrote:
> 
> Here is how we can go: I have minor adjustments to the series. I can rebase it
> on top of 2013.10 as soon as it is released (I have already rebased on top of
> 2013.10-rc4) so that this gets tested on the hardware and send you a V4. I'd 
> be
> glad to help. Just tell me what you prefer.
> 

If it is a minor change, you can submit a new patch. I will apply then
in order. If the change is relatively big, please send v4.

York



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

Re: [U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver

[Albert ARIBAUD]

Hi Chin,

On Mon, 14 Oct 2013 08:40:20 -0500, Chin Liang See 
wrote:

> Adding Freeze Controller driver. All HPS IOs need to be
> in freeze state during pin mux or IO buffer configuration.
> It is to avoid any glitch which might happen
> during the configuration from propagating to external devices.
> 
> Signed-off-by: Chin Liang See 
> Cc: Wolfgang Denk 
> CC: Pavel Machek 
> Cc: Dinh Nguyen 
> Cc: Tom Rini 
> Cc: Albert Aribaud 
> ---

V4 was already posted under patchwork number 277520, and is reposted
here under 283228. What is the difference?

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

Re: [U-Boot] [PATCH] spi: mxc: Fix data loss for non aligned write buffers.

[Martin Fuzzey]

On 16/10/13 15:22, Jagan Teki wrote:

Hi Albert,

On Wed, Oct 16, 2013 at 5:35 PM, Albert ARIBAUD
 wrote:

Hi Jagan,

On Wed, 16 Oct 2013 16:20:17 +0530, Jagan Teki
 wrote:


Hi Amicalement,

On Wed, Oct 16, 2013 at 1:05 PM, Albert ARIBAUD
 wrote:

Hi Jagan,

On Wed, 16 Oct 2013 11:16:49 +0530, Jagan Teki
 wrote:


Hi,

On Tue, Oct 15, 2013 at 11:27 PM, Martin Fuzzey  wrote:

When writing buffers that are not 32 bit aligned data loss occurs.

This can also occur when the total transfer size is not a multiple of 4 bytes
since the extra bytes are written first causing the rest to be unaligned.

This can be seen by writing to SPI flash a 57 byte file containing 00 01 .. 38:

U-Boot > dhcp data.bin
...
Bytes transferred = 57 (39 hex)
U-Boot > md.b $loadaddr
7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
7220: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
7230: 30 31 32 33 34 35 36 37 38 ff ff ff ff ff ff ff012345678...
U-Boot > sf write $loadaddr 0 $filesize

U-Boot > mw.b $loadaddr ff 100
U-Boot > sf read $loadaddr 0 100
U-Boot > md.b $loadaddr
7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
7220: 20 21 22 23 24 29 2a 2b 2c 31 32 33 34 ff ff ff !"#$)*+,1234...
7230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[bytes 25-28, 2d-30, 35-38 are missing]

Activating debug in the write command gave:
spi_xchg_single: bitlen 256 dout 0x7200 din 0x0
Sending SPI 0x10203
Sending SPI 0x4050607
Sending SPI 0x8090a0b
Sending SPI 0xc0d0e0f
Sending SPI 0x10111213
Sending SPI 0x14151617
Sending SPI 0x18191a1b
Sending SPI 0x1c1d1e1f
SPI Rx: 0x 0x
...
SPI Rx: 0x 0x
spi_xchg_single: bitlen 200 dout 0x7220 din 0x0
Sending SPI 0x20
Sending SPI 0x21222324
Sending SPI 0x292a2b2c  <===  What happened to 25262728?
Sending SPI 0x31323334
Sending SPI 0x
...
SF: program success 57 bytes @ 0x0

Thanks for your log, for showing the exact issues.

Agreed, but I think this log could go in a comment below the '---'
line, so that the commit message focuses on describing what the patch
does, rather than how it was found out necessary.

I too thought the same, but the commit is already in master, any
possibility to alter?

Er... Martin's patch is already in patchwork as 283794, but its state
is still "New" with no delegate, and I don't see it in any of the
repos I usually read, nor does it appear on u-boot-spi. Where do you
see it "in master" exactly?

Besides, it is less than 24 hours old; this is not enough time for
review, and therefore, it should not be accepted yet.

I got the similar patch from Timo Herbrecher  couple of weeks back,
I just reviewed and sent back to v3 before apllied on u-boot-spi.

Yesterday I sent this patch as part of spi PR.

You can find the patch in master:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=6d5ce1bd0048617d48c05de1a84fae8696081127

Please let me know you still have any concerns, I agreed your concern
that the commit message
have enough info for this fix. But right know i think we can't do as
it's part of master.

If any possibility to alter the commit msg, please let me know.


Yes looks like two patches doing the same thing.
The one in master is from Timo Herbrecher not me.

I checked git master before sending my patch and it wasn't there yet but
didin't check the mailing list archives.

Anyway the code is identical just the commit message changes.

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

Re: [U-Boot] [PATCH] spi: mxc: Fix data loss for non aligned write buffers.

[Albert ARIBAUD]

Hi Jagan,

On Wed, 16 Oct 2013 18:52:34 +0530, Jagan Teki
 wrote:

> Hi Albert,
> 
> On Wed, Oct 16, 2013 at 5:35 PM, Albert ARIBAUD
>  wrote:
> > Hi Jagan,
> >
> > On Wed, 16 Oct 2013 16:20:17 +0530, Jagan Teki
> >  wrote:
> >
> >> Hi Amicalement,
> >>
> >> On Wed, Oct 16, 2013 at 1:05 PM, Albert ARIBAUD
> >>  wrote:
> >> > Hi Jagan,
> >> >
> >> > On Wed, 16 Oct 2013 11:16:49 +0530, Jagan Teki
> >> >  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> On Tue, Oct 15, 2013 at 11:27 PM, Martin Fuzzey  
> >> >> wrote:
> >> >> > When writing buffers that are not 32 bit aligned data loss occurs.
> >> >> >
> >> >> > This can also occur when the total transfer size is not a multiple of 
> >> >> > 4 bytes
> >> >> > since the extra bytes are written first causing the rest to be 
> >> >> > unaligned.
> >> >> >
> >> >> > This can be seen by writing to SPI flash a 57 byte file containing 00 
> >> >> > 01 .. 38:
> >> >> >
> >> >> > U-Boot > dhcp data.bin
> >> >> > ...
> >> >> > Bytes transferred = 57 (39 hex)
> >> >> > U-Boot > md.b $loadaddr
> >> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> >> >> > 
> >> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> >> >> > 
> >> >> > 7220: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
> >> >> > !"#$%&'()*+,-./
> >> >> > 7230: 30 31 32 33 34 35 36 37 38 ff ff ff ff ff ff ff
> >> >> > 012345678...
> >> >> > U-Boot > sf write $loadaddr 0 $filesize
> >> >> >
> >> >> > U-Boot > mw.b $loadaddr ff 100
> >> >> > U-Boot > sf read $loadaddr 0 100
> >> >> > U-Boot > md.b $loadaddr
> >> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> >> >> > 
> >> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> >> >> > 
> >> >> > 7220: 20 21 22 23 24 29 2a 2b 2c 31 32 33 34 ff ff ff 
> >> >> > !"#$)*+,1234...
> >> >> > 7230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> >> > 
> >> >> >
> >> >> > [bytes 25-28, 2d-30, 35-38 are missing]
> >> >> >
> >> >> > Activating debug in the write command gave:
> >> >> > spi_xchg_single: bitlen 256 dout 0x7200 din 0x0
> >> >> > Sending SPI 0x10203
> >> >> > Sending SPI 0x4050607
> >> >> > Sending SPI 0x8090a0b
> >> >> > Sending SPI 0xc0d0e0f
> >> >> > Sending SPI 0x10111213
> >> >> > Sending SPI 0x14151617
> >> >> > Sending SPI 0x18191a1b
> >> >> > Sending SPI 0x1c1d1e1f
> >> >> > SPI Rx: 0x 0x
> >> >> > ...
> >> >> > SPI Rx: 0x 0x
> >> >> > spi_xchg_single: bitlen 200 dout 0x7220 din 0x0
> >> >> > Sending SPI 0x20
> >> >> > Sending SPI 0x21222324
> >> >> > Sending SPI 0x292a2b2c  <===  What happened to 25262728?
> >> >> > Sending SPI 0x31323334
> >> >> > Sending SPI 0x
> >> >> > ...
> >> >> > SF: program success 57 bytes @ 0x0
> >> >> Thanks for your log, for showing the exact issues.
> >> >
> >> > Agreed, but I think this log could go in a comment below the '---'
> >> > line, so that the commit message focuses on describing what the patch
> >> > does, rather than how it was found out necessary.
> >>
> >> I too thought the same, but the commit is already in master, any
> >> possibility to alter?
> >
> > Er... Martin's patch is already in patchwork as 283794, but its state
> > is still "New" with no delegate, and I don't see it in any of the
> > repos I usually read, nor does it appear on u-boot-spi. Where do you
> > see it "in master" exactly?
> >
> > Besides, it is less than 24 hours old; this is not enough time for
> > review, and therefore, it should not be accepted yet.
> 
> I got the similar patch from Timo Herbrecher  couple of weeks back,
> I just reviewed and sent back to v3 before apllied on u-boot-spi.
> 
> Yesterday I sent this patch as part of spi PR.
> 
> You can find the patch in master:
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=6d5ce1bd0048617d48c05de1a84fae8696081127
> 
> Please let me know you still have any concerns, I agreed your concern
> that the commit message
> have enough info for this fix. But right know i think we can't do as
> it's part of master.
> 
> If any possibility to alter the commit msg, please let me know.

If it's gone in a repo, especially the main one, then you can't roll
it back -- BTW Timo's commit message is ok for me.

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

[U-Boot] [PATCH V2 0/6] Add support for SPI based DataImage LCD panel

[Nikita Kiryanov]

This patch ports the Linux driver for DataImage SCF0403852GGU04 and
SCF0403526GGU20 LCD panels into U-Boot. As a preparation step, variable SPI word
length support is added to omap3_spi and the generic SPI interface.
Finally, the driver is used in cm_t35 board.

The SPI changes were tested with a Beagle I2C/SPI/MDIO Protocol Analyzer, and
also with a DataImage SCF0403 lcd as part of the DataImage driver test.

Patch number 6 depends on http://patchwork.ozlabs.org/patch/275283/

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Cc: Jagannadha Sutradharudu Teki 

Changes in V2:
- Rebased on top of latest U-Boot
- New patches:
 1) spi: omap3: remove semicolon from #define
 2) spi: define SPI_XFER_ONCE
 3) omap3_dss: define DSS_ONOFF
1 is a preliminary cleanup suggested by Gerhard Sittig and Igor Grinberg
2 and 3 are splitting off some new #defines to separate patches
- Moved wordlen to generic spi_slave struct, and added generic
implementation for spi_set_wordlen which only updates the struct without
touching the hardware (Igor Grinberg)
- Updated wordlen in hardware just before doing SPI transactions, not
when changing wordlen (Igor Grinberg)
- OMAP3 specific check of wordlen value from old implementation of
spi_set_wordlen moved to xfer. It refines the more general check done
in the new spi_set_wordlen.
- Fixed comment style in spi.h following a rebase on top of latest
U-Boot
- Added SPDX-License-Identifier to all new files (Anatolij Gustschin)
- s/printf/puts for not formatted strings in scf0403 driver (Anatolij
Gustschin)
- Do not fail scf0403 driver init if an invalid reset_gpio is given
(Igor Grinberg)

Nikita Kiryanov (6):
  spi: omap3: remove semicolon from #define
  spi: omap3: add support for more word lengths
  spi: define SPI_XFER_ONCE
  lcd: add DataImage SCF0403x LCD panel support
  omap3_dss: define DSS_ONOFF
  cm_t35: use scf0403 driver

 arch/arm/include/asm/arch-omap3/dss.h |   9 +-
 board/compulab/cm_t35/cm_t35.c|  12 ++
 board/compulab/common/omap3_display.c |  46 +-
 drivers/spi/omap3_spi.c   |  71 +---
 drivers/spi/omap3_spi.h   |   8 +-
 drivers/spi/spi.c |  13 ++
 drivers/video/Makefile|   1 +
 drivers/video/scf0403_lcd.c   | 296 ++
 include/configs/cm_t35.h  |   3 +
 include/scf0403_lcd.h |  11 ++
 include/spi.h |  17 ++
 11 files changed, 456 insertions(+), 31 deletions(-)
 create mode 100644 drivers/video/scf0403_lcd.c
 create mode 100644 include/scf0403_lcd.h

-- 
1.8.1.2

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

[U-Boot] [PATCH V2 6/6] cm_t35: use scf0403 driver

[Nikita Kiryanov]

Use scf0403 driver to add scf0403x LCD support for cm-t35 and cm-t3730
boards.

Signed-off-by: Nikita Kiryanov 
Acked-by: Igor Grinberg 
---
NOTE:   This patch depends on http://patchwork.ozlabs.org/patch/275283/

Changes in V2:
- Changes to arch/arm/include/asm/arch-omap3/dss.h were split off to
another patch.

 board/compulab/cm_t35/cm_t35.c| 12 +
 board/compulab/common/omap3_display.c | 46 +--
 include/configs/cm_t35.h  |  3 +++
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index a6d4aba..51dd4a4 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -268,6 +268,9 @@ static void cm_t3x_set_common_muxconf(void)
/* DVI enable */
MUX_VAL(CP(GPMC_NCS3),  (IDIS  | PTU | DIS  | M4));/*GPMC_nCS3*/
 
+   /* DataImage backlight */
+   MUX_VAL(CP(GPMC_NCS7),  (IDIS  | PTU | DIS  | M4));/*GPIO_58*/
+
/* CM-T3x Ethernet */
MUX_VAL(CP(GPMC_NCS5),  (IDIS | PTU | DIS | M0)); /*GPMC_nCS5*/
MUX_VAL(CP(GPMC_CLK),   (IEN  | PTD | DIS | M4)); /*GPIO_59*/
@@ -374,6 +377,15 @@ static void cm_t3x_set_common_muxconf(void)
MUX_VAL(CP(MMC1_DAT1),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT1*/
MUX_VAL(CP(MMC1_DAT2),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT2*/
MUX_VAL(CP(MMC1_DAT3),  (IEN  | PTU | EN  | M0)); /*MMC1_DAT3*/
+
+   /* SPI */
+   MUX_VAL(CP(MCBSP1_CLKR),(IEN | PTD | DIS | M1)); /*MCSPI4_CLK*/
+   MUX_VAL(CP(MCBSP1_DX),  (IEN | PTD | DIS | M1)); /*MCSPI4_SIMO*/
+   MUX_VAL(CP(MCBSP1_DR),  (IEN | PTD | DIS | M1)); /*MCSPI4_SOMI*/
+   MUX_VAL(CP(MCBSP1_FSX), (IEN | PTU | EN  | M1)); /*MCSPI4_CS0*/
+
+   /* display controls */
+   MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | DIS | M4)); /*GPIO_157*/
 }
 
 static void cm_t35_set_muxconf(void)
diff --git a/board/compulab/common/omap3_display.c 
b/board/compulab/common/omap3_display.c
index ead821e..61707f5 100644
--- a/board/compulab/common/omap3_display.c
+++ b/board/compulab/common/omap3_display.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -22,6 +23,7 @@ enum display_type {
NONE,
DVI,
DVI_CUSTOM,
+   DATA_IMAGE, /* #define CONFIG_SCF0403_LCD to use */
 };
 
 #define CMAP_ADDR  0x8010
@@ -119,6 +121,18 @@ static const struct panel_config preset_dvi_1280X1024 = {
.gfx_format = GFXFORMAT_RGB16,
 };
 
+static const struct panel_config preset_dataimage_480X800 = {
+   .lcd_size   = PANEL_LCD_SIZE(480, 800),
+   .timing_h   = DSS_HBP(2) | DSS_HFP(2) | DSS_HSW(2),
+   .timing_v   = DSS_VBP(17) | DSS_VFP(20) | DSS_VSW(3),
+   .pol_freq   = DSS_IVS | DSS_IHS | DSS_IPC | DSS_ONOFF,
+   .divisor= 10 | (1 << 10),
+   .data_lines = LCD_INTERFACE_18_BIT,
+   .panel_type = ACTIVE_DISPLAY,
+   .load_mode  = 2,
+   .gfx_format = GFXFORMAT_RGB16,
+};
+
 /*
  * set_resolution_params()
  *
@@ -146,6 +160,13 @@ static enum display_type set_dvi_preset(const struct 
panel_config preset,
return DVI;
 }
 
+static enum display_type set_dataimage_preset(const struct panel_config preset,
+   int x_res, int y_res)
+{
+   set_preset(preset, x_res, y_res);
+   return DATA_IMAGE;
+}
+
 /*
  * parse_mode() - parse the mode parameter of custom lcd settings
  *
@@ -369,6 +390,8 @@ static enum display_type env_parse_displaytype(char 
*displaytype)
return set_dvi_preset(preset_dvi_1280X960, 1280, 960);
else if (!strncmp(displaytype, "dvi1280x1024", 12))
return set_dvi_preset(preset_dvi_1280X1024, 1280, 1024);
+   else if (!strncmp(displaytype, "dataimage480x800", 16))
+   return set_dataimage_preset(preset_dataimage_480X800, 480, 800);
 
return NONE;
 }
@@ -401,12 +424,31 @@ void lcd_ctrl_init(void *lcdbase)
clrsetbits_le32(&prcm->clksel_dss, 0xF, 3);
 }
 
+#ifdef CONFIG_SCF0403_LCD
+static void scf0403_enable(void)
+{
+   gpio_direction_output(58, 1);
+   scf0403_init(157);
+}
+#else
+static inline void scf0403_enable(void) {}
+#endif
+
 void lcd_enable(void)
 {
-   if (lcd_def == DVI || lcd_def == DVI_CUSTOM) {
+   switch (lcd_def) {
+   case NONE:
+   return;
+   case DVI:
+   case DVI_CUSTOM:
gpio_direction_output(54, 0); /* Turn on DVI */
-   omap3_dss_enable();
+   break;
+   case DATA_IMAGE:
+   scf0403_enable();
+   break;
}
+
+   omap3_dss_enable();
 }
 
 void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue) {}
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index eff35b9..f01958d 100644
--- a/include/confi

[U-Boot] [PATCH V2 2/6] spi: omap3: add support for more word lengths

[Nikita Kiryanov]

Current implementation only supports 8 bit word lengths, even though
omap3 can handle anything between 4 and 32.

Update the spi interface to support changing the SPI word length,
and implement it in omap3_spi driver to support the full range of
possible word lengths.
This implementation is backwards compatible by defaulting to the old
behavior of 8 bit word lengths.
Also, it required a change to the omap3_spi non static I/O functions,
but since they are not used anywhere else, no collateral changes are required.

Cc: Tom Rini 
Cc: Jagannadha Sutradharudu Teki 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
---
Changes in V2:
- Removed semicolon from #define SPI_DEFAULT_WORDLEN (Gerhard Sittig,
Igor Grinberg)
- Moved wordlen to generic spi_slave struct, and added generic
implementation for spi_set_wordlen which only updates the struct without
touching the hardware (Igor Grinberg)
- Update wordlen in hardware just before doing SPI transactions, not
when changing wordlen (Igor Grinberg)
- OMAP3 specific check of wordlen value from old implementation of
spi_set_wordlen moved to xfer. It refines the more general check done
in the new spi_set_wordlen.
- Fixed comment style in spi.h following a rebase on top of latest
U-Boot

 drivers/spi/omap3_spi.c | 69 +++--
 drivers/spi/omap3_spi.h |  8 +++---
 drivers/spi/spi.c   | 13 ++
 include/spi.h   | 16 
 4 files changed, 82 insertions(+), 24 deletions(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 116276c..a3ad056 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -20,7 +20,6 @@
 #include 
 #include "omap3_spi.h"
 
-#define WORD_LEN   8
 #define SPI_WAIT_TIMEOUT 300
 
 static void spi_reset(struct omap3_spi_slave *ds)
@@ -185,7 +184,7 @@ int spi_claim_bus(struct spi_slave *slave)
 
/* wordlength */
conf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
-   conf |= (WORD_LEN - 1) << 7;
+   conf |= (ds->slave.wordlen - 1) << 7;
 
/* set chipselect polarity; manage with FORCE */
if (!(ds->mode & SPI_CS_HIGH))
@@ -223,7 +222,7 @@ void spi_release_bus(struct spi_slave *slave)
spi_reset(ds);
 }
 
-int omap3_spi_write(struct spi_slave *slave, unsigned int len, const u8 *txp,
+int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void *txp,
unsigned long flags)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
@@ -234,7 +233,8 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int 
len, const u8 *txp,
/* Enable the channel */
omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
 
-   chconf &= ~OMAP3_MCSPI_CHCONF_TRM_MASK;
+   chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
+   chconf |= (ds->slave.wordlen - 1) << 7;
chconf |= OMAP3_MCSPI_CHCONF_TRM_TX_ONLY;
chconf |= OMAP3_MCSPI_CHCONF_FORCE;
omap3_spi_write_chconf(ds,chconf);
@@ -250,7 +250,13 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int 
len, const u8 *txp,
}
}
/* Write the data */
-   writel(txp[i], &ds->regs->channel[ds->slave.cs].tx);
+   unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
+   if (ds->slave.wordlen > 16)
+   writel(((u32 *)txp)[i], tx);
+   else if (ds->slave.wordlen > 8)
+   writel(((u16 *)txp)[i], tx);
+   else
+   writel(((u8 *)txp)[i], tx);
}
 
/* wait to finish of transfer */
@@ -268,7 +274,7 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int 
len, const u8 *txp,
return 0;
 }
 
-int omap3_spi_read(struct spi_slave *slave, unsigned int len, u8 *rxp,
+int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
   unsigned long flags)
 {
struct omap3_spi_slave *ds = to_omap3_spi(slave);
@@ -279,7 +285,8 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int 
len, u8 *rxp,
/* Enable the channel */
omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_EN);
 
-   chconf &= ~OMAP3_MCSPI_CHCONF_TRM_MASK;
+   chconf &= ~(OMAP3_MCSPI_CHCONF_TRM_MASK | OMAP3_MCSPI_CHCONF_WL_MASK);
+   chconf |= (ds->slave.wordlen - 1) << 7;
chconf |= OMAP3_MCSPI_CHCONF_TRM_RX_ONLY;
chconf |= OMAP3_MCSPI_CHCONF_FORCE;
omap3_spi_write_chconf(ds,chconf);
@@ -302,7 +309,13 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int 
len, u8 *rxp,
omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
 
/* Read the data */
-   rxp[i] = readl(&ds->regs->channel[ds->slave.cs].rx);
+   unsigned int *rx = &ds->regs->channel[ds->slave.cs].rx;
+   if (ds->slave.wordlen > 16)
+  

[U-Boot] [PATCH V2 4/6] lcd: add DataImage SCF0403x LCD panel support

[Nikita Kiryanov]

Add SPI-based driver for DataImage SCF0403852GGU04 and SCF0403526GGU20
LCD panels.

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
---
Changes in V2:
- Added SPDX-License-Identifier to all new files (Anatolij Gustschin)
- s/printf/puts for not formatted strings (Anatolij Gustschin)
- Do not fail init if an invalid reset_gpio is given (Igor Grinberg)
- Move definition of SPI_XFER_ONCE to a separate patch (Igor Grinberg)

 drivers/video/Makefile  |   1 +
 drivers/video/scf0403_lcd.c | 296 
 include/scf0403_lcd.h   |  11 ++
 3 files changed, 308 insertions(+)
 create mode 100644 drivers/video/scf0403_lcd.c
 create mode 100644 include/scf0403_lcd.h

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 6c208c5..e7324d1 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -22,6 +22,7 @@ COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o
 COBJS-$(CONFIG_L5F31188) += l5f31188.o
 COBJS-$(CONFIG_MPC8XX_LCD) += mpc8xx_lcd.o
 COBJS-$(CONFIG_PXA_LCD) += pxa_lcd.o
+COBJS-$(CONFIG_SCF0403_LCD) += scf0403_lcd.o
 COBJS-$(CONFIG_S6E8AX0) += s6e8ax0.o
 COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
 COBJS-$(CONFIG_LD9040) += ld9040.o
diff --git a/drivers/video/scf0403_lcd.c b/drivers/video/scf0403_lcd.c
new file mode 100644
index 000..2bc8bca
--- /dev/null
+++ b/drivers/video/scf0403_lcd.c
@@ -0,0 +1,296 @@
+/*
+ * scf0403.c -- support for DataImage SCF0403 LCD
+ *
+ * Copyright (c) 2013 Adapted from Linux driver:
+ * Copyright (c) 2012 Anders Electronics plc. All Rights Reserved.
+ * Copyright (c) 2012 CompuLab, Ltd
+ *   Dmitry Lifshitz 
+ *   Ilya Ledvich 
+ * Inspired by Alberto Panizzo  &
+ * Marek Vasut work in l4f00242t03.c
+ *
+ * U-Boot port: Nikita Kiryanov 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+struct scf0403_cmd {
+   u16 cmd;
+   u16 *params;
+   int count;
+};
+
+struct scf0403_initseq_entry {
+   struct scf0403_cmd cmd;
+   int delay_ms;
+};
+
+struct scf0403_priv {
+   struct spi_slave *spi;
+   unsigned int reset_gpio;
+   u32 rddid;
+   struct scf0403_initseq_entry *init_seq;
+   int seq_size;
+};
+
+struct scf0403_priv priv;
+
+#define SCF0403852GGU04_ID 0x80
+
+/* SCF0403526GGU20 model commands parameters */
+static u16 extcmd_params_sn20[]= {0xff, 0x98, 0x06};
+static u16 spiinttype_params_sn20[]= {0x60};
+static u16 bc_params_sn20[]= {
+   0x01, 0x10, 0x61, 0x74, 0x01, 0x01, 0x1B,
+   0x12, 0x71, 0x00, 0x00, 0x00, 0x01, 0x01,
+   0x05, 0x00, 0xFF, 0xF2, 0x01, 0x00, 0x40,
+};
+static u16 bd_params_sn20[] = {0x01, 0x23, 0x45, 0x67, 0x01, 0x23, 0x45, 0x67};
+static u16 be_params_sn20[] = {
+   0x01, 0x22, 0x22, 0xBA, 0xDC, 0x26, 0x28, 0x22, 0x22,
+};
+static u16 vcom_params_sn20[]  = {0x74};
+static u16 vmesur_params_sn20[]= {0x7F, 0x0F, 0x00};
+static u16 powerctl_params_sn20[]  = {0x03, 0x0b, 0x00};
+static u16 lvglvolt_params_sn20[]  = {0x08};
+static u16 engsetting_params_sn20[]= {0x00, 0x00, 0x00, 0x00, 0x00, 0x20};
+static u16 dispfunc_params_sn20[]  = {0xa0};
+static u16 dvddvolt_params_sn20[]  = {0x74};
+static u16 dispinv_params_sn20[]   = {0x00, 0x00, 0x00};
+static u16 panelres_params_sn20[]  = {0x82};
+static u16 framerate_params_sn20[] = {0x00, 0x13, 0x13};
+static u16 timing_params_sn20[]= {0x80, 0x05, 0x40, 0x28};
+static u16 powerctl2_params_sn20[] = {0x17, 0x75, 0x79, 0x20};
+static u16 memaccess_params_sn20[] = {0x00};
+static u16 pixfmt_params_sn20[]= {0x66};
+static u16 pgamma_params_sn20[]= {
+   0x00, 0x03, 0x0b, 0x0c, 0x0e, 0x08, 0xc5, 0x04,
+   0x08, 0x0c, 0x13, 0x11, 0x11, 0x14, 0x0c, 0x10,
+};
+static u16 ngamma_params_sn20[] = {
+   0x00, 0x0d, 0x11, 0x0c, 0x0c, 0x04, 0x76, 0x03,
+   0x08, 0x0b, 0x16, 0x10, 0x0d, 0x16, 0x0a, 0x00,
+};
+static u16 tearing_params_sn20[] = {0x00};
+
+/* SCF0403852GGU04 model commands parameters */
+static u16 memaccess_params_sn04[] = {0x08};
+static u16 pixfmt_params_sn04[]= {0x66};
+static u16 modectl_params_sn04[]   = {0x01};
+static u16 dispfunc_params_sn04[]  = {0x22, 0xe2, 0xFF, 0x04};
+static u16 vcom_params_sn04[]  = {0x00, 0x6A};
+static u16 pgamma_params_sn04[]= {
+   0x00, 0x07, 0x0d, 0x10, 0x13, 0x19, 0x0f, 0x0c,
+   0x05, 0x08, 0x06, 0x13, 0x0f, 0x30, 0x20, 0x1f,
+};
+static u16 ngamma_params_sn04[]= {
+   0x1F, 0x20, 0x30, 0x0F, 0x13, 0x06, 0x08, 0x05,
+   0x0C, 0x0F, 0x19, 0x13, 0x10, 0x0D, 0x07, 0x00,
+};
+static u16 dispinv_params_sn04[]   = {0x02};
+
+/* Common commands */
+static struct scf0403_cmd scf0403_cmd_slpo

[U-Boot] [PATCH V2 1/6] spi: omap3: remove semicolon from #define

[Nikita Kiryanov]

Remove unnecessary semicolon from #define SPI_WAIT_TIMEOUT

Cc: Tom Rini 
Cc: Jagannadha Sutradharudu Teki 
Cc: Igor Grinberg 
Cc: Gerhard Sittig 
Signed-off-by: Nikita Kiryanov 
---
NOTE:   New patch in series (Gerhard Sittig, Igor Grinberg)

 drivers/spi/omap3_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index e80be8e..116276c 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -21,7 +21,7 @@
 #include "omap3_spi.h"
 
 #define WORD_LEN   8
-#define SPI_WAIT_TIMEOUT 300;
+#define SPI_WAIT_TIMEOUT 300
 
 static void spi_reset(struct omap3_spi_slave *ds)
 {
-- 
1.8.1.2

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

[U-Boot] [PATCH V2 5/6] omap3_dss: define DSS_ONOFF

[Nikita Kiryanov]

Add DSS_ONOFF to polarity defines

Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
Acked-by: Igor Grinberg 
---
NOTE:   This is a new patch. Its contents were originally part of "cm_t35: use
scf0403 driver". Split because it is unrelated to the patch it was
originally in.

 arch/arm/include/asm/arch-omap3/dss.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap3/dss.h 
b/arch/arm/include/asm/arch-omap3/dss.h
index ae0babf..8bf6b48 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -178,10 +178,11 @@ struct venc_regs {
 #define LCD_INTERFACE_24_BIT   3
 
 /* Polarity */
-#define DSS_IVS(1 << 12)
-#define DSS_IHS(1 << 13)
-#define DSS_IPC(1 << 14)
-#define DSS_IEO(1 << 15)
+#define DSS_IVS(1 << 12)
+#define DSS_IHS(1 << 13)
+#define DSS_IPC(1 << 14)
+#define DSS_IEO(1 << 15)
+#define DSS_ONOFF  (1 << 17)
 
 /* GFX format */
 #define GFXFORMAT_BITMAP1  (0x0 << 1)
-- 
1.8.1.2

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

[U-Boot] [PATCH V2 3/6] spi: define SPI_XFER_ONCE

[Nikita Kiryanov]

The flag combination "SPI_XFER_BEGIN | SPI_XFER_END" is a common use
case of spi_xfer, and it can easily cause an already long line (spi_xfer
takes 5 parameters) to go over the 80 character limit.

define SPI_XFER_ONCE to be a shorter version of the above flag combination.

Cc: Tom Rini 
Cc: Jagannadha Sutradharudu Teki 
Cc: Igor Grinberg 
Signed-off-by: Nikita Kiryanov 
---
NOTE:   This is a new patch. Its contents were originally part of "lcd: add
DataImage SCF0403x LCD panel support". Split because it is unrelated to
the patch it was originally in. (Igor Grinberg)

 include/spi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/spi.h b/include/spi.h
index 67da75c..e2563c9 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -29,6 +29,7 @@
 #define SPI_XFER_END   0x02/* Deassert CS after transfer */
 #define SPI_XFER_MMAP  0x08/* Memory Mapped start */
 #define SPI_XFER_MMAP_END  0x10/* Memory Mapped End */
+#define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
 
 /* Header byte that marks the start of the message */
 #define SPI_PREAMBLE_END_BYTE  0xec
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init

[Marek Vasut]

Dear Stefano Babic,

> Hi Marek,
> 
> On 15/10/2013 23:19, Marek Vasut wrote:
> > Forget this, the issue is still present. Damn!
> > 
> > It's at least a little clearer to me what happens now. The FEC fails to
> > transmit an TFTP block ACK packet -> the server waits 5 seconds -> sends
> > ARP packet -> FEC replies and resends the TFTP block ACK again. Why does
> > the FEC swallow a TX packet, I don't know.
> 
> Anyway, it is strange that this happens only with this board. It appears
> as the SOC sends or thinks to have sent, but the packet is corrupted or
> not sent at all on the physical layer. Maybe you can check on the other
> side of the connection on the switch and/or on the server, if some
> errors are detected.

This happens on multiple boards and we're sometimes getting reports about this 
issue. So this is not a single board issue. Maybe we should figure out what do 
these boards have in common.

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] spi: mxc: Fix data loss for non aligned write buffers.

[Jagan Teki]

Hi Albert,

On Wed, Oct 16, 2013 at 5:35 PM, Albert ARIBAUD
 wrote:
> Hi Jagan,
>
> On Wed, 16 Oct 2013 16:20:17 +0530, Jagan Teki
>  wrote:
>
>> Hi Amicalement,
>>
>> On Wed, Oct 16, 2013 at 1:05 PM, Albert ARIBAUD
>>  wrote:
>> > Hi Jagan,
>> >
>> > On Wed, 16 Oct 2013 11:16:49 +0530, Jagan Teki
>> >  wrote:
>> >
>> >> Hi,
>> >>
>> >> On Tue, Oct 15, 2013 at 11:27 PM, Martin Fuzzey  
>> >> wrote:
>> >> > When writing buffers that are not 32 bit aligned data loss occurs.
>> >> >
>> >> > This can also occur when the total transfer size is not a multiple of 4 
>> >> > bytes
>> >> > since the extra bytes are written first causing the rest to be 
>> >> > unaligned.
>> >> >
>> >> > This can be seen by writing to SPI flash a 57 byte file containing 00 
>> >> > 01 .. 38:
>> >> >
>> >> > U-Boot > dhcp data.bin
>> >> > ...
>> >> > Bytes transferred = 57 (39 hex)
>> >> > U-Boot > md.b $loadaddr
>> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>> >> > 
>> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
>> >> > 
>> >> > 7220: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
>> >> > !"#$%&'()*+,-./
>> >> > 7230: 30 31 32 33 34 35 36 37 38 ff ff ff ff ff ff ff
>> >> > 012345678...
>> >> > U-Boot > sf write $loadaddr 0 $filesize
>> >> >
>> >> > U-Boot > mw.b $loadaddr ff 100
>> >> > U-Boot > sf read $loadaddr 0 100
>> >> > U-Boot > md.b $loadaddr
>> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>> >> > 
>> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
>> >> > 
>> >> > 7220: 20 21 22 23 24 29 2a 2b 2c 31 32 33 34 ff ff ff 
>> >> > !"#$)*+,1234...
>> >> > 7230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> >> > 
>> >> >
>> >> > [bytes 25-28, 2d-30, 35-38 are missing]
>> >> >
>> >> > Activating debug in the write command gave:
>> >> > spi_xchg_single: bitlen 256 dout 0x7200 din 0x0
>> >> > Sending SPI 0x10203
>> >> > Sending SPI 0x4050607
>> >> > Sending SPI 0x8090a0b
>> >> > Sending SPI 0xc0d0e0f
>> >> > Sending SPI 0x10111213
>> >> > Sending SPI 0x14151617
>> >> > Sending SPI 0x18191a1b
>> >> > Sending SPI 0x1c1d1e1f
>> >> > SPI Rx: 0x 0x
>> >> > ...
>> >> > SPI Rx: 0x 0x
>> >> > spi_xchg_single: bitlen 200 dout 0x7220 din 0x0
>> >> > Sending SPI 0x20
>> >> > Sending SPI 0x21222324
>> >> > Sending SPI 0x292a2b2c  <===  What happened to 25262728?
>> >> > Sending SPI 0x31323334
>> >> > Sending SPI 0x
>> >> > ...
>> >> > SF: program success 57 bytes @ 0x0
>> >> Thanks for your log, for showing the exact issues.
>> >
>> > Agreed, but I think this log could go in a comment below the '---'
>> > line, so that the commit message focuses on describing what the patch
>> > does, rather than how it was found out necessary.
>>
>> I too thought the same, but the commit is already in master, any
>> possibility to alter?
>
> Er... Martin's patch is already in patchwork as 283794, but its state
> is still "New" with no delegate, and I don't see it in any of the
> repos I usually read, nor does it appear on u-boot-spi. Where do you
> see it "in master" exactly?
>
> Besides, it is less than 24 hours old; this is not enough time for
> review, and therefore, it should not be accepted yet.

I got the similar patch from Timo Herbrecher  couple of weeks back,
I just reviewed and sent back to v3 before apllied on u-boot-spi.

Yesterday I sent this patch as part of spi PR.

You can find the patch in master:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=6d5ce1bd0048617d48c05de1a84fae8696081127

Please let me know you still have any concerns, I agreed your concern
that the commit message
have enough info for this fix. But right know i think we can't do as
it's part of master.

If any possibility to alter the commit msg, please let me know.

-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] Microblaze bug-fixes

[Tom Rini]

On Wed, Oct 16, 2013 at 09:06:30AM +0200, Michal Simek wrote:

> Hi Tom,
> 
> I have just found that there are two problems in microblaze compilation.
> Also I have found that my regular testing is broken that's why I haven't
> found these problems earlier.
> Would it be possible to add these two patches to your tree.
> I know it is late but still v2013.10 hasn't been tagged.

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings

[Enric Balletbo Serra]

Hi Sricharan,

2013/10/16 Sricharan R :
> Hi,
>
> On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
>>> Hi Sricharan,
>>>
>>> 2013/10/16 Sricharan R :
 Changing the IO settings to turn on VREF_DQ and
 disable weak pullup for DQS/nDQS.

 Signed-off-by: Sricharan R 
 ---
  arch/arm/include/asm/arch-omap5/omap.h |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
 b/arch/arm/include/asm/arch-omap5/omap.h
 index 414d37a..3c2306f 100644
 --- a/arch/arm/include/asm/arch-omap5/omap.h
 +++ b/arch/arm/include/asm/arch-omap5/omap.h
 @@ -145,9 +145,9 @@ struct s32ktimer {
  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0

  #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
 -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
 +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
  #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
 -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
 +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421

  #define EFUSE_1 0x45145100
>>> Sorry for my ignorance, I just want to know more ...
>>>
>>> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? 
>>> Improves ?
>> I suspect I know what this is about, but can we please have a more
>> verbose commit message here?
>
> Above the two changes improved DDR3 stability at extended temperature
> ranges above 83C.
>
> 1) The first change from 0x64656465 to 0x64646464 removes the weak pull
>  on the DQ lines. Otherwise the DQ line was not staying at Vref when IDLE 
> (retreats
>  to ground) and because of this there were extra transitions and noise.
>
>  2) The second change was to enable internal VREF_DQ_OUT which otherwise was 
> at 0V.
>
> Hope this helps. BTW, i will repost with a better commit log. Sorry.
>
> Regards,
>  Sricharan
>

Many thanks for the explanation.

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

[U-Boot] [PATCH V2] ARM: OMAP5: DDR3: Change io settings

[Sricharan R]

The DDR DQ lines are enabled with weak pull. So the DQ line was not staying at 
Vref
when IDLE (retreats to ground) and because of this there were extra transitions
and noise. So change from 0x64656465 to 0x64646464 to remove the weak pull.

Also internal VREF_DQOUT is set to 0. This has to enabled as well.

With the above two changes better memory stability was observed with extended 
temperature ranges around 100C

Signed-off-by: Sricharan R 
---
[V2] Added more descriptive commit log

 arch/arm/include/asm/arch-omap5/omap.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
 #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
 
 #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
 #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
 #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
 
 #define EFUSE_1 0x45145100
-- 
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] ARM: OMAP5: DDR3: Change io settings

[Sricharan R]

Hi,

On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
>> Hi Sricharan,
>>
>> 2013/10/16 Sricharan R :
>>> Changing the IO settings to turn on VREF_DQ and
>>> disable weak pullup for DQS/nDQS.
>>>
>>> Signed-off-by: Sricharan R 
>>> ---
>>>  arch/arm/include/asm/arch-omap5/omap.h |4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
>>> b/arch/arm/include/asm/arch-omap5/omap.h
>>> index 414d37a..3c2306f 100644
>>> --- a/arch/arm/include/asm/arch-omap5/omap.h
>>> +++ b/arch/arm/include/asm/arch-omap5/omap.h
>>> @@ -145,9 +145,9 @@ struct s32ktimer {
>>>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
>>>
>>>  #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
>>> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
>>> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
>>>  #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
>>> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
>>> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
>>>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
>>>
>>>  #define EFUSE_1 0x45145100
>> Sorry for my ignorance, I just want to know more ...
>>
>> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? 
>> Improves ?
> I suspect I know what this is about, but can we please have a more
> verbose commit message here?

Above the two changes improved DDR3 stability at extended temperature
ranges above 83C.

1) The first change from 0x64656465 to 0x64646464 removes the weak pull
 on the DQ lines. Otherwise the DQ line was not staying at Vref when IDLE 
(retreats
 to ground) and because of this there were extra transitions and noise.

 2) The second change was to enable internal VREF_DQ_OUT which otherwise was at 
0V.

Hope this helps. BTW, i will repost with a better commit log. Sorry.

Regards,
 Sricharan

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

[U-Boot] [PATCH 2/4] usb: ums: code refactoring to improve reusability at other boards.

[Przemyslaw Marczak]

This patch introduces some cleanups to ums code. Changes:

ums common:
- introduce UMS_START_BLOCK and UMS_PART_SIZE as defined in usb_mass_storage.h
  both default values as 0 if board config do not define them

common cleanup changes:
- change name of struct "ums_board_info" to "ums"
- "ums_device" fields are moved to struct ums and "dev_num" is removed
- change function name: board_ums_init to ums_init
- remove "extern" prefixes from usb_mass_storage.h

cmd_usb_mass_storage:
- change error() to printf() if need to print info message
- change return values to command_ret_t type at ums command code
- add command usage string

Signed-off-by: Przemyslaw Marczak 
Cc: Marek Vasut 
---
 board/samsung/common/ums.c  |   37 ++-
 common/cmd_usb_mass_storage.c   |   27 +++--
 drivers/usb/gadget/f_mass_storage.c |   26 
 drivers/usb/gadget/storage_common.c |3 +--
 include/usb_mass_storage.h  |   33 +--
 5 files changed, 62 insertions(+), 64 deletions(-)

diff --git a/board/samsung/common/ums.c b/board/samsung/common/ums.c
index 506f4b5..1f28590 100644
--- a/board/samsung/common/ums.c
+++ b/board/samsung/common/ums.c
@@ -9,30 +9,33 @@
 #include 
 #include 
 
-static int ums_read_sector(struct ums_device *ums_dev,
+static int ums_read_sector(struct ums *ums_dev,
   ulong start, lbaint_t blkcnt, void *buf)
 {
-   if (ums_dev->mmc->block_dev.block_read(ums_dev->dev_num,
-  start + ums_dev->offset, blkcnt,
-  buf) != blkcnt)
+   int dev_num = ums_dev->mmc->block_dev.dev;
+
+   if (ums_dev->mmc->block_dev.block_read(dev_num,
+  start + ums_dev->offset,
+  blkcnt, buf) != blkcnt)
return -1;
 
return 0;
 }
 
-static int ums_write_sector(struct ums_device *ums_dev,
+static int ums_write_sector(struct ums *ums_dev,
ulong start, lbaint_t blkcnt, const void *buf)
 {
-   if (ums_dev->mmc->block_dev.block_write(ums_dev->dev_num,
-   start + ums_dev->offset, blkcnt,
-   buf) != blkcnt)
+   int dev_num = ums_dev->mmc->block_dev.dev;
+
+   if (ums_dev->mmc->block_dev.block_write(dev_num,
+   start + ums_dev->offset,
+   blkcnt, buf) != blkcnt)
return -1;
 
return 0;
 }
 
-static void ums_get_capacity(struct ums_device *ums_dev,
-long long int *capacity)
+static void ums_get_capacity(struct ums *ums_dev, long long int *capacity)
 {
long long int tmp_capacity;
 
@@ -41,15 +44,16 @@ static void ums_get_capacity(struct ums_device *ums_dev,
*capacity = ums_dev->mmc->capacity - tmp_capacity;
 }
 
-static struct ums_board_info ums_board = {
+static struct ums ums_dev = {
.read_sector = ums_read_sector,
.write_sector = ums_write_sector,
.get_capacity = ums_get_capacity,
.name = "UMS disk",
+   .offset = UMS_START_BLOCK,
+   .part_size = UMS_PART_SIZE,
 };
 
-struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int 
offset,
- unsigned int part_size)
+struct ums *ums_init(unsigned int dev_num)
 {
struct mmc *mmc = NULL;
 
@@ -57,10 +61,7 @@ struct ums_board_info *board_ums_init(unsigned int dev_num, 
unsigned int offset,
if (!mmc)
return NULL;
 
-   ums_board.ums_dev.mmc = mmc;
-   ums_board.ums_dev.dev_num = dev_num;
-   ums_board.ums_dev.offset = offset;
-   ums_board.ums_dev.part_size = part_size;
+   ums_dev.mmc = mmc;
 
-   return &ums_board;
+   return &ums_dev;
 }
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index f583caf..f6ceba7 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -22,28 +22,26 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
 
unsigned int dev_num = (unsigned int)(simple_strtoul(mmc_devstring,
NULL, 0));
-   if (dev_num) {
-   error("Set eMMC device to 0! - e.g. ums 0");
-   goto fail;
-   }
+   if (dev_num)
+   return CMD_RET_USAGE;
 
unsigned int controller_index = (unsigned int)(simple_strtoul(
usb_controller, NULL, 0));
if (board_usb_init(controller_index, USB_INIT_DEVICE)) {
error("Couldn't init USB controller.");
-   goto fail;
+   return CMD_RET_FAILURE;
}
 
-   struct ums_board_info *ums_info = board_ums_init(dev_num, 0, 0);
-   if (!ums_info) {
-   er

[U-Boot] [PATCH 3/4] usb: ums: fix bug in partition capacity computation.

[Przemyslaw Marczak]

Before this change ums disk capacity was miscalculated because
of integer overflow.

Signed-off-by: Przemyslaw Marczak 
Cc: Marek Vasut 
---
 board/samsung/common/ums.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/board/samsung/common/ums.c b/board/samsung/common/ums.c
index 1f28590..6c4e6c4 100644
--- a/board/samsung/common/ums.c
+++ b/board/samsung/common/ums.c
@@ -37,11 +37,19 @@ static int ums_write_sector(struct ums *ums_dev,
 
 static void ums_get_capacity(struct ums *ums_dev, long long int *capacity)
 {
-   long long int tmp_capacity;
+   int64_t mmc_capacity = (int64_t)ums_dev->mmc->capacity;
+   int64_t ums_capacity = (int64_t)ums_dev->part_size * SECTOR_SIZE;
+   int64_t ums_offset = (int64_t)ums_dev->offset * SECTOR_SIZE;
 
-   tmp_capacity = (long long int)((ums_dev->offset + ums_dev->part_size)
-  * SECTOR_SIZE);
-   *capacity = ums_dev->mmc->capacity - tmp_capacity;
+   if (ums_capacity && ((ums_capacity + ums_offset) < mmc_capacity))
+   *capacity = ums_capacity;
+   else
+   *capacity = mmc_capacity - ums_offset;
+
+   printf("UMS: partition capacity: %#llx blocks\n"
+  "UMS: partition start block: %#x\n",
+  *capacity / SECTOR_SIZE,
+  ums_dev->offset);
 }
 
 static struct ums ums_dev = {
-- 
1.7.9.5

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

[U-Boot] [PATCH 0/4] USB: UMS: code refactoring and usage improvement

[Przemyslaw Marczak]

Hello,
Please look at my little ums refactor.

Quick summary:
- move ums initialization code to Samsung common
- introduce board definable parameters: UMS_START_BLOCK and UMS_PART_SIZE
- remove ums unnecessary code
- move ums structures to just one generic ums structure
- fix ums capacity miscalculation
- add function usb_cable_connected() which depends on CONFIG_USB_CABLE_CHECK
- add ums exit feature by ctrl+c or cable detachment

Thank you,
Przemyslaw Marczak

Przemyslaw Marczak (4):
  usb: ums: move ums code from trats to Samsung common directory
  usb: ums: code refactoring to improve reusability at other boards.
  usb: ums: fix bug in partition capacity computation.
  usb: ums: add ums exit feature by ctrl+c or by detach usb cable

 board/samsung/common/Makefile   |1 +
 board/samsung/common/ums.c  |   75 +++
 board/samsung/trats/trats.c |   62 -
 common/cmd_usb_mass_storage.c   |   48 +++---
 drivers/usb/gadget/f_mass_storage.c |   50 +++
 drivers/usb/gadget/storage_common.c |3 +-
 include/configs/trats.h |2 -
 include/usb.h   |   10 +
 include/usb_mass_storage.h  |   33 ---
 9 files changed, 163 insertions(+), 121 deletions(-)
 create mode 100644 board/samsung/common/ums.c

-- 
1.7.9.5

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

[U-Boot] [PATCH 4/4] usb: ums: add ums exit feature by ctrl+c or by detach usb cable

[Przemyslaw Marczak]

This patch allows exiting from UMS mode to u-boot prompt
by detaching usb cable or by pressing ctrl+c.

Add new config: CONFIG_USB_CABLE_CHECK. If defined then board
file should provide function: usb_cable_connected() (include/usb.h)
that return 1 if cable is connected and 0 otherwise.

Signed-off-by: Przemyslaw Marczak 
Cc: Marek Vasut 
---
 common/cmd_usb_mass_storage.c   |   21 +
 drivers/usb/gadget/f_mass_storage.c |   24 +---
 include/usb.h   |   10 ++
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index f6ceba7..9224d3c 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -47,16 +48,20 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
g_dnl_register("ums");
 
while (1) {
-   /* Handle control-c and timeouts */
-   if (ctrlc()) {
-   error("The remote end did not respond in time.");
-   goto exit;
-   }
-
usb_gadget_handle_interrupts();
-   /* Check if USB cable has been detached */
-   if (fsg_main_thread(NULL) == EIO)
+
+   rc = fsg_main_thread(NULL);
+   if (rc) {
+   /* Check I/O error */
+   if (rc == -EIO)
+   printf("\rCheck USB cable connection\n");
+
+   /* Check CTRL+C */
+   if (rc == -EPIPE)
+   printf("\rCTRL+C - Operation aborted\n");
+
goto exit;
+   }
}
 exit:
g_dnl_unregister();
diff --git a/drivers/usb/gadget/f_mass_storage.c 
b/drivers/usb/gadget/f_mass_storage.c
index 9560deb..a49572d 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -245,6 +245,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -678,6 +679,18 @@ static int sleep_thread(struct fsg_common *common)
k++;
}
 
+   if (k == 10) {
+   /* Handle CTRL+C */
+   if (ctrlc())
+   return -EPIPE;
+#ifdef CONFIG_USB_CABLE_CHECK
+   /* Check cable connection */
+   if (!usb_cable_connected())
+   return -EIO;
+#endif
+   k = 0;
+   }
+
usb_gadget_handle_interrupts();
}
common->thread_wakeup_needed = 0;
@@ -2389,6 +2402,7 @@ static void handle_exception(struct fsg_common *common)
 
 int fsg_main_thread(void *common_)
 {
+   int ret;
struct fsg_common   *common = the_fsg_common;
/* The main loop */
do {
@@ -2398,12 +2412,16 @@ int fsg_main_thread(void *common_)
}
 
if (!common->running) {
-   sleep_thread(common);
+   ret = sleep_thread(common);
+   if (ret)
+   return ret;
+
continue;
}
 
-   if (get_next_command(common))
-   continue;
+   ret = get_next_command(common);
+   if (ret)
+   return ret;
 
if (!exception_in_progress(common))
common->state = FSG_STATE_DATA_PHASE;
diff --git a/include/usb.h b/include/usb.h
index 17fb68c..8c1789f 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -197,6 +197,16 @@ int board_usb_init(int index, enum board_usb_init_type 
init);
  */
 int board_usb_cleanup(int index, enum board_usb_init_type init);
 
+/*
+ * If CONFIG_USB_CABLE_CHECK is set then this function
+ * should be defined in board file.
+ *
+ * @return 1 if cable is connected and 0 otherwise.
+ */
+#ifdef CONFIG_USB_CABLE_CHECK
+int usb_cable_connected(void);
+#endif
+
 #ifdef CONFIG_USB_STORAGE
 
 #define USB_MAX_STOR_DEV 5
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/4] usb: ums: move ums code from trats to Samsung common directory

[Przemyslaw Marczak]

UMS init was implemented in trats board file but mostly it comprises
common code. Due to that it has been moved to common/ums.c to avoid
code duplication in the future.

Changes:
- move ums initialization code from trats to common/ums.c
- remove unused CONFIG_USB_GADGET_MASS_STORAGE from trats.h

Signed-off-by: Przemyslaw Marczak 
Cc: Marek Vasut 
Cc: Minkyu Kang 
Cc: Lukasz Majewski 
---
 board/samsung/common/Makefile |1 +
 board/samsung/common/ums.c|   66 +
 board/samsung/trats/trats.c   |   62 --
 include/configs/trats.h   |2 --
 4 files changed, 67 insertions(+), 64 deletions(-)
 create mode 100644 board/samsung/common/ums.c

diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index ad7564c..d122169 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -11,6 +11,7 @@ LIB   = $(obj)libsamsung.o
 
 COBJS-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
 COBJS-$(CONFIG_THOR_FUNCTION) += thor.o
+COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += ums.o
 
 SRCS:= $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/samsung/common/ums.c b/board/samsung/common/ums.c
new file mode 100644
index 000..506f4b5
--- /dev/null
+++ b/board/samsung/common/ums.c
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Lukasz Majewski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+static int ums_read_sector(struct ums_device *ums_dev,
+  ulong start, lbaint_t blkcnt, void *buf)
+{
+   if (ums_dev->mmc->block_dev.block_read(ums_dev->dev_num,
+  start + ums_dev->offset, blkcnt,
+  buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+   ulong start, lbaint_t blkcnt, const void *buf)
+{
+   if (ums_dev->mmc->block_dev.block_write(ums_dev->dev_num,
+   start + ums_dev->offset, blkcnt,
+   buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+long long int *capacity)
+{
+   long long int tmp_capacity;
+
+   tmp_capacity = (long long int)((ums_dev->offset + ums_dev->part_size)
+  * SECTOR_SIZE);
+   *capacity = ums_dev->mmc->capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+   .read_sector = ums_read_sector,
+   .write_sector = ums_write_sector,
+   .get_capacity = ums_get_capacity,
+   .name = "UMS disk",
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int 
offset,
+ unsigned int part_size)
+{
+   struct mmc *mmc = NULL;
+
+   mmc = find_mmc_device(dev_num);
+   if (!mmc)
+   return NULL;
+
+   ums_board.ums_dev.mmc = mmc;
+   ums_board.ums_dev.dev_num = dev_num;
+   ums_board.ums_dev.offset = offset;
+   ums_board.ums_dev.part_size = part_size;
+
+   return &ums_board;
+}
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 58d925f..db5828d 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -772,65 +772,3 @@ void init_panel_info(vidinfo_t *vid)
 
setenv("lcdinfo", "lcd=s6e8ax0");
 }
-
-#ifdef CONFIG_USB_GADGET_MASS_STORAGE
-static int ums_read_sector(struct ums_device *ums_dev,
-  ulong start, lbaint_t blkcnt, void *buf)
-{
-   if (ums_dev->mmc->block_dev.block_read(ums_dev->dev_num,
-   start + ums_dev->offset, blkcnt, buf) != blkcnt)
-   return -1;
-
-   return 0;
-}
-
-static int ums_write_sector(struct ums_device *ums_dev,
-   ulong start, lbaint_t blkcnt, const void *buf)
-{
-   if (ums_dev->mmc->block_dev.block_write(ums_dev->dev_num,
-   start + ums_dev->offset, blkcnt, buf) != blkcnt)
-   return -1;
-
-   return 0;
-}
-
-static void ums_get_capacity(struct ums_device *ums_dev,
-long long int *capacity)
-{
-   long long int tmp_capacity;
-
-   tmp_capacity = (long long int) ((ums_dev->offset + ums_dev->part_size)
-   * SECTOR_SIZE);
-   *capacity = ums_dev->mmc->capacity - tmp_capacity;
-}
-
-static struct ums_board_info ums_board = {
-   .read_sector = ums_read_sector,
-   .write_sector = ums_write_sector,
-   .get_capacity = ums_get_capacity,
-   .name = "TRATS UMS disk",
-   .ums_dev = {
-   .mmc = NULL,
-   .dev_num = 0,
-   .offset = 0,
-   .part_size = 0.
-   },
-};
-
-struct ums_board

Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
> Hi Sricharan,
> 
> 2013/10/16 Sricharan R :
>> Changing the IO settings to turn on VREF_DQ and
>> disable weak pullup for DQS/nDQS.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  arch/arm/include/asm/arch-omap5/omap.h |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
>> b/arch/arm/include/asm/arch-omap5/omap.h
>> index 414d37a..3c2306f 100644
>> --- a/arch/arm/include/asm/arch-omap5/omap.h
>> +++ b/arch/arm/include/asm/arch-omap5/omap.h
>> @@ -145,9 +145,9 @@ struct s32ktimer {
>>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
>>
>>  #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
>> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
>> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
>>  #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
>> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
>> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
>>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
>>
>>  #define EFUSE_1 0x45145100
>
> Sorry for my ignorance, I just want to know more ...
> 
> What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? 
> Improves ?

I suspect I know what this is about, but can we please have a more
verbose commit message here?

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

iQIcBAEBAgAGBQJSXoefAAoJENk4IS6UOR1WbcUP/0BlIP5NY4KU47JRfUn3CbxP
zS2m38hrHsmwiO7RO1OocI5wZm4jTFKfoTkxenuYdfyoJycSKaD0qWOCgYHobMHy
uxZ4qTkMrBVquRgiUuMjlII8tHMAX+ce8sVehnGXmG3EMYK4H5OAzvrKWsW7Cyx8
PbNQzZxNghenMJ2UHme2GhWp5OJtHerVoj7j7DMNUVFgeOs/x9MxRQyvIc/dOJ9r
0M1UOLK15R3GjHw6ClrYvsa8wPoobbdhALU7Nem7EuQZlmYtBl8RIQa3EghjVfB+
yX9IxbFMoWgEDCSYkzK/oAm5rjcqGJxfTsOYancEBd8l3L2eSTsYUuK2BVPBCkYP
GoHz1Mm7f+TwzVZfyAS4cGkFg7LRymj9M5vIhKg9mZp5a0MxKw/2DsiVEKlCJU/t
TZHaBzQ8jmwmZ296qvPh8n3XnEzO7zn3hutowghux3LLfkuyaBC346haMS5GA77D
D3TjWsYIr8XEaJ87DI7H3Ll1leSxRcDu3V3naR7/s/+gVIcXe8Iv4QApnp0bP5+2
8HT5bQtIJTEu58ZP7taWzhkrpD/FWTBUNt18X6koaRSMjG7Za37VnG6IRlKW1MbG
CdsfWbTv1n46Ee4Qr/g1d5t0g92fay5dlpuJHdMafQR7p6WqA88QkxhWBSUv7mnn
ZTONa00kbM3+npFlIZfZ
=cIsK
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: mxc: Fix data loss for non aligned write buffers.

[Albert ARIBAUD]

Hi Jagan,

On Wed, 16 Oct 2013 16:20:17 +0530, Jagan Teki
 wrote:

> Hi Amicalement,
> 
> On Wed, Oct 16, 2013 at 1:05 PM, Albert ARIBAUD
>  wrote:
> > Hi Jagan,
> >
> > On Wed, 16 Oct 2013 11:16:49 +0530, Jagan Teki
> >  wrote:
> >
> >> Hi,
> >>
> >> On Tue, Oct 15, 2013 at 11:27 PM, Martin Fuzzey  
> >> wrote:
> >> > When writing buffers that are not 32 bit aligned data loss occurs.
> >> >
> >> > This can also occur when the total transfer size is not a multiple of 4 
> >> > bytes
> >> > since the extra bytes are written first causing the rest to be unaligned.
> >> >
> >> > This can be seen by writing to SPI flash a 57 byte file containing 00 01 
> >> > .. 38:
> >> >
> >> > U-Boot > dhcp data.bin
> >> > ...
> >> > Bytes transferred = 57 (39 hex)
> >> > U-Boot > md.b $loadaddr
> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> >> > 
> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> >> > 
> >> > 7220: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
> >> > !"#$%&'()*+,-./
> >> > 7230: 30 31 32 33 34 35 36 37 38 ff ff ff ff ff ff ff
> >> > 012345678...
> >> > U-Boot > sf write $loadaddr 0 $filesize
> >> >
> >> > U-Boot > mw.b $loadaddr ff 100
> >> > U-Boot > sf read $loadaddr 0 100
> >> > U-Boot > md.b $loadaddr
> >> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> >> > 
> >> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> >> > 
> >> > 7220: 20 21 22 23 24 29 2a 2b 2c 31 32 33 34 ff ff ff 
> >> > !"#$)*+,1234...
> >> > 7230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> > 
> >> >
> >> > [bytes 25-28, 2d-30, 35-38 are missing]
> >> >
> >> > Activating debug in the write command gave:
> >> > spi_xchg_single: bitlen 256 dout 0x7200 din 0x0
> >> > Sending SPI 0x10203
> >> > Sending SPI 0x4050607
> >> > Sending SPI 0x8090a0b
> >> > Sending SPI 0xc0d0e0f
> >> > Sending SPI 0x10111213
> >> > Sending SPI 0x14151617
> >> > Sending SPI 0x18191a1b
> >> > Sending SPI 0x1c1d1e1f
> >> > SPI Rx: 0x 0x
> >> > ...
> >> > SPI Rx: 0x 0x
> >> > spi_xchg_single: bitlen 200 dout 0x7220 din 0x0
> >> > Sending SPI 0x20
> >> > Sending SPI 0x21222324
> >> > Sending SPI 0x292a2b2c  <===  What happened to 25262728?
> >> > Sending SPI 0x31323334
> >> > Sending SPI 0x
> >> > ...
> >> > SF: program success 57 bytes @ 0x0
> >> Thanks for your log, for showing the exact issues.
> >
> > Agreed, but I think this log could go in a comment below the '---'
> > line, so that the commit message focuses on describing what the patch
> > does, rather than how it was found out necessary.
> 
> I too thought the same, but the commit is already in master, any
> possibility to alter?

Er... Martin's patch is already in patchwork as 283794, but its state
is still "New" with no delegate, and I don't see it in any of the
repos I usually read, nor does it appear on u-boot-spi. Where do you
see it "in master" exactly?

Besides, it is less than 24 hours old; this is not enough time for
review, and therefore, it should not be accepted yet.

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

Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings

[Enric Balletbo Serra]

Hi Sricharan,

2013/10/16 Sricharan R :
> Changing the IO settings to turn on VREF_DQ and
> disable weak pullup for DQS/nDQS.
>
> Signed-off-by: Sricharan R 
> ---
>  arch/arm/include/asm/arch-omap5/omap.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
> b/arch/arm/include/asm/arch-omap5/omap.h
> index 414d37a..3c2306f 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -145,9 +145,9 @@ struct s32ktimer {
>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
>
>  #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
> -#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
> +#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
>  #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
> -#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
> +#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
>  #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
>
>  #define EFUSE_1 0x45145100
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Sorry for my ignorance, I just want to know more ...

What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ? Improves ?

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

Re: [U-Boot] [PATCH] spi: mxc: Fix data loss for non aligned write buffers.

[Jagan Teki]

Hi Amicalement,

On Wed, Oct 16, 2013 at 1:05 PM, Albert ARIBAUD
 wrote:
> Hi Jagan,
>
> On Wed, 16 Oct 2013 11:16:49 +0530, Jagan Teki
>  wrote:
>
>> Hi,
>>
>> On Tue, Oct 15, 2013 at 11:27 PM, Martin Fuzzey  wrote:
>> > When writing buffers that are not 32 bit aligned data loss occurs.
>> >
>> > This can also occur when the total transfer size is not a multiple of 4 
>> > bytes
>> > since the extra bytes are written first causing the rest to be unaligned.
>> >
>> > This can be seen by writing to SPI flash a 57 byte file containing 00 01 
>> > .. 38:
>> >
>> > U-Boot > dhcp data.bin
>> > ...
>> > Bytes transferred = 57 (39 hex)
>> > U-Boot > md.b $loadaddr
>> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>> > 
>> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
>> > 
>> > 7220: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
>> > !"#$%&'()*+,-./
>> > 7230: 30 31 32 33 34 35 36 37 38 ff ff ff ff ff ff ff
>> > 012345678...
>> > U-Boot > sf write $loadaddr 0 $filesize
>> >
>> > U-Boot > mw.b $loadaddr ff 100
>> > U-Boot > sf read $loadaddr 0 100
>> > U-Boot > md.b $loadaddr
>> > 7200: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>> > 
>> > 7210: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
>> > 
>> > 7220: 20 21 22 23 24 29 2a 2b 2c 31 32 33 34 ff ff ff 
>> > !"#$)*+,1234...
>> > 7230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > 
>> >
>> > [bytes 25-28, 2d-30, 35-38 are missing]
>> >
>> > Activating debug in the write command gave:
>> > spi_xchg_single: bitlen 256 dout 0x7200 din 0x0
>> > Sending SPI 0x10203
>> > Sending SPI 0x4050607
>> > Sending SPI 0x8090a0b
>> > Sending SPI 0xc0d0e0f
>> > Sending SPI 0x10111213
>> > Sending SPI 0x14151617
>> > Sending SPI 0x18191a1b
>> > Sending SPI 0x1c1d1e1f
>> > SPI Rx: 0x 0x
>> > ...
>> > SPI Rx: 0x 0x
>> > spi_xchg_single: bitlen 200 dout 0x7220 din 0x0
>> > Sending SPI 0x20
>> > Sending SPI 0x21222324
>> > Sending SPI 0x292a2b2c  <===  What happened to 25262728?
>> > Sending SPI 0x31323334
>> > Sending SPI 0x
>> > ...
>> > SF: program success 57 bytes @ 0x0
>> Thanks for your log, for showing the exact issues.
>
> Agreed, but I think this log could go in a comment below the '---'
> line, so that the commit message focuses on describing what the patch
> does, rather than how it was found out necessary.

I too thought the same, but the commit is already in master, any
possibility to alter?

-- 
Thanks,
Jagan.

Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings

[Sricharan R]

Changing the IO settings to turn on VREF_DQ and
disable weak pullup for DQS/nDQS.

Signed-off-by: Sricharan R 
---
 arch/arm/include/asm/arch-omap5/omap.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
 #define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
 
 #define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
 #define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
 #define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
 
 #define EFUSE_1 0x45145100
-- 
1.7.9.5

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

Re: [U-Boot] Is EP88x board dead or not?

[Masahiro Yamada]

Hello Albert, Wolfgang.

> I would therefore say that if you want EP88x re-introduced, then please
> step up as the new board maintainer by adding your e-mail address in
> boards.cfg -- and please do it only if you actually have an EP88x board
> to test on.
> 
> If you don't have an EP88x, or do not plan to be a maintainer for it,
> and if no one else does either, then the best is to remove it ent

I neither have the board nor plan to be a maintiner.

Best Regards
Masahiro Yamada

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

Re: [U-Boot] Is EP88x board dead or not?

[Albert ARIBAUD]

Hi Masahiro,

On Wed, 16 Oct 2013 18:30:56 +0900, Masahiro Yamada
 wrote:

> Hello Wolfgang
> 
> 
> You deleted the EP88x entry in boards.cfg
> at the following commit
> 
> 
> commit 1b0757eceddf037aad99ab59217a3a5c215e15d1
> Author: Wolfgang Denk 
> Date:   Wed Oct 24 02:36:15 2012 +
> 
> PPC: remove dead boards (AMX860, c2mon, ETX094, IAD210, LANTEC, SCM)
> 
> These boards have long reached EOL, and there has been no indication
> of any active users of such hardware for years.  Get rid of the dead
> weight.
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Wolfgang Grandegger 
> 
> 
> 
> You only mentioned about AMX860, c2mon, ETX094, IAD210, LANTEC, SCM in commit 
> log.
> But you also deleted EP88x.
> 
> 
> I suspect you accidentally deleted the entry of EP88x in boards.cfg
> because:
> 
>  - EP88x is not found in doc/README.scrapyard
>  - include/configs/EP88x.h is remaining
>  - board/ep88x/  is remaining
>  - I could successfully build EP88x by simply re-adding entry to boards.cfg

(Wolfgang, correct me if I am wrong)

I cannot tell indeed if Wolfgang's removal of ep88x was intentional or
not, but two things are sure: prior to its removal by Wolfgang, EP88x
did not have any MAINTAINERS entry; and since it was removed, you are
the first one to notice.

I would therefore say that if you want EP88x re-introduced, then please
step up as the new board maintainer by adding your e-mail address in
boards.cfg -- and please do it only if you actually have an EP88x board
to test on.

If you don't have an EP88x, or do not plan to be a maintainer for it,
and if no one else does either, then the best is to remove it entirely.

> Best Regards
> Masahiro Yamada

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

Re: [U-Boot] [PATCH] mtd: fix warnings due to 64-bit partition support

[Paul Burton]

On 16/10/13 07:08, Stefan Roese wrote:

Hi Scott,

On 16.10.2013 00:41, Scott Wood wrote:

commit 39ac34473f3c96e77cbe03a49141771ed1639486 ("cmd_mtdparts: use 64
bits for flash size, partition size & offset") introduced warnings
in a couple places due to printf formats or pointer casting.

This patch fixes the warnings pointed out here:
http://lists.denx.de/pipermail/u-boot/2013-October/164981.html

Signed-off-by: Scott Wood 
Cc: York Sun 
Cc: Stefan Roese 
Cc: Paul Burton 
Cc: Tom Rini 


Acked-by: Stefan Roese 


---
Alternatively, given the imminent release, perhaps all but the first
patch of my recent NAND pull request should be reverted.  The first
patch was a regression fix, but on a second look the remaining patches
look more like enabling a new feature (and I didn't look too closely at
the ubi patches because Stefan had acked them and asked me to apply;
patch 4 is clearly not a bugfix).


Yes. But the first version of this patchset was posted before the merge
window was closed (on the 6th of August). So they should be integrated
in this release. That was my reasoning.

Thanks,
Stefan



Thanks for catching & fixing this guys :)

I'll make sure to build all boards when touching non-board-specific code 
in future!


Paul

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

[U-Boot] Is EP88x board dead or not?

[Masahiro Yamada]

Hello Wolfgang


You deleted the EP88x entry in boards.cfg
at the following commit


commit 1b0757eceddf037aad99ab59217a3a5c215e15d1
Author: Wolfgang Denk 
Date:   Wed Oct 24 02:36:15 2012 +

PPC: remove dead boards (AMX860, c2mon, ETX094, IAD210, LANTEC, SCM)

These boards have long reached EOL, and there has been no indication
of any active users of such hardware for years.  Get rid of the dead
weight.

Signed-off-by: Wolfgang Denk 
Cc: Wolfgang Grandegger 



You only mentioned about AMX860, c2mon, ETX094, IAD210, LANTEC, SCM in commit 
log.
But you also deleted EP88x.


I suspect you accidentally deleted the entry of EP88x in boards.cfg
because:

 - EP88x is not found in doc/README.scrapyard
 - include/configs/EP88x.h is remaining
 - board/ep88x/  is remaining
 - I could successfully build EP88x by simply re-adding entry to boards.cfg




Best Regards
Masahiro Yamada

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

[U-Boot] [RFC PATCH 2/2] usb: dfu: correct dfu buffer inited value

[Bo Shen]

After dfu buffer is initialized, the buffer should be all available,
while not 0. Initialize its value to min(dfu_buf_size, dfu->r_left).

Signed-off-by: Bo Shen 

---
 drivers/dfu/dfu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 65c6984..b8c8aa4 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -288,7 +288,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size, 
int blk_seq_num)
dfu->offset = 0;
dfu->i_buf_end = dfu_get_buf() + dfu_buf_size;
dfu->i_buf = dfu->i_buf_start;
-   dfu->b_left = 0;
+   dfu->b_left = min(dfu_buf_size, dfu->r_left);
 
dfu->bad_skip = 0;
 
-- 
1.7.9.5

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

[U-Boot] [RFC PATCH 1/2] usb: dfu: decrease dfu->r_left along with the transfer

[Bo Shen]

The value of dfu->r_left need decrease along with the transfer

Signed-off-by: Bo Shen 
---
 drivers/dfu/dfu.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 56b21c7..65c6984 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -229,6 +229,7 @@ static int dfu_read_buffer_fill(struct dfu_entity *dfu, 
void *buf, int size)
dfu->crc = crc32(dfu->crc, buf, chunk);
dfu->i_buf += chunk;
dfu->b_left -= chunk;
+   dfu->r_left -= chunk;
size -= chunk;
buf += chunk;
readn += chunk;
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 0/3] All M68K boards are broken

[Masahiro Yamada]

Hello Albert


> If it is unrelated, then ignore my comment.

Yes.
They are totally unrelated.



> Even after applying the patch
> "config.mk: fix -fstack-usage support test"
> (http://patchwork.ozlabs.org/patch/283619/),
> I still cannot compile m68k correctly.

I should have dropped this comment.
It looks like it was confusing...


Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init

[Stefano Babic]

Hi Marek,

On 15/10/2013 23:19, Marek Vasut wrote:
> 
> Forget this, the issue is still present. Damn!
> 
> It's at least a little clearer to me what happens now. The FEC fails to 
> transmit 
> an TFTP block ACK packet -> the server waits 5 seconds -> sends ARP packet -> 
> FEC replies and resends the TFTP block ACK again. Why does the FEC swallow a 
> TX 
> packet, I don't know.

Anyway, it is strange that this happens only with this board. It appears
as the SOC sends or thinks to have sent, but the packet is corrupted or
not sent at all on the physical layer. Maybe you can check on the other
side of the connection on the switch and/or on the server, if some
errors are detected.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 1/2] I2C: Zynq: Support for 0-length register address

[Michal Simek]

On 10/16/2013 10:24 AM, Heiko Schocher wrote:
> Hello Michael,
> 
> Am 15.10.2013 22:23, schrieb Michael Burr:
>>> Fixed bug with alen == 0 in 'i2c_write', 'i2c_read'
>> Further minor corrections:
>>> Write 'address' register before 'data' register.
>>> Write 'transfer_size' register before 'address' register.
>>
>> Signed-off-by: Michael Burr 
>> Cc: Heiko Schocher 
>> Cc: Michal Simek 
>>
>> ---
>> Tested:
>> Xilinx ZC702 eval board.
>> Write and read registers with addresses of length 0 and 1.
>>
>> Change history:
>>> v2: put this in a series instead of by itself
>>> v3: fixed formatting problem in patch message
>>> v4: _really_ fixed this time!
>>> v5: yet another try
>>> v6: one more time
>>> v7: again
>>  > v8: After trying many times, I cannot get Patchwork to properly 
>> understand the diff in this message. As a workaround, please accept the diff 
>> in my patch of 2013-09-24, titled "[U-Boot] I2C: Zynq: Support for 0-length 
>> register address", which is 100%
>> equivalent to the patch in this message (1/2). It should still be applied 
>> before the patch in the second message (2/2).
> 
> Hmm.. please try to post a correct version of this patch, as I not
> really want to search the correct patch ... I am sure I will pick up
> the wrong version and I cannot test anything.
> 
> Thanks!
> 
> Hmm.. if you have problems with your commit message, you can reedit
> it:
> - get the commit id before your commit you want to edit
> - "git rebase -i commit-id"
>   -> you get a list of commits, see for help maybe here:
>  https://help.github.com/articles/interactive-rebase
> 
> Please remove the ">" in your commit message ... maybe this confuses
> patchwork ...

Albert is right. Just use patman -n to see your patches to get it done
correctly and then just use patman for sending.
There is nice README which describes everything what you need.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] [RFC PATCH] usb: dfu: make nand upload working

[Bo Shen]

Hi Lukasz Majewski,

On 10/14/2013 15:25, Bo Shen wrote:

Hi Lukasz Majewski,

On 10/13/2013 05:19, Lukasz Majewski wrote:

On Sat, 12 Oct 2013 15:47:14 +0800
Bo Shen  wrote:


If won't pass value to dfu->r_left, it always 0, make no transfer,
the dfu-util on host side report failed. So, before starting transfer,
pass the value, then nand uploading can work.

Signed-off-by: Bo Shen 

---
  drivers/dfu/dfu.c |1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 56b21c7..3c3ad1b 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -274,6 +274,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (dfu->i_buf_start == NULL)
  return -ENOMEM;

+dfu->r_left = dfu->data.nand.size;


Please do not add nand related code to "generic" DFU code. This can
damage DFU operation with other memories (like eMMC).

Such code shall be added to dfu_nand.c file.


Thanks for point out this.
I will check it.


After read more deeply into dfu core code, even we move this patch to 
nand related code as following.
I think this only a workaround for NAND uploading, because it the same 
as mmc uploading, need the dfu buffer size equal or larger than the 
upload file size or partition size.

So, does this acceptable? If acceptable, I will send v2.

---8>---
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -121,6 +121,7 @@ static int dfu_read_medium_nand(struct dfu_entity 
*dfu, u64 offset, void *buf,


switch (dfu->layout) {
case DFU_RAW_ADDR:
+   *len = dfu->data.nand.size;
ret = nand_block_read(dfu, offset, buf, len);
break;
default:
---<8---

Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] All M68K boards are broken

[Albert ARIBAUD]

Hi Masahiro,

On Wed, 16 Oct 2013 17:20:27 +0900, Masahiro Yamada
 wrote:

> Hello Albert.
> 
> 
> > > Even after applying the patch
> > > "config.mk: fix -fstack-usage support test"
> > > (http://patchwork.ozlabs.org/patch/283619/),
> > > I still cannot compile m68k correctly.
> > 
> > Patch 283691 has not been applied and won't be since it breaks builds;
> > therefore, to fix this, rather than submitting this new patch, please
> > provide a new and fixed version (v5) of the existing one.
> 
> Sorry, I could not understand what you mean.
> 
> I think Patch 283691 does not break builds,
> but fixes -fstack-usage related warnings
> on Blackfin, M68K, etc.
> 
> What I mean is:
> Patch 283619 makes it better,
> but we still have lots of other errors/warnings.

That's what I understood too; and the way you said it, I thought this
patch series was an improvement on 283619. If it is unrelated, then
ignore my comment.

> Best Regards
> Masahiro Yamada

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

Re: [U-Boot] help on adding bootelf to u-boot

[myan]

On 10/16/2013 03:10 PM, Robin Fernandes wrote:

hi sir/madam
 I am trying to run bootelf command from u-boot. But the command is
not inbuilt in it. So could you please let me know what is the procedure
to compile..


for build instructions, see them here:

http://www.denx.de/wiki/DULG/UBoot


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

Re: [U-Boot] help on adding bootelf to u-boot

[myan]

Hi,

On 10/16/2013 03:10 PM, Robin Fernandes wrote:

hi sir/madam
 I am trying to run bootelf command from u-boot. But the command is
not inbuilt in it. So could you please let me know what is the procedure
to compile..


make sure you have CONFIG_CMD_ELF in your board config file.

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