date:20130530

Dear Stephen,

In message 51a6869f.1020...@wwwdotorg.org you wrote:

Since DT is supposed to be a HW description, it shouldn't be using cpp's
built-in macros to compile in different ways; there really isn't a
concept of the target arch of compilation; a .dts file should simply
compile the same way everywhere. Different DTs represent different HW;

I am not 100% sure of that. First, it's not correct to say compiled
compile the same way everywhere - it's not that where it compiled,
butthe for which machine, i. e. which exact cross tool chain is
selected.

And I can well imagine DTs that include parts for specific IP blocks,
where the exact details might depend on the target architecture. We
see an incresing number of cases where the same IP blocks are being
used in different architectures, even of different endianess, etc.
So even if this appears not useful or needed today, I think we should
not intentionally barr the way unless that would realy cause problems
to us.

Or do you see a real potentiol of conflict with the classed reserved
namespaces in GCC with double underscores?

we don't use a single DT with conditional compilation to represent
different HW. This led Rob Herring (one of the kernel device tree
maintainers) to propose the following rules for cpp usage on device trees:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-October/020831.html

One of which was:

- No gcc built-in define usage

I understand that was part of some discussion then. But has it been
generally agreed on, and eventually even turned into a DT policy
document?

Some history on why we needed to not-define, or un-define, some macros
(such as the linux macro we're discussing here) can be found in:

http://linux-kernel.2935.n7.nabble.com/PATCH-V7-kbuild-create-a-rule-to-run-the-pre-processor-on-dts-files-td575632.html

The last few messages there end up mentioning -undef, which we/I ended
up using. It looks like -ansi wasn't mentioned at all when discussing
this issue.

-x assembler-with-cpp makes sense for other reasons, i. e. being
able to mark related lines incommonly used header files with
__ASSEMBLER__ and making sure that '#' gets only processed when in
column 1. It does NOT solve the indetifier problem, though, as GCC
will still define unix and :linux (and eventually more):

- gcc -E -dM -x assembler-with-cpp - /dev/null | grep -v _
#define unix 1
#define linux 1

However, I assert that -undef is better, since we end up without any
pre-defined macros, which DT files shouldn't be using anyway. By my
reading of the cpp manual link you send, -ansi simply stops
non-conforming pre-defined macros from being defined, but doesn't stop
them all being defined as -undef does. Hence, I prefer -undef.

Why do you want to stop something which doesn't hurt you, but might
eventually be useful in other cases?

No, I do not have any real such use cases at hand, but I can see that
it might be for example useful to auto-detect the certain properties
of the system we're building for.

Oh, and another of Rob's proposed rules:

Agreed, another propsal...

shouldn't be exposed. For this reason, create a specific include
directory for use by dtc+cpp, and symlink dt-bindings from there to the
actual location of include/dt-bindings/. For want of a better location,
place this include chroot into the existing dts/ directory.

arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings

OT here, but: Don't you see a risk that such arch specific things
might become a problem soon?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The only way to get rid of a temptation is to yield to it.
- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

Dear Stephen Warren,

In message 51a68a4c.4060...@wwwdotorg.org you wrote:

  Sorry, instead we should strive to be compatible to a reasonably old,
  stable version of DTC, like we do for all other tools as well.  As
  mentioned before - just because RHEL 5 ships an ancient version of -
  say - make we will NOT start building this from the sources ourself.
  This cannot be the way to go.
 
 So the result of that is that we can never ever use new features in any
 tool, at least in any meaningful time-frame.

I wrote we should strive, not this is the only way.

 However, when enabling a new feature, such as using device trees to
 configure U-Boot[1], for which tool support is new and evolving along
 with the feature itself, and which is only used on a very very few
 boards and even fewer SoCs right now within U-Boot, it seems entirely
 reasonable to demand that the people working on/with that new feature
 are aware that it's evolving, and that they may need to take a few extra
 steps to go out and get tools that support that new feature. No doubt
 once this feature has settled down a bit, and distros have pulled in
 newer versions of dtc, everthing will just work just like any other
 stable feature.

Agreed.  And nothing prevents you to installl on your system another,
more recent version of dtc or any other tools needed for specific
purposes.

 If you don't accept this, then we simply have to ban any include use in
 U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to

This has never been my intention. I object only against including the
dtc source into U-Boot, and against automatic methods to build dtc as
part of U-Boot, even in a way that depends on the U-Boot version.

dtc is a tool, like gcc or others.  We may test against specific
versions of the tools in the Makefiles, and even abort a build if an
incompatible version is found.  But we will not include tool sources,
nor build / install rules for tools.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Who alone has reason to *lie  himself  out*  of  actuality?  He  who
*suffers* from it. - Friedrich Nietzsche
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fopen/fwrite functions

Dear tiger...@viatech.com.cn,

In message fe7aded5c2218b4786c09cd97dc4c49f8db...@exchbj02.viatech.com.bj you 
wrote:

 Could i use fopen/fwrite standard C lib functions in U-boot code?

What for?  We do not even have a concept of files in U-Boot...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Any time things appear to be going better, you have overlooked  some-
thing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree

2013-05-30 Thread Vishwanathrao Badarkhe, Manish

Move pinmux configurations for the DA830 SoCs from board file
to the arch tree so that it can be used for all da830 based devices.
Also, avoids duplicate pinmuxing in case of NAND.

Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
---
Depends on:
http://u-boot.10912.n7.nabble.com/PATCH-da830-add-MMC-support-td155590.html

:100644 100644 dec7bfb... bba4671... M  arch/arm/cpu/arm926ejs/davinci/Makefile
:00 100644 000... d0c964a... A  
arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
:100644 100644 a851f1f... beaf0d6... M  
arch/arm/include/asm/arch-davinci/pinmux_defs.h
:100644 100644 bf014ae... a4e9254... M  board/davinci/da8xxevm/da830evm.c
:100644 100644 28995a0... 00e92a6... M  include/configs/da830evm.h
 arch/arm/cpu/arm926ejs/davinci/Makefile |1 +
 arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c   |  151 +++
 arch/arm/include/asm/arch-davinci/pinmux_defs.h |   15 ++-
 board/davinci/da8xxevm/da830evm.c   |  145 ++
 include/configs/da830evm.h  |1 +
 5 files changed, 181 insertions(+), 132 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile 
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index dec7bfb..bba4671 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_SOC_DM355) += dm355.o
 COBJS-$(CONFIG_SOC_DM365)  += dm365.o
 COBJS-$(CONFIG_SOC_DM644X) += dm644x.o
 COBJS-$(CONFIG_SOC_DM646X) += dm646x.o
+COBJS-$(CONFIG_SOC_DA830)  += da830_pinmux.o
 COBJS-$(CONFIG_SOC_DA850)  += da850_pinmux.o
 COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o et1011c.o ksz8873.o
 
diff --git a/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c 
b/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
new file mode 100644
index 000..d0c964a
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
@@ -0,0 +1,151 @@
+/*
+ * Pinmux configurations for the DA830 SoCs
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include asm/arch/davinci_misc.h
+#include asm/arch/hardware.h
+#include asm/arch/pinmux_defs.h
+
+/* SPI0 pin muxer settings */
+const struct pinmux_config spi0_pins_base[] = {
+   { pinmux(7), 1, 3 },  /* SPI0_SOMI */
+   { pinmux(7), 1, 4 },  /* SPI0_SIMO */
+   { pinmux(7), 1, 6 }   /* SPI0_CLK */
+};
+
+const struct pinmux_config spi0_pins_scs0[] = {
+   { pinmux(7), 1, 7 }   /* SPI0_SCS[0] */
+};
+
+const struct pinmux_config spi0_pins_ena[] = {
+   { pinmux(7), 1, 5 }   /* SPI0_ENA */
+};
+
+/* NAND pin muxer settings */
+const struct pinmux_config emifa_pins_cs0[] = {
+   { pinmux(18), 1, 2 }   /* EMA_CS[0] */
+};
+
+const struct pinmux_config emifa_pins_cs2[] = {
+   { pinmux(18), 1, 3 }   /* EMA_CS[2] */
+};
+
+const struct pinmux_config emifa_pins_cs3[] = {
+   { pinmux(18), 1, 4 }   /* EMA_CS[3] */
+};
+
+#ifdef CONFIG_USE_NAND
+const struct pinmux_config emifa_pins[] = {
+   { pinmux(13), 1, 6 },  /* EMA_D[0] */
+   { pinmux(13), 1, 7 },  /* EMA_D[1] */
+   { pinmux(14), 1, 0 },  /* EMA_D[2] */
+   { pinmux(14), 1, 1 },  /* EMA_D[3] */
+   { pinmux(14), 1, 2 },  /* EMA_D[4] */
+   { pinmux(14), 1, 3 },  /* EMA_D[5] */
+   { pinmux(14), 1, 4 },  /* EMA_D[6] */
+   { pinmux(14), 1, 5 },  /* EMA_D[7] */
+   { pinmux(14), 1, 6 },  /* EMA_D[8] */
+   { pinmux(14), 1, 7 },  /* EMA_D[9] */
+   { pinmux(15), 1, 0 },  /* EMA_D[10] */
+   { pinmux(15), 1, 1 },  /* EMA_D[11] */
+   { pinmux(15), 1, 2 },  /* EMA_D[12] */
+   { pinmux(15), 1, 3 },  /* EMA_D[13] */
+   { pinmux(15), 1, 4 },  /* EMA_D[14] */
+   { pinmux(15), 1, 5 },  /* EMA_D[15] */
+   { pinmux(15), 1, 6 },  /* EMA_A[0] */
+   { pinmux(15), 1, 7 },  /* EMA_A[1] */
+   { pinmux(16), 1, 0 },  /* EMA_A[2] */
+   { pinmux(16), 1, 1 },  /* EMA_A[3] */
+   { pinmux(16), 1, 2 },  /* EMA_A[4] */
+   { pinmux(16), 1, 3 },  /* EMA_A[5] */
+   { pinmux(16), 1, 4 },  /* EMA_A[6] */
+   { pinmux(16), 1, 5 },  /* EMA_A[7] */
+   { pinmux(16), 1, 6 },  /* EMA_A[8] */
+   { pinmux(16), 1, 7 },  /* EMA_A[9] */
+   { pinmux(17), 1, 0 },  /* EMA_A[10] */
+

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

Dear Stephen,

In message 51a6df7c.30...@wwwdotorg.org you wrote:

 It seems to be aimed specifically at enabling use of new dtc features
 when present. That seems to be specifically against Wolfgang's goal of
 not requiring new dtc features. There's no point allowing use of new dtc

Please stop planting statements on me that I did not make.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
They're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it. - Terry Pratchett, _Wyrd Sisters_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Andrew Gabbasov

The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
(shifted and or'ed with chip select), so it's incorrect to pass
that macro directly as an argument to gpio_direction_output() call.
The gpio number should be extracted (shifted back) before that.

Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
 board/boundary/nitrogen6x/nitrogen6x.c|2 +-
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
b/board/boundary/nitrogen6x/nitrogen6x.c
index cc071d6..b588ac2 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -342,7 +342,7 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
 
 void setup_spi(void)
 {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
+   gpio_direction_output(CONFIG_SF_DEFAULT_CS  8, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
 }
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 9f9cac8..8b71e03 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -312,7 +312,7 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
 
 void setup_spi(void)
 {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
+   gpio_direction_output(CONFIG_SF_DEFAULT_CS  8, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
 }
-- 
1.7.10.4

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

Re: [U-Boot] fopen/fwrite functions

2013-05-30 Thread TigerLiu

Dear Denk:
U-boot supports FAT file system.
So, i want to read/write a file in USB disk (formatted with fat file system).
So, could i use fopen/fwrite functions?

Best wishes,

-邮件原件-
发件人: Wolfgang Denk [mailto:w...@denx.de] 
发送时间: 2013年5月30日 15:50
收件人: Tiger Liu
抄送: u-boot@lists.denx.de
主题: Re: [U-Boot] fopen/fwrite functions

Dear tiger...@viatech.com.cn,

In message fe7aded5c2218b4786c09cd97dc4c49f8db...@exchbj02.viatech.com.bj you 
wrote:

 Could i use fopen/fwrite standard C lib functions in U-boot code?

What for?  We do not even have a concept of files in U-Boot...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Any time things appear to be going better, you have overlooked  some-
thing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] In U-Boot-2013-01, __stringify is not working

2013-05-30 Thread Balaji N

In U-Boot-2013-01 version  P3041 board, __stringify is not working.
Enabled the DEBUG mode and got the output as:

*** Warning - bad CRC, using default environment

Destroy Hash Table: 3ffa9b90 table = 
Create Hash Table: N=221
INSERT: table 3ffa9b90, filled 1/223 rv 3fe2f858 == name=bootcmd
value=setenv bootargs root=/dev/$bdev rw console=$consoledev,$baudrate $o
INSERT: table 3ffa9b90, filled 2/223 rv 3fe2eef8 == name=ramboot
value=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $oth
INSERT: table 3ffa9b90, filled 3/223 rv 3fe2f2f4 == name=nfsboot
value=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ip
Bad trap at PC: 3ff7efc8, SR: 21200, vector=d00
NIP: 3FF7EFC8 XER: 2000 LR: 3FF7F03C REGS: 3fe2bd30 TRAP: 0d00 DAR:
61646486
MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00:  3FE2BE20 3FE2DF30 013E 000A  

GPR08:  3FE2E5A8 FF0D 3FE2BE20 42002042 CB3D6461 
3FE2E59C
GPR16: 3FE2E5A6 3FFA0651 3FFA0669 3FFA06C7 3FFA0696  
3FE2BE30
GPR24:  3FE2E820 3FE2E338 3FE2E5A9  3FFA9B90 3FFA5280
61646472
Call backtrace:
3FF7F03C DEADBEEF
Exception in kernel pc 3ff7efc8 signal 0
### ERROR ### Please RESET the board ###

In file include/env_default.h,

the environment variable is defines as:

#ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
env_t environment __PPCENV__ = {
ENV_CRC,/* CRC Sum */
#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
1,  /* Flags: valid */
#endif
{
#elif defined(DEFAULT_ENV_INSTANCE_STATIC)
static char default_environment[] = {
#else
const uchar default_environment[] = {
#endif
#ifdef  CONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR = CONFIG_ENV_CALLBACK_LIST_DEFAULT \0
#endif
#ifdef  CONFIG_ENV_FLAGS_LIST_DEFAULT
ENV_FLAGS_VAR = CONFIG_ENV_FLAGS_LIST_DEFAULT \0
#endif
#ifdef  CONFIG_BOOTARGS
bootargs= CONFIG_BOOTARGS \0
#endif
#ifdef  CONFIG_BOOTCOMMAND
bootcmd=  CONFIG_BOOTCOMMAND  \0
#endif
#ifdef  CONFIG_RAMBOOTCOMMAND
ramboot=  CONFIG_RAMBOOTCOMMAND   \0
#endif
#ifdef  CONFIG_NFSBOOTCOMMAND
nfsboot=  CONFIG_NFSBOOTCOMMAND   \0
#endif
#if defined(CONFIG_BOOTDELAY)  (CONFIG_BOOTDELAY = 0)
bootdelay=__stringify(CONFIG_BOOTDELAY)   \0
#endif
#if defined(CONFIG_BAUDRATE)  (CONFIG_BAUDRATE = 0)
baudrate= __stringify(CONFIG_BAUDRATE)\0
#endif

For first 3 environment variable, it is working fine. When it reaches the
environment variable
bootdelay=__stringify(CONFIG_BOOTDELAY)   \0

it gets corrupted.

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

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Dirk Behme


On 30.05.2013 12:02, Andrew Gabbasov wrote:

The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
(shifted and or'ed with chip select), so it's incorrect to pass
that macro directly as an argument to gpio_direction_output() call.
The gpio number should be extracted (shifted back) before that.

Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
  board/boundary/nitrogen6x/nitrogen6x.c|2 +-
  board/freescale/mx6qsabrelite/mx6qsabrelite.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
b/board/boundary/nitrogen6x/nitrogen6x.c
index cc071d6..b588ac2 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -342,7 +342,7 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
+   gpio_direction_output(CONFIG_SF_DEFAULT_CS  8, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
  }
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 9f9cac8..8b71e03 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -312,7 +312,7 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
+   gpio_direction_output(CONFIG_SF_DEFAULT_CS  8, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
  }


To my understanding, above change is correct, but not complete ;)

The question is why has it worked with the wrong setting and nobody 
ever noticed that its wrong?


To my understanding the answer is because the SPI driver does it 
correctly:


http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=5bed858787f610a9c9a46bb2214665a51d60a9e9;hb=refs/heads/master#l376

So IMHO the gpio_direction_output() above can be removed completely.

Best regards

Dirk



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

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Gabbasov, Andrew

Hi Dirk,

 From: Behme, Dirk - Bosch
 Sent: Thursday, May 30, 2013 14:50
 To: Gabbasov, Andrew
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio 
 number in SF chip select

[skipped]

 To my understanding, above change is correct, but not complete ;)

 The question is why has it worked with the wrong setting and nobody
 ever noticed that its wrong?

 To my understanding the answer is because the SPI driver does it
 correctly:

 http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=5bed858787f610a9c9a46bb2214665a51d60a9e9;hb=refs/heads/master#l376

 So IMHO the gpio_direction_output() above can be removed completely.

 Best regards

 Dirk

Yes, the SPI driver correctly activates and deactivates the CS signal.
But before the first activation it relies on what signal state was set before 
that.
Setting it early at startup just adds some confidence that we have correct
(inactive) chip select state before the first activation by SPI driver.
Otherwise we have to rely on particular pad configuration (e.g. EIM_D19).
I understand, that we set its configuration to pull-up (and this is also
the reset default), and if we do nothing here, it will be recognized as high.
But in order to make sure, it's more safe to explicitly set the signal to 1.

Thanks.

Best regards,
Andrew

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

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Dirk Behme

On 30.05.2013 13:32, Gabbasov, Andrew wrote:

Hi Dirk,

From: Behme, Dirk - Bosch
Sent: Thursday, May 30, 2013 14:50
To: Gabbasov, Andrew
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio 
number in SF chip select

[skipped]

To my understanding, above change is correct, but not complete ;)

The question is why has it worked with the wrong setting and nobody
ever noticed that its wrong?

To my understanding the answer is because the SPI driver does it
correctly:

http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=5bed858787f610a9c9a46bb2214665a51d60a9e9;hb=refs/heads/master#l376

So IMHO the gpio_direction_output() above can be removed completely.

Best regards

Dirk

Yes, the SPI driver correctly activates and deactivates the CS signal.
But before the first activation it relies on what signal state was set before 
that.
Setting it early at startup just adds some confidence that we have correct
(inactive) chip select state before the first activation by SPI driver.
Otherwise we have to rely on particular pad configuration (e.g. EIM_D19).
I understand, that we set its configuration to pull-up (and this is also
the reset default), and if we do nothing here, it will be recognized as high.
But in order to make sure, it's more safe to explicitly set the signal to 1.

Hmm, what's 'unsure' in the time between calling setup_spi() the first 
time and calling spi_setup_slave() the first time?

Are they even called in this order? How long is the time between these 
two calls? What's 'unsafe' in this time frame? Why isn't it unsafe 
_until_ setup_spi() is called, then?

Best regards

Dirk

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

[U-Boot] [PATCH V2 0/4] ARM: OMAP2+: Misc Cleanup

Misc cleanup.
And also adding a Generic bus init and write functions
for PMIC.
This series is applied on top of u-boot-ti:
git://git.denx.de/u-boot-ti.git

Testing:
Boot tested on OMAP5432 ES2.0, OMAP4460 PANDA.
Verified MAKEALL for armv7/omap boards.

Changes from v1:
* Created new patch for renaming arch-omap*/clocks.h to
  arch-omap*/clock.h

Lokesh Vutla (3):
  ARM: OMAP4+: Cleanup header files
  ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.h
  ARM: OMAP4+: pmic: Make generic bus init and write functions

Sricharan R (1):
  ARM: OMAP5: clocks: Do not enable sgx clocks

 arch/arm/cpu/armv7/omap-common/clocks-common.c |8 ++---
 arch/arm/cpu/armv7/omap-common/emif-common.c   |2 +-
 arch/arm/cpu/armv7/omap-common/vc.c|   14 -
 arch/arm/cpu/armv7/omap3/clock.c   |2 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |   13 ++--
 arch/arm/cpu/armv7/omap4/prcm-regs.c   |3 ++
 arch/arm/cpu/armv7/omap5/hw_data.c |   11 +++
 arch/arm/cpu/armv7/omap5/hwinit.c  |2 +-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |2 ++
 .../asm/arch-omap24xx/{clocks.h = clock.h}|0
 .../include/asm/arch-omap3/{clocks.h = clock.h}   |0
 .../include/asm/arch-omap4/{clocks.h = clock.h}   |   28 --
 arch/arm/include/asm/arch-omap4/cpu.h  |   12 
 arch/arm/include/asm/arch-omap4/omap.h |   14 -
 arch/arm/include/asm/arch-omap4/sys_proto.h|4 +--
 .../include/asm/arch-omap5/{clocks.h = clock.h}   |   22 --
 arch/arm/include/asm/arch-omap5/cpu.h  |   12 
 arch/arm/include/asm/arch-omap5/omap.h |   31 +---
 arch/arm/include/asm/arch-omap5/sys_proto.h|6 ++--
 arch/arm/include/asm/omap_common.h |7 +++--
 board/htkw/mcx/mcx.c   |2 +-
 board/teejet/mt_ventoux/mt_ventoux.c   |2 +-
 board/ti/omap2420h4/lowlevel_init.S|2 +-
 board/ti/omap2420h4/mem.c  |2 +-
 board/ti/omap5_uevm/evm.c  |   12 +---
 board/ti/panda/panda.c |   22 --
 board/ti/sdp4430/sdp.c |   16 ++
 drivers/usb/musb/omap3.c   |4 ++-
 28 files changed, 87 insertions(+), 168 deletions(-)
 rename arch/arm/include/asm/arch-omap24xx/{clocks.h = clock.h} (100%)
 rename arch/arm/include/asm/arch-omap3/{clocks.h = clock.h} (100%)
 rename arch/arm/include/asm/arch-omap4/{clocks.h = clock.h} (90%)
 rename arch/arm/include/asm/arch-omap5/{clocks.h = clock.h} (90%)

-- 
1.7.9.5

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

[U-Boot] [PATCH V2 1/4] ARM: OMAP4+: Cleanup header files

After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap4/prcm-regs.c |3 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c |2 ++
 arch/arm/include/asm/arch-omap4/clocks.h |   28 ---
 arch/arm/include/asm/arch-omap4/cpu.h|   12 
 arch/arm/include/asm/arch-omap4/omap.h   |   14 --
 arch/arm/include/asm/arch-omap5/clocks.h |   22 -
 arch/arm/include/asm/arch-omap5/cpu.h|   12 
 arch/arm/include/asm/arch-omap5/omap.h   |   31 +-
 arch/arm/include/asm/omap_common.h   |4 +---
 board/ti/omap5_uevm/evm.c|   12 
 board/ti/panda/panda.c   |   20 +++
 board/ti/sdp4430/sdp.c   |   16 +--
 drivers/usb/musb/omap3.c |4 +++-
 13 files changed, 40 insertions(+), 140 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/prcm-regs.c 
b/arch/arm/cpu/armv7/omap4/prcm-regs.c
index 7225a30..7e71ca0 100644
--- a/arch/arm/cpu/armv7/omap4/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap4/prcm-regs.c
@@ -301,6 +301,8 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_ldosram_iva_voltage_ctrl   = 0x4A002320,
.control_ldosram_mpu_voltage_ctrl   = 0x4A002324,
.control_ldosram_core_voltage_ctrl  = 0x4A002328,
+   .control_usbotghs_ctrl  = 0x4A00233C,
+   .control_padconf_core_base  = 0x4A10,
.control_pbiaslite  = 0x4A100600,
.control_lpddr2io1_0= 0x4A100638,
.control_lpddr2io1_1= 0x4A10063C,
@@ -312,4 +314,5 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_lpddr2io2_3= 0x4A100654,
.control_efuse_1= 0x4A100700,
.control_efuse_2= 0x4A100704,
+   .control_padconf_wkup_base  = 0x4A31E000,
 };
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..db779f2 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -311,6 +311,7 @@ struct prcm_regs const omap5_es1_prcm = {
 
 struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
+   .control_padconf_core_base  = 0x4A002800,
.control_paconf_global  = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
.control_smart1io_padconf_0 = 0x4A002DA8,
@@ -358,6 +359,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_port_emif2_sdram_config= 0x4AE0C118,
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
+   .control_padconf_wkup_base  = 0x4AE0C800,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
.control_padconf_mode   = 0x4AE0CDA8,
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h 
b/arch/arm/include/asm/arch-omap4/clocks.h
index ed7a1c8..f544edf 100644
--- a/arch/arm/include/asm/arch-omap4/clocks.h
+++ b/arch/arm/include/asm/arch-omap4/clocks.h
@@ -34,25 +34,6 @@
  */
 #define LDELAY 100
 
-#define CM_CLKMODE_DPLL_CORE   0x4A004120
-#define CM_CLKMODE_DPLL_PER0x4A008140
-#define CM_CLKMODE_DPLL_MPU0x4A004160
-#define CM_CLKSEL_CORE 0x4A004100
-
-/* DPLL register offsets */
-#define CM_CLKMODE_DPLL0
-#define CM_IDLEST_DPLL 0x4
-#define CM_AUTOIDLE_DPLL   0x8
-#define CM_CLKSEL_DPLL 0xC
-#define CM_DIV_M2_DPLL 0x10
-#define CM_DIV_M3_DPLL 0x14
-#define CM_DIV_M4_DPLL 0x18
-#define CM_DIV_M5_DPLL 0x1C
-#define CM_DIV_M6_DPLL 0x20
-#define CM_DIV_M7_DPLL 0x24
-
-#define DPLL_CLKOUT_DIV_MASK   0x1F /* post-divider mask */
-
 /* CM_DLL_CTRL */
 #define CM_DLL_CTRL_OVERRIDE_SHIFT 0
 #define CM_DLL_CTRL_OVERRIDE_MASK  (1  0)
@@ -94,8 +75,6 @@
 #define CM_CLKSEL_DCC_EN_SHIFT 22
 #define CM_CLKSEL_DCC_EN_MASK  (1  22)
 
-#define OMAP4_DPLL_MAX_N   127
-
 /* CM_SYS_CLKSEL */
 #define CM_SYS_CLKSEL_SYS_CLKSEL_MASK  7
 
@@ -181,9 +160,7 @@
 #define MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK   (1  25)
 
 /* Clock frequencies */
-#define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840
 #define OMAP_SYS_CLK_IND_38_4_MHZ  6
-#define OMAP_32K_CLK_FREQ  32768
 
 /* PRM_VC_VAL_BYPASS */
 #define PRM_VC_I2C_CHANNEL_FREQ_KHZ400
@@ -234,11 +211,6 @@
 
 #define ALTCLKSRC_MODE_ACTIVE  1
 
-/* Defines for DPLL setup */
-#define

[U-Boot] [PATCH V2 2/4] ARM: OMAP5: clocks: Do not enable sgx clocks

From: Sricharan R r.sricha...@ti.com

SGX clocks should be enabled only for OMAP5 ES1.0.
So this can be removed.

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap5/hw_data.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 604fa42..842cf27 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -383,12 +383,6 @@ void enable_basic_clocks(void)
 clk_modules_explicit_en_essential,
 1);
 
-   /* Select 384Mhz for GPU as its the POR for ES1.0 */
-   setbits_le32((*prcm)-cm_sgx_sgx_clkctrl,
-   CLKSEL_GPU_HYD_GCLK_MASK);
-   setbits_le32((*prcm)-cm_sgx_sgx_clkctrl,
-   CLKSEL_GPU_CORE_GCLK_MASK);
-
/* Enable SCRM OPT clocks for PER and CORE dpll */
setbits_le32((*prcm)-cm_wkupaon_scrm_clkctrl,
OPTFCLKEN_SCRM_PER_MASK);
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 3/4] ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.h

To be consistent with other ARM platforms,
renaming asm/arch-omap*/clocks.h to asm/arch-omap*/clock.h

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |2 +-
 arch/arm/cpu/armv7/omap-common/emif-common.c   |2 +-
 arch/arm/cpu/armv7/omap3/clock.c   |2 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
 arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
 arch/arm/cpu/armv7/omap5/hwinit.c  |2 +-
 .../asm/arch-omap24xx/{clocks.h = clock.h}|0
 .../include/asm/arch-omap3/{clocks.h = clock.h}   |0
 .../include/asm/arch-omap4/{clocks.h = clock.h}   |0
 arch/arm/include/asm/arch-omap4/sys_proto.h|2 +-
 .../include/asm/arch-omap5/{clocks.h = clock.h}   |0
 arch/arm/include/asm/arch-omap5/sys_proto.h|4 ++--
 board/htkw/mcx/mcx.c   |2 +-
 board/teejet/mt_ventoux/mt_ventoux.c   |2 +-
 board/ti/omap2420h4/lowlevel_init.S|2 +-
 board/ti/omap2420h4/mem.c  |2 +-
 board/ti/panda/panda.c |2 +-
 17 files changed, 14 insertions(+), 14 deletions(-)
 rename arch/arm/include/asm/arch-omap24xx/{clocks.h = clock.h} (100%)
 rename arch/arm/include/asm/arch-omap3/{clocks.h = clock.h} (100%)
 rename arch/arm/include/asm/arch-omap4/{clocks.h = clock.h} (100%)
 rename arch/arm/include/asm/arch-omap5/{clocks.h = clock.h} (100%)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 99910cd..e5c95db 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -32,7 +32,7 @@
 #include common.h
 #include asm/omap_common.h
 #include asm/gpio.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/arch/sys_proto.h
 #include asm/utils.h
 #include asm/omap_gpio.h
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 11e830a..8823967 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -27,7 +27,7 @@
 
 #include common.h
 #include asm/emif.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/arch/sys_proto.h
 #include asm/omap_common.h
 #include asm/utils.h
diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c
index 09c51f6..81cc859 100644
--- a/arch/arm/cpu/armv7/omap3/clock.c
+++ b/arch/arm/cpu/armv7/omap3/clock.c
@@ -27,7 +27,7 @@
 
 #include common.h
 #include asm/io.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/arch/clocks_omap3.h
 #include asm/arch/mem.h
 #include asm/arch/sys_proto.h
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 06a2fc8..650319a 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -29,7 +29,7 @@
 #include asm/arch/omap.h
 #include asm/arch/sys_proto.h
 #include asm/omap_common.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/omap_gpio.h
 #include asm/io.h
 
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 842cf27..d2f5900 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -29,7 +29,7 @@
 #include asm/arch/omap.h
 #include asm/arch/sys_proto.h
 #include asm/omap_common.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/omap_gpio.h
 #include asm/io.h
 #include asm/emif.h
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index e192fea..afb7000 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -32,7 +32,7 @@
 #include asm/armv7.h
 #include asm/arch/cpu.h
 #include asm/arch/sys_proto.h
-#include asm/arch/clocks.h
+#include asm/arch/clock.h
 #include asm/sizes.h
 #include asm/utils.h
 #include asm/arch/gpio.h
diff --git a/arch/arm/include/asm/arch-omap24xx/clocks.h 
b/arch/arm/include/asm/arch-omap24xx/clock.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap24xx/clocks.h
rename to arch/arm/include/asm/arch-omap24xx/clock.h
diff --git a/arch/arm/include/asm/arch-omap3/clocks.h 
b/arch/arm/include/asm/arch-omap3/clock.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap3/clocks.h
rename to arch/arm/include/asm/arch-omap3/clock.h
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h 
b/arch/arm/include/asm/arch-omap4/clock.h
similarity index 100%
rename from arch/arm/include/asm/arch-omap4/clocks.h
rename to arch/arm/include/asm/arch-omap4/clock.h
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 039a1f2..1644ba6 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -22,7 +22,7 @@
 #define

[U-Boot] [PATCH V2 4/4] ARM: OMAP4+: pmic: Make generic bus init and write functions

Voltage scaling can be done in two ways:
- Using SR I2C
- Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |6 ++
 arch/arm/cpu/armv7/omap-common/vc.c|   14 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |   11 ++-
 arch/arm/cpu/armv7/omap5/hw_data.c |3 +++
 arch/arm/include/asm/arch-omap4/sys_proto.h|2 +-
 arch/arm/include/asm/arch-omap5/sys_proto.h|2 +-
 arch/arm/include/asm/omap_common.h |3 +++
 7 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index e5c95db..a1ada58 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -487,6 +487,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
 
+   pmic-pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic-gpio_en)
ret = gpio_request(pmic-gpio, PMIC_GPIO);
@@ -509,8 +510,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
debug(do_scale_vcore: volt - %d offset_code - 0x%x\n, volt_mv,
offset_code);
 
-   if (omap_vc_bypass_send_value(SMPS_I2C_SLAVE_ADDR,
-   vcore_reg, offset_code))
+   if (pmic-pmic_write(pmic-i2c_slave_addr, vcore_reg, offset_code))
printf(Scaling voltage failed for 0x%x\n, vcore_reg);
 
if (pmic-gpio_en)
@@ -525,8 +525,6 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
-
do_scale_vcore(vcores-core.addr, vcores-core.value,
  vcores-core.pmic);
 
diff --git a/arch/arm/cpu/armv7/omap-common/vc.c 
b/arch/arm/cpu/armv7/omap-common/vc.c
index e6e5f78..a68f1d1 100644
--- a/arch/arm/cpu/armv7/omap-common/vc.c
+++ b/arch/arm/cpu/armv7/omap-common/vc.c
@@ -17,6 +17,7 @@
 #include common.h
 #include asm/omap_common.h
 #include asm/arch/sys_proto.h
+#include asm/arch/clock.h
 
 /*
  * Define Master code if there are multiple masters on the I2C_SR bus.
@@ -57,7 +58,7 @@
  * omap_vc_init() - Initialization for Voltage controller
  * @speed_khz: I2C buspeed in KHz
  */
-void omap_vc_init(u16 speed_khz)
+static void omap_vc_init(u16 speed_khz)
 {
u32 val;
u32 sys_clk_khz, cycles_hi, cycles_low;
@@ -137,3 +138,14 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 
reg_data)
/* All good.. */
return 0;
 }
+
+void sri2c_init(void)
+{
+   static int sri2c = 1;
+
+   if (sri2c) {
+   omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
+   sri2c = 0;
+   }
+   return;
+}
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 650319a..b97cad4 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -219,6 +219,9 @@ struct pmic_data twl6030_4430es1 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct pmic_data twl6030 = {
@@ -226,6 +229,9 @@ struct pmic_data twl6030 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct pmic_data tps62361 = {
@@ -233,7 +239,10 @@ struct pmic_data tps62361 = {
.step = 1, /* 10 mV represented in uV */
.start_code = 0,
.gpio = TPS62361_VSEL0_GPIO,
-   .gpio_en = 1
+   .gpio_en = 1,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct vcores_data omap4430_volts_es1 = {
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index d2f5900..585e318 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -289,6 +289,9 @@ struct pmic_data palmas = {
 * Offset code 0 switches OFF the SMPS
 */
.start_code = 6,
+   .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = sri2c_init,
+   .pmic_write = omap_vc_bypass_send_value,
 };
 
 struct vcores_data omap5430_volts = {
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index

Re: [U-Boot] fopen/fwrite functions

Dear tiger...@viatech.com.cn,

please do not top post / full quote.  See [1] if you need help.

[1] http://www.netmeister.org/news/learn2quote.html


In message fe7aded5c2218b4786c09cd97dc4c49f8db...@exchbj02.viatech.com.bj you 
wrote:

 U-boot supports FAT file system.

Yes, it does.  And it supports commands to access these.

 So, i want to read/write a file in USB disk (formatted with fat file
 system).
 So, could i use fopen/fwrite functions?

No, you cannot.

As I mentioned before: We do not even have a concept of files in
U-Boot.  Operations like fopen/fwrite make only sense when you always
have an underlying file system (like the root file system in Unix
systems).  We don't have that, and so we have no functions like
fopen() or open() etc.

To read a file from a FAT file system, you have to use the file system
specific access code, in this case do_fat_fsload() resp. do_load()

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Conflict resolution for u-boot-arm/master and u-boot/master merge

Hello Tom and Bo,

While preparing for my ARM PR, I have encountered two merge conflicts.
Their resolution can be found in branch 'merge_from_mainline' of ARM
repo git://git.denx.de/u-boot-arm.

For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
renaming fit somehow caused a need for manual resolution just to
select the version with the right name. Simon, can you confirm that my
resolution is correct?

For drivers/usb/host/ohci-at91.c, the conflicting commits are both from
Bo, respectively 158947d2 (committed by Marek) and e5e8bb05 (commited
by Andreas). Bo, can you confirm that my resolution is correct?

If both resolutions are correct, then at Tom's discretion, either I'll
move my master there and submit what should then be a fast-forward PR,
or I'll submit current master and Tom will replay my resolutions when
doing his merge. Tom, your preference?

Thanks in advance to all!

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

Re: [U-Boot] Conflict resolution for u-boot-arm/master and u-boot/master merge

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/30/2013 08:55 AM, Albert ARIBAUD wrote:
 Hello Tom and Bo,
 
 While preparing for my ARM PR, I have encountered two merge 
 conflicts. Their resolution can be found in branch 
 'merge_from_mainline' of ARM repo git://git.denx.de/u-boot-arm.
 
 For common/cmd_fpga.c, the merge conflict was trivial -- Simon's 
 renaming fit somehow caused a need for manual resolution just to 
 select the version with the right name. Simon, can you confirm
 that my resolution is correct?
 
 For drivers/usb/host/ohci-at91.c, the conflicting commits are both 
 from Bo, respectively 158947d2 (committed by Marek) and e5e8bb05 
 (commited by Andreas). Bo, can you confirm that my resolution is 
 correct?
 
 If both resolutions are correct, then at Tom's discretion, either 
 I'll move my master there and submit what should then be a 
 fast-forward PR, or I'll submit current master and Tom will replay 
 my resolutions when doing his merge. Tom, your preference?

I'm OK with a fastforward, thanks.

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

iQIcBAEBAgAGBQJRp04LAAoJENk4IS6UOR1WBtIP/RmA/DT/5ctxeQAf5Z87sPEC
bNp5hzRAcjuHmbaCWwEaPjgxuBjbsoAqvpwl+mPBvlzdd71ORQrR90pahH367Mtf
HthU0a9S5CIWNz92j16yqO1HKe6CyJKV3Zyu/g5jIjW4hPcddg173ZLJIbHIcZUg
86G8/A3lSHKBZa3ywYfft1O+AHHdB0lN4jvI8gV0TxBB4X411G5xqpYHV74ypt9y
gryH+WoeJxJK7jVLHZihZKHBLG7MAlJQXkGO+ughAmI2qRA2OMQuqVocYnwc88Kf
NEl7Sn+FcgoO3u+CQ5h97KqNo8i5jX68gbjX68+sLnkP0pT1ZfhhnyQLmoxaF2v7
HIgzuIJPpV8hfaexdZMAsRDNqTmLH++jKwjRIX0Q56I8faS3NgchzASOJOu4+6Ts
r8hED5gtSTmjpNwDHbzVlVafzevrp/46yXB68BeP/Dh0YqSxaj2v/0upuN98JSVZ
APJfkMIFF4CvSsCVmyekOljTRRKytsntJyVIMb6x0aVVPZvdkrj7mfHzdQel8egk
NE9zAwZ15PEmlgvntIyIoFc95s1TStgay+thUhk7NrvhMU6IyccXLk42tcQR92d6
LkkVNv3weWApp5nm9RIJZ47E3kl+Ijh2RtJ6P4OLek3KzjcrQv/PIQTTqLR4WAmX
9V2vIYVjkLWLU+8fBuwY
=Gc0L
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] In U-Boot-2013-01, __stringify is not working

Dear Balaji N,

In message caf8ym8presb4fjrnunmhgjgmq_zquakgf_cfpbqg+hpotev...@mail.gmail.com 
you wrote:
 
 In U-Boot-2013-01 version  P3041 board, __stringify is not working.
 Enabled the DEBUG mode and got the output as:
 
 *** Warning - bad CRC, using default environment
 
 Destroy Hash Table: 3ffa9b90 table = 
 Create Hash Table: N=221
 INSERT: table 3ffa9b90, filled 1/223 rv 3fe2f858 == name=bootcmd
 value=setenv bootargs root=/dev/$bdev rw console=$consoledev,$baudrate $o
 INSERT: table 3ffa9b90, filled 2/223 rv 3fe2eef8 == name=ramboot
 value=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $oth
 INSERT: table 3ffa9b90, filled 3/223 rv 3fe2f2f4 == name=nfsboot
 value=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ip
 Bad trap at PC: 3ff7efc8, SR: 21200, vector=d00
...

 For first 3 environment variable, it is working fine. When it reaches the

Is it, really?  To me the variable values look pretty much truncated 
after exactly 67 characters.

 environment variable
 bootdelay=__stringify(CONFIG_BOOTDELAY)   \0
 
 it gets corrupted.

What makes you think so?  If I look at the strings in the compiles
image (using for example strings -a u-boot.bin), I see:

...
bootcmd=setenv bootargs root=/dev/$bdev rw console=$consoledev,$baudrate 
$othbootargs;tftp $loadaddr 
$bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate 
$othbootargs;tftp $ramdiskaddr 
$ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr 
$ramdiskaddr $fdtaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath 
ip=$ipaddr:$serverip:$gatewayip:$
netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp 
$loadaddr $bootfile;tftp
 $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
bootdelay=10
baudrate=115200
...

All these values look perfectly fine for me, and __stringify has
worked fine for bootdelay, too.


Your problem must be caused by something else. If I were you I would
fire up the debugger and check why the values of bootcmd, ramboot,
and nfsboot are truncated after exactly 67 characters.

There appears to be a problem ealier in the code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every program has at least one bug and can be shortened by  at  least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 01/12] ARM: DRA7xx: Add control id code for DRA7xx

The registers that are used for device identification
are changed from OMAP5 to DRA7xx.
Using the correct registers for DRA7xx.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/include/asm/arch-omap5/omap.h |   11 +--
 include/configs/dra7xx_evm.h   |3 ++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 6dfedf4..3222996 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -44,8 +44,15 @@
 #define DRAM_ADDR_SPACE_START  OMAP54XX_DRAM_ADDR_SPACE_START
 #define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END
 
-/* CONTROL_ID_CODE */
-#define CONTROL_ID_CODE0x4A002204
+/* CONTROL ID CODE */
+#define CONTROL_CORE_ID_CODE   0x4A002204
+#define CONTROL_WKUP_ID_CODE   0x4AE0C204
+
+#ifdef CONFIG_DRA7XX
+#define CONTROL_ID_CODECONTROL_WKUP_ID_CODE
+#else
+#define CONTROL_ID_CODECONTROL_CORE_ID_CODE
+#endif
 
 /* To be verified */
 #define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..7826d13 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -28,11 +28,12 @@
 #ifndef __CONFIG_DRA7XX_EVM_H
 #define __CONFIG_DRA7XX_EVM_H
 
+/* High Level Configuration Options */
+#define CONFIG_DRA7XX  /* in a TI DRA7XX core */
 #define CONFIG_ENV_IS_NOWHERE  /* For now. */
 
 #include configs/omap5_common.h
 
-#define CONFIG_DRA7XX  /* in a TI DRA7XX core */
 #define CONFIG_SYS_PROMPT  DRA752 EVM # 
 
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 06/12] ARM: DRA7xx: Change the Debug UART to UART1

From: Sricharan R r.sricha...@ti.com

Serial UART is connected to UART1. So add the change
for the same.

Signed-off-by: Sricharan R r.sricha...@ti.com
---
 include/configs/dra7xx_evm.h   |3 +++
 include/configs/omap5_common.h |4 
 include/configs/omap5_uevm.h   |4 
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 7826d13..35dec08 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -36,4 +36,7 @@
 
 #define CONFIG_SYS_PROMPT  DRA752 EVM # 
 
+#define CONFIG_CONS_INDEX  1
+#define CONFIG_SYS_NS16550_COM1UART1_BASE
+#define CONFIG_BAUDRATE115200
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..d57c0da 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -81,10 +81,6 @@
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-#define CONFIG_CONS_INDEX  3
-#define CONFIG_SYS_NS16550_COM3UART3_BASE
-
-#define CONFIG_BAUDRATE115200
 
 /* CPU */
 #define CONFIG_ARCH_CPU_INIT
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index c791789..ba81e30 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -35,6 +35,10 @@
 
 #include configs/omap5_common.h
 
+#define CONFIG_CONS_INDEX  3
+#define CONFIG_SYS_NS16550_COM3UART3_BASE
+#define CONFIG_BAUDRATE115200
+
 /* TWL6035 */
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_PALMAS_POWER
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 05/12] ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's

Slew rate compensation cells are not present for DRA7xx
Soc's. So return from function srcomp_enable() if soc is not
OMAP54xx.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap5/hwinit.c  |3 +++
 arch/arm/include/asm/omap_common.h |8 
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index afb7000..40dbf45 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -201,6 +201,9 @@ void srcomp_enable(void)
u32 sysclk_ind  = get_sys_clk_index();
u32 omap_rev= omap_revision();
 
+   if (!is_omap54xx())
+   return;
+
mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
div_factor = srcomp_parameters[sysclk_ind].divide_factor;
 
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 1435674..7007177 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -575,6 +575,14 @@ static inline u32 omap_revision(void)
extern u32 *const omap_si_rev;
return *omap_si_rev;
 }
+
+#define OMAP54xx   0x5400
+
+static inline u8 is_omap54xx(void)
+{
+   extern u32 *const omap_si_rev;
+   return ((*omap_si_rev  0xFF00) == OMAP54xx);
+}
 #endif
 
 /*
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

From: Balaji T K balaj...@ti.com

add dra mmc pbias support and ldo1 power on

Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/include/asm/arch-omap5/omap.h |3 ++-
 drivers/mmc/omap_hsmmc.c   |   26 ++
 drivers/power/palmas.c |   25 -
 include/configs/omap5_common.h |4 
 include/configs/omap5_uevm.h   |5 -
 include/palmas.h   |6 +-
 6 files changed, 49 insertions(+), 20 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 8105c14..9abb663 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -106,9 +106,10 @@
 /* CONTROL_EFUSE_2 */
 #define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1   0x00ffc000
 
+#define SDCARD_BIAS_PWRDNZ (1  27)
 #define SDCARD_PWRDNZ  (1  26)
 #define SDCARD_BIAS_HIZ_MODE   (1  25)
-#define SDCARD_BIAS_PWRDNZ (1  22)
+#define SDCARD_BIAS_PWRDNZ2(1  22)
 #define SDCARD_PBIASLITE_VMODE (1  21)
 
 #ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..27d1f76 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,25 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
 
value = readl((*ctrl)-control_pbias);
-   value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
+   value = ~SDCARD_PWRDNZ;
+   writel(value, (*ctrl)-control_pbias);
+   udelay(10); /* wait 10 us */
+   value = ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
 
-   palmas_mmc1_poweron_ldo();
+#if defined(CONFIG_DRA7XX)
+   palmas_mmc1_poweron_ldo1();
+#else
+   palmas_mmc1_poweron_ldo9();
+#endif
 
value = readl((*ctrl)-control_pbias);
-   value = ~SDCARD_BIAS_HIZ_MODE;
-   value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+   value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
-
-   value = readl((*ctrl)-control_pbias);
-   if (value  (1  23)) {
-   value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
-   writel(value, (*ctrl)-control_pbias);
-   }
+   udelay(150); /* wait 150 us */
+   value |= SDCARD_PWRDNZ;
+   writel(value, (*ctrl)-control_pbias);
+   udelay(150); /* wait 150 us */
 }
 #endif
 
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..1bcff52 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
return;
 }
 
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
 {
u8 val = 0;
 
@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
 
return 0;
 }
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+   u8 val = 0;
+
+   /* set LDO9 TWL6035 to 3V */
+   val = 0x2b; /* (3 - 0.9) * 20 + 1 */
+
+   if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+   printf(tps659038: could not set LDO1 voltage\n);
+   return 1;
+   }
+
+   /* TURN ON LDO9 */
+   val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+
+   if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
+   printf(tps659038: could not turn on LDO1\n);
+   return 1;
+   }
+
+   return 0;
+}
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 83b91d1..ddf2ad4 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -238,6 +238,10 @@
 #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
 #endif
 
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index ba81e30..f4a2d31 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -39,11 +39,6 @@
 #define CONFIG_SYS_NS16550_COM3UART3_BASE
 #define CONFIG_BAUDRATE115200
 
-/* TWL6035 */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_PALMAS_POWER
-#endif
-
 /* MMC ENV related defines */
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1   /* SLOT2: eMMC(1) */
diff --git a/include/palmas.h b/include/palmas.h
index 3b18589..4218e18 100644
--- a/include/palmas.h
+++ b/include/palmas.h
@@ -28,8 +28,11 @@
 
 /* I2C chip addresses */
 #define PALMAS_CHIP_ADDR   0x48
+#define TPS659038_CHIP_ADDR0x58
 
 /* 0x1XY translates to page 1, register address 0xXY */
+#define LDO1_CTRL  0x50
+#define LDO1_VOLTAGE

[U-Boot] [PATCH V2 02/12] ARM: DRA7xx: power Add support for tps659038 PMIC

TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   23 ++
 arch/arm/cpu/armv7/omap5/hw_data.c |   38 +++-
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/clock.h|   15 ++
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/omap_common.h |3 ++
 6 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index a1ada58..dc57516 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -30,6 +30,7 @@
  * MA 02111-1307 USA
  */
 #include common.h
+#include i2c.h
 #include asm/omap_common.h
 #include asm/gpio.h
 #include asm/arch/clock.h
@@ -487,6 +488,9 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
 
+   if (!volt_mv)
+   return;
+
pmic-pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic-gpio_en)
@@ -534,6 +538,15 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores-mm.addr, vcores-mm.value,
  vcores-mm.pmic);
 
+   do_scale_vcore(vcores-gpu.addr, vcores-gpu.value,
+  vcores-gpu.pmic);
+
+   do_scale_vcore(vcores-eve.addr, vcores-eve.value,
+  vcores-eve.pmic);
+
+   do_scale_vcore(vcores-iva.addr, vcores-iva.value,
+  vcores-iva.pmic);
+
 if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM magic bits */
writel(2, (*prcm)-prm_sldo_core_setup);
@@ -723,3 +736,13 @@ void prcm_init(void)
if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context())
enable_basic_uboot_clocks();
 }
+
+void gpi2c_init(void)
+{
+   static int gpi2c = 1;
+
+   if (gpi2c) {
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   gpi2c = 0;
+   }
+}
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 585e318..90274a0 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -26,6 +26,7 @@
  * MA 02111-1307 USA
  */
 #include common.h
+#include palmas.h
 #include asm/arch/omap.h
 #include asm/arch/sys_proto.h
 #include asm/omap_common.h
@@ -294,6 +295,19 @@ struct pmic_data palmas = {
.pmic_write = omap_vc_bypass_send_value,
 };
 
+struct pmic_data tps659038 = {
+   .base_offset = PALMAS_SMPS_BASE_VOLT_UV,
+   .step = 1, /* 10 mV represented in uV */
+   /*
+* Offset codes 1-6 all give the base voltage in Palmas
+* Offset code 0 switches OFF the SMPS
+*/
+   .start_code = 6,
+   .i2c_slave_addr = TPS659038_I2C_SLAVE_ADDR,
+   .pmic_bus_init  = gpi2c_init,
+   .pmic_write = palmas_i2c_write_u8,
+};
+
 struct vcores_data omap5430_volts = {
.mpu.value = VDD_MPU,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
@@ -322,6 +336,28 @@ struct vcores_data omap5430_volts_es2 = {
.mm.pmic = palmas,
 };
 
+struct vcores_data dra752_volts = {
+   .mpu.value  = VDD_MPU_DRA752,
+   .mpu.addr   = TPS659038_REG_ADDR_SMPS12_MPU,
+   .mpu.pmic   = tps659038,
+
+   .eve.value  = VDD_EVE_DRA752,
+   .eve.addr   = TPS659038_REG_ADDR_SMPS45_EVE,
+   .eve.pmic   = tps659038,
+
+   .gpu.value  = VDD_GPU_DRA752,
+   .gpu.addr   = TPS659038_REG_ADDR_SMPS6_GPU,
+   .gpu.pmic   = tps659038,
+
+   .core.value = VDD_CORE_DRA752,
+   .core.addr  = TPS659038_REG_ADDR_SMPS7_CORE,
+   .core.pmic  = tps659038,
+
+   .iva.value  = VDD_IVA_DRA752,
+   .iva.addr   = TPS659038_REG_ADDR_SMPS8_IVA,
+   .iva.pmic   = tps659038,
+};
+
 /*
  * Enable essential clock domains, modules and
  * do some additional special settings needed
@@ -562,7 +598,7 @@ void hw_data_init(void)
case DRA752_ES1_0:
*prcm = dra7xx_prcm;
*dplls_data = dra7xx_dplls;
-   *omap_vcores = omap5430_volts_es2;
+   *omap_vcores = dra752_volts;
*ctrl = dra7xx_ctrl;
break;
 
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 38d4768..14479ba 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -57,6 +57,7 @@ u32 cortex_rev(void);
 void init_omap_revision(void);
 void do_io_settings(void);
 void sri2c_init(void);
+void gpi2c_init(void);
 int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 reg_data);
 u32 warm_reset(void);

[U-Boot] [PATCH V2 04/12] ARM: OMAP5: DRA7xx: support class 0 optimized voltages

From: Nishanth Menon n...@ti.com

DRA752 now uses AVS Class 0 voltages which are voltages in efuse.

This means that we can now use the optimized voltages which are
stored as mV values in efuse and program PMIC accordingly.

This allows us to go with higher OPP as needed in the system without
the need for implementing complex AVS logic.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   58 +++-
 arch/arm/cpu/armv7/omap5/hw_data.c |   10 
 arch/arm/include/asm/arch-omap5/clock.h|   30 
 arch/arm/include/asm/omap_common.h |   11 +
 4 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 0a5bda5..64fffd3 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -521,6 +521,38 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
gpio_direction_output(pmic-gpio, 1);
 }
 
+static u32 optimize_vcore_voltage(struct volts const *v)
+{
+   u32 val;
+   if (!v-value)
+   return 0;
+   if (!v-efuse.reg)
+   return v-value;
+
+   switch (v-efuse.reg_bits) {
+   case 16:
+   val = readw(v-efuse.reg);
+   break;
+   case 32:
+   val = readl(v-efuse.reg);
+   break;
+   default:
+   printf(Error: efuse 0x%08x bits=%d unknown\n,
+  v-efuse.reg, v-efuse.reg_bits);
+   return v-value;
+   }
+
+   if (!val) {
+   printf(Error: efuse 0x%08x bits=%d val=0, using %d\n,
+  v-efuse.reg, v-efuse.reg_bits, v-value);
+   return v-value;
+   }
+
+   debug(%s:efuse 0x%08x bits=%d Vnom=%d, using efuse value %d\n,
+ __func__, v-efuse.reg, v-efuse.reg_bits, v-value, val);
+   return val;
+}
+
 /*
  * Setup the voltages for vdd_mpu, vdd_core, and vdd_iva
  * We set the maximum voltages allowed here because Smart-Reflex is not
@@ -529,23 +561,25 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   do_scale_vcore(vcores-core.addr, vcores-core.value,
- vcores-core.pmic);
+   u32 val;
+
+   val = optimize_vcore_voltage(vcores-core);
+   do_scale_vcore(vcores-core.addr, val, vcores-core.pmic);
 
-   do_scale_vcore(vcores-mpu.addr, vcores-mpu.value,
- vcores-mpu.pmic);
+   val = optimize_vcore_voltage(vcores-mpu);
+   do_scale_vcore(vcores-mpu.addr, val, vcores-mpu.pmic);
 
-   do_scale_vcore(vcores-mm.addr, vcores-mm.value,
- vcores-mm.pmic);
+   val = optimize_vcore_voltage(vcores-mm);
+   do_scale_vcore(vcores-mm.addr, val, vcores-mm.pmic);
 
-   do_scale_vcore(vcores-gpu.addr, vcores-gpu.value,
-  vcores-gpu.pmic);
+   val = optimize_vcore_voltage(vcores-gpu);
+   do_scale_vcore(vcores-gpu.addr, val, vcores-gpu.pmic);
 
-   do_scale_vcore(vcores-eve.addr, vcores-eve.value,
-  vcores-eve.pmic);
+   val = optimize_vcore_voltage(vcores-eve);
+   do_scale_vcore(vcores-eve.addr, val, vcores-eve.pmic);
 
-   do_scale_vcore(vcores-iva.addr, vcores-iva.value,
-  vcores-iva.pmic);
+   val = optimize_vcore_voltage(vcores-iva);
+   do_scale_vcore(vcores-iva.addr, val, vcores-iva.pmic);
 
 if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM magic bits */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 90274a0..bddcaed 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -338,22 +338,32 @@ struct vcores_data omap5430_volts_es2 = {
 
 struct vcores_data dra752_volts = {
.mpu.value  = VDD_MPU_DRA752,
+   .mpu.efuse.reg  = STD_FUSE_OPP_VMIN_MPU_NOM,
+   .mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr   = TPS659038_REG_ADDR_SMPS12_MPU,
.mpu.pmic   = tps659038,
 
.eve.value  = VDD_EVE_DRA752,
+   .eve.efuse.reg  = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
+   .eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr   = TPS659038_REG_ADDR_SMPS45_EVE,
.eve.pmic   = tps659038,
 
.gpu.value  = VDD_GPU_DRA752,
+   .gpu.efuse.reg  = STD_FUSE_OPP_VMIN_GPU_NOM,
+   .gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr   = TPS659038_REG_ADDR_SMPS6_GPU,
.gpu.pmic   = tps659038,
 
.core.value = VDD_CORE_DRA752,
+   .core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
+

[U-Boot] [PATCH V2 11/12] ARM: DRA7xx: clocks: Update PLL values

Update PLL values.
SYS_CLKSEL value for 20MHz is changed to 2. In other platforms
SYS_CLKSEL value 2 represents reserved. But in sys_clk array
ind 1 is used for 13Mhz. Since other platforms are not using
13Mhz, reusing index 1 for 20MHz.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |   16 ++---
 arch/arm/cpu/armv7/omap5/hw_data.c |   87 +++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |1 +
 arch/arm/include/asm/arch-omap4/clock.h|2 +-
 arch/arm/include/asm/arch-omap5/clock.h|8 ++-
 arch/arm/include/asm/omap_common.h |3 +-
 include/configs/dra7xx_evm.h   |2 +
 7 files changed, 73 insertions(+), 46 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 64fffd3..2e5a01e 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -50,13 +50,12 @@
 
 const u32 sys_clk_array[8] = {
1200,  /* 12 MHz */
-   1300,  /* 13 MHz */
+   2000,   /* 20 MHz */
1680,  /* 16.8 MHz */
1920,  /* 19.2 MHz */
2600,  /* 26 MHz */
2700,  /* 27 MHz */
3840,  /* 38.4 MHz */
-   2000,   /* 20 MHz */
 };
 
 static inline u32 __get_sys_clk_index(void)
@@ -75,13 +74,6 @@ static inline u32 __get_sys_clk_index(void)
/* SYS_CLKSEL - 1 to match the dpll param array indices */
ind = (readl((*prcm)-cm_sys_clksel) 
CM_SYS_CLKSEL_SYS_CLKSEL_MASK) - 1;
-   /*
-* SYS_CLKSEL value for 20MHz is 0. This is introduced newly
-* in DRA7XX socs. SYS_CLKSEL -1 will be greater than
-* NUM_SYS_CLK. So considering the last 3 bits as the index
-* for the dpll param array.
-*/
-   ind = CM_SYS_CLKSEL_SYS_CLKSEL_MASK;
}
return ind;
 }
@@ -441,6 +433,12 @@ static void setup_non_essential_dplls(void)
params = get_abe_dpll_params(*dplls_data);
 #ifdef CONFIG_SYS_OMAP_ABE_SYSCK
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_SYSCLK;
+
+   if (omap_revision() == DRA752_ES1_0)
+   /* Select the sys clk for dpll_abe */
+   clrsetbits_le32((*prcm)-cm_abe_pll_sys_clksel,
+   CM_CLKSEL_ABE_PLL_SYS_CLKSEL_MASK,
+   CM_ABE_PLL_SYS_CLKSEL_SYSCLK2);
 #else
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_32KCLK;
/*
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index bddcaed..44552c3 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -100,14 +100,13 @@ static const struct dpll_params 
mpu_dpll_params_499mhz[NUM_SYS_CLKS] = {
 };
 
 static const struct dpll_params mpu_dpll_params_1ghz[NUM_SYS_CLKS] = {
-   {250, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {119, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {625, 11, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {500, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {250, 2, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz   */
+   {500, 9, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 20 MHz   */
+   {119, 1, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+   {625, 11, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+   {500, 12, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 26 MHz   */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {625, 23, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 38.4 MHz */
-   {50, 0, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}  /* 20 MHz   */
+   {625, 23, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 38.4 MHz */
 };
 
 static const struct dpll_params
@@ -133,15 +132,14 @@ static const struct dpll_params
 };
 
 static const struct dpll_params
-   core_dpll_params_2128mhz_ddr532_dra7xx[NUM_SYS_CLKS] = {
-   {266, 2, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 12 MHz   */
-   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {443, 6, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 16.8 MHz */
-   {277, 4, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 19.2 MHz */
-   {368, 8, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 26 MHz   */
+   core_dpll_params_2128mhz_dra7xx[NUM_SYS_CLKS] = {
+   {266, 2, 2, 1, -1, 4, 62, 5, -1, 5, 4, 6},

[U-Boot] [PATCH V2 12/12] ARM: DRA7xx: EMIF: Change settings required for EVM board

From: Sricharan R r.sricha...@ti.com

DRA7 EVM board has the below configuration. Adding the
settings for the same here.

   2Gb_1_35V_DDR3L part * 2 on EMIF1
   2Gb_1_35V_DDR3L part * 4 on EMIF2

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/emif-common.c |   26 +++-
 arch/arm/cpu/armv7/omap5/hw_data.c   |   21 +++-
 arch/arm/cpu/armv7/omap5/hwinit.c|   19 +--
 arch/arm/cpu/armv7/omap5/prcm-regs.c |1 +
 arch/arm/cpu/armv7/omap5/sdram.c |  170 --
 arch/arm/include/asm/arch-omap5/omap.h   |1 +
 arch/arm/include/asm/emif.h  |   12 +-
 arch/arm/include/asm/omap_common.h   |1 +
 8 files changed, 220 insertions(+), 31 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 8823967..652e5a7 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -209,7 +209,8 @@ void emif_update_timings(u32 base, const struct emif_regs 
*regs)
writel(regs-temp_alert_config, emif-emif_temp_alert_config);
writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
 
-   if (omap_revision() = OMAP5430_ES1_0) {
+   if ((omap_revision() = OMAP5430_ES1_0) ||
+   (omap_revision() == DRA752_ES1_0)) {
writel(EMIF_L3_CONFIG_VAL_SYS_10_MPU_5_LL_0,
emif-emif_l3_config);
} else if (omap_revision() = OMAP4460_ES1_0) {
@@ -263,6 +264,18 @@ static void ddr3_leveling(u32 base, const struct emif_regs 
*regs)
__udelay(130);
 }
 
+static void ddr3_sw_leveling(u32 base, const struct emif_regs *regs)
+{
+   struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
+
+   writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
+   writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
+   config_data_eye_leveling_samples(base);
+
+   writel(regs-emif_rd_wr_lvl_ctl, emif-emif_rd_wr_lvl_ctl);
+   writel(regs-sdram_config, emif-emif_sdram_config);
+}
+
 static void ddr3_init(u32 base, const struct emif_regs *regs)
 {
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
@@ -273,6 +286,7 @@ static void ddr3_init(u32 base, const struct emif_regs 
*regs)
 * defined, contents of mode Registers must be fully initialized.
 * H/W takes care of this initialization
 */
+   writel(regs-sdram_config2, emif-emif_lpddr2_nvm_config);
writel(regs-sdram_config_init, emif-emif_sdram_config);
 
writel(regs-emif_ddr_phy_ctlr_1_init, emif-emif_ddr_phy_ctrl_1);
@@ -290,7 +304,10 @@ static void ddr3_init(u32 base, const struct emif_regs 
*regs)
/* enable leveling */
writel(regs-emif_rd_wr_lvl_rmp_ctl, emif-emif_rd_wr_lvl_rmp_ctl);
 
-   ddr3_leveling(base, regs);
+   if (omap_revision() == DRA752_ES1_0)
+   ddr3_sw_leveling(base, regs);
+   else
+   ddr3_leveling(base, regs);
 }
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
@@ -1078,7 +1095,10 @@ static void do_sdram_init(u32 base)
if (warm_reset()  (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
set_lpmode_selfrefresh(base);
emif_reset_phy(base);
-   ddr3_leveling(base, regs);
+   if (omap_revision() == DRA752_ES1_0)
+   ddr3_sw_leveling(base, regs);
+   else
+   ddr3_leveling(base, regs);
}
 
/* Write to the shadow registers */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 44552c3..56cf1f8 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -602,6 +602,17 @@ const struct ctrl_ioregs ioregs_omap5432_es2 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
 };
 
+const struct ctrl_ioregs ioregs_dra7xx_es1 = {
+   .ctrl_ddrch = 0x40404040,
+   .ctrl_lpddr2ch = 0x40404040,
+   .ctrl_ddr3ch = 0x80808080,
+   .ctrl_ddrio_0 = 0xbae8c631,
+   .ctrl_ddrio_1 = 0xb46318d8,
+   .ctrl_ddrio_2 = 0x8421,
+   .ctrl_emif_sdram_config_ext = 0xb2c0,
+   .ctrl_ddr_ctrl_ext_0 = 0xA200,
+};
+
 void hw_data_init(void)
 {
u32 omap_rev = omap_revision();
@@ -644,14 +655,16 @@ void get_ioregs(const struct ctrl_ioregs **regs)
case OMAP5430_ES1_0:
case OMAP5430_ES2_0:
*regs = ioregs_omap5430;
-   break;
+   break;
case OMAP5432_ES1_0:
*regs = ioregs_omap5432_es1;
-   break;
+   break;
case OMAP5432_ES2_0:
-   case DRA752_ES1_0:
*regs = ioregs_omap5432_es2;
-   break;
+   break;
+   case DRA752_ES1_0:
+   *regs = ioregs_dra7xx_es1;
+

[U-Boot] [PATCH V2 03/12] ARM: DRA7xx: clocks: Fixing i2c_init for PMIC

In DRA7xx Soc's voltage scaling is done using GPI2C.
So i2c_init should happen before scaling. I2C driver
uses __udelay which needs timer to be initialized.
So moving timer_init just before voltage scaling.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c |1 +
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index dc57516..0a5bda5 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -721,6 +721,7 @@ void prcm_init(void)
case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR:
case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH:
enable_basic_clocks();
+   timer_init();
scale_vcores(*omap_vcores);
setup_dplls();
 #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 1645120..5602b0e 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -202,8 +202,6 @@ void s_init(void)
 #endif
prcm_init();
 #ifdef CONFIG_SPL_BUILD
-   timer_init();
-
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
 #endif
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 08/12] ARM: DRA7xx: Correct SRAM END address

From: Sricharan R r.sricha...@ti.com

NON SECURE SRAM is 512KB in DRA7xx devices.
So fixing it here.

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/include/asm/arch-omap5/omap.h |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 3222996..8105c14 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -169,13 +169,14 @@ struct s32ktimer {
 #define EFUSE_4 0x45145100
 #endif /* __ASSEMBLY__ */
 
-/*
- * Non-secure SRAM Addresses
- * Non-secure RAM starts at 0x4030 for GP devices. But we keep SRAM_BASE
- * at 0x40304000(EMU base) so that our code works for both EMU and GP
- */
+#ifdef CONFIG_DRA7XX
+#define NON_SECURE_SRAM_START  0x4030
+#define NON_SECURE_SRAM_END0x4038  /* Not inclusive */
+#else
 #define NON_SECURE_SRAM_START  0x4030
 #define NON_SECURE_SRAM_END0x4032  /* Not inclusive */
+#endif
+
 /* base address for indirect vectors (internal boot mode) */
 #define SRAM_ROM_VECT_BASE 0x4031F000
 
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 10/12] ARM: DRA7xx: Update pinmux data

Updating pinmux data as specified in the latest DM

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +++--
 board/ti/dra7xx/mux_data.h   |   38 --
 2 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h 
b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
index 55e9de6..5f2b0f9 100644
--- a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
+++ b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
@@ -28,11 +28,14 @@
 
 #include asm/types.h
 
+#define FSC(1  19)
+#define SSC(0  19)
+
 #define IEN(1  18)
 #define IDIS   (0  18)
 
-#define PTU(3  16)
-#define PTD(1  16)
+#define PTU(1  17)
+#define PTD(0  17)
 #define PEN(1  16)
 #define PDIS   (0  16)
 
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 04c95fd..338a241 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -29,19 +29,29 @@
 #include asm/arch/mux_dra7xx.h
 
 const struct pad_conf_entry core_padconf_array_essential[] = {
-   {MMC1_CLK, (PTU | IEN | M0)},   /* MMC1_CLK */
-   {MMC1_CMD, (PTU | IEN | M0)},   /* MMC1_CMD */
-   {MMC1_DAT0, (PTU | IEN | M0)},  /* MMC1_DAT0 */
-   {MMC1_DAT1, (PTU | IEN | M0)},  /* MMC1_DAT1 */
-   {MMC1_DAT2, (PTU | IEN | M0)},  /* MMC1_DAT2 */
-   {MMC1_DAT3, (PTU | IEN | M0)},  /* MMC1_DAT3 */
-   {MMC1_SDCD, (PTU | IEN | M0)},  /* MMC1_SDCD */
-   {MMC1_SDWP, (PTU | IEN | M0)},  /* MMC1_SDWP */
-   {UART1_RXD, (PTU | IEN | M0)},  /* UART1_RXD */
-   {UART1_TXD, (M0)},  /* UART1_TXD */
-   {UART1_CTSN, (PTU | IEN | M0)}, /* UART1_CTSN */
-   {UART1_RTSN, (M0)}, /* UART1_RTSN */
-   {I2C1_SDA, (PTU | IEN | M0)},   /* I2C1_SDA */
-   {I2C1_SCL, (PTU | IEN | M0)},   /* I2C1_SCL */
+   {MMC1_CLK, (IEN | PTU | PDIS | M0)},/* MMC1_CLK */
+   {MMC1_CMD, (IEN | PTU | PDIS | M0)},/* MMC1_CMD */
+   {MMC1_DAT0, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT0 */
+   {MMC1_DAT1, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT1 */
+   {MMC1_DAT2, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT2 */
+   {MMC1_DAT3, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT3 */
+   {MMC1_SDCD, (FSC | IEN | PTU | PDIS | M0)}, /* MMC1_SDCD */
+   {MMC1_SDWP, (FSC | IEN | PTD | PEN | M14)}, /* MMC1_SDWP */
+   {GPMC_A19, (IEN | PTU | PDIS | M1)},/* mmc2_dat4 */
+   {GPMC_A20, (IEN | PTU | PDIS | M1)},/* mmc2_dat5 */
+   {GPMC_A21, (IEN | PTU | PDIS | M1)},/* mmc2_dat6 */
+   {GPMC_A22, (IEN | PTU | PDIS | M1)},/* mmc2_dat7 */
+   {GPMC_A23, (IEN | PTU | PDIS | M1)},/* mmc2_clk */
+   {GPMC_A24, (IEN | PTU | PDIS | M1)},/* mmc2_dat0 */
+   {GPMC_A25, (IEN | PTU | PDIS | M1)},/* mmc2_dat1 */
+   {GPMC_A26, (IEN | PTU | PDIS | M1)},/* mmc2_dat2 */
+   {GPMC_A27, (IEN | PTU | PDIS | M1)},/* mmc2_dat3 */
+   {GPMC_CS1, (IEN | PTU | PDIS | M1)},/* mmm2_cmd */
+   {UART1_RXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_RXD */
+   {UART1_TXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_TXD */
+   {UART1_CTSN, (IEN | PTU | PDIS | M3)},  /* UART1_CTSN */
+   {UART1_RTSN, (IEN | PTU | PDIS | M3)},  /* UART1_RTSN */
+   {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
+   {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
 };
 #endif /* _MUX_DATA_DRA7XX_H_ */
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 07/12] ARM: DRA7xx: Correct the SYS_CLK to 20MHZ

From: Sricharan R r.sricha...@ti.com

The sys_clk on the dra evm board is 20MHZ.
Changing the configuration for the same.
And also moving V_SCLK, V_OSCK defines to
arch/clock.h for OMAP4+ boards.

Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 arch/arm/cpu/armv7/omap-common/timer.c  |1 +
 arch/arm/include/asm/arch-omap4/clock.h |4 
 arch/arm/include/asm/arch-omap5/clock.h |8 
 include/configs/omap4_common.h  |4 
 include/configs/omap5_common.h  |4 
 5 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/timer.c 
b/arch/arm/cpu/armv7/omap-common/timer.c
index 507f687..5926a5a 100644
--- a/arch/arm/cpu/armv7/omap-common/timer.c
+++ b/arch/arm/cpu/armv7/omap-common/timer.c
@@ -35,6 +35,7 @@
 #include common.h
 #include asm/io.h
 #include asm/arch/cpu.h
+#include asm/arch/clock.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/arch/arm/include/asm/arch-omap4/clock.h 
b/arch/arm/include/asm/arch-omap4/clock.h
index f544edf..d7b61c2 100644
--- a/arch/arm/include/asm/arch-omap4/clock.h
+++ b/arch/arm/include/asm/arch-omap4/clock.h
@@ -214,6 +214,10 @@
 #define DPLL_NO_LOCK   0
 #define DPLL_LOCK  1
 
+/* Clock Defines */
+#define V_OSCK 3840/* Clock output from T2 */
+#define V_SCLK   V_OSCK
+
 struct omap4_scrm_regs {
u32 revision;   /* 0x */
u32 pad00[63];
diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index 6d02835..86d4711 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -284,4 +284,12 @@
  * into microsec and passing the value.
  */
 #define CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC31219
+
+#ifdef CONFIG_DRA7XX
+#define V_OSCK 2000/* Clock output from T2 */
+#else
+#define V_OSCK 1920/* Clock output from T2 */
+#endif
+
+#define V_SCLK V_OSCK
 #endif /* _CLOCKS_OMAP5_H_ */
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index d6448b0..3e5d36b 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -45,10 +45,6 @@
 #define CONFIG_DISPLAY_CPUINFO 1
 #define CONFIG_DISPLAY_BOARDINFO   1
 
-/* Clock Defines */
-#define V_OSCK 3840/* Clock output from T2 */
-#define V_SCLK   V_OSCK
-
 #define CONFIG_MISC_INIT_R
 
 #define CONFIG_OF_LIBFDT   1
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index d57c0da..83b91d1 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -45,10 +45,6 @@
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
 
-/* Clock Defines */
-#define V_OSCK 1920/* Clock output from T2 */
-#define V_SCLK V_OSCK
-
 #define CONFIG_MISC_INIT_R
 
 #define CONFIG_OF_LIBFDT
-- 
1.7.9.5

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

[U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's

This series update support for DRA7xx family Socs and the data for
DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html

Testing:
Boot tested on DRA752 ES1.0, OMAP5432 ES2.0, OMAP4460 PANDA
Verified MAKEALL for armv7 and omap boards.

Changes from v1:
* Addressed comments from Tom Rini

Balaji T K (1):
  mmc: omap_hsmmc: add mmc1 pbias, ldo1

Lokesh Vutla (6):
  ARM: DRA7xx: Add control id code for DRA7xx
  ARM: DRA7xx: power Add support for tps659038 PMIC
  ARM: DRA7xx: clocks: Fixing i2c_init for PMIC
  ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's
  ARM: DRA7xx: Update pinmux data
  ARM: DRA7xx: clocks: Update PLL values

Nishanth Menon (1):
  ARM: OMAP5: DRA7xx: support class 0 optimized voltages

Sricharan R (4):
  ARM: DRA7xx: Change the Debug UART to UART1
  ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
  ARM: DRA7xx: Correct SRAM END address
  ARM: DRA7xx: EMIF: Change settings required for EVM board

 arch/arm/cpu/armv7/omap-common/clocks-common.c |   86 +---
 arch/arm/cpu/armv7/omap-common/emif-common.c   |   26 +++-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 -
 arch/arm/cpu/armv7/omap-common/timer.c |1 +
 arch/arm/cpu/armv7/omap5/hw_data.c |  156 --
 arch/arm/cpu/armv7/omap5/hwinit.c  |   22 ++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |2 +
 arch/arm/cpu/armv7/omap5/sdram.c   |  170 ++--
 arch/arm/include/asm/arch-omap4/clock.h|6 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/clock.h|   61 -
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h   |7 +-
 arch/arm/include/asm/arch-omap5/omap.h |   26 ++--
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/emif.h|   12 +-
 arch/arm/include/asm/omap_common.h |   26 +++-
 board/ti/dra7xx/mux_data.h |   38 --
 drivers/mmc/omap_hsmmc.c   |   26 ++--
 drivers/power/palmas.c |   25 +++-
 include/configs/dra7xx_evm.h   |8 +-
 include/configs/omap4_common.h |4 -
 include/configs/omap5_common.h |   12 +-
 include/configs/omap5_uevm.h   |7 +-
 include/palmas.h   |6 +-
 24 files changed, 590 insertions(+), 141 deletions(-)

-- 
1.7.9.5

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

Re: [U-Boot] [U-BOOT PATCH] sf: Fix sf read for memory-mapped SPI flashes

Hi,

On Mon, May 27, 2013 at 1:14 PM, Jagannadha Sutradharudu Teki 
jagannadha.sutradharudu-t...@xilinx.com wrote:

 Missing return after memcpy is done for memory-mapped SPI flashes,
 hence added retun 0 after memcpy done.

 The return is missing in below patch
 sf: Enable FDT-based configuration and memory mapping
 (sha1: bb8215f437a7c948eec82a6abe754c226978bd6d)

 Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com


Acked-by: Simon Glass s...@chromium.org

Thanks for fixing it.

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

Re: [U-Boot] Conflict resolution for u-boot-arm/master and u-boot/master merge

2013-05-30 Thread Bo Shen


Bo Shen voice.s...@gmail.com on behalf of Bo Shen voice.s...@atmel.com

Hi Albert,

On 05/30/2013 08:55 PM, Albert ARIBAUD wrote:

Hello Tom and Bo,

While preparing for my ARM PR, I have encountered two merge conflicts.
Their resolution can be found in branch 'merge_from_mainline' of ARM
repo git://git.denx.de/u-boot-arm.

For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
renaming fit somehow caused a need for manual resolution just to
select the version with the right name. Simon, can you confirm that my
resolution is correct?

For drivers/usb/host/ohci-at91.c, the conflicting commits are both from
Bo, respectively 158947d2 (committed by Marek) and e5e8bb05 (commited
by Andreas). Bo, can you confirm that my resolution is correct?


Confirmed, the resolution is correct.
Thanks.


If both resolutions are correct, then at Tom's discretion, either I'll
move my master there and submit what should then be a fast-forward PR,
or I'll submit current master and Tom will replay my resolutions when
doing his merge. Tom, your preference?

Thanks in advance to all!

Amicalement,



Best Regards,
Bo Shen

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

[U-Boot] [PATCH v2 0/8] sf: spansion|winbond: ID table corrections/updates

This patch series consists of few corrections dones on already commited 
patches, 
along with some updates on parts name and few new flash parts are added.

Thanks,
Jagan.

Jagannadha Sutradharudu Teki (8):
  sf: spansion: Update the name for S25FL256S flash
  sf: spansion: Add support for S25FL128S_64K
  sf: winbond: Add support for W25Q80BW
  sf: winbond: Correct the nr_blocks used for W25Q32DW
  sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
  sf: winbond: Add support for W25Q128FW
  sf: winbond: Add support for W25Q16DW
  sf: winbond: Add support for W25QXXXFV

 drivers/mtd/spi/spansion.c |  4 ++--
 drivers/mtd/spi/winbond.c  | 30 --
 2 files changed, 22 insertions(+), 12 deletions(-)

-- 
1.8.3


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

[U-Boot] [PATCH v2 3/8] sf: winbond: Add support for W25Q80BW

Add support for Winbond W25Q80BW SPI flash.

This patch corrected the flash name, nr_blocks and
also commit message header from below patch.
sf: winbond: add W25Q32
(sha1: c969abc47033d6f810d3c9dbdb994ea9d691d038)

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

 drivers/mtd/spi/winbond.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index cb57ce0..a7cd51f 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -84,8 +84,8 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
},
{
.id = 0x5014,
-   .nr_blocks  = 128,
-   .name   = W25Q80,
+   .nr_blocks  = 16,
+   .name   = W25Q80BW,
},
{
.id = 0x6016,
-- 
1.8.3


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

[U-Boot] [PATCH v2 8/8] sf: winbond: Add support for W25QXXXFV

Add support for Winbond W25QXXXFV SPI flash.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

 drivers/mtd/spi/winbond.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 9fb4910..c399bf1 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -65,17 +65,17 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
{
.id = 0x4016,
.nr_blocks  = 64,
-   .name   = W25Q32BV,
+   .name   = W25Q32BV/W25Q32FV_SPI,
},
{
.id = 0x4017,
.nr_blocks  = 128,
-   .name   = W25Q64CV,
+   .name   = W25Q64CV/W25Q64FV_SPI,
},
{
.id = 0x4018,
.nr_blocks  = 256,
-   .name   = W25Q128BV,
+   .name   = W25Q128BV/W25Q128FV_SPI,
},
{
.id = 0x4019,
@@ -95,17 +95,17 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
{
.id = 0x6016,
.nr_blocks  = 64,
-   .name   = W25Q32DW,
+   .name   = W25Q32DW/W25Q32FV_QPI,
},
{
.id = 0x6017,
.nr_blocks  = 128,
-   .name   = W25Q64DW,
+   .name   = W25Q64DW/W25Q64FV_QPI,
},
{
.id = 0x6018,
.nr_blocks  = 256,
-   .name   = W25Q128FW,
+   .name   = W25Q128FW/W25Q128FV_QPI,
},
 };
 
-- 
1.8.3


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

[U-Boot] [PATCH v2 4/8] sf: winbond: Correct the nr_blocks used for W25Q32DW

This patch corrected the nr_blocks used for W25Q32DW SPI flash.

nr_blcoks are incorrectly assigned on below patch
sf: winbond: add W25Q32DW
(sha1: 772ba15474f73adc942e817cc072b6e9750836cc)

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

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

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index a7cd51f..8457808 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -89,7 +89,7 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
},
{
.id = 0x6016,
-   .nr_blocks  = 512,
+   .nr_blocks  = 64,
.name   = W25Q32DW,
},
{
-- 
1.8.3


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

[U-Boot] [PATCH v2 7/8] sf: winbond: Add support for W25Q16DW

Add support for Winbond W25Q16DW SPI flash.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

 drivers/mtd/spi/winbond.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index e07480b..9fb4910 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -88,6 +88,11 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
.name   = W25Q80BW,
},
{
+   .id = 0x6015,
+   .nr_blocks  = 32,
+   .name   = W25Q16DW,
+   },
+   {
.id = 0x6016,
.nr_blocks  = 64,
.name   = W25Q32DW,
-- 
1.8.3


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

[U-Boot] [PATCH v2 1/8] sf: spansion: Update the name for S25FL256S flash

As the per the ID tabl the flash is under Uniform 64-kB sector
architecture, hence updated with proper name.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

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

diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 307b852..2218e2f 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -108,7 +108,7 @@ static const struct spansion_spi_flash_params 
spansion_spi_flash_table[] = {
.idcode2 = 0x4d01,
.pages_per_sector = 256,
.nr_sectors = 512,
-   .name = S25FL256S,
+   .name = S25FL256S_64K,
},
 };
 
-- 
1.8.3


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

[U-Boot] [PATCH v2 2/8] sf: spansion: Add support for S25FL128S_64K

This commit is based on the patch from Xie Xiaobo x@freescale.com
with commit head title as sf: spansion: Add support for S25FL128S.
pulled the same code changes into current u-boot tree with little update
on the name field.

http://patchwork.ozlabs.org/patch/218145/

SPANSION recommend S25FL128S supersedes S25FL129P, and the two flash
memory have the same device ID and Memory architecture. So they can
use the same config parameters.

Signed-off-by: Xie Xiaobo x@freescale.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

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

diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 2218e2f..dad4fbb 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -101,7 +101,7 @@ static const struct spansion_spi_flash_params 
spansion_spi_flash_table[] = {
.idcode2 = 0x4d01,
.pages_per_sector = 256,
.nr_sectors = 256,
-   .name = S25FL129P_64K,
+   .name = S25FL129P_64K/S25FL128S_64K,
},
{
.idcode1 = 0x0219,
-- 
1.8.3


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

[U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts

Use the exact names for W25Q 0x40XX ID's flash parts, as the same
sizes of flashes comes with different ID's. so-that the distinguishes
becomes easy with this change.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

 drivers/mtd/spi/winbond.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 8457808..3c0ca88 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -55,27 +55,27 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
{
.id = 0x4014,
.nr_blocks  = 16,
-   .name   = W25Q80BL,
+   .name   = W25Q80BL/W25Q80BV,
},
{
.id = 0x4015,
.nr_blocks  = 32,
-   .name   = W25Q16,
+   .name   = W25Q16CL/W25Q16DV,
},
{
.id = 0x4016,
.nr_blocks  = 64,
-   .name   = W25Q32,
+   .name   = W25Q32BV,
},
{
.id = 0x4017,
.nr_blocks  = 128,
-   .name   = W25Q64,
+   .name   = W25Q64CV,
},
{
.id = 0x4018,
.nr_blocks  = 256,
-   .name   = W25Q128,
+   .name   = W25Q128BV,
},
{
.id = 0x4019,
-- 
1.8.3


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

[U-Boot] [PATCH v2 6/8] sf: winbond: Add support for W25Q128FW

Add support for Winbond W25Q128FW SPI flash.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none

 drivers/mtd/spi/winbond.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 3c0ca88..e07480b 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -97,6 +97,11 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
.nr_blocks  = 128,
.name   = W25Q64DW,
},
+   {
+   .id = 0x6018,
+   .nr_blocks  = 256,
+   .name   = W25Q128FW,
+   },
 };
 
 struct spi_flash *spi_flash_probe_winbond(struct spi_slave *spi, u8 *idcode)
-- 
1.8.3


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

Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere

Hi Tom,

On Thu, May 16, 2013 at 11:49 AM, Simon Glass s...@chromium.org wrote:

 Hi Tom,

 On Thu, May 16, 2013 at 9:26 AM, Tom Rini tr...@ti.com wrote:
  On Wed, May 15, 2013 at 07:13:18AM -0700, Simon Glass wrote:
 
  [snip]
  I've brought over the patches that I can that don't depend on autoconf:
 
  6c0e6c9 (HEAD, ws/us-config5, us-config5) main: Add debug_bootkeys to
  avoid #ifdefs
  9777b9f main: Add debug_parser() to avoid #ifdefs
  2fc85b6 main: Correct header order
  24e80be main: Fix typos and checkpatch warnings in command line reading
  9e9e3b9 main: Use get/setenv_ulong()
  1290cb7 main: Move boot_delay code into its own function
  cd8f13e main: Separate out the two abortboot() functions
  ca2451c net: Add prototype for update_tftp
  4a2a802 at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263
 
  I will run these through the builder and send an interim series
  without autoconf. We still have a lot of inline #ifdefs, and static
  functions and local variables must also be #ifdefed out if not used.
  Still, there is some improvement.
 
  I've read them over and they look good.  Since you didn't re-send
  anything I assume they passed your builder test and I'll apply them next
  week (and give them my own builder test like everything else gets).
  Thanks!


Just checking up if you got to this? I am thinking of respinning the
autoconf series on top of this.



 Yes I did a full build and saw no additional failures from my patch.
 But then I did a few whitespace changes and only built a few boards
 after that. I think it's OK though.

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

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Gabbasov, Andrew

From: Behme, Dirk - Bosch
Sent: Thursday, May 30, 2013 15:50
To: Gabbasov, Andrew
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio
number in SF chip select

On 30.05.2013 13:32, Gabbasov, Andrew wrote:
Hi Dirk,

From: Behme, Dirk - Bosch
Sent: Thursday, May 30, 2013 14:50
To: Gabbasov, Andrew
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of
gpio number in SF chip select

[skipped]

To my understanding, above change is correct, but not complete ;)

The question is why has it worked with the wrong setting and nobody
ever noticed that its wrong?

To my understanding the answer is because the SPI driver does it
correctly:

http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=5bed858787f610a9c9a46bb2214665a51d60a9e9;hb=refs/heads/master#l376

So IMHO the gpio_direction_output() above can be removed completely.

Best regards

Dirk

Yes, the SPI driver correctly activates and deactivates the CS signal.
But before the first activation it relies on what signal state was set
before that.
Setting it early at startup just adds some confidence that we have correct
(inactive) chip select state before the first activation by SPI driver.
Otherwise we have to rely on particular pad configuration (e.g. EIM_D19).
I understand, that we set its configuration to pull-up (and this is also
the reset default), and if we do nothing here, it will be recognized as
high.
But in order to make sure, it's more safe to explicitly set the signal to 1.

Hmm, what's 'unsure' in the time between calling setup_spi() the first
time and calling spi_setup_slave() the first time?

Are they even called in this order? How long is the time between these
two calls? What's 'unsafe' in this time frame? Why isn't it unsafe
_until_ setup_spi() is called, then?

Best regards

Dirk

Hi Dirk,

It turns out I overlooked that the pad configuration for chip select gpio is
actually pull-down, so, since erroneous gpio_direction_output call does not
make effect, the signal seems to be kept low, i.e. active, until first
spi_setup_slave
call (where it is set correctly before any actual activity is being done on SPI
bus).

And since indeed nobody yet complained about that, it must be ok to just remove
the gpio related call in setup_spi.

So, OK, you convinced me ;-) I'll prepare another patch shortly, that just
removes
gpio_direction_output calls from setup_spi function for both mx6qsabrelite
and nitrogen6x.

Thanks.

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

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:

 Tested on OMAP4/5 only, but should work on older OMAPs and
 derivatives as well.
 
 - Rewritten i2c_read to operate correctly with all types of chips
   (old function could not read consistent data from some I2C slaves).
 - Optimised i2c_write.
 - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
   performs write access vs read. The old probe could hang the system
   under certain conditions (e.g. unconfigured pads).
 - The read/write/probe functions try to identify unconfigured bus.
 - Status functions now read irqstatus_raw as per TRM guidelines
   (except for OMAP243X and OMAP34XX).
 - Driver now supports up to I2C5 (OMAP5).
 
 Signed-off-by: Lubomir Popov lpo...@mm-sol.com

With CONFIG_I2C_PROBE_WRITE set:
Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM

So lets just go with the write probe always being on again.

Now, when I git am'd I saw some whitespace problems, so please make sure
v4 is checkpatch clean.  And note that printf(Long than 80 char wide,
a, b) is OK and expected to NOT break the string (but do align the
args).

-- 
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 V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

Hi Lokesh,

On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com
 
 add dra mmc pbias support and ldo1 power on
 
 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  arch/arm/include/asm/arch-omap5/omap.h |3 ++-
  drivers/mmc/omap_hsmmc.c   |   26 ++
  drivers/power/palmas.c |   25 -
  include/configs/omap5_common.h |4 
  include/configs/omap5_uevm.h   |5 -
  include/palmas.h   |6 +-
  6 files changed, 49 insertions(+), 20 deletions(-)
 
[snip]
  
 diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
 index 09c832d..1bcff52 100644
 --- a/drivers/power/palmas.c
 +++ b/drivers/power/palmas.c
 @@ -28,7 +28,7 @@ void palmas_init_settings(void)
   return;
  }
  
 -int palmas_mmc1_poweron_ldo(void)
 +int palmas_mmc1_poweron_ldo9(void)
  {
   u8 val = 0;
  
 @@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
  
   return 0;
  }
 +
 +int palmas_mmc1_poweron_ldo1(void)
 +{
 + u8 val = 0;
 +
 + /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.

 +
 + if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
 + printf(tps659038: could not set LDO1 voltage\n);
 + return 1;
 + }
 +
 + /* TURN ON LDO9 */
LDO9?

 + val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.

 +
 + if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
 + printf(tps659038: could not turn on LDO1\n);
 + return 1;
 + }
 +
[snip]
  /* I2C chip addresses */
  #define PALMAS_CHIP_ADDR 0x48
 +#define TPS659038_CHIP_ADDR  0x58
Now we have a mess again. The files were recently renamed from twl6035.x
to palmas.x, implying that palmas is the generic family name of a series
of PMICs. Having TPS659038_CHIP_ADDR above is OK, but then we should have
TWL603X_CHIP_ADDR instead of PALMAS_CHIP_ADDR.

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

[U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal

2013-05-30 Thread Andrew Gabbasov

The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
(shifted and or'ed with chip select), so it's incorrect to pass
that macro directly as an argument to gpio_direction_output() call.

Also, SPI driver sets the direction and initial value of a gpio,
used as a chip select signal, before any actual activity happens
on the bus.

So, it is safe to just remove the gpio_direction_output call,
that works incorrectly, thus making no effect, anyway.

Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
 board/boundary/nitrogen6x/nitrogen6x.c|1 -
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |1 -
 2 files changed, 2 deletions(-)

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
b/board/boundary/nitrogen6x/nitrogen6x.c
index cc071d6..735fd76 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -342,7 +342,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
 
 void setup_spi(void)
 {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
 }
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 9f9cac8..29815d7 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -312,7 +312,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
 
 void setup_spi(void)
 {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
 }
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

Hi Tom,

On 30/05/13 17:37, Tom Rini wrote:
 On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
 
 Tested on OMAP4/5 only, but should work on older OMAPs and
 derivatives as well.

 - Rewritten i2c_read to operate correctly with all types of chips
   (old function could not read consistent data from some I2C slaves).
 - Optimised i2c_write.
 - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
   performs write access vs read. The old probe could hang the system
   under certain conditions (e.g. unconfigured pads).
 - The read/write/probe functions try to identify unconfigured bus.
 - Status functions now read irqstatus_raw as per TRM guidelines
   (except for OMAP243X and OMAP34XX).
 - Driver now supports up to I2C5 (OMAP5).

 Signed-off-by: Lubomir Popov lpo...@mm-sol.com
 
 With CONFIG_I2C_PROBE_WRITE set:
 Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM
 
 So lets just go with the write probe always being on again.
 
 Now, when I git am'd I saw some whitespace problems, so please make sure
 v4 is checkpatch clean.  And note that printf(Long than 80 char wide,
 a, b) is OK and expected to NOT break the string (but do align the
 args).
 
OK, shall do it tonight. I see a minor problem however: if we are not
going to support all OMAP2 chips (the 2420 in particular), isn't it
somewhat misleading to keep the driver named omap24xx_i2c? Letting
you decide...

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

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

On Thu, May 30, 2013 at 05:51:44PM +0300, Lubomir Popov wrote:
 Hi Tom,
 
 On 30/05/13 17:37, Tom Rini wrote:
  On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
  
  Tested on OMAP4/5 only, but should work on older OMAPs and
  derivatives as well.
 
  - Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
  - Optimised i2c_write.
  - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
  - The read/write/probe functions try to identify unconfigured bus.
  - Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
  - Driver now supports up to I2C5 (OMAP5).
 
  Signed-off-by: Lubomir Popov lpo...@mm-sol.com
  
  With CONFIG_I2C_PROBE_WRITE set:
  Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM
  
  So lets just go with the write probe always being on again.
  
  Now, when I git am'd I saw some whitespace problems, so please make sure
  v4 is checkpatch clean.  And note that printf(Long than 80 char wide,
  a, b) is OK and expected to NOT break the string (but do align the
  args).
  
 OK, shall do it tonight. I see a minor problem however: if we are not
 going to support all OMAP2 chips (the 2420 in particular), isn't it
 somewhat misleading to keep the driver named omap24xx_i2c? Letting
 you decide...

Please add a comment that this driver needs some re-adaptation for the
OMAP2420 implementation of this IP block now.  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] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

2013-05-30 Thread Gabbasov, Andrew

 From: Gabbasov, Andrew
 Sent: Thursday, May 30, 2013 18:36
 To: Behme, Dirk - Bosch
 Cc: u-boot@lists.denx.de
 Subject: RE: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio 
 number in SF chip select

[skipped]

 So, OK, you convinced me ;-) I'll prepare another patch shortly, that just 
 removes
 gpio_direction_output calls from setup_spi function for both mx6qsabrelite
 and nitrogen6x.

I have submitted the mentioned patch. See Subject line
mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal

Thanks.

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

Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere

On Thu, May 30, 2013 at 06:57:02AM -0700, Simon Glass wrote:

 Hi Tom,
 
 On Thu, May 16, 2013 at 11:49 AM, Simon Glass s...@chromium.org wrote:
 
  Hi Tom,
 
  On Thu, May 16, 2013 at 9:26 AM, Tom Rini tr...@ti.com wrote:
   On Wed, May 15, 2013 at 07:13:18AM -0700, Simon Glass wrote:
  
   [snip]
   I've brought over the patches that I can that don't depend on autoconf:
  
   6c0e6c9 (HEAD, ws/us-config5, us-config5) main: Add debug_bootkeys to
   avoid #ifdefs
   9777b9f main: Add debug_parser() to avoid #ifdefs
   2fc85b6 main: Correct header order
   24e80be main: Fix typos and checkpatch warnings in command line reading
   9e9e3b9 main: Use get/setenv_ulong()
   1290cb7 main: Move boot_delay code into its own function
   cd8f13e main: Separate out the two abortboot() functions
   ca2451c net: Add prototype for update_tftp
   4a2a802 at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263
  
   I will run these through the builder and send an interim series
   without autoconf. We still have a lot of inline #ifdefs, and static
   functions and local variables must also be #ifdefed out if not used.
   Still, there is some improvement.
  
   I've read them over and they look good.  Since you didn't re-send
   anything I assume they passed your builder test and I'll apply them next
   week (and give them my own builder test like everything else gets).
   Thanks!
 
 
 Just checking up if you got to this? I am thinking of respinning the
 autoconf series on top of this.

Looking to clear up my patchwork TODO list tomorrow and this is up in
there for eligible patches.  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] Conflict resolution for u-boot-arm/master and u-boot/master merge

On Thu, 30 May 2013 14:55:41 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:

 Hello Tom and Bo,
 
 While preparing for my ARM PR, I have encountered two merge conflicts.
 Their resolution can be found in branch 'merge_from_mainline' of ARM
 repo git://git.denx.de/u-boot-arm.
 
 For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
 renaming fit somehow caused a need for manual resolution just to
 select the version with the right name. Simon, can you confirm that my
 resolution is correct?

... actually adding Simon as To:...

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

Re: [U-Boot] [PATCH] pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option

2013-05-30 Thread Daniel Schwierzeck

2013/5/29 Gabor Juhos juh...@openwrt.org:
 The pci_indirect.c file is always compiled when
 CONFIG_PCI is defined although the indirect PCI
 bridge support is not needed by every board.

 Introduce a new CONFIG_PCI_INDIRECT_BRIDGE
 config option and only compile indirect PCI
 bridge support if this options is enabled.

 Also add the new option into the configuration
 files of the boards which needs that.

looks good, thanks for your efforts.
But you should document that new config option in the README file.


 Compile tested for powerpc, x86, arm and nds32.
 MAKEALL results:

 powerpc:
   - SUMMARY 
   Boards compiled: 641
   Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB )
   --
   Note: the warnings for ELPPC and MPC8323ERDB are present even
   without the actual patch.

 x86:
   - SUMMARY 
   Boards compiled: 1
   --

 arm:
   - SUMMARY 
   Boards compiled: 311
   --

 nds32:
   - SUMMARY 
   Boards compiled: 3
   --

 Cc: Tom Rini tr...@ti.com
 Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
 Signed-off-by: Gabor Juhos juh...@openwrt.org
 ---
 Notes:
  - warning details for powerpc:

  ELPPC:
misc.c: In function 'misc_init_r':
misc.c:210:3: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules [-Wstrict-aliasing]
misc.c:211:3: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules [-Wstrict-aliasing]
misc.c:212:3: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules [-Wstrict-aliasing]

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

  - because nds32 support in u-boot/master is broken at the moment,
the following patch-set has been used in the test:
http://patchwork.ozlabs.org/bundle/juhosg/nds32-fix-build-errors-warnings/

 -Gabor
 ---

[...]

 diff --git a/include/pci.h b/include/pci.h
 index 15f583f..f9c5148 100644
 --- a/include/pci.h
 +++ b/include/pci.h
 @@ -569,7 +569,9 @@ extern __inline__ void pci_set_ops(struct pci_controller 
 *hose,
 hose-write_dword = write_dword;
  }

 +#ifdef CONFIG_PCI_INDIRECT_BRIDGE
  extern void pci_setup_indirect(struct pci_controller* hose, u32 cfg_addr, 
 u32 cfg_data);
 +#endif


ifdef's around function declarations are not necessary

  extern phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
 pci_addr_t addr, unsigned long flags);
 --
 1.7.10




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

Re: [U-Boot] Conflict resolution for u-boot-arm/master and u-boot/master merge

Hi Albert,

On Thu, May 30, 2013 at 9:21 AM, Albert ARIBAUD
albert.u.b...@aribaud.netwrote:

 On Thu, 30 May 2013 14:55:41 +0200, Albert ARIBAUD
 albert.u.b...@aribaud.net wrote:

  Hello Tom and Bo,
 
  While preparing for my ARM PR, I have encountered two merge conflicts.
  Their resolution can be found in branch 'merge_from_mainline' of ARM
  repo git://git.denx.de/u-boot-arm.
 
  For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
  renaming fit somehow caused a need for manual resolution just to
  select the version with the right name. Simon, can you confirm that my
  resolution is correct?

 ... actually adding Simon as To:...


Yes this looks right thanks.

Although I do wonder if you mean that I renamed 'fit', or I had a renaming
fit.

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

Re: [U-Boot] [PATCH] pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option

2013-05-30 Thread Gabor Juhos

2013.05.30. 18:36 keltezéssel, Daniel Schwierzeck írta:
 2013/5/29 Gabor Juhos juh...@openwrt.org:
 The pci_indirect.c file is always compiled when
 CONFIG_PCI is defined although the indirect PCI
 bridge support is not needed by every board.

 Introduce a new CONFIG_PCI_INDIRECT_BRIDGE
 config option and only compile indirect PCI
 bridge support if this options is enabled.

 Also add the new option into the configuration
 files of the boards which needs that.
 
 looks good, thanks for your efforts.
 But you should document that new config option in the README file.

Ok, will send a modified patch.

Thank you for the review!

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

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
 On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
 
  Tested on OMAP4/5 only, but should work on older OMAPs and
  derivatives as well.
  
  - Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
  - Optimised i2c_write.
  - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
  - The read/write/probe functions try to identify unconfigured bus.
  - Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
  - Driver now supports up to I2C5 (OMAP5).
  
  Signed-off-by: Lubomir Popov lpo...@mm-sol.com
 
 With CONFIG_I2C_PROBE_WRITE set:
 Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM

But, crap, breaks am335x_evm (and probably beaglebones, etc).  I'll
dig into this more to see if I can spot something obvious tomorrow.


-- 
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] Conflict resolution for u-boot-arm/master and u-boot/master merge

Hi Simon,

On Thu, 30 May 2013 09:38:56 -0700, Simon Glass s...@chromium.org
wrote:

 Hi Albert,
 
 On Thu, May 30, 2013 at 9:21 AM, Albert ARIBAUD
 albert.u.b...@aribaud.netwrote:
 
  On Thu, 30 May 2013 14:55:41 +0200, Albert ARIBAUD
  albert.u.b...@aribaud.net wrote:
 
   Hello Tom and Bo,
  
   While preparing for my ARM PR, I have encountered two merge conflicts.
   Their resolution can be found in branch 'merge_from_mainline' of ARM
   repo git://git.denx.de/u-boot-arm.
  
   For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
   renaming fit somehow caused a need for manual resolution just to
   select the version with the right name. Simon, can you confirm that my
   resolution is correct?
 
  ... actually adding Simon as To:...
 
 
 Yes this looks right thanks.

Thanks for your confirmation.

 Although I do wonder if you mean that I renamed 'fit', or I had a renaming
 fit.

Phew! I was wondering if that one had gone below everyone's radars. :)

 Regards,
 Simon

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

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

2013-05-30 Thread Stephen Warren

On 05/30/2013 01:56 AM, Wolfgang Denk wrote:
 Dear Stephen,
 
 In message 51a6df7c.30...@wwwdotorg.org you wrote:

 It seems to be aimed specifically at enabling use of new dtc features
 when present. That seems to be specifically against Wolfgang's goal of
 not requiring new dtc features. There's no point allowing use of new dtc
 
 Please stop planting statements on me that I did not make.

Sorry, but that's what I believe you meant. If you didn't mean that,
well then let's clear this up, and the rest of the conversation will be
a lot simpler:

I believe that for building the *.dts in U-Boot we should simply require
the user to have a version of dtc that supports the recently added
features such as:

* -i directive.
* Ability to parse the output of cpp well (e.g. #line directives, emit
useful error/warning messages in this case).
* Cell expression support.

Those are all present in the latest git repo for dtc.

If we do that, then we won't need any conditional logic in the U-Boot
makefiles. At least parts of Simon's patch won't be necessary.

I'm quite happy to achieve this requirement by having the user install
that dtc into the $PATH prior to running any U-Boot make, either
manually or via distro packages once they're available.

It is my understanding that you object to requiring such a new version
of dtc, irrespective of the means by which it's provided. If this is not
true, then please do let me know; it would vastly simplify matters.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

Hi Tom,

 On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
 On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:

  Tested on OMAP4/5 only, but should work on older OMAPs and
  derivatives as well.
 
  - Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
  - Optimised i2c_write.
  - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
  - The read/write/probe functions try to identify unconfigured bus.
  - Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
  - Driver now supports up to I2C5 (OMAP5).
 
  Signed-off-by: Lubomir Popov lpo...@mm-sol.com

 With CONFIG_I2C_PROBE_WRITE set:
 Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM

 But, crap, breaks am335x_evm (and probably beaglebones, etc).  I'll
 dig into this more to see if I can spot something obvious tomorrow.

OK, holding off. And thanks for testing.

 --
 Tom

-- 
Lubo


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

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

Hello Tom,

The following changes since commit
a71d45d706a5b51c348160163b6c159632273fed:

  powerpc/mpc85xx: Clear L1 D-cache lock (2013-05-24 16:54:14 -0500)

are available in the git repository at:

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

for you to fetch changes up to 3da0e5750b24a9491058df6126c7be577a276c09:

  arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)


Albert ARIBAUD (9):
  Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master'
  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
  Revert wrong removal of nand_init and nand_deselect
  Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'
  Merge branch 'u-boot/master' into 'u-boot-arm/master'
  mx31pdk: copy SPL directly, not using relocate_code.
  tx25: copy SPL directly, not using relocate_code.
  arm: do not compile relocate_code() for SPL builds
  arm: factorize relocate_code routine

Allen Martin (1):
  Tegra: clk: always use find_best_divider() for periph clocks

Andre Przywara (2):
  ARM: vexpress: add support for Versatile Express Cortex-A15-TC2
  ARM: vexpress: enable bootz and hush parser for all VExpress
boards

Andreas Bießmann (1):
  at91sam9260ek: move board id setup to config header

Axel Lin (2):
  ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for
cpu_init_crit tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build

Benoît Thébaudeau (40):
  imx: Homogenize and fix fuse register definitions
  imx: Add useful fuse definitions
  Add fuse API and commands
  Add fsl_iim driver
  mpc: iim: Switch to common fsl_iim
  mx51evk: Enable support for iim
  Add mxc_ocotp driver
  mx6qsabrelite: Enable support for ocotp
  nitrogen6x: Enable support for ocotp
  imx: Document fuse assignments for MAC addresses
  imx: iomux-v3: Fix common pad control definitions
  imx: iomux-v3: cosmetic: Reorganize definitions
  imx: iomux-v3: Restore Linux's NEW_PAD_CTRL() macro
  imx: iomux-v3: Include PKE and PUE to pad control pull definitions
  imx: iomux-v3: Add iomux-mx25.h
  imx: mx25pdk: Convert to iomux-v3
  imx: mx25pdk: Fix GPIO assignments
  imx: tx25: Convert to iomux-v3
  imx: zmx25: Convert to iomux-v3
  imx: mx25: Remove legacy iomux support
  imx: iomux-v3: Add iomux-mx35.h
  imx: flea3: Convert to iomux-v3
  imx: mx35pdk: Fix WDOG_RST iomux function
  imx: mx35pdk: Convert to iomux-v3
  imx: woodburn: Convert to iomux-v3
  imx: mx35: Remove legacy iomux support
  imx: iomux-mx51: Fix MX51_PAD_EIM_CS2__GPIO2_27
  imx: iomux-v3: Add missing definitions to iomux-mx51.h
  imx: mx51evk: Convert to iomux-v3
  imx: mx51_efikamx/sb: Convert to iomux-v3
  imx: vision2: Convert to iomux-v3
  imx: iomux-v3: Add iomux-mx53.h
  imx: ima3-mx53: Convert to iomux-v3
  imx: mx53ard: Convert to iomux-v3
  imx: mx53evk: Convert to iomux-v3
  imx: mx53loco: Convert to iomux-v3
  imx: mx53smd: Convert to iomux-v3
  imx: m53evk: Convert to iomux-v3
  imx: mx5: Remove legacy iomux support
  imx: mx35pdk: Fix MUX2_CTR GPIO

Bo Shen (9):
  spi: atmel_spi: using ip version to check whether has wdrbt
  mmc: atmel_mci: using IP version for different setting
  mmc: atmel_mci: add mmc card support
  ARM: at91: add Atmel sama5d3 SoC new pmc register
  USB: ohci-at91: support sama5d3x devices
  ARM: atmel: add sama5d3xek support
  ARM: at91: fix and update README.at91 document
  ARM: at91: add at91sam9x5 and sama5d3x information
  ARM: at91: add NAND partition table and index

Dan Murphy (2):
  ARM:Panda:Fix device tree loading for the panda-es
  ARM: Panda: Add flag to allow runtime enviroment varibale mods

David Andrey (3):
  arm: zynq: U-Boot udelay  1000 FIX
  net: gem: Pass phy address to init
  net: gem: Preserve clk on emio interface

Enric Balletbo i Serra (2):
  Add DDR3 support for IGEP COM AQUILA/CYGNUS.
  ARM: Add support for IGEP COM AQUILA/CYGNUS

Eric Benard (3):
  mx28evk: add trimffs to nand command
  da850: provide davinci_enable_uart0
  davinci: handle CONFIG_SYS_CLE_MASK and CONFIG_SYS_ALE_MASK

Fabio Estevam (22):
  iomux-v3: Place pad control definitions into common file
  mx6: Add solo-lite variant support
  mx6sl: Add initial support for mx6slevk board
  imx: mx6q_4x_mt41j128.cfg: Setup CCM_CCOSR register
  nitrogen6x: Setup CCM_CCOSR register
  mx51evk: Update environment in order to allow booting a dt kernel
  mx51evk: Do not force the rootfs type
  mx5: Define a common get_board_rev()
  mx5: Select CONFIG_REVISION_TAG
  mx53ard: Move register masks into imx-regs.h
  mx23: Put back RAM voltage level to its original value
  mx23: Fix pad voltage selection bit
  mx23evk: Fix DDR pin iomux settings

Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions

Hi Tom,

 On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
 On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:

  Tested on OMAP4/5 only, but should work on older OMAPs and
  derivatives as well.
 
  - Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
  - Optimised i2c_write.
  - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
  - The read/write/probe functions try to identify unconfigured bus.
  - Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
  - Driver now supports up to I2C5 (OMAP5).
 
  Signed-off-by: Lubomir Popov lpo...@mm-sol.com

 With CONFIG_I2C_PROBE_WRITE set:
 Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM

 But, crap, breaks am335x_evm (and probably beaglebones, etc).  I'll
 dig into this more to see if I can spot something obvious tomorrow.

How does it actually break? Does not build, or I2C is not working,
or what?

If I2C is not working, could you try changing the condition

#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)

to

#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || 
defined(CONFIG_AM33XX)

found in 3 places in driver (lines 155, 554, 585) and test again?

Thanks,
Lubo

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

Re: [U-Boot] [U-Boot,v2] mtd: resync with Linux-3.7.1

2013-05-30 Thread Scott Wood

On Mon, Jan 14, 2013 at 03:46:50AM -, Sergey Lapin wrote:
 This patch is essentially an update of u-boot MTD subsystem to
 the state of Linux-3.7.1 with exclusion of some bits:
 
 - the update is concentrated on NAND, no onenand or CFI/NOR/SPI
 flashes interfaces are updated EXCEPT for API changes.
 
 - new large NAND chips support is there, though some updates
 have got in Linux-3.8.-rc1, (which will follow on top of this patch).
 
 To produce this update I used tag v3.7.1 of linux-stable repository.
 
 The update was made using application of relevant patches,
 with changes relevant to U-Boot-only stuff sticked together
 to keep bisectability. Then all changes were grouped together
 to this patch.
 
 Signed-off-by: Sergey Lapin sla...@ossfans.org
 
 ---
 v2: recreated on v3.7.1
 removed unimportant bits
 fixed look of the patch
 v1: original submission

Applied to u-boot-nand-flash, with the ecc strength patch merged, and
some fixes based mainly on my earlier comments, and to fix build
breakage.

Here's the diff of what I applied from this patch:

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index b09e7b7..3bfbaf8 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -709,6 +709,7 @@ static int atmel_pmecc_nand_init_params(struct nand_chip 
*nand,
 
nand-ecc.read_page = atmel_nand_pmecc_read_page;
nand-ecc.write_page = atmel_nand_pmecc_write_page;
+   nand-ecc.strength = cap;
 
atmel_pmecc_core_init(mtd);
 
diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c
index c7ddbb2..7e755e8 100644
--- a/drivers/mtd/nand/bfin_nand.c
+++ b/drivers/mtd/nand/bfin_nand.c
@@ -374,9 +374,11 @@ int board_nand_init(struct nand_chip *chip)
if (!NAND_IS_512()) {
chip-ecc.bytes = 3;
chip-ecc.size = 256;
+   chip-ecc.strength = 1;
} else {
chip-ecc.bytes = 6;
chip-ecc.size = 512;
+   chip-ecc.strength = 2;
}
chip-ecc.mode = NAND_ECC_HW;
chip-ecc.calculate = bfin_nfc_calculate_ecc;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 04b24f3..90f5985 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -613,6 +613,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW;
nand-ecc.size = 512;
nand-ecc.bytes = 3;
+   nand-ecc.strength = 1;
nand-ecc.calculate = nand_davinci_calculate_ecc;
nand-ecc.correct  = nand_davinci_correct_data;
nand-ecc.hwctl  = nand_davinci_enable_hwecc;
@@ -623,6 +624,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW_OOB_FIRST;
nand-ecc.size = 512;
nand-ecc.bytes = 10;
+   nand-ecc.strength = 4;
nand-ecc.calculate = nand_davinci_4bit_calculate_ecc;
nand-ecc.correct = nand_davinci_4bit_correct_data;
nand-ecc.hwctl = nand_davinci_4bit_enable_hwecc;
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 104d97f..4cd741e 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -1658,6 +1658,7 @@ static int __init doc_probe(unsigned long physadr)
nand-ecc.mode  = NAND_ECC_HW_SYNDROME;
nand-ecc.size  = 512;
nand-ecc.bytes = 6;
+   nand-ecc.strength  = 2;
nand-bbt_options   = NAND_BBT_USE_FLASH;
 
doc-physadr= physadr;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 28e6d35..0fa776a 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -769,6 +769,7 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr)
nand-ecc.size = 512;
nand-ecc.bytes = 3;
nand-ecc.steps = 1;
+   nand-ecc.strength = 1;
} else {
/* otherwise fall back to default software ECC */
nand-ecc.mode = NAND_ECC_SOFT;
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 68c1c83..439822c 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -890,11 +890,13 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
bbt_mirror_descr.offs = 0;
}
 
+   nand-ecc.strength = 4;
priv-bufnum_mask = 15;
break;
 
case CSOR_NAND_PGS_2K:
layout = oob_2048_ecc4;
+   nand-ecc.strength = 4;
priv-bufnum_mask = 3;
break;
 
@@ -902,8 +904,10 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
if ((csor  CSOR_NAND_ECC_MODE_MASK) ==
CSOR_NAND_ECC_MODE_4) {

[U-Boot] [PATCH] Add splash screen support via loading from flash

2013-05-30 Thread Robert Winkler

Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
 board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
 include/configs/nitrogen6x.h   | 11 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
b/board/boundary/nitrogen6x/nitrogen6x.c
index 3b228cf..648b877 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -401,6 +401,24 @@ int board_eth_init(bd_t *bis)
return 0;
 }
 
+
+void splash_screen_prepare(void)
+{
+   char *env_loadsplash;
+
+   if (!getenv(splashimage) || !getenv(splashsize))
+   return;
+
+   env_loadsplash = getenv(loadsplash);
+   if (!env_loadsplash) {
+   printf(Environment variable loadsplash not found!\n);
+   return;
+   }
+
+   if (run_command_list(env_loadsplash, -1, 0))
+   printf(failed to run loadsplash %s\n\n, env_loadsplash);
+}
+
 static void setup_buttons(void)
 {
imx_iomux_v3_setup_multiple_pads(button_pads,
@@ -661,6 +679,10 @@ int board_video_skip(void)
printf(unsupported panel %s\n, panel);
ret = -EINVAL;
}
+
+   if (!ret)
+   splash_screen_prepare();
+
return (0 != ret);
 }
 
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 2c904d3..011666f 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -38,7 +38,7 @@
 #define CONFIG_REVISION_TAG
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (10 * 1024 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (12 * 1024 * 1024)
 
 #define CONFIG_BOARD_EARLY_INIT_F
 #define CONFIG_MISC_INIT_R
@@ -151,6 +151,13 @@
 #define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
 #define CONFIG_VIDEO_BMP_RLE8
 #define CONFIG_SPLASH_SCREEN
+#define CONFIG_SPLASH_SCREEN_ALIGN
+
+ #define CONFIG_VIDEO_BMP_GZIP
+#ifdef CONFIG_VIDEO_BMP_GZIP
+#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (6 * 1024 * 1024)
+#endif
+
 #define CONFIG_BMP_16BPP
 #define CONFIG_VIDEO_LOGO
 #define CONFIG_IPUV3_CLK 26000
@@ -211,5 +218,7 @@
echo details at http://boundarydevices.com/6q_bootscript ;  \
setenv stdout serial\0 \
+   loadsplash=if sf probe ; then  \
+   sf read ${splashimage} c2000 ${splashsize} ; fi\0 \
upgradeu=for dtype in  CONFIG_DRIVE_TYPES \
; do  \
for disk in 0 1 ; do ${dtype} dev ${disk} ; \
-- 
1.8.2.3

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

Re: [U-Boot] JFFS2 seems to drop nand data with ECC corrections

2013-05-30 Thread passal

Hi

Have you submitted this patch?
Would it be possible to share  this patch because we have the same problem?

BR,
Pierre Assal



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/JFFS2-seems-to-drop-nand-data-with-ECC-corrections-tp142008p155997.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal

2013-05-30 Thread Robert Winkler

On Thu, May 30, 2013 at 7:47 AM, Andrew Gabbasov andrew_gabba...@mentor.com
 wrote:

 The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
 (shifted and or'ed with chip select), so it's incorrect to pass
 that macro directly as an argument to gpio_direction_output() call.

 Also, SPI driver sets the direction and initial value of a gpio,
 used as a chip select signal, before any actual activity happens
 on the bus.

 So, it is safe to just remove the gpio_direction_output call,
 that works incorrectly, thus making no effect, anyway.

 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
  board/boundary/nitrogen6x/nitrogen6x.c|1 -
  board/freescale/mx6qsabrelite/mx6qsabrelite.c |1 -
  2 files changed, 2 deletions(-)

 diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
 b/board/boundary/nitrogen6x/nitrogen6x.c
 index cc071d6..735fd76 100644
 --- a/board/boundary/nitrogen6x/nitrogen6x.c
 +++ b/board/boundary/nitrogen6x/nitrogen6x.c
 @@ -342,7 +342,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
 -   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
 imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
  ARRAY_SIZE(ecspi1_pads));
  }
 diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
 b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
 index 9f9cac8..29815d7 100644
 --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
 +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
 @@ -312,7 +312,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
 -   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
 imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
  ARRAY_SIZE(ecspi1_pads));
  }
 --
 1.7.10.4

 Works for me for all Tegra builds, so:

Tested-by: Robert Winkler robert.wink...@boundarydevices.com

Tested on the Sabre Lite.




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

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

Re: [U-Boot] [PATCH] Add splash screen support via loading from flash

Dear Robert Winkler,

In message 
1369947781-25077-1-git-send-email-robert.wink...@boundarydevices.com you 
wrote:
 Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
 ---
  board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
  include/configs/nitrogen6x.h   | 11 ++-
  2 files changed, 32 insertions(+), 1 deletion(-)

Could you please explain why you need custom code here?

What exactly cannot be done wioth the existing features?


BTW: it would be nice if you flag board specific code in the Subject:,
and it is considered mandatory to Cc: the respective board maintainer.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Doubt isn't the opposite of faith; it is an element of faith.
- Paul Tillich, German theologian and historian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add splash screen support via loading from flash

2013-05-30 Thread Robert Winkler

On Thu, May 30, 2013 at 4:32 PM, Wolfgang Denk w...@denx.de wrote:

Dear Robert Winkler,

In message
1369947781-25077-1-git-send-email-robert.wink...@boundarydevices.com you
wrote:
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
include/configs/nitrogen6x.h | 11 ++-
2 files changed, 32 insertions(+), 1 deletion(-)

Could you please explain why you need custom code here?

I originally tried to use the CONFIG_SPLASH_SCREEN_PREPARE functionality.
After some frustration, I figured out that without CONFIG_LCD, it is never
actually called.
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=blob;f=common/stdio.c;h=5d5117c0ed838195a2caad7c28c128247771cd92;hb=HEAD#l216

It does seem odd that there are 2 totally different paths and the other
splash screen related macros are used in both but the prepare function is
only called in the LCD case.

Since we use CONFIG_VIDEO and not CONFIG_LCD, this seemed to be the best,
or at least the least invasive, solution.

What exactly cannot be done wioth the existing features?

BTW: it would be nice if you flag board specific code in the Subject:,
and it is considered mandatory to Cc: the respective board maintainer.

I apologize for that. I'm new and didn't know till after I'd already sent
it. I did CC the board maintainer, Eric. We also went over the code in
person.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Doubt isn't the opposite of faith; it is an element of faith.
- Paul Tillich, German theologian and historian

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

Re: [U-Boot] Conflict resolution for u-boot-arm/master and u-boot/master merge

Hi Albert,

On Thu, May 30, 2013 at 10:37 AM, Albert ARIBAUD
albert.u.b...@aribaud.netwrote:

 Hi Simon,

 On Thu, 30 May 2013 09:38:56 -0700, Simon Glass s...@chromium.org
 wrote:

  Hi Albert,
 
  On Thu, May 30, 2013 at 9:21 AM, Albert ARIBAUD
  albert.u.b...@aribaud.netwrote:
 
   On Thu, 30 May 2013 14:55:41 +0200, Albert ARIBAUD
   albert.u.b...@aribaud.net wrote:
  
Hello Tom and Bo,
   
While preparing for my ARM PR, I have encountered two merge
 conflicts.
Their resolution can be found in branch 'merge_from_mainline' of ARM
repo git://git.denx.de/u-boot-arm.
   
For common/cmd_fpga.c, the merge conflict was trivial -- Simon's
renaming fit somehow caused a need for manual resolution just to
select the version with the right name. Simon, can you confirm that
 my
resolution is correct?
  
   ... actually adding Simon as To:...
  
 
  Yes this looks right thanks.

 Thanks for your confirmation.

  Although I do wonder if you mean that I renamed 'fit', or I had a
 renaming
  fit.

 Phew! I was wondering if that one had gone below everyone's radars. :)


If you recall I had a renaming fit with bss_end, this was just a tic.

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

Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state

On Mon, May 06, 2013 at 03:17:45PM +0200, Andre Przywara wrote:
 A prerequisite for using virtualization is to be in HYP mode, which
 requires the CPU to be in non-secure state.
 Introduce a monitor handler routine which switches the CPU to
 non-secure state by setting the NS and associated bits.
 According to the ARM ARM this should not be done in SVC mode, so we
 have to setup a SMC handler for this. We reuse the current vector
 table for this and make sure that we only access the MVBAR register
 if the CPU supports the security extension and only if we
 configured the board to use it, since boards entering u-boot already
 in non-secure mode would crash on accessing MVBAR otherwise.
 
 Signed-off-by: Andre Przywara andre.przyw...@linaro.org
 ---
  arch/arm/cpu/armv7/start.S | 31 ---
  1 file changed, 28 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
 index e9e57e6..da48b36 100644
 --- a/arch/arm/cpu/armv7/start.S
 +++ b/arch/arm/cpu/armv7/start.S
 @@ -155,6 +155,13 @@ reset:
   /* Set vector address in CP15 VBAR register */
   ldr r0, =_start
   mcr p15, 0, r0, c12, c0, 0  @Set VBAR
 +
 +#ifdef CONFIG_ARMV7_VIRT
 + mrc p15, 0, r1, c0, c1, 1   @ check for security extension
 + andsr1, r1, #0x30
 + mcrne   p15, 0, r0, c12, c0, 1  @ Set secure monitor MVBAR

Hmm, this smells a bit simplified to me.

Support for ARMv7_VIRT should easy to integrate into u-boot even for
platforms that do not boot U-boot directly into secure mode (OMAP5 GP
platforms are such an example).  In this case you cannot assume that you
can write the secure monitor mvbar.

 +#endif
 +
  #endif
  
   /* the mask ROM code should have PLL and others stable */
 @@ -257,6 +264,12 @@ ENTRY(c_runtime_cpu_setup)
   ldr r0, =_start
   mcr p15, 0, r0, c12, c0, 0  @Set VBAR
  
 +#ifdef CONFIG_ARMV7_VIRT
 + mrc p15, 0, r1, c0, c1, 1   @ check for security extension
 + andsr1, r1, #0x30
 + mcrne   p15, 0, r0, c12, c0, 1  @ Set secure monitor MVBAR
 +#endif
 +
   bx  lr
  
  ENDPROC(c_runtime_cpu_setup)
 @@ -490,11 +503,23 @@ undefined_instruction:
   bad_save_user_regs
   bl  do_undefined_instruction
  
 +/*
 + * software interrupt aka. secure monitor handler
 + * This is executed on a smc instruction, we use a smc #0 to switch
 + * to non-secure state
 + */
   .align  5
  software_interrupt:
 - get_bad_stack_swi
 - bad_save_user_regs
 - bl  do_software_interrupt

Why is the following block not conditional on CONFIG_ARMV7_VIRT?

Again, it feels a bit funny to modify this generic mechanism to contain
this code for boards that boot in NS mode but have a way to enter Hyp
mode using an HVC or SMC instruction.

 + mrc p15, 0, r1, c1, c1, 0   @ read SCR
 + bic r1, r1, #0x07f
 + orr r1, r1, #0x31   @ enable NS, AW, FW

Are you sure you want to always route FIQ to non-secure here?

Don't you need to set the HCE bit?  The whole register resets to
0register resets to zero.

 +
 + mrc p15, 0, r0, c12, c0, 0  @ save secure copy of VBAR
 + mcr p15, 0, r1, c1, c1, 0   @ write SCR, switch to non-sec

Not quite a swith to non-sec; you're still in monitor mode.

 + isb
 + mcr p15, 0, r0, c12, c0, 0  @ write non-secure copy of VBAR

I don't actually think that you are, I think you're writing the secure
copy here.

In that case, I'm also wondering if the isb is superflous, because we
perform an exception return below, but we of course want to make damn
sure that the write of the NS bit is set before the exception return,
maybe some ARM guys have the right expertise here.

 +
 + movspc, lr

This movs is pretty drastic, because it changes from secure to
non-secure world, and yes, you can tell by looking at the orr
instruction above, but I would prefer a (potentially big fat) comment
here as well.

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

Re: [U-Boot] fopen/fwrite functions

2013-05-30 Thread TigerLiu

Dear Denk:
Got it!
Thank you!

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

[U-Boot] readl / writel function questions

2013-05-30 Thread TigerLiu

Hi, experts:
I wrote a driver for uboot.
This driver called writel/readl function.
I have included include/asm/io.h.

But when i compiled , it output below error msgs:
undefined reference to `__readwrite_bug'

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

Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal

2013-05-30 Thread Dirk Behme


On 30.05.2013 16:47, Andrew Gabbasov wrote:

The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro
(shifted and or'ed with chip select), so it's incorrect to pass
that macro directly as an argument to gpio_direction_output() call.

Also, SPI driver sets the direction and initial value of a gpio,
used as a chip select signal, before any actual activity happens
on the bus.

So, it is safe to just remove the gpio_direction_output call,
that works incorrectly, thus making no effect, anyway.

Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
  board/boundary/nitrogen6x/nitrogen6x.c|1 -
  board/freescale/mx6qsabrelite/mx6qsabrelite.c |1 -
  2 files changed, 2 deletions(-)

diff --git a/board/boundary/nitrogen6x/nitrogen6x.c 
b/board/boundary/nitrogen6x/nitrogen6x.c
index cc071d6..735fd76 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -342,7 +342,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
  }
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 9f9cac8..29815d7 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -312,7 +312,6 @@ iomux_v3_cfg_t const ecspi1_pads[] = {

  void setup_spi(void)
  {
-   gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);
imx_iomux_v3_setup_multiple_pads(ecspi1_pads,
 ARRAY_SIZE(ecspi1_pads));
  }



Acked-by: Dirk Behme dirk.be...@de.bosch.com

Thanks

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

Re: [U-Boot] [PATCH 2/6] ARM: add assembly routine to switch to non-secure state

On Mon, May 06, 2013 at 03:17:46PM +0200, Andre Przywara wrote:
 While actually switching to non-secure state is one thing, the
 more important part of this process is to make sure that we still
 have full access to the interrupt controller (GIC).
 The GIC is fully aware of secure vs. non-secure state, some
 registers are banked, others may be configured to be accessible from
 secure state only.
 To be as generic as possible, we get the GIC memory mapped address
 based on the PERIPHBASE register. We check explicitly for
 ARM Cortex-A7 and A15 cores, assuming an A9 otherwise, as for those
 cores we know the offsets for the GIC CPU interface from the
 PERIPHBASE content. Other cores could be added as needed.
 
 With the GIC accessible, we:
 a) allow private interrupts to be delivered to the core
(GICD_IGROUPR0 = 0x)
 b) enable the CPU interface (GICC_CTLR[0] = 1)
 c) set the priority filter to allow non-secure interrupts
(GICC_PMR = 0x80)
 
 After having switched to non-secure state, we also enable the
 non-secure GIC CPU interface, since this register is banked.
 
 Also we allow access to all coprocessor interfaces from non-secure
 state by writing the appropriate bits in the NSACR register.
 
 For reasons obvious later we only use caller saved registers r0-r3.

You probably want to put that in a comment in the code, and it would
also be super helpful to explain the obvious part here, because most
readers don't look forward in time to understand this patch...

 
 Signed-off-by: Andre Przywara andre.przyw...@linaro.org
 ---
  arch/arm/cpu/armv7/start.S | 47 
 ++
  1 file changed, 47 insertions(+)
 
 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
 index da48b36..e63e892 100644
 --- a/arch/arm/cpu/armv7/start.S
 +++ b/arch/arm/cpu/armv7/start.S
 @@ -572,3 +572,50 @@ fiq:
  
  #endif /* CONFIG_USE_IRQ */
  #endif /* CONFIG_SPL_BUILD */
 +
 +#ifdef CONFIG_ARMV7_VIRT
 +/* Routine to initialize GIC CPU interface and switch to nonsecure state.
 + */
 +.globl _nonsec_gic_switch
 +_nonsec_gic_switch:
 + mrc p15, 4, r2, c15, c0, 0  @ r2 = PERIPHBASE

You should probably check if bits [7:0] == 0x00 here, otherwise you may
end up doing some very strange stuff - if any of those bits are set you
can just error out at this point, but it should be gracefully handled.

Also since it's core specific, you'd probably want to check that before
using it.

 + add r3, r2, #0x1000 @ GIC dist i/f offset

Since this is core specific, could the offset please go in an
appropriate header file?  It will also eliminate the need for the
comment if you just have a proper define (i.e. GIC_DIST_OFFSET ...)

 + mvn r1, #0
 + str r1, [r3, #0x80] @ allow private interrupts

Aren't you makeing an assumption about the number of available
interrupts here?  You should read the ITLinesNumber field from the
GICD_TYPER if I'm not mistaking.

I also think it would be much cleaner if you again used a define for the
0x80 offset.

Also, don't you need to set some enable fields on the GICD_CTLR here to
enable group 1 interrupts?

 +
 + mrc p15, 0, r0, c0, c0, 0   @ MIDR
 + bfc r0, #16, #8 @ mask out variant, arch
 + bfc r0, #0, #4  @ and revision
 + movwr1, #0xc070
 + movtr1, #0x4100
 + cmp r0, r1  @ check for Cortex-A7
 + orr r1, #0xf0

wow, nice bit fiddling.  It may be quite a bit easier to read if you
simply had defines for the bitmasks and real values and just did a load
and placed a literal section accordingly.

 + cmpne   r0, r1  @ check for Cortex-A15
 + movne   r1, #0x100  @ GIC CPU offset for A9

So I read the ARMV7_VIRT config flag as something you can only enable on
a board that actually supports the virtulization extensions, which the
A9 doesn't so this should probably error out instead (or do an endless
loop, or ignore the case in the code, ...).

 + moveq   r1, #0x2000 @ GIC CPU offset for A15/A7

Again, I think defines for these are appropriate.

 + add r3, r2, r1  @ r3 = GIC CPU i/f addr
 +
 + mov r1, #1
 + str r1, [r3, #0]@ set GICC_CTLR[enable]
 + mov r1, #0x80

Why are you not setting this to #0xff ?

 + str r1, [r3, #4]@ set GICC_PIMR[7]
 +

here it seems we're moving into non-gic related stuff in a function
called _nonsec_gic_switch

 + movwr1, #0x3fff
 + movtr1, #0x0006
 + mcr p15, 0, r1, c1, c1, 2   @ NSACR = all copros to non-sec
 +
 + ldr r1, =_start
 + mcr p15, 0, r1, c12, c0, 0  @ set VBAR
 + mcr p15, 0, r1, c12, c0, 1  @ set MVBAR

I thought you already took care of the MVBAR during init?
 +
 + isb
 +

Re: [U-Boot] [PATCH 3/6] ARM: switch to non-secure state during bootm execution

On Mon, May 06, 2013 at 03:17:47PM +0200, Andre Przywara wrote:
 To actually trigger the non-secure switch we just implemented, call
 the switching routine from within the bootm command implementation.
 This way we automatically enable this feature without further user
 intervention.
 
 Some part of the work is done in the assembly routine in start.S,
 introduced with the previous patch, but for the full glory we need
 to setup the GIC distributor interface once for the whole system,
 which is done in C here.
 The routine is placed in arch/arm/lib to allow easy access from
 different boards or CPUs.

I'm beginning to loose track of exactly which parts is in assembly and
which parts are in C, and why.  We are fiddling with some gic dist.
settings in assembly, and some of them in C as well.

I think it's just the ordering or naming of the patches that is a little
confusing.

 
 First we check for the availability of the security extensions.
 
 The generic timer base frequency register is only accessible from
 secure state, so we have to program it now. Actually this should be
 done from primary firmware before, but some boards seems to omit
 this, so if needed we do this here with a board specific value.
 
 Since we need a safe way to access the GIC, we use the PERIPHBASE
 registers on Cortex-A15 and A7 CPUs and do some sanity checks.
 
 Then we actually do the GIC enablement:
 a) enable the GIC distributor, both for non-secure and secure state
(GICD_CTLR[1:0] = 11b)
 b) allow all interrupts to be handled from non-secure state
(GICD_IGROUPRn = 0x)
 The core specific GIC setup is then done in the assembly routine.
 
 The actual bootm trigger is pretty small: calling the routine and
 doing some error reporting. A return value of 1 will be added later.
 
 To enable the whole code we introduce the CONFIG_ARMV7_VIRT variable.
 
 Signed-off-by: Andre Przywara andre.przyw...@linaro.org
 ---
  arch/arm/include/asm/armv7.h |   7 +++
  arch/arm/lib/Makefile|   2 +
  arch/arm/lib/bootm.c |  20 
  arch/arm/lib/virt-v7.c   | 113 
 +++
  4 files changed, 142 insertions(+)
  create mode 100644 arch/arm/lib/virt-v7.c
 
 diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
 index a73630b..25afffe 100644
 --- a/arch/arm/include/asm/armv7.h
 +++ b/arch/arm/include/asm/armv7.h
 @@ -74,4 +74,11 @@ void v7_outer_cache_inval_all(void);
  void v7_outer_cache_flush_range(u32 start, u32 end);
  void v7_outer_cache_inval_range(u32 start, u32 end);
  
 +#ifdef CONFIG_ARMV7_VIRT
 +int armv7_switch_nonsec(void);
 +
 +/* defined in cpu/armv7/start.S */
 +void _nonsec_gic_switch(void);
 +#endif /* CONFIG_ARMV7_VIRT */
 +
  #endif
 diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
 index 6ae161a..37a0e71 100644
 --- a/arch/arm/lib/Makefile
 +++ b/arch/arm/lib/Makefile
 @@ -58,6 +58,8 @@ COBJS-y += reset.o
  COBJS-y  += cache.o
  COBJS-y  += cache-cp15.o
  
 +COBJS-$(CONFIG_ARMV7_VIRT) += virt-v7.o
 +
  SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
  $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
  OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
 diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
 index f3b30c5..a3d3aae 100644
 --- a/arch/arm/lib/bootm.c
 +++ b/arch/arm/lib/bootm.c
 @@ -35,6 +35,10 @@
  #include asm/bootm.h
  #include linux/compiler.h
  
 +#ifdef CONFIG_ARMV7_VIRT
 +#include asm/armv7.h
 +#endif
 +
  DECLARE_GLOBAL_DATA_PTR;
  
  #if defined(CONFIG_SETUP_MEMORY_TAGS) || \
 @@ -319,6 +323,22 @@ static void boot_prep_linux(bootm_headers_t *images)
   hang();
  #endif /* all tags */
   }
 +#ifdef CONFIG_ARMV7_VIRT
 + switch (armv7_switch_nonsec()) {
 + case 0:
 + debug(entered non-secure state\n);
 + break;
 + case 2:
 + printf(HYP mode: Security extensions not implemented.\n);
 + break;
 + case 3:
 + printf(HYP mode: CPU not supported (must be Cortex-A15 or 
 A7).\n);

I would drop the specifics of what's supported here.

 + break;
 + case 4:
 + printf(HYP mode: PERIPHBASE is above 4 GB, cannot access 
 this.\n);
 + break;
 + }

I think these hard-coded numbers are a bit ugly, either define an enum
or some defines somewhere, or just make the armv7_switch_nonsec return a
boolean value and put the prints in there.

That will also make it easier to read the other function and not go
return 2 hmmm, I wonder what that means ;)

 +#endif
  }
  
  /* Subcommand: GO */
 diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c
 new file mode 100644
 index 000..3a48aee
 --- /dev/null
 +++ b/arch/arm/lib/virt-v7.c
 @@ -0,0 +1,113 @@
 +/*
 + * (C) Copyright 2013
 + * Andre Przywara, Linaro
 + *
 + * routines to push ARMv7 processors from secure into non-secure state
 + * needed to enable ARMv7 virtualization for current hypervisors

Nits: Routines should be capitalized.

Re: [U-Boot] [PATCH 5/6] ARM: extend non-secure switch to also go into HYP mode

On Mon, May 06, 2013 at 03:17:49PM +0200, Andre Przywara wrote:
 For the KVM and XEN hypervisors to be usable, we need to enter the
 kernel in HYP mode. Now that we already are in non-secure state,
 HYP mode switching is within short reach.
 
 While doing the non-secure switch, we have to enable the HVC
 instruction and setup the HYP mode HVBAR (while still secure).
 
 The actual switch is done by dropping back from a HYP mode handler
 without actually leaving HYP mode, so we introduce a new handler
 routine in the exception vector table.
 
 In the assembly switching routine - which we rename to hyp_gic_switch
 on the way - we save and restore the banked LR and SP registers
 around the hypercall to do the actual HYP mode switch.
 
 The C routine first checks whether we are in HYP mode already and
 also whether the virtualization extensions are available. It also
 checks whether the HYP mode switch was finally successful.
 The bootm command part only adds and adjusts some error reporting.
 
 Signed-off-by: Andre Przywara andre.przyw...@linaro.org
 ---
  arch/arm/cpu/armv7/start.S   | 34 +++---
  arch/arm/include/asm/armv7.h |  4 ++--
  arch/arm/lib/bootm.c | 12 +---
  arch/arm/lib/virt-v7.c   | 22 +++---
  4 files changed, 49 insertions(+), 23 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
 index 02234c7..921e9d9 100644
 --- a/arch/arm/cpu/armv7/start.S
 +++ b/arch/arm/cpu/armv7/start.S
 @@ -41,7 +41,7 @@ _start: b   reset
   ldr pc, _software_interrupt
   ldr pc, _prefetch_abort
   ldr pc, _data_abort
 - ldr pc, _not_used
 + ldr pc, _hyp_trap
   ldr pc, _irq
   ldr pc, _fiq
  #ifdef CONFIG_SPL_BUILD
 @@ -49,7 +49,7 @@ _undefined_instruction: .word _undefined_instruction
  _software_interrupt: .word _software_interrupt
  _prefetch_abort: .word _prefetch_abort
  _data_abort: .word _data_abort
 -_not_used:   .word _not_used
 +_hyp_trap:   .word _hyp_trap
  _irq:.word _irq
  _fiq:.word _fiq
  _pad:.word 0x12345678 /* now 16*4=64 */
 @@ -58,7 +58,7 @@ _undefined_instruction: .word undefined_instruction
  _software_interrupt: .word software_interrupt
  _prefetch_abort: .word prefetch_abort
  _data_abort: .word data_abort
 -_not_used:   .word not_used
 +_hyp_trap:   .word hyp_trap
  _irq:.word irq
  _fiq:.word fiq
  _pad:.word 0x12345678 /* now 16*4=64 */
 @@ -513,12 +513,18 @@ software_interrupt:
   mrc p15, 0, r1, c1, c1, 0   @ read SCR
   bic r1, r1, #0x07f
   orr r1, r1, #0x31   @ enable NS, AW, FW
 + mrc p15, 0, r0, c0, c1, 1   @ check for Virt ext
 + and r0, r0, #0xf000
 + cmp r0, #0x1000

you can just do ands r0, r0 ,#0xf000 and change the orreq below to orrne

 + orreq   r1, r1, #0x100  @ allow HVC instruction
  
   mrc p15, 0, r0, c12, c0, 0  @ save secure copy of VBAR
   mcr p15, 0, r1, c1, c1, 0   @ write SCR, switch to non-sec
   isb
   mcr p15, 0, r0, c12, c0, 0  @ write non-secure copy of VBAR
  
 + mcreq   p15, 4, r0, c12, c0, 0  @ write HYP mode HVBAR
 +

nit: s/HYP mode//

   movspc, lr
  
   .align  5
 @@ -534,10 +540,9 @@ data_abort:
   bl  do_data_abort
  
   .align  5
 -not_used:
 - get_bad_stack
 - bad_save_user_regs
 - bl  do_not_used
 +hyp_trap:
 + .byte 0x00, 0xe3, 0x0e, 0xe1@ mrs lr, elr_hyp

do we really need to support this on assemblers that old?

 + mov pc, lr
  
  #ifdef CONFIG_USE_IRQ
  
 @@ -574,21 +579,21 @@ fiq:
  #endif /* CONFIG_SPL_BUILD */
  
  #ifdef CONFIG_ARMV7_VIRT
 -/* Routine to initialize GIC CPU interface and switch to nonsecure state.
 - * Will be executed directly by secondary CPUs after coming out of
 +/* Routine to initialize GIC CPU interface, switch to nonsecure and to HYP
 + * mode. Will be executed directly by secondary CPUs after coming out of

So now this routine does three different things in different context at
once, why?

   * WFI, or can be called directly by C code for CPU 0.
   * Those two paths mandate to not use any stack and to only use registers
   * r0-r3 to comply with both the C ABI and the requirement of SMP startup
   * code.
   */
 -.globl _nonsec_gic_switch
 +.globl _hyp_gic_switch
  .globl _smp_pen
  _smp_pen:
   mrs r0, cpsr
   orr r0, r0, #0xc0
   msr cpsr, r0@ disable interrupts
   mov lr, #0  @ clear LR to mark secondary
 -_nonsec_gic_switch:
 +_hyp_gic_switch:
   mrc p15, 4, r2, c15, c0, 0  @ r2 = PERIPHBASE
   add r3, r2, #0x1000 @ GIC dist

Re: [U-Boot] [PATCH 4/6] ARM: add SMP support for non-secure switch