Re: [U-Boot] [PATCH v2 3/5] I2C: add i2c support for Pantheon platform

2011-03-14 Thread Heiko Schocher
Hello Lei,

Lei Wen wrote:
> Add i2c support to dkb board with pantheon soc.
> 
> Signed-off-by: Lei Wen 
> ---
>  arch/arm/cpu/arm926ejs/pantheon/cpu.c|   10 ++
>  arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
>  arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
>  board/Marvell/dkb/dkb.c  |4 
>  include/configs/dkb.h|   11 +++
>  5 files changed, 30 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c 
> b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> index 9ddc77c..88ecfae 100644
> --- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> @@ -59,6 +59,10 @@ int arch_cpu_init(void)
>   /* Enable GPIO clock */
>   writel(APBC_APBCLK, &apbclkres->gpio);
>  
> + /* Enable I2C clock */
> + writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> + writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> +
>   icache_enable();
>  
>   return 0;
> @@ -76,3 +80,9 @@ int print_cpuinfo(void)
>   return 0;
>  }
>  #endif
> +
> +#ifdef CONFIG_I2C_MV
> +void i2c_clk_enable (void)
> +{
> +}
> +#endif
> diff --git a/arch/arm/include/asm/arch-pantheon/cpu.h 
> b/arch/arm/include/asm/arch-pantheon/cpu.h
> index 30f4393..60955c5 100644
> --- a/arch/arm/include/asm/arch-pantheon/cpu.h
> +++ b/arch/arm/include/asm/arch-pantheon/cpu.h
> @@ -50,7 +50,9 @@ struct panthapb_registers {
>   u32 uart0;  /*0x000*/
>   u32 uart1;  /*0x004*/
>   u32 gpio;   /*0x008*/
> - u8 pad0[0x034 - 0x08 - 4];
> + u8 pad0[0x02c - 0x08 - 4];
> + u32 twsi;   /*0x02c*/
> + u8 pad1[0x034 - 0x2c - 4];
>   u32 timers; /*0x034*/
>  };
>  
> diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h 
> b/arch/arm/include/asm/arch-pantheon/mfp.h
> index fb291cf..041e64c 100644
> --- a/arch/arm/include/asm/arch-pantheon/mfp.h
> +++ b/arch/arm/include/asm/arch-pantheon/mfp.h
> @@ -34,6 +34,8 @@
>  /* UART2 */
>  #define MFP47_UART2_RXD  MFP_REG(0x198) | MFP_AF6 | 
> MFP_DRIVE_MEDIUM
>  #define MFP48_UART2_TXD  MFP_REG(0x19c) | MFP_AF6 | 
> MFP_DRIVE_MEDIUM
> +#define MFP53_CI2C_SCL   MFP_REG(0x1b0) | MFP_AF2 | 
> MFP_DRIVE_MEDIUM
> +#define MFP54_CI2C_SDA   MFP_REG(0x1b4) | MFP_AF2 | 
> MFP_DRIVE_MEDIUM

Please add braces around this multiple or concatenation

>  /* More macros can be defined here... */
>  
> diff --git a/board/Marvell/dkb/dkb.c b/board/Marvell/dkb/dkb.c
> index 72a2d2a..00f73e7 100644
> --- a/board/Marvell/dkb/dkb.c
> +++ b/board/Marvell/dkb/dkb.c
> @@ -36,6 +36,10 @@ int board_early_init_f(void)
>   MFP47_UART2_RXD,
>   MFP48_UART2_TXD,
>  
> + /* I2C */
> + MFP53_CI2C_SCL,
> + MFP54_CI2C_SDA,
> +
>   MFP_EOC /*End of configureation*/
>   };
>   /* configure MFP's */
> diff --git a/include/configs/dkb.h b/include/configs/dkb.h
> index 638af5e..75c4b99 100644
> --- a/include/configs/dkb.h
> +++ b/include/configs/dkb.h
> @@ -56,6 +56,17 @@
>  #include "mv-common.h"
>  
>  #undef CONFIG_ARCH_MISC_INIT
> +
> +/*
> + * I2C definition
> + */
> +#define CONFIG_CMD_I2C
> +#define CONFIG_I2C_MV1
> +#define CONFIG_PXA_I2C_REG   0xd4011000
> +#define CONFIG_HARD_I2C  1
> +#define CONFIG_SYS_I2C_SPEED 0
> +#define CONFIG_SYS_I2C_SLAVE 0xfe
> +
>  /*
>   * Environment variables configurations
>   */

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/5] mvi2c: use structure to replace the direclty define

2011-03-14 Thread Heiko Schocher
Hello Lei,

Lei Wen wrote:
> Signed-off-by: Lei Wen 
> ---
>  arch/arm/cpu/pxa/cpu.c   |   11 +++
>  arch/arm/include/asm/arch-pxa/pxa-regs.h |   56 
>  board/innokom/innokom.c  |9 +--
>  drivers/i2c/mvi2c.c  |  139 
> +-
>  include/configs/innokom.h|1 +
>  include/configs/xm250.h  |1 +
>  6 files changed, 111 insertions(+), 106 deletions(-)
> 
> diff --git a/arch/arm/cpu/pxa/cpu.c b/arch/arm/cpu/pxa/cpu.c
> index 7d49cbb..24b59e7 100644
> --- a/arch/arm/cpu/pxa/cpu.c
> +++ b/arch/arm/cpu/pxa/cpu.c
> @@ -318,3 +318,14 @@ int arch_cpu_init(void)
>   pxa_clock_setup();
>   return 0;
>  }
> +
> +void i2c_clk_enable(void)
> +{
> +#ifdef CONFIG_CPU_MONAHANS
> + /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
> + writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
> +#else /* CONFIG_CPU_MONAHANS */
> + /* set the global I2C clock on */
> + writel(readl(CKEN) | CKEN14_I2C, CKEN);
> +#endif
> +}
> diff --git a/arch/arm/include/asm/arch-pxa/pxa-regs.h 
> b/arch/arm/include/asm/arch-pxa/pxa-regs.h
> index 65a387f..109fdc0 100644
> --- a/arch/arm/include/asm/arch-pxa/pxa-regs.h
> +++ b/arch/arm/include/asm/arch-pxa/pxa-regs.h
> @@ -456,62 +456,6 @@ typedef void (*ExcpHndlr) (void) ;
>   IrSR_XMITIR_IR_MODE)
>  
>  /*
> - * I2C registers
> - */
> -#define IBMR 0x40301680  /* I2C Bus Monitor Register - IBMR */
> -#define IDBR 0x40301688  /* I2C Data Buffer Register - IDBR */
> -#define ICR  0x40301690  /* I2C Control Register - ICR */
> -#define ISR  0x40301698  /* I2C Status Register - ISR */
> -#define ISAR 0x403016A0  /* I2C Slave Address Register - ISAR */
> -
> -#ifdef CONFIG_CPU_MONAHANS
> -#define PWRIBMR  0x40f500C0  /* Power I2C Bus Monitor 
> Register-IBMR */
> -#define PWRIDBR  0x40f500C4  /* Power I2C Data Buffer 
> Register-IDBR */
> -#define PWRICR   0x40f500C8  /* Power I2C Control Register - ICR 
> */
> -#define PWRISR   0x40f500CC  /* Power I2C Status Register - ISR 
> */
> -#define PWRISAR  0x40f500D0  /* Power I2C Slave Address 
> Register-ISAR */
> -#else
> -#define PWRIBMR  0x40f00180  /* Power I2C Bus Monitor 
> Register-IBMR */
> -#define PWRIDBR  0x40f00188  /* Power I2C Data Buffer 
> Register-IDBR */
> -#define PWRICR   0x40f00190  /* Power I2C Control Register - ICR 
> */
> -#define PWRISR   0x40f00198  /* Power I2C Status Register - ISR 
> */
> -#define PWRISAR  0x40f001A0  /* Power I2C Slave Address 
> Register-ISAR */
> -#endif
> -
> -/* - Control register bits  */
> -
> -#define ICR_START0x1 /* start bit */
> -#define ICR_STOP 0x2 /* stop bit */
> -#define ICR_ACKNAK   0x4 /* send ACK(0) or NAK(1) */
> -#define ICR_TB   0x8 /* transfer byte bit */
> -#define ICR_MA   0x10/* master abort */
> -#define ICR_SCLE 0x20/* master clock enable, mona SCLEA */
> -#define ICR_IUE  0x40/* unit enable */
> -#define ICR_GCD  0x80/* general call disable */
> -#define ICR_ITEIE0x100   /* enable tx interrupts */
> -#define ICR_IRFIE0x200   /* enable rx interrupts, mona: DRFIE */
> -#define ICR_BEIE 0x400   /* enable bus error ints */
> -#define ICR_SSDIE0x800   /* slave STOP detected int enable */
> -#define ICR_ALDIE0x1000  /* enable arbitration interrupt */
> -#define ICR_SADIE0x2000  /* slave address detected int enable */
> -#define ICR_UR   0x4000  /* unit reset */
> -#define ICR_FM   0x8000  /* Fast Mode */
> -
> -/* - Status register bits - */
> -
> -#define ISR_RWM  0x1 /* read/write mode */
> -#define ISR_ACKNAK   0x2 /* ack/nak status */
> -#define ISR_UB   0x4 /* unit busy */
> -#define ISR_IBB  0x8 /* bus busy */
> -#define ISR_SSD  0x10/* slave stop detected */
> -#define ISR_ALD  0x20/* arbitration loss detected */
> -#define ISR_ITE  0x40/* tx buffer empty */
> -#define ISR_IRF  0x80/* rx buffer full */
> -#define ISR_GCAD 0x100   /* general call address detected */
> -#define ISR_SAD  0x200   /* slave address detected */
> -#define ISR_BED  0x400   /* bus error no ACK/NAK */
> -
> -/*
>   * Serial Audio Controller
>   */
>  /* FIXME the audio defines collide w/ the SA defines.  I don't like these
> diff --git a/board/innokom/innokom.c b/board/innokom/innokom.c
> index e658c35..22de7e3 100

Re: [U-Boot] [PATCH V2 1/5] pxa: move i2c driver to the common place

2011-03-14 Thread Heiko Schocher
Hello Lei,

Lei Wen wrote:
> For better sharing with other platform other than pxa's,
> it is more convenient to put the driver to the common place.
> 
> Signed-off-by: Lei Wen 
> ---
> Changelog:
> v2: rename previous pxa_i2c to mvi2c.

Maybe a Coding Style cleanup would be good for this file ...
(I know, you don;t wrote this file...)

>  arch/arm/cpu/pxa/Makefile |1 -
>  arch/arm/cpu/pxa/i2c.c|  469 
> -
>  drivers/i2c/Makefile  |1 +
>  drivers/i2c/mvi2c.c   |  469 
> +

Why you don;t use git format-patch -M ?
If so, I wouldn;t stumbled over the Coding Style ;-)

>  include/configs/innokom.h |1 +
>  include/configs/xm250.h   |1 +
>  6 files changed, 472 insertions(+), 470 deletions(-)
>  delete mode 100644 arch/arm/cpu/pxa/i2c.c
>  create mode 100644 drivers/i2c/mvi2c.c
> 
[...]
> diff --git a/drivers/i2c/mvi2c.c b/drivers/i2c/mvi2c.c
> new file mode 100644
> index 000..7aa49ae
> --- /dev/null
> +++ b/drivers/i2c/mvi2c.c
> @@ -0,0 +1,469 @@
> +/*
> + * (C) Copyright 2000
> + * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
> + *
> + * (C) Copyright 2000 Sysgo Real-Time Solutions, GmbH 
> + * Marius Groeger 
> + *
> + * (C) Copyright 2003 Pengutronix e.K.
> + * Robert Schwebel 
> + *
> + * 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
> + *
> + * Back ported to the 8xx platform (from the 8260 platform) by
> + * murray.jen...@cmst.csiro.au, 27-Jan-01.
> + */
> +
> +/* FIXME: this file is PXA255 specific! What about other XScales? */

As you rename this file to mv, please change this comment.

> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_HARD_I2C
> +
> +/*
> + *   - CONFIG_SYS_I2C_SPEED
> + *   - I2C_PXA_SLAVE_ADDR
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/*#defineDEBUG_I2C   1   /###* activate local debugging output  
> */

Please remove dead code.

> +#define I2C_PXA_SLAVE_ADDR   0x1 /* slave pxa unit address   */
> +
> +#if (CONFIG_SYS_I2C_SPEED == 40)
> +#define I2C_ICR_INIT (ICR_FM | ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | 
> ICR_SCLE)

Line too long.

> +#else
> +#define I2C_ICR_INIT (ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | ICR_SCLE)
> +#endif
> +
> +#define I2C_ISR_INIT 0x7FF
> +
> +#ifdef DEBUG_I2C
> +#define PRINTD(x) printf x
> +#else
> +#define PRINTD(x)
> +#endif
> +
> +
> +/* Shall the current transfer have a start/stop condition? */
> +#define I2C_COND_NORMAL  0
> +#define I2C_COND_START   1
> +#define I2C_COND_STOP2
> +
> +/* Shall the current transfer be ack/nacked or being waited for it? */
> +#define I2C_ACKNAK_WAITACK   1
> +#define I2C_ACKNAK_SENDACK   2
> +#define I2C_ACKNAK_SENDNAK   4
> +
> +/* Specify who shall transfer the data (master or slave) */
> +#define I2C_READ 0
> +#define I2C_WRITE1
> +
> +/* All transfers are described by this data structure */
> +struct i2c_msg {
> + u8 condition;
> + u8 acknack;
> + u8 direction;
> + u8 data;
> +};
> +
> +

Only one empty line.

> +/**
> + * i2c_pxa_reset: - reset the host controller
> + *
> + */

Wrong comment style, no empty line after the comment necessary.
Fix globally please.

> +
> +static void i2c_reset( void )

No spaces after "(" and before ")"
Fix globally please.

> +{
> + writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
> + writel(readl(ICR) | ICR_UR, ICR);   /* reset the unit */
> + udelay(100);
> + writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
> +#ifdef CONFIG_CPU_MONAHANS
> + /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
> + writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
> +#else /* CONFIG_CPU_MONAHANS */
> + /* set the global I2C clock on */
> + writel(readl(CKEN) | CKEN14_I2C, CKEN);
> +#endif
> + writel(I2C_PXA_SLAVE_ADDR, ISAR);   /* set our slave address */
> + writel(I2C_ICR_INIT, ICR);  /* set control reg values */
> + writel(I2C_ISR_INIT, ISR);  /* set clear interrupt bits */
> + writel(readl(ICR) | ICR_IUE, ICR);  /* enable unit */
> + udelay(100);
> +}
> +

[U-Boot] Please pull u-boot-mpc85xx.git

2011-03-14 Thread Kumar Gala
The following changes since commit cc1dd33f273f8c96cbd7539b4a2d1d7aa12773cd:

  mpc8[5/6]xx: Ensure POST word does not get reset (2011-03-13 11:24:44 -0500)

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

Kumar Gala (1):
  powerpc/85xx: Fix synchronization of timebase on MP boot

 arch/powerpc/cpu/mpc85xx/mp.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] powerpc/85xx: Fix synchronization of timebase on MP boot

2011-03-14 Thread Kumar Gala

On Mar 15, 2011, at 1:25 AM, Kumar Gala wrote:

> There is a small ordering issue in the master core in that we need to
> make sure the disabling of the timebase in the SoC is visible before we
> set the value to 0.  We can simply just read back the value to
> synchronizatize the write, before we set TB to 0.
> 
> Reported-by: Dan Hettena
> Tested-by: Dan Hettena
> Signed-off-by: Kumar Gala 
> ---
> arch/powerpc/cpu/mpc85xx/mp.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)

applied

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


Re: [U-Boot] Uboot- Nor flash

2011-03-14 Thread Hebbar, Gururaja
Hi,

On Tue, Mar 15, 2011 at 11:07:46, Sanjeeva Kumara wrote:
> Hi pls help me...
> How the boot image is read into memory from where exactly execution 
> starts...
> 

1. what is your board configuration (memory, Processor, ram, etc..)
2. Is your board inside u-boot repository ?. what is the board config name 

Regards
Gururaja




> 
> -Original Message-
> From: Hebbar, Gururaja [mailto:gururaja.heb...@ti.com]
> Sent: Friday, March 11, 2011 6:14 PM
> To: Sanjeeva Kumara; u-boot@lists.denx.de
> Subject: RE: Uboot- Nor flash
> 
> Hi,
> 
> On Fri, Mar 11, 2011 at 14:02:20, Sanjeeva Kumara wrote:
> > Hi
> > My self Sanjeev.  I'm working on marvell's processor ( PXA ). I'm using NOR 
> > flash to port Uboot. I want to do partition in NOR flash so that in one 
> > partition I can keep my master copy and provide Uboot upgrade option. 
> > Please suggest me how can I achieve this.
> >
> 
> The quickest would be to use CONFIG_SYS_FLASH_AUTOPROTECT_LIST. Search for 
> this config and this will help you setup autoprotect options for various 
> partitions.
> 
> 
> Regards,
> Gururaja
> 
> 
> Larsen & Toubro Limited
> 
> www.larsentoubro.com
> 
> This Email may contain confidential or privileged information for the 
> intended recipient (s) If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
> 


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


[U-Boot] [PATCH] powerpc/85xx: Fix synchronization of timebase on MP boot

2011-03-14 Thread Kumar Gala
There is a small ordering issue in the master core in that we need to
make sure the disabling of the timebase in the SoC is visible before we
set the value to 0.  We can simply just read back the value to
synchronizatize the write, before we set TB to 0.

Reported-by: Dan Hettena
Tested-by: Dan Hettena
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/mp.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/mp.c b/arch/powerpc/cpu/mpc85xx/mp.c
index 6c0da83..758e6d7 100644
--- a/arch/powerpc/cpu/mpc85xx/mp.c
+++ b/arch/powerpc/cpu/mpc85xx/mp.c
@@ -276,8 +276,13 @@ static void plat_mp_up(unsigned long bootpg)
 
/* enable time base at the platform */
out_be32(&rcpm->ctbenrl, 0);
+
+   /* readback to sync write */
+   in_be32(&rcpm->ctbenrl);
+
mtspr(SPRN_TBWU, 0);
mtspr(SPRN_TBWL, 0);
+
out_be32(&rcpm->ctbenrl, (1 << nr_cpus) - 1);
 
 #ifdef CONFIG_MPC8xxx_DISABLE_BPTR
@@ -347,6 +352,10 @@ static void plat_mp_up(unsigned long bootpg)
else
devdisr |= MPC85xx_DEVDISR_TB0;
out_be32(&gur->devdisr, devdisr);
+
+   /* readback to sync write */
+   in_be32(&gur->devdisr);
+
mtspr(SPRN_TBWU, 0);
mtspr(SPRN_TBWL, 0);
 
-- 
1.7.2.3

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


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Kumar Gala

On Mar 14, 2011, at 4:37 PM, Scott Wood wrote:

> On Mon, 14 Mar 2011 16:25:54 -0500
> Kumar Gala  wrote:
> 
>> 
>> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>> 
>>> On Sat, 12 Mar 2011 16:56:09 -0600
>>> Kumar Gala  wrote:
>>> 
 
 On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
 
> I was surprised to find myself at the decrement interrupt when running my 
> new stuff.
> That is against ePAPR, right?
> Does u-boot at least make sure that the DEC is set to some large value 
> before it leaps at me?
> I don't mind forcing EE=0 but I'd like to make sure I make it that far 
> into the code :)
> -JX
 
 Jimi,
 
 Not sure how or why you are seeing this, but u-boot should disable 
 interrupts in common/cmd_bootm.c
 
 Look for disable_interrupts() -> this should set MSR[EE] = 0.
>>> 
>>> What about the rest of MSR -- ME/CE/DE?
>> 
>> I dont think we ever turn on CE in u-boot, DE would only get set in some 
>> weird external debugger build.
> 
> From arch/powerpc/cpu/mpc85xx/start.S:
> 
>/* switch back to AS = 0 */
>lis r3,(MSR_CE|MSR_ME|MSR_DE)@h
>ori r3,r3,(MSR_CE|MSR_ME|MSR_DE)@l
>mtmsr   r3
>isync
> 
>bl  cpu_init_f
>bl  board_init_f
>isync
> 
> -Scott

commit 15fba3279b56333bdb65ead366f82c945ed320d1
Author: Kumar Gala 
Date:   Fri Sep 11 15:28:41 2009 -0500

ppc/85xx: Disable all async interrupt sources when we boot

We should make sure to clear MSR[ME, CE, DE] when we boot an OS image
since we have changed the exception vectors and the OSes vectors might
not be setup we should avoid async interrupts at all costs.

Signed-off-by: Kumar Gala 

diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index 48a82ed..a6d1e99 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -364,5 +364,16 @@ extern void setup_ivors(void);
 
 void arch_preboot_os(void)
 {
+   u32 msr;
+
+   /*
+* We are changing interrupt offsets and are about to boot the OS so
+* we need to make sure we disable all async interrupts. EE is already
+* disabled by the time we get called.
+*/
+   msr = mfmsr();
+   msr &= ~(MSR_ME|MSR_CE|MSR_DE);
+   mtmsr(msr);
+
setup_ivors();
 }

-

:)

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


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Kumar Gala

On Mar 14, 2011, at 2:39 PM, Jimi Xenidis wrote:

> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>> 
>> On Sat, 12 Mar 2011 16:56:09 -0600
>> Kumar Gala  wrote:
>> 
>>> 
>>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>>> 
 I was surprised to find myself at the decrement interrupt when running my 
 new stuff.
 That is against ePAPR, right?
 Does u-boot at least make sure that the DEC is set to some large value 
 before it leaps at me?
 I don't mind forcing EE=0 but I'd like to make sure I make it that far 
 into the code :)
 -JX
>>> 
>>> Jimi,
>>> 
>>> Not sure how or why you are seeing this, but u-boot should disable 
>>> interrupts in common/cmd_bootm.c
>>> 
>>> Look for disable_interrupts() -> this should set MSR[EE] = 0.
>> 
>> What about the rest of MSR -- ME/CE/DE?
> 
> I can attest that MSR=0 when my program takes over.
> BTW: secondary CPUs have MSR[IS|DS] == 0b11

The spin in such a mapping, but when released out of spin they should be in a 
MSR[IS|DS] = 0b00 mapping.

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


[U-Boot] [PATCH] powerpc:Enable compiler debug option for powerpc platforms

2011-03-14 Thread Roy Zang
This patch enables compiler debug option for powerpc platforms
by default.  Patch is tested on 85xx/QorIQ platforms in u-boot
with CodeWarrior.

Signed-off-by: Roy Zang 
Cc: Wood Scott-B07421 
Cc: Kumar Gala 
---
Consider the comments 
http://lists.denx.de/pipermail/u-boot/2010-October/080689.html
http://lists.denx.de/pipermail/u-boot/2011-January/086485.html

 arch/powerpc/config.mk |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index 64191c7..8bd57e3 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -53,3 +53,5 @@ endif
 ifeq ($(CROSS_COMPILE),powerpc-openbsd-)
 PLATFORM_CPPFLAGS+= -D__PPC__
 endif
+# default enable debug option for powerpc platform
+PLATFORM_CPPFLAGS+= -ggdb -Wa,-gdwarf2
-- 
1.7.3.5


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


Re: [U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7

2011-03-14 Thread Aneesh V
Loic,

On Monday 14 March 2011 09:41 PM, Loïc Minier wrote:
> On Mon, Mar 14, 2011, Aneesh V wrote:
>> +- ARM Options:
>> +CONFIG_SYS_THUMB_BUILD
>> +
>> +Use this flag to build U-Boot using the Thumb instruction
>> +set for ARM architectures. Thumb instruction set provides
>> +better code density. For ARM architectures that support
>> +Thumb2 this flag will result in Thumb2 code generated by
>> +GCC.
>> +
>>   - Linux Kernel Interface:
>>  CONFIG_CLOCKS_IN_MHZ
>>
>
>   The above README changes suggest that "Thumb-1" would also be possible
>   but you patch an armv7 file:
>
>> --- a/arch/arm/cpu/armv7/config.mk
>> +++ b/arch/arm/cpu/armv7/config.mk
>
>   so I suspect only armv7 CPUs would be affected?  Consider patching
>   arch/arm/config.mk instead which is where -marm is currently set:
>  # Explicitly specifiy 32-bit ARM ISA since toolchain default can be 
> -mthumb:
>  PLATFORM_CPPFLAGS += $(call cc-option,-marm,)
>   In fact, I would find it less confusing if the flags were -mthumb or
>   -marm and never -marm -mthumb, so you probably want to patch the code
>   setting -marm above to be in your "else" clause.

I will do that. Thank you.

>
>> @@ -31,3 +31,8 @@ PLATFORM_CPPFLAGS += -march=armv5
>
>   This suggests that u-boot is actually built in ARMv5 mode, which means
>   we're missing out actual Thumb-2 instructions (v6+).
>
>   Perhaps arch/arm/cpu/armv7/config.mk should also $(call
>   cc-option,-march=armv7).  (I've never used -march=armv7 but it seems to
>   exist and is probably more correct than -march=armv7-a).
>

Please note that I am enabling armv7-a in the second patch in omap4
config.mk file. The reason I didn't do this here was some ARMv7 SoCs do
not want to use -march=armv7-a even if the compiler supports it. Tegra2
is an example. Please see the below from Tegra2 config.mk:

# Use ARMv4 for Tegra2 - initial code runs on the AVP, which is an ARM7TDI.
PLATFORM_CPPFLAGS += -march=armv4

This being the case I would have had to define another CONFIG flag if I
had to add -march=armv7-a in arch/arm/cpu/armv7/config.mk. I thought it
un-necessary and instead put it in the SoC specific file. So, Tegra2
can continue to use -march=armv4 and will get Thumb-1 if they enable
CONFIG_SYS_THUMB_BUILD. Or do you think we should define something like
CONFIG_SYS_MARCH_ARMV7

I will try -march=armv7, but I vaguely remember it had some issues.

>>   # =
>>   PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,\
>>  $(call cc-option,-malignment-traps,))
>> +
>> +ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
>> +# Enable Thumb mode build if compiler supports it
>> +PLATFORM_CPPFLAGS += $(call cc-option,-mthumb -mthumb-interwork)
>> +endif
>> --
>> 1.7.0.4
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 1/5] pxa: move i2c driver to the common place

2011-03-14 Thread Lei Wen
For better sharing with other platform other than pxa's,
it is more convenient to put the driver to the common place.

Signed-off-by: Lei Wen 
---
Changelog:
v2: rename previous pxa_i2c to mvi2c.

 arch/arm/cpu/pxa/Makefile |1 -
 arch/arm/cpu/pxa/i2c.c|  469 -
 drivers/i2c/Makefile  |1 +
 drivers/i2c/mvi2c.c   |  469 +
 include/configs/innokom.h |1 +
 include/configs/xm250.h   |1 +
 6 files changed, 472 insertions(+), 470 deletions(-)
 delete mode 100644 arch/arm/cpu/pxa/i2c.c
 create mode 100644 drivers/i2c/mvi2c.c

diff --git a/arch/arm/cpu/pxa/Makefile b/arch/arm/cpu/pxa/Makefile
index 49a6ed3..e8b59a3 100644
--- a/arch/arm/cpu/pxa/Makefile
+++ b/arch/arm/cpu/pxa/Makefile
@@ -28,7 +28,6 @@ LIB   = $(obj)lib$(CPU).o
 START  = start.o
 
 COBJS  += cpu.o
-COBJS  += i2c.o
 COBJS  += pxafb.o
 COBJS  += timer.o
 COBJS  += usb.o
diff --git a/arch/arm/cpu/pxa/i2c.c b/arch/arm/cpu/pxa/i2c.c
deleted file mode 100644
index 7aa49ae..000
--- a/arch/arm/cpu/pxa/i2c.c
+++ /dev/null
@@ -1,469 +0,0 @@
-/*
- * (C) Copyright 2000
- * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
- *
- * (C) Copyright 2000 Sysgo Real-Time Solutions, GmbH 
- * Marius Groeger 
- *
- * (C) Copyright 2003 Pengutronix e.K.
- * Robert Schwebel 
- *
- * 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
- *
- * Back ported to the 8xx platform (from the 8260 platform) by
- * murray.jen...@cmst.csiro.au, 27-Jan-01.
- */
-
-/* FIXME: this file is PXA255 specific! What about other XScales? */
-
-#include 
-#include 
-
-#ifdef CONFIG_HARD_I2C
-
-/*
- * - CONFIG_SYS_I2C_SPEED
- * - I2C_PXA_SLAVE_ADDR
- */
-
-#include 
-#include 
-#include 
-
-/*#define  DEBUG_I2C   1   /###* activate local debugging output  
*/
-#define I2C_PXA_SLAVE_ADDR 0x1 /* slave pxa unit address   */
-
-#if (CONFIG_SYS_I2C_SPEED == 40)
-#define I2C_ICR_INIT   (ICR_FM | ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | 
ICR_SCLE)
-#else
-#define I2C_ICR_INIT   (ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | ICR_SCLE)
-#endif
-
-#define I2C_ISR_INIT   0x7FF
-
-#ifdef DEBUG_I2C
-#define PRINTD(x) printf x
-#else
-#define PRINTD(x)
-#endif
-
-
-/* Shall the current transfer have a start/stop condition? */
-#define I2C_COND_NORMAL0
-#define I2C_COND_START 1
-#define I2C_COND_STOP  2
-
-/* Shall the current transfer be ack/nacked or being waited for it? */
-#define I2C_ACKNAK_WAITACK 1
-#define I2C_ACKNAK_SENDACK 2
-#define I2C_ACKNAK_SENDNAK 4
-
-/* Specify who shall transfer the data (master or slave) */
-#define I2C_READ   0
-#define I2C_WRITE  1
-
-/* All transfers are described by this data structure */
-struct i2c_msg {
-   u8 condition;
-   u8 acknack;
-   u8 direction;
-   u8 data;
-};
-
-
-/**
- * i2c_pxa_reset: - reset the host controller
- *
- */
-
-static void i2c_reset( void )
-{
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-   writel(readl(ICR) | ICR_UR, ICR);   /* reset the unit */
-   udelay(100);
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-#ifdef CONFIG_CPU_MONAHANS
-   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
-   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
-#else /* CONFIG_CPU_MONAHANS */
-   /* set the global I2C clock on */
-   writel(readl(CKEN) | CKEN14_I2C, CKEN);
-#endif
-   writel(I2C_PXA_SLAVE_ADDR, ISAR);   /* set our slave address */
-   writel(I2C_ICR_INIT, ICR);  /* set control reg values */
-   writel(I2C_ISR_INIT, ISR);  /* set clear interrupt bits */
-   writel(readl(ICR) | ICR_IUE, ICR);  /* enable unit */
-   udelay(100);
-}
-
-
-/**
- * i2c_isr_set_cleared: - wait until certain bits of the I2C status register
- *   are set and cleared
- *
- * @return: 1 in case of success, 0 means timeout (no match within 10 ms).
- */
-static int i2c_isr_set_cleared( unsigned long set_mask, unsigned long 
cleared_mask )
-{
-   int timeout = 1;
-
-   while( ((ISR & set_mask)!=set_mask) || ((ISR & cleared_mask)!=0) 

[U-Boot] [PATCH v2 5/5] I2C: add i2c support for Armada100 platform

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 arch/arm/cpu/arm926ejs/armada100/cpu.c|   14 ++
 arch/arm/include/asm/arch-armada100/mfp.h |4 
 board/Marvell/aspenite/aspenite.c |5 +
 include/configs/aspenite.h|   12 
 4 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c 
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
index 62aa175..8039ad2 100644
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -62,6 +62,14 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apb1clkres->gpio);
 
+   /* Enable general I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+
+   /* Enable power I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+
/*
 * Enable Functional and APB clock at 14.7456MHz
 * for configured UART console
@@ -90,3 +98,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_I2C_MV
+void i2c_clk_enable (void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h 
b/arch/arm/include/asm/arch-armada100/mfp.h
index d21a79f..f22b5e7 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -60,6 +60,10 @@
 #define MFPO8_UART3_RXDMFP_REG(0x06c) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
 #define MFPO9_UART3_TXDMFP_REG(0x070) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
 
+/* I2c */
+#define MFP105_CI2C_SDAMFP_REG(0x1a4) | MFP_AF1 | 
MFP_DRIVE_MEDIUM
+#define MFP106_CI2C_SCLMFP_REG(0x1a8) | MFP_AF1 | 
MFP_DRIVE_MEDIUM
+
 /* More macros can be defined here... */
 
 #define MFP_PIN_MAX117
diff --git a/board/Marvell/aspenite/aspenite.c 
b/board/Marvell/aspenite/aspenite.c
index 046ffd6..34ac7aa 100644
--- a/board/Marvell/aspenite/aspenite.c
+++ b/board/Marvell/aspenite/aspenite.c
@@ -33,9 +33,14 @@ DECLARE_GLOBAL_DATA_PTR;
 int board_early_init_f(void)
 {
u32 mfp_cfg[] = {
+   /* I2C */
+   MFP105_CI2C_SDA,
+   MFP106_CI2C_SCL,
+
/* Enable Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
+
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
diff --git a/include/configs/aspenite.h b/include/configs/aspenite.h
index fd35f3e..50f8ed7 100644
--- a/include/configs/aspenite.h
+++ b/include/configs/aspenite.h
@@ -63,6 +63,18 @@
 #undef CONFIG_ARCH_MISC_INIT
 
 /*
+ * I2C definition
+ */
+#define CONFIG_CMD_I2C 1
+#define CONFIG_I2C_MV  1
+#define CONFIG_PXA_I2C_NUM 2
+#define CONFIG_I2C_MULTI_BUS   1
+#define CONFIG_PXA_I2C_REG {0xd4011000, 0xd4025000}
+#define CONFIG_HARD_I2C1
+#define CONFIG_SYS_I2C_SPEED   0
+#define CONFIG_SYS_I2C_SLAVE   0xfe
+
+/*
  * Environment variables configurations
  */
 #define CONFIG_ENV_IS_NOWHERE  1   /* if env in SDRAM */
-- 
1.7.0.4

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


[U-Boot] [PATCH v2 4/5] I2C: mvi2c: add multi bus support

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 drivers/i2c/mvi2c.c |   37 -
 1 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/mvi2c.c b/drivers/i2c/mvi2c.c
index 0e37417..ca1add8 100644
--- a/drivers/i2c/mvi2c.c
+++ b/drivers/i2c/mvi2c.c
@@ -131,9 +131,38 @@ struct pxa_i2c {
u32 isar;
 };
 
-static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
 #define PXAI2C_AND(reg, val)   writel(readl(reg) & val, reg)
 #define PXAI2C_OR(reg, val)writel(readl(reg) | val, reg)
+static struct pxa_i2c *base;
+
+#ifdef CONFIG_I2C_MULTI_BUS
+static u32 i2c_regs[CONFIG_PXA_I2C_NUM] = CONFIG_PXA_I2C_REG;
+static unsigned int bus_initialized[CONFIG_PXA_I2C_NUM];
+static unsigned int current_bus = 0;
+
+int i2c_set_bus_num(unsigned int bus)
+{
+   if ((bus < 0) || (bus >= CONFIG_PXA_I2C_NUM)) {
+   printf("Bad bus: %d\n", bus);
+   return -1;
+   }
+
+   base = (struct pxa_i2c *)i2c_regs[bus];
+   current_bus = bus;
+
+   if(!bus_initialized[current_bus]) {
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   bus_initialized[current_bus] = 1;
+   }
+
+   return 0;
+}
+
+unsigned int i2c_get_bus_num(void)
+{
+   return current_bus;
+}
+#endif
 
 /**
  * i2c_pxa_reset: - reset the host controller
@@ -311,6 +340,12 @@ i2c_transfer_finish:
 
 void i2c_init(int speed, int slaveaddr)
 {
+#ifdef CONFIG_I2C_MULTI_BUS
+   base = (struct pxa_i2c *)i2c_regs[current_bus];
+#else
+   base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
+#endif
+
 #ifdef CONFIG_SYS_I2C_INIT_BOARD
u32 icr;
/* call board specific i2c bus reset routine before accessing the   */
-- 
1.7.0.4

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


[U-Boot] [PATCH v2 3/5] I2C: add i2c support for Pantheon platform

2011-03-14 Thread Lei Wen
Add i2c support to dkb board with pantheon soc.

Signed-off-by: Lei Wen 
---
 arch/arm/cpu/arm926ejs/pantheon/cpu.c|   10 ++
 arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
 arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
 board/Marvell/dkb/dkb.c  |4 
 include/configs/dkb.h|   11 +++
 5 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c 
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index 9ddc77c..88ecfae 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -59,6 +59,10 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apbclkres->gpio);
 
+   /* Enable I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+   writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+
icache_enable();
 
return 0;
@@ -76,3 +80,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_I2C_MV
+void i2c_clk_enable (void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-pantheon/cpu.h 
b/arch/arm/include/asm/arch-pantheon/cpu.h
index 30f4393..60955c5 100644
--- a/arch/arm/include/asm/arch-pantheon/cpu.h
+++ b/arch/arm/include/asm/arch-pantheon/cpu.h
@@ -50,7 +50,9 @@ struct panthapb_registers {
u32 uart0;  /*0x000*/
u32 uart1;  /*0x004*/
u32 gpio;   /*0x008*/
-   u8 pad0[0x034 - 0x08 - 4];
+   u8 pad0[0x02c - 0x08 - 4];
+   u32 twsi;   /*0x02c*/
+   u8 pad1[0x034 - 0x2c - 4];
u32 timers; /*0x034*/
 };
 
diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h 
b/arch/arm/include/asm/arch-pantheon/mfp.h
index fb291cf..041e64c 100644
--- a/arch/arm/include/asm/arch-pantheon/mfp.h
+++ b/arch/arm/include/asm/arch-pantheon/mfp.h
@@ -34,6 +34,8 @@
 /* UART2 */
 #define MFP47_UART2_RXDMFP_REG(0x198) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
 #define MFP48_UART2_TXDMFP_REG(0x19c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
+#define MFP53_CI2C_SCL MFP_REG(0x1b0) | MFP_AF2 | MFP_DRIVE_MEDIUM
+#define MFP54_CI2C_SDA MFP_REG(0x1b4) | MFP_AF2 | MFP_DRIVE_MEDIUM
 
 /* More macros can be defined here... */
 
diff --git a/board/Marvell/dkb/dkb.c b/board/Marvell/dkb/dkb.c
index 72a2d2a..00f73e7 100644
--- a/board/Marvell/dkb/dkb.c
+++ b/board/Marvell/dkb/dkb.c
@@ -36,6 +36,10 @@ int board_early_init_f(void)
MFP47_UART2_RXD,
MFP48_UART2_TXD,
 
+   /* I2C */
+   MFP53_CI2C_SCL,
+   MFP54_CI2C_SDA,
+
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
diff --git a/include/configs/dkb.h b/include/configs/dkb.h
index 638af5e..75c4b99 100644
--- a/include/configs/dkb.h
+++ b/include/configs/dkb.h
@@ -56,6 +56,17 @@
 #include "mv-common.h"
 
 #undef CONFIG_ARCH_MISC_INIT
+
+/*
+ * I2C definition
+ */
+#define CONFIG_CMD_I2C
+#define CONFIG_I2C_MV  1
+#define CONFIG_PXA_I2C_REG 0xd4011000
+#define CONFIG_HARD_I2C1
+#define CONFIG_SYS_I2C_SPEED   0
+#define CONFIG_SYS_I2C_SLAVE   0xfe
+
 /*
  * Environment variables configurations
  */
-- 
1.7.0.4

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


[U-Boot] [PATCH v2 2/5] mvi2c: use structure to replace the direclty define

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 arch/arm/cpu/pxa/cpu.c   |   11 +++
 arch/arm/include/asm/arch-pxa/pxa-regs.h |   56 
 board/innokom/innokom.c  |9 +--
 drivers/i2c/mvi2c.c  |  139 +-
 include/configs/innokom.h|1 +
 include/configs/xm250.h  |1 +
 6 files changed, 111 insertions(+), 106 deletions(-)

diff --git a/arch/arm/cpu/pxa/cpu.c b/arch/arm/cpu/pxa/cpu.c
index 7d49cbb..24b59e7 100644
--- a/arch/arm/cpu/pxa/cpu.c
+++ b/arch/arm/cpu/pxa/cpu.c
@@ -318,3 +318,14 @@ int arch_cpu_init(void)
pxa_clock_setup();
return 0;
 }
+
+void i2c_clk_enable(void)
+{
+#ifdef CONFIG_CPU_MONAHANS
+   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
+   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
+#else /* CONFIG_CPU_MONAHANS */
+   /* set the global I2C clock on */
+   writel(readl(CKEN) | CKEN14_I2C, CKEN);
+#endif
+}
diff --git a/arch/arm/include/asm/arch-pxa/pxa-regs.h 
b/arch/arm/include/asm/arch-pxa/pxa-regs.h
index 65a387f..109fdc0 100644
--- a/arch/arm/include/asm/arch-pxa/pxa-regs.h
+++ b/arch/arm/include/asm/arch-pxa/pxa-regs.h
@@ -456,62 +456,6 @@ typedef void   (*ExcpHndlr) (void) ;
IrSR_XMITIR_IR_MODE)
 
 /*
- * I2C registers
- */
-#define IBMR   0x40301680  /* I2C Bus Monitor Register - IBMR */
-#define IDBR   0x40301688  /* I2C Data Buffer Register - IDBR */
-#define ICR0x40301690  /* I2C Control Register - ICR */
-#define ISR0x40301698  /* I2C Status Register - ISR */
-#define ISAR   0x403016A0  /* I2C Slave Address Register - ISAR */
-
-#ifdef CONFIG_CPU_MONAHANS
-#define PWRIBMR0x40f500C0  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f500C4  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f500C8  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f500CC  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f500D0  /* Power I2C Slave Address 
Register-ISAR */
-#else
-#define PWRIBMR0x40f00180  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f00188  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f00190  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f00198  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f001A0  /* Power I2C Slave Address 
Register-ISAR */
-#endif
-
-/* - Control register bits  */
-
-#define ICR_START  0x1 /* start bit */
-#define ICR_STOP   0x2 /* stop bit */
-#define ICR_ACKNAK 0x4 /* send ACK(0) or NAK(1) */
-#define ICR_TB 0x8 /* transfer byte bit */
-#define ICR_MA 0x10/* master abort */
-#define ICR_SCLE   0x20/* master clock enable, mona SCLEA */
-#define ICR_IUE0x40/* unit enable */
-#define ICR_GCD0x80/* general call disable */
-#define ICR_ITEIE  0x100   /* enable tx interrupts */
-#define ICR_IRFIE  0x200   /* enable rx interrupts, mona: DRFIE */
-#define ICR_BEIE   0x400   /* enable bus error ints */
-#define ICR_SSDIE  0x800   /* slave STOP detected int enable */
-#define ICR_ALDIE  0x1000  /* enable arbitration interrupt */
-#define ICR_SADIE  0x2000  /* slave address detected int enable */
-#define ICR_UR 0x4000  /* unit reset */
-#define ICR_FM 0x8000  /* Fast Mode */
-
-/* - Status register bits - */
-
-#define ISR_RWM0x1 /* read/write mode */
-#define ISR_ACKNAK 0x2 /* ack/nak status */
-#define ISR_UB 0x4 /* unit busy */
-#define ISR_IBB0x8 /* bus busy */
-#define ISR_SSD0x10/* slave stop detected */
-#define ISR_ALD0x20/* arbitration loss detected */
-#define ISR_ITE0x40/* tx buffer empty */
-#define ISR_IRF0x80/* rx buffer full */
-#define ISR_GCAD   0x100   /* general call address detected */
-#define ISR_SAD0x200   /* slave address detected */
-#define ISR_BED0x400   /* bus error no ACK/NAK */
-
-/*
  * Serial Audio Controller
  */
 /* FIXME the audio defines collide w/ the SA defines.  I don't like these
diff --git a/board/innokom/innokom.c b/board/innokom/innokom.c
index e658c35..22de7e3 100644
--- a/board/innokom/innokom.c
+++ b/board/innokom/innokom.c
@@ -45,12 +45,7 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 int i2c_init_board(void)
 {
-   int i, icr;
-
-   /* disable I2C controller first, otherwhise it think

[U-Boot] [PATCH 0/5] add i2c support to pantheon and aramada100

2011-03-14 Thread Lei Wen
V2:
rename the previous pxa_i2c to mvi2c, since this driver would be shared
by many other Marvell platforms.

Lei Wen (5):
  pxa: move i2c driver to the common place
  mvi2c: use structure to replace the direclty define
  I2C: add i2c support for Pantheon platform
  I2C: mvi2c: add multi bus support
  I2C: add i2c support for Armada100 platform

 arch/arm/cpu/arm926ejs/armada100/cpu.c|   14 +
 arch/arm/cpu/arm926ejs/pantheon/cpu.c |   10 +
 arch/arm/cpu/pxa/Makefile |1 -
 arch/arm/cpu/pxa/cpu.c|   11 +
 arch/arm/cpu/pxa/i2c.c|  469 
 arch/arm/include/asm/arch-armada100/mfp.h |4 +
 arch/arm/include/asm/arch-pantheon/cpu.h  |4 +-
 arch/arm/include/asm/arch-pantheon/mfp.h  |2 +
 arch/arm/include/asm/arch-pxa/pxa-regs.h  |   56 ---
 board/Marvell/aspenite/aspenite.c |5 +
 board/Marvell/dkb/dkb.c   |4 +
 board/innokom/innokom.c   |9 +-
 drivers/i2c/Makefile  |1 +
 drivers/i2c/mvi2c.c   |  559 +
 include/configs/aspenite.h|   12 +
 include/configs/dkb.h |   11 +
 include/configs/innokom.h |2 +
 include/configs/xm250.h   |2 +
 18 files changed, 641 insertions(+), 535 deletions(-)
 delete mode 100644 arch/arm/cpu/pxa/i2c.c
 create mode 100644 drivers/i2c/mvi2c.c

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


Re: [U-Boot] [PATCH v6 7/7] modify files for ben nanonote board

2011-03-14 Thread Shinya Kuribayashi
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> diff --git a/Makefile b/Makefile
> index dc2e3d8..758daf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1093,6 +1093,19 @@ smdk6400_config:   unconfig
>   @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
>  
>  #
> +# MIPS
> +#
> +#
> +## MIPS32 XBurst jz4740
> +#
> +qi_lb60_config  : unconfig
> + @mkdir -p $(obj)include
> + @echo "#define CONFIG_NAND_U_BOOT" > $(obj)include/config.h
> + @echo "Compile NAND boot image for QI LB60"
> + @$(MKCONFIG) -a qi_lb60 mips xburst nanonote xburst
> + @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
> +
> +#
>  # Nios
>  #

(In PATCH v6 6/7)
> diff --git a/boards.cfg b/boards.cfg
> index 45c3102..cb8c6a0 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -243,6 +243,7 @@ vct_platinumavc  mipsmipsvct  
>microna
>  vct_platinumavc_smallmipsmipsvct 
> micronas   -   vct:VCT_PLATINUMAVC,VCT_SMALL_IMAGE
>  vct_platinumavc_onenand  mipsmipsvct 
> micronas   -   vct:VCT_PLATINUMAVC,VCT_ONENAND
>  vct_platinumavc_onenand_small mips   mipsvct 
> micronas   -   vct:VCT_PLATINUMAVC,VCT_ONENAND,VCT_SMALL_IMAGE
> +qi_lb60  mipsmips
>  PCI5441  nios2   nios2   pci5441 
> psyent
>  PK1C20   nios2   nios2   pk1c20  
> psyent
>  EVB64260 powerpc 74xx_7xxevb64260-   
>-   EVB64260

You added targets with the same name to two places.  In this case,
boards.cfg will be used to configure qi_lb60.  All MIPS targets can
be configured through boards.cfg now, so please 1) remove $(TOPDIR)/
Makefile part, and 2) get 'qi_lb60' entry work as expected, instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] sh: Add handling of CONFIG_SYS_NO_FLASH for board.c

2011-03-14 Thread Nobuhiro Iwamatsu
Some board of SH does not have flash memoy.
This revises it to initialize Flash when CONFIG_SYS_NO_FLASH is not
defined.

Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Nobuhiro Iwamatsu 
---
 arch/sh/lib/board.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c
index 968566c..ed91643 100644
--- a/arch/sh/lib/board.c
+++ b/arch/sh/lib/board.c
@@ -43,6 +43,7 @@ const char version_string[] = U_BOOT_VERSION" ("U_BOOT_DATE" 
- "U_BOOT_TIME")";
 
 unsigned long monitor_flash_len = CONFIG_SYS_MONITOR_LEN;
 
+#ifndef CONFIG_SYS_NO_FLASH
 static int sh_flash_init(void)
 {
gd->bd->bi_flashsize = flash_init();
@@ -54,6 +55,7 @@ static int sh_flash_init(void)
 
return 0;
 }
+#endif /* CONFIG_SYS_NO_FLASH */
 
 #if defined(CONFIG_CMD_NAND)
 # include 
@@ -125,7 +127,9 @@ init_fnc_t *init_sequence[] =
dram_init,  /* SDRAM init */
timer_init, /* SuperH Timer (TCNT0 only) init */
sh_mem_env_init,
-   sh_flash_init,  /* Flash memory(NOR) init*/
+#ifndef CONFIG_SYS_NO_FLASH
+   sh_flash_init,  /* Flash memory init*/
+#endif
INIT_FUNC_NAND_INIT/* Flash memory (NAND) init */
INIT_FUNC_PCI_INIT  /* PCI init */
stdio_init,
@@ -157,7 +161,9 @@ void sh_generic_init(void)
bd = gd->bd;
bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
+#ifndef CONFIG_SYS_NO_FLASH
bd->bi_flashstart = CONFIG_SYS_FLASH_BASE;
+#endif
 #if defined(CONFIG_SYS_SRAM_BASE) && defined(CONFIG_SYS_SRAM_SIZE)
bd->bi_sramstart = CONFIG_SYS_SRAM_BASE;
bd->bi_sramsize = CONFIG_SYS_SRAM_SIZE;
-- 
1.7.4.1

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


Re: [U-Boot] [PATCH v6 1/7] those files are jz4740 base files

2011-03-14 Thread Shinya Kuribayashi
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
>  arch/mips/cpu/xburst/Makefile|   50 +++
>  arch/mips/cpu/xburst/config.mk   |   33 ++
>  arch/mips/cpu/xburst/cpu.c   |  160 
>  arch/mips/cpu/xburst/jz4740.c|  264 
>  arch/mips/cpu/xburst/jz_serial.c |  114 +
>  arch/mips/cpu/xburst/start.S |  160 
>  arch/mips/cpu/xburst/start_spl.S |   63 +++
>  arch/mips/cpu/xburst/timer.c |  167 
>  arch/mips/cpu/xburst/usbboot.S   |  841 
> ++
>  9 files changed, 1852 insertions(+), 0 deletions(-)
>  create mode 100644 arch/mips/cpu/xburst/Makefile
>  create mode 100644 arch/mips/cpu/xburst/config.mk
>  create mode 100644 arch/mips/cpu/xburst/cpu.c
>  create mode 100644 arch/mips/cpu/xburst/jz4740.c
>  create mode 100644 arch/mips/cpu/xburst/jz_serial.c
>  create mode 100644 arch/mips/cpu/xburst/start.S
>  create mode 100644 arch/mips/cpu/xburst/start_spl.S
>  create mode 100644 arch/mips/cpu/xburst/timer.c
>  create mode 100644 arch/mips/cpu/xburst/usbboot.S

Please pay more attention to coding style issues.
- Comments with multiple lines
- Trailing whitespaces
- Inconsistent tab and space usages
- Follow the basic Linux CodingStyle guide

and so on.

Here's quick fixes on 1/7 part.  2/7..7/7 should be checked as well.

diff --git a/arch/mips/cpu/xburst/Makefile b/arch/mips/cpu/xburst/Makefile
index a9a6e77..6d6ffb7 100644
--- a/arch/mips/cpu/xburst/Makefile
+++ b/arch/mips/cpu/xburst/Makefile
@@ -26,8 +26,8 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)lib$(CPU).o
 
 START  = start.o
-SOBJS-y= 
-COBJS-y = cpu.o timer.o jz_serial.o 
+SOBJS-y=
+COBJS-y= cpu.o timer.o jz_serial.o
 
 COBJS-$(CONFIG_JZ4740) += jz4740.o
 
diff --git a/arch/mips/cpu/xburst/cpu.c b/arch/mips/cpu/xburst/cpu.c
index 5eb047d..43e8c3d 100644
--- a/arch/mips/cpu/xburst/cpu.c
+++ b/arch/mips/cpu/xburst/cpu.c
@@ -40,7 +40,7 @@
:   \
: "i" (op), "R" (*(unsigned char *)(addr)))
 
-#if !defined (CONFIG_NAND_SPL) && !defined (CONFIG_MSC_SPL) 
+#if !defined (CONFIG_NAND_SPL) && !defined (CONFIG_MSC_SPL)
 
 void __attribute__((weak)) _machine_restart(void)
 {
@@ -79,7 +79,7 @@ void flush_cache(ulong start_addr, ulong size)
unsigned long addr = start_addr & ~(lsize - 1);
unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
 
-   for (;addr <= aend;addr += lsize) {
+   for (;addr <= aend; addr += lsize) {
cache_op(Hit_Writeback_Inv_D, addr);
cache_op(Hit_Invalidate_I, addr);
}
@@ -91,7 +91,7 @@ void flush_dcache_range(ulong start_addr, ulong stop)
unsigned long addr = start_addr & ~(lsize - 1);
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
-   for (;addr <= aend;addr += lsize)
+   for (;addr <= aend; addr += lsize)
cache_op(Hit_Writeback_Inv_D, addr);
 }
 
@@ -101,7 +101,7 @@ void invalidate_dcache_range(ulong start_addr, ulong stop)
unsigned long addr = start_addr & ~(lsize - 1);
unsigned long aend = (stop - 1) & ~(lsize - 1);
 
-   for (;addr <= aend;addr += lsize)
+   for (;addr <= aend; addr += lsize)
cache_op(Hit_Invalidate_D, addr);
 }
 
@@ -145,7 +145,7 @@ void flush_dcache_all(void)
 {
u32 addr;
 
-   for (addr = KSEG0; addr < KSEG0 + CONFIG_SYS_DCACHE_SIZE; 
+   for (addr = KSEG0; addr < KSEG0 + CONFIG_SYS_DCACHE_SIZE;
 addr += CONFIG_SYS_CACHELINE_SIZE) {
cache_op(Index_Writeback_Inv_D, addr);
}
diff --git a/arch/mips/cpu/xburst/jz4740.c b/arch/mips/cpu/xburst/jz4740.c
index aedee52..63952b7 100644
--- a/arch/mips/cpu/xburst/jz4740.c
+++ b/arch/mips/cpu/xburst/jz4740.c
@@ -27,18 +27,19 @@ void enable_interrupts(void)
 {
 }
 
-int disable_interrupts(void) 
+int disable_interrupts(void)
 {
return 0;
 }
 
-/* PLL output clock = EXTAL * NF / (NR * NO)
+/*
+ * PLL output clock = EXTAL * NF / (NR * NO)
  * NF = FD + 2, NR = RD + 2
  * NO = 1 (if OD = 0), NO = 2 (if OD = 1 or 2), NO = 4 (if OD = 3)
  */
 void pll_init(void)
 {
-   struct jz4740_cpm * cpm = (struct jz4740_cpm *) JZ4740_CPM_BASE;
+   struct jz4740_cpm *cpm = (struct jz4740_cpm *) JZ4740_CPM_BASE;
 
register unsigned int cfcr, plcr1;
int n2FR[33] = {
@@ -56,7 +57,7 @@ void pll_init(void)
(n2FR[div[3]] << CPM_CPCCR_MDIV_BIT) |
(n2FR[div[4]] << CPM_CPCCR_LDIV_BIT);
 
-   pllout2 = (cfcr & CPM_CPCCR_PCS) ? 
+   pllout2 = (cfcr & CPM_CPCCR_PCS) ?
CONFIG_SYS_CPU_SPEED : (CONFIG_SYS_CPU_SPEED / 2);
 
/* Init USB Host clock, pllout2 must be n*48MHz */
@@ -65,9 +66,9 @@ void pll_init(void)
nf = CONFIG_SYS_CPU_SPEED * 2 / CONFIG_SYS_EXTAL;
plcr1 = ((nf - 2) << CPM_CPPCR_PLLM_BIT) | /* FD */
(0 << CPM_CPPCR_PLLN_BIT) | /* RD=0, NR=2 */
-   (0 << CPM_CPPCR_PLLOD_B

Re: [U-Boot] [PATCH v6 2/7] this is jz4740 head file

2011-03-14 Thread Shinya Kuribayashi
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> this is jz4740 base head file
> 
> Signed-off-by: Xiangfu Liu 
> Acked-by: Daniel 
> ---
> Changes for v2:
> - remove useless code, prepare for using io.h
> - delete all base + offset. using C struct 
> 
>  arch/mips/include/asm/jz4740.h | 1102 
> 
>  1 files changed, 1102 insertions(+), 0 deletions(-)
>  create mode 100644 arch/mips/include/asm/jz4740.h

This  is used by files in PATCH v6 1/7.  Please fold
this patch into the v6 1/7.  That should be ok.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6 1/7] those files are jz4740 base files

2011-03-14 Thread Shinya Kuribayashi
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> diff --git a/arch/mips/cpu/xburst/jz_serial.c 
> b/arch/mips/cpu/xburst/jz_serial.c
> new file mode 100644
> index 000..65ce993
> --- /dev/null
> +++ b/arch/mips/cpu/xburst/jz_serial.c
[...]
> +/*
> + * serial_init - initialize a channel
> + *
> + * This routine initializes the number of data bits, parity
> + * and set the selected baud rate. Interrupts are disabled.
> + * Set the modem control signals if the option is selected.
> + *
> + * RETURNS: N/A
> + */
> +struct jz4740_uart *uart = (struct jz4740_uart *) CONFIG_SYS_UART_BASE;
> +

Can we make this static?
___
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 grab memory for LCD if FB address is defined

2011-03-14 Thread Minkyu Kang
Dear Wolfgang,

On 14 March 2011 04:50, Wolfgang Denk  wrote:
> Dear Minkyu Kang,
>
> In message <4d75b591.3040...@samsung.com> you wrote:
>> If FB address is defined specific address then don't grab memory for LCD
>>
>> Signed-off-by: Minkyu Kang 
>> Cc: Albert Aribaud 
>> ---
>>  arch/arm/lib/board.c |    4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>> index c620d2c..5a4d2bd 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -356,9 +356,13 @@ void board_init_f (ulong bootflag)
>>  #endif /* CONFIG_VFD */
>>
>>  #ifdef CONFIG_LCD
>> +#ifdef CONFIG_FB_ADDR
>
> If you add a new CONFIG_ option, then you must document it (at least
> in the README).
>
>
> Also, you must not split this into several patches, one for each
> architecture.  All these changes must be done in a single commit.
>

OK, I will.

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/8] pxa: move i2c driver to the common place

2011-03-14 Thread Lei Wen
Hi Prafulla,

On Mon, Mar 14, 2011 at 8:03 PM, Prafulla Wadaskar  wrote:
>
>
>> -Original Message-
>> From: Lei Wen [mailto:lei...@marvell.com]
>> Sent: Monday, March 14, 2011 3:46 PM
>> To: u-boot@lists.denx.de; Marek Vasut; Prafulla Wadaskar; Lei Wen
>> Subject: [PATCH 1/8] pxa: move i2c driver to the common place
>>
>> For better sharing with other platform other than pxa's,
>> it is more convenient to put the driver to the common place.
>>
>> Signed-off-by: Lei Wen 
>> ---
>>  arch/arm/cpu/pxa/Makefile |    1 -
>>  arch/arm/cpu/pxa/i2c.c    |  469 --
>> ---
>>  drivers/i2c/Makefile      |    1 +
>>  drivers/i2c/pxa_i2c.c     |  469
>> +
>
> Hi Lei
> It looks like this is cut-paste, have you done git-mv? Pls confirm
Good catch. :) I would use the git-mv to redo the patch.

>
> Secondly
> Since this will be supported by multiple Marvell SoC cores.
> How about renaming new moved i2c driver as mvi2c.c?

Yep, I'm ok with this change. I would post modified patch later.

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


Re: [U-Boot] [RFC PATCH 1/6] Mips: Move content of arch/mips/cpu to arch/mips/cpu/mips32

2011-03-14 Thread Aaron Williams
Seperating the SOCs solves most of my problems with the exception of board.c, 
but then again, we're rather a special case there due to some of the stuff we 
do.

Not counting our SDK we have around 27Kloc for our platform, a large chunk of 
that being DDR2/3 memory initialization code. Our SDK currently weighs in at 
764Kloc, most of which isn't needed by U-Boot (lots of autogenerated hardware 
definition files for all our chips).

-Aaron

On Saturday, March 12, 2011 04:48:58 PM Daniel Schwierzeck wrote:
> Hi Shinya,
> 
> On 03/12/2011 03:43 PM, Shinya Kuribayashi wrote:
> > On 3/9/11 10:16 PM, daniel.schwierz...@googlemail.com wrote:
> >> All current CPUs and SoCs are based on Mips32 arch. The complete
> > 
> > Is that true? What about purple SoC? IIUC It's based on MIPS 5Kc
> > and capable of 64-bit, which MIPS32 is 32-bit only architecture.
> 
> that was an assumption. I could not find any information about Purple.
> This patch series is a suggestion. Maybe there are better approaches
> like arch/mips/cpu/{mips4k|mips5k|mips24k|...|octeon}.
> 
> >> code resides in the global arch/mips/cpu directory. This is not
> >> suitable if other Mips architectures like Mips64 or Octeon should
> >> be supported in the future.
> > 
> > Just for the record.
> > 
> > Personally, Octeon is sort of a special case. It's based on MIPS64
> > architecture, and definitely a MIPS SoC, but not usual MIPS machine.
> > As Aaron already mentioned before, we have very few files sharable
> > with other MIPS machines even in the Linux kernel case. I think it
> > will take long time the Octeon port gets merged to upstream, regard-
> > less of my opinions, because they have a lot of things need to be
> > resolved prior to Octeon itself.
> 
> My original intention was cleaning up the MIPS CPU directory as
> preparation to support new SoCs. I included this patch because Aaron
> asked for this separation some weeks ago but no one answered or commented
> ;) However I posted this series to get some feedback if such a change is
> wanted or acceptable. If so I prepare a new patch series. At least I hope
> the SoC separation is acceptable.
> 
> Cheers,
> Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/5] MIPS: Optimize the setup of endianess and CPU optimization flags

2011-03-14 Thread Shinya Kuribayashi
On 3/15/11 6:14 AM, daniel.schwierz...@googlemail.com wrote:
> Replace the current MIPSFLAGS code by cc-option macro and use
> -march=mips32r2 as default optimization level for all Mips32 CPUs.
> Replace the endianess determination code from toolchain prefix by
> a more generic one inspired by the Linux arch/mips/Makefile.
[...]
> -ifneq (,$(findstring 4KCle,$(CROSS_COMPILE)))
> -ENDIANNESS = -EL
> -else
> -ENDIANNESS = -EB
> -endif
> +# Optimization flags for all Mips32 CPUs
> +MIPSFLAGS = $(call cc-option,-march=mips32r2,-mips32r2 -Wa,-mips32r2)
>
> -MIPSFLAGS += $(ENDIANNESS)
> +# Determine endianess from toolchain prefix
> +ENDIANESS = $(shell $(CC) -dumpmachine | \
> + grep -q 'mips.*el-.*'&&  echo -EL || echo -EB)
> +
> +PLATFORM_CPPFLAGS += $(MIPSFLAGS) $(ENDIANESS)
>
> -PLATFORM_CPPFLAGS += $(MIPSFLAGS)

This trick can not work with the ELDK toolchain, which also I don't
want to think about and be involved in discussion any more.   See:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81572/focus=81735

Users who need to dig into this area should install the ELDK first,
build little-endian targets with it by yourself, then find a way
to handle endianness appropriately which works for both the ELDK and
non-ELDK toolchains.

Or I may miss something.  If it's already verified with the ELDK,
please let me know, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] I2C: change CONFIG_SYS_SPD_BUS_NUM to CONFIG_I2C_DEFAULT_BUS_NUM

2011-03-14 Thread McClintock Matthew-B29882
On Mon, Mar 14, 2011 at 6:28 PM, Wolfgang Denk  wrote:
>> We are trying to access the I2C bus before relocation from flash to read
>> switch settings. Using the current CONFIG_SYS_SPD_BUS_NUM define to do this
>> is fine for our needs however I would like to ask if we wanted to change
>> this to a new more generic define CONFIG_I2C_DEFAULT_BUS_NUM
>
> Well, obviously you need to update the documentation, too:
>

Will be more thorough and fix-up everything and submit a non-RFC patch.

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


Re: [U-Boot] [PATCH] [v2] powerpc: 'monitor' environment variable contains full video configuration

2011-03-14 Thread Tabi Timur-B04825
Wolfgang Denk wrote:
> Looks as if this was a Freescale specific implementation?

Yes.

> Can this not be turned into generic code, usable for other boards /
> systems as well?

Possibly, but I would like to fix one bug at a time.

> Please see the discussion we had about video modes for the i.MX
> systems.

Can you point me to the thread or at least tell me the subject line?  I have no 
idea what you're talking about.

> I want to see handled most of this with generic code, not with
> processor / architecture specific one.

This patch also cleans up a lot of the DIU code to make it handle more generic 
options.

-- 
Timur Tabi
Linux kernel developer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] [v2] powerpc: 'monitor' environment variable contains full video configuration

2011-03-14 Thread Wolfgang Denk
Dear Timur Tabi,

In message <1300133949-1115-1-git-send-email-ti...@freescale.com> you wrote:
> Update the "monitor" environment variable (for Freescale chips that have a
> DIU display controller) to designate the full video configuration, instead
> of just the output monitor.
> 
> The old definition of the "monitor" environment variable only determines
> which video port to use for output.  This variable is set to a number (0,
> 1, or sometimes 2) to specify a DVI, LVDS, or Dual-LVDS port.  The
> resolution is hard-coded into board-specific code.  The Linux command-line
> arguments need to be hard-coded to the proper video definition string.
> 
> Instead, the "monitor" variable is now set to a string that indicates not
> only the part name, but also the resolution, color depth, and refresh rate.
> This string is then parsed for all needed information, and can be passed to
> the kernel via the 'diubootargs' environment variable.

Looks as if this was a Freescale specific implementation?

Can this not be turned into generic code, usable for other boards /
systems as well?

Please see the discussion we had about video modes for the i.MX
systems.

I want to see handled most of this with generic code, not with
processor / architecture specific one.


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
Even historians fail to learn from history -- they repeat the same
mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] I2C: change CONFIG_SYS_SPD_BUS_NUM to CONFIG_I2C_DEFAULT_BUS_NUM

2011-03-14 Thread Wolfgang Denk
Dear Matthew McClintock,

In message <1300135645-21544-1-git-send-email-...@freescale.com> you wrote:
> The bus that the i2c api can access before relocating from flash
> is defined via CONFIG_SYS_SPD_BUS_NUM, however we want to use
> the i2c bus before relocating from flash for non-SPD related
> reasons. Therefore, we rename this define to something more
> appropriate
> ---
> 
> We are trying to access the I2C bus before relocation from flash to read
> switch settings. Using the current CONFIG_SYS_SPD_BUS_NUM define to do this
> is fine for our needs however I would like to ask if we wanted to change
> this to a new more generic define CONFIG_I2C_DEFAULT_BUS_NUM

Well, obviously you need to update the documentation, too:

> - CONFIG_SYS_SPD_BUS_NUM
> + CONFIG_I2C_DEFAULT_BUS_NUM
>  
>   If defined, then this indicates the I2C bus number for DDR SPD.
>   If not defined, then U-Boot assumes that SPD is on I2C bus 0.

"bus number for DDR SPD" is not really correct any more?

> @@ -2834,7 +2834,7 @@ Low Level (hardware related) configuration options:
>SPD_EEPROM_ADDRESS
>   I2C address of the SPD EEPROM
>  
> -- CONFIG_SYS_SPD_BUS_NUM
> +- CONFIG_I2C_DEFAULT_BUS_NUM
>   If SPD EEPROM is on an I2C bus other than the first
>   one, specify here. Note that the value must resolve
>   to something your driver can deal with.

"SPD EEPROM" is not correct either...

> --- a/board/freescale/common/sys_eeprom.c
> +++ b/board/freescale/common/sys_eeprom.c
> @@ -495,11 +495,11 @@ int mac_read_from_eeprom(void)
>   * This function is called before relocation, so we need to read a private
>   * copy of the EEPROM into a local variable on the stack.
>   *
> - * Also, we assume that CONFIG_SYS_EEPROM_BUS_NUM == CONFIG_SYS_SPD_BUS_NUM. 
>  The global
> - * variable i2c_bus_num must be compile-time initialized to 
> CONFIG_SYS_SPD_BUS_NUM,
> + * Also, we assume that CONFIG_SYS_EEPROM_BUS_NUM == 
> CONFIG_I2C_DEFAULT_BUS_NUM.  The global
> + * variable i2c_bus_num must be compile-time initialized to 
> CONFIG_I2C_DEFAULT_BUS_NUM,
>   * so that the SPD code will work.  This means that all pre-relocation I2C
> - * operations can only occur on the CONFIG_SYS_SPD_BUS_NUM bus.  So if
> - * CONFIG_SYS_EEPROM_BUS_NUM != CONFIG_SYS_SPD_BUS_NUM, then we can't read 
> the EEPROM when
> + * operations can only occur on the CONFIG_I2C_DEFAULT_BUS_NUM bus.  So if
> + * CONFIG_SYS_EEPROM_BUS_NUM != CONFIG_I2C_DEFAULT_BUS_NUM, then we can't 
> read the EEPROM when
>   * this function is called.  Oh well.

Lines too long.


> -static unsigned int i2c_bus_num __attribute__ ((section (".data"))) = 
> CONFIG_SYS_SPD_BUS_NUM;
> +static unsigned int i2c_bus_num __attribute__ ((section (".data"))) = 
> CONFIG_I2C_DEFAULT_BUS_NUM;

Ditto.


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
Until you walk a mile in another man's moccasins, you  can't  imagine
the smell.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init

2011-03-14 Thread Tom Warren
Peter,

On Mon, Mar 14, 2011 at 3:20 PM, Peter Tyser  wrote:
> Hi Tom,
>
> 
>
>> >> +static void init_pll_x(void)
>> >> +{
>> >> +     struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST 
>> >> _BASE;
>> >> +     u32     reg;
>> >
>> > The spaces in front of "reg" can be removed.  Ditto for all
>> > functions/variables.
>> Not sure what you mean, here, Peter. There are no spaces here in my
>> ap20.c file, just tabs.
>> Please clarify.
>
> My email client converted to spaces I was referring to the "u32    reg;"
> above.  I think it should be "u32reg" instead of "u32reg".
> Other places in this patch spaces are used (eg in enable_cpu_clock, and
> in the struct declaration above), so at a minimum the tabs/spaces should
> be changed to be consistent, and  seems cleanest to
> me.
I see. I can change to  globally, no problem.

>
>> >
>> >> +     /* Is PLL-X already running? */
>> >> +     reg = readl(&clkrst->crc_pllx_base);
>> >> +     if (reg & PLL_ENABLE)
>> >> +             return;
>> >> +
>> >> +     /* Do PLLX init if it isn't running, but BootROM sets it, so TBD */
>> >> +}
>> >
>> > The above function looks incorrect.
>> What looks incorrect? It checks to see if the PLL is already
>> running/enabled, and returns if it is.
>> Tegra2 mask ROM (BootROM) currently always sets PLLX, so this will
>> always return, but the comment is there for future chips that may not
>> set up PLLX.
>
> It looks like a function that does a read of a value it doesn't care
> about, does an unnecessary comparison, and then returns either way,
> without doing anything:)  If/when you want to do future stuff with the
> PLL-X, code should be added then - as is it doesn't do anything and is
> confusing.  The general policy of U-Boot is not to add dead code.
OK, so not really incorrect, just unnecessary. Agreed - again a
vestigial leftover from our in-house code. I'll remove it.

>
> 
>
>> >> +static void enable_cpu_power_rail(void)
>> >> +{
>> >> +     struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
>> >> +     u32   reg;
>> >> +
>> >> +     reg = readl(&pmc->pmc_cntrl);
>> >> +     reg |= CPUPWRREQ_OE;
>> >> +     writel(reg, &pmc->pmc_cntrl);
>> >> +
>> >> +     /* Delay to allow for stable power (CPU_PWR_REQ -> VDD_CPU from 
>> >> PMU) */
>> >> +     udelay(3750);
>> >
>> > Ditto for description.
>> Ditto on why the delay? In this case, I did find a reference to the
>> time needed between the request from the chipset to the PMU, hence the
>> comment.
>
> It'd be nice mention that reference in the comment.  For those designing
> boards around your chips, during debug they will look through the
> initialization code and wonder "I wonder if we need to delay longer", or
> "I'm not using the same power supply sequencer, I wonder if this might
> be a problem".  If you more explicitly state where the delay came from,
> or what the delay specifically accomplishes, it saves others from having
> to guess and investigate.
OK, I'll expand the comment.

>
>> >> +}
>> >> +
>> >> +static void reset_A9_cpu(int reset)
>> >> +{
>> >> +     struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
>> >> *)NV_PA_CLK_RST_BASE;
>> >> +     u32   reg, cpu;
>> >> +
>> >> +     /*
>> >> +     * NOTE:  Regardless of whether the request is to hold the CPU in 
>> >> reset
>> >> +     *        or take it out of reset, every processor in the CPU complex
>> >> +     *        except the master (CPU 0) will be held in reset because the
>> >> +     *        AVP only talks to the master. The AVP does not know that 
>> >> there
>> >> +     *        are multiple processors in the CPU complex.
>> >> +     */
>> >> +
>> >> +     /* Hold CPU 1 in reset */
>> >> +     cpu = SET_DBGRESET1 | SET_DERESET1 | SET_CPURESET1;
>> >> +     writel(cpu, &clkrst->crc_cpu_cmplx_set);
>> >
>> > The cpu variable can be removed.
>> It could be, sure. But it makes the line longer, >80 chars, and hence
>> it would have to be broken into two lines.
>> Actually, now that I look at the code again, it appears that 'cpu'
>> later should be OR'd with the SET_/CLR_DBGRESET0, etc. bits, depending
>> on the state of 'reset'.
>> I'll give it a rewrite for the next patch.
>
> Its a matter of preference, but is acceptable either way.  I think:
> +       writel(SET_DBGRESET1 | SET_DERESET1 | SET_CPURESET1,
> +               &clkrst->crc_cpu_cmplx_set);
>
> makes it clearer what is going on.  Setting 'cpu', then writing would
> imply to me that 'cpu' has some additional purpose, or is being used
> later.  If you restructure the code, this comment will likely be moot.
>
> 
>
>> >> +     if (enable) {
>> >> +             /*
>> >> +              * Put CoreSight on PLLP_OUT0 (216 MHz) and divide it down 
>> >> by
>> >> +              *  1.5, giving an effective frequency of 144MHz.
>> >> +              * Set PLLP_OUT0 [bits31:30 = 00], and use a 7.1 divisor
>> >> +              *  (bits 7:0), so 0001b == 1.5 (n+1 + .5)
>> >> +              */
>> >> +             src = CLK_DIVIDER(NVB

Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init

2011-03-14 Thread Peter Tyser
Hi Tom,



> >> +static void init_pll_x(void)
> >> +{
> >> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
> >> *)NV_PA_CLK_RST_BASE;
> >> + u32 reg;
> >
> > The spaces in front of "reg" can be removed.  Ditto for all
> > functions/variables.
> Not sure what you mean, here, Peter. There are no spaces here in my
> ap20.c file, just tabs.
> Please clarify.

My email client converted to spaces I was referring to the "u32reg;"
above.  I think it should be "u32reg" instead of "u32reg".
Other places in this patch spaces are used (eg in enable_cpu_clock, and
in the struct declaration above), so at a minimum the tabs/spaces should
be changed to be consistent, and  seems cleanest to
me.

> >
> >> + /* Is PLL-X already running? */
> >> + reg = readl(&clkrst->crc_pllx_base);
> >> + if (reg & PLL_ENABLE)
> >> + return;
> >> +
> >> + /* Do PLLX init if it isn't running, but BootROM sets it, so TBD */
> >> +}
> >
> > The above function looks incorrect.
> What looks incorrect? It checks to see if the PLL is already
> running/enabled, and returns if it is.
> Tegra2 mask ROM (BootROM) currently always sets PLLX, so this will
> always return, but the comment is there for future chips that may not
> set up PLLX.

It looks like a function that does a read of a value it doesn't care
about, does an unnecessary comparison, and then returns either way,
without doing anything:)  If/when you want to do future stuff with the
PLL-X, code should be added then - as is it doesn't do anything and is
confusing.  The general policy of U-Boot is not to add dead code.



> >> +static void enable_cpu_power_rail(void)
> >> +{
> >> + struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
> >> + u32   reg;
> >> +
> >> + reg = readl(&pmc->pmc_cntrl);
> >> + reg |= CPUPWRREQ_OE;
> >> + writel(reg, &pmc->pmc_cntrl);
> >> +
> >> + /* Delay to allow for stable power (CPU_PWR_REQ -> VDD_CPU from PMU) 
> >> */
> >> + udelay(3750);
> >
> > Ditto for description.
> Ditto on why the delay? In this case, I did find a reference to the
> time needed between the request from the chipset to the PMU, hence the
> comment.

It'd be nice mention that reference in the comment.  For those designing
boards around your chips, during debug they will look through the
initialization code and wonder "I wonder if we need to delay longer", or
"I'm not using the same power supply sequencer, I wonder if this might
be a problem".  If you more explicitly state where the delay came from,
or what the delay specifically accomplishes, it saves others from having
to guess and investigate.

> >> +}
> >> +
> >> +static void reset_A9_cpu(int reset)
> >> +{
> >> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
> >> *)NV_PA_CLK_RST_BASE;
> >> + u32   reg, cpu;
> >> +
> >> + /*
> >> + * NOTE:  Regardless of whether the request is to hold the CPU in 
> >> reset
> >> + *or take it out of reset, every processor in the CPU complex
> >> + *except the master (CPU 0) will be held in reset because the
> >> + *AVP only talks to the master. The AVP does not know that 
> >> there
> >> + *are multiple processors in the CPU complex.
> >> + */
> >> +
> >> + /* Hold CPU 1 in reset */
> >> + cpu = SET_DBGRESET1 | SET_DERESET1 | SET_CPURESET1;
> >> + writel(cpu, &clkrst->crc_cpu_cmplx_set);
> >
> > The cpu variable can be removed.
> It could be, sure. But it makes the line longer, >80 chars, and hence
> it would have to be broken into two lines.
> Actually, now that I look at the code again, it appears that 'cpu'
> later should be OR'd with the SET_/CLR_DBGRESET0, etc. bits, depending
> on the state of 'reset'.
> I'll give it a rewrite for the next patch.

Its a matter of preference, but is acceptable either way.  I think:
+   writel(SET_DBGRESET1 | SET_DERESET1 | SET_CPURESET1,
+   &clkrst->crc_cpu_cmplx_set);

makes it clearer what is going on.  Setting 'cpu', then writing would
imply to me that 'cpu' has some additional purpose, or is being used
later.  If you restructure the code, this comment will likely be moot.



> >> + if (enable) {
> >> + /*
> >> +  * Put CoreSight on PLLP_OUT0 (216 MHz) and divide it down by
> >> +  *  1.5, giving an effective frequency of 144MHz.
> >> +  * Set PLLP_OUT0 [bits31:30 = 00], and use a 7.1 divisor
> >> +  *  (bits 7:0), so 0001b == 1.5 (n+1 + .5)
> >> +  */
> >> + src = CLK_DIVIDER(NVBL_PLLP_KHZ, 144000);
> >> + writel(src, &clkrst->crc_clk_src_csite);
> >> +
> >> + /* Unlock the CPU CoreSight interfaces */
> >> + rst = 0xC5ACCE55;
> >
> > What's this number?  Is there a define that could be used instead?
> Sure, I can add a #define. Some magic ARM access sequence to unlock
> the CoreSight I/F, as the comment says

Its not clear what the number is from the comm

Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Wolfgang Denk
Dear "Moffett, Kyle D",

In message <44a75130-ed4f-46d6-b0e4-12433cc15...@boeing.com> you wrote:
> 
> Oh, absolutely. I do think there still needs to be a separation
> between a "normal user-initiated restart" and an "panic-time
> emergency restart" though, see further on in this email.

These terms refer to another software level, though.

do_reset() is supposed to provide a hard reset function, nothing else
- as mentioned, the software way of pressing the reset button (or
pulling the plug).

A "normal user-initiated restart" would be the equivalent of a
"shutdown -r" in Linux context. We don't offer such a service in
U-Boot, as it has never been needed yet. If implemented, it would
probably call do_reset() as last of it's actions.

A "panic-time emergency restart" can be anything, too - again, it
would probably call do_reset() at the end.

> Such decisions on what is and is not "acceptable" to run on a panic()
> are better left to the individual boards and architectures.

This is a completely new topic now.   We have not been discussing the
implementation or function of panic() before.  This has nothing to do
with what do_reset() is supposed to do - do_reset() may (or may not)
be one action called by panic() [and if so, it should be the last
thing that panic() has been doing.]

> Specifically, the separate board and arch hooks for regular and
> "emergency" restarts that I included in the patch:
> 
>   __arch_restart()
>   __board_restart()
>   __arch_emergency_restart()
>   __board_emergency_restart()

Yes, and I object against such unneeded (for everybody else)
complexity.


> I would argue that is a bug to be fixed. Regardless of how various
> boards and architectures implement "reset", U-Boot should provide
> generic functionality to drivers and library code to allow them to
> indicate what they want:
> 
>   (1) A safe normal operational restart, with all hardware shut down
> (as much as is considered necessary on the platform). Depending on
> the platform this may fail or take some time.
> 
>   (2) A critical error restart, where system state may be undefined
> and the calling code does not expect the function to ever return.

This is overkill for a boot loader.  We assume that when anything goes
wrong we do the best we can to perform a hard reset.  Any halfway sane
hardware design will allow you do do that.  There is a zillion of ways
to do that - from causing a machine check, using a hardware watchdog,
messing limits of system monitor chips, etc. etc.  Or there is a
simple GPIO pin that triggers an external hard reset.

If some hardware provides no such option I will not hesitate to call
this a hardare bug and blame the hardware designer.

Workarounds for such bugs should be dealt with in board specific code.

> Linux has *both* of those cases in the kernel: sys_reboot() and
> emergency_restart().

Linux is an OS.  U-Boot is a boot loader.

Linux offers many things and services that are not available in
U-Boot.

I am even tempted to recommend you to boot Linux as part of your reset
sequence ;-)

> The "jump to _start" case is very similar to Linux kexec().  There are two 
> specific use-cases:

The "jump to _start" case is something I consider a bug that should be
fixed.  I will not accept the existence of such code as reason to
build arbitrarily complex layers on top of it.  It may be the best
possible solution in the given case (which I actually doubt), but even
then it's just that: the best possible approximation to what
actuallyis needed.

>   (1) Safe reliable run-time handoff from one kernel to another
>   (2) Emergency panic() call into another kernel to record the error and 
> reboot safely

U-Boot just provides "reset".


I think I understand what you have in mind, but I'm not going to
accept that, especially not in common code.  Sorry.

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
Remember that Beethoven wrote his first symphony in C ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Scott Wood
On Mon, 14 Mar 2011 16:25:54 -0500
Kumar Gala  wrote:

> 
> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
> 
> > On Sat, 12 Mar 2011 16:56:09 -0600
> > Kumar Gala  wrote:
> > 
> >> 
> >> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
> >> 
> >>> I was surprised to find myself at the decrement interrupt when running my 
> >>> new stuff.
> >>> That is against ePAPR, right?
> >>> Does u-boot at least make sure that the DEC is set to some large value 
> >>> before it leaps at me?
> >>> I don't mind forcing EE=0 but I'd like to make sure I make it that far 
> >>> into the code :)
> >>> -JX
> >> 
> >> Jimi,
> >> 
> >> Not sure how or why you are seeing this, but u-boot should disable 
> >> interrupts in common/cmd_bootm.c
> >> 
> >> Look for disable_interrupts() -> this should set MSR[EE] = 0.
> > 
> > What about the rest of MSR -- ME/CE/DE?
> 
> I dont think we ever turn on CE in u-boot, DE would only get set in some 
> weird external debugger build.

>From arch/powerpc/cpu/mpc85xx/start.S:

/* switch back to AS = 0 */
lis r3,(MSR_CE|MSR_ME|MSR_DE)@h
ori r3,r3,(MSR_CE|MSR_ME|MSR_DE)@l
mtmsr   r3
isync

bl  cpu_init_f
bl  board_init_f
isync

-Scott

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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC

2011-03-14 Thread York Sun
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
> 
> Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
> and DDR frequencies), we can easily restructure the computation to use
> the "do_div()" function to perform 64-bit/32-bit divide operations.
> 
> This decreases compute time rather significantly for each conversion and
> avoids bringing in a very complicated function from libgcc.
> 
> It should be noted that nothing else in U-Boot or the Linux kernel seems
> to require a full 64-bit divide on any 32-bit PowerPC.
> 
> Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Wolfgang Denk 
> Cc: Kim Phillips 
> ---

Acked-by: York Sun 


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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on32-bit PowerPC

2011-03-14 Thread Moffett, Kyle D
On Mar 14, 2011, at 16:22, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> + * Now divide by 5^12 and track the 32-bit remainder, then divide
>> + * by 2*(2^12) using shifts (and updating the remainder).
>> + */
>> +clks_rem = do_div(clks, UL_5pow12);
>> +clks_rem <<= 13;
> 
> Shouldn't this be clks_rem >>= 13 ?
>> 
>> +clks_rem |= clks & (UL_2pow13-1);
>> +clks >>= 13;
>> +
>> +/* If we had a remainder, then round up */
>> +if (clks_rem)
>>  clks++;
>> -}

Since I'm dividing a second time, the old remainder value represents the high 
bits of the new remainder value and therefore needs to be left-shifted, then 
the now-empty low bits of the remainder are taken from the bits of "clks" which 
get shifted away.

Example:

Say I want to divide 1 (IE: 2*10^^12 - 1) by 2 
(2*10^^12).  Obviously the dividend is less than the divisor (by 1), so the 
result should be 0 and the remainder should be equal to the dividend.

So my initial value is:
  clks = 1;

Now I divide by 5^^12:
  clks_rem = do_div(clks, 244140625); /* This number is 5pow12 */

The results are:
  clks_rem == 244140624
  clks == 8191

Now I shift left:
  clks_rem <<= 13;

And get:
  clks_rem == 11808

Finally, I copy the low bits of clks to clks_rem and shift them out of clks:
  clks_rem |= clks & (UL_2pow13-1);
  clks >>= 13

The result is as expected:
  clks_rem == 1;
  clks == 0;

Cheers,
Kyle Moffett

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


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Kumar Gala

On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:

> On Sat, 12 Mar 2011 16:56:09 -0600
> Kumar Gala  wrote:
> 
>> 
>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>> 
>>> I was surprised to find myself at the decrement interrupt when running my 
>>> new stuff.
>>> That is against ePAPR, right?
>>> Does u-boot at least make sure that the DEC is set to some large value 
>>> before it leaps at me?
>>> I don't mind forcing EE=0 but I'd like to make sure I make it that far into 
>>> the code :)
>>> -JX
>> 
>> Jimi,
>> 
>> Not sure how or why you are seeing this, but u-boot should disable 
>> interrupts in common/cmd_bootm.c
>> 
>> Look for disable_interrupts() -> this should set MSR[EE] = 0.
> 
> What about the rest of MSR -- ME/CE/DE?

I dont think we ever turn on CE in u-boot, DE would only get set in some weird 
external debugger build.

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


[U-Boot] [PATCH v2 4/5] MIPS: IncaIP: Move all IncaIP specific code to separate subdirectory

2011-03-14 Thread daniel . schwierzeck
IncaIP is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.

Signed-off-by: Daniel Schwierzeck 
Cc: Shinya Kuribayashi 
Cc: Wolfgang Denk 
---
 arch/mips/cpu/mips32/Makefile|2 -
 arch/mips/cpu/mips32/incaip/Makefile |   46 ++
 arch/mips/cpu/mips32/{ => incaip}/asc_serial.c   |0
 arch/mips/cpu/mips32/{ => incaip}/asc_serial.h   |0
 arch/mips/cpu/mips32/incaip/config.mk|   24 +++
 arch/mips/cpu/mips32/{ => incaip}/incaip_clock.c |0
 arch/mips/cpu/mips32/{ => incaip}/incaip_wdt.S   |0
 boards.cfg   |8 ++--
 8 files changed, 74 insertions(+), 6 deletions(-)
 create mode 100644 arch/mips/cpu/mips32/incaip/Makefile
 rename arch/mips/cpu/mips32/{ => incaip}/asc_serial.c (100%)
 rename arch/mips/cpu/mips32/{ => incaip}/asc_serial.h (100%)
 create mode 100644 arch/mips/cpu/mips32/incaip/config.mk
 rename arch/mips/cpu/mips32/{ => incaip}/incaip_clock.c (100%)
 rename arch/mips/cpu/mips32/{ => incaip}/incaip_wdt.S (100%)

diff --git a/arch/mips/cpu/mips32/Makefile b/arch/mips/cpu/mips32/Makefile
index 816b76c..88e3023 100644
--- a/arch/mips/cpu/mips32/Makefile
+++ b/arch/mips/cpu/mips32/Makefile
@@ -29,8 +29,6 @@ START = start.o
 SOBJS-y= cache.o
 COBJS-y= cpu.o interrupts.o

-SOBJS-$(CONFIG_INCA_IP)+= incaip_wdt.o
-COBJS-$(CONFIG_INCA_IP)+= asc_serial.o incaip_clock.o
 COBJS-$(CONFIG_SOC_AU1X00) += au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o

 SRCS   := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
diff --git a/arch/mips/cpu/mips32/incaip/Makefile 
b/arch/mips/cpu/mips32/incaip/Makefile
new file mode 100644
index 000..9c2b1aa
--- /dev/null
+++ b/arch/mips/cpu/mips32/incaip/Makefile
@@ -0,0 +1,46 @@
+#
+# (C) Copyright 2011
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+SOBJS  = incaip_wdt.o
+COBJS  = incaip_clock.o asc_serial.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/mips/cpu/mips32/asc_serial.c 
b/arch/mips/cpu/mips32/incaip/asc_serial.c
similarity index 100%
rename from arch/mips/cpu/mips32/asc_serial.c
rename to arch/mips/cpu/mips32/incaip/asc_serial.c
diff --git a/arch/mips/cpu/mips32/asc_serial.h 
b/arch/mips/cpu/mips32/incaip/asc_serial.h
similarity index 100%
rename from arch/mips/cpu/mips32/asc_serial.h
rename to arch/mips/cpu/mips32/incaip/asc_serial.h
diff --git a/arch/mips/cpu/mips32/incaip/config.mk 
b/arch/mips/cpu/mips32/incaip/config.mk
new file mode 100644
index 000..ecfcb9c
--- /dev/null
+++ b/arch/mips/cpu/mips32/incaip/config.mk
@@ -0,0 +1,24 @@
+#
+# (C) Copyright 2011
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+PLATFORM_CPPFLAGS += $(call cc-option,-mtune=4kc)
diff --git a/arch/mips/cpu/mips32/incaip_clock.c 
b/arch/mips/cpu/mips32/incaip/incaip_clock.c
similarity index 100%
rename from arch/

Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Moffett, Kyle D
On Mar 14, 2011, at 16:38, Wolfgang Denk wrote:
> In message <613c8f89-3ce5-4c28-a48e-d5c3e8143...@boeing.com> you wrote:
>> 
>> If just *one* of the 2 CPUs triggers the reset then only *some* of
>> the attached hardware will be properly reset due to a hardware
>> errata, and as a result the board will sometimes hang or corrupt DMA
>> transfers to the SSDs shortly after reset.
> ...
>> Yes, it's a royal pain, but we're stuck with this hardware for the
>> time being, and if the board can't communicate then it might as well
>> hang() anyways.
> 
> Do you agree that this is a highly board-specific problem (I would
> call it a hardware bug, but I don't insist you agree on that term),
> and while there is a the need for you to work around such behaviour
> there is little or no reason to do this, or anything like that, in
> common code ?

Oh, absolutely.  I do think there still needs to be a separation between a 
"normal user-initiated restart" and an "panic-time emergency restart" though, 
see further on in this email.

The comment about Ctrl-C was simply because our board restart can be aborted by 
someone at the console because it may take a while for the other CPU to cleanly 
shut down and acknowledge.  Our __board_restart() watches for Ctrl-C to handle 
this nicely, and then returns an error, which makes do_reset() return to the 
user or script with an error.  Obviously in the middle of a panic() there is 
nothing useful to return to, so the code keeps polling regardless.

Such decisions on what is and is not "acceptable" to run on a panic() are 
better left to the individual boards and architectures.  Specifically, the 
separate board and arch hooks for regular and "emergency" restarts that I 
included in the patch:

  __arch_restart()
  __board_restart()
  __arch_emergency_restart()
  __board_emergency_restart()

>>> And if there are more things that could be done to provide a "better"
>>> reset, then why should we not always do these?
>> 
>> If the board is in a panic() state it may well have still-running DMA
>> transfers (such as USB URBs), or be in the middle of writing to
>> FLASH.
> 
> The same (at least having USB or other drivers still being enabled,
> and USB writing it's SOF counters to RAM) can happen for any call to
> the reset() function.  I see no reason for assuming there would be
> better or worse conditions to perform a reset.

I would argue that is a bug to be fixed.  Regardless of how various boards and 
architectures implement "reset", U-Boot should provide generic functionality to 
drivers and library code to allow them to indicate what they want:

  (1) A safe normal operational restart, with all hardware shut down (as much 
as is considered necessary on the platform).  Depending on the platform this 
may fail or take some time.

  (2) A critical error restart, where system state may be undefined and the 
calling code does not expect the function to ever return.

Linux has *both* of those cases in the kernel:  sys_reboot() and 
emergency_restart().

>> If this board starts receiving packets and then panic()s, it will
>> disable address translation and immediately re-relocate U-Boot into
>> RAM, then zero the BSS. If the network card tries to receive a packet
>> after BSS is zeroed, it will read a packet buffer address of
>> (probably) 0x0 from the RX ring and promptly overwrite part of
>> U-Boot's memory at that address.
> 
> Agreed.  So this should be fixed.  One clean way to fix it would be to
> help improving the driver model for U-Boot (read: create one) and
> making sure drivers get deinitialized in such a case.

This another excellent reason to have separate system_restart() and 
emergency_restart().  The "system_restart()" function would hook into the 
driver model and perform device shutdown (just like Linux), while the 
emergency_restart() function (and therefore panic()) would not.

The "jump to _start" case is very similar to Linux kexec().  There are two 
specific use-cases:
  (1) Safe reliable run-time handoff from one kernel to another
  (2) Emergency panic() call into another kernel to record the error and reboot 
safely

In the former case, the kernel runs all of its normal shutdown handlers and 
quiesces all DMA before passing control to the new kernel.  Under U-Boot this 
is analogous to the "system_restart()" function I added.  The 
"system_restart()" function would be the ideal central place to hook 
driver-model device shut-down.

In the latter case (similar to "emergency_restart()"), the new kernel runs in a 
sub-section of memory *completely-preallocated* at boot time, and explicitly 
ignores all other memory because there might be ongoing DMA transactions.  The 
"emergency kexec" case intentionally avoids running device shutdown handlers 
because the system state is not well defined.  Under U-Boot there is no way to 
run completely from a preallocated chunk of memory, which means that a 
panic()-time jump to "_start" is not safe.

Cheers,
Kyle Moffett

___

Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init

2011-03-14 Thread Tom Warren
Peter,

On Mon, Mar 14, 2011 at 8:33 AM, Peter Tyser  wrote:
> Hi Tom,
> I'm not too familiar with the architecture, so many comments are
> aesthetic.  It would be a good idea to run the patch through
> checkpatch.pl too.
I run checkpatch on every submission. Only 1 warning was generated
(about an extern), and no errors.

>
>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>> index 684f2d2..50a1725 100644
>> --- a/arch/arm/cpu/armv7/start.S
>> +++ b/arch/arm/cpu/armv7/start.S
>> @@ -70,6 +70,12 @@ _end_vect:
>>  _TEXT_BASE:
>>       .word   CONFIG_SYS_TEXT_BASE
>>
>> +#ifdef CONFIG_TEGRA2
>> +.globl _armboot_start
>> +_armboot_start:
>> +        .word _start
>> +#endif
>> +
>
> It'd be good to add a comment about what's going on above, and why its
> tegra2-specific.  Eg why is it needed?
Tegra uses 2 separate CPUs - the AVP (ARM7TDI) and the dual-core A9. A
bootloader first runs on the AVP and sets things up for the CPU
complex to take over.
The CPU complex jumps here during it's init phase/boot (from it's
reset vector). It needs a dereferenced jump to the _start code in
start.S (which in turn chains to the reset code).
I'll add a comment about this in the next patch.

> 
>
>> +static void init_pll_x(void)
>> +{
>> +     struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
>> *)NV_PA_CLK_RST_BASE;
>> +     u32     reg;
>
> The spaces in front of "reg" can be removed.  Ditto for all
> functions/variables.
Not sure what you mean, here, Peter. There are no spaces here in my
ap20.c file, just tabs.
Please clarify.

>
>> +     /* Is PLL-X already running? */
>> +     reg = readl(&clkrst->crc_pllx_base);
>> +     if (reg & PLL_ENABLE)
>> +             return;
>> +
>> +     /* Do PLLX init if it isn't running, but BootROM sets it, so TBD */
>> +}
>
> The above function looks incorrect.
What looks incorrect? It checks to see if the PLL is already
running/enabled, and returns if it is.
Tegra2 mask ROM (BootROM) currently always sets PLLX, so this will
always return, but the comment is there for future chips that may not
set up PLLX.

>
>> +static void set_cpu_reset_vector(u32 vector)
>> +{
>> +     writel(vector, EXCEP_VECTOR_CPU_RESET_VECTOR);
>> +}
>
> Is it worth breaking this out into its own function?  The define names
> make it pretty clear what is being done, and its only called from 1
> location.
I can move the writel() to the called location and remove this func.

>
>> +static void enable_cpu_clock(int enable)
>> +{
>> +     struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr 
>> *)NV_PA_CLK_RST_BASE;
>> +     u32   reg, clk;
>> +
>> +     /*
>> +      * NOTE:
>> +      * Regardless of whether the request is to enable or disable the CPU
>> +      * clock, every processor in the CPU complex except the master (CPU 0)
>> +      * will have it's clock stopped because the AVP only talks to the
>> +      * master. The AVP does not know (nor does it need to know) that there
>> +      * are multiple processors in the CPU complex.
>> +      */
>> +
>> +     /* Need to initialize PLLX? */
>> +     if (enable) {
>> +             /* Initialize PLL */
>> +             init_pll_x();
>> +
>> +             /* Wait until stable */
>> +             udelay(NVBOOT_CLOCKS_PLL_STABILIZATION_DELAY);
>> +
>> +             reg = CCLK_BURST_POLICY;
>> +             writel(reg, &clkrst->crc_cclk_brst_pol);
>
> It'd look cleaner to not set "reg" for each access, just use the define
> directly.  I'd personally use less temporary variables in general and
> only use them when it made the code cleaner and easier to understand.
Will do. This code was ported from our orignal, in-house bootloader,
so it's going to be a bit hairy.

>
>> +             reg = SUPER_CCLK_DIVIDER;
>> +             writel(reg, &clkrst->crc_super_cclk_div);
>> +     }
>> +
>> +     /* Fetch the register containing the main CPU complex clock enable */
>> +     reg = readl(&clkrst->crc_clk_out_enb_l);
>
> Is this read necessary?  You overwrite reg unconditionally below.
Yeah, I saw that and did a rewrite a week or two ago, but was waiting
to incorporate into the next patch to get everything in one place.

>
>> +     /*
>> +      * Read the register containing the individual CPU clock enables and
>> +      * always stop the clock to CPU 1.
>> +      */
>> +     clk = readl(&clkrst->crc_clk_cpu_cmplx);
>> +     clk |= CPU1_CLK_STP;
>> +
>> +     if (enable) {
>> +             /* Enable the CPU clock */
>> +             reg = readl(&clkrst->crc_clk_out_enb_l);
>> +             reg |= CLK_ENB_CPU;
>> +             clk = readl(&clkrst->crc_clk_cpu_cmplx);
>> +             clk &= ~CPU0_CLK_STP;
>> +     } else {
>> +             /* Disable the CPU clock */
>> +             reg = readl(&clkrst->crc_clk_out_enb_l);
>> +             reg |= CLK_ENB_CPU;
>> +             clk = readl(&clkrst->crc_clk_cpu_cmplx);
>> +             clk |= CPU0_CLK_STP;
>> +     }
>
> For if/elses that share common code, the common code should be broken
> out.  eg above only the 

[U-Boot] [PATCH v2 3/5] MIPS: Optimize the setup of endianess and CPU optimization flags

2011-03-14 Thread daniel . schwierzeck
The current Mips CPU config.mk code always expects a Mips 4kc
core and toolchain. This is not appropiate for other toolchains
and CPUs/SoCs.

Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Replace the endianess determination code from toolchain prefix by
a more generic one inspired by the Linux arch/mips/Makefile.

Signed-off-by: Daniel Schwierzeck 
Cc: Shinya Kuribayashi 
Cc: Wolfgang Denk 
---
 arch/mips/cpu/mips32/config.mk |   21 +++--
 1 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/mips/cpu/mips32/config.mk b/arch/mips/cpu/mips32/config.mk
index a173c54..a91dcb4 100644
--- a/arch/mips/cpu/mips32/config.mk
+++ b/arch/mips/cpu/mips32/config.mk
@@ -20,20 +20,13 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-v=$(shell $(AS) --version | grep 'GNU assembler' | egrep -o '2\.[0-9\.]+' | 
cut -d. -f2)
-MIPSFLAGS:=$(shell \
-if [ "$v" -lt "14" ]; then \
-   echo "-mcpu=4kc"; \
-else \
-   echo "-march=4kc -mtune=4kc"; \
-fi)

-ifneq (,$(findstring 4KCle,$(CROSS_COMPILE)))
-ENDIANNESS = -EL
-else
-ENDIANNESS = -EB
-endif
+# Optimization flags for all Mips32 CPUs
+MIPSFLAGS = $(call cc-option,-march=mips32r2,-mips32r2 -Wa,-mips32r2)

-MIPSFLAGS += $(ENDIANNESS)
+# Determine endianess from toolchain prefix
+ENDIANESS = $(shell $(CC) -dumpmachine | \
+   grep -q 'mips.*el-.*' && echo -EL || echo -EB)
+
+PLATFORM_CPPFLAGS += $(MIPSFLAGS) $(ENDIANESS)

-PLATFORM_CPPFLAGS += $(MIPSFLAGS)
--
1.7.4.1

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


[U-Boot] [PATCH v2 5/5] MIPS: Au1x00: Move all Au1x00 specific code to separate subdirectory

2011-03-14 Thread daniel . schwierzeck
Au1x00 is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.

Signed-off-by: Daniel Schwierzeck 
Cc: Shinya Kuribayashi 
Cc: Thomas Lange 
---
 arch/mips/cpu/mips32/Makefile  |2 -
 arch/mips/cpu/mips32/au1x00/Makefile   |   45 
 arch/mips/cpu/mips32/{ => au1x00}/au1x00_eth.c |0
 arch/mips/cpu/mips32/{ => au1x00}/au1x00_serial.c  |0
 .../mips/cpu/mips32/{ => au1x00}/au1x00_usb_ohci.c |0
 .../mips/cpu/mips32/{ => au1x00}/au1x00_usb_ohci.h |0
 arch/mips/cpu/mips32/au1x00/config.mk  |   24 ++
 boards.cfg |   14 +++---
 8 files changed, 76 insertions(+), 9 deletions(-)
 create mode 100644 arch/mips/cpu/mips32/au1x00/Makefile
 rename arch/mips/cpu/mips32/{ => au1x00}/au1x00_eth.c (100%)
 rename arch/mips/cpu/mips32/{ => au1x00}/au1x00_serial.c (100%)
 rename arch/mips/cpu/mips32/{ => au1x00}/au1x00_usb_ohci.c (100%)
 rename arch/mips/cpu/mips32/{ => au1x00}/au1x00_usb_ohci.h (100%)
 create mode 100644 arch/mips/cpu/mips32/au1x00/config.mk

diff --git a/arch/mips/cpu/mips32/Makefile b/arch/mips/cpu/mips32/Makefile
index 88e3023..e315c1b 100644
--- a/arch/mips/cpu/mips32/Makefile
+++ b/arch/mips/cpu/mips32/Makefile
@@ -29,8 +29,6 @@ START = start.o
 SOBJS-y= cache.o
 COBJS-y= cpu.o interrupts.o

-COBJS-$(CONFIG_SOC_AU1X00) += au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o
-
 SRCS   := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
 START  := $(addprefix $(obj),$(START))
diff --git a/arch/mips/cpu/mips32/au1x00/Makefile 
b/arch/mips/cpu/mips32/au1x00/Makefile
new file mode 100644
index 000..dc58475
--- /dev/null
+++ b/arch/mips/cpu/mips32/au1x00/Makefile
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2011
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS  = au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/mips/cpu/mips32/au1x00_eth.c 
b/arch/mips/cpu/mips32/au1x00/au1x00_eth.c
similarity index 100%
rename from arch/mips/cpu/mips32/au1x00_eth.c
rename to arch/mips/cpu/mips32/au1x00/au1x00_eth.c
diff --git a/arch/mips/cpu/mips32/au1x00_serial.c 
b/arch/mips/cpu/mips32/au1x00/au1x00_serial.c
similarity index 100%
rename from arch/mips/cpu/mips32/au1x00_serial.c
rename to arch/mips/cpu/mips32/au1x00/au1x00_serial.c
diff --git a/arch/mips/cpu/mips32/au1x00_usb_ohci.c 
b/arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c
similarity index 100%
rename from arch/mips/cpu/mips32/au1x00_usb_ohci.c
rename to arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c
diff --git a/arch/mips/cpu/mips32/au1x00_usb_ohci.h 
b/arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.h
similarity index 100%
rename from arch/mips/cpu/mips32/au1x00_usb_ohci.h
rename to arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.h
diff --git a/arch/mips/cpu/mips32/au1x00/config.mk 
b/arch/mips/cpu/mips32/au1x00/config.mk
new file mode 100644
index 000..ecfcb9c
--- /dev/null
+++ b/arch/mips/cpu/mips32/au1x00/config.mk
@@ -0,0 +1,24 @@
+#
+# (C) Copyright 2011
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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

[U-Boot] [PATCH v2 2/5] MIPS: Move content of arch/mips/cpu to arch/mips/cpu/mips32

2011-03-14 Thread daniel . schwierzeck
All current CPUs and SoCs are based on Mips32 arch. The complete
code resides in the global arch/mips/cpu directory. This is not
suitable if other Mips architectures like Mips64 or Octeon should
be supported in the future.

To achieve this the current CPU code is moved to its own mips32
subdirectory. All Mips32 boards have to use mips32 as config switch
in board.cfg.

Signed-off-by: Daniel Schwierzeck 
Cc: Shinya Kuribayashi 
Cc: Wolfgang Denk 
Cc: Stefan Roese 
Cc: Thomas Lange 
Cc: Vlad Lungu 
---
 arch/mips/cpu/{ => mips32}/Makefile  |0
 arch/mips/cpu/{ => mips32}/asc_serial.c  |0
 arch/mips/cpu/{ => mips32}/asc_serial.h  |0
 arch/mips/cpu/{ => mips32}/au1x00_eth.c  |0
 arch/mips/cpu/{ => mips32}/au1x00_serial.c   |0
 arch/mips/cpu/{ => mips32}/au1x00_usb_ohci.c |0
 arch/mips/cpu/{ => mips32}/au1x00_usb_ohci.h |0
 arch/mips/cpu/{ => mips32}/cache.S   |0
 arch/mips/cpu/{ => mips32}/config.mk |0
 arch/mips/cpu/{ => mips32}/cpu.c |0
 arch/mips/cpu/{ => mips32}/incaip_clock.c|0
 arch/mips/cpu/{ => mips32}/incaip_wdt.S  |0
 arch/mips/cpu/{ => mips32}/interrupts.c  |0
 arch/mips/cpu/{ => mips32}/start.S   |0
 boards.cfg   |   50 +-
 15 files changed, 25 insertions(+), 25 deletions(-)
 rename arch/mips/cpu/{ => mips32}/Makefile (100%)
 rename arch/mips/cpu/{ => mips32}/asc_serial.c (100%)
 rename arch/mips/cpu/{ => mips32}/asc_serial.h (100%)
 rename arch/mips/cpu/{ => mips32}/au1x00_eth.c (100%)
 rename arch/mips/cpu/{ => mips32}/au1x00_serial.c (100%)
 rename arch/mips/cpu/{ => mips32}/au1x00_usb_ohci.c (100%)
 rename arch/mips/cpu/{ => mips32}/au1x00_usb_ohci.h (100%)
 rename arch/mips/cpu/{ => mips32}/cache.S (100%)
 rename arch/mips/cpu/{ => mips32}/config.mk (100%)
 rename arch/mips/cpu/{ => mips32}/cpu.c (100%)
 rename arch/mips/cpu/{ => mips32}/incaip_clock.c (100%)
 rename arch/mips/cpu/{ => mips32}/incaip_wdt.S (100%)
 rename arch/mips/cpu/{ => mips32}/interrupts.c (100%)
 rename arch/mips/cpu/{ => mips32}/start.S (100%)

diff --git a/arch/mips/cpu/Makefile b/arch/mips/cpu/mips32/Makefile
similarity index 100%
rename from arch/mips/cpu/Makefile
rename to arch/mips/cpu/mips32/Makefile
diff --git a/arch/mips/cpu/asc_serial.c b/arch/mips/cpu/mips32/asc_serial.c
similarity index 100%
rename from arch/mips/cpu/asc_serial.c
rename to arch/mips/cpu/mips32/asc_serial.c
diff --git a/arch/mips/cpu/asc_serial.h b/arch/mips/cpu/mips32/asc_serial.h
similarity index 100%
rename from arch/mips/cpu/asc_serial.h
rename to arch/mips/cpu/mips32/asc_serial.h
diff --git a/arch/mips/cpu/au1x00_eth.c b/arch/mips/cpu/mips32/au1x00_eth.c
similarity index 100%
rename from arch/mips/cpu/au1x00_eth.c
rename to arch/mips/cpu/mips32/au1x00_eth.c
diff --git a/arch/mips/cpu/au1x00_serial.c 
b/arch/mips/cpu/mips32/au1x00_serial.c
similarity index 100%
rename from arch/mips/cpu/au1x00_serial.c
rename to arch/mips/cpu/mips32/au1x00_serial.c
diff --git a/arch/mips/cpu/au1x00_usb_ohci.c 
b/arch/mips/cpu/mips32/au1x00_usb_ohci.c
similarity index 100%
rename from arch/mips/cpu/au1x00_usb_ohci.c
rename to arch/mips/cpu/mips32/au1x00_usb_ohci.c
diff --git a/arch/mips/cpu/au1x00_usb_ohci.h 
b/arch/mips/cpu/mips32/au1x00_usb_ohci.h
similarity index 100%
rename from arch/mips/cpu/au1x00_usb_ohci.h
rename to arch/mips/cpu/mips32/au1x00_usb_ohci.h
diff --git a/arch/mips/cpu/cache.S b/arch/mips/cpu/mips32/cache.S
similarity index 100%
rename from arch/mips/cpu/cache.S
rename to arch/mips/cpu/mips32/cache.S
diff --git a/arch/mips/cpu/config.mk b/arch/mips/cpu/mips32/config.mk
similarity index 100%
rename from arch/mips/cpu/config.mk
rename to arch/mips/cpu/mips32/config.mk
diff --git a/arch/mips/cpu/cpu.c b/arch/mips/cpu/mips32/cpu.c
similarity index 100%
rename from arch/mips/cpu/cpu.c
rename to arch/mips/cpu/mips32/cpu.c
diff --git a/arch/mips/cpu/incaip_clock.c b/arch/mips/cpu/mips32/incaip_clock.c
similarity index 100%
rename from arch/mips/cpu/incaip_clock.c
rename to arch/mips/cpu/mips32/incaip_clock.c
diff --git a/arch/mips/cpu/incaip_wdt.S b/arch/mips/cpu/mips32/incaip_wdt.S
similarity index 100%
rename from arch/mips/cpu/incaip_wdt.S
rename to arch/mips/cpu/mips32/incaip_wdt.S
diff --git a/arch/mips/cpu/interrupts.c b/arch/mips/cpu/mips32/interrupts.c
similarity index 100%
rename from arch/mips/cpu/interrupts.c
rename to arch/mips/cpu/mips32/interrupts.c
diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/mips32/start.S
similarity index 100%
rename from arch/mips/cpu/start.S
rename to arch/mips/cpu/mips32/start.S
diff --git a/boards.cfg b/boards.cfg
index 63b1cda..8194bb2 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -217,31 +217,31 @@ M5282EVB m68kmcf52x2 
m5282evbfreesca
 M53017EVBm68kmcf52x2 m53017evb   
freescale
 EP2500   m68kmcf52x2 ep2500  

[U-Boot] [PATCH v2 1/5] MIPS: Purple: Remove Purple support

2011-03-14 Thread daniel . schwierzeck
The Purple SoC and eval board are not actively maintained since years.
This patch removes the support completely as aggreed with Wolfgang Denk.

Signed-off-by: Daniel Schwierzeck 
Cc: Shinya Kuribayashi 
Cc: Wolfgang Denk 
---
 MAINTAINERS |1 -
 MAKEALL |4 +-
 arch/mips/cpu/Makefile  |1 -
 arch/mips/cpu/asc_serial.c  |   83 --
 arch/mips/cpu/cache.S   |4 -
 arch/mips/cpu/start.S   |   32 --
 arch/mips/include/asm/inca-ip.h |   10 -
 arch/mips/lib/board.c   |   10 -
 board/purple/Makefile   |   46 ---
 board/purple/config.mk  |   32 --
 board/purple/flash.c|  595 ---
 board/purple/lowlevel_init.S|   36 ---
 board/purple/purple.c   |  284 ---
 board/purple/sconsole.c |  125 
 board/purple/sconsole.h |   46 ---
 board/purple/u-boot.lds |   75 -
 boards.cfg  |1 -
 doc/README.Purple   |   84 --
 include/configs/purple.h|  173 
 19 files changed, 1 insertions(+), 1641 deletions(-)
 delete mode 100644 board/purple/Makefile
 delete mode 100644 board/purple/config.mk
 delete mode 100644 board/purple/flash.c
 delete mode 100644 board/purple/lowlevel_init.S
 delete mode 100644 board/purple/purple.c
 delete mode 100644 board/purple/sconsole.c
 delete mode 100644 board/purple/sconsole.h
 delete mode 100644 board/purple/u-boot.lds
 delete mode 100644 doc/README.Purple
 delete mode 100644 include/configs/purple.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4756f14..1d7e1f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -919,7 +919,6 @@ Daniel Engstr
 Wolfgang Denk 

incaip  MIPS32 4Kc
-   purple  MIPS64 5Kc

 Thomas Lange 
dbau1x00MIPS32 Au1000
diff --git a/MAKEALL b/MAKEALL
index a732e6a..e1b928f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -507,9 +507,7 @@ LIST_mips4kc="  \
vct_premium_onenand_small   \
 "

-LIST_mips5kc=" \
-   purple  \
-"
+LIST_mips5kc=""

 LIST_au1xx0="  \
dbau1000\
diff --git a/arch/mips/cpu/Makefile b/arch/mips/cpu/Makefile
index 06df8d1..816b76c 100644
--- a/arch/mips/cpu/Makefile
+++ b/arch/mips/cpu/Makefile
@@ -31,7 +31,6 @@ COBJS-y   = cpu.o interrupts.o

 SOBJS-$(CONFIG_INCA_IP)+= incaip_wdt.o
 COBJS-$(CONFIG_INCA_IP)+= asc_serial.o incaip_clock.o
-COBJS-$(CONFIG_PURPLE) += asc_serial.o
 COBJS-$(CONFIG_SOC_AU1X00) += au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o

 SRCS   := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
diff --git a/arch/mips/cpu/asc_serial.c b/arch/mips/cpu/asc_serial.c
index be686c2..7239804 100644
--- a/arch/mips/cpu/asc_serial.c
+++ b/arch/mips/cpu/asc_serial.c
@@ -3,47 +3,10 @@
  */

 #include 
-
-#ifdef CONFIG_PURPLE
-#defineserial_init asc_serial_init
-#defineserial_putc asc_serial_putc
-#defineserial_puts asc_serial_puts
-#defineserial_getc asc_serial_getc
-#defineserial_tstc asc_serial_tstc
-#defineserial_setbrg   asc_serial_setbrg
-#endif
-
 #include 
 #include 
 #include "asc_serial.h"

-#ifdef CONFIG_PURPLE
-
-#undef ASC_FIFO_PRESENT
-#define TOUT_LOOP  10
-
-/* Set base address for second FPI interrupt control register bank */
-#define SFPI_INTCON_BASEADDR   0xBF0F
-
-/* Register offset from base address */
-#define FBS_ISR0x  /* Interrupt status register */
-#define FBS_IMR0x0008  /* Interrupt mask register */
-#define FBS_IDIS   0x0010  /* Interrupt disable register */
-
-/* Interrupt status register bits */
-#define FBS_ISR_AT 0x0040  /* ASC transmit interrupt */
-#define FBS_ISR_AR 0x0020  /* ASC receive interrupt */
-#define FBS_ISR_AE 0x0010  /* ASC error interrupt */
-#define FBS_ISR_AB 0x0008  /* ASC transmit buffer interrupt */
-#define FBS_ISR_AS  0x0004 /* ASC start of autobaud detection 
interrupt */
-#define FBS_ISR_AF 0x0002  /* ASC end of autobaud detection 
interrupt */
-
-#else
-
-#define ASC_FIFO_PRESENT
-
-#endif
-

 #define SET_BIT(reg, mask)  reg |= (mask)
 #define CLEAR_BIT(reg, mask)reg &= (~mask)
@@ -71,10 +34,8 @@ static volatile incaAsc_t *pAsc = (incaAsc_t *)INCA_IP_ASC;

 int serial_init (void)
 {
-#ifdef CONFIG_INCA_IP
 /* we have to set PMU.EN13 bit to enable an ASC device*/
 INCAASC_PMU_ENABLE(13);
-#endif

 /* and we have to set CLC register*/
 CLEAR_BIT(pAsc->asc_clc, ASCCLC_DISS);
@@ -86,7 +47,6 @@ int serial_init (void)
 /* select input port */
 pAsc->asc_pisel = (CONSOLE_TTY & 0x1);

-#ifdef ASC_FIFO_PRESENT
 /* TXFIFO's filling level */
 SET_BITFIELD(pAsc->asc_txfcon, ASCTXFCON_TXFITLMASK,
ASCTXFCON_TXFITLOFF, INCAASC_TXFI

[U-Boot] [PATCH v2 0/5] MIPS: Refactoring of CPU and SoC code

2011-03-14 Thread daniel . schwierzeck
All current Mips CPUs and SoCs except Purple are based on Mips32 arch.
The complete code resides in the global arch/mips/cpu directory.
All SoC specific code resides in this directory too. This is not suitable
if other Mips architectures like Mips64 or Octeon or new SoCs should be
supported in the future.

This patch series refactors the Mips CPU directory and put all current
code into an own mips32 subdirectory. Furthermore the SoC specific code
of IncaIP and Au1x00 is moved to separate SoC subdirectories.
The support for Purple is dropped because not actively maintained
anymore.

Changes since RFC/v1:
- drop Purple supported as agreed with Wolfgang Denk
- use MIPS rather than Mips in patch subject
- fixed Cc lines in all patches

Daniel Schwierzeck (5):
  MIPS: Purple: Remove Purple support
  MIPS: Move content of arch/mips/cpu to arch/mips/cpu/mips32
  MIPS: Optimize the setup of endianess and CPU optimization flags
  MIPS: IncaIP: Move all IncaIP specific code to separate subdirectory
  MIPS: Au1x00: Move all Au1x00 specific code to separate subdirectory

 MAINTAINERS|1 -
 MAKEALL|4 +-
 arch/mips/cpu/asc_serial.c |  368 
 arch/mips/cpu/config.mk|   39 --
 arch/mips/cpu/{ => mips32}/Makefile|5 -
 .../mips/cpu/mips32/au1x00}/Makefile   |   15 +-
 arch/mips/cpu/{ => mips32/au1x00}/au1x00_eth.c |0
 arch/mips/cpu/{ => mips32/au1x00}/au1x00_serial.c  |0
 .../mips/cpu/{ => mips32/au1x00}/au1x00_usb_ohci.c |0
 .../mips/cpu/{ => mips32/au1x00}/au1x00_usb_ohci.h |0
 .../mips/cpu/mips32/au1x00}/config.mk  |   12 +-
 arch/mips/cpu/{ => mips32}/cache.S |4 -
 arch/mips/cpu/mips32/config.mk |   32 +
 arch/mips/cpu/{ => mips32}/cpu.c   |0
 .../mips/cpu/mips32/incaip}/Makefile   |   16 +-
 arch/mips/cpu/mips32/incaip/asc_serial.c   |  285 ++
 arch/mips/cpu/{ => mips32/incaip}/asc_serial.h |0
 .../mips/cpu/mips32/incaip}/config.mk  |   12 +-
 arch/mips/cpu/{ => mips32/incaip}/incaip_clock.c   |0
 arch/mips/cpu/{ => mips32/incaip}/incaip_wdt.S |0
 arch/mips/cpu/{ => mips32}/interrupts.c|0
 arch/mips/cpu/{ => mips32}/start.S |   32 -
 arch/mips/include/asm/inca-ip.h|   10 -
 arch/mips/lib/board.c  |   10 -
 board/purple/flash.c   |  595 
 board/purple/lowlevel_init.S   |   36 --
 board/purple/purple.c  |  284 --
 board/purple/sconsole.c|  125 
 board/purple/sconsole.h|   46 --
 board/purple/u-boot.lds|   75 ---
 boards.cfg |   51 +-
 doc/README.Purple  |   84 ---
 include/configs/purple.h   |  173 --
 33 files changed, 362 insertions(+), 1952 deletions(-)
 delete mode 100644 arch/mips/cpu/asc_serial.c
 delete mode 100644 arch/mips/cpu/config.mk
 rename arch/mips/cpu/{ => mips32}/Makefile (87%)
 copy {board/purple => arch/mips/cpu/mips32/au1x00}/Makefile (83%)
 rename arch/mips/cpu/{ => mips32/au1x00}/au1x00_eth.c (100%)
 rename arch/mips/cpu/{ => mips32/au1x00}/au1x00_serial.c (100%)
 rename arch/mips/cpu/{ => mips32/au1x00}/au1x00_usb_ohci.c (100%)
 rename arch/mips/cpu/{ => mips32/au1x00}/au1x00_usb_ohci.h (100%)
 copy {board/purple => arch/mips/cpu/mips32/au1x00}/config.mk (83%)
 rename arch/mips/cpu/{ => mips32}/cache.S (98%)
 create mode 100644 arch/mips/cpu/mips32/config.mk
 rename arch/mips/cpu/{ => mips32}/cpu.c (100%)
 rename {board/purple => arch/mips/cpu/mips32/incaip}/Makefile (83%)
 create mode 100644 arch/mips/cpu/mips32/incaip/asc_serial.c
 rename arch/mips/cpu/{ => mips32/incaip}/asc_serial.h (100%)
 rename {board/purple => arch/mips/cpu/mips32/incaip}/config.mk (83%)
 rename arch/mips/cpu/{ => mips32/incaip}/incaip_clock.c (100%)
 rename arch/mips/cpu/{ => mips32/incaip}/incaip_wdt.S (100%)
 rename arch/mips/cpu/{ => mips32}/interrupts.c (100%)
 rename arch/mips/cpu/{ => mips32}/start.S (92%)
 delete mode 100644 board/purple/flash.c
 delete mode 100644 board/purple/lowlevel_init.S
 delete mode 100644 board/purple/purple.c
 delete mode 100644 board/purple/sconsole.c
 delete mode 100644 board/purple/sconsole.h
 delete mode 100644 board/purple/u-boot.lds
 delete mode 100644 doc/README.Purple
 delete mode 100644 include/configs/purple.h

--
1.7.4.1

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


[U-Boot] [RFC] I2C: change CONFIG_SYS_SPD_BUS_NUM to CONFIG_I2C_DEFAULT_BUS_NUM

2011-03-14 Thread Matthew McClintock
The bus that the i2c api can access before relocating from flash
is defined via CONFIG_SYS_SPD_BUS_NUM, however we want to use
the i2c bus before relocating from flash for non-SPD related
reasons. Therefore, we rename this define to something more
appropriate
---

We are trying to access the I2C bus before relocation from flash to read
switch settings. Using the current CONFIG_SYS_SPD_BUS_NUM define to do this
is fine for our needs however I would like to ask if we wanted to change
this to a new more generic define CONFIG_I2C_DEFAULT_BUS_NUM

 README|4 ++--
 arch/powerpc/cpu/mpc5xxx/i2c.c|2 +-
 arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c|2 +-
 arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c |2 +-
 board/freescale/common/sys_eeprom.c   |8 
 drivers/i2c/fsl_i2c.c |6 +++---
 drivers/i2c/ppc4xx_i2c.c  |8 
 include/configs/DU440.h   |2 +-
 include/configs/MPC8349ITX.h  |2 +-
 include/configs/MPC8536DS.h   |2 +-
 include/configs/MPC8572DS.h   |2 +-
 include/configs/P1022DS.h |2 +-
 include/configs/P2020DS.h |2 +-
 include/configs/corenet_ds.h  |2 +-
 include/configs/hcu4.h|2 +-
 include/configs/hcu5.h|2 +-
 include/configs/icon.h|2 +-
 include/configs/katmai.h  |2 +-
 include/configs/mcu25.h   |2 +-
 include/configs/sbc8349.h |2 +-
 include/configs/vme8349.h |2 +-
 include/i2c.h |4 ++--
 22 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/README b/README
index 21cd71b..4284809 100644
--- a/README
+++ b/README
@@ -1576,7 +1576,7 @@ The following options need to be configured:
 
will skip addresses 0x50 and 0x68 on bus 0 and address 0x54 on 
bus 1
 
-   CONFIG_SYS_SPD_BUS_NUM
+   CONFIG_I2C_DEFAULT_BUS_NUM
 
If defined, then this indicates the I2C bus number for DDR SPD.
If not defined, then U-Boot assumes that SPD is on I2C bus 0.
@@ -2834,7 +2834,7 @@ Low Level (hardware related) configuration options:
   SPD_EEPROM_ADDRESS
I2C address of the SPD EEPROM
 
-- CONFIG_SYS_SPD_BUS_NUM
+- CONFIG_I2C_DEFAULT_BUS_NUM
If SPD EEPROM is on an I2C bus other than the first
one, specify here. Note that the value must resolve
to something your driver can deal with.
diff --git a/arch/powerpc/cpu/mpc5xxx/i2c.c b/arch/powerpc/cpu/mpc5xxx/i2c.c
index 9fb330f..65fb1f2 100644
--- a/arch/powerpc/cpu/mpc5xxx/i2c.c
+++ b/arch/powerpc/cpu/mpc5xxx/i2c.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 #else
 static unsigned int i2c_bus_num __attribute__ ((section (".data"))) =
-   CONFIG_SYS_SPD_BUS_NUM;
+   CONFIG_I2C_DEFAULT_BUS_NUM;
 static unsigned int i2c_bus_speed[2] = {CONFIG_SYS_I2C_SPEED,
CONFIG_SYS_I2C_SPEED};
 
diff --git a/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c 
b/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c
index 95df1d9..00984cd 100644
--- a/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c
+++ b/arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c
@@ -475,7 +475,7 @@ phys_size_t initdram(int board_type)
 */
 
/* switch to correct I2C bus */
-   I2C_SET_BUS(CONFIG_SYS_SPD_BUS_NUM);
+   I2C_SET_BUS(CONFIG_I2C_DEFAULT_BUS_NUM);
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
 
/*--
diff --git a/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c 
b/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
index c35b113..1431056 100644
--- a/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
+++ b/arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c
@@ -1048,7 +1048,7 @@ phys_size_t initdram(int board_type)
 * before continuing.
 */
/* switch to correct I2C bus */
-   I2C_SET_BUS(CONFIG_SYS_SPD_BUS_NUM);
+   I2C_SET_BUS(CONFIG_I2C_DEFAULT_BUS_NUM);
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
 
/*--
diff --git a/board/freescale/common/sys_eeprom.c 
b/board/freescale/common/sys_eeprom.c
index 3ecfb06..2c678d3 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -495,11 +495,11 @@ int mac_read_from_eeprom(void)
  * This function is called before relocation, so we need to read a private
  * copy of the EEPROM into a local variable on the stack.
  *
- * Also, we assume that CONFIG_SYS_EEPROM_BUS_NUM == CONFIG_SYS_SPD_BUS_NUM.  
The global
- * variable i2c_bus_num must be compile-time initialized to 
CONFIG_SYS_SPD_BUS_NUM,
+ * Also, we as

Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Wolfgang Denk
Dear "Moffett, Kyle D",

In message <613c8f89-3ce5-4c28-a48e-d5c3e8143...@boeing.com> you wrote:
>
> On our boards, when the "reset" button is pressed in hardware, both
> processor modules on the board and all the attached hardware reset at
> the same time.

OK.  So a sane design would provide a way for both of the processors
to do the same, for example by toggeling some GPIO or similar.

> If just *one* of the 2 CPUs triggers the reset then only *some* of
> the attached hardware will be properly reset due to a hardware
> errata, and as a result the board will sometimes hang or corrupt DMA
> transfers to the SSDs shortly after reset.
...
> Yes, it's a royal pain, but we're stuck with this hardware for the
> time being, and if the board can't communicate then it might as well
> hang() anyways.

Do you agree that this is a highly board-specific problem (I would
call it a hardware bug, but I don't insist you agree on that term),
and while there is a the need for you to work around such behaviour
there is little or no reason to do this, or anything like that, in
common code ?


> > And if there are more things that could be done to provide a "better"
> > reset, then why should we not always do these?
> 
> If the board is in a panic() state it may well have still-running DMA
> transfers (such as USB URBs), or be in the middle of writing to
> FLASH.

The same (at least having USB or other drivers still being enabled,
and USB writing it's SOF counters to RAM) can happen for any call to
the reset() function.  I see no reason for assuming there would be
better or worse conditions to perform a reset.

> Performing a jump to early-boot code which is only ever tested when
> everything is OK and devices are properly initialized is a great way
> to cause data corruption.

If there is a software way to prevent such issues, then these steps
should always be performed.

> I know for a fact that our boards would rather hang forever than try
> to reset without cooperation from the other CPU.

As mentioned above, this is a board specific issue that should not
influence common code design.

> >> While I was going through the hooks I noticed that several of them were
> >> explicitly NOT safe if the board was in the middle of a panic() for 
> >> whatever
> > 
> > Can you please peovide some specific examples?  I don't understand what
> > you are talking about.
> 
> Ok, using the ppmc7xx board as an example:
> 
> /* Disable and invalidate cache */
> icache_disable();
> dcache_disable();
> 
> /* Jump to cold reset point (in RAM) */
> _start();
> 
> /* Should never get here */
> while(1)
> ;
> 
> This board uses the EEPRO100 driver, which appears to set up
> statically allocated TX and RX rings which the device performs DMA
> to/from.
> 
> If this board starts receiving packets and then panic()s, it will
> disable address translation and immediately re-relocate U-Boot into
> RAM, then zero the BSS. If the network card tries to receive a packet
> after BSS is zeroed, it will read a packet buffer address of
> (probably) 0x0 from the RX ring and promptly overwrite part of
> U-Boot's memory at that address.

Agreed.  So this should be fixed.  One clean way to fix it would be to
help improving the driver model for U-Boot (read: create one) and
making sure drivers get deinitialized in such a case.

> Since the panic() path is so infrequently used and tested, it's
> better to be safe and hang() on the boards which do not have a
> reliable hardware-level reset than it is to cause undefined behavior
> or potentially corrupt data.

I disagree.  Instead of adding somewhat obscure alternate code paths
(which get tested even less frequently) we should focus oin fixing
such problems where we run into them.

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
Microsoft Multitasking:
 several applications can crash at the same time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] [v2] powerpc: 'monitor' environment variable contains full video configuration

2011-03-14 Thread Timur Tabi
Update the "monitor" environment variable (for Freescale chips that have a
DIU display controller) to designate the full video configuration, instead
of just the output monitor.

The old definition of the "monitor" environment variable only determines
which video port to use for output.  This variable is set to a number (0,
1, or sometimes 2) to specify a DVI, LVDS, or Dual-LVDS port.  The
resolution is hard-coded into board-specific code.  The Linux command-line
arguments need to be hard-coded to the proper video definition string.

Instead, the "monitor" variable is now set to a string that indicates not
only the part name, but also the resolution, color depth, and refresh rate.
This string is then parsed for all needed information, and can be passed to
the kernel via the 'diubootargs' environment variable.

Signed-off-by: Timur Tabi 
---

This patch depends on my previous patch, "[v4] powerpc: clean up DIU macro
definitions for Freescale reference boards".

 README|9 +-
 board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |   73 +-
 board/freescale/p1022ds/diu.c |   29 +-
 doc/README.video  |   29 +
 drivers/video/fsl_diu_fb.c| 1019 -
 include/configs/MPC8610HPCD.h |   16 +-
 include/configs/P1022DS.h |   12 +-
 include/fsl_diu_fb.h  |   91 +--
 8 files changed, 631 insertions(+), 647 deletions(-)
 rewrite drivers/video/fsl_diu_fb.c (63%)
 rewrite include/fsl_diu_fb.h (62%)

diff --git a/README b/README
index 9597fed..4fc35f4 100644
--- a/README
+++ b/README
@@ -1072,12 +1072,9 @@ The following options need to be configured:
CONFIG_VIDEO_BMP_LOGO
 
The DIU driver will look for the 'monitor' environment variable,
-   and if defined, enable the DIU as a console during boot.  This
-   variable should be set to one of these values:
-
-   '0' Output video to the DVI connector
-   '1' Output video to the LVDS connector
-   '2' Output video to the Dual-Link LVDS connector
+   and if defined, enable the DIU as a console during boot.  See
+   the documentation file README.video for a description of this
+   variable.
 
 - Keyboard Support:
CONFIG_KEYBOARD
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c 
b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
index 81e53e7..6ffe457 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
@@ -1,6 +1,7 @@
 /*
- * Copyright 2007 Freescale Semiconductor, Inc.
- * York Sun 
+ * Copyright 2007-2011 Freescale Semiconductor, Inc.
+ * Authors: York Sun 
+ *  Timur Tabi 
  *
  * FSL DIU Framebuffer driver
  *
@@ -27,6 +28,10 @@
 #include 
 #include 
 #include 
+#include "../common/pixis.h"
+
+#define PX_BRDCFG0_DLINK   0x10
+#define PX_BRDCFG0_DVISEL  0x08
 
 void diu_set_pixel_clock(unsigned int pixclock)
 {
@@ -49,50 +54,36 @@ void diu_set_pixel_clock(unsigned int pixclock)
debug("DIU: Modified value of CLKDVDR = 0x%08x\n", *guts_clkdvdr);
 }
 
-int platform_diu_init(unsigned int *xres, unsigned int *yres)
+int platform_diu_init(unsigned int xres, unsigned int yres)
 {
-   char *monitor_port;
-   int gamma_fix;
-   unsigned int pixel_format;
-   unsigned char tmp_val;
-   unsigned char pixis_arch;
-   u8 *pixis_base = (u8 *)PIXIS_BASE;
+   const char *monitor_port;
+   const char *name;
+   int gamma_fix = 0;
+   u32 pixel_format = 0x3316;
+   u8 temp;
 
-   tmp_val = in_8(pixis_base + PIXIS_BRDCFG0);
-   pixis_arch = in_8(pixis_base + PIXIS_VER);
+   temp = in_8(&pixis->brdcfg0);
 
monitor_port = getenv("monitor");
-   if (!strncmp(monitor_port, "0", 1)) {   /* 0 - DVI */
-   *xres = 1280;
-   *yres = 1024;
-   if (pixis_arch == 0x01)
-   pixel_format = 0x2317;
-   else
-   pixel_format = 0x3316;
-   gamma_fix = 0;
-   out_8(pixis_base + PIXIS_BRDCFG0, tmp_val | 0x08);
-
-   } else if (!strncmp(monitor_port, "1", 1)) { /* 1 - Single link LVDS */
-   *xres = 1024;
-   *yres = 768;
-   pixel_format = 0x3316;
-   gamma_fix = 0;
-   out_8(pixis_base + PIXIS_BRDCFG0, (tmp_val & 0xf7) | 0x10);
-
-   } else if (!strncmp(monitor_port, "2", 1)) { /* 2 - Double link LVDS */
-   *xres = 1280;
-   *yres = 1024;
-   pixel_format = 0x3316;
+   if (strncmp(monitor_port, "dlvds", 5) == 0) {
+   /* Dual link LVDS */
gamma_fix = 1;
-   out_8(pixis_base + PIXIS_BRDCFG0, tmp_val & 0xe7);
-
-   } el

Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC

2011-03-14 Thread York Sun
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> +  * Now divide by 5^12 and track the 32-bit remainder, then divide
> +  * by 2*(2^12) using shifts (and updating the remainder).
> +  */
> + clks_rem = do_div(clks, UL_5pow12);
> + clks_rem <<= 13;

Shouldn't this be clks_rem >>= 13 ?

> + clks_rem |= clks & (UL_2pow13-1);
> + clks >>= 13;
> +
> + /* If we had a remainder, then round up */
> + if (clks_rem)
>   clks++;
> - }


York



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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on32-bit PowerPC

2011-03-14 Thread Moffett, Kyle D
On Mar 14, 2011, at 14:19, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
>> integer divide operations to convert between nanoseconds and DDR clock
>> cycles given arbitrary DDR clock frequencies.
>> 
>> Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
>> and DDR frequencies), we can easily restructure the computation to use
>> the "do_div()" function to perform 64-bit/32-bit divide operations.
>> 
>> This decreases compute time rather significantly for each conversion and
>> avoids bringing in a very complicated function from libgcc.
>> 
>> It should be noted that nothing else in U-Boot or the Linux kernel seems
>> to require a full 64-bit divide on any 32-bit PowerPC.
>> 
>> Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
>> 
>> Signed-off-by: Kyle Moffett 
>> Cc: Andy Fleming 
>> Cc: Kumar Gala 
>> Cc: Wolfgang Denk 
>> Cc: Kim Phillips 
>> ---
>> 
>> Ok, so this patch touches a rather sensitive part of the fsl_ddr logic.
>> 
>> I spent a fair amount of time trying to verify that the resulting math is
>> exactly the same as it was before, but the consequences of a mistake are
>> insideous timing problems.  Additional in-depth review would be much
>> appreciated.
>> 
> 
> What's the gain of the changes? A smaller footprint? Going forward from
> 32- to 64-bit, are we going to change it back?

On 64-bit this change is basically a no-op, because do_div() is implemented as 
a literal 64-bit divide operation and the instruction scheduling works out 
almost the same.

On 32-bit PowerPC a fully accurate 64/64 divide (__udivdi3 in libgcc) is 1.1kb 
of code and hundreds or thousands of dependent cycles to compute, all of which 
is linked in from libgcc.  Another 1.2kb of code comes in for __umoddi3.

The original reason I wrote this patch is that the native "libgcc" on my boards 
is hard-float and therefore generates warnings when linking to it from 
soft-float code.  The toolchain is the native Debian powerpc (or powerpcspe), 
and most other native PowerPC distributions are also hard-float-only.

When I combine this patch with the other patch I posted to create a minimal 
internal libgcc with a few 64-bit shift functions from the linux kernel, I can 
successfully build U-Boot on those native PowerPC systems.

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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divideson32-bit PowerPC

2011-03-14 Thread Moffett, Kyle D
On Mar 14, 2011, at 15:41, York Sun wrote:
> Kyle,
> 
> On Mon, 2011-03-14 at 14:04 -0500, Moffett, Kyle D wrote:
>> On 64-bit this change is basically a no-op, because do_div() is implemented 
>> as a literal 64-bit divide operation and the instruction scheduling works 
>> out almost the same.
>> 
>> On 32-bit PowerPC a fully accurate 64/64 divide (__udivdi3 in libgcc) is 
>> 1.1kb of code and hundreds or thousands of dependent cycles to compute, all 
>> of which is linked in from libgcc.  Another 1.2kb of code comes in for 
>> __umoddi3.
>> 
>> The original reason I wrote this patch is that the native "libgcc" on my 
>> boards is hard-float and therefore generates warnings when linking to it 
>> from soft-float code.  The toolchain is the native Debian powerpc (or 
>> powerpcspe), and most other native PowerPC distributions are also 
>> hard-float-only.
>> 
>> When I combine this patch with the other patch I posted to create a minimal 
>> internal libgcc with a few 64-bit shift functions from the linux kernel, I 
>> can successfully build U-Boot on those native PowerPC systems.
>> 
> 
> Points taken. Can you explain your algorithm? I see you want to do
> clks/5^12/2^13, but I don't see when the clks is divided by 5^12. Did I
> miss some lines?

The "do_div()" macro is a bit confusing that way, it simultaneously performs an 
in-place division of the first argument and returns the remainder.  
Unfortunately that's a clumsy interface that's been around in the Linux kernel 
for ages.

So this line here:
  clks_rem = do_div(clks, UL_5pow12);

It divides clks by UL_5pow12 and saves the remainder as clks_rem.

Then the 2^^13 divide and remainder is perform with shifts and masks.

Actually, it occurs to me that the one comment isn't quite right, the remainder 
is a 64-bit value (not a 32-bit one).

I feel relatively confident that this is the right technical direction to go, 
because almost all of the Linux kernel timekeeping and scheduling code uses 
64-bit values and careful application of do_div() or shift+mask for efficiency.

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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on32-bit PowerPC

2011-03-14 Thread York Sun
Kyle,

On Mon, 2011-03-14 at 14:04 -0500, Moffett, Kyle D wrote:
> On 64-bit this change is basically a no-op, because do_div() is implemented 
> as a literal 64-bit divide operation and the instruction scheduling works out 
> almost the same.
> 
> On 32-bit PowerPC a fully accurate 64/64 divide (__udivdi3 in libgcc) is 
> 1.1kb of code and hundreds or thousands of dependent cycles to compute, all 
> of which is linked in from libgcc.  Another 1.2kb of code comes in for 
> __umoddi3.
> 
> The original reason I wrote this patch is that the native "libgcc" on my 
> boards is hard-float and therefore generates warnings when linking to it from 
> soft-float code.  The toolchain is the native Debian powerpc (or powerpcspe), 
> and most other native PowerPC distributions are also hard-float-only.
> 
> When I combine this patch with the other patch I posted to create a minimal 
> internal libgcc with a few 64-bit shift functions from the linux kernel, I 
> can successfully build U-Boot on those native PowerPC systems.
> 

Points taken. Can you explain your algorithm? I see you want to do
clks/5^12/2^13, but I don't see when the clks is divided by 5^12. Did I
miss some lines?

York



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


Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Moffett, Kyle D
On Mar 14, 2011, at 14:59, Wolfgang Denk wrote:
> In message  you wrote:
>> My own board needs both processor modules to synchronize resets to allow
>> them to come back up at all, which means that a "reset" may block for an
>> arbitrary amount of time waiting for the other module to cleanly shut down
>> and restart (or waiting for somebody to type "reset" on the other U-Boot).
>> If someone just types "reset" on the console, I want to allow them to hit
>> Ctrl-C to interrupt the process.
> 
> This is not what the "reset" command is supposed to do.  The reset
> command is supposed to be the software equivalent of someone pressing
> the reset button on your board - to the extend possible to be
> implemented in software.

On our boards, when the "reset" button is pressed in hardware, both processor 
modules on the board and all the attached hardware reset at the same time.

If just *one* of the 2 CPUs triggers the reset then only *some* of the attached 
hardware will be properly reset due to a hardware errata, and as a result the 
board will sometimes hang or corrupt DMA transfers to the SSDs shortly after 
reset.

The only way to reset either chip safely is by resetting both at the same time, 
which requires them to communicate before the reset and wait (possibly a long 
time) for the other board to agree to reset.  Yes, it's a royal pain, but we're 
stuck with this hardware for the time being, and if the board can't communicate 
then it might as well hang() anyways.

This same logic is also implemented in my Linux board-support code, so when one 
CPU requests a reset the other treats it as a Ctrl-Alt-Del.


>>> What is the difference between these two - and why do we need
>>> different functions at all?
>>> 
>>> A reset is a reset is a reset, isn't it?
>> 
>> That might be true *IF* all boards could actually perform a real hardware 
>> reset.
>> 
>> Some can't, and instead they just jump to their reset vector (Nios-II) or to 
>> flash (some ppc 74xx/7xx systems).
> 
> So this is the "reset" on these boards, then.
> 
>> If the board just panic()ed or got an unhandled trap or exception, then you
>> don't want to do a soft-reset that assumes everything is OK.  A startup in
>> a bad environment like that could corrupt FLASH or worse.  Right now there
>> is no way to tell the difference, but the lower-level arch-specific code
>> really should care.
> 
> I don't understand your chain of arguments.
> 
> If there really is no better way to implement the reset on such
> boards, then what else can we do?
> 
> And if there are more things that could be done to provide a "better"
> reset, then why should we not always do these?

If the board is in a panic() state it may well have still-running DMA transfers 
(such as USB URBs), or be in the middle of writing to FLASH.

Performing a jump to early-boot code which is only ever tested when everything 
is OK and devices are properly initialized is a great way to cause data 
corruption.

I know for a fact that our boards would rather hang forever than try to reset 
without cooperation from the other CPU.

>>> My initial feeling is a plain NAK, for this and the rest of the patch
>>> series.  Why would we want all this?
>> 
>> While I was going through the hooks I noticed that several of them were
>> explicitly NOT safe if the board was in the middle of a panic() for whatever
> 
> Can you please peovide some specific examples?  I don't understand what
> you are talking about.

Ok, using the ppmc7xx board as an example:

/* Disable and invalidate cache */
icache_disable();
dcache_disable();

/* Jump to cold reset point (in RAM) */
_start();

/* Should never get here */
while(1)
;

This board uses the EEPRO100 driver, which appears to set up statically 
allocated TX and RX rings which the device performs DMA to/from.

If this board starts receiving packets and then panic()s, it will disable 
address translation and immediately re-relocate U-Boot into RAM, then zero the 
BSS.  If the network card tries to receive a packet after BSS is zeroed, it 
will read a packet buffer address of (probably) 0x0 from the RX ring and 
promptly overwrite part of U-Boot's memory at that address.

Depending on the initialization process and memory layout, other similar boards 
could start writing garbage values to FLASH control registers and potentially 
corrupt data.

Since the panic() path is so infrequently used and tested, it's better to be 
safe and hang() on the boards which do not have a reliable hardware-level reset 
than it is to cause undefined behavior or potentially corrupt data.

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


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Jimi Xenidis
On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
> 
> On Sat, 12 Mar 2011 16:56:09 -0600
> Kumar Gala  wrote:
> 
>> 
>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>> 
>>> I was surprised to find myself at the decrement interrupt when running my 
>>> new stuff.
>>> That is against ePAPR, right?
>>> Does u-boot at least make sure that the DEC is set to some large value 
>>> before it leaps at me?
>>> I don't mind forcing EE=0 but I'd like to make sure I make it that far into 
>>> the code :)
>>> -JX
>> 
>> Jimi,
>> 
>> Not sure how or why you are seeing this, but u-boot should disable 
>> interrupts in common/cmd_bootm.c
>> 
>> Look for disable_interrupts() -> this should set MSR[EE] = 0.
> 
> What about the rest of MSR -- ME/CE/DE?

I can attest that MSR=0 when my program takes over.
BTW: secondary CPUs have MSR[IS|DS] == 0b11

-JX

> 
> -Scott


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


Re: [U-Boot] Please pull u-boot-mpc85xx.git

2011-03-14 Thread Wolfgang Denk
Dear Kumar Gala,

In message  you 
wrote:
> A few fixes for v2011.03 release.
> 
> The following changes since commit c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8:
> 
>   ARM: Update mach-types (2011-02-21 08:30:55 +0100)
> 
> are available in the git repository at:
>   git://git.denx.de/u-boot-mpc85xx.git master
> 
> Ed Swarthout (1):
>   powerpc/85xx: Fix plat_mp_up() disabling of BPTR for CoreNet Platforms
> 
> John Schmoller (1):
>   mpc8[5/6]xx: Ensure POST word does not get reset
> 
> Kumar Gala (1):
>   fsl_law: Fix LAW printing function
> 
> Matthew McClintock (1):
>   powerpc/85xx: Fix pixis_reset altbank mask on MPC8536DS
> 
> Priyanka Jain (1):
>   fsl_esdhc: Correcting esdhc timeout counter calculation
> 
> York Sun (3):
>   powerpc/mpc8xxx: Fix DDR3 timing_cfg_1 and sdram_mode registers
>   corenet_ds: pick the middle value for all tested timing parameters
>   powerpc/corenet_ds: revise platform dependent parameters
> 
>  arch/powerpc/cpu/mpc85xx/interrupts.c|   16 
>  arch/powerpc/cpu/mpc85xx/mp.c|4 +-
>  arch/powerpc/cpu/mpc86xx/interrupts.c|   16 
>  arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |   20 +++---
>  board/freescale/corenet_ds/ddr.c |   58 +
>  drivers/misc/fsl_law.c   |2 +-
>  drivers/mmc/fsl_esdhc.c  |   16 -
>  include/configs/MPC8536DS.h  |2 +-
>  8 files changed, 83 insertions(+), 51 deletions(-)

Applied, thanks.

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 takes all sorts of in & out-door schooling to get adapted  to  my
kind of fooling"   - R. Frost
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Wolfgang Denk
Dear "Moffett, Kyle D",

In message  you wrote:
> 
> >> The new wrapper functions are:
> >>  system_restart() -  Normal system reboot (IE: user request)
> >>  emergency_restart()  -  Critical error response (IE: panic(), etc)
> > 
> > What is the difference between these two - and why do we need
> > different functions at all?
> > 
> > A reset is a reset is a reset, isn't it?
>
> That might be true *IF* all boards could actually perform a real hardware 
> reset.
>
> Some can't, and instead they just jump to their reset vector (Nios-II) or to 
> flash (some ppc 74xx/7xx systems).

So this is the "reset" on these boards, then.

> If the board just panic()ed or got an unhandled trap or exception, then you
> don't want to do a soft-reset that assumes everything is OK.  A startup in
> a bad environment like that could corrupt FLASH or worse.  Right now there
> is no way to tell the difference, but the lower-level arch-specific code
> really should care.

I don't understand your chain of arguments.

If there really is no better way to implement the reset on such
boards, then what else can we do?

And if there are more things that could be done to provide a "better"
reset, then why should we not always do these?

> So system_restart() is what you use when the system is in a good normal
> operating condition.  The emergency_restart() is what gets called from panic()
> or in other places where a crash has happened.

Why?  What's the difference?

> >> + * If this function fails to guarantee a clean reboot or receives a Ctrl-C
> >> + * keystroke it SHOULD return with an error (-1).
> > 
> > A "reset" is supposed to take place immediately, and unconditionally.
> > If you need delays and ^C handling and other bells and whistles,
> > please add these to your own code, but not here.
>
> There's no Ctrl-C handling anywhere in this code, it will all be in my own
> __board_restart() hook.  As above, this documentation is just describing the

There is no ^C handling supposed to be in any reset hook.

You are changing user interfaces to very low-level and intentinally
simple commands in a complicated way, and I don;t see any advantage of
either this complexity nor your changes.

> guarantees provided to underlying __board_restart() and __arch_restart()
> hooks; if they check for Ctrl-C while polling external hardware and return
> an error then that's fine.

No, it is not, because it is not supposed to be done.

You could as well implement a "reset" cpmmand that actually turns on a
fan and the LCD backlight - that would be similarly useful.

> > My initial feeling is a plain NAK, for this and the rest of the patch
> > series.  Why would we want all this?
>
> While I was going through the hooks I noticed that several of them were
> explicitly NOT safe if the board was in the middle of a panic() for whatever

Can you please peovide some specific xamples?  I don't understand what
you are talking about.

> reason, so I split off the __*_emergency_restart() hooks separately to allow
> architectures to handle them cleanly.
>
> My own board needs both processor modules to synchronize resets to allow
> them to come back up at all, which means that a "reset" may block for an
> arbitrary amount of time waiting for the other module to cleanly shut down
> and restart (or waiting for somebody to type "reset" on the other U-Boot).
> If someone just types "reset" on the console, I want to allow them to hit
> Ctrl-C to interrupt the process.

This is not what the "reset" command is supposed to do.  The reset
command is supposed to be the software equivalent of someone pressing
the reset button on your board - to the extend possible to be
implemented in software.

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
If God had a beard, he'd be a UNIX programmer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 1/3] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements

2011-03-14 Thread York Sun
On Mon, 2011-03-14 at 12:38 -0400, Kyle Moffett wrote:
> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header.  This dramatically improves the
> readability of the switch statments.
> 
> In addition, a few of the longer lines were cleaned up, and the DDR2
> type for an SO-RDIMM module was added to the DDR2 switch statement.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Kim Phillips 
> ---
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   23 +++-
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |   43 ++
>  common/ddr_spd.c|2 +-
>  include/ddr_spd.h   |   28 ++-
>  4 files changed, 53 insertions(+), 43 deletions(-)
> 

Acked-by: York Sun 




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


Re: [U-Boot] [PATCH v5 1/3] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements

2011-03-14 Thread York Sun
On Mon, 2011-03-14 at 12:38 -0400, Kyle Moffett wrote:
> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header.  This dramatically improves the
> readability of the switch statments.
> 
> In addition, a few of the longer lines were cleaned up, and the DDR2
> type for an SO-RDIMM module was added to the DDR2 switch statement.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Kim Phillips 
> ---
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   23 +++-
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |   43 ++
>  common/ddr_spd.c|2 +-
>  include/ddr_spd.h   |   28 ++-
>  4 files changed, 53 insertions(+), 43 deletions(-)
> 

Ack.

York



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


Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?

2011-03-14 Thread Scott Wood
On Sat, 12 Mar 2011 16:56:09 -0600
Kumar Gala  wrote:

> 
> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
> 
> > I was surprised to find myself at the decrement interrupt when running my 
> > new stuff.
> > That is against ePAPR, right?
> > Does u-boot at least make sure that the DEC is set to some large value 
> > before it leaps at me?
> > I don't mind forcing EE=0 but I'd like to make sure I make it that far into 
> > the code :)
> > -JX
> 
> Jimi,
> 
> Not sure how or why you are seeing this, but u-boot should disable interrupts 
> in common/cmd_bootm.c
> 
> Look for disable_interrupts() -> this should set MSR[EE] = 0.

What about the rest of MSR -- ME/CE/DE?

-Scott

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


Re: [U-Boot] [PATCH] 8xxx: ddr3: Adjust timings for tRRD, tWTR, and tRTP

2011-03-14 Thread York Sun
On Thu, 2011-03-10 at 16:54 -0600, Peter Tyser wrote:
> From: John Schmoller 
> 
> The JEDEC DDR3 specification states that the above parameters should
> be set to a minimum of 4 clocks.  The SPD defines the values in
> nanoseconds, and depending on the clock frequency the value in the
> SPD can be less than 4 clocks.
> 
> Previously, we were only using the values from the SPD, regardless if
> they were less than 4 clocks.  Now, set the timing values to the greater
> of 4 clocks or the SPD value.
> 
> Invalid tRRD, tWTR, and tRTP values were observed on a variety of
> Freescale CPUs, although no negative side effects were seen from their
> use.
> 
> Signed-off-by: John Schmoller 
> Signed-off-by: Peter Tyser 
> ---
>  arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |7 ---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c 
> b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
> index 29cea53..8669898 100644
> --- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
> +++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
> @@ -230,8 +230,9 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
>* eg: tRRD_min =
>* DDR3-800(1KB page)   80 MTB (10ns)
>* DDR3-1333(1KB page)  48 MTB (6ns)
> +  * tRRD is at least 4 mclk independent of operating freq.
>*/
> - pdimm->tRRD_ps = spd->tRRD_min * mtb_ps;
> + pdimm->tRRD_ps = max(spd->tRRD_min * mtb_ps, mclk_to_picos(4));
>  
>   /*
>* min row precharge delay time
> @@ -276,14 +277,14 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t 
> *spd,
>* eg: tWTR_min = 40 MTB (7.5ns) - all speed bins.
>* tWRT is at least 4 mclk independent of operating freq.
>*/
> - pdimm->tWTR_ps = spd->tWTR_min * mtb_ps;
> + pdimm->tWTR_ps = max(spd->tWTR_min * mtb_ps, mclk_to_picos(4));
>  
>   /*
>* min internal read to precharge command delay time
>* eg: tRTP_min = 40 MTB (7.5ns) - all speed bins.
>* tRTP is at least 4 mclk independent of operating freq.
>*/
> - pdimm->tRTP_ps = spd->tRTP_min * mtb_ps;
> + pdimm->tRTP_ps = max(spd->tRTP_min * mtb_ps, mclk_to_picos(4));
>  
>   /*
>* Average periodic refresh interval

It is not necessary. The JEDEC spec is enforced in ctrl_regs.c.
ddr3_dimm_params.c only parses the raw timing.

York



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


Re: [U-Boot] [PATCHv2] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC

2011-03-14 Thread York Sun
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
> 
> Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
> and DDR frequencies), we can easily restructure the computation to use
> the "do_div()" function to perform 64-bit/32-bit divide operations.
> 
> This decreases compute time rather significantly for each conversion and
> avoids bringing in a very complicated function from libgcc.
> 
> It should be noted that nothing else in U-Boot or the Linux kernel seems
> to require a full 64-bit divide on any 32-bit PowerPC.
> 
> Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Wolfgang Denk 
> Cc: Kim Phillips 
> ---
> 
> Ok, so this patch touches a rather sensitive part of the fsl_ddr logic.
> 
> I spent a fair amount of time trying to verify that the resulting math is
> exactly the same as it was before, but the consequences of a mistake are
> insideous timing problems.  Additional in-depth review would be much
> appreciated.
> 

What's the gain of the changes? A smaller footprint? Going forward from
32- to 64-bit, are we going to change it back?

York


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


[U-Boot] [PATCH v5 3/3] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices

2011-03-14 Thread Kyle Moffett
The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
with 3 independent TEMPEST zones.  Two independent P2020 computers may
be found inside each zone.  Complete hardware support is included.

High-level hardware overview:
  * DO-160 certified for passenger aircraft (noncritical)
  * TEMPEST ceritified for RED/BLACK separation
  * 3 zones per chassis, 2 computers per zone (total of 6)
  * Dual-core 1.066GHz P2020 per computer
  * One 2GB DDR2 SO-RDIMM module per computer (upgradable to 4GB)
  * Removable 80GB or 160GB Intel X18-M SSD per computer
  * Front-accessible dual-port E1000E per computer
  * Front-accessible serial console per computer
  * Front-accessible USB port per computer
  * Internal Gigabit crossover within each TEMPEST zone
  * Internal unidirectional fiber links across TEMPEST zones
  * Battery-backed DS1339 I2C RTC on each CPU.

Combined, each 13lb 1U chassis contains 12GB RAM, 12 cores @ 1.066GHz,
12 front-accessible Gigabit Ethernet ports and 960GB of solid-state
storage with a total power consumption of ~200W.

Additional notes:
  * SPD detection is only known to work with the DO-160-certified DIMMs

  * A U-Boot built with 36-bit address-space seems to work, but I don't
yet have a usable 36-bit kernel or DTB, so it's mostly untested.

  * CPU reset is a little quirky due to hardware misfeature, see the
extensive comments in the __board_restart() function in hww1u1a.c

Signed-off-by: Kyle Moffett 
Cc: Andy Fleming 
Cc: Kumar Gala 
---
 MAINTAINERS   |4 +
 board/exmeritus/hww1u1a/Makefile  |   54 
 board/exmeritus/hww1u1a/ddr.c |   51 
 board/exmeritus/hww1u1a/gpios.h   |   67 +
 board/exmeritus/hww1u1a/hww1u1a.c |  549 +
 board/exmeritus/hww1u1a/law.c |   34 +++
 board/exmeritus/hww1u1a/tlb.c |  106 +++
 boards.cfg|2 +
 include/configs/HWW1U1A.h |  474 
 9 files changed, 1341 insertions(+), 0 deletions(-)
 create mode 100644 board/exmeritus/hww1u1a/Makefile
 create mode 100644 board/exmeritus/hww1u1a/ddr.c
 create mode 100644 board/exmeritus/hww1u1a/gpios.h
 create mode 100644 board/exmeritus/hww1u1a/hww1u1a.c
 create mode 100644 board/exmeritus/hww1u1a/law.c
 create mode 100644 board/exmeritus/hww1u1a/tlb.c
 create mode 100644 include/configs/HWW1U1A.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4756f14..6644baf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -320,6 +320,10 @@ Reinhard Meyer 
TOP5200 MPC5200
TOP9000 ARM926EJS (AT91SAM9xxx SoC)
 
+Kyle Moffett 
+
+   HWW1U1A P2020
+
 Tolunay Orkun 
 
csb272  PPC405GP
diff --git a/board/exmeritus/hww1u1a/Makefile b/board/exmeritus/hww1u1a/Makefile
new file mode 100644
index 000..b927f59
--- /dev/null
+++ b/board/exmeritus/hww1u1a/Makefile
@@ -0,0 +1,54 @@
+#
+# Copyright 2007-2009 Freescale Semiconductor, Inc.
+# (C) Copyright 2001-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= $(BOARD).o
+COBJS-y+= law.o
+COBJS-y+= tlb.o
+COBJS-$(CONFIG_DDR_SPD) += ddr.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+clean:
+   rm -f $(OBJS) $(SOBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/exmeritus/hww1u1a/ddr.c b/board/exmeritus/hww1u1a/ddr.c
new file mode 100644
index 000..dbdcc86
--- /dev/null
+++ b/board/exmeritus/hww1u1a/ddr.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2009-2010 eXMeritus, A Boeing Company
+ * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms o

[U-Boot] [PATCH v5 1/3] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements

2011-03-14 Thread Kyle Moffett
The numeric constants in the switch statements are replaced by #defines
added to the common ddr_spd.h header.  This dramatically improves the
readability of the switch statments.

In addition, a few of the longer lines were cleaned up, and the DDR2
type for an SO-RDIMM module was added to the DDR2 switch statement.

Signed-off-by: Kyle Moffett 
Cc: Andy Fleming 
Cc: Kumar Gala 
Cc: Kim Phillips 
---
 arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   23 +++-
 arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |   43 ++
 common/ddr_spd.c|2 +-
 include/ddr_spd.h   |   28 ++-
 4 files changed, 53 insertions(+), 43 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c 
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
index dcb37ce..b565e33 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
@@ -250,24 +250,27 @@ ddr_compute_dimm_parameters(const ddr2_spd_eeprom_t *spd,
pdimm->primary_sdram_width = spd->primw;
pdimm->ec_sdram_width = spd->ecw;
 
-   /* FIXME: what about registered SO-DIMM? */
+   /* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
switch (spd->dimm_type) {
-   case 0x01:  /* RDIMM */
-   case 0x10:  /* Mini-RDIMM */
-   pdimm->registered_dimm = 1; /* register buffered */
+   case DDR2_SPD_DIMMTYPE_RDIMM:
+   case DDR2_SPD_DIMMTYPE_72B_SO_RDIMM:
+   case DDR2_SPD_DIMMTYPE_MINI_RDIMM:
+   /* Registered/buffered DIMMs */
+   pdimm->registered_dimm = 1;
break;
 
-   case 0x02:  /* UDIMM */
-   case 0x04:  /* SO-DIMM */
-   case 0x08:  /* Micro-DIMM */
-   case 0x20:  /* Mini-UDIMM */
-   pdimm->registered_dimm = 0; /* unbuffered */
+   case DDR2_SPD_DIMMTYPE_UDIMM:
+   case DDR2_SPD_DIMMTYPE_SO_DIMM:
+   case DDR2_SPD_DIMMTYPE_MICRO_DIMM:
+   case DDR2_SPD_DIMMTYPE_MINI_UDIMM:
+   /* Unbuffered DIMMs */
+   pdimm->registered_dimm = 0;
break;
 
+   case DDR2_SPD_DIMMTYPE_72B_SO_CDIMM:
default:
printf("unknown dimm_type 0x%02X\n", spd->dimm_type);
return 1;
-   break;
}
 
/* SDRAM device parameters */
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c 
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
index 29cea53..756b15f 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
@@ -128,24 +128,32 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm->data_width = pdimm->primary_sdram_width
  + pdimm->ec_sdram_width;
 
-   switch (spd->module_type & 0xf) {
-   case 0x01:  /* RDIMM */
-   case 0x05:  /* Mini-RDIMM */
-   pdimm->registered_dimm = 1; /* register buffered */
+   /* These are the types defined by the JEDEC DDR3 SPD spec */
+   pdimm->mirrored_dimm = 0;
+   pdimm->registered_dimm = 0;
+   switch (spd->module_type & DDR3_SPD_MODULETYPE_MASK) {
+   case DDR3_SPD_MODULETYPE_RDIMM:
+   case DDR3_SPD_MODULETYPE_MINI_RDIMM:
+   /* Registered/buffered DIMMs */
+   pdimm->registered_dimm = 1;
for (i = 0; i < 16; i += 2) {
-   pdimm->rcw[i] = spd->mod_section.registered.rcw[i/2] & 
0x0F;
-   pdimm->rcw[i+1] = (spd->mod_section.registered.rcw[i/2] 
>> 4) & 0x0F;
+   u8 rcw = spd->mod_section.registered.rcw[i/2];
+   pdimm->rcw[i]   = (rcw >> 0) & 0x0F;
+   pdimm->rcw[i+1] = (rcw >> 4) & 0x0F;
}
break;
-   case 0x02:  /* UDIMM */
-   case 0x03:  /* SO-DIMM */
-   case 0x04:  /* Micro-DIMM */
-   case 0x06:  /* Mini-UDIMM */
-   pdimm->registered_dimm = 0; /* unbuffered */
+
+   case DDR3_SPD_MODULETYPE_UDIMM:
+   case DDR3_SPD_MODULETYPE_SO_DIMM:
+   case DDR3_SPD_MODULETYPE_MICRO_DIMM:
+   case DDR3_SPD_MODULETYPE_MINI_UDIMM:
+   /* Unbuffered DIMMs */
+   if (spd->mod_section.unbuffered.addr_mapping & 0x1)
+   pdimm->mirrored_dimm = 1;
break;
 
default:
-   printf("unknown dimm_type 0x%02X\n", spd->module_type);
+   printf("unknown module_type 0x%02X\n", spd->module_type);
return 1;
}
 
@@ -303,16 +311,5 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm->tFAW_ps = (((spd->tFAW_msb & 0xf) << 8) | spd->tFAW_min)
* mtb_ps;
 
-   /*
-* We need check the address mirror for unbuffered DIMM
-* If SPD indicate the address map mirror, The DDR co

[U-Boot] [PATCH v5 2/3] mpc85xx: Add inline GPIO acessor functions

2011-03-14 Thread Kyle Moffett
To ease the implementation of other MPC85xx board ports, several common
GPIO helpers are added to .

Since each of these compiles to no more than 4-5 instructions it would
be very inefficient to call them out of line, therefore we put them
entirely in the header file.

The HWW-1U-1A board port which these were written for strongly prefers
to set multiple GPIOs as a single batch operation, so the API is
designed around that basis.

To assist other board ports, a small set of wrappers are used which
provides a standard Linux-compatible gpio_request() interface around the
MPC85xx-specific functions.  This can be enabled with the config option
CONFIG_MPC85XX_GENERIC_GPIO.

Signed-off-by: Kyle Moffett 
Cc: Andy Fleming 
Cc: Kumar Gala 
Cc: Peter Tyser 
---
 arch/powerpc/include/asm/mpc85xx_gpio.h |  120 +++
 1 files changed, 120 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/include/asm/mpc85xx_gpio.h

diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h 
b/arch/powerpc/include/asm/mpc85xx_gpio.h
new file mode 100644
index 000..ad54b4e
--- /dev/null
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -0,0 +1,120 @@
+/*
+ * Copyright 2010 eXMeritus, A Boeing Company
+ *
+ * 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 
+
+/*
+ * The following internal functions are an MPC85XX-specific GPIO API which
+ * allows setting and querying multiple GPIOs in a single operation.
+ *
+ * All of these look relatively large, but the arguments are almost always
+ * constants, so they compile down to just a few instructions and a
+ * memory-mapped IO operation or two.
+ */
+static inline void mpc85xx_gpio_set(unsigned int mask,
+   unsigned int dir, unsigned int val)
+{
+   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+
+   /* First mask off the unwanted parts of "dir" and "val" */
+   dir &= mask;
+   val &= mask;
+
+   /* Now read in the values we're supposed to preserve */
+   dir |= (in_be32(&gpio->gpdir) & ~mask);
+   val |= (in_be32(&gpio->gpdat) & ~mask);
+
+   /*
+* Poke the new output values first, then set the direction.  This
+* helps to avoid transient data when switching from input to output
+* and vice versa.
+*/
+   out_be32(&gpio->gpdat, val);
+   out_be32(&gpio->gpdir, dir);
+}
+
+static inline void mpc85xx_gpio_set_in(unsigned int gpios)
+{
+   mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_low(unsigned int gpios)
+{
+   mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_high(unsigned int gpios)
+{
+   mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
+{
+   ccsr_gpio_t *gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+
+   /* Read the requested values */
+   return in_be32(&gpio->gpdat) & mask;
+}
+
+/*
+ * These implement the generic Linux GPIO API on top of the other functions
+ * in this header.
+ */
+#ifdef CONFIG_MPC85XX_GENERIC_GPIO
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+   /* Compatibility shim */
+   return 0;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+   /* Compatibility shim */
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+   mpc85xx_gpio_set_in(1U << gpio);
+   return 0;
+}
+
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+   mpc85xx_gpio_set_low(1U << gpio);
+   return 0;
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+   return !!mpc85xx_gpio_get(1U << gpio)
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+   if (value)
+   mpc85xx_gpio_set_high(1U << gpio);
+   else
+   mpc85xx_gpio_set_low(1U << gpio);
+}
+
+static inline int gpio_is_valid(int gpio)
+{
+   return (gpio >= 0) && (gpio < 32);
+}
+#endif /* CONFIG_MPC85XX_GENERIC_GPIO */
-- 
1.7.2.3

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


[U-Boot] [PATCH v5 0/3] Board support series for the eXMeritus HWW-1U-1A

2011-03-14 Thread Kyle Moffett
This is the latest respin of the eXMeritus HWW-1U-1A board support patches.
It's down to just a 3-patch series, with all of the other patches submitted
separately.

This series techncially depends on the reset rework, the "reset" command
will not work properly on the HWW-1U-1A hardware without those patches.
It will not cause a build failure however, as this board port simply defines
an otherwise-unused __board_restart() function.

I believe these 3 patches at least are ready to be merged, as all concerns
presented so far have been resolved.

Cheers,
Kyle Moffett

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


Re: [U-Boot] [PATCH 01/21] Define new system_restart() and emergency_restart()

2011-03-14 Thread Moffett, Kyle D
Hi!

On Mar 13, 2011, at 15:24, Wolfgang Denk wrote:
> In message <1299519462-25320-2-git-send-email-kyle.d.moff...@boeing.com> you 
> wrote:
>> In preparation for making system restart use a generic set of hooks for
>> boards and architectures, we define some wrappers and weak stubs.
>> 
>> The new wrapper functions are:
>>  system_restart() -  Normal system reboot (IE: user request)
>>  emergency_restart()  -  Critical error response (IE: panic(), etc)
> 
> What is the difference between these two - and why do we need
> different functions at all?
> 
> A reset is a reset is a reset, isn't it?

That might be true *IF* all boards could actually perform a real hardware reset.

Some can't, and instead they just jump to their reset vector (Nios-II) or to 
flash (some ppc 74xx/7xx systems).

If the board just panic()ed or got an unhandled trap or exception, then you 
don't want to do a soft-reset that assumes everything is OK.  A startup in a 
bad environment like that could corrupt FLASH or worse.  Right now there is no 
way to tell the difference, but the lower-level arch-specific code really 
should care.

So system_restart() is what you use when the system is in a good normal 
operating condition.  The emergency_restart() is what gets called from panic() 
or in other places where a crash has happened.


> ...
>> +/*
>> + * This MUST be called from normal interrupts-on context.  If it requires
>> + * extended interaction with external hardware it SHOULD react to Ctrl-C.
> 
> ??? Why such complicated restrictions for a simple command that is
> just supposed to reset the board?

This is just documenting what the underlying hardware-specific code is 
guaranteed.  On some hardware a "system_restart()" may fail and return -1, on 
others the board needs to cleanly respond to interrupts while polling external 
hardware, etc.  This is analogous to the normal "sys_reboot()" code under 
Linux, which requires interrupts-on, etc.

This is to contrast with the emergency_restart() function which has no such API 
constraints.  It can be called from any context whatsoever and will do its best 
to either perform a full hardware reset or hang while trying.


>> + * If this function fails to guarantee a clean reboot or receives a Ctrl-C
>> + * keystroke it SHOULD return with an error (-1).
> 
> A "reset" is supposed to take place immediately, and unconditionally.
> If you need delays and ^C handling and other bells and whistles,
> please add these to your own code, but not here.

There's no Ctrl-C handling anywhere in this code, it will all be in my own 
__board_restart() hook.  As above, this documentation is just describing the 
guarantees provided to underlying __board_restart() and __arch_restart() hooks; 
if they check for Ctrl-C while polling external hardware and return an error 
then that's fine.

>> +int system_restart(void)
>> +{
>> +int err;
>> +
>> +/*
>> + * Print a nice message and wait a bit to make sure it goes out the
>> + * console properly.
>> + */
>> +printf ("Restarting...\n");
>> +udelay(5);
>> +
>> +/* First let the board code try to reboot */
>> +err = __board_restart();
>> +if (err)
>> +goto failed;
>> +
>> +/* Now call into the architecture-specific code */
>> +err = __arch_restart();
>> +if (err)
>> +goto failed;
>> +
>> +/* Fallback to the old do_reset() until everything is converted. */
>> +err = do_reset(NULL, 0, 0, NULL);
>> +
>> +failed:
>> +printf("*** SYSTEM RESTART FAILED ***\n");
>> +return err;
>> +}
> 
> You are making a simple thing pretty much complicated.  This adds lots
> of code and I cannot see any benefits.

No, it's actually a net removal of code, the diffstat is:
  90 files changed, 341 insertions(+), 374 deletions(-)

The basic hook structure from system_restart() already existed individually in 
6 different architectures (incl. PowerPC, Blackfin, ARM, MIPS...), each of 
which had its own "board_reset()" or "_machine_restart()" or similar.  This 
code makes it entirely generic, so as a new board implementor you can simply 
define a "__board_restart()" function to override (or enhance) the normal 
architecture-specific code.


> My initial feeling is a plain NAK, for this and the rest of the patch
> series.  Why would we want all this?

While I was going through the hooks I noticed that several of them were 
explicitly NOT safe if the board was in the middle of a panic() for whatever 
reason, so I split off the __*_emergency_restart() hooks separately to allow 
architectures to handle them cleanly.

My own board needs both processor modules to synchronize resets to allow them 
to come back up at all, which means that a "reset" may block for an arbitrary 
amount of time waiting for the other module to cleanly shut down and restart 
(or waiting for somebody to type "reset" on the other U-Boot).  If someone just 
types "reset" on the console, I want to allow them to hit Ctrl-C to inte

Re: [U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7

2011-03-14 Thread Loïc Minier
On Mon, Mar 14, 2011, Aneesh V wrote:
> +- ARM Options:
> + CONFIG_SYS_THUMB_BUILD
> +
> + Use this flag to build U-Boot using the Thumb instruction
> + set for ARM architectures. Thumb instruction set provides
> + better code density. For ARM architectures that support
> + Thumb2 this flag will result in Thumb2 code generated by
> + GCC.
> +
>  - Linux Kernel Interface:
>   CONFIG_CLOCKS_IN_MHZ
>  

 The above README changes suggest that "Thumb-1" would also be possible
 but you patch an armv7 file:

> --- a/arch/arm/cpu/armv7/config.mk
> +++ b/arch/arm/cpu/armv7/config.mk

 so I suspect only armv7 CPUs would be affected?  Consider patching
 arch/arm/config.mk instead which is where -marm is currently set:
# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
PLATFORM_CPPFLAGS += $(call cc-option,-marm,)
 In fact, I would find it less confusing if the flags were -mthumb or
 -marm and never -marm -mthumb, so you probably want to patch the code
 setting -marm above to be in your "else" clause.

> @@ -31,3 +31,8 @@ PLATFORM_CPPFLAGS += -march=armv5

 This suggests that u-boot is actually built in ARMv5 mode, which means
 we're missing out actual Thumb-2 instructions (v6+).

 Perhaps arch/arm/cpu/armv7/config.mk should also $(call
 cc-option,-march=armv7).  (I've never used -march=armv7 but it seems to
 exist and is probably more correct than -march=armv7-a).

>  # =
>  PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,\
>   $(call cc-option,-malignment-traps,))
> +
> +ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
> +# Enable Thumb mode build if compiler supports it
> +PLATFORM_CPPFLAGS += $(call cc-option,-mthumb -mthumb-interwork)
> +endif
> -- 
> 1.7.0.4
> 

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


Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init

2011-03-14 Thread Tom Warren
Albert,

On Sun, Mar 13, 2011 at 10:46 AM, Albert ARIBAUD  wrote:
> Le 16/02/2011 21:26, Tom Warren a écrit :
>>
>> Signed-off-by: Tom Warren
>> ---
>>  arch/arm/cpu/armv7/start.S                 |    6 +
>>  arch/arm/cpu/armv7/tegra2/Makefile         |    2 +-
>
>>  arch/arm/cpu/armv7/tegra2/ap20.c           |  490
>> 
>
> This one has an extra empty line at end of file.
>
Thanks - I'll remove it.

>> +void cold_boot(void)
>> +{
>> +       asm volatile(
>> +
>> +       "msr     cpsr_c, #0xd3            \n"
>> +       /*
>> +       * Check current processor: CPU or AVP?
>> +       * If AVP, go to AVP boot code, else continue on.
>> +       */
>> +       "mov     r0, %0                   \n"
>> +       "ldrb    r2, [r0, %1]             \n"
>> +       /* are we the CPU? */
>> +       "cmp     r2, %2                   \n"
>> +       "mov     sp, %3                   \n"
>> +       /* leave in some symbols for release debugging */
>> +       "mov     r3, %6                   \n"
>> +       "str     r3, [sp, #-4]!           \n"
>> +       "str     r3, [sp, #-4]!           \n"
>> +       /*  yep, we are the CPU */
>> +       "bxeq     %4                      \n"
>> +       /* AVP Initialization follows this path */
>> +       "mov     sp, %5                   \n"
>> +       /* leave in some symbols for release debugging */
>> +       "mov     r3, %6                   \n"
>> +       "str     r3, [sp, #-4]!           \n"
>> +       "str     r3, [sp, #-4]!           \n"
>> +
>> +       /* Init and Start CPU */
>> +       "b       startup_cpu              \n"
>> +       :
>> +       : "i"(NV_PA_PG_UP_BASE),
>
> If I'm not mistaken, NV_PA_PG_UP_BASE could be used just as well directly in
> the asm statement instead of via %0 and i(), as anyway the asm will be
> preprocessed and the macro will turn to a number. That would simplify the
> asm instruction as a whole and make the asm statement more understandable
> (also applies to other macros used similarly).
>
Yeah, this code came this way from our bringup group for out in-house
bootloader, and it's always been confusing.
I'll try to simplify it when I incorporate Peter's critiques. Thanks.
> Apart from that, I must admit I don't know the Tegra2/A9 well enough to
> comment further.
>
> amicalement,
> Amicalement,
> --
> Albert.
Thanks for the input,
Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init

2011-03-14 Thread Peter Tyser
Hi Tom,
I'm not too familiar with the architecture, so many comments are
aesthetic.  It would be a good idea to run the patch through
checkpatch.pl too.

> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 684f2d2..50a1725 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -70,6 +70,12 @@ _end_vect:
>  _TEXT_BASE:
>   .word   CONFIG_SYS_TEXT_BASE
>  
> +#ifdef CONFIG_TEGRA2
> +.globl _armboot_start
> +_armboot_start:
> +.word _start
> +#endif
> +

It'd be good to add a comment about what's going on above, and why its
tegra2-specific.  Eg why is it needed?



> +static void init_pll_x(void)
> +{
> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
> + u32 reg;

The spaces in front of "reg" can be removed.  Ditto for all
functions/variables.

> + /* Is PLL-X already running? */
> + reg = readl(&clkrst->crc_pllx_base);
> + if (reg & PLL_ENABLE)
> + return;
> +
> + /* Do PLLX init if it isn't running, but BootROM sets it, so TBD */
> +}

The above function looks incorrect.

> +static void set_cpu_reset_vector(u32 vector)
> +{
> + writel(vector, EXCEP_VECTOR_CPU_RESET_VECTOR);
> +}

Is it worth breaking this out into its own function?  The define names
make it pretty clear what is being done, and its only called from 1
location.

> +static void enable_cpu_clock(int enable)
> +{
> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
> + u32   reg, clk;
> +
> + /*
> +  * NOTE:
> +  * Regardless of whether the request is to enable or disable the CPU
> +  * clock, every processor in the CPU complex except the master (CPU 0)
> +  * will have it's clock stopped because the AVP only talks to the
> +  * master. The AVP does not know (nor does it need to know) that there
> +  * are multiple processors in the CPU complex.
> +  */
> +
> + /* Need to initialize PLLX? */
> + if (enable) {
> + /* Initialize PLL */
> + init_pll_x();
> +
> + /* Wait until stable */
> + udelay(NVBOOT_CLOCKS_PLL_STABILIZATION_DELAY);
> +
> + reg = CCLK_BURST_POLICY;
> + writel(reg, &clkrst->crc_cclk_brst_pol);

It'd look cleaner to not set "reg" for each access, just use the define
directly.  I'd personally use less temporary variables in general and
only use them when it made the code cleaner and easier to understand.

> + reg = SUPER_CCLK_DIVIDER;
> + writel(reg, &clkrst->crc_super_cclk_div);
> + }
> +
> + /* Fetch the register containing the main CPU complex clock enable */
> + reg = readl(&clkrst->crc_clk_out_enb_l);

Is this read necessary?  You overwrite reg unconditionally below.

> + /*
> +  * Read the register containing the individual CPU clock enables and
> +  * always stop the clock to CPU 1.
> +  */
> + clk = readl(&clkrst->crc_clk_cpu_cmplx);
> + clk |= CPU1_CLK_STP;
> +
> + if (enable) {
> + /* Enable the CPU clock */
> + reg = readl(&clkrst->crc_clk_out_enb_l);
> + reg |= CLK_ENB_CPU;
> + clk = readl(&clkrst->crc_clk_cpu_cmplx);
> + clk &= ~CPU0_CLK_STP;
> + } else {
> + /* Disable the CPU clock */
> + reg = readl(&clkrst->crc_clk_out_enb_l);
> + reg |= CLK_ENB_CPU;
> + clk = readl(&clkrst->crc_clk_cpu_cmplx);
> + clk |= CPU0_CLK_STP;
> + }

For if/elses that share common code, the common code should be broken
out.  eg above only the one-line |=/&= operations should be conditional.

> + writel(clk, &clkrst->crc_clk_cpu_cmplx);
> + writel(reg, &clkrst->crc_clk_out_enb_l);
> +}
> +
> +static int is_cpu_powered(void)
> +{
> + struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
> + u32   reg;
> +
> + reg = readl(&pmc->pmc_pwrgate_status);
> +
> + if (reg & CPU_PWRED)
> + return TRUE;

I'd remove the reg variable.  eg something like:
return readl(&pmc->pmc_pwrgate_status & CPU_PWRED ? 1 : 0);

> + return FALSE;
> +}
> +
> +static void remove_cpu_io_clamps(void)
> +{
> + struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
> + u32   reg;
> +
> + /* Remove the clamps on the CPU I/O signals */
> + reg = readl(&pmc->pmc_remove_clamping);
> + reg |= CPU_CLMP;
> + writel(reg, &pmc->pmc_remove_clamping);
> +
> + /* Give I/O signals time to stabilize */
> + udelay(1000);

For magic delays it'd be good to reference why you're waiting a specific
amount of time.  Does a manual state 1 ms?  Did testing show 1ms was
required?

> +}
> +
> +static void powerup_cpu(void)
> +{
> + struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
> + u32   reg;
> +
> + if (!is_cpu_powered()) {
> + /* Toggle the CPU power state (OFF -> ON) */
> + reg = readl(&pmc->pmc_pwrgate_toggl

[U-Boot] [PATCH] UBI: Fix error code handling in ubi commands

2011-03-14 Thread Stefan Roese
Some ubi commands returned negative error codes, resulting in
the following error message on the prompt:

"exit not allowed from main input shell."

Negative error codes are not allowed.

This patch now changes the UBI code to return positive error codes.
Additionally "better" error codes are used, for example "ENOMEM" when
no memory is available for the UBI volume creation any more.

Note that the new positive error codes are currently not returned
via the U-Boot HUSH version to the user. All positive codes are returned
as 1. This might change in the future though, so it makes sense to
already support multiple positive return codes.

Signed-off-by: Stefan Roese 
Cc: Wolfgang Denk 
---
 common/cmd_ubi.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index b486ca8..620102c 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -123,7 +123,7 @@ static int ubi_info(int layout)
 static int verify_mkvol_req(const struct ubi_device *ubi,
const struct ubi_mkvol_req *req)
 {
-   int n, err = -EINVAL;
+   int n, err = EINVAL;
 
if (req->bytes < 0 || req->alignment < 0 || req->vol_type < 0 ||
req->name_len < 0)
@@ -136,8 +136,11 @@ static int verify_mkvol_req(const struct ubi_device *ubi,
if (req->alignment == 0)
goto bad;
 
-   if (req->bytes == 0)
+   if (req->bytes == 0) {
+   printf("No space left in UBI device!\n");
+   err = ENOMEM;
goto bad;
+   }
 
if (req->vol_type != UBI_DYNAMIC_VOLUME &&
req->vol_type != UBI_STATIC_VOLUME)
@@ -151,13 +154,13 @@ static int verify_mkvol_req(const struct ubi_device *ubi,
goto bad;
 
if (req->name_len > UBI_VOL_NAME_MAX) {
-   err = -ENAMETOOLONG;
+   printf("Name too long!\n");
+   err = ENAMETOOLONG;
goto bad;
}
 
return 0;
 bad:
-   printf("bad volume creation request");
return err;
 }
 
-- 
1.7.4.1

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


Re: [U-Boot] [PATCH V4 4/4] various cleanups/code style fixes

2011-03-14 Thread Peter Tyser
Hi David,
It'd be good to include "smdk2410" in this patch titles, eg "smdk2410:
Various cleanups/code style fixes". or "arm: smdk2410: Various..."

Without the prefix, its unclear what code these patches affect, and
somewhat implies you are changing common code.



> -#define  CONFIG_RTC_S3C24X0  1
> +#define  CONFIG_RTC_S3C24X0

Looks like there are a number of tabs in odd locations, it'd be nice to
clean those up while you're modifying this file.

Best,
Peter

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


Re: [U-Boot] fw_printenv cross compilation issue

2011-03-14 Thread Elie De Brauwer
On 03/14/11 14:37, Stefano Babic wrote:
> On 03/14/2011 02:15 PM, Elie De Brauwer wrote:
>> Hi List,
>>
>> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept
>> ending with a natively compiled version of fw_printenv. When looking at
>> the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly
>> ever since:
>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=abd315a1357ab05e82f0d61ebad666bc0d5378c3
>>
>> Is there a rationale for this ?
>
> Yes, there is an issue requiring to compile the env tools with native
> compiler.
>
>> Just reverting this change to
>> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/Makefile;hb=78acc472d9719316f22e002a009a998d9ceec29d
>>
>> Makes building a crosscompiled fw_printenv possible again.
>
> You do not need, try this:
>
>   make HOSTCC=  env
>
> for example, make HOSTCC=arm-linux-gcc env
>

Allright,

Thanks for the info, guessed reading some older docs on the internet 
confused me.

gr
E
-- 
Elie De Brauwer

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


Re: [U-Boot] fw_printenv cross compilation issue

2011-03-14 Thread Wolfgang Denk
Dear Elie De Brauwer,

In message <4d7e14ed.1050...@gmail.com> you wrote:
> 
> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept 
> ending with a natively compiled version of fw_printenv. When looking at 
> the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly 
> ever since: 
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=abd315a1357ab05e82f0d61ebad666bc0d5378c3
> 
> Is there a rationale for this ? Just reverting this change to
> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/Makefile;hb=78acc472d9719316f22e002a009a998d9ceec29d
> 
> Makes building a crosscompiled fw_printenv possible again.

There is a rationale for that, and Mike Frisinger explained it when
this patch was being discussed, and later again.  Please see the
archives.

I have to admit that I share your confusion, but even rational is
relative ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] fw_printenv cross compilation issue

2011-03-14 Thread Stefano Babic
On 03/14/2011 02:15 PM, Elie De Brauwer wrote:
> Hi List,
> 
> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept 
> ending with a natively compiled version of fw_printenv. When looking at 
> the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly 
> ever since: 
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=abd315a1357ab05e82f0d61ebad666bc0d5378c3
> 
> Is there a rationale for this ?

Yes, there is an issue requiring to compile the env tools with native
compiler.

> Just reverting this change to
> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/Makefile;hb=78acc472d9719316f22e002a009a998d9ceec29d
> 
> Makes building a crosscompiled fw_printenv possible again.

You do not need, try this:

make HOSTCC= env

for example, make HOSTCC=arm-linux-gcc env

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


[U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7

2011-03-14 Thread Aneesh V
Signed-off-by: Aneesh V 
---
 README   |9 +
 arch/arm/cpu/armv7/config.mk |5 +
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/README b/README
index f1547a4..ff3a345 100644
--- a/README
+++ b/README
@@ -370,6 +370,15 @@ The following options need to be configured:
2. The core frequency as calculated above is multiplied
by this value.
 
+- ARM Options:
+   CONFIG_SYS_THUMB_BUILD
+
+   Use this flag to build U-Boot using the Thumb instruction
+   set for ARM architectures. Thumb instruction set provides
+   better code density. For ARM architectures that support
+   Thumb2 this flag will result in Thumb2 code generated by
+   GCC.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 49ac9c7..b7bebad 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -31,3 +31,8 @@ PLATFORM_CPPFLAGS += -march=armv5
 # =
 PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,\
$(call cc-option,-malignment-traps,))
+
+ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
+# Enable Thumb mode build if compiler supports it
+PLATFORM_CPPFLAGS += $(call cc-option,-mthumb -mthumb-interwork)
+endif
-- 
1.7.0.4

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


[U-Boot] [RFC PATCH 2/2] OMAP4: enable Thumb2 support for OMAP4

2011-03-14 Thread Aneesh V
Enable -march=armv7-a and Thumb build for OMAP4. This results in
Thumb2 code generated for OMAP4.

The newly added compiler switches are put under cc-option so
that it doesn't break old compilers.

Signed-off-by: Aneesh V 
---
 arch/arm/cpu/armv7/omap4/config.mk |   25 +
 include/configs/omap4_sdp4430.h|1 +
 2 files changed, 26 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/config.mk

diff --git a/arch/arm/cpu/armv7/omap4/config.mk 
b/arch/arm/cpu/armv7/omap4/config.mk
new file mode 100644
index 000..a715ba3
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap4/config.mk
@@ -0,0 +1,25 @@
+#
+# Copyright 2011 Linaro Limited
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# Aneesh V 
+#
+# 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
+#
+
+# Enable armv7 if the compiler supports it
+PLATFORM_CPPFLAGS += $(call cc-option,-march=armv7-a)
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index 48a3774..74f686b 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -266,4 +266,5 @@
 #define CONFIG_SYS_SPL_BSS_START_ADDR  0x8000
 #define CONFIG_SYS_SPL_BSS_MAX_SIZE0x8 /* 512 KB */
 
+#define CONFIG_SYS_THUMB_BUILD
 #endif /* __CONFIG_H */
-- 
1.7.0.4

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


[U-Boot] fw_printenv cross compilation issue

2011-03-14 Thread Elie De Brauwer
Hi List,

I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept 
ending with a natively compiled version of fw_printenv. When looking at 
the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly 
ever since: 
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=abd315a1357ab05e82f0d61ebad666bc0d5378c3

Is there a rationale for this ? Just reverting this change to
http://git.denx.de/?p=u-boot.git;a=blob;f=tools/env/Makefile;hb=78acc472d9719316f22e002a009a998d9ceec29d

Makes building a crosscompiled fw_printenv possible again.

gr
E.

-- 
Elie De Brauwer

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


Re: [U-Boot] [RFC PATCH 1/6] Mips: Move content of arch/mips/cpu to arch/mips/cpu/mips32

2011-03-14 Thread Wolfgang Denk
Dear Daniel Schwierzeck,

In message  you 
wrote:
> 
> > OTOH, the purple board has not been actively maintained for several
> > years, and I'm not aware of anybody who still has access to the
> > hardware. =C2=A0If it should cause trouble, it would probably most
> > appropriate to drop the purple support.
>
> shall I include an additional patch that drops Purple support and do you agree

Yes, please, if it reduces the effort for you now.

> to the refactoring of the CPU directory itself?

Sorry, I didn't have much time to read it / think about it yet.

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
Drawing on my fine command of language, I said nothing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 02/20] mpc832x: add support for the mpc8321 based suvd3 board

2011-03-14 Thread Wolfgang Denk
Dear Heiko,

In message <4d7dc1c1.4060...@denx.de> you wrote:
> 
> >> +  im->sysconf.ddrlaw[0].bar = CONFIG_SYS_DDR_BASE & LAWBAR_BAR;
> >> +  msize = fixed_sdram ();
> > 
> > Can we not use get_ram_size() ?
> 
> fixed_sdram calls this.

I see, thanks.

> > I see this:
> > 
> > [PATCH 01/20] keymile: rework headerfiles for keymile boards
> > total: 0 errors, 16 warnings, 659 lines checked
> 
> Hmm... I see other statistics:

I'm using

-> checkpatch.pl --version
Usage: checkpatch.pl [OPTION]... [FILE]...
Version: 0.31

> [hs@pollux u-boot]$ ./../linux-2.6-denx/scripts/checkpatch.pl 
> 20110308/0001-keymile-rework-headerfiles-for-keymile-boards.patch

This should be the same version, assuming your repository is up to
date.

> WARNING: line over 80 characters
> #636: FILE: include/configs/kmeter1.h:179:
> +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) /* Reserve 768 kB for 
> Mon */
> 
> WARNING: line over 80 characters
> #750: FILE: include/configs/mgcoge.h:133:
> +#define CONFIG_SYS_MONITOR_LEN (768 << 10) /* Reserve 768KB for 
> Monitor */
> 
> total: 0 errors, 2 warnings, 659 lines checked
> 
> 20110313/0001-keymile-rework-headerfiles-for-keymile-boards.patch has style 
> problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> [hs@pollux u-boot]$
> 
> Only 2 warnings ... which checkpatch.pl do you use?

You must be doing something wrong.

On pollux, as you:

-> /home/git/linux-2.6-denx/scripts/checkpatch.pl --no-tree /tmp/patch
WARNING: please, no space before tabs
#221: FILE: include/configs/keymile-common.h:117:
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS ^I3$

...
WARNING: please, no space before tabs
#791: FILE: include/configs/mgcoge.h:107:
+^I^I"era 0xFE0C +0x4\0" ^I^I^I^I\$

WARNING: line over 80 characters
#801: FILE: include/configs/mgcoge.h:133:
+#define CONFIG_SYS_MONITOR_LEN (768 << 10) /* Reserve 768KB for 
Monitor */

total: 0 errors, 16 warnings, 659 lines checked



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
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 1/6] Mips: Move content of arch/mips/cpu to arch/mips/cpu/mips32

2011-03-14 Thread Daniel Schwierzeck
Hello Wolfgang,

2011/3/13 Wolfgang Denk :
> Dear Daniel Schwierzeck,
>
> In message <4d7c147a.5060...@gmail.com> you wrote:
>>
>> >> All current CPUs and SoCs are based on Mips32 arch. The complete
>> >
>> > Is that true? What about purple SoC? IIUC It's based on MIPS 5Kc
>> > and capable of 64-bit, which MIPS32 is 32-bit only architecture.
>>
>> that was an assumption. I could not find any information about Purple.
>> This patch series is a suggestion. Maybe there are better approaches
>> like arch/mips/cpu/{mips4k|mips5k|mips24k|...|octeon}.
>
> Purple is (better: was) indeed a 64 bit system.
>
> OTOH, the purple board has not been actively maintained for several
> years, and I'm not aware of anybody who still has access to the
> hardware.  If it should cause trouble, it would probably most
> appropriate to drop the purple support.
>

shall I include an additional patch that drops Purple support and do you agree
to the refactoring of the CPU directory itself?

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


Re: [U-Boot] [PATCH 1/8] pxa: move i2c driver to the common place

2011-03-14 Thread Prafulla Wadaskar


> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Monday, March 14, 2011 3:46 PM
> To: u-boot@lists.denx.de; Marek Vasut; Prafulla Wadaskar; Lei Wen
> Subject: [PATCH 1/8] pxa: move i2c driver to the common place
> 
> For better sharing with other platform other than pxa's,
> it is more convenient to put the driver to the common place.
> 
> Signed-off-by: Lei Wen 
> ---
>  arch/arm/cpu/pxa/Makefile |1 -
>  arch/arm/cpu/pxa/i2c.c|  469 --
> ---
>  drivers/i2c/Makefile  |1 +
>  drivers/i2c/pxa_i2c.c |  469
> +

Hi Lei
It looks like this is cut-paste, have you done git-mv? Pls confirm

Secondly
Since this will be supported by multiple Marvell SoC cores.
How about renaming new moved i2c driver as mvi2c.c?

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


Re: [U-Boot] [PATCH 1/2] ARM: MX31: print WRSR to indicate the source of the last reset

2011-03-14 Thread Stefano Babic
On 03/12/2011 02:15 PM, Anatolij Gustschin wrote:

> The reason for using wrsr register is that when reading this register,
> we can also recognize the software reset cause (SWFT, bit 0 is set).
> In our use case we have this requirement.

Ok, understood.

>> I do not think printing the reset cause should be implemented in
>> print_cpuinfo(), because it manages a different issue (reset cause
>> against CPU information). The print_cpuinfo() should have only CPU
>> related values, as clock values, and so on, as it is implemented now for
>> this and other processors. Better to add a different function for the
>> reset cause.
> 
> Were should we call this different function? Should be put it
> into init_sequence[]?

Well, I have not thought as a general function to be inserted in the
init_sequence, I do not know if other ARM processor can export this
function. On other i.MX processors, the reset cause is printed inside
the checkboard function, if CONFIG_DISPLAY_BOARDINFO is set, and not
inside print_cpuinfo(). I understand that the cpuinfo reports only how
to identify the CPU, and the reset cause should be handled separately.

IMHO should be enough to have a mxc_get_reset_cause() (or something like
this) that the board maintainer can call if for some reason he must
perform different actions according to the last reset cause. As name, I
would prefer to identify not static functions starting with mxc_, as I
am trying to uniform all i.MX exponing the same set of functions.

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] powerpc/8xxx: Reduce NAND-SPL build size

2011-03-14 Thread Kumar Gala

On Mar 14, 2011, at 1:27 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message  you 
> wrote:
>> 
 We don't use disable_law in the SPL code so only build it if
 !CONFIG_NAND_SPL.
>>> 
>>> Does -ffunction-sections / --gc-sections not catch this automatically?
>> 
>> Doesn't appear to, but not sure if the NAND makefiles are utilizing those 
>> options.
> 
> Can you please verify this first?
> 
> At first glace it looks as if the compilation was done with
> -ffunction-sections and -fdata-sections, but I don't see --gc-sections
> on the linker command line

commit 8aba9dceebb14144e07d19593111ee3a999c37fc
Author: Nobuhiro Iwamatsu 
Date:   Thu Jan 6 10:23:54 2011 +0900

Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

However, I think this is fixed via:

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

Which we need anyways, because Haiying's patch fixes nand boot in general.

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


[U-Boot] [PATCH V2] Ethernut 5 board support

2011-03-14 Thread Harald Kipp
Add support for the Ethernut 5 open hardware design, based
on Atmel's AT91SAM9XE512 SoC.

Signed-off-by: Harald Kipp 
---

V2:
 - Fix several coding style issues.
 - Remove Ethernet MAC address from default environment.

 MAINTAINERS   |3 +
 board/egnite/ethernut5/Makefile   |   54 +
 board/egnite/ethernut5/ethernut5.c|  259 ++
 board/egnite/ethernut5/ethernut5_pwrman.c |  339 +
 board/egnite/ethernut5/ethernut5_pwrman.h |   68 ++
 boards.cfg|1 +
 include/configs/ethernut5.h   |  281 
 7 files changed, 1005 insertions(+), 0 deletions(-)
 create mode 100644 board/egnite/ethernut5/Makefile
 create mode 100644 board/egnite/ethernut5/ethernut5.c
 create mode 100644 board/egnite/ethernut5/ethernut5_pwrman.c
 create mode 100644 board/egnite/ethernut5/ethernut5_pwrman.h
 create mode 100644 include/configs/ethernut5.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4756f14..8b8aa49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -616,6 +616,9 @@ Wolfgang Denk 
imx27lite   i.MX27
qongi.MX31
 
+egnite GmbH 
+   ethernut5   ARM926EJS (AT91SAM9XE SoC)
+
 Thomas Elste 
 
modnet50ARM720T (NET+50)
diff --git a/board/egnite/ethernut5/Makefile b/board/egnite/ethernut5/Makefile
new file mode 100644
index 000..d8e485f
--- /dev/null
+++ b/board/egnite/ethernut5/Makefile
@@ -0,0 +1,54 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2010
+# egnite GmbH
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= $(BOARD).o
+COBJS-y+= $(BOARD)_pwrman.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/egnite/ethernut5/ethernut5.c 
b/board/egnite/ethernut5/ethernut5.c
new file mode 100644
index 000..ab6d28a
--- /dev/null
+++ b/board/egnite/ethernut5/ethernut5.c
@@ -0,0 +1,259 @@
+/*
+ * (C) Copyright 2011
+ * egnite GmbH 
+ *
+ * (C) Copyright 2010
+ * Ole Reinhardt 
+ *
+ * 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
+ */
+
+/*
+ * Ethernut 5 general board support
+ *
+ * Ethernut is an open source hardware and software project for
+ * embedded Ethernet devices. Hardware layouts and CAD files are
+ * freely available under BSD-like license.
+ *
+ * Ethernut 5 is the first member of the Ethernut board family
+ * with U-Boot and Linux support. This implementation is based
+ * on the original work done by Ole Reinhardt, but heavily modified
+ * to support additional features and the latest board revision 5.0F.
+ *
+ * Main board components are by default:
+ *
+ * Atmel AT91SAM9XE512 CPU with 512 kBytes NOR Flash
+ * 2 x 64 MBytes Micron MT48LC32M16A2P SDRAM
+ * 512 MBytes Micron MT29F4G08ABADA NAND Flash
+ * 4 MBytes Atmel AT45DB321D DataFl

[U-Boot] [PATCH 5/8] I2C: add i2c support for Armada100 platform

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 arch/arm/cpu/arm926ejs/armada100/cpu.c|   14 ++
 arch/arm/include/asm/arch-armada100/mfp.h |4 
 board/Marvell/aspenite/aspenite.c |5 +
 include/configs/aspenite.h|   12 
 4 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c 
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
index 62aa175..8039ad2 100644
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -62,6 +62,14 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apb1clkres->gpio);
 
+   /* Enable general I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+
+   /* Enable power I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+
/*
 * Enable Functional and APB clock at 14.7456MHz
 * for configured UART console
@@ -90,3 +98,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_PXA_I2C
+void i2c_clk_enable (void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h 
b/arch/arm/include/asm/arch-armada100/mfp.h
index d21a79f..f22b5e7 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -60,6 +60,10 @@
 #define MFPO8_UART3_RXDMFP_REG(0x06c) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
 #define MFPO9_UART3_TXDMFP_REG(0x070) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
 
+/* I2c */
+#define MFP105_CI2C_SDAMFP_REG(0x1a4) | MFP_AF1 | 
MFP_DRIVE_MEDIUM
+#define MFP106_CI2C_SCLMFP_REG(0x1a8) | MFP_AF1 | 
MFP_DRIVE_MEDIUM
+
 /* More macros can be defined here... */
 
 #define MFP_PIN_MAX117
diff --git a/board/Marvell/aspenite/aspenite.c 
b/board/Marvell/aspenite/aspenite.c
index 046ffd6..34ac7aa 100644
--- a/board/Marvell/aspenite/aspenite.c
+++ b/board/Marvell/aspenite/aspenite.c
@@ -33,9 +33,14 @@ DECLARE_GLOBAL_DATA_PTR;
 int board_early_init_f(void)
 {
u32 mfp_cfg[] = {
+   /* I2C */
+   MFP105_CI2C_SDA,
+   MFP106_CI2C_SCL,
+
/* Enable Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
+
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
diff --git a/include/configs/aspenite.h b/include/configs/aspenite.h
index fd35f3e..50f8ed7 100644
--- a/include/configs/aspenite.h
+++ b/include/configs/aspenite.h
@@ -63,6 +63,18 @@
 #undef CONFIG_ARCH_MISC_INIT
 
 /*
+ * I2C definition
+ */
+#define CONFIG_CMD_I2C 1
+#define CONFIG_PXA_I2C 1
+#define CONFIG_PXA_I2C_NUM 2
+#define CONFIG_I2C_MULTI_BUS   1
+#define CONFIG_PXA_I2C_REG {0xd4011000, 0xd4025000}
+#define CONFIG_HARD_I2C1
+#define CONFIG_SYS_I2C_SPEED   0
+#define CONFIG_SYS_I2C_SLAVE   0xfe
+
+/*
  * Environment variables configurations
  */
 #define CONFIG_ENV_IS_NOWHERE  1   /* if env in SDRAM */
-- 
1.7.0.4

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


[U-Boot] [PATCH 1/8] pxa: move i2c driver to the common place

2011-03-14 Thread Lei Wen
For better sharing with other platform other than pxa's,
it is more convenient to put the driver to the common place.

Signed-off-by: Lei Wen 
---
 arch/arm/cpu/pxa/Makefile |1 -
 arch/arm/cpu/pxa/i2c.c|  469 -
 drivers/i2c/Makefile  |1 +
 drivers/i2c/pxa_i2c.c |  469 +
 include/configs/innokom.h |1 +
 include/configs/xm250.h   |1 +
 6 files changed, 472 insertions(+), 470 deletions(-)
 delete mode 100644 arch/arm/cpu/pxa/i2c.c
 create mode 100644 drivers/i2c/pxa_i2c.c

diff --git a/arch/arm/cpu/pxa/Makefile b/arch/arm/cpu/pxa/Makefile
index 49a6ed3..e8b59a3 100644
--- a/arch/arm/cpu/pxa/Makefile
+++ b/arch/arm/cpu/pxa/Makefile
@@ -28,7 +28,6 @@ LIB   = $(obj)lib$(CPU).o
 START  = start.o
 
 COBJS  += cpu.o
-COBJS  += i2c.o
 COBJS  += pxafb.o
 COBJS  += timer.o
 COBJS  += usb.o
diff --git a/arch/arm/cpu/pxa/i2c.c b/arch/arm/cpu/pxa/i2c.c
deleted file mode 100644
index 7aa49ae..000
--- a/arch/arm/cpu/pxa/i2c.c
+++ /dev/null
@@ -1,469 +0,0 @@
-/*
- * (C) Copyright 2000
- * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
- *
- * (C) Copyright 2000 Sysgo Real-Time Solutions, GmbH 
- * Marius Groeger 
- *
- * (C) Copyright 2003 Pengutronix e.K.
- * Robert Schwebel 
- *
- * 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
- *
- * Back ported to the 8xx platform (from the 8260 platform) by
- * murray.jen...@cmst.csiro.au, 27-Jan-01.
- */
-
-/* FIXME: this file is PXA255 specific! What about other XScales? */
-
-#include 
-#include 
-
-#ifdef CONFIG_HARD_I2C
-
-/*
- * - CONFIG_SYS_I2C_SPEED
- * - I2C_PXA_SLAVE_ADDR
- */
-
-#include 
-#include 
-#include 
-
-/*#define  DEBUG_I2C   1   /###* activate local debugging output  
*/
-#define I2C_PXA_SLAVE_ADDR 0x1 /* slave pxa unit address   */
-
-#if (CONFIG_SYS_I2C_SPEED == 40)
-#define I2C_ICR_INIT   (ICR_FM | ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | 
ICR_SCLE)
-#else
-#define I2C_ICR_INIT   (ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | ICR_SCLE)
-#endif
-
-#define I2C_ISR_INIT   0x7FF
-
-#ifdef DEBUG_I2C
-#define PRINTD(x) printf x
-#else
-#define PRINTD(x)
-#endif
-
-
-/* Shall the current transfer have a start/stop condition? */
-#define I2C_COND_NORMAL0
-#define I2C_COND_START 1
-#define I2C_COND_STOP  2
-
-/* Shall the current transfer be ack/nacked or being waited for it? */
-#define I2C_ACKNAK_WAITACK 1
-#define I2C_ACKNAK_SENDACK 2
-#define I2C_ACKNAK_SENDNAK 4
-
-/* Specify who shall transfer the data (master or slave) */
-#define I2C_READ   0
-#define I2C_WRITE  1
-
-/* All transfers are described by this data structure */
-struct i2c_msg {
-   u8 condition;
-   u8 acknack;
-   u8 direction;
-   u8 data;
-};
-
-
-/**
- * i2c_pxa_reset: - reset the host controller
- *
- */
-
-static void i2c_reset( void )
-{
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-   writel(readl(ICR) | ICR_UR, ICR);   /* reset the unit */
-   udelay(100);
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-#ifdef CONFIG_CPU_MONAHANS
-   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
-   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
-#else /* CONFIG_CPU_MONAHANS */
-   /* set the global I2C clock on */
-   writel(readl(CKEN) | CKEN14_I2C, CKEN);
-#endif
-   writel(I2C_PXA_SLAVE_ADDR, ISAR);   /* set our slave address */
-   writel(I2C_ICR_INIT, ICR);  /* set control reg values */
-   writel(I2C_ISR_INIT, ISR);  /* set clear interrupt bits */
-   writel(readl(ICR) | ICR_IUE, ICR);  /* enable unit */
-   udelay(100);
-}
-
-
-/**
- * i2c_isr_set_cleared: - wait until certain bits of the I2C status register
- *   are set and cleared
- *
- * @return: 1 in case of success, 0 means timeout (no match within 10 ms).
- */
-static int i2c_isr_set_cleared( unsigned long set_mask, unsigned long 
cleared_mask )
-{
-   int timeout = 1;
-
-   while( ((ISR & set_mask)!=set_mask) || ((ISR & cleared_mask)!=0) ){
-   udelay( 10 );
-  

[U-Boot] [PATCH 4/8] I2C: pxa_i2c: add multi bus support

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 drivers/i2c/pxa_i2c.c |   38 --
 include/configs/dkb.h |4 +++-
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/pxa_i2c.c b/drivers/i2c/pxa_i2c.c
index 0e37417..17b83ab 100644
--- a/drivers/i2c/pxa_i2c.c
+++ b/drivers/i2c/pxa_i2c.c
@@ -131,9 +131,38 @@ struct pxa_i2c {
u32 isar;
 };
 
-static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
 #define PXAI2C_AND(reg, val)   writel(readl(reg) & val, reg)
 #define PXAI2C_OR(reg, val)writel(readl(reg) | val, reg)
+static struct pxa_i2c *base;
+
+#ifdef CONFIG_I2C_MULTI_BUS
+static u32 i2c_regs[CONFIG_PXA_I2C_NUM] = CONFIG_PXA_I2C_REG;
+static unsigned int bus_initialized[CONFIG_PXA_I2C_NUM];
+static unsigned int current_bus = 0;
+
+int i2c_set_bus_num(unsigned int bus)
+{
+   if ((bus < 0) || (bus >= CONFIG_PXA_I2C_NUM)) {
+   printf("Bad bus: %d\n", bus);
+   return -1;
+   }
+
+   base = (struct pxa_i2c *)i2c_regs[bus];
+   current_bus = bus;
+
+   if(!bus_initialized[current_bus]) {
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   bus_initialized[current_bus] = 1;
+   }
+
+   return 0;
+}
+
+unsigned int i2c_get_bus_num(void)
+{
+   return current_bus;
+}
+#endif
 
 /**
  * i2c_pxa_reset: - reset the host controller
@@ -311,6 +340,12 @@ i2c_transfer_finish:
 
 void i2c_init(int speed, int slaveaddr)
 {
+#ifdef CONFIG_I2C_MULTI_BUS
+   base = (struct pxa_i2c *)i2c_regs[current_bus];
+#else
+   base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
+#endif
+
 #ifdef CONFIG_SYS_I2C_INIT_BOARD
u32 icr;
/* call board specific i2c bus reset routine before accessing the   */
@@ -520,5 +555,4 @@ int i2c_write(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
return 0;
 
 }
-
 #endif /* CONFIG_HARD_I2C */
diff --git a/include/configs/dkb.h b/include/configs/dkb.h
index 75c4b99..b1a2319 100644
--- a/include/configs/dkb.h
+++ b/include/configs/dkb.h
@@ -62,7 +62,9 @@
  */
 #define CONFIG_CMD_I2C
 #define CONFIG_PXA_I2C 1
-#define CONFIG_PXA_I2C_REG 0xd4011000
+#define CONFIG_PXA_I2C_NUM 1
+#define CONFIG_I2C_MULTI_BUS   1
+#define CONFIG_PXA_I2C_REG {0xd4011000}
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   0
 #define CONFIG_SYS_I2C_SLAVE   0xfe
-- 
1.7.0.4

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


[U-Boot] [PATCH 2/8] pxa_i2c: use structure to replace the direclty define

2011-03-14 Thread Lei Wen
Signed-off-by: Lei Wen 
---
 arch/arm/cpu/pxa/cpu.c   |   11 +++
 arch/arm/include/asm/arch-pxa/pxa-regs.h |   56 
 board/innokom/innokom.c  |9 +--
 drivers/i2c/pxa_i2c.c|  139 +-
 include/configs/innokom.h|1 +
 include/configs/xm250.h  |1 +
 6 files changed, 111 insertions(+), 106 deletions(-)

diff --git a/arch/arm/cpu/pxa/cpu.c b/arch/arm/cpu/pxa/cpu.c
index 7d49cbb..24b59e7 100644
--- a/arch/arm/cpu/pxa/cpu.c
+++ b/arch/arm/cpu/pxa/cpu.c
@@ -318,3 +318,14 @@ int arch_cpu_init(void)
pxa_clock_setup();
return 0;
 }
+
+void i2c_clk_enable(void)
+{
+#ifdef CONFIG_CPU_MONAHANS
+   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
+   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
+#else /* CONFIG_CPU_MONAHANS */
+   /* set the global I2C clock on */
+   writel(readl(CKEN) | CKEN14_I2C, CKEN);
+#endif
+}
diff --git a/arch/arm/include/asm/arch-pxa/pxa-regs.h 
b/arch/arm/include/asm/arch-pxa/pxa-regs.h
index 65a387f..109fdc0 100644
--- a/arch/arm/include/asm/arch-pxa/pxa-regs.h
+++ b/arch/arm/include/asm/arch-pxa/pxa-regs.h
@@ -456,62 +456,6 @@ typedef void   (*ExcpHndlr) (void) ;
IrSR_XMITIR_IR_MODE)
 
 /*
- * I2C registers
- */
-#define IBMR   0x40301680  /* I2C Bus Monitor Register - IBMR */
-#define IDBR   0x40301688  /* I2C Data Buffer Register - IDBR */
-#define ICR0x40301690  /* I2C Control Register - ICR */
-#define ISR0x40301698  /* I2C Status Register - ISR */
-#define ISAR   0x403016A0  /* I2C Slave Address Register - ISAR */
-
-#ifdef CONFIG_CPU_MONAHANS
-#define PWRIBMR0x40f500C0  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f500C4  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f500C8  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f500CC  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f500D0  /* Power I2C Slave Address 
Register-ISAR */
-#else
-#define PWRIBMR0x40f00180  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f00188  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f00190  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f00198  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f001A0  /* Power I2C Slave Address 
Register-ISAR */
-#endif
-
-/* - Control register bits  */
-
-#define ICR_START  0x1 /* start bit */
-#define ICR_STOP   0x2 /* stop bit */
-#define ICR_ACKNAK 0x4 /* send ACK(0) or NAK(1) */
-#define ICR_TB 0x8 /* transfer byte bit */
-#define ICR_MA 0x10/* master abort */
-#define ICR_SCLE   0x20/* master clock enable, mona SCLEA */
-#define ICR_IUE0x40/* unit enable */
-#define ICR_GCD0x80/* general call disable */
-#define ICR_ITEIE  0x100   /* enable tx interrupts */
-#define ICR_IRFIE  0x200   /* enable rx interrupts, mona: DRFIE */
-#define ICR_BEIE   0x400   /* enable bus error ints */
-#define ICR_SSDIE  0x800   /* slave STOP detected int enable */
-#define ICR_ALDIE  0x1000  /* enable arbitration interrupt */
-#define ICR_SADIE  0x2000  /* slave address detected int enable */
-#define ICR_UR 0x4000  /* unit reset */
-#define ICR_FM 0x8000  /* Fast Mode */
-
-/* - Status register bits - */
-
-#define ISR_RWM0x1 /* read/write mode */
-#define ISR_ACKNAK 0x2 /* ack/nak status */
-#define ISR_UB 0x4 /* unit busy */
-#define ISR_IBB0x8 /* bus busy */
-#define ISR_SSD0x10/* slave stop detected */
-#define ISR_ALD0x20/* arbitration loss detected */
-#define ISR_ITE0x40/* tx buffer empty */
-#define ISR_IRF0x80/* rx buffer full */
-#define ISR_GCAD   0x100   /* general call address detected */
-#define ISR_SAD0x200   /* slave address detected */
-#define ISR_BED0x400   /* bus error no ACK/NAK */
-
-/*
  * Serial Audio Controller
  */
 /* FIXME the audio defines collide w/ the SA defines.  I don't like these
diff --git a/board/innokom/innokom.c b/board/innokom/innokom.c
index e658c35..22de7e3 100644
--- a/board/innokom/innokom.c
+++ b/board/innokom/innokom.c
@@ -45,12 +45,7 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 int i2c_init_board(void)
 {
-   int i, icr;
-
-   /* disable I2C controller first, otherwhise it think

[U-Boot] [PATCH 3/8] I2C: add i2c support for Pantheon platform

2011-03-14 Thread Lei Wen
Add i2c support to dkb board with pantheon soc.

Signed-off-by: Lei Wen 
---
 arch/arm/cpu/arm926ejs/pantheon/cpu.c|   10 ++
 arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
 arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
 board/Marvell/dkb/dkb.c  |4 
 include/configs/dkb.h|   11 +++
 5 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c 
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index 9ddc77c..88ecfae 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -59,6 +59,10 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apbclkres->gpio);
 
+   /* Enable I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+   writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+
icache_enable();
 
return 0;
@@ -76,3 +80,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_PXA_I2C
+void i2c_clk_enable (void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-pantheon/cpu.h 
b/arch/arm/include/asm/arch-pantheon/cpu.h
index 30f4393..60955c5 100644
--- a/arch/arm/include/asm/arch-pantheon/cpu.h
+++ b/arch/arm/include/asm/arch-pantheon/cpu.h
@@ -50,7 +50,9 @@ struct panthapb_registers {
u32 uart0;  /*0x000*/
u32 uart1;  /*0x004*/
u32 gpio;   /*0x008*/
-   u8 pad0[0x034 - 0x08 - 4];
+   u8 pad0[0x02c - 0x08 - 4];
+   u32 twsi;   /*0x02c*/
+   u8 pad1[0x034 - 0x2c - 4];
u32 timers; /*0x034*/
 };
 
diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h 
b/arch/arm/include/asm/arch-pantheon/mfp.h
index fb291cf..041e64c 100644
--- a/arch/arm/include/asm/arch-pantheon/mfp.h
+++ b/arch/arm/include/asm/arch-pantheon/mfp.h
@@ -34,6 +34,8 @@
 /* UART2 */
 #define MFP47_UART2_RXDMFP_REG(0x198) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
 #define MFP48_UART2_TXDMFP_REG(0x19c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
+#define MFP53_CI2C_SCL MFP_REG(0x1b0) | MFP_AF2 | MFP_DRIVE_MEDIUM
+#define MFP54_CI2C_SDA MFP_REG(0x1b4) | MFP_AF2 | MFP_DRIVE_MEDIUM
 
 /* More macros can be defined here... */
 
diff --git a/board/Marvell/dkb/dkb.c b/board/Marvell/dkb/dkb.c
index 72a2d2a..00f73e7 100644
--- a/board/Marvell/dkb/dkb.c
+++ b/board/Marvell/dkb/dkb.c
@@ -36,6 +36,10 @@ int board_early_init_f(void)
MFP47_UART2_RXD,
MFP48_UART2_TXD,
 
+   /* I2C */
+   MFP53_CI2C_SCL,
+   MFP54_CI2C_SDA,
+
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
diff --git a/include/configs/dkb.h b/include/configs/dkb.h
index 638af5e..75c4b99 100644
--- a/include/configs/dkb.h
+++ b/include/configs/dkb.h
@@ -56,6 +56,17 @@
 #include "mv-common.h"
 
 #undef CONFIG_ARCH_MISC_INIT
+
+/*
+ * I2C definition
+ */
+#define CONFIG_CMD_I2C
+#define CONFIG_PXA_I2C 1
+#define CONFIG_PXA_I2C_REG 0xd4011000
+#define CONFIG_HARD_I2C1
+#define CONFIG_SYS_I2C_SPEED   0
+#define CONFIG_SYS_I2C_SLAVE   0xfe
+
 /*
  * Environment variables configurations
  */
-- 
1.7.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] sh: Add handling of CONFIG_SYS_FLASH_BASE for board.c

2011-03-14 Thread Nobuhiro Iwamatsu
Hi,

2011/3/13 Wolfgang Denk :
> Dear Nobuhiro Iwamatsu,
>
> In message 
> <1299484258-6042-1-git-send-email-nobuhiro.iwamatsu...@renesas.com> you wrote:
>> Some board of SH does not have flash memoy.
>> This change initializes bi_flashstart, when CONFIG_SYS_FLASH_BASE was 
>> defined,
>>
>> Signed-off-by: Nobuhiro Iwamatsu 
>> ---
>>  arch/sh/lib/board.c |    6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c
>> index 968566c..81244ae 100644
>> --- a/arch/sh/lib/board.c
>> +++ b/arch/sh/lib/board.c
>> @@ -43,6 +43,7 @@ const char version_string[] = U_BOOT_VERSION" 
>> ("U_BOOT_DATE" - "U_BOOT_TIME")";
>>
>>  unsigned long monitor_flash_len = CONFIG_SYS_MONITOR_LEN;
>>
>> +#if defined(CONFIG_SYS_FLASH_BASE)
>
> I don't think this should depend on CONFIG_SYS_FLASH_BASE.
>
> Boards without NOR flash should define CONFIG_SYS_NO_FLASH, and this
> define should be used here.
>

Oh, sorry. I will resend patch.
Thanks fo your patch review.

Nobuhiro

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


Re: [U-Boot] [PATCH] Ethernut 5 board support

2011-03-14 Thread Harald Kipp
On 3/13/2011 12:41 PM, Harald Kipp wrote:
> Add support for the Ethernut 5 open hardware design, based on Atmel's
> AT91SAM9XE512 SoC.

NAK.

Too many trailing whitespaces and some more style issues. I haven't been 
aware of the checkpatch script.

Regards,

Harald

PS: Seems to become a confirmed habit, that I'm talking to myself on 
this list. ;-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 02/20] mpc832x: add support for the mpc8321 based suvd3 board

2011-03-14 Thread Heiko Schocher
Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <1299591018-8944-3-git-send-email...@denx.de> you wrote:
>> - serial console on UART1
>> - Ethernet RMII over UCC4
>> - PHY SMSC LAN8700
>> - 64MB Flash
>> - 128 MB DDR2 RAM
>> - I2C
>> - bootcount
>>
>> This board is similiar to the kmeter1 (8360) board,
>> so common config options are extracted into the
>> include/configs/km83xx-common.h file.
> 
> ...
>> -#if defined(CONFIG_BOOTCOUNT_LIMIT) && defined(CONFIG_MPC8360)
>> +#if defined(CONFIG_BOOTCOUNT_LIMIT) && \
>> +(defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x))
>>  #include 
> 
> Please keep lists sorted: 832x < 8360.  Please fix globally.

Ok.

>> +phys_size_t initdram (int board_type)
>> +{
>> +#if defined(CONFIG_DDR_ECC) && !defined(CONFIG_ECC_INIT_VIA_DDRCONTROLLER)
>> +extern void ddr_enable_ecc (unsigned int dram_size);
>> +#endif
>> +volatile immap_t *im = (immap_t *)CONFIG_SYS_IMMR;
>> +u32 msize = 0;
>> +
>> +if ((im->sysconf.immrbar & IMMRBAR_BASE_ADDR) != (u32)im)
>> +return -1;
>> +
>> +/* DDR SDRAM - Main SODIMM */
> 
> Is this comment correct?

No, remove it.

>> +im->sysconf.ddrlaw[0].bar = CONFIG_SYS_DDR_BASE & LAWBAR_BAR;
>> +msize = fixed_sdram ();
> 
> Can we not use get_ram_size() ?

fixed_sdram calls this.

>> +extern int ivm_read_eeprom (void);
> 
> Protoypes belong to header files.

Yep, this extern is not needed, as the header file is included, remove it.

> Um... seems you did not run checkpatch?

:-(

Argh, you are right ...

> I see this:
> 
> [PATCH 01/20] keymile: rework headerfiles for keymile boards
> total: 0 errors, 16 warnings, 659 lines checked

Hmm... I see other statistics:

[hs@pollux u-boot]$ ./../linux-2.6-denx/scripts/checkpatch.pl 
20110308/0001-keymile-rework-headerfiles-for-keymile-boards.patch
WARNING: line over 80 characters
#636: FILE: include/configs/kmeter1.h:179:
+#define CONFIG_SYS_MONITOR_LEN (768 * 1024) /* Reserve 768 kB for Mon 
*/

WARNING: line over 80 characters
#750: FILE: include/configs/mgcoge.h:133:
+#define CONFIG_SYS_MONITOR_LEN (768 << 10) /* Reserve 768KB for 
Monitor */

total: 0 errors, 2 warnings, 659 lines checked

20110313/0001-keymile-rework-headerfiles-for-keymile-boards.patch has style 
problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
[hs@pollux u-boot]$

Only 2 warnings ... which checkpatch.pl do you use?

> [PATCH 02/20] mpc832x: add support for the mpc8321 based suvd3 board
> total: 17 errors, 63 warnings, 1326 lines checked
> [PATCH 03/20] mpc832x: add support for mpc8321 based tuxa1 board
> total: 16 errors, 2 warnings, 250 lines checked
> [PATCH 04/20] mpc832x: add support for mpc8321 based tuda1 board
> total: 0 errors, 4 warnings, 265 lines checked
> ...
> [PATCH 06/20] arm: add support of Kirkwood based board SUEN8
> total: 0 errors, 1 warnings, 73 lines checked
> [PATCH 07/20] ppc: add support for ppc based board mgcoge2ne
> total: 11 errors, 14 warnings, 733 lines checked
> ...
> [PATCH 09/20] powerpc, 83xx: add kmsupx5 board support
> total: 3 errors, 3 warnings, 103 lines checked
> [PATCH 10/20] km-arm: i2c support for suenx based boards
> total: 1 errors, 0 warnings, 70 lines checked
> ...
> [PATCH 12/20] ppc, 8321: cleanup tuxa1, tuda1 and suvd3 support
> total: 1 errors, 5 warnings, 570 lines checked
> [PATCH 13/20] keymile, common; fix i2c deblocking support
> total: 0 errors, 21 warnings, 161 lines checked
> [PATCH 14/20] arm, keymile: updates for the arm based boards from keymile
> total: 0 errors, 2 warnings, 142 lines checked
> [PATCH 15/20] keymile boards: add CONFIG_PIGGY_MAC_ADRESS_OFFSET
> total: 1 errors, 1 warnings, 38 lines checked
> [PATCH 16/20] keymile, common: add setting of some environment variables
> total: 0 errors, 7 warnings, 145 lines checked
> [PATCH 17/20] ppc, arm: rework and enhance keymile-common.h
> total: 0 errors, 3 warnings, 253 lines checked
> ...
> [PATCH 19/20] keymile-common.h: remove IO mux stuff
> total: 3 errors, 5 warnings, 27 lines checked
> 
> 
> Please check and fix where needed.  I stop reviewing here.

Ok, I recheck this, thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 01/20] keymile: rework headerfiles for keymile boards

2011-03-14 Thread Heiko Schocher
Hello Wolfgang,

Wolfgang Denk wrote:
> In message <1299591018-8944-2-git-send-email...@denx.de> you wrote:
>> - This patch reworks all headerfiles for keymile boards (coge, supx4,
>>   eter1, suen3).
>>   Furthermore, a refactoring on the whole environment variables has been
>>   acomplished.
> 
> Two independent changes => Please submit as two separate patches.

Ok, I try to split this in two patches.

> ...
>> +#define CONFIG_HUSH_INIT_VAR1
> ...
>> +#define CONFIG_I2C_MULTI_BUS1
> ...
>> +#define CONFIG_I2C_MUX  1
> 
> Defines like these that select functions only should not be assigned
> any numeric (or other value).  Please omit thse.  Please fix globally.

Ok.

>> +#define CONFIG_KM_DEF_ENV_CONSTANTS \
> ...
>> +"default="  \
>> +"setenv default \'run newenv; reset\' &&  " \
> 
> These backslashes are redundant at best.  Why not drop them?

Ok, drop it.

> ...
>> +"u-boot=" xstr(CONFIG_HOSTNAME) "/u-boot.bin \0"\
> 
> Are you sure you really want that trailing blank? [Please check
> globally.]

Good cathc, check this.

> ...
>> +#define CONFIG_SYS_MONITOR_LEN  (768 << 10) /* Reserve 
>> 768KB for Monitor */
> 
> Line too long.  Please fix globally.

Ok.

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot