date:20131114


Hi Andreas,

On 11/14/2013 03:42 PM, Andreas Bießmann wrote:

Hi Bo,

On 11/14/2013 07:40 AM, Bo Shen wrote:

On 11/13/2013 09:03 PM, Andreas Bießmann wrote:

On 11/06/2013 06:29 AM, Bo Shen wrote:


snip


+static void atmel_mpddr_op(int mode, u32 ram_address)


static inline, could give the compiler a hint to optimize here.


I am not sure whether the write(0, ram_address) will be optimized.
Because this must excute later than write mode to let it work.


well, I don't mean reordering for optimization here.
The point is the atmel_mpddr_op will get two mostly static values (it is
not fully true cause ram_address will be calculated, but didn't knew
when writing). So when using the function we need to setup two
registers, branch (and do all the stuff involved: saving to the stack
a.s.o.) and write the register content to two different addresses.

If we instruct the compiler to inline atmel_mpddr_op() he could decide
to just take the const value given into ddr2_init to be written to the
relevant address. I think that is optimization too. It could however
increase the text segment by some bytes also, that is to be checked
(cause it would be getting worse and that would be no optimization).


Got you means, ok, I will test it.


+{
+struct atmel_mpddr *mpddr = (struct atmel_mpddr
*)ATMEL_BASE_MPDDRC;
+
+writel(mode, mpddr-mr);
+writel(0, ram_address);
+}
+
+int ddr2_init(u32 ram_address, struct atmel_mpddr *mpddr_value)


could you please constify mpddr_value for the very same reason?


OK.


I think ram_address should also be declared const.

snip


+#ifndef __ATMEL_MPDDRC_H__
+#define __ATMEL_MPDDRC_H__
+
+struct atmel_mpddr {
+u32 mr;
+u32 rtr;
+u32 cr;
+u32 tp0r;


Datasheet names them tprX


Actually, this name is Timing Parameter 0 Register,
Timing Parameter 1 Register.


Well, I know. But my data sheet names it MPDDRC_TPR0 (the abbreviation
in table 28-13). I think we should use the names in data sheet here. I
often search the data sheet for the given name. mpddr will point to the
correct subsystem in SoC, that is good. But tp0r will find nothing. This
just consumes time when looking up the spec and is IMHO annoying.


+u32 tp1r;
+u32 tp2r;
+u32 reserved[2];
+u32 mdr;


Datasheet names it just md.


All other registers with r suffix, so, add r to this register name too.


But the name in data sheet is MPDDRC_MD ...


OK, for register name, I will following up the table.
Thanks.


Best regards

Andreas Bießmann



Best Regards,
Bo Shen

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

[U-Boot] NAND BBI swap on iMX53

2013-11-14 Thread Luca Ellero


Hi all,
I've noticed that mxc_nand driver doesn't implement BBI swap for reading 
factory marked bad blocks on NAND devices, as suggested by Freescale:


https://community.freescale.com/servlet/JiveServlet/download/329191-260869/AN_MX_NAND_BAD_BLOCK.pdf

BBI swap is implemented in Freescale iMX53 BSP (which use an old u-boot 
version 2009.08) but not DENX official U-Boot.
Isn't this a dangerous behaviour? As far as as I can see it can lead to 
an irreparable loss of factory bad blocks markers.

Can someone please give me some information about this topic.
Thanks

Best regards
Luca Ellero


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

Re: [U-Boot] [PATCH] mx6: Add initial support for Carrier1 mx6solo board

2013-11-14 Thread Stefano Babic

On 14/11/2013 11:12, Fabio Estevam wrote:

 I would like to send another patch that depends on this one.

 Could you please let me know if you think this one looks good?
 
 Actually please discard this one. Will need to send a v2 soon.

Ok, understood.

Stefano


-- 
=
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

[U-Boot] tr

2013-11-14 Thread Frank Ihle

Hi everybody

I'm writing you since you have been mentioned in the README as help

I
 got this ARM9 SAM9G25, and i try to use it with embedded linux, I 
already made the images but there's an Error on the target while booting which 
says No NandFlash 
detected ! and afterwards it continues with the system already 
installed. Since there is a special page from Atmel for this job, i 
sticked to that content 
(http://www.at91.com/linux4sam/bin/view/Linux4SAM/SAM9x5Page).

I wanted to boot that system from SD Card, therefore i used bootstrap with the 
at91sam9x5sduboot_defconfig (like the page says) and U-Boot with the 
at91sam9x5ek_nandflash_config.

And i made an image with buildroot (with the patch for that CPU).

So
 in the end I put the boot.bin, u-boot.bin and the 
uImage-2.6.39-r1-at91sam9x5ek (from buildroot) on the FAT16 SD card and 
when i try to boot from that Card the error message appears '(no 
NandFlash detected), then he ignores the SD-Card device and continues 
with the already installed system.

Unfortunately i have completly no clue whats the problem here, i hope some of 
you can help me out. But what I know: it trys to read the SD-Card, since 
there's a little bit of a different startup when booting without the Card.

Thank you! and greetings

Frank



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

[U-Boot] [PATCH] phy: introduce structure fixed-link

2013-11-14 Thread shh.xie

From: Shaohui Xie shaohui@freescale.com

fixed-link is used in kernel for PHY-less MAC, so introduce this
structure that U-boot can use it to fixup dtb dynamically.

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 include/phy.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/phy.h b/include/phy.h
index f0f522a..f86ffb9 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -160,6 +160,14 @@ struct phy_device {
u32 flags;
 };
 
+struct fixed_link {
+   int phy_id;
+   int duplex;
+   int link_speed;
+   int pause;
+   int asym_pause;
+};
+
 static inline int phy_read(struct phy_device *phydev, int devad, int regnum)
 {
struct mii_dev *bus = phydev-bus;
-- 
1.8.0


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

[U-Boot] [PATCH 1/4] net/fman: Add support for 10GEC3 and 10GEC4

2013-11-14 Thread Shengzhou Liu

There are more than two 10GEC in single FMAN in some SoCs(e.g. T2080).
This patch adds support for 10GEC3 and 10GEC4.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
Against master branch of upstream.

 arch/powerpc/include/asm/fsl_serdes.h |  2 ++
 arch/powerpc/include/asm/immap_85xx.h |  2 ++
 drivers/net/fm/eth.c  |  8 ++--
 drivers/net/fm/fm.h   |  2 ++
 drivers/net/fm/init.c | 18 ++
 include/fm_eth.h  | 18 ++
 6 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_serdes.h 
b/arch/powerpc/include/asm/fsl_serdes.h
index cce892c..404ded4 100644
--- a/arch/powerpc/include/asm/fsl_serdes.h
+++ b/arch/powerpc/include/asm/fsl_serdes.h
@@ -62,6 +62,8 @@ enum srds_prtcl {
QSGMII_FM1_B,   /* B indicates MACs 5,6,9,10 */
QSGMII_FM2_A,
QSGMII_FM2_B,
+   XFI_FM1_MAC1,
+   XFI_FM1_MAC2,
XFI_FM1_MAC9,
XFI_FM1_MAC10,
XFI_FM2_MAC9,
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 060e0d7..e47da1d 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1717,6 +1717,8 @@ typedef struct ccsr_gur {
 #define FSL_CORENET_DEVDISR2_DTSEC1_10 0x0040
 #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
 #define FSL_CORENET_DEVDISR2_DTSEC2_1  0x0008
 #define FSL_CORENET_DEVDISR2_DTSEC2_2  0x0004
 #define FSL_CORENET_DEVDISR2_DTSEC2_3  0x0002
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index cb099cd..e346cd2 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -557,8 +557,12 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
num = fm_eth-num;
 
 #ifdef CONFIG_SYS_FMAN_V3
-   if (fm_eth-type == FM_ETH_10G_E)
-   num += 8;
+   if (fm_eth-type == FM_ETH_10G_E) {
+   if (fm_eth-num = 2)
+   num -= 2;
+   else
+   num += 8;
+   }
base = reg-memac[num].fm_memac;
phyregs = reg-memac[num].fm_memac_mdio;
 #else
diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
index 3ec49a4..43de114 100644
--- a/drivers/net/fm/fm.h
+++ b/drivers/net/fm/fm.h
@@ -18,9 +18,11 @@
 #define RX_PORT_1G_BASE0x08
 #define MAX_NUM_RX_PORT_1G CONFIG_SYS_NUM_FM1_DTSEC
 #define RX_PORT_10G_BASE   0x10
+#define RX_PORT_10G_BASE2  0x08
 #define TX_PORT_1G_BASE0x28
 #define MAX_NUM_TX_PORT_1G CONFIG_SYS_NUM_FM1_DTSEC
 #define TX_PORT_10G_BASE   0x30
+#define TX_PORT_10G_BASE2  0x28
 #define MIIM_TIMEOUT0x
 
 struct fm_muram {
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 35edd7a..cd787f4 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -64,6 +64,12 @@ struct fm_eth_info fm_info[] = {
 #if (CONFIG_SYS_NUM_FM1_10GEC = 2)
FM_TGEC_INFO_INITIALIZER(1, 2),
 #endif
+#if (CONFIG_SYS_NUM_FM1_10GEC = 3)
+   FM_TGEC_INFO_INITIALIZER2(1, 3),
+#endif
+#if (CONFIG_SYS_NUM_FM1_10GEC = 4)
+   FM_TGEC_INFO_INITIALIZER2(1, 4),
+#endif
 #if (CONFIG_SYS_NUM_FM2_10GEC = 1)
FM_TGEC_INFO_INITIALIZER(2, 1),
 #endif
@@ -239,10 +245,14 @@ static void ft_fixup_port(void *blob, struct fm_eth_info 
*info, char *prop)
 * FM1_10GEC1 is enabled and  FM1_DTSEC9 is disabled, ensure that the
 * dual-role MAC is not disabled, ditto for other dual-role MACs.
 */
-   if (((info-port == FM1_DTSEC9)  (PORT_IS_ENABLED(FM1_10GEC1)))   
||
-   ((info-port == FM1_DTSEC10)  (PORT_IS_ENABLED(FM1_10GEC2)))  
||
-   ((info-port == FM1_10GEC1)  (PORT_IS_ENABLED(FM1_DTSEC9)))   
||
-   ((info-port == FM1_10GEC2)  (PORT_IS_ENABLED(FM1_DTSEC10)))
+   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_10GEC3)))  ||
+   ((info-port == FM1_DTSEC2)  (PORT_IS_ENABLED(FM1_10GEC4)))  ||
+   ((info-port == FM1_10GEC1)  (PORT_IS_ENABLED(FM1_DTSEC9)))  ||
+   ((info-port == FM1_10GEC2)  (PORT_IS_ENABLED(FM1_DTSEC10))) ||
+   ((info-port == FM1_10GEC3)  (PORT_IS_ENABLED(FM1_DTSEC1)))  ||
+   ((info-port == FM1_10GEC4)  (PORT_IS_ENABLED(FM1_DTSEC2)))
 #if (CONFIG_SYS_NUM_FMAN == 2)

||
((info-port == FM2_DTSEC9)  (PORT_IS_ENABLED(FM2_10GEC1)))   
||
diff --git a/include/fm_eth.h b/include/fm_eth.h
index 5a4fb70..98edfcf 100644
--- a/include/fm_eth.h
+++ b/include/fm_eth.h
@@ -22,6 +22,8 @@ enum fm_port {
FM1_DTSEC10,

[U-Boot] [PATCH 2/4] powerpc/mpc85xx: Add T2080/T2081 SoC support

2013-11-14 Thread Shengzhou Liu

Add support for Freescale T2080/T2081 SoC.

T2080 includes the following functions and features:
- Four dual-threads 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- 16 SerDes lanes up to 10.3125 GHz
- 8 mEMACs for network interfaces (four 1Gbps MACs and four 10Gbps/1Gbps MACs)
- High-speed peripheral interfaces
  - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV)
  - Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz
- Additional peripheral interfaces
  - Two serial ATA (SATA 2.0) controllers
  - Two high-speed USB 2.0 controllers with integrated PHY
  - Enhanced secure digital host controller (SD/SDHC/SDXC/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
- Three eight-channel DMA engines
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0

Differences between T2080 and T2081:
  Feature   T2080 T2081
  1G Ethernet numbers:  8 6
  10G Ethernet numbers: 4 2
  SerDes lanes: 168
  Serial RapidIO,RMan:  2 no
  SATA Controller:  2 no
  Aurora:   yes   no
  SoC Package:  896-pins 780-pins

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
Against master branch of upstream.

 arch/powerpc/cpu/mpc85xx/Makefile |   6 +
 arch/powerpc/cpu/mpc85xx/speed.c  |   2 +-
 arch/powerpc/cpu/mpc85xx/t2080_ids.c  | 142 
 arch/powerpc/cpu/mpc85xx/t2080_serdes.c   | 209 ++
 arch/powerpc/cpu/mpc8xxx/cpu.c|   2 +
 arch/powerpc/include/asm/config_mpc85xx.h |  43 ++
 arch/powerpc/include/asm/immap_85xx.h |  16 +++
 arch/powerpc/include/asm/processor.h  |   2 +
 drivers/net/fm/Makefile   |   2 +
 drivers/net/fm/t2080.c|  92 +
 10 files changed, 515 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/cpu/mpc85xx/t2080_ids.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/t2080_serdes.c
 create mode 100644 drivers/net/fm/t2080.c

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index 50ddb50..22b98db 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -70,6 +70,8 @@ obj-$(CONFIG_PPC_B4860)   += ddr-gen3.o
 obj-$(CONFIG_BSC9131)  += ddr-gen3.o
 obj-$(CONFIG_BSC9132)  += ddr-gen3.o
 obj-$(CONFIG_PPC_T1040)+= ddr-gen3.o
+obj-$(CONFIG_PPC_T2080) += ddr-gen3.o
+obj-$(CONFIG_PPC_T2081) += ddr-gen3.o
 
 obj-$(CONFIG_CPM2) += ether_fcc.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
@@ -89,6 +91,8 @@ obj-$(CONFIG_PPC_T4160) += t4240_ids.o
 obj-$(CONFIG_PPC_B4420) += b4860_ids.o
 obj-$(CONFIG_PPC_B4860) += b4860_ids.o
 obj-$(CONFIG_PPC_T1040) += t1040_ids.o
+obj-$(CONFIG_PPC_T2080) += t2080_ids.o
+obj-$(CONFIG_PPC_T2081) += t2080_ids.o
 
 obj-$(CONFIG_QE)   += qe_io.o
 obj-$(CONFIG_CPM2) += serial_scc.o
@@ -128,6 +132,8 @@ obj-$(CONFIG_PPC_B4420) += b4860_serdes.o
 obj-$(CONFIG_PPC_B4860) += b4860_serdes.o
 obj-$(CONFIG_BSC9132) += bsc9132_serdes.o
 obj-$(CONFIG_PPC_T1040) += t1040_serdes.o
+obj-$(CONFIG_PPC_T2080) += t2080_serdes.o
+obj-$(CONFIG_PPC_T2081) += t2080_serdes.o
 
 obj-y  += cpu.o
 obj-y  += cpu_init.o
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index d08a8d2..1a58a19 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -122,7 +122,7 @@ void get_sys_info(sys_info_t *sys_info)
sys_info-freq_processor[cpu] =
 freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
-#ifdef CONFIG_PPC_B4860
+#if defined(CONFIG_PPC_B4860) || defined(CONFIG_PPC_T2080)
 #define FM1_CLK_SEL0xe000
 #define FM1_CLK_SHIFT  29
 #else
diff --git a/arch/powerpc/cpu/mpc85xx/t2080_ids.c 
b/arch/powerpc/cpu/mpc85xx/t2080_ids.c
new file mode 100644
index 000..068e1f2
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/t2080_ids.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/fsl_portals.h
+#include asm/fsl_liodn.h
+
+#ifdef CONFIG_SYS_DPAA_QBMAN
+struct qportal_info qp_info[CONFIG_SYS_QMAN_NUM_PORTALS] = {
+   /* dqrr liodn, frame data liodn, liodn off, sdest */
+   SET_QP_INFO(1, 27, 1, 0),
+   SET_QP_INFO(2, 28, 1, 0),
+   SET_QP_INFO(3, 29, 1, 1),
+   SET_QP_INFO(4, 30, 1, 1),
+   SET_QP_INFO(5, 31, 1, 2),
+   SET_QP_INFO(6, 32, 1, 2),
+   SET_QP_INFO(7, 33, 1, 3),
+   SET_QP_INFO(8, 34, 1, 3),
+   SET_QP_INFO(9, 35,

[U-Boot] [PATCH 4/4] t2080qds/ramboot: enable PBL tool for t2080qds

2013-11-14 Thread Shengzhou Liu

Add the default RCW(0x66_0x16) and PBI configure file for
T2080QDS board, so we can use PBL tool to generate the ramboot
image to support boot from NAND/SPI/SD.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
Against master branch of upstream.

 board/freescale/t2080qds/t2080_pbi.cfg | 41 ++
 board/freescale/t2080qds/t2080_rcw.cfg |  8 +++
 2 files changed, 49 insertions(+)
 create mode 100644 board/freescale/t2080qds/t2080_pbi.cfg
 create mode 100644 board/freescale/t2080qds/t2080_rcw.cfg

diff --git a/board/freescale/t2080qds/t2080_pbi.cfg 
b/board/freescale/t2080qds/t2080_pbi.cfg
new file mode 100644
index 000..e200d92
--- /dev/null
+++ b/board/freescale/t2080qds/t2080_pbi.cfg
@@ -0,0 +1,41 @@
+#
+# Copyright 2013 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+# Refer doc/README.pblimage for more details about how-to configure
+# and create PBL boot image
+#
+
+#PBI commands
+#Initialize CPC1
+0901 00200400
+09138000 
+091380c0 0100
+#512KB SRAM
+09010100 
+09010104 fff80009
+09010f00 0800
+#enable CPC1
+0901 8000
+#Configure LAW for CPC1
+09000d00 
+09000d04 fff8
+09000d08 8112
+#Initialize eSPI controller, default configuration is slow for eSPI to
+#load data, this configuration comes from u-boot eSPI driver.
+0911 8403
+09110020 2d170008
+09110024 0018
+09110028 0018
+0911002c 0018
+#Errata for slowing down the MDC clock to make it = 2.5 MHZ
+094fc030 8148
+094fd030 8148
+#Configure alternate space
+0910 
+0914 ff00
+0918 8100
+#Flush PBL data
+09138000 
+091380c0 
diff --git a/board/freescale/t2080qds/t2080_rcw.cfg 
b/board/freescale/t2080qds/t2080_rcw.cfg
new file mode 100644
index 000..c2ad0fd
--- /dev/null
+++ b/board/freescale/t2080qds/t2080_rcw.cfg
@@ -0,0 +1,8 @@
+#PBL preamble and RCW header
+aa55aa55 010e0100
+#SerDes Protocol: 0x66_0x16
+#Core/DDR: 1533Mhz/2133MT/s
+12100017 1500  
+66160002 8400 e8104000 c100
+   000307fc
+   0004
-- 
1.8.0


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

Re: [U-Boot] [U-Boot,PATCHv4] Optimized nand_read_buf for kirkwood

2013-11-14 Thread Phil Sutter

Scott,

On Wed, Nov 13, 2013 at 07:31:02PM -0600, Scott Wood wrote:
 On Mon, Aug 26, 2013 at 02:10:56PM +0200, Phil Sutter wrote:
  From: Nico Erfurth n...@erfurth.eu
  
  The basic idea is taken from the linux-kernel, but further optimized.
  
  First align the buffer to 8 bytes, then use ldrd/strd to read and store
  in 8 byte quantities, then do the final bytes.
  
  Tested using: 'date ; nand read.raw 0xE0 0x0 0x1 ; date'.
  Without this patch, NAND read of 132MB took 49s (~2.69MB/s). With this
  patch in place, reading the same amount of data was done in 27s
  (~4.89MB/s). So read performance is increased by ~80%!
  
  Signed-off-by: Nico Erfurth n...@erfurth.eu
  Tested-by: Phil Sutter phil.sut...@viprinet.com
  Cc: Prafulla Wadaskar prafu...@marvell.com
  
  ---
  Changed since V3:
  - fixed author
  ---
   drivers/mtd/nand/kirkwood_nand.c | 32 
   1 file changed, 32 insertions(+)
 
 I tried to build-test this, and I couldn't find any board that defines
 CONFIG_NAND_KIRKWOOD.
 
 The patch that removed it was commit
 b5befd8211b54ae2d2fca3fbed061c879951ceaa (arm/km: fix u-boot.kwb build
 breakage), over two years ago.  It's not clear whether the removal was
 intentional.
 
 What target did you use to test this?

I tested using a custom board with Marvell Kirkwood SoC, but e.g. the
Marvell OpenRD Ultimate should be fine.

Best wishes,

Phil Sutter
Software Engineer

-- 
Viprinet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany

Phone/Zentrale:   +49 6721 49030-0
Direct line/Durchwahl:+49 6721 49030-134
Fax:  +49 6721 49030-109

phil.sut...@viprinet.com
http://www.viprinet.com

Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany
Commercial register/Handelsregister: Amtsgericht Mainz HRB44090
CEO/Geschäftsführer: Simon Kissel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] powerpc/t2080qds: add support for t2080qds board

2013-11-14 Thread Wolfgang Denk

Dear Shengzhou Liu,

In message 1384428739-31299-1-git-send-email-shengzhou@freescale.com you 
wrote:
 The T2080QDS is a high-performance computing evaluation, development and
 test platform supporting the T2080 QorIQ Power Architecture processor.

This commit has a number of checkpatch warnings (Avoid unnecessary
line continuations, quoted string split across lines) that need to be
fixed.

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
Be kind to unkind people - they need it the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] env export fixes

2013-11-14 Thread Pierre Aubert

These patches fix two issues in the export of environment 
variables with CRC calculation.

Pierre Aubert (2):
  hashtable: fix the export lenght computation.
  env export fix: compute the CRC on the real lenght of the exported
variables.

 common/cmd_nvedit.c |5 +++--
 lib/hashtable.c |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
1.7.6.5

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

[U-Boot] [PATCH 2/2] env export fix: compute the CRC on the real lenght of the exported variables.

2013-11-14 Thread Pierre Aubert

Signed-off-by: Pierre Aubert p.aub...@staubli.com
---
 common/cmd_nvedit.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 5bcc324..c32a932 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -922,14 +922,15 @@ NXTARG:   ;
 
len = hexport_r(env_htab, '\0',
H_MATCH_KEY | H_MATCH_IDENT,
-   res, ENV_SIZE, argc, argv);
+   res, size, argc, argv);
+
if (len  0) {
error(Cannot export environment: errno = %d\n, errno);
return 1;
}
 
if (chk) {
-   envp-crc = crc32(0, envp-data, ENV_SIZE);
+   envp-crc = crc32(0, envp-data, len);
 #ifdef CONFIG_ENV_ADDR_REDUND
envp-flags = ACTIVE_FLAG;
 #endif
-- 
1.7.6.5

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

[U-Boot] [PATCH 1/2] hashtable: fix the export lenght computation.

2013-11-14 Thread Pierre Aubert

The room for the '=' and the sep char was reserved twice.

Signed-off-by: Pierre Aubert p.aub...@staubli.com
---
 lib/hashtable.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/hashtable.c b/lib/hashtable.c
index 4356b23..480d207 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -623,7 +623,7 @@ ssize_t hexport_r(struct hsearch_data *htab, const char 
sep, int flag,
 
list[n++] = ep;
 
-   totlen += strlen(ep-key) + 2;
+   totlen += strlen(ep-key);
 
if (sep == '\0') {
totlen += strlen(ep-data);
-- 
1.7.6.5

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

[U-Boot] [PATCH][RESEND 0/2] get_ram_size incorrectly returns long, should be unsigned long

2013-11-14 Thread Oliver Schinagl

From: Oliver Schinagl oli...@schinagl.nl

This is a resond of the previous patch I offered as an RFC. There was some
talk on the list but nothing related to the code in question.

This patchset is split in two, one that modifies get_ram_size() and a second
one that updates all invocations of get_ram_size(). Maintainers probably should
double check if their board was handled properly or even improve it to handle
it better.

Oliver

Oliver Schinagl (2):
  get_ram_size incorrectly returns long, should be unsigned long
  Update all references to get_ram_size to unsigned long

 arch/arm/cpu/arm926ejs/davinci/misc.c   |  2 +-
 arch/arm/cpu/arm926ejs/kirkwood/dram.c  |  2 +-
 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c   |  2 +-
 arch/arm/cpu/arm926ejs/orion5x/dram.c   |  2 +-
 arch/arm/cpu/armv7/am33xx/emif4.c   |  2 +-
 arch/arm/cpu/armv7/omap-common/emif-common.c|  4 ++--
 arch/arm/cpu/armv7/socfpga/misc.c   |  2 +-
 arch/powerpc/cpu/mpc512x/fixed_sdram.c  |  2 +-
 arch/powerpc/cpu/ppc4xx/sdram.c |  8 
 board/AndesTech/adp-ag101/adp-ag101.c   |  2 +-
 board/AndesTech/adp-ag101p/adp-ag101p.c |  2 +-
 board/AndesTech/adp-ag102/adp-ag102.c   |  2 +-
 board/BuS/eb_cpux9k2/cpux9k2.c  |  2 +-
 board/BuS/vl_ma2sc/vl_ma2sc.c   |  2 +-
 board/CarMediaLab/flea3/flea3.c |  2 +-
 board/LEOX/elpt860/elpt860.c|  2 +-
 board/RPXClassic/RPXClassic.c   |  2 +-
 board/RPXlite/RPXlite.c |  2 +-
 board/RPXlite_dw/RPXlite_dw.c   |  2 +-
 board/RRvision/RRvision.c   |  2 +-
 board/a3000/a3000.c |  8 
 board/a3m071/a3m071.c   |  4 ++--
 board/a4m072/a4m072.c   |  4 ++--
 board/adder/adder.c |  2 +-
 board/afeb9260/afeb9260.c   |  2 +-
 board/armltd/integrator/integrator.c|  4 ++--
 board/armltd/versatile/versatile.c  |  2 +-
 board/armltd/vexpress/vexpress_common.c |  6 +++---
 board/atc/atc.c |  2 +-
 board/atmel/at91rm9200ek/at91rm9200ek.c |  2 +-
 board/atmel/at91sam9260ek/at91sam9260ek.c   |  2 +-
 board/atmel/at91sam9261ek/at91sam9261ek.c   |  2 +-
 board/atmel/at91sam9263ek/at91sam9263ek.c   |  2 +-
 board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |  2 +-
 board/atmel/at91sam9n12ek/at91sam9n12ek.c   |  2 +-
 board/atmel/at91sam9rlek/at91sam9rlek.c |  2 +-
 board/atmel/at91sam9x5ek/at91sam9x5ek.c |  2 +-
 board/atmel/atngw100/atngw100.c |  2 +-
 board/atmel/atngw100mkii/atngw100mkii.c |  2 +-
 board/atmel/atstk1000/atstk1000.c   |  2 +-
 board/atmel/sama5d3xek/sama5d3xek.c |  2 +-
 board/bc3450/bc3450.c   |  8 
 board/bluewater/snapper9260/snapper9260.c   |  2 +-
 board/calao/sbc35_a9g20/sbc35_a9g20.c   |  2 +-
 board/calao/tny_a9260/tny_a9260.c   |  2 +-
 board/canmb/canmb.c |  8 
 board/cm5200/cm5200.c   |  4 ++--
 board/congatec/cgtqmx6eval/cgtqmx6eval.c|  2 +-
 board/cpu86/cpu86.c |  2 +-
 board/cpu87/cpu87.c |  2 +-
 board/cu824/cu824.c |  8 
 board/davedenx/qong/qong.c  |  2 +-
 board/denx/m53evk/m53evk.c  |  6 +++---
 board/earthlcd/favr-32-ezkit/favr-32-ezkit.c|  2 +-
 board/egnite/ethernut5/ethernut5.c  |  2 +-
 board/emk/top9000/top9000.c |  2 +-
 board/ep88x/ep88x.c |  2 +-
 board/esd/cpci5200/cpci5200.c   |  4 ++--
 board/esd/mecp5123/mecp5123.c   |  2 +-
 board/esd/meesc/meesc.c |  2 +-
 board/esd/otc570/otc570.c   |  2 +-
 board/esd/pf5200/pf5200.c   |  4 ++--
 board/esd/vme8349/vme8349.c |  2 +-
 board/esg/ima3-mx53/ima3-mx53.c |  2 +-
 board/esteem192e/esteem192e.c   |  4 ++--
 board/eukrea/cpu9260/cpu9260.c  |  2 +-
 board/eukrea/cpuat91/cpuat91.c  |  2 +-
 board/fads/fads.c   |  2 +-
 board/faraday/a320evb/a320evb.c |  2 +-
 board/freescale/mpc8308rdb/sdram.c  |  2 +-
 board/freescale/mx25pdk/mx25pdk.c   |  2 +-
 board/freescale/mx31ads/mx31ads.c   |  2 +-
 board/freescale/mx31pdk/mx31pdk.c   |  2 +-
 board/freescale/mx35pdk/mx35pdk.c   |  6 +++---
 board/freescale/mx51evk/mx51evk.c   |  2 +-
 board/freescale/mx53ard/mx53ard.c   |  6 +++---

[U-Boot] [PATCH][RESEND 1/2] get_ram_size incorrectly returns long, should be unsigned long

2013-11-14 Thread Oliver Schinagl

From: Oliver Schinagl oli...@schinagl.nl

One of the parameters that gets passed to the Linux kernel is the
physical continuous RAM size. The type for this datum is phys_size_t
which is hiding its real data type, unsigned long.

get_ram_size however returns long and thus can not only report negative
memory, it also clashes with pyhs_size_t.

This patch converts get_ram_size to take and return unsigned long's over
signed longs.

Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
 common/memsize.c | 24 
 include/common.h |  2 +-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/common/memsize.c b/common/memsize.c
index 73b92c8..617907d 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -21,16 +21,16 @@
  * the actually available RAM size between addresses `base' and
  * `base + maxsize'.
  */
-long get_ram_size(long *base, long maxsize)
+unsigned long get_ram_size(unsigned long *base, unsigned long maxsize)
 {
-   volatile long *addr;
-   long   save[32];
-   long   cnt;
-   long   val;
-   long   size;
-   inti = 0;
+   volatile unsigned long *addr;
+   unsigned long   save[32];
+   unsigned long   cnt;
+   unsigned long   val;
+   unsigned long   size;
+   int i = 0;
 
-   for (cnt = (maxsize / sizeof (long))  1; cnt  0; cnt = 1) {
+   for (cnt = (maxsize / sizeof (unsigned long))  1; cnt  0; cnt = 1) 
{
addr = base + cnt;  /* pointer arith! */
sync ();
save[i++] = *addr;
@@ -50,7 +50,7 @@ long get_ram_size(long *base, long maxsize)
 */
sync ();
*addr = save[i];
-   for (cnt = 1; cnt  maxsize / sizeof(long); cnt = 1) {
+   for (cnt = 1; cnt  maxsize / sizeof(unsigned long); cnt = 1) 
{
addr  = base + cnt;
sync ();
*addr = save[--i];
@@ -58,15 +58,15 @@ long get_ram_size(long *base, long maxsize)
return (0);
}
 
-   for (cnt = 1; cnt  maxsize / sizeof (long); cnt = 1) {
+   for (cnt = 1; cnt  maxsize / sizeof (unsigned long); cnt = 1) {
addr = base + cnt;  /* pointer arith! */
val = *addr;
*addr = save[--i];
if (val != ~cnt) {
-   size = cnt * sizeof (long);
+   size = cnt * sizeof (unsigned long);
/* Restore the original data before leaving the 
function.
 */
-   for (cnt = 1; cnt  maxsize / sizeof (long); cnt = 
1) {
+   for (cnt = 1; cnt  maxsize / sizeof (unsigned long); 
cnt = 1) {
addr  = base + cnt;
*addr = save[--i];
}
diff --git a/include/common.h b/include/common.h
index 8addf43..e8a3547 100644
--- a/include/common.h
+++ b/include/common.h
@@ -453,7 +453,7 @@ const char *symbol_lookup(unsigned long addr, unsigned long 
*caddr);
 void   api_init (void);
 
 /* common/memsize.c */
-long   get_ram_size  (long *, long);
+unsigned long  get_ram_size  (unsigned long *, unsigned long);
 
 /* $(BOARD)/$(BOARD).c */
 void   reset_phy (void);
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

On Wed, Nov 13, 2013 at 09:08:29AM -0500, Vaibhav Bedia wrote:
 On Wed, Nov 13, 2013 at 3:48 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 [...]
  I checked with hardware folks. There is no register or some way to tell
  if VTT is present. It is not added in EEPROM also and I have no answer why 
  it
  is not added in EEPROM..:(
  It is specific to boards using DDR3. So its good to have it in board files 
  as I did it here
  instead of adding this check in emif file.
 
 That EEPROM is clearly not getting used the way i think it should be :\
 I would have made a lot of noise to get details like this added there.
 
 You should at least check for the GP EVM (if possible) and then enable
 VTT. Doing this unconditionally is bound to cause problems later on.
 I would also put in a big comment over there so that folks who design
 their own board with DDR3 don't miss this fact.

I agree, the code should be doing a check for what board we're on and
enabling VTT, and a good comment about what's going on here.

-- 
Tom


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

Re: [U-Boot] [PATCH 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

On Wed, Nov 13, 2013 at 12:50:50PM -0500, Vaibhav Bedia wrote:
 Hi Sekhar :)
 
 On Wed, Nov 13, 2013 at 11:08 AM, Sekhar Nori nsek...@ti.com wrote:
  Hi Vaibhav,
 
  On 11/13/2013 7:38 PM, Vaibhav Bedia wrote:
  On Wed, Nov 13, 2013 at 3:48 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
  [...]
  I checked with hardware folks. There is no register or some way to tell
  if VTT is present. It is not added in EEPROM also and I have no answer 
  why it
  is not added in EEPROM..:(
  It is specific to boards using DDR3. So its good to have it in board 
  files as I did it here
  instead of adding this check in emif file.
 
  That EEPROM is clearly not getting used the way i think it should be :\
  I would have made a lot of noise to get details like this added there.
 
  The EEPROM was designed as a way to differentiate between different TI
  EVMs, not as a generic way to differentiate between various possible
  board hook-ups. Even if we did define it that way, why would all boards
  using AM437x have an onboard EEPROM?
 
  We could request this information be placed in EEPROM and see if
  hardware folks oblige, but I don't see how that's going to be used
  beyond TI EVMs.
 
 
 I understand the intent of customers to get rid of all the components
 they can to lower the cost. But if one just thinks about this a bit more,
 the current solution does a half-hearted attempt to differentiate the boards
 variants. It doesn't really capture the differences that are there and that
 is leading to hard coding to a certain extent.
 
 From AM335x boards we should now have a decent idea of what
 things change across boards that go into production. I don't think it
 makes sense to throw away all that knowledge and go ahead
 assuming we will never make a change. The request for change is just
 to future proof the current code and have the EEPROM actually help us
 do our jobs. Why? Because life's too short to keep worrying about why a
 board rev that a you pick up from a neighbor's desk doesn't boot, hooking
 up the JTAG to trace the DDR setup code, figure out what needs to change
 in the boot-loader, add in the appropriate check and then get to the task
 at hand ;)

In theory, one could also learn from the customers that did keep the
EEPROM about what additional information they programmed in.

I think however, the most likely outcome here is that we'll be able to
only rely on the board name (and rev) part of the EEPROM being populated
and the board code should be clear and well commented about non-obvious
things such as design choice A means B is required.

-- 
Tom


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

[U-Boot] [UBOOT][PATCH 0/2] misc fix for memory mapped support, dra config

Hi Jagan,
Here are the miscellaneous fix and config update for dra7 qspi flash.

Patch series adds:
Add BAR config in dra7 config file.
Set spi controller device control registers before
doing a memory mapped read.

Patches available here:
git://gitorious.org/u-boot-shared/u-boot-qspi.git debug_dra_qspi

Tested on dra7 evm with qspi boot.

Sourav Poddar (2):
  config: dra7_evm: Add Bank Address Register(BAR) config
  driver: mtd: sf_ops: claim bus while doing memcpy

 drivers/mtd/spi/sf_ops.c |6 ++
 include/configs/dra7xx_evm.h |1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

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

[U-Boot] [UBOOT][PATCH 2/2] driver: mtd: sf_ops: claim bus while doing memcpy

claim spi bus while doing memory copy, this will set up
the spi controller device control register before doing
a memory read.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Tested-by: Yebio Mesfin ymes...@ti.com
---
 drivers/mtd/spi/sf_ops.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 108665f..e316a69 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -273,9 +273,15 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 
/* Handle memory-mapped SPI */
if (flash-memory_map) {
+   ret = spi_claim_bus(flash-spi);
+   if (ret) {
+   debug(SF: unable to claim SPI bus\n);
+   return ret;
+   }
spi_xfer(flash-spi, 0, NULL, NULL, SPI_XFER_MMAP);
memcpy(data, flash-memory_map + offset, len);
spi_xfer(flash-spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
+   spi_release_bus(flash-spi);
return 0;
}
 
-- 
1.7.1

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

[U-Boot] [UBOOT][PATCH 1/2] config: dra7_evm: Add Bank Address Register(BAR) config

Add config to support bank address register.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Tested-by: Yebio Mesfin ymes...@ti.com
---
 include/configs/dra7xx_evm.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 1600131..46cc6db 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -54,6 +54,7 @@
 #define CONFIG_SPI_FLASH_SPANSION
 #define CONFIG_CMD_SF
 #define CONFIG_CMD_SPI
+#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_TI_SPI_MMAP
 #define CONFIG_SF_DEFAULT_SPEED4800
 #define CONFIG_DEFAULT_SPI_MODESPI_MODE_3
-- 
1.7.1

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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Robert Nelson

On Thu, Nov 14, 2013 at 4:06 AM, Hardik hardik.pa...@volansystech.com wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
 struct emif_regs **regs)
 *regs = emif_regs_elpida_200_mhz_2cs;
 else if (omap4_rev == OMAP4430_ES2_3)
 *regs = emif_regs_elpida_400_mhz_1cs;
 -   else if (omap4_rev  OMAP4470_ES1_0)
 +   else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
 *regs = emif_regs_elpida_400_mhz_2cs;
 else
 *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
 return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is rev 
 b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of


Nice, this works great on my Panda ES B3.

Tested-by: Robert Nelson robertcnel...@gmai.com


U-Boot SPL 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)
OMAP4460 ES1.1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img


U-Boot 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)

CPU  : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
Using default environment

BTW, should be bump the system enviroment board_name, that way it
loads a different kernel *.dtb? (omap4-panda-es-b3.dtb)

As right now it'll load the omap4-panda-es.dtb which currently uses
both cs lines on the emif driver..

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4-panda-common.dtsi#n373

Regards,

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

[U-Boot] [UBOOT][PATCH 3/5] sf: macronix: Add support for MX66L51235F

From: Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 drivers/mtd/spi/sf_probe.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 5eb8ffe..874ef8c 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -68,6 +68,7 @@ static const struct spi_flash_params spi_flash_params_table[] 
= {
{MX25L25635F,0xc22019, 0x0,   64 * 1024,   512,   
 0},
{MX25L51235F,0xc2201A, 0x0,   64 * 1024,  1024,   
 0},
{MX25L12855E,0xc22618, 0x0,   64 * 1024,   256,   
 0},
+   {MX66L51235F,0xc2201a, 0x0,   64 * 1024,  1024,   
 0},
 #endif
 #ifdef CONFIG_SPI_FLASH_SPANSION   /* SPANSION */
{S25FL008A,  0x010213, 0x0,   64 * 1024,16,   
 0},
@@ -207,6 +208,7 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
flash-page_size = (ext_jedec == 0x4d00) ? 512 : 256;
flash-sector_size = params-sector_size;
flash-size = flash-sector_size * params-nr_sectors;
+   flash-memory_map = spi-memory_map;
 
/* Compute erase sector and command */
if (params-flags  SECT_4K) {
-- 
1.7.1

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

[U-Boot] [UBOOT][PATCH 1/5] am43xx: add qspi support

Add QSPI definitions and clock configuration support.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 arch/arm/cpu/armv7/am33xx/clock_am43xx.c |1 +
 arch/arm/include/asm/arch-am33xx/cpu.h   |4 +++-
 arch/arm/include/asm/arch-am33xx/omap.h  |1 +
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index 97c00b4..fb654bb 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -98,6 +98,7 @@ void enable_basic_clocks(void)
cmper-emiffwclkctrl,
cmper-emifclkctrl,
cmper-otfaemifclkctrl,
+   cmper-qspiclkctrl,
0
};
 
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h 
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 23af125..6537b30 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -332,7 +332,9 @@ struct cm_perpll {
unsigned int mcasp1clkctrl; /* offset 0x240 */
unsigned int resv11;
unsigned int mmc2clkctrl;   /* offset 0x248 */
-   unsigned int resv12[5];
+   unsigned int resv12[3];
+   unsigned int qspiclkctrl;   /* offset 0x258 */
+   unsigned int resv121;
unsigned int usb0clkctrl;   /* offset 0x260 */
unsigned int resv13[103];
unsigned int l4lsclkstctrl; /* offset 0x400 */
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
b/arch/arm/include/asm/arch-am33xx/omap.h
index 10f05c9..7b2f193 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -29,5 +29,6 @@
 #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
 #define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
 #define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC
+#define QSPI_BASE  0x4790
 #endif
 #endif
-- 
1.7.1

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

[U-Boot] [UBOOT][PATCH 5/5] am43xx: add delay before xfer

Without this delay, write/read is failing.
Looks like, the WIP always remain set and hence a timeout
occurs leading to the error.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Hi Jagan,
This patch seems to be necessary for read/write.
I tested by changing few timing variables, but it did not help.
The same driver works on J6 with a differnet flash(S25FL256S).
Is any one tested macronix flash at uboot?

 drivers/spi/ti_qspi.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 5666250..aa7b6ae 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -285,6 +285,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
qslave-cmd |= QSPI_3_PIN;
qslave-cmd |= 0xfff;
 
+#ifdef CONFIG_AM43XX
+   udelay(100);
+#endif
while (words--) {
if (txp) {
debug(tx cmd %08x dc %08x data %02x\n,
-- 
1.7.1

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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Michael Trimarchi

Hi

On Thu, Nov 14, 2013 at 11:06 AM, Hardik hardik.pa...@volansystech.com wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
 struct emif_regs **regs)
 *regs = emif_regs_elpida_200_mhz_2cs;
 else if (omap4_rev == OMAP4430_ES2_3)
 *regs = emif_regs_elpida_400_mhz_1cs;
 -   else if (omap4_rev  OMAP4470_ES1_0)
 +   else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
 *regs = emif_regs_elpida_400_mhz_2cs;
 else
 *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644

No, it's not ok. Sorry but implement in this way it's a no-sense

 +   else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3()   
 !is_cat() 
!is_dog())
 *regs = emif_regs_elpida_400_mhz_2cs;

Michael


 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
 return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is rev 
 b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of
 --
 1.7.9.5

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

[U-Boot] [UBOOT][PATCH 0/5] qspi: Add AM437x support

The patch series add support for enabling qspi
on AM43xx at uboot.

Testing done:
-
Wrote a uImage to the flash, read it back and boot the
kernel.

Jagannadha Sutradharudu Teki (1):
  sf: macronix: Add support for MX25L51235F

Sourav Poddar (4):
  am43xx: add qspi support
  am437x_epos_evm: add SPL API, QSPI, and serial flash support
  qspi/spi: Add AM43xx specifics changes
  am43xx: add delay before xfer

 arch/arm/cpu/armv7/am33xx/clock_am43xx.c |1 +
 arch/arm/include/asm/arch-am33xx/cpu.h   |4 +++-
 arch/arm/include/asm/arch-am33xx/omap.h  |1 +
 board/ti/am43xx/mux.c|   11 +++
 drivers/mtd/spi/sf_probe.c   |2 ++
 drivers/spi/ti_qspi.c|   29 ++---
 include/configs/am43xx_evm.h |   20 
 7 files changed, 64 insertions(+), 4 deletions(-)

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

[U-Boot] [UBOOT][PATCH 2/5] am437x_epos_evm: add SPL API, QSPI, and serial flash support

Enables support for SPI SPL, QSPI and Spansion serial flash device
on the EVM. Configures pin muxes for QSPI mode.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 board/ti/am43xx/mux.c|   11 +++
 include/configs/am43xx_evm.h |   20 
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 341214d..ff12981 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -35,6 +35,16 @@ static struct module_pin_mux i2c0_pin_mux[] = {
{-1},
 };
 
+static struct module_pin_mux qspi_pin_mux[] = {
+   {OFFSET(gpmc_csn0), (MODE(3) | PULLUP_EN | RXACTIVE)},  /* QSPI_CS0 */
+   {OFFSET(gpmc_csn3), (MODE(2) | PULLUP_EN | RXACTIVE)},  /* QSPI_CLK */
+   {OFFSET(gpmc_advn_ale), (MODE(3) | PULLUP_EN | RXACTIVE)},  /* 
QSPI_D0 */
+   {OFFSET(gpmc_oen_ren), (MODE(3) | PULLUP_EN | RXACTIVE)},   /* 
QSPI_D1 */
+   {OFFSET(gpmc_wen), (MODE(3) | PULLUP_EN | RXACTIVE)},   /* QSPI_D2 */
+   {OFFSET(gpmc_be0n_cle), (MODE(3) | PULLUP_EN | RXACTIVE)},  /* 
QSPI_D3 */
+   {-1},
+};
+
 void enable_uart0_pin_mux(void)
 {
configure_module_pin_mux(uart0_pin_mux);
@@ -44,6 +54,7 @@ void enable_board_pin_mux(void)
 {
configure_module_pin_mux(mmc0_pin_mux);
configure_module_pin_mux(i2c0_pin_mux);
+   configure_module_pin_mux(qspi_pin_mux);
 }
 
 void enable_i2c0_pin_mux(void)
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 456dcaa..f28ad41 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -79,6 +79,26 @@
 #define CONFIG_OMAP_USB_PHY
 #define CONFIG_AM437X_USB2PHY2_HOST
 
+/* SPI */
+#undef CONFIG_OMAP3_SPI
+#define CONFIG_TI_QSPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_MACRONIX
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
+#define CONFIG_TI_SPI_MMAP
+#define CONFIG_QSPI_SEL_GPIO   48
+#define CONFIG_SF_DEFAULT_SPEED4800
+#define CONFIG_DEFAULT_SPI_MODESPI_MODE_3
+
+/* SPI SPL */
+#define CONFIG_SPL_SPI_SUPPORT
+#define CONFIG_SPL_SPI_LOAD
+#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#define CONFIG_SPL_SPI_BUS 0
+#define CONFIG_SPL_SPI_CS  0
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2
+
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
-- 
1.7.1

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

[U-Boot] [UBOOT][PATCH 4/5] qspi/spi: Add AM43xx specifics changes

Add AM43xx specific changes.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 drivers/spi/ti_qspi.c |   26 +++---
 1 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 5a5b482..5666250 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -11,6 +11,8 @@
 #include asm/arch/omap.h
 #include malloc.h
 #include spi.h
+#include asm/gpio.h
+#include asm/omap_gpio.h
 
 /* ti qpsi register bit masks */
 #define QSPI_TIMEOUT200
@@ -39,7 +41,8 @@
 #define MM_SWITCH   0x01
 #define MEM_CS  0x100
 #define MEM_CS_UNSELECT 0xf0ff
-#define MMAP_START_ADDR 0x5c00
+#define MMAP_START_ADDR_DRA0x5c00
+#define MMAP_START_ADDR_AM43x  0x3000
 #define CORE_CTRL_IO0x4a002558
 
 #define QSPI_CMD_READ   (0x3  0)
@@ -99,7 +102,11 @@ static void ti_spi_setup_spi_register(struct ti_qspi_slave 
*qslave)
struct spi_slave *slave = qslave-slave;
u32 memval = 0;
 
-   slave-memory_map = (void *)MMAP_START_ADDR;
+#ifdef CONFIG_DRA7XX
+   slave-memory_map = (void *)MMAP_START_ADDR_DRA;
+#else
+   slave-memory_map = (void *)MMAP_START_ADDR_AM43x;
+#endif
 
memval |= QSPI_CMD_READ | QSPI_SETUP0_NUM_A_BYTES |
QSPI_SETUP0_NUM_D_BYTES_NO_BITS |
@@ -165,6 +172,11 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 {
struct ti_qspi_slave *qslave;
 
+#ifdef CONFIG_AM43XX
+   gpio_request(CONFIG_QSPI_SEL_GPIO, qspi_gpio);
+   gpio_direction_output(CONFIG_QSPI_SEL_GPIO, 1);
+#endif
+
qslave = spi_alloc_slave(struct ti_qspi_slave, bus, cs);
if (!qslave) {
printf(SPI_error: Fail to allocate ti_qspi_slave\n);
@@ -229,7 +241,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
const uchar *txp = dout;
uchar *rxp = din;
uint status;
-   int timeout, val;
+   int timeout;
+
+#ifdef CONFIG_DRA7XX
+   int val;
+#endif
 
debug(spi_xfer: bus:%i cs:%i bitlen:%i words:%i flags:%lx\n,
  slave-bus, slave-cs, bitlen, words, flags);
@@ -237,15 +253,19 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
/* Setup mmap flags */
if (flags  SPI_XFER_MMAP) {
writel(MM_SWITCH, qslave-base-memswitch);
+#ifdef CONFIG_DRA7XX
val = readl(CORE_CTRL_IO);
val |= MEM_CS;
writel(val, CORE_CTRL_IO);
+#endif
return 0;
} else if (flags  SPI_XFER_MMAP_END) {
writel(~MM_SWITCH, qslave-base-memswitch);
+#ifdef CONFIG_DRA7XX
val = readl(CORE_CTRL_IO);
val = MEM_CS_UNSELECT;
writel(val, CORE_CTRL_IO);
+#endif
return 0;
}
 
-- 
1.7.1

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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com
 
 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24 
  2 files changed, 25 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
 struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }
  
 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171 
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is rev 
 b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of

This isn't right.  What I was saying is that board/ti/panda/panda.c
needs to provide its own emif_get_reg_dump function, which will (as
designed) override the current one from
arch/arm/cpu/armv7/omap4/sdram_elpida.c

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

iQIcBAEBAgAGBQJShPgfAAoJENk4IS6UOR1WROMP/3lqEirFqwVeXUaq2eyphdnD
AQzrzGE3ARc/gb7PqoAKGcvr7HZXQqa/ueRib/QyCRT53gc9S/nJu/wLN/i3NAVJ
4Y2LOgIkWlPi1k2l1mHvb6SZRVC4ZBFr3MwxoOQCRzMmBCAOwjSzimllT/nA9oSF
7r2/4tsYpidEoXxK8hn8lKpcfLeAda3MRdQwRjnWXfkJD+rBuAE/w0xCy8I5UmJr
+7J25HFacEbdceexAuzn4wFpSjex5o4yMyD6TFShzsG3GP8aktvWzXi94gx2FZhF
r6526qnjRXH7+RefIVlb95u2+/VpGz9Zu69xga2aszvU+kLHV0s2TTV6SVVmf2aG
Rj4JUxHc6wBYSB3tVNP1NJBiSS3WrmEIlmnQqZXmx51GfJKBHPGaljt5ldGMAUtT
/gtTRw0tw5q/Lv2dHy7BByqxTxk+8iko52X/9zl+vqzKuZS9oOS7/8Wu6q6pXeZc
jm8W/dCRCtO8h1j7BZVJTA+LE05MWKiA6P79lWAR08Eh7U2OwvkCq8WsRBtdxk5z
hqqy09OliHnMliNIRzW5LA8UiBmbw4mXIl27HrX8eNJ0PSXuRFCravm50OLph88L
BQDhKETjVy/dguq/L5lC+FgHwI0U6Hoip20Y8qy/m8YywdutKhw5Zk9jxMZFNCOb
KrOq3OJiJE8d4oSe8VnA
=NxpQ
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2013 11:28 AM, Michael Trimarchi wrote:
 Hi
 
 On Thu, Nov 14, 2013 at 5:19 PM, Tom Rini tr...@ti.com wrote:
 On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
 struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) 
 */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is 
 rev b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of
 
 This isn't right.  What I was saying is that board/ti/panda/panda.c
 needs to provide its own emif_get_reg_dump function, which will (as
 designed) override the current one from
 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 
 
 Any problem to have visibility of emif_regs array of lpddr?

Things that need exposing so that we can do what was intended before
should be exposed, in asm/arch-omap4/sys_proto.h I think.

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

iQIcBAEBAgAGBQJShPszAAoJENk4IS6UOR1W2TMP/RzK77vL75h5HYP23RKP/CWx
i7A/xbStKYT8ozh2s1IyHsKohVmnFmIh6lIa4cTYMzrqQBIJxnw9NB1p73qRFPFS
M8Bwx0QS3IU9Wqybk2w1x26Ymm65NWcAQ9SvPh4EBCpdnu1JnJoaceekw1fp55Pb
B+H/44Xr5D57F4R0DAuLqT2Kc6uoMf69X6I/DU7CuxhcceoMAMaFrZq+WrLAqIeY
M5qsCTsyOIQdzV4pheR9gH7F6dbzlA9uee2lshIP0yN5JJmWkZc1CjMR0SsStSpy
RKFJuNOgv32v7CGwvyA/HAk6KdKy5VSWUhHT/+1B3fMzIZhxypOlL90Vbz2Zlh5N
J5E5RNWsQaBJnVaEpo/4wWOTWmq/L5+lQLyJVPUkZFGocHgRBT8gqkcREe/+mSKx
DaxX4mLNlCvooMrNSakPPZHtPHXnVieMAvhdKDDdhLRKHAST+1hZD/ztBD63bwcJ
eSvGBe6SDv/K/mScU9eeNtJzVYs6O1VZm9sqgJBPhgUTN/Mfv7NbZVF3m4rMpkeB
PbQ/eSzxERBxeiInrPh2Ns62oDxCXTodOw5qy+jUQ72WPI/3zMNRHaBbyXTNn9nZ
NAj4XSex3tiQUpJYw21wbshEuCz4/Lo5LBWXeksdg0bfSxWX9jG/mpkOE6NACSyE
7TeL/tTeum0zVByyfhjG
=ZmUi
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Michael Trimarchi

Hi

On Thu, Nov 14, 2013 at 5:19 PM, Tom Rini tr...@ti.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c 
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
 struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is rev 
 b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of

 This isn't right.  What I was saying is that board/ti/panda/panda.c
 needs to provide its own emif_get_reg_dump function, which will (as
 designed) override the current one from
 arch/arm/cpu/armv7/omap4/sdram_elpida.c


Any problem to have visibility of emif_regs array of lpddr?

Michael


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

 iQIcBAEBAgAGBQJShPgfAAoJENk4IS6UOR1WROMP/3lqEirFqwVeXUaq2eyphdnD
 AQzrzGE3ARc/gb7PqoAKGcvr7HZXQqa/ueRib/QyCRT53gc9S/nJu/wLN/i3NAVJ
 4Y2LOgIkWlPi1k2l1mHvb6SZRVC4ZBFr3MwxoOQCRzMmBCAOwjSzimllT/nA9oSF
 7r2/4tsYpidEoXxK8hn8lKpcfLeAda3MRdQwRjnWXfkJD+rBuAE/w0xCy8I5UmJr
 +7J25HFacEbdceexAuzn4wFpSjex5o4yMyD6TFShzsG3GP8aktvWzXi94gx2FZhF
 r6526qnjRXH7+RefIVlb95u2+/VpGz9Zu69xga2aszvU+kLHV0s2TTV6SVVmf2aG
 Rj4JUxHc6wBYSB3tVNP1NJBiSS3WrmEIlmnQqZXmx51GfJKBHPGaljt5ldGMAUtT
 /gtTRw0tw5q/Lv2dHy7BByqxTxk+8iko52X/9zl+vqzKuZS9oOS7/8Wu6q6pXeZc
 jm8W/dCRCtO8h1j7BZVJTA+LE05MWKiA6P79lWAR08Eh7U2OwvkCq8WsRBtdxk5z
 hqqy09OliHnMliNIRzW5LA8UiBmbw4mXIl27HrX8eNJ0PSXuRFCravm50OLph88L
 BQDhKETjVy/dguq/L5lC+FgHwI0U6Hoip20Y8qy/m8YywdutKhw5Zk9jxMZFNCOb
 KrOq3OJiJE8d4oSe8VnA
 =NxpQ
 -END PGP SIGNATURE-
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder
Cruquiuskade 47 |
| +31(0)851119172   Amsterdam 1018 AM NL |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] arm: omap3: Add SPL support to tao3530

On Tue, Nov 12, 2013 at 01:15:00PM +0100, Stefan Roese wrote:

 Add SPL support for the Technexion TAO3530 SOM to replace
 x-loader. Tested with the Thunder baseboard. Currently this is
 only tested with the TAO3530 SOM revision (Ax/Bx).
 
 Tested by booting via MMC and NAND.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Tapani Utriainen tap...@technexion.com
 Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
 Cc: Tom Rini tr...@ti.com

Do we no longer have stack issues that this exposed?

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] env export fix: compute the CRC on the real lenght of the exported variables.

2013-11-14 Thread Wolfgang Denk

Dear Pierre Aubert,

In message 1384434720-11214-3-git-send-email-p.aub...@staubli.com you wrote:
 Signed-off-by: Pierre Aubert p.aub...@staubli.com
 ---
  common/cmd_nvedit.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
 index 5bcc324..c32a932 100644
 --- a/common/cmd_nvedit.c
 +++ b/common/cmd_nvedit.c
 @@ -922,14 +922,15 @@ NXTARG: ;
  
   len = hexport_r(env_htab, '\0',
   H_MATCH_KEY | H_MATCH_IDENT,
 - res, ENV_SIZE, argc, argv);
 + res, size, argc, argv);
 +
   if (len  0) {
   error(Cannot export environment: errno = %d\n, errno);
   return 1;
   }
  
   if (chk) {
 - envp-crc = crc32(0, envp-data, ENV_SIZE);
 + envp-crc = crc32(0, envp-data, len);

This is not correct.  When exporting with CRC, then the CRC
computation should be the same as is done with the persistently
stored environment, i. e. it should be taken over ENV_SIZE bytes.

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
Hindsight is an exact science.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] hashtable: fix the export lenght computation.

2013-11-14 Thread Wolfgang Denk

Dear Pierre Aubert,

In message 1384434720-11214-2-git-send-email-p.aub...@staubli.com you wrote:
 The room for the '=' and the sep char was reserved twice.

Are you sure?  Keep in mind that the termination of the list is a
_double_ NUL byte.  IIRC this is what we do here.

Best regards,

Wolfgang Denk

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

Re: [U-Boot] [PATCH 2/5] arm: omap3: Add SPL support to tao3530

2013-11-14 Thread Stefan Roese

Hi Tom,

On 14.11.2013 18:18, Tom Rini wrote:
 On Tue, Nov 12, 2013 at 01:15:00PM +0100, Stefan Roese wrote:
 
 Add SPL support for the Technexion TAO3530 SOM to replace
 x-loader. Tested with the Thunder baseboard. Currently this is
 only tested with the TAO3530 SOM revision (Ax/Bx).

 Tested by booting via MMC and NAND.

 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Tapani Utriainen tap...@technexion.com
 Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
 Cc: Tom Rini tr...@ti.com
 
 Do we no longer have stack issues that this exposed?

No. Work fine without any further patches applied. I have to admit, that
I have no idea why this problem with the re-assignment of r8 seems to be
solved. Some for CM_T35 btw.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 2/5] arm: omap3: Add SPL support to tao3530

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2013 12:47 PM, Stefan Roese wrote:
 Hi Tom,
 
 On 14.11.2013 18:18, Tom Rini wrote:
 On Tue, Nov 12, 2013 at 01:15:00PM +0100, Stefan Roese wrote:
 
 Add SPL support for the Technexion TAO3530 SOM to replace 
 x-loader. Tested with the Thunder baseboard. Currently this is 
 only tested with the TAO3530 SOM revision (Ax/Bx).
 
 Tested by booting via MMC and NAND.
 
 Signed-off-by: Stefan Roese s...@denx.de Cc: Tapani Utriainen
 tap...@technexion.com Cc: Thorsten Eisbein
 thorsten.eisb...@head-acoustics.de Cc: Tom Rini
 tr...@ti.com
 
 Do we no longer have stack issues that this exposed?
 
 No. Work fine without any further patches applied. I have to admit,
 that I have no idea why this problem with the re-assignment of r8
 seems to be solved. Some for CM_T35 btw.

OK, can you please repost any other older patches from then that need
to be applied still?  I think I see them all, but I suspect they need
Makefile changes anyhow.

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

iQIbBAEBAgAGBQJShROZAAoJENk4IS6UOR1Ww+QP9AtCXJcZSVT/7FUzb1RWt+9O
6HfMg7Nu+QPG7xsqh8+Isc7JX+yO0iOtkm273978p6XTUwxq8mGqsaaRioN1xJZ1
xewvTo0B0I2u4nR2DqH1ZQI5CaTrVKWc4Xf/WP7rGOEsGnJCDldkK4aTzCTGA+/y
LjZe23D6m0RxJKWuYY+0jC8h21PkpYFD9k+khanNMJ1DlXk4ALh+ExZAkj9iay0H
XWJ4RBEL8FOvaAkP8K+zj6en/+dpSHvqOLtvaRS09jQSIeKPQyy1mKOrFHUs4GDN
8IDIxfAq07g/jc52CVEEcFAnCwrmgCKjj9eeVLZRXCCGIo6C3cg0CanahFCiVOAI
eXnCi0IY1YQK7I2kNTBxU5crunywL0t59rGNgF5d5OC9qgqnndE4YFUGUYoyMS7a
FNxIMIKzv2GQM5vdoVRS5GcQI8KLfIlygPl4M1Xmx3gSKiUU3suxn5MU4MQ7iFZp
2H532WTtZD+rfWZX7Idyb+S/7zpODWsuQBQ4cY8wpmllHntedotohoFTfgQYYu6x
Ex1ca9fqusX1Lmmw7a+jEH5ekuGIiKqIeKmy45EKNEdwftf1jz/Mnf98olJ6tU27
VCRO1ICD5IWzEWCZPJ9TdW7DbCPPtmpnN8wr6UlDUl8LxRRfFLKlgH43zix2y6f5
kgp2Spqhm7ILK3MYVFI=
=/cZe
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] arm: omap3: Add SPL support to tao3530

2013-11-14 Thread Stefan Roese

On 14.11.2013 19:16, Tom Rini wrote:
 Add SPL support for the Technexion TAO3530 SOM to replace 
 x-loader. Tested with the Thunder baseboard. Currently this is 
 only tested with the TAO3530 SOM revision (Ax/Bx).

 Tested by booting via MMC and NAND.

 Signed-off-by: Stefan Roese s...@denx.de Cc: Tapani Utriainen
 tap...@technexion.com Cc: Thorsten Eisbein
 thorsten.eisb...@head-acoustics.de Cc: Tom Rini
 tr...@ti.com

 Do we no longer have stack issues that this exposed?

 No. Work fine without any further patches applied. I have to admit,
 that I have no idea why this problem with the re-assignment of r8
 seems to be solved. Some for CM_T35 btw.
 
 OK, can you please repost any other older patches from then that need
 to be applied still?  I think I see them all, but I suspect they need
 Makefile changes anyhow.

Yes, they definitely need some massaging. I'll repost the CM_T35 related
patches tomorrow as well.

Thanks,
Stefan

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

[U-Boot] [PATCH] i.MX6: nitrogen6x: update memory configuration files to use macros

This patch updates the memory configuration files for the Nitrogen6X
boards to use macros to define the output for imximage. This allows
re-use of the same files of register/value pairs to be included from C
as a pre-cursor to run-time detection of the memory size on a board.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg | 72 -
 board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg | 72 -
 board/boundary/nitrogen6x/800mhz_2x128mx16.cfg  | 72 -
 board/boundary/nitrogen6x/800mhz_2x256mx16.cfg  | 72 -
 board/boundary/nitrogen6x/800mhz_4x128mx16.cfg  | 72 -
 board/boundary/nitrogen6x/800mhz_4x256mx16.cfg  | 72 -
 board/boundary/nitrogen6x/nitrogen6dl.cfg   |  1 +
 board/boundary/nitrogen6x/nitrogen6dl2g.cfg |  1 +
 board/boundary/nitrogen6x/nitrogen6q.cfg|  1 +
 board/boundary/nitrogen6x/nitrogen6q2g.cfg  |  1 +
 board/boundary/nitrogen6x/nitrogen6s.cfg|  1 +
 board/boundary/nitrogen6x/nitrogen6s1g.cfg  |  1 +
 12 files changed, 222 insertions(+), 216 deletions(-)

diff --git a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg 
b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg
index 6c68146..c3d15a2 100644
--- a/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg
+++ b/board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg
@@ -4,39 +4,39 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036
-DATA 4, MX6_MMDC_P0_MDCFG0, 0x555A7974
-DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64
-DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB
-DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2
-DATA 4, MX6_MMDC_P0_MDOR, 0x005A1023
-DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040
-DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576
-DATA 4, MX6_MMDC_P0_MDASP, 0x0027
-DATA 4, MX6_MMDC_P0_MDCTL, 0x831A
-DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032
-DATA 4, MX6_MMDC_P0_MDSCR, 0x8033
-DATA 4, MX6_MMDC_P0_MDSCR, 0x00428031
-DATA 4, MX6_MMDC_P0_MDSCR, 0x19308030
-DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040
-DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003
-DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003
-DATA 4, MX6_MMDC_P0_MDREF, 0x5800
-DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007
-DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007
-DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x42720306
-DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x026F0266
-DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x4273030A
-DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x02740240
-DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E
-DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x403A3747
-DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x40434541
-DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B
-DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E
-DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B
-DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00190015
-DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00070018
-DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800
-DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800
-DATA 4, MX6_MMDC_P0_MDSCR, 0x
-DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006
+DCD_REG(MX6_MMDC_P0_MDPDC, 0x00020036)
+DCD_REG(MX6_MMDC_P0_MDCFG0, 0x555A7974)
+DCD_REG(MX6_MMDC_P0_MDCFG1, 0xDB538F64)
+DCD_REG(MX6_MMDC_P0_MDCFG2, 0x01FF00DB)
+DCD_REG(MX6_MMDC_P0_MDRWD, 0x26D2)
+DCD_REG(MX6_MMDC_P0_MDOR, 0x005A1023)
+DCD_REG(MX6_MMDC_P0_MDOTC, 0x09444040)
+DCD_REG(MX6_MMDC_P0_MDPDC, 0x00025576)
+DCD_REG(MX6_MMDC_P0_MDASP, 0x0027)
+DCD_REG(MX6_MMDC_P0_MDCTL, 0x831A)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x04088032)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x8033)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x00428031)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x19308030)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x04008040)
+DCD_REG(MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003)
+DCD_REG(MX6_MMDC_P1_MPZQHWCTRL, 0xA1390003)
+DCD_REG(MX6_MMDC_P0_MDREF, 0x5800)
+DCD_REG(MX6_MMDC_P0_MPODTCTRL, 0x0007)
+DCD_REG(MX6_MMDC_P1_MPODTCTRL, 0x0007)
+DCD_REG(MX6_MMDC_P0_MPDGCTRL0, 0x42720306)
+DCD_REG(MX6_MMDC_P0_MPDGCTRL1, 0x026F0266)
+DCD_REG(MX6_MMDC_P1_MPDGCTRL0, 0x4273030A)
+DCD_REG(MX6_MMDC_P1_MPDGCTRL1, 0x02740240)
+DCD_REG(MX6_MMDC_P0_MPRDDLCTL, 0x45393B3E)
+DCD_REG(MX6_MMDC_P1_MPRDDLCTL, 0x403A3747)
+DCD_REG(MX6_MMDC_P0_MPWRDLCTL, 0x40434541)
+DCD_REG(MX6_MMDC_P1_MPWRDLCTL, 0x473E4A3B)
+DCD_REG(MX6_MMDC_P0_MPWLDECTRL0, 0x0011000E)
+DCD_REG(MX6_MMDC_P0_MPWLDECTRL1, 0x000E001B)
+DCD_REG(MX6_MMDC_P1_MPWLDECTRL0, 0x00190015)
+DCD_REG(MX6_MMDC_P1_MPWLDECTRL1, 0x00070018)
+DCD_REG(MX6_MMDC_P0_MPMUR0, 0x0800)
+DCD_REG(MX6_MMDC_P1_MPMUR0, 0x0800)
+DCD_REG(MX6_MMDC_P0_MDSCR, 0x)
+DCD_REG(MX6_MMDC_P0_MAPSR, 0x00011006)
diff --git a/board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg 
b/board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
index bb5716e..af7ca1f 100644
--- a/board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
+++ b/board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
@@ -4,39 +4,39 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036
-DATA 4, MX6_MMDC_P0_MDCFG0, 0x898E7974
-DATA 4, MX6_MMDC_P0_MDCFG1, 0xDB538F64
-DATA 4, MX6_MMDC_P0_MDCFG2,

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Hardik Patel

On Thu, Nov 14, 2013 at 10:02 PM, Tom Rini tr...@ti.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11/14/2013 11:28 AM, Michael Trimarchi wrote:
 Hi

 On Thu, Nov 14, 2013 at 5:19 PM, Tom Rini tr...@ti.com wrote:
 On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24

  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr,
const struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda
board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio
171) */
 +writew((IEN | M3),
(*ctrl)-control_padconf_core_base + UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it
is rev b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of

 This isn't right.  What I was saying is that board/ti/panda/panda.c
 needs to provide its own emif_get_reg_dump function, which will (as
 designed) override the current one from
 arch/arm/cpu/armv7/omap4/sdram_elpida.c


 Any problem to have visibility of emif_regs array of lpddr?

 Things that need exposing so that we can do what was intended before
 should be exposed, in asm/arch-omap4/sys_proto.h I think.

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

 iQIcBAEBAgAGBQJShPszAAoJENk4IS6UOR1W2TMP/RzK77vL75h5HYP23RKP/CWx
 i7A/xbStKYT8ozh2s1IyHsKohVmnFmIh6lIa4cTYMzrqQBIJxnw9NB1p73qRFPFS
 M8Bwx0QS3IU9Wqybk2w1x26Ymm65NWcAQ9SvPh4EBCpdnu1JnJoaceekw1fp55Pb
 B+H/44Xr5D57F4R0DAuLqT2Kc6uoMf69X6I/DU7CuxhcceoMAMaFrZq+WrLAqIeY
 M5qsCTsyOIQdzV4pheR9gH7F6dbzlA9uee2lshIP0yN5JJmWkZc1CjMR0SsStSpy
 RKFJuNOgv32v7CGwvyA/HAk6KdKy5VSWUhHT/+1B3fMzIZhxypOlL90Vbz2Zlh5N
 J5E5RNWsQaBJnVaEpo/4wWOTWmq/L5+lQLyJVPUkZFGocHgRBT8gqkcREe/+mSKx
 DaxX4mLNlCvooMrNSakPPZHtPHXnVieMAvhdKDDdhLRKHAST+1hZD/ztBD63bwcJ
 eSvGBe6SDv/K/mScU9eeNtJzVYs6O1VZm9sqgJBPhgUTN/Mfv7NbZVF3m4rMpkeB
 PbQ/eSzxERBxeiInrPh2Ns62oDxCXTodOw5qy+jUQ72WPI/3zMNRHaBbyXTNn9nZ
 NAj4XSex3tiQUpJYw21wbshEuCz4/Lo5LBWXeksdg0bfSxWX9jG/mpkOE6NACSyE
 7TeL/tTeum0zVByyfhjG
 =ZmUi
 -END PGP SIGNATURE-

Hi Tom, Michel,

Thanks for your feedback on this.

We had implemented override of emif_get_reg_dump function in panda.c.
However, we thought checking detection of pandaboard in sdram_elpida.c be
smaller change and it was also under omap4. However, now I realized after
discussing that this may break in case of non panda.c OMAP4 boards.

Based on your feedback,we are going to correct it like below. I am trying
to explain it in brief:

1) We are going to extern emif_regs in asm/arch-omap4/sys_proto.h, so
that we can access them in panda.c
#ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
extern const struct emif_regs emif_regs_elpida_200_mhz_2cs;
extern const struct emif_regs emif_regs_elpida_380_mhz_1cs;
extern const struct emif_regs emif_regs_elpida_400_mhz_1cs;
extern const struct emif_regs emif_regs_elpida_400_mhz_2cs;
#endif

2) emif_regs_elpida_200_mhz_2cs  emif_regs_elpida_380_mhz_1cs are
defined as *static* const in sdram_elpida.c. So, we need to remove
static out of them as we are accessing it outside. This will be change in
sdram_elpida.c.

3) In Panda.c, we will write emif_get_reg_dump strong function as below
to override one of

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Michael Trimarchi

Hi

On Thu, Nov 14, 2013 at 7:43 PM, Hardik Patel
hardik.pa...@volansystech.com wrote:


 On Thu, Nov 14, 2013 at 10:02 PM, Tom Rini tr...@ti.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11/14/2013 11:28 AM, Michael Trimarchi wrote:
 Hi

 On Thu, Nov 14, 2013 at 5:19 PM, Tom Rini tr...@ti.com wrote:
 On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24
 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr,
 const struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda
 board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio
 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base
 + UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it
 is rev b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of

 This isn't right.  What I was saying is that board/ti/panda/panda.c
 needs to provide its own emif_get_reg_dump function, which will (as
 designed) override the current one from
 arch/arm/cpu/armv7/omap4/sdram_elpida.c


 Any problem to have visibility of emif_regs array of lpddr?

 Things that need exposing so that we can do what was intended before
 should be exposed, in asm/arch-omap4/sys_proto.h I think.

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

 iQIcBAEBAgAGBQJShPszAAoJENk4IS6UOR1W2TMP/RzK77vL75h5HYP23RKP/CWx
 i7A/xbStKYT8ozh2s1IyHsKohVmnFmIh6lIa4cTYMzrqQBIJxnw9NB1p73qRFPFS
 M8Bwx0QS3IU9Wqybk2w1x26Ymm65NWcAQ9SvPh4EBCpdnu1JnJoaceekw1fp55Pb
 B+H/44Xr5D57F4R0DAuLqT2Kc6uoMf69X6I/DU7CuxhcceoMAMaFrZq+WrLAqIeY
 M5qsCTsyOIQdzV4pheR9gH7F6dbzlA9uee2lshIP0yN5JJmWkZc1CjMR0SsStSpy
 RKFJuNOgv32v7CGwvyA/HAk6KdKy5VSWUhHT/+1B3fMzIZhxypOlL90Vbz2Zlh5N
 J5E5RNWsQaBJnVaEpo/4wWOTWmq/L5+lQLyJVPUkZFGocHgRBT8gqkcREe/+mSKx
 DaxX4mLNlCvooMrNSakPPZHtPHXnVieMAvhdKDDdhLRKHAST+1hZD/ztBD63bwcJ
 eSvGBe6SDv/K/mScU9eeNtJzVYs6O1VZm9sqgJBPhgUTN/Mfv7NbZVF3m4rMpkeB
 PbQ/eSzxERBxeiInrPh2Ns62oDxCXTodOw5qy+jUQ72WPI/3zMNRHaBbyXTNn9nZ
 NAj4XSex3tiQUpJYw21wbshEuCz4/Lo5LBWXeksdg0bfSxWX9jG/mpkOE6NACSyE
 7TeL/tTeum0zVByyfhjG
 =ZmUi
 -END PGP SIGNATURE-

 Hi Tom, Michel,

 Thanks for your feedback on this.

 We had implemented override of emif_get_reg_dump function in panda.c.
 However, we thought checking detection of pandaboard in sdram_elpida.c be
 smaller change and it was also under omap4. However, now I realized after
 discussing that this may break in case of non panda.c OMAP4 boards.

 Based on your feedback,we are going to correct it like below. I am trying to
 explain it in brief:

 1) We are going to extern emif_regs in asm/arch-omap4/sys_proto.h, so that
 we can access them in panda.c
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 extern const struct emif_regs emif_regs_elpida_200_mhz_2cs;
 extern const struct emif_regs emif_regs_elpida_380_mhz_1cs;
 extern const struct emif_regs emif_regs_elpida_400_mhz_1cs;
 extern const struct emif_regs emif_regs_elpida_400_mhz_2cs;
 #endif


I prefer having them in type name and have a function that give back
the pointer of the regs?

 2) emif_regs_elpida_200_mhz_2cs  emif_regs_elpida_380_mhz_1cs are
 defined as static const in sdram_elpida.c. So,

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2013 01:43 PM, Hardik Patel wrote:
 
 
 On Thu, Nov 14, 2013 at 10:02 PM, Tom Rini tr...@ti.com
 mailto:tr...@ti.com wrote:
 On 11/14/2013 11:28 AM, Michael Trimarchi wrote:
 Hi

 On Thu, Nov 14, 2013 at 5:19 PM, Tom Rini tr...@ti.com
 mailto:tr...@ti.com wrote:
 On 11/14/2013 05:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com
 mailto:hardik.pa...@volansystech.com

 Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
 mailto:hardik.pa...@volansystech.com
 ---
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
  board/ti/panda/panda.c  |   24
 
  2 files changed, 25 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 index e4c8316..9fbdeea 100644
 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
 @@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr,
 const struct emif_regs **regs)
   *regs = emif_regs_elpida_200_mhz_2cs;
   else if (omap4_rev == OMAP4430_ES2_3)
   *regs = emif_regs_elpida_400_mhz_1cs;
 - else if (omap4_rev  OMAP4470_ES1_0)
 + else if (omap4_rev  OMAP4470_ES1_0  !is_panda_es_rev_b3())
   *regs = emif_regs_elpida_400_mhz_2cs;
   else
   *regs = emif_regs_elpida_400_mhz_1cs;
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }

 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda
 board,
 +*  This can be done by reading the level of GPIO 171
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/
 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins
 (gpio 171) */
 +writew((IEN | M3),
 (*ctrl)-control_padconf_core_base + UNIPRO_TX0);
 +
 +/* if processor_rev is panda ES and GPIO171 is 1,
 it is rev b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of

 This isn't right.  What I was saying is that board/ti/panda/panda.c
 needs to provide its own emif_get_reg_dump function, which will (as
 designed) override the current one from
 arch/arm/cpu/armv7/omap4/sdram_elpida.c


 Any problem to have visibility of emif_regs array of lpddr?
 
 Things that need exposing so that we can do what was intended before
 should be exposed, in asm/arch-omap4/sys_proto.h I think.
 
 
 Hi Tom, Michel,
 
 Thanks for your feedback on this.
 
 We had implemented override of emif_get_reg_dump function in panda.c.
 However, we thought checking detection of pandaboard in sdram_elpida.c
 be smaller change and it was also under omap4. However, now I realized
 after discussing that this may break in case of non panda.c OMAP4 boards.
 
 Based on your feedback,we are going to correct it like below. I am
 trying to explain it in brief:
 
 1) We are going to extern emif_regs in asm/arch-omap4/sys_proto.h, so
 that we can access them in panda.c
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 extern const struct emif_regs emif_regs_elpida_200_mhz_2cs;
 extern const struct emif_regs emif_regs_elpida_380_mhz_1cs;
 extern const struct emif_regs emif_regs_elpida_400_mhz_1cs;
 extern const struct emif_regs emif_regs_elpida_400_mhz_2cs;
 #endif

Minor nit, don't protect externs with #ifdef, that's not required.
Otherwise, sounds like a good plan, thanks.

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

iQIcBAEBAgAGBQJShR43AAoJENk4IS6UOR1WZH4P+wTVrxdCNuvPVIhos2l7ilwR
yY/QJaPZ2KMlIAHkS56AGe1EYW+LvoVOgrocmYiTq4FgFbeDwEraJ9+Sqaeghg/+
pyTlvbLXjTUuipfe8G8sKFFeTMlRQSDA4xIsDNR05cU3NcC2IvUrYA8IaWG/b4cE
FndWWAPOqnJ3ZQmzDgOtuMwmBm0kkhKJ/5eobzhW/eReS/d6SD9A0GZQ9VOCmulf
/bRIyebcq0/HXpzL9TMaBp5z+48e3TE/ANIL9TnaTQUwcCErGsJ8JcJUQ50hrCVf
mqv/rrH38FSI2B9ZoejcnpadmArHL2wLY+PQlyerS3tmeZ2BUVYE3ex5/9aXg32b
HJxd+9YgHyAtYNym92X08uXmtLv7eKnN65TR89A8pWqwNuhfsBZIPjNh0zCDJaY6
nGupJIU/XKBACJsnSaiQ08FfXjasBTcZe5XZEOxMU6/FOiYs9uqJGy4XoeWFONrN
w4SNryORZmdggAuSD/OPKTeZWECXI2AES0O1gHHZj3dUx5S0009sZBQ2odJDkrD+
ZBMF60y8DNBAgImCyL4SOaOcX8iPwktTc/mj2eQyPSbS8oEjJEuCO5a76MaVrc1m
kkFiuxjmURn3J23z6wByyvaVKw2ElQL4vmFCvaDAP48SKGVdtEJlLDDpgA4xSOjs
TL1otD20nlVXUh/Coz/D
=IXue
-END PGP SIGNATURE-

Re: [U-Boot] u-boot gerrit server

On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
[snip]

 What I think it'd be possible to get working would be:
 
 Custodians would have Submit rights
 Custodians would have +2 review rights
 Normal people would have +1 review rights
 CI system could have the +1 for verified
 Single tree
 
 So essentially custodians could be assigned using some keyword, file
 matching and other clever heuristics, but it'd give freedom for them
 to 'drop' their review need or add someone else. Once they submit a
 change it goes straight to 'master' branch.
 
 This easy the merging of stuff but this ends with the sub-trees.

This sounds like a first good step to me.  It's important that things
get reviewed and everyone seems to be able to see the difference between
this is a small change to $subsystem driver for $soc, $soc custodian
can just push it and this is a big change, $subsystem custodian should
speak up too.  But I still want a final say on when things are able to
be merged into master

-- 
Tom


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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Nishanth Menon

On 11/14/2013 04:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com
Add some details about the change - commit message is usually
suggested as a good thing to have.

[...]
 diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
 index c104024..5a7f80a 100644
 --- a/board/ti/panda/panda.c
 +++ b/board/ti/panda/panda.c
 @@ -122,6 +122,30 @@ int get_board_revision(void)
   return board_id;
  }
  
 +/*
 +* Routine: is_panda_es_rev_b3
 +* Description: Detect if we are running on B3 version of ES panda board,
 +*  This can be done by reading the level of GPIO 171 
 +*  and checking the processor revisions.
 +*  GPIO171: 1 = Panda ES Rev B3
 +*/

will be good to see some kernel-doc style comments here..
/**
 * u8 is_panda_es_rev_b3 - Detect if we are running on B3 version of
ES panda
 *
 * This can be done by reading the level of GPIO 171 and checking the
 * processor revisions.  GPIO171: 1 = Panda ES Rev B3 (if using OMAP4460)
 */

u8 is_panda_es_rev_b3(void)


 +u8 is_panda_es_rev_b3(void)
 +{
 +int processor_rev = omap_revision();
 +int ret = 0;
 +
 +if ((processor_rev = OMAP4460_ES1_0 
 + processor_rev = OMAP4460_ES1_1)) {
 +
 +/* Setup the mux for the common board ID pins (gpio 171) */
 +writew((IEN | M3), (*ctrl)-control_padconf_core_base + 
 UNIPRO_TX0);
Could rather belong to mux code in board/ti/panda/panda_mux_data.h?

 +
 +/* if processor_rev is panda ES and GPIO171 is 1, it is rev 
 b3 */
 +ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
 +}
 +return ret;
 +}
Why cant we do something equivalent to beagle here? see
board/ti/beagle/beagle.c

 +
  /**
   * @brief misc_init_r - Configure Panda board specific configurations
   * such as power configurations, ethernet initialization as phase2 of
 


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

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

On Thu, Nov 14, 2013 at 01:41:48PM -0600, Nishanth Menon wrote:

 On 11/14/2013 04:06 AM, Hardik wrote:
  From: Hardik Patel hardik.pa...@volansystech.com
 Add some details about the change - commit message is usually
 suggested as a good thing to have.
 
 [...]
  diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
  index c104024..5a7f80a 100644
  --- a/board/ti/panda/panda.c
  +++ b/board/ti/panda/panda.c
  @@ -122,6 +122,30 @@ int get_board_revision(void)
  return board_id;
   }
   
  +/*
  +* Routine: is_panda_es_rev_b3
  +* Description: Detect if we are running on B3 version of ES panda board,
  +*  This can be done by reading the level of GPIO 171 

Using Nishanth's reply since I had this one handy.  There's trailing
whitespace here, which the gerrit test setup makes very visible, but
also shows that checkpatch.pl wasn't run before submission, so please
fix that in v3.  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 gerrit server

On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury () wrote:

 Hello Wolfgang,
[snip]
  Can you not pick up the patches directly from the mailing list?  I
  mean, we know of the problems patchwork has (like silently dropping
  certain base64 / utf8 encoded messages), so we should rather try and
  get a more reliable feed for the patches?
 
 
 this is the thing: picking up patches from patchwork is not something
 you'd do regularly - this is just my way of populating the review site
 from a single test account.
 
 If this workflow were adopted, each user would push their patch to the
 gerrit server, creating a new review branch for that particular patch.
 In general, gerrit view of the branch matches the submitter's view of
 the branch - if the submitter has several patches in one branch, they
 will all be uploaded by gerrit to the same separate branch,
 maintaining the relationship between the patches.

This is my biggest concern.  On the one-off to infrequent contribution
side (and we do have some of that), I worry about the infrastucture
hurdle here.

On the other side, what is the gerrit equivalent of 'git send-email
--compose ...', and I'm focusing on the compose side here.  Or is it
just another mental switch the project makes, from that to push to
gerrit / compose email saying hey, look at this

  Any one can upload patches to this server after creating an account on
  it. Any Google account will do, or if you don't want to have a Google
  based email you can create the account using your existing email.
  Follow the prompts after clicking on 'Sign in' link on the top right.
 
  Is my understanding correct that I have to use or create a google
  account in any case to participate in this type of work?  What if I am
  not willing to accept Google's Terms of Service, or to register an
  account with google for other reasons?
 
 
 This is correct, if you decide to use the google infrastructure based
 server. But you don't have to, gerrit is a stand alone application
 which can be easily installed on the same server or on a different
 server in the same location where the master u-boot git server is,
 with you (denx.de) having full control over it.
 
 Google hosting has advantages of providing extremely high bandwidth
 and reliability, but google's version of gerrit (distributed and
 replicated) is not a requirement, as i said, gerrit could be hosted on
 a linux machine.

Well, how much help and tweaking can we get, if we go with Google
hosting?  My views are perhaps biased based on using gerrit earlier in
Android's life, but, I can't imagine us having the time to deal with
admining and upgrading a server later on.  And of course, given ${insert
ones favorite now defunct google service} what might happen down the
line if the Google hosting goes away?

[snip]
  This server is not configured yet, but in general gerrit allows for
  three levels of reviewers - those who can just comment, those who can
  assign a +1 rating to the change (an equivalent of an acked by) and
  those who can assign a +2 rating or push the change (the custodians).
  There is no point in setting these up on a mirror, but if so desired,
  it could be done.
 
  How can we arrange to keep the mailing list in sync?
 
 
 This is a big question for which there is no good answer. Gerrit will
 send submitted patches in emails (limited to a configurable max patch
 size), but it will not accept email based reviews. So, this would
 involve a change in the way things done, I am just suggesting this as
 an alternative for consideration.

Can we at least get all reviews sent to the ML?

-- 
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 gerrit server

On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
 On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
 [snip]

 What I think it'd be possible to get working would be:

 Custodians would have Submit rights
 Custodians would have +2 review rights
 Normal people would have +1 review rights
 CI system could have the +1 for verified
 Single tree

 So essentially custodians could be assigned using some keyword, file
 matching and other clever heuristics, but it'd give freedom for them
 to 'drop' their review need or add someone else. Once they submit a
 change it goes straight to 'master' branch.

 This easy the merging of stuff but this ends with the sub-trees.

 This sounds like a first good step to me.  It's important that things
 get reviewed and everyone seems to be able to see the difference between
 this is a small change to $subsystem driver for $soc, $soc custodian
 can just push it and this is a big change, $subsystem custodian should
 speak up too.  But I still want a final say on when things are able to
 be merged into master

In this case, you could be the only one with 'submit' rights. So
everything would be just 'awaiting' for submit.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
  On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
  [snip]
 
  What I think it'd be possible to get working would be:
 
  Custodians would have Submit rights
  Custodians would have +2 review rights
  Normal people would have +1 review rights
  CI system could have the +1 for verified
  Single tree
 
  So essentially custodians could be assigned using some keyword, file
  matching and other clever heuristics, but it'd give freedom for them
  to 'drop' their review need or add someone else. Once they submit a
  change it goes straight to 'master' branch.
 
  This easy the merging of stuff but this ends with the sub-trees.
 
  This sounds like a first good step to me.  It's important that things
  get reviewed and everyone seems to be able to see the difference between
  this is a small change to $subsystem driver for $soc, $soc custodian
  can just push it and this is a big change, $subsystem custodian should
  speak up too.  But I still want a final say on when things are able to
  be merged into master
 
 In this case, you could be the only one with 'submit' rights. So
 everything would be just 'awaiting' for submit.

And custodian should still be able to easily pull together a list of
stuff they're happy with, change sets I guess?

-- 
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 gerrit server

On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
  On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
  [snip]
 
  What I think it'd be possible to get working would be:
 
  Custodians would have Submit rights
  Custodians would have +2 review rights
  Normal people would have +1 review rights
  CI system could have the +1 for verified
  Single tree
 
  So essentially custodians could be assigned using some keyword, file
  matching and other clever heuristics, but it'd give freedom for them
  to 'drop' their review need or add someone else. Once they submit a
  change it goes straight to 'master' branch.
 
  This easy the merging of stuff but this ends with the sub-trees.
 
  This sounds like a first good step to me.  It's important that things
  get reviewed and everyone seems to be able to see the difference between
  this is a small change to $subsystem driver for $soc, $soc custodian
  can just push it and this is a big change, $subsystem custodian should
  speak up too.  But I still want a final say on when things are able to
  be merged into master

 In this case, you could be the only one with 'submit' rights. So
 everything would be just 'awaiting' for submit.

 And custodian should still be able to easily pull together a list of
 stuff they're happy with, change sets I guess?

You can pull the 'patchsets' but the workflow I often see is that when
the changes are approved they go  to 'master' right away.

The main drawback I see is that the 'custodian' gets the power to
merge stuff direct in master. At same time, we get a more 'complete'
master and this avoids subsystems being tested late in the release
cycle.

I think it radically change the workflow but I've been using it for a
while in internal projects, customers and partners and it works quite
well.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3

2013-11-14 Thread Nishanth Menon

On 11/14/2013 01:41 PM, Nishanth Menon wrote:
 On 11/14/2013 04:06 AM, Hardik wrote:
 From: Hardik Patel hardik.pa...@volansystech.com
 Add some details about the change - commit message is usually
 suggested as a good thing to have.
 

Forgot to mention that you might want a better $subject here. the
current one sucks :(

I suggest some thing like:
ARM: OMAP4+: panda-es: Support Rev B3 Elpida DDR2

Commit message will state something on the lines of:
OMAP4460 PandaBoard-ES samples till Rev B3 used ABC DDR2, however,
starting Rev B3, boards are now manufactured with Elpida XYZ DDR2



This kind of helps folks not reading pandaboard mailing lists to
understand the context of the change.

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

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini tr...@ti.com wrote:
  On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
  On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
   On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
   [snip]
  
   What I think it'd be possible to get working would be:
  
   Custodians would have Submit rights
   Custodians would have +2 review rights
   Normal people would have +1 review rights
   CI system could have the +1 for verified
   Single tree
  
   So essentially custodians could be assigned using some keyword, file
   matching and other clever heuristics, but it'd give freedom for them
   to 'drop' their review need or add someone else. Once they submit a
   change it goes straight to 'master' branch.
  
   This easy the merging of stuff but this ends with the sub-trees.
  
   This sounds like a first good step to me.  It's important that things
   get reviewed and everyone seems to be able to see the difference between
   this is a small change to $subsystem driver for $soc, $soc custodian
   can just push it and this is a big change, $subsystem custodian should
   speak up too.  But I still want a final say on when things are able to
   be merged into master
 
  In this case, you could be the only one with 'submit' rights. So
  everything would be just 'awaiting' for submit.
 
  And custodian should still be able to easily pull together a list of
  stuff they're happy with, change sets I guess?
 
 You can pull the 'patchsets' but the workflow I often see is that when
 the changes are approved they go  to 'master' right away.
 
 The main drawback I see is that the 'custodian' gets the power to
 merge stuff direct in master. At same time, we get a more 'complete'
 master and this avoids subsystems being tested late in the release
 cycle.
 
 I think it radically change the workflow but I've been using it for a
 while in internal projects, customers and partners and it works quite
 well.

So long as we can plug a reasonable mount of CI in, this might not be
too bad, honestly.  The big problems I find with custodian PRs are oh,
when I threw this through the everything-matrix, $board broke that you
didn't try.

-- 
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 gerrit server

On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini tr...@ti.com wrote:
  On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
  On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
   On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
   [snip]
  
   What I think it'd be possible to get working would be:
  
   Custodians would have Submit rights
   Custodians would have +2 review rights
   Normal people would have +1 review rights
   CI system could have the +1 for verified
   Single tree
  
   So essentially custodians could be assigned using some keyword, file
   matching and other clever heuristics, but it'd give freedom for them
   to 'drop' their review need or add someone else. Once they submit a
   change it goes straight to 'master' branch.
  
   This easy the merging of stuff but this ends with the sub-trees.
  
   This sounds like a first good step to me.  It's important that things
   get reviewed and everyone seems to be able to see the difference between
   this is a small change to $subsystem driver for $soc, $soc custodian
   can just push it and this is a big change, $subsystem custodian should
   speak up too.  But I still want a final say on when things are able to
   be merged into master
 
  In this case, you could be the only one with 'submit' rights. So
  everything would be just 'awaiting' for submit.
 
  And custodian should still be able to easily pull together a list of
  stuff they're happy with, change sets I guess?

 You can pull the 'patchsets' but the workflow I often see is that when
 the changes are approved they go  to 'master' right away.

 The main drawback I see is that the 'custodian' gets the power to
 merge stuff direct in master. At same time, we get a more 'complete'
 master and this avoids subsystems being tested late in the release
 cycle.

 I think it radically change the workflow but I've been using it for a
 while in internal projects, customers and partners and it works quite
 well.

 So long as we can plug a reasonable mount of CI in, this might not be
 too bad, honestly.  The big problems I find with custodian PRs are oh,
 when I threw this through the everything-matrix, $board broke that you
 didn't try.

In fact I think every commit could be 'forced' to have the 'Verified'
vote set by the CI. So we couldn't push anything which fail.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury () wrote:
 On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini tr...@ti.com wrote:
  On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury () wrote:
 
  Hello Wolfgang,
  [snip]
   Can you not pick up the patches directly from the mailing list?  I
   mean, we know of the problems patchwork has (like silently dropping
   certain base64 / utf8 encoded messages), so we should rather try and
   get a more reliable feed for the patches?
  
 
  this is the thing: picking up patches from patchwork is not something
  you'd do regularly - this is just my way of populating the review site
  from a single test account.
 
  If this workflow were adopted, each user would push their patch to the
  gerrit server, creating a new review branch for that particular patch.
  In general, gerrit view of the branch matches the submitter's view of
  the branch - if the submitter has several patches in one branch, they
  will all be uploaded by gerrit to the same separate branch,
  maintaining the relationship between the patches.
 
  This is my biggest concern.  On the one-off to infrequent contribution
  side (and we do have some of that), I worry about the infrastucture
  hurdle here.
 
 
 Sorry, I am not sure i understand what the biggest concern is: that
 the users would push their own patches? Why is this a problem - the
 patches would go into their own branches until reviewed and merged. Or
 did you mean something else?

I mean, it's a higher hurdle to clear.  Looking at other non-Android
projects, I know some folks have said bah, not worth the effort to
push trivial things, if it must come via gerrit.  So some way to scrape
the ML for things that don't come in via gerrit to start with would be
handy.

  On the other side, what is the gerrit equivalent of 'git send-email
  --compose ...', and I'm focusing on the compose side here.  Or is it
  just another mental switch the project makes, from that to push to
  gerrit / compose email saying hey, look at this
 
 
 This is how we usually do this:
 
 - upload all patches to gerrit
 - go to the web interface of the first patch in the series (by this
 time gerrit would have a stack of patches showing their dependencies),
 click on review - at this point gerrit would open a form to type the
 cover message in
 - once you finish composing the message you click on publish
 comments and it gets sent to everybody who was picked as the
 reviewer, and to default addresses, if any are configured (which of
 course could be u-boot@lists.denx.de, for instance)

Right, and at that point we've mixed discussion of a concept with
discussion of a particular change, and we're in web-only for writes.  I
guess (pending see below) one could just write the 0/N email separate,
or in-reply-to 1/N, so that the concept discussion stays on the list and
in the archives and so on.

 Once thing I have to mention: gerrit is notorious for sending tons of
 email, while this is being worked on, in the meantime some more
 rigorous email filtering might be very useful.

Just how hard is it likely to be to filter things so that only:
1) new patches
2) reviews
get sent to the ML?

   Any one can upload patches to this server after creating an account on
   it. Any Google account will do, or if you don't want to have a Google
   based email you can create the account using your existing email.
   Follow the prompts after clicking on 'Sign in' link on the top right.
  
   Is my understanding correct that I have to use or create a google
   account in any case to participate in this type of work?  What if I am
   not willing to accept Google's Terms of Service, or to register an
   account with google for other reasons?
  
 
  This is correct, if you decide to use the google infrastructure based
  server. But you don't have to, gerrit is a stand alone application
  which can be easily installed on the same server or on a different
  server in the same location where the master u-boot git server is,
  with you (denx.de) having full control over it.
 
  Google hosting has advantages of providing extremely high bandwidth
  and reliability, but google's version of gerrit (distributed and
  replicated) is not a requirement, as i said, gerrit could be hosted on
  a linux machine.
 
  Well, how much help and tweaking can we get, if we go with Google
  hosting?  My views are perhaps biased based on using gerrit earlier in
  Android's life, but, I can't imagine us having the time to deal with
  admining and upgrading a server later on.
 
 Well, if you use google hosteg gerrit, you won't have a problem with
 upgrading or managing the server. Some one would need to get admin
 rights and set it up properly (create branches per custodian, set up
 user groups and group permissions, etc.). I am not going to be able to
 do this, but I sure could help pushing issues through the
 Gerrit-On-Google folks, they are pretty accommodating and responsive.

Right, I'm saying the

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 7:13 PM, Vadim Bendebury (вб)
vben...@google.com wrote:
 On Thu, Nov 14, 2013 at 12:17 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
  On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
  [snip]
 
  What I think it'd be possible to get working would be:
 
  Custodians would have Submit rights
  Custodians would have +2 review rights
  Normal people would have +1 review rights
  CI system could have the +1 for verified
  Single tree
 
  So essentially custodians could be assigned using some keyword, file
  matching and other clever heuristics, but it'd give freedom for them
  to 'drop' their review need or add someone else. Once they submit a
  change it goes straight to 'master' branch.
 
  This easy the merging of stuff but this ends with the sub-trees.
 
  This sounds like a first good step to me.  It's important that things
  get reviewed and everyone seems to be able to see the difference between
  this is a small change to $subsystem driver for $soc, $soc custodian
  can just push it and this is a big change, $subsystem custodian should
  speak up too.  But I still want a final say on when things are able to
  be merged into master

 In this case, you could be the only one with 'submit' rights. So
 everything would be just 'awaiting' for submit.

 And custodian should still be able to easily pull together a list of
 stuff they're happy with, change sets I guess?


 Presumably the custodians will have their own copy of their branch,
 they could upload patches to the master branch for merging into
 master.

I understand this is the closer we can get of our /current/ workflow
but I do believe it'd be sub-optimal.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX6: nitrogen6x: update memory configuration files to use macros

Dear Eric Nelson,

 This patch updates the memory configuration files for the Nitrogen6X
 boards to use macros to define the output for imximage. This allows
 re-use of the same files of register/value pairs to be included from C
 as a pre-cursor to run-time detection of the memory size on a board.
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
 ---
  board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg | 72
 - board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
 | 72 -
 board/boundary/nitrogen6x/800mhz_2x128mx16.cfg  | 72
 - board/boundary/nitrogen6x/800mhz_2x256mx16.cfg 
 | 72 -
 board/boundary/nitrogen6x/800mhz_4x128mx16.cfg  | 72
 - board/boundary/nitrogen6x/800mhz_4x256mx16.cfg 
 | 72 - board/boundary/nitrogen6x/nitrogen6dl.cfg  
 |  1 +
  board/boundary/nitrogen6x/nitrogen6dl2g.cfg |  1 +
  board/boundary/nitrogen6x/nitrogen6q.cfg|  1 +
  board/boundary/nitrogen6x/nitrogen6q2g.cfg  |  1 +
  board/boundary/nitrogen6x/nitrogen6s.cfg|  1 +
  board/boundary/nitrogen6x/nitrogen6s1g.cfg  |  1 +
  12 files changed, 222 insertions(+), 216 deletions(-)

I dont mind either way, but just an idea for discussion:

What do you say to implementing the DRAM controller programming in SPL? That 
way, we can even do proper DRAM calibration on boot and other such nice things. 
And we'd also get rid of these static magic numbers all around.

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

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 07:00:09PM -0200, Otavio Salvador wrote:
 On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini tr...@ti.com wrote:
  On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
  On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini tr...@ti.com wrote:
   On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
   On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
[snip]
   
What I think it'd be possible to get working would be:
   
Custodians would have Submit rights
Custodians would have +2 review rights
Normal people would have +1 review rights
CI system could have the +1 for verified
Single tree
   
So essentially custodians could be assigned using some keyword, file
matching and other clever heuristics, but it'd give freedom for them
to 'drop' their review need or add someone else. Once they submit a
change it goes straight to 'master' branch.
   
This easy the merging of stuff but this ends with the sub-trees.
   
This sounds like a first good step to me.  It's important that things
get reviewed and everyone seems to be able to see the difference 
between
this is a small change to $subsystem driver for $soc, $soc custodian
can just push it and this is a big change, $subsystem custodian 
should
speak up too.  But I still want a final say on when things are able 
to
be merged into master
  
   In this case, you could be the only one with 'submit' rights. So
   everything would be just 'awaiting' for submit.
  
   And custodian should still be able to easily pull together a list of
   stuff they're happy with, change sets I guess?
 
  You can pull the 'patchsets' but the workflow I often see is that when
  the changes are approved they go  to 'master' right away.
 
  The main drawback I see is that the 'custodian' gets the power to
  merge stuff direct in master. At same time, we get a more 'complete'
  master and this avoids subsystems being tested late in the release
  cycle.
 
  I think it radically change the workflow but I've been using it for a
  while in internal projects, customers and partners and it works quite
  well.
 
  So long as we can plug a reasonable mount of CI in, this might not be
  too bad, honestly.  The big problems I find with custodian PRs are oh,
  when I threw this through the everything-matrix, $board broke that you
  didn't try.
 
 In fact I think every commit could be 'forced' to have the 'Verified'
 vote set by the CI. So we couldn't push anything which fail.

True.  But can we also setup levels of CI?  Make everything pass the 1
ARM 1 PowerPC, 1 MIPS, x86, sandbox build-test, optionally make others
(the merge request equivalents) have to build all ARM, all PowerPC, all
MIPS, etc, etc.

-- 
Tom


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

Re: [U-Boot] [PATCH V2] imx: Define common routines to set cpu and board environment variables

Dear Eric Nelson,

+Albert, Tom

 These can be used in bootcmd to produce DTB file names.
 
 set_board_env() allows over-ride for use when a developing custom
 DTB files.
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
 ---
 V2 adds void to the function declarations and definitions and adds
 a blank to keep checkpatch clean.
 
 I'm feeling like I missed something here. Routines in imx-common/cpu.c
 are shared between various i.MX processors, but there doesn't appear
 to be a common header file.
 
 It seems that arch/arm/include/asm/imx-common.h should be present
 but isn't. Am I missing something?
 
 I also think there should be a way we could pull this into multiple
 boards without adding a full-up board_late_init() function into
 each board file, but tracing the init sequence, I'm not seeing an
 architecture-specific spot after env_init.
 
  arch/arm/imx-common/cpu.c | 15 +--
  arch/arm/include/asm/arch-mx6/sys_proto.h |  9 +
  2 files changed, 22 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
 index 0cd2538..4214946 100644
 --- a/arch/arm/imx-common/cpu.c
 +++ b/arch/arm/imx-common/cpu.c
 @@ -99,8 +99,6 @@ unsigned imx_ddr_size(void)
  }
  #endif
 
 -#if defined(CONFIG_DISPLAY_CPUINFO)
 -
  const char *get_imx_type(u32 imxtype)
  {
   switch (imxtype) {
 @@ -121,6 +119,19 @@ const char *get_imx_type(u32 imxtype)
   }
  }
 
 +void __weak set_cpu_env(void)
 +{
 + setenv(cpu, get_imx_type(cpu_type(get_cpu_rev(;
 +}

I'd say we should have a U-Boot wide thing here + CPU-specific overrides where 
applicable.

 +void __weak set_board_env(void)
 +{
 + char *old = getenv(board);
 + if (!old)
 + setenv(board, CONFIG_SYS_BOARD);
 +}

This might go into arch/FOO/lib/board.c ?
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 7:17 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury () wrote:
 On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini tr...@ti.com wrote:
  On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury () wrote:
 
  Hello Wolfgang,
  [snip]
   Can you not pick up the patches directly from the mailing list?  I
   mean, we know of the problems patchwork has (like silently dropping
   certain base64 / utf8 encoded messages), so we should rather try and
   get a more reliable feed for the patches?
  
 
  this is the thing: picking up patches from patchwork is not something
  you'd do regularly - this is just my way of populating the review site
  from a single test account.
 
  If this workflow were adopted, each user would push their patch to the
  gerrit server, creating a new review branch for that particular patch.
  In general, gerrit view of the branch matches the submitter's view of
  the branch - if the submitter has several patches in one branch, they
  will all be uploaded by gerrit to the same separate branch,
  maintaining the relationship between the patches.
 
  This is my biggest concern.  On the one-off to infrequent contribution
  side (and we do have some of that), I worry about the infrastucture
  hurdle here.
 

 Sorry, I am not sure i understand what the biggest concern is: that
 the users would push their own patches? Why is this a problem - the
 patches would go into their own branches until reviewed and merged. Or
 did you mean something else?

 I mean, it's a higher hurdle to clear.  Looking at other non-Android
 projects, I know some folks have said bah, not worth the effort to
 push trivial things, if it must come via gerrit.  So some way to scrape
 the ML for things that don't come in via gerrit to start with would be
 handy.

I think this is something one of 'known' developers will end doing and
applying it to Gerrit.

  On the other side, what is the gerrit equivalent of 'git send-email
  --compose ...', and I'm focusing on the compose side here.  Or is it
  just another mental switch the project makes, from that to push to
  gerrit / compose email saying hey, look at this
 

 This is how we usually do this:

 - upload all patches to gerrit
 - go to the web interface of the first patch in the series (by this
 time gerrit would have a stack of patches showing their dependencies),
 click on review - at this point gerrit would open a form to type the
 cover message in
 - once you finish composing the message you click on publish
 comments and it gets sent to everybody who was picked as the
 reviewer, and to default addresses, if any are configured (which of
 course could be u-boot@lists.denx.de, for instance)

 Right, and at that point we've mixed discussion of a concept with
 discussion of a particular change, and we're in web-only for writes.  I
 guess (pending see below) one could just write the 0/N email separate,
 or in-reply-to 1/N, so that the concept discussion stays on the list and
 in the archives and so on.

 Once thing I have to mention: gerrit is notorious for sending tons of
 email, while this is being worked on, in the meantime some more
 rigorous email filtering might be very useful.

 Just how hard is it likely to be to filter things so that only:
 1) new patches
 2) reviews
 get sent to the ML?

   Any one can upload patches to this server after creating an account on
   it. Any Google account will do, or if you don't want to have a Google
   based email you can create the account using your existing email.
   Follow the prompts after clicking on 'Sign in' link on the top right.
  
   Is my understanding correct that I have to use or create a google
   account in any case to participate in this type of work?  What if I am
   not willing to accept Google's Terms of Service, or to register an
   account with google for other reasons?
  
 
  This is correct, if you decide to use the google infrastructure based
  server. But you don't have to, gerrit is a stand alone application
  which can be easily installed on the same server or on a different
  server in the same location where the master u-boot git server is,
  with you (denx.de) having full control over it.
 
  Google hosting has advantages of providing extremely high bandwidth
  and reliability, but google's version of gerrit (distributed and
  replicated) is not a requirement, as i said, gerrit could be hosted on
  a linux machine.
 
  Well, how much help and tweaking can we get, if we go with Google
  hosting?  My views are perhaps biased based on using gerrit earlier in
  Android's life, but, I can't imagine us having the time to deal with
  admining and upgrading a server later on.

 Well, if you use google hosteg gerrit, you won't have a problem with
 upgrading or managing the server. Some one would need to get admin
 rights and set it up properly (create branches per custodian, set up
 user groups and group permissions, etc.). I am not going to

Re: [U-Boot] u-boot gerrit server

On Thu, Nov 14, 2013 at 01:13:37PM -0800, Vadim Bendebury () wrote:
 On Thu, Nov 14, 2013 at 12:17 PM, Tom Rini tr...@ti.com wrote:
  On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
  On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini tr...@ti.com wrote:
   On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
   [snip]
  
   What I think it'd be possible to get working would be:
  
   Custodians would have Submit rights
   Custodians would have +2 review rights
   Normal people would have +1 review rights
   CI system could have the +1 for verified
   Single tree
  
   So essentially custodians could be assigned using some keyword, file
   matching and other clever heuristics, but it'd give freedom for them
   to 'drop' their review need or add someone else. Once they submit a
   change it goes straight to 'master' branch.
  
   This easy the merging of stuff but this ends with the sub-trees.
  
   This sounds like a first good step to me.  It's important that things
   get reviewed and everyone seems to be able to see the difference between
   this is a small change to $subsystem driver for $soc, $soc custodian
   can just push it and this is a big change, $subsystem custodian should
   speak up too.  But I still want a final say on when things are able to
   be merged into master
 
  In this case, you could be the only one with 'submit' rights. So
  everything would be just 'awaiting' for submit.
 
  And custodian should still be able to easily pull together a list of
  stuff they're happy with, change sets I guess?
 
 Presumably the custodians will have their own copy of their branch,
 they could upload patches to the master branch for merging into
 master.

Sorry for not being clear.  I'm thinking of the single-tree approach
where custodians don't have separate trees per-se but provide changesets
they want merged or some other mechanism to include the N changes
they're happy with and have reviewed.

-- 
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, v1, 1/4] mtd: nand: add NAND_BUSWIDTH_AUTO to autodetect bus width

On Thu, 2013-11-14 at 04:32 +, Gupta, Pekon wrote:
  From: Scott Wood [mailto:scottw...@freescale.com]
  On Tue, Sep 10, 2013 at 06:57:05PM +0530, pekon gupta wrote:
   From: Matthieu CASTET matthieu.cas...@parrot.com

   This patch is slightly modified from following linux patch
   http://lists.infradead.org/pipermail/linux-mtd/2012-
  November/044803.html

  Which is now commit 64b37b2a63eb2f80b65c7185f0013f8ffc637ae3

   So retaining the authorship to Matthieu CASTET
  matthieu.cas...@parrot.com
   *Modifications from original patch*
   reset chip-read_byte, chip-read_buf, chip-write_buf before setting
  defaults.

  Why does U-Boot need this if Linux doesn't?

 Yes, I plan to drop this patch.
 Reason: Though this feature was introduced in linux long back, but hardly
 any mtd/nand drivers using this. Also there are alternative approaches
 which do not require any change in individual controller drivers, but just
 in generic NAND driver.
 I have proposed them in linux mtd-maillist, I'll propose same in my next
 version of patch-set.

 http://lists.infradead.org/pipermail/linux-mtd/2013-November/049744.html

Hmm, I don't like the kill NAND_BUSWIDTH_AUTO sentiment.  The device
tree is for describing things that can't be reasonably discovered
through hardware interfaces.  ONFI identification always being x8 seems
designed specifically to allow said discovery.

-Scott

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

Re: [U-Boot] [PATCH] i.MX6: nitrogen6x: update memory configuration files to use macros


Hi Marek,

On 11/14/2013 02:20 PM, Marek Vasut wrote:

Dear Eric Nelson,


This patch updates the memory configuration files for the Nitrogen6X
boards to use macros to define the output for imximage. This allows
re-use of the same files of register/value pairs to be included from C
as a pre-cursor to run-time detection of the memory size on a board.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
  board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg | 72
- board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
| 72 -
board/boundary/nitrogen6x/800mhz_2x128mx16.cfg  | 72
- board/boundary/nitrogen6x/800mhz_2x256mx16.cfg
| 72 -
board/boundary/nitrogen6x/800mhz_4x128mx16.cfg  | 72
- board/boundary/nitrogen6x/800mhz_4x256mx16.cfg
| 72 - board/boundary/nitrogen6x/nitrogen6dl.cfg
 |  1 +
  board/boundary/nitrogen6x/nitrogen6dl2g.cfg |  1 +
  board/boundary/nitrogen6x/nitrogen6q.cfg|  1 +
  board/boundary/nitrogen6x/nitrogen6q2g.cfg  |  1 +
  board/boundary/nitrogen6x/nitrogen6s.cfg|  1 +
  board/boundary/nitrogen6x/nitrogen6s1g.cfg  |  1 +
  12 files changed, 222 insertions(+), 216 deletions(-)


I dont mind either way, but just an idea for discussion:

What do you say to implementing the DRAM controller programming in SPL? That
way, we can even do proper DRAM calibration on boot and other such nice things.
And we'd also get rid of these static magic numbers all around.



We can (and hopefully will very soon) implement some of the
configuration in C under SPL, but we can't (and shouldn't) get
rid of all of the magic numbers.

Some of these numbers come from testing large numbers of devices
under a variety of temperature conditions. The best that the
automagic calibration facilities can do is set things up based
on nominal current conditions.

That said, I'm sure we can cut down on the total number.

My immediate goal is simply to set the stage for SPL and
a single binary.

Regards,


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

Re: [U-Boot] [PATCH V2] imx: Define common routines to set cpu and board environment variables


Thanks Marek,

On 11/14/2013 02:22 PM, Marek Vasut wrote:

Dear Eric Nelson,

+Albert, Tom


These can be used in bootcmd to produce DTB file names.

set_board_env() allows over-ride for use when a developing custom
DTB files.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
V2 adds void to the function declarations and definitions and adds
a blank to keep checkpatch clean.

I'm feeling like I missed something here. Routines in imx-common/cpu.c
are shared between various i.MX processors, but there doesn't appear
to be a common header file.

It seems that arch/arm/include/asm/imx-common.h should be present
but isn't. Am I missing something?

I also think there should be a way we could pull this into multiple
boards without adding a full-up board_late_init() function into
each board file, but tracing the init sequence, I'm not seeing an
architecture-specific spot after env_init.

  arch/arm/imx-common/cpu.c | 15 +--
  arch/arm/include/asm/arch-mx6/sys_proto.h |  9 +
  2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 0cd2538..4214946 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -99,8 +99,6 @@ unsigned imx_ddr_size(void)
  }
  #endif

-#if defined(CONFIG_DISPLAY_CPUINFO)
-
  const char *get_imx_type(u32 imxtype)
  {
switch (imxtype) {
@@ -121,6 +119,19 @@ const char *get_imx_type(u32 imxtype)
}
  }

+void __weak set_cpu_env(void)
+{
+   setenv(cpu, get_imx_type(cpu_type(get_cpu_rev(;
+}


I'd say we should have a U-Boot wide thing here + CPU-specific overrides where
applicable.



I'll follow your lead on this.

I'm just hoping to get a trivial amount of machinery so a boot
script can figure out which of a set of DTBs to load:

imx6q-nitrogen6x.dtb,
imx6dl-nitrogen6x.dtb, or
imx6s-nitrogen6x.dtb

Fabio's recent patch for SABRE SD showed the same need.

This could be even easier on i.MX6 if we had more formalized (and
lower-case) strings returned by get_imx_type(), but I wanted this
to be very small.

I'm not sure how consistent the DTB naming is for other machines
or if there's always the equivalent of get_imx_type().

Regards,


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

Re: [U-Boot] [PATCH 2/2] powerpc/t104xrdb: Add T1042RDB_PI board support

On Mon, 2013-10-07 at 15:18 +0530, Priyanka Jain wrote:
 +#ifdef CONFIG_CMD_KGDB
 +#define CONFIG_KGDB_BAUDRATE 230400  /* speed to run kgdb serial port */
 +#define CONFIG_KGDB_SER_INDEX2   /* which serial port to use */
 +#endif

Don't copy and paste random stuff without understanding it.

-Scott



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

Re: [U-Boot] [PATCH v5] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board

2013-11-14 Thread Stephen Warren

On 11/14/2013 02:58 AM, Alban Bedel wrote:
 Add support for the new Tamonten™ NG platform from Avionic Design.
 Currently only I2C, MMC, USB and ethernet have been tested.

Reviewed-by: Stephen Warren swar...@nvidia.com

It's odd to take patch v4 3/3, revise that, and just repost that one
patch, since now Tom has to take patch 1/3 and 2/3 from v4 and patch 3/3
from v5. Still, I guess he can work that out.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx: Define common routines to set cpu and board environment variables

Hi Eric,

 Thanks Marek,
 
 On 11/14/2013 02:22 PM, Marek Vasut wrote:
  Dear Eric Nelson,
  
  +Albert, Tom
  
  These can be used in bootcmd to produce DTB file names.
  
  set_board_env() allows over-ride for use when a developing custom
  DTB files.
  
  Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
  ---
  V2 adds void to the function declarations and definitions and adds
  a blank to keep checkpatch clean.
  
  I'm feeling like I missed something here. Routines in imx-common/cpu.c
  are shared between various i.MX processors, but there doesn't appear
  to be a common header file.
  
  It seems that arch/arm/include/asm/imx-common.h should be present
  but isn't. Am I missing something?
  
  I also think there should be a way we could pull this into multiple
  boards without adding a full-up board_late_init() function into
  each board file, but tracing the init sequence, I'm not seeing an
  architecture-specific spot after env_init.
  
arch/arm/imx-common/cpu.c | 15 +--
arch/arm/include/asm/arch-mx6/sys_proto.h |  9 +
2 files changed, 22 insertions(+), 2 deletions(-)
  
  diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
  index 0cd2538..4214946 100644
  --- a/arch/arm/imx-common/cpu.c
  +++ b/arch/arm/imx-common/cpu.c
  @@ -99,8 +99,6 @@ unsigned imx_ddr_size(void)
  
}
#endif
  
  -#if defined(CONFIG_DISPLAY_CPUINFO)
  -
  
const char *get_imx_type(u32 imxtype)
{

 switch (imxtype) {
  
  @@ -121,6 +119,19 @@ const char *get_imx_type(u32 imxtype)
  
 }

}
  
  +void __weak set_cpu_env(void)
  +{
  +  setenv(cpu, get_imx_type(cpu_type(get_cpu_rev(;
  +}
  
  I'd say we should have a U-Boot wide thing here + CPU-specific overrides
  where applicable.
 
 I'll follow your lead on this.

I'd wait for Tom's/Albert's opinion on this one too btw.

 I'm just hoping to get a trivial amount of machinery so a boot
 script can figure out which of a set of DTBs to load:
 
   imx6q-nitrogen6x.dtb,
   imx6dl-nitrogen6x.dtb, or
   imx6s-nitrogen6x.dtb
 
 Fabio's recent patch for SABRE SD showed the same need.

Full agreement here.

 This could be even easier on i.MX6 if we had more formalized (and
 lower-case) strings returned by get_imx_type(), but I wanted this
 to be very small.
 
 I'm not sure how consistent the DTB naming is for other machines
 or if there's always the equivalent of get_imx_type().

In the worst-case scenario, you might end up with some mapping function full of 
strcmp()s ;-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX6: nitrogen6x: update memory configuration files to use macros

Dear Eric Nelson,

 Hi Marek,
 
 On 11/14/2013 02:20 PM, Marek Vasut wrote:
  Dear Eric Nelson,
  
  This patch updates the memory configuration files for the Nitrogen6X
  boards to use macros to define the output for imximage. This allows
  re-use of the same files of register/value pairs to be included from C
  as a pre-cursor to run-time detection of the memory size on a board.
  
  Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
  ---
  
board/boundary/nitrogen6x/1066mhz_4x128mx16.cfg | 72
  
  -
  board/boundary/nitrogen6x/1066mhz_4x256mx16.cfg
  
  | 72 -
  
  board/boundary/nitrogen6x/800mhz_2x128mx16.cfg  | 72
  - board/boundary/nitrogen6x/800mhz_2x256mx16.cfg
  
  | 72 -
  
  board/boundary/nitrogen6x/800mhz_4x128mx16.cfg  | 72
  - board/boundary/nitrogen6x/800mhz_4x256mx16.cfg
  
  | 72 - board/boundary/nitrogen6x/nitrogen6dl.cfg
  | 
   |  1 +

board/boundary/nitrogen6x/nitrogen6dl2g.cfg |  1 +
board/boundary/nitrogen6x/nitrogen6q.cfg|  1 +
board/boundary/nitrogen6x/nitrogen6q2g.cfg  |  1 +
board/boundary/nitrogen6x/nitrogen6s.cfg|  1 +
board/boundary/nitrogen6x/nitrogen6s1g.cfg  |  1 +
12 files changed, 222 insertions(+), 216 deletions(-)
  
  I dont mind either way, but just an idea for discussion:
  
  What do you say to implementing the DRAM controller programming in SPL?
  That way, we can even do proper DRAM calibration on boot and other such
  nice things. And we'd also get rid of these static magic numbers all
  around.
 
 We can (and hopefully will very soon) implement some of the
 configuration in C under SPL, but we can't (and shouldn't) get
 rid of all of the magic numbers.

That would be really nice.

 Some of these numbers come from testing large numbers of devices
 under a variety of temperature conditions. The best that the
 automagic calibration facilities can do is set things up based
 on nominal current conditions.

This is what I'm concerned about. On the other hand, the DRAM controller in 
iMXes does run-time recalibration of the DDR, does it not ?

 That said, I'm sure we can cut down on the total number.

Absolutely. And if we cannot do runtime calibration, we could at least have 
support for multiple boards in a single image.
 
 My immediate goal is simply to set the stage for SPL and
 a single binary.

Full ACK on this course ;-)

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

Re: [U-Boot] fdt performance

On Thu, 2013-10-17 at 16:27 -0600, Simon Glass wrote:
Hi Aaron,

On Thu, Oct 17, 2013 at 12:24 AM, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
Hi all,

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

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

len is always positive.

Are you using CONFIG_OF_CONTROL?

If so, as a higher-level point, we could bring in an efficient DT
library, which converts the the FDT into a tree structure for faster
parsing. I can point you to a starting point if you like.

I've also seen it be a noticeable performance problem (in slow
simulation environments) on the extensive DT fixups we do on FSL PPC
(repeated calls to functions like fdt_node_offset_by_compat_reg are
particularly bad).

Though, when it comes to parsing the tree, rather than modifying it, I'm
not sure that the flattened data structure is all that much worse than
an unflattened tree. Lookups by path would be faster, but lookups by
compatible would still have to visit every node. I think the usage
patterns are at least part of the problem -- repeatedly scanning the
entire tree, rather than going over it once and assigning node offsets
to drivers. The driver model ought to help here.

FWIW, if there is interest in unflattening the device tree, Freescale's
hypervisor has code for this:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/hypervisor/hypervisor.git/tree/src/livetree.c
http://git.freescale.com/git/cgit.cgi/ppc/sdk/hypervisor/hypervisor.git/tree/include/devtree.h

I'm not sure how it compares to the code Simon had in mind, but it
supports merging nodes which could be useful for boards that do dynamic
device tree updates.

-Scott

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

Re: [U-Boot] fdt performance

2013-11-14 Thread Simon Glass

Hi Scott,

On Thu, Nov 14, 2013 at 4:36 PM, Scott Wood scottw...@freescale.com wrote:

On Thu, 2013-10-17 at 16:27 -0600, Simon Glass wrote:
Hi Aaron,

On Thu, Oct 17, 2013 at 12:24 AM, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
Hi all,

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

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

len is always positive.

Are you using CONFIG_OF_CONTROL?

If so, as a higher-level point, we could bring in an efficient DT
library, which converts the the FDT into a tree structure for faster
parsing. I can point you to a starting point if you like.

My thought was that compatible strings would be collated somewhere so there
is an efficient way to find them. However, that might violate the
simplicity rule.

patterns are at least part of the problem -- repeatedly scanning the
entire tree, rather than going over it once and assigning node offsets
to drivers. The driver model ought to help here.

FWIW, if there is interest in unflattening the device tree, Freescale's
hypervisor has code for this:

http://git.freescale.com/git/cgit.cgi/ppc/sdk/hypervisor/hypervisor.git/tree/src/livetree.c

http://git.freescale.com/git/cgit.cgi/ppc/sdk/hypervisor/hypervisor.git/tree/include/devtree.h

I'm not sure how it compares to the code Simon had in mind, but it
supports merging nodes which could be useful for boards that do dynamic
device tree updates.

Well that code looks great. I'm not sure if we have the demand as yet (as
you say driver model should largely allow the tree to be scanned
sequentially and only once) but I am sure it will come up one day.

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

Re: [U-Boot] [U-Boot,PATCHv4] Optimized nand_read_buf for kirkwood

On Thu, 2013-11-14 at 09:18 +0100, Holger Brunck wrote:
 Hi Scott,
 
 On 11/14/2013 02:31 AM, Scott Wood wrote:
  On Mon, Aug 26, 2013 at 02:10:56PM +0200, Phil Sutter wrote:
  From: Nico Erfurth n...@erfurth.eu
 
  The basic idea is taken from the linux-kernel, but further optimized.
 
  First align the buffer to 8 bytes, then use ldrd/strd to read and store
  in 8 byte quantities, then do the final bytes.
 
  Tested using: 'date ; nand read.raw 0xE0 0x0 0x1 ; date'.
  Without this patch, NAND read of 132MB took 49s (~2.69MB/s). With this
  patch in place, reading the same amount of data was done in 27s
  (~4.89MB/s). So read performance is increased by ~80%!
 
  Signed-off-by: Nico Erfurth n...@erfurth.eu
  Tested-by: Phil Sutter phil.sut...@viprinet.com
  Cc: Prafulla Wadaskar prafu...@marvell.com
 
  ---
  Changed since V3:
  - fixed author
  ---
   drivers/mtd/nand/kirkwood_nand.c | 32 
   1 file changed, 32 insertions(+)
  
  I tried to build-test this, and I couldn't find any board that defines
  CONFIG_NAND_KIRKWOOD.
  
 
 it's not in board specific code defined it's defined in a common kirkwood 
 header:
 
 arch/arm/include/asm/arch-kirkwood/config.h:58:#define CONFIG_NAND_KIRKWOOD

Oops.  I thought I grepped the whole tree rather than just include/, but
apparently not.

-Scott



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

Re: [U-Boot] [PATCH V2] imx: Define common routines to set cpu and board environment variables



On 11/14/2013 04:30 PM, Marek Vasut wrote:

Hi Eric,

Thanks Marek,
On 11/14/2013 02:22 PM, Marek Vasut wrote:

Dear Eric Nelson,



 snip



I'm just hoping to get a trivial amount of machinery so a boot
script can figure out which of a set of DTBs to load:

imx6q-nitrogen6x.dtb,
imx6dl-nitrogen6x.dtb, or
imx6s-nitrogen6x.dtb

Fabio's recent patch for SABRE SD showed the same need.


Full agreement here.


This could be even easier on i.MX6 if we had more formalized (and
lower-case) strings returned by get_imx_type(), but I wanted this
to be very small.

I'm not sure how consistent the DTB naming is for other machines
or if there's always the equivalent of get_imx_type().


In the worst-case scenario, you might end up with some mapping function full of
strcmp()s ;-)



This is much easier for us to do, since we defer much of the
scripting into a boot script.

It will be harder for Fabio to shoe-horn in until we get environment
settings in an external file...


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

Re: [U-Boot] [U-Boot, 1/3, v5] mtd: move update nand_ecclayout structure

On Fri, Oct 04, 2013 at 01:47:58PM +0530, Prabhakar Kushwaha wrote:
 nand_ecclayout is present in mtd.h at Linux.
 Move this structure to mtd.h to comply with Linux.
 
 Also, increase the ecc placement locations to 640 to suport device having
 writesize/oobsize of 8KB/640B. This means that the maximum oobsize has gone
 up to 640 bytes and consequently the maximum ecc placement locations have
 also gone up to 640.
 
 Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
 CC: Vipin Kumar vipin.ku...@st.com
 
 ---
 Changes for v2: Incorporated Scott's comments
   - move nand_ecclayout to mtd.h
   - updated OOBFREE, ECCPOS max entries
 
  Changes for v3: Sending as it is
  Changes for v4: Sending as it is
  Changes for v5: Sending as it is
  
  include/linux/mtd/mtd.h |   14 ++
  include/mtd/mtd-abi.h   |   12 
  2 files changed, 14 insertions(+), 12 deletions(-)

This breaks the tricorder build due to the expanded eccpos violating SPL
size constraints:

Configuring for tricorder board...
make[1]: *** [/tmp/u-boot-arm/spl/u-boot-spl] Error 1
make: *** [/tmp/u-boot-arm/spl/u-boot-spl.bin] Error 2
   textdata bss dec hex filename
 352879   27592  217888  598359   92157 /tmp/u-boot-arm/u-boot
armv7a-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram'
armv7a-ld.bfd: region `.sram' overflowed by 140 bytes
make[1]: *** [/tmp/u-boot-arm/spl/u-boot-spl] Error 1
make: *** [/tmp/u-boot-arm/spl/u-boot-spl.bin] Error 2
make: *** Waiting for unfinished jobs

-Scott

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

Re: [U-Boot] [PATCH 07/10 V6] DTS: Add dts support for SMDK5420

2013-11-14 Thread Rajeshwari Birje

Hi Minkyu Kang,

On Thu, Nov 14, 2013 at 7:31 AM, Minkyu Kang proms...@gmail.com wrote:
 Dear Rajeshwari,


 On 13 November 2013 13:26, Rajeshwari Birje rajeshwari.bi...@gmail.com
 wrote:

 Hi Minkyu Kang,

 Thank you for comments.

 On Wed, Nov 13, 2013 at 8:47 AM, Minkyu Kang proms...@gmail.com wrote:
  Dear Rajeshwari S Shinde,
 
 
  On 29 October 2013 16:23, Rajeshwari S Shinde
  rajeshwar...@samsung.comwrote:
 
  This patch adds support for SMDK5420.
  exynos5.dtsi created is a common file which has the nodes common
  to both 5420 and 5250.
 
  Signed-off-by: Akshay Saraswat aksha...@samsung.com
  Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
  Acked-by: Simon Glass s...@chromium.org
  ---
  Changes in V2:
  - None
  Changes in V3:
  - None
  Changes in V4:
  - Added /include/ exynos5420.dtsi
  Changes in V5:
  - None
  Changes in V6:
  - None
   arch/arm/dts/exynos5.dtsi | 211
  ++
   arch/arm/dts/exynos5250.dtsi  | 178
  +
   arch/arm/dts/exynos5420.dtsi  |  74 +++
   board/samsung/dts/exynos5420-smdk5420.dts | 172
  
   4 files changed, 458 insertions(+), 177 deletions(-)
   create mode 100644 arch/arm/dts/exynos5.dtsi
   create mode 100644 arch/arm/dts/exynos5420.dtsi
   create mode 100644 board/samsung/dts/exynos5420-smdk5420.dts
 
  diff --git a/board/samsung/dts/exynos5420-smdk5420.dts
  b/board/samsung/dts/exynos5420-smdk5420.dts
  new file mode 100644
  index 000..5ef0c92
  --- /dev/null
  +++ b/board/samsung/dts/exynos5420-smdk5420.dts
  @@ -0,0 +1,172 @@
  +/*
  + * SAMSUNG SMDK5420 board device tree source
  + *
  + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
  + * Use of this source code is governed by a BSD-style license that can
  be
  + * found in the LICENSE file.
 
 
  is it right?
 Iam sorry did not get your question, about what are you pointing to?.


 The Copyright and License.
Have corrected this in V7.



 
 
  + */
  +
  +/dts-v1/;
  +/include/ exynos5420.dtsi
  +
  +/ {
  +   model = SAMSUNG SMDK5420 board based on EXYNOS5420;
  +   compatible = samsung,smdk5420, samsung,exynos5;
  +
  +   config {
  +   hwid = smdk5420 TEST A-A 9382;
  +   };
  +
  +   aliases {
  +   i2c0 = /i2c@12c6;
  +   i2c1 = /i2c@12c7;
  +   i2c2 = /i2c@12c8;
  +   i2c3 = /i2c@12c9;
  +   i2c4 = /i2c@12ca;
  +   i2c5 = /i2c@12cb;
  +   i2c6 = /i2c@12cc;
  +   i2c7 = /i2c@12cd;
  +   i2c8 = /i2c@12e0;
  +   i2c9 = /i2c@12e1;
  +   i2c10 = /i2c@12e2;
  +   spi0 = /spi@12d2;
  +   spi1 = /spi@12d3;
  +   spi2 = /spi@12d4;
  +   spi3 = /spi@131a;
  +   spi4 = /spi@131b;
  +   mmc0 = /mmc@1220;
  +   mmc1 = /mmc@1221;
  +   mmc2 = /mmc@1222;
  +   xhci0 = /xhci@1200;
  +   xhci1 = /xhci@1240;
  +   serial0 = /serial@12C3;
  +   console = /serial@12C3;
  +   };
  +
  +   tmu@1006 {
  +   samsung,min-temp= 25;
  +   samsung,max-temp= 125;
  +   samsung,start-warning   = 95;
  +   samsung,start-tripping  = 105;
  +   samsung,hw-tripping = 110;
  +   samsung,efuse-min-value = 40;
  +   samsung,efuse-value = 55;
  +   samsung,efuse-max-value = 100;
  +   samsung,slope   = 274761730;
  +   samsung,dc-value= 25;
  +   };
  +
  +   /* s2mps11 is on i2c bus 4 */
  +   i2c@12ca {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   pmic@66 {
  +   reg = 0x66;
  +   compatible = samsung,s2mps11-pmic;
  +   };
  +   };
  +
  +   spi@12d2 { /* spi0 */
  +   spi-max-frequency = 5000;
  +   firmware_storage_spi: flash@0 {
  +   reg = 0;
  +   };
  +   };
  +
  +   fimd@1440 {
  +   samsung,vl-freq = 60;
  +   samsung,vl-col = 2560;
  +   samsung,vl-row = 1600;
  +   samsung,vl-width = 2560;
  +   samsung,vl-height = 1600;
  +
  +   samsung,vl-clkp;
  +   samsung,vl-dp;
  +   samsung,vl-bpix = 4;
  +
  +   samsung,vl-hspw = 32;
  +   samsung,vl-hbpd = 80;
  +   samsung,vl-hfpd = 48;
  +   samsung,vl-vspw = 6;
  +   samsung,vl-vbpd = 37;
  +   samsung,vl-vfpd = 3;
  +   samsung,vl-cmd-allow-len =

[U-Boot] [PATCH v4 0/7] arm: atmel: sama5d3: enable spl boot from SD card

This patch series enable spl boot from SD card, it only can boot
u-boot itself.

Changes in v4:
  - Using blank replace table after defined
  - Align the register define with datasheet
  - constify the ram_address and ddr configuration value
  - Add comments to DDR refresh timing register.

Changes in v3:
  - Correct the clock enable code, the ID can not OR
  - Move to at91 common folder
  - Move plla and mck configure to spl.c file

Changes in v2:
  - Move spl related code to at91-common folder

Bo Shen (7):
  arm: atmel: sama5d3: correct the ID for DBGU and PIT
  arm: at91: pm9261: remove undefined bit in mckr
  arm: atmel: sama5d3: correct the error define of DIV
  arm: atmel: sama5d3: the offset of MULA is 18
  arm: atmel: sama5d3: early enable PIO peripherals
  arm: atmel: add ddr2 initialization function
  arm: atmel: sama5d3: spl boot from fat fs SD card

 arch/arm/cpu/Makefile |1 +
 arch/arm/cpu/armv7/Makefile   |2 +-
 arch/arm/cpu/armv7/at91/sama5d3_devices.c |2 +-
 arch/arm/cpu/armv7/at91/timer.c   |2 +-
 arch/arm/cpu/at91-common/Makefile |   11 +++
 arch/arm/cpu/at91-common/mpddrc.c |  124 +
 arch/arm/cpu/at91-common/spl.c|   90 ++
 arch/arm/cpu/at91-common/u-boot-spl.lds   |   50 ++
 arch/arm/include/asm/arch-at91/at91_common.h  |4 +
 arch/arm/include/asm/arch-at91/at91_pmc.h |8 +-
 arch/arm/include/asm/arch-at91/atmel_mpddrc.h |  115 +++
 arch/arm/include/asm/arch-at91/spl.h  |   20 
 board/atmel/sama5d3xek/sama5d3xek.c   |   91 ++
 include/configs/pm9261.h  |6 +-
 include/configs/sama5d3xek.h  |   34 +++
 15 files changed, 551 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/cpu/at91-common/Makefile
 create mode 100644 arch/arm/cpu/at91-common/mpddrc.c
 create mode 100644 arch/arm/cpu/at91-common/spl.c
 create mode 100644 arch/arm/cpu/at91-common/u-boot-spl.lds
 create mode 100644 arch/arm/include/asm/arch-at91/atmel_mpddrc.h
 create mode 100644 arch/arm/include/asm/arch-at91/spl.h

-- 
1.7.9.5

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

[U-Boot] [PATCH v4 2/7] arm: at91: pm9261: remove undefined bit in mckr

The PLLADIV2 bit is not defined in at91sam9261 SoC, so remove it.

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - New
Changes in v3:
  - None
Changes in v2:
  - None

 include/configs/pm9261.h |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h
index fc95cf0..acf6d61 100644
--- a/include/configs/pm9261.h
+++ b/include/configs/pm9261.h
@@ -50,15 +50,13 @@
 #defineCONFIG_SYS_MCKR1_VAL\
(AT91_PMC_MCKR_CSS_SLOW |   \
 AT91_PMC_MCKR_PRES_1 | \
-AT91_PMC_MCKR_MDIV_2 | \
-AT91_PMC_MCKR_PLLADIV_1)
+AT91_PMC_MCKR_MDIV_2)
 
 /* PCK/2 = MCK Master Clock from PLLA */
 #defineCONFIG_SYS_MCKR2_VAL\
(AT91_PMC_MCKR_CSS_PLLA |   \
 AT91_PMC_MCKR_PRES_1 | \
-AT91_PMC_MCKR_MDIV_2 | \
-AT91_PMC_MCKR_PLLADIV_1)
+AT91_PMC_MCKR_MDIV_2)
 
 /* define PDC[31:16] as DATA[31:16] */
 #define CONFIG_SYS_PIOC_PDR_VAL1   0x
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 3/7] arm: atmel: sama5d3: correct the error define of DIV

Correct the error define of DIV.

Signed-off-by: Bo Shen voice.s...@atmel.com
---
Changes in v4:
  - None
Changes in v3:
  - None
Changes in v2:
  - None

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

diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h 
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index 7b36f74..3efdc37 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -124,8 +124,8 @@ typedef struct at91_pmc {
 #define AT91_PMC_MCKR_MDIV_MASK0x0300
 #endif
 
-#define AT91_PMC_MCKR_PLLADIV_10x1000
-#define AT91_PMC_MCKR_PLLADIV_20x2000
+#define AT91_PMC_MCKR_PLLADIV_10x
+#define AT91_PMC_MCKR_PLLADIV_20x1000
 
 #define AT91_PMC_IXR_MOSCS 0x0001
 #define AT91_PMC_IXR_LOCKA 0x0002
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 1/7] arm: atmel: sama5d3: correct the ID for DBGU and PIT

As the DBGU and PIT has its own ID on sama5d3 SoC, while not share
with SYS ID. So, correct them.

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - None
Changes in v3:
  - None
Changes in v2:
  - None

 arch/arm/cpu/armv7/at91/sama5d3_devices.c |2 +-
 arch/arm/cpu/armv7/at91/timer.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/at91/sama5d3_devices.c 
b/arch/arm/cpu/armv7/at91/sama5d3_devices.c
index 51f0a6d..ebe99d2 100644
--- a/arch/arm/cpu/armv7/at91/sama5d3_devices.c
+++ b/arch/arm/cpu/armv7/at91/sama5d3_devices.c
@@ -82,7 +82,7 @@ void at91_seriald_hw_init(void)
at91_set_a_periph(AT91_PIO_PORTB, 30, 0);   /* DRXD */
 
/* Enable clock */
-   at91_periph_clk_enable(ATMEL_ID_SYS);
+   at91_periph_clk_enable(ATMEL_ID_DBGU);
 }
 
 #if defined(CONFIG_ATMEL_SPI)
diff --git a/arch/arm/cpu/armv7/at91/timer.c b/arch/arm/cpu/armv7/at91/timer.c
index 3808aed..e3ebfe0 100644
--- a/arch/arm/cpu/armv7/at91/timer.c
+++ b/arch/arm/cpu/armv7/at91/timer.c
@@ -60,7 +60,7 @@ int timer_init(void)
at91_pit_t *pit = (at91_pit_t *)ATMEL_BASE_PIT;
 
/* Enable PITC Clock */
-   at91_periph_clk_enable(ATMEL_ID_SYS);
+   at91_periph_clk_enable(ATMEL_ID_PIT);
 
/* Enable PITC */
writel(TIMER_LOAD_VAL | AT91_PIT_MR_EN , pit-mr);
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 6/7] arm: atmel: add ddr2 initialization function

The MPDDRC supports different type of SDRAM
This patch add ddr2 initialization function

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - Using blank replace table after defined
  - Align the register define with datasheet
  - constify the ram_address and ddr configuration value

Changes in v3:
  - Move to at91 common folder

Changes in v2:
  - None

 arch/arm/cpu/Makefile |1 +
 arch/arm/cpu/at91-common/Makefile |   11 +++
 arch/arm/cpu/at91-common/mpddrc.c |  124 +
 arch/arm/include/asm/arch-at91/atmel_mpddrc.h |  115 +++
 4 files changed, 251 insertions(+)
 create mode 100644 arch/arm/cpu/at91-common/Makefile
 create mode 100644 arch/arm/cpu/at91-common/mpddrc.c
 create mode 100644 arch/arm/include/asm/arch-at91/atmel_mpddrc.h

diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
index fd0da53..b2d30b1 100644
--- a/arch/arm/cpu/Makefile
+++ b/arch/arm/cpu/Makefile
@@ -1,2 +1,3 @@
+obj-$(CONFIG_AT91FAMILY) += at91-common/
 obj-$(CONFIG_TEGRA) += $(SOC)-common/
 obj-$(CONFIG_TEGRA) += tegra-common/
diff --git a/arch/arm/cpu/at91-common/Makefile 
b/arch/arm/cpu/at91-common/Makefile
new file mode 100644
index 000..671a05e
--- /dev/null
+++ b/arch/arm/cpu/at91-common/Makefile
@@ -0,0 +1,11 @@
+#
+# (C) Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2013 Atmel Corporation
+#   Bo Shen voice.s...@atmel.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_SPL_BUILD) += mpddrc.o
diff --git a/arch/arm/cpu/at91-common/mpddrc.c 
b/arch/arm/cpu/at91-common/mpddrc.c
new file mode 100644
index 000..8136396
--- /dev/null
+++ b/arch/arm/cpu/at91-common/mpddrc.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2013 Atmel Corporation
+ *   Bo Shen voice.s...@atmel.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/atmel_mpddrc.h
+
+static inline void atmel_mpddr_op(int mode, u32 ram_address)
+{
+   struct atmel_mpddr *mpddr = (struct atmel_mpddr *)ATMEL_BASE_MPDDRC;
+
+   writel(mode, mpddr-mr);
+   writel(0, ram_address);
+}
+
+int ddr2_init(const unsigned int ram_address,
+ const struct atmel_mpddr *mpddr_value)
+{
+   struct atmel_mpddr *mpddr = (struct atmel_mpddr *)ATMEL_BASE_MPDDRC;
+   u32 ba_off, cr;
+
+   /* Compute bank offset according to NC in configuration register */
+   ba_off = (mpddr_value-cr  ATMEL_MPDDRC_CR_NC_MASK) + 9;
+   if (!(mpddr_value-cr  ATMEL_MPDDRC_CR_DECOD_INTERLEAVED))
+   ba_off += ((mpddr-cr  ATMEL_MPDDRC_CR_NR_MASK)  2) + 11;
+
+   ba_off += (mpddr_value-md  ATMEL_MPDDRC_MD_DBW_MASK) ? 1 : 2;
+
+   /* Program the memory device type into the memory device register */
+   writel(mpddr_value-md, mpddr-md);
+
+   /* Program the configuration register */
+   writel(mpddr_value-cr, mpddr-cr);
+
+   /* Program the timing register */
+   writel(mpddr_value-tpr0, mpddr-tpr0);
+   writel(mpddr_value-tpr1, mpddr-tpr1);
+   writel(mpddr_value-tpr2, mpddr-tpr2);
+
+   /* Issue a NOP command */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
+
+   /* A 200 us is provided to precede any signal toggle */
+   udelay(200);
+
+   /* Issue a NOP command */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
+
+   /* Issue an all banks precharge command */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_PRCGALL_CMD, ram_address);
+
+   /* Issue an extended mode register set(EMRS2) to choose operation */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_EXT_LMR_CMD,
+  ram_address + (0x2  ba_off));
+
+   /* Issue an extended mode register set(EMRS3) to set EMSR to 0 */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_EXT_LMR_CMD,
+  ram_address + (0x3  ba_off));
+
+   /*
+* Issue an extended mode register set(EMRS1) to enable DLL and
+* program D.I.C (output driver impedance control)
+*/
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_EXT_LMR_CMD,
+  ram_address + (0x1  ba_off));
+
+   /* Enable DLL reset */
+   cr = readl(mpddr-cr);
+   writel(cr | ATMEL_MPDDRC_CR_DLL_RESET_ENABLED, mpddr-cr);
+
+   /* A mode register set(MRS) cycle is issued to reset DLL */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_LMR_CMD, ram_address);
+
+   /* Issue an all banks precharge command */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_PRCGALL_CMD, ram_address);
+
+   /* Two auto-refresh (CBR) cycles are provided */
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_RFSH_CMD, ram_address);
+   atmel_mpddr_op(ATMEL_MPDDRC_MR_MODE_RFSH_CMD, ram_address);
+
+   /* Disable DLL reset */
+   cr = readl(mpddr-cr);
+   writel(cr  (~ATMEL_MPDDRC_CR_DLL_RESET_ENABLED), mpddr-cr);
+
+   /* A mode register set

[U-Boot] [PATCH v4 5/7] arm: atmel: sama5d3: early enable PIO peripherals

Enable the PIO peripherals early than other peripherals.

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - None
Changes in v3:
  - Correct the clock enable code, the ID can not OR

Changes in v2:
  - None

 board/atmel/sama5d3xek/sama5d3xek.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/atmel/sama5d3xek/sama5d3xek.c 
b/board/atmel/sama5d3xek/sama5d3xek.c
index b0965ef..f245f98 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -158,6 +158,12 @@ void lcd_show_board_info(void)
 
 int board_early_init_f(void)
 {
+   at91_periph_clk_enable(ATMEL_ID_PIOA);
+   at91_periph_clk_enable(ATMEL_ID_PIOB);
+   at91_periph_clk_enable(ATMEL_ID_PIOC);
+   at91_periph_clk_enable(ATMEL_ID_PIOD);
+   at91_periph_clk_enable(ATMEL_ID_PIOE);
+
at91_seriald_hw_init();
 
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 v4 4/7] arm: atmel: sama5d3: the offset of MULA is 18

The offset of MULA field in PLLA register in sama5d3 is 18,
and the length only 7 bits.

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - None
Changes in v3:
  - None
Changes in v2:
  - None

 arch/arm/include/asm/arch-at91/at91_pmc.h |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h 
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index 3efdc37..b6e542e 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -73,7 +73,11 @@ typedef struct at91_pmc {
 #define AT91_PMC_PLLXR_DIV(x)  (x  0xFF)
 #define AT91_PMC_PLLXR_PLLCOUNT(x) ((x  0x3F)  8)
 #define AT91_PMC_PLLXR_OUT(x)  ((x  0x03)  14)
+#ifdef CONFIG_SAMA5D3
+#define AT91_PMC_PLLXR_MUL(x)  ((x  0x7F)  18)
+#else
 #define AT91_PMC_PLLXR_MUL(x)  ((x  0x7FF)  16)
+#endif
 #define AT91_PMC_PLLAR_29  0x2000
 #define AT91_PMC_PLLBR_USBDIV_10x
 #define AT91_PMC_PLLBR_USBDIV_20x1000
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 7/7] arm: atmel: sama5d3: spl boot from fat fs SD card

Enable Atmel sama5d3xek boart spl boot support, which can load u-boot
from SD card with FAT file system.

Signed-off-by: Bo Shen voice.s...@atmel.com

---
Changes in v4:
  - Add comments to DDR refresh timing register.

Changes in v3:
  - Move plla and mck configure to spl.c file

Changes in v2:
  - Move spl related code to at91-common folder

 arch/arm/cpu/armv7/Makefile  |2 +-
 arch/arm/cpu/at91-common/Makefile|2 +-
 arch/arm/cpu/at91-common/spl.c   |   90 ++
 arch/arm/cpu/at91-common/u-boot-spl.lds  |   50 ++
 arch/arm/include/asm/arch-at91/at91_common.h |4 ++
 arch/arm/include/asm/arch-at91/spl.h |   20 ++
 board/atmel/sama5d3xek/sama5d3xek.c  |   85 
 include/configs/sama5d3xek.h |   34 ++
 8 files changed, 285 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/at91-common/spl.c
 create mode 100644 arch/arm/cpu/at91-common/u-boot-spl.lds
 create mode 100644 arch/arm/include/asm/arch-at91/spl.h

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index d3347b3..0467d00 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -12,7 +12,7 @@ obj-y += cache_v7.o
 obj-y  += cpu.o
 obj-y  += syslib.o
 
-ifneq 
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX),)
+ifneq 
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY),)
 ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
 obj-y  += lowlevel_init.o
 endif
diff --git a/arch/arm/cpu/at91-common/Makefile 
b/arch/arm/cpu/at91-common/Makefile
index 671a05e..d97053f 100644
--- a/arch/arm/cpu/at91-common/Makefile
+++ b/arch/arm/cpu/at91-common/Makefile
@@ -8,4 +8,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_SPL_BUILD) += mpddrc.o
+obj-$(CONFIG_SPL_BUILD) += mpddrc.o spl.o
diff --git a/arch/arm/cpu/at91-common/spl.c b/arch/arm/cpu/at91-common/spl.c
new file mode 100644
index 000..37c0cc4
--- /dev/null
+++ b/arch/arm/cpu/at91-common/spl.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) 2013 Atmel Corporation
+ *   Bo Shen voice.s...@atmel.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_wdt.h
+#include asm/arch/clk.h
+#include spl.h
+
+static void at91_disable_wdt(void)
+{
+   struct at91_wdt *wdt = (struct at91_wdt *)ATMEL_BASE_WDT;
+
+   writel(AT91_WDT_MR_WDDIS, wdt-mr);
+}
+
+void at91_plla_init(u32 pllar)
+{
+   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+
+   writel(pllar, pmc-pllar);
+   while (!(readl(pmc-sr)  (AT91_PMC_LOCKA | AT91_PMC_MCKRDY)))
+   ;
+}
+
+void at91_mck_init(u32 mckr)
+{
+   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+   u32 tmp;
+
+   tmp = readl(pmc-mckr);
+   tmp = ~(AT91_PMC_MCKR_PRES_MASK |
+AT91_PMC_MCKR_MDIV_MASK |
+AT91_PMC_MCKR_PLLADIV_2);
+   tmp |= mckr  (AT91_PMC_MCKR_PRES_MASK |
+  AT91_PMC_MCKR_MDIV_MASK |
+  AT91_PMC_MCKR_PLLADIV_2);
+   writel(tmp, pmc-mckr);
+
+   while (!(readl(pmc-sr)  AT91_PMC_MCKRDY))
+   ;
+}
+
+
+u32 spl_boot_device(void)
+{
+#ifdef CONFIG_SYS_USE_MMC
+   return BOOT_DEVICE_MMC1;
+#endif
+   return BOOT_DEVICE_NONE;
+}
+
+u32 spl_boot_mode(void)
+{
+   switch (spl_boot_device()) {
+#ifdef CONFIG_SYS_USE_MMC
+   case BOOT_DEVICE_MMC1:
+   return MMCSD_MODE_FAT;
+   break;
+#endif
+   case BOOT_DEVICE_NONE:
+   default:
+   hang();
+   }
+}
+
+void s_init(void)
+{
+   /* disable watchdog */
+   at91_disable_wdt();
+
+   /* PMC configuration */
+   at91_pmc_init();
+
+   at91_clock_init(CONFIG_SYS_AT91_MAIN_CLOCK);
+
+   timer_init();
+
+   board_early_init_f();
+
+   preloader_console_init();
+
+   mem_init();
+}
diff --git a/arch/arm/cpu/at91-common/u-boot-spl.lds 
b/arch/arm/cpu/at91-common/u-boot-spl.lds
new file mode 100644
index 000..038335d
--- /dev/null
+++ b/arch/arm/cpu/at91-common/u-boot-spl.lds
@@ -0,0 +1,50 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ * Aneesh V ane...@ti.com
+ *
+ * (C) 2013 Atmel Corporation
+ * Bo Shen voice.s...@atmel.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE, \
+   LENGTH = CONFIG_SPL_MAX_SIZE }
+MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+   LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
+OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
+OUTPUT_ARCH(arm)
+ENTRY(_start)

[U-Boot] [PATCH v15 02/10] cmd_pxe: remove compiling warnings

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
---
 common/cmd_pxe.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index db6b156..c27ec35 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -59,7 +59,7 @@ static int format_mac_pxe(char *outbuf, size_t outbuf_len)
uchar ethaddr[6];
 
if (outbuf_len  21) {
-   printf(outbuf is too small (%d  21)\n, outbuf_len);
+   printf(outbuf is too small (%zd  21)\n, outbuf_len);
 
return -EINVAL;
}
@@ -103,7 +103,7 @@ static int get_bootfile_path(const char *file_path, char 
*bootfile_path,
path_len = (last_slash - bootfile) + 1;
 
if (bootfile_path_size  path_len) {
-   printf(bootfile_path too small. (%d  %d)\n,
+   printf(bootfile_path too small. (%zd  %zd)\n,
bootfile_path_size, path_len);
 
return -1;
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 00/10] arm64 patch

From: David Feng feng...@phytium.com.cn

Changes for v15:
  - modify boot process, u-boot will run at the highest
exception level until it prepare jump to OS.
  - Fix a few bugs in cache.S.These bug is reported by
York Sun york...@freescale.com and Scott Wood
scottw...@freescale.com.
  - when booting, slaves will wait on WFI, master wakeup
slaves by SGI interrupt.
  - add generic_timer.c to utilize the newest timer architecture.
  - add gic.S to support gic initialization and interrupt
operations, currently only support GICv2.

Changes for v14:
  - Merge rela relocation patches from Scott Wood
scottw...@freescale.com.
  - Remove all CONFIG_NEED_MANUAL_RELOC and other fixups
due to manual relocation. With rela relocation patches
them are not needed.
  - Fix the bug of MEMORY_ATTRIBUTES definition due to
assembler. That need put brackets around (MT_NORMAL*8).
Otherwise the result is wrong.This bug is reported by
York Sun york...@freescale.com.
  - -msoft-float is not supported by aarch64-gcc,
make a test though $(call cc-option,-msoft-float).
  - Adjust the virtual address space to 42 bits.
  - Filter armv8 boards from LIST_arm in MAKEALL.
  - remove gpio.h in asm/arch-armv8/ and move mmu.h to
asm/armv8/ directory.
  - remove vexpress64.dts from this patch, it could be
accessed from linux kernel.

Changes for v13:
  - fix the bug of board_r.c and arm/lib/board.c due to
CONFIG_NEED_MANUAL_RELOC. adjust initr_serial() in board_r.c
to the first entry of init_sequence_r[] and relocate
serial_initialize() in arm/lib/board.c, routines of serial_device
should be relocated firstly by serial_initialize(), so that printf
access the correct puts function, otherwise uninitialized
serial_current will be selected as the output device.
  - fix the bug of dcache_enable(). after mmu_setup the sctrl
register value should be fetched again because it has been
modifed by mmu_seup() function. This bug is reported by York Sun
york...@freescale.com.
  - add macro branch_if_slave to macro.h, it choose processor
with all zero affinity value as the master and is used in start.S.

Changes for v12:
  - custom the patches to new format boards.cfg.

Changes for v11:
  - Replace CONFIG_ARMV8 with CONFIG_ARM64. Currently,
it's hard to distinguish what is armv8 specific and
what is aarch64 specific, so we use CONFIG_ARM64
only, no CONFIG_ARMV8 used.
  - rename README.armv8 with README.arm64 and make some modification.

Changes for v10:
  - add weak definition to include/linux/linkage.h and make
setup_el2/setup_el3/lowlevel_init weak routines,
so them can be easily overridden by processor specific code.
  - modify s-o-f of 0002-board-support-of-vexpress_aemv8a which
use wrong mail address of Bhupesh Sharma.

Changes for v9:
  - add Signed-off-by information to patch board support of
vexpress_aemv8a which SMC9 support is integrated
from Sharma Bhupesh's patch.
  - adjust pt_regs struct and add exception state
preservation in exception.S.

Changes for v8:
  - Integrate SMC9 patch of sharma bhupesh.
  - remove v8_outer_cache* which is not need currently.
  - Change license tag.
  - Mov crt0.S/relocate.S/interrupts.c to arm/lib and
rename them with _64 suffix.
  - Make el3/el2 initializing process of start.S as
two separate routines. It could be easier to be
replaced with processor specific codes.
  - Remove exception stack save and restore routine,
it is unnecessary now.
  - simplify __weak function declaration.

Changes for v7:
  - Check the patches with checkpatch.pl and get rid of
almost all warnings. There are a few warnings still,
but I think it should be that.
  - change printf format in cmd_pxe.c, use %zd indtead
of %ld to format size_t type variable.
  - add macro PGTABLE_SIZE to identify tlb table size.

Changes for v6:
  - Make modification to inappropriate licensed file
and bugs according to ScottWood's advice.
Thanks Scott for his checking to these patches.
  - Enable u-boot's running at EL1.
  - Get rid of compiling warnings originated from cmd_pxe.c.

Changes for v5:
  - fix the generic board_f.c, remove zero_global_data
from init_sequence_f array and move it to board_init_f()
function with CONFIG_X86 switch. The previous fixup is
inaccurate.
  - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h
and unaligned.h, gcc for aarch64 use __AARCH64EB__ and
__AARCH64EL__ to identify endian.
  - Some modification to README.armv8

Changes for v4:
  - merge arm64 to arm architecture.

David Feng (10):
  fdt_support: 64bit initrd start address support
  cmd_pxe: remove compiling warnings
  add weak entry definition
  arm64: Add tool to statically apply RELA relocations
  arm64: Turn u-boot.bin back into an ELF file after relocate-rela
  arm64: Make checkarmreloc accept arm64 relocations
  arm64: core support
  arm64: generic board support
  arm64:

[U-Boot] [PATCH v15 03/10] add weak entry definition

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
---
 include/linux/linkage.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index 39c712e..7435fcd 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -48,6 +48,10 @@
.globl SYMBOL_NAME(name); \
LENTRY(name)
 
+#define WEAK(name) \
+   .weak SYMBOL_NAME(name); \
+   LENTRY(name)
+
 #ifndef END
 #define END(name) \
.size name, .-name
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 04/10] arm64: Add tool to statically apply RELA relocations

From: Scott Wood scottw...@freescale.com

ARM64 uses the newer RELA-style relocations rather than the older REL.
RELA relocations have an addend in the relocation struct, rather than
expecting the loader to read a value from the location to be updated.

While this is beneficial for ordinary program loading, it's problematic
for U-Boot because the location to be updated starts out with zero,
rather than a pre-relocation value.  Since we need to be able to run C
code before relocation, we need a tool to apply the relocations at
build time.

In theory this tool is applicable to other newer architectures (mainly
64-bit), but currently the only relocations it supports are for arm64,
and it assumes a 64-bit little-endian target.  If the latter limitation
is ever to be changed, we'll need a way to tell the tool what format
the image is in.  Eventually this may be replaced by a tool that uses
libelf or similar and operates directly on the ELF file.  I've written
some code for such an approach but libelf does not make it easy to poke
addresses by memory address (rather than by section), and I was
hesitant to write code to manually parse the program headers and do the
update outside of libelf (or to iterate over sections) -- especially
since it wouldn't get test coverage on things like binaries with
multiple PT_LOAD segments.  This should be good enough for now to let
the manual relocation stuff be removed from the arm64 patches.

Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: David Feng feng...@phytium.com.cn
---
 Makefile  |   12 
 tools/Makefile|6 ++
 tools/relocate-rela.c |  189 +
 3 files changed, 207 insertions(+)
 create mode 100644 tools/relocate-rela.c

diff --git a/Makefile b/Makefile
index 1f499c5..1dbe796 100644
--- a/Makefile
+++ b/Makefile
@@ -355,6 +355,17 @@ else
 BOARD_SIZE_CHECK =
 endif
 
+# Statically apply RELA-style relocations (currently arm64 only)
+ifneq ($(CONFIG_STATIC_RELA),)
+# $(1) is u-boot ELF, $(2) is u-boot bin, $(3) is text base
+DO_STATIC_RELA = \
+   start=$$($(NM) $(1) | grep __rel_dyn_start | cut -f 1 -d ' '); \
+   end=$$($(NM) $(1) | grep __rel_dyn_end | cut -f 1 -d ' '); \
+   $(obj)tools/relocate-rela $(2) $(3) $$start $$end
+else
+DO_STATIC_RELA =
+endif
+
 # Always append ALL so that arch config.mk's can add custom ones
 ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
 
@@ -397,6 +408,7 @@ $(obj)u-boot.srec:  $(obj)u-boot
 
 $(obj)u-boot.bin:  $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+   $(call DO_STATIC_RELA,$,$@,$(CONFIG_SYS_TEXT_BASE))
$(BOARD_SIZE_CHECK)
 
 $(obj)u-boot.ldr:  $(obj)u-boot
diff --git a/tools/Makefile b/tools/Makefile
index 14d94e3..6d40398 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -59,6 +59,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
 BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
 BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX)
 BIN_FILES-y += proftool(SFX)
+BIN_FILES-$(CONFIG_STATIC_RELA) += relocate-rela$(SFX)
 
 # Source files which exist outside the tools directory
 EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o
@@ -84,6 +85,7 @@ NOPED_OBJ_FILES-y += os_support.o
 NOPED_OBJ_FILES-y += pblimage.o
 NOPED_OBJ_FILES-y += proftool.o
 NOPED_OBJ_FILES-y += ublimage.o
+NOPED_OBJ_FILES-y += relocate-rela.o
 OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o
 OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
 OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o
@@ -250,6 +252,10 @@ $(obj)kwboot$(SFX): $(obj)kwboot.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
 
+$(obj)relocate-rela$(SFX): $(obj)relocate-rela.o
+   $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+   $(HOSTSTRIP) $@
+
 # Some of the tool objects need to be accessed from outside the tools directory
 $(obj)%.o: $(SRCTREE)/common/%.c
$(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
new file mode 100644
index 000..93b4c39
--- /dev/null
+++ b/tools/relocate-rela.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+ BSD-2-Clause
+ *
+ * 64-bit and little-endian target only until we need to support a different
+ * arch that needs this.
+ */
+
+#include elf.h
+#include errno.h
+#include inttypes.h
+#include stdarg.h
+#include stdbool.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+
+#ifndef R_AARCH64_RELATIVE
+#define R_AARCH64_RELATIVE 1027
+#endif
+
+static const bool debug_en;
+
+static void debug(const char *fmt, ...)
+{
+   va_list args;
+
+   va_start(args, fmt);
+   if (debug_en)
+   vprintf(fmt, args);
+}
+
+static bool supported_rela(Elf64_Rela *rela)
+{
+   uint64_t mask = 0xULL; /* would be different on 32-bit */
+   uint32_t type = rela-r_info  mask;
+
+   switch

[U-Boot] [PATCH v15 01/10] fdt_support: 64bit initrd start address support

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
---
 common/fdt_support.c |   66 ++
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 1f0d8f5..a3f7442 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+   const fdt32_t *cell;
+
+   cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+   if (cell  fdt32_to_cpu(*cell) == 2)
+   return 8;
+
+   return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+   int shift = (size - 1) * 8;
+   while (size--  0) {
+   *addr++ = (val  shift)  0xff;
+   shift -= 8;
+   }
+}
+
 /**
  * fdt_getprop_u32_default - Find a node and return it's property or a default
  *
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
 
 int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
 {
-   int   nodeoffset;
+   int   nodeoffset, addr_cell_len;
int   err, j, total;
-   fdt32_t  tmp;
+   fdt64_t  tmp;
const char *path;
uint64_t addr, size;
 
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
return err;
}
 
+   addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
-   tmp = cpu_to_fdt32(initrd_start);
+   write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err  0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
fdt_strerror(err));
return err;
}
-   tmp = cpu_to_fdt32(initrd_end);
+   write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err  0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
 }
 
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
-   const fdt32_t *cell;
-
-   cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
-   if (cell  fdt32_to_cpu(*cell) == 2)
-   return 8;
-
-   return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
-   int shift = (size - 1) * 8;
-   while (size--  0) {
-   *addr++ = (val  shift)  0xff;
-   shift -= 8;
-   }
-}
-
 #ifdef CONFIG_NR_DRAM_BANKS
 #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
 #else
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 05/10] arm64: Turn u-boot.bin back into an ELF file after relocate-rela

From: Scott Wood scottw...@freescale.com

While performing relocations on u-boot.bin should be good enough for
booting on real hardware, some simulators insist on booting an ELF file
(and yet don't perform ELF relocations), so convert the relocated
binary back into an ELF file.  This can go away in the future if we
change relocate-rela to operate directly on the ELF file, or if and
when we stop caring about a simulator with this restriction.

Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: David Feng feng...@phytium.com.cn
---
 Makefile |   13 +
 1 file changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index 1dbe796..44546ff 100644
--- a/Makefile
+++ b/Makefile
@@ -379,6 +379,7 @@ ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb 
$(obj)u-boot-dtb.bin
 ifneq ($(CONFIG_SPL_TARGET),)
 ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET))
 endif
+ALL-$(CONFIG_REMAKE_ELF) += $(obj)u-boot.elf
 
 # enable combined SPL/u-boot/dtb rules for tegra
 ifneq ($(CONFIG_TEGRA),)
@@ -547,6 +548,18 @@ $(obj)u-boot-img-spl-at-end.bin: $(obj)spl/u-boot-spl.bin 
$(obj)u-boot.img
conv=notrunc 2/dev/null
cat $(obj)u-boot-pad.img $(obj)spl/u-boot-spl.bin  $@
 
+# Create a new ELF from a raw binary file.  This is useful for arm64
+# where static relocation needs to be performed on the raw binary,
+# but certain simulators only accept an ELF file (but don't do the
+# relocation).
+# FIXME refactor dts/Makefile to share target/arch detection
+$(obj)u-boot.elf: $(obj)u-boot.bin
+   @$(OBJCOPY)  -B aarch64 -I binary -O elf64-littleaarch64 \
+   $ $(obj)u-boot-elf.o
+   @$(LD) $(obj)u-boot-elf.o -o $@ \
+   --defsym=_start=$(CONFIG_SYS_TEXT_BASE) \
+   -Ttext=$(CONFIG_SYS_TEXT_BASE)
+
 ifeq ($(CONFIG_SANDBOX),y)
 GEN_UBOOT = \
cd $(LNDIR)  $(CC) $(SYMS) -T $(obj)u-boot.lds \
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 06/10] arm64: Make checkarmreloc accept arm64 relocations

From: Scott Wood scottw...@freescale.com

Signed-off-by: Scott Wood scottw...@freescale.com
Signed-off-by: David Feng feng...@phytium.com.cn
---
 Makefile |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 44546ff..01e1268 100644
--- a/Makefile
+++ b/Makefile
@@ -771,12 +771,16 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE)
$(MAKE) -C $@ all
 endif  # config.mk
 
-# ARM relocations should all be R_ARM_RELATIVE.
+# ARM relocations should all be R_ARM_RELATIVE (32-bit) or
+# R_AARCH64_RELATIVE (64-bit).
 checkarmreloc: $(obj)u-boot
-   @if test R_ARM_RELATIVE != \
-   `$(CROSS_COMPILE)readelf -r $ | cut -d ' ' -f 4 | grep R_ARM 
| sort -u`; \
-   then echo $ contains relocations other than \
-   R_ARM_RELATIVE; false; fi
+   @RELOC=`$(CROSS_COMPILE)readelf -r -W $ | cut -d ' ' -f 4 | \
+   grep R_A | sort -u`; \
+   if test $$RELOC != R_ARM_RELATIVE -a \
+$$RELOC != R_AARCH64_RELATIVE; then \
+   echo $ contains unexpected relocations: $$RELOC; \
+   false; \
+   fi
 
 $(VERSION_FILE):
@mkdir -p $(dir $(VERSION_FILE))
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 10/10] arm64: MAKEALL, filter armv8 boards from LIST_arm

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
---
 MAKEALL |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/MAKEALL b/MAKEALL
index 80cd4f8..213383d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -368,6 +368,12 @@ LIST_ARM11=$(targets_by_cpu arm1136)  \
 LIST_ARMV7=$(targets_by_cpu armv7)
 
 #
+## ARMV8 Systems
+#
+
+LIST_ARMV8=$(targets_by_cpu armv8)
+
+#
 ## AT91 Systems
 #
 
@@ -391,7 +397,11 @@ LIST_spear=$(targets_by_soc spear)
 ## ARM groups
 #
 
-LIST_arm=$(targets_by_arch arm)
+LIST_arm=$(targets_by_arch arm |  \
+   for ARMV8_TARGET in $LIST_ARMV8;\
+   do sed /$ARMV8_TARGET/d;  \
+   done)   \
+
 
 #
 ## MIPS Systems(default = big endian)
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 08/10] arm64: generic board support

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
---
 common/board_f.c |   20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index f0664bc..d918e4b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -462,7 +462,7 @@ static int reserve_round_4k(void)
 static int reserve_mmu(void)
 {
/* reserve TLB table */
-   gd-arch.tlb_size = 4096 * 4;
+   gd-arch.tlb_size = PGTABLE_SIZE;
gd-relocaddr -= gd-arch.tlb_size;
 
/* round down to next 64 kB limit */
@@ -614,7 +614,7 @@ static int reserve_stacks(void)
 * TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
 * to handle this and put in arch/xxx/lib/stack.c
 */
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM)  !defined(CONFIG_ARM64)
 #  ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -811,11 +811,6 @@ static int mark_bootstage(void)
 }
 
 static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2)  !defined(CONFIG_MPC512X)  \
-   !defined(CONFIG_MPC83xx)  !defined(CONFIG_MPC85xx)  \
-   !defined(CONFIG_MPC86xx)  !defined(CONFIG_X86)
-   zero_global_data,
-#endif
 #ifdef CONFIG_SANDBOX
setup_ram_buf,
 #endif
@@ -1009,6 +1004,17 @@ void board_init_f(ulong boot_flags)
gd = data;
 #endif
 
+   /*
+* Clear global data before it is accessed at debug print
+* in initcall_run_list. Otherwise the debug print probably
+* get the wrong vaule of gd-have_console.
+*/
+#if !defined(CONFIG_CPM2)  !defined(CONFIG_MPC512X)  \
+   !defined(CONFIG_MPC83xx)  !defined(CONFIG_MPC85xx)  \
+   !defined(CONFIG_MPC86xx)  !defined(CONFIG_X86)
+   zero_global_data();
+#endif
+
gd-flags = boot_flags;
 
if (initcall_run_list(init_sequence_f))
-- 
1.7.9.5


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

[U-Boot] [PATCH v15 09/10] arm64: board support of vexpress_aemv8a

From: David Feng feng...@phytium.com.cn

Signed-off-by: David Feng feng...@phytium.com.cn
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
---
 board/armltd/vexpress64/Makefile |8 ++
 board/armltd/vexpress64/vexpress64.c |   56 ++
 boards.cfg   |1 +
 include/configs/vexpress_aemv8a.h|  189 ++
 4 files changed, 254 insertions(+)
 create mode 100644 board/armltd/vexpress64/Makefile
 create mode 100644 board/armltd/vexpress64/vexpress64.c
 create mode 100644 include/configs/vexpress_aemv8a.h

diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
new file mode 100644
index 000..e009141
--- /dev/null
+++ b/board/armltd/vexpress64/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2000-2004
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := vexpress64.o
diff --git a/board/armltd/vexpress64/vexpress64.c 
b/board/armltd/vexpress64/vexpress64.c
new file mode 100644
index 000..2ec3bc9
--- /dev/null
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2013
+ * David Feng feng...@phytium.com.cn
+ * Sharma Bhupesh bhupesh.sha...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include malloc.h
+#include errno.h
+#include netdev.h
+#include asm/io.h
+#include linux/compiler.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   /*
+* Clear spin table so that secondary processors
+* observe the correct value after waken up from wfe.
+*/
+   *(unsigned long *)CPU_RELEASE_ADDR = 0;
+
+   gd-ram_size = PHYS_SDRAM_1_SIZE;
+   return 0;
+}
+
+int timer_init(void)
+{
+   return 0;
+}
+
+/*
+ * Board specific reset that is system reset.
+ */
+void reset_cpu(ulong addr)
+{
+}
+
+/*
+ * Board specific ethernet initialization routine.
+ */
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+#ifdef CONFIG_SMC9
+   rc = smc9_initialize(0, CONFIG_SMC9_BASE);
+#endif
+   return rc;
+}
diff --git a/boards.cfg b/boards.cfg
index caba64e..5e0c99a 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -386,6 +386,7 @@ Active  arm pxa-   -
   vpac270
 Active  arm pxa-   icpdas  lp8x4x  
lp8x4x   -  

   Sergey Yanovich ynv...@gmail.com
 Active  arm pxa-   toradex -   
colibri_pxa270   -  

   Marek Vasut marek.va...@gmail.com
 Active  arm sa1100 -   -   -   
jornada  -  

   Kristoffer Ericson kristoffer.eric...@gmail.com
+Active  arm armv8  -   armltd  vexpress64  
vexpress_aemv8a  vexpress_aemv8a:ARM64  

   David Feng feng...@phytium.com.cn
 Active  avr32   at32ap at32ap700x  atmel   -   
atngw100 -  

   Haavard Skinnemoen haavard.skinnem...@atmel.com
 Active  avr32   at32ap at32ap700x  atmel   -   
atngw100mkii -  

   Andreas Bießmann andreas.de...@googlemail.com
 Active  avr32   at32ap at32ap700x  atmel   atstk1000   
atstk1002-  

   Haavard Skinnemoen haavard.skinnem...@atmel.com
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
new file mode 100644
index 000..ce5f384
--- /dev/null
+++ b/include/configs/vexpress_aemv8a.h
@@ -0,0 +1,189 @@
+/*
+ * Configuration for Versatile Express. Parts were derived from other ARM
+ *   configurations.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __VEXPRESS_AEMV8A_H
+#define __VEXPRESS_AEMV8A_H
+
+#define DEBUG
+
+#define CONFIG_REMAKE_ELF
+
+/*#define CONFIG_ARMV8_SWITCH_TO_EL1*/
+
+/*#define CONFIG_SYS_GENERIC_BOARD*/
+
+#define CONFIG_SYS_NO_FLASH
+

Re: [U-Boot] [PATCH V2] imx: Define common routines to set cpu and board environment variables

Dear Eric Nelson,

 On 11/14/2013 04:30 PM, Marek Vasut wrote:
  Hi Eric,
  
  Thanks Marek,
  
  On 11/14/2013 02:22 PM, Marek Vasut wrote:
  Dear Eric Nelson,
   
   snip
   
  I'm just hoping to get a trivial amount of machinery so a boot
  
  script can figure out which of a set of DTBs to load:
 imx6q-nitrogen6x.dtb,
 imx6dl-nitrogen6x.dtb, or
 imx6s-nitrogen6x.dtb
  
  Fabio's recent patch for SABRE SD showed the same need.
  
  Full agreement here.
  
  This could be even easier on i.MX6 if we had more formalized (and
  lower-case) strings returned by get_imx_type(), but I wanted this
  to be very small.
  
  I'm not sure how consistent the DTB naming is for other machines
  or if there's always the equivalent of get_imx_type().
  
  In the worst-case scenario, you might end up with some mapping function
  full of strcmp()s ;-)
 
 This is much easier for us to do, since we defer much of the
 scripting into a boot script.
 
 It will be harder for Fabio to shoe-horn in until we get environment
 settings in an external file...

Yeah, patching the env unto u-boot is the way to go here I guess. What's the 
progress on this anyway, Tom ?

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

Re: [U-Boot] [UBOOT][PATCH 0/5] qspi: Add AM437x support