Re: [U-Boot] [PATCH V2] sheevaplug: correct SDRAM address control register value
> -Original Message- > From: Mark Asselstine [mailto:mark.asselst...@windriver.com] > Sent: Monday, October 19, 2009 6:49 PM > To: u-boot@lists.denx.de; Prafulla Wadaskar > Subject: [PATCH V2] sheevaplug: correct SDRAM address control > register value > > The SheevaPlug DevKit is shipped with 4x8 by 1Gb DDR devices in > two banks for a total of 512MB of RAM. Based on this configuration > the existing values for SDRAM address control register are incorrect > and result in random kernel oops as memory is incorrectly accessed > (while for example extracting a large tarball such as a rootfs). > Based on the hardware configuration along with the supporting > documentation from Marvell these are the correct values, as > well this change mimics values previously used in Marvell's own > u-boot git tree for the SheevaPlug. > > Other variants of the hardware such as the PogoPlug and TonidoPlug > may have different memory configurations but to properly support > those additional board directories should be maintained or a better > system to support other kwb*.cfg is needed. > > Tested on SheevaPlug DevKit. > > Signed-off-by: Mark Asselstine > --- > Thanks Simon for the heads up on the documentation change. Changes > from V1, fix comment "reserved" -> "x8". > > board/Marvell/sheevaplug/kwbimage.cfg | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/board/Marvell/sheevaplug/kwbimage.cfg > b/board/Marvell/sheevaplug/kwbimage.cfg > index 6c47d62..3b9c53f 100644 > --- a/board/Marvell/sheevaplug/kwbimage.cfg > +++ b/board/Marvell/sheevaplug/kwbimage.cfg > @@ -74,11 +74,11 @@ DATA 0xFFD0140C 0x0a33# DDR > Timing (High) > # bit12-11: TW2W > # bit31-13: zero required > > -DATA 0xFFD01410 0x0099 # DDR Address Control > -# bit1-0: 01, Cs0width=x16 > -# bit3-2: 10, Cs0size=512Mb > -# bit5-4: 01, Cs1width=x16 > -# bit7-6: 10, Cs1size=512Mb > +DATA 0xFFD01410 0x00cc # DDR Address Control > +# bit1-0: 00, Cs0width=x8 > +# bit3-2: 11, Cs0size=1Gb > +# bit5-4: 00, Cs1width=x8 > +# bit7-6: 11, Cs1size=1Gb > # bit9-8: 00, Cs2width=nonexistent > # bit11-10: 00, Cs2size =nonexistent > # bit13-12: 00, Cs3width=nonexistent > -- > 1.6.3.3 > Applied to u-boot-marvell.git next branch Regards.. Prafulla . . > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Wednesday, October 28, 2009 1:47 PM
> To: Prafulla Wadaskar; u-boot@lists.denx.de
> Subject: Re: [PATCH] arm:kirkwood: Add hardware watchdog
> support for Marvell Kirkwood boards
>
> Hi again Prafulla and the list!
>
> On Mon, 28 Sep 2009 09:06:26 +0200
> Simon Kagstrom wrote:
>
> > Initialize by calling kw_watchdog_init() with the number of
> seconds for
> > the watchdog to timeout.
> >
> > Signed-off-by: Simon Kagstrom
>
> Were there any particular problems with this patch that I should
> rework? It's not enabled by default.
Hi Simon
We can enable this support
Please see my in lined comments below
>
> // Simon
>
> > ---
> > cpu/arm926ejs/kirkwood/timer.c | 29
> +
> > include/asm-arm/arch-kirkwood/cpu.h |2 ++
> > 2 files changed, 31 insertions(+), 0 deletions(-)
> >
> > diff --git a/cpu/arm926ejs/kirkwood/timer.c
> b/cpu/arm926ejs/kirkwood/timer.c
> > index 817ff42..f3397e7 100644
> > --- a/cpu/arm926ejs/kirkwood/timer.c
> > +++ b/cpu/arm926ejs/kirkwood/timer.c
> > @@ -25,6 +25,7 @@
> > #include
> >
> > #define UBOOT_CNTR 0 /* counter to use for uboot timer */
> > +#define WATCHDOG_CNTR 2
BTW, this declaration will not be required if you see struct kwtmr_register
> >
> > /* Timer reload and current value registers */
> > struct kwtmr_val {
> > @@ -166,3 +167,31 @@ int timer_init(void)
> >
> > return 0;
> > }
> > +
> > +#if defined(CONFIG_HW_WATCHDOG)
> > +static unsigned long watchdog_timeout = 5;
Please get rid of this magic number, Pls provide some comments
I think just u8 are sufficient here since the time is in seconds.
I suggest variable name as "wdt_tout" to keep it small
Some comments for function...
> > +void hw_watchdog_reset(void)
> > +{
> > + unsigned long time = CONFIG_SYS_TCLK * watchdog_timeout;
Please use u32 here to avoid typecast in writel
Pls provide comments for this calculations
> > +
> > + writel(time, CNTMR_VAL_REG(WATCHDOG_CNTR));
Please check struct kwtmr_registers, wdt regs are named differently, pls use
them
> > +}
> > +
> > +void kw_watchdog_init(unsigned long timeout_secs)
> > +{
> > + struct kwcpu_registers *cpureg =
> > + (struct kwcpu_registers *)KW_CPU_REG_BASE;
> > + unsigned int cntmrctrl;
> > +
> > + watchdog_timeout = timeout_secs;
> > + /* Enable CPU reset if watchdog expires */
> > + cpureg->rstoutn_mask |= WATCHDOG_CNTR;
access any arm registers through readl/writel only
Using WATCHDOG_CNTR is confusing here, pls use something like this (1 << 1)
(ref reset_cpu in cpu.c)
> > + hw_watchdog_reset();
> > +
> > + /* Enable the watchdog */
> > + cntmrctrl = readl(CNTMR_CTRL_REG);
> > + cntmrctrl |= CTCR_ARM_TIMER_EN(WATCHDOG_CNTR);
> > + cntmrctrl |= CTCR_ARM_TIMER_AUTO_EN(WATCHDOG_CNTR);
> > + writel(cntmrctrl, CNTMR_CTRL_REG);
This need to be updated as per struct kwtmr_register
> > +}
> > +#endif
> > diff --git a/include/asm-arm/arch-kirkwood/cpu.h
> b/include/asm-arm/arch-kirkwood/cpu.h
> > index b3022a3..df49c3f 100644
> > --- a/include/asm-arm/arch-kirkwood/cpu.h
> > +++ b/include/asm-arm/arch-kirkwood/cpu.h
> > @@ -165,5 +165,7 @@ int kw_config_mpp(unsigned int mpp0_7,
> unsigned int mpp8_15,
> > unsigned int mpp32_39, unsigned int mpp40_47,
> > unsigned int mpp48_55);
> > unsigned int kw_winctrl_calcsize(unsigned int sizeval);
> > +void kw_watchdog_init(unsigned long timeout_secs);
Functions declared here are suppose to be in cpu.c
Moreover I think we don't need this function at all,
You can club kw_watchdog_init with hw_watchdog_reset so that at very first
WATCHDOG_RESET() function call,
watchdog timer it will be initialized.
Regards..
Prafulla . .
> > +
> > #endif /* __ASSEMBLY__ */
> > #endif /* _KWCPU_H */
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Wednesday, October 28, 2009 3:23 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] arm:kirkwood: Add hardware watchdog
> support for Marvell Kirkwood boards
>
> Thanks for the comments!
>
> On Wed, 28 Oct 2009 02:24:43 -0700
> Prafulla Wadaskar wrote:
>
> > > >
> > > > #define UBOOT_CNTR 0 /* counter to use for
> uboot timer */
> > > > +#define WATCHDOG_CNTR 2
> >
> > BTW, this declaration will not be required if you see
> struct kwtmr_register
>
> Well, to me it makes the code more clear, so I'd prefer to keep it.
So I would like to suggest rename it as WATCHDOG_TMR
>
> > > >
> > > > /* Timer reload and current value registers */
> > > > struct kwtmr_val {
> > > > @@ -166,3 +167,31 @@ int timer_init(void)
> > > >
> > > > return 0;
> > > > }
> > > > +
> > > > +#if defined(CONFIG_HW_WATCHDOG)
> > > > +static unsigned long watchdog_timeout = 5;
> >
> > Please get rid of this magic number, Pls provide some comments
> > I think just u8 are sufficient here since the time is in seconds.
> > I suggest variable name as "wdt_tout" to keep it small
>
> I'll make it configurable through config.h, and a u8. However, I think
> watchdog_timeout is a more descriptive name here.
>
> > > > +
> > > > + writel(time, CNTMR_VAL_REG(WATCHDOG_CNTR));
> >
> > Please check struct kwtmr_registers, wdt regs are named
> differently, pls use them
>
> I can do that, but CNTMR_VAL_REG is actually defined higher up in the
> file as
>
>#define CNTMR_VAL_REG(tmrnum)
> &kwtmr_regs->tmr[tmrnum].val
>
> and used for the regular timer support. I'm not sure I like that, but
> at least the file should be internally consistent.
You can update the structure to use WDT timer in the same way as other timers,
there is no sense putting additional names in structure.
>
> > > > --- a/include/asm-arm/arch-kirkwood/cpu.h
> > > > +++ b/include/asm-arm/arch-kirkwood/cpu.h
> > > > @@ -165,5 +165,7 @@ int kw_config_mpp(unsigned int mpp0_7,
> > > unsigned int mpp8_15,
> > > > unsigned int mpp32_39, unsigned int mpp40_47,
> > > > unsigned int mpp48_55);
> > > > unsigned int kw_winctrl_calcsize(unsigned int sizeval);
> > > > +void kw_watchdog_init(unsigned long timeout_secs);
> >
> > Functions declared here are suppose to be in cpu.c
> > Moreover I think we don't need this function at all,
> > You can club kw_watchdog_init with hw_watchdog_reset so
> that at very first WATCHDOG_RESET() function call,
> > watchdog timer it will be initialized.
>
> But then it's unconditionally turned on as soon as the first
> WATCHDOG_RESET() is called, which might not be what you want.
>
> In the long run, we should probably add command line support for
> enabling the watchdog (some might want to do it just before starting
> Linux for example).
You can even call WATCHDOG_RESET() from wherever from your code to enable it
Regards..
Prafulla . .
>
> // Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
> -Original Message- > From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] > Sent: Wednesday, October 28, 2009 6:14 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] arm:kirkwood: Add hardware watchdog > support for Marvell Kirkwood boards > > On Wed, 28 Oct 2009 04:34:10 -0700 > Prafulla Wadaskar wrote: > > > >#define CNTMR_VAL_REG(tmrnum) > > > &kwtmr_regs->tmr[tmrnum].val > > > > > > and used for the regular timer support. I'm not sure I > like that, but > > > at least the file should be internally consistent. > > > > You can update the structure to use WDT timer in the same > way as other timers, > > there is no sense putting additional names in structure. > > But I'm not - the WDT timer is used in the same way as the > other timer. So the kwtmr_register structure clean up can be a separate patch. > The only difference is the added WATCHDOG_TMR define which specifies > which Kirkwood timer to use as a watchdog. Ack > > > > But then it's unconditionally turned on as soon as the first > > > WATCHDOG_RESET() is called, which might not be what you want. > > > > > > In the long run, we should probably add command line support for > > > enabling the watchdog (some might want to do it just > before starting > > > Linux for example). > > > > You can even call WATCHDOG_RESET() from wherever from your > code to enable it > > Sure, but WATCHDOG_RESET() will be called anyway (and probably before > my code), so it will be enabled anyhow in that case. My point is that > sometimes you don't want the watchdog to get started directly, hence > the function to enable it. That is also valid point, This will be the generic need for all architectures. Lets introduce WATCHDOG_INIT() as new generic interface. What do you think? Regards.. Prafulla . . > > // Simon > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2]: common: Add a watchdog CLI command
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Wednesday, October 28, 2009 7:44 PM
> To: U-Boot ML; Prafulla Wadaskar
> Subject: [PATCH 1/2]: common: Add a watchdog CLI command
>
> A watchdog command to enable the watchdog with a timeout or disable it
> can sometimes be useful. Add that. This also adds a common API for
> enabling or disabling watchdogs. The API is simple:
>
> void watchdog_enable(unsigned int timeout);
> void watchdog_disable(void);
>
> disabling the watchdog might or might not be possible depending on the
> hardware, and the timeout range can also vary in the same way.
>
> Signed-off-by: Simon Kagstrom
> ---
> common/Makefile |1 +
> common/cmd_watchdog.c | 61
> +
> include/watchdog.h|9 +++
> 3 files changed, 71 insertions(+), 0 deletions(-)
> create mode 100644 common/cmd_watchdog.c
>
> diff --git a/common/Makefile b/common/Makefile
> index 3781738..f14ba0e 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -160,6 +160,7 @@ COBJS-$(CONFIG_LYNXKDI) += lynxkdi.o
> COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
> COBJS-$(CONFIG_UPDATE_TFTP) += update.o
> COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
> +COBJS-$(CONFIG_CMD_WATCHDOG) += cmd_watchdog.o
>
>
> COBJS:= $(sort $(COBJS-y))
> diff --git a/common/cmd_watchdog.c b/common/cmd_watchdog.c
> new file mode 100644
> index 000..d26be4f
> --- /dev/null
> +++ b/common/cmd_watchdog.c
> @@ -0,0 +1,61 @@
> +/*
> + * (C) Copyright 2009
> + * Net Insight
> + * Written-by: Simon Kagstrom
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include
> +#include
> +
> +static int do_watchdog(cmd_tbl_t *cmdtp, int flag, int argc,
> char *argv[])
> +{
> + const char *cmd;
> + char *endp;
> + int timeout;
> +
> + /* need one argument */
> + if (argc != 2)
> + goto usage;
> +
> + cmd = argv[1];
> +
> + if (strcmp(cmd, "off") == 0) {
> + watchdog_disable();
> + return 0;
> + }
> + timeout = simple_strtoul(cmd, &endp, 0);
> + if (endp == cmd)
> + goto usage;
> + if (timeout < 0)
> + goto usage;
How about passing zero value here, will it be a correct input for
watchdog_enable?
> +
> + /* Everything fine, enable the watchdog */
> + watchdog_enable(timeout);
Can we check for some error code here from lower layer and dump some error
message?
For ex. Specified timeout value may be invalid for specific h/w
> +
> + return 0;
> +usage:
> + cmd_usage(cmdtp);
> + return 1;
> +}
> +
> +U_BOOT_CMD(
> + watchdog, 2, 0, do_watchdog,
> + "Watchdog commands",
> + " - start the watchdog with `timeout'
> seconds timeout\n"
> + "watchdog off - stop the watchdog (can't be
> done on all boards)\n"
> +);
> diff --git a/include/watchdog.h b/include/watchdog.h
> index 9265be9..953cf61 100644
> --- a/include/watchdog.h
> +++ b/include/watchdog.h
> @@ -70,6 +70,15 @@
> #endif /* CONFIG_WATCHDOG && !__ASSEMBLY__ */
> #endif /* CONFIG_HW_WATCHDOG */
>
> +#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)
> +extern void watchdog_enable(unsigned int timeout_secs);
> +
> +extern void watchdog_disable(void);
> +#else
> +static inline void watchdog_enable(unsigned int timeout_secs) { }
> +static inline void watchdog_disable(void) { }
> +#endif
> +
> /*
> * Prototypes from $(CPU)/cpu.c.
> */
What does this means?
Regards..
Prafulla . .
> --
> 1.6.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2]: arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Wednesday, October 28, 2009 7:46 PM
> To: U-Boot ML; Prafulla Wadaskar
> Subject: [PATCH 2/2]: arm:kirkwood: Add hardware watchdog
> support for Marvell Kirkwood boards
>
> Initialize by calling the generic API watchdog_enable() with
> the number
> of seconds for the watchdog to timeout. It's not possible to
> disable the
> watchdog once it's on.
>
> Signed-off-by: Simon Kagstrom
> ---
> ChangeLog:
>
> v2: (Some of the comments from Prafulla)
>* Use readl/writel
>* Rename WATCHDOG_CNTR -> WATCHDOG_TMR
>
> cpu/arm926ejs/kirkwood/timer.c | 37
> +
> 1 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/arm926ejs/kirkwood/timer.c
> b/cpu/arm926ejs/kirkwood/timer.c
> index 817ff42..797ab04 100644
> --- a/cpu/arm926ejs/kirkwood/timer.c
> +++ b/cpu/arm926ejs/kirkwood/timer.c
> @@ -23,8 +23,10 @@
>
> #include
> #include
> +#include
>
> #define UBOOT_CNTR 0 /* counter to use for uboot timer */
> +#define WATCHDOG_TMR 2
>
> /* Timer reload and current value registers */
> struct kwtmr_val {
> @@ -166,3 +168,38 @@ int timer_init(void)
>
> return 0;
> }
> +
> +#if defined(CONFIG_HW_WATCHDOG)
> +static unsigned long watchdog_timeout = 5;
> +void hw_watchdog_reset(void)
> +{
> + u32 time = CONFIG_SYS_TCLK * watchdog_timeout;
> +
> + writel(time, CNTMR_VAL_REG(WATCHDOG_TMR));
> +}
> +
> +void watchdog_enable(unsigned int timeout_secs)
> +{
> + struct kwcpu_registers *cpureg =
> + (struct kwcpu_registers *)KW_CPU_REG_BASE;
> + u32 rstoutn_mask;
> + u32 cntmrctrl;
> +
> + watchdog_timeout = timeout_secs;
> + /* Enable CPU reset if watchdog expires */
> + rstoutn_mask = readl(cpureg->rstoutn_mask);
> + writel(rstoutn_mask |= WATCHDOG_TMR, &cpureg->rstoutn_mask);
> + hw_watchdog_reset();
> +
> + /* Enable the watchdog */
> + cntmrctrl = readl(CNTMR_CTRL_REG);
> + cntmrctrl |= CTCR_ARM_TIMER_EN(WATCHDOG_TMR);
> + cntmrctrl |= CTCR_ARM_TIMER_AUTO_EN(WATCHDOG_TMR);
> + writel(cntmrctrl, CNTMR_CTRL_REG);
> +}
> +
> +void watchdog_disable(void)
> +{
> + /* Can't be done */
you can disable CPU reset if watchdog expires to achieve this functionality
Or reseting bit 4 in CPU timer control reg
Regards..
Prafulla . .
> +}
> +#endif
> --
> 1.6.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2]: common: Add a watchdog CLI command
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Thursday, October 29, 2009 1:39 PM
> To: U-Boot ML; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH v2 1/2]: common: Add a watchdog CLI command
>
> A watchdog command to enable the watchdog with a timeout from the CLI
> can sometimes be useful. Add that. This also adds a common API for
> enabling watchdogs. The API is simple:
>
> int watchdog_enable(unsigned int timeout);
>
> the timeout range vary depending on hardware, and the driver should
> return a negative value if the call failed.
>
> Signed-off-by: Simon Kagstrom
> ---
> ChangeLog:
> v2:
> * Passing zero as timeout is invalid (Prafulla)
> * Add return value from watchdog_enable(), negative means
> failure (Prafulla, Wolfgang)
> * Remove watchdog_disable() (Wolfgang)
> * Use weak default function for watchdog_enable() (Wolfgang)
> * Provide friendly and helpful printouts when invalid
> parameters are
> passed to the CLI command
>
...snip..
> index 10d8904..47e867b 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -1446,3 +1446,10 @@ int do_run (cmd_tbl_t * cmdtp, int
> flag, int argc, char *argv[])
> return 0;
> }
> #endif
> +
> +
One small cosmetic change,
Additional line inserted here, pls remove it.
Otherwise ack.
Regards..
Prafulla . .
> +inline int __watchdog_enable(unsigned int timeout_secs)
> +{
> + return -1;
> +}
> +int watchdog_enable(unsigned int timeout_secs)
> __attribute__((weak, alias("__watchdog_enable")));
> diff --git a/include/watchdog.h b/include/watchdog.h
> index 9265be9..74c2bda 100644
> --- a/include/watchdog.h
> +++ b/include/watchdog.h
> @@ -70,6 +70,8 @@
> #endif /* CONFIG_WATCHDOG && !__ASSEMBLY__ */
> #endif /* CONFIG_HW_WATCHDOG */
>
> +extern int watchdog_enable(unsigned int timeout_secs);
> +
> /*
> * Prototypes from $(CPU)/cpu.c.
> */
> --
> 1.6.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2]: arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Thursday, October 29, 2009 1:41 PM
> To: U-Boot ML; Prafulla Wadaskar; Wolfgang Denk
> Subject: [PATCH v2 2/2]: arm:kirkwood: Add hardware watchdog
> support for Marvell Kirkwood boards
>
> Initialize by calling the generic API watchdog_enable() with
> the number
> of seconds for the watchdog to timeout. It's not possible to
> disable the
> watchdog once it's on.
>
> Signed-off-by: Simon Kagstrom
> ---
> ChangeLog:
> v2:
> * Remove watchdog_disable()
> * Add check to see that the maximum timeout supported by
> the hardware
>is not exceeded
>
> cpu/arm926ejs/kirkwood/timer.c | 38
> ++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/arm926ejs/kirkwood/timer.c
> b/cpu/arm926ejs/kirkwood/timer.c
> index 817ff42..69a5cb7 100644
> --- a/cpu/arm926ejs/kirkwood/timer.c
> +++ b/cpu/arm926ejs/kirkwood/timer.c
> @@ -23,8 +23,10 @@
>
> #include
> #include
> +#include
>
> #define UBOOT_CNTR 0 /* counter to use for uboot timer */
> +#define WATCHDOG_TMR 2
>
> /* Timer reload and current value registers */
> struct kwtmr_val {
> @@ -166,3 +168,39 @@ int timer_init(void)
>
> return 0;
> }
> +
> +#if defined(CONFIG_HW_WATCHDOG)
> +static unsigned long watchdog_timeout = 5;
> +void hw_watchdog_reset(void)
> +{
> + u32 time = CONFIG_SYS_TCLK * watchdog_timeout;
> +
> + writel(time, CNTMR_VAL_REG(WATCHDOG_TMR));
> +}
> +
> +#define MAX_TIMEOUT (0x / CONFIG_SYS_TCLK)
> +int watchdog_enable(unsigned int timeout_secs)
> +{
> + struct kwcpu_registers *cpureg =
> + (struct kwcpu_registers *)KW_CPU_REG_BASE;
> + u32 rstoutn_mask;
> + u32 cntmrctrl;
> +
> + if (timeout_secs > MAX_TIMEOUT)
> + return -1;
> +
> + watchdog_timeout = timeout_secs;
> + /* Enable CPU reset if watchdog expires */
> + rstoutn_mask = readl(cpureg->rstoutn_mask);
> + writel(rstoutn_mask |= 2, &cpureg->rstoutn_mask);
> + hw_watchdog_reset();
> +
> + /* Enable the watchdog */
> + cntmrctrl = readl(CNTMR_CTRL_REG);
> + cntmrctrl |= CTCR_ARM_TIMER_EN(WATCHDOG_TMR);
> + cntmrctrl |= CTCR_ARM_TIMER_AUTO_EN(WATCHDOG_TMR);
> + writel(cntmrctrl, CNTMR_CTRL_REG);
> +
> + return 0;
> +}
> +#endif
> --
> 1.6.0.4
Ack
Regards..
Prafulla . .
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
Copying Tom I will replay latter Regards.. Prafulla . . > -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Saturday, October 31, 2009 2:42 PM > To: u-boot@lists.denx.de > Cc: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar > Subject: Best way of making some drivers common across > kirkwood and orion5x SoCs? > > Hi, > > I am working on adding mainline support for Orion5x family of Marvell > SoCs in U-boot, based on the Kirkwood support already present. > > I believe these are different enough families to justify adding an > 'orion5x' SoC along the existing 'kirkwood' one. > > Several kirkwood drivers could actually be reused almost as-is and > should thus be shared between both SoC families. For instance, > kirkwood_egiga.c and ehci-kirkwood.c would only differ by the > number of > ports and kirkwood_i2c.c could be reused as-is. > > However, these drivers have hard-coded numbers of ports, and 'hard' > references to 'kirkwood.h' for their register definitions. > Making them > cross-SoC would require moving the numbers of ports to some > SoC-specific > header file, and that this header file *not* be named after a > specific SoC. > > I've searched for a layer between CPU and Core where cross-SoC code > could fit, but I haven't seen one, and I don't think one > would be needed. > > Instead, I have thought of replacing the #include "kirkwood.h" with a > #include "soc.h", where soc.h would exist in both SoC's header files > include/asm-arm/arch-kirkwood and include/asm-arm/arch-orion5x. This > soc.h file would either include the specific soc header file > (kirkwood.h > or orion5x.h) or, better yet, be a symlink to it, or better again, > replace it. > > This could be done in a two-step approach, each step being one commit. > > 1) introduce "soc.h" by: > > - 1a) renaming, symlinking or including kirkwood.h into soc.h and > changing kirkwood drivers that #include "kirkwood.h" accordingly; > > - 1b) turning all kirkwood-specific namings in these kirkwood drivers > into marvell-non-soc-specific ones (remove "KW_" prefixes and such). > > (steps 1a and 1b are independent) > > 2) add orion5x support with its own "soc.h" file. > > Would this approach be clean enough to be considered for inclusion in > mainline? > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
Hi Albert > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD > Sent: Saturday, October 31, 2009 8:42 PM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood and orion5x SoCs? > > Wolfgang Denk a écrit : > > > "soc.h" is eventually a too generic name. > > I'd actually chosen it "as generic as" the 'cpu.h' file which already > exists in the kirkwood arch (and others), but making it more > specific is > ok, as long as it is not as specific as 'kirkwood' -- see > below for an > alternate proposal. Anything inside "Kirkwood" folder is Kirkwood specific, that applies for cpu.c/h. There is no sense to keep soc.h in SOC specific folders. If we are keeping it in Arch specific folder then it is applicable for all other SOCs too. > > > Please don't use symlinks. > > I've already started with replacing the file rather than > symlinking, so > that's fine with me. I fully ack with NOT to use symlinks > > >> Would this approach be clean enough to be considered for > inclusion > in mainline? > > > > Yes, except for the "soc.h" name. And no links, please. > > Would a name such as "marvell.h" be more acceptable? This would be > consistent with my intent to replace kirkwood references with marvell > ones in all non-kirkwood-specific symbols, e.g. > kikwood_egiga_initialize > would become marvell_egiga_initialize etc. I disagree with this, - marvell.h is again more generic name applicable for all other Marvell IPs that May not be the same on other SOCs unless we call them with specific names. The name kirkwood_egiga.c/h clearly specifies it is for kirkwood. If it can be used as it is, well there are no issues. We can tune it to address Orion issues if any so that kirkwood/orion can be supported though clean abstraction. Otherwise I would always prefer to have separate driver (for ex. Orion_egiga.c/h). Regards.. Prafulla . . > > Amicalement, > -- > Albert. > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
Dear Albert > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD > Sent: Sunday, November 01, 2009 6:30 AM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood and orion5x SoCs? > > Wolfgang Denk a écrit : > > Dear Albert ARIBAUD, > > > > In message <4aec53db.6050...@free.fr> you wrote: > >> Would a name such as "marvell.h" be more acceptable? This would be > > > > Hm... I expect there will be little chance to see MAarvell IP blocks > > in non-Marvell SoCs, so this should work indeed. On the other hand, > > why not chose a name that works for other CPUs / SoCs as > well. [So on > > second thought maybe your "soc.h" was not that bad a name.] > > > > Let's see what others suggest. I propose the following strategy for this- For orion- let's follow the standard development strategy used for ARM architectures including Kirkwood. Since orion and kirkwood has lot of similarities but when both these will evolve for there entire supports there will be problems resulting code complexity. So My suggestion is- let's develop orion as separate ARM SOC family as kirkwood. Some of Kirkwood drivers can be directly used with Orion, that can be addressed through makefiles as we used NS16550 Serial support in Kirkwood. SOC specific configuration in the common drivers (for ex. Egiga) can always be addressed through individual > > While we wait for others' opinion, one quick question: do you > prefer me > to submit this rework of the Marvell IP/drivers as individual patches, > one for each IP/driver, or as a single patch for the whole rework? It is always better to break down the entire work in the small pieces, it's easier to digest them faster :-) Regards.. Prafulla . . > > Amicalement, > -- > Albert. > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, November 02, 2009 3:34 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Tom > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood and orion5x SoCs? > > Prafulla Wadaskar a écrit : > > > Dear Albert > > > > I propose the following strategy for this- For orion- let's follow > > the standard development strategy used for ARM architectures > > including Kirkwood. Since orion and kirkwood has lot of similarities > > but when both these will evolve for there entire supports there will > > be problems resulting code complexity. > > > > So My suggestion is- let's develop orion as separate ARM SOC family > > as kirkwood. > > This is what I intend to do, so that's fine with me. > > > Some of Kirkwood drivers can be directly used with Orion, > that can be > > addressed through makefiles as we used NS16550 Serial support in > > Kirkwood. SOC specific configuration in the common drivers (for ex. > > Egiga) can always be addressed through individual > > Agreed on reusing the drivers; again, that is what I intend to do. > > Thus the only issue left is that the shared drivers (egiga, ehci, I2C, > gpio and, to a lesser extent, serial) #include the kirkwood.h file and > use kirkwood-defined symbols (e.g. KW_UART0_BASE) which ties > them to the > kirkwood soc -- purely syntactically, as these symbols for > the most part > are not actually kirkwood-specific. > > The #include part I can handle with something like > > #if defined (CONFIG_KIRKWOOD) > #include > #elif defined (CONFIG_ORION5X) > #include > #else > #error egiga.c needs either CONFIG_KIRKWOOD or CONFIG_ORION5X. > #endif This is correct approach. > > in each driver, so yes, I can live without the 'soc.h' file renaming. With above reference, you should be, because it will come from include/asm/arch-/ that will be different in both the cases. > > Still, the drivers would be full of 'KWxxx" and "kwxxx" > symbols of which > many are not kirkwood-specific actually. Any way, those are not even orion specific nor Marvell specific. Those are related to the functionality supported by SOCs that may be customized by each SOC > In order for these drivers to > compile with an orion5x SoC, I would have to adopt kirkwood > names in the What harm in this? > orion5x code, which I don't like as much as I would like fixing the If you see kernel code even there you can see kirkwood call from Orion drivers and vice versa. > symbols to make them marvell-, not kirkwood-, specific. This will not solve the root problem, what about some non marvell SoC have same h/w and want to reuse the code? Do we again change the suffixes? (kirkwood re-used external serial driver adopting external definitions). I suggest here to adopt kw symbols in Orion. This would make it clear for anybody that kirkwood code is reused by orion. With this kirkwood drives will be untouched. While doing this reuse activity, if we find something blocking, certainly we should address that, but let's avoid changing identity of drivers. Regards.. Prafulla . . > > Note that such fixing is rather trivial (tens of lines in the source > code, basically search and replace) and binary-invariant (I > have patches > for these already that I can post for review upon request). > > > It is always better to break down the entire work in the small > > pieces, it's easier to digest them faster :-) > > Fine! > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2]: common: Add a watchdog CLI command
> -Original Message-
> From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net]
> Sent: Friday, November 06, 2009 2:58 PM
> To: U-Boot ML; Wolfgang Denk
> Cc: Prafulla Wadaskar
> Subject: Re: [PATCH v2 1/2]: common: Add a watchdog CLI command
>
> (Ping!)
>
> On Thu, 29 Oct 2009 09:09:23 +0100
> Simon Kagstrom wrote:
>
> > A watchdog command to enable the watchdog with a timeout
> from the CLI
> > can sometimes be useful. Add that. This also adds a common API for
> > enabling watchdogs. The API is simple:
> >
> > int watchdog_enable(unsigned int timeout);
> >
> > the timeout range vary depending on hardware, and the driver should
> > return a negative value if the call failed.
>
> Wolfgang: Do you have any additional comments on this patch?
>
> // Simon
>
> > Signed-off-by: Simon Kagstrom
> > ---
> > ChangeLog:
> > v2:
> > * Passing zero as timeout is invalid (Prafulla)
> > * Add return value from watchdog_enable(), negative
> means failure (Prafulla, Wolfgang)
> > * Remove watchdog_disable() (Wolfgang)
> > * Use weak default function for watchdog_enable() (Wolfgang)
> > * Provide friendly and helpful printouts when invalid
> parameters are
> > passed to the CLI command
> >
> > common/Makefile |1 +
> > common/cmd_watchdog.c | 62
> +
> > common/main.c |7 +
> > include/watchdog.h|2 +
> > 4 files changed, 72 insertions(+), 0 deletions(-)
> > create mode 100644 common/cmd_watchdog.c
> >
> > diff --git a/common/Makefile b/common/Makefile
> > index 3781738..f14ba0e 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -160,6 +160,7 @@ COBJS-$(CONFIG_LYNXKDI) += lynxkdi.o
> > COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
> > COBJS-$(CONFIG_UPDATE_TFTP) += update.o
> > COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
> > +COBJS-$(CONFIG_CMD_WATCHDOG) += cmd_watchdog.o
> >
> >
> > COBJS := $(sort $(COBJS-y))
> > diff --git a/common/cmd_watchdog.c b/common/cmd_watchdog.c
> > new file mode 100644
> > index 000..ca1a8fd
> > --- /dev/null
> > +++ b/common/cmd_watchdog.c
> > @@ -0,0 +1,62 @@
> > +/*
> > + * (C) Copyright 2009
> > + * Net Insight
> > + * Written-by: Simon Kagstrom
> > + *
> > + * 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., 51 Franklin Street, Fifth Floor, Boston,
> > + * MA 02110-1301 USA
> > + */
> > +
> > +#include
> > +#include
> > +
> > +static int do_watchdog(cmd_tbl_t *cmdtp, int flag, int
> argc, char *argv[])
> > +{
> > + const char *cmd;
> > + char *endp;
> > + unsigned long timeout;
> > +
> > + /* need one argument */
> > + if (argc != 2)
> > + goto usage;
> > +
> > + cmd = argv[1];
> > + timeout = simple_strtoul(cmd, &endp, 0);
> > + if (endp == cmd) {
> > + printf("Error: Could not convert `%s' to a
> number\n\n", cmd);
> > + goto usage;
> > + }
> > + if (timeout < 1) {
> > + printf("Error: zero timeouts are invalid\n\n");
> > + goto usage;
> > + }
> > +
> > + /* Everything fine, enable the watchdog */
> > + if (watchdog_enable(timeout) < 0) {
> > + printf("Error: Could not enable watchdog, check
> timeout parameter\n\n");
> > + goto usage;
> > + }
> > +
> > + return 0;
> > +usage:
> > + cmd_usage(cmdtp);
> > + return 1;
> > +}
> > +
> > +U_BOOT_CMD(
> > + watchdog, 2, 0, do_watchdog,
> > + "Watchdog commands",
> > + " - start the watchdog with `timeout'
> seconds timeout\n"
>
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
Dear Albert > -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, November 02, 2009 5:46 PM > To: Prafulla Wadaskar > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood and orion5x SoCs? > > Prafulla Wadaskar a écrit : > > > >> Still, the drivers would be full of 'KWxxx" and "kwxxx" symbols of > >> which many are not kirkwood-specific actually. > > > > Any way, those are not even orion specific nor Marvell specific. > > Those are related to the functionality supported by SOCs that may be > > customized by each SOC > > > >> In order for these drivers to compile with an orion5x SoC, I would > >> have to adopt kirkwood names in the > > > > What harm in this? > > I would say it harms maintenability and reuseability of the code. If > those drivers are neither kirkwood- nor even > marvell-specific, then they > should not lead readers to believe they are, otherwise people > might not > realize they can ruse these drivers in their own SoCs. > > >> orion5x code, which I don't like as much as I would like fixing the > >> > > If you see kernel code even there you can see kirkwood call from > > Orion drivers and vice versa. > > > >> symbols to make them marvell-, not kirkwood-, specific. > > > > This will not solve the root problem, what about some non > marvell SoC > > have same h/w and want to reuse the code? Do we again change the > > suffixes? (kirkwood re-used external serial driver adopting external > > definitions). > > Point valid and taken--see my suggestion below. > > > I suggest here to adopt kw symbols in Orion. This would > make it clear > > for anybody that kirkwood code is reused by orion. With > this kirkwood > > drives will be untouched. > > This does not solve the root problem any better than switching to > Marvell prefixes, as you rightly point out. I thus suggest > removing any > Marvell, Kirkwood or Orion prefixes from symbols in these drivers > altogether. For instance, egiga symbols would take EGIGA_ as > a prefix. > Then each SoC (kirkwood, orion5x, any other) header file > would provide > adequate definitions (#define EGIGA_ ). I understands your concerns- 1. For SOC support Orion should be implemented similar to Kirkwood (you agreed on this) 2. For common drivers for (ex: kirkwood_egiga.c) the common code must be abstracted to egiga_core.c and architecture specific code must be supported through kirkwood_egiga.c/h and orion_egiga.c/h, this way it would make it more clean and structured. > > > While doing this reuse activity, if we find something blocking, > > certainly we should address that, but let's avoid changing identity > > of drivers. > > I personally believe that having the Orion5x SoC dependent of the > kirkwood one is blocking enough from a design standpoint. What is your opinion with #2 suggestion? Regards.. Prafulla . . > > > Regards.. Prafulla . . > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Tuesday, November 10, 2009 12:27 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] Best way of making some drivers common
> across kirkwood and orion5x SoCs?
>
> Hi PRafulla,
>
> Prafulla Wadaskar a écrit :
>
> > 1. For SOC support Orion should be implemented similar to Kirkwood
> > (you agreed on this)
>
> I still do. :)
>
> > 2. For common drivers for (ex: kirkwood_egiga.c) the
> common code must
> > be abstracted to egiga_core.c and architecture specific
> code must be
> > supported through kirkwood_egiga.c/h and orion_egiga.c/h,
> this way it
> > would make it more clean and structured.
>
> Agreed.
>
> > What is your opinion with #2 suggestion?
>
> Sounds fine! I'll start submitting patches for both common
> drivers and
> orion support based on this proposal.
>
> Regarding the arch-specific parts of current driver code, should they
> end up in cpu/arm926ejs/{kirkwood,orion5x} or stay in
> drivers/*? I tend
> like cpu/arm926ejs/* better as it puts everything arch-specific in a
> single place.
I agree for this. Good luck :-)
Regards...
Prafulla . . .
>
> Amicalement,
> --
> Albert.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Initial support for Orion5x SoC and EDMini board
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Saturday, November 14, 2009 2:53 PM
> To: Prafulla Wadaskar
> Cc: U-Boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH] Initial support for Orion5x SoC
> and EDMini board
>
> Hi Prafulla and all,
>
> Prafulla Wadaskar a écrit :
> >
> >> -Original Message-
> >> From: u-boot-boun...@lists.denx.de
> >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> >> Sent: Saturday, November 14, 2009 6:32 AM
> >> To: U-Boot@lists.denx.de
> >> Subject: [U-Boot] [PATCH] Initial support for Orion5x SoC and
> >> EDMini board
> >>
> >> This patch adds initial u-boot support for the Marvell orion5x
> >> SoC and the LAcie ED Mini V2 board--support is limited to serial,
> >> flash and environment. Further support will be added as devices
> >> common with kirkwood are made useable across SoCs.
> >>
> >> Signed-off-by: Albert Aribaud
> >> ---
> >
> > Hi Albert
> >
> > Please break this patch in to small pieces
> > [...]
> > Pls edit MAKEALL and Maintainers files too for new board support
> > [...]
> > Arm: add Edminv2 board support (orion5x based)
>
> Ok.
>
> > Break this in to basic orion5x Soc support patch
> > And individual drivers patches like gpio, uart, etc..
>
> Will do. What exact criteria should I use for splitting patches?
> Obviously some patches will never be compiled alone, e.g.
> basic Orion5x
> support won't be compiled until board support patches come in; also,
> having SoC and board support without uart support, if it even
> compiles,
> will be pretty useless as the resulting u-boot won't even
> have a console.
It should be patch series with properly addressed dependencies
i.e.
(1/4)basic orion soc support patch
(2/4)orion gpio driver
(3/4)orion UART support
(4/4) Board support patch
All patches when applied in series should build u-boot for respective board.
The spilt has to be done carefully because individual patch may be applied to
different repositories,
like nandf to u-boot-nand.git, basic orion support to u-boot-marvell.git, egiga
driver patch will go in u-boot-net.git etc
> >> +TEXT_BASE = 0x0060
> >
> > Is this valid for your board? BTW: how much DRAM you have
> on this board?
>
> Yes it works for the board--I'm using this value for testing.
> However,
> in very old and non-reuseable u-boot code, it was 0x00F0. I'll
> switch to this in order to minimize the difference between
> these older
> u-boots and the current mainline one.
I will suggest to use lower part of available ram for this
> >> diff --git a/cpu/arm926ejs/orion5x/Makefile
> >> [...]
> >> +COBJS-y = dram.o
> >> +COBJS-y += cpu.o
> >
> > Pls put these lines in order
>
> Ok. Note this comes directly from kirkwood's Makefile, so the
> lines are
Thanks , I will provide separate patch for this
>
> >> + if (dev == MV88F5181_DEV_ID) {
> >> + dev_name = "MV88F5181";
> >> + if (rev == MV88F5181_REV_B1) {
> >> + rev_name = "B1";
> >> + } else if (rev == MV88F5181L_REV_A1) {
> >> + dev_name = "MV88F5181L";
> >> + rev_name = "A1";
> >> + } else if (rev == MV88F5181L_REV_A0) {
> >> + dev_name = "MV88F5181L";
> >> + rev_name = "A0";
> >> + } else {
> >> + sprintf(rev_str,"0x%02x", rev);
> >> + }
> >> + } else if (dev == MV88F5182_DEV_ID) {
> >> + dev_name = "MV88F5182";
> >> + if (rev == MV88F5182_REV_A2) {
> >> + rev_name = "A2";
> >> + } else {
> >> + sprintf(rev_str,"0x%02x", rev);
> >> + }
> >> + } else if (dev == MV88F5281_DEV_ID) {
> >> + dev_name = "MV88F5281";
> >> + if (rev == MV88F5281_REV_D2) {
> >> + rev_name = "D2";
> >> + } else if (rev == MV88F5281_REV_D1) {
> >> + rev_name = "D1";
> >> + } else if (rev == MV88F5281_REV_D0) {
> >> + rev_name = "D0";
> >
[U-Boot] [PATCH] Kirkwood: Makefile cleanup- fixed ordering (cosmetic change)
As per coding guidlines, it is good to maintain proper ordering in the makefiles. This was missed during initial coding, corrected here. This was discovered during orion5x code review Thanks to Albert Aribaud for this. Signed-off-by: Prafulla Wadaskar --- cpu/arm926ejs/kirkwood/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/arm926ejs/kirkwood/Makefile b/cpu/arm926ejs/kirkwood/Makefile index d73e210..fc2cc03 100644 --- a/cpu/arm926ejs/kirkwood/Makefile +++ b/cpu/arm926ejs/kirkwood/Makefile @@ -26,8 +26,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).a -COBJS-y= dram.o -COBJS-y+= cpu.o +COBJS-y= cpu.o +COBJS-y+= dram.o COBJS-y+= mpp.o COBJS-y+= timer.o -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support for Marvell Orion5x SoC
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Sunday, November 15, 2009 1:27 PM > To: U-Boot@lists.denx.de > Subject: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support > for Marvell Orion5x SoC > > ** ATTENTION: this patch supersedes the previous '1/3' patch in > the same series. The correction is the removal of Kirkwood-inherited > device init code unused at the moment and partly inapplicable to > Orion5x anyway. This correct patch has been run through checkpatch.pl > again with the exact same result as its predecessor (6 false pos). > > Sorry for the inconvenience. Please post this patch as v3 with above description as change log for v3 Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED Mini V2 board
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Sunday, November 15, 2009 4:33 AM > To: U-Boot@lists.denx.de > Subject: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED > Mini V2 board > > This board is based on the Marvell Orion5x SoC. > Current support is limited to console and Flash. > Flash support uses LEGACY as the Macronix 29LV400 > used on ED Mini V2 is not 100% CFI compliant. > > Signed-off-by: Albert Aribaud > --- > MAINTAINERS |4 + > MAKEALL |1 + > Makefile|3 + > board/LaCie/edminiv2/Makefile | 54 +++ > board/LaCie/edminiv2/config.mk | 27 +++ > board/LaCie/edminiv2/edminiv2.c | 134 > > board/LaCie/edminiv2/edminiv2.h | 43 > include/configs/edminiv2.h | 143 > +++ > 8 files changed, 409 insertions(+), 0 deletions(-) > create mode 100644 board/LaCie/edminiv2/Makefile > create mode 100644 board/LaCie/edminiv2/config.mk > create mode 100644 board/LaCie/edminiv2/edminiv2.c > create mode 100644 board/LaCie/edminiv2/edminiv2.h > create mode 100644 include/configs/edminiv2.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index d70a9d2..93e57f5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -512,6 +512,10 @@ Unknown / orphaned boards: > #Board CPU > # > > ## > ### > > +Albert ARIBAUD > + > + edminiv2ARM926EJS (Orion5x SoC) > + That's good if you can move this entry above Albin Tonnerre's entry ...snip... > + MPP17_GPIO, > + MPP18_GPIO, > + MPP19_GPIO, Why not configured rest 6 gpios ? ...snip... > + > +/* > + * GPIOs for LaCie ED Mini: > + * GPIO3 is input (RTC interrupt) > + * GPIO16 is Power LED control (0 = on, 1 = off) > + * GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16) > + * GPIO18 is Power Button status (0 = Released, 1 = Pressed) > + * > + * Default is LED ON > + */ > + > +#define EDMINIV2_OE 0xfffc > +#define EDMINIV2_OE_VAL 0x0002 How about adding GPIO_OE? This settings are referred to GPIOs register ...snip... > +#define CONFIG_IDENT_STRING " EDMiniV2" > + > +/* > + * High Level Configuration Options (easy to change) > + */ > +#define CONFIG_MARVELL 1 > +#define CONFIG_ARM926EJS 1 /* Basic Architecture */ > +#define CONFIG_FEROCEON 1 /* CPU Core > subversion */ > +#define CONFIG_ORION5X 1 /* SOC Family Name */ > +#define CONFIG_88F5182 1 /* SOC Name */ > +#define CONFIG_MACH_EDMINIV2 1 /* Machine type */ > + > +#define CONFIG_SKIP_LOWLEVEL_INIT/* disable board > lowlevel_init */ How you are addressing DRAM configuration? I think you need lowlevel_init. ...snip... > +/* > + * Environment variables configurations > + */ > +#define CONFIG_ENV_IS_IN_FLASH 1 > +#define CONFIG_ENV_SECT_SIZE 0x2000 /* 16K */ > +#define CONFIG_ENV_SIZE 0x2000 > +#define CONFIG_ENV_OFFSET0x4000 /* env starts here */ I don't know how this is going to work, how much flash do you have? I hope it is mapped in the end since your reset address is 0x. Where is the code to fetch flashed image from flash to DRAM at TEXT_BASE? I suggest you provide some more details about your board in the commit log > + > +/* > + * Size of malloc() pool > + */ > +#define CONFIG_SYS_MALLOC_LEN(1024 * 128) /* 128kB > for malloc() */ > +/* size in bytes reserved for initial data */ > +#define CONFIG_SYS_GBL_DATA_SIZE 128 > + > +/* > + * Other required minimal configurations > + */ > +#define CONFIG_CONSOLE_INFO_QUIET/* some code reduction */ > +#define CONFIG_ARCH_CPU_INIT /* call arch_cpu_init() */ > +#define CONFIG_ARCH_MISC_INIT/* call arch_misc_init() */ > +#define CONFIG_DISPLAY_CPUINFO /* Display cpu info */ > +#define CONFIG_NR_DRAM_BANKS 4 > +#define CONFIG_STACKSIZE 0x0010 /* regular stack- 1M */ > +#define CONFIG_SYS_LOAD_ADDR 0x0080 /* default load > adr- 8M */ > +#define CONFIG_SYS_MEMTEST_START 0x0040 /* 4M */ > +#define CONFIG_SYS_MEMTEST_END 0x007f /*(_8M -1) */ > +#define CONFIG_SYS_RESET_ADDRESS 0x /* Rst Vector Adr */ Same comment applies here Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial support for Marvell Orion5x SoC
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, November 16, 2009 2:52 PM > To: Prafulla Wadaskar > Cc: U-Boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH V2 1/3 CORRECTED] Initial > support for Marvell Orion5x SoC > > Hi Rafulla, > > Prafulla Wadaskar a écrit : > > > > Please post this patch as v3 with above description as > change log for v3 > > > > Regards.. > > Prafulla . . . > > Seeing as I have also some fixes to do on patch V2 3/3, I'll > report a > whole V3 patch set with the description in the cover letter. > Is that fine? Change log is important to understand reviewers and other community friends to understand the history of the patch. In each patch you should maintain change log after line containing "---" when patch will be applied, only commit log will be considered. So please segregate your information carefully. Cover letter is optional, you better put enough information in the commit log relevant to patch Regards.. Prafulla . . > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC/PATCH 1/2]: Arm: Kirkwood: Split PHY-related initialization to a common file
> -Original Message- > From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] > Sent: Monday, November 23, 2009 1:04 PM > To: Wolfgang Denk > Cc: Ben Warren; U-Boot ML; Prafulla Wadaskar > Subject: Re: [U-Boot] [RFC/PATCH 1/2]: Arm: Kirkwood: Split > PHY-related initialization to a common file > > On Sun, 22 Nov 2009 21:57:05 +0100 > Wolfgang Denk wrote: > > > > In message <20090713131125.6e6a3...@marrow.netinsight.se> > Simon Kagstrom wrote: > > > > The mv881116 PHY initialization is split out to a > common file to enable > > > > code reuse between different boards. > > > > > > > > Signed-off-by: Simon Kagstrom > > > > --- > > > > board/Marvell/sheevaplug/sheevaplug.c | 32 +-- > > > > board/Marvell/sheevaplug/sheevaplug.h |8 > > > > drivers/net/phy/Makefile |1 + > > > > drivers/net/phy/mv88e1116.c | 66 > + > > > > include/configs/sheevaplug.h |1 + > > > > include/mv88e1116.h | 29 ++ > > > > 6 files changed, 100 insertions(+), 37 deletions(-) > > > > create mode 100644 drivers/net/phy/mv88e1116.c > > > > create mode 100644 include/mv88e1116.h > > > > > > Ping... > > > > Can you please check the status of this patch: > > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63590/f > ocus=63591 > > I believe Prafulla voted to keep the PHY stuff locally in sheevaplug.c > and openrd_base.c until the generic PHY support was added. So I later > submitted a patch with the PHY init for OpenRD base in the board-file > (like sheevaplug). > > So I think this patch should simply be dropped - code reuse > will happen > in a more generic way later anyway. Perhaps you have some additional > comments, Prafulla? I think we should port it in generic way, because there are numerous board in pipeline which will have to use similar support and there will be code duplication. If I remember correctly, Jean has also put some efforts in this direction. This is call for Ben Hi Ben and Jean Is Generic PHY arch is ready to use (even though in bits and patches)? Can we start migrating Marvell Switch/PHY devices for the same? Regards.. Prafulla . . > > // Simon > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] Initial support for Marvell Orion5x SoC
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Saturday, December 05, 2009 6:08 AM > To: Albert ARIBAUD > Cc: U-Boot@lists.denx.de; Prafulla Wadaskar > Subject: Re: [U-Boot] [PATCH V2 1/3] Initial support for > Marvell Orion5x SoC > > Dear Albert ARIBAUD, > > In message <4b1236f3.4010...@free.fr> you wrote: > > > > These files are derived from their kirkwood counterparts, > which are GPL > > v2 only, so I don't have the right to simply change that to > "v2 or any > > later version", I believe, unless the originals' copyright > owner allows > > it (and possibly even fixes the originals). Prafulla, would > you ACK this? Ack > > Indeed. These files need to be fixed ASAP, too: > > drivers/gpio/kw_gpio.c > drivers/i2c/kirkwood_i2c.c > include/asm-arm/arch-kirkwood/gpio.h > include/asm-arm/arch-kirkwood/mpp.h In the kirkwood port these files are Imported from Linux kernel source, I will request the respective writers to update to latest GPL license. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/3] Add support for the LaCie ED Mini V2 board
Hi Albert
First of all I am very sorry for the late feedback
Pls find my comments in lined.
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Wednesday, December 02, 2009 1:57 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH V3 3/3] Add support for the LaCie ED
> Mini V2 board
>
> This patch adds support for the LaCie ED Mini V2 product
> which is based on the Marvell Orion5x SoC.
> Current support is limited to console and Flash.
> Flash support uses LEGACY as the Macronix 29LV400
> used on ED Mini V2 is not 100% CFI compliant.
>
> Signed-off-by: Albert Aribaud
> ---
History for earlier versions (including this) is not captured here as change log
> MAINTAINERS |4 +
> MAKEALL |1 +
> Makefile |3 +
> board/LaCie/edminiv2/Makefile| 58 ++
> board/LaCie/edminiv2/config.mk | 27 +++
> board/LaCie/edminiv2/edminiv2.c | 100 +++
> board/LaCie/edminiv2/edminiv2.h | 59 ++
> board/LaCie/edminiv2/lowlevel_init.S | 324
> ++
> include/configs/edminiv2.h | 148
> 9 files changed, 724 insertions(+), 0 deletions(-)
> create mode 100644 board/LaCie/edminiv2/Makefile
> create mode 100644 board/LaCie/edminiv2/config.mk
> create mode 100644 board/LaCie/edminiv2/edminiv2.c
> create mode 100644 board/LaCie/edminiv2/edminiv2.h
> create mode 100644 board/LaCie/edminiv2/lowlevel_init.S
> create mode 100644 include/configs/edminiv2.h
>
...snip...
> diff --git a/board/LaCie/edminiv2/config.mk
> b/board/LaCie/edminiv2/config.mk
> new file mode 100644
> index 000..e2477c9
> --- /dev/null
> +++ b/board/LaCie/edminiv2/config.mk
> @@ -0,0 +1,27 @@
> +#
> +# Copyright (C) 2009 Albert ARIBAUD
> +#
> +# (C) Copyright 2009
> +# Marvell Semiconductor
> +# Written-by: Prafulla Wadaskar
> +#
> +# 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., 51 Franklin Street, Fifth Floor, Boston,
> +# MA 02110-1301 USA
> +#
> +
> +TEXT_BASE = 0x0060
Can you pls us a smaller value here, that will offer more continues memory for
applications
> diff --git a/board/LaCie/edminiv2/edminiv2.c
> b/board/LaCie/edminiv2/edminiv2.c
> new file mode 100644
> index 000..31ecb11
> --- /dev/null
> +++ b/board/LaCie/edminiv2/edminiv2.c
> @@ -0,0 +1,100 @@
> +/*
> + * Copyright (C) 2009 Albert ARIBAUD
> + *
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wadaskar
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include "edminiv2.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * The ED Mini V2 is equipped with a Macronix MXLV400CB FLASH
> + * which CFI does not properly detect, hence the LEGACY config.
> + */
> +#if defined(CONFIG_FLASH_CFI_LEGACY)
> +#include
> +ulong board_flash_get_legacy(ulong base, int banknum,
> flash_info_t *info)
> +{
> + int sectsz[] = CONFIG_SYS_FLASH_SECTSZ;
> +
Re: [U-Boot] [PATCH V3 1/3] Initial support for Marvell Orion5x SoC
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Wednesday, December 02, 2009 1:57 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH V3 1/3] Initial support for Marvell
> Orion5x SoC
>
> This patch adds support for the Marvell Orion5x SoC.
> It has no use alone, and must be followed by a patch
> to add Orion5x support for serial, then support for
> the ED Mini V2, an Orion5x-based product from LaCie.
>
> Signed-off-by: Albert Aribaud
> ---
> V1 of the patch was monolithic
>
> V2 contains a number of fixes as a result of the V1 review,
> and notably:
> - is split in three patches : orion, serial, edmini;
> - has been checkpatch'ed, with only 6 errors, in patch 1/3,
> all 6 errors being false positives.
>
> V3 contains yet several fixes as a result of the V2 review,
> and notably:
> - removes most of the GPIO and MPP programming support;
> - adds low level init and removes CONFIG_SKIP_LOW_LEVEL_INIT.
>
> cpu/arm926ejs/orion5x/Makefile | 51 ++
> cpu/arm926ejs/orion5x/cpu.c | 258
> ++
> cpu/arm926ejs/orion5x/dram.c | 61 +++
> cpu/arm926ejs/orion5x/timer.c| 181 +
> include/asm-arm/arch-orion5x/cpu.h | 205
>
> include/asm-arm/arch-orion5x/mv88f5182.h | 40 +
> include/asm-arm/arch-orion5x/orion5x.h | 65
> 7 files changed, 861 insertions(+), 0 deletions(-)
> create mode 100644 cpu/arm926ejs/orion5x/Makefile
> create mode 100644 cpu/arm926ejs/orion5x/cpu.c
> create mode 100644 cpu/arm926ejs/orion5x/dram.c
> create mode 100644 cpu/arm926ejs/orion5x/timer.c
> create mode 100644 include/asm-arm/arch-orion5x/cpu.h
> create mode 100644 include/asm-arm/arch-orion5x/mv88f5182.h
> create mode 100644 include/asm-arm/arch-orion5x/orion5x.h
>
...snip...
> diff --git a/cpu/arm926ejs/orion5x/cpu.c b/cpu/arm926ejs/orion5x/cpu.c
> new file mode 100644
> index 000..deebf24
> --- /dev/null
> +++ b/cpu/arm926ejs/orion5x/cpu.c
> @@ -0,0 +1,258 @@
> +/*
> + * Copyright (C) 2009 Albert ARIBAUD
> + *
> + * Based on original Kirkwood support which is
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wadaskar
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BUFLEN 16
> +
> +void reset_cpu(unsigned long ignored)
> +{
> + struct orion5x_cpu_registers *cpureg =
> + (struct orion5x_cpu_registers *)ORION5X_CPU_REG_BASE;
> +
> + writel(readl(&cpureg->rstoutn_mask) | (1 << 2),
> + &cpureg->rstoutn_mask);
> + writel(readl(&cpureg->sys_soft_rst) | 1,
> + &cpureg->sys_soft_rst);
> + while (1)
> + ;
> +}
> +
> +/*
> + * Window Size
> + * Used with the Base register to set the address window
> size and location.
> + * Must be programmed from LSB to MSB as sequence of ones followed by
> + * sequence of zeros. The number of ones specifies the size
> of the window in
> + * 64 KByte granularity (e.g., a value of 0x00FF specifies
> 256 = 16 MByte).
> + * NOTE: A value of 0x0 specifies 64-KByte size.
> + */
Any data sheet reference for this description?
> +unsigned int orion5x_winctrl_calcsize(unsigned int sizeval)
> +{
> + int i;
> + unsigned int j = 0;
> + u32 val = sizeval >> 1;
> +
> + for (i = 0; val > 0x1; i++) {
> + j |= (1 << i);
> + val = val >> 1;
> + }
> + return 0x & j;
> +}
> +
> +/*
> + * orion5x_config_adr_windows - Configure address Windows
> + *
> + * The
Re: [U-Boot] [PATCH V2 1/3] Initial support for Marvell Orion5x SoC
> -Original Message- > From: Prafulla Wadaskar > Sent: Wednesday, December 23, 2009 11:32 AM > To: 'Wolfgang Denk'; Albert ARIBAUD > Cc: U-Boot@lists.denx.de > Subject: RE: [U-Boot] [PATCH V2 1/3] Initial support for > Marvell Orion5x SoC > > > > > -Original Message- > > From: Wolfgang Denk [mailto:w...@denx.de] > > Sent: Saturday, December 05, 2009 6:08 AM > > To: Albert ARIBAUD > > Cc: U-Boot@lists.denx.de; Prafulla Wadaskar > > Subject: Re: [U-Boot] [PATCH V2 1/3] Initial support for > > Marvell Orion5x SoC > > > > Dear Albert ARIBAUD, > > > > In message <4b1236f3.4010...@free.fr> you wrote: > > > > > > These files are derived from their kirkwood counterparts, > > which are GPL > > > v2 only, so I don't have the right to simply change that to > > "v2 or any > > > later version", I believe, unless the originals' copyright > > owner allows > > > it (and possibly even fixes the originals). Prafulla, would > > you ACK this? > > Ack > > > > > Indeed. These files need to be fixed ASAP, too: > > > > drivers/gpio/kw_gpio.c > > drivers/i2c/kirkwood_i2c.c > > include/asm-arm/arch-kirkwood/gpio.h > > include/asm-arm/arch-kirkwood/mpp.h > > In the kirkwood port these files are > Imported from Linux kernel source, > I will request the respective writers to update to latest GPL license. I got a GREEN flag from respective owners, we can update these files for GPL v2, I will send the patch soon. Hi Albert, you also take care of the same in your patches Regards.. Prafulla . . > > Regards.. > Prafulla . . > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Kirkwood: Updated licencing to GPLv2 or later
These are few files directly imported from Linux kernel source. These files contains source with GPLv2 only whereas u-boot expects GPLv2 or latter These files are updated for the same with prior permission from original writer Acked-by: Nicolas Pitre Signed-off-by: Prafulla Wadaskar --- drivers/gpio/kw_gpio.c | 20 +--- drivers/i2c/kirkwood_i2c.c | 23 ++- include/asm-arm/arch-kirkwood/gpio.h | 20 +--- include/asm-arm/arch-kirkwood/mpp.h | 20 +--- 4 files changed, 69 insertions(+), 14 deletions(-) diff --git a/drivers/gpio/kw_gpio.c b/drivers/gpio/kw_gpio.c index 1c28834..56383c2 100644 --- a/drivers/gpio/kw_gpio.c +++ b/drivers/gpio/kw_gpio.c @@ -3,9 +3,23 @@ * * Marvell Orion SoC GPIO handling. * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. + * 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA */ /* diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/kirkwood_i2c.c index 37b7d99..a4409be 100644 --- a/drivers/i2c/kirkwood_i2c.c +++ b/drivers/i2c/kirkwood_i2c.c @@ -5,16 +5,29 @@ * * Based on: * Author: Mark A. Greer + * 2005 (c) MontaVista, Software, Inc. * - * 2005 (c) MontaVista, Software, Inc. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. + * 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA * * ported from Linux to u-boot * (C) Copyright 2009 * Heiko Schocher, DENX Software Engineering, h...@denx.de. - * */ #include #include diff --git a/include/asm-arm/arch-kirkwood/gpio.h b/include/asm-arm/arch-kirkwood/gpio.h index b5bacde..cd1bc00 100644 --- a/include/asm-arm/arch-kirkwood/gpio.h +++ b/include/asm-arm/arch-kirkwood/gpio.h @@ -1,9 +1,23 @@ /* * arch/asm-arm/mach-kirkwood/include/mach/gpio.h * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. + * 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA */ /* diff --git a/include/asm-arm/arch-kirkwood/mpp.h b/include/asm-arm/arch-kirkwood/mpp.h index bc74278..b3c090e 100644 --- a/include/asm-arm/arch-kirkwood/mpp.h +++ b/include/asm-arm/arch-kirkwood/mpp.h @@ -3,9 +3,23 @@ * * Copyright 2009: Marvell Technology Group Ltd. * - * This file is licensed under the terms of the GNU General Public - * License versio
[U-Boot] [PATCH] Kirkwood: Makefile cleanup- fixed ordering (cosmetic change)
As per coding guidlines, it is good to maintain proper ordering in the makefiles. This was missed during initial coding, corrected here. This was discovered during orion5x code review Thanks to Albert Aribaud for this. Signed-off-by: Prafulla Wadaskar --- cpu/arm926ejs/kirkwood/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/arm926ejs/kirkwood/Makefile b/cpu/arm926ejs/kirkwood/Makefile index d73e210..fc2cc03 100644 --- a/cpu/arm926ejs/kirkwood/Makefile +++ b/cpu/arm926ejs/kirkwood/Makefile @@ -26,8 +26,8 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).a -COBJS-y= dram.o -COBJS-y+= cpu.o +COBJS-y= cpu.o +COBJS-y+= dram.o COBJS-y+= mpp.o COBJS-y+= timer.o -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: Makefile cleanup- fixed ordering (cosmetic change)
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Thursday, December 24, 2009 3:04 AM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar > Subject: [PATCH] Kirkwood: Makefile cleanup- fixed ordering > (cosmetic change) > > As per coding guidlines, it is good to maintain proper ordering > in the makefiles. > This was missed during initial coding, corrected here. > > This was discovered during orion5x code review > Thanks to Albert Aribaud for this. > > Signed-off-by: Prafulla Wadaskar > --- > cpu/arm926ejs/kirkwood/Makefile |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > Applied to u-boot-marvell.git/master Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: Updated licencing to GPLv2 or later
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Thursday, December 24, 2009 3:00 AM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Nicolas Pitre; > Prafulla Wadaskar > Subject: [PATCH] Kirkwood: Updated licencing to GPLv2 or later > > These are few files directly imported from Linux kernel source. > These files contains source with GPLv2 only > whereas u-boot expects GPLv2 or latter > > These files are updated for the same with prior permission from > original writer > > Acked-by: Nicolas Pitre > Signed-off-by: Prafulla Wadaskar > --- > drivers/gpio/kw_gpio.c | 20 +--- > drivers/i2c/kirkwood_i2c.c | 23 ++- > include/asm-arm/arch-kirkwood/gpio.h | 20 +--- > include/asm-arm/arch-kirkwood/mpp.h | 20 +--- > 4 files changed, 69 insertions(+), 14 deletions(-) > Applied to u-boot-marvell.git/master Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/3] Initial support for Marvell Orion5x SoC
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Sunday, January 10, 2010 9:34 PM
> To: U-Boot@lists.denx.de
> Subject: [U-Boot] [PATCH V4 1/3] Initial support for Marvell
> Orion5x SoC
>
> This patch adds support for the Marvell Orion5x SoC.
> It has no use alone, and must be followed by a patch
> to add Orion5x support for serial, then support for
> the ED Mini V2, an Orion5x-based product from LaCie.
>
> Signed-off-by: Albert Aribaud
> ---
> Patchset history
>
> V1: Initial monolithic patch.
> V2: split in three patches : orion, serial, edmini;
> checkpatch'ed, with only 6 errors, in patch 1/3,
> all 6 errors being false positives.
> V3: useless GPIO and MPP programming support removed;
> low level init added/CONFIG_SKIP_LOW_LEVEL_INIT removed.
> V4: all files licensed GPLv2-only removed;
> RAM bank size detection now uses getm_ram_size().
>
> cpu/arm926ejs/orion5x/Makefile | 51 ++
> cpu/arm926ejs/orion5x/cpu.c | 258
> ++
> cpu/arm926ejs/orion5x/dram.c | 62 +++
> cpu/arm926ejs/orion5x/timer.c| 181 +
> include/asm-arm/arch-orion5x/cpu.h | 187 +
> include/asm-arm/arch-orion5x/mv88f5182.h | 40 +
> include/asm-arm/arch-orion5x/orion5x.h | 67
> 7 files changed, 846 insertions(+), 0 deletions(-)
> create mode 100644 cpu/arm926ejs/orion5x/Makefile
> create mode 100644 cpu/arm926ejs/orion5x/cpu.c
> create mode 100644 cpu/arm926ejs/orion5x/dram.c
> create mode 100644 cpu/arm926ejs/orion5x/timer.c
> create mode 100644 include/asm-arm/arch-orion5x/cpu.h
> create mode 100644 include/asm-arm/arch-orion5x/mv88f5182.h
> create mode 100644 include/asm-arm/arch-orion5x/orion5x.h
>
...snip...
> diff --git a/cpu/arm926ejs/orion5x/dram.c
> b/cpu/arm926ejs/orion5x/dram.c
> new file mode 100644
> index 000..af4a788
> --- /dev/null
> +++ b/cpu/arm926ejs/orion5x/dram.c
> @@ -0,0 +1,62 @@
> +/*
> + * Copyright (C) 2009 Albert ARIBAUD
> + *
> + * Based on original Kirkwood support which is
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wadaskar
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define ORION5X_REG_CPUCS_WIN_BAR(x)
> (ORION5X_REGISTER(0x1500) + (x * 0x08))
> +#define ORION5X_REG_CPUCS_WIN_SZ(x)
> (ORION5X_REGISTER(0x1504) + (x * 0x08))
As pointed by wolfgang earlier, you can use c-structures here too.
-Magic numbers 1500, 1504 can be replaced by appropreate macros like-
CPU_CS0_BAR, CPU_CS0_SZ
-Struct pointer can be declared in cpu.h like
#define ORION5X_SDRAM_ADRDEC_BASE (ORION5X_REGISTER(0x1500))
ref( table 114 in 5182 users manual)
I know it's coming from referenced code but lets make new code the best. Also I
will be updating old code too.
> +/*
> + * orion5x_sdram_bar - reads SDRAM Base Address Register
> + */
> +u32 orion5x_sdram_bar(enum memory_bank bank)
> +{
> + u32 result = 0;
> + u32 enable = 0x01 & readl(ORION5X_REG_CPUCS_WIN_SZ(bank));
> +
> + if ((!enable) || (bank > BANK3))
> + return 0;
> +
> + result = readl(ORION5X_REG_CPUCS_WIN_BAR(bank));
> + return result;
> +}
...snip..
> diff --git a/include/asm-arm/arch-orion5x/cpu.h
> b/include/asm-arm/arch-orion5x/cpu.h
> new file mode 100644
> index 000..0a33999
> --- /dev/null
> +++ b/include/asm-arm/arch-orion5x/cpu.h
> @@ -0,0 +1,187 @@
> +/*
> + * Copyright (C) 2009 Albert ARIBAUD
> + *
> + * Based on original Kirorion5x_ood support which is
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wad
Re: [U-Boot] [PATCH V4 1/3] Initial support for Marvell Orion5x SoC
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Sunday, January 10, 2010 9:34 PM
> To: U-Boot@lists.denx.de
> Subject: [U-Boot] [PATCH V4 1/3] Initial support for Marvell
> Orion5x SoC
>
> This patch adds support for the Marvell Orion5x SoC.
> It has no use alone, and must be followed by a patch
> to add Orion5x support for serial, then support for
> the ED Mini V2, an Orion5x-based product from LaCie.
>
> Signed-off-by: Albert Aribaud
> ---
> Patchset history
>
> V1: Initial monolithic patch.
> V2: split in three patches : orion, serial, edmini;
> checkpatch'ed, with only 6 errors, in patch 1/3,
> all 6 errors being false positives.
> V3: useless GPIO and MPP programming support removed;
> low level init added/CONFIG_SKIP_LOW_LEVEL_INIT removed.
> V4: all files licensed GPLv2-only removed;
> RAM bank size detection now uses getm_ram_size().
>
> cpu/arm926ejs/orion5x/Makefile | 51 ++
> cpu/arm926ejs/orion5x/cpu.c | 258
snip
> +int print_cpuinfo(void)
> +{
> + char dev_str[] = "0x";
> + char rev_str[] = "0x00";
> + char *dev_name = NULL;
> + char *rev_name = NULL;
> +
> + u32 dev = orion5x_device_id();
> + u32 rev = orion5x_device_rev();
> +
> + if (dev == MV88F5181_DEV_ID) {
> + dev_name = "MV88F5181";
> + if (rev == MV88F5181_REV_B1)
> + rev_name = "B1";
> + else if (rev == MV88F5181L_REV_A1) {
> + dev_name = "MV88F5181L";
> + rev_name = "A1";
> + } else if (rev == MV88F5181L_REV_A0) {
> + dev_name = "MV88F5181L";
> + rev_name = "A0";
> + }
> + } else if (dev == MV88F5182_DEV_ID) {
> + dev_name = "MV88F5182";
> + if (rev == MV88F5182_REV_A2)
> + rev_name = "A2";
> + } else if (dev == MV88F5281_DEV_ID) {
> + dev_name = "MV88F5281";
> + if (rev == MV88F5281_REV_D2)
> + rev_name = "D2";
> + else if (rev == MV88F5281_REV_D1)
> + rev_name = "D1";
> + else if (rev == MV88F5281_REV_D0)
> + rev_name = "D0";
> + } else if (dev == MV88F6183_DEV_ID) {
> + dev_name = "MV88F6183";
> + if (rev == MV88F6183_REV_B0)
> + rev_name = "B0";
> + }
The above checks should be #ifdefed with CONFIG_88F (SOC type)
There is no need to check for all SoC names, this will also reduce code size.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/3] Add support for the LaCie ED Mini V2 board
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Sunday, January 10, 2010 9:34 PM
> To: U-Boot@lists.denx.de
> Subject: [U-Boot] [PATCH V4 3/3] Add support for the LaCie ED
> Mini V2 board
>
> This patch adds support for the LaCie ED Mini V2 product
> which is based on the Marvell Orion5x SoC.
> Current support is limited to console and Flash.
> Flash support uses CONFIG_FLASH_CFI_LEGACY as the
> Macronix MX29LV400 used on ED Mini V2 is not CFI
> compliant (mixes 16 and 8 bit behaviors).
>
> Signed-off-by: Albert Aribaud
> ---
> MAINTAINERS |4 +
> MAKEALL |1 +
> Makefile |3 +
> board/LaCie/edminiv2/Makefile| 58 ++
> board/LaCie/edminiv2/config.mk | 27 +++
> board/LaCie/edminiv2/edminiv2.c | 88 +
> board/LaCie/edminiv2/edminiv2.h | 59 ++
> board/LaCie/edminiv2/lowlevel_init.S | 324
> ++
> include/configs/edminiv2.h | 147 +++
> 9 files changed, 711 insertions(+), 0 deletions(-)
> create mode 100644 board/LaCie/edminiv2/Makefile
> create mode 100644 board/LaCie/edminiv2/config.mk
> create mode 100644 board/LaCie/edminiv2/edminiv2.c
> create mode 100644 board/LaCie/edminiv2/edminiv2.h
> create mode 100644 board/LaCie/edminiv2/lowlevel_init.S
> create mode 100644 include/configs/edminiv2.h
>
snip...
> diff --git a/board/LaCie/edminiv2/config.mk
> b/board/LaCie/edminiv2/config.mk
> new file mode 100644
> index 000..91f2db9
> --- /dev/null
> +++ b/board/LaCie/edminiv2/config.mk
> @@ -0,0 +1,27 @@
> +#
> +# Copyright (C) 2009 Albert ARIBAUD
> +#
> +# (C) Copyright 2009
> +# Marvell Semiconductor
> +# Written-by: Prafulla Wadaskar
> +#
> +# 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., 51 Franklin Street, Fifth Floor, Boston,
> +# MA 02110-1301 USA
> +#
> +
> +TEXT_BASE = 0x0060
??? As reported earlier, is this okay for you? And do not want to lower it?
> diff --git a/board/LaCie/edminiv2/edminiv2.c
> b/board/LaCie/edminiv2/edminiv2.c
> new file mode 100644
> index 000..988de52
> --- /dev/null
> +++ b/board/LaCie/edminiv2/edminiv2.c
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright (C) 2009 Albert ARIBAUD
> + *
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wadaskar
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include "edminiv2.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * The ED Mini V2 is equipped with a Macronix MXLV400CB FLASH
> + * which CFI does not properly detect, hence the LEGACY config.
> + */
> +#if defined(CONFIG_FLASH_CFI_LEGACY)
> +#include
> +ulong board_flash_get_legacy(ulong base, int banknum,
> flash_info_t *info)
> +{
> + int sectsz[] = CONFIG_SYS_FLASH_SECTSZ;
> + int sect;
> +
> + if (base != CONFIG_SYS_FLASH_BASE)
> + return 0;
> +
> + info->size = 0;
> + info->se
Re: [U-Boot] [PATCH V4 3/3] Add support for the LaCie ED Mini V2 board
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, January 11, 2010 5:42 PM > To: Prafulla Wadaskar > Cc: U-Boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH V4 3/3] Add support for the > LaCie ED Mini V2 board > > Prafulla Wadaskar a écrit : > > > I still do not understand who will fectch u-boot binary to > TEXT_BASE? (reported earlier) > > Is this flash XIP? Does u-boot binary below 16k? What is > the size of flash? > > Pls refer my comments for v3 > > I thought I'd explained that already, haven't I? At power-up > a ROM code > at (64KB of ROM taking precedence over CS0, as seen > from JTAG) > does a few checks then jumps to FFF9, which is the NOR Flash. The > U-boot image is mapped and flashed so that the entry point is at > FFF9. The entry point then does further inits (some under > condition > that SKIP_CONFIG_LOWLEVEL_INIT is not defined), initializes RAM, > relocates code to TEXT_BASE (if CONFIG_SKIP_RELOCATE_UBOOT is not > defined) and then jumps to it. > Okay. I am referring to 5281 users manual section 17.2.1 and that does not have these details. Or is ROM sitting at 0x already have a code that does above? Or Are you pointing to Boot ROM Support that 5281 have? Do you have any reference for all this explanation? Or can you point any reference for me to look for? Regards.. Prafulla . . > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/3] Add support for the LaCie ED Mini V2 board
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Wednesday, January 13, 2010 6:08 PM > To: Prafulla Wadaskar > Cc: U-Boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH V4 3/3] Add support for the > LaCie ED Mini V2 board ...snip... > >> + info->flash_id = 0x0100; > >> + info->portwidth = FLASH_CFI_8BIT; > >> + info->chipwidth = FLASH_CFI_BY8; > >> + info->buffer_size = 0; > >> + info->erase_blk_tout = 1000; > >> + info->write_tout = 10; > >> + info->buffer_write_tout = 300; > >> + info->vendor = CFI_CMDSET_AMD_LEGACY; > >> + info->cmd_reset = 0xF0; > >> + info->interface = FLASH_CFI_X8; > >> + info->legacy_unlock = 0; > >> + info->manufacturer_id = 0x22; > >> + info->device_id = 0xBA; > >> + info->device_id2 = 0; > >> + info->ext_addr = 0; > >> + info->cfi_version = 0x3133; > >> + info->cfi_offset = 0x; > >> + info->addr_unlock1 = 0x0aaa; > >> + info->addr_unlock2 = 0x0555; > >> + info->name = "MX29LV400CB"; > > > > initialization with magic numbers should be provided with > some comments for better understanding. > > I can add some comments, although here most of the comments > would simply > paraphrase the code one way or the other, e.g. > > >> + info->device_id = 0xBA; /* device ID of the > MX29LV400CB is 0xBA */ This level documentation is good rather than nothing :-) ...snip... > >> + > >> +lowlevel_init: > >> + > >> + /* Use 'r4 as the base for internal register accesses */ > >> + ldr r4, =EDMINIV2_INTERNAL_BASE > >> + > >> + /* move internal registers from the default 0xD000 > >> + * to their intended location of 0xf100 */ > >> + ldr r3, =0xD000 > >> + add r3, r3, #0x2 > >> +str r4, [r3, #0x80] > >> + > >> + /* Use R3 as the base for Device Bus registers */ > >> + add r3, r4, #0x1 > >> + > >> + /* init MPPs */ > >> + ldr r6, =EDMINIV2_MPP0_7 > >> + str r6, [r3, #0x000] > >> + ldr r6, =EDMINIV2_MPP8_15 > >> + str r6, [r3, #0x004] > >> + ldr r6, =EDMINIV2_MPP16_23 > >> + str r6, [r3, #0x050] > >> + > >> + /* init GPIOs */ > >> + ldr r6, =EDMINIV2_GPIO_OUT_ENABLE > >> + str r6, [r3, #0x104] > >> + > >> + /* Use R3 as the base for DRAM registers */ > >> + add r3, r4, #0x01000 > >> + > >> + /*DDR SDRAM Initialization Control */ > >> + ldr r6, =0x0001 > >> + str r6, [r3, #0x480] > >> + > >> + /* Use R3 as the base for PCI registers */ > >> + add r3, r4, #0x31000 > >> + > >> + /* Disable arbiter */ > >> + ldr r6, =0x0030 > >> + str r6, [r3, #0xd00] > >> + > >> + /* Use R3 as the base for DRAM registers */ > >> + add r3, r4, #0x01000 > >> + > >> + /* set all dram windows to 0 */ > >> + mov r6, #0 > >> + str r6, [r3, #0x504] > >> + str r6, [r3, #0x50C] > >> + str r6, [r3, #0x514] > >> + str r6, [r3, #0x51C] > >> + > >> + /* 1) Configure SDRAM */ > >> + ldr r6, =SDRAM_CONFIG > >> + str r6, [r3, #0x400] > >> + > >> + /* 2) Set SDRAM Control reg */ > >> + ldr r6, =SDRAM_CONTROL > >> + str r6, [r3, #0x404] > >> + > >> +/* 3) Write SDRAM address control register */ > >> + ldr r6, =SDRAM_ADDR_CTRL > >> + str r6, [r3, #0x410] > >> + > >> +/* 4) Write SDRAM bank 0 size register */ > >> + ldr r6, =SDRAM_BANK0_SIZE > >> + str r6, [r3, #0x504] > >> + /* keep other banks disabled */ > >> + > >> +/* 5) Write SDRAM open pages control register */ > >> + ldr r6, =SDRAM_OPEN_PAGE_EN > >> + str r6, [r3, #0x414] > >> + > >> +/* 6) Write SDRAM timing Low register */ > >> + ldr r6, =SDRAM_TIME_CTRL_LOW > >> + str r6, [r3, #0x408] > >> + > >> +/*
Re: [U-Boot] open u-boot on the DockStar
Hi Alexander Welcome on board :-) Pls see my in lined answers > -Original Message- > From: Alexander Holler [mailto:hol...@ahsoftware.de] > Sent: Friday, January 15, 2010 4:15 AM > To: Prafulla Wadaskar > Subject: Re: open u-boot on the DockStar > > Hello again, > > through painful debugging by reset (tm) ;) I have found the exact > location where the problem seems to occur. The following diff > explains it: ...snip... > Am 14.01.2010 20:45, schrieb Alexander Holler: > > Hello, > > > > I'm currently trying to build an u-boot from the sources at > denx.de and > > I'm stuck. Because I currently only have a serial > connection an no JTAG, Working on u-boot really needs some JTAG since it is risky game. > > debugging isn't easy and I have only limited knowledge > about the hardware. > > > > It is no problem if you don't want or could help me on that > topc, I'm I will try to help you, You are most welcomed (as my first line)... > > just thought mailing to you directly could be worth a try. I would prefer to be u-boot mailing list so that other users can benefit from the discussion. I am copying to mailing list. > > > > What I've done so far: > > > > For all things, I'm using the precompiled gcc from the > sheevaplug sdk I suggest to use latest gcc, (ref: www.codesourcery.com to work with latest u-boot > > > > Currently I'm booting using an u-boot I've build from the > sources found > > in pogoplug-u-boot-1.1.4.pp2.0.tar.bz2 pogoplug published > after I asked > > for the GPL-sources used in the DockStar. This works but doesn't the > > load the kernel. I'm not really interested the pogoplug > kernel, but for > > completness this is where the pogoplug u-boot I've build from their > > sources stops: > > > > NAND read: device 0 offset 0x10, size 0x30 > > > > reading NAND page at offset 0x10 failed > > 3145728 bytes read: ERROR > > ## Booting image at 0080 ... > > Bad Magic Number > > > > So nand read.e fails. I've build pogoplugs u-boot with the following > > commands: > > > > PATH=$PATH:/home/aholler/gcc/bin make mrproper > > PATH=$PATH:/home/aholler/gcc/bin make redstone_config > > PATH=$PATH:/home/aholler/gcc/bin make > > > > Anyway, that error currently isn't of interest for me, the resulted > > u-boot is enough for trying to load and execute an u-boot > build from the > > sources at denx.de. > > > > To build such an u-boot, I've modified > > board/Marvell/sheevaplug/config.mk to have a TEXT_BASE = > 0x0160 (for > > testing by loading it to RAM). This will not help much > > > > Than I've modified the values kwbimage.cfg to be same as those I've > > found dramregs_pp128_A.txt in pogoplug-u-boot-1.1.4.pp2.0.tar.bz2. Sounds good > > > > Compilation was done with > > > > PATH=$PATH:/home/aholler/gcc/bin make mrproper > USE_PRIVATE_LIBGCC=yes > > CROSS_COMPILE=arm-none-linux-gnueabi- > > PATH=$PATH:/home/aholler/gcc/bin make sheevaplug_config > > USE_PRIVATE_LIBGCC=yes CROSS_COMPILE=arm-none-linux-gnueabi- > > PATH=$PATH:/home/aholler/gcc/bin make u-boot.kwb > USE_PRIVATE_LIBGCC=yes > > CROSS_COMPILE=arm-none-linux-gnueabi- > > > > After loading the resulting u-boot.bin with > > tftp 0x0160 u-boot.bin > > and starting it with > > go 0x0160 This will not work since this interface is used for application execution. on Kirkwood, internal BootROM will start "boot from configured media" on Power on reset only to read kirkwood boot image header and that too from 0x0 address, so you must need to put uboot image at 0x0 in NAND Flash Or use JTAG to download u-boot.bin to RAM and then start execution. > > > > just nothing happens. No single char appears over the serial, just > > nothing. I've even tried it without CONFIG_CMD_NAND, but > the results are > > the same: nothing visible happens. Even the led doesn't change (it's > > still blinking orange). > > > > I would appreciate any help. ;) This is new board with NEW DRAM and new configuration, Kwbimage.cfg file will be used to create target u-boot.kwb. I strongly recommend to use JTAG tool for ex. openOCD The best approach should be- Use openocd, get some JTAG tool (ex. Amontec) Prepare script to configure DRAM and some other CPU register as provided in kwbimage.cfg Load u-boot elf through JTAG Debug with dgb/led/uart Prepare nice and clean patches if you want to mainline them Good luck Regards.. Prafulla . . > > > > My next step will be to use the led for simplified > debugging (in absence > > of a JTAG) for finding out, how far the initialization will come. > > > > Kind regards, > > > > Alexander Holler > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-marvell.git
Hi Tom Pls pull the following The following changes since commit 06f95959bc5421e516a9a25012e303dea8833385: Tom Rix (1): ARM Update mach-types are available in the git repository at: http://git.denx.de/u-boot/u-boot-marvell.git master branch. Prafulla Wadaskar (2): Kirkwood: Upgated licencing for files imported from linux source to GPLv2 or later Kirkwood: Makefile cleanup- fixed ordering (cosmetic change) cpu/arm926ejs/kirkwood/Makefile |4 ++-- drivers/gpio/kw_gpio.c | 20 +--- drivers/i2c/kirkwood_i2c.c | 23 ++- include/asm-arm/arch-kirkwood/gpio.h | 20 +--- include/asm-arm/arch-kirkwood/mpp.h | 20 +--- 5 files changed, 71 insertions(+), 16 deletions(-) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NET: kirkwood-egiga smi access fix
> -Original Message- > From: Siddarth Gore [mailto:go...@marvell.com] > Sent: Tuesday, January 19, 2010 11:09 AM > To: u-boot@lists.denx.de > Cc: Prafulla Wadaskar; Siddarth Gore > Subject: [PATCH] NET: kirkwood-egiga smi access fix > > Although the datasheet mentions seperate smi registers for > each port, using Port 1 smi register to access ethernet phys > does not work. Hence only Port 0 smi register should be used > to access all devices connected to the smi bus. This behavior > is consistant with the mv643xx driver in the linux kernel. > > Signed-off-by: Siddarth Gore > Acked-by: Prafulla Wadaskar Ack I have tested this Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Linux Kernel without Ethernet (missed MAC)
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Arno Steffen > Sent: Tuesday, January 19, 2010 3:14 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] Linux Kernel without Ethernet (missed MAC) > > Changing my OMAP EVM board to newest uboot 2009-11 I do have a problem > with ethernet. > Although the kernel could be loaded via tftp perfectly, the upcoming > kernel complains about invalid MAC. > > Kernel command line: mem=128M console=ttyS0,115200n8 > root=/dev/mtdblock8 rw rootfstype=jffs2 ip=dhcp Hi Arno I hope, when you are booting the kernel from media (i.e. NAND/Flash/Sata and not Ethernet) you are getting this problem. u-boot does not perform peripheral h/w initialization by default, u-boot as well as kernel assumes h/w is doing this. May be in your case, smc91x h/w does not do it on Power on by default. When you do any network activity prior to kernel boot, device_init is invoked and the MAC address is set and your system works. Possible Solution: add dummy network command like (ping x.x.x.x) in your auto boot sequence. Regards.. Prafulla . . > ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot build failes with armv5tel-reghat-linux-gnueabi-gcc (4.1.2)
Hi I am using u-boot-1.1.6 and building u-boot from my new board which includes nand flash support If I build using armv5tel-reghat-linux-gnueabi-gcc (4.1.2) toolchain it gives build failure with below log --start-group lib_generic/libgeneric.a board/Marvell/rd6281/librd6281.a cpu/arm926ejs/libarm926ejs.a cpu/arm926ejs/feroceon/libferoceon.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/nand/libnand.a drivers/nand_legacy/libnand_legacy.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a --end-group -L /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2 -lgcc \ -Map u-boot.map -o u-boot /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' make: *** [u-boot] Error 1 Whereas, If I build the same code using codesoucery toolchain (arm2008q1) release (gcc ver 4.2.3) the build is sucessfull. I want to go ahead with armv5tel-reghat-linux-gnueabi-gcc (4.1.2) Can someone suggest what is problem and how should I proceed? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot build failes witharmv5tel-reghat-linux-gnueabi-gcc (4.1.2)
Hi Jean, First of all sorry for late feedback Thanks for your help. I tried to apply the above patch but it has lot of diff, On the other thread I have migrated to latest u-boot version and the problem got resolved :-) I think your patch is mainlined. But I am facing now new problem... The earlier I was using u-boot ver 1.1.6 and my nand driver was working fine. With migration to latest u-boot I am always getting bad block errors (Skipping bad block 0x) What could be the problem? Regards.. Prafulla. . > -Original Message- > From: Jean-Christophe PLAGNIOL-VILLARD [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 23, 2008 5:57 AM > To: Prafulla Wadaskar; u-boot@lists.denx.de > Subject: Re: [U-Boot] U-boot build failes > witharmv5tel-reghat-linux-gnueabi-gcc (4.1.2) > > On 13:06 Wed 19 Nov , Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 03:10 Wed 19 Nov , Prafulla Wadaskar wrote: > > > Hi > > > I am using u-boot-1.1.6 and building u-boot from my new > board which > > > includes nand flash support > > > > > > If I build using armv5tel-reghat-linux-gnueabi-gcc > (4.1.2) toolchain > > > it gives build failure with below log > > > > > > --start-group > lib_generic/libgeneric.a board/Marvell/rd6281/librd6281.a > cpu/arm926ejs/libarm926ejs.a > cpu/arm926ejs/feroceon/libferoceon.a lib_arm/libarm.a > fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a > fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a > fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a > dtt/libdtt.a drivers/libdrivers.a drivers/nand/libnand.a > drivers/nand_legacy/libnand_legacy.a > drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a > common/libcommon.a --end-group -L > /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2 -lgcc \ > > > -Map u-boot.map -o u-boot > > > > /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2/libgcc.a(_div di3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' > > > > /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.1.2/libgcc.a(_udi vdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' > > > make: *** [u-boot] Error 1 > > > > > > Whereas, > > > If I build the same code using codesoucery toolchain > (arm2008q1) release (gcc ver 4.2.3) the build is sucessfull. > > > > > > I want to go ahead with armv5tel-reghat-linux-gnueabi-gcc (4.1.2) > > > Can someone suggest what is problem and how should I proceed? > > update the divdi3 and _udivdi3 implementation > > > > I'll said > > > > so please try this patch > > > > please note I've just test it on one board > > > > Best Regards, > > J. > > Any news? > > Best Regards, > J. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot build faileswitharmv5tel-reghat-linux-gnueabi-gcc (4.1.2)
> > The earlier I was using u-boot ver 1.1.6 and my nand driver > was working fine. > > With migration to latest u-boot I am always getting bad > block errors > > (Skipping bad block 0x) > could you be a few more specific? > Hi J Just now it is working I set chip_delay=1000 in board specific code, earlier it was 100 I am trying to get optimal value for the same > CPU, NAND? > your patch? > I am using arm926ejs based CPU and NAND01G-A, Soon I will provide a patch Thanks... Regards.. Prafulla . . ___ 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
> -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 5/7] Support passing a Marvell-specific ATAG
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of ro...@dawes.za.net
> Sent: Friday, March 18, 2011 1:40 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 5/7] Support passing a Marvell-specific ATAG
>
> From: Rogan Dawes
>
> ---
> arch/arm/include/asm/setup.h | 18 ++
> arch/arm/lib/bootm.c | 31 +++
> 2 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index 89df4dc..bd6229a 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -198,6 +198,19 @@ struct tag_acorn {
> u8 adfsdrives;
> };
>
> +/* Marvell specific information
> + * requred for compatability with vendor kernels
> + */
> +#define ATAG_MV_UBOOT 0x41000403
What is a need for this ATAG?
Open source Linux Kernel does not have any implementation to support this ATAG.
Nor u-boot have any vendor specific ATAGs
NACK, if this is specific to support any custom implementation.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] Orion5x: Correct DRAM bank detection
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of ro...@dawes.za.net
> Sent: Friday, March 18, 2011 1:40 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 1/7] Orion5x: Correct DRAM bank detection
>
Some more explanation about the patch may find help full.
Please have a practice to provide some detailed comments.
> From: Rogan Dawes
>
> ---
> arch/arm/cpu/arm926ejs/orion5x/dram.c |2 +-
> arch/arm/include/asm/arch-orion5x/orion5x.h |1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/orion5x/dram.c
> b/arch/arm/cpu/arm926ejs/orion5x/dram.c
> index b749282..2ae8f48 100644
> --- a/arch/arm/cpu/arm926ejs/orion5x/dram.c
> +++ b/arch/arm/cpu/arm926ejs/orion5x/dram.c
> @@ -38,7 +38,7 @@ u32 orion5x_sdram_bar(enum memory_bank bank)
> {
> struct orion5x_ddr_addr_decode_registers *winregs =
> (struct orion5x_ddr_addr_decode_registers *)
> - ORION5X_CPU_WIN_BASE;
> + ORION5X_DRAM_BASE;
Any explanation about previous definition was wrong?
Does struct orion5x_ddr_addr_decode_registers still valid for this change?
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-working Relocated DNS323 config
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of ro...@dawes.za.net > Sent: Friday, March 18, 2011 1:40 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] Non-working Relocated DNS323 config > > This patch series contains the previous working configuration for > the DNS323, forward-ported to mainline, taking into account changes > made to the EDMiniV2 configuration on which this is based. > > Unfortunately, this does not boot at all. I get: > > Marvell>> bootm > ## Booting image at 0010 ... >Image Name: UBoot dns323 >Image Type: ARM U-Boot Kernel Image (uncompressed) >Data Size:170100 Bytes = 166.1 kB >Load Address: 0300 >Entry Point: 0300 >Verifying Checksum ... OK > OK > > Starting kernel ... There might be machine id mismatch in the kernel and programmed in u-boot for this board. Regards.. Prafulla . . > > and that is the end of it. > > Any hints and suggestions as to what I may be doing wrong are gratefully > received. > > Regards, > > Rogan > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] edminiv2: add I2C support using mvtwsi driver
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of ro...@dawes.za.net > Sent: Friday, March 18, 2011 1:35 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH 06/11] edminiv2: add I2C support using mvtwsi > driver > > From: Albert Aribaud > > Signed-off-by: Albert Aribaud > --- > include/configs/edminiv2.h |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h > index 57dd165..36ed392 100644 > --- a/include/configs/edminiv2.h > +++ b/include/configs/edminiv2.h > @@ -182,6 +182,15 @@ > #endif /* CMD_IDE */ > > /* > + * I2C related stuff > + */ > +#define CONFIG_I2C_DRIVER_MVTWSI > +#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE > +#define CONFIG_SYS_I2C_SLAVE 0x0 > +#define CONFIG_SYS_I2C_SPEED 10 > +#define CONFIG_CMD_I2C Pls defind _CMD_I2C above with other enabled commands and #ifdefed this stuff in it. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] Orion5x: bugfix: window size (mis)calculation
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of ro...@dawes.za.net > Sent: Friday, March 18, 2011 1:35 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH 04/11] Orion5x: bugfix: window size > (mis)calculation > > From: Albert Aribaud BTW: who has send this patch? I think not Albert? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/23] keymile board update
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Heiko Schocher
> Sent: Monday, March 21, 2011 12:32 PM
> To: u-boot@lists.denx.de
> Cc: Heiko Schocher
> Subject: [U-Boot] [PATCH v3 00/23] keymile board update
>
> The following patchset updates the support for the keymile
> boards.
>
> - fix a lot of Codingstyle issues for this boards
> - heavy rework of the headerfiles, common board code
> - add support for 4 new mpc83xx based boards
> - add support for 1 82xx based board
> - add support for 2 new kirkwood based boards
> - fix i2c deblocking for this boards
Hi Heiko
Ideally this patch series should go all together, right?
Since there are multiple SoC based support in the same patch series, who is
suppose to pull this?
I suggest to have smaller patche series i.e. board wise.
Since there is heavy rework,
Also take a look at mv-common.h that we have created for armada100 and Kirkwood
common boards configs. With this we had an abstraction where mostly files are
only added to any new board support.
Regards..
Prafulla . .
>
> Heiko Schocher (16):
> powerpc, mpc83xx: add missing functions to mpc83xx.h
> keymile: Fix Coding style issues for keymile boards.
> mpc832x: add support for the mpc8321 based suvd3 board
> mpc832x: add support for mpc8321 based tuxa1 board
> mpc832x: add support for mpc8321 based tuda1 board
> arm: add support for kirkwood based mgcoge2un board
> arm: add support of Kirkwood based board SUEN8
> ppc: add support for ppc based board mgcoge2ne
> powerpc, 83xx: add kmsupx5 board support
> km-arm: i2c support for suenx based boards
> km_arm: change some register values for SDRAM initialization
> ppc, 8321: cleanup tuxa1, tuda1 and suvd3 support
> keymile, common; fix i2c deblocking support
> arm, keymile: updates for the arm based boards from keymile
> keymile boards: add CONFIG_PIGGY_MAC_ADRESS_OFFSET
> keymile, common: add setting of some environment variables
>
> Holger Brunck (5):
> arm, keymile: rename MACH_SUEN3 to MACH_KM_KIRKWOOD
> ppc, arm: adapt keymile header
> arm, ppc: rework environment variables for keymile boards
> ppc, arm: rework and enhance keymile-common.h
> keymile-common.h: remove IO mux stuff
>
> Thomas Herzmann (1):
> keymile boards: support of boardId / hwkey lists
>
> Thomas Reufer (1):
> keymile, 8321 boards: move common definitions to km8321-common.h
>
> MAINTAINERS|7 +
> arch/powerpc/cpu/mpc83xx/fdt.c |3 +-
> arch/powerpc/lib/bootcount.c |2 +-
> board/keymile/common/common.c | 496 -
> ---
> board/keymile/common/common.h | 44 +++-
> board/keymile/{kmeter1 => km83xx}/Makefile |0
> board/keymile/km83xx/km83xx.c | 288
> board/keymile/km_arm/km_arm.c | 91 --
> board/keymile/km_arm/kwbimage.cfg | 32 +-
> board/keymile/kmeter1/kmeter1.c| 217
> board/keymile/mgcoge/mgcoge.c | 93 +++---
> boards.cfg |9 +-
> include/configs/keymile-common.h | 489 +++--
> ---
> include/configs/km-powerpc.h | 92 +
> include/configs/km82xx-common.h| 336 +++
> include/configs/km8321-common.h| 138
> include/configs/km83xx-common.h| 325 ++
> include/configs/km_arm.h | 104 +-
> include/configs/kmeter1.h | 369 +++--
> -
> include/configs/kmsupx5.h | 91 +
> include/configs/mgcoge.h | 307 +-
> include/configs/mgcoge2ne.h| 64
> include/configs/mgcoge2un.h| 65
> include/configs/suen3.h| 45 +---
> include/configs/suen8.h| 65
> include/configs/suvd3.h| 104 ++
> include/configs/tuda1.h| 141
> include/configs/tuxa1.h| 124 +++
> include/mpc83xx.h |6 +
> 29 files changed, 2794 insertions(+), 1353 deletions(-)
> rename board/keymile/{kmeter1 => km83xx}/Makefile (100%)
> create mode 100644 board/keymile/km83xx/km83xx.c
> delete mode 100644 board/keymile/kmeter1/kmeter1.c
> create mode 100644 include/configs/km-powerpc.h
> create mode 100644 include/configs/km82xx-common.h
> create mode 100644 include/configs/km8321-common.h
> create mode 100644 include/configs/km83xx-common.h
> create mode 100644 include/configs/kmsupx5.h
> create mode 100644 include/configs/mgcoge2ne.h
> create mode 100644 include/configs/mgcoge2un.h
> create mode 100644 include/configs/suen8.h
> create mode 100644 include/configs/suvd3.h
> create mode 100644 include/con
Re: [U-Boot] [PATCH V3 2/5] mv_i2c: use structure to replace the direclty define
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 17, 2011 12:15 PM
> To: Heiko Schocher; Wolfgang Denk; Prafulla Wadaskar; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik;
> adrian.w...@gmail.com
> Subject: [PATCH V3 2/5] mv_i2c: use structure to replace the direclty
> define
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V3:
> clean code sytle issue
>
> arch/arm/cpu/pxa/cpu.c | 11 +++
> arch/arm/include/asm/arch-pxa/pxa-regs.h | 56 -
> board/innokom/innokom.c |9 +--
> drivers/i2c/mv_i2c.c | 133 ++-
> --
> drivers/i2c/mv_i2c.h | 83 +++
> include/configs/innokom.h|1 +
> include/configs/xm250.h |1 +
> 7 files changed, 161 insertions(+), 133 deletions(-)
> create mode 100644 drivers/i2c/mv_i2c.h
>
...snip...
> diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
> index 09756a4..152ea43 100644
> --- a/drivers/i2c/mv_i2c.c
> +++ b/drivers/i2c/mv_i2c.c
> @@ -8,6 +8,9 @@
> * (C) Copyright 2003 Pengutronix e.K.
> * Robert Schwebel
> *
> + * (C) Copyright 2011 Marvell Inc.
> + * Lei Wen
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
> @@ -34,44 +37,16 @@
> #include
>
> #ifdef CONFIG_HARD_I2C
> -
> -/*
> - * - CONFIG_SYS_I2C_SPEED
> - * - I2C_PXA_SLAVE_ADDR
> - */
> -
> -#include
> -#include
> #include
> -
> -#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
> +#include "mv_i2c.h"
>
> #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
> +#define PXAI2C_AND(reg, val) writel(readl(reg) & val, reg)
> +#define PXAI2C_OR(reg, val) writel(readl(reg) | val, reg)
With reference to the file name MVI2C_ is better macro name to be used here.
Applicable for s/pxa/mv/g in the entire file too
>
> /* All transfers are described by this data structure */
> struct i2c_msg {
> @@ -81,27 +56,37 @@ struct i2c_msg {
> u8 data;
> };
>
> +struct pxa_i2c {
> + u32 ibmr;
> + u32 pad0;
> + u32 idbr;
> + u32 pad1;
> + u32 icr;
> + u32 pad2;
> + u32 isr;
> + u32 pad3;
> + u32 isar;
> +};
Please document the long names of these register with their offsets.
> +
> +static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
> +
...snip...
> if (msg->acknack == I2C_ACKNAK_SENDACK)
> - writel(readl(ICR) & ~ICR_ACKNAK, ICR);
> - writel(readl(ICR) & ~ICR_ALDIE, ICR);
> - writel(readl(ICR) | ICR_TB, ICR);
> + PXAI2C_AND(&base->icr, ~ICR_ACKNAK);
> + PXAI2C_AND(&base->icr, ~ICR_ALDIE);
> + PXAI2C_OR(&base->icr, ICR_TB);
What are benefits of those macros?
To me this looks ugly and looses readability.
...snip...
> diff --git a/drivers/i2c/mv_i2c.h b/drivers/i2c/mv_i2c.h
> new file mode 100644
> index 000..41af0d9
> --- /dev/null
> +++ b/drivers/i2c/mv_i2c.h
> @@ -0,0 +1,83 @@
> +/*
> + * (C) Copyright 2011
> + * Marvell Inc,
> + *
> + * 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 fo
Re: [U-Boot] [PATCH V3 3/5] I2C: add i2c support for Pantheon platform
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 17, 2011 12:15 PM
> To: Heiko Schocher; Wolfgang Denk; Prafulla Wadaskar; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik;
> adrian.w...@gmail.com
> Subject: [PATCH V3 3/5] I2C: add i2c support for Pantheon platform
>
> Add i2c support to dkb board with pantheon soc.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V3:
> clean code sytle issue
> Add i2c clock enable code include in I2C configure define block
>
> arch/arm/cpu/arm926ejs/pantheon/cpu.c| 12
> arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
> arch/arm/include/asm/arch-pantheon/mfp.h |6 --
> board/Marvell/dkb/dkb.c |4
> include/configs/dkb.h| 11 +++
> 5 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> index 9ddc77c..8b2eafa 100644
> --- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> @@ -59,6 +59,12 @@ int arch_cpu_init(void)
> /* Enable GPIO clock */
> writel(APBC_APBCLK, &apbclkres->gpio);
>
> +#ifdef CONFIG_I2C_MV
> + /* Enable I2C clock */
> + writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> + writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> +#endif
> +
> icache_enable();
>
> return 0;
> @@ -76,3 +82,9 @@ int print_cpuinfo(void)
> return 0;
> }
> #endif
> +
> +#ifdef CONFIG_I2C_MV
> +void i2c_clk_enable(void)
> +{
> +}
Empty function !!
> +#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..e939196 100644
> --- a/arch/arm/include/asm/arch-pantheon/mfp.h
> +++ b/arch/arm/include/asm/arch-pantheon/mfp.h
> @@ -32,8 +32,10 @@
> * offset, pull,pF, drv,dF, edge,eF ,afn,aF
> */
> /* 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 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)
>
> /* 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..1b18c44 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
> +
What about if I don't want to include this support
These configuration must if ifdefed with CONFIG_CMD_I2C which will be defined
in board config file.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 5/5] I2C: add i2c support for Armada100 platform
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 17, 2011 12:15 PM
> To: Heiko Schocher; Wolfgang Denk; Prafulla Wadaskar; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik;
> adrian.w...@gmail.com
> Subject: [PATCH V3 5/5] I2C: add i2c support for Armada100 platform
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V3:
> clean code sytle issue
> Add i2c clock enable code include in I2C configure define block
>
> arch/arm/cpu/arm926ejs/armada100/cpu.c| 16 +++
> arch/arm/include/asm/arch-armada100/mfp.h | 40 --
> ---
> board/Marvell/aspenite/aspenite.c |5 +++
> include/configs/aspenite.h| 12
> 4 files changed, 55 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c
> b/arch/arm/cpu/arm926ejs/armada100/cpu.c
> index 62aa175..c21938e 100644
> --- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
> @@ -62,6 +62,16 @@ int arch_cpu_init(void)
> /* Enable GPIO clock */
> writel(APBC_APBCLK, &apb1clkres->gpio);
>
> +#ifdef CONFIG_I2C_MV
> + /* 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);
> +#endif
> +
> /*
>* Enable Functional and APB clock at 14.7456MHz
>* for configured UART console
> @@ -90,3 +100,9 @@ int print_cpuinfo(void)
> return 0;
> }
> #endif
> +
> +#ifdef CONFIG_I2C_MV
> +void i2c_clk_enable(void)
> +{
> +}
Empty function, you can better ifdef calling line
> +#endif
> diff --git a/arch/arm/include/asm/arch-armada100/mfp.h
> b/arch/arm/include/asm/arch-armada100/mfp.h
> index d21a79f..73783a7 100644
> --- a/arch/arm/include/asm/arch-armada100/mfp.h
> +++ b/arch/arm/include/asm/arch-armada100/mfp.h
> @@ -37,28 +37,32 @@
> * offset, pull,pF, drv,dF, edge,eF ,afn,aF
> */
> /* UART1 */
> -#define MFP107_UART1_TXD MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST
> -#define MFP107_UART1_RXD MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST
> -#define MFP108_UART1_RXD MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST
> -#define MFP108_UART1_TXD MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST
> -#define MFP109_UART1_CTS MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP109_UART1_RTS MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP110_UART1_RTS MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP110_UART1_CTS MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP111_UART1_RI MFP_REG(0x01bc) | MFP_AF1 |
> MFP_DRIVE_MEDIUM
> -#define MFP111_UART1_DSR MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP112_UART1_DTR MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP112_UART1_DCD MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM
> +#define MFP107_UART1_TXD (MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST)
> +#define MFP107_UART1_RXD (MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST)
> +#define MFP108_UART1_RXD (MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST)
> +#define MFP108_UART1_TXD (MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST)
> +#define MFP109_UART1_CTS (MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP109_UART1_RTS (MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP110_UART1_RTS (MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP110_UART1_CTS (MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP111_UART1_RI (MFP_REG(0x01bc) | MFP_AF1 |
> MFP_DRIVE_MEDIUM)
> +#define MFP111_UART1_DSR (MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP112_UART1_DTR (MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP112_UART1_DCD (MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM)
>
> /* UART2 */
> -#define MFP47_UART2_RXD MFP_REG(0x0028) | MFP_AF6 |
> MFP_DRIVE_MEDIUM
> -#define MFP48_UART2_TXD MFP_REG(0x002c) | MFP_AF6 |
> MFP_DRIVE_MEDIUM
> -#define MFP88_UART2_RXD MFP_REG(0x0160) | MFP_AF2 |
> MFP_DRIVE_MEDIUM
> -#define MFP89_UART2_TXD MFP_REG(0x0164) | MFP_AF2 |
> MFP_DRIVE_MEDIUM
> +#define MFP47_UART2_RXD (MFP_REG(0x0028) | MFP_AF6 |
> MFP_DRIVE_MEDIUM)
> +#define MFP48_UART2_TXD (MFP_REG(0x002c) | MFP_AF6 |
> MFP_DRIVE_MEDIUM)
&g
Re: [U-Boot] [PATCH V3 1/5] pxa: move i2c driver to the common place
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Thursday, March 17, 2011 12:15 PM > To: Heiko Schocher; Wolfgang Denk; Prafulla Wadaskar; u- > b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; > adrian.w...@gmail.com > Subject: [PATCH V3 1/5] 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 > --- > Changelog: > v2: rename previous pxa_i2c to mvi2c. > > V3: change previous name from pxa_i2c to mv_i2c > clean code style issue exist in original code > > arch/arm/cpu/pxa/Makefile |1 - > arch/arm/cpu/pxa/i2c.c| 469 -- > --- > drivers/i2c/Makefile |1 + > drivers/i2c/mv_i2c.c | 452 > +++ > include/configs/innokom.h |1 + > include/configs/xm250.h |1 + > 6 files changed, 455 insertions(+), 470 deletions(-) > delete mode 100644 arch/arm/cpu/pxa/i2c.c > create mode 100644 drivers/i2c/mv_i2c.c ...snip... > -#endif /* CONFIG_HARD_I2C */ > diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile > index 052fe36..00a12cc 100644 > --- a/drivers/i2c/Makefile > +++ b/drivers/i2c/Makefile > @@ -29,6 +29,7 @@ COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o > COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o > COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o > COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o > +COBJS-$(CONFIG_I2C_MV) += mv_i2c.o Mvtwsi and mv_i2c are two i2c drivers for Marvell. Can you merge these two? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/5] pxa: move i2c driver to the common place
> -Original Message- > From: Lei Wen [mailto:adrian.w...@gmail.com] > Sent: Tuesday, March 22, 2011 6:14 PM > To: Prafulla Wadaskar > Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek > Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: Re: [PATCH V3 1/5] pxa: move i2c driver to the common place > ...snip... > >> drivers/i2c/Makefile | 1 + > >> drivers/i2c/mv_i2c.c | 452 > >> +++ > >> include/configs/innokom.h | 1 + > >> include/configs/xm250.h | 1 + > >> 6 files changed, 455 insertions(+), 470 deletions(-) > >> delete mode 100644 arch/arm/cpu/pxa/i2c.c > >> create mode 100644 drivers/i2c/mv_i2c.c > > > > > > ...snip... > > > >> -#endif /* CONFIG_HARD_I2C */ > >> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile > >> index 052fe36..00a12cc 100644 > >> --- a/drivers/i2c/Makefile > >> +++ b/drivers/i2c/Makefile > >> @@ -29,6 +29,7 @@ COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o > >> COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o > >> COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o > >> COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o > >> +COBJS-$(CONFIG_I2C_MV) += mv_i2c.o > > > > Mvtwsi and mv_i2c are two i2c drivers for Marvell. > > Can you merge these two? > > As I explain to you before. Although kirkwood and pxa series are both > the product > of Marvell, but it don't necessary means that they must have the same > controller > for both product line. For the i2c part, they just use two different > controller. > So why you keep request merge those two? Do you mean you want to > create a unique I2C > framework for whole i2c drivers in drivers/i2c? Hi Lei 1. Most of i2c drivers supported in u-boot are either in SoC specific folder or in drivers/i2c folder, there is no as such thumb rule here. 2. Secondly all these drivers have some common code, mostly i2c_read, i2c_write, i2c_probe, etc.. 3. Specific to Marvell, we already have mvtwsi.c that supports Kirkwood and Orion5X SoCs. Whereas you are adding new mvi2c.c that will support armada100, pantheon apart from pxa. 4. What about if we need to support some new Marvell SoC with different i2C controller? Do we add one more driver? I would love if some one creates drivers/i2c/i2c_core.c??? not necessarily you ;-) Here is what I would like to suggest. 1. cmd_i2c mostly interfaced with i2c_probe, i2c_read, i2c_write, i2c_get_bun_num, i2c_set_bus_num, those should go in drivers/i2c_core.c 2. APIs like i2c_start, i2c_stop, i2c_send, i2c_recv, i2c_reset are more I2C controller specific and those will be different implementation on different SoCs, those can go in SoC specific i2c driver file. 3. all I2C driver files should be in drivers/i2c/ 4. i2c_read/write API need to be redefined since those are not generic to be used to access any I2C peripheral( most of the device don't need address to be programmed) 5. Flags must be provided for i2c_read/write APIs to have precise control to execute I2C_START/I2C_STOP sequence in the call. Since you are the one starting with re-using pxa driver for armada100 and Pantheon SoC, why don't you split it into i2c_core.c and i2c_pxa.c? then add i2c_armada100.c and i2c_pantheon.c? Others can migrate in the similar way. (even mvtwsi,c) Hi Heiko What do you think on this? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/5] pxa: move i2c driver to the common place
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Wednesday, March 23, 2011 2:23 PM > To: Lei Wen > Cc: Prafulla Wadaskar; Lei Wen; Wolfgang Denk; u-boot@lists.denx.de; > Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: Re: [PATCH V3 1/5] pxa: move i2c driver to the common place > > Hello Lei, > > Lei Wen wrote: > > Hi Heiko, > > > > On Wed, Mar 23, 2011 at 4:22 PM, Heiko Schocher wrote: > >> Hello Prafulla, > >> > >> Prafulla Wadaskar wrote: > >>>> -Original Message- > >>>> From: Lei Wen [mailto:adrian.w...@gmail.com] > >>>> Sent: Tuesday, March 22, 2011 6:14 PM > >>>> To: Prafulla Wadaskar > >>>> Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; > Marek > >>>> Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > >>>> Subject: Re: [PATCH V3 1/5] pxa: move i2c driver to the common > place > >>>> > >>> ...snip... > >>>>>> drivers/i2c/Makefile |1 + > >>>>>> drivers/i2c/mv_i2c.c | 452 > >>>>>> +++ > >>>>>> include/configs/innokom.h |1 + > >>>>>> include/configs/xm250.h |1 + > >>>>>> 6 files changed, 455 insertions(+), 470 deletions(-) > >>>>>> delete mode 100644 arch/arm/cpu/pxa/i2c.c > >>>>>> create mode 100644 drivers/i2c/mv_i2c.c > >>>>> ...snip... > >>>>> > >>>>>> -#endif /* CONFIG_HARD_I2C */ > >>>>>> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile > >>>>>> index 052fe36..00a12cc 100644 > >>>>>> --- a/drivers/i2c/Makefile > >>>>>> +++ b/drivers/i2c/Makefile > >>>>>> @@ -29,6 +29,7 @@ COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o > >>>>>> COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o > >>>>>> COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o > >>>>>> COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o > >>>>>> +COBJS-$(CONFIG_I2C_MV) += mv_i2c.o > >>>>> Mvtwsi and mv_i2c are two i2c drivers for Marvell. > >>>>> Can you merge these two? > >>>> As I explain to you before. Although kirkwood and pxa series are > both > >>>> the product > >>>> of Marvell, but it don't necessary means that they must have the > same > >>>> controller > >>>> for both product line. For the i2c part, they just use two > different > >>>> controller. > >>>> So why you keep request merge those two? Do you mean you want to > >>>> create a unique I2C > >>>> framework for whole i2c drivers in drivers/i2c? > >>> Hi Lei > >>> > >>> 1. Most of i2c drivers supported in u-boot are either in SoC > specific folder or in drivers/i2c folder, there is no as such thumb rule > here. > >> New drivers should go to drivers/i2c ! > >> The existing (old) drivers are just not moved ... > >> patches welcome! > >> > >>> 2. Secondly all these drivers have some common code, mostly > i2c_read, i2c_write, i2c_probe, etc.. > >>> 3. Specific to Marvell, we already have mvtwsi.c that supports > Kirkwood and Orion5X SoCs. Whereas you are adding new mvi2c.c that will > support armada100, pantheon apart from pxa. > >>> 4. What about if we need to support some new Marvell SoC with > different i2C controller? Do we add one more driver? > >>> > >>> I would love if some one creates drivers/i2c/i2c_core.c??? not > necessarily you ;-) > >>> > >>> Here is what I would like to suggest. > >>> 1. cmd_i2c mostly interfaced with i2c_probe, i2c_read, i2c_write, > i2c_get_bun_num, i2c_set_bus_num, those should go in drivers/i2c_core.c > >> Yep, but see below comment. > >> > >>> 2. APIs like i2c_start, i2c_stop, i2c_send, i2c_recv, i2c_reset are > more I2C controller specific and those will be different implementation > on different SoCs, those can go in SoC specific i2c driver file. > >> Yep. > >> > >>> 3. all I2C driver files should be in drivers/i2c/ > >> Yep. > >> > >>> 4. i2c_read/write API need to be redefined since those are not > generic to be used to access any I2C peripheral( most of the device > don't need address to be program
Re: [U-Boot] [PATCH V3 1/5] pxa: move i2c driver to the common place
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Wednesday, March 23, 2011 2:37 PM > To: Lei Wen > Cc: Prafulla Wadaskar; Lei Wen; Wolfgang Denk; u-boot@lists.denx.de; > Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: Re: [PATCH V3 1/5] pxa: move i2c driver to the common place > > Hello Lei, > > Lei Wen wrote: > > Hi Heiko, > > > > On Wed, Mar 23, 2011 at 4:53 PM, Heiko Schocher wrote: > >> Hello Lei, > >> > >> Lei Wen wrote: > >>> Hi Heiko, > >>> > >>> On Wed, Mar 23, 2011 at 4:22 PM, Heiko Schocher wrote: > >>>> Hello Prafulla, > >>>> > >>>> Prafulla Wadaskar wrote: > >>>>>> -Original Message- > >>>>>> From: Lei Wen [mailto:adrian.w...@gmail.com] > >>>>>> Sent: Tuesday, March 22, 2011 6:14 PM > >>>>>> To: Prafulla Wadaskar > >>>>>> Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; > Marek > >>>>>> Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > >>>>>> Subject: Re: [PATCH V3 1/5] pxa: move i2c driver to the common > place > >>>>>> > [...] > >>> Also my incoming mmc/sd enabling patch for pantheon and armada100 > >>> is also based on this i2c enabling patch, as I need the i2c to turn > on the > >>> repsonding pmic power connection. > >>> > >>> While we could get a i2c working pantheon, armada100, and other pxa > >>> series platform now with this patch set. So what about Could we > merge > >>> this first, and > >>> gradually change to the i2c framework, test and make it mature. > >> I am fine with that, but please address the other comments from > >> Prafulla and Wolfgang (rename defines, use standard accessors). > > > > Ok, I would post another round of patch to fix those issue Prafulla > and Wolfgang > > metioned. > > Ok, thanks! > > >> If you plan to investigate time for the multibus/multiadapter > >> i2c branch, let me know, maybe I can rebase this branch before > >> you use it. > > > > Currently, I have no bandwidth to do this... :( > > Maybe I would try to investigate when I have time. > > :-( > > Thats also my state ... please give me a notice, if you find some time, > so we can sync us ... Sorry I posted earlier email before checking this email. Even same the my state too :-) Well Let's lei get his stuff, we will think of migration latter :-( Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD-{Client,Ultimate}
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Albert ARIBAUD
> Sent: Friday, March 25, 2011 12:33 PM
> To: Clint Adams
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] OpenRD-{Client,Ultimate}
>
> Hi Clint,
>
> Le 25/03/2011 03:21, Clint Adams a écrit :
> > What is the status of the OpenRD-Ultimate support discussed last
> summer?
>
> AFAIK, there were patch proposals but no final patch. Feel free to look
> up the list archives, find the last post and bump the topic up by
> responding to it, Cc:ing relevant U-boot tree maintainers and the patch
> submitter; if there wasn't, then try to ping the submitter.
Today I received new patches from Julian, This is a good start point, Let's
review them.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Clint Adams > Sent: Saturday, March 26, 2011 3:32 AM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v2 0/4] Kirkwood: Add support for OpenRD- > Client & OpenRD-Ultimate > > Julian Pidancet wrote: > > A nice future improvement would be to add variant detection and > configuration > > at run-time as suggested on the mailing-list in a recent email. So one > could > > use the same binary for all board variants. > > Does anyone know offhand how to do this? I have heard rumors of a GPIO > method but I haven't found any details. 1. One possibility is to use some GPIOs and configure them on all board to detect the board version, read these GPIOs in the u-boot code and take board variant specific execution/configuration. 2. One can have similar approach keeping some data in separate EEPROM. 3. one can read availability of specific h/w on the board. Of which #3 will be better but may not be suitable for all boards variant. I personally do not like this method. Since there is always chance to have wrong configuration. I would always prefer to have build time configuration passing as per board variant. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5.1 1/6] io: add and* and or* operation api to set and clear bit
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Tuesday, March 29, 2011 8:24 AM
> To: Scott Wood; Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V5.1 1/6] io: add and* and or* operation api to set and
> clear bit
>
> Those api take use of read*/write* to align the current dmb usage.
> Also this could short the code length in one line.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> V3:
> V4:
> Move original driver specific bit set to the general place
>
> V5:
> fix code style issue
>
> V5.1:
> Add parentheses for the around incoming parameters to prevent
> parsing the complex expression wrong.
>
> arch/arm/include/asm/io.h |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 1fbc531..71e85e8 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -141,6 +141,14 @@ extern inline void __raw_readsl(unsigned int addr,
> void *data, int longlen)
> #define readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; })
> #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
>
> +#define orb(v, c) writeb(readb(c) | (v), c)
If I am not wrong, this should be like
#define orb(v, c) writeb((readb(c) | v), c)
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] Kirkwood: Rename openrd_base board files to openrd.
> -Original Message-
> From: Julian Pidancet [mailto:swaplin...@gmail.com] On Behalf Of
> julian.pidan...@citrix.com
> Sent: Friday, March 25, 2011 2:19 PM
> To: u-boot@lists.denx.de
> Cc: tanmay.upadh...@einfochips.com; Prafulla Wadaskar; Julian Pidancet
> Subject: [PATCH v2 1/4] Kirkwood: Rename openrd_base board files to
> openrd.
>
> From: Julian Pidancet
>
> This patch renames openrd_base to openrd in order to add support for
> other boards of the OpenRD family in future commits. The openrd_base
> board name remain in use.
>
> Signed-off-by: Julian Pidancet
>
> rename board/Marvell/{openrd_base => openrd}/Makefile (98%)
> rename board/Marvell/{openrd_base => openrd}/kwbimage.cfg (100%)
> rename board/Marvell/{openrd_base/openrd_base.c => openrd/openrd.c}
> (97%)
> rename board/Marvell/{openrd_base/openrd_base.h => openrd/openrd.h}
> (95%)
> create mode 100644 include/configs/openrd.h
>
> diff --git a/board/Marvell/openrd_base/Makefile
> b/board/Marvell/openrd/Makefile
> similarity index 98%
> rename from board/Marvell/openrd_base/Makefile
> rename to board/Marvell/openrd/Makefile
> index d6d0ed3..19020e4 100644
> --- a/board/Marvell/openrd_base/Makefile
> +++ b/board/Marvell/openrd/Makefile
> @@ -31,7 +31,7 @@ include $(TOPDIR)/config.mk
>
> LIB = $(obj)lib$(BOARD).o
>
> -COBJS:= openrd_base.o
> +COBJS:= openrd.o
>
> SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> OBJS := $(addprefix $(obj),$(COBJS))
> diff --git a/board/Marvell/openrd_base/kwbimage.cfg
> b/board/Marvell/openrd/kwbimage.cfg
> similarity index 100%
> rename from board/Marvell/openrd_base/kwbimage.cfg
> rename to board/Marvell/openrd/kwbimage.cfg
> diff --git a/board/Marvell/openrd_base/openrd_base.c
> b/board/Marvell/openrd/openrd.c
> similarity index 97%
> rename from board/Marvell/openrd_base/openrd_base.c
> rename to board/Marvell/openrd/openrd.c
> index 10109c1..b395df7 100644
> --- a/board/Marvell/openrd_base/openrd_base.c
> +++ b/board/Marvell/openrd/openrd.c
> @@ -31,7 +31,7 @@
> #include
> #include
> #include
> -#include "openrd_base.h"
> +#include "openrd.h"
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -110,7 +110,7 @@ int board_init(void)
> /*
>* arch number of board
>*/
> - gd->bd->bi_arch_number = MACH_TYPE_OPENRD_BASE;
> + gd->bd->bi_arch_number = MACH_TYPE_OPENRD;
NAK for this,
the MACH_TYPE for any board is coming form external world.
Tweaking it in u-boot is not recommended.
You can have conditional code here to use different predefined MACH_TYPES
instead of macros defining it.
...snip...
> diff --git a/boards.cfg b/boards.cfg
> index 45c3102..07c904b 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -96,7 +96,7 @@ davinci_sonata arm arm926ejs
> sonata davinci
> suen3arm arm926ejs km_arm
> keymilekirkwood
> guruplug arm arm926ejs -
> Marvellkirkwood
> mv88f6281gtw_ge arm arm926ejs -
> Marvellkirkwood
> -openrd_base arm arm926ejs -
> Marvellkirkwood
> +openrd_base arm arm926ejs openrd
> MarvellKirkwood
You can pass additional options here to identify your board uniquely out of
several supported boards (to be coming)
For ex:
+openrd_base arm arm926ejs openrd
+MarvellKirkwoodopenrd_common:BOARD_IS_OPENRD_BASE
This approach will help better way to add conditional code for other boards type
For more details refer syntax in the top of this file.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] Change OpenRD Base board identification string.
> -Original Message- > From: Julian Pidancet [mailto:swaplin...@gmail.com] On Behalf Of > julian.pidan...@citrix.com > Sent: Friday, March 25, 2011 2:19 PM > To: u-boot@lists.denx.de > Cc: tanmay.upadh...@einfochips.com; Prafulla Wadaskar; Julian Pidancet > Subject: [PATCH v2 2/4] Change OpenRD Base board identification string. > > From: Julian Pidancet > > Renamed from "Openrd_base" to "OpenRD-Base" > > Signed-off-by: Julian Pidancet > > diff --git a/include/configs/openrd_base.h > b/include/configs/openrd_base.h > index 136d3bf..ba57d90 100644 > --- a/include/configs/openrd_base.h > +++ b/include/configs/openrd_base.h > @@ -35,7 +35,7 @@ > /* > * Version number information > */ > -#define CONFIG_IDENT_STRING "\nOpenRD_base" > +#define CONFIG_IDENT_STRING "\nOpenRD-Base" > Ack Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] Add support for the Client variant of the OpenRD board.
> -Original Message- > From: Julian Pidancet [mailto:swaplin...@gmail.com] On Behalf Of > julian.pidan...@citrix.com > Sent: Friday, March 25, 2011 2:19 PM > To: u-boot@lists.denx.de > Cc: tanmay.upadh...@einfochips.com; Prafulla Wadaskar; Julian Pidancet > Subject: [PATCH v2 3/4] Add support for the Client variant of the OpenRD > board. > > From: Julian Pidancet > > This patch takes care of initializing the second PHY of the > OpenRD board. > > Signed-off-by: Julian Pidancet > > create mode 100644 include/configs/openrd_client.h > ...snip... > --- /dev/null > +++ b/include/configs/openrd_client.h > @@ -0,0 +1,44 @@ > +/* > + * 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., 51 Franklin Street, Fifth Floor, Boston, > + * MA 02110-1301 USA > + */ > + > +#ifndef _CONFIG_OPENRD_CLIENT_H > +#define _CONFIG_OPENRD_CLIENT_H > + > +#include > + > +/* > + * Version number information > + */ > +#define CONFIG_IDENT_STRING "\nOpenRD-Client" > + > +/* Machine type */ > +#define MACH_TYPE_OPENRD MACH_TYPE_OPENRD_CLIENT NAK for this Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 4/6] I2C: add i2c support for Pantheon platform
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Monday, March 28, 2011 12:24 PM > To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu > Tang; adrian.w...@gmail.com > Subject: [PATCH V5 4/6] I2C: add i2c support for Pantheon platform > > Add i2c support to dkb board with pantheon soc. > > Signed-off-by: Lei Wen > --- > Changelog: > V2: > NO CHANGE > > V3: > clean code sytle issue > Add i2c clock enable code include in I2C configure define block > > V4: > make i2c definition included in the ifdef > > V5: > NO CHANGE > > arch/arm/cpu/arm926ejs/pantheon/cpu.c| 12 > arch/arm/include/asm/arch-pantheon/cpu.h |4 +++- > arch/arm/include/asm/arch-pantheon/mfp.h |6 -- > board/Marvell/dkb/dkb.c |4 > include/configs/dkb.h| 13 + > 5 files changed, 36 insertions(+), 3 deletions(-) > ...snip... > diff --git a/include/configs/dkb.h b/include/configs/dkb.h > index 638af5e..599c8b8 100644 > --- a/include/configs/dkb.h > +++ b/include/configs/dkb.h > @@ -56,6 +56,19 @@ > #include "mv-common.h" > > #undef CONFIG_ARCH_MISC_INIT > + > +/* > + * I2C definition > + */ > +#define CONFIG_CMD_I2C This command definition should be moved up (below #include Otherwise ack for rest of the code Regards.. Prafulla . . > +#ifdef 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 > +#endif > + > /* > * 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 V5 6/6] I2C: add i2c support for Armada100 platform
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Monday, March 28, 2011 12:24 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V5 6/6] I2C: add i2c support for Armada100 platform
>
> Add i2c support to aspenite board with Armada100 soc.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code sytle issue
> Add i2c clock enable code include in I2C configure define block
>
> V4:
> make i2c definition include in the ifdef
>
> V5:
> NO CHANGE
>
> arch/arm/cpu/arm926ejs/armada100/cpu.c| 16 +++
> arch/arm/include/asm/arch-armada100/mfp.h | 40 --
> ---
> board/Marvell/aspenite/aspenite.c |5 +++
> include/configs/aspenite.h| 14 ++
> 4 files changed, 57 insertions(+), 18 deletions(-)
...snip...
> /*
> + * I2C definition
> + */
> +#define CONFIG_CMD_I2C 1
Same here, move up with other command configs.
> +#ifdef CONFIG_CMD_I2C
> +#define CONFIG_I2C_MV1
> +#define CONFIG_PXA_I2C_NUM 2
> +#define CONFIG_I2C_MULTI_BUS 1
> +#define CONFIG_PXA_I2C_REG {0xd4011000, 0xd4025000}
> +#define CONFIG_HARD_I2C 1
> +#define CONFIG_SYS_I2C_SPEED 0
> +#define CONFIG_SYS_I2C_SLAVE 0xfe
> +#endif
> +
> +/*
> * Environment variables configurations
> */
> #define CONFIG_ENV_IS_NOWHERE1 /* if env in SDRAM */
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 3/6] mv_i2c: use structure to replace the direclty define
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Monday, March 28, 2011 12:24 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V5 3/6] mv_i2c: use structure to replace the direclty
> define
>
> Add i2c_clk_enable in the cpu specific code, since previous platform it,
> while new platform don't need. In the pantheon and armada100 platform,
> this function is defined as NULL one.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code sytle issue
>
> V4:
> V5:
> NO CHANGE
>
> arch/arm/cpu/pxa/cpu.c | 11 +++
> arch/arm/include/asm/arch-pxa/pxa-regs.h | 56 -
> board/innokom/innokom.c |9 +--
> drivers/i2c/mv_i2c.c | 131 ++-
> ---
> drivers/i2c/mv_i2c.h | 83 +++
> include/configs/innokom.h|1 +
> include/configs/xm250.h |1 +
> 7 files changed, 159 insertions(+), 133 deletions(-)
> create mode 100644 drivers/i2c/mv_i2c.h
>
...snip...
> diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
> index 09756a4..734148b 100644
> --- a/drivers/i2c/mv_i2c.c
> +++ b/drivers/i2c/mv_i2c.c
> @@ -8,6 +8,9 @@
> * (C) Copyright 2003 Pengutronix e.K.
> * Robert Schwebel
> *
> + * (C) Copyright 2011 Marvell Inc.
> + * Lei Wen
> + *
> * See file CREDITS for list of people who contributed to this
> * project.
> *
> @@ -34,24 +37,8 @@
> #include
>
> #ifdef CONFIG_HARD_I2C
> -
> -/*
> - * - CONFIG_SYS_I2C_SPEED
> - * - I2C_PXA_SLAVE_ADDR
> - */
> -
> -#include
> -#include
> #include
> -
> -#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
> +#include "mv_i2c.h"
>
> #ifdef DEBUG_I2C
> #define PRINTD(x) printf x
> @@ -59,20 +46,6 @@
> #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;
> @@ -81,27 +54,37 @@ struct i2c_msg {
> u8 data;
> };
>
> +struct pxa_i2c {
> + u32 ibmr;
> + u32 pad0;
> + u32 idbr;
> + u32 pad1;
> + u32 icr;
> + u32 pad2;
> + u32 isr;
> + u32 pad3;
> + u32 isar;
> +};
(Optional to implement)
It is better if you can push register structure definition to the SoC specific
header file, so that if there are new SoC that has different register
structures that can be addressed cleanly.
> +
> +static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
> +
> /*
> * 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 */
> + andl(~ICR_IUE, &base->icr); /* disable unit */
> + orl(ICR_UR, &base->icr);/* reset the unit */
Apart from discussion going on for patch - [PATCH V5.1 1/6] io: add and* and
or* operation api to set and clear bit
The original code looks more readable to me.
> 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_IU
Re: [U-Boot] [PATCH] Kirkwood: SATA supports only one device per bus
> -Original Message- > From: Gray Remlin [mailto:gryr...@gmail.com] > Sent: Wednesday, March 30, 2011 1:12 AM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Gray Remlin > Subject: [PATCH] Kirkwood: SATA supports only one device per bus > > Change CONFIG_SYS_IDE_MAXDEVICE from 2 to 1 Kirkwood supports max 2 Why do you want this change? Regards.. Prafulla .. > > Signed-off-by: Gray Remlin > --- > arch/arm/include/asm/arch-kirkwood/config.h |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/include/asm/arch-kirkwood/config.h > b/arch/arm/include/asm/arch-kirkwood/config.h > index 71ba464..f582ba4 100644 > --- a/arch/arm/include/asm/arch-kirkwood/config.h > +++ b/arch/arm/include/asm/arch-kirkwood/config.h > @@ -128,7 +128,8 @@ > #define CONFIG_LBA48 > /* CONFIG_CMD_IDE requires some #defines for ATA registers */ > #define CONFIG_SYS_IDE_MAXBUS2 > -#define CONFIG_SYS_IDE_MAXDEVICE 2 > +/* Only one device per bus on SATA */ > +#define CONFIG_SYS_IDE_MAXDEVICE 1 > /* ATA registers base is at SATA controller base */ > #define CONFIG_SYS_ATA_BASE_ADDR MV_SATA_BASE > #endif /* CONFIG_CMD_IDE */ > -- > 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: SATA supports only one device per bus
> -Original Message- > From: Prafulla Wadaskar > Sent: Wednesday, March 30, 2011 4:48 PM > To: 'Gray Remlin' > Cc: u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare > Subject: RE: [PATCH] Kirkwood: SATA supports only one device per bus > > > > > -Original Message- > > From: Gray Remlin [mailto:gryr...@gmail.com] > > Sent: Wednesday, March 30, 2011 1:12 AM > > To: Prafulla Wadaskar > > Cc: u-boot@lists.denx.de; Gray Remlin > > Subject: [PATCH] Kirkwood: SATA supports only one device per bus > > > > Change CONFIG_SYS_IDE_MAXDEVICE from 2 to 1 > > Kirkwood supports max 2 > Why do you want this change? Hi Gray I take back my words. I will study more and let you know my comments on this. Sorry for noise. Regards.. Prafulla . . > > Regards.. > Prafulla .. > > > > > Signed-off-by: Gray Remlin > > --- > > arch/arm/include/asm/arch-kirkwood/config.h |3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-kirkwood/config.h > > b/arch/arm/include/asm/arch-kirkwood/config.h > > index 71ba464..f582ba4 100644 > > --- a/arch/arm/include/asm/arch-kirkwood/config.h > > +++ b/arch/arm/include/asm/arch-kirkwood/config.h > > @@ -128,7 +128,8 @@ > > #define CONFIG_LBA48 > > /* CONFIG_CMD_IDE requires some #defines for ATA registers */ > > #define CONFIG_SYS_IDE_MAXBUS 2 > > -#define CONFIG_SYS_IDE_MAXDEVICE 2 > > +/* Only one device per bus on SATA */ > > +#define CONFIG_SYS_IDE_MAXDEVICE 1 > > /* ATA registers base is at SATA controller base */ > > #define CONFIG_SYS_ATA_BASE_ADDR MV_SATA_BASE > > #endif /* CONFIG_CMD_IDE */ > > -- > > 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 3/6] mv_i2c: use structure to replace the direclty define
> -Original Message-
> From: Lei Wen [mailto:adrian.w...@gmail.com]
> Sent: Wednesday, March 30, 2011 7:42 PM
> To: Prafulla Wadaskar
> Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek
> Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang
> Subject: Re: [PATCH V5 3/6] mv_i2c: use structure to replace the
> direclty define
>
> Hi Prafulla,
>
> On Tue, Mar 29, 2011 at 9:27 PM, Prafulla Wadaskar
> wrote:
> >
> >
> >> -Original Message-
> >> From: Lei Wen [mailto:lei...@marvell.com]
> >> Sent: Monday, March 28, 2011 12:24 PM
> >> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> >> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik;
> Yu
> >> Tang; adrian.w...@gmail.com
> >> Subject: [PATCH V5 3/6] mv_i2c: use structure to replace the direclty
> >> define
> >>
> >> Add i2c_clk_enable in the cpu specific code, since previous platform
> it,
> >> while new platform don't need. In the pantheon and armada100
> platform,
> >> this function is defined as NULL one.
> >>
> >> Signed-off-by: Lei Wen
> >> ---
> >> Changelog:
> >> V2:
> >> NO CHANGE
> >>
> >> V3:
> >> clean code sytle issue
> >>
> >> V4:
> >> V5:
> >> NO CHANGE
> >>
> >> arch/arm/cpu/pxa/cpu.c | 11 +++
> >> arch/arm/include/asm/arch-pxa/pxa-regs.h | 56 -
> >> board/innokom/innokom.c | 9 +--
> >> drivers/i2c/mv_i2c.c | 131 ++--
> ---
> >> ---
> >> drivers/i2c/mv_i2c.h | 83 +++
> >> include/configs/innokom.h | 1 +
> >> include/configs/xm250.h | 1 +
> >> 7 files changed, 159 insertions(+), 133 deletions(-)
> >> create mode 100644 drivers/i2c/mv_i2c.h
> >>
> > ...snip...
> >> diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
> >> index 09756a4..734148b 100644
> >> --- a/drivers/i2c/mv_i2c.c
> >> +++ b/drivers/i2c/mv_i2c.c
> >> @@ -8,6 +8,9 @@
> >> * (C) Copyright 2003 Pengutronix e.K.
> >> * Robert Schwebel
> >> *
> >> + * (C) Copyright 2011 Marvell Inc.
> >> + * Lei Wen
> >> + *
> >> * See file CREDITS for list of people who contributed to this
> >> * project.
> >> *
> >> @@ -34,24 +37,8 @@
> >> #include
> >>
> >> #ifdef CONFIG_HARD_I2C
> >> -
> >> -/*
> >> - * - CONFIG_SYS_I2C_SPEED
> >> - * - I2C_PXA_SLAVE_ADDR
> >> - */
> >> -
> >> -#include
> >> -#include
> >> #include
> >> -
> >> -#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
> >> +#include "mv_i2c.h"
> >>
> >> #ifdef DEBUG_I2C
> >> #define PRINTD(x) printf x
> >> @@ -59,20 +46,6 @@
> >> #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_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;
> >> @@ -81,27 +54,37 @@ struct i2c_msg {
> >> u8 data;
> >> };
> >>
> >> +struct pxa_i2c {
> >> + u32 ibmr;
> >> + u32 pad0;
> >> + u32 idbr;
> >> + u32 pad1;
> >> + u32 icr;
> >> + u32 pad2;
> >> + u32 isr;
> >> + u32 pad3;
> >> + u32 isar;
Re: [U-Boot] [PATCH V5 4/6] I2C: add i2c support for Pantheon platform
> -Original Message- > From: Lei Wen [mailto:adrian.w...@gmail.com] > Sent: Wednesday, March 30, 2011 7:36 PM > To: Prafulla Wadaskar > Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek > Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: Re: [PATCH V5 4/6] I2C: add i2c support for Pantheon platform > > Hi Prafulla, > > On Tue, Mar 29, 2011 at 9:07 PM, Prafulla Wadaskar > wrote: > > > > > >> -Original Message- > >> From: Lei Wen [mailto:lei...@marvell.com] > >> Sent: Monday, March 28, 2011 12:24 PM > >> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > >> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; > Yu > >> Tang; adrian.w...@gmail.com > >> Subject: [PATCH V5 4/6] I2C: add i2c support for Pantheon platform > >> > >> Add i2c support to dkb board with pantheon soc. > >> > >> Signed-off-by: Lei Wen > >> --- > >> Changelog: > >> V2: > >> NO CHANGE > >> > >> V3: > >> clean code sytle issue > >> Add i2c clock enable code include in I2C configure define block > >> > >> V4: > >> make i2c definition included in the ifdef > >> > >> V5: > >> NO CHANGE > >> > >> arch/arm/cpu/arm926ejs/pantheon/cpu.c | 12 > >> arch/arm/include/asm/arch-pantheon/cpu.h | 4 +++- > >> arch/arm/include/asm/arch-pantheon/mfp.h | 6 -- > >> board/Marvell/dkb/dkb.c | 4 > >> include/configs/dkb.h | 13 + > >> 5 files changed, 36 insertions(+), 3 deletions(-) > >> > > ...snip... > > > >> diff --git a/include/configs/dkb.h b/include/configs/dkb.h > >> index 638af5e..599c8b8 100644 > >> --- a/include/configs/dkb.h > >> +++ b/include/configs/dkb.h > >> @@ -56,6 +56,19 @@ > >> #include "mv-common.h" > >> > >> #undef CONFIG_ARCH_MISC_INIT > >> + > >> +/* > >> + * I2C definition > >> + */ > >> +#define CONFIG_CMD_I2C > > > > This command definition should be moved up (below #include > > > I'm ok to put this define to the config_cmd_default.h, but this mean > many other platform need > which didn't not need the i2c but include the , > need to undef the i2c now. > Does that worth the change? I don't mean here to put it in to the config_cmd_default.h I means put it below #include line where other commands are defined/undefed. Regards.. Prafulla . . > > Best regards, > Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: SATA supports only one device per bus
> -Original Message- > From: Gray Remlin [mailto:gryr...@gmail.com] > Sent: Wednesday, March 30, 2011 7:21 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] Kirkwood: SATA supports only one device per bus > > On 03/30/2011 12:21 PM, Prafulla Wadaskar wrote: > > > >> -Original Message- > >> From: Prafulla Wadaskar > >> Sent: Wednesday, March 30, 2011 4:48 PM > >> To: 'Gray Remlin' > >> Cc: u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare > >> Subject: RE: [PATCH] Kirkwood: SATA supports only one device per bus > >> > >> > >> > >>> -Original Message- > >>> From: Gray Remlin [mailto:gryr...@gmail.com] > >>> Sent: Wednesday, March 30, 2011 1:12 AM > >>> To: Prafulla Wadaskar > >>> Cc: u-boot@lists.denx.de; Gray Remlin > >>> Subject: [PATCH] Kirkwood: SATA supports only one device per bus > >>> > >>> Change CONFIG_SYS_IDE_MAXDEVICE from 2 to 1 > >> Kirkwood supports max 2 > >> Why do you want this change? > > Hi Gray > > I take back my words. I will study more and let you know my comments > on this. > > Sorry for noise. > > > > Regards.. > > Prafulla . . > > > >> Regards.. > >> Prafulla .. > >> > >>> Signed-off-by: Gray Remlin > >>> --- > >>> arch/arm/include/asm/arch-kirkwood/config.h |3 ++- > >>> 1 files changed, 2 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/arch/arm/include/asm/arch-kirkwood/config.h > >>> b/arch/arm/include/asm/arch-kirkwood/config.h > >>> index 71ba464..f582ba4 100644 > >>> --- a/arch/arm/include/asm/arch-kirkwood/config.h > >>> +++ b/arch/arm/include/asm/arch-kirkwood/config.h > >>> @@ -128,7 +128,8 @@ > >>> #define CONFIG_LBA48 > >>> /* CONFIG_CMD_IDE requires some #defines for ATA registers */ > >>> #define CONFIG_SYS_IDE_MAXBUS 2 > >>> -#define CONFIG_SYS_IDE_MAXDEVICE 2 > >>> +/* Only one device per bus on SATA */ > >>> +#define CONFIG_SYS_IDE_MAXDEVICE 1 > >>> /* ATA registers base is at SATA controller base */ > >>> #define CONFIG_SYS_ATA_BASE_ADDRMV_SATA_BASE > >>> #endif /* CONFIG_CMD_IDE */ > >>> -- > >>> 1.7.4 > Hi Prafulla, > > This one was a bit of a judgement call. > You are absolutely correct in what you say that Kirkwood supports two, > but > to the best of my knowledge, no one has yet implemented a board using > both busses (I am not that familiar with OpenRD, I may have to eat my > words). OpenRD-Base board has two, one e-sata for external hdd and one sata for onboard hdd interface, I am using them :-) Regards.. Prafulla . . > > For the sheevaplug, guruplug & dreamplug, it is definitely the case that > only > one device can be attached. > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 2/5] mv_i2c: use structure to replace the direclty define
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 31, 2011 2:07 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V6 2/5] mv_i2c: use structure to replace the direclty
> define
>
> Add i2c_clk_enable in the cpu specific code, since previous platform it,
> while new platform don't need. In the pantheon and armada100 platform,
> this function is defined as NULL one.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code sytle issue
>
> V4:
> V5:
> V6:
> NO CHANGE
>
> arch/arm/cpu/pxa/cpu.c | 11 +++
> arch/arm/include/asm/arch-pxa/pxa-regs.h | 56 -
> board/innokom/innokom.c |9 +--
> drivers/i2c/mv_i2c.c | 131 ++-
> ---
> drivers/i2c/mv_i2c.h | 83 +++
> include/configs/innokom.h|1 +
> include/configs/xm250.h |1 +
> 7 files changed, 159 insertions(+), 133 deletions(-)
> create mode 100644 drivers/i2c/mv_i2c.h
>
> 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); */
This comment line looks like part of code, Can be rephrased in better way.
> + writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
> +#else /* CONFIG_CPU_MONAHANS */
> + /* set the global I2C clock on */
> + writel(readl(CKEN) | CKEN14_I2C, CKEN);
> +#endif
> +}
...snip...
> @@ -81,27 +54,37 @@ struct i2c_msg {
> u8 data;
> };
>
> +struct pxa_i2c {
> + u32 ibmr;
> + u32 pad0;
> + u32 idbr;
> + u32 pad1;
> + u32 icr;
> + u32 pad2;
> + u32 isr;
> + u32 pad3;
> + u32 isar;
> +};
> +
> +static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
I think to sync with mc_i2c change at least the macro CONFIG_PXA_I2C_REG
Need to be renamed as CONFIG_MV_I2C_REG, because the same will be referred by
other SoC code.
> +
> /*
> * i2c_pxa_reset: - reset the host controller
> *
> */
...snip...
> @@ -114,13 +97,15 @@ static void i2c_reset(void)
> static int i2c_isr_set_cleared(unsigned long set_mask,
> unsigned long cleared_mask)
> {
> - int timeout = 1;
> + int timeout = 1000, isr;
Is this done purposely? Or reducing timeout value from 1 to 1000 has some
meaning?
>
> - while (((ISR & set_mask) != set_mask) || ((ISR & cleared_mask) !=
> 0)) {
> + do {
> + isr = readl(&base->isr);
> udelay(10);
> if (timeout-- < 0)
> return 0;
> - }
> + } while (((isr & set_mask) != set_mask)
> + || ((isr & cleared_mask) != 0));
>
> return 1;
> }
> @@ -153,26 +138,26 @@ int i2c_transfer(struct i2c_msg *msg)
> goto transfer_error_bus_busy;
>
> /* start transmission */
> - writel(readl(ICR) & ~ICR_START, ICR);
> - writel(readl(ICR) & ~ICR_STOP, ICR);
> - writel(msg->data, IDBR);
> + writel(readl(&base->icr) & ~ICR_START, &base->icr);
> + writel(readl(&base->icr) & ~ICR_STOP, &base->icr);
> + writel(msg->data, &base->idbr);
> if (msg->condition == I2C_COND_START)
> - writel(readl(ICR) | ICR_START, ICR);
> + writel(readl(&base->icr) | ICR_START, &base->icr);
> if (msg->condition == I2C_COND_STOP)
> - writel(readl(ICR) | ICR_STOP, ICR);
> + writel(readl(&base->icr) | ICR_STOP, &base->icr);
> if (msg->acknack == I2C_ACKNAK_SENDNAK)
> - writel(readl(ICR) | ICR_ACKNAK, ICR);
> + writel(readl(&base->icr) | ICR_ACKNAK, &base->icr);
> if (msg->acknack == I2C_ACKNAK_SENDACK)
> - writel(readl(ICR) & ~ICR_ACKNAK, ICR);
> - writel(readl(ICR) & ~ICR_ALDIE, ICR);
> - writel(readl(ICR) | ICR_TB, ICR);
> +
Re: [U-Boot] [PATCH V6 3/5] I2C: add i2c support for Pantheon platform
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 31, 2011 2:07 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V6 3/5] I2C: add i2c support for Pantheon platform
>
> Add i2c support to dkb board with pantheon soc.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code sytle issue
> Add i2c clock enable code include in I2C configure define block
>
> V4:
> make i2c definition included in the ifdef
>
> V5:
> NO CHANGE
>
> V6:
> Move the CONFIG_CMD_I2C define place
>
> arch/arm/cpu/arm926ejs/pantheon/cpu.c| 12
> arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
> arch/arm/include/asm/arch-pantheon/mfp.h |6 --
> board/Marvell/dkb/dkb.c |4
> include/configs/dkb.h| 13 +
> 5 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> index 9ddc77c..8b2eafa 100644
> --- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
> @@ -59,6 +59,12 @@ int arch_cpu_init(void)
> /* Enable GPIO clock */
> writel(APBC_APBCLK, &apbclkres->gpio);
>
> +#ifdef CONFIG_I2C_MV
> + /* Enable I2C clock */
> + writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> + writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
> +#endif
> +
> icache_enable();
>
> return 0;
> @@ -76,3 +82,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..e939196 100644
> --- a/arch/arm/include/asm/arch-pantheon/mfp.h
> +++ b/arch/arm/include/asm/arch-pantheon/mfp.h
> @@ -32,8 +32,10 @@
> * offset, pull,pF, drv,dF, edge,eF ,afn,aF
> */
> /* 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 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)
>
> /* 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..c893a9d 100644
> --- a/include/configs/dkb.h
> +++ b/include/configs/dkb.h
> @@ -47,6 +47,7 @@
> #define CONFIG_SYS_NO_FLASH /* Declare no flash (NOR/SPI) */
> #include
> #define CONFIG_CMD_AUTOSCRIPT
> +#define CONFIG_CMD_I2C
> #undef CONFIG_CMD_NET
> #undef CONFIG_CMD_NFS
> /*
> @@ -56,6 +57,18 @@
> #include "mv-common.h"
>
> #undef CONFIG_ARCH_MISC_INIT
> +
> +/*
> + * I2C definition
> + */
> +#ifdef CONFIG_CMD_I2C
> +#define CONFIG_I2C_MV1
> +#define CONFIG_PXA_I2C_REG 0xd4011000
PXA looks invalid reference here, should be MV.
> +#define CONFIG_HARD_I2C 1
> +#define CONFIG_SYS_I2C_SPEED 0
> +#define CONFIG_SYS_I2C_SLAVE 0xfe
> +#endif
Sorry being not reported earlier.
But this #ifdefed code should be in mv-common.h or so that it
can be shared across all the boards supported by the same SoC or IP.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 4/5] I2C: mv_i2c: add multi bus support
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 31, 2011 2:07 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V6 4/5] I2C: mv_i2c: add multi bus support
>
> Add the ability to support multiple i2c bus for mv_i2c
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code style issue
>
> V4:
> V5:
> V6:
> NO CHANGE
>
> drivers/i2c/mv_i2c.c | 36 +++-
> 1 files changed, 35 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
> index 3f145de..3a3f7d7 100644
> --- a/drivers/i2c/mv_i2c.c
> +++ b/drivers/i2c/mv_i2c.c
> @@ -66,7 +66,35 @@ struct pxa_i2c {
> u32 isar;
> };
>
> -static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_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;
> +
> +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
> @@ -235,6 +263,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
> */
Ack, except s/PXA/MV/g
Regards..
Prafulla . .
> --
> 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 V6 5/5] I2C: add i2c support for Armada100 platform
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Thursday, March 31, 2011 2:07 PM
> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject: [PATCH V6 5/5] I2C: add i2c support for Armada100 platform
>
> Add i2c support to aspenite board with Armada100 soc.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> V2:
> NO CHANGE
>
> V3:
> clean code style issue
>
> V4:
> V5:
> NO CHANGE
>
> V6:
> Move the CONFIG_CMD_I2C define place
>
> arch/arm/cpu/arm926ejs/armada100/cpu.c| 16 +++
> arch/arm/include/asm/arch-armada100/mfp.h | 40 --
> ---
> board/Marvell/aspenite/aspenite.c |5 +++
> include/configs/aspenite.h| 14 ++
> 4 files changed, 57 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c
> b/arch/arm/cpu/arm926ejs/armada100/cpu.c
> index 62aa175..c21938e 100644
> --- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
> @@ -62,6 +62,16 @@ int arch_cpu_init(void)
> /* Enable GPIO clock */
> writel(APBC_APBCLK, &apb1clkres->gpio);
>
> +#ifdef CONFIG_I2C_MV
> + /* 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);
> +#endif
> +
> /*
>* Enable Functional and APB clock at 14.7456MHz
>* for configured UART console
> @@ -90,3 +100,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..73783a7 100644
> --- a/arch/arm/include/asm/arch-armada100/mfp.h
> +++ b/arch/arm/include/asm/arch-armada100/mfp.h
> @@ -37,28 +37,32 @@
> * offset, pull,pF, drv,dF, edge,eF ,afn,aF
> */
> /* UART1 */
> -#define MFP107_UART1_TXD MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST
> -#define MFP107_UART1_RXD MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST
> -#define MFP108_UART1_RXD MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST
> -#define MFP108_UART1_TXD MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST
> -#define MFP109_UART1_CTS MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP109_UART1_RTS MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP110_UART1_RTS MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP110_UART1_CTS MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP111_UART1_RI MFP_REG(0x01bc) | MFP_AF1 |
> MFP_DRIVE_MEDIUM
> -#define MFP111_UART1_DSR MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM
> -#define MFP112_UART1_DTR MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM
> -#define MFP112_UART1_DCD MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM
> +#define MFP107_UART1_TXD (MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST)
> +#define MFP107_UART1_RXD (MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST)
> +#define MFP108_UART1_RXD (MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST)
> +#define MFP108_UART1_TXD (MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST)
> +#define MFP109_UART1_CTS (MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP109_UART1_RTS (MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP110_UART1_RTS (MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP110_UART1_CTS (MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP111_UART1_RI (MFP_REG(0x01bc) | MFP_AF1 |
> MFP_DRIVE_MEDIUM)
> +#define MFP111_UART1_DSR (MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM)
> +#define MFP112_UART1_DTR (MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM)
> +#define MFP112_UART1_DCD (MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM)
>
> /* UART2 */
> -#define MFP47_UART2_RXD MFP_REG(0x0028) | MFP_AF6 |
> MFP_DRIVE_MEDIUM
> -#define MFP48_UART2_TXD MFP_REG(0x002c) | MFP_AF6 |
> MFP_DRIVE_MEDIUM
> -#define MFP88_UART2_RXD MFP_REG(0x0160) | MFP_AF2 |
> MFP_DRIVE_MEDIUM
> -#define MFP89_UART2_TXD MFP_REG(0x0164) | MFP_AF2 |
> MFP_DRIVE_MEDIUM
> +#define MFP47_UART2_RXD (MFP_REG(0x0028) | MFP_AF6 |
> MFP_DRIVE_MEDIUM)
> +#define MFP48_UART2_
Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size access
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Lei Wen > Sent: Friday, April 01, 2011 8:04 PM > To: Wolfgang Denk > Cc: Lei Wen; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size > access > > Hi Wolfgang, > > On Fri, Apr 1, 2011 at 10:25 PM, Wolfgang Denk wrote: > > Dear Lei Wen, > > > > In message q5inqiqpeddkh1dxuar1h_5wenaes...@mail.gmail.com> you wrote: > >> > >> >> > I don't think so. You still use just a single writel() call > then. To > >> >> > leave the other bits untouched, you would have to perform a > readl() > >> >> > first, then insert one data byte, and then write it back. Your > patch > >> >> > does not do that. > >> >> > >> >> My original patch is like below, so where it call writel?... > >> >> +#elif (CONFIG_SYS_NS16550_REG_SIZE == 1) || > (CONFIG_SYS_NS16550_REG_SIZE == -1) > >> >> +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED > >> >> +#define serial_out(x, y) outb(x, y) > >> >> +#define serial_in(y) inb(y) > >> >> +#else > >> >> +#define serial_out(x, y) writeb(x, y) > >> >> +#define serial_in(y) readb(y) > >> > > >> > If you use writeb() [as the current driver would do as well}, then > how > >> > do you expect to set this bit 8 (which is in the next byte) to 0 as > >> > you claim you have to? > >> > >> As I explain, if set CONFIG_SYS_NS16550_REG_SIZE to 4, and > >> set CONFIG_SYS_NS16550_MAX_REG_SIZE also to 4, then the serial_out > >> becomes writel. :) > > > > Right - which is exactly what I said, and which you denied. > > > > I give up, I have other things to do as well. > > Just a question to clarify... What your point I denied, that is really > confused me... > I think in this thread, I explain to you, my patch could recover what > original > CONFIG_SYS_NS16550_REG_SIZE means... > > Since you reject, I have nothing else to say... Hi Lei I understood this thread correctly as- 1. ns16550 is standard IP used across several SoC and has driver in place. 2. Your specific implementation of the same IP on your specific SoC need bit9 or x register to be set to 0 to work this IP correctly on your h/w. 3. but doing in ns16550 driver may brake other implementations. (correct me if I am wrong) So what I suggest here- 1. do not disturb/touch nx16550 driver at all. 2. write a small init code in cpu.c (specific to this SoC/arch) to reset this bit only. This would be straight forward and will satisfy your need and acceptance too. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Initialize second PHY on OpenRD-Client and OpenRD-Ultimate.
> -Original Message-
> From: Clint Adams [mailto:cl...@debian.org]
> Sent: Thursday, April 07, 2011 12:25 AM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; julian.pidan...@citrix.com; Clint Adams
> Subject: [PATCH 2/2] Initialize second PHY on OpenRD-Client and OpenRD-
> Ultimate.
>
> (rework of Julian Pidancet's patch)
> ---
> board/Marvell/openrd_base/openrd_base.c | 22 ++
> include/configs/openrd_base.h | 14 --
> 2 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/board/Marvell/openrd_base/openrd_base.c
> b/board/Marvell/openrd_base/openrd_base.c
> index 10109c1..aea4760 100644
> --- a/board/Marvell/openrd_base/openrd_base.c
> +++ b/board/Marvell/openrd_base/openrd_base.c
> @@ -118,12 +118,11 @@ int board_init(void)
> }
>
> #ifdef CONFIG_RESET_PHY_R
> -/* Configure and enable MV88E1116 PHY */
> -void reset_phy(void)
> +/* Configure and enable MV88E1116/88E1121 PHY */
> +void mv_phy_init(char *name)
> {
> u16 reg;
> u16 devadr;
> - char *name = "egiga0";
>
> if (miiphy_set_current_dev(name))
> return;
> @@ -148,6 +147,21 @@ void reset_phy(void)
> /* reset the phy */
> miiphy_reset(name, devadr);
>
> - printf("88E1116 Initialized on %s\n", name);
> + printf(PHY_NO" Initialized on %s\n", name);
> +}
> +
> +void reset_phy(void)
> +{
> + mv_phy_init("egiga0");
> +
> +#ifdef CONFIG_BOARD_IS_OPENRD_CLIENT
> + /* Kirkwood ethernet driver is written with the assumption that
> in case
> +* of multiple PHYs, their addresses are consecutive. But
> unfortunately
> +* in case of OpenRD-Client, PHY addresses are not
> consecutive.*/
> + miiphy_write("egiga1", 0xEE, 0xEE, 24);
> +
> + /* configure and initialize both PHY's */
> + mv_phy_init("egiga1");
> +#endif
> }
> #endif /* CONFIG_RESET_PHY_R */
> diff --git a/include/configs/openrd_base.h
> b/include/configs/openrd_base.h
> index 5e05890..aa13908 100644
> --- a/include/configs/openrd_base.h
> +++ b/include/configs/openrd_base.h
> @@ -117,8 +117,18 @@
> * Ethernet Driver configuration
> */
> #ifdef CONFIG_CMD_NET
> -#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> -#define CONFIG_PHY_BASE_ADR 0x8
> +# ifdef CONFIG_BOARD_IS_OPENRD_BASE
> +# define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> +# else
> +# define CONFIG_MVGBE_PORTS {1, 1} /* enable both ports */
> +# endif
> +# ifdef CONFIG_BOARD_IS_OPENRD_ULTIMATE
> +# define CONFIG_PHY_BASE_ADR0x0
> +# define PHY_NO "88E1121"
> +# else
> +# define CONFIG_PHY_BASE_ADR0x8
> +# define PHY_NO "88E1116"
> +# endif
> #endif /* CONFIG_CMD_NET */
>
This looks pretty good.
Ack for both the patches.
Regards..
Prafulla ..
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 0/6] add i2c support to pantheon and aramada100
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Tuesday, April 05, 2011 1:31 PM > To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu > Tang; adrian.w...@gmail.com > Subject: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > V2: > rename the previous pxa_i2c to mvi2c, since this driver would be shared > by many other Marvell platforms. > > V3: > Clean the code sytle issue > > V4: > add and* and or* to make set bit operation generic > Also make i2c definition included in the ifdef > > V5: > Fix code style issue of the first patch > > V6: > Seperate the and* and or* patch out of the patch set > Move CONFIG_CMD_I2C define place > > V7: > Fix comments style > Make global change from PXA to MV > Move i2c config setting to > > V8: > Seperate timeout fix patch out > > Lei Wen (6): > pxa: move i2c driver to the common place > mv_i2c: fix timeout value to be consistent with comments > mv_i2c: use structure to replace the direclty define > I2C: add i2c support for Pantheon platform > I2C: mv_i2c: add multi bus support > I2C: add i2c support for Armada100 platform I am okay with this patch series. I will pull them on this week end. Meanwhile further comments if any are welcomed. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/km: change default settings for egiga on mgcoge3un
> -Original Message- > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] > Sent: Friday, April 08, 2011 6:18 PM > To: u-boot@lists.denx.de > Cc: holger.bru...@keymile.com; h...@denx.de; Wolfgang Denk; Detlev Zundel; > Prafulla Wadaskar; Valentin Longchamp > Subject: [PATCH] arm/km: change default settings for egiga on mgcoge3un > > From: Holger Brunck > > The reason we need this is that we have the gig port on mgcoge3un > connected using a back-to-back pair of PHYs. There are no magnetics and > because of that the port has to be run with a fixd configuration and > auto-negotiation must be disabled. In the default mode the egiga driver > uses autoneg to determine port speed - which defaults to 1G (we need > 100M full duplex). > > Signed-off-by: Holger Brunck > Acked-by: Heiko Schocher > cc: Wolfgang Denk > cc: Detlev Zundel > cc: Prafulla Wadaskar > cc: Valentin Longchamp > Signed-off-by: Valentin Longchamp > --- > drivers/net/mvgbe.h |2 ++ > include/configs/mgcoge3un.h | 25 + > 2 files changed, 27 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/mvgbe.h b/drivers/net/mvgbe.h > index 3de98d0..d8a5429 100644 > --- a/drivers/net/mvgbe.h > +++ b/drivers/net/mvgbe.h > @@ -84,6 +84,7 @@ > MVGBE_TX_BURST_SIZE_16_64BIT) > > /* Default port serial control value */ > +#ifndef PORT_SERIAL_CONTROL_VALUE > #define PORT_SERIAL_CONTROL_VALUE( \ > MVGBE_FORCE_LINK_PASS | \ > MVGBE_DIS_AUTO_NEG_FOR_DUPLX| \ > @@ -101,6 +102,7 @@ > MVGBE_CLR_EXT_LOOPBACK | \ > MVGBE_SET_FULL_DUPLEX_MODE | \ > MVGBE_DIS_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX) > +#endif > > /* Tx WRR confoguration macros */ > #define PORT_MAX_TRAN_UNIT 0x24/* MTU register (default) 9KByte */ > diff --git a/include/configs/mgcoge3un.h b/include/configs/mgcoge3un.h > index da5935b..c7f9056 100644 > --- a/include/configs/mgcoge3un.h > +++ b/include/configs/mgcoge3un.h > @@ -48,6 +48,31 @@ > #define KM_ENV_BUS "pca9547:70:d" /* I2C2 (Mux-Port 5)*/ > > /* > + * mgcoge3un has a fixed link to the marvell switch > + * with 100MB full duplex and autoneg off, for this > + * reason we have to change the default settings > + */ > +#define PORT_SERIAL_CONTROL_VALUE( \ > + MVGBE_FORCE_LINK_PASS | \ > + MVGBE_DIS_AUTO_NEG_FOR_DUPLX| \ > + MVGBE_DIS_AUTO_NEG_FOR_FLOW_CTRL| \ > + MVGBE_ADV_NO_FLOW_CTRL | \ > + MVGBE_FORCE_FC_MODE_NO_PAUSE_DIS_TX | \ > + MVGBE_FORCE_BP_MODE_NO_JAM | \ > + (1 << 9) /* Reserved bit has to be 1 */ | \ > + MVGBE_DO_NOT_FORCE_LINK_FAIL| \ > + MVGBE_DIS_AUTO_NEG_SPEED_GMII | \ > + MVGBE_DTE_ADV_0 | \ > + MVGBE_MIIPHY_MAC_MODE | \ > + MVGBE_AUTO_NEG_NO_CHANGE| \ > + MVGBE_MAX_RX_PACKET_1552BYTE| \ > + MVGBE_CLR_EXT_LOOPBACK | \ > + MVGBE_SET_FULL_DUPLEX_MODE | \ > + MVGBE_DIS_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX|\ > + MVGBE_SET_GMII_SPEED_TO_10_100 |\ > + MVGBE_SET_MII_SPEED_TO_100) > + > +/* > * Default environment variables > */ > #define CONFIG_EXTRA_ENV_SETTINGS Acked-by: Prafulla Wadaskar Regards.. Prafulla . . \ > -- > 1.7.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/km: add mkimage config file for uart download
> -Original Message- > From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] > Sent: Friday, April 08, 2011 6:18 PM > To: u-boot@lists.denx.de > Cc: holger.bru...@keymile.com; h...@denx.de; Valentin Longchamp; Wolfgang > Denk; Detlev Zundel; Prafulla Wadaskar > Subject: [PATCH] arm/km: add mkimage config file for uart download > > Signed-off-by: Valentin Longchamp > Signed-off-by: Holger Brunck > Acked-by: Heiko Schocher > cc: Wolfgang Denk > cc: Detlev Zundel > cc: Prafulla Wadaskar > --- > board/keymile/km_arm/kwbimage-uart.cfg | 179 > > 1 files changed, 179 insertions(+), 0 deletions(-) > create mode 100644 board/keymile/km_arm/kwbimage-uart.cfg > > diff --git a/board/keymile/km_arm/kwbimage-uart.cfg > b/board/keymile/km_arm/kwbimage-uart.cfg > new file mode 100644 > index 000..d8c517c > --- /dev/null > +++ b/board/keymile/km_arm/kwbimage-uart.cfg > @@ -0,0 +1,179 @@ > +# > +# (C) Copyright 2010 > +# Heiko Schocher, DENX Software Engineering, h...@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., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301 USA > +# > +# Refer docs/README.kwimage for more details about how-to configure > +# and create kirkwood boot image > +# > + > +# Boot Media configurations > +BOOT_FROMuart# Boot from SPI flash Comments are wrong here.. I think this is more over debug support. i.e. if you want to bring up broken board with the help of UART. Does it makes sense to mainline? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Keymile boards mainlining, part 2
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Valentin Longchamp > Sent: Friday, April 08, 2011 6:23 PM > To: u-boot@lists.denx.de > Cc: h...@denx.de; holger.bru...@keymile.com > Subject: Re: [U-Boot] [PATCH] Keymile boards mainlining, part 2 > > Sorry, the whole series is not numbered, -N statt -n ... it will be > corrected for the very likely v2 of the series posting. It would be good if you can split patch series in to small group as per functionality/SoC, so that it is easy to pull. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Initialize second PHY on OpenRD-Client and OpenRD-Ultimate.
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, April 07, 2011 12:48 PM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; Clint Adams
> Subject: Re: [U-Boot] [PATCH 2/2] Initialize second PHY on OpenRD-Client
> and OpenRD-Ultimate.
>
> Le 07/04/2011 08:17, Prafulla Wadaskar a écrit :
> >
> >
> >> -Original Message-
> >> From: Clint Adams [mailto:cl...@debian.org]
> >> Sent: Thursday, April 07, 2011 12:25 AM
> >> To: u-boot@lists.denx.de
> >> Cc: Prafulla Wadaskar; julian.pidan...@citrix.com; Clint Adams
> >> Subject: [PATCH 2/2] Initialize second PHY on OpenRD-Client and
> OpenRD-
> >> Ultimate.
> >>
> >> (rework of Julian Pidancet's patch)
> >> ---
> >> board/Marvell/openrd_base/openrd_base.c | 22 ++--
> --
> >> include/configs/openrd_base.h | 14 --
> >> 2 files changed, 30 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/board/Marvell/openrd_base/openrd_base.c
> >> b/board/Marvell/openrd_base/openrd_base.c
> >> index 10109c1..aea4760 100644
> >> --- a/board/Marvell/openrd_base/openrd_base.c
> >> +++ b/board/Marvell/openrd_base/openrd_base.c
> >> @@ -118,12 +118,11 @@ int board_init(void)
> >> }
> >>
> >> #ifdef CONFIG_RESET_PHY_R
> >> -/* Configure and enable MV88E1116 PHY */
> >> -void reset_phy(void)
> >> +/* Configure and enable MV88E1116/88E1121 PHY */
> >> +void mv_phy_init(char *name)
> >> {
> >>u16 reg;
> >>u16 devadr;
> >> - char *name = "egiga0";
> >>
> >>if (miiphy_set_current_dev(name))
> >>return;
> >> @@ -148,6 +147,21 @@ void reset_phy(void)
> >>/* reset the phy */
> >>miiphy_reset(name, devadr);
> >>
> >> - printf("88E1116 Initialized on %s\n", name);
> >> + printf(PHY_NO" Initialized on %s\n", name);
> >> +}
> >> +
> >> +void reset_phy(void)
> >> +{
> >> + mv_phy_init("egiga0");
> >> +
> >> +#ifdef CONFIG_BOARD_IS_OPENRD_CLIENT
> >> + /* Kirkwood ethernet driver is written with the assumption
> that
> >> in case
> >> +* of multiple PHYs, their addresses are consecutive. But
> >> unfortunately
> >> +* in case of OpenRD-Client, PHY addresses are not
> >> consecutive.*/
> >> + miiphy_write("egiga1", 0xEE, 0xEE, 24);
> >> +
> >> + /* configure and initialize both PHY's */
> >> + mv_phy_init("egiga1");
> >> +#endif
> >> }
> >> #endif /* CONFIG_RESET_PHY_R */
> >> diff --git a/include/configs/openrd_base.h
> >> b/include/configs/openrd_base.h
> >> index 5e05890..aa13908 100644
> >> --- a/include/configs/openrd_base.h
> >> +++ b/include/configs/openrd_base.h
> >> @@ -117,8 +117,18 @@
> >>* Ethernet Driver configuration
> >>*/
> >> #ifdef CONFIG_CMD_NET
> >> -#define CONFIG_MVGBE_PORTS{1, 0} /* enable port 0 only */
> >> -#define CONFIG_PHY_BASE_ADR 0x8
> >> +# ifdef CONFIG_BOARD_IS_OPENRD_BASE
> >> +# define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> >> +# else
> >> +# define CONFIG_MVGBE_PORTS {1, 1} /* enable both ports */
> >> +# endif
> >> +# ifdef CONFIG_BOARD_IS_OPENRD_ULTIMATE
> >> +# define CONFIG_PHY_BASE_ADR 0x0
> >> +# define PHY_NO "88E1121"
> >> +# else
> >> +# define CONFIG_PHY_BASE_ADR 0x8
> >> +# define PHY_NO "88E1116"
> >> +# endif
> >> #endif /* CONFIG_CMD_NET */
> >>
> >
> > This looks pretty good.
> > Ack for both the patches.
> >
> > Regards..
> > Prafulla ..
>
> Didn't Julian re-post patches that actually separates Base, Client and
> Ultimate into distinct config header files plus a common one? How does
> this affect Clint's patchset?
I acked for the method used here.
We don't need separate config headers. Using CONFIG_BOARD_IS_OPENRD_* the
boards related stuff can be identified.
To me this looks better that what Julian had posted
I have tested these patches and works for openRD-Base, certainly it may not
work for ultimate and client since respective machine ids are not programmed.
Hi Julian/Clint
May you please provide tuned version of these patches?
Regards..
Prafulla . .
>
> Amicalement,
> --
> Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Initialize second PHY on OpenRD-Client and OpenRD-Ultimate.
> -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Monday, April 11, 2011 6:15 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Clint Adams; Julian Pidancet > Subject: Re: [U-Boot] [PATCH 2/2] Initialize second PHY on OpenRD-Client > and OpenRD-Ultimate. > > Hi Prafulle, > > Le 11/04/2011 14:03, Prafulla Wadaskar a écrit : > > >>>>board/Marvell/openrd_base/openrd_base.c | 22 > ++-- > >> -- > >>>>include/configs/openrd_base.h | 14 -- > > >> Didn't Julian re-post patches that actually separates Base, Client > and > >> Ultimate into distinct config header files plus a common one? How > does > >> this affect Clint's patchset? > > > > I acked for the method used here. > > > > We don't need separate config headers. Using CONFIG_BOARD_IS_OPENRD_* > the boards related stuff can be identified. > > If the two files above are to be used for all Open-RD boards (which is > fine for me), then they should be renamed from openrd_base.* to openrd.* > for the sake of clarity as to what they actually support. Ack, I hope this will be addressed in next version. Regards.. Prafulla . . > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 0/6] add i2c support to pantheon and aramada100
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Tuesday, April 05, 2011 1:31 PM > To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu > Tang; adrian.w...@gmail.com > Subject: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > V2: > rename the previous pxa_i2c to mvi2c, since this driver would be shared > by many other Marvell platforms. > > V3: > Clean the code sytle issue > > V4: > add and* and or* to make set bit operation generic > Also make i2c definition included in the ifdef > > V5: > Fix code style issue of the first patch > > V6: > Seperate the and* and or* patch out of the patch set > Move CONFIG_CMD_I2C define place > > V7: > Fix comments style > Make global change from PXA to MV > Move i2c config setting to > > V8: > Seperate timeout fix patch out > > Lei Wen (6): > pxa: move i2c driver to the common place > mv_i2c: fix timeout value to be consistent with comments > mv_i2c: use structure to replace the direclty define > I2C: add i2c support for Pantheon platform > I2C: mv_i2c: add multi bus support > I2C: add i2c support for Armada100 platform > > arch/arm/cpu/arm926ejs/armada100/cpu.c | 16 + > arch/arm/cpu/arm926ejs/pantheon/cpu.c| 12 + > arch/arm/cpu/pxa/Makefile|1 - > arch/arm/cpu/pxa/cpu.c | 10 + > arch/arm/cpu/pxa/i2c.c | 469 --- > -- > arch/arm/include/asm/arch-armada100/config.h | 12 + > arch/arm/include/asm/arch-armada100/mfp.h| 40 ++- > arch/arm/include/asm/arch-pantheon/config.h | 10 + > arch/arm/include/asm/arch-pantheon/cpu.h |4 +- > arch/arm/include/asm/arch-pantheon/mfp.h |6 +- > 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/mv_i2c.c | 481 > ++ > drivers/i2c/mv_i2c.h | 83 + > include/configs/aspenite.h |1 + > include/configs/dkb.h|2 + > include/configs/innokom.h|2 + > include/configs/xm250.h |2 + > 21 files changed, 671 insertions(+), 555 deletions(-) > delete mode 100644 arch/arm/cpu/pxa/i2c.c > create mode 100644 drivers/i2c/mv_i2c.c > create mode 100644 drivers/i2c/mv_i2c.h Dear Lei I have trying to apply this patch series to u-boot-marvell.git master branch. Since I have rebased this branch to latest u-boot-arm.git master. This patch series cannot be cleanly applied. Can you pls provide new one in sync with latest pull from u-boot-marvell.git master branch? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: enable the reception of packets with an odd number of preamble nibbles
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Wolfgang Denk > Sent: Wednesday, April 13, 2011 12:20 AM > To: Klaus Flittner > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] mvgbe: enable the reception of packets > with an odd number of preamble nibbles > > Dear Klaus Flittner, > > In message <20110131204025.1ffb0...@earth.lan> you wrote: > > With the current hardware initialisation of the driver all packets > with > > an odd number of preamble nibbles are dropped. Some switches seem to > > send all packets with such an preamble. > > > > According to the functional specifications of the marvell 88F6180, > > 6190, 6192 and 6281 the reception of such packets can be enabled by > > setting bit 22 in register PSC1. Klaus Flittner Do you thing setting this by default will not disturb functionality on other hardware? If so, how about encapsulating it in #ifdef with SYS_CONFIG_xx ? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Rename openrd_base files to openrd.
> -Original Message- > From: Clint Adams [mailto:cl...@debian.org] > Sent: Wednesday, April 13, 2011 12:14 AM > To: u-boot@lists.denx.de > Cc: Prafulla Wadaskar; julian.pidan...@citrix.com; Clint Adams > Subject: [PATCH 3/3] Rename openrd_base files to openrd. > > --- > board/Marvell/openrd/Makefile | 56 ++ > board/Marvell/openrd/kwbimage.cfg | 168 > + > board/Marvell/openrd/openrd.c | 175 > +++ > board/Marvell/openrd/openrd.h | 46 > board/Marvell/openrd_base/Makefile | 56 -- > board/Marvell/openrd_base/kwbimage.cfg | 168 > - > board/Marvell/openrd_base/openrd_base.c | 175 > --- > board/Marvell/openrd_base/openrd_base.h | 46 > boards.cfg |6 +- > include/configs/openrd.h| 142 > + > include/configs/openrd_base.h | 142 > - > 11 files changed, 590 insertions(+), 590 deletions(-) > create mode 100644 board/Marvell/openrd/Makefile > create mode 100644 board/Marvell/openrd/kwbimage.cfg > create mode 100644 board/Marvell/openrd/openrd.c > create mode 100644 board/Marvell/openrd/openrd.h > delete mode 100644 board/Marvell/openrd_base/Makefile > delete mode 100644 board/Marvell/openrd_base/kwbimage.cfg > delete mode 100644 board/Marvell/openrd_base/openrd_base.c > delete mode 100644 board/Marvell/openrd_base/openrd_base.h > create mode 100644 include/configs/openrd.h > delete mode 100644 include/configs/openrd_base.h I think it would be good if you make this your first patch in the patch series, then rest of the code changes looks more relevant. Also take care of additional suggestions form Albert about incremental versioning, change logs, and git-rename for delete/create logs Also keep practice of adding some more information for patch description in the beginning of each patch. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Initialize second PHY on OpenRD-Client and OpenRD-Ultimate.
> -Original Message-
> From: Clint Adams [mailto:cl...@debian.org]
> Sent: Wednesday, April 13, 2011 12:14 AM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; julian.pidan...@citrix.com; Clint Adams
> Subject: [PATCH 2/3] Initialize second PHY on OpenRD-Client and OpenRD-
> Ultimate.
>
> (rework of Julian Pidancet's patch)
> ---
> board/Marvell/openrd_base/openrd_base.c | 24
> include/configs/openrd_base.h | 14 --
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/board/Marvell/openrd_base/openrd_base.c
> b/board/Marvell/openrd_base/openrd_base.c
> index f7c63ac..cb0f0fe 100644
> --- a/board/Marvell/openrd_base/openrd_base.c
> +++ b/board/Marvell/openrd_base/openrd_base.c
> @@ -124,12 +124,11 @@ int board_init(void)
> }
>
> #ifdef CONFIG_RESET_PHY_R
> -/* Configure and enable MV88E1116 PHY */
> -void reset_phy(void)
> +/* Configure and enable MV88E1116/88E1121 PHY */
> +void mv_phy_init(char *name)
> {
> u16 reg;
> u16 devadr;
> - char *name = "egiga0";
>
> if (miiphy_set_current_dev(name))
> return;
> @@ -154,6 +153,23 @@ void reset_phy(void)
> /* reset the phy */
> miiphy_reset(name, devadr);
>
> - printf("88E1116 Initialized on %s\n", name);
> + printf(PHY_NO" Initialized on %s\n", name);
> +}
> +
> +void reset_phy(void)
> +{
> + mv_phy_init("egiga0");
> +
> +#ifdef CONFIG_BOARD_IS_OPENRD_CLIENT
> + /* Kirkwood ethernet driver is written with the assumption that
> in case
> +* of multiple PHYs, their addresses are consecutive. But
> unfortunately
> +* in case of OpenRD-Client, PHY addresses are not
> consecutive.*/
> + miiphy_write("egiga1", 0xEE, 0xEE, 24);
> +#endif
> +
> +#if defined(CONFIG_BOARD_IS_OPENRD_CLIENT) ||
> defined(CONFIG_BOARD_IS_OPENRD_ULTIMATE)
The line is too long >80 chars
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 0/6] add i2c support to pantheon and aramada100
> -Original Message- > From: Lei Wen [mailto:adrian.w...@gmail.com] > Sent: Wednesday, April 13, 2011 7:44 PM > To: Prafulla Wadaskar > Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek > Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: Re: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > Hi Prafulla, > > On Wed, Apr 13, 2011 at 10:01 PM, Prafulla Wadaskar > wrote: > > > > > >> -Original Message- > >> From: Lei Wen [mailto:lei...@marvell.com] > >> Sent: Tuesday, April 05, 2011 1:31 PM > >> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > >> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; > Yu > >> Tang; adrian.w...@gmail.com > >> Subject: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > >> > >> V2: > >> rename the previous pxa_i2c to mvi2c, since this driver would be > shared > >> by many other Marvell platforms. > >> > >> V3: > >> Clean the code sytle issue > >> > >> V4: > >> add and* and or* to make set bit operation generic > >> Also make i2c definition included in the ifdef > >> > >> V5: > >> Fix code style issue of the first patch > >> > >> V6: > >> Seperate the and* and or* patch out of the patch set > >> Move CONFIG_CMD_I2C define place > >> > >> V7: > >> Fix comments style > >> Make global change from PXA to MV > >> Move i2c config setting to > >> > >> V8: > >> Seperate timeout fix patch out > >> > >> Lei Wen (6): > >> pxa: move i2c driver to the common place > >> mv_i2c: fix timeout value to be consistent with comments > >> mv_i2c: use structure to replace the direclty define > >> I2C: add i2c support for Pantheon platform > >> I2C: mv_i2c: add multi bus support > >> I2C: add i2c support for Armada100 platform > >> > >> arch/arm/cpu/arm926ejs/armada100/cpu.c | 16 + > >> arch/arm/cpu/arm926ejs/pantheon/cpu.c | 12 + > >> arch/arm/cpu/pxa/Makefile | 1 - > >> arch/arm/cpu/pxa/cpu.c | 10 + > >> arch/arm/cpu/pxa/i2c.c | 469 > --- > >> -- > >> arch/arm/include/asm/arch-armada100/config.h | 12 + > >> arch/arm/include/asm/arch-armada100/mfp.h | 40 ++- > >> arch/arm/include/asm/arch-pantheon/config.h | 10 + > >> arch/arm/include/asm/arch-pantheon/cpu.h | 4 +- > >> arch/arm/include/asm/arch-pantheon/mfp.h | 6 +- > >> 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/mv_i2c.c | 481 > >> ++ > >> drivers/i2c/mv_i2c.h | 83 + > >> include/configs/aspenite.h | 1 + > >> include/configs/dkb.h | 2 + > >> include/configs/innokom.h | 2 + > >> include/configs/xm250.h | 2 + > >> 21 files changed, 671 insertions(+), 555 deletions(-) > >> delete mode 100644 arch/arm/cpu/pxa/i2c.c > >> create mode 100644 drivers/i2c/mv_i2c.c > >> create mode 100644 drivers/i2c/mv_i2c.h > > > > Dear Lei > > I have trying to apply this patch series to u-boot-marvell.git master > branch. > > Since I have rebased this branch to latest u-boot-arm.git master. > > > > This patch series cannot be cleanly applied. > > > > Can you pls provide new one in sync with latest pull from u-boot- > marvell.git master branch? > > > > I just apply those patch on master branch without any warning. > Are you apply the V8 series? Yes, I am using V8 patches. Have you done git pull before that? What is your latest git log? (before applying patches) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 0/6] add i2c support to pantheon and aramada100
> -Original Message- > From: Prafulla Wadaskar > Sent: Wednesday, April 13, 2011 7:57 PM > To: 'Lei Wen' > Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek > Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > Subject: RE: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > > > > -Original Message- > > From: Lei Wen [mailto:adrian.w...@gmail.com] > > Sent: Wednesday, April 13, 2011 7:44 PM > > To: Prafulla Wadaskar > > Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; > Marek > > Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang > > Subject: Re: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > > > Hi Prafulla, > > > > On Wed, Apr 13, 2011 at 10:01 PM, Prafulla Wadaskar > > wrote: > > > > > > > > >> -----Original Message- > > >> From: Lei Wen [mailto:lei...@marvell.com] > > >> Sent: Tuesday, April 05, 2011 1:31 PM > > >> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > > >> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan > Sarnaik; > > Yu > > >> Tang; adrian.w...@gmail.com > > >> Subject: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > >> > > >> V2: > > >> rename the previous pxa_i2c to mvi2c, since this driver would be > > shared > > >> by many other Marvell platforms. > > >> > > >> V3: > > >> Clean the code sytle issue > > >> > > >> V4: > > >> add and* and or* to make set bit operation generic > > >> Also make i2c definition included in the ifdef > > >> > > >> V5: > > >> Fix code style issue of the first patch > > >> > > >> V6: > > >> Seperate the and* and or* patch out of the patch set > > >> Move CONFIG_CMD_I2C define place > > >> > > >> V7: > > >> Fix comments style > > >> Make global change from PXA to MV > > >> Move i2c config setting to > > >> > > >> V8: > > >> Seperate timeout fix patch out > > >> > > >> Lei Wen (6): > > >> pxa: move i2c driver to the common place > > >> mv_i2c: fix timeout value to be consistent with comments > > >> mv_i2c: use structure to replace the direclty define > > >> I2C: add i2c support for Pantheon platform > > >> I2C: mv_i2c: add multi bus support > > >> I2C: add i2c support for Armada100 platform > > >> > > >> arch/arm/cpu/arm926ejs/armada100/cpu.c | 16 + > > >> arch/arm/cpu/arm926ejs/pantheon/cpu.c | 12 + > > >> arch/arm/cpu/pxa/Makefile | 1 - > > >> arch/arm/cpu/pxa/cpu.c | 10 + > > >> arch/arm/cpu/pxa/i2c.c | 469 -- > -- > > --- > > >> -- > > >> arch/arm/include/asm/arch-armada100/config.h | 12 + > > >> arch/arm/include/asm/arch-armada100/mfp.h | 40 ++- > > >> arch/arm/include/asm/arch-pantheon/config.h | 10 + > > >> arch/arm/include/asm/arch-pantheon/cpu.h | 4 +- > > >> arch/arm/include/asm/arch-pantheon/mfp.h | 6 +- > > >> 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/mv_i2c.c | 481 > > >> ++ > > >> drivers/i2c/mv_i2c.h | 83 + > > >> include/configs/aspenite.h | 1 + > > >> include/configs/dkb.h | 2 + > > >> include/configs/innokom.h | 2 + > > >> include/configs/xm250.h | 2 + > > >> 21 files changed, 671 insertions(+), 555 deletions(-) > > >> delete mode 100644 arch/arm/cpu/pxa/i2c.c > > >> create mode 100644 drivers/i2c/mv_i2c.c > > >> create mode 100644 drivers/i2c/mv_i2c.h > > > > > > Dear Lei > > > I have trying to apply this patch series to u-boot-marvell.git > master > > branch. > > > Since I have rebased this branch to latest u-boot-arm.git master. > > > > > > This patch series cannot be cleanly applied. > > > > > > Can you pls provide new one in sync with latest pull from u-boot- > > marvell.git master branch? > > > > > > > I just apply those patch on master branch without any warning. > > Are you apply the V8 series? > > Yes, I am using V8 patches. > Have you done git pull before that? > What is your latest git log? (before applying patches) Sorry for the noise Lei. I could apply them cleanly. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 0/6] add i2c support to pantheon and aramada100
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Tuesday, April 05, 2011 1:31 PM > To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u- > b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu > Tang; adrian.w...@gmail.com > Subject: [PATCH V8 0/6] add i2c support to pantheon and aramada100 > > V2: > rename the previous pxa_i2c to mvi2c, since this driver would be shared > by many other Marvell platforms. > > V3: > Clean the code sytle issue > > V4: > add and* and or* to make set bit operation generic > Also make i2c definition included in the ifdef > > V5: > Fix code style issue of the first patch > > V6: > Seperate the and* and or* patch out of the patch set > Move CONFIG_CMD_I2C define place > > V7: > Fix comments style > Make global change from PXA to MV > Move i2c config setting to > > V8: > Seperate timeout fix patch out > > Lei Wen (6): > pxa: move i2c driver to the common place > mv_i2c: fix timeout value to be consistent with comments > mv_i2c: use structure to replace the direclty define > I2C: add i2c support for Pantheon platform > I2C: mv_i2c: add multi bus support > I2C: add i2c support for Armada100 platform > > arch/arm/cpu/arm926ejs/armada100/cpu.c | 16 + > arch/arm/cpu/arm926ejs/pantheon/cpu.c| 12 + > arch/arm/cpu/pxa/Makefile|1 - > arch/arm/cpu/pxa/cpu.c | 10 + > arch/arm/cpu/pxa/i2c.c | 469 --- > -- > arch/arm/include/asm/arch-armada100/config.h | 12 + > arch/arm/include/asm/arch-armada100/mfp.h| 40 ++- > arch/arm/include/asm/arch-pantheon/config.h | 10 + > arch/arm/include/asm/arch-pantheon/cpu.h |4 +- > arch/arm/include/asm/arch-pantheon/mfp.h |6 +- > 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/mv_i2c.c | 481 > ++ > drivers/i2c/mv_i2c.h | 83 + > include/configs/aspenite.h |1 + > include/configs/dkb.h|2 + > include/configs/innokom.h|2 + > include/configs/xm250.h |2 + > 21 files changed, 671 insertions(+), 555 deletions(-) > delete mode 100644 arch/arm/cpu/pxa/i2c.c > create mode 100644 drivers/i2c/mv_i2c.c > create mode 100644 drivers/i2c/mv_i2c.h Applied this patch series to u-boot-marvell.git master branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] Orion5x: Correct DRAM bank detection
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of ro...@dawes.za.net
> Sent: Friday, March 18, 2011 1:40 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 1/7] Orion5x: Correct DRAM bank detection
>
> From: Rogan Dawes
>
> ---
> arch/arm/cpu/arm926ejs/orion5x/dram.c |2 +-
> arch/arm/include/asm/arch-orion5x/orion5x.h |1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/orion5x/dram.c
> b/arch/arm/cpu/arm926ejs/orion5x/dram.c
> index b749282..2ae8f48 100644
> --- a/arch/arm/cpu/arm926ejs/orion5x/dram.c
> +++ b/arch/arm/cpu/arm926ejs/orion5x/dram.c
> @@ -38,7 +38,7 @@ u32 orion5x_sdram_bar(enum memory_bank bank)
> {
> struct orion5x_ddr_addr_decode_registers *winregs =
> (struct orion5x_ddr_addr_decode_registers *)
> - ORION5X_CPU_WIN_BASE;
> + ORION5X_DRAM_BASE;
>
> u32 result = 0;
> u32 enable = 0x01 & winregs[bank].size;
> diff --git a/arch/arm/include/asm/arch-orion5x/orion5x.h
> b/arch/arm/include/asm/arch-orion5x/orion5x.h
> index e3d3f76..1dd9f65 100644
> --- a/arch/arm/include/asm/arch-orion5x/orion5x.h
> +++ b/arch/arm/include/asm/arch-orion5x/orion5x.h
> @@ -42,6 +42,7 @@
> #define ORION5X_REGISTER(x) (ORION5X_REGS_PHY_BASE + x)
>
> /* Documented registers */
> +#define ORION5X_DRAM_BASE(ORION5X_REGISTER(0x01500))
> #define ORION5X_TWSI_BASE(ORION5X_REGISTER(0x11000))
> #define ORION5X_UART0_BASE (ORION5X_REGISTER(0x12000))
> #define ORION5X_UART1_BASE (ORION5X_REGISTER(0x12100))
> --
> 1.7.1
Applied to u-boot-marvell.git master branch
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-marvell.git
Hi Albert Please kindly pull The following changes since commit 531bb02c0bfc783e95f1b761f18e15d6f565e357: Fabio Estevam (1): MX25: tx25: Add _end section on nand_spl are available in the git repository at: u-boot-marvell.git master branch Lei Wen (6): pxa: move i2c driver to the common place mv_i2c: fix timeout value to be consistent with comments mv_i2c: use structure to replace the direclty define I2C: add i2c support for Pantheon platform I2C: mv_i2c: add multi bus support I2C: add i2c support for Armada100 platform Rogan Dawes (1): Orion5x: Correct DRAM bank detection arch/arm/cpu/arm926ejs/armada100/cpu.c | 16 ++ arch/arm/cpu/arm926ejs/orion5x/dram.c |2 +- arch/arm/cpu/arm926ejs/pantheon/cpu.c | 12 + arch/arm/cpu/pxa/Makefile |1 - arch/arm/cpu/pxa/cpu.c | 10 + arch/arm/include/asm/arch-armada100/config.h | 12 + arch/arm/include/asm/arch-armada100/mfp.h | 40 ++-- arch/arm/include/asm/arch-orion5x/orion5x.h|1 + arch/arm/include/asm/arch-pantheon/config.h| 10 + arch/arm/include/asm/arch-pantheon/cpu.h |4 +- arch/arm/include/asm/arch-pantheon/mfp.h |6 +- 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 + arch/arm/cpu/pxa/i2c.c => drivers/i2c/mv_i2c.c | 294 --- drivers/i2c/mv_i2c.h | 83 +++ include/configs/aspenite.h |1 + include/configs/dkb.h |2 + include/configs/innokom.h |2 + include/configs/xm250.h|2 + 22 files changed, 345 insertions(+), 228 deletions(-) rename arch/arm/cpu/pxa/i2c.c => drivers/i2c/mv_i2c.c (65%) create mode 100644 drivers/i2c/mv_i2c.h Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] Initialize second PHY on OpenRD-Client and OpenRD-Ultimate
> -Original Message-
> From: Clint Adams [mailto:cl...@debian.org]
> Sent: Tuesday, April 19, 2011 5:17 AM
> To: u-boot@lists.denx.de
> Cc: Albert ARIBAUD; Prafulla Wadaskar; julian.pidan...@citrix.com;
> Wolfgang Denk; Clint Adams
> Subject: [PATCH v2 3/4] Initialize second PHY on OpenRD-Client and
> OpenRD-Ultimate
>
> (rework of Julian Pidancet's patch)
Hi Clint
Some meaning full description about this patch is useful to understand
objective of this patch. It is very difficult to know which patch you are
referring here. At least pointers are expected.
> ---
You must have captured change log history here.
That is equally important too.
Please refer "Sending updated patch versions" @
http://denx.de/wiki/U-Boot/Patches
Regards..
Prafulla . .
> board/Marvell/openrd/openrd.c | 25 +
> include/configs/openrd.h | 14 --
> 2 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/board/Marvell/openrd/openrd.c
> b/board/Marvell/openrd/openrd.c
> index 14ca88e..b2f7adb 100644
> --- a/board/Marvell/openrd/openrd.c
> +++ b/board/Marvell/openrd/openrd.c
> @@ -124,12 +124,11 @@ int board_init(void)
> }
>
> #ifdef CONFIG_RESET_PHY_R
> -/* Configure and enable MV88E1116 PHY */
> -void reset_phy(void)
> +/* Configure and enable MV88E1116/88E1121 PHY */
> +void mv_phy_init(char *name)
> {
> u16 reg;
> u16 devadr;
> - char *name = "egiga0";
>
> if (miiphy_set_current_dev(name))
> return;
> @@ -154,6 +153,24 @@ void reset_phy(void)
> /* reset the phy */
> miiphy_reset(name, devadr);
>
> - printf("88E1116 Initialized on %s\n", name);
> + printf(PHY_NO" Initialized on %s\n", name);
> +}
> +
> +void reset_phy(void)
> +{
> + mv_phy_init("egiga0");
> +
> +#ifdef CONFIG_BOARD_IS_OPENRD_CLIENT
> + /* Kirkwood ethernet driver is written with the assumption that
> in case
> +* of multiple PHYs, their addresses are consecutive. But
> unfortunately
> +* in case of OpenRD-Client, PHY addresses are not
> consecutive.*/
> + miiphy_write("egiga1", 0xEE, 0xEE, 24);
> +#endif
> +
> +#if defined(CONFIG_BOARD_IS_OPENRD_CLIENT) || \
> +defined(CONFIG_BOARD_IS_OPENRD_ULTIMATE)
> + /* configure and initialize both PHY's */
> + mv_phy_init("egiga1");
> +#endif
> }
> #endif /* CONFIG_RESET_PHY_R */
> diff --git a/include/configs/openrd.h b/include/configs/openrd.h
> index 7299749..8d86067 100644
> --- a/include/configs/openrd.h
> +++ b/include/configs/openrd.h
> @@ -117,8 +117,18 @@
> * Ethernet Driver configuration
> */
> #ifdef CONFIG_CMD_NET
> -#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> -#define CONFIG_PHY_BASE_ADR 0x8
> +# ifdef CONFIG_BOARD_IS_OPENRD_BASE
> +# define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
> +# else
> +# define CONFIG_MVGBE_PORTS {1, 1} /* enable both ports */
> +# endif
> +# ifdef CONFIG_BOARD_IS_OPENRD_ULTIMATE
> +# define CONFIG_PHY_BASE_ADR0x0
> +# define PHY_NO "88E1121"
> +# else
> +# define CONFIG_PHY_BASE_ADR0x8
> +# define PHY_NO "88E1116"
> +# endif
> #endif /* CONFIG_CMD_NET */
>
> /*
> --
> 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] mvsata: issue hard reset on initialization
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Monday, May 02, 2011 3:35 AM
> To: u-boot@lists.denx.de
> Cc: Michael Walle; Prafulla Wadaskar
> Subject: [PATCH] mvsata: issue hard reset on initialization
>
> Before the actual initialization do a hard reset of the SATA port and
> the
> connected device.
Copying Albert for his ack
Regards..
Prafulla . .
>
> Signed-off-by: Michael Walle
> Cc: Prafulla Wadaskar
> ---
> drivers/block/mvsata_ide.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/mvsata_ide.c b/drivers/block/mvsata_ide.c
> index 3d6993a..ff880d5 100644
> --- a/drivers/block/mvsata_ide.c
> +++ b/drivers/block/mvsata_ide.c
> @@ -33,7 +33,9 @@
>
> /* SATA port registers */
> struct mvsata_port_registers {
> - u32 reserved1[192];
> + u32 reserved0[10];
> + u32 edma_cmd;
> + u32 reserved1[181];
> /* offset 0x300 : ATA Interface registers */
> u32 sstatus;
> u32 serror;
> @@ -76,6 +78,7 @@ struct mvsata_port_registers {
> * and for SStatus DETection.
> */
>
> +#define MVSATA_EDMA_CMD_ATA_RST 0x0004
> #define MVSATA_SCONTROL_DET_MASK 0x000F
> #define MVSATA_SCONTROL_DET_NONE 0x
> #define MVSATA_SCONTROL_DET_INIT 0x0001
> @@ -115,6 +118,11 @@ static int mvsata_ide_initialize_port(struct
> mvsata_port_registers *port)
> u32 status;
> u32 timeleft = 1; /* wait at most 10 ms for SATA reset to
> complete */
>
> + /* Hard reset */
> + writel(MVSATA_EDMA_CMD_ATA_RST, &port->edma_cmd);
> + udelay(25);
> + writel(0, &port->edma_cmd);
> +
> /* Set control IPM to 3 (no low power) and DET to 1 (initialize) */
> control = readl(&port->scontrol);
> control = (control & ~MVSATA_SCONTROL_MASK) | MVSATA_PORT_INIT;
> --
> 1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] Kirkwood: allow to override CONFIG_SYS_TCLK
> -Original Message- > From: Simon Guinot [mailto:sgui...@lacie.com] > Sent: Monday, May 02, 2011 2:40 AM > To: Prafulla Wadaskar; Albert ARIBAUD; Wolfgang Denk > Cc: u-boot@lists.denx.de; Simon Guinot > Subject: [PATCH v2 3/6] Kirkwood: allow to override CONFIG_SYS_TCLK > > This patch allow to override CONFIG_SYS_TCLK from board configuration > files. This is needed for the Network Space v2 which use a non standard > core clock frequency (166MHz instead of 200MHz for a 6281 SoC). > > As a possible enhancement for 6281 and 6282 devices, TCLK could be > dynamically detected by checking the Sample at Reset register bit 21. > > Additionally this patch fix a typo. > > Signed-off-by: Simon Guinot > --- > arch/arm/include/asm/arch-kirkwood/kw88f6281.h |8 +--- > 1 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/include/asm/arch-kirkwood/kw88f6281.h > b/arch/arm/include/asm/arch-kirkwood/kw88f6281.h > index 80723ea..22d10f1 100644 > --- a/arch/arm/include/asm/arch-kirkwood/kw88f6281.h > +++ b/arch/arm/include/asm/arch-kirkwood/kw88f6281.h > @@ -27,11 +27,13 @@ > #ifndef _ASM_ARCH_KW88F6281_H > #define _ASM_ARCH_KW88F6281_H > > -/* SOC specific definations */ > +/* SOC specific definitions */ > #define KW88F6281_REGS_PHYS_BASE 0xf100 > #define KW_REGS_PHY_BASE KW88F6281_REGS_PHYS_BASE > > -/* TCLK Core Clock defination*/ > -#define CONFIG_SYS_TCLK2 /* 200MHz */ > +/* TCLK Core Clock definition */ > +#ifndef CONFIG_SYS_TCLK > +#define CONFIG_SYS_TCLK 2 /* 200MHz */ > +#endif > > #endif /* _ASM_ARCH_KW88F6281_H */ Acked-by: Prafulla Wadaskar Regards.. Prafulla . . > -- > 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] sf: disable write protection for Macronix flash
> -Original Message-
> From: Simon Guinot [mailto:sgui...@lacie.com]
> Sent: Monday, May 02, 2011 2:40 AM
> To: Prafulla Wadaskar; Albert ARIBAUD; Wolfgang Denk
> Cc: u-boot@lists.denx.de; Simon Guinot
> Subject: [PATCH v2 2/6] sf: disable write protection for Macronix flash
>
> Signed-off-by: Simon Guinot
> ---
> drivers/mtd/spi/macronix.c | 87
>
> 1 files changed, 87 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
> index 8e4d71c..b587ac9 100644
> --- a/drivers/mtd/spi/macronix.c
> +++ b/drivers/mtd/spi/macronix.c
> @@ -49,6 +49,10 @@
> #define CMD_MX25XX_DP0xb9/* Deep Power-down */
> #define CMD_MX25XX_RES 0xab/* Release from DP, and Read
> Signature
> */
>
> +/* Status registers */
> +#define MX25XX_SR_BP (0xF << 2) /* Block Protect */
> +#define MX25XX_SR_SRWP (1 << 7)/* Write Protect */
> +
> struct macronix_spi_flash_params {
> u16 idcode;
> u16 page_size;
> @@ -120,6 +124,86 @@ static const struct macronix_spi_flash_params
> macronix_spi_flash_table[] = {
> },
> };
>
> +static int macronix_write_status(struct spi_flash *flash, u8 sr)
> +{
> + u8 cmd[2];
> + int ret;
> +
> + ret = spi_flash_cmd(flash->spi, CMD_MX25XX_WREN, NULL, 0);
> + if (ret < 0) {
> + debug("SF: Enabling Write failed\n");
> + return ret;
> + }
> +
> + cmd[0] = CMD_MX25XX_WRSR;
> + cmd[1] = sr;
> + ret = spi_xfer(flash->spi, 16, cmd, NULL, SPI_XFER_BEGIN);
> + if (ret) {
> + debug("SF: fail to write status register\n");
> + return ret;
> + }
> +
> + spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_END);
> +
> + ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
> + if (ret < 0) {
> + debug("SF: write status register timed out\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int macronix_read_status(struct spi_flash *flash, u8 *sr)
> +{
> + u8 cmd = CMD_MX25XX_RDSR;
> + int ret;
> +
> + ret = spi_xfer(flash->spi, 8, &cmd, NULL, SPI_XFER_BEGIN);
> + if (ret) {
> + debug("SF: Failed to send command %02x: %d\n", cmd, ret);
> + return ret;
> + }
> + ret = spi_xfer(flash->spi, 8, NULL, sr, 0);
> + if (ret) {
> + debug("SF: fail to read status register: %d\n", ret);
> + return ret;
> + }
> +
> + spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_END);
> +
> + return 0;
> +}
> +
> +static int macronix_disable_protect(struct spi_flash *flash)
> +{
> + int ret;
> + u8 sr;
> +
> + ret = macronix_read_status(flash, &sr);
> + if (ret)
> + return ret;
> +
> + if ((sr & MX25XX_SR_BP) == 0)
> + return ret;
> +
> + /* Disable status register write protection. */
> + sr &= ~MX25XX_SR_SRWP;
> + ret = macronix_write_status(flash, sr);
> + if (ret)
> + return ret;
> +
> + /* Disable block protection. */
> + sr &= ~MX25XX_SR_BP;
> + ret = macronix_write_status(flash, sr);
> + if (ret)
> + return ret;
> +
> + printf("SF: disable write protection\n");
> +
> + return 0;
> +}
> +
> static int macronix_write(struct spi_flash *flash,
> u32 offset, size_t len, const void *buf)
> {
> @@ -223,5 +307,8 @@ struct spi_flash *spi_flash_probe_macronix(struct
> spi_slave *spi, u8 *idcode)
> * params->sectors_per_block;
> mcx->flash.size = mcx->flash.sector_size * params->nr_blocks;
>
> + if (macronix_disable_protect(&mcx->flash))
> + printf("SF: disable write protection failed\n");
> +
This will forced disable the flash being written.
What if some one has purposely protected certain flash sectors?
This feature should be addressed through protect CLI
Regards..
Prafulla . .
> return &mcx->flash;
> }
> --
> 1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] Add support for Network Space v2
> -Original Message- > From: Simon Guinot [mailto:simon.gui...@sequanux.org] > Sent: Sunday, May 01, 2011 8:34 PM > To: Prafulla Wadaskar; Albert ARIBAUD > Cc: u-boot@lists.denx.de; Simon Guinot > Subject: [PATCH 6/6] Add support for Network Space v2 > > From: Simon Guinot > > This patch add support for the Network Space v2 board and parents. > This include Network Space (Max) v2 and Internet Space v2. It's good it you can provide any pointer for board information if any. > > Signed-off-by: Simon Guinot > --- > Makefile |7 ++ > board/LaCie/netspace_v2/Makefile | 49 ++ > board/LaCie/netspace_v2/kwbimage.cfg | 162 > + > board/LaCie/netspace_v2/netspace_v2.c | 150 > ++ > board/LaCie/netspace_v2/netspace_v2.h | 39 > include/configs/netspace_v2.h | 142 > + > 6 files changed, 549 insertions(+), 0 deletions(-) > create mode 100644 board/LaCie/netspace_v2/Makefile > create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg > create mode 100644 board/LaCie/netspace_v2/netspace_v2.c > create mode 100644 board/LaCie/netspace_v2/netspace_v2.h > create mode 100644 include/configs/netspace_v2.h I hope these are not clone from existing supported board. If you have 80% similarities, you can use the same source code. > > diff --git a/Makefile b/Makefile > index ada951e..18e6ecd 100644 > --- a/Makefile > +++ b/Makefile > @@ -897,6 +897,13 @@ TNY_A9260_config : unconfig > @echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h > @$(MKCONFIG) -n $@ -a tny_a9260 arm arm926ejs tny_a9260 calao at91 > > +inetspace_v2_config \ > +netspace_v2_config \ > +netspace_max_v2_config : unconfig > + @mkdir -p $(obj)include > + @echo "#define CONFIG_$(shell echo $(@:_config=) | tr 'a-z' 'A-Z') > 1" >$(obj)include/config.h > + @$(MKCONFIG) -n $@ -a netspace_v2 arm arm926ejs netspace_v2 LaCie > kirkwood > + > Please refer better way of doing it. Ref boards.cfg file in : http://lists.denx.de/pipermail/u-boot/2011-April/091368.html Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] sf: disable write protection for Macronix flash
> -Original Message-
> From: Simon Guinot [mailto:simon.gui...@sequanux.org]
> Sent: Monday, May 02, 2011 3:28 PM
> To: Prafulla Wadaskar
> Cc: Simon Guinot; Albert ARIBAUD; Wolfgang Denk; u-boot@lists.denx.de;
> Prabhanjan Sarnaik; Ashish Karkare; Mike Frysinger
> Subject: Re: [U-Boot] [PATCH v2 2/6] sf: disable write protection for
> Macronix flash
>
> Hi Prafulla,
>
> On Mon, May 02, 2011 at 01:53:29AM -0700, Prafulla Wadaskar wrote:
> > > static int macronix_write(struct spi_flash *flash,
> > > u32 offset, size_t len, const void *buf)
> > > {
> > > @@ -223,5 +307,8 @@ struct spi_flash
> *spi_flash_probe_macronix(struct
> > > spi_slave *spi, u8 *idcode)
> > > * params->sectors_per_block;
> > > mcx->flash.size = mcx->flash.sector_size * params->nr_blocks;
> > >
> > > + if (macronix_disable_protect(&mcx->flash))
> > > + printf("SF: disable write protection failed\n");
> > > +
> >
> > This will forced disable the flash being written.
>
> Yes, as the SST driver do. Maybe it is good enough for the Macronix
> driver too ?
>
> > What if some one has purposely protected certain flash sectors?
>
> Honestly, I don't know. Block protection for SPI flashes is not
> supported either by u-boot (except for SST which only disable it)
> nor by Linux. So, I am not sure this feature is really used.
>
> >
> > This feature should be addressed through protect CLI
>
> I could add an unlock method to the SPI flash operation structure.
> And then, I could bind this method to a CLI command "sf unlock"...
>
> Do you want me to do that ?
Let's get Mike's opinion on this.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/5] Add support for LaCie NAS Network Space v2
> -Original Message- > From: Simon Guinot [mailto:simon.gui...@sequanux.org] > Sent: Tuesday, May 03, 2011 4:12 AM > To: Prafulla Wadaskar; Albert ARIBAUD; Wolfgang Denk; Mike Frysinger > Cc: u-boot@lists.denx.de; Simon Guinot > Subject: [PATCH v5 0/5] Add support for LaCie NAS Network Space v2 > > This patch series adds support for Network Space v2 board and parents. > > Changes for v2: > - netconsole: restore NetOurIP check > - add entries to MAINTAINERS file > - move boards from root Makefile to boards.cfg > - move MACH_TYPE definition into netspace_v2.h > - remove CONFIG_SYS_HZ redefinition > - turn PHY initialization message into debug() > > Changes for v3: > - drop patch for Macronix MX25L4005A > - rewrite patch "sf: disable write protection for Macronix flash", > using the common spi flash code > - fix "Definitions" typo in mv-common.h > - netconsole: add a "/* Fall through */" comment before the NETCONS > case label > > Changes for v4: > - sf macronix: use spi_flash_cmd_write_enable() > - enhance commit message for patch "Add support for Network Space v2" > > Changes for v5: > - add a changelog per patch > > Simon Guinot (5): > sf: disable write protection for Macronix flash > Kirkwood: allow to override CONFIG_SYS_TCLK > mv-common.h: fix DRAM banks configuration Hi Simon >From these patch series, I will pull these two patches into u-boot-marvell.git >since they have standalone Kirkwood related fixes. You may exclude them from your next patch series > netconsole: remove `serverip' check > Add support for Network Space v2 Whereas, mainly your board support patch have dependency with 1. "sf: disable write protection for Macronix flash" to be mainlined by Mike and 2. "netconsole: remove `serverip' check" to be mainlined by net maintainer. 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] MMC: add sdhci generic framework
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Lei Wen > Sent: Sunday, July 17, 2011 12:54 PM > To: Gérald Kerma > Cc: Lei Wen; Yu Tang; Rob Herring; u-boot@lists.denx.de; Andy Fleming; > Ashish Karkare; Prabhanjan Sarnaik > Subject: Re: [U-Boot] [PATCH 1/2] MMC: add sdhci generic framework > > Hi Gérald, > > On Sun, Jul 17, 2011 at 3:20 PM, Gérald Kerma wrote: > > Hello Lei, > > > > Le 29/06/2011 07:58, Lei Wen a écrit : > >> Hi Gérald, > >> > >> On Wed, Jun 29, 2011 at 1:53 PM, Gérald Kerma > wrote: > >>> > Hello, > >>> > > >>> > Is this driver adaptable for sheevaplug ? > > > >> In the Linux kernel, the sdhci-dove.c does the similar way to support > >> the kirkwood. > > > > The linux kernel use mvsdio driver for kirkwood. > > > > MMC_MVSDIO > > Marvell MMC/SD/SDIO host driver > > This selects the Marvell SDIO host driver. > > SDIO may currently be found on the Kirkwood 88F6281 and 88F6192 > > SoC controllers. > > > > MMC_SDHCI_DOVE > > SDHCI support on Marvell's Dove SoC > > This selects the Secure Digital Host Controller Interface in > > Marvell's Dove SoC. > > > > a driver patch which use the old generic driver was adapted from > Marvell > > UBoot (mvsdio). > > > > It's not included in the Denx uboot mainline but is available in the > > Debian Uboot. > > > > I just don't object kirkwood to resue the old way. But since sdhci > could be a generic > framework, it is nice that denx mainline could also use sdhci for > kirkwood which is > actively maintained like in the linux kernel. I don't see an issue here, if sdhci is more generic, it will support few more SoCs then it should go for mainlining. Regards.. Prafulla . . . > > Best regards, > Lei > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] gpio: Adds GPIO driver support for Armada100
> -Original Message-
> From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com]
> Sent: Monday, July 18, 2011 3:12 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ajay Bhargav
> Subject: [PATCH 1/4] gpio: Adds GPIO driver support for Armada100
Correct patch name as
gpio: Add GPIO driver for Marvell SoC Armada100
>
> This patch adds generic GPIO driver framework support for Armada100
> series.
>
> To enable GPIO driver define CONFIG_ARMADA100_GPIO and for GPIO commands
> define CONFIG_CMD_GPIO in your board configuration file.
>
> NOTE: This driver assumes proper configuration of MFP register for the
> GPIO
> in use.
>
> These patches depends on patch series that adds support for Marvell
> Guruplug-Display [1,2].
>
> Signed-off-by: Ajay Bhargav
> ---
> arch/arm/include/asm/arch-armada100/gpio.h | 130 +++
> drivers/gpio/Makefile |1 +
> drivers/gpio/armada100_gpio.c | 192
>
> 3 files changed, 323 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-armada100/gpio.h
> create mode 100644 drivers/gpio/armada100_gpio.c
>
> diff --git a/arch/arm/include/asm/arch-armada100/gpio.h
> b/arch/arm/include/asm/arch-armada100/gpio.h
> new file mode 100644
> index 000..9024a2e
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-armada100/gpio.h
> @@ -0,0 +1,130 @@
> +/*
> + * (C) Copyright 2010
2011???
> + * eInfochips Ltd.
> + * Written-by: Ajay Bhargav
> + *
> + * (C) Copyright 2010
> + * Marvell Semiconductor
> + *
> + * 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., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + */
> +
> +#ifndef _ASM_ARCH_GPIO_H
> +#define _ASM_ARCH_GPIO_H
> +
> +#ifndef __ASSEMBLY__
> +#include
> +#endif
> +
> +#if defined(CONFIG_ARMADA100_GPIO)
> +#include
> +
> +#define GPIO_LABEL_MAX 20
> +#define ARMD_MAX_GPIO128
Pls derive it from MAX_MFP
> +
> +#define GPIO_TO_REG(gp) (gp >> 5)
> +#define GPIO_TO_BIT(gp) (1 << (gp & 0x1F))
> +#define GPIO_VAL(gp, val)((val >> (gp & 0x1F)) & 0x01)
> +
> +#define GPIO_SET 1
> +#define GPIO_CLR 0
> +
> +/*
> + * GPIO register map
> + * Refer Datasheet Appendix A.36
> + */
> +struct armdgpio_registers {
> + u32 gplr0; /* Pin Level Register - 0x */
> + u32 gplr1; /* 0x0004 */
> + u32 gplr2; /* 0x0008 */
> + u32 gpdr0; /* Pin Direction Register - 0x000C */
NAK
You should define all GPIO register in a single struct
And point them with base address offsets
> + u32 gpdr1; /* 0x0010 */
> + u32 gpdr2; /* 0x0014 */
> + u32 gpsr0; /* Pin Output Set Register - 0x0018 */
> + u32 gpsr1; /* 0x001C */
> + u32 gpsr2; /* 0x0020 */
> + u32 gpcr0; /* Pin Output Clear Register - 0x0024 */
> + u32 gpcr1; /* 0x0028 */
> + u32 gpcr2; /* 0x002C */
> + u32 grer0; /* Rising-Edge Detect Enable Register - 0x0030 */
> + u32 grer1; /* 0x0034 */
> + u32 grer2; /* 0x0038 */
> + u32 gfer0; /* Falling-Edge Detect Enable Register - 0x003C */
> + u32 gfer1; /* 0x0040 */
> + u32 gfer2; /* 0x0044 */
> + u32 gedr0; /* Edge Detect Status Register - 0x0048 */
> + u32 gedr1; /* 0x004C */
> + u32 gedr2; /* 0x0050 */
> + u32 gsdr0; /* Bitwise Set of GPIO Direction Register - 0x0054 */
> + u32 gsdr1; /* 0x0058 */
> + u32 gsdr2; /* 0x005C */
> + u32 gcdr0; /* Bitwise Clear of GPIO Direction Register - 0x0060 */
> + u32 gcdr1; /* 0x0064 */
> + u32 gcdr2; /* 0x0068 */
> + u32 gsrer0; /* Bitwise Set of Rising-Edge Detect Enable
> +Register - 0x006C */
> + u32 gsrer1; /* 0x
Re: [U-Boot] [PATCH 2/4] net: Adds Fast Ethernet Controller driver for Armada100
> -Original Message- > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > Sent: Monday, July 18, 2011 3:12 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ajay Bhargav > Subject: [PATCH 2/4] net: Adds Fast Ethernet Controller driver for > Armada100 s/Adds/Add/g > > This patch adds support for Fast Ethernet Controller driver for > Armada100 series. > > Signed-off-by: Ajay Bhargav > --- > arch/arm/include/asm/arch-armada100/armada100.h |1 + > drivers/net/Makefile|1 + > drivers/net/armada100_fec.c | 816 > +++ > drivers/net/armada100_fec.h | 227 +++ > include/netdev.h|1 + > 5 files changed, 1046 insertions(+), 0 deletions(-) > create mode 100644 drivers/net/armada100_fec.c > create mode 100644 drivers/net/armada100_fec.h Acked-By: Prafulla Wadaskar Regards.. Prafulla .. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
