Re: [U-Boot] [PATCH] arm: exynos: fix the div value for set_mmc_clk

2014-11-24 Thread Minkyu Kang
Hi,

On 20/11/14 17:17, Jaehoon Chung wrote:
 The most exynos used the  Ratio + 1 as div value.
 And value at register is Ratio.
 So if want to set exact value, it needs to subtract one.
 
 Value at register (Ratio) = div - 1
 
 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 ---
  arch/arm/cpu/armv7/exynos/clock.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
 b/arch/arm/cpu/armv7/exynos/clock.c
 index 4ecce44..6633ffe 100644
 --- a/arch/arm/cpu/armv7/exynos/clock.c
 +++ b/arch/arm/cpu/armv7/exynos/clock.c
 @@ -1654,6 +1654,12 @@ unsigned long get_mmc_clk(int dev_index)
  
  void set_mmc_clk(int dev_index, unsigned int div)
  {
 + /*
 +  * If want to set correct value, it needs to substract one from div.
 +  */

wrong comment style

 + if (div  0)
 + div -= 1;

On trats2 and odroid dts file, div value is set to 0x3.
Then should it modified to 0x4 after applied this patch?

 +
   if (cpu_is_exynos5()) {
   if (proid_is_exynos5420() || proid_is_exynos5800())
   exynos5420_set_mmc_clk(dev_index, div);
 

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


Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning

2014-11-24 Thread Lukasz Majewski
Hi Albert,

 Hi Albert,
 
 Sorry for a late reply.
 
  Hello Lukasz,
  
  On Sat, 22 Nov 2014 07:56:35 +0100, Lukasz Majewski
  l.majew...@majess.pl wrote:
  
Agreed in general, but not for this one, since fixing is the
carpet, 
   
   I assume that you are presenting below an answer to a general
   case.
   
   However, as Thomas pointed out earlier, this fix is perfectly
   safe regarding the underlying kwbimage code.
  
  Jeroen and I (full disclaimer: we have discussed the topic on IRC)
  do not contend that the proposed fix would be unsafe; it *is* safe,
  i.e. it does not adversely affect the code behavior in any
  measurable way.
  
  What we contend is that the fix be the /right/ fix (although Jeroen
  and I have slightly differing criteria for defining what the right
  fix would be).
  
 and
 the only justification I see as acceptable for doing so is
 when leaving the warning enabled would cause an obnoxiously
 high number of false positives.

Well let me add, if fixing the warning causes real error
to be hidden, we shouldn't fix the warnings by modifying
valid code.
   
   Each subsequent fix for this kind of warning should be
   considered case by case IMHO, therefore I agree with Albert.
  
  Jeroen also agreed on IRC that disabling the compiler warning is not
  the right fix either; and I agreed that there had to be a better fix
  than pseudo-initializing headersz. I therefore suggested refactoring
  kwbimage_set_header in order to ensure gcc does not emit the
  warning, but without resorting to non-functional code such as a
  functionally meaningless initialization.
  
  Problem is, to refactor the code, one needs a gcc which emits the
  warnig. I tried various versions of gcc (4.7.4, 4.8.3, 4.9.1) and
  all remained silent when compiling tools/kwbimage.c.
  
  Hence my request: Lukasz, which toolchain are you using exactly?
  Where can we download it from?
 
 The warning appear on my personal laptop too:
 
 lukma@jawa:~/work/embedded/u-boot-denx (master)$ cc -v
 Using built-in specs.
 COLLECT_GCC=cc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
 Target: x86_64-linux-gnu
 Configured with: ../src/configure -v --with-pkgversion='Debian
 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
 --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
 --program-suffix=-4.7 --enable-shared --enable-linker-build-id
 --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
 --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-libstdcxx-time=yes
 --enable-gnu-unique-object --enable-plugin --enable-objc-gc
 --with-arch-32=i586 --with-tune=generic --enable-checking=release
 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
 --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2
 (Debian 4.7.2-5) 
 
 
   HOSTCC  tools/kwbimage.o
 tools/kwbimage.c: In function ‘kwbimage_set_header’:
 tools/kwbimage.c:803:8: warning: ‘headersz’ may be used uninitialized
 in this function [-Wmaybe-uninitialized]
 
 Debian distro: version 7.6 (Wheezy)
 
 
 I will check the exact gcc on my office PC tomorrow.

On my office PC I've got following gcc:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian
4.7.2-5

I've got a stable debian (Wheezy - 7.4)

 
 
 Heiko also complained about this Warning. Heiko could you also share
 information about your setup?
 
  
Regards,
Jeroen
   
   Best regards,
   Lukasz Majewski
  
  Amicalement,
 
 Best regards,
 Lukasz Majewski


-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] fix: tools: kwbimage.c: Initialize headersz to suppress warning

2014-11-24 Thread Guillaume Gardet

Hi,

Le 23/11/2014 18:38, Lukasz Majewski a écrit :

Hi Albert,

Sorry for a late reply.


Hello Lukasz,

On Sat, 22 Nov 2014 07:56:35 +0100, Lukasz Majewski
l.majew...@majess.pl wrote:


Agreed in general, but not for this one, since fixing is the
carpet,

I assume that you are presenting below an answer to a general
case.

However, as Thomas pointed out earlier, this fix is perfectly safe
regarding the underlying kwbimage code.

Jeroen and I (full disclaimer: we have discussed the topic on IRC)
do not contend that the proposed fix would be unsafe; it *is* safe,
i.e. it does not adversely affect the code behavior in any measurable
way.

What we contend is that the fix be the /right/ fix (although Jeroen
and I have slightly differing criteria for defining what the right
fix would be).


and
the only justification I see as acceptable for doing so is when
leaving the warning enabled would cause an obnoxiously high
number of false positives.

Well let me add, if fixing the warning causes real error
to be hidden, we shouldn't fix the warnings by modifying
valid code.

Each subsequent fix for this kind of warning should be considered
case by case IMHO, therefore I agree with Albert.

Jeroen also agreed on IRC that disabling the compiler warning is not
the right fix either; and I agreed that there had to be a better fix
than pseudo-initializing headersz. I therefore suggested refactoring
kwbimage_set_header in order to ensure gcc does not emit the warning,
but without resorting to non-functional code such as a functionally
meaningless initialization.

Problem is, to refactor the code, one needs a gcc which emits the
warnig. I tried various versions of gcc (4.7.4, 4.8.3, 4.9.1) and all
remained silent when compiling tools/kwbimage.c.

Hence my request: Lukasz, which toolchain are you using exactly? Where
can we download it from?

The warning appear on my personal laptop too:

lukma@jawa:~/work/embedded/u-boot-denx (master)$ cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian
4.7.2-5)


   HOSTCC  tools/kwbimage.o
tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:803:8: warning: ‘headersz’ may be used uninitialized
in this function [-Wmaybe-uninitialized]

Debian distro: version 7.6 (Wheezy)


I also have this warning on my openSUSE 13.1 (GCC 4.8.1). If it could help, gcc 
-v returns:
**
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 
--enable-ssp --disable-libssp --disable-plugin 
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' 
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib 
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --enable-linker-build-id 
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind 
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)
**



Guillaume

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


[U-Boot] [PATCH 2/9 v2] powerpc/mpc85xx: Add T1024/T1023 SoC support

2014-11-24 Thread Shengzhou Liu
Add support for Freescale T1024/T1023 SoC.

The T1024 SoC includes the following function and features:
- Two 64-bit Power architecture e5500 cores, up to 1.4GHz
- private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC)
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving 
support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI)
- High-speed peripheral interfaces
  - Three PCI Express 2.0 controllers
- Additional peripheral interfaces
  - One SATA 2.0 controller
  - Two USB 2.0 controllers with integrated PHY
  - Enhanced secure digital host controller (SD/eSDHC/eMMC)
  - Enhanced serial peripheral interface (eSPI)
  - Four I2C controllers
  - Four 2-pin UARTs or two 4-pin UARTs
  - Integrated Flash Controller supporting NAND and NOR flash
- Two 8-channel DMA engines
- Multicore programmable interrupt controller (PIC)
- LCD interface (DIU) with 12 bit dual data rate
- QUICC Engine block supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0

Differences between T1024 and T1023:
  Feature T1024  T1023
  QUICC Engine:   yesno
  DIU:yesno
  Deep Sleep: yesno
  I2C controller: 4  3
  DDR:64-bit 32-bit
  IFC:32-bit 28-bit

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: add new serdes 0x135 and 0x119 in t1024_serdes.c

 arch/powerpc/cpu/mpc85xx/Makefile  |  4 ++
 arch/powerpc/cpu/mpc85xx/speed.c   | 12 +++-
 arch/powerpc/cpu/mpc85xx/t1024_ids.c   | 82 
 arch/powerpc/cpu/mpc85xx/t1024_serdes.c| 52 ++
 arch/powerpc/cpu/mpc8xxx/cpu.c |  4 ++
 arch/powerpc/include/asm/config_mpc85xx.h  | 45 +++
 arch/powerpc/include/asm/fsl_secure_boot.h |  4 +-
 arch/powerpc/include/asm/immap_85xx.h  | 14 +
 arch/powerpc/include/asm/processor.h   |  4 ++
 drivers/net/fm/Makefile|  2 +
 drivers/net/fm/t1024.c | 88 ++
 11 files changed, 309 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_ids.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_serdes.c
 create mode 100644 drivers/net/fm/t1024.c

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index ad26b43..b93158b 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -51,6 +51,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_ids.o
 obj-$(CONFIG_PPC_T1042)+= t1040_ids.o
 obj-$(CONFIG_PPC_T1020)+= t1040_ids.o
 obj-$(CONFIG_PPC_T1022)+= t1040_ids.o
+obj-$(CONFIG_PPC_T1023) += t1024_ids.o
+obj-$(CONFIG_PPC_T1024) += t1024_ids.o
 obj-$(CONFIG_PPC_T2080) += t2080_ids.o
 obj-$(CONFIG_PPC_T2081) += t2080_ids.o
 
@@ -97,6 +99,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_serdes.o
 obj-$(CONFIG_PPC_T1042)+= t1040_serdes.o
 obj-$(CONFIG_PPC_T1020)+= t1040_serdes.o
 obj-$(CONFIG_PPC_T1022)+= t1040_serdes.o
+obj-$(CONFIG_PPC_T1023) += t1024_serdes.o
+obj-$(CONFIG_PPC_T1024) += t1024_serdes.o
 obj-$(CONFIG_PPC_T2080) += t2080_serdes.o
 obj-$(CONFIG_PPC_T2081) += t2080_serdes.o
 
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 8426b1a..5f0faef 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -168,6 +168,9 @@ void get_sys_info(sys_info_t *sys_info)
defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081)
 #define FM1_CLK_SEL0xe000
 #define FM1_CLK_SHIFT  29
+#elif defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023)
+#define FM1_CLK_SEL0x0007
+#define FM1_CLK_SHIFT  0
 #else
 #define PME_CLK_SEL0xe000
 #define PME_CLK_SHIFT  29
@@ -175,8 +178,12 @@ void get_sys_info(sys_info_t *sys_info)
 #define FM1_CLK_SHIFT  26
 #endif
 #if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV)
+#if defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023)
+   rcw_tmp = in_be32(gur-rcwsr[15]) - 4;
+#else
rcw_tmp = in_be32(gur-rcwsr[7]);
 #endif
+#endif
 
 #ifdef CONFIG_SYS_DPAA_PME
 #ifndef CONFIG_PME_PLAT_CLK_DIV
@@ -213,7 +220,10 @@ void get_sys_info(sys_info_t *sys_info)
 #endif
 
 #ifdef CONFIG_SYS_DPAA_QBMAN
-   sys_info-freq_qman = sys_info-freq_systembus / 2;
+#ifndef CONFIG_QBMAN_CLK_DIV
+#define CONFIG_QBMAN_CLK_DIV   2
+#endif
+   sys_info-freq_qman = sys_info-freq_systembus / CONFIG_QBMAN_CLK_DIV;
 #endif
 
 #ifdef CONFIG_SYS_DPAA_FMAN
diff --git a/arch/powerpc/cpu/mpc85xx/t1024_ids.c 
b/arch/powerpc/cpu/mpc85xx/t1024_ids.c
new file mode 100644
index 000..5f24c15
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/t1024_ids.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, 

[U-Boot] [PATCH 5/9 v2] net/fman: update 10GEC to fit new SoC

2014-11-24 Thread Shengzhou Liu
fm_standard_init() initializes each 10G port by FM_TGEC_INFO_INITIALIZER.
but it needs different implementation of FM_TGEC_INFO_INITIALIZER on different 
SoCs.
on SoCs earlier(e.g. T4240, T2080), the notation between 10GEC and MAC as below:
10GEC1-MAC9, 10GEC2-MAC10, 10GEC3-MAC1, 10GEC4-MAC2
on SoCs later(e.g. T1024, etc), the notation between 10GEC and MAC as below:
10GEC1-MAC1, 10GEC2-MAC2

so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to fit the new SoCs on
which 10GEC enumeration is consistent with MAC enumeration.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: refine the commit message and add readme document.

 arch/powerpc/include/asm/config_mpc85xx.h |  1 +
 arch/powerpc/include/asm/immap_85xx.h |  5 +
 doc/README.fsl-dpaa   | 10 ++
 drivers/net/fm/eth.c  |  7 +--
 drivers/net/fm/init.c |  2 ++
 include/fm_eth.h  | 15 +++
 6 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 doc/README.fsl-dpaa

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 9a8ebd7..7164ded 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -810,6 +810,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   4
 #define CONFIG_SYS_NUM_FM1_10GEC   1
+#define CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #define CONFIG_SYS_FSL_DDR_VER  FSL_DDR_VER_5_0
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index f58456f..361be6f 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1626,10 +1626,15 @@ typedef struct ccsr_gur {
 #define FSL_CORENET_DEVDISR2_DTSEC1_6  0x0400
 #define FSL_CORENET_DEVDISR2_DTSEC1_9  0x0080
 #define FSL_CORENET_DEVDISR2_DTSEC1_10 0x0040
+#ifdef CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
+#define FSL_CORENET_DEVDISR2_10GEC1_1   0x8000
+#define FSL_CORENET_DEVDISR2_10GEC1_2   0x4000
+#else
 #define FSL_CORENET_DEVDISR2_10GEC1_1  0x0080
 #define FSL_CORENET_DEVDISR2_10GEC1_2  0x0040
 #define FSL_CORENET_DEVDISR2_10GEC1_3  0x8000
 #define FSL_CORENET_DEVDISR2_10GEC1_4  0x4000
+#endif
 #define FSL_CORENET_DEVDISR2_DTSEC2_1  0x0008
 #define FSL_CORENET_DEVDISR2_DTSEC2_2  0x0004
 #define FSL_CORENET_DEVDISR2_DTSEC2_3  0x0002
diff --git a/doc/README.fsl-dpaa b/doc/README.fsl-dpaa
new file mode 100644
index 000..0d8d4f6
--- /dev/null
+++ b/doc/README.fsl-dpaa
@@ -0,0 +1,10 @@
+This file documents Freescale DPAA-specific options.
+
+FMan (Frame Manager)
+  - CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
+   on SoCs earlier(e.g. T4240, T2080), the notation between 10GEC and MAC 
as below:
+   10GEC1-MAC9, 10GEC2-MAC10, 10GEC3-MAC1, 10GEC4-MAC2
+   on SoCs later(e.g. T1024, etc), the notation between 10GEC and MAC as 
below:
+   10GEC1-MAC1, 10GEC2-MAC2
+   so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to identify the 
new SoCs on
+   which 10GEC enumeration is consistent with MAC enumeration.
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 137886c..f1e39b9 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -565,9 +565,11 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
num = fm_eth-num;
 
 #ifdef CONFIG_SYS_FMAN_V3
+#ifndef CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
if (fm_eth-type == FM_ETH_10G_E) {
-   /* 10GEC1/10GEC2 use mEMAC9/mEMAC10
-* 10GEC3/10GEC4 use mEMAC1/mEMAC2
+   /* 10GEC1/10GEC2 use mEMAC9/mEMAC10 on T2080/T4240.
+* 10GEC3/10GEC4 use mEMAC1/mEMAC2 on T2080.
+* 10GEC1 uses mEMAC1 on T1024.
 * so it needs to change the num.
 */
if (fm_eth-num = 2)
@@ -575,6 +577,7 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
else
num += 8;
}
+#endif
base = reg-memac[num].fm_memac;
phyregs = reg-memac[num].fm_memac_mdio;
 #else
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 6cf21c6..5d82f29 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -254,8 +254,10 @@ static void ft_fixup_port(void *blob, struct fm_eth_info 
*info, char *prop)
 */
if (((info-port == FM1_DTSEC9)  (PORT_IS_ENABLED(FM1_10GEC1)))  ||
((info-port == FM1_DTSEC10)  (PORT_IS_ENABLED(FM1_10GEC2))) ||
+   ((info-port == FM1_DTSEC1)  (PORT_IS_ENABLED(FM1_10GEC1)))  ||
((info-port == FM1_DTSEC1)  (PORT_IS_ENABLED(FM1_10GEC3)))  ||
((info-port == FM1_DTSEC2)  

[U-Boot] [PATCH 3/9 v2] powerpc/t1024qds: Add T1024 QDS board support

2014-11-24 Thread Shengzhou Liu
T1024QDS is a high-performance computing evaluation, development and
test platform for T1024 QorIQ Power Architecture processor.

T1024QDS board Overview
---
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving 
support
- Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC
- Ethernet interfaces:
  - Two 10M/100M/1G RGMII ports on-board
  - Three 1G/2.5Gbps SGMII ports
  - Four 1Gbps QSGMII ports
  - one 10Gbps XFI or 10Base-KR interface
- SerDes: 4 lanes up to 10.3125GHz Supporting SGMII/QSGMII, XFI, PCIe, SATA and 
Aurora
- PCIe: Three PCI Express controllers with five PCIe slots.
- IFC: 128MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA
- Video: DIU supports video up to 1280x1024x32 bpp.
  - Chrontel CH7201 for HDMI connection.
  - TI DS90C387R for direct LCD connection.
  - Raw (not encoded) video connector for testing or other encoders.
- QUICC Engine block
  - 32-bit RISC controller for flexible support of the communications 
peripherals
  - Serial DMA channel for receive and transmit on all serial channels
  - Two universal communication controllers, supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- eSPI: Three SPI flash devices.
- SATA: one SATA 2.O.
- USB: Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB)
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC.
- I2C: Four I2C controllers.
- UART: Two UART on board.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: removed diu.c by using common diu_ch7301.c

 arch/powerpc/cpu/mpc85xx/Kconfig  |   4 +
 board/freescale/t102xqds/Kconfig  |  12 +
 board/freescale/t102xqds/MAINTAINERS  |  10 +
 board/freescale/t102xqds/Makefile |  17 +
 board/freescale/t102xqds/README   | 328 +++
 board/freescale/t102xqds/ddr.c| 170 ++
 board/freescale/t102xqds/eth_t102xqds.c   | 442 ++
 board/freescale/t102xqds/law.c|  32 +
 board/freescale/t102xqds/pci.c|  23 +
 board/freescale/t102xqds/spl.c| 151 +
 board/freescale/t102xqds/t1024_pbi.cfg|  26 +
 board/freescale/t102xqds/t1024_rcw.cfg|  10 +
 board/freescale/t102xqds/t102xqds.c   | 319 ++
 board/freescale/t102xqds/t102xqds.h   |  14 +
 board/freescale/t102xqds/t102xqds_qixis.h |  61 ++
 board/freescale/t102xqds/tlb.c| 117 
 configs/T1024QDS_D4_SECURE_BOOT_defconfig |   4 +
 configs/T1024QDS_NAND_defconfig   |   5 +
 configs/T1024QDS_SDCARD_defconfig |   5 +
 configs/T1024QDS_SECURE_BOOT_defconfig|   4 +
 configs/T1024QDS_SPIFLASH_defconfig   |   5 +
 include/configs/T102xQDS.h| 936 ++
 22 files changed, 2695 insertions(+)
 create mode 100644 board/freescale/t102xqds/Kconfig
 create mode 100644 board/freescale/t102xqds/MAINTAINERS
 create mode 100644 board/freescale/t102xqds/Makefile
 create mode 100644 board/freescale/t102xqds/README
 create mode 100644 board/freescale/t102xqds/ddr.c
 create mode 100644 board/freescale/t102xqds/eth_t102xqds.c
 create mode 100644 board/freescale/t102xqds/law.c
 create mode 100644 board/freescale/t102xqds/pci.c
 create mode 100644 board/freescale/t102xqds/spl.c
 create mode 100644 board/freescale/t102xqds/t1024_pbi.cfg
 create mode 100644 board/freescale/t102xqds/t1024_rcw.cfg
 create mode 100644 board/freescale/t102xqds/t102xqds.c
 create mode 100644 board/freescale/t102xqds/t102xqds.h
 create mode 100644 board/freescale/t102xqds/t102xqds_qixis.h
 create mode 100644 board/freescale/t102xqds/tlb.c
 create mode 100644 configs/T1024QDS_D4_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024QDS_NAND_defconfig
 create mode 100644 configs/T1024QDS_SDCARD_defconfig
 create mode 100644 configs/T1024QDS_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024QDS_SPIFLASH_defconfig
 create mode 100644 include/configs/T102xQDS.h

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 7b42d06..c738a8c 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -110,6 +110,9 @@ config TARGET_P2041RDB
 config TARGET_QEMU_PPCE500
bool Support qemu-ppce500
 
+config TARGET_T102XQDS
+   bool Support T102xQDS
+
 config TARGET_T1040QDS
bool Support T1040QDS
 
@@ -183,6 +186,7 @@ source board/freescale/p2020come/Kconfig
 source board/freescale/p2020ds/Kconfig
 source board/freescale/p2041rdb/Kconfig
 source board/freescale/qemu-ppce500/Kconfig
+source board/freescale/t102xqds/Kconfig
 source board/freescale/t1040qds/Kconfig
 source board/freescale/t104xrdb/Kconfig
 source board/freescale/t208xqds/Kconfig
diff --git a/board/freescale/t102xqds/Kconfig b/board/freescale/t102xqds/Kconfig

[U-Boot] [PATCH 8/9 v2] t1024qds: increase IO drive strength

2014-11-24 Thread Shengzhou Liu
Increase IO drive strength to fix FCS error on RGMII ports
on T1024QDS.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: removed rdb.

 arch/powerpc/include/asm/immap_85xx.h | 3 +++
 board/freescale/t102xqds/t102xqds.c   | 4 
 2 files changed, 7 insertions(+)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 361be6f..ace1d12 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1803,6 +1803,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
 #define FSL_CORENET_RCWSR13_EC20x0c00
 #define FSL_CORENET_RCWSR13_EC2_RGMII  0x0800
 #define CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET0x28
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET0xd00
 #define PXCKEN_MASK0x8000
 #define PXCK_MASK  0x00FF
 #define PXCK_BITS_START16
@@ -2990,6 +2991,8 @@ struct ccsr_sfp_regs {
(CONFIG_SYS_CCSRBAR + CONFIG_SYS_FSL_SCFG_OFFSET)
 #define CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR\
(CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET)
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR \
+   (CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET)
 #define CONFIG_SYS_FSL_QMAN_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_QMAN_OFFSET)
 #define CONFIG_SYS_FSL_BMAN_ADDR \
diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index f7fc869..013024e 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -220,6 +220,10 @@ int board_early_init_r(void)
 #endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+
+   /* Increase IO drive strength to address FCS error on RGMII */
+   out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
+
return 0;
 }
 
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 4/9 v2] powerpc/t1024rdb: Add T1024 RDB board support

2014-11-24 Thread Shengzhou Liu
T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.

T1024RDB board Overview
---
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3L SDRAM memory controller with ECC and interleaving support
- Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC
- Ethernet interfaces:
  - Two 10M/100M/1G RGMII ports on-board
  - one 10Gbps XFI interface
- PCIe: Three PCIe controllers: one PCIe Slot and two Mini-PCIe connectors.
- SerDes: 4 lanes up to 10.3125GHz
- IFC: 128MB NOR Flash, 512MB NAND Flash and CPLD
- eSPI: 64MB N25Q512 SPI flash.
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- USB: Two  Type-A USB2.0 ports with internal PHY
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC
- I2C: Four I2C controllers
- UART: Two UART serial ports

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: no change.

 arch/powerpc/cpu/mpc85xx/Kconfig|   4 +
 board/freescale/t102xrdb/Kconfig|  12 +
 board/freescale/t102xrdb/MAINTAINERS|   9 +
 board/freescale/t102xrdb/Makefile   |  17 +
 board/freescale/t102xrdb/README | 258 +
 board/freescale/t102xrdb/cpld.c | 103 
 board/freescale/t102xrdb/cpld.h |  45 ++
 board/freescale/t102xrdb/ddr.c  | 154 ++
 board/freescale/t102xrdb/eth_t102xrdb.c | 100 
 board/freescale/t102xrdb/law.c  |  32 ++
 board/freescale/t102xrdb/pci.c  |  23 +
 board/freescale/t102xrdb/spl.c  | 107 
 board/freescale/t102xrdb/t1024_pbi.cfg  |  26 +
 board/freescale/t102xrdb/t1024_rcw.cfg  |   8 +
 board/freescale/t102xrdb/t102xrdb.c | 142 +
 board/freescale/t102xrdb/t102xrdb.h |  13 +
 board/freescale/t102xrdb/tlb.c  | 117 +
 configs/T1024RDB_NAND_defconfig |   5 +
 configs/T1024RDB_SDCARD_defconfig   |   5 +
 configs/T1024RDB_SECURE_BOOT_defconfig  |   4 +
 configs/T1024RDB_SPIFLASH_defconfig |   5 +
 configs/T1024RDB_defconfig  |   4 +
 include/configs/T102xRDB.h  | 896 
 23 files changed, 2089 insertions(+)
 create mode 100644 board/freescale/t102xrdb/Kconfig
 create mode 100644 board/freescale/t102xrdb/MAINTAINERS
 create mode 100644 board/freescale/t102xrdb/Makefile
 create mode 100644 board/freescale/t102xrdb/README
 create mode 100644 board/freescale/t102xrdb/cpld.c
 create mode 100644 board/freescale/t102xrdb/cpld.h
 create mode 100644 board/freescale/t102xrdb/ddr.c
 create mode 100644 board/freescale/t102xrdb/eth_t102xrdb.c
 create mode 100644 board/freescale/t102xrdb/law.c
 create mode 100644 board/freescale/t102xrdb/pci.c
 create mode 100644 board/freescale/t102xrdb/spl.c
 create mode 100644 board/freescale/t102xrdb/t1024_pbi.cfg
 create mode 100644 board/freescale/t102xrdb/t1024_rcw.cfg
 create mode 100644 board/freescale/t102xrdb/t102xrdb.c
 create mode 100644 board/freescale/t102xrdb/t102xrdb.h
 create mode 100644 board/freescale/t102xrdb/tlb.c
 create mode 100644 configs/T1024RDB_NAND_defconfig
 create mode 100644 configs/T1024RDB_SDCARD_defconfig
 create mode 100644 configs/T1024RDB_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024RDB_SPIFLASH_defconfig
 create mode 100644 configs/T1024RDB_defconfig
 create mode 100644 include/configs/T102xRDB.h

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index c738a8c..fcbc319 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -113,6 +113,9 @@ config TARGET_QEMU_PPCE500
 config TARGET_T102XQDS
bool Support T102xQDS
 
+config TARGET_T102XRDB
+   bool Support T102xRDB
+
 config TARGET_T1040QDS
bool Support T1040QDS
 
@@ -187,6 +190,7 @@ source board/freescale/p2020ds/Kconfig
 source board/freescale/p2041rdb/Kconfig
 source board/freescale/qemu-ppce500/Kconfig
 source board/freescale/t102xqds/Kconfig
+source board/freescale/t102xrdb/Kconfig
 source board/freescale/t1040qds/Kconfig
 source board/freescale/t104xrdb/Kconfig
 source board/freescale/t208xqds/Kconfig
diff --git a/board/freescale/t102xrdb/Kconfig b/board/freescale/t102xrdb/Kconfig
new file mode 100644
index 000..10d49f5
--- /dev/null
+++ b/board/freescale/t102xrdb/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_T102XRDB
+
+config SYS_BOARD
+   default t102xrdb
+
+config SYS_VENDOR
+   default freescale
+
+config SYS_CONFIG_NAME
+   default T102xRDB
+
+endif
diff --git a/board/freescale/t102xrdb/MAINTAINERS 
b/board/freescale/t102xrdb/MAINTAINERS
new file mode 100644
index 000..9f1a973
--- /dev/null
+++ b/board/freescale/t102xrdb/MAINTAINERS
@@ -0,0 +1,9 @@
+T102XRDB BOARD
+M: Shengzhou Liu  shengzhou@freescale.com
+S: Maintained
+F: board/freescale/t102xrdb/
+F: include/configs/T102xRDB.h
+F: configs/T1024RDB_defconfig
+F: configs/T1024RDB_NAND_defconfig

[U-Boot] [PATCH 7/9 v2] net/phy: enable serdes auto-negotiation for vsc8514 phy

2014-11-24 Thread Shengzhou Liu
VSC8514 QSGMII PHY requires enabling auto-negotiation,
otherwise it wouldn't work.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: updated copyright year.

 drivers/net/phy/vitesse.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2b29cd8..20a6746 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -1,8 +1,8 @@
 /*
  * Vitesse PHY drivers
  *
- * Copyright 2010-2012 Freescale Semiconductor, Inc.
- * Author: Andy Fleming
+ * Copyright 2010-2014 Freescale Semiconductor, Inc.
+ * Original Author: Andy Fleming
  * Add vsc8662 phy support - Priyanka Jain
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -50,6 +50,7 @@
 #define MIIM_VSC8574_18G_CMDSTAT   0x8000
 
 /* Vitesse VSC8514 control register */
+#define MIIM_VSC8514_MAC_SERDES_CON 0x10
 #define MIIM_VSC8514_GENERAL18 0x12
 #define MIIM_VSC8514_GENERAL19 0x13
 #define MIIM_VSC8514_GENERAL23 0x17
@@ -246,6 +247,14 @@ static int vsc8514_config(struct phy_device *phydev)
val = (val  0xf8ff);
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23, val);
 
+   /* Enable Serdes Auto-negotiation */
+   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
+ PHY_EXT_PAGE_ACCESS_EXTENDED3);
+   val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON);
+   val = val | MIIM_VSC8574_MAC_SERDES_ANEG;
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val);
+   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0);
+
genphy_config_aneg(phydev);
 
return 0;
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 6/9 v2] board/t1024qds: update pin multiplexing

2014-11-24 Thread Shengzhou Liu
Add multiplexing support among SPI flash, TDM riser card and SDXC.
it routes SPI pins to SPI flash by default.
Route SPI pins to SD slot if adaptor=sdxc is set in hwconfig.
Route SPI pins to TDM riser card and do fixup for dts if pin_mux=tdm
is set in hwconfig.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Xie Xiaobo x@freescale.com
Signed-off-by: Zhao Qiang b45...@freescale.com
---
v2: refine commit message.

 board/freescale/t102xqds/t102xqds.c   | 26 ++
 board/freescale/t102xqds/t102xqds_qixis.h |  7 +--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index f7af332..f7fc869 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -165,6 +165,8 @@ static void board_mux_setup(void)
/* Route QE_TDM multiplexed signals to TDM Riser slot */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_TDM);
QIXIS_WRITE(brdcfg[13], BRDCFG13_TDM_INTERFACE  2);
+   QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) 
+   ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_TDM);
} else if (hwconfig_arg_cmp(pin_mux, ucc)) {
/* to UCC (ProfiBus) interface */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_UCC);
@@ -176,6 +178,11 @@ static void board_mux_setup(void)
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_LCDFM |
BRDCFG15_LCDPD | BRDCFG15_DIUSEL_LCD);
}
+
+   if (hwconfig_arg_cmp(adaptor, sdxc))
+   /* Route SPI_CS multiplexed signals to SD slot */
+   QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) 
+   ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_SDHC);
 }
 #endif
 
@@ -265,6 +272,24 @@ int misc_init_r(void)
return 0;
 }
 
+void fdt_fixup_spi_mux(void *blob)
+{
+   int nodeoff = 0;
+
+   if (hwconfig_arg_cmp(pin_mux, tdm)) {
+   while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+   eon,en25s64)) = 0) {
+   fdt_del_node(blob, nodeoff);
+   }
+   } else {
+   /* remove tdm node */
+   while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+   maxim,ds26522)) = 0) {
+   fdt_del_node(blob, nodeoff);
+   }
+   }
+}
+
 void ft_board_setup(void *blob, bd_t *bd)
 {
phys_addr_t base;
@@ -291,6 +316,7 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_fman_ethernet(blob);
fdt_fixup_board_enet(blob);
 #endif
+   fdt_fixup_spi_mux(blob);
 }
 
 void qixis_dump_switch(void)
diff --git a/board/freescale/t102xqds/t102xqds_qixis.h 
b/board/freescale/t102xqds/t102xqds_qixis.h
index ad83f03..a429fb7 100644
--- a/board/freescale/t102xqds/t102xqds_qixis.h
+++ b/board/freescale/t102xqds/t102xqds_qixis.h
@@ -17,6 +17,9 @@
 #define BRDCFG5_IMX_MASK   0xC0
 #define BRDCFG5_IMX_DIU0x80
 
+#define BRDCFG5_SPIRTE_MASK0x07
+#define BRDCFG5_SPIRTE_TDM 0x01
+#define BRDCFG5_SPIRTE_SDHC0x02
 #define BRDCFG9_XFI_TX_DISABLE 0x10
 
 /* BRDCFG13[0:5] TDM configuration and setup */
@@ -35,8 +38,8 @@
 #define BRDCFG15_DIUSEL_MASK   0x03
 #define BRDCFG15_DIUSEL_HDMI   0x00
 #define BRDCFG15_DIUSEL_LCD0x01
-#define BRDCFG15_DIUSEL_UCC0x10
-#define BRDCFG15_DIUSEL_TDM0x11
+#define BRDCFG15_DIUSEL_UCC0x02
+#define BRDCFG15_DIUSEL_TDM0x03
 
 /* SYSCLK */
 #define QIXIS_SYSCLK_660x0
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 9/9 v2] board/t1024qds: add retimer support on t1024qds

2014-11-24 Thread Shengzhou Liu
Initialize retimer for XFI on t1024qds.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: no change.

 board/freescale/t102xqds/t102xqds.c | 57 +
 include/configs/T102xQDS.h  |  5 +++-
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index 013024e..ca8ce1e 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -186,6 +186,62 @@ static void board_mux_setup(void)
 }
 #endif
 
+void board_retimer_ds125df111_init(void)
+{
+   u8 reg;
+
+   /* Retimer DS125DF111 is connected to I2C1_CH7_CH5 */
+   reg = I2C_MUX_CH7;
+   i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, reg, 1);
+   reg = I2C_MUX_CH5;
+   i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, reg, 1);
+
+   /* Access to Control/Shared register */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Read device revision and ID */
+   i2c_read(I2C_RETIMER_ADDR, 1, 1, reg, 1);
+   debug(Retimer version id = 0x%x\n, reg);
+
+   /* Enable Broadcast */
+   reg = 0x0c;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Reset Channel Registers */
+   i2c_read(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+   reg |= 0x4;
+   i2c_write(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+
+   /* Enable override divider select and Enable Override Output Mux */
+   i2c_read(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+   reg |= 0x24;
+   i2c_write(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+
+   /* Select VCO Divider to full rate (000) */
+   i2c_read(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+   reg = 0x8f;
+   i2c_write(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+
+   /* Select active PFD MUX input as re-timed data (001) */
+   i2c_read(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+   reg = 0x3f;
+   reg |= 0x20;
+   i2c_write(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+
+   /* Set data rate as 10.3125 Gbps */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0x60, 1, reg, 1);
+   reg = 0xb2;
+   i2c_write(I2C_RETIMER_ADDR, 0x61, 1, reg, 1);
+   reg = 0x90;
+   i2c_write(I2C_RETIMER_ADDR, 0x62, 1, reg, 1);
+   reg = 0xb3;
+   i2c_write(I2C_RETIMER_ADDR, 0x63, 1, reg, 1);
+   reg = 0xcd;
+   i2c_write(I2C_RETIMER_ADDR, 0x64, 1, reg, 1);
+}
+
 int board_early_init_r(void)
 {
 #ifdef CONFIG_SYS_FLASH_BASE
@@ -220,6 +276,7 @@ int board_early_init_r(void)
 #endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+   board_retimer_init();
 
/* Increase IO drive strength to address FCS error on RGMII */
out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index d24e06e..78ed243 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -555,11 +555,14 @@ unsigned long get_board_ddr_clk(void);
 
 #define I2C_MUX_PCA_ADDR   0x77
 #define I2C_MUX_PCA_ADDR_PRI   0x77 /* Primary Mux*/
-
+#define I2C_MUX_PCA_ADDR_SEC0x76 /* Secondary multiplexer */
+#define I2C_RETIMER_ADDR   0x18
 
 /* I2C bus multiplexer */
 #define I2C_MUX_CH_DEFAULT  0x8
 #define I2C_MUX_CH_DIU 0xC
+#define I2C_MUX_CH50xD
+#define I2C_MUX_CH70xF
 
 /* LDI/DVI Encoder for display */
 #define CONFIG_SYS_I2C_LDI_ADDR 0x38
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 9/9 v2] board/t1024qds: add retimer support on t1024qds

2014-11-24 Thread Shengzhou Liu
Initialize retimer for XFI on t1024qds.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: updated function name.

 board/freescale/t102xqds/t102xqds.c | 57 +
 include/configs/T102xQDS.h  |  5 +++-
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index 013024e..9253efe 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -186,6 +186,62 @@ static void board_mux_setup(void)
 }
 #endif
 
+void board_retimer_ds125df111_init(void)
+{
+   u8 reg;
+
+   /* Retimer DS125DF111 is connected to I2C1_CH7_CH5 */
+   reg = I2C_MUX_CH7;
+   i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, reg, 1);
+   reg = I2C_MUX_CH5;
+   i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, reg, 1);
+
+   /* Access to Control/Shared register */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Read device revision and ID */
+   i2c_read(I2C_RETIMER_ADDR, 1, 1, reg, 1);
+   debug(Retimer version id = 0x%x\n, reg);
+
+   /* Enable Broadcast */
+   reg = 0x0c;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Reset Channel Registers */
+   i2c_read(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+   reg |= 0x4;
+   i2c_write(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+
+   /* Enable override divider select and Enable Override Output Mux */
+   i2c_read(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+   reg |= 0x24;
+   i2c_write(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+
+   /* Select VCO Divider to full rate (000) */
+   i2c_read(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+   reg = 0x8f;
+   i2c_write(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+
+   /* Select active PFD MUX input as re-timed data (001) */
+   i2c_read(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+   reg = 0x3f;
+   reg |= 0x20;
+   i2c_write(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+
+   /* Set data rate as 10.3125 Gbps */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0x60, 1, reg, 1);
+   reg = 0xb2;
+   i2c_write(I2C_RETIMER_ADDR, 0x61, 1, reg, 1);
+   reg = 0x90;
+   i2c_write(I2C_RETIMER_ADDR, 0x62, 1, reg, 1);
+   reg = 0xb3;
+   i2c_write(I2C_RETIMER_ADDR, 0x63, 1, reg, 1);
+   reg = 0xcd;
+   i2c_write(I2C_RETIMER_ADDR, 0x64, 1, reg, 1);
+}
+
 int board_early_init_r(void)
 {
 #ifdef CONFIG_SYS_FLASH_BASE
@@ -220,6 +276,7 @@ int board_early_init_r(void)
 #endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+   board_retimer_ds125df111_init();
 
/* Increase IO drive strength to address FCS error on RGMII */
out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index d24e06e..78ed243 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -555,11 +555,14 @@ unsigned long get_board_ddr_clk(void);
 
 #define I2C_MUX_PCA_ADDR   0x77
 #define I2C_MUX_PCA_ADDR_PRI   0x77 /* Primary Mux*/
-
+#define I2C_MUX_PCA_ADDR_SEC0x76 /* Secondary multiplexer */
+#define I2C_RETIMER_ADDR   0x18
 
 /* I2C bus multiplexer */
 #define I2C_MUX_CH_DEFAULT  0x8
 #define I2C_MUX_CH_DIU 0xC
+#define I2C_MUX_CH50xD
+#define I2C_MUX_CH70xF
 
 /* LDI/DVI Encoder for display */
 #define CONFIG_SYS_I2C_LDI_ADDR 0x38
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 1/9 v2] net/fm: add 2.5G SGMII support

2014-11-24 Thread Shengzhou Liu
As auto-negotiation is not supported for 2.5G SGMII, we need
to add a new type PHY_INTERFACE_MODE_SGMII_2500 to differentiate
SGMII-1G and SGMII-2.5G with different setting for auto-negotiation.

Signed-off-by: Shaohui Xie shaohui@freescale.com
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: no change

 arch/powerpc/include/asm/fsl_serdes.h | 16 
 drivers/net/fm/eth.c  | 16 
 include/phy.h |  2 ++
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_serdes.h 
b/arch/powerpc/include/asm/fsl_serdes.h
index f60cb0a..8e0e190 100644
--- a/arch/powerpc/include/asm/fsl_serdes.h
+++ b/arch/powerpc/include/asm/fsl_serdes.h
@@ -71,6 +71,22 @@ enum srds_prtcl {
INTERLAKEN,
QSGMII_SW1_A,   /* Indicates ports on L2 Switch */
QSGMII_SW1_B,
+   SGMII_2500_FM1_DTSEC1,
+   SGMII_2500_FM1_DTSEC2,
+   SGMII_2500_FM1_DTSEC3,
+   SGMII_2500_FM1_DTSEC4,
+   SGMII_2500_FM1_DTSEC5,
+   SGMII_2500_FM1_DTSEC6,
+   SGMII_2500_FM1_DTSEC9,
+   SGMII_2500_FM1_DTSEC10,
+   SGMII_2500_FM2_DTSEC1,
+   SGMII_2500_FM2_DTSEC2,
+   SGMII_2500_FM2_DTSEC3,
+   SGMII_2500_FM2_DTSEC4,
+   SGMII_2500_FM2_DTSEC5,
+   SGMII_2500_FM2_DTSEC6,
+   SGMII_2500_FM2_DTSEC9,
+   SGMII_2500_FM2_DTSEC10,
 };
 
 enum srds {
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 218a5ed..137886c 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -39,9 +39,14 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
u32 value;
struct mii_dev bus;
bus.priv = priv-mac-phyregs;
+   bool sgmii_2500 = (priv-enet_if ==
+   PHY_INTERFACE_MODE_SGMII_2500) ? true : false;
+
+   /* SGMII IF mode + AN enable only for 1G SGMII, not for 2.5G */
+   value = PHY_SGMII_IF_MODE_SGMII;
+   if (!sgmii_2500)
+   value |= PHY_SGMII_IF_MODE_AN;
 
-   /* SGMII IF mode + AN enable */
-   value = PHY_SGMII_IF_MODE_AN | PHY_SGMII_IF_MODE_SGMII;
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0x14, value);
 
/* Dev ability according to SGMII specification */
@@ -54,7 +59,9 @@ static void dtsec_configure_serdes(struct fm_eth *priv)
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0x12, 0xd40);
 
/* Restart AN */
-   value = PHY_SGMII_CR_DEF_VAL | PHY_SGMII_CR_RESET_AN;
+   value = PHY_SGMII_CR_DEF_VAL;
+   if (!sgmii_2500)
+   value |= PHY_SGMII_CR_RESET_AN;
memac_mdio_write(bus, 0, MDIO_DEVAD_NONE, 0, value);
 #else
struct dtsec *regs = priv-mac-base;
@@ -83,7 +90,8 @@ static void dtsec_init_phy(struct eth_device *dev)
out_be32(regs-tbipa, CONFIG_SYS_TBIPA_VALUE);
 #endif
 
-   if (fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII)
+   if (fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII ||
+   fm_eth-enet_if == PHY_INTERFACE_MODE_SGMII_2500)
dtsec_configure_serdes(fm_eth);
 }
 
diff --git a/include/phy.h b/include/phy.h
index b495077..d430ed0 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -41,6 +41,7 @@ typedef enum {
PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII,
PHY_INTERFACE_MODE_SGMII,
+   PHY_INTERFACE_MODE_SGMII_2500,
PHY_INTERFACE_MODE_QSGMII,
PHY_INTERFACE_MODE_TBI,
PHY_INTERFACE_MODE_RMII,
@@ -57,6 +58,7 @@ static const char *phy_interface_strings[] = {
[PHY_INTERFACE_MODE_MII]= mii,
[PHY_INTERFACE_MODE_GMII]   = gmii,
[PHY_INTERFACE_MODE_SGMII]  = sgmii,
+   [PHY_INTERFACE_MODE_SGMII_2500] = sgmii-2500,
[PHY_INTERFACE_MODE_QSGMII] = qsgmii,
[PHY_INTERFACE_MODE_TBI]= tbi,
[PHY_INTERFACE_MODE_RMII]   = rmii,
-- 
2.1.0.27.g96db324

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


[U-Boot] USB port detection problem1

2014-11-24 Thread Balaji N
Hi All,

In board, we have 2 USB controllers and the first port with USB Mass
storage is detected without any problem
and 2nd Controller with USB Mass storage is not detected properly.
Sometimes it is detecting and sometimes, it is not detecting.

In U-Boot version U-Boot 2011.12, When detect the USB, got the below errors:

U-Boot usb start
(Re)start USB...
USB:   Active port: 1
Register 10011 NbrPorts 1
USB EHCI 1.00
*scanning bus for devices... port(0) reset error*
*port(0) reset error*
*port(0) reset error*
*port(0) reset error*
*port(0) reset error*
*cannot reset port 1!?*
1 USB Device(s) found
   scanning bus for storage devices... 0 Storage Device(s) found

When USB works, the output is:

U-Boot usb start
(Re)start USB...
USB:   Active port: 1
Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
   scanning bus for storage devices... 1 Storage Device(s) found
U-Boot usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - JetFlash Mass Storage Device K5Z75Z3O
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x8564  Product 0x1000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 1 Out Bulk MaxPacket 512
 - Endpoint 2 In Bulk MaxPacket 512

Please help on this.

When enable the debug printf(), then the error messages is:

U-Boot usb start
(Re)start USB...
USB:   Active port: 1
Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... New Device 0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x40
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length
0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
length 0x19
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length
0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0
length 0xFF
USB device number 1 default language ID 0x1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1
length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1
length 0xFF
Manufacturer u-boot
Product  EHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
length 0x8
1 ports detected
individual port power switching
standalone hub
global over-current protection
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0
length 0x4
get_hub_status returned status 1, change 8101
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
length 0x0
port 1 returns 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4
Port 1 Status 101 Change 1
port 1 connection change
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1
length 0x0
*hub_port_reset: resetting port 0...*
*usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1
length 0x0*
*port(0) reset error*
*usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4*
*portstatus 111, change 0, 12 Mb/s*
*STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0*
*usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1
length 0x0*
*usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4*
*portstatus 101, change 13, 12 Mb/s*
*STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0*
*cannot reset port 1!?*
1 USB Device(s) found
scan end
   scanning bus for storage devices... 0 Storage Device(s) found

In 2nd Controller, USB Mass storage detection is inconsistent.  Need to
test this in U-Boot version U-Boot 2011.12.

-Thanks,
Balaji N
___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [PATCH] powerpc/hydra: fix judging condition of RGMII selection

2014-11-24 Thread shh.xie
From: Minghuan Lian minghuan.l...@freescale.com

BRDCFG1_EMI1_SEL_MASK has been changed to 0x78, which contains
selection bits and connected status bit. So the Corresponding mux
value of RGMII is changed to BRDCFG1_EMI1_SEL_RGMII | BRDCFG1_EMI1_EN.

Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 board/freescale/corenet_ds/eth_hydra.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/freescale/corenet_ds/eth_hydra.c 
b/board/freescale/corenet_ds/eth_hydra.c
index 35825c4..9d8ca9e 100644
--- a/board/freescale/corenet_ds/eth_hydra.c
+++ b/board/freescale/corenet_ds/eth_hydra.c
@@ -250,11 +250,12 @@ void board_ft_fman_fixup_port(void *fdt, char *compat, 
phys_addr_t addr,
return;
}
 
-   if (mux == BRDCFG1_EMI1_SEL_RGMII) {
+   if (mux == (BRDCFG1_EMI1_SEL_RGMII | BRDCFG1_EMI1_EN)) {
/* RGMII */
/* The RGMII PHY is identified by the MAC connected to it */
sprintf(phy, phy_rgmii_%u, port == FM1_DTSEC4 ? 0 : 1);
fdt_set_phy_handle(fdt, compat, addr, phy);
+   return;
}
 
/* If it's not RGMII or XGMII, it must be SGMII */
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH] Add custodian to the m68k subsystem.

2014-11-24 Thread Angelo Dureghello
Signed-off-by: Angelo Dureghello ang...@sysam.it
---
 MAINTAINERS| 2 +-
 doc/git-mailrc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c8386ab..f598e23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -196,7 +196,7 @@ F:  drivers/mtd/cfi_flash.c
 F: drivers/mtd/jedec_flash.c
 
 COLDFIRE
-M: Jason Jin jason@freescale.com
+M: Angelo Dureghello ang...@sysam.it
 S: Maintained
 T: git git://git.denx.de/u-boot-coldfire.git
 F: arch/m68k/
diff --git a/doc/git-mailrc b/doc/git-mailrc
index ad22763..1d55d20 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -14,13 +14,13 @@ alias aaribaud   Albert Aribaud 
albert.u.b...@aribaud.net
 alias abiessmann Andreas Bießmann andreas.de...@googlemail.com
 alias afleming   Andy Fleming aflem...@gmail.com
 alias ag Anatolij Gustschin ag...@denx.de
+alias angelo Angelo Dureghello ang...@sysam.it
 alias galak  Kumar Gala ga...@kernel.crashing.org
 alias gruss  Graeme Russ graeme.r...@gmail.com
 alias hs Heiko Schocher h...@denx.de
 alias ijcIan Campbell ijc+ub...@hellion.org.uk
 alias iwamatsu   Nobuhiro Iwamatsu iwama...@nigauri.org
 alias jagan Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
-alias jasonjin   Jason Jin jason@freescale.com
 alias jhersh Joe Hershberger joe.hershber...@gmail.com
 alias jwrdegoede Hans de Goede hdego...@redhat.com
 alias kimphill   Kim Phillips kim.phill...@freescale.com
-- 
2.1.0.rc1

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


Re: [U-Boot] m68k maintenance

2014-11-24 Thread Angelo Dureghello

Dear all,

just would like to thanks the whole community for this great and 
important chance.


Will do my best.

Regards,
Angelo



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


Re: [U-Boot] [PATCH] powerpc/83xx: add support for kmtepr2 board

2014-11-24 Thread Holger Brunck
On 07/17/2014 11:15 AM, Holger Brunck wrote:
 From: Christoph Dietrich christoph.dietr...@keymile.com
 
 This board is similar to TUXX1, but it has a different FPGA connected to
 chipselect 2. Therefore we need a different configuration for this
 chipselect.
 
 Signed-off-by: Christoph Dietrich christoph.dietr...@keymile.com
 Signed-off-by: Holger Brunck holger.bru...@keymile.com
 cc: Kim Phillips kim.phill...@freescale.com
 ---

ping request on this one. Posted in July...

Regards
Holger


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


Re: [U-Boot] [PATCH] Add custodian to the m68k subsystem.

2014-11-24 Thread Wolfgang Denk
Dear Angelo Dureghello,

In message 1416826089-5510-1-git-send-email-ang...@sysam.it you wrote:
 Signed-off-by: Angelo Dureghello ang...@sysam.it
 ---
  MAINTAINERS| 2 +-
  doc/git-mailrc | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index c8386ab..f598e23 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -196,7 +196,7 @@ F:drivers/mtd/cfi_flash.c
  F:   drivers/mtd/jedec_flash.c
  
  COLDFIRE
 -M:   Jason Jin jason@freescale.com
 +M:   Angelo Dureghello ang...@sysam.it
  S:   Maintained
  T:   git git://git.denx.de/u-boot-coldfire.git
  F:   arch/m68k/

It was my understanding that both you and Alison Wang would become the
nuew custodians.  So we should add another line like:

M:  Huan Wang alison.w...@freescale.com

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
It's like deja vu all over again.  - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Add custodian to the m68k subsystem.

2014-11-24 Thread Angelo Dureghello




It was my understanding that both you and Alison Wang would become the
nuew custodians.  So we should add another line like:

M:  Huan Wang alison.w...@freescale.com

Best regards,

Wolfgang Denk


Hi Wolfgang,

sure, i thought we both had to do it separately. I can do it. Re-post in 
a moment.


Regards,
Angelo




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


Re: [U-Boot] [PATCH] gw_ventana: Use the generic spl_sd.cfg

2014-11-24 Thread Stefano Babic
Hi Fabio, Tim

On 20/11/2014 16:17, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 gw_ventana can boot from SPI or NAND and both of these interfaces boot from
 the same 0x400 offset.
 
 This means that we could simplify the code and replace the custom 
 gw_ventana.cfg
 with the generic spl_sd.cfg, as it provides the same boot offset of 0x400.
 
 Cc: Tim Harvey thar...@gateworks.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Tim, this factorize common code - I think it can harmless flow into
mainline.

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 0/5] introduce sata stop

2014-11-24 Thread Stefano Babic
On 21/11/2014 11:47, Nikita Kiryanov wrote:
 This series adds the sata stop command, which includes both cmd_sata code and
 driver support for resetting sata.
 A non-dummy reset_sata() is provided for dwc_ahsata, and a non-default
 sata_stop() is provided for cm_fx6.
 Finally, we use the new functionality to turn off sata on boot for mx6 
 devices.
 
 Cc: Stefano Babic sba...@denx.de
 Cc: Simon Glass s...@chromium.org
 
 Nikita Kiryanov (5):
   arm: mx6: introduce disable_sata_clock
   sata: implement reset_sata for dwc_ahsata
   cmd_sata: implement sata stop command
   arm: mx6: cm_fx6: implement board specific sata stop
   arm: imx: stop sata on boot
 
  arch/arm/cpu/armv7/mx6/clock.c|  8 
  arch/arm/cpu/armv7/omap-common/sata.c |  5 +
  arch/arm/imx-common/cpu.c |  8 ++--
  arch/arm/include/asm/arch-mx6/clock.h |  1 +
  board/compulab/cm_fx6/cm_fx6.c| 12 +---
  common/cmd_sata.c | 24 +++-
  drivers/block/ata_piix.c  |  5 +
  drivers/block/dwc_ahsata.c| 21 +
  drivers/block/fsl_sata.c  |  5 +
  drivers/block/pata_bfin.c |  5 +
  drivers/block/sata_dwc.c  |  5 +
  drivers/block/sata_sil.c  |  5 +
  drivers/block/sata_sil3114.c  |  5 +
  include/sata.h|  3 +++
  14 files changed, 106 insertions(+), 6 deletions(-)
 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH 1/3] ot1200: Fix error handling in board_mmc_init()

2014-11-24 Thread Stefano Babic
On 21/11/2014 19:42, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 When an invalid USDHC port is passed we should return -EINVAL instead of 0.
 
 Also, return the error immediately on fsl_esdhc_initialize() failure.
 
 Cc: Christian Gmeiner christian.gmei...@gmail.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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


Re: [U-Boot] [PATCH 2/3] nitrogen6x: Fix error handling in board_mmc_init()

2014-11-24 Thread Stefano Babic
On 21/11/2014 19:42, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 When an invalid USDHC port is passed we should return -EINVAL instead of 0.
 
 Also, return the error immediately on fsl_esdhc_initialize() failure.
 
 Cc: Eric Nelson eric.nel...@boundarydevices.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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


Re: [U-Boot] [PATCH 3/3] mx6boards: Fix error handling in board_mmc_init()

2014-11-24 Thread Stefano Babic
On 21/11/2014 19:42, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 When an invalid USDHC port is passed we should return -EINVAL instead of 0.
 
 Also, return the error immediately on fsl_esdhc_initialize() failure.
 
 Cc: Eric Benard e...@eukrea.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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


Re: [U-Boot] [PATCH 1/3] ot1200: Fix error handling in board_mmc_init()

2014-11-24 Thread Christian Gmeiner
2014-11-24 12:05 GMT+01:00 Stefano Babic sba...@denx.de:
 On 21/11/2014 19:42, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com

 When an invalid USDHC port is passed we should return -EINVAL instead of 0.

 Also, return the error immediately on fsl_esdhc_initialize() failure.

 Cc: Christian Gmeiner christian.gmei...@gmail.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


 Applied to u-boot-imx, thanks !


Thanks Fabio for the patch!

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PULL] Please pull u-boot-imx

2014-11-24 Thread Stefano Babic
Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit f196044dfd64745a163773c6c746f9e149ace127:

  ARM: atmel: add sama5d4 xplained ultra board support (2014-11-17
08:47:18 -0500)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to e7eb277dced570f177d75d56f40219d9dc599ed1:

  mx6boards: Fix error handling in board_mmc_init() (2014-11-24 12:10:18
+0100)


Albert ARIBAUD (3):
  cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
  imx: fix exception vectors relocation in imx27
  tools/msximage.c: fix warning about nptr possibly uninitialized

Alexey Ignatov (1):
  ARM: mxs: tools: Add support for boot progress display flag

Fabio Estevam (23):
  mx6sabresd: Move the DCD settings to spl code
  gw_ventana: Move the DCD settings to spl code
  novena: Move the DCD settings to spl code
  mx6: Use a common SPL configuration file
  imx: consolidate set_chipselect_size function
  mx6: add weim registers
  mx6qsabreauto: Add parallel NOR flash support
  wandboard: Fix error handling in board_mmc_init()
  mx53loco: Fix error handling in board_mmc_init()
  mx6sabresd: State that only mx6q is supported in SPL
  mx6slevk: Simplify the return value of setup_fec()
  mx6sxsabresd: Simplify the return value of setup_fec()
  mx6sabresd: Add mx6sabresd_spl_defconfig to MAINTAINERS entry
  mx6sabresd: Access SRC_SBMR1 register via structure
  mx51evk: Fix error handling in board_mmc_init()
  mx6qarm2: Fix error handling in board_mmc_init()
  mx53smd: Fix error handling in board_mmc_init()
  mx53evk: Fix error handling in board_mmc_init()
  mx53ard: Fix error handling in board_mmc_init()
  gw_ventana: Use the generic spl_sd.cfg
  ot1200: Fix error handling in board_mmc_init()
  nitrogen6x: Fix error handling in board_mmc_init()
  mx6boards: Fix error handling in board_mmc_init()

Markus Niebel (4):
  tqma6: (cosmetic) remove CONFIG_FLASH_SECTOR_SIZE
  tqma6: add missing include
  tqma6: add warning on failed setup_i2c
  tqma6: use imx_ddr_size

Nikita Kiryanov (5):
  arm: mx6: introduce disable_sata_clock
  sata: implement reset_sata for dwc_ahsata
  cmd_sata: implement sata stop command
  arm: mx6: cm_fx6: implement board specific sata stop
  arm: imx: stop sata on boot

Nitin Garg (1):
  mx6: clock: Add thermal clock enable function

Peng Fan (1):
  imx:mx6sxsabresd fix pfuz probe failed

Soeren Moch (1):
  tbs2910: Fix error handling in board_mmc_init()

Ye.Li (11):
  imx: mx6slevk: Change default mmcdev to USDHC2 device
  mmc: fsl_esdhc: Update esdhc driver for iMX6SX
  imx: mx6sxsabresd: Add board support for USDHC2 and USDHC3
  power: pfuze100: Update definitions for buck regulators
  imx: mx6sabre common: Factorize the Pfuze init function
  imx: mx6sabresd: Use the pfuze common init function
  imx: mx6sxsabresd: Use the pfuze common init function
  imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
  DM: thermal: Add imx thermal DM driver
  mx6: thermal: Check cpu temperature via thermal sensor
  mx6: mx6sabre common: Enable i.MX thermal DM driver

 arch/arm/cpu/arm926ejs/mx27/Makefile|   4 +
 arch/arm/cpu/arm926ejs/mx27/relocate.S  |  51 
 .../arm926ejs/mxs/mxsimage-signed.cfg   |   1 +
 .../cpu/arm926ejs/mxs/mxsimage.mx23.cfg |   1 +
 .../cpu/arm926ejs/mxs/mxsimage.mx28.cfg |   1 +
 arch/arm/cpu/armv7/mx5/soc.c|  31 ---
 arch/arm/cpu/armv7/mx6/clock.c  |  38 +++
 arch/arm/cpu/armv7/mx6/soc.c|  15 ++
 arch/arm/cpu/armv7/omap-common/sata.c   |   5 +
 arch/arm/imx-common/cpu.c   |  60 -
 .../arm/imx-common/spl_sd.cfg   |   2 +-
 arch/arm/include/asm/arch-imx/cpu.h |   5 +
 .../arm/include/asm/arch-mx5/imx-regs.h |  12 +-
 arch/arm/include/asm/arch-mx6/clock.h   |   2 +
 .../arm/include/asm/arch-mx6/imx-regs.h |  37 +++
 .../include/asm/arch-mx6/sys_proto.h|   1 +
 arch/arm/lib/crt0.S |   5 +
 arch/arm/lib/relocate.S |  73 +++---
 board/bachmann/ot1200/ot1200.c  |  10 +-
 board/boundary/nitrogen6x/nitrogen6x.c  |  10 +-
 board/compulab/cm_fx6/cm_fx6.c  |  12 +-
 board/embest/mx6boards/mx6boards.c  |  10 +-
 board/freescale/common/Makefile |   1 +
 board/freescale/common/pfuze.c  |  54 
 board/freescale/common/pfuze.h  |  12 +
 board/freescale/mx51evk/mx51evk.c   |  10 +-
 board/freescale/mx53ard/mx53ard.c   |  10 +-
 board/freescale/mx53evk/mx53evk.c   |  10 +-
 board/freescale/mx53loco/mx53loco.c |  10 +-
 board/freescale/mx53smd/mx53smd.c   |  10 +-
 board/freescale/mx6qarm2/mx6qarm2.c |  10 +-
 .../mx6qsabreauto/mx6qsabreauto.c   |  95 ++-
 

[U-Boot] AM335x Ethernet pin mux confusion

2014-11-24 Thread Andy Pont
Hello,

I am working on porting U-Boot 2014.07 to a custom TI AM3354 based hardware
platform and am confused trying to set the pin mux for the two Ethernet
interfaces that are on the board.  

RGMII1_ pins are connected to an ATHEROS AR8031 PHY (PHY ADDR 04) and the
pins GPMC_A0 .. GPMC_A11 are connected to a Micrel KSZ8041NL (PHY ADDR 01).
The output of the mii info command looks OK so the MDIO interface looks to
be OK as it gives:

PHY 0x00: OUI = 0x0885, Model = 0x11, Rev = 0x03,  10baseT, HDX
PHY 0x01: OUI = 0x0885, Model = 0x11, Rev = 0x03,  10baseT, HDX
PHY 0x04: OUI = 0x1374, Model = 0x07, Rev = 0x04, 1000baseX, FDX

However, with debug enabled, it is reporting the PHYs incorrectly as it
gives:

cpsw connected to Micrel KSZ804
cpsw connected to Micrel KSZ804
cpsw

The AR8031 provides a connection to the outside world and the KSZ8041
connects to an Ethernet switch which then connects on to other devices on
the board to form a private network.  The DHCP command just sits in a loop
waiting for PHY auto negotiation to complete but timing out!

In the SPL code I am setting up the pin mux as follows:

static struct module_pin_mux rgmii1_pin_mux[] = {
{OFFSET(mii1_txen), MODE(2)},   /* RGMII1_TCTL */
{OFFSET(mii1_rxdv), MODE(2) | RXACTIVE},/* RGMII1_RCTL */
{OFFSET(mii1_txd3), MODE(2)},   /* RGMII1_TD3 */
{OFFSET(mii1_txd2), MODE(2)},   /* RGMII1_TD2 */
{OFFSET(mii1_txd1), MODE(2)},   /* RGMII1_TD1 */
{OFFSET(mii1_txd0), MODE(2)},   /* RGMII1_TD0 */
{OFFSET(mii1_txclk), MODE(2)},  /* RGMII1_TCLK */
{OFFSET(mii1_rxclk), MODE(2) | RXACTIVE},   /* RGMII1_RCLK */
{OFFSET(mii1_rxd3), MODE(2) | RXACTIVE},/* RGMII1_RD3 */
{OFFSET(mii1_rxd2), MODE(2) | RXACTIVE},/* RGMII1_RD2 */
{OFFSET(mii1_rxd1), MODE(2) | RXACTIVE},/* RGMII1_RD1 */
{OFFSET(mii1_rxd0), MODE(2) | RXACTIVE},/* RGMII1_RD0 */
{OFFSET(mdio_data), MODE(0) | RXACTIVE | PULLUP_EN},  /* MDIO_DATA
*/
{OFFSET(mdio_clk), MODE(0) | PULLUP_EN},/* MDIO_CLK */
{-1},
};

static struct module_pin_mux rmii2_pin_mux[] = {
{OFFSET(gpmc_a0), MODE(2)}, /* RMII2_TXEN */
{OFFSET(gpmc_a1), MODE(2) | RXACTIVE},  /* RMII2_RXDV */
{OFFSET(gpmc_a2), MODE(2)}, /* RMII2_TXD3 */
{OFFSET(gpmc_a3), MODE(2)}, /* RMII2_TXD2 */
{OFFSET(gpmc_a4), MODE(2)}, /* RMII2_TXD1 */
{OFFSET(gpmc_a5), MODE(2)}, /* RMII2_TXD0 */
{OFFSET(gpmc_a6), MODE(2)}, /* RMII2_TXCLK */
{OFFSET(gpmc_a7), MODE(2) | RXACTIVE},  /* RMII2_RXCLK */
{OFFSET(gpmc_a8), MODE(2) | RXACTIVE},  /* RMII2_RXD3 */
{OFFSET(gpmc_a9), MODE(2) | RXACTIVE},  /* RMII2_RXD2 */
{OFFSET(gpmc_a10), MODE(2) | RXACTIVE}, /* RMII2_RXD1 */
{OFFSET(gpmc_a11), MODE(2) | RXACTIVE}, /* RMII2_RXD0 */
{OFFSET(mdio_data), MODE(0) | RXACTIVE | PULLUP_EN}, /* MDIO_DATA */
{OFFSET(mdio_clk), MODE(0) | PULLUP_EN},/* MDIO_CLK */
{-1},
};

Any help would be much appreciated?

Thanks,

Andy.



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


[U-Boot] [PATCH v2] Add custodians to the m68k subsystem.

2014-11-24 Thread Angelo Dureghello
---
 MAINTAINERS| 3 ++-
 doc/git-mailrc | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c8386ab..9fce7b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -196,7 +196,8 @@ F:  drivers/mtd/cfi_flash.c
 F: drivers/mtd/jedec_flash.c
 
 COLDFIRE
-M: Jason Jin jason@freescale.com
+M: Huan Wang alison.w...@freescale.com
+M: Angelo Dureghello ang...@sysam.it
 S: Maintained
 T: git git://git.denx.de/u-boot-coldfire.git
 F: arch/m68k/
diff --git a/doc/git-mailrc b/doc/git-mailrc
index ad22763..21574e1 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -14,6 +14,7 @@ alias aaribaud   Albert Aribaud 
albert.u.b...@aribaud.net
 alias abiessmann Andreas Bießmann andreas.de...@googlemail.com
 alias afleming   Andy Fleming aflem...@gmail.com
 alias ag Anatolij Gustschin ag...@denx.de
+alias angelo_ts  Angelo Dureghello ang...@sysam.it
 alias galak  Kumar Gala ga...@kernel.crashing.org
 alias gruss  Graeme Russ graeme.r...@gmail.com
 alias hs Heiko Schocher h...@denx.de
-- 
2.1.0.rc1

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


[U-Boot] [PATCH] thermal: imx_thermal: Do not display calibration data

2014-11-24 Thread Fabio Estevam
Printing the calibration data on every boot does not provide really useful
information:

U-Boot 2015.01-rc1-18266-ge7eb277 (Nov 24 2014 - 11:29:51)  

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz   
CPU:   Thermal calibration data: 0x5d85067d 
CPU:   Temperature 33 C 
Reset cause: POR
Board: MX6-SabreSD

Do not display the calibration data in order to have a cleaner boot log.
   

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 drivers/thermal/imx_thermal.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 1161585..0bd9cfd 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -156,8 +156,6 @@ static int imx_thermal_probe(struct udevice *dev)
if (fuse == 0 || fuse == ~0) {
printf(CPU:   Thermal invalid data, fuse: 0x%x\n, fuse);
return -EPERM;
-   } else {
-   printf(CPU:   Thermal calibration data: 0x%x\n, fuse);
}
 
*priv = fuse;
-- 
1.9.1

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


Re: [U-Boot] usbkbd input double echoed

2014-11-24 Thread Nikita Kiryanov

Hi Hans,

On 11/23/2014 05:18 PM, Hans de Goede wrote:

Hi,

On 11/23/2014 04:07 PM, Nikita Kiryanov wrote:

Hi all,

I've enabled USB keyboard for cm_fx6 using these three defines:

#define CONFIG_USB_KEYBOARD
#define CONFIG_SYS_USB_EVENT_POLL
#define CONFIG_SYS_STDIO_DEREGISTER

I am able to probe it with `usb start`, and set it as input using
`setenv stdin usbkbd`.

It works, save for one problem: all key presses are echoed twice.
The double echo happens both on serial and vga stdout.
It is not dependant on the keyboard (tried different ones).
Output from commands looks normal.
Switching to CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP did not help.
Shell still understands each key press as one key press, so
even though pprriinntteennvv is displayed, the shell still sees
printenv.

Any idea what the cause may be?


In my experience both polling methods are sub-optimal, if your board
has an ehci controller, try using CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE

Also I use CONFIG_CONSOLE_MUX, then you can do:

setenv stdin serial,usbkbd

And get both, using this usb-kbd support works fine for me, without the
double echo, both on the serial console and on the sunxi-cfb console over
hdmi.

Regards,

Hans



I think I must have encountered some toolchain bug. After switching to
another branch to work on something else I came back to my dev branch
and the compiled images no longer have this bug.

Thanks for the help though..

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Douglas Rupp
It's the version of qemu-system-arm downloaded for Ubuntu 14.04
Version info:
qemu-system-arm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)

I also tried the three boot.bin files in 2014.3-release.tar.gz
downloaded from the Xilinx website, those in subdirectories zc70x/zc706/
and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no output.

I also tried the version 2.0.0 version of qemu-system-arm from the
open-do.org website that we regular use with xlnx-zynq-a9 bsp for vxworks7,
it boots vxworks without uboot, but hangs with uboot.

You're suggesting that only the qemu-system-arm built from the xilinx repo
is functional with uboot?  I used that version of qemu about a year ago,
and it worked fine for Linux but it was an ancient version of qemu (at that
time).

On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki jagannadh.t...@gmail.com
wrote:

 On 24 November 2014 at 06:03, Douglas Rupp douglas.b.r...@gmail.com
 wrote:
  I'm brand new to Uboot, so hopefully this is just some missing switch.  I
  did search the archive, and I was able to build and u-boot a versaatilepb
  version, but xilinx-zynq-a9 is the one I really need.
 
  u-boot-2014.10$ make zynq_zed_defconfig
  u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm
  u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M -nographic
  -kernel u-boot-dtb.bin
  Segmentation fault (core dumped)

 I guess it may be qemu usage issue, is qemu from
 https://github.com/Xilinx/qemu ?

 + Peter
 Hope, he will give some inputs

 
  What am I doing wrong?

 thanks!
 --
 Jagan.

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


[U-Boot] [PATCH 1/2] exynos5420: fix compilation without parade video

2014-11-24 Thread Sjoerd Simons
Not all exynos 5420 based devices with an LCD also have a parade LVDS
bridge. So make sure compilation doesn't break if CONFIG_LCD is enabled
and CONFIG_VIDEO_PARADE is not.

Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
 board/samsung/smdk5420/smdk5420.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
index a691222..f8be401 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -43,6 +43,7 @@ int exynos_init(void)
 }
 
 #ifdef CONFIG_LCD
+#ifdef CONFIG_VIDEO_PARADE
 static int has_edp_bridge(void)
 {
int node;
@@ -56,6 +57,7 @@ static int has_edp_bridge(void)
/* Default is with bridge ic */
return 1;
 }
+#endif
 
 void exynos_lcd_power_on(void)
 {
@@ -83,9 +85,11 @@ void exynos_lcd_power_on(void)
gpio_direction_input(EXYNOS5420_GPIO_X26);  /* EDP_HPD */
gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
 
+#ifdef CONFIG_VIDEO_PARADE
if (has_edp_bridge())
if (parade_init(gd-fdt_blob))
printf(%s: ps8625_init() failed\n, __func__);
+#endif
 }
 
 void exynos_backlight_on(unsigned int onoff)
-- 
2.1.3

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


[U-Boot] [PATCH 2/2] Exynos5800: The Peach-Pi board does not have a Parade video bridge

2014-11-24 Thread Sjoerd Simons
Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the
Pi. So drop it from the board configuration  device-tree

Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
 arch/arm/dts/exynos5800-peach-pi.dts | 5 -
 include/configs/peach-pi.h   | 2 --
 2 files changed, 7 deletions(-)

diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
b/arch/arm/dts/exynos5800-peach-pi.dts
index 8aedf8e..2f9d2db 100644
--- a/arch/arm/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/dts/exynos5800-peach-pi.dts
@@ -63,11 +63,6 @@
  reg = 0x20;
  compatible = maxim,max98090-codec;
   };
-
-   edp-lvds-bridge@48 {
-   compatible = parade,ps8625;
-   reg = 0x48;
-   };
};
 
 sound@383 {
diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h
index 8a82402..ff31728 100644
--- a/include/configs/peach-pi.h
+++ b/include/configs/peach-pi.h
@@ -26,8 +26,6 @@
 #define CONFIG_SYS_PROMPT  Peach-Pi # 
 #define CONFIG_IDENT_STRING for Peach-Pi
 
-#define CONFIG_VIDEO_PARADE
-
 /* Display */
 #define CONFIG_LCD
 #ifdef CONFIG_LCD
-- 
2.1.3

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


[U-Boot] [PATCH 0/2] No need for parade bridge on peach-pi

2014-11-24 Thread Sjoerd Simons
With current u-boot-samsung HEAD on a peach-pi the following error is printed:
  exynos_lcd_power_on: ps8625_init() failed

Which is not surprising given that chip does not exist on these boards.

Sjoerd Simons (2):
  exynos5420: fix compilation without parade video
  Exynos5800: The Peach-Pi board does not have a Parade video bridge

 arch/arm/dts/exynos5800-peach-pi.dts | 5 -
 board/samsung/smdk5420/smdk5420.c| 4 
 include/configs/peach-pi.h   | 2 --
 3 files changed, 4 insertions(+), 7 deletions(-)

-- 
2.1.3

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


Re: [U-Boot] [PATCH v2] Add custodians to the m68k subsystem.

2014-11-24 Thread Wolfgang Denk
Dear Angelo Dureghello,

In message 1416839817-9319-1-git-send-email-ang...@sysam.it you wrote:
 ---
  MAINTAINERS| 3 ++-
  doc/git-mailrc | 1 +
  2 files changed, 3 insertions(+), 1 deletion(-)

Acked-by: Wolfgang Denk w...@denx.de

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
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.  - Franklin D. Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/3] Kconfig: Add EXPERT option

2014-11-24 Thread Albert ARIBAUD
Hello Hans,

On Thu, 13 Nov 2014 20:37:40 +0100, Hans de Goede hdego...@redhat.com wrote:
 From: Tom Rini tr...@ti.com
 
 For similar reasons to why the Linux Kernel has an EXPERT option, we too
 want an option to allow for tweaking of some options that while normally
 should remain hidden, may need to be changed in some cases.
 
 Signed-off-by: Tom Rini tr...@ti.com
 Acked-by: Hans de Goede hdego...@redhat.com
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  Kconfig | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/Kconfig b/Kconfig
 index f34f341..405b7a6 100644
 --- a/Kconfig
 +++ b/Kconfig
 @@ -58,6 +58,14 @@ config CC_OPTIMIZE_FOR_SIZE
  
  endmenu  # General setup
  
 +menuconfig EXPERT
 +bool Configure standard U-Boot features (expert users)
 +help
 +  This option allows certain base U-Boot options and settings
 +  to be disabled or tweaked. This is for specialized
 +  environments which can tolerate a non-standard U-Boot.
 +  Only use this if you really know what you are doing.
 +
  menu Boot images
  
  config SPL_BUILD
 -- 
 2.1.0
 

Applied to u-boot-arm/master, thanks!

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


Re: [U-Boot] [PATCH v2 3/3] ARM: bootm: Allow booting in secure mode on hyp capable systems

2014-11-24 Thread Albert ARIBAUD
Hello Hans,

On Thu, 13 Nov 2014 20:37:42 +0100, Hans de Goede hdego...@redhat.com wrote:
 Older Linux kernels will not properly boot in hyp mode, add support for a
 bootm_boot_mode environment variable, which can be set to sec or nonsec
 to force booting in secure or non-secure mode when build with non-sec support.
 
 The default behavior can be selected through CONFIG_ARMV7_BOOT_SEC_DEFAULT,
 when this is set booting in secure mode is the default. The default setting
 for this Kconfig option is N, preserving the current behavior of booting in
 non-secure mode by default when non-secure mode is supported.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 Acked-by: Marc Zyngier marc.zyng...@arm.com
 Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
 --
 Changes in v2:
 -Allow changing the default boot mode to secure through defining
  CONFIG_ARMV7_BOOT_SEC_DEFAULT, this is useful for archs which have a Kconfig
  option for compatibility with older kernels
 Changes in v3:
 -Add an else at the end of the #ifdef NONSEC block so that if do_nonsec_entry
  fails we do not end up re-trying in secure mode
 Changes in v4:
 -Add a Kconfig option to select to boot in secure or non-secure mode by 
 default
 ---
  arch/arm/cpu/armv7/Kconfig | 11 +++
  arch/arm/lib/bootm.c   | 31 ++-
  2 files changed, 37 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
 index 15c5155..6ee5ff8 100644
 --- a/arch/arm/cpu/armv7/Kconfig
 +++ b/arch/arm/cpu/armv7/Kconfig
 @@ -13,6 +13,17 @@ config ARMV7_NONSEC
   ---help---
   Say Y here to enable support for booting in non-secure / SVC mode.
  
 +config ARMV7_BOOT_SEC_DEFAULT
 + boolean Boot in secure mode by default if EXPERT
 + depends on ARMV7_NONSEC
 + default n
 + ---help---
 + Say Y here to boot in secure mode by default even if non-secure mode
 + is supported. This option is useful to boot kernels which do not
 + suppport booting in secure mode. Only set this if you need it.
 + This can be overriden at run-time by setting the bootm_boot_mode env.
 + variable to sec or nonsec.
 +
  config ARMV7_VIRT
   boolean Enable support for hardware virtualization if EXPERT
   depends on CPU_V7_HAS_VIRT  ARMV7_NONSEC
 diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
 index 4949d57..a7f7c67 100644
 --- a/arch/arm/lib/bootm.c
 +++ b/arch/arm/lib/bootm.c
 @@ -237,6 +237,26 @@ static void boot_prep_linux(bootm_headers_t *images)
   }
  }
  
 +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
 +static bool boot_nonsec(void)
 +{
 + char *s = getenv(bootm_boot_mode);
 +#ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
 + bool nonsec = false;
 +#else
 + bool nonsec = true;
 +#endif
 +
 + if (s  !strcmp(s, sec))
 + nonsec = false;
 +
 + if (s  !strcmp(s, nonsec))
 + nonsec = true;
 +
 + return nonsec;
 +}
 +#endif
 +
  /* Subcommand: GO */
  static void boot_jump_linux(bootm_headers_t *images, int flag)
  {
 @@ -285,12 +305,13 @@ static void boot_jump_linux(bootm_headers_t *images, 
 int flag)
  
   if (!fake) {
  #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
 - armv7_init_nonsec();
 - secure_ram_addr(_do_nonsec_entry)(kernel_entry,
 -   0, machid, r2);
 -#else
 - kernel_entry(0, machid, r2);
 + if (boot_nonsec()) {
 + armv7_init_nonsec();
 + secure_ram_addr(_do_nonsec_entry)(kernel_entry,
 +   0, machid, r2);
 + } else
  #endif
 + kernel_entry(0, machid, r2);
   }
  #endif
  }
 -- 
 2.1.0
 

Applied to u-boot-arm/master, thanks!

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


Re: [U-Boot] [PATCH v2 2/3] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options

2014-11-24 Thread Albert ARIBAUD
Hello Hans,

On Thu, 13 Nov 2014 20:37:41 +0100, Hans de Goede hdego...@redhat.com wrote:
 Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options, this is a
 preparation patch for adding an env variable to choose between secure /
 non-secure boot on non-secure boot capable systems, specifically this
 prepares for adding CONFIG_CPU_V7_SEC_BY_DEFAULT as a proper Kconfig option.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 --
 Changes in v2:
 -Drop all the FIXME-s, use proper CPU_V7 and CPU_V7_HAS_foo checks instead
 ---
  arch/arm/Kconfig|  4 
  arch/arm/cpu/armv7/Kconfig  | 23 +++
  arch/arm/cpu/armv7/exynos/Kconfig   |  2 ++
  board/sunxi/Kconfig |  2 ++
  include/configs/arndale.h   |  2 --
  include/configs/sun7i.h |  2 --
  include/configs/vexpress_ca15_tc2.h |  2 --
  7 files changed, 31 insertions(+), 6 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/Kconfig
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 79ccc06..43ace2c 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -410,6 +410,8 @@ config TARGET_INTEGRATORCP_CM946ES
  config TARGET_VEXPRESS_CA15_TC2
   bool Support vexpress_ca15_tc2
   select CPU_V7
 + select CPU_V7_HAS_NONSEC
 + select CPU_V7_HAS_VIRT
  
  config TARGET_VEXPRESS_CA5X2
   bool Support vexpress_ca5x2
 @@ -809,6 +811,8 @@ source arch/arm/cpu/arm926ejs/versatile/Kconfig
  
  source arch/arm/cpu/armv7/zynq/Kconfig
  
 +source arch/arm/cpu/armv7/Kconfig
 +
  source board/aristainetos/Kconfig
  source board/BuR/kwb/Kconfig
  source board/BuR/tseries/Kconfig
 diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
 new file mode 100644
 index 000..15c5155
 --- /dev/null
 +++ b/arch/arm/cpu/armv7/Kconfig
 @@ -0,0 +1,23 @@
 +if CPU_V7
 +
 +config CPU_V7_HAS_NONSEC
 +bool
 +
 +config CPU_V7_HAS_VIRT
 +bool
 +
 +config ARMV7_NONSEC
 + boolean Enable support for booting in non-secure mode if EXPERT
 + depends on CPU_V7_HAS_NONSEC
 + default y
 + ---help---
 + Say Y here to enable support for booting in non-secure / SVC mode.
 +
 +config ARMV7_VIRT
 + boolean Enable support for hardware virtualization if EXPERT
 + depends on CPU_V7_HAS_VIRT  ARMV7_NONSEC
 + default y
 + ---help---
 + Say Y here to boot in hypervisor (HYP) mode when booting non-secure.
 +
 +endif
 diff --git a/arch/arm/cpu/armv7/exynos/Kconfig 
 b/arch/arm/cpu/armv7/exynos/Kconfig
 index 090be93..e9a102c 100644
 --- a/arch/arm/cpu/armv7/exynos/Kconfig
 +++ b/arch/arm/cpu/armv7/exynos/Kconfig
 @@ -26,6 +26,8 @@ config TARGET_ODROID
  
  config TARGET_ARNDALE
   bool Exynos5250 Arndale board
 + select CPU_V7_HAS_NONSEC
 + select CPU_V7_HAS_VIRT
   select SUPPORT_SPL
   select OF_CONTROL if !SPL_BUILD
  
 diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
 index 0bab31b..e20ea1b 100644
 --- a/board/sunxi/Kconfig
 +++ b/board/sunxi/Kconfig
 @@ -21,6 +21,8 @@ config MACH_SUN6I
  config MACH_SUN7I
   bool sun7i (Allwinner A20)
   select CPU_V7
 + select CPU_V7_HAS_NONSEC
 + select CPU_V7_HAS_VIRT
   select SUPPORT_SPL
  
  config MACH_SUN8I
 diff --git a/include/configs/arndale.h b/include/configs/arndale.h
 index f9ee40f..aa6b631 100644
 --- a/include/configs/arndale.h
 +++ b/include/configs/arndale.h
 @@ -60,6 +60,4 @@
  /* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override 
 it */
  #define CONFIG_ARM_GIC_BASE_ADDRESS  0x1048
  
 -#define CONFIG_ARMV7_VIRT
 -
  #endif   /* __CONFIG_H */
 diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
 index ea40790..3629587 100644
 --- a/include/configs/sun7i.h
 +++ b/include/configs/sun7i.h
 @@ -22,8 +22,6 @@
  #define CONFIG_USB_MAX_CONTROLLER_COUNT  2
  #endif
  
 -#define CONFIG_ARMV7_VIRT1
 -#define CONFIG_ARMV7_NONSEC  1
  #define CONFIG_ARMV7_PSCI1
  #define CONFIG_ARMV7_PSCI_NR_CPUS2
  #define CONFIG_ARMV7_SECURE_BASE SUNXI_SRAM_B_BASE
 diff --git a/include/configs/vexpress_ca15_tc2.h 
 b/include/configs/vexpress_ca15_tc2.h
 index 982f4a7..b43afa2 100644
 --- a/include/configs/vexpress_ca15_tc2.h
 +++ b/include/configs/vexpress_ca15_tc2.h
 @@ -18,6 +18,4 @@
  #define CONFIG_SYSFLAGS_ADDR 0x1c010030
  #define CONFIG_SMP_PEN_ADDR  CONFIG_SYSFLAGS_ADDR
  
 -#define CONFIG_ARMV7_VIRT
 -
  #endif
 -- 
 2.1.0
 

Applied to u-boot-arm/master, thanks!

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


Re: [U-Boot] [PATCH U-Boot] ARM: rpi_b: detect board revision

2014-11-24 Thread Simon Glass
Hi Stephen,

On 18 November 2014 at 21:40, Stephen Warren swar...@wwwdotorg.org wrote:
 Detect the board revision early during boot, and print the decoded
 model name.

 Eventually, this information can be used for tasks such as:
 - Allowing/preventing USB device mode; some models have a USB device on-
   board so only host mode makes sense. Others connect the SoC directly
   to the USB connector, so device-mode might make sense.
 - The on-board USB hub/Ethernet requires different GPIOs to enable it,
   although luckily the default appears to be fine so far.
 - The compute module contains an on-board eMMC device, so we could store
   the environment there. Other models use an SD card and so don't support
   saving the environment (unless we store it in a file on the FAT boot
   partition...)

 Set $fdtfile based on this information. At present, the mainline Linux
 kernel doesn't contain a separate DTB for most models, but I hope that
 will change soon.

 Signed-off-by: Stephen Warren swar...@wwwdotorg.org
 ---
 I'm considering renaming rpi_b - rpi in U-Boot since it supports many
 models. Hopefully I can persuade U-Boot to load the environment from
 different places at run-time, so we won't need different builds based
 on whether the environment is in eMMC or not for example.

  arch/arm/include/asm/arch-bcm2835/mbox.h |  33 +
  board/raspberrypi/rpi_b/rpi_b.c  | 122 
 ++-
  include/configs/rpi_b.h  |   1 -
  3 files changed, 152 insertions(+), 4 deletions(-)

I tried this out. It worked OK for me except that it can't find the
device tree file bcm2835-rpi-b-rev2.dtb.

Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try
from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the
file. Reducing the filename length to 8 chars works. I wonder what
year of my life FAT will stop plaguing me?

Anyway this doesn't seem to be related to this patch, so:

Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org

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


Re: [U-Boot] [PATCH 0/5] PL01x: baudrate line control fixes

2014-11-24 Thread Simon Glass
Hi Vikas,

On 18 November 2014 at 11:59, vikasm vikas.mano...@st.com wrote:
 Thanks Simon,


 On 11/17/2014 09:30 PM, Simon Glass wrote:

 Hi Vikas,

 On 18 November 2014 00:17, Vikas Manocha vikas.mano...@st.com wrote:

 This patchset fixes the pl01x driver esp for pl011 baudrate  line
 control.

 Vikas Manocha (5):
serial: pl01x: pass pl01x_type to set baudrate
serial: pl01x: fix pl011 baud rate configuration
serial: pl01x: move all line control at same place
serial: pl01x: disable as per type of pl01x
serial: pl01x: avoid pl01x type check two times

   drivers/serial/serial_pl01x.c |   46
 +
   1 file changed, 24 insertions(+), 22 deletions(-)

 Great to see this series. If you have not tested on p1010 I can do
 this in a week or so (am travelling). At least a few of these looks
 like bug fixes to my recent refactor so I could bring them through the
 DM tree if no one else picks them up.


 I was able to test it only for pl011, don't have any board with pl010.

Sadly I was wrong, I only have pl011 also. It makes me wonder how it
worked so nicely for me without your patches.

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


Re: [U-Boot] [PATCH 1/2] ARM: rpi: rename rpi_b to rpi

2014-11-24 Thread Simon Glass
On 19 November 2014 at 20:41, Stephen Warren swar...@wwwdotorg.org wrote:
 The U-Boot port runs on a variety of RPi models, not just the B. So,
 rename the port to something slightly more generic.

 Signed-off-by: Stephen Warren swar...@wwwdotorg.org
 ---
 These two patches are based on ARM: rpi_b: detect board revision which
 I sent recently.
 ---
  arch/arm/Kconfig   | 6 +++---
  board/raspberrypi/{rpi_b = rpi}/Kconfig   | 6 +++---
  board/raspberrypi/rpi/MAINTAINERS  | 6 ++
  board/raspberrypi/{rpi_b = rpi}/Makefile  | 2 +-
  board/raspberrypi/{rpi_b/rpi_b.c = rpi/rpi.c} | 0
  board/raspberrypi/rpi_b/MAINTAINERS| 6 --
  common/lcd.c   | 2 +-
  configs/rpi_b_defconfig| 2 --
  configs/rpi_defconfig  | 2 ++
  doc/README.clang   | 4 ++--
  include/configs/{rpi_b.h = rpi.h} | 0
  11 files changed, 18 insertions(+), 18 deletions(-)
  rename board/raspberrypi/{rpi_b = rpi}/Kconfig (71%)
  create mode 100644 board/raspberrypi/rpi/MAINTAINERS
  rename board/raspberrypi/{rpi_b = rpi}/Makefile (96%)
  rename board/raspberrypi/{rpi_b/rpi_b.c = rpi/rpi.c} (100%)
  delete mode 100644 board/raspberrypi/rpi_b/MAINTAINERS
  delete mode 100644 configs/rpi_b_defconfig
  create mode 100644 configs/rpi_defconfig
  rename include/configs/{rpi_b.h = rpi.h} (100%)

Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] ARM: rpi: support an environment

2014-11-24 Thread Simon Glass
On 19 November 2014 at 20:41, Stephen Warren swar...@wwwdotorg.org wrote:
 Enable ENV_IS_IN_FAT so that the environment can be stored persistently.
 It's stored in the FAT partition that the RPi firmware requires. On most
 RPis, this is on the SD card (which must be present in order for the
 system to boot). On the CM this is on the built-in eMMC device.

 Since we now have a persistent environment, there's no need to load
 uEnv.txt at boot; we only did that to work around the lack of persistent
 environment.

 Signed-off-by: Stephen Warren swar...@wwwdotorg.org

Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Raspberry Pi with driver model

2014-11-24 Thread Simon Glass
Hi Stephen,

There was another thread where you reported a hang when booting
Raspberry Pi with driver model. It can be repeated by applying this
patch and trying to boot with syslinux.

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

When it hangs, the HDMI display displays lots of spaces, then lots of
dots, scrolling forever. The serial console displays nothing further.

I narrowed the problem down to writing to address 0. So it is easy to
repeat with something like 'mw 0 0'.

However I'm really not sure what is going on. Something with driver
model seems to make address 0 sensitive to writes. I can't see what
that might be, but I don't understand the platform very well. Do you
have any ideas?

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


Re: [U-Boot] [PATCH 2/2] Exynos5800: The Peach-Pi board does not have a Parade video bridge

2014-11-24 Thread Simon Glass
Hi Sjoerd,

On 24 November 2014 at 08:15, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
 Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the
 Pi. So drop it from the board configuration  device-tree

 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
  arch/arm/dts/exynos5800-peach-pi.dts | 5 -
  include/configs/peach-pi.h   | 2 --
  2 files changed, 7 deletions(-)

 diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
 b/arch/arm/dts/exynos5800-peach-pi.dts
 index 8aedf8e..2f9d2db 100644
 --- a/arch/arm/dts/exynos5800-peach-pi.dts
 +++ b/arch/arm/dts/exynos5800-peach-pi.dts
 @@ -63,11 +63,6 @@
   reg = 0x20;
   compatible = maxim,max98090-codec;
};
 -
 -   edp-lvds-bridge@48 {
 -   compatible = parade,ps8625;
 -   reg = 0x48;
 -   };
 };

  sound@383 {
 diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h
 index 8a82402..ff31728 100644
 --- a/include/configs/peach-pi.h
 +++ b/include/configs/peach-pi.h
 @@ -26,8 +26,6 @@
  #define CONFIG_SYS_PROMPT  Peach-Pi # 
  #define CONFIG_IDENT_STRING for Peach-Pi

 -#define CONFIG_VIDEO_PARADE
 -
  /* Display */
  #define CONFIG_LCD
  #ifdef CONFIG_LCD
 --
 2.1.3


Does it fix the problem if you just remove it from the device tree?

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


[U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-24 Thread Lubomir Popov
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either the write
does not come into effect at all, or normal operation of internal circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.

This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes in a single bus transaction if
CONFIG_SYS_I2C_BULK_WRITE is defined in the board header (otherwise the old
method shall compile).

Signed-off-by: Lubomir Popov l-po...@ti.com
---
 common/cmd_i2c.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 3a75f94..7116458 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[
return cmd_usage(cmdtp);

/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
 */
length = simple_strtoul(argv[4], NULL, 16);

+#if defined(CONFIG_SYS_I2C_BULK_WRITE)
+   /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page bounady.
+*/
+   if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
+   puts(Error writing to the chip.\n);
+   return 1;
+   }
+#else
+   /* Perform length separate write transactions of one byte each */
while (length--  0) {
if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
puts(Error writing to the chip.\n);
@@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[
udelay(11000);
 #endif
}
+#endif
return 0;
 }

-- 
1.7.9.5

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


[U-Boot] [PATCH 1/5] sunxi: display: Remove unused HDMI register addr defines

2014-11-24 Thread Hans de Goede
All hdmi code uses struct sunxi_hdmi_reg, so these are not needed.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/include/asm/arch-sunxi/display.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/display.h 
b/arch/arm/include/asm/arch-sunxi/display.h
index c17c3c3..ddb71c1 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -91,19 +91,6 @@ struct sunxi_lcdc_reg {
u32 tcon1_io_tristate;  /* 0xf4 */
 };
 
-#define SUNXI_HDMI_CTRL0x004
-#define SUNXI_HDMI_INT_CTRL0x008
-#define SUNXI_HDMI_HPD 0x00c
-#define SUNXI_HDMI_VIDEO_CTRL  0x010
-#define SUNXI_HDMI_VIDEO_SIZE  0x014
-#define SUNXI_HDMI_VIDEO_BP0x018
-#define SUNXI_HDMI_VIDEO_FP0x01c
-#define SUNXI_HDMI_VIDEO_SPW   0x020
-#define SUNXI_HDMI_VIDEO_POLARITY  0x024
-#define SUNXI_HDMI_TX_DRIVER0  0x200
-#define SUNXI_HDMI_TX_DRIVER1  0x204
-#define SUNXI_HDMI_TX_DRIVER2  0x208
-#define SUNXI_HDMI_TX_DRIVER3  0x20C
 struct sunxi_hdmi_reg {
u32 version_id; /* 0x000 */
u32 ctrl;   /* 0x004 */
-- 
2.1.0

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


[U-Boot] [PATCH 2/5] sunxi: display: Do not use eprintf in early boot

2014-11-24 Thread Hans de Goede
stderr is not hooked up yet as this point, so use a regular printf.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 drivers/video/sunxi_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index fb28c23..5154084 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -351,7 +351,7 @@ retry:
(SUNXI_HDMI_IRQ_STATUS_FIFO_UF | SUNXI_HDMI_IRQ_STATUS_FIFO_OF)) {
if (retries--)
goto retry;
-   eprintf(HDMI fifo under or overrun\n);
+   printf(HDMI fifo under or overrun\n);
}
 }
 
-- 
2.1.0

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


[U-Boot] [PATCH 0/5] sunxi: display: Add DDC EDID support

2014-11-24 Thread Hans de Goede
Hi Ian and Anatolij,

The first 2 patches here are minor fixes to the existing sunxi display code,
a quick review would be appreciated, so that I can queue them up for the
next pull-req.

The other 3 patches are for next, so you can take your time reviewing them.

Anatolij, patches 3 and 4 add 2 new edid utility functions, so a review from
you would be appreciated. Patch 5 uses them, so your input there would be
appreciated too.

Regards,

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


[U-Boot] [PATCH 5/5] sunxi: display: Add DDC EDID support

2014-11-24 Thread Hans de Goede
Add DDC  EDID support and use it to automatically select the native mode of
the attached monitor. This can be overriden through the hdmi_mode env.
variable.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/include/asm/arch-sunxi/display.h |  85 
 drivers/video/sunxi_display.c | 164 +-
 include/configs/sunxi-common.h|   1 +
 3 files changed, 249 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/display.h 
b/arch/arm/include/asm/arch-sunxi/display.h
index ddb71c1..8c4835e 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -107,6 +107,48 @@ struct sunxi_hdmi_reg {
u32 pad_ctrl1;  /* 0x204 */
u32 pll_ctrl;   /* 0x208 */
u32 pll_dbg0;   /* 0x20c */
+   u32 pll_dbg1;   /* 0x210 */
+   u32 hpd_cec;/* 0x214 */
+   u8 res1[0x28];  /* 0x218 */
+   u32 spd_pkt;/* 0x240 */
+   u8 res2[0xac];  /* 0x244 */
+   u32 pkt_ctrl0;  /* 0x2f0 */
+   u32 pkt_ctrl1;  /* 0x2f4 */
+   u8 res3[0x18];  /* 0x2f8 */
+   u32 audio_sample_count; /* 0x310 */
+   u8 res4[0xec];  /* 0x314 */
+   u32 audio_tx_fifo;  /* 0x400 */
+   u8 res5[0xfc];  /* 0x404 */
+#ifndef CONFIG_MACH_SUN6I
+   u32 ddc_ctrl;   /* 0x500 */
+   u32 ddc_addr;   /* 0x504 */
+   u32 ddc_int_mask;   /* 0x508 */
+   u32 ddc_int_status; /* 0x50c */
+   u32 ddc_fifo_ctrl;  /* 0x510 */
+   u32 ddc_fifo_status;/* 0x514 */
+   u32 ddc_fifo_data;  /* 0x518 */
+   u32 ddc_byte_count; /* 0x51c */
+   u32 ddc_cmnd;   /* 0x520 */
+   u32 ddc_exreg;  /* 0x524 */
+   u32 ddc_clock;  /* 0x528 */
+   u8 res6[0x14];  /* 0x52c */
+   u32 ddc_line_ctrl;  /* 0x540 */
+#else
+   u32 ddc_ctrl;   /* 0x500 */
+   u32 ddc_exreg;  /* 0x504 */
+   u32 ddc_cmnd;   /* 0x508 */
+   u32 ddc_addr;   /* 0x50c */
+   u32 ddc_int_mask;   /* 0x510 */
+   u32 ddc_int_status; /* 0x514 */
+   u32 ddc_fifo_ctrl;  /* 0x518 */
+   u32 ddc_fifo_status;/* 0x51c */
+   u32 ddc_clock;  /* 0x520 */
+   u32 ddc_timeout;/* 0x524 */
+   u8 res6[0x18];  /* 0x528 */
+   u32 ddc_dbg;/* 0x540 */
+   u8 res7[0x3c];  /* 0x544 */
+   u32 ddc_fifo_data;  /* 0x580 */
+#endif
 };
 
 /*
@@ -182,6 +224,49 @@ struct sunxi_hdmi_reg {
 #define SUNXI_HDMI_PLL_DBG0_PLL3   (0  21)
 #define SUNXI_HDMI_PLL_DBG0_PLL7   (1  21)
 
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_HMDI_DDC_CTRL_ENABLE (1  0)
+#define SUNXI_HMDI_DDC_CTRL_SCL_ENABLE (1  4)
+#define SUNXI_HMDI_DDC_CTRL_SDA_ENABLE (1  6)
+#define SUNXI_HMDI_DDC_CTRL_START  (1  27)
+#define SUNXI_HMDI_DDC_CTRL_RESET  (1  31)
+#else
+#define SUNXI_HMDI_DDC_CTRL_RESET  (1  0)
+/* sun4i / sun5i / sun7i do not have a separate line_ctrl reg */
+#define SUNXI_HMDI_DDC_CTRL_SDA_ENABLE 0
+#define SUNXI_HMDI_DDC_CTRL_SCL_ENABLE 0
+#define SUNXI_HMDI_DDC_CTRL_START  (1  30)
+#define SUNXI_HMDI_DDC_CTRL_ENABLE (1  31)
+#endif
+
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_HMDI_DDC_ADDR_SLAVE_ADDR (0xa0  0)
+#else
+#define SUNXI_HMDI_DDC_ADDR_SLAVE_ADDR (0x50  0)
+#endif
+#define SUNXI_HMDI_DDC_ADDR_OFFSET(n)  (((n)  0xff)  8)
+#define SUNXI_HMDI_DDC_ADDR_EDDC_ADDR  (0x60  16)
+#define SUNXI_HMDI_DDC_ADDR_EDDC_SEGMENT(n)((n)  24)
+
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_HDMI_DDC_FIFO_CTRL_CLEAR (1  15)
+#else
+#define SUNXI_HDMI_DDC_FIFO_CTRL_CLEAR (1  31)
+#endif
+
+#define SUNXI_HDMI_DDC_CMND_EXPLICIT_EDDC_READ 6
+#define SUNXI_HDMI_DDC_CMND_IMPLICIT_EDDC_READ 7
+
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_HDMI_DDC_CLOCK   0x61
+#else
+/* N = 5,M=1 Fscl= Ftmds/2/10/2^N/(M+1) */
+#define SUNXI_HDMI_DDC_CLOCK   0x0d
+#endif
+
+#define SUNXI_HMDI_DDC_LINE_CTRL_SCL_ENABLE(1  8)
+#define SUNXI_HMDI_DDC_LINE_CTRL_SDA_ENABLE(1  9)
+
 int sunxi_simplefb_setup(void *blob);
 
 #endif /* _SUNXI_DISPLAY_H */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 5154084..9f31ac5 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
 #include asm/arch/display.h
 #include 

[U-Boot] [PATCH 4/5] edid: Add an edid_check_checksum() helper function

2014-11-24 Thread Hans de Goede
Add a helper function to check the checksum of an EDID data block.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 common/edid.c  | 11 +++
 include/edid.h |  9 +
 2 files changed, 20 insertions(+)

diff --git a/common/edid.c b/common/edid.c
index e41cd3e..e5d35b2 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -353,3 +353,14 @@ int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
 
return 0;
 }
+
+int edid_check_checksum(u8 *edid_block)
+{
+   u8 checksum = 0;
+   int i;
+
+   for (i = 0; i  128; i++)
+   checksum += edid_block[i];
+
+   return (checksum == 0) ? 0 : -EINVAL;
+}
diff --git a/include/edid.h b/include/edid.h
index d66f76b..b32f42c 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -273,4 +273,13 @@ int edid_get_ranges(struct edid1_info *edid, unsigned int 
*hmin,
 int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
   struct fb_videomode *mode, char *name, int name_len);
 
+/**
+ * Check checksum of a 128 bytes EDID data block
+ *
+ * @param edid_block   EDID block data
+ *
+ * @return 0 on success, or a negative errno on error
+ */
+int edid_check_checksum(u8 *edid_block);
+
 #endif /* __EDID_H_ */
-- 
2.1.0

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


[U-Boot] [PATCH 3/5] edid: Add an edid_dtd_to_fbmode() helper function

2014-11-24 Thread Hans de Goede
Various u-boot video drivers use fb_videomode structs to store timing info,
add a helper function to convert an EDID detailed timing into a fb_videomode
struct.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 common/edid.c  | 65 ++
 include/edid.h | 18 
 2 files changed, 83 insertions(+)

diff --git a/common/edid.c b/common/edid.c
index e66108f..e41cd3e 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -12,6 +12,7 @@
 
 #include common.h
 #include edid.h
+#include errno.h
 #include linux/ctype.h
 #include linux/string.h
 
@@ -288,3 +289,67 @@ void edid_print_info(struct edid1_info *edid_info)
if (!have_timing)
printf(\tNone\n);
 }
+
+int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
+  struct fb_videomode *mode, char *name, int name_len)
+{
+   int margin, h_total, v_total;
+
+   if (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) == 0 ||
+   EDID_DETAILED_TIMING_HORIZONTAL_ACTIVE(*t) == 0 ||
+   EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t) == 0 ||
+   EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 ||
+   EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 ||
+   EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 ||
+   EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 ||
+   EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 ||
+   EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0)
+   return -EINVAL;
+
+   mode-name = name;
+   mode-xres = EDID_DETAILED_TIMING_HORIZONTAL_ACTIVE(*t);
+   mode-yres = EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t);
+   mode-pixclock = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) /
+1000;
+
+   mode-left_margin = EDID_DETAILED_TIMING_HSYNC_OFFSET(*t);
+   mode-hsync_len = EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t);
+   margin = EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t) -
+   (mode-left_margin + mode-hsync_len);
+   if (margin = 0)
+   return -EINVAL;
+
+   mode-right_margin = margin;
+
+   mode-lower_margin = EDID_DETAILED_TIMING_VSYNC_OFFSET(*t);
+   mode-vsync_len = EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t);
+   margin = EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) -
+   (mode-lower_margin + mode-vsync_len);
+   if (margin = 0)
+   return -EINVAL;
+
+   mode-upper_margin = margin;
+
+   if (EDID_DETAILED_TIMING_FLAG_INTERLEAVED(*t))
+   mode-vmode = FB_VMODE_INTERLACED;
+   else
+   mode-vmode = FB_VMODE_NONINTERLACED;
+
+   mode-sync = 0;
+   if (EDID_DETAILED_TIMING_FLAG_HSYNC_POLARITY(*t))
+   mode-sync |= FB_SYNC_HOR_HIGH_ACT;
+   if (EDID_DETAILED_TIMING_FLAG_VSYNC_POLARITY(*t))
+   mode-sync |= FB_SYNC_VERT_HIGH_ACT;
+
+   mode-flag = 0;
+
+   h_total = mode-xres + EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t);
+   v_total = mode-yres + EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t);
+   mode-refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) /
+   (h_total * v_total);
+
+   snprintf(name, name_len, %dx%d@%d, mode-xres, mode-yres,
+mode-refresh);
+
+   return 0;
+}
diff --git a/include/edid.h b/include/edid.h
index 480a773..d66f76b 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -13,6 +13,7 @@
 #ifndef __EDID_H_
 #define __EDID_H_
 
+#include linux/fb.h
 #include linux/types.h
 
 #define GET_BIT(_x, _pos) \
@@ -86,6 +87,10 @@ struct edid_detailed_timing {
GET_BITS((_x).flags, 4, 3)
 #define EDID_DETAILED_TIMING_FLAG_POLARITY(_x) \
GET_BITS((_x).flags, 2, 1)
+#define EDID_DETAILED_TIMING_FLAG_VSYNC_POLARITY(_x) \
+   GET_BIT((_x).flags, 2)
+#define EDID_DETAILED_TIMING_FLAG_HSYNC_POLARITY(_x) \
+   GET_BIT((_x).flags, 1)
 #define EDID_DETAILED_TIMING_FLAG_INTERLEAVED(_x) \
GET_BIT((_x).flags, 0)
 } __attribute__ ((__packed__));
@@ -255,4 +260,17 @@ int edid_get_ranges(struct edid1_info *edid, unsigned int 
*hmin,
unsigned int *hmax, unsigned int *vmin,
unsigned int *vmax);
 
+/**
+ * Convert an EDID detailed timing to a fb_videomode
+ *
+ * @param tThe EDID detailed timing to be converted
+ * @param mode Returns the converted timing
+ * @param name Buffer for the mode name mode-name will be set to this
+ * @param name_len Length of name
+ *
+ * @return 0 on success, or a negative errno on error
+ */
+int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
+  struct fb_videomode *mode, char *name, int name_len);
+
 #endif /* __EDID_H_ */
-- 
2.1.0

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


Re: [U-Boot] [PATCH 2/2] Exynos5800: The Peach-Pi board does not have a Parade video bridge

2014-11-24 Thread Sjoerd Simons
On Mon, 2014-11-24 at 09:01 -0700, Simon Glass wrote:
 Hi Sjoerd,
 
 On 24 November 2014 at 08:15, Sjoerd Simons
 sjoerd.sim...@collabora.co.uk wrote:
  Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the
  Pi. So drop it from the board configuration  device-tree
 
  Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
  ---
   arch/arm/dts/exynos5800-peach-pi.dts | 5 -
   include/configs/peach-pi.h   | 2 --
   2 files changed, 7 deletions(-)
 
  diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
  b/arch/arm/dts/exynos5800-peach-pi.dts
  index 8aedf8e..2f9d2db 100644
  --- a/arch/arm/dts/exynos5800-peach-pi.dts
  +++ b/arch/arm/dts/exynos5800-peach-pi.dts
  @@ -63,11 +63,6 @@
reg = 0x20;
compatible = maxim,max98090-codec;
 };
  -
  -   edp-lvds-bridge@48 {
  -   compatible = parade,ps8625;
  -   reg = 0x48;
  -   };
  };
 
   sound@383 {
  diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h
  index 8a82402..ff31728 100644
  --- a/include/configs/peach-pi.h
  +++ b/include/configs/peach-pi.h
  @@ -26,8 +26,6 @@
   #define CONFIG_SYS_PROMPT  Peach-Pi # 
   #define CONFIG_IDENT_STRING for Peach-Pi
 
  -#define CONFIG_VIDEO_PARADE
  -
   /* Display */
   #define CONFIG_LCD
   #ifdef CONFIG_LCD
  --
  2.1.3
 
 
 Does it fix the problem if you just remove it from the device tree?

That should indeed work as well, but i haven't tested it thusfar.

Would you simply like to see that tested, or are you suggesting to keep
CONFIG_VIDEO_PARADE around ?


-- 
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.


smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/5] sunxi: display: Do not use eprintf in early boot

2014-11-24 Thread Ian Campbell
On Mon, 2014-11-24 at 17:14 +0100, Hans de Goede wrote:
 stderr is not hooked up yet as this point, so use a regular printf.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Acked-by: Ian Campbell i...@hellion.org.uk


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


Re: [U-Boot] [PATCH 1/5] sunxi: display: Remove unused HDMI register addr defines

2014-11-24 Thread Ian Campbell
On Mon, 2014-11-24 at 17:14 +0100, Hans de Goede wrote:
 All hdmi code uses struct sunxi_hdmi_reg, so these are not needed.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Acked-by: Ian Campbell i...@hellion.org.uk


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


Re: [U-Boot] [PATCH 2/2] Exynos5800: The Peach-Pi board does not have a Parade video bridge

2014-11-24 Thread Simon Glass
Hi Sjoerd,

On 24 November 2014 at 09:21, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
 On Mon, 2014-11-24 at 09:01 -0700, Simon Glass wrote:
 Hi Sjoerd,

 On 24 November 2014 at 08:15, Sjoerd Simons
 sjoerd.sim...@collabora.co.uk wrote:
  Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the
  Pi. So drop it from the board configuration  device-tree
 
  Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
  ---
   arch/arm/dts/exynos5800-peach-pi.dts | 5 -
   include/configs/peach-pi.h   | 2 --
   2 files changed, 7 deletions(-)
 
  diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
  b/arch/arm/dts/exynos5800-peach-pi.dts
  index 8aedf8e..2f9d2db 100644
  --- a/arch/arm/dts/exynos5800-peach-pi.dts
  +++ b/arch/arm/dts/exynos5800-peach-pi.dts
  @@ -63,11 +63,6 @@
reg = 0x20;
compatible = maxim,max98090-codec;
 };
  -
  -   edp-lvds-bridge@48 {
  -   compatible = parade,ps8625;
  -   reg = 0x48;
  -   };
  };
 
   sound@383 {
  diff --git a/include/configs/peach-pi.h b/include/configs/peach-pi.h
  index 8a82402..ff31728 100644
  --- a/include/configs/peach-pi.h
  +++ b/include/configs/peach-pi.h
  @@ -26,8 +26,6 @@
   #define CONFIG_SYS_PROMPT  Peach-Pi # 
   #define CONFIG_IDENT_STRING for Peach-Pi
 
  -#define CONFIG_VIDEO_PARADE
  -
   /* Display */
   #define CONFIG_LCD
   #ifdef CONFIG_LCD
  --
  2.1.3
 

 Does it fix the problem if you just remove it from the device tree?

 That should indeed work as well, but i haven't tested it thusfar.

 Would you simply like to see that tested, or are you suggesting to keep
 CONFIG_VIDEO_PARADE around ?

Some background - I'd like to have an exynos5-dt board config which is
used by the various Chromebooks (and perhaps other boards to) where
the only difference is the device tree. At present the peach-pi.h file
is mostly identical to peach-pit.h, so then we can avoid #ifdefs in
the code, etc.

For memory size we can specify it with device tree, although the patch
for this has yet to land.

So in general I'm keen for this peach-pi.h file to go away and be
replaced with a CONFIG_DEFAULT_DEVICE_TREE line in the defconfig. If
all you need to change is the device tree then that is best.

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


[U-Boot] [PATCH] fs/ext4/ext4fs.c, fs/fs.c: Use lldiv and multiplication / subtraction on 64bit ops

2014-11-24 Thread Tom Rini
In some cases we need to do math on 64bit quantities.  We need to be
using lldiv in these cases rather than letting the compiler do it.  In
addition we need to avoid doing % operations on these same quantities.
These changes fix compilation on MIPS/MIPSEL.

Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
Cc: Suriyan Ramasami suriya...@gmail.com
Cc: Simon Glass s...@chromium.org
Signed-off-by: Tom Rini tr...@ti.com
---
 fs/ext4/ext4fs.c |   11 ++-
 fs/fs.c  |3 ++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 943b5bc..258b9379 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -25,6 +25,7 @@
 #include ext_common.h
 #include ext4fs.h
 #include ext4_common.h
+#include div64.h
 
 int ext4fs_symlinknest;
 struct ext_filesystem ext_fs;
@@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
if (len  filesize)
len = filesize;
 
-   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
+   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
 
-   for (i = pos / blocksize; i  blockcnt; i++) {
+   for (i = lldiv(pos, blocksize); i  blockcnt; i++) {
lbaint_t blknr;
-   int blockoff = pos % blocksize;
+   int blockoff = pos - (blocksize * i);
int blockend = blocksize;
int skipfirst = 0;
blknr = read_allocated_block((node-inode), i);
@@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 
/* Last block.  */
if (i == blockcnt - 1) {
-   blockend = (len + pos) % blocksize;
+   blockend = (len + pos) - (blocksize * i);
 
/* The last portion is exactly blocksize. */
if (!blockend)
@@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
}
 
/* First block. */
-   if (i == pos / blocksize) {
+   if (i == lldiv(pos, blocksize)) {
skipfirst = blockoff;
blockend -= skipfirst;
}
diff --git a/fs/fs.c b/fs/fs.c
index 3da7860..760f4a6 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -17,6 +17,7 @@
 #include config.h
 #include errno.h
 #include common.h
+#include div64.h
 #include part.h
 #include ext4fs.h
 #include fat.h
@@ -399,7 +400,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
printf(%llu bytes read in %lu ms, len_read, time);
if (time  0) {
puts( ();
-   print_size(len_read / time * 1000, /s);
+   print_size(lldiv(len_read, time * 1000), /s);
puts());
}
puts(\n);
-- 
1.7.9.5

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


Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND

2014-11-24 Thread York Sun
On 11/23/2014 11:30 PM, Joakim Tjernlund wrote:
 York Sun york...@freescale.com wrote on 2014/10/24 18:02:03:

 On 10/24/2014 08:39 AM, Joakim Tjernlund wrote:
 Booting my t1042 I get:
 Loading Ramdisk to 2e639000, end 2cc4 ... OK
 Loading Device Tree to 03fe4000, end 03fffd45 ... OK
 WARNING Could not get liodn of node /pcie@ffe24: FDT_ERR_NOTFOUND
 WARNING Could not get liodn of node /pcie@ffe25: FDT_ERR_NOTFOUND
 WARNING Could not get liodn of node /pcie@ffe24: FDT_ERR_NOTFOUND
 WARNING Could not get liodn of node /pcie@ffe25: FDT_ERR_NOTFOUND
 

 This apperas to come from 
 base_liodn = fdt_getprop(fdt, off, fsl,liodn, rc);
 if (!base_liodn) {
 char path[64];

 if (fdt_get_path(fdt, off, path, sizeof(path)) 
  
 0)
 strcpy(path, (unknown));
 printf(WARNING Could not get liodn of node 
 %s: 
 %s\n,
path, fdt_strerror(rc));
 continue;
 }

 but I cannot find out  what what this property should be. Anyone?


 Laurentiu,

 Can you take a look?

 York
 
 I might have missed it, but did this go anywhere?
 

No. It didn't go anywhere. Laurentiu, can you follow up?

York

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Douglas Rupp
I built qemu-system-arm from the xilinx-master branch.   xilinx-zynq-a9 is
not a supported machine. :(

On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp douglas.b.r...@gmail.com
wrote:

 It's the version of qemu-system-arm downloaded for Ubuntu 14.04
 Version info:
 qemu-system-arm --version
 QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)

 I also tried the three boot.bin files in 2014.3-release.tar.gz
 downloaded from the Xilinx website, those in subdirectories zc70x/zc706/
 and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no output.

 I also tried the version 2.0.0 version of qemu-system-arm from the
 open-do.org website that we regular use with xlnx-zynq-a9 bsp for
 vxworks7, it boots vxworks without uboot, but hangs with uboot.

 You're suggesting that only the qemu-system-arm built from the xilinx repo
 is functional with uboot?  I used that version of qemu about a year ago,
 and it worked fine for Linux but it was an ancient version of qemu (at that
 time).

 On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki jagannadh.t...@gmail.com
 wrote:

 On 24 November 2014 at 06:03, Douglas Rupp douglas.b.r...@gmail.com
 wrote:
  I'm brand new to Uboot, so hopefully this is just some missing switch.
 I
  did search the archive, and I was able to build and u-boot a
 versaatilepb
  version, but xilinx-zynq-a9 is the one I really need.
 
  u-boot-2014.10$ make zynq_zed_defconfig
  u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm
  u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M -nographic
  -kernel u-boot-dtb.bin
  Segmentation fault (core dumped)

 I guess it may be qemu usage issue, is qemu from
 https://github.com/Xilinx/qemu ?

 + Peter
 Hope, he will give some inputs

 
  What am I doing wrong?

 thanks!
 --
 Jagan.



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


Re: [U-Boot] [PATCH v3 2/4] tegra: dts: Sync tegra124.dtsi with linux kernel

2014-11-24 Thread Stephen Warren

On 11/23/2014 09:12 AM, Simon Glass wrote:

Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to
supported in U-Boot soon (regulators, pinmux). Also the addresses are
updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings
for pinctrl.


Assuming this content exactly matches the kernel,
Acked-by: Stephen Warren swar...@nvidia.com

Do all the existing nodes exactly match the kernel already?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/4] tegra: config: Enable FIT and device tree for all boards

2014-11-24 Thread Stephen Warren

On 11/23/2014 09:12 AM, Simon Glass wrote:

Modern kernels require a device tree to boot.


True.

 Enable FIT support to permit

booting these images, rather than just legacy images.


I don't understand this? Modern kernels boot perfectly well without FIT 
support. U-Boot supports the kernel's standard separate DTB and zImage 
file formats just fine.


To be honest, I'd strongly prefer not to enable support for 
non-universal (bootloader-specific) formats such as FIT.



This allows booting of Chrome OS kernels, among other things.


This might be a reasonable justification to support FIT. However, it'd 
be best to enable FIT support only on boards that are actually supported 
by ChromeOS, so as not to pollute other boards' configuration.

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


Re: [U-Boot] [PATCH v3 2/4] tegra: dts: Sync tegra124.dtsi with linux kernel

2014-11-24 Thread Simon Glass
Hi Stephen,

On 24 November 2014 at 10:09, Stephen Warren swar...@wwwdotorg.org wrote:
 On 11/23/2014 09:12 AM, Simon Glass wrote:

 Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to
 supported in U-Boot soon (regulators, pinmux). Also the addresses are
 updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings
 for pinctrl.

 Assuming this content exactly matches the kernel,
 Acked-by: Stephen Warren swar...@nvidia.com

 Do all the existing nodes exactly match the kernel already?

Apart from the differences noted in the commit message, yes.

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


Re: [U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board

2014-11-24 Thread Stephen Warren

On 11/23/2014 10:02 AM, Simon Glass wrote:

Hi,

On 23 November 2014 at 09:12, Simon Glass s...@chromium.org wrote:


From: Allen Martin amar...@nvidia.com

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.

The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.

Signed-off-by: Allen Martin amar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
(rebase, change to 'nyan', fix pinmux that resets nyan)

---

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts


I should say that I'm not thrilled with this approach, particularly as
the files it generate have no mentioned that they are auto-generated.
Here we have a case where Nyan and Norrin apparently different by one
pixmux setting but there is no way to exploit this commonality.

I think this was discussed a while ago (the idea of static pinmux
being set up at start of day). If I recall I expressed my objections
at the time. If U-Boot headed this way in general it would be
unfortunate. You get a whole load of pinmux settings with no idea what
they are for, and no idea how to change them for your board. It almost
feels similar to a 'binary blob'.


That's the entire point; people should not be randomly fiddling with the 
pinmux data in U-Boot for any reason.


The model for Tegra boards is that whoever designs the boards fills out 
a spreadsheet to define the pinmux for the board. That spreadsheet is 
coded to detect and avoid a lot of mistakes (such as multiple pins muxed 
to/from the same signal, redundant pull-ups enabled on board and SoC, 
pins used for purposes incompatible with what the SoC supports, etc.). 
Any pinmux changes should be made in that spreadsheet, and all SW should 
use the values exported from or derived from the spreadsheet. There's no 
reason to modify the values afterwards.


This is similar to a binary blob in that the data shouldn't be modified.

This is quite different from a binary blob in that it's quite obvious 
exactly what the data represents semantically; it's a quite plain-text 
format. with non-obfuscated code to implement it, which directly maps to 
reasonably well documented hardware.



I recently saw a patch to (from what I can tell) remove all the pinmux
information from the device tree in Linux, presumably on the
assumption it can never be changed except very early in the boot. If
this is a limitation of Tegra then it seems unfortunate to me.


It's to avoid redundant work. Bootloaders are expected to set up 100% of 
the pinmux[1]. Given that, there's no point the kernel repeating the 
process of setting up the exact same configuration.


[1] This is the only sane way to avoid conflicts between mux settings of 
different pins. Only partially programming the pinmux can leave other 
pins muxed to the same controller/signal for example. Resolving that 
requires hit-and-miss testing or complex table lookups to reprogram pins 
that conflict that otherwise wouldn't be programmed. That approach could 
cause undesired glitches on pins as they're continually reprogrammed 
between different states to avoid conflicts. The simplest and only 100% 
guaranteed way to avoid this is to simply program everything directly to 
the desired final configuration. This issue isn't anything Tegra 
specific either, but applies to any pinmux controller where the same 
signal can be routed to multiple pins/pads. I believe the only reason 
this hasn't been so explicitly addressed before is that people just 
haven't thought it through at this level.

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


Re: [U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board

2014-11-24 Thread Stephen Warren

On 11/23/2014 10:02 AM, Simon Glass wrote:

Hi,

On 23 November 2014 at 09:12, Simon Glass s...@chromium.org wrote:


From: Allen Martin amar...@nvidia.com

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.

The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.

Signed-off-by: Allen Martin amar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
(rebase, change to 'nyan', fix pinmux that resets nyan)

---

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts


I should say that I'm not thrilled with this approach, particularly as
the files it generate have no mentioned that they are auto-generated.


Oh I forgot to mention - feel free to send a patch for that. I mainly 
didn't add such a message earlier, since I when I wrote the U-Boot 
header generator in tegra-pinmux-scripts, I wanted to generate exactly 
the same data as was already there in U-Boot in the manually written 
files. If you think updating those files to add a this is 
auto-generated message would be useful, feel free to send a patch to 
tegra-pinmux-scripts and we can add it.

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


Re: [U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board

2014-11-24 Thread Stephen Warren

On 11/23/2014 09:12 AM, Simon Glass wrote:

From: Allen Martin amar...@nvidia.com

Nyan is a Tegra124 clamshell board that is very similar to venice2, but it
has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.


As Olof explained it to me, Nyan is a family of boards, of which Nyan 
Big is a particular member. In other words, Nyan Big is the CB5. As 
such, I believe the U-Boot board should be named Nyan Big not Nyan, 
unless we expect the U-Boot support for work for the various other Nyan 
family boards; I believe the HP Tegra Chromebooks are also in the Nyan 
family. Either way though (i.e. even if nyan.c gets shared between the 
Acer and HP Tegra Chromebooks), I still think we want separate top-level 
U-Boot board names for the two, so that it's easy for people to build 
the right DT into their U-Boot binary for example.

___
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

2014-11-24 Thread Albert ARIBAUD
Hi Tom,

The following changes since commit 0d485b9095328cdc81b2ee94ff59b988c69b9127:

  Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2014-11-13 10:35:13 
-0500)

are available in the git repository at:

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

for you to fetch changes up to 8bc347e2ec17bca44b1639a001eeed50d042f0db:

  ARM: bootm: Allow booting in secure mode on hyp capable systems (2014-11-24 
09:09:52 +0100)


Hans de Goede (2):
  ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options
  ARM: bootm: Allow booting in secure mode on hyp capable systems

Tom Rini (1):
  Kconfig: Add EXPERT option

 Kconfig |  8 
 arch/arm/Kconfig|  4 
 arch/arm/cpu/armv7/Kconfig  | 34 ++
 arch/arm/cpu/armv7/exynos/Kconfig   |  2 ++
 arch/arm/lib/bootm.c| 31 ++-
 board/sunxi/Kconfig |  2 ++
 include/configs/arndale.h   |  2 --
 include/configs/sun7i.h |  2 --
 include/configs/vexpress_ca15_tc2.h |  2 --
 9 files changed, 76 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/Kconfig

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Douglas Rupp
The result is:

arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2 -machine
linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
SPI device 0x7f8161521ee0
qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0

then a register dump

The boot.bin and devicetree.dtb is from xilinx binary release
2014.3-release/zed

I tried removing -smp 2 -machine linux=on, and same error.

On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann soren.brinkm...@xilinx.com
 wrote:

 Could you try whether these instructions work?
 http://www.wiki.xilinx.com/QEMU

 Sören

 On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
  I built qemu-system-arm from the xilinx-master branch.   xilinx-zynq-a9
 is
  not a supported machine. :(
 
  On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp douglas.b.r...@gmail.com
  wrote:
 
   It's the version of qemu-system-arm downloaded for Ubuntu 14.04
   Version info:
   qemu-system-arm --version
   QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
  
   I also tried the three boot.bin files in 2014.3-release.tar.gz
   downloaded from the Xilinx website, those in subdirectories
 zc70x/zc706/
   and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no output.
  
   I also tried the version 2.0.0 version of qemu-system-arm from the
   open-do.org website that we regular use with xlnx-zynq-a9 bsp for
   vxworks7, it boots vxworks without uboot, but hangs with uboot.
  
   You're suggesting that only the qemu-system-arm built from the xilinx
 repo
   is functional with uboot?  I used that version of qemu about a year
 ago,
   and it worked fine for Linux but it was an ancient version of qemu (at
 that
   time).
  
   On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki jagannadh.t...@gmail.com
 
   wrote:
  
   On 24 November 2014 at 06:03, Douglas Rupp douglas.b.r...@gmail.com
   wrote:
I'm brand new to Uboot, so hopefully this is just some missing
 switch.
   I
did search the archive, and I was able to build and u-boot a
   versaatilepb
version, but xilinx-zynq-a9 is the one I really need.
   
u-boot-2014.10$ make zynq_zed_defconfig
u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm
u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M
 -nographic
-kernel u-boot-dtb.bin
Segmentation fault (core dumped)
  
   I guess it may be qemu usage issue, is qemu from
   https://github.com/Xilinx/qemu ?
  
   + Peter
   Hope, he will give some inputs
  
   
What am I doing wrong?
  
   thanks!
   --
   Jagan.
  
  
  

  ___
  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] [RFC Patch 2/2] driver/usb/fsl: Make FSL USB driver common

2014-11-24 Thread York Sun
On 11/21/2014 08:27 PM, Badola Nikhil-B46172 wrote:
 -Original Message-
 From: York Sun [mailto:york...@freescale.com]
 Sent: Thursday, November 20, 2014 2:55 AM
 To: u-boot@lists.denx.de
 Cc: Sun York-R58495; Wang Huan-B18965; Badola Nikhil-B46172
 Subject: [RFC Patch 2/2] driver/usb/fsl: Make FSL USB driver common

 Add ifdef for powerpc specific code. This driver can be used by arm SoCs.

 Signed-off-by: York Sun york...@freescale.com
 CC: Alison Wang alison.w...@freescale.com
 CC: Nikhil Badola nikhil.bad...@freescale.com
 ---
 This patch is needed if fsl USB driver is enabled for ARM SoCs, like LS1021.

  drivers/usb/host/ehci-fsl.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index
 79fb6b4..994bfd7 100644
 --- a/drivers/usb/host/ehci-fsl.c
 +++ b/drivers/usb/host/ehci-fsl.c
 @@ -130,9 +130,11 @@ int ehci_hcd_init(int index, enum usb_init_type init,

  in_le32(ehci-usbmode);

 +#ifdef CONFIG_PPC
  if (SVR_SOC_VER(get_svr()) == SVR_T4240 
  IS_SVR_REV(get_svr(), 2, 0))
  set_txfifothresh(ehci, TXFIFOTHRESH);
 +#endif
 
 This patch can be replaced by 
 http://patchwork.ozlabs.org/patch/400407/ 

Great! I will drop this patch.

York

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Sören Brinkmann
Could you try whether these instructions work?
http://www.wiki.xilinx.com/QEMU

Sören

On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
 I built qemu-system-arm from the xilinx-master branch.   xilinx-zynq-a9 is
 not a supported machine. :(
 
 On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp douglas.b.r...@gmail.com
 wrote:
 
  It's the version of qemu-system-arm downloaded for Ubuntu 14.04
  Version info:
  qemu-system-arm --version
  QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
 
  I also tried the three boot.bin files in 2014.3-release.tar.gz
  downloaded from the Xilinx website, those in subdirectories zc70x/zc706/
  and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no output.
 
  I also tried the version 2.0.0 version of qemu-system-arm from the
  open-do.org website that we regular use with xlnx-zynq-a9 bsp for
  vxworks7, it boots vxworks without uboot, but hangs with uboot.
 
  You're suggesting that only the qemu-system-arm built from the xilinx repo
  is functional with uboot?  I used that version of qemu about a year ago,
  and it worked fine for Linux but it was an ancient version of qemu (at that
  time).
 
  On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki jagannadh.t...@gmail.com
  wrote:
 
  On 24 November 2014 at 06:03, Douglas Rupp douglas.b.r...@gmail.com
  wrote:
   I'm brand new to Uboot, so hopefully this is just some missing switch.
  I
   did search the archive, and I was able to build and u-boot a
  versaatilepb
   version, but xilinx-zynq-a9 is the one I really need.
  
   u-boot-2014.10$ make zynq_zed_defconfig
   u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm
   u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M -nographic
   -kernel u-boot-dtb.bin
   Segmentation fault (core dumped)
 
  I guess it may be qemu usage issue, is qemu from
  https://github.com/Xilinx/qemu ?
 
  + Peter
  Hope, he will give some inputs
 
  
   What am I doing wrong?
 
  thanks!
  --
  Jagan.
 
 
 

 ___
 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] fix: tools: kwbimage.c: Initialize headersz to suppress warning

2014-11-24 Thread Albert ARIBAUD
Hello Lukasz,

Thank you and Guillaume for the indications. So gcc 4.7.2 and 4.8.1
should exhibit the problem.

Apparently, 4.7.4 and 4.8.3 don't. :(

/me goes and fetches a 4.8.1 somewhere.

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Sören Brinkmann
I don't think boot.bin is a legal kernel. IIRC, I had issues running
on QEMU, but it was slightly better than what you describe.

Sören

On Mon, 2014-11-24 at 09:40AM -0800, Douglas Rupp wrote:
The result is:
 
arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2 -machine
linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
SPI device 0x7f8161521ee0
qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0
 
then a register dump
 
The boot.bin and devicetree.dtb is from xilinx binary release
2014.3-release/zed
 
I tried removing -smp 2 -machine linux=on, and same error.
On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann
[1]soren.brinkm...@xilinx.com wrote:
 
  Could you try whether these instructions work?
  [2]http://www.wiki.xilinx.com/QEMU
 
  Sören
  On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
   I built qemu-system-arm from the xilinx-master branch. 
   xilinx-zynq-a9 is
   not a supported machine. :(
  
   On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp
  [3]douglas.b.r...@gmail.com
   wrote:
  
It's the version of qemu-system-arm downloaded for Ubuntu 14.04
Version info:
qemu-system-arm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
   
I also tried the three boot.bin files in 2014.3-release.tar.gz
downloaded from the Xilinx website, those in subdirectories
  zc70x/zc706/
and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no
  output.
   
I also tried the version 2.0.0 version of qemu-system-arm from the
[4]open-do.org website that we regular use with xlnx-zynq-a9 bsp for
vxworks7, it boots vxworks without uboot, but hangs with uboot.
   
You're suggesting that only the qemu-system-arm built from the
  xilinx repo
is functional with uboot?  I used that version of qemu about a year
  ago,
and it worked fine for Linux but it was an ancient version of qemu
  (at that
time).
   
On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki
  [5]jagannadh.t...@gmail.com
wrote:
   
On 24 November 2014 at 06:03, Douglas Rupp
  [6]douglas.b.r...@gmail.com
wrote:
 I'm brand new to Uboot, so hopefully this is just some missing
  switch.
I
 did search the archive, and I was able to build and u-boot a
versaatilepb
 version, but xilinx-zynq-a9 is the one I really need.

 u-boot-2014.10$ make zynq_zed_defconfig
 u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi- ARCH=arm
 u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M
  -nographic
 -kernel u-boot-dtb.bin
 Segmentation fault (core dumped)
   
I guess it may be qemu usage issue, is qemu from
[7]https://github.com/Xilinx/qemu ?
   
+ Peter
Hope, he will give some inputs
   

 What am I doing wrong?
   
thanks!
--
Jagan.
   
   
   
 
   ___
   U-Boot mailing list
   [8]U-Boot@lists.denx.de
   [9]http://lists.denx.de/mailman/listinfo/u-boot
 
 Links:
 1. mailto:soren.brinkm...@xilinx.com/
 2. http://www.wiki.xilinx.com/QEMU
 3. mailto:douglas.b.r...@gmail.com/
 4. http://open-do.org/
 5. mailto:jagannadh.t...@gmail.com/
 6. mailto:douglas.b.r...@gmail.com/
 7. https://github.com/Xilinx/qemu
 8. mailto:U-Boot@lists.denx.de/
 9. 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] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Douglas Rupp
For versatilepb arm, there's a blog post that describes a recipe of how to
build and boot uboot.bin in qemu.  It works fine, here's the link if
you're interested.
https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/

I assumed that uboot was standardized enough so that it would work the same
for other machine/board emulations. I'd like to understand why it's not
working.

The problem I'm trying to solve is to configure networking in uboot for the
xilinx-zynq-a9 bsp for vxworks7 running under qemu.  Vxworks7 uses uboot
where 6.9 didn't, and the default device tree isn't set correctly for my
network, it just has some random defaults that are expected to be
customized.  The alternative is to use real hardware, which should work
well enough for debugging but in general it's much easier to debug and run
tests in qemu especially when working remotely.

So any ideas you might have on what's special about zynq utboot would be
appreciated.

On Mon, Nov 24, 2014 at 9:45 AM, Sören Brinkmann soren.brinkm...@xilinx.com
 wrote:

 I don't think boot.bin is a legal kernel. IIRC, I had issues running
 on QEMU, but it was slightly better than what you describe.

 Sören

 On Mon, 2014-11-24 at 09:40AM -0800, Douglas Rupp wrote:
 The result is:
 
 arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2
 -machine
 linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
 SPI device 0x7f8161521ee0
 qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0
 
 then a register dump
 
 The boot.bin and devicetree.dtb is from xilinx binary release
 2014.3-release/zed
 
 I tried removing -smp 2 -machine linux=on, and same error.
 On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann
 [1]soren.brinkm...@xilinx.com wrote:
 
   Could you try whether these instructions work?
   [2]http://www.wiki.xilinx.com/QEMU
 
   Sören
   On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
I built qemu-system-arm from the xilinx-master branch.
xilinx-zynq-a9 is
not a supported machine. :(
   
On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp
   [3]douglas.b.r...@gmail.com
wrote:
   
 It's the version of qemu-system-arm downloaded for Ubuntu 14.04
 Version info:
 qemu-system-arm --version
 QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)

 I also tried the three boot.bin files in
 2014.3-release.tar.gz
 downloaded from the Xilinx website, those in subdirectories
   zc70x/zc706/
 and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no
   output.

 I also tried the version 2.0.0 version of qemu-system-arm from
 the
 [4]open-do.org website that we regular use with xlnx-zynq-a9
 bsp for
 vxworks7, it boots vxworks without uboot, but hangs with uboot.

 You're suggesting that only the qemu-system-arm built from the
   xilinx repo
 is functional with uboot?  I used that version of qemu about a
 year
   ago,
 and it worked fine for Linux but it was an ancient version of
 qemu
   (at that
 time).

 On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki
   [5]jagannadh.t...@gmail.com
 wrote:

 On 24 November 2014 at 06:03, Douglas Rupp
   [6]douglas.b.r...@gmail.com
 wrote:
  I'm brand new to Uboot, so hopefully this is just some
 missing
   switch.
 I
  did search the archive, and I was able to build and u-boot a
 versaatilepb
  version, but xilinx-zynq-a9 is the one I really need.
 
  u-boot-2014.10$ make zynq_zed_defconfig
  u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi-
 ARCH=arm
  u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M
   -nographic
  -kernel u-boot-dtb.bin
  Segmentation fault (core dumped)

 I guess it may be qemu usage issue, is qemu from
 [7]https://github.com/Xilinx/qemu ?

 + Peter
 Hope, he will give some inputs

 
  What am I doing wrong?

 thanks!
 --
 Jagan.



 
___
U-Boot mailing list
[8]U-Boot@lists.denx.de
[9]http://lists.denx.de/mailman/listinfo/u-boot
 
  Links:
  1. mailto:soren.brinkm...@xilinx.com/
  2. http://www.wiki.xilinx.com/QEMU
  3. mailto:douglas.b.r...@gmail.com/
  4. http://open-do.org/
  5. mailto:jagannadh.t...@gmail.com/
  6. mailto:douglas.b.r...@gmail.com/
  7. https://github.com/Xilinx/qemu
  8. mailto:U-Boot@lists.denx.de/
  9. 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] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Sören Brinkmann
I suppose the uboot.bin files you are talking about are binaries that
had been converted with objcopy or similar from ELF to binary. That
probably works well. The Zynq boot.bin is a container file that contains
the Zynq bootloader and (optionally) other things (like U-Boot). I doubt
QEMU is able to parse this Zynq specific file (though, it's all
documented, so it could be implemented I guess). So, you probably want to
pass the u-boot.elf as kernel, but I don't know to what extend that works
currently. For that we need input from Peter.
For more information about the Zynq boot.bin format, please have a look
at section 6.3.2 in the Zynq TRM
(http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf)
and the Zynq SW developer guide
(http://www.xilinx.com/support/documentation/user_guides/ug821-zynq-7000-swdev.pdf).

Sören

On Mon, 2014-11-24 at 10:24AM -0800, Douglas Rupp wrote:
 For versatilepb arm, there's a blog post that describes a recipe of how to
 build and boot uboot.bin in qemu.  It works fine, here's the link if
 you're interested.
 https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/
 
 I assumed that uboot was standardized enough so that it would work the same
 for other machine/board emulations. I'd like to understand why it's not
 working.
 
 The problem I'm trying to solve is to configure networking in uboot for the
 xilinx-zynq-a9 bsp for vxworks7 running under qemu.  Vxworks7 uses uboot
 where 6.9 didn't, and the default device tree isn't set correctly for my
 network, it just has some random defaults that are expected to be
 customized.  The alternative is to use real hardware, which should work
 well enough for debugging but in general it's much easier to debug and run
 tests in qemu especially when working remotely.
 
 So any ideas you might have on what's special about zynq utboot would be
 appreciated.
 
 On Mon, Nov 24, 2014 at 9:45 AM, Sören Brinkmann soren.brinkm...@xilinx.com
  wrote:
 
  I don't think boot.bin is a legal kernel. IIRC, I had issues running
  on QEMU, but it was slightly better than what you describe.
 
  Sören
 
  On Mon, 2014-11-24 at 09:40AM -0800, Douglas Rupp wrote:
  The result is:
  
  arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2
  -machine
  linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
  SPI device 0x7f8161521ee0
  qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0
  
  then a register dump
  
  The boot.bin and devicetree.dtb is from xilinx binary release
  2014.3-release/zed
  
  I tried removing -smp 2 -machine linux=on, and same error.
  On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann
  [1]soren.brinkm...@xilinx.com wrote:
  
Could you try whether these instructions work?
[2]http://www.wiki.xilinx.com/QEMU
  
Sören
On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
 I built qemu-system-arm from the xilinx-master branch.
 xilinx-zynq-a9 is
 not a supported machine. :(

 On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp
[3]douglas.b.r...@gmail.com
 wrote:

  It's the version of qemu-system-arm downloaded for Ubuntu 14.04
  Version info:
  qemu-system-arm --version
  QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
 
  I also tried the three boot.bin files in
  2014.3-release.tar.gz
  downloaded from the Xilinx website, those in subdirectories
zc70x/zc706/
  and zc70x/zc702/, and zed/ .  Same command line.  Hangs with no
output.
 
  I also tried the version 2.0.0 version of qemu-system-arm from
  the
  [4]open-do.org website that we regular use with xlnx-zynq-a9
  bsp for
  vxworks7, it boots vxworks without uboot, but hangs with uboot.
 
  You're suggesting that only the qemu-system-arm built from the
xilinx repo
  is functional with uboot?  I used that version of qemu about a
  year
ago,
  and it worked fine for Linux but it was an ancient version of
  qemu
(at that
  time).
 
  On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki
[5]jagannadh.t...@gmail.com
  wrote:
 
  On 24 November 2014 at 06:03, Douglas Rupp
[6]douglas.b.r...@gmail.com
  wrote:
   I'm brand new to Uboot, so hopefully this is just some
  missing
switch.
  I
   did search the archive, and I was able to build and u-boot a
  versaatilepb
   version, but xilinx-zynq-a9 is the one I really need.
  
   u-boot-2014.10$ make zynq_zed_defconfig
   u-boot-2014.10$ make all CROSS_COMPILE=arm-none-eabi-
  ARCH=arm
   u-boot-2014.10$ qemu-system-arm -M xilinx-zynq-a9 -m 1024M
-nographic
   -kernel u-boot-dtb.bin
  

Re: [U-Boot] [PATCH v3 10/26] x86: ivybridge: Enable PCI in early init

2014-11-24 Thread Simon Glass
HI James,

On 24 November 2014 at 00:06, James Zhou james.zhou.l...@outlook.com wrote:
 Hello Simon,

 Is there a specific case to use PCI before relocation?
 Or it only applies for x86?
 If so, we could figure out how to use this new feature. Thanks for the info.

It's not x86-specific - you can use this for any arch. The main
enabler was pre-relocation malloc() which is now supported in U-Boot.

Regards,
Simon


 Regards,
 James

 Date: Fri, 21 Nov 2014 07:51:08 +0100
 From: s...@chromium.org
 To: u-boot@lists.denx.de
 CC: graeme.r...@gmail.com
 Subject: Re: [U-Boot] [PATCH v3 10/26] x86: ivybridge: Enable PCI in early
 init


 On 13 November 2014 06:42, Simon Glass s...@chromium.org wrote:
  Enable PCI so we can access devices that need to be set up before
  relocation.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
  Changes in v3:
  - Adjust PCI setup code to fit with new generic cpu PCI code
 
  Changes in v2: None
 
  arch/x86/cpu/ivybridge/Makefile | 1 +
  arch/x86/cpu/ivybridge/cpu.c | 6 
  arch/x86/cpu/ivybridge/pci.c | 60
  +++
  include/configs/chromebook_link.h | 14 +++--
  4 files changed, 79 insertions(+), 2 deletions(-)
  create mode 100644 arch/x86/cpu/ivybridge/pci.c

 Applied to u-boot-x86.
 ___
 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 0/4] dm: rpi: Move Raspberry Pi to use driver model

2014-11-24 Thread Simon Glass
Hi,

On 25 October 2014 at 23:10, Simon Glass s...@chromium.org wrote:
 Hi Stephen,

 On 25 Oct 2014 23:08, Stephen Warren swar...@wwwdotorg.org wrote:

 On 10/25/2014 09:47 PM, Simon Glass wrote:
  Hi Stephen,
 
  On Oct 25, 2014 9:43 PM, Stephen Warren swar...@wwwdotorg.org
  mailto:swar...@wwwdotorg.org wrote:
 
  On 10/21/2014 08:04 PM, Simon Glass wrote:
   Hi Stephen,
  
   On 20 October 2014 20:23, Stephen Warren swar...@wwwdotorg.org
  mailto:swar...@wwwdotorg.org wrote:
   On 10/19/2014 09:14 PM, Simon Glass wrote:
   Hi Stephen,
  
   On 17 October 2014 20:51, Stephen Warren swar...@wwwdotorg.org
  mailto:swar...@wwwdotorg.org wrote:
   On 09/30/2014 07:41 PM, Stephen Warren wrote:
   On 09/22/2014 05:30 PM, Simon Glass wrote:
   This series adds driver model support to the GPIO and serial
  drivers used
   by Raspberry Pi, and moves Raspberry Pi over to driver model.
  
   This requires adding driver model support to the pl01x serial
  driver, and
   replacing the bcm2835 GPIO driver with a driver model version
  (since there
   are no longer clients that don't use driver model).
  
   See u-boot-dm.git branch rpi-working for the tree this is based
   on.
  
   The series,
   Tested-by: Stephen Warren swar...@wwwdotorg.org
  mailto:swar...@wwwdotorg.org
  
   Hmm. I take that back. Patch 4 causes a problem, at least when
  applied
   on top of u-boot/master from today.
  
   Basic serial output works just fine, and I can interact with
   U-Boot
   without issue. However, when the boot scripts execute and load an
   extlinux.conf, U-Boot hangs. Up to patch 3, everything is fine.
  
   U-Boot 2014.10-4-g7830ed7 (Oct 17 2014 - 20:47:19)
  
   DRAM:  480 MiB
   WARNING: Caches not enabled
   MMC:   bcm2835_sdhci: 0
   Using default environment
  
   In:serial
   Out:   lcd
   Err:   lcd
   reading /uEnv.txt
   24 bytes read in 14 ms (1000 Bytes/s)
   Hit any key to stop autoboot:  0
   switch to partitions #0, OK
   mmc0 is current device
   Scanning mmc 0...
   Found /extlinux/extlinux.conf
   Retrieving file: /extlinux/extlinux.conf
   reading /extlinux/extlinux.conf
   (U-Boot hangs here)
  
  
   Can you please point me to where I can get an image to try this
   with?
   Also did you check with dm/next? There may be dependent patches,
   although the nature of the problem suggests not.
  
   I use (a pretty old version of, but I doubt that matters) RPi
   Foundation's Raspbian image, and compiled the kernel and U-Boot
   according to:
  
  
 
  http://elinux.org/index.php?title=RPi_Upstream_Kernel_Compilationoldid=351104
  
   http://elinux.org/RPi_U-Boot
  
  
   I installed the Raspbian image but I don't get uImg.txt nor the same
   boot sequence. I am able to boot a kernel though.
  
   Do you have your settings or images uploaded somewhere? Also please
   confirm you used dm/next.
 
  FWIW, the content in the following branches does seem to work:
 
  u-boot/master
  5b3ee38 kbuild: clear VENDOR variable to fix build error on tcsh
 
  u-boot-dm/master
  c2ded96 serial: remove uniphier_serial_initialize() call
 
 
  In what way?

 I ran U-Boot, and let it boot a kernel via extlinux.conf.

 Ok that is probably just because I didn't pull in the patch you said was a
 problem.


 Note that I said it worked, not that it failed.

 I did misread this...

 Regards,
 Simon

I started a new thread here:

http://u-boot.10912.n7.nabble.com/Raspberry-Pi-with-driver-model-td197255.html

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


[U-Boot] [PATCH v3 0/10] dm: Add I2C support and convert sandbox, tegra

2014-11-24 Thread Simon Glass

This series adds I2C support to driver model. It has become apparent that
this is a high priority as it is widely used. It follows along to some
extent from the SPI conversion.

Several changes are made from the original I2C implementations.

Firstly it is not necessary to specify the chip address with every call,
since each chip knows its own address - it is stored in struct dm_i2c_chip
which is attached to each chip on the I2C bus. However, this information
*is* passed to the driver since I presume most drivers need it and it would
be cumbersome to look up in every call.

Secondly there is no concept of a 'current' I2C bus so all associated logic
is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are
not available. Since the chip device specifies both the bus and the chip
address, there is no need for this concept. It also causes problems when
one driver changes the current bus and forgets to change it back.

Thirdly initialisation is handled by driver model's normal probe() method
on each device so there should be no need for i2c_init_all(), i2c_init(),
i2c_init_board(), i2c_board_late_init() and board_i2c_init().

I2C muxes are not yet supported. To support these we will need to maintain
state of the current mux settings to avoid resetting every mux every time.
Probably we need to add a sandbox I2C mux driver to permit testing of this.
This can probably be done later.

Platform data is not yet supported either, only device tree. The
U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not
used. Also struct i2c_adapter is not defined anymore. This will need to be
addressed, perhaps as part of converting over a board that does not use
device tree, assuming that we want to support this.

The following I2C CONFIGs are no-longer needed when driver model is used:

  CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method
  CONFIG_I2C_MULTI_BUS  - we always support multi-bus with driver model
  CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses
  CONFIG_SYS_I2C_SPEED  - the device tree specifies the speed for each bus
  CONFIG_SYS_I2C- this is the 'new old' API, now deprecated

There are a few SPI patches included here due to a dependency on a new
device binding function.

v3 changes the uclass to driver interface significantly. It is now a list of
messages to be processed by the driver. This matches the Linux user space
API which may be a benefit. It does introduce one complication, which is
that the protocol does not support separate chip offset and data. I have
enhanced it to do so.

This series is available at u-boot-dm/i2c-working2.

Changes in v3:
- Change uclass = driver API to use a message list
- Correct bogus address len code (was confused with chip address length)
- Drop extra call to i2c_bind_driver() in i2c_probe()
- Add a helper to query chip flags
- Add support for reading a byte at a time with an address for each byte
- Adjust for slightly altered I2C uclass API
- Add new 'i2c flags' command to get/set chip flags
- Update for new uclass = driver interface
- Update emulator for new uclass interface
- Update for new uclass = emulateor interface
- Change driver to support new message-based I2C uclass API

Changes in v2:
- Fix cihp typo
- Implement generic I2C devices to allow 'i2c probe' on unknown devices
- Return the probed device from i2c_probe()
- Set the bus speed after the bus is probed
- Add some debugging for generic I2C device binding
- Add a 'deblock' method to recover an I2C bus stuck in mid-transaction
- Add a helper function to find a chip on a particular bus number
- Change alen to int so that it can be -1 (this was a bug)
- Call the deblock() method for 'i2c reset'
- Update commit message for EEPROM driver
- Add a test for automatic binding of generic I2C devices
- Add a new asm/test.h header for tests in sandbox
- Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices
- Correct the compatible strings for I2C buses
- Don't init if the speed is 0, since this breaks the controller
- Expand coverage to all Tegra boards

Simon Glass (10):
  dm: i2c: Add a uclass for I2C
  dm: i2c: Implement driver model support in the i2c command
  dm: i2c: Add I2C emulation driver for sandbox
  dm: i2c: Add a sandbox I2C driver
  dm: i2c: Add an I2C EEPROM simulator
  dm: i2c: config: Enable I2C for sandbox using driver model
  dm: i2c: dts: Add an I2C bus for sandbox
  dm: Add a simple EEPROM driver
  dm: i2c: Add tests for I2C
  dm: i2c: tegra: Convert to driver model

 arch/arm/cpu/tegra20-common/pmu.c   |  21 +-
 arch/arm/dts/tegra124-jetson-tk1.dts|   1 -
 arch/arm/dts/tegra124-norrin.dts|   1 -
 arch/arm/dts/tegra30-tec-ng.dts |   4 +
 arch/arm/include/asm/arch-tegra/tegra_i2c.h |   2 +-
 arch/sandbox/dts/sandbox.dts|  17 ++
 arch/sandbox/include/asm/test.h |  15 +
 board/avionic-design/common/tamonten-ng.c   |  12 +-
 

[U-Boot] [PATCH v3 09/10] dm: i2c: Add tests for I2C

2014-11-24 Thread Simon Glass
Add some basic tests to check that the system works as expected.

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

Changes in v3:
- Update for new uclass = emulateor interface

Changes in v2:
- Add a test for automatic binding of generic I2C devices
- Add a new asm/test.h header for tests in sandbox

 drivers/i2c/sandbox_i2c.c |   1 +
 test/dm/Makefile  |   1 +
 test/dm/i2c.c | 112 ++
 test/dm/test.dts  |  17 +++
 4 files changed, 131 insertions(+)
 create mode 100644 test/dm/i2c.c

diff --git a/drivers/i2c/sandbox_i2c.c b/drivers/i2c/sandbox_i2c.c
index 35e3daa..acee384 100644
--- a/drivers/i2c/sandbox_i2c.c
+++ b/drivers/i2c/sandbox_i2c.c
@@ -122,6 +122,7 @@ static int sandbox_i2c_child_pre_probe(struct udevice *dev)
return 0;
if (dev-of_offset == -1)
return 0;
+
return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
   i2c_chip);
 }
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 75d3d41..612aa95 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -20,4 +20,5 @@ ifneq ($(CONFIG_SANDBOX),)
 obj-$(CONFIG_DM_GPIO) += gpio.o
 obj-$(CONFIG_DM_SPI) += spi.o
 obj-$(CONFIG_DM_SPI_FLASH) += sf.o
+obj-$(CONFIG_DM_I2C) += i2c.o
 endif
diff --git a/test/dm/i2c.c b/test/dm/i2c.c
new file mode 100644
index 000..94f7934
--- /dev/null
+++ b/test/dm/i2c.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2013 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include fdtdec.h
+#include i2c.h
+#include dm/device-internal.h
+#include dm/test.h
+#include dm/uclass-internal.h
+#include dm/ut.h
+#include dm/util.h
+#include asm/state.h
+#include asm/test.h
+
+static const int busnum;
+static const int chip = 0x2c;
+
+/* Test that we can find buses and chips */
+static int dm_test_i2c_find(struct dm_test_state *dms)
+{
+   struct udevice *bus, *dev;
+   const int no_chip = 0x10;
+
+   ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_I2C, busnum,
+  false, bus));
+
+   /*
+* i2c_post_bind() will bind devices to chip selects. Check this then
+* remove the emulation and the slave device.
+*/
+   ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+   ut_assertok(i2c_probe(bus, chip, dev));
+   ut_asserteq(-ENODEV, i2c_probe(bus, no_chip, dev));
+   ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_I2C, 1, bus));
+
+   return 0;
+}
+DM_TEST(dm_test_i2c_find, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_read_write(struct dm_test_state *dms)
+{
+   struct udevice *bus, *dev;
+   uint8_t buf[5];
+
+   ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+   ut_assertok(i2c_get_chip(bus, chip, dev));
+   ut_assertok(i2c_read(dev, 0, buf, 5));
+   ut_assertok(memcmp(buf, \0\0\0\0\0, sizeof(buf)));
+   ut_assertok(i2c_write(dev, 2, (uint8_t *)AB, 2));
+   ut_assertok(i2c_read(dev, 0, buf, 5));
+   ut_assertok(memcmp(buf, \0\0AB\0, sizeof(buf)));
+
+   return 0;
+}
+DM_TEST(dm_test_i2c_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_speed(struct dm_test_state *dms)
+{
+   struct udevice *bus, *dev;
+   uint8_t buf[5];
+
+   ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+   ut_assertok(i2c_get_chip(bus, chip, dev));
+   ut_assertok(i2c_set_bus_speed(bus, 10));
+   ut_assertok(i2c_read(dev, 0, buf, 5));
+   ut_assertok(i2c_set_bus_speed(bus, 40));
+   ut_asserteq(40, i2c_get_bus_speed(bus));
+   ut_assertok(i2c_read(dev, 0, buf, 5));
+   ut_asserteq(-EINVAL, i2c_write(dev, 0, buf, 5));
+
+   return 0;
+}
+DM_TEST(dm_test_i2c_speed, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_offset_len(struct dm_test_state *dms)
+{
+   struct udevice *bus, *dev;
+   uint8_t buf[5];
+
+   ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+   ut_assertok(i2c_get_chip(bus, chip, dev));
+   ut_assertok(i2c_set_chip_offset_len(dev, 1));
+   ut_assertok(i2c_read(dev, 0, buf, 5));
+
+   /* The sandbox driver allows this setting, but then fails reads */
+   ut_assertok(i2c_set_chip_offset_len(dev, 2));
+   ut_asserteq(-EINVAL, i2c_read(dev, 0, buf, 5));
+
+   /* This is not supported by the uclass */
+   ut_asserteq(-EINVAL, i2c_set_chip_offset_len(dev, 4));
+
+   /* This is faulted by the sandbox driver */
+   ut_asserteq(-EINVAL, i2c_set_chip_offset_len(dev, 3));
+
+   return 0;
+}
+DM_TEST(dm_test_i2c_offset_len, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_probe_empty(struct dm_test_state *dms)
+{
+   struct udevice *bus, *dev;
+
+   ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+   

[U-Boot] [PATCH v3 02/10] dm: i2c: Implement driver model support in the i2c command

2014-11-24 Thread Simon Glass
The concept of a 'current bus' is now implemented in the command line
rather than in the uclass. Also the address length does not need to
be specified with each command - really we should consider dropping
this from most commands but it works OK for now.

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

Changes in v3:
- Adjust for slightly altered I2C uclass API
- Add new 'i2c flags' command to get/set chip flags

Changes in v2:
- Change alen to int so that it can be -1 (this was a bug)
- Call the deblock() method for 'i2c reset'

 common/cmd_i2c.c | 376 +++
 1 file changed, 323 insertions(+), 53 deletions(-)

diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index c266b88..39f9735 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -69,8 +69,10 @@
 #include bootretry.h
 #include cli.h
 #include command.h
+#include dm.h
 #include edid.h
 #include environment.h
+#include errno.h
 #include i2c.h
 #include malloc.h
 #include asm/byteorder.h
@@ -117,6 +119,60 @@ static uchar i2c_no_probes[] = CONFIG_SYS_I2C_NOPROBES;
 
 #define DISP_LINE_LEN  16
 
+/*
+ * Default for driver model is to use the chip's existing address length.
+ * For legacy code, this is not stored, so we need to use a suitable
+ * default.
+ */
+#ifdef CONFIG_DM_I2C
+#define DEFAULT_ADDR_LEN   (-1)
+#else
+#define DEFAULT_ADDR_LEN   1
+#endif
+
+#ifdef CONFIG_DM_I2C
+static struct udevice *i2c_cur_bus;
+
+static int i2c_set_bus_num(unsigned int busnum)
+{
+   struct udevice *bus;
+   int ret;
+
+   ret = uclass_get_device_by_seq(UCLASS_I2C, busnum, bus);
+   if (ret) {
+   debug(%s: No bus %d\n, __func__, busnum);
+   return ret;
+   }
+   i2c_cur_bus = bus;
+
+   return 0;
+}
+
+static int i2c_get_cur_bus(struct udevice **busp)
+{
+   if (!i2c_cur_bus) {
+   puts(No I2C bus selected\n);
+   return -ENODEV;
+   }
+   *busp = i2c_cur_bus;
+
+   return 0;
+}
+
+static int i2c_get_cur_bus_chip(uint chip_addr, struct udevice **devp)
+{
+   struct udevice *bus;
+   int ret;
+
+   ret = i2c_get_cur_bus(bus);
+   if (ret)
+   return ret;
+
+   return i2c_get_chip(bus, chip_addr, devp);
+}
+
+#endif
+
 /**
  * i2c_init_board() - Board-specific I2C bus init
  *
@@ -143,7 +199,7 @@ void i2c_init_board(void)
  *
  * Returns I2C bus speed in Hz.
  */
-#if !defined(CONFIG_SYS_I2C)
+#if !defined(CONFIG_SYS_I2C)  !defined(CONFIG_DM_I2C)
 /*
  * TODO: Implement architecture-specific get/set functions
  * Should go away, if we switched completely to new multibus support
@@ -182,12 +238,12 @@ int i2c_set_bus_speed(unsigned int speed)
  *
  * Returns the address length.
  */
-static uint get_alen(char *arg)
+static uint get_alen(char *arg, int default_len)
 {
int j;
int alen;
 
-   alen = 1;
+   alen = default_len;
for (j = 0; j  8; j++) {
if (arg[j] == '.') {
alen = arg[j+1] - '0';
@@ -227,8 +283,13 @@ static int i2c_report_err(int ret, enum i2c_err_op op)
 static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
u_char  chip;
-   uintdevaddr, alen, length;
+   uintdevaddr, length;
+   int alen;
u_char  *memaddr;
+   int ret;
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+#endif
 
if (argc != 5)
return CMD_RET_USAGE;
@@ -243,7 +304,7 @@ static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
 * 2 bytes long.  Some day it might be 3 bytes long :-).
 */
devaddr = simple_strtoul(argv[2], NULL, 16);
-   alen = get_alen(argv[2]);
+   alen = get_alen(argv[2], DEFAULT_ADDR_LEN);
if (alen  3)
return CMD_RET_USAGE;
 
@@ -257,18 +318,31 @@ static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
 */
memaddr = (u_char *)simple_strtoul(argv[4], NULL, 16);
 
-   if (i2c_read(chip, devaddr, alen, memaddr, length) != 0) {
-   i2c_report_err(-1, I2C_ERR_READ);
-   return 1;
-   }
+#ifdef CONFIG_DM_I2C
+   ret = i2c_get_cur_bus_chip(chip, dev);
+   if (!ret  alen != -1)
+   ret = i2c_set_chip_offset_len(dev, alen);
+   if (!ret)
+   ret = i2c_read(dev, devaddr, memaddr, length);
+#else
+   ret = i2c_read(chip, devaddr, alen, memaddr, length);
+#endif
+   if (ret)
+   return i2c_report_err(ret, I2C_ERR_READ);
+
return 0;
 }
 
 static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
u_char  chip;
-   uintdevaddr, alen, length;
+   uintdevaddr, length;
+   int alen;
u_char  *memaddr;
+   int ret;
+#ifdef CONFIG_DM_I2C
+   struct udevice *dev;
+#endif
 
if (argc != 5)
return cmd_usage(cmdtp);
@@ -288,7 

[U-Boot] [PATCH v3 08/10] dm: Add a simple EEPROM driver

2014-11-24 Thread Simon Glass
There seem to be a few EEPROM drivers around - perhaps we should have a
single standard one? This simple driver is used for sandbox testing, but
could be pressed into more active service.

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

Changes in v3: None
Changes in v2:
- Update commit message for EEPROM driver

 drivers/misc/Makefile |  1 +
 drivers/misc/i2c_eeprom.c | 51 +++
 include/dm/uclass-id.h|  1 +
 include/i2c_eeprom.h  | 19 ++
 4 files changed, 72 insertions(+)
 create mode 100644 drivers/misc/i2c_eeprom.c
 create mode 100644 include/i2c_eeprom.h

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index ff02184..6fa836f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_CROS_EC_SANDBOX) += cros_ec_sandbox.o
 obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
 obj-$(CONFIG_FSL_IIM) += fsl_iim.o
 obj-$(CONFIG_GPIO_LED) += gpio_led.o
+obj-$(CONFIG_I2C_EEPROM) += i2c_eeprom.o
 obj-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
 obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o
 obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
new file mode 100644
index 000..d0548ec
--- /dev/null
+++ b/drivers/misc/i2c_eeprom.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include i2c.h
+#include i2c_eeprom.h
+
+static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
+  int size)
+{
+   return -ENODEV;
+}
+
+static int i2c_eeprom_write(struct udevice *dev, int offset,
+   const uint8_t *buf, int size)
+{
+   return -ENODEV;
+}
+
+struct i2c_eeprom_ops i2c_eeprom_std_ops = {
+   .read   = i2c_eeprom_read,
+   .write  = i2c_eeprom_write,
+};
+
+int i2c_eeprom_std_probe(struct udevice *dev)
+{
+   return 0;
+}
+
+static const struct udevice_id i2c_eeprom_std_ids[] = {
+   { .compatible = i2c-eeprom },
+   { }
+};
+
+U_BOOT_DRIVER(i2c_eeprom_std) = {
+   .name   = i2c_eeprom,
+   .id = UCLASS_I2C_EEPROM,
+   .of_match   = i2c_eeprom_std_ids,
+   .probe  = i2c_eeprom_std_probe,
+   .priv_auto_alloc_size = sizeof(struct i2c_eeprom),
+   .ops= i2c_eeprom_std_ops,
+};
+
+UCLASS_DRIVER(i2c_eeprom) = {
+   .id = UCLASS_I2C_EEPROM,
+   .name   = i2c_eeprom,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index e9f6104..7f7dcf7 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -31,6 +31,7 @@ enum uclass_id {
UCLASS_CROS_EC, /* Chrome OS EC */
UCLASS_I2C, /* I2C bus */
UCLASS_I2C_GENERIC, /* Generic I2C device */
+   UCLASS_I2C_EEPROM,  /* I2C EEPROM device */
 
UCLASS_COUNT,
UCLASS_INVALID = -1,
diff --git a/include/i2c_eeprom.h b/include/i2c_eeprom.h
new file mode 100644
index 000..ea6c962
--- /dev/null
+++ b/include/i2c_eeprom.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __I2C_EEPROM
+#define __I2C_EEPROM
+
+struct i2c_eeprom_ops {
+   int (*read)(struct udevice *dev, int offset, uint8_t *buf, int size);
+   int (*write)(struct udevice *dev, int offset, const uint8_t *buf,
+int size);
+};
+
+struct i2c_eeprom {
+};
+
+#endif
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v3 01/10] dm: i2c: Add a uclass for I2C

2014-11-24 Thread Simon Glass
The uclass implements the same operations as the current I2C framework but
makes some changes to make it fit driver model better:

- Remove the chip address from API calls
- Remove the address length from API calls
- Remove concept of 'current' I2C bus
- Drop all existing init functions

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

Changes in v3:
- Change uclass = driver API to use a message list
- Correct bogus address len code (was confused with chip address length)
- Drop extra call to i2c_bind_driver() in i2c_probe()
- Add a helper to query chip flags
- Add support for reading a byte at a time with an address for each byte

Changes in v2:
- Fix cihp typo
- Implement generic I2C devices to allow 'i2c probe' on unknown devices
- Return the probed device from i2c_probe()
- Set the bus speed after the bus is probed
- Add some debugging for generic I2C device binding
- Add a 'deblock' method to recover an I2C bus stuck in mid-transaction
- Add a helper function to find a chip on a particular bus number

 drivers/i2c/Makefile   |   1 +
 drivers/i2c/i2c-uclass.c   | 411 +
 include/config_fallbacks.h |   6 +
 include/dm/uclass-id.h |   2 +
 include/i2c.h  | 348 ++
 5 files changed, 768 insertions(+)
 create mode 100644 drivers/i2c/i2c-uclass.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index dae3d71..063e097 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -4,6 +4,7 @@
 #
 # SPDX-License-Identifier: GPL-2.0+
 #
+obj-$(CONFIG_DM_I2C) += i2c-uclass.o
 
 obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
new file mode 100644
index 000..4063a80
--- /dev/null
+++ b/drivers/i2c/i2c-uclass.c
@@ -0,0 +1,411 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include i2c.h
+#include malloc.h
+#include dm/device-internal.h
+#include dm/lists.h
+#include dm/root.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static bool i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
+uint8_t offset_buf[], struct i2c_msg *msg)
+{
+   if (!chip-offset_len)
+   return false;
+   msg-addr = chip-chip_addr;
+   msg-flags = chip-flags;
+   msg-len = chip-offset_len;
+   msg-buf = offset_buf;
+   offset_buf[0] = offset;
+   offset_buf[1] = offset  8;
+   offset_buf[2] = offset  16;
+   offset_buf[3] = offset  24;
+
+   return true;
+}
+
+static int i2c_read_bytewise(struct udevice *dev, uint offset,
+const uint8_t *buffer, int len)
+{
+   struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+   struct udevice *bus = dev_get_parent(dev);
+   struct dm_i2c_ops *ops = i2c_get_ops(bus);
+   struct i2c_msg msg[1];
+   uint8_t buf[5];
+   int ret;
+   int i;
+
+   for (i = 0; i  len; i++) {
+   i2c_setup_offset(chip, offset, buf, msg);
+   msg-len++;
+   buf[chip-offset_len] = buffer[i];
+
+   ret = ops-xfer(bus, msg, 1);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+int i2c_read(struct udevice *dev, uint offset, uint8_t *buffer, int len)
+{
+   struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+   struct udevice *bus = dev_get_parent(dev);
+   struct dm_i2c_ops *ops = i2c_get_ops(bus);
+   struct i2c_msg msg[2], *ptr;
+   uint8_t offset_buf[4];
+   int msg_count;
+
+   if (!ops-xfer)
+   return -ENOSYS;
+   if (chip-flags  DM_I2C_CHIP_RE_ADDRESS)
+   return i2c_read_bytewise(dev, offset, buffer, len);
+   ptr = msg;
+   if (i2c_setup_offset(chip, offset, offset_buf, ptr))
+   ptr++;
+
+   if (len) {
+   ptr-addr = chip-chip_addr;
+   ptr-flags = chip-flags | I2C_M_RD;
+   ptr-len = len;
+   ptr-buf = buffer;
+   ptr++;
+   }
+   msg_count = ptr - msg;
+
+   return ops-xfer(bus, msg, msg_count);
+}
+
+int i2c_write(struct udevice *dev, uint offset, const uint8_t *buffer, int len)
+{
+   struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+   struct udevice *bus = dev_get_parent(dev);
+   struct dm_i2c_ops *ops = i2c_get_ops(bus);
+   struct i2c_msg msg[1];
+
+   if (!ops-xfer)
+   return -ENOSYS;
+
+   /*
+* The simple approach would be to send two messages here: one to
+* set the offset and one to write the bytes. However some drivers
+* will not be expecting this, and some chips won't like how the
+* driver presents this on the I2C bus.
+*
+* The API does not support separate offset and data. We could extend
+* it with a flag indicating 

[U-Boot] [PATCH v3 05/10] dm: i2c: Add an I2C EEPROM simulator

2014-11-24 Thread Simon Glass
To enable testing of I2C, add a simple I2C EEPROM simulator for sandbox.
It supports reading and writing from a small data store.

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

Changes in v3:
- Update emulator for new uclass interface

Changes in v2: None

 drivers/misc/Makefile  |   3 ++
 drivers/misc/i2c_eeprom_emul.c | 108 +
 2 files changed, 111 insertions(+)
 create mode 100644 drivers/misc/i2c_eeprom_emul.c

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2f2e48f..ff02184 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,9 @@ obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o
 obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o
 obj-$(CONFIG_NS87308) += ns87308.o
 obj-$(CONFIG_PDSP188x) += pdsp188x.o
+ifdef CONFIG_DM_I2C
+obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o
+endif
 obj-$(CONFIG_STATUS_LED) += status_led.o
 obj-$(CONFIG_TWL4030_LED) += twl4030_led.o
 obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
diff --git a/drivers/misc/i2c_eeprom_emul.c b/drivers/misc/i2c_eeprom_emul.c
new file mode 100644
index 000..4cdf442
--- /dev/null
+++ b/drivers/misc/i2c_eeprom_emul.c
@@ -0,0 +1,108 @@
+/*
+ * Simulate an I2C eeprom
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include fdtdec.h
+#include i2c.h
+#include malloc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sandbox_i2c_flash_plat_data {
+   const char *filename;
+   int size;
+};
+
+struct sandbox_i2c_flash {
+   uint8_t *data;
+};
+
+static int sandbox_i2c_eprom_xfer(struct udevice *emul, struct i2c_msg *msg,
+ int nmsgs)
+{
+   int offset = 0;
+
+   /* Always let probe succeed */
+   if (nmsgs == 1  msg-len == 1) {
+   printf(%s: Detected probe\n, __func__);
+   return 0;
+   }
+
+   for (; nmsgs  0; nmsgs--, msg++) {
+   struct sandbox_i2c_flash_plat_data *plat =
+   dev_get_platdata(emul);
+   struct sandbox_i2c_flash *priv = dev_get_priv(emul);
+
+   if (!plat-size)
+   return -ENODEV;
+   if (msg-addr + msg-len  plat-size) {
+   debug(%s: Address %x, len %x is outside range 0..%x\n,
+ __func__, msg-addr, msg-len, plat-size);
+   return -EINVAL;
+   }
+   if (msg-flags  I2C_M_RD) {
+   memcpy(msg-buf, priv-data + offset, msg-len);
+   } else {
+   offset = *msg-buf;
+   memcpy(priv-data + offset, msg-buf + 1,
+  msg-len - 1);
+   }
+   }
+
+   return 0;
+}
+
+struct dm_i2c_ops sandbox_i2c_emul_ops = {
+   .xfer = sandbox_i2c_eprom_xfer,
+};
+
+static int sandbox_i2c_eeprom_ofdata_to_platdata(struct udevice *dev)
+{
+   struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+
+   plat-size = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
+   sandbox,size, 32);
+   plat-filename = fdt_getprop(gd-fdt_blob, dev-of_offset,
+sandbox,filename, NULL);
+   if (!plat-filename) {
+   debug(%s: No filename for device '%s'\n, __func__,
+ dev-name);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int sandbox_i2c_eeprom_probe(struct udevice *dev)
+{
+   struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+   struct sandbox_i2c_flash *priv = dev_get_priv(dev);
+
+   priv-data = calloc(1, plat-size);
+   if (!priv-data)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static const struct udevice_id sandbox_i2c_ids[] = {
+   { .compatible = sandbox,i2c-eeprom },
+   { }
+};
+
+U_BOOT_DRIVER(sandbox_i2c_emul) = {
+   .name   = sandbox_i2c_eeprom_emul,
+   .id = UCLASS_I2C_EMUL,
+   .of_match   = sandbox_i2c_ids,
+   .ofdata_to_platdata = sandbox_i2c_eeprom_ofdata_to_platdata,
+   .probe  = sandbox_i2c_eeprom_probe,
+   .priv_auto_alloc_size = sizeof(struct sandbox_i2c_flash),
+   .platdata_auto_alloc_size = sizeof(struct sandbox_i2c_flash_plat_data),
+   .ops= sandbox_i2c_emul_ops,
+};
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v3 03/10] dm: i2c: Add I2C emulation driver for sandbox

2014-11-24 Thread Simon Glass
In order to test I2C we need some sort of emulation interface. Add hooks
to allow a driver to emulate an I2C device for sandbox.

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

Changes in v3: None
Changes in v2: None

 drivers/i2c/Makefile  |  1 +
 drivers/i2c/i2c-emul-uclass.c | 14 ++
 include/dm/uclass-id.h|  1 +
 3 files changed, 16 insertions(+)
 create mode 100644 drivers/i2c/i2c-emul-uclass.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 063e097..5a93473 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
 obj-$(CONFIG_SYS_I2C_S3C24X0) += s3c24x0_i2c.o
+obj-$(CONFIG_SYS_I2C_SANDBOX) += i2c-emul-uclass.o
 obj-$(CONFIG_SYS_I2C_SH) += sh_i2c.o
 obj-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
 obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
diff --git a/drivers/i2c/i2c-emul-uclass.c b/drivers/i2c/i2c-emul-uclass.c
new file mode 100644
index 000..aa89f95
--- /dev/null
+++ b/drivers/i2c/i2c-emul-uclass.c
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include i2c.h
+
+UCLASS_DRIVER(i2c_emul) = {
+   .id = UCLASS_I2C_EMUL,
+   .name   = i2c_emul,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 43514bc..e9f6104 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -19,6 +19,7 @@ enum uclass_id {
UCLASS_TEST_FDT,
UCLASS_TEST_BUS,
UCLASS_SPI_EMUL,/* sandbox SPI device emulator */
+   UCLASS_I2C_EMUL,/* sandbox I2C device emulator */
UCLASS_SIMPLE_BUS,
 
/* U-Boot uclasses start here */
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v3 07/10] dm: i2c: dts: Add an I2C bus for sandbox

2014-11-24 Thread Simon Glass
Add an I2C bus to the device tree, with an EEPROM emulator attached to one
of the addresses.

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

Changes in v3: None
Changes in v2: None

 arch/sandbox/dts/sandbox.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 7614715..11748ae 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -134,6 +134,23 @@
num-gpios = 20;
};
 
+   i2c@0 {
+   #address-cells = 1;
+   #size-cells = 0;
+   reg = 0;
+   compatible = sandbox,i2c;
+   clock-frequency = 40;
+   eeprom@2c {
+   reg = 0x2c;
+   compatible = i2c-eeprom;
+   emul {
+   compatible = sandbox,i2c-eeprom;
+   sandbox,filename = i2c.bin;
+   sandbox,size = 128;
+   };
+   };
+   };
+
spi@0 {
#address-cells = 1;
#size-cells = 0;
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v3 06/10] dm: i2c: config: Enable I2C for sandbox using driver model

2014-11-24 Thread Simon Glass
Enable the options to bring up I2C on sandbox. Also enable all the available
I2C commands for testing purposes.

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

Changes in v3: None
Changes in v2: None

 arch/sandbox/include/asm/test.h | 15 +++
 include/configs/sandbox.h   |  6 ++
 2 files changed, 21 insertions(+)
 create mode 100644 arch/sandbox/include/asm/test.h

diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
new file mode 100644
index 000..d7f7bb5
--- /dev/null
+++ b/arch/sandbox/include/asm/test.h
@@ -0,0 +1,15 @@
+/*
+ * Test-related constants for sandbox
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_TEST_H
+#define __ASM_TEST_H
+
+/* The sandbox driver always permits an I2C device with this address */
+#define SANDBOX_I2C_TEST_ADDR  0x59
+
+#endif
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index ee4b244..d4ebe6a 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -110,6 +110,12 @@
 #define CONFIG_SPI_FLASH_STMICRO
 #define CONFIG_SPI_FLASH_WINBOND
 
+#define CONFIG_DM_I2C
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C_SANDBOX
+#define CONFIG_I2C_EDID
+#define CONFIG_I2C_EEPROM
+
 /* Memory things - we don't really want a memory test */
 #define CONFIG_SYS_LOAD_ADDR   0x
 #define CONFIG_SYS_MEMTEST_START   0x0010
-- 
2.1.0.rc2.206.gedb03e5

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


[U-Boot] [PATCH v3 04/10] dm: i2c: Add a sandbox I2C driver

2014-11-24 Thread Simon Glass
This driver includes some test features such as only supporting certain
bus speeds. It passes its I2C traffic through to an emulator.

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

Changes in v3:
- Update for new uclass = driver interface

Changes in v2: None

 drivers/i2c/Makefile  |   2 +-
 drivers/i2c/sandbox_i2c.c | 141 ++
 2 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 drivers/i2c/sandbox_i2c.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 5a93473..6f3c86c 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
 obj-$(CONFIG_SYS_I2C_S3C24X0) += s3c24x0_i2c.o
-obj-$(CONFIG_SYS_I2C_SANDBOX) += i2c-emul-uclass.o
+obj-$(CONFIG_SYS_I2C_SANDBOX) += sandbox_i2c.o i2c-emul-uclass.o
 obj-$(CONFIG_SYS_I2C_SH) += sh_i2c.o
 obj-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
 obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
diff --git a/drivers/i2c/sandbox_i2c.c b/drivers/i2c/sandbox_i2c.c
new file mode 100644
index 000..35e3daa
--- /dev/null
+++ b/drivers/i2c/sandbox_i2c.c
@@ -0,0 +1,141 @@
+/*
+ * Simulate an I2C port
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include i2c.h
+#include asm/test.h
+#include dm/lists.h
+#include dm/device-internal.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct dm_sandbox_i2c_emul_priv {
+   struct udevice *emul;
+};
+
+static int get_emul(struct udevice *bus, uint chip_addr, struct udevice **devp,
+   struct dm_i2c_ops **opsp)
+{
+   const void *blob = gd-fdt_blob;
+   struct dm_i2c_chip *priv;
+   struct udevice *dev;
+   int ret;
+
+   *devp = NULL;
+   *opsp = NULL;
+   ret = i2c_get_chip(bus, chip_addr, dev);
+   if (ret)
+   return ret;
+   priv = dev_get_parentdata(dev);
+   if (!priv-emul) {
+   int node;
+
+   debug(Scanning i2c bus '%s' for devices\n, dev-name);
+   for (node = fdt_first_subnode(blob, dev-of_offset);
+   node = 0;
+   node = fdt_next_subnode(blob, node)) {
+   int ret;
+
+   ret = lists_bind_fdt(dev, blob, node, priv-emul);
+   if (ret)
+   return ret;
+   debug(Found emul '%s' for i2c device '%s'\n,
+ priv-emul-name, dev-name);
+   break;
+   }
+   }
+
+   if (!priv-emul)
+   return -ENODEV;
+   ret = device_probe(priv-emul);
+   if (ret)
+   return ret;
+   *devp = priv-emul;
+   *opsp = i2c_get_ops(priv-emul);
+
+   return 0;
+}
+
+static int sandbox_i2c_xfer(struct udevice *bus, struct i2c_msg *msg,
+   int nmsgs)
+{
+   struct dm_i2c_bus *i2c = bus-uclass_priv;
+   struct dm_i2c_ops *ops;
+   struct udevice *emul, *dev;
+   struct dm_i2c_chip *chip;
+   bool is_read;
+   int ret;
+
+   /* Special test code to return success but with no emulation */
+   if (msg-addr == SANDBOX_I2C_TEST_ADDR)
+   return 0;
+
+   ret = get_emul(bus, msg-addr, emul, ops);
+   if (ret)
+   return ret;
+
+   /* For testing, require an offset length of 1 */
+   ret = i2c_get_chip(bus, msg-addr, dev);
+   if (ret)
+   return ret;
+   chip = dev_get_parentdata(dev);
+   if (chip-offset_len != 1)
+   return -EINVAL;
+
+   /*
+* For testing, don't allow writing above 100KHz for writes and
+* 400KHz for reads
+*/
+   is_read = nmsgs  1;
+   if (i2c-speed_hz  (is_read ? 40 : 10))
+   return -EINVAL;
+   return ops-xfer(emul, msg, nmsgs);
+}
+
+static int sandbox_i2c_set_offset_len(struct udevice *dev, uint offset_len)
+{
+   if (offset_len == 3)
+   return -EINVAL;
+
+   return 0;
+}
+
+static const struct dm_i2c_ops sandbox_i2c_ops = {
+   .xfer   = sandbox_i2c_xfer,
+   .set_offset_len = sandbox_i2c_set_offset_len,
+};
+
+static int sandbox_i2c_child_pre_probe(struct udevice *dev)
+{
+   struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
+
+   /* Ignore our test address */
+   if (i2c_chip-chip_addr == SANDBOX_I2C_TEST_ADDR)
+   return 0;
+   if (dev-of_offset == -1)
+   return 0;
+   return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
+  i2c_chip);
+}
+
+static const struct udevice_id sandbox_i2c_ids[] = {
+   { .compatible = sandbox,i2c },
+   { }
+};
+
+U_BOOT_DRIVER(i2c_sandbox) = {
+   .name   = i2c_sandbox,
+   .id = 

[U-Boot] [PATCH v3 10/10] dm: i2c: tegra: Convert to driver model

2014-11-24 Thread Simon Glass
This converts all Tegra boards over to use driver model for I2C. The driver
is adjusted to use driver model and the following obsolete CONFIGs are
removed:

   - CONFIG_SYS_I2C_INIT_BOARD
   - CONFIG_I2C_MULTI_BUS
   - CONFIG_SYS_MAX_I2C_BUS
   - CONFIG_SYS_I2C_SPEED
   - CONFIG_SYS_I2C

This has been tested on:
- trimslice (no I2C)
- beaver
- Jetson-TK1

It has not been tested on Tegra 114 as I don't have that board.

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

Changes in v3:
- Change driver to support new message-based I2C uclass API

Changes in v2:
- Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices
- Correct the compatible strings for I2C buses
- Don't init if the speed is 0, since this breaks the controller
- Expand coverage to all Tegra boards

 arch/arm/cpu/tegra20-common/pmu.c   |  21 +-
 arch/arm/dts/tegra124-jetson-tk1.dts|   1 -
 arch/arm/dts/tegra124-norrin.dts|   1 -
 arch/arm/dts/tegra30-tec-ng.dts |   4 +
 arch/arm/include/asm/arch-tegra/tegra_i2c.h |   2 +-
 board/avionic-design/common/tamonten-ng.c   |  12 +-
 board/nvidia/cardhu/cardhu.c|  13 +-
 board/nvidia/common/board.c |   4 -
 board/nvidia/dalmore/dalmore.c  |  21 +-
 board/nvidia/whistler/whistler.c|  29 ++-
 board/toradex/apalis_t30/apalis_t30.c   |  19 +-
 drivers/i2c/tegra_i2c.c | 363 +---
 drivers/power/tps6586x.c|  27 +--
 include/configs/apalis_t30.h|   3 -
 include/configs/beaver.h|   3 -
 include/configs/cardhu.h|   5 -
 include/configs/colibri_t30.h   |   3 -
 include/configs/dalmore.h   |   5 -
 include/configs/jetson-tk1.h|   5 -
 include/configs/norrin.h|   5 -
 include/configs/seaboard.h  |   3 -
 include/configs/tec-ng.h|   5 -
 include/configs/tegra-common.h  |   1 +
 include/configs/tegra114-common.h   |   3 -
 include/configs/tegra124-common.h   |   3 -
 include/configs/tegra20-common.h|   3 -
 include/configs/tegra30-common.h|   3 -
 include/configs/trimslice.h |   3 -
 include/configs/venice2.h   |   5 -
 include/configs/whistler.h  |   3 -
 include/tps6586x.h  |   4 +-
 31 files changed, 205 insertions(+), 377 deletions(-)

diff --git a/arch/arm/cpu/tegra20-common/pmu.c 
b/arch/arm/cpu/tegra20-common/pmu.c
index c595f70..36a76a2 100644
--- a/arch/arm/cpu/tegra20-common/pmu.c
+++ b/arch/arm/cpu/tegra20-common/pmu.c
@@ -6,6 +6,7 @@
  */
 
 #include common.h
+#include i2c.h
 #include tps6586x.h
 #include asm/io.h
 #include asm/arch/tegra.h
@@ -23,9 +24,13 @@
 #define VDD_TRANSITION_STEP0x06/* 150mv */
 #define VDD_TRANSITION_RATE0x06/* 3.52mv/us */
 
+#define PMI_I2C_ADDRESS0x34/* chip requires this address */
+
 int pmu_set_nominal(void)
 {
-   int core, cpu, bus;
+   struct udevice *bus, *dev;
+   int core, cpu;
+   int ret;
 
/* by default, the table has been filled with T25 settings */
switch (tegra_get_chip_sku()) {
@@ -42,12 +47,18 @@ int pmu_set_nominal(void)
return -1;
}
 
-   bus = tegra_i2c_get_dvc_bus_num();
-   if (bus == -1) {
+   ret = tegra_i2c_get_dvc_bus(bus);
+   if (ret) {
debug(%s: Cannot find DVC I2C bus\n, __func__);
-   return -1;
+   return ret;
}
-   tps6586x_init(bus);
+   ret = i2c_get_chip(bus, PMI_I2C_ADDRESS, dev);
+   if (ret) {
+   debug(%s: Cannot find DVC I2C chip\n, __func__);
+   return ret;
+   }
+
+   tps6586x_init(dev);
tps6586x_set_pwm_mode(TPS6586X_PWM_SM1);
return tps6586x_adjust_sm0_sm1(core, cpu, VDD_TRANSITION_STEP,
VDD_TRANSITION_RATE, VDD_RELATION);
diff --git a/arch/arm/dts/tegra124-jetson-tk1.dts 
b/arch/arm/dts/tegra124-jetson-tk1.dts
index ffad116..f6fe9a0 100644
--- a/arch/arm/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/dts/tegra124-jetson-tk1.dts
@@ -16,7 +16,6 @@
i2c2 = /i2c@7000c400;
i2c3 = /i2c@7000c500;
i2c4 = /i2c@7000c700;
-   i2c5 = /i2c@7000d100;
sdhci0 = /sdhci@700b0600;
sdhci1 = /sdhci@700b0400;
spi0 = /spi@7000d400;
diff --git a/arch/arm/dts/tegra124-norrin.dts b/arch/arm/dts/tegra124-norrin.dts
index b07630c..2dbeab8 100644
--- a/arch/arm/dts/tegra124-norrin.dts
+++ b/arch/arm/dts/tegra124-norrin.dts
@@ -13,7 +13,6 @@
i2c2 = /i2c@7000c400;
i2c3 = /i2c@7000c500;
i2c4 = /i2c@7000c700;
-   i2c5 = /i2c@7000d100;
sdhci0 = /sdhci@700b0600;
sdhci1 = /sdhci@700b0400;
 

[U-Boot] [PATCH] sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set

2014-11-24 Thread Hans de Goede
Old kernels cannot handle booting in non-secure (hyp) mode, so when
OLD_SUNXI_KERNEL_COMPAT is set, also set ARMV7_BOOT_SEC_DEFAULT.

Note that whether to booting secure or non-secure can always be overriden
using the bootm_boot_mode environment variable.

Signed-off-by: Hans de Goede hdego...@redhat.com
--
Changes in v2:
-Use Kconfig rather the a hard-define in include/configs/sun7i.h
---
 board/sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e20ea1b..246cd9a 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -24,6 +24,7 @@ config MACH_SUN7I
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select SUPPORT_SPL
+   select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
 
 config MACH_SUN8I
bool sun8i (Allwinner A23)
-- 
2.1.0

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


[U-Boot] [PATCH] RFC: Add driver model support for PCI

2014-11-24 Thread Simon Glass
This is an early preview of some recent work to support PCI in driver model.
It was prompted by fiddling with bare x86 support and finding that PCI has
its own device model, but no actual storage as to what devices exist in
the system. It is not possible to specify configuration information for
devices other than in board code.

This patch is a collection of changes in core DM, sandbox and PCI code to
implement a PCI uclass and associated operations. Some basic tests are
provided but they are incomplete.

As is becoming common with DM conversions, the existing structure (here
struct pci_controller) becomes per-bus uclass data. This allows the concept
of a 'hose' (generally a PCI host controller and a bus) to continue to exist
in the interim, even if it should not be needed in the end. This makes it
much easier to convert over existing code.

There is one major core DM change tacked into this patch. The core DM
code is updated to move allocation of platform data into the bind()
stage instead of probe(). This is because with PCI we need to know the
bus address of a device (in PCI speak: device and function or devfn) before
we can probe it. Actually a similar problem arose with SPI and I2C and I
worked around it, but with evidence from PCI also it seems we should make
this change.

PCI buses are not scanned in the bind() method but only later when probe()
is called. This will be automatic if you access a bus, but it does mean that
if PCI is not used it will not be touched, in keeping with U-Boot's lazy-
init philosophy.

The existing 'pciauto' bus configuration code is still used, although it now
uses DM underneath. It works exclusively by reading and writing PCI config
and does not refer to DM data structures. In fact that file is not touched
in this patch which is an indication that a good level of compatibility is
achieved between DM and legacy PCI.

In order to support testing of PCI I/O and memory space, support has been
added to sandbox to allow mapping of these. This allows commands like 'md'
and 'iod' to display data from mapped PCI devices. Similarly, it is possible
to make changes to this space. This support relies on the existing
map_sysmem() and unmap_sysmem() calls which are now fairly widespread in
U-Boot.

Apart from the driver model tests (run with ./test/dm/test-dm.sh) you can
try out these commands which use the new 'swap_case' test device:

../u-boot -d b/sandbox/u-boot.dtb

= iow.b 2000 2
= iod.b 2000
: 02
= mw.l 1000 64436241
= md.l 1000 1
1000: 44634261   aBcD
=

This shows an I/O access to 2000, setting the value 2 which means to
swap the case. Then 'AbCd' is written to the memory space at 1000 and
'aBcD' is read back.

The 'pci' command works to some extent.

Most existing PCI functions still work, but route through driver model.
The file drivers/pci/pci.c is replaced when driver model is enabled so not
everything is present. Also multiple bus support is untested and probably
broken. A new pci_common.c file holds functions common to driver model and
the old system, and pci_compat.c contains functions I would like to
eventually deprecate.

This series is not tested on any real hardware at this stage. Once the bare
x86 support is merged I will tidy this patch up and move it over, fix up
Kconfig, etc.

This patch is available at u-boot-dm.git branch pci-working.

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

 arch/sandbox/Kconfig  |   6 +
 arch/sandbox/cpu/cpu.c|  37 ++-
 arch/sandbox/dts/sandbox.dts  |  26 ++-
 arch/sandbox/include/asm/io.h |  16 +-
 arch/sandbox/include/asm/processor.h  |  12 +
 arch/sandbox/include/asm/test.h   |   7 +-
 arch/sandbox/include/asm/u-boot-sandbox.h |   7 +
 arch/sandbox/lib/Makefile |   2 +-
 arch/sandbox/lib/pci_io.c | 137 +++
 common/board_r.c  |   2 +
 common/cmd_mem.c  |   7 +-
 common/cmd_pci.c  |  14 +-
 configs/sandbox_defconfig |   4 +
 doc/driver-model/pci-info.txt |  52 +
 drivers/core/device.c |  92 ++--
 drivers/core/root.c   |   3 +
 drivers/misc/Makefile |   1 +
 drivers/misc/swap_case.c  | 284 +++
 drivers/pci/Kconfig   |  22 ++
 drivers/pci/Makefile  |  10 +-
 drivers/pci/pci-emul-uclass.c |  66 ++
 drivers/pci/pci-uclass.c  | 374 ++
 drivers/pci/pci.c |  72 +-
 drivers/pci/pci_common.c  |  72 ++
 drivers/pci/pci_compat.c  |  67 ++
 drivers/pci/pci_sandbox.c | 171 ++
 include/configs/sandbox.h |   5 +-
 include/dm/device.h   |  32 

[U-Boot] [PATCH 0/1] sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set

2014-11-24 Thread Hans de Goede
Hi Ian,

Thanks for the quick review on the 2 display fixes. With Albert's pull-req
of today the dependencies for this fix are going upstream as soon as Tom
merges the pull-req.

Can you review this one too please ?

Thanks  Regards,

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


Re: [U-Boot] [PATCH 1/5] sunxi: display: Remove unused HDMI register addr defines

2014-11-24 Thread Anatolij Gustschin
On Mon, 24 Nov 2014 17:14:15 +0100
Hans de Goede hdego...@redhat.com wrote:

 All hdmi code uses struct sunxi_hdmi_reg, so these are not needed.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

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


Re: [U-Boot] [PATCH 2/5] sunxi: display: Do not use eprintf in early boot

2014-11-24 Thread Anatolij Gustschin
On Mon, 24 Nov 2014 17:14:16 +0100
Hans de Goede hdego...@redhat.com wrote:

 stderr is not hooked up yet as this point, so use a regular printf.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Acked-by: Anatolij Gustschin ag...@denx.de

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


Re: [U-Boot] [PATCH] fs/ext4/ext4fs.c, fs/fs.c: Use lldiv and multiplication / subtraction on 64bit ops

2014-11-24 Thread Simon Glass
On 24 November 2014 at 09:55, Tom Rini tr...@ti.com wrote:
 In some cases we need to do math on 64bit quantities.  We need to be
 using lldiv in these cases rather than letting the compiler do it.  In
 addition we need to avoid doing % operations on these same quantities.
 These changes fix compilation on MIPS/MIPSEL.

 Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
 Cc: Suriyan Ramasami suriya...@gmail.com
 Cc: Simon Glass s...@chromium.org
 Signed-off-by: Tom Rini tr...@ti.com

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

 ---
  fs/ext4/ext4fs.c |   11 ++-
  fs/fs.c  |3 ++-
  2 files changed, 8 insertions(+), 6 deletions(-)

 diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
 index 943b5bc..258b9379 100644
 --- a/fs/ext4/ext4fs.c
 +++ b/fs/ext4/ext4fs.c
 @@ -25,6 +25,7 @@
  #include ext_common.h
  #include ext4fs.h
  #include ext4_common.h
 +#include div64.h

  int ext4fs_symlinknest;
  struct ext_filesystem ext_fs;
 @@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 if (len  filesize)
 len = filesize;

 -   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
 +   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);

 -   for (i = pos / blocksize; i  blockcnt; i++) {
 +   for (i = lldiv(pos, blocksize); i  blockcnt; i++) {
 lbaint_t blknr;
 -   int blockoff = pos % blocksize;
 +   int blockoff = pos - (blocksize * i);
 int blockend = blocksize;
 int skipfirst = 0;
 blknr = read_allocated_block((node-inode), i);
 @@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,

 /* Last block.  */
 if (i == blockcnt - 1) {
 -   blockend = (len + pos) % blocksize;
 +   blockend = (len + pos) - (blocksize * i);

 /* The last portion is exactly blocksize. */
 if (!blockend)
 @@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 }

 /* First block. */
 -   if (i == pos / blocksize) {
 +   if (i == lldiv(pos, blocksize)) {
 skipfirst = blockoff;
 blockend -= skipfirst;
 }
 diff --git a/fs/fs.c b/fs/fs.c
 index 3da7860..760f4a6 100644
 --- a/fs/fs.c
 +++ b/fs/fs.c
 @@ -17,6 +17,7 @@
  #include config.h
  #include errno.h
  #include common.h
 +#include div64.h
  #include part.h
  #include ext4fs.h
  #include fat.h
 @@ -399,7 +400,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
 const argv[],
 printf(%llu bytes read in %lu ms, len_read, time);
 if (time  0) {
 puts( ();
 -   print_size(len_read / time * 1000, /s);
 +   print_size(lldiv(len_read, time * 1000), /s);
 puts());
 }
 puts(\n);
 --
 1.7.9.5

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-24 Thread Douglas Rupp
I tried with a zed_zynq built u-boot.bin and u-boot.dtb built from
u-boot-2014.10 release, and got slightly different results:

qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0.

Then a register dump.

Oh well, thanks for the pointers in your previous message, will read for
clues.

On Mon, Nov 24, 2014 at 10:34 AM, Sören Brinkmann 
soren.brinkm...@xilinx.com wrote:

 I suppose the uboot.bin files you are talking about are binaries that
 had been converted with objcopy or similar from ELF to binary. That
 probably works well. The Zynq boot.bin is a container file that contains
 the Zynq bootloader and (optionally) other things (like U-Boot). I doubt
 QEMU is able to parse this Zynq specific file (though, it's all
 documented, so it could be implemented I guess). So, you probably want to
 pass the u-boot.elf as kernel, but I don't know to what extend that works
 currently. For that we need input from Peter.
 For more information about the Zynq boot.bin format, please have a look
 at section 6.3.2 in the Zynq TRM
 (
 http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
 )
 and the Zynq SW developer guide
 (
 http://www.xilinx.com/support/documentation/user_guides/ug821-zynq-7000-swdev.pdf
 ).

 Sören

 On Mon, 2014-11-24 at 10:24AM -0800, Douglas Rupp wrote:
  For versatilepb arm, there's a blog post that describes a recipe of how
 to
  build and boot uboot.bin in qemu.  It works fine, here's the link if
  you're interested.
  https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/
 
  I assumed that uboot was standardized enough so that it would work the
 same
  for other machine/board emulations. I'd like to understand why it's not
  working.
 
  The problem I'm trying to solve is to configure networking in uboot for
 the
  xilinx-zynq-a9 bsp for vxworks7 running under qemu.  Vxworks7 uses uboot
  where 6.9 didn't, and the default device tree isn't set correctly for my
  network, it just has some random defaults that are expected to be
  customized.  The alternative is to use real hardware, which should work
  well enough for debugging but in general it's much easier to debug and
 run
  tests in qemu especially when working remotely.
 
  So any ideas you might have on what's special about zynq utboot would be
  appreciated.
 
  On Mon, Nov 24, 2014 at 9:45 AM, Sören Brinkmann 
 soren.brinkm...@xilinx.com
   wrote:
 
   I don't think boot.bin is a legal kernel. IIRC, I had issues running
   on QEMU, but it was slightly better than what you describe.
  
   Sören
  
   On Mon, 2014-11-24 at 09:40AM -0800, Douglas Rupp wrote:
   The result is:
   
   arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2
   -machine
   linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
   SPI device 0x7f8161521ee0
   qemu: fatal: Trying to execute code outside RAM or ROM at
 0xfff0
   
   then a register dump
   
   The boot.bin and devicetree.dtb is from xilinx binary release
   2014.3-release/zed
   
   I tried removing -smp 2 -machine linux=on, and same error.
   On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann
   [1]soren.brinkm...@xilinx.com wrote:
   
 Could you try whether these instructions work?
 [2]http://www.wiki.xilinx.com/QEMU
   
 Sören
 On Mon, 2014-11-24 at 08:58AM -0800, Douglas Rupp wrote:
  I built qemu-system-arm from the xilinx-master branch.
  xilinx-zynq-a9 is
  not a supported machine. :(
 
  On Mon, Nov 24, 2014 at 7:02 AM, Douglas Rupp
 [3]douglas.b.r...@gmail.com
  wrote:
 
   It's the version of qemu-system-arm downloaded for Ubuntu
 14.04
   Version info:
   qemu-system-arm --version
   QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
  
   I also tried the three boot.bin files in
   2014.3-release.tar.gz
   downloaded from the Xilinx website, those in subdirectories
 zc70x/zc706/
   and zc70x/zc702/, and zed/ .  Same command line.  Hangs
 with no
 output.
  
   I also tried the version 2.0.0 version of qemu-system-arm
 from
   the
   [4]open-do.org website that we regular use with
 xlnx-zynq-a9
   bsp for
   vxworks7, it boots vxworks without uboot, but hangs with
 uboot.
  
   You're suggesting that only the qemu-system-arm built from
 the
 xilinx repo
   is functional with uboot?  I used that version of qemu
 about a
   year
 ago,
   and it worked fine for Linux but it was an ancient version
 of
   qemu
 (at that
   time).
  
   On Sun, Nov 23, 2014 at 10:17 PM, Jagan Teki
 [5]jagannadh.t...@gmail.com
   wrote:
  
   On 24 November 2014 at 06:03, Douglas Rupp
 [6]douglas.b.r...@gmail.com
   wrote:
   

[U-Boot] Building fw_env tools seems broken

2014-11-24 Thread Denys Dmytriyenko
Hi,

I came across this issue recently, that affects 2014.10 as well as master, but 
used to work fine in 2014.07 and older. Please let me know if I'm missing 
something or you need additional info. Thanks!


$ make CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
#
# configuration written to spl/.config
#

$ make CROSS_COMPILE=arm-linux-gnueabihf- env
scripts/kconfig/conf --silentoldconfig Kconfig
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK include/config.h
  GEN include/autoconf.mk
  GEN include/autoconf.mk.dep
  GEN spl/include/autoconf.mk
  HOSTCC  tools/env/fw_env.o
In file included from tools/env/fw_env.c:117:0:
include/env_default.h:110:11: error: expected ‘}’ before ‘CONFIG_SYS_ARCH’
scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed
make[1]: *** [tools/env/fw_env.o] Error 1
Makefile:1208: recipe for target 'env' failed
make: *** [env] Error 2

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


Re: [U-Boot] [U-Boot, 3/5] edid: Add an edid_dtd_to_fbmode() helper function

2014-11-24 Thread Hans de Goede

Hi,

On 11/24/2014 05:14 PM, Hans de Goede wrote:

Various u-boot video drivers use fb_videomode structs to store timing info,
add a helper function to convert an EDID detailed timing into a fb_videomode
struct.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
  common/edid.c  | 65 ++
  include/edid.h | 18 
  2 files changed, 83 insertions(+)

diff --git a/common/edid.c b/common/edid.c
index e66108f..e41cd3e 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -12,6 +12,7 @@

  #include common.h
  #include edid.h
+#include errno.h
  #include linux/ctype.h
  #include linux/string.h

@@ -288,3 +289,67 @@ void edid_print_info(struct edid1_info *edid_info)
if (!have_timing)
printf(\tNone\n);
  }
+
+int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
+  struct fb_videomode *mode, char *name, int name_len)
+{
+   int margin, h_total, v_total;
+
+   if (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) == 0 ||
+   EDID_DETAILED_TIMING_HORIZONTAL_ACTIVE(*t) == 0 ||
+   EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t) == 0 ||
+   EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 ||
+   EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 ||
+   EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 ||
+   EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 ||
+   EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 ||
+   EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0)
+   return -EINVAL;
+
+   mode-name = name;
+   mode-xres = EDID_DETAILED_TIMING_HORIZONTAL_ACTIVE(*t);
+   mode-yres = EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t);
+   mode-pixclock = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) /
+1000;
+
+   mode-left_margin = EDID_DETAILED_TIMING_HSYNC_OFFSET(*t);
+   mode-hsync_len = EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t);
+   margin = EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t) -
+   (mode-left_margin + mode-hsync_len);
+   if (margin = 0)
+   return -EINVAL;
+
+   mode-right_margin = margin;


Note left and right margin are swapped here, I've this fixed in my
local tree.

Regards,

Hans


+
+   mode-lower_margin = EDID_DETAILED_TIMING_VSYNC_OFFSET(*t);
+   mode-vsync_len = EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t);
+   margin = EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) -
+   (mode-lower_margin + mode-vsync_len);
+   if (margin = 0)
+   return -EINVAL;
+
+   mode-upper_margin = margin;
+
+   if (EDID_DETAILED_TIMING_FLAG_INTERLEAVED(*t))
+   mode-vmode = FB_VMODE_INTERLACED;
+   else
+   mode-vmode = FB_VMODE_NONINTERLACED;
+
+   mode-sync = 0;
+   if (EDID_DETAILED_TIMING_FLAG_HSYNC_POLARITY(*t))
+   mode-sync |= FB_SYNC_HOR_HIGH_ACT;
+   if (EDID_DETAILED_TIMING_FLAG_VSYNC_POLARITY(*t))
+   mode-sync |= FB_SYNC_VERT_HIGH_ACT;
+
+   mode-flag = 0;
+
+   h_total = mode-xres + EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*t);
+   v_total = mode-yres + EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t);
+   mode-refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) /
+   (h_total * v_total);
+
+   snprintf(name, name_len, %dx%d@%d, mode-xres, mode-yres,
+mode-refresh);
+
+   return 0;
+}
diff --git a/include/edid.h b/include/edid.h
index 480a773..d66f76b 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -13,6 +13,7 @@
  #ifndef __EDID_H_
  #define __EDID_H_

+#include linux/fb.h
  #include linux/types.h

  #define GET_BIT(_x, _pos) \
@@ -86,6 +87,10 @@ struct edid_detailed_timing {
GET_BITS((_x).flags, 4, 3)
  #define EDID_DETAILED_TIMING_FLAG_POLARITY(_x) \
GET_BITS((_x).flags, 2, 1)
+#define EDID_DETAILED_TIMING_FLAG_VSYNC_POLARITY(_x) \
+   GET_BIT((_x).flags, 2)
+#define EDID_DETAILED_TIMING_FLAG_HSYNC_POLARITY(_x) \
+   GET_BIT((_x).flags, 1)
  #define EDID_DETAILED_TIMING_FLAG_INTERLEAVED(_x) \
GET_BIT((_x).flags, 0)
  } __attribute__ ((__packed__));
@@ -255,4 +260,17 @@ int edid_get_ranges(struct edid1_info *edid, unsigned int 
*hmin,
unsigned int *hmax, unsigned int *vmin,
unsigned int *vmax);

+/**
+ * Convert an EDID detailed timing to a fb_videomode
+ *
+ * @param tThe EDID detailed timing to be converted
+ * @param mode Returns the converted timing
+ * @param name Buffer for the mode name mode-name will be set to this
+ * @param name_len Length of name
+ *
+ * @return 0 on success, or a negative errno on error
+ */
+int edid_dtd_to_fbmode(struct edid_detailed_timing *t,
+  struct fb_videomode *mode, char *name, int name_len);
+
  #endif /* __EDID_H_ */


___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [U-Boot,3/5] ARM: remove CONFIG_ARM920T defines

2014-11-24 Thread Tom Rini
On Thu, Nov 06, 2014 at 02:59:35PM +0900, Masahiro Yamada wrote:

 CONFIG_CPU_ARM920T was introduced into Kconfig by commit 2e07c249a67e
 (kconfig: arm: introduce symbol for ARM CPUs).
 
 This commit removes all the defines of CONFIG_ARM920T and replaces the
 only reference in drivers/usb/host/ohci-hcd.c with CONFIG_CPU_ARM920T.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/5] ARM: remove CONFIG_ARM1176 defines

2014-11-24 Thread Tom Rini
On Thu, Nov 06, 2014 at 02:59:34PM +0900, Masahiro Yamada wrote:

 CONFIG_ARM1176 is defined for some boards but not referenced at all.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,1/5] ARM: remove CONFIG_ARMV7 defines

2014-11-24 Thread Tom Rini
On Thu, Nov 06, 2014 at 02:59:33PM +0900, Masahiro Yamada wrote:

 Some (not all) of ARMv7 boards define CONFIG_ARMV7, which is useless.
 Besides, it is never referenced.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,5/5] ARM: remove CONFIG_ARM1136 defines

2014-11-24 Thread Tom Rini
On Thu, Nov 06, 2014 at 02:59:37PM +0900, Masahiro Yamada wrote:

 CONFIG_CPU_ARM1136 was introduced into Kconfig by commit 2e07c249a67e
 (kconfig: arm: introduce symbol for ARM CPUs).
 
 This commit removes all the defines of CONFIG_ARM1136 and replaces
 the only reference in arch/arm/lib/cache.c with CONFIG_CPU_ARM1136.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v3,4/6] linux/kernel.h: import more macros

2014-11-24 Thread Tom Rini
On Fri, Nov 07, 2014 at 03:03:29AM +0900, Masahiro Yamada wrote:

 These macros seem to be useful for U-Boot too (or at least
 harmless).  Imported from Linux 3.18-rc2.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
Tom


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


  1   2   3   >