Re: [U-Boot] [PATCH] BeagleBoard: Configure DVI/S-video

[Igor Grinberg]

On 04/21/11 02:52, Jason Kridner wrote:

 Based on patches from Syed Mohammed Khasim (kha...@ti.com).

 Configures the output of the BeagleBoard DVI to be orange.
 Configures the output of the BeagleBoard S-Video to be a colorbar.
 ---
 Updates for this version
 * Rebased on u-boot-ti.

 Signed-off-by: Jason Kridner jkrid...@beagleboard.org
 ---
  board/ti/beagle/beagle.c |   24 +
  board/ti/beagle/beagle.h |   86 
 ++
  2 files changed, 110 insertions(+), 0 deletions(-)

 diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
 index 2e27aef..69fe162 100644
 --- a/board/ti/beagle/beagle.c
 +++ b/board/ti/beagle/beagle.c
 @@ -165,6 +165,28 @@ unsigned int get_expansion_id(void)
  }
  
  /*
 + * Configure DSS to display background color on DVID
 + * Configure VENC to display color bar on S-Video
 + */
 +void display_init(void)

Probably, static void display_init(void) would be better...
or even beagle_display_init... so no name space collision will occur ever...

 +{
 + omap3_dss_venc_config(venc_config_std_tv, VENC_HEIGHT, VENC_WIDTH);
 + switch (get_board_revision()) {
 + case REVISION_AXBX:
 + case REVISION_CX:
 + case REVISION_C4:
 + omap3_dss_panel_config(dvid_cfg);
 + break;
 + case REVISION_XM_A:
 + case REVISION_XM_B:
 + case REVISION_XM_C:
 + default:
 + omap3_dss_panel_config(dvid_cfg_xm);
 + break;
 + }
 +}
 +
 +/*
   * Routine: misc_init_r
   * Description: Configure board specific parts
   */
 @@ -311,6 +333,7 @@ int misc_init_r(void)
  
   twl4030_power_init();
   twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
 + display_init();
  
   /* Set GPIO states before they are made outputs */
   writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1,
 @@ -324,6 +347,7 @@ int misc_init_r(void)
   GPIO15 | GPIO14 | GPIO13 | GPIO12), gpio5_base-oe);
  
   dieid_num_r();
 + omap3_dss_enable();
  
   return 0;
  }
 diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
 index 04247cd..18bfaa8 100644
 --- a/board/ti/beagle/beagle.h
 +++ b/board/ti/beagle/beagle.h
 @@ -23,6 +23,8 @@
  #ifndef _BEAGLE_H_
  #define _BEAGLE_H_
  
 +#include asm/arch/dss.h
 +
  const omap3_sysinfo sysinfo = {
   DDR_STACKED,
   OMAP3 Beagle board,
 @@ -472,4 +474,88 @@ const omap3_sysinfo sysinfo = {
   MUX_VAL(CP(MMC2_DAT6),  (IDIS | PTU | EN  | M4)) /*GPIO_138 BT_EN*/\
   MUX_VAL(CP(MMC2_DAT7),  (IDIS | PTU | EN  | M4)) /*GPIO_139 
 WLAN_EN*/
  
 +/*
 + * Display Configuration
 + */
 +
 +#define DVI_BEAGLE_ORANGE_COL0x00FF8000
 +#define VENC_HEIGHT  0x00ef
 +#define VENC_WIDTH   0x027f
 +
 +/*
 + * Configure VENC in DSS for Beagle to generate Color Bar
 + *
 + * Kindly refer to OMAP TRM for definition of these values.
 + */
 +static const struct venc_regs venc_config_std_tv = {
 + .status = 0x001B,
 + .f_control  = 0x0040,
 + .vidout_ctrl= 0x,
 + .sync_ctrl  = 0x8000,
 + .llen   = 0x8359,
 + .flens  = 0x020C,
 + .hfltr_ctrl = 0x,
 + .cc_carr_wss_carr   = 0x043F2631,
 + .c_phase= 0x0024,
 + .gain_u = 0x0130,
 + .gain_v = 0x0198,
 + .gain_y = 0x01C0,
 + .black_level= 0x006A,
 + .blank_level= 0x005C,
 + .x_color= 0x,
 + .m_control  = 0x0001,
 + .bstamp_wss_data= 0x003F,
 + .s_carr = 0x21F07C1F,
 + .line21 = 0x,
 + .ln_sel = 0x0015,
 + .l21__wc_ctl= 0x1400,
 + .htrigger_vtrigger  = 0x,
 + .savid__eavid   = 0x069300F4,
 + .flen__fal  = 0x0016020C,
 + .lal__phase_reset   = 0x00060107,
 + .hs_int_start_stop_x= 0x008D034E,
 + .hs_ext_start_stop_x= 0x000F0359,
 + .vs_int_start_x = 0x01A0,
 + .vs_int_stop_x__vs_int_start_y  = 0x020501A0,
 + .vs_int_stop_y__vs_ext_start_x  = 0x01AC0024,
 + .vs_ext_stop_x__vs_ext_start_y  = 0x020D01AC,
 + .vs_ext_stop_y  = 0x0006,
 + .avid_start_stop_x 

Re: [U-Boot] [PATCH v3] USB: Remove __attribute__ ((packed)) for struct ehci_hccr and ehci_hcor

[Igor Grinberg]

On 04/21/11 02:52, Jason Kridner wrote:

 Remove __attribute__ ((packed)) to prevent byte access to soc
 registers in some gcc versions.

 Having patches to enable ehci for the BeagleBoard lying around for
 several month, this one was the show-stopper.

 Credits have to go to Laine Walker-Avina lwalk...@ieee.org for
 finding the problem.

 Signed-off-by: Jason Kridner jkrid...@beagleboard.org
 Cc: Alexander Holler hol...@ahsoftware.de
 Cc: Sandeep Paulraj s-paul...@ti.com
 ---
 Changes for v2:
 * Original and v2 were provided by Alexander Holler.
 * v1 was http://patchwork.ozlabs.org/patch/89358/
 * v2 was http://patchwork.ozlabs.org/patch/89362/

 Changes for v3:
 * Switched to align(4), rather than remove the attribute, per suggestion
   from Alexander.

Also fixing the commit message would help
as the change log won't be available after the patch applied.

 ---
  drivers/usb/host/ehci.h |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
 index 945ab64..3d0ad0c 100644
 --- a/drivers/usb/host/ehci.h
 +++ b/drivers/usb/host/ehci.h
 @@ -55,7 +55,7 @@ struct ehci_hccr {
  #define HCS_N_PORTS(p)   (((p)  0)  0xf)
   uint32_t cr_hccparams;
   uint8_t cr_hcsp_portrt[8];
 -} __attribute__ ((packed));
 +} __attribute__ ((packed, aligned(4)));
  
  struct ehci_hcor {
   uint32_t or_usbcmd;
 @@ -85,7 +85,7 @@ struct ehci_hcor {
  #define FLAG_CF  (1  0)/* true:  we'll support high 
 speed */
   uint32_t or_portsc[CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS];
   uint32_t or_systune;
 -} __attribute__ ((packed));
 +} __attribute__ ((packed, aligned(4)));
  
  #define USBMODE  0x68/* USB Device mode */
  #define USBMODE_SDIS (1  3)/* Stream disable */

-- 
Regards,
Igor.

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

[U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Shaohui Xie]

From: Mingkai Hu mingkai...@freescale.com

Signed-off-by: Mingkai Hu mingkai...@freescale.com
Singed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Shaohui Xie b21...@freescale.com
Cc: Mike Frysinger vap...@gentoo.org
---
changes for v2:
remove #ifdef wrapper and refactor spi_xfer by use SPI_XFER(BEGIN | END).
remove 'volatile' use I/O accessors instead.

 drivers/spi/Makefile   |1 +
 drivers/spi/fsl_espi.c |  297 
 include/spi.h  |4 +-
 3 files changed, 301 insertions(+), 1 deletions(-)
 create mode 100644 drivers/spi/fsl_espi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d582fbb..74f1293 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
 COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
 COBJS-$(CONFIG_SH_SPI) += sh_spi.o
+COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
new file mode 100644
index 000..9b8ae9a
--- /dev/null
+++ b/drivers/spi/fsl_espi.c
@@ -0,0 +1,297 @@
+/*
+ * eSPI controller driver.
+ *
+ * Copyright 2010-2011 Freescale Semiconductor, Inc.
+ * Author: Mingkai Hu (mingkai...@freescale.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+#include malloc.h
+#include spi.h
+#include asm/immap_85xx.h
+
+#define ESPI_MAX_CS_NUM4
+
+#define ESPI_EV_RNE(1  9)
+#define ESPI_EV_TNF(1  8)
+
+#define ESPI_MODE_EN   (1  31)   /* Enable interface */
+#define ESPI_MODE_TXTHR(x) ((x)  8)  /* Tx FIFO threshold */
+#define ESPI_MODE_RXTHR(x) ((x)  0)  /* Rx FIFO threshold */
+
+#define ESPI_COM_CS(x) ((x)  30)
+#define ESPI_COM_TRANLEN(x)((x)  0)
+
+#define ESPI_CSMODE_CI_INACTIVEHIGH(1  31)
+#define ESPI_CSMODE_CP_BEGIN_EDGCLK(1  30)
+#define ESPI_CSMODE_REV_MSB_FIRST  (1  29)
+#define ESPI_CSMODE_DIV16  (1  28)
+#define ESPI_CSMODE_PM(x)  ((x)  24)
+#define ESPI_CSMODE_POL_ASSERTED_LOW   (1  20)
+#define ESPI_CSMODE_LEN(x) ((x)  16)
+#define ESPI_CSMODE_CSBEF(x)   ((x)  12)
+#define ESPI_CSMODE_CSAFT(x)   ((x)  8)
+#define ESPI_CSMODE_CSCG(x)((x)  3)
+
+#define ESPI_CSMODE_INIT_VAL (ESPI_CSMODE_POL_ASSERTED_LOW | \
+   ESPI_CSMODE_CSBEF(0) | ESPI_CSMODE_CSAFT(0) | \
+   ESPI_CSMODE_CSCG(1))
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+   unsigned int max_hz, unsigned int mode)
+{
+   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
+   struct spi_slave *slave;
+   sys_info_t sysinfo;
+   unsigned long spibrg = 0;
+   unsigned char pm = 0;
+   int i;
+
+   if (!spi_cs_is_valid(bus, cs))
+   return NULL;
+
+   slave = malloc(sizeof(struct spi_slave));
+   if (!slave)
+   return NULL;
+
+   slave-bus = bus;
+   slave-cs = cs;
+
+   /* Enable eSPI interface */
+   out_be32(espi-mode, ESPI_MODE_RXTHR(3)
+   | ESPI_MODE_TXTHR(4) | ESPI_MODE_EN);
+
+   out_be32(espi-event, 0x); /* Clear all eSPI events */
+   out_be32(espi-mask, 0x); /* Mask  all eSPI interrupts */
+
+   /* Init CS mode interface */
+   for (i = 0; i  ESPI_MAX_CS_NUM; i++)
+   out_be32(espi-csmode[i], ESPI_CSMODE_INIT_VAL);
+
+   out_be32(espi-csmode[cs], in_be32(espi-csmode[cs]) 
+   ~(ESPI_CSMODE_PM(0xF) | ESPI_CSMODE_DIV16
+   | ESPI_CSMODE_CI_INACTIVEHIGH | ESPI_CSMODE_CP_BEGIN_EDGCLK
+   | ESPI_CSMODE_REV_MSB_FIRST | ESPI_CSMODE_LEN(0xF)));
+
+   /* Set eSPI BRG clock source */
+   get_sys_info(sysinfo);
+   spibrg = sysinfo.freqSystemBus / 2;
+   if ((spibrg / max_hz)  32) {
+   out_be32(espi-csmode[cs], in_be32(espi-csmode[cs])
+   | ESPI_CSMODE_DIV16);
+   pm = spibrg / (max_hz * 16 * 2);
+   if (pm  16) {
+   pm = 16;
+   debug(Requested speed is too low: %d Hz
+%d Hz is used.\n, max_hz, spibrg / 

[U-Boot] [PATCH 2/2][v2] powerpc: make espi can read more than 0xFFFA bytes

[Shaohui Xie]

espi flash read returns invalid data if the read length is more than 0xFFFA
bytes, it supports maximum transaction of 2^16 bytes at a time, resister
spcom[TRANLEN] is 16 bits. If the transaction length is greater than  0x,
it need to be split into multiple transactions.

Signed-off-by: Shaohui Xie b21...@freescale.com
Cc: Mike Frysinger vap...@gentoo.org
---
changes for v2:
fix some compile warnings.
remove ifdef and use if else instead.

 drivers/mtd/spi/spi_flash.c |   39 +++
 drivers/spi/fsl_espi.c  |6 ++
 include/spi.h   |2 ++
 3 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index c75b716..f90ef25 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1,6 +1,7 @@
 /*
  * SPI flash interface
  *
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
  * Copyright (C) 2008 Atmel Corporation
  * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
  *
@@ -82,11 +83,41 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 
offset,
 {
u8 cmd[5];
 
-   cmd[0] = CMD_READ_ARRAY_FAST;
-   spi_flash_addr(offset, cmd);
-   cmd[4] = 0x00;
+   if (len = flash-spi-max_transfer_length) {
+   cmd[0] = CMD_READ_ARRAY_FAST;
+   spi_flash_addr(offset, cmd);
+   cmd[4] = 0x00;
+
+   return spi_flash_read_common(flash, cmd, sizeof(cmd), data, 
len);
+   } else {
+   int max_tran_len, num_chunks, tran_len, ret = 0;
+
+   max_tran_len = flash-spi-max_transfer_length;
+   num_chunks = len / max_tran_len + (len % max_tran_len ? 1 : 0);
+
+   while (num_chunks--) {
+   tran_len = min(len , max_tran_len);
+
+   cmd[0] = CMD_READ_ARRAY_FAST;
+   spi_flash_addr(offset, cmd);
+   cmd[4] = 0x00;
+
+   debug(READ: 0x%x = cmd = 
+   { 0x%02x 0x%02x%02x%02x%02x } tran_len = 0x%x\n,
+   offset, cmd[0], cmd[1], cmd[2], cmd[3], cmd[4], 
tran_len);
 
-   return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
+   ret = spi_flash_read_common(
+   flash, cmd, sizeof(cmd), data, tran_len);
+   if (ret  0)
+   return ret;
+
+   offset += max_tran_len;
+   data += max_tran_len;
+   len -= max_tran_len;
+   }
+
+   return ret;
+   }
 }
 
 int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index 9b8ae9a..7630fb3 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -53,6 +53,8 @@
ESPI_CSMODE_CSBEF(0) | ESPI_CSMODE_CSAFT(0) | \
ESPI_CSMODE_CSCG(1))
 
+#define ESPI_MAX_DATA_TRANSFER_LEN 0xFFF0
+
 struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
 {
@@ -72,6 +74,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned 
int cs,
 
slave-bus = bus;
slave-cs = cs;
+   slave-max_transfer_length = ESPI_MAX_DATA_TRANSFER_LEN;
 
/* Enable eSPI interface */
out_be32(espi-mode, ESPI_MODE_RXTHR(3)
@@ -165,6 +168,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *data_out,
unsigned char *buffer;
size_t buf_len;
 
+   if (slave-max_transfer_length  ESPI_MAX_DATA_TRANSFER_LEN)
+   return -1;
+
switch (flags) {
case SPI_XFER_BEGIN:
cmd_len = bitlen / 8;
diff --git a/include/spi.h b/include/spi.h
index c5da3ca..866b920 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -58,10 +58,12 @@
  *
  *   bus:  ID of the bus that the slave is attached to.
  *   cs:   ID of the chip select connected to the slave.
+ *   max_transfer_length: maximum data transfer length supported by the slave.
  */
 struct spi_slave {
unsigned intbus;
unsigned intcs;
+   unsigned intmax_transfer_length;
 };
 
 /*---
-- 
1.6.4


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

Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation

[Aneesh V]

Hi Simon, Wolfgang,

On Thursday 21 April 2011 12:04 AM, Simon Glass wrote:
 On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUDalbert.arib...@free.fr  
 wrote:
 Le 25/03/2011 17:12, Aneesh V a écrit :

 Another problem I have with relocation is that it makes debugging with
 JTAG debugers more difficult. The addresses of symbols in the ELF
 target are no longer valid. Of course, you can load the symbols at an
 offset from the original location. But one has to first enable debug
 prints, find the relocation offset, use it while loading the symbols
 before you can do source level debugging.

 Actually you don't need recompiling: simply set a breakpoint at the
 entry of relocate_code and once you hit the bp, look up r2: it contains
 the destination. If you want the offset rather than the absolute
 address, set the breakpoint right after the 'sub r9, r6, r0' round line
 222: r9 will then give you the offset. Unload the current symbols,
 reload the symbols with the relevant offset, and there you go.

 I would like to revisit this thread. I'm not sure how other people do
 development in U-Boot but I like to use an ICE and a source-level
 debugger for any significant effort. I think it should be possible to
 use a JTAG debugging just by loading the u-boot ELF file and running.

 With this patch (or something similar) this is possible. Without it,
 it is painful.

 To be clear, we are not talking here about creating a platform that
 doesn't use relocation, just that for development purposes it is
 convenient to be able to disable it.

Actually, I am not even sure why relocation shouldn't be disabled in my
platform for good. It may be useful to have things such as the frame
buffer at the end of available memory. But, IMHO, that can still be
done without relocating u-boot. That's what the patch does.Am I missing
something?


 Looking at the December thread
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262

 Aneesh:
 Shouldn't we provide a CONFIG option by which users can disable
 Elf relocation?

 Wolfgang:
 Why should we?  It would just make the code even more complicated, and
 require a lot of additional test cases.

  From what I can see this is a new CONFIG option, two ifdefs in the
 board.c file, and optionally disabling the -pie position-independent
 executable option to reduce size. It is pretty trivial:

   arch/arm/config.mk   |2 ++
   arch/arm/lib/board.c |5 +
   2 files changed, 7 insertions(+), 0 deletions(-)

 Regards,
 Simon


 Amicalement,
 --
 Albert.
 ___
 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] [PATCH v2 0/2] SMDKV310 Board Support

[Chander Kashyap]

Hi,
This patchset adds support for a new board SMDKV310, based on S5PV310 SOC.
This SOC is very similar to S5PC210 SOC, hence we are re-using this SOC code.

Specific changes in PATCH v2 are mention in specific patch files.

Chander Kashyap (2):
  ARMV7: Add support for Samsung SMDKV310 Board
  ARMV7: MMC SPL Boot support for SMDKV310 board

 MAINTAINERS |4 +
 Makefile|9 +
 arch/arm/include/asm/arch-s5pc2xx/sromc.h   |   51 ++
 board/samsung/smdkv310/Makefile |   46 ++
 board/samsung/smdkv310/lowlevel_init.S  |  577 +++
 board/samsung/smdkv310/mem_setup.S  |  365 ++
 board/samsung/smdkv310/smdkv310.c   |  136 ++
 boards.cfg  |1 +
 include/configs/smdkv310.h  |  172 +++
 spl/board/samsung/smdkv310/Makefile |  103 
 spl/board/samsung/smdkv310/mmc_boot.c   |   82 
 spl/board/samsung/smdkv310/tools/mkv310_image.c |  103 
 spl/board/samsung/smdkv310/u-boot.lds   |   86 
 13 files changed, 1735 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h
 create mode 100644 spl/board/samsung/smdkv310/Makefile
 create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 spl/board/samsung/smdkv310/u-boot.lds
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung SMDKV310 Board

[Chander Kashyap]

SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
similar to S5PC210.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for v2:
- Coding Style Cleanup
- Removed unwanted macros from board config file.
- Ethernet controllor configuration is done using gpio structures.
- MMC Controllor gpio configuration corrected.
- Added MAINTAINERS entry.
- Removed unwanted code from mem_setup.S.

 MAINTAINERS   |4 +
 arch/arm/include/asm/arch-s5pc2xx/sromc.h |   51 +++
 board/samsung/smdkv310/Makefile   |   46 +++
 board/samsung/smdkv310/lowlevel_init.S|  577 +
 board/samsung/smdkv310/mem_setup.S|  365 ++
 board/samsung/smdkv310/smdkv310.c |  136 +++
 boards.cfg|1 +
 include/configs/smdkv310.h|  172 +
 8 files changed, 1352 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1299cbb..44f33db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -687,6 +687,10 @@ Minkyu Kang mk7.k...@samsung.com
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal   ARM ARMV7 (S5PC210 SoC)

+Chander Kashyap k.chan...@samsung.com
+
+   SMDKV310ARM ARMV7 (S5PC210 SoC)
+
 Frederik Kriewitz frede...@kriewitz.eu

devkit8000  ARM ARMV7 (OMAP3530 SoC)
diff --git a/arch/arm/include/asm/arch-s5pc2xx/sromc.h 
b/arch/arm/include/asm/arch-s5pc2xx/sromc.h
new file mode 100644
index 000..f616bcb
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc2xx/sromc.h
@@ -0,0 +1,51 @@
+/*
+ * (C) Copyright 2010 Samsung Electronics
+ * Naveen Krishna Ch ch.nav...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * Note: This file contains the register description for SROMC
+ *
+ */
+
+#ifndef __ASM_ARCH_SROMC_H_
+#define __ASM_ARCH_SROMC_H_
+
+#define SROMC_DATA16_WIDTH(x)(1((x*4)+0))
+#define SROMC_BYTE_ADDR_MODE(x)  (1((x*4)+1))  /* 0- Half-word base 
address*/
+   /* 1- Byte base address*/
+#define SROMC_WAIT_ENABLE(x) (1((x*4)+2))
+#define SROMC_BYTE_ENABLE(x) (1((x*4)+3))
+
+#define SROMC_BC_TACS(x) (x  28) /* address set-up */
+#define SROMC_BC_TCOS(x) (x  24) /* chip selection set-up */
+#define SROMC_BC_TACC(x) (x  16) /* access cycle */
+#define SROMC_BC_TCOH(x) (x  12) /* chip selection hold */
+#define SROMC_BC_TAH(x)  (x  8)  /* address holding time */
+#define SROMC_BC_TACP(x) (x  4)  /* page mode access cycle */
+#define SROMC_BC_PMC(x)  (x  0)  /* normal(1data)page mode configuration */
+
+#ifndef __ASSEMBLY__
+struct s5p_sromc {
+   unsigned intbw;
+   unsigned intbc[4];
+};
+#endif /* __ASSEMBLY__ */
+
+/* Configure the Band Width and Bank Control Regs for required SROMC Bank */
+void s5p_config_sromc(u32 srom_bank, u32 srom_bw_conf, u32 srom_bc_conf);
+
+#endif /* __ASM_ARCH_SROMC_H_ */
diff --git a/board/samsung/smdkv310/Makefile b/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..8e9b703
--- /dev/null
+++ b/board/samsung/smdkv310/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this 

[U-Boot] [PATCH v2 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board

[Chander Kashyap]

Added MMC SPL boot support for SMDKV310. This framework design is
based on nand_spl support.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
 Makefile|9 ++
 spl/board/samsung/smdkv310/Makefile |  103 +++
 spl/board/samsung/smdkv310/mmc_boot.c   |   82 ++
 spl/board/samsung/smdkv310/tools/mkv310_image.c |  103 +++
 spl/board/samsung/smdkv310/u-boot.lds   |   86 +++
 5 files changed, 383 insertions(+), 0 deletions(-)
 create mode 100644 spl/board/samsung/smdkv310/Makefile
 create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 spl/board/samsung/smdkv310/u-boot.lds

diff --git a/Makefile b/Makefile
index 713dba1..a298221 100644
--- a/Makefile
+++ b/Makefile
@@ -321,6 +321,10 @@ ALL += $(obj)u-boot-onenand.bin
 ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
 endif

+ifeq ($(CONFIG_MMC_U_BOOT),y)
+ALL += $(obj)spl/v310_mmc_spl.bin
+endif
+
 all:   $(ALL)

 $(obj)u-boot.hex:  $(obj)u-boot
@@ -412,6 +416,11 @@ onenand_ipl:   $(TIMESTAMP_FILE) $(VERSION_FILE) 
$(obj)include/autoconf.mk
 $(obj)u-boot-onenand.bin:  onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin  $(obj)u-boot-onenand.bin

+spl:   $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+   $(MAKE) -C spl/board/$(BOARDDIR) all
+
+$(obj)spl/v310_mmc_spl.bin:spl
+
 $(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion 
$(TOPDIR))' ; \
   printf '#define PLAIN_VERSION %s%s\n' \
diff --git a/spl/board/samsung/smdkv310/Makefile 
b/spl/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..fdede6b
--- /dev/null
+++ b/spl/board/samsung/smdkv310/Makefile
@@ -0,0 +1,103 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, k.chan...@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext 
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+
+SOBJS  = start.o mem_setup.o lowlevel_init.o
+COBJS  = mmc_boot.o
+
+SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
+OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR  := $(OBJTREE)/spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/spl/
+
+
+MKBIN_V310_MMC_SPL_BIN = mkv310_mmc_spl_bin
+MMC_SPL_BIN = v310_mmc_spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN):  $(mmcobj)u-boot-spl.bin 
tools/$(MKBIN_V310_MMC_SPL_BIN)
+   ./tools/$(MKBIN_V310_MMC_SPL_BIN) $(mmcobj)u-boot-spl.bin 
$(mmcobj)$(MMC_SPL_BIN)
+
+tools/$(MKBIN_V310_MMC_SPL_BIN): tools/mkv310_image.c
+   $(HOSTCC) tools/mkv310_image.c -o tools/$(MKBIN_V310_MMC_SPL_BIN)
+
+$(mmcobj)u-boot-spl.bin:   $(mmcobj)u-boot-spl
+   $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+
+$(mmcobj)u-boot-spl:   $(OBJS) $(mmcobj)u-boot.lds
+   cd $(LNDIR)  $(LD) $(LDFLAGS) $(__OBJS) \
+   -Map $(mmcobj)u-boot-spl.map \
+   -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+   $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@
+
+# create symbolic links for common files
+
+# from cpu directory
+$(obj)start.S:
+   @rm -f $@
+   @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@
+
+# from board directory
+$(obj)mem_setup.S:
+   @rm -f $@
+   @ln -s $(TOPDIR)/board/samsung/smdkv310/mem_setup.S $@
+
+$(obj)lowlevel_init.S:
+   @rm -f $@
+   @ln -s $(TOPDIR)/board/samsung/smdkv310/lowlevel_init.S $@
+
+#
+
+$(obj)%.o: $(obj)%.S
+   $(CC) $(AFLAGS) -c -o $@ $
+
+$(obj)%.o: $(obj)%.c
+ 

[U-Boot] [PATCH] sf: spansion: add support for new spansion flash

[Shaohui Xie]

Signed-off-by: Shaohui Xie b21...@freescale.com
Cc: Mike Frysinger vap...@gentoo.org
---
 drivers/mtd/spi/spansion.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index a3401b3..8835e96 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -53,6 +53,7 @@
 #define SPSN_EXT_ID_S25FL128P_256KB0x0300
 #define SPSN_EXT_ID_S25FL128P_64KB 0x0301
 #define SPSN_EXT_ID_S25FL032P  0x4d00
+#define SPSN_EXT_ID_S25FL129P  0x4d01
 
 struct spansion_spi_flash_params {
u16 idcode1;
@@ -131,6 +132,14 @@ static const struct spansion_spi_flash_params 
spansion_spi_flash_table[] = {
.nr_sectors = 64,
.name = S25FL032P,
},
+   {
+   .idcode1 = SPSN_ID_S25FL128P,
+   .idcode2 = SPSN_EXT_ID_S25FL129P,
+   .page_size = 256,
+   .pages_per_sector = 256,
+   .nr_sectors = 256,
+   .name = S25FL129P_64K,
+   },
 };
 
 static int spansion_write(struct spi_flash *flash,
-- 
1.6.4


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

[U-Boot] RFC: getramsize() prototype and volatile qualifier

[Albert ARIBAUD]

Hi all,

Call it a detail, but I see that get_ram_size() calls sometime qualify 
their argument as volatile and sometimes not, and this makes checkpatch 
complain that volatiles are Bad(tm), which I would like to get fixed.

The prototype for get_ram_size() in is

longget_ram_size  (volatile long *, long);

While I understand that the way get_ram_size() works, it needs to 
perform volatile *accesses* to addresses computed from its arguments, I 
don't see why it requires one of the arguments themselves to be volatile.

Am I missing something here, particularly about some toolchain requiring 
the argument to be volatile? I see no reason it should, but better safe 
than sorry.

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

Re: [U-Boot] Attention Buyer

[led10-May]

Hello Sir, 

Good day to you.

This is May from DesirePower International Group in Shenzhen, China, which is 
specialized in LED lighting for several years.

Top quality with low price of LED lights for you.  E-catalogue is free for your 
learning if you are in need.

Would you just take several minutes to go over our website: 
www.desire-lighting.com  http://www.desire-ledlighting.com.cn/, if you are 
interested please feel free to let me know, thanks.

Looking forward to hearing from you.

Regards

May


--
DESIRE POWER INTERNATIONAL GROUP
LED LIGHTING DEPARTMENT
 
Tel:  +86-755-2806-8560  
Fax:  +86-755-2806-8650
Mobile:  00 86 1355 4711 346
Website: www.desire-lighting.com  http://www.desire-ledlighting.com.cn/
E-mail: le...@desire-lighting.com  or ledlighting.shenz...@gmail.com
MSN: footprint-jes...@hotmail.com 
Skype: ledtube_may02
Shenzhen Factory: Unit 6, Jiayiyuan Technology Park, Huaning Road, Dalang 
sub-district, 
 Longhua Town, Baoan district, Shenzhen city, 
Guangdong province, China.
2011-04-21


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

Re: [U-Boot] [PATCH] xilinx_ppc_boards: Change address of RESET_VECTOR

[Stefan Roese]

On Wednesday 12 January 2011 10:14:42 Ricardo Ribalda Delgado wrote:
 Old address of RESET_VECTOR were overwritten by the bss sector, making
 impossible its run from xmd.

Applied to u-boot-ppc4xx/master. Thanks.
 
Cheers,
Stefan

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

Re: [U-Boot] [PATCH 0/8] ppc4xx: Update DLVision 10G support

[Stefan Roese]

On Wednesday 06 April 2011 13:53:42 Dirk Eibach wrote:
 Dirk Eibach (8):
   ppc4xx: Improve DLVision-10G PLL setup
   ppc4xx: Improve video board detection
   hwmon: Extend lm63.c to support LM64
   ppc4xx: Adapt DLVision 10G to new FPGA firmware
   ppc4xx: Set DLVision 10G osd position to linux defaults
   ppc4xx: Enable MPC92469AC on DLVision 10G
   ppc4xx: Improve fan PWM curve on DLVision 10G
   ppc4xx: Do not stop booting on any keypress on dlvision-10g

Applied whole patch series with the exception of patch 3 hwmon: Extend lm63.c 
to support LM64. Here the 2nd ppc4xx specific version has been applied: 
ppc4xx: Enable LM64 on DLVision 10G.

Thanks.
 
Cheers,
Stefan

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

[U-Boot] Please pull u-boot-ppc4xx/master

[Stefan Roese]

Hi Wolfgang,

please pull the following ppc4xx patches:

The following changes since commit 735eb0f0e66b544b1dfaf6c43ce6e4bd9ae64b5e:

  tools/env: fix redundant env flag comparison (2011-04-21 00:25:08 +0200)

are available in the git repository at:
  git://www.denx.de/git/u-boot-ppc4xx.git master

Dirk Eibach (8):
  ppc4xx: Improve DLVision-10G PLL setup
  ppc4xx: Improve video board detection
  ppc4xx: Enable LM64 on DLVision 10G
  ppc4xx: Adapt DLVision 10G to new FPGA firmware
  ppc4xx: Set DLVision 10G osd position to linux defaults
  ppc4xx: Enable MPC92469AC on DLVision 10G
  ppc4xx: Improve fan PWM curve on DLVision 10G
  ppc4xx: Do not stop booting on any keypress on dlvision-10g

Ricardo Ribalda Delgado (1):
  xilinx_ppc_boards: Change address of RESET_VECTOR

 board/gdsys/405ep/405ep.c|9 +-
 board/gdsys/405ep/dlvision-10g.c |   41 ++-
 board/gdsys/common/osd.c |   57 --
 boards.cfg   |   10 +++---
 include/configs/dlvision-10g.h   |   12 ++-
 include/gdsys_fpga.h |   13 +---
 6 files changed, 118 insertions(+), 24 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] ftsdmc020: move ftsdmc020.h to include/faraday

[Albert ARIBAUD]

Hi MacPaul,

Le 21/04/2011 04:57, Macpaul Lin a écrit :
 HI Albert,

 2011/4/16 Albert ARIBAUDalbert.u.b...@aribaud.net:
 Please resend a V3 patch set of the four patches, even if two of them are
 unchanged. Make sure all patches have their history updated, even the
 unchanged patches ('V3: no change'). I'll apply the whole set in one go.

 Amicalement,
 --
 Albert.


 Patch v3 of this set of patches has been send on 2011-04-16

 Please refer to
 http://patchwork.ozlabs.org/patch/91478/
 http://patchwork.ozlabs.org/patch/91479/
 http://patchwork.ozlabs.org/patch/91476/
 http://patchwork.ozlabs.org/patch/91477/

91476 and 91477 are ok, I'll apply them.

91478 and 91479, though, I don't see their point: they are adding a file 
that obviously no one used before it was added, but that no one uses 
now. These header files are dead code, and should only be added in a 
patch where other code changes actually make them required.

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

Re: [U-Boot] Update and Cut down mach types

[Albert ARIBAUD]

Le 20/04/2011 21:26, Michael Schwingen a écrit :
 On 04/20/2011 07:49 PM, Albert ARIBAUD wrote:
 Le 20/04/2011 19:15, Michael Schwingen a écrit :

 Why don't we pull the original master mach-types file, and generate the
 required .h file(s) during make using the same (or a similar) script
 Linux uses?
 Hmm, because it would mean maintaining the same script as Linux uses.
 With the current solution, there's work to be done on mach-types only
 when someone needs new machine IDs.
 I don't see how much maintaining the script would need - if the input
 format does not change, the script does not need changes, and if changes
 are needed, the can be copied 1:1 from the Linux version.

 On the plus side: the mach-types file is much more terse than the
 generated headers, so updates that pull in new machines would generate
 diffs that are a lot smaller than they are now.


 Have you checked that none of the removed boards are in U-Boot tree?
 Because if there are some, then their build will be broken...
 It will break ACTUX1-ACTUX4 (which are in-tree, and work fine as soon as
 the relocation-breakage-patch is accepted), plus  DVLHOST, for which I
 have patches submitted to add support.

 For my own boards, I can go to the ARM machine database, touch the
 entry, and wait until the define re-emerges in Linux, and await until
 that is marged back to u-boot, but this is plain silly. However, for
 DVLHOST, I am not the registered maintainer in the machine database, so
 I would have to create a duplicate entry for this to work.
 IIUC the machines that would disappear are those for which the is no
 actual mainline Linux support and which have not been touched in over a
 year, right? Do ACTUX* and DVLHOST boards fit in this description?
 Yes. The ACTUX board ports are by me, while the DVLHOST machine type
 seems to be allocated by the manufacturer, Devolo, who never mainlined
 their Linux adaptions, so my goal is to get an independent port up.
 However, that means I can't update the machine type to get it back in
 mainline Linux by the 12-month-rule.

 cu
 Michael

Michael, for the time being, can you provide a patch over Sandeep's 
update to reintroduce ACTUX* and DVLHOST? I'll consider it as a bugfix 
and apply it before my pull request.

For the longer term, let us keep on weighting the pros and cons of the 
options we have for handling machine types.

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

Re: [U-Boot] [PATCH v2 3/4] ftsdmc020: move ftsdmc020.h to include/faraday

[Macpaul Lin]

Hi Albert,

2011/4/21 Albert ARIBAUD albert.u.b...@aribaud.net:
 91478 and 91479, though, I don't see their point: they are adding a file
 that obviously no one used before it was added, but that no one uses now.
 These header files are dead code, and should only be added in a patch where
 other code changes actually make them required.

 Amicalement,
 --
 Albert.


Roger that.
I'll resend this later with the SoC which used it is under reviewing.
Thanks.

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

[U-Boot] The forbidden value in omap3-common timer.c code

[Simon Schwarz]

Hi there,

I just started to work with the u-boot sources for my bachelor thesis. 
There was a part in the source which irritated me a bit.

I talk about ./arch/arm/cpu/armv7/omap-common/timer.c

It's about that part of code:
#define TIMER_LOAD_VAL  0x

int timer_init(void)
{
 /* start the counter ticking up, reload value on overflow */
 writel(TIMER_LOAD_VAL, timer_base-tldr);
 /* enable timer */
 writel((CONFIG_SYS_PTV  2) | TCLR_PRE | TCLR_AR | TCLR_ST,
timer_base-tclr);

 reset_timer_masked();   /* init the timestamp and lastinc value */

 return 0;
}


The tldr ist loaded with 0x.

The OMAP35x Technical Reference Manual (Rev. P) says on page 2583:
Do not put the overflow value (0x) in the GPTi.TLDR register
because it can lead to undesired results.

Is there a reason why the value is used nevertheless? At this time I 
don't know where the timer is used, maybe the undesired results 
haven't been noticed yet?

Thanks!
Simon

-- 
-
Simon Schwarz

Corscience GmbH  Co. KG
Henkestraße 91
D-91052 Erlangen

e-mail: schw...@corscience.de
Internet: www.corscience.de
-
Corscience GmbH  Co.KG
Sitz der Gesellschaft/Place of business: Erlangen
Amtsgericht/Local court: Fürth
Handelsregisternummer/Commercial Register No.: HRA 7510
Geschäftsführer/Managing director: Prof. Dr. Armin Bolz,
Dr. Karl-Andreas Feldhahn, Dipl.-Volksw. Marc Griefahn

CONFIDENTIALITY:
This e-mail and any attachments are confidential and may also be
privileged. If received in error, please do not disclose the contents
to anyone, but notify us immediately by return e-mail and delete this
e-mail and any attachments from your system. Thank you.

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

Re: [U-Boot] [beagleboard] Re: [PATCH] Add 'led' command

[Jason Kridner]

Adding u-boot list seem to have missed it in my reply.

On Thu, Apr 21, 2011 at 9:16 AM, Jason Kridner jkrid...@beagleboard.orgwrote:

 On Wed, Apr 20, 2011 at 6:04 PM, Wolfgang Denk w...@denx.de wrote:

 Dear Jason Kridner,

 In message 1299013329-29931-1-git-send-email-jkrid...@beagleboard.org
 you wrote:
  This patch allows any board implementing the coloured LED API
  to control the LEDs from the console.
 
  led [green | yellow | red | all ]  [ on | off ]
 
  or
 
  led [ 1 | 2 | 3 | all ]  [ on | off ]

 I still wonder if such a patch will help to get rid of the ton of LEd
 drivers we already have in U-Boot, or if it just adds another such
 interface?


 It neither adds nor subtracts.



 Which drivers (led.c files) will be obsoleted by this patch?


 None.  The objective is simply to expose led.c functionality to a
 command-line function.




 If it is intended to be a generic interface - how can this then be
 combined with the status_led.c driver?


 It is intended to utilize status_led.h and therefore to be complementary to
 status_led.c.  Looking at it right now, it looks like I can better reuse
 some functions in that driver, so I will modify the code to do that.  My
 apologies for missing it.



 The configuration green, yellow, red seems to be very specific
 to me - I guess this applies just to very few boards?


 Yes, but it is in status_led.h, so I wanted to include the support for it.



 ...
  +struct led_tbl_s {
  + char*string;/* String for use in the command
 */
  + led_id_tmask;   /* Mask used for calling
 __led_set() */
  + void(*on)(void);/* Optional fucntion for turning
 LED on */
  + void(*off)(void);   /* Optional fucntion for turning
 LED on */
  +};
  +
  +typedef struct led_tbl_s led_tbl_t;
  +
  +static const led_tbl_t led_commands[] = {
  +#ifdef CONFIG_BOARD_SPECIFIC_LED
  +#ifdef STATUS_LED_BIT
  + { 0, STATUS_LED_BIT, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT1
  + { 1, STATUS_LED_BIT1, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT2
  + { 2, STATUS_LED_BIT2, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT3
  + { 3, STATUS_LED_BIT3, NULL, NULL },
  +#endif

 What are these status bits good for when they have no actual
 handlers attached?  Where are they actually used?


 If no LED specific handler is provided, __led_set is used.  I'm going to
 switch this to status_led_set() based on your feedback.




  +#ifdef STATUS_LED_GREEN
  + { green, STATUS_LED_GREEN, green_LED_off, green_LED_on },
  +#endif
  +#ifdef STATUS_LED_YELLOW
  + { yellow, STATUS_LED_YELLOW, yellow_LED_off, yellow_LED_on },
  +#endif
  +#ifdef STATUS_LED_RED
  + { red, STATUS_LED_RED, red_LED_off, red_LED_on },
  +#endif
  +#ifdef STATUS_LED_BLUE
  + { blue, STATUS_LED_BLUE, blue_LED_off, blue_LED_on },
  +#endif

 We do not allow CamelCase identifiers (like green_LED_off).


 Easy enough to fix.




 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
 Sometimes a man will tell his bartender things he'll never tell his
 doctor.
-- Dr. Phillip Boyce, The Menagerie (The Cage),
   stardate unknown.

 --
 You received this message because you are subscribed to the Google Groups
 Beagle Board group.
 To post to this group, send email to beaglebo...@googlegroups.com.
 To unsubscribe from this group, send email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/beagleboard?hl=en.



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

Re: [U-Boot] The forbidden value in omap3-common timer.c code

[Bedia, Vaibhav]

On Thursday, April 21, 2011 5:44 PM, Simon Schwarz wrote:
 Hi there,
[...]
 
 It's about that part of code:
 #define TIMER_LOAD_VAL  0x
 

IIRC there was a patch which corrected this reload value to 0.

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

Re: [U-Boot] [PATCH] cfi_flash: reverse geometry for M29W800DT parts

[Stefan Roese]

On Sunday 10 April 2011 22:06:29 Mike Frysinger wrote:
 The M29W800DT parts also report their geometry with the sector layout
 reversed.  So add that ID to the flash_fixup_stm function.
 
 Otherwise, we get:
 bfin flinfo
 
 Bank # 1: CFI conformant FLASH (16 x 16)  Size: 1 MB in 19 Sectors
   AMD Standard command set, Manufacturer ID: 0x20, Device ID: 0x22D7
   Erase timeout: 8192 ms, write timeout: 1 ms
 
   Sector Start Addresses:
   20002000400020006000200080002001
   20022003200420052006
   200720082009200A200B
   200C200D200E200F

Applied to u-boot-cfi-flash/master. Thanks.
 
Cheers,
Stefan

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

Re: [U-Boot] [PATCH v2] mtd, cfi: read AMD 3-byte (expanded) device ids on 16bit devices

[Stefan Roese]

On Monday 11 April 2011 14:16:19 Heiko Schocher wrote:
 tested on the a4m072 board with a S29GL512P flash.
 
 flinfo without this patch
 Bank # 1: CFI conformant flash (16 x 16)  Size: 32 MB in 256 Sectors
   AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
   Erase timeout: 16384 ms, write timeout: 2 ms
   Buffer write timeout: 5 ms, buffer size: 32 bytes
 [...]
 
 flinfo with this patch
 Bank # 1: CFI conformant flash (16 x 16)  Size: 32 MB in 256 Sectors
   AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2301
   Erase timeout: 16384 ms, write timeout: 2 ms
   Buffer write timeout: 5 ms, buffer size: 32 bytes
 [...]

Applied to u-boot-cfi-flash/master. Thanks.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH] cfi_flash driver - Add delay after reset command

[Stefan Roese]

On Tuesday 12 April 2011 09:59:04 Aaron Williams wrote:
 I ran into a problem where the reset was failing except when I enabled
 debugging support.  After talking with Garret Swalling at Spansion I
 was told that the GL-N series of devices require a 500ns wait for the
 reset to complete.  The below patch adds a 1us delay after all reset
 commands.

Applied to u-boot-cfi-flash/master. Thanks.

Cheers,
Stefan

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

[U-Boot] Please pull u-boot-cfi-flash

[Stefan Roese]

Hi Wolfgang,

please pull the following patches:

The following changes since commit 735eb0f0e66b544b1dfaf6c43ce6e4bd9ae64b5e:

  tools/env: fix redundant env flag comparison (2011-04-21 00:25:08 +0200)

are available in the git repository at:
  git://www.denx.de/git/u-boot-cfi-flash.git master

Aaron Williams (1):
  cfi_flash driver - Add delay after reset command

Heiko Schocher (1):
  mtd, cfi: read AMD 3-byte (expanded) device ids on 16bit devices

Mike Frysinger (1):
  cfi_flash: reverse geometry for M29W800DT parts

 drivers/mtd/cfi_flash.c |   27 ++-
 1 files changed, 22 insertions(+), 5 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Detlev Zundel]

Hi Wolfgang,

 Dear Graeme Russ,

 In message BANLkTimdJkETWEOrJFuxq4hN8gG+DvY=-a...@mail.gmail.com you wrote:

 What about my other suggestion - A checkpatch summary with an expalation
 for any warnings or errors? See for example my heads-up for checkpatch
 warnings - http://lists.denx.de/pipermail/u-boot/2011-April/090144.html

 For issues like this one should do what the last lines of the
 checkpatch output say: If any of these errors are false positives
 report them to the maintainer, see CHECKPATCH in MAINTAINERS.

But as I showed, we already know that we do have false positives in
U-Boot as we miss some Linux constructs.  We should refrain from taking
this as false positives to the checkpatch maintainers.  Either we can
suppress them somehow or maybe we should list them?

Cheers
  Detlev

-- 
Warning: this comic occasionally contains strong language (which may be unsuit-
able for children), unusual humor (which may be unsuitable for adults), and ad-
vanced mathematics (which may be unsuitable for liberal-arts majors). /xkcd.org
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Detlev Zundel]

Hi Scott,

 I vote for checkpatch is a tool that can help you find some style problems,
 but is imperfect, and the things it complains about are of varying
 importance.  If you insist on zero warnings, what's the difference between
 a warning and an error?  And will there then be a U-Boot-specific coding
 style document to match?  Will anyone that wants to submit a patch that
 checkpatch erroneously complains about have to first submit a patch for
 checkpatch (first learning Perl if need be)?

So you would agree to this text:

  Checkpatch is a tool that can help you find some style problems, but is
  imperfect, and the things it complains about are of varying importance.
  So use common sense in interpreting the results.  Warnings that clearly
  only make sense in the Linux kernel can be ignored.  
  
What about the problem with checkpatch errors in current code, i.e. the
origin of this sentence:

  Also warnings produced for context lines (i.e. existing code) rather
  than actual changes can also be ignored.

Do we want this?

 There's a lot more common sense that needs to be applied when writing
 software than where to stick what kind and amount of whitespace.
 Guidelines are good -- zero-tolerance obedience to a script, not so much.

I agree 100%, but I also understand that people want to see some
guideline that they can refer to.  So let's see how good a compromise we
can find.

Thanks
  Detlev

-- 
Some people unfortunately like  jumping up and down about spaces but not code.
[...]   I'd rather read good poetry written in very bad hand writing than bad
poetry written in beautiful handwriting, and I think the same is true of code.
   -- Alan Cox 20090701130018.115ce...@lxorguk.ukuu.org.uk
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Eric Cooper]

On Thu, Apr 21, 2011 at 04:29:17PM +0200, Detlev Zundel wrote:
 What about the problem with checkpatch errors in current code, i.e. the
 origin of this sentence:
 
   Also warnings produced for context lines (i.e. existing code) rather
   than actual changes can also be ignored.

How about replacing it with this:

If you encounter warnings for existing code, not modified by your
patch, consider submitting a separate, cosmetic-only patch --
clearly described as such -- that *precedes* your substantive
patch.

-- 
Eric Cooper e c c @ c m u . e d u
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [beagleboard] Re: [PATCH] Add 'led' command

[Jason Kridner]

On Thu, Apr 21, 2011 at 9:17 AM, Jason Kridner jkrid...@beagleboard.orgwrote:

 Adding u-boot list seem to have missed it in my reply.


 On Thu, Apr 21, 2011 at 9:16 AM, Jason Kridner 
 jkrid...@beagleboard.orgwrote:

 On Wed, Apr 20, 2011 at 6:04 PM, Wolfgang Denk w...@denx.de wrote:

 Dear Jason Kridner,

 In message 1299013329-29931-1-git-send-email-jkrid...@beagleboard.org
 you wrote:
  This patch allows any board implementing the coloured LED API
  to control the LEDs from the console.
 
  led [green | yellow | red | all ]  [ on | off ]
 
  or
 
  led [ 1 | 2 | 3 | all ]  [ on | off ]

 I still wonder if such a patch will help to get rid of the ton of LEd
 drivers we already have in U-Boot, or if it just adds another such
 interface?


 It neither adds nor subtracts.



 Which drivers (led.c files) will be obsoleted by this patch?


 None.  The objective is simply to expose led.c functionality to a
 command-line function.




 If it is intended to be a generic interface - how can this then be
 combined with the status_led.c driver?


 It is intended to utilize status_led.h and therefore to be complementary
 to status_led.c.  Looking at it right now, it looks like I can better reuse
 some functions in that driver, so I will modify the code to do that.  My
 apologies for missing it.



 The configuration green, yellow, red seems to be very specific
 to me - I guess this applies just to very few boards?


 Yes, but it is in status_led.h, so I wanted to include the support for it.



 ...
  +struct led_tbl_s {
  + char*string;/* String for use in the command
 */
  + led_id_tmask;   /* Mask used for calling
 __led_set() */
  + void(*on)(void);/* Optional fucntion for turning
 LED on */
  + void(*off)(void);   /* Optional fucntion for turning
 LED on */
  +};
  +
  +typedef struct led_tbl_s led_tbl_t;
  +
  +static const led_tbl_t led_commands[] = {
  +#ifdef CONFIG_BOARD_SPECIFIC_LED
  +#ifdef STATUS_LED_BIT
  + { 0, STATUS_LED_BIT, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT1
  + { 1, STATUS_LED_BIT1, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT2
  + { 2, STATUS_LED_BIT2, NULL, NULL },
  +#endif
  +#ifdef STATUS_LED_BIT3
  + { 3, STATUS_LED_BIT3, NULL, NULL },
  +#endif

 What are these status bits good for when they have no actual
 handlers attached?  Where are they actually used?


 If no LED specific handler is provided, __led_set is used.  I'm going to
 switch this to status_led_set() based on your feedback.




  +#ifdef STATUS_LED_GREEN
  + { green, STATUS_LED_GREEN, green_LED_off, green_LED_on },
  +#endif
  +#ifdef STATUS_LED_YELLOW
  + { yellow, STATUS_LED_YELLOW, yellow_LED_off, yellow_LED_on },
  +#endif
  +#ifdef STATUS_LED_RED
  + { red, STATUS_LED_RED, red_LED_off, red_LED_on },
  +#endif
  +#ifdef STATUS_LED_BLUE
  + { blue, STATUS_LED_BLUE, blue_LED_off, blue_LED_on },
  +#endif

 We do not allow CamelCase identifiers (like green_LED_off).


 Easy enough to fix.



I might have spoken too soon.  Those identifiers come straight out of
status_led.h.  Would you like me to run a script across the entire codebase
to switch them?

I am doing so with:
for file in `find . | grep '\.[ch]$'`; do perl -i -pe
's/(green|yellow|red|blue)_LED_(on|off)/$1_led_$2/g' $file; done

Eventually, maybe I'll have my head wrapped around how all of this led.c
stuff works well enough to really give you a global clean-up.  I still feel
like I'm being suckered into something when all I want is a command to
access the functions that are already there. I guess that is the price of
open source.  :-)






 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
 Sometimes a man will tell his bartender things he'll never tell his
 doctor.
-- Dr. Phillip Boyce, The Menagerie (The Cage),
   stardate unknown.

 --
 You received this message because you are subscribed to the Google Groups
 Beagle Board group.
 To post to this group, send email to beaglebo...@googlegroups.com.
 To unsubscribe from this group, send email to
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/beagleboard?hl=en.




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

Re: [U-Boot] Policy for checkpatch usage?

[Fabian Cenedese]

At 10:49 21.04.2011 -0400, Eric Cooper wrote:
On Thu, Apr 21, 2011 at 04:29:17PM +0200, Detlev Zundel wrote:
 What about the problem with checkpatch errors in current code, i.e. the
 origin of this sentence:
 
   Also warnings produced for context lines (i.e. existing code) rather
   than actual changes can also be ignored.

How about replacing it with this:

If you encounter warnings for existing code, not modified by your
patch, consider submitting a separate, cosmetic-only patch --
clearly described as such -- that *precedes* your substantive
patch.

Is that even possible? The cosmetic patch itself will be surrounded
by context lines which may fire up a warning. So these lines need
to be changed as well to satisy checkpatch. But this new patch
will again include several context lines... until you have to fix up the
whole file. Or did I misunderstand?

bye  Fabi

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

Re: [U-Boot] Policy for checkpatch usage?

[Eric Cooper]

On Thu, Apr 21, 2011 at 04:56:36PM +0200, Fabian Cenedese wrote:
 Is that even possible? The cosmetic patch itself will be surrounded
 by context lines which may fire up a warning. So these lines need
 to be changed as well to satisy checkpatch. But this new patch
 will again include several context lines... until you have to fix up the
 whole file. Or did I misunderstand?

What's wrong with (cosmetically) fixing all the files that a patch
touches?  That way the project gets incremental cleanup of the code
base as it evolves.

(It would be easy to automate a check for whitespace-only patches to
ease the job of the custodians.  Line-breaking and other style changes
might still require eyeballing.)

-- 
Eric Cooper e c c @ c m u . e d u
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation

[Simon Glass]

On Wed, Apr 20, 2011 at 11:56 PM, Aneesh V ane...@ti.com wrote:
 Hi Simon, Wolfgang,

 On Thursday 21 April 2011 12:04 AM, Simon Glass wrote:

 On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUDalbert.arib...@free.fr
  wrote:

 Le 25/03/2011 17:12, Aneesh V a écrit :

 Another problem I have with relocation is that it makes debugging with
 JTAG debugers more difficult. The addresses of symbols in the ELF
 target are no longer valid. Of course, you can load the symbols at an
 offset from the original location. But one has to first enable debug
 prints, find the relocation offset, use it while loading the symbols
 before you can do source level debugging.

 Actually you don't need recompiling: simply set a breakpoint at the
 entry of relocate_code and once you hit the bp, look up r2: it contains
 the destination. If you want the offset rather than the absolute
 address, set the breakpoint right after the 'sub r9, r6, r0' round line
 222: r9 will then give you the offset. Unload the current symbols,
 reload the symbols with the relevant offset, and there you go.

 I would like to revisit this thread. I'm not sure how other people do
 development in U-Boot but I like to use an ICE and a source-level
 debugger for any significant effort. I think it should be possible to
 use a JTAG debugging just by loading the u-boot ELF file and running.

 With this patch (or something similar) this is possible. Without it,
 it is painful.

 To be clear, we are not talking here about creating a platform that
 doesn't use relocation, just that for development purposes it is
 convenient to be able to disable it.

 Actually, I am not even sure why relocation shouldn't be disabled in my
 platform for good. It may be useful to have things such as the frame
 buffer at the end of available memory. But, IMHO, that can still be
 done without relocating u-boot. That's what the patch does.Am I missing
 something?

Well relocation does remove a lot of this ad-hoc positioning of things
at compile time. I think it is desirable. My point is that it is not
engineer-friendly during development, and we should have an easy way
to disable it for debugging / JTAG purposes.

Regards,
Simon



 Looking at the December thread
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262

 Aneesh:

 Shouldn't we provide a CONFIG option by which users can disable
 Elf relocation?

 Wolfgang:

 Why should we?  It would just make the code even more complicated, and
 require a lot of additional test cases.

  From what I can see this is a new CONFIG option, two ifdefs in the
 board.c file, and optionally disabling the -pie position-independent
 executable option to reduce size. It is pretty trivial:

  arch/arm/config.mk   |    2 ++
  arch/arm/lib/board.c |    5 +
  2 files changed, 7 insertions(+), 0 deletions(-)

 Regards,
 Simon


 Amicalement,
 --
 Albert.
 ___
 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] Notification

[Western Union Money]

Confirm the receipt of $50,000 from western 
union by filling the details to the Transfer 
Manager Mr.Eddy James: 
WESTERN UNION WINNER BIODATAS Form
1. Name:
2. Address  
3. Country :
4. Phone Number
5. Occupation:
6. Sex :..
7. Age
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Detlev Zundel]

Hi Fabi,

 At 10:49 21.04.2011 -0400, Eric Cooper wrote:
On Thu, Apr 21, 2011 at 04:29:17PM +0200, Detlev Zundel wrote:
 What about the problem with checkpatch errors in current code, i.e. the
 origin of this sentence:
 
   Also warnings produced for context lines (i.e. existing code) rather
   than actual changes can also be ignored.

How about replacing it with this:

If you encounter warnings for existing code, not modified by your
patch, consider submitting a separate, cosmetic-only patch --
clearly described as such -- that *precedes* your substantive
patch.

 Is that even possible? The cosmetic patch itself will be surrounded
 by context lines which may fire up a warning. So these lines need
 to be changed as well to satisy checkpatch. But this new patch
 will again include several context lines... until you have to fix up the
 whole file. Or did I misunderstand?

It may become an iterative process.  Fortunately our source files are
finite, so this process has a fixpoint ;)

Cheers
  Detlev

-- 
debian is a prototype for a future version of emacs.
 -- Thien-Thi Nguyen in 7eekubiffq@ada2.unipv.it
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Detlev Zundel]

Hi Eric,

 On Thu, Apr 21, 2011 at 04:56:36PM +0200, Fabian Cenedese wrote:
 Is that even possible? The cosmetic patch itself will be surrounded
 by context lines which may fire up a warning. So these lines need
 to be changed as well to satisy checkpatch. But this new patch
 will again include several context lines... until you have to fix up the
 whole file. Or did I misunderstand?

 What's wrong with (cosmetically) fixing all the files that a patch
 touches?  That way the project gets incremental cleanup of the code
 base as it evolves.

Of course such a cleanup would be nice indeed, but I assume that many
people do not want to go this extra mile - alas I do not want to require
it.

 (It would be easy to automate a check for whitespace-only patches to
 ease the job of the custodians.  Line-breaking and other style changes
 might still require eyeballing.)

Like this?

#!/bin/sh

die() {
echo $@ 12
exit 1
}

if [ $# -lt 1 ]; then
die usage: `basename $0` patchname
fi

[ -z $(git status -s) ] || die Repository not clean - refusing to continue
git apply $1
if [ -n $(git diff -b) ]; then
	echo Patch contains non-whitespace changes:
	git diff -b
	ret=1
else
	echo Patch is only a cosmetic change
	ret=0
fi
git reset --hard

exit ${ret}

Cheers
  Detlev

-- 
Question: If you were redesigning UNIX, what would you do differently?
Ken Thompson: I'd spell creat with an e.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Detlev Zundel]

Hi Eric,

 On Thu, Apr 21, 2011 at 04:29:17PM +0200, Detlev Zundel wrote:
 What about the problem with checkpatch errors in current code, i.e. the
 origin of this sentence:
 
   Also warnings produced for context lines (i.e. existing code) rather
   than actual changes can also be ignored.

 How about replacing it with this:

Thanks for the input.  Current base for discussion:

  Checkpatch is a tool that can help you find some style problems, but
  is imperfect, and the things it complains about are of varying
  importance.  So use common sense in interpreting the results.

  Warnings that clearly only make sense in the Linux kernel can be
  ignored.  This includes Use #include linux/$file instead of
  asm/$file for example.
  
  If you encounter warnings for existing code, not modified by your
  patch, consider submitting a separate, cosmetic-only patch -- clearly
  described as such -- that *precedes* your substantive patch.

Anyone unhappy with that?  Will this help newcomers?

Happy easter everyone, and remember around easter some people like to
hide eggs, _not_ bugs ;)

  Detlev

-- 
Whenever you find yourself on the side of the majority it is
time to pause and reflect.
-- Mark Twain
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5] ARM: mx31: Print the silicon version

[Stefano Babic]

On 04/15/2011 08:07 PM, Stefano Babic wrote:
 On 04/12/2011 04:18 AM, Fabio Estevam wrote:
 Use the same method of the Linux kernel to print the MX31 silicon version on 
 boot.

 Tested on a MX31PDK with a 2.0 silicon, where it shows:

 CPU:   Freescale i.MX31 rev 2.0 at 531 MHz

 Signed-off-by: Fabio Estevam fabio.este...@freescale.com

 
 Applied to u-boot-imx, thanks.
 

Fabio,

I have not noted before that your patch introduce a warning:

generic.c: In function 'get_cpu_rev':
generic.c:131: warning: return discards qualifiers from pointer target type

This is due to the usage of the const in the mx3_cpu_type:

struct mx3_cpu_type {
u8 srev;
   const char *v;

Do you agree if I drop myself the const attribute on u-boot-imx before
pulling your patch to the arm tree ?

Regards,
Stefano

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

[U-Boot] [PATCH] MX31: drop warnings in get_cpu_rev

[Stefano Babic]

Drop warnings due to recent commit
ARM: mx31: Print the silicon version

Signed-off-by: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
---
 arch/arm/include/asm/arch-mx31/imx-regs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h 
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 7f2..c830a03 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -105,7 +105,7 @@ struct iim_regs {
 
 struct mx3_cpu_type {
u8 srev;
-   const char *v;
+   char *v;
 };
 
 #define IOMUX_PADNUM_MASK  0x1ff
-- 
1.7.1

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

Re: [U-Boot] Policy for checkpatch usage?

[Scott Wood]

On Thu, 21 Apr 2011 16:29:17 +0200
Detlev Zundel d...@denx.de wrote:

 Hi Scott,
 
  I vote for checkpatch is a tool that can help you find some style problems,
  but is imperfect, and the things it complains about are of varying
  importance.  If you insist on zero warnings, what's the difference between
  a warning and an error?  And will there then be a U-Boot-specific coding
  style document to match?  Will anyone that wants to submit a patch that
  checkpatch erroneously complains about have to first submit a patch for
  checkpatch (first learning Perl if need be)?
 
 So you would agree to this text:
 
   Checkpatch is a tool that can help you find some style problems, but is
   imperfect, and the things it complains about are of varying importance.
   So use common sense in interpreting the results.  Warnings that clearly
   only make sense in the Linux kernel can be ignored.  

Yes.

That said, if someone wants to maintain a U-Boot version, that'd be great.

 What about the problem with checkpatch errors in current code, i.e. the
 origin of this sentence:
 
   Also warnings produced for context lines (i.e. existing code) rather
   than actual changes can also be ignored.
 
 Do we want this?

That sounds like a bug in checkpatch, which should be reported.

But there's a similar issue of new code that is added in compliance with
the existing style in the file, which is slightly different from what
checkpatch wants.  I'd usually be inclined to stick with what's already in
the file, as long as it's not too ugly, rather than introduce inconsistency
or reformat a large chunk of code to accommodate a small addition.

-Scott

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

Re: [U-Boot] [PATCH] mtd/spi/macronix.c: add MX25L4005 and MX25L8005

[Mike Frysinger]

On Wed, Apr 20, 2011 at 10:51 PM, Macpaul Lin wrote:
 Add support of MX25L4005 and MX25L8005 according to the datasheet
 http://www.mct.net/download/macronix/mx25l8005.pdf

 This patch has been tested with MX25L4005 and MX25L8005

thanks, added to my sf branch
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: getramsize() prototype and volatile qualifier

[Mike Frysinger]

On Thu, Apr 21, 2011 at 3:09 AM, Albert ARIBAUD wrote:
 Call it a detail, but I see that get_ram_size() calls sometime qualify
 their argument as volatile and sometimes not, and this makes checkpatch
 complain that volatiles are Bad(tm), which I would like to get fixed.

 The prototype for get_ram_size() in is

        long    get_ram_size  (volatile long *, long);

 While I understand that the way get_ram_size() works, it needs to
 perform volatile *accesses* to addresses computed from its arguments, I
 don't see why it requires one of the arguments themselves to be volatile.

 Am I missing something here, particularly about some toolchain requiring
 the argument to be volatile? I see no reason it should, but better safe
 than sorry.

the argument isnt volatile, the memory it points to is.  since
get_ram_size() itself doesnt dereference the argument (only goes
through a local addr), the volatile marking in the prototype could
be dropped, but personally i dont see the point.  the prototype doesnt
require callers to add volatile markings to their own code, and i
could see someone using base in the future after the volatile being
dropped and people not noticing right away.  the current code is safe
and causes no problems by itself, so i see no value in changing it.

this sounds like useless gotta be checkpatch clean work by people
blindly following its output.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Mike Frysinger]

On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 --- a/include/spi.h
 +++ b/include/spi.h
  /* Controller-specific definitions: */

  /* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */
 -#ifdef CONFIG_MPC8XXX_SPI
 +#if defined(CONFIG_MPC8XXX_SPI) || defined(CONFIG_FSL_ESPI)
  # ifndef CONFIG_HARD_SPI
  #  define CONFIG_HARD_SPI
  # endif

i cant see why this PowerPC-specific code needs to be in the common
spi.h.  why cant this live in a PowerPC header like asm/config.h ?  (i
know this code predates asm/config.h)
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] powerpc: make espi can read more than 0xFFFA bytes

[Mike Frysinger]

On Thu, Apr 21, 2011 at 2:05 AM, Shaohui Xie wrote:
 espi flash read returns invalid data if the read length is more than 0xFFFA
 bytes, it supports maximum transaction of 2^16 bytes at a time, resister
 spcom[TRANLEN] is 16 bits. If the transaction length is greater than  0x,
 it need to be split into multiple transactions.

hrm, so how does this work under Linux ?  or does it just not ?
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx5: drop boot cause code from board support code

[Stefano Babic]

On 04/20/2011 12:47 PM, Jason Liu wrote:
 The boot cause code has been factor out to soc common
 code,we need drop the part from the board support code
 
 Signed-off-by: Jason Liu jason@linaro.org

Hi Jason,

 ---
  board/efikamx/efikamx.c   |   30 ++
  board/freescale/mx51evk/mx51evk.c |   26 ++
  board/freescale/mx53evk/mx53evk.c |   21 +
  board/ttcontrol/vision2/vision2.c |   28 ++--
  4 files changed, 19 insertions(+), 86 deletions(-)
 
 diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
 index f735260..0aef654 100644
 --- a/board/efikamx/efikamx.c
 +++ b/board/efikamx/efikamx.c
 @@ -644,46 +644,28 @@ int board_late_init(void)
  int checkboard(void)
  {
   u32 system_rev = get_cpu_rev();
 - u32 cause;
 - struct src *src_regs = (struct src *)SRC_BASE_ADDR;

This seems to me not the best solution. If we have now factored out code
to print the reset cause and the silicon version (inside print_cpuinfo),
why do we need to repeat this code for each board ? Calling get_cpu_rev
seems to me redundant (then each board should only set
CONFIG_DISPLAY_CPUINFO). And then the CPU revision is printed again, and
this is redundant.

  
   puts(Board: Efika MX );
  
   switch (system_rev  0xff) {

As I see in code, in system_rev  0xff we can find the cpu revision, and
the output is already part of print_cpuinfo.

I think we need more clean up, removing all part related to CPU revision
and leaving (if any) only the output related to the board revision.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V5 2/2] MX53: support for freescale MX53LOCO board

[Stefano Babic]

On 04/20/2011 12:47 PM, Jason Liu wrote:

 +int board_mmc_getcd(u8 *cd, struct mmc *mmc)
 +{
 + struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
 +
 + if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
 + *cd = mxc_gpio_get(77); /*GPIO3_13*/
 + else
 + *cd = mxc_gpio_get(75); /*GPIO3_11*/
 +
 + return 0;
 +}

Rereading the thread regarding this board I see there is an open
question issued by Wolfgang about this code, if accessors should be used
in this case. IMHO the code is correct, using the GPIO get function to
acquire the current value of a pin. Wolfgang, is it enough to answer
your question ? Do you see an open issue ?

 +/* PMIC Configs */
 +#define CONFIG_FSL_PMIC
 +#define CONFIG_FSL_PMIC_I2C
 +#define CONFIG_SYS_FSL_PMIC_I2C_ADDR8

If I am not confused, this setup is not valid as you already sent a
patchset to drop these lines and adding support for the DA9053 pmic.

PMIC: Add dialog pmic support
MX53: loco: Add power init support

As this patchset is based on the LOCO patch (this one), and it does not
apply anymore, please drop these lines and rebase your patches to add
pmic support on the actual state of the current patch.
IMHO it should be better if you resend them as a single patchset, as
they are strictly related, merging Add power init support inside this
patch.


 +#define CONFIG_SYS_MEMTEST_START   0x7000
 +#define CONFIG_SYS_MEMTEST_END 0x7001

There is still an open question about this range. Can you answer to
Wolfgang's question ?

Best regards,
Stefano

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

Re: [U-Boot] [PATCH v4 1/3] ARM: MX31: Fix file name label

[Stefano Babic]

On 04/16/2011 04:54 AM, Fabio Estevam wrote:
 Commit 5d2c154 (IMX: MX31: Cleanup include files and drop nasty #ifdef in 
 drivers)
 renamed mx31-imx-regs.h to imx-regs.h.
 
 Change the file label accordingly.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks.

Regards,
Stefano Babic


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

Re: [U-Boot] RFC: getramsize() prototype and volatile qualifier

[Albert ARIBAUD]

Le 21/04/2011 19:02, Mike Frysinger a écrit :
 On Thu, Apr 21, 2011 at 3:09 AM, Albert ARIBAUD wrote:
 Call it a detail, but I see that get_ram_size() calls sometime qualify
 their argument as volatile and sometimes not, and this makes checkpatch
 complain that volatiles are Bad(tm), which I would like to get fixed.

 The prototype for get_ram_size() in is

 longget_ram_size  (volatile long *, long);

 While I understand that the way get_ram_size() works, it needs to
 perform volatile *accesses* to addresses computed from its arguments, I
 don't see why it requires one of the arguments themselves to be volatile.

 Am I missing something here, particularly about some toolchain requiring
 the argument to be volatile? I see no reason it should, but better safe
 than sorry.

 the argument isnt volatile, the memory it points to is.  since
 get_ram_size() itself doesnt dereference the argument (only goes
 through a local addr), the volatile marking in the prototype could
 be dropped, but personally i dont see the point.  the prototype doesnt
 require callers to add volatile markings to their own code, and i
 could see someone using base in the future after the volatile being
 dropped and people not noticing right away.  the current code is safe
 and causes no problems by itself, so i see no value in changing it.

 this sounds like useless gotta be checkpatch clean work by people
 blindly following its output.
 -mike

Just because checkpatch complains about something does not mean that 
particular complaint is without merit. :)

Yes, the code works as it is; but it'll work just as well if volatile is 
removed from the prototype and calls, and that'll make the code simpler 
and more homogeneous overall, plus it'll give checkpatch one less cause 
for complaint. We gain something there, if not a functional plus, an 
overal quality plus.

As for people fiddling with get_ram_size() *body* and removing the 
volatile 'addr' and use the non-volatile 'base' directly, why would 
they? They will plainly see that 'addr' is volatile and 'base' is not 
(all the more because removing the volatile' attribute from 'base' will 
require casting it to 'base+int' where it belongs), and the very role of 
the function makes it clear to them that the volatile attribute is 
required for 'addr', so they'll keep 'addr'.

Plus, get_ram_size() is pretty stable -- actually, it has changed only 
once in 2006 since its creation in 2004.

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

Re: [U-Boot] [PATCH V5 1/2] MX5: factor out boot cause funciton to common code

[Stefano Babic]

On 04/20/2011 12:47 PM, Jason Liu wrote:
 factor out boot cause funciton to common code to avoid
 the duplicate code in each board support package
 
 Signed-off-by: Jason Liu jason@linaro.org
 ---
 change since v4:
 - make common code soc specific
 changes since v3:
 - add full boot reset cause
 ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] MX31: drop warnings in get_cpu_rev

[Stefano Babic]

On 04/21/2011 06:09 PM, Stefano Babic wrote:
 Drop warnings due to recent commit
 ARM: mx31: Print the silicon version
 
 Signed-off-by: Stefano Babic sba...@denx.de
 CC: Fabio Estevam fabio.este...@freescale.com
 ---

Applied directly to u-boot-imx, as fix.

regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Kumar Gala]

On Apr 21, 2011, at 12:10 PM, Mike Frysinger wrote:

 On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 --- a/include/spi.h
 +++ b/include/spi.h
 /* Controller-specific definitions: */
 
 /* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */
 -#ifdef CONFIG_MPC8XXX_SPI
 +#if defined(CONFIG_MPC8XXX_SPI) || defined(CONFIG_FSL_ESPI)
 # ifndef CONFIG_HARD_SPI
 #  define CONFIG_HARD_SPI
 # endif
 
 i cant see why this PowerPC-specific code needs to be in the common
 spi.h.  why cant this live in a PowerPC header like asm/config.h ?  (i
 know this code predates asm/config.h)
 -mike

If the rest of the patch looks fine we can move this into asm/config.h

There are a bunch of board patches I'd like to get in that depend on the base 
SPI driver being in tree.

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

[U-Boot] [PATCH] powerpc/85xx: handle both secX.Y and sec-vX.Y properties

[Kumar Gala]

From: Kim Phillips kim.phill...@freescale.com

versioned SEC properties changed names during development, so
for now search and update LIODNs for both secX.Y and
sec-vX.Y based properties.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/include/asm/fsl_liodn.h |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_liodn.h 
b/arch/powerpc/include/asm/fsl_liodn.h
index 0ec5c0a..801571f 100644
--- a/arch/powerpc/include/asm/fsl_liodn.h
+++ b/arch/powerpc/include/asm/fsl_liodn.h
@@ -115,10 +115,18 @@ extern void fdt_fixup_liodn(void *blob);
FM_PPID_RX_PORT_OFFSET(fmNum, enetNum + 16), \
CONFIG_SYS_FSL_FM##fmNum##_RX##enetNum##_10G_OFFSET) \
 
+/*
+ * handle both old and new versioned SEC properties:
+ * fsl,secX.Y became fsl,sec-vX.Y during development
+ */
 #define SET_SEC_JR_LIODN_ENTRY(jrNum, liodnA, liodnB) \
SET_LIODN_ENTRY_2(fsl,sec4.0-job-ring, liodnA, liodnB,\
offsetof(ccsr_sec_t, jrliodnr[jrNum].ls) + \
CONFIG_SYS_FSL_SEC_OFFSET, \
+   CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jrNum), \
+   SET_LIODN_ENTRY_2(fsl,sec-v4.0-job-ring, liodnA, liodnB,\
+   offsetof(ccsr_sec_t, jrliodnr[jrNum].ls) + \
+   CONFIG_SYS_FSL_SEC_OFFSET, \
CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jrNum)
 
 /* This is a bit evil since we treat rtic param as both a string  hex value */
@@ -127,6 +135,11 @@ extern void fdt_fixup_liodn(void *blob);
liodnA, \
offsetof(ccsr_sec_t, rticliodnr[0x##rtic-0xa].ls) + \
CONFIG_SYS_FSL_SEC_OFFSET, \
+   CONFIG_SYS_FSL_SEC_OFFSET + 0x6100 + 0x20 * (0x##rtic-0xa)), \
+   SET_LIODN_ENTRY_1(fsl,sec-v4.0-rtic-memory, \
+   liodnA, \
+   offsetof(ccsr_sec_t, rticliodnr[0x##rtic-0xa].ls) + \
+   CONFIG_SYS_FSL_SEC_OFFSET, \
CONFIG_SYS_FSL_SEC_OFFSET + 0x6100 + 0x20 * (0x##rtic-0xa))
 
 #define SET_SEC_DECO_LIODN_ENTRY(num, liodnA, liodnB) \
-- 
1.7.3.4

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

[U-Boot] [PATCH] powerpc/85xx: Enable ESDHC111 erratum on P2040/P3041/P5010/P5020 SoCs

[Kumar Gala]

From: Lei Xu b33...@freescale.com

The workaround for ESDHC111 should also be applied on
P2040/P3041/P5010/P5020 SoCs.

Signed-off-by: Lei Xu b33...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/include/asm/config_mpc85xx.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index d93586a..da2e998 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -266,6 +266,7 @@
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 
 #elif defined(CONFIG_PPC_P3041)
 #define CONFIG_MAX_CPUS4
@@ -279,6 +280,7 @@
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 
 #elif defined(CONFIG_PPC_P4040)
 #define CONFIG_MAX_CPUS4
@@ -323,6 +325,7 @@
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 
 #elif defined(CONFIG_PPC_P5020)
 #define CONFIG_MAX_CPUS2
@@ -336,6 +339,7 @@
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 
 #else
 #error Processor type not defined for this platform
-- 
1.7.3.4

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

[U-Boot] [PATCH 1/3] powerpc/85xx: Enable eSPI controller SPI bootsupport on P2020DS

[Kumar Gala]

From: Jerry Huang chang-ming.hu...@freescale.com

Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Zhao Chenhui b35...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 boards.cfg|1 +
 include/configs/P2020DS.h |   28 
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index be5f83d..39f15f6 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -537,6 +537,7 @@ P2020DS  powerpc mpc85xx 
p2020ds freesca
 P2020DS_36BITpowerpc mpc85xx p2020ds 
freescale  -   P2020DS:36BIT
 P2020DS_DDR2 powerpc mpc85xx p2020ds 
freescale  -   P2020DS:DDR2
 P2020DS_SDCARD   powerpc mpc85xx p2020ds 
freescale  -   P2020DS:SDCARD
+P2020DS_SPIFLASH powerpc mpc85xx p2020ds 
freescale  -   P2020DS:SPIFLASH
 P2020RDB powerpc mpc85xx p1_p2_rdb   
freescale  -   P1_P2_RDB:P2020RDB
 P2020RDB_36BIT   powerpc mpc85xx p1_p2_rdb   
freescale  -   P1_P2_RDB:P2020RDB,36BIT
 P2020RDB_36BIT_SDCARDpowerpc mpc85xx p1_p2_rdb   
freescale  -   P1_P2_RDB:P2020RDB,36BIT,SDCARD
diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h
index 47f1f18..cee9fd4 100644
--- a/include/configs/P2020DS.h
+++ b/include/configs/P2020DS.h
@@ -40,6 +40,13 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0xf8fc
 #endif
 
+#ifdef CONFIG_SPIFLASH
+#define CONFIG_SYS_RAMBOOT
+#define CONFIG_SYS_EXTRA_ENV_RELOC
+#define CONFIG_SYS_TEXT_BASE   0xf8f8
+#define CONFIG_RESET_VECTOR_ADDRESS0xf8fc
+#endif
+
 /* High Level Configuration Options */
 #define CONFIG_BOOKE   1   /* BOOKE */
 #define CONFIG_E5001   /* BOOKE e500 family */
@@ -418,6 +425,18 @@
 #define CONFIG_SYS_EEPROM_BUS_NUM  0
 
 /*
+ * eSPI - Enhanced SPI
+ */
+#define CONFIG_FSL_ESPI
+
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+
+#define CONFIG_CMD_SF
+#define CONFIG_SF_DEFAULT_SPEED1000
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+
+/*
  * General PCI
  * Memory space is mapped 1-1, but I/O space must start from 0.
  */
@@ -594,6 +613,15 @@
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_ENV_SIZE0x2000
 #define CONFIG_SYS_MMC_ENV_DEV 0
+#elif defined(CONFIG_SPIFLASH)
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_SPI_BUS 0
+#define CONFIG_ENV_SPI_CS  0
+#define CONFIG_ENV_SPI_MAX_HZ  1000
+#define CONFIG_ENV_SPI_MODE0
+#define CONFIG_ENV_SIZE0x2000  /* 8KB */
+#define CONFIG_ENV_OFFSET  0x10/* 1MB */
+#define CONFIG_ENV_SECT_SIZE   0x1
 #else
 #define CONFIG_ENV_IS_IN_FLASH 1
 #if CONFIG_SYS_MONITOR_BASE  0xfff8
-- 
1.7.3.4

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

[U-Boot] [PATCH 2/3] powerpc/85xx: Enable eSPI support for p1_p2_rdb

[Kumar Gala]

From: Priyanka Jain priyanka.j...@freescale.com

Also added support to save env to spi flash in case of SPIBOOT.

Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 include/configs/P1_P2_RDB.h |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 449329a..9249e37 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -411,6 +411,15 @@ extern unsigned long get_board_sys_clk(unsigned long 
dummy);
 #define CONFIG_RTC_DS1337
 #define CONFIG_SYS_RTC_DS1337_NOOSC
 #define CONFIG_SYS_I2C_RTC_ADDR0x68
+
+/* eSPI - Enhanced SPI */
+#define CONFIG_FSL_ESPI
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_CMD_SF
+#define CONFIG_SF_DEFAULT_SPEED1000
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
+
 /*
  * General PCI
  * Memory space is mapped 1-1, but I/O space must start from 0.
@@ -527,8 +536,13 @@ extern unsigned long get_board_sys_clk(unsigned long 
dummy);
 #define CONFIG_ENV_SIZE0x2000
 #define CONFIG_SYS_MMC_ENV_DEV 0
 #elif defined(CONFIG_RAMBOOT_SPIFLASH)
-   #define CONFIG_ENV_IS_NOWHERE   1   /* Store ENV in memory only */
-   #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000)
+   #define CONFIG_ENV_IS_IN_SPI_FLASH
+   #define CONFIG_ENV_SPI_BUS  0
+   #define CONFIG_ENV_SPI_CS   0
+   #define CONFIG_ENV_SPI_MAX_HZ   1000
+   #define CONFIG_ENV_SPI_MODE 0
+   #define CONFIG_ENV_OFFSET   0x10/* 1MB */
+   #define CONFIG_ENV_SECT_SIZE0x1
#define CONFIG_ENV_SIZE 0x2000
 #endif
 #else
-- 
1.7.3.4

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

[U-Boot] [PATCH] powerpc/85xx: Change timebase divisor to be defined per processor

[Kumar Gala]

Introduce new CONFIG_SYS_FSL_TBCLK_DIV on 85xx platforms because
different SoCs have different divisor amounts.  All the PQ3 parts are
/8, the P4080/P4080 is /16, and P2040/P3041/P5020 are /32.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/cpu/mpc85xx/cpu.c|   11 ++-
 arch/powerpc/include/asm/config_mpc85xx.h |6 ++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index f5b39c0..f863f4a 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -234,13 +234,14 @@ int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
 /*
  * Get timebase clock frequency
  */
+#ifndef CONFIG_SYS_FSL_TBCLK_DIV
+#define CONFIG_SYS_FSL_TBCLK_DIV 8
+#endif
 unsigned long get_tbclk (void)
 {
-#ifdef CONFIG_FSL_CORENET
-   return (gd-bus_clk + 8) / 16;
-#else
-   return (gd-bus_clk + 4UL)/8UL;
-#endif
+   unsigned long tbclk_div = CONFIG_SYS_FSL_TBCLK_DIV;
+
+   return (gd-bus_clk + (tbclk_div  1)) / tbclk_div;
 }
 
 
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index da2e998..d71c3fc 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -264,6 +264,7 @@
 #define CONFIG_SYS_NUM_FM1_DTSEC   5
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   32
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -278,6 +279,7 @@
 #define CONFIG_SYS_NUM_FM1_10GEC   1
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   32
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -288,6 +290,7 @@
 #define CONFIG_SYS_FSL_NUM_LAWS32
 #define CONFIG_SYS_FSL_SEC_COMPAT  4
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   16
 
 #elif defined(CONFIG_PPC_P4080)
 #define CONFIG_MAX_CPUS8
@@ -301,6 +304,7 @@
 #define CONFIG_SYS_NUM_FM2_10GEC   1
 #define CONFIG_NUM_DDR_CONTROLLERS 2
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   16
 #define CONFIG_SYS_FSL_ERRATUM_CPC_A002
 #define CONFIG_SYS_FSL_ERRATUM_CPC_A003
 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003
@@ -323,6 +327,7 @@
 #define CONFIG_SYS_NUM_FM1_10GEC   1
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   32
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -337,6 +342,7 @@
 #define CONFIG_SYS_NUM_FM1_10GEC   1
 #define CONFIG_NUM_DDR_CONTROLLERS 2
 #define CONFIG_SYS_FM_MURAM_SIZE   0x28000
+#define CONFIG_SYS_FSL_TBCLK_DIV   32
 #define CONFIG_SYS_FSL_USB1_PHY_ENABLE
 #define CONFIG_SYS_FSL_USB2_PHY_ENABLE
 #define CONFIG_SYS_FSL_ERRATUM_ESDHC111
-- 
1.7.3.4

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

Re: [U-Boot] [PATCH 1/3] powerpc/85xx: Enable eSPI controller SPI bootsupport on P2020DS

[Scott Wood]

On Thu, 21 Apr 2011 13:54:01 -0500
Kumar Gala ga...@kernel.crashing.org wrote:

 From: Jerry Huang chang-ming.hu...@freescale.com
 
 Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
 Signed-off-by: Zhao Chenhui b35...@freescale.com
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
  boards.cfg|1 +
  include/configs/P2020DS.h |   28 
  2 files changed, 29 insertions(+), 0 deletions(-)
 
 diff --git a/boards.cfg b/boards.cfg
 index be5f83d..39f15f6 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -537,6 +537,7 @@ P2020DS  powerpc mpc85xx 
 p2020ds freesca
  P2020DS_36BITpowerpc mpc85xx p2020ds 
 freescale  -   P2020DS:36BIT
  P2020DS_DDR2 powerpc mpc85xx p2020ds 
 freescale  -   P2020DS:DDR2
  P2020DS_SDCARD   powerpc mpc85xx p2020ds 
 freescale  -   P2020DS:SDCARD
 +P2020DS_SPIFLASH powerpc mpc85xx p2020ds 
 freescale  -   P2020DS:SPIFLASH

36BIT+SPIFLASH?

If it's not working, perhaps a comment about it?

-Scott

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

[U-Boot] [PATCH] MX31: Make get_cpu_rev() and get_reset_cause() static

[Fabio Estevam]

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 arch/arm/cpu/arm1136/mx31/generic.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm1136/mx31/generic.c 
b/arch/arm/cpu/arm1136/mx31/generic.c
index 18572b9..c17c738 100644
--- a/arch/arm/cpu/arm1136/mx31/generic.c
+++ b/arch/arm/cpu/arm1136/mx31/generic.c
@@ -118,7 +118,7 @@ struct mx3_cpu_type mx31_cpu_type[] = {
{ .srev = 0x29, .v = 2.0  },
 };
 
-char *get_cpu_rev(void)
+static char *get_cpu_rev(void)
 {
u32 i, srev;
 
@@ -132,7 +132,7 @@ char *get_cpu_rev(void)
return unknown;
 }
 
-char *get_reset_cause(void)
+static char *get_reset_cause(void)
 {
/* read RCSR register from CCM module */
struct clock_control_regs *ccm =
-- 
1.6.0.4

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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Mike Frysinger]

On Thu, Apr 21, 2011 at 2:13 PM, Kumar Gala wrote:
 On Apr 21, 2011, at 12:10 PM, Mike Frysinger wrote:
 On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 --- a/include/spi.h
 +++ b/include/spi.h
 /* Controller-specific definitions: */

 /* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */
 -#ifdef CONFIG_MPC8XXX_SPI
 +#if defined(CONFIG_MPC8XXX_SPI) || defined(CONFIG_FSL_ESPI)
 # ifndef CONFIG_HARD_SPI
 #  define CONFIG_HARD_SPI
 # endif

 i cant see why this PowerPC-specific code needs to be in the common
 spi.h.  why cant this live in a PowerPC header like asm/config.h ?  (i
 know this code predates asm/config.h)

 If the rest of the patch looks fine we can move this into asm/config.h

 There are a bunch of board patches I'd like to get in that depend on the base 
 SPI driver being in tree.

i dont run spi drivers through my tree, so generally if the arch
maintainer is happy with it, it's up to them to merge it.  i watch
over the spi core and the spi flash pieces, and sometimes give
feedback on the specific spi drivers.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Mike Frysinger]

On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 +struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
 +               unsigned int max_hz, unsigned int mode)
 +{
 +   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);

you support just one bus ?  that's no fun ;).

 +       /* Enable eSPI interface */
 +       out_be32(espi-mode, ESPI_MODE_RXTHR(3)
 +                       | ESPI_MODE_TXTHR(4) | ESPI_MODE_EN);
 +
 +       out_be32(espi-event, 0x); /* Clear all eSPI events */
 +       out_be32(espi-mask, 0x); /* Mask  all eSPI interrupts */
 +
 +       /* Init CS mode interface */
 +       for (i = 0; i  ESPI_MAX_CS_NUM; i++)
 +               out_be32(espi-csmode[i], ESPI_CSMODE_INIT_VAL);
 +
 +       out_be32(espi-csmode[cs], in_be32(espi-csmode[cs]) 
 +               ~(ESPI_CSMODE_PM(0xF) | ESPI_CSMODE_DIV16
 +               | ESPI_CSMODE_CI_INACTIVEHIGH | ESPI_CSMODE_CP_BEGIN_EDGCLK
 +               | ESPI_CSMODE_REV_MSB_FIRST | ESPI_CSMODE_LEN(0xF)));
 

usually spi_setup_slave() is to get the slave client ready to be used.
 it shouldnt be programming any actual hardware registers.  that is
the point of the spi_claim_bus() and spi_release_bus() steps ... use
the information in the slave state to setup the hardware for that
slave and then break it down in the release step.

 +static u8 cmd_buf[16];
 +static size_t cmd_len;
 +static size_t data_len;
 +
 +int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void 
 *data_out,
 +               void *data_in, unsigned long flags)
 +{
 +       ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +       unsigned int tmpdout, tmpdin, event;
 +       const void *dout = NULL;
 +       void *din = NULL;
 +       unsigned int len;
 +       int numBlks;
 +       int num_bytes;
 +       unsigned char *ch;
 +       unsigned char *buffer;
 +       size_t buf_len;
 +
 +       switch (flags) {
 +       case SPI_XFER_BEGIN:
 +               cmd_len = bitlen / 8;
 +               memcpy(cmd_buf, data_out, cmd_len);
 +               return 0;

interesting solution to the problem, but i'd think it might make more
sense to have this state live in the slave data rather than in the
global bus.

 +void spi_cs_activate(struct spi_slave *slave)
 +{
 +       ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +       unsigned int com = 0;
 +
 +       com = ~(ESPI_COM_CS(0x3) | ESPI_COM_TRANLEN(0x));
 +       com |= ESPI_COM_CS(slave-cs);
 +       com |= ESPI_COM_TRANLEN(data_len - 1);
 +       out_be32(espi-com, com);
 +
 +       return;
 +}

that return is useless and can be punted
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: getramsize() prototype and volatile qualifier

[Mike Frysinger]

On Thu, Apr 21, 2011 at 1:50 PM, Albert ARIBAUD wrote:
 Le 21/04/2011 19:02, Mike Frysinger a écrit :
 On Thu, Apr 21, 2011 at 3:09 AM, Albert ARIBAUD wrote:
 Call it a detail, but I see that get_ram_size() calls sometime qualify
 their argument as volatile and sometimes not, and this makes checkpatch
 complain that volatiles are Bad(tm), which I would like to get fixed.

 The prototype for get_ram_size() in is

        long    get_ram_size  (volatile long *, long);

 While I understand that the way get_ram_size() works, it needs to
 perform volatile *accesses* to addresses computed from its arguments, I
 don't see why it requires one of the arguments themselves to be volatile.

 Am I missing something here, particularly about some toolchain requiring
 the argument to be volatile? I see no reason it should, but better safe
 than sorry.

 the argument isnt volatile, the memory it points to is.  since
 get_ram_size() itself doesnt dereference the argument (only goes
 through a local addr), the volatile marking in the prototype could
 be dropped, but personally i dont see the point.  the prototype doesnt
 require callers to add volatile markings to their own code, and i
 could see someone using base in the future after the volatile being
 dropped and people not noticing right away.  the current code is safe
 and causes no problems by itself, so i see no value in changing it.

 this sounds like useless gotta be checkpatch clean work by people
 blindly following its output.

 Just because checkpatch complains about something does not mean that
 particular complaint is without merit. :)

like ive said many times, checkpatch clean is not a hard rule.
review the output to see when it makes sense.  the general volatile
is bad check is there because people often screw it up.  this is not
one of those cases ... we absolutely want volatile accesses.

 Yes, the code works as it is; but it'll work just as well if volatile is
 removed from the prototype and calls

uhh, there is no volatile in calls.  there is no requirement that
the call sites also use volatile markings.

, and that'll make the code simpler and more homogeneous overall

i think you missed a fairly important qualifier.  this is your
opinion, and one i dont share in this particular instance.

 plus it'll give checkpatch one less cause for complaint. We gain
 something there, if not a functional plus, an overal quality plus.

there is absolutely no quality difference

 As for people fiddling with get_ram_size() *body* and removing the volatile
 'addr' and use the non-volatile 'base' directly, why would they?

i have no idea.  i leave the door open to things that i dont happen to
think of rather than assuming absolutes.

 They will plainly see that 'addr' is volatile and 'base' is not

this sort of blind assumption is dangerous.  things that are plain to
you doesnt mean it's plain to everyone, and people make mistakes all
the time.  keeping the volatile markings on base protects from that
sort of screw up.

 (all the more because removing the volatile' attribute from 'base' will
 require casting it to 'base+int' where it belongs)

i dont know what you're talking about here ... there is no need for
casting regardless of the volatile markings of base.  casting is need
to ignore warnings when casting down from volatile to non-volatile,
not the other way around.  which is not the case here.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Mainlining android fastboot support to upstream u-boot

[Wolfgang Denk]

Dear John Rigby,

In message banlktikmfdknysqnoe6kvgjpdk2buxt...@mail.gmail.com you wrote:

  If you are discussing requirements for U-Boot, and plan to get these
  merged in to mainlineU-Boot one day, it would probably be a good idea
  to discuss these plans on the U-Boot mailing list as well - ideally
  before any design is cast in iron.
...

 As you can see from this discussion, Linaro is considering applying
 resources (probably me) to upstreaming Android Fastboot features into
 mainline u-boot.  What suggestions do you have for making this process
 as painless as possible?

I already wrote this above: discuss the _design_ early with the
respective community. Don't define some design and implement it and
then confront the community with your solution which you consider
ready at this point: this is guaranteed to cause frustration, because
you think you are done but we may think the design should be done
differently and ask you to restart from scratch.

 An implementation exists for omap4/panda on gitorious:
 git://gitorious.org/pandaboard/u-boot.git in the omap4_panda_es2.0
 branch.  There is also a version for omap3 somewhere else on
 gitorious.

Ah, cool.  So we already have the situation I warned about above.

 To bring this to mainline one would have to:
 
 1) Bring code up to current mainline revision.
 2) Fix any coding standards issues.
 3) Document the new features.
 
 What else?  I know one issue maybe why does this need to exist when
 other solutions exist.  I think that since Android uses it, it is
 somewhat of a de facto standard.
 
Oh. Android uses it. It must be The Right Thing (TM), then, I guess.
Probably like some of the Linux kernel code they use.

This is the killer argument I really like. Thank you very much.

I don't exactly feel motivated to accept just any stuff just because
company A or project B uses it (even if they appear to be really
big), or because already lots of efforts have been spent to implement
something.  On contrary.  Usually an argumentation like that means
that the design or the implementation are poor. Often both are.

It's 14 years or so that ESR formulated the RERO principle of
software development; one could really think this is time enough to
sink in.  Alas, I know I'm an optimist...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's not an optical illusion, it just looks like one.   -- Phil White
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5 2/2] MX53: support for freescale MX53LOCO board

[Wolfgang Denk]

Dear Stefano Babic,

In message 4db06cbe.8050...@denx.de you wrote:
 On 04/20/2011 12:47 PM, Jason Liu wrote:
 
  +int board_mmc_getcd(u8 *cd, struct mmc *mmc)
  +{
  +   struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
  +
  +   if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
  +   *cd = mxc_gpio_get(77); /*GPIO3_13*/
  +   else
  +   *cd = mxc_gpio_get(75); /*GPIO3_11*/
  +
  +   return 0;
  +}
 
 Rereading the thread regarding this board I see there is an open
 question issued by Wolfgang about this code, if accessors should be used
 in this case. IMHO the code is correct, using the GPIO get function to
 acquire the current value of a pin. Wolfgang, is it enough to answer
 your question ? Do you see an open issue ?

I was just asking.


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 all else fails, read the instructions.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: don't panic if no flash is there

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message 20110418094025.gc11...@bee.dooz.org you wrote:
  Would it be possible to introduce a QEMU Versatile board in U-Boot
  derived from the regular Versatile board's config?  It would disable
  the things that aren't (yet) supported in QEMU or too painful to
  support.

Sure.  Please feel free to submit a patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It became apparent that one reason why the Ice Giants were  known  as
the  Ice  Giants  was  because they were, well, giants. The other was
that they were made of ice.  -Terry Pratchett, _Sourcery_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/5] Add Ethernet hardware MAC address framework to usbnet

[Wolfgang Denk]

Dear Simon Glass,

In message banlktikgucjpun2rhs2t2nyq4_kb9gk...@mail.gmail.com you wrote:

  + eth = usb_eth[usb_max_eth_dev].eth_dev;
 
  Index for eth is usb_max_eth_dev.
 
  @@ -100,7 +102,10 @@ static void probe_valid_drivers(struct usb_device * 
  dev)
 * call since eth_current_ changed (internally 
  called)
 * relies on it
 */
  - eth_register(usb_eth[usb_max_eth_dev - 1].eth_dev);
  + eth_register(eth);
 
  You change the behaviour here.  Please confirmt his is really
  intentional.

 Yes. Since I am using an 'eth' pointer I don't need to index the array
 again. The behaviour is the same as before.

No, it is not.  Before, we were accessing entry N-1 here. Now we use
entry N.  usb_max_eth_dev != usb_max_eth_dev - 1

  + *   base_name - base name for device (NULL for eth)
 
  This is an atitifical decision for the API which is difficult to
  understand.  It just makes the code and understanding it more
  difficult.  Just pass eth when you mean it.

 The intention was to avoid everyone having to pass the correct value -
 potential for error, etc. I could have created a #define, but decided
 on this.

Ummm... but having everyone to pass the correct value is actually a
really good thing to have!


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 a child is taught ... its programmed with simple instructions --
and at some point, if its mind develops properly, it exceeds the  sum
of what it was taught, thinks independently.
-- Dr. Richard Daystrom, The Ultimate Computer,
   stardate 4731.3.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] Add support for SMSC95XX USB 2.0 10/100MBit Ethernet Adapter

[Wolfgang Denk]

Dear Simon Glass,

In message BANLkTin=5wsszPvwDW_q=Vb44ep0zmP=k...@mail.gmail.com you wrote:
 
 Thanks, yes - have done a better rebase so can test properly now.
 (where do I get ppc_8xx-gcc so I can use MAKEALL?)

ELDK is your friend.

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
God is real, unless declared integer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Policy for checkpatch usage?

[Graeme Russ]

On 22/04/11 02:10, Scott Wood wrote:
 On Thu, 21 Apr 2011 16:29:17 +0200
 Detlev Zundel d...@denx.de wrote:
 
 Hi Scott,

 I vote for checkpatch is a tool that can help you find some style problems,
 but is imperfect, and the things it complains about are of varying
 importance.  If you insist on zero warnings, what's the difference between
 a warning and an error?  And will there then be a U-Boot-specific coding
 style document to match?  Will anyone that wants to submit a patch that
 checkpatch erroneously complains about have to first submit a patch for
 checkpatch (first learning Perl if need be)?

 So you would agree to this text:

   Checkpatch is a tool that can help you find some style problems, but is
   imperfect, and the things it complains about are of varying importance.
   So use common sense in interpreting the results.  Warnings that clearly
   only make sense in the Linux kernel can be ignored.  
 
 Yes.
 
 That said, if someone wants to maintain a U-Boot version, that'd be great.

So, if someone maintains a U-Boot fork of checkpatch, keeps it up-to-date
with the Linux version, and pushes patches back up to Linux (to keep them
is sync as much as practicable possible) would we agree that that would be
the most favoured solution?

I'm looking at checkpatch now (and its change history) - If I think I can
take it on, I will send out a call for U-Boot specific checkpatch features

Regards,

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

Re: [U-Boot] [PATCH v4 2/5] Add Ethernet hardware MAC address framework to usbnet

[Simon Glass]

On Thu, Apr 21, 2011 at 4:38 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message banlktikgucjpun2rhs2t2nyq4_kb9gk...@mail.gmail.com you wrote:

  +             eth = usb_eth[usb_max_eth_dev].eth_dev;
 
  Index for eth is usb_max_eth_dev.
 
  @@ -100,7 +102,10 @@ static void probe_valid_drivers(struct usb_device * 
  dev)
                         * call since eth_current_ changed (internally 
  called)
                         * relies on it
                         */
  -                     eth_register(usb_eth[usb_max_eth_dev - 1].eth_dev);
  +                     eth_register(eth);
 
  You change the behaviour here.  Please confirmt his is really
  intentional.

 Yes. Since I am using an 'eth' pointer I don't need to index the array
 again. The behaviour is the same as before.

 No, it is not.  Before, we were accessing entry N-1 here. Now we use
 entry N.  usb_max_eth_dev != usb_max_eth_dev - 1

Hi Wolfgang,

Hmmm. If you see the usb_max_eth_dev++ below, it is increasing the
index variable to keep eth_register() happy. I have kept that
behaviour.

So let's say usb_max_eth_dev is 3. The sequence is:

- set eth to point to item 3
- increase usb_max_eth_dev to 4 as required by eth_register()
- call eth_register() with item 3 (i.e. eth pointer hasn't changed)
- call eth_write_hwaddr with item 3

Maybe look at the whole code with my patch applied?

Let me know if I am missing something.

+   eth)) {
   /* found proper driver */
   /* register with networking stack */
   usb_max_eth_dev++;
@@ -100,7 +102,10 @@ static void probe_valid_drivers(struct usb_device *dev)
* call since eth_current_changed (internally called)
* relies on it
*/
-   eth_register(usb_eth[usb_max_eth_dev - 1].eth_dev);
+   eth_register(eth);
+   if (eth_write_hwaddr(eth, usbeth,
+   usb_max_eth_dev - 1))
+   puts(Warning: failed to set MAC address\n);
   break;
   }


  + *   base_name - base name for device (NULL for eth)
 
  This is an atitifical decision for the API which is difficult to
  understand.  It just makes the code and understanding it more
  difficult.  Just pass eth when you mean it.

 The intention was to avoid everyone having to pass the correct value -
 potential for error, etc. I could have created a #define, but decided
 on this.

 Ummm... but having everyone to pass the correct value is actually a
 really good thing to have!

OK fair enough, it is in there now.

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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Kumar Gala]

On Apr 21, 2011, at 4:25 PM, Mike Frysinger wrote:

 On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 +struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
 +   unsigned int max_hz, unsigned int mode)
 +{
 +   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 
 you support just one bus ?  that's no fun ;).

Until our SoC guys actually build a device with more than one, we'll keep with 
the one.
 
 +   /* Enable eSPI interface */
 +   out_be32(espi-mode, ESPI_MODE_RXTHR(3)
 +   | ESPI_MODE_TXTHR(4) | ESPI_MODE_EN);
 +
 +   out_be32(espi-event, 0x); /* Clear all eSPI events */
 +   out_be32(espi-mask, 0x); /* Mask  all eSPI interrupts */
 +
 +   /* Init CS mode interface */
 +   for (i = 0; i  ESPI_MAX_CS_NUM; i++)
 +   out_be32(espi-csmode[i], ESPI_CSMODE_INIT_VAL);
 +
 +   out_be32(espi-csmode[cs], in_be32(espi-csmode[cs]) 
 +   ~(ESPI_CSMODE_PM(0xF) | ESPI_CSMODE_DIV16
 +   | ESPI_CSMODE_CI_INACTIVEHIGH | ESPI_CSMODE_CP_BEGIN_EDGCLK
 +   | ESPI_CSMODE_REV_MSB_FIRST | ESPI_CSMODE_LEN(0xF)));
 
 
 usually spi_setup_slave() is to get the slave client ready to be used.
 it shouldnt be programming any actual hardware registers.  that is
 the point of the spi_claim_bus() and spi_release_bus() steps ... use
 the information in the slave state to setup the hardware for that
 slave and then break it down in the release step.
 
 +static u8 cmd_buf[16];
 +static size_t cmd_len;
 +static size_t data_len;
 +
 +int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void 
 *data_out,
 +   void *data_in, unsigned long flags)
 +{
 +   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +   unsigned int tmpdout, tmpdin, event;
 +   const void *dout = NULL;
 +   void *din = NULL;
 +   unsigned int len;
 +   int numBlks;
 +   int num_bytes;
 +   unsigned char *ch;
 +   unsigned char *buffer;
 +   size_t buf_len;
 +
 +   switch (flags) {
 +   case SPI_XFER_BEGIN:
 +   cmd_len = bitlen / 8;
 +   memcpy(cmd_buf, data_out, cmd_len);
 +   return 0;
 
 interesting solution to the problem, but i'd think it might make more
 sense to have this state live in the slave data rather than in the
 global bus.
 
 +void spi_cs_activate(struct spi_slave *slave)
 +{
 +   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +   unsigned int com = 0;
 +
 +   com = ~(ESPI_COM_CS(0x3) | ESPI_COM_TRANLEN(0x));
 +   com |= ESPI_COM_CS(slave-cs);
 +   com |= ESPI_COM_TRANLEN(data_len - 1);
 +   out_be32(espi-com, com);
 +
 +   return;
 +}
 
 that return is useless and can be punted

- k


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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Kumar Gala]

On Apr 21, 2011, at 4:20 PM, Mike Frysinger wrote:

 On Thu, Apr 21, 2011 at 2:13 PM, Kumar Gala wrote:
 On Apr 21, 2011, at 12:10 PM, Mike Frysinger wrote:
 On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 --- a/include/spi.h
 +++ b/include/spi.h
 /* Controller-specific definitions: */
 
 /* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */
 -#ifdef CONFIG_MPC8XXX_SPI
 +#if defined(CONFIG_MPC8XXX_SPI) || defined(CONFIG_FSL_ESPI)
 # ifndef CONFIG_HARD_SPI
 #  define CONFIG_HARD_SPI
 # endif
 
 i cant see why this PowerPC-specific code needs to be in the common
 spi.h.  why cant this live in a PowerPC header like asm/config.h ?  (i
 know this code predates asm/config.h)
 
 If the rest of the patch looks fine we can move this into asm/config.h
 
 There are a bunch of board patches I'd like to get in that depend on the 
 base SPI driver being in tree.
 
 i dont run spi drivers through my tree, so generally if the arch
 maintainer is happy with it, it's up to them to merge it.  i watch
 over the spi core and the spi flash pieces, and sometimes give
 feedback on the specific spi drivers.
 -mike

Ok, I'll take it via my tree, but would like your ack on the patch.

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

Re: [U-Boot] Mainlining android fastboot support to upstream u-boot

[Zach Pfeffer]

 What else?  I know one issue maybe why does this need to exist when
 other solutions exist.  I think that since Android uses it, it is
 somewhat of a de facto standard.

 Oh. Android uses it. It must be The Right Thing (TM), then, I guess.
 Probably like some of the Linux kernel code they use.

 This is the killer argument I really like. Thank you very much.

So, Google uses it aside, it seems that being able to boot via USB
is a useful thing and fastboot is a particular solution; I'm not
entirely sure what other USB u-boot extensions exist apart from those
already mentioned. I find u-boot great and think being able to use USB
instead of a serial port would help adoption. Perhaps we can do away
with fastboot if u-boot had USB support?

 I don't exactly feel motivated to accept just any stuff just because
 company A or project B uses it (even if they appear to be really
 big), or because already lots of efforts have been spent to implement
 something.  On contrary.  Usually an argumentation like that means
 that the design or the implementation are poor. Often both are.

 It's 14 years or so that ESR formulated the RERO principle of
 software development; one could really think this is time enough to
 sink in.  Alas, I know I'm an optimist...

Of course part of RERO is listen to your customers. With the end of
native serial port inclusion on most systems and the proliferation of
USB, it seems that something could be done to the benefit of all.
Actually, it would be kind of cool to have some low level USB config
in u-boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5 2/2] MX53: support for freescale MX53LOCO board

[Jason Hui]

Hi, Stefano,

On Fri, Apr 22, 2011 at 1:43 AM, Stefano Babic sba...@denx.de wrote:
 On 04/20/2011 12:47 PM, Jason Liu wrote:

 +int board_mmc_getcd(u8 *cd, struct mmc *mmc)
 +{
 +     struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
 +
 +     if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
 +             *cd = mxc_gpio_get(77); /*GPIO3_13*/
 +     else
 +             *cd = mxc_gpio_get(75); /*GPIO3_11*/
 +
 +     return 0;
 +}

 Rereading the thread regarding this board I see there is an open
 question issued by Wolfgang about this code, if accessors should be used
 in this case. IMHO the code is correct, using the GPIO get function to
 acquire the current value of a pin. Wolfgang, is it enough to answer
 your question ? Do you see an open issue ?

 +/* PMIC Configs */
 +#define CONFIG_FSL_PMIC
 +#define CONFIG_FSL_PMIC_I2C
 +#define CONFIG_SYS_FSL_PMIC_I2C_ADDR    8

 If I am not confused, this setup is not valid as you already sent a
 patchset to drop these lines and adding support for the DA9053 pmic.

        PMIC: Add dialog pmic support
        MX53: loco: Add power init support

 As this patchset is based on the LOCO patch (this one), and it does not
 apply anymore, please drop these lines and rebase your patches to add
 pmic support on the actual state of the current patch.
 IMHO it should be better if you resend them as a single patchset, as
 they are strictly related, merging Add power init support inside this
 patch.

OK, I will resend the patchset as the following layout:

MX5: clock: Add clock config interface
MX5: factor out boot cause funciton to common code
PMIC: Add dialog pmic support
MX53: support for freescale MX53LOCO board (merge Add power init support)

I will rebase on the u-boot-imx git, do you think is it OK?



 +#define CONFIG_SYS_MEMTEST_START       0x7000
 +#define CONFIG_SYS_MEMTEST_END         0x7001

 There is still an open question about this range. Can you answer to
 Wolfgang's question ?

In fact, I want to give one simple test range when use mtest, I don't know
what you are worrying about, please tell it clearly?


 Best regards,
 Stefano

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =

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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Xie Shaohui-B21989]

From: vapierfil...@gmail.com [mailto:vapierfil...@gmail.com] On Behalf Of
Mike Frysinger
Sent: Friday, April 22, 2011 5:25 AM
To: Xie Shaohui-B21989
Cc: u-boot@lists.denx.de; Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-
B21284
Subject: Re: [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 +struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
 +               unsigned int max_hz, unsigned int mode) {
 +   ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);

you support just one bus ?  that's no fun ;).
[Xie Shaohui] See Kumar's comment.


 +       /* Enable eSPI interface */
 +       out_be32(espi-mode, ESPI_MODE_RXTHR(3)
 +                       | ESPI_MODE_TXTHR(4) | ESPI_MODE_EN);
 +
 +       out_be32(espi-event, 0x); /* Clear all eSPI events
 + */
 +       out_be32(espi-mask, 0x); /* Mask  all eSPI
 + interrupts */
 +
 +       /* Init CS mode interface */
 +       for (i = 0; i  ESPI_MAX_CS_NUM; i++)
 +               out_be32(espi-csmode[i], ESPI_CSMODE_INIT_VAL);
 +
 +       out_be32(espi-csmode[cs], in_be32(espi-csmode[cs]) 
 +               ~(ESPI_CSMODE_PM(0xF) | ESPI_CSMODE_DIV16
 +               | ESPI_CSMODE_CI_INACTIVEHIGH |
 + ESPI_CSMODE_CP_BEGIN_EDGCLK
 +               | ESPI_CSMODE_REV_MSB_FIRST | ESPI_CSMODE_LEN(0xF)));
 

usually spi_setup_slave() is to get the slave client ready to be used.
 it shouldnt be programming any actual hardware registers.  that is the
point of the spi_claim_bus() and spi_release_bus() steps ... use the
information in the slave state to setup the hardware for that slave and
then break it down in the release step.

[Xie Shaohui] OK, I'll move these operations out of spi_setup_slave(), use 
spi_claim_bus() and spi_release_bus() to setup and break down hardware.

 +static u8 cmd_buf[16];
 +static size_t cmd_len;
 +static size_t data_len;
 +
 +int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void
 +*data_out,
 +               void *data_in, unsigned long flags) {
 +       ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +       unsigned int tmpdout, tmpdin, event;
 +       const void *dout = NULL;
 +       void *din = NULL;
 +       unsigned int len;
 +       int numBlks;
 +       int num_bytes;
 +       unsigned char *ch;
 +       unsigned char *buffer;
 +       size_t buf_len;
 +
 +       switch (flags) {
 +       case SPI_XFER_BEGIN:
 +               cmd_len = bitlen / 8;
 +               memcpy(cmd_buf, data_out, cmd_len);
 +               return 0;

interesting solution to the problem, but i'd think it might make more
sense to have this state live in the slave data rather than in the global
bus.

[Xie Shaohui] OK, I'll use slave data to store these info.

 +void spi_cs_activate(struct spi_slave *slave) {
 +       ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
 +       unsigned int com = 0;
 +
 +       com = ~(ESPI_COM_CS(0x3) | ESPI_COM_TRANLEN(0x));
 +       com |= ESPI_COM_CS(slave-cs);
 +       com |= ESPI_COM_TRANLEN(data_len - 1);
 +       out_be32(espi-com, com);
 +
 +       return;
 +}

that return is useless and can be punted -mike
[Xie Shaohui] OK, I'll drop the return. Thanks.


Best Regards, 
Shaohui Xie

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

Re: [U-Boot] [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

[Xie Shaohui-B21989]

-Original Message-
From: vapierfil...@gmail.com [mailto:vapierfil...@gmail.com] On Behalf Of
Mike Frysinger
Sent: Friday, April 22, 2011 1:10 AM
To: Xie Shaohui-B21989
Cc: u-boot@lists.denx.de; Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-
B21284
Subject: Re: [PATCH 1/2][v2] powerpc: eSPI and eSPI controller support

On Thu, Apr 21, 2011 at 2:04 AM, Shaohui Xie wrote:
 --- a/include/spi.h
 +++ b/include/spi.h
  /* Controller-specific definitions: */

  /* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */
 -#ifdef CONFIG_MPC8XXX_SPI
 +#if defined(CONFIG_MPC8XXX_SPI) || defined(CONFIG_FSL_ESPI)
  # ifndef CONFIG_HARD_SPI
  #  define CONFIG_HARD_SPI
  # endif

i cant see why this PowerPC-specific code needs to be in the common spi.h.
why cant this live in a PowerPC header like asm/config.h ?  (i know this
code predates asm/config.h) -mike
[Xie Shaohui] OK, I'll move these codes to asm/config.h


Best Regards, 
Shaohui Xie 


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

[U-Boot] ubi command in u-boot

[Ratheendran R]

Dear All,

I am presently trying to port UBI filesystem for TQ2440 board, my u-boot do
not support the UBI command.

Please let me wither we can do copy ubi image without u-boot's UBI
support.if there is work around let me know this can be done.

I tried nand write.e command support by my uboot to write the UBI
image,this is currently not working.


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

Re: [U-Boot] [PATCH V5 2/2] MX53: support for freescale MX53LOCO board

[Jason Hui]

Hi, Stefano,

On Fri, Apr 22, 2011 at 12:36 PM, Jason Hui jason@linaro.org wrote:
 Hi, Stefano,

 On Fri, Apr 22, 2011 at 1:43 AM, Stefano Babic sba...@denx.de wrote:
 On 04/20/2011 12:47 PM, Jason Liu wrote:

 +int board_mmc_getcd(u8 *cd, struct mmc *mmc)
 +{
 +     struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
 +
 +     if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
 +             *cd = mxc_gpio_get(77); /*GPIO3_13*/
 +     else
 +             *cd = mxc_gpio_get(75); /*GPIO3_11*/
 +
 +     return 0;
 +}

 Rereading the thread regarding this board I see there is an open
 question issued by Wolfgang about this code, if accessors should be used
 in this case. IMHO the code is correct, using the GPIO get function to
 acquire the current value of a pin. Wolfgang, is it enough to answer
 your question ? Do you see an open issue ?

 +/* PMIC Configs */
 +#define CONFIG_FSL_PMIC
 +#define CONFIG_FSL_PMIC_I2C
 +#define CONFIG_SYS_FSL_PMIC_I2C_ADDR    8

 If I am not confused, this setup is not valid as you already sent a
 patchset to drop these lines and adding support for the DA9053 pmic.

        PMIC: Add dialog pmic support
        MX53: loco: Add power init support

 As this patchset is based on the LOCO patch (this one), and it does not
 apply anymore, please drop these lines and rebase your patches to add
 pmic support on the actual state of the current patch.
 IMHO it should be better if you resend them as a single patchset, as
 they are strictly related, merging Add power init support inside this
 patch.

 OK, I will resend the patchset as the following layout:

 MX5: clock: Add clock config interface
 MX5: factor out boot cause funciton to common code
 PMIC: Add dialog pmic support
 MX53: support for freescale MX53LOCO board (merge Add power init support)

 I will rebase on the u-boot-imx git, do you think is it OK?

I just noticed that MX5: factor out boot cause funciton to common code
has been applied.
So, I will send out the following,

MX5: clock: Add clock config interface
PMIC: Add dialog pmic support
MX53: support for freescale MX53LOCO board (merge Add power init support)

Any comments?

Jason




 +#define CONFIG_SYS_MEMTEST_START       0x7000
 +#define CONFIG_SYS_MEMTEST_END         0x7001

 There is still an open question about this range. Can you answer to
 Wolfgang's question ?

 In fact, I want to give one simple test range when use mtest, I don't know
 what you are worrying about, please tell it clearly?


 Best regards,
 Stefano

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =


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

Re: [U-Boot] [PATCH 1/1] mx5: drop boot cause code from board support code

[Jason Hui]

Hi, Stefano,

On Fri, Apr 22, 2011 at 1:18 AM, Stefano Babic sba...@denx.de wrote:
 On 04/20/2011 12:47 PM, Jason Liu wrote:
 The boot cause code has been factor out to soc common
 code,we need drop the part from the board support code

 Signed-off-by: Jason Liu jason@linaro.org

 Hi Jason,

 ---
  board/efikamx/efikamx.c           |   30 ++
  board/freescale/mx51evk/mx51evk.c |   26 ++
  board/freescale/mx53evk/mx53evk.c |   21 +
  board/ttcontrol/vision2/vision2.c |   28 ++--
  4 files changed, 19 insertions(+), 86 deletions(-)

 diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
 index f735260..0aef654 100644
 --- a/board/efikamx/efikamx.c
 +++ b/board/efikamx/efikamx.c
 @@ -644,46 +644,28 @@ int board_late_init(void)
  int checkboard(void)
  {
       u32 system_rev = get_cpu_rev();
 -     u32 cause;
 -     struct src *src_regs = (struct src *)SRC_BASE_ADDR;

 This seems to me not the best solution. If we have now factored out code
 to print the reset cause and the silicon version (inside print_cpuinfo),
 why do we need to repeat this code for each board ? Calling get_cpu_rev
 seems to me redundant (then each board should only set
 CONFIG_DISPLAY_CPUINFO). And then the CPU revision is printed again, and
 this is redundant.

The purpose for this patch is to remove the boot cause code and and don't change
any cpu rev code. The cpu rev part of code is as it is as before.



       puts(Board: Efika MX );

       switch (system_rev  0xff) {

 As I see in code, in system_rev  0xff we can find the cpu revision, and
 the output is already part of print_cpuinfo.

Ditto, as I only remove the boot cause part of code as the patch tile said.


 I think we need more clean up, removing all part related to CPU revision
 and leaving (if any) only the output related to the board revision.

If that, I need change the patch tile, and include more clean up in the patch
and send again.

Jason



 Best regards,
 Stefano Babic

 --
 =
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
 =

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

Re: [U-Boot] RFC: getramsize() prototype and volatile qualifier

[Albert ARIBAUD]

Le 22/04/2011 00:28, Mike Frysinger a écrit :

 On Thu, Apr 21, 2011 at 1:50 PM, Albert ARIBAUD wrote:
 Le 21/04/2011 19:02, Mike Frysinger a écrit :
 On Thu, Apr 21, 2011 at 3:09 AM, Albert ARIBAUD wrote:
 Call it a detail, but I see that get_ram_size() calls sometime qualify
 their argument as volatile and sometimes not, and this makes checkpatch
 complain that volatiles are Bad(tm), which I would like to get fixed.

 The prototype for get_ram_size() in is

 longget_ram_size  (volatile long *, long);

 While I understand that the way get_ram_size() works, it needs to
 perform volatile *accesses* to addresses computed from its arguments, I
 don't see why it requires one of the arguments themselves to be volatile.

 Am I missing something here, particularly about some toolchain requiring
 the argument to be volatile? I see no reason it should, but better safe
 than sorry.

 the argument isnt volatile, the memory it points to is.  since
 get_ram_size() itself doesnt dereference the argument (only goes
 through a local addr), the volatile marking in the prototype could
 be dropped, but personally i dont see the point.  the prototype doesnt
 require callers to add volatile markings to their own code, and i
 could see someone using base in the future after the volatile being
 dropped and people not noticing right away.  the current code is safe
 and causes no problems by itself, so i see no value in changing it.

 this sounds like useless gotta be checkpatch clean work by people
 blindly following its output.

 Just because checkpatch complains about something does not mean that
 particular complaint is without merit. :)

 like ive said many times, checkpatch clean is not a hard rule.
 review the output to see when it makes sense.  the general volatile
 is bad check is there because people often screw it up.  this is not
 one of those cases ... we absolutely want volatile accesses.

Volatile accesses, yes, we want them, I said so. But that does not mean 
we need volatile *paramters* to the function or *arguments* to the calls.

 Yes, the code works as it is; but it'll work just as well if volatile is
 removed from the prototype and calls

 uhh, there is no volatile in calls.  there is no requirement that
 the call sites also use volatile markings.

There *are* volatiles in the calls; just check the source code.

 , and that'll make the code simpler and more homogeneous overall

 i think you missed a fairly important qualifier.  this is your
 opinion, and one i dont share in this particular instance.

Maybe you missed the fact that there are calls to get_ram_size() that 
don't have the volatile qualifier to 'base' and there are other who have 
it -- that's heterogeneity (I suspect it stems from various strictnesses 
in toolchains) and removing all volatiles objectively does remove that 
heterogeneity.

 plus it'll give checkpatch one less cause for complaint. We gain
 something there, if not a functional plus, an overal quality plus.

 there is absolutely no quality difference

Less error / warning messages from a tool we use counts as better 
quality for me.

 As for people fiddling with get_ram_size() *body* and removing the volatile
 'addr' and use the non-volatile 'base' directly, why would they?

 i have no idea.  i leave the door open to things that i dont happen to
 think of rather than assuming absolutes.

I don't assume absolutes here I think. My assumtion is that 'people' 
will not blindly remove a volatile qualifier in a memory size test 
function which obviously requires its memory accesses to not be 
optimized in any way.

 They will plainly see that 'addr' is volatile and 'base' is not

 this sort of blind assumption is dangerous.  things that are plain to
 you doesnt mean it's plain to everyone, and people make mistakes all
 the time.  keeping the volatile markings on base protects from that
 sort of screw up.

If things are not plain, then let's make them plain where they need to 
be. We do agree that the qualifier in the prototype and calls is useless 
from a functional viewpoint; we do agree that the volatile *access* in 
the function body is crucial; if you think people who want to modify the 
body of get_ram_size() need an explicit warning about keeping the 
accesses volatile then that warning should be given right near the 
accesses, for instance in the form of a Big Fat Comment (tm) right in 
the function's code, not elsewhere in calls.

 (all the more because removing the volatile' attribute from 'base' will
 require casting it to 'base+int' where it belongs)

 i dont know what you're talking about here ... there is no need for
 casting regardless of the volatile markings of base.  casting is need
 to ignore warnings when casting down from volatile to non-volatile,
 not the other way around.  which is not the case here.
 -mike

Correct: the cast to volatile is not needed. Still, removing the 'base' 
variable will remove a 'volatile' qualifier. However, I still think 
people