Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
> -Original Message-
> From: Dirk Behme [mailto:dirk.be...@googlemail.com]
> Sent: Wednesday, May 06, 2009 8:25 PM
> To: Matthias Ludwig; Pillai, Manikandan
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
>
> Matthias Ludwig wrote:
> > Signed-off-by: Matthias Ludwig
>
> Matthias: Thanks for fixing this!
[Pillai, Manikandan] not sure why this change in the Chip select
>
> Mani: Can we get your ack as EVM maintainer?
>
> Many thanks and best regards
>
> Dirk
>
> > ---
> > board/omap3/evm/evm.c| 16
> > include/asm-arm/arch-omap3/cpu.h |5 +++--
> > 2 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
> > index c008c2e..5fd5efa 100644
> > --- a/board/omap3/evm/evm.c
> > +++ b/board/omap3/evm/evm.c
> > @@ -92,17 +92,17 @@ void set_muxconf_regs(void)
> > static void setup_net_chip(void)
> > {
> > gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
> > - gpmc_csx_t *gpmc_cs6_base = (gpmc_csx_t *)GPMC_CONFIG_CS6_BASE;
> > + gpmc_csx_t *gpmc_cs5_base = (gpmc_csx_t *)GPMC_CONFIG_CS5_BASE;
> > ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
> >
> > /* Configure GPMC registers */
> > - writel(NET_GPMC_CONFIG1, &gpmc_cs6_base->config1);
> > - writel(NET_GPMC_CONFIG2, &gpmc_cs6_base->config2);
> > - writel(NET_GPMC_CONFIG3, &gpmc_cs6_base->config3);
> > - writel(NET_GPMC_CONFIG4, &gpmc_cs6_base->config4);
> > - writel(NET_GPMC_CONFIG5, &gpmc_cs6_base->config5);
> > - writel(NET_GPMC_CONFIG6, &gpmc_cs6_base->config6);
> > - writel(NET_GPMC_CONFIG7, &gpmc_cs6_base->config7);
> > + writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1);
> > + writel(NET_GPMC_CONFIG2, &gpmc_cs5_base->config2);
> > + writel(NET_GPMC_CONFIG3, &gpmc_cs5_base->config3);
> > + writel(NET_GPMC_CONFIG4, &gpmc_cs5_base->config4);
> > + writel(NET_GPMC_CONFIG5, &gpmc_cs5_base->config5);
> > + writel(NET_GPMC_CONFIG6, &gpmc_cs5_base->config6);
> > + writel(NET_GPMC_CONFIG7, &gpmc_cs5_base->config7);
> >
> > /* Enable off mode for NWE in PADCONF_GPMC_NWE register */
> > writew(readw(&ctrl_base ->gpmc_nwe) | 0x0E00, &ctrl_base->gpmc_nwe);
> > diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-
> omap3/cpu.h
> > index c544e0c..a4ce45a 100644
> > --- a/include/asm-arm/arch-omap3/cpu.h
> > +++ b/include/asm-arm/arch-omap3/cpu.h
> > @@ -84,9 +84,10 @@ typedef struct ctrl_id {
> > /* GPMC CS3/cs4/cs6 not avaliable */
> > #define GPMC_BASE (OMAP34XX_GPMC_BASE)
> > #define GPMC_CONFIG_CS00x60
> > -#define GPMC_CONFIG_CS60x150
> > +#define GPMC_CONFIG_CS50x150
> > +
> > #define GPMC_CONFIG_CS0_BASE (GPMC_BASE + GPMC_CONFIG_CS0)
> > -#define GPMC_CONFIG_CS6_BASE (GPMC_BASE + GPMC_CONFIG_CS6)
> > +#define GPMC_CONFIG_CS5_BASE (GPMC_BASE + GPMC_CONFIG_CS5)
> > #define GPMC_CONFIG_WP 0x10
> >
> > #define GPMC_CONFIG_WIDTH 0x30
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
This is not really a change. The cs configuration was correct, but not
the naming of it.
OMAP34XX_GPMC_BASE (0x6e00) + 0x150 = base address of configuration
registers for GPMC-CS5 not GPMC-CS6.
best regards,
Matthias
On Thu, May 07, 2009 at 12:34:01PM +0530, Pillai, Manikandan wrote:
>
>
> > -Original Message-
> > From: Dirk Behme [mailto:dirk.be...@googlemail.com]
> > Sent: Wednesday, May 06, 2009 8:25 PM
> > To: Matthias Ludwig; Pillai, Manikandan
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
> >
> > Matthias Ludwig wrote:
> > > Signed-off-by: Matthias Ludwig
> >
> > Matthias: Thanks for fixing this!
> [Pillai, Manikandan] not sure why this change in the Chip select
>
> >
> > Mani: Can we get your ack as EVM maintainer?
> >
> > Many thanks and best regards
> >
> > Dirk
> >
> > > ---
> > > board/omap3/evm/evm.c| 16
> > > include/asm-arm/arch-omap3/cpu.h |5 +++--
> > > 2 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
> > > index c008c2e..5fd5efa 100644
> > > --- a/board/omap3/evm/evm.c
> > > +++ b/board/omap3/evm/evm.c
> > > @@ -92,17 +92,17 @@ void set_muxconf_regs(void)
> > > static void setup_net_chip(void)
> > > {
> > > gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
> > > - gpmc_csx_t *gpmc_cs6_base = (gpmc_csx_t *)GPMC_CONFIG_CS6_BASE;
> > > + gpmc_csx_t *gpmc_cs5_base = (gpmc_csx_t *)GPMC_CONFIG_CS5_BASE;
> > > ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
> > >
> > > /* Configure GPMC registers */
> > > - writel(NET_GPMC_CONFIG1, &gpmc_cs6_base->config1);
> > > - writel(NET_GPMC_CONFIG2, &gpmc_cs6_base->config2);
> > > - writel(NET_GPMC_CONFIG3, &gpmc_cs6_base->config3);
> > > - writel(NET_GPMC_CONFIG4, &gpmc_cs6_base->config4);
> > > - writel(NET_GPMC_CONFIG5, &gpmc_cs6_base->config5);
> > > - writel(NET_GPMC_CONFIG6, &gpmc_cs6_base->config6);
> > > - writel(NET_GPMC_CONFIG7, &gpmc_cs6_base->config7);
> > > + writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1);
> > > + writel(NET_GPMC_CONFIG2, &gpmc_cs5_base->config2);
> > > + writel(NET_GPMC_CONFIG3, &gpmc_cs5_base->config3);
> > > + writel(NET_GPMC_CONFIG4, &gpmc_cs5_base->config4);
> > > + writel(NET_GPMC_CONFIG5, &gpmc_cs5_base->config5);
> > > + writel(NET_GPMC_CONFIG6, &gpmc_cs5_base->config6);
> > > + writel(NET_GPMC_CONFIG7, &gpmc_cs5_base->config7);
> > >
> > > /* Enable off mode for NWE in PADCONF_GPMC_NWE register */
> > > writew(readw(&ctrl_base ->gpmc_nwe) | 0x0E00, &ctrl_base->gpmc_nwe);
> > > diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-
> > omap3/cpu.h
> > > index c544e0c..a4ce45a 100644
> > > --- a/include/asm-arm/arch-omap3/cpu.h
> > > +++ b/include/asm-arm/arch-omap3/cpu.h
> > > @@ -84,9 +84,10 @@ typedef struct ctrl_id {
> > > /* GPMC CS3/cs4/cs6 not avaliable */
> > > #define GPMC_BASE(OMAP34XX_GPMC_BASE)
> > > #define GPMC_CONFIG_CS0 0x60
> > > -#define GPMC_CONFIG_CS6 0x150
> > > +#define GPMC_CONFIG_CS5 0x150
> > > +
> > > #define GPMC_CONFIG_CS0_BASE (GPMC_BASE + GPMC_CONFIG_CS0)
> > > -#define GPMC_CONFIG_CS6_BASE (GPMC_BASE + GPMC_CONFIG_CS6)
> > > +#define GPMC_CONFIG_CS5_BASE (GPMC_BASE + GPMC_CONFIG_CS5)
> > > #define GPMC_CONFIG_WP 0x10
> > >
> > > #define GPMC_CONFIG_WIDTH0x30
> >
>
--
Matthias Ludwig, Software Development
Ultratronik Entwicklungs GmbH, Gewerbestrasse 52, 82211 Herrsching, Germany
http://www.ultratronik.de Tel: +49 8152 3709-356 Fax: +49 8152 5183
Registergericht Muenchen, HRB 55584
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
ACKed
> -Original Message-
> From: Matthias Ludwig [mailto:mlud...@ultratronik.de]
> Sent: Thursday, May 07, 2009 12:42 PM
> To: Pillai, Manikandan
> Cc: Dirk Behme; u-boot@lists.denx.de
> Subject: Re: [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
>
> This is not really a change. The cs configuration was correct, but not
> the naming of it.
>
> OMAP34XX_GPMC_BASE (0x6e00) + 0x150 = base address of configuration
> registers for GPMC-CS5 not GPMC-CS6.
>
> best regards,
> Matthias
>
>
> On Thu, May 07, 2009 at 12:34:01PM +0530, Pillai, Manikandan wrote:
> >
> >
> > > -Original Message-
> > > From: Dirk Behme [mailto:dirk.be...@googlemail.com]
> > > Sent: Wednesday, May 06, 2009 8:25 PM
> > > To: Matthias Ludwig; Pillai, Manikandan
> > > Cc: u-boot@lists.denx.de
> > > Subject: Re: [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
> > >
> > > Matthias Ludwig wrote:
> > > > Signed-off-by: Matthias Ludwig
> > >
> > > Matthias: Thanks for fixing this!
> > [Pillai, Manikandan] not sure why this change in the Chip select
> >
> > >
> > > Mani: Can we get your ack as EVM maintainer?
> > >
> > > Many thanks and best regards
> > >
> > > Dirk
> > >
> > > > ---
> > > > board/omap3/evm/evm.c| 16
> > > > include/asm-arm/arch-omap3/cpu.h |5 +++--
> > > > 2 files changed, 11 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
> > > > index c008c2e..5fd5efa 100644
> > > > --- a/board/omap3/evm/evm.c
> > > > +++ b/board/omap3/evm/evm.c
> > > > @@ -92,17 +92,17 @@ void set_muxconf_regs(void)
> > > > static void setup_net_chip(void)
> > > > {
> > > > gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
> > > > - gpmc_csx_t *gpmc_cs6_base = (gpmc_csx_t *)GPMC_CONFIG_CS6_BASE;
> > > > + gpmc_csx_t *gpmc_cs5_base = (gpmc_csx_t *)GPMC_CONFIG_CS5_BASE;
> > > > ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
> > > >
> > > > /* Configure GPMC registers */
> > > > - writel(NET_GPMC_CONFIG1, &gpmc_cs6_base->config1);
> > > > - writel(NET_GPMC_CONFIG2, &gpmc_cs6_base->config2);
> > > > - writel(NET_GPMC_CONFIG3, &gpmc_cs6_base->config3);
> > > > - writel(NET_GPMC_CONFIG4, &gpmc_cs6_base->config4);
> > > > - writel(NET_GPMC_CONFIG5, &gpmc_cs6_base->config5);
> > > > - writel(NET_GPMC_CONFIG6, &gpmc_cs6_base->config6);
> > > > - writel(NET_GPMC_CONFIG7, &gpmc_cs6_base->config7);
> > > > + writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1);
> > > > + writel(NET_GPMC_CONFIG2, &gpmc_cs5_base->config2);
> > > > + writel(NET_GPMC_CONFIG3, &gpmc_cs5_base->config3);
> > > > + writel(NET_GPMC_CONFIG4, &gpmc_cs5_base->config4);
> > > > + writel(NET_GPMC_CONFIG5, &gpmc_cs5_base->config5);
> > > > + writel(NET_GPMC_CONFIG6, &gpmc_cs5_base->config6);
> > > > + writel(NET_GPMC_CONFIG7, &gpmc_cs5_base->config7);
> > > >
> > > > /* Enable off mode for NWE in PADCONF_GPMC_NWE register */
> > > > writew(readw(&ctrl_base ->gpmc_nwe) | 0x0E00, &ctrl_base-
> >gpmc_nwe);
> > > > diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-
> > > omap3/cpu.h
> > > > index c544e0c..a4ce45a 100644
> > > > --- a/include/asm-arm/arch-omap3/cpu.h
> > > > +++ b/include/asm-arm/arch-omap3/cpu.h
> > > > @@ -84,9 +84,10 @@ typedef struct ctrl_id {
> > > > /* GPMC CS3/cs4/cs6 not avaliable */
> > > > #define GPMC_BASE (OMAP34XX_GPMC_BASE)
> > > > #define GPMC_CONFIG_CS00x60
> > > > -#define GPMC_CONFIG_CS60x150
> > > > +#define GPMC_CONFIG_CS50x150
> > > > +
> > > > #define GPMC_CONFIG_CS0_BASE (GPMC_BASE + GPMC_CONFIG_CS0)
> > > > -#define GPMC_CONFIG_CS6_BASE (GPMC_BASE + GPMC_CONFIG_CS6)
> > > > +#define GPMC_CONFIG_CS5_BASE (GPMC_BASE + GPMC_CONFIG_CS5)
> > > > #define GPMC_CONFIG_WP 0x10
> > > >
> > > > #define GPMC_CONFIG_WIDTH 0x30
> > >
> >
>
> --
> Matthias Ludwig, Software Development
> Ultratronik Entwicklungs GmbH, Gewerbestrasse 52, 82211 Herrsching, Germany
> http://www.ultratronik.de Tel: +49 8152 3709-356 Fax: +49 8152 5183
> Registergericht Muenchen, HRB 55584
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to change the entry point for standalone Applications same as the text section base address
Dear ffmm rrcc,
In message you
wrote:
> Hi all:
>
> I have write a standalone application on U-Boot,it works well.but i
> have to get the entry point address follow this article:
>
> http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork
>
> I use -Ttext option for ${CROSS_COMPILE}ld to set the text section
> base address,and -e option to set the entry point function,is there
> any way to let the compiler and linker put the entry point function on
> the text section base address?
Change your code so that your entry point function is the first or
only function in a source file (and thus in the resulting object
file), and change the linker script so that this object gets linked
first, starting at the text section base address.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The light at the end of the tunnel is usually a "No Exit" sign.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
Dear Daniel Gorsulowski, In message <4a02792b.8060...@esd.eu> you wrote: > > > Ummm... common is for, well, for >>common<< stuff. If this code is > > specific to AT91 only, it should not go into common. > > > IMHO this code is not specific to AT91 only. Well, other architectures does > not > support the CONFIG_CMD_LED yet, but they could be implemented later. This is not quite correct. Actually several boards already support this, or very similar functions: board/amcc/taihu/taihu.c:static int do_led_ctl(cmd_tbl_t* cmd_tp, int flags, int argc, char *argv[]) board/amcc/taishan/lcd.c:static int do_led_test_off(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) board/amcc/taishan/lcd.c:static int do_led_test_on(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) board/cm5200/cmd_cm5200.c:int do_led(char *argv[]) board/pcs440ep/pcs440ep.c:int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) board/pn62/cmd_pn62.c:int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) board/tqc/tqm5200/cmd_stk52xx.c:int do_led(char *argv[]) board/trab/trab_fkt.c:int do_led (char **); board/trab/trab_fkt.c:int do_led (char **argv) If the code is really generic, then probably it should merge some (or all?) of the existing implementations, too. > >> +++ b/include/asm-arm/arch-at91/led.h > >> @@ -0,0 +1,52 @@ > >> +/* > >> + * (C) Copyright 2000-2004 > >> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > > > You claim that I have written any of this code? I decline. > > > I took that structure from include/status_led.h, so i picked you up to the > list. > But if you mean, I'll remove these lines. I did not write this code: -> git-blame include/status_led.h ... de74b9ee (Wolfgang Denk2007-10-13 21:15:39 +0200 389) /* bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 390) * Coloured LEDs API de74b9ee (Wolfgang Denk2007-10-13 21:15:39 +0200 391) */ bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 392) #ifndef __ASSEMBLY__ bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 393) extern void coloured_LED_init (void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 394) extern void red_LED_on(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 395) extern void red_LED_off(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 396) extern void green_LED_on(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 397) extern void green_LED_off(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 398) extern void yellow_LED_on(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 399) extern void yellow_LED_off(void); bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 400) #else bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 401) .extern LED_init bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 402) .extern red_LED_on bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 403) .extern red_LED_off bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 404) .extern yellow_LED_on bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 405) .extern yellow_LED_off bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 406) .extern green_LED_on bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 407) .extern green_LED_off bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 408) #endif bd86220f (Peter Pearse 2007-09-18 13:07:54 +0100 409) c609719b (wdenk2002-11-03 00:24:07 + 410) #endif/* CONFIG_STATUS_LED*/ ... As you can see, this stuff was added in commit bd86220f by Peter Pearse. But... if this is already present in include/status_led.h, then why do you have to copy the code? Don't do that! Use the existing include file instead. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Making files is easy under the UNIX operating system. Therefore, users tend to create numerous files using large amounts of file space. It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files. - System V.2 administrator's guide ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Dear Kazuaki Ichinohe, In message <4a027e44.5080...@fsi.co.jp> you wrote: > Hello Denk, Stefan, > > > Could you please rebase your patch against the current top-of-tree mainline > > repository and resumbmit? > > Thank you for the reply. > I made the patch from the source obtained with git in 5/7. > The confirmed patch is sent again. > Please review this patch. > --- Please put comments BELOW the "---" line, not above. Only put the commit message ABOVE the "---" line. And note that there is only ONE "---" line in a patch. > [patch] > diff -uprN u-boot-0507/drivers/block/Makefile > u-boot-sata/drivers/block/Makefile > --- u-boot-0507/drivers/block/Makefile2009-05-07 09:25:48.0 > +0900 > +++ u-boot-sata/drivers/block/Makefile2009-05-07 09:43:56.0 > +0900 > @@ -35,6 +35,7 @@ COBJS-$(CONFIG_SATA_SIL3114) += sata_sil > COBJS-$(CONFIG_SCSI_AHCI) += ahci.o > COBJS-$(CONFIG_SCSI_SYM53C8XX) += sym53c8xx.o > COBJS-$(CONFIG_SYSTEMACE) += systemace.o > +COBJS-$(CONFIG_SATA_DWC) += sata_dwc.o Sorry, your patch is white-space corrupted: patching file drivers/block/Makefile Hunk #1 FAILED at 35. 1 out of 1 hunk FAILED -- saving rejects to file drivers/block/Makefile.rej patching file drivers/block/sata_dwc.c patching file drivers/block/sata_dwc.h patching file include/configs/canyonlands.h Hunk #1 FAILED at 454. patch: malformed patch at line 2718: Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's "better nature." he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Dear Matthias Ludwig, In message <20090507071155.ga8...@ultratronik.de> you wrote: > This is not really a change. The cs configuration was correct, but not > the naming of it. > > OMAP34XX_GPMC_BASE (0x6e00) + 0x150 = base address of configuration > registers for GPMC-CS5 not GPMC-CS6. Can we please get rid of all this crap with register offsets and device accesses through pointers using base address plus offset? Please provide proper C structs! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Wish not to seem, but to be, the best." - Aeschylus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.
Cards which are not compatible with SD 2.0 standard, cat return response for CMD8 command, but it will be invalid in terms of SD 2.0. We should accept this case as admissible. Signed-off-by: Yauhen Kharuzhy --- drivers/mmc/mmc.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 596e052..b284030 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -870,10 +870,6 @@ int mmc_init(struct mmc *mmc) /* Test for SD version 2 */ err = mmc_send_if_cond(mmc); - /* If we got an error other than timeout, we bail */ - if (err && err != TIMEOUT) - return err; - /* Now try to get the SD card's operating condition */ err = sd_send_op_cond(mmc); -- 1.6.2.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm/imx31_phycore: Fix bi_arch_number
Signed-off-by: Detlev Zundel Cc: Sascha Hauer --- board/imx31_phycore/imx31_phycore.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/imx31_phycore/imx31_phycore.c b/board/imx31_phycore/imx31_phycore.c index 93a5c40..92aba96 100644 --- a/board/imx31_phycore/imx31_phycore.c +++ b/board/imx31_phycore/imx31_phycore.c @@ -61,8 +61,8 @@ int board_init (void) mx31_gpio_mux(MUX_CSPI2_MOSI__I2C2_SCL); mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SDA); - gd->bd->bi_arch_number = 447; /* board id for linux */ - gd->bd->bi_boot_params = (0x8100); /* adress of boot parameters */ + gd->bd->bi_arch_number = MACH_TYPE_PCM037; /* board id for linux */ + gd->bd->bi_boot_params = (0x8100); /* adress of boot parameters */ return 0; } -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MII register display
Hi Jon, Jon Smirl wrote: > On Wed, May 6, 2009 at 2:57 PM, Jon Smirl wrote: >> Why is "speed selection = 10 Mbps" when both sides support 100Mb? >> Is uboot decoding this register correctly? >> >> uboot> mii dump 0 0 >> 0. (1000) -- PHY control register -- >> (8000:) 0.15= 0reset >> (4000:) 0.14= 0loopback >> (2040:) 0. 6,13 = b00speed selection = 10 Mbps > > This b00 here is confusing. b is a valid hex character, I thought this > was reporting the register value as 0xb00. > Instead it appears to be trying to indicate that the two bits are binary? Yes. The display confusion is rooted and aggravated by the fact that the two bits are not adjacent in the register (bits 6 and 13). Looking at the rest of your dump, it isn't obvious to me why your PHY is running 10bT. Mike's suggestion of turning on (and possibly adding) debug is a good one. Since you mention you are trying to debug new PHY problems, I would be suspicious of the PHY signal integrity (hardware problem) or a PHY non-standard register problem (software). WRT hardware / signal integrity, note that the autonegotiation communications is done using the "fast link pulses" which are *not* fast and do not require anywhere near the signal integrity that 10/100/1000bT requires. Autonegotiation can work over bailing wire. WRT software, the MII standard is a poster child for the saying "the beauty of standards is that there are so many novel ways to implement them." :-/ [snip] Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] QUESTION: How do I generate an assembly listing?
Jonathan Haws wrote:
> I need to generate an assembly listing that contains all the assembly
> code generated by the compiler. I have tried putting the standard
> GCC options in ppc_config.mk, but cannot get the results I am looking
> for.
>
> What I need is a listing file that contains the address (preferably
> with _start at 0x) and the function name and any assembly
> code with their respective addresses.
${CROSS_COMPILE}objdump -d
The elf file can be unlinked or linked.
You can also use the -S switch to stop gcc at the assembly language
output level.
> Can this easily be done?
Yes. There are other switches available with gcc and objdump to do
various things like interspersing the C source in with the (dis)assembly.
> --
> Jonathan R. Haws
Best regards,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Hi Stefan,
> This patch adds another build target for the AMCC Sequoia PPC440EPx
> eval board. This RAM-booting version is targeted for boards without
> NOR FLASH (NAND booting) which need a possibility to initially
> program their NAND FLASH. Using a JTAG debugger (e.g. BDI2000/3000)
> configured to setup the SDRAM, this debugger can load this RAM-
> booting image to the target address in SDRAM (in this case 0x100)
> and start it there. Then U-Boot's standard NAND commands can be
> used to program the NAND FLASH (e.g. "nand write ...").
>
> Here the commands to load and start this image from the BDI2000:
>
> 440EPX>load 0x100 /tftpboot/sequoia/u-boot.bin
> 440EPX>go 0x100
>
> Please note that this image automatically scans for an already
> initialized SDRAM TLB (detected by EPN=0). This TLB will not be
> cleared. So your debugger should configure the SDRAM TLB correctly
> (as done in the standard Sequoia BDI init script).
>
> Signed-off-by: Stefan Roese
> ---
> Makefile | 11 +++
> board/amcc/sequoia/init.S |7 ++
> board/amcc/sequoia/sdram.c|3 +-
> board/amcc/sequoia/sequoia.c | 12 +++-
> board/amcc/sequoia/u-boot-ram.lds | 126
> +
> cpu/ppc4xx/start.S| 33 --
> include/configs/amcc-common.h | 11 +++
> include/configs/sequoia.h | 30 +++--
> 8 files changed, 215 insertions(+), 18 deletions(-)
> create mode 100644 board/amcc/sequoia/u-boot-ram.lds
>
[...]
> diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
> index e824b8f..8b23823 100644
> --- a/board/amcc/sequoia/sequoia.c
> +++ b/board/amcc/sequoia/sequoia.c
> @@ -33,7 +33,9 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if !defined(CONFIG_SYS_NO_FLASH)
> extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for
> FLASH chips */
> +#endif
>
> extern void __ft_board_setup(void *blob, bd_t *bd);
> ulong flash_get_size(ulong base, int banknum);
> @@ -122,9 +124,9 @@ int board_early_init_f(void)
>
> int misc_init_r(void)
> {
> - uint pbcr;
> - int size_val = 0;
> - u32 reg;
> + __attribute__((unused)) uint pbcr;
> + __attribute__((unused)) int size_val = 0;
> + __attribute__((unused)) u32 reg;
Am I correct to assume that this should shut up warnings for the ifdef
case? If so, it still seems to be a somewhat rude way to do it. How
long will it take the gcc maintainers to produce a "warning: unused
variable is used" warning? ;)
Cheers
Detlev
--
Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist
denn das allemal im Buche?
- Lichtenberg
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot on Xilinx Virtex platforms
On Wed, May 6, 2009 at 2:33 AM, Felix Radensky wrote: > Hi, > > I'm new to Xilinx world, so please bare with my ignorance. > > Looking at u-boot Xilinx files I see that u-boot does not perform > SDRAM initialization. SDRAM is apparently initialized by FPGA > code. Is that correct ? Usually, yes. > Another question is whether u-boot on Virtex can start > executing from NOR flash or should be copied to SDRAM > by some first level bootloader ? Yes. Either method works. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Hi Detlev,
On Thursday 07 May 2009, Detlev Zundel wrote:
> > int misc_init_r(void)
> > {
> > - uint pbcr;
> > - int size_val = 0;
> > - u32 reg;
> > + __attribute__((unused)) uint pbcr;
> > + __attribute__((unused)) int size_val = 0;
> > + __attribute__((unused)) u32 reg;
>
> Am I correct to assume that this should shut up warnings for the ifdef
> case?
Yes.
> If so, it still seems to be a somewhat rude way to do it. How
> long will it take the gcc maintainers to produce a "warning: unused
> variable is used" warning? ;)
I prefer to do it this way instead of encasing the variable declaration into
another #ifdef ... #endif section. This is used in many cases in the Linux
kernel btw. Here the macro "__maybe_unsed" is defined to
"__attribute__((unused))".
So what should I do now? Should I revert to another #ifdef in the variable
declaration? Or is the current version ok?
Thanks.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add a new command to U-Boot
HI I am working with Freescale MPC8313E-RDB and with it comes their BSP. This provides a u-boot. I want to understand how the u-boot commands work as in where are they defined and in which files. My utlimate goal is to add new u-boot commands and to modify the exsisting commands (if needed) Im a total newbie to uboot. and am looking for a hint as to where to look for. thanks a lot... Deepak -- View this message in context: http://www.nabble.com/Add-a-new-command-to-U-Boot-tp1498653p23426790.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add a new command to U-Boot
Deepak Gopalakrishnan wrote: > HI > I am working with Freescale MPC8313E-RDB and with it comes their BSP. This > provides a u-boot. I want to understand how the u-boot commands work as in > where are they defined and in which files. > My utlimate goal is to add new u-boot commands and to modify the exsisting > commands (if needed) > Im a total newbie to uboot. and am looking for a hint as to where to look > for. > > thanks a lot... > > Deepak ls common/cmd*.c Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add a new command to U-Boot
yes indeed...thanks a lot... i can guess that adding a command wont be just a walk in the park.could you tell me wat all this i will have to take care of if i were supposed to writesay another date function...which would display the date in another format other than adding it into the makefile and placing it in the common folder...wat shud i do..? thanks alot... Regards, Deepak Jerry Van Baren 05/07/2009 07:10 PM To Deepak Gopalakrishnan cc u-boot@lists.denx.de Subject Re: [U-Boot] Add a new command to U-Boot Deepak Gopalakrishnan wrote: > HI > I am working with Freescale MPC8313E-RDB and with it comes their BSP. This > provides a u-boot. I want to understand how the u-boot commands work as in > where are they defined and in which files. > My utlimate goal is to add new u-boot commands and to modify the exsisting > commands (if needed) > Im a total newbie to uboot. and am looking for a hint as to where to look > for. > > thanks a lot... > > Deepak ls common/cmd*.c Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Zoom2 initial support rebased to arm/next
Dirk, I believe I caught and fixed these changes when rebasing my zoom2 patches to the latest arm/next From my notes : Remove SDP_3430_V1 and SDP_3430_V2 per upstream changes These were removed in the zoom2.h file. No other changes needed. Tom Dirk Behme wrote: > Hi Tom, > > Tom wrote: >> Here is the changes to Zoom2 to rebase onto the arm/next branch > > I'm not sure and and didn't test it, but it seems to me that we might > get some conflicts with patches in arm/master branch and these against > arm/next. > > With Premi's patch that removes unused board-types > > http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=90006e9b33bcdbf241b0295d186e3634137907a9 > > > > it might conflict with your patch that still assumes the struct > elements and macros are still there (?). > > Best regards > > Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Hi Stefan,
> Hi Detlev,
>
> On Thursday 07 May 2009, Detlev Zundel wrote:
>> > int misc_init_r(void)
>> > {
>> > - uint pbcr;
>> > - int size_val = 0;
>> > - u32 reg;
>> > + __attribute__((unused)) uint pbcr;
>> > + __attribute__((unused)) int size_val = 0;
>> > + __attribute__((unused)) u32 reg;
>>
>> Am I correct to assume that this should shut up warnings for the ifdef
>> case?
>
> Yes.
>
>> If so, it still seems to be a somewhat rude way to do it. How
>> long will it take the gcc maintainers to produce a "warning: unused
>> variable is used" warning? ;)
>
> I prefer to do it this way instead of encasing the variable declaration into
> another #ifdef ... #endif section. This is used in many cases in the Linux
> kernel btw. Here the macro "__maybe_unsed" is defined to
> "__attribute__((unused))".
In many cases? a rgrep on a recent kernel counts 84 incantations, which
is not much for the Linux kernel, I believe.
> So what should I do now? Should I revert to another #ifdef in the variable
> declaration? Or is the current version ok?
I'm not too sure myself. What really tickles me, and what speaks
against using this attribute, is the fact that the "unused" attribute is
itself not part of an #ifdef, whereas the intention clearly is that this
attribute should only be applied when the ifdefs erases code.
Now currently this connection maybe clear for the writer of the patch,
but it is in no way obvious in the code. So theoretically, when the
#ifdef gets removed, nobody will think about the "unused" attributes,
forget them and then we have effectively lost correct warnings.
What do other people think?
Cheers
Detlev
--
(let ((s "bottles of beer on the wall")) ((lambda (f) (f f 99))
(lambda (f i) (or (= i 0) (format #t "~a ~a - take one down pass it around
~a ~a\n" i s (- i 1) s) (f f (- i 1))
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Dear Wolfgang, Wolfgang Denk wrote: > Dear Matthias Ludwig, > > In message <20090507071155.ga8...@ultratronik.de> you wrote: >> This is not really a change. The cs configuration was correct, but not >> the naming of it. >> >> OMAP34XX_GPMC_BASE (0x6e00) + 0x150 = base address of configuration >> registers for GPMC-CS5 not GPMC-CS6. > > Can we please get rid of all this crap with register offsets and > device accesses through pointers using base address plus offset? > > Please provide proper C structs! Would you like to have a look to the code snippet visible in Matthias' patch http://lists.denx.de/pipermail/u-boot/2009-May/052157.html ? It's my understanding that what's in code writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1); is what you want? I.e. as I understand it, the code is correct (we use C structs), and the style Matthias used above you complain about was just for patch explanation (to make it easier understandable). Sorry if I missed something, just correct then ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add a new command to U-Boot
Have you looked at code in common/cmd_date.c? If you see at the end of the file there is macro U_BOOT_CMD() that adds the command date, there is function do_date that is invoked, so if you wanted to implement your own version of date command you will have to implement your own do_date function. /Subodh > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Deepak > Gopalakrishnan > Sent: Thursday, May 07, 2009 7:00 AM > To: Jerry Van Baren > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] Add a new command to U-Boot > > yes indeed...thanks a lot... > i can guess that adding a command wont be just a walk in the > park.could you tell me wat all this i will have to take > care of if i were supposed to writesay another date > function...which would display the date in another format > other than adding it into the makefile and placing it in the > common folder...wat shud i do..? > thanks alot... > > Regards, > Deepak > > > > Jerry Van Baren > 05/07/2009 07:10 PM > > To > Deepak Gopalakrishnan > cc > u-boot@lists.denx.de > Subject > Re: [U-Boot] Add a new command to U-Boot > > > > > > > Deepak Gopalakrishnan wrote: > > HI > > I am working with Freescale MPC8313E-RDB and with it comes > their BSP. > This > > provides a u-boot. I want to understand how the u-boot > commands work > > as > in > > where are they defined and in which files. > > My utlimate goal is to add new u-boot commands and to modify the > exsisting > > commands (if needed) > > Im a total newbie to uboot. and am looking for a hint as to where to > look > > for. > > > > thanks a lot... > > > > Deepak > > ls common/cmd*.c > > Best regards, > gvb > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
On Thursday 07 May 2009, Detlev Zundel wrote: > >> If so, it still seems to be a somewhat rude way to do it. How > >> long will it take the gcc maintainers to produce a "warning: unused > >> variable is used" warning? ;) > > > > I prefer to do it this way instead of encasing the variable declaration > > into another #ifdef ... #endif section. This is used in many cases in the > > Linux kernel btw. Here the macro "__maybe_unsed" is defined to > > "__attribute__((unused))". > > In many cases? a rgrep on a recent kernel counts 84 incantations, which > is not much for the Linux kernel, I believe. Perhaps it's quite new to the Linux kernel. I just spotted it the first time a few weeks ago and thought: "What a nice way to remove some of the ugly #ifdef's in U-Boot!". :) > > So what should I do now? Should I revert to another #ifdef in the > > variable declaration? Or is the current version ok? > > I'm not too sure myself. What really tickles me, and what speaks > against using this attribute, is the fact that the "unused" attribute is > itself not part of an #ifdef, whereas the intention clearly is that this > attribute should only be applied when the ifdefs erases code. BTW: The resulting code/data length is the same, comparing a version with #ifdef's, the attribute version or a version with the variable declaration intact and the warnings. > Now currently this connection maybe clear for the writer of the patch, > but it is in no way obvious in the code. So theoretically, when the > #ifdef gets removed, nobody will think about the "unused" attributes, > forget them and then we have effectively lost correct warnings. This could be the case. But this could happen to the #ifdef version as well. That the #ifdef'ed variable declaration stays in the code after removing the code referencing the variables. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM: Updating mach-types.h
Hi, I have added OMAP3517EVM at: http://www.arm.linux.org.uk/developer/machines/ What is the preferred way to bring this definition into u-boot (include/asm-arm/mach-types.h)? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Updating mach-types.h
Premi, Sanjeev wrote: > Hi, > > I have added OMAP3517EVM at: > http://www.arm.linux.org.uk/developer/machines/ > > What is the preferred way to bring this definition > into u-boot (include/asm-arm/mach-types.h)? Bad timing, mach-types.h was updated recently in U-Boot http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=0b3cc4d75f85b1114fe06522d5394391ddc54823 The official way is http://lists.denx.de/pipermail/u-boot/2008-September/040553.html If your new mach type isn't available yet, looks like you have to ask Jean-Christophe if he kindly likes to update again. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Updating mach-types.h
> -Original Message- > From: Dirk Behme [mailto:dirk.be...@googlemail.com] > Sent: Thursday, May 07, 2009 10:02 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de; Jean-Christophe PLAGNIOL-VILLARD > Subject: Re: [U-Boot] ARM: Updating mach-types.h > > Premi, Sanjeev wrote: > > Hi, > > > > I have added OMAP3517EVM at: > > http://www.arm.linux.org.uk/developer/machines/ > > > > What is the preferred way to bring this definition > > into u-boot (include/asm-arm/mach-types.h)? > > Bad timing, mach-types.h was updated recently in U-Boot :( > > http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=0b3cc4d > 75f85b1114fe06522d5394391ddc54823 > > The official way is > > http://lists.denx.de/pipermail/u-boot/2008-September/040553.html > > If your new mach type isn't available yet, looks like you have to ask > Jean-Christophe if he kindly likes to update again. Jean-Christophe: Is it too early to send another sync request? ~sanjeev > > Best regards > > Dirk > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Dear Stefan,
In message <200905071530.43940...@denx.de> you wrote:
>
> On Thursday 07 May 2009, Detlev Zundel wrote:
> > > int misc_init_r(void)
> > > {
> > > - uint pbcr;
> > > - int size_val = 0;
> > > - u32 reg;
> > > + __attribute__((unused)) uint pbcr;
> > > + __attribute__((unused)) int size_val = 0;
> > > + __attribute__((unused)) u32 reg;
> >
> > Am I correct to assume that this should shut up warnings for the ifdef
> > case?
Well spotted, thanks.
> I prefer to do it this way instead of encasing the variable declaration into
> another #ifdef ... #endif section. This is used in many cases in the Linux
> kernel btw. Here the macro "__maybe_unsed" is defined to
> "__attribute__((unused))".
I don;t accept this, though.
> So what should I do now? Should I revert to another #ifdef in the variable
> declaration? Or is the current version ok?
Please use #ifdef.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Conceptual integrity in turn dictates that the design must proceed
from one mind, or from a very small number of agreeing resonant
minds. - Frederick Brooks Jr., "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Dear Dirk, In message <4a02fb34.2090...@googlemail.com> you wrote: > > > Please provide proper C structs! > > Would you like to have a look to the code snippet visible in Matthias' > patch > > http://lists.denx.de/pipermail/u-boot/2009-May/052157.html > > ? Done. > It's my understanding that what's in code > > writel(NET_GPMC_CONFIG1, &gpmc_cs5_base->config1); > > is what you want? I.e. as I understand it, the code is correct (we use It is only part of what I want to see. There are still deficiencies. Yes, we have a struct gpmc_csx, that's good. Note though that using such typedef's not in line with the Coding Style, which says: "It's a _mistake_ to use typedef for structures and pointers." Also, checkpatch.pl complains about this. The next problem is that the entries in these structs are declared as "unsigned int", which just happens to work by chance. "u32" would be more reliable. Finally, and this is what I really compalin about, is that there is no big structure which includes all the blocks that make up the CPU into one big structure (as it's done for example for PowerPC systems in the include/asm-ppc/*immap* files) - you still use code like gpmc_csx_t *gpmc_cs5_base = (gpmc_csx_t *)GPMC_CONFIG_CS5_BASE; to locate each of the individual C structs in the memory map; instead, onle one single pointer to the internal memory should be needed. > Sorry if I missed something, just correct then ;) Done. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Dear Stefan, in message <200905071739.56301...@denx.de> you wrote: > > > > Linux kernel btw. Here the macro "__maybe_unsed" is defined to > > > "__attribute__((unused))". > > > > In many cases? a rgrep on a recent kernel counts 84 incantations, which > > is not much for the Linux kernel, I believe. > > Perhaps it's quite new to the Linux kernel. I just spotted it the first time > a > few weeks ago and thought: "What a nice way to remove some of the ugly > #ifdef's in U-Boot!". :) My understanding was that this is (only?) intended for function declarations to silence warnings about unused function arguments (which may be necessary anyway for compatible call interface with other functions that actually need this arg). > This could be the case. But this could happen to the #ifdef version as well. > That the #ifdef'ed variable declaration stays in the code after removing the > code referencing the variables. No. In this case the compiler will issue warnings abouit "unused variable". Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Time is a drug. Too much of it kills you. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Wolfgang Denk wrote: > Finally, and this is what I really compalin about, is that there is no > big structure which includes all the blocks that make up the CPU into > one big structure (as it's done for example for PowerPC systems in the > include/asm-ppc/*immap* files) - you still use code like Those immap structs are a huge pain to maintain (or to verify the correctness of), loaded with ifdeffery and magic numbers describing reserved spans. We should not be emulating them. We used to have them in Linux, and got rid of them. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Wolfgang Denk wrote: > Dear Stefan, > > in message <200905071739.56301...@denx.de> you wrote: Linux kernel btw. Here the macro "__maybe_unsed" is defined to "__attribute__((unused))". >>> In many cases? a rgrep on a recent kernel counts 84 incantations, which >>> is not much for the Linux kernel, I believe. >> Perhaps it's quite new to the Linux kernel. I just spotted it the first time >> a >> few weeks ago and thought: "What a nice way to remove some of the ugly >> #ifdef's in U-Boot!". :) > > My understanding was that this is (only?) intended for function > declarations to silence warnings about unused function arguments > (which may be necessary anyway for compatible call interface with > other functions that actually need this arg). Unusued function argument warnings are not normally enabled in the first place (it's a separate warning class from unused variables). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.
On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy wrote: > Cards which are not compatible with SD 2.0 standard, cat return response > for CMD8 command, but it will be invalid in terms of SD 2.0. We should > accept this case as admissible. > > Signed-off-by: Yauhen Kharuzhy You've got a typo in the description on a key word, "cat". Is it can't? can? I'm not convinced that this patch is valid. My understanding is that if a card receives a command it does not understand, it should not respond. Thus, if it responds with an error, it's an actual error. Are you saying that some cards respond to cmd 8 that don't implement 2.0? Because that would not totally surprise me, but would violate not just 2.0, but 1.x, as CMD8 is reserved. MMC cards should also not respond to CMD8 at this stage in initialization, as they are in the wrong state... Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On 12:48 Tue 05 May , Daniel Mack wrote: > U-Boot does not currently build for PXA platforms with USB support > enabled. This is due to commit 24e37645e7378b20fa8f20e2996c8fb8e9 > which introduced the usage of UP2OCR without defining it. unfortunatly it's the invert this commit remove it please fix the comment otherwise ok Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Dear Scott, In message <4a0333fc.6090...@freescale.com> you wrote: > Wolfgang Denk wrote: > > Finally, and this is what I really compalin about, is that there is no > > big structure which includes all the blocks that make up the CPU into > > one big structure (as it's done for example for PowerPC systems in the > > include/asm-ppc/*immap* files) - you still use code like > > Those immap structs are a huge pain to maintain (or to verify the > correctness of), loaded with ifdeffery and magic numbers describing > reserved spans. We should not be emulating them. Well, #define'ing long lists of register offsets is not easier to maintain or verify, and you don't have any typechecking by the compiler. > We used to have them in Linux, and got rid of them. Hm... Seems I have missed this change... What's things like struct qe_immap __iomem *qe_immr or cpm2_map_t __iomem *cpm2_immr or immap_t __iomem *mpc8xx_immr then? Or what replaced the "immr" structs? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The manager will be continually amazed that policies he took for com- mon knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Set default bootfile
On 14:52 Tue 05 May , Sanjeev Premi wrote: > The current configuration doesn't define default > bootfile; leading to this warning at execution: > > OMAP3_EVM # dhcp > ... > ... > DHCP client bound to address 192.168.1.11 > *** Warning: no boot file name; using 'AC18BE16.img' > TFTP from server 0.0.0.0; our IP address is 192.168.1.11; > sending through gateway 192.168.1.1 > Filename 'AC18BE16.img'. > Load address: 0x8200 > Loading: * > TFTP error: 'File not found' (1) IMHO it's the correct way as you will be allow to have only one tftp server with one file per mac address but as the Board Maintainer Ack it ok as it's not really a fix but a preference it will be for the next expect you have a specific reason for this release Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] OMAP3: Rename interrupts.c to timer.c
On 17:41 Tue 05 May , Dirk Behme wrote: > After removal of dublicated interrupt code, rename file to what it > really does now. I prefer to rename all files at the same time Btw please use git to show that you only rename the file without change Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] OMAP3: Reorganize Makefile style
On 17:41 Tue 05 May , Dirk Behme wrote: > Reformat COBJS handling. please rebase against you first patch as the 2 will be handle by an otherone Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code
On 17:21 Wed 06 May , Dirk Behme wrote: > Some OMAP3 boards need control for external power companion > chips. Introduce a CONFIG option for this, to avoid Makefile > changes for each board. please also move it to cpu/arm_cortexa8/omap3/ omap3 and davinci is not a vendor so common code will need to go to drivers or cpu// for the davinci it's already start to move to it Best Regards, J. > > Signed-off-by: Dirk Behme > --- > > Compile tested with ./MAKEALL ARM_CORTEX_A8, boot tested on > OMAP3 based BeagleBoard. > > Note: This patch trys to fix the first comment of > > http://lists.denx.de/pipermail/u-boot/2009-April/051383.html > > board/omap3/common/Makefile |5 + > doc/README.omap3| 11 +++ > include/configs/omap3_beagle.h |1 + > include/configs/omap3_overo.h |1 + > include/configs/omap3_pandora.h |1 + > include/configs/omap3_zoom1.h |1 + > 6 files changed, 16 insertions(+), 4 deletions(-) > > Index: u-boot-main/doc/README.omap3 > === > --- u-boot-main.orig/doc/README.omap3 > +++ u-boot-main/doc/README.omap3 > @@ -77,6 +77,17 @@ For all other commands see > > help > > +Custom configs > +== > + > +CONFIG_OMAP3_POWER > + > +Some OMAP3 boards use external power companion chips to be configured. Enable > +this CONFIG option in your board specific configuration file if your board > +uses such a companion chip. could you name it ine the config and the file name Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Wolfgang Denk wrote: > Dear Scott, > > In message <4a0333fc.6090...@freescale.com> you wrote: >> Wolfgang Denk wrote: >>> Finally, and this is what I really compalin about, is that there is no >>> big structure which includes all the blocks that make up the CPU into >>> one big structure (as it's done for example for PowerPC systems in the >>> include/asm-ppc/*immap* files) - you still use code like >> Those immap structs are a huge pain to maintain (or to verify the >> correctness of), loaded with ifdeffery and magic numbers describing >> reserved spans. We should not be emulating them. > > Well, #define'ing long lists of register offsets is not easier to > maintain or verify, IMHO it is; you can just compare to the manual rather than have offsets be screwed up if something is missing, out of order, or the wrong size. That's countered by the typechecking and ease of use of structs, though. > and you don't have any typechecking by the > compiler. It doesn't have to be all one or the other. Use structs to describe individual blocks (provided they're not too sparsely populated), but define block addresses rather than huge structs consisting of sub-blocks and empty space. And let the details be flexible at the author/maintainer's discretion, rather than a rigid rule. >> We used to have them in Linux, and got rid of them. > > Hm... Seems I have missed this change... What's things like > > struct qe_immap __iomem *qe_immr > or > cpm2_map_t __iomem *cpm2_immr > or > immap_t __iomem *mpc8xx_immr > > then? Legacy stuff that hasn't been fully cleaned up. There used to be immap structs for 83xx and 85xx back in arch/ppc IIRC. > Or what replaced the "immr" structs? The device tree, mainly. But #defines can work for u-boot. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Updating mach-types.h
> > Premi, Sanjeev wrote: > > > Hi, > > > > > > I have added OMAP3517EVM at: > > > http://www.arm.linux.org.uk/developer/machines/ > > > > > > What is the preferred way to bring this definition > > > into u-boot (include/asm-arm/mach-types.h)? > > > > Bad timing, mach-types.h was updated recently in U-Boot > > :( > > > > > http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=0b3cc4d > > 75f85b1114fe06522d5394391ddc54823 > > > > The official way is > > > > http://lists.denx.de/pipermail/u-boot/2008-September/040553.html > > > > If your new mach type isn't available yet, looks like you have to ask > > Jean-Christophe if he kindly likes to update again. > > Jean-Christophe: > Is it too early to send another sync request? no but I will prefer to sync it just before apply your patch so if we need an other sync it will be at the sametime Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <20090507203647.ga3...@game.jcrosoft.org> you wrote: > On 12:48 Tue 05 May , Daniel Mack wrote: > > U-Boot does not currently build for PXA platforms with USB support > > enabled. This is due to commit 24e37645e7378b20fa8f20e2996c8fb8e9 > > which introduced the usage of UP2OCR without defining it. > unfortunatly it's the invert this commit remove it > > please fix the comment Can you please run a "git show 24e37645" again? To me it seems that this commit - removed the usage of UP2OCR from board/delta/delta.c but also - added the usage of UP2OCR to the new file cpu/pxa/usb.c without defining it. So the comment seems absolutely correct to me. Maybe I'm missing something? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
On 09:11 Thu 07 May , Matthias Ludwig wrote: > This is not really a change. The cs configuration was correct, but not > the naming of it. > > OMAP34XX_GPMC_BASE (0x6e00) + 0x150 = base address of configuration > registers for GPMC-CS5 not GPMC-CS6. so please fix the comment Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Dear Scott Wood, In message <4a034b09.7030...@freescale.com> you wrote: > > > Or what replaced the "immr" structs? > > The device tree, mainly... Right, of course. > ... But #defines can work for u-boot. Of course they _can_ work. But they can easily fail (as we just see in this patch), and we don't have typechecking. So until DT's are omnipresent, let's use structs in U-Boot, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When in doubt, mumble; when in trouble, delegate; when in charge, ponder. -- James H. Boren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On 23:00 Thu 07 May , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <20090507203647.ga3...@game.jcrosoft.org> you wrote: > > On 12:48 Tue 05 May , Daniel Mack wrote: > > > U-Boot does not currently build for PXA platforms with USB support > > > enabled. This is due to commit 24e37645e7378b20fa8f20e2996c8fb8e9 > > > which introduced the usage of UP2OCR without defining it. > > unfortunatly it's the invert this commit remove it > > > > please fix the comment > > Can you please run a "git show 24e37645" again? > > To me it seems that this commit > > - removed the usage of UP2OCR from board/delta/delta.c > but also > - added the usage of UP2OCR to the new file cpu/pxa/usb.c > without defining it. > > > So the comment seems absolutely correct to me. Maybe I'm missing > something? It's me I mix the commit this commit 3ccbfb25f48a:Support for PXA27X UDC. brake the pxa support by removing the UP2OCR Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6
Wolfgang Denk wrote: > Dear Scott Wood, > > In message <4a034b09.7030...@freescale.com> you wrote: >>> Or what replaced the "immr" structs? >> The device tree, mainly... > > Right, of course. > >> ... But #defines can work for u-boot. > > Of course they _can_ work. But they can easily fail (as we just see > in this patch), and we don't have typechecking. So until DT's are > omnipresent, let's use structs in U-Boot, please. You *do* have typechecking as long as the individual blocks are described with structs. We could take immap to extremes by defining one big 4GiB struct that shows where memory, immr, flash, desired PCI bars, FPGAs, etc. are -- but that would be silly. IMHO, so is doing it at the immr level. :-) How would you deal with blocks being at different locations in different chips? It's a lot easier to ifdef (or have the config file specify) a couple addresses than to ifdef the locations of fields in a struct, especially when you have more than a couple variations. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Zoom2 patch set on arm/next
Initial Zoom2 support rebased on arm/next branch.
Runtested on Zoom2
MAKEALL arm tested.
Patchset to follow.
Tom
My notes on issues and changes.
Jean-Christophe Zoom2 base 4/29
[PATCH 1/5] ZOOM2 Add initial support for Zoom2
Please fix the whitespace present on the patch and split the merge of
the lds
in a seperated patch
Tom :
OK
lds split out again, in the first patch.
Whitespace changes
include/configs/omap3_zoom2.h
Tabs in trailing comment
#undef CONFIG_CMD_NFS /* NFS support */
Only tabs in space between variable and comment
#define CONFIG_SYS_LONGHELP/* undef to save memory */
Other changes
Swap refernce 7 & 8 in README.omap3
Remove ext2 and jffs2 support from config file
environment nand offset in config file matches omapzoom
Remove onenand defines from config file
Remove SDP_3430_V1 and SDP_3430_V2 per upstream changes
--
Jean-Christophe Zoom2 base 4/29
[PATCH 2/5] OMAP3 Port kernel omap gpio interface.
please specify against which kernel commit you import it
Tom : OK
Did in gpio.c and readme.
Other changes
spelling of 'derived'
remove WARNON macro.
remove unused element from gpio_bank structure
Jean-Christophe Zoom2 base 4/29
[PATCH 3/5] ZOOM2 Add support for debug boarddetection.
> +#define DEBUG_BOARD_CONNECTED 1
^
whitespace please fix
Tom : OK
> +int val = 0;
please add an empty line
> > +if (!omap_request_gpio(158)) {
> > +/*
Tom : OK
---
Jean-Christophe Zoom2 base 4/29
[PATCH 4/5] ZOOM2 Add serial support.
> +
> > +static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
> > +0x00011000,
> > +0x001F1F01,
> > +0x00080803,
> > +0x1D091D09,
> > +0x041D1F1F,
> > +0x1D0904C4, 0
> > +};
please add a few comment about this value
Tom : TBD
> +extern int zoom2_debug_board_connected (void);
> > +
> > +#define SERIAL_TL16CP754C_BASE0x1000 /* Zoom2 Serial
chip address */
^^
whitespace please fix
> > +
> > +#define QUAD_BASE_0 SERIAL_TL16CP754C_BASE
^^
whitespace please fix
> > +#define QUAD_BASE_1 (SERIAL_TL16CP754C_BASE + 0x100)
^^
whitespace please fix
> > +#define QUAD_BASE_2 (SERIAL_TL16CP754C_BASE + 0x200)
^^
whitespace please fix
> > +#define QUAD_BASE_3 (SERIAL_TL16CP754C_BASE + 0x300)
^^
whitespace please fix
> > +
Tom : OK
+struct serial_device zoom2_serial_device##n =\
> +{\
> +N(n),\
> +U(n),\
> +quad_init_##n,\
> +quad_setbrg_##n,\
> +quad_getc_##n,\
> +quad_tstc_##n,\
> +quad_putc_##n,\
> +quad_puts_##n,\
> +};
I'm not a fan of this kind of define
a upgrade of the serial API and console device to allow
to provide a struct pointer will be great so we could merge this 2 API
(change not resquested for this patch)
Tom: I agree, this tends to hide what is is really happening. I did this
after starting down a path similar to cpu/mpc5xxx/serial.c. 4 sets of
very similar functions seemed to me a worse option.
whitespace please fix
> > /*
> > - * select serial console configuration
> > + * 0 - 1 : first USB with respect to the left edge of the debug board
> > + * 2 - 3 : second USB with respect to the left edge of the debug board
> > */
> > -#define CONFIG_CONS_INDEX3
> > -#define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3
> > -#define CONFIG_SERIAL33/* UART3 */
> > +#define DEFAULT_ZOOM2_SERIAL_DEVICE (&zoom2_serial_device0)
> > +
> > +#define V_NS16550_CLK(1843200) /* 1.8432 Mhz */
whitespace please fix
> > +
> > +#define CONFIG_SYS_NS16550
> > +#define CONFIG_SYS_NS16550_REG_SIZE (-2)
^
whitespace please fix
> > +#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
^^
whitespace please fix
> > +#define CONFIG_BAUDRATE 115200
^^
whitespace please fix
> > +#define CONFIG_SYS_BAUDRATE_TABLE {115200}
^^^
whitespace please fix
> >
Tom : OK
Sorry..
I am starting to emacs blank-mode, it helps.
http://www.emacswiki.org/emacs/BlankMode
---
Jean-Christophe Zoom2 base 4/29
[PATCH 5/5] ZOOM2 Add led support.
> +COBJS-${CONFIG_STATUS_LED} += led.o
$() please
Tom: Ok
Other changes,
Redundant CONFIG_STATUS_LED decoration around #include
#define led gpio numbers
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] OMAP Consolidate common u-boot.lds to cpu layer.
The u-boot.lds file is common for all omap boards.
Move a cleaned up version to the cpu layer and add makefile logic to use it.
Signed-off-by: Tom Rix
---
board/omap3/beagle/u-boot.lds | 63 -
board/omap3/evm/u-boot.lds| 63 -
board/omap3/overo/u-boot.lds | 63 -
board/omap3/pandora/u-boot.lds| 63 -
board/omap3/zoom1/u-boot.lds | 63 -
cpu/arm_cortexa8/omap3/config.mk |2 +
cpu/arm_cortexa8/omap3/u-boot.lds | 58 ++
7 files changed, 60 insertions(+), 315 deletions(-)
delete mode 100644 board/omap3/beagle/u-boot.lds
delete mode 100644 board/omap3/evm/u-boot.lds
delete mode 100644 board/omap3/overo/u-boot.lds
delete mode 100644 board/omap3/pandora/u-boot.lds
delete mode 100644 board/omap3/zoom1/u-boot.lds
create mode 100644 cpu/arm_cortexa8/omap3/u-boot.lds
diff --git a/board/omap3/beagle/u-boot.lds b/board/omap3/beagle/u-boot.lds
deleted file mode 100644
index 66a8925..000
--- a/board/omap3/beagle/u-boot.lds
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * January 2004 - Changed to support H4 device
- * Copyright (c) 2004 Texas Instruments
- *
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering,
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- cpu/arm_cortexa8/start.o(.text)
- *(.text)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
- __exidx_start = .;
- .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
- __exidx_end = .;
-
- . = ALIGN(4);
- .data : { *(.data) }
-
- . = ALIGN(4);
- .got : { *(.got) }
-
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
-
- . = ALIGN(4);
- __bss_start = .;
- .bss : { *(.bss) }
- _end = .;
-}
diff --git a/board/omap3/evm/u-boot.lds b/board/omap3/evm/u-boot.lds
deleted file mode 100644
index 66a8925..000
--- a/board/omap3/evm/u-boot.lds
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * January 2004 - Changed to support H4 device
- * Copyright (c) 2004 Texas Instruments
- *
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering,
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- cpu/arm_cortexa8/start.o(.text)
- *(.text)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
- __exidx_start = .;
- .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
- __exidx_end = .;
-
- . = ALIGN(4);
- .data : { *(.data) }
-
- . = ALIGN(4);
- .got : { *(.got) }
-
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cm
[U-Boot] [PATCH 2/6] ZOOM2 Add initial support for Zoom2
Zoom2 is a new board from Texas Instruments and LogicPD The logicpd web site is a good source for general information on this board. Please start looking here if the below links are broken. http://www.logicpd.com This is a pdf of the product http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf This is the product description web page http://www.logicpd.com/products/development-kits/texas-instruments-zoom%E2%84%A2-omap34x-ii-mdp This patch provides a zoom2 base target by copying zoom1 and by making some obvious changes. To configure, run make omap3_zoom2_config Signed-off-by: Tom Rix --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/omap3/common/Makefile |1 + board/omap3/zoom2/Makefile| 49 + board/omap3/zoom2/config.mk | 33 ++ board/omap3/zoom2/zoom2.c | 76 ++ board/omap3/zoom2/zoom2.h | 149 +++ doc/README.omap3 | 15 +++- include/configs/omap3_zoom2.h | 226 + 10 files changed, 555 insertions(+), 2 deletions(-) create mode 100644 board/omap3/zoom2/Makefile create mode 100644 board/omap3/zoom2/config.mk create mode 100644 board/omap3/zoom2/zoom2.c create mode 100644 board/omap3/zoom2/zoom2.h create mode 100644 include/configs/omap3_zoom2.h diff --git a/MAINTAINERS b/MAINTAINERS index 6bb03b4..e19fd0f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -615,6 +615,10 @@ Stelian Pop at91sam9263ek ARM926EJS (AT91SAM9263 SoC) at91sam9rlekARM926EJS (AT91SAM9RL SoC) +Tom Rix + + omap3_zoom2 ARM CORTEX-A8 (OMAP3xx SoC) + Stefan Roese ixdpg425xscale diff --git a/MAKEALL b/MAKEALL index f13c81a..46a96c0 100755 --- a/MAKEALL +++ b/MAKEALL @@ -561,6 +561,7 @@ LIST_ARM_CORTEX_A8="\ omap3_evm \ omap3_pandora \ omap3_zoom1 \ + omap3_zoom2 \ " # diff --git a/Makefile b/Makefile index 137c88f..9d107e6 100644 --- a/Makefile +++ b/Makefile @@ -2983,6 +2983,9 @@ omap3_pandora_config :unconfig omap3_zoom1_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom1 omap3 omap3 +omap3_zoom2_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 omap3 omap3 + # ## XScale Systems # diff --git a/board/omap3/common/Makefile b/board/omap3/common/Makefile index 7b892fa..b8a0b14 100644 --- a/board/omap3/common/Makefile +++ b/board/omap3/common/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_OMAP3_BEAGLE) += power.o COBJS-$(CONFIG_OMAP3_OVERO) += power.o COBJS-$(CONFIG_OMAP3_PANDORA) += power.o COBJS-$(CONFIG_OMAP3_ZOOM1) += power.o +COBJS-$(CONFIG_OMAP3_ZOOM2) += power.o COBJS := $(COBJS-y) SRCS := $(COBJS:.o=.c) diff --git a/board/omap3/zoom2/Makefile b/board/omap3/zoom2/Makefile new file mode 100644 index 000..088b8cb --- /dev/null +++ b/board/omap3/zoom2/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := zoom2.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/omap3/zoom2/config.mk b/board/omap3/zoom2/config.mk new file mode 100644 index 000..33f394b --- /dev/null +++ b/board/omap3/zoom2/config.mk @@ -0,0 +1,33 @@ +# +# (C) Copyright 2009 +# Texas Instruments, +# +# Zoom II uses OMAP3
[U-Boot] [PATCH 3/6] OMAP3 Port kernel omap gpio interface.
Port the linux kernel's omap gpio interface to u-boot.
The orignal source is in linux/arch/arm/plat-omap/gpio.c
See doc/README.omap3 for instructions on use.
Signed-off-by: Tom Rix
---
cpu/arm_cortexa8/omap3/Makefile |1 +
cpu/arm_cortexa8/omap3/gpio.c | 185 +
doc/README.omap3 | 32 +++
include/asm-arm/arch-omap3/gpio.h | 86 +
4 files changed, 304 insertions(+), 0 deletions(-)
create mode 100644 cpu/arm_cortexa8/omap3/gpio.c
create mode 100644 include/asm-arm/arch-omap3/gpio.h
diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
index edf5cb2..50176ee 100644
--- a/cpu/arm_cortexa8/omap3/Makefile
+++ b/cpu/arm_cortexa8/omap3/Makefile
@@ -29,6 +29,7 @@ SOBJS := lowlevel_init.o
COBJS += board.o
COBJS += clock.o
+COBJS += gpio.o
COBJS += mem.o
COBJS += syslib.o
COBJS += sys_info.o
diff --git a/cpu/arm_cortexa8/omap3/gpio.c b/cpu/arm_cortexa8/omap3/gpio.c
new file mode 100644
index 000..aeb6066
--- /dev/null
+++ b/cpu/arm_cortexa8/omap3/gpio.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright (c) 2009 Wind River Systems, Inc.
+ * Tom Rix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This work is derived from the linux 2.6.27 kernel source
+ * To fetch, use the kernel repository
+ * git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ * Use the v2.6.27 tag.
+ *
+ * Below is the original's header including its copyright
+ *
+ * linux/arch/arm/plat-omap/gpio.c
+ *
+ * Support functions for OMAP GPIO
+ *
+ * Copyright (C) 2003-2005 Nokia Corporation
+ * Written by Juha Yrjölä
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+
+static struct gpio_bank gpio_bank_34xx[6] = {
+ { (void *)OMAP34XX_GPIO1_BASE, METHOD_GPIO_24XX },
+ { (void *)OMAP34XX_GPIO2_BASE, METHOD_GPIO_24XX },
+ { (void *)OMAP34XX_GPIO3_BASE, METHOD_GPIO_24XX },
+ { (void *)OMAP34XX_GPIO4_BASE, METHOD_GPIO_24XX },
+ { (void *)OMAP34XX_GPIO5_BASE, METHOD_GPIO_24XX },
+ { (void *)OMAP34XX_GPIO6_BASE, METHOD_GPIO_24XX },
+};
+
+static struct gpio_bank *gpio_bank = &gpio_bank_34xx[0];
+
+static inline struct gpio_bank *get_gpio_bank(int gpio)
+{
+ return &gpio_bank[gpio >> 5];
+}
+
+static inline int get_gpio_index(int gpio)
+{
+ return gpio & 0x1f;
+}
+
+static inline int gpio_valid(int gpio)
+{
+ if (gpio < 0)
+ return -1;
+ if (gpio < 192)
+ return 0;
+ return -1;
+}
+
+static int check_gpio(int gpio)
+{
+ if (gpio_valid(gpio) < 0) {
+ printf("ERROR : check_gpio: invalid GPIO %d\n", gpio);
+ return -1;
+ }
+ return 0;
+}
+
+static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input)
+{
+ void *reg = bank->base;
+ u32 l;
+
+ switch (bank->method) {
+ case METHOD_GPIO_24XX:
+ reg += OMAP24XX_GPIO_OE;
+ break;
+ default:
+ return;
+ }
+ l = __raw_readl(reg);
+ if (is_input)
+ l |= 1 << gpio;
+ else
+ l &= ~(1 << gpio);
+ __raw_writel(l, reg);
+}
+
+void omap_set_gpio_direction(int gpio, int is_input)
+{
+ struct gpio_bank *bank;
+
+ if (check_gpio(gpio) < 0)
+ return;
+ bank = get_gpio_bank(gpio);
+ _set_gpio_direction(bank, get_gpio_index(gpio), is_input);
+}
+
+static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
+{
+ void *reg = bank->base;
+ u32 l = 0;
+
+ switch (bank->method) {
+ case METHOD_GPIO_24XX:
+ if (enable)
+ reg += OMAP24XX_GPIO_SETDATAOUT;
+ else
+ reg += OMAP24XX_GPIO_CLEARDATAOUT;
+ l = 1 << gpio;
+ break;
+ default:
+ printf("omap3-gpio unknown bank method %s %d\n",
+ __FILE__, __LINE__);
+ return;
+ }
+ __raw_writel(l, reg);
+}
+
+void omap_set_gpio_dataout(int gpio, int enable)
+{
+
[U-Boot] [PATCH 4/6] ZOOM2 Add support for debug board detection.
The logicpd web site is a good source for general information on this board.
Please start looking here if the below links are broken.
http://www.logicpd.com
This is a pdf of the product
http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
This is a pdf of the product quick start guide.
The debug board is described here.
http://support.logicpd.com/downloads/1165/
This is a wiki showing the debug board in use
https://omapzoom.org/gf/project/omapzoom/wiki/?pagename=GettingStartedWithZoomII_AKA_OMAP34XII_MDP
The zoom2 has an auxillary board that contains the serial, net, jtag and
battery simulator. This change supports a runtime check if the debug board is
connected.
Signed-off-by: Tom Rix
---
board/omap3/zoom2/Makefile |3 +-
board/omap3/zoom2/debug_board.c | 59 +++
2 files changed, 61 insertions(+), 1 deletions(-)
create mode 100644 board/omap3/zoom2/debug_board.c
diff --git a/board/omap3/zoom2/Makefile b/board/omap3/zoom2/Makefile
index 088b8cb..b8fa5a7 100644
--- a/board/omap3/zoom2/Makefile
+++ b/board/omap3/zoom2/Makefile
@@ -25,7 +25,8 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := zoom2.o
+COBJS := zoom2.o \
+ debug_board.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/omap3/zoom2/debug_board.c b/board/omap3/zoom2/debug_board.c
new file mode 100644
index 000..a4ddf29
--- /dev/null
+++ b/board/omap3/zoom2/debug_board.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2009 Wind River Systems, Inc.
+ * Tom Rix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+
+#define DEBUG_BOARD_CONNECTED 1
+#define DEBUG_BOARD_NOT_CONNECTED 0
+
+static int debug_board_connected = DEBUG_BOARD_CONNECTED;
+
+static void zoom2_debug_board_detect (void)
+{
+ int val = 0;
+
+ if (!omap_request_gpio(158)) {
+ /*
+* GPIO to query for debug board
+* 158 db board query
+*/
+ omap_set_gpio_direction(158, 1);
+ val = omap_get_gpio_datain(158);
+ omap_free_gpio(158);
+ }
+
+ if (!val)
+ debug_board_connected = DEBUG_BOARD_NOT_CONNECTED;
+}
+
+int zoom2_debug_board_connected (void)
+{
+ static int first_time = 1;
+
+ if (first_time) {
+ zoom2_debug_board_detect ();
+ first_time = 0;
+ }
+ return debug_board_connected;
+}
--
1.6.0.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] ZOOM2 Add serial support.
Zoom2 serial is in general supplied by one of the 4 UARTS on the debug board.
The default serial is from the USB connector on left side of the debug board.
The USB connector will produce 2 of the 4 UARTS. On your host pick the first
enumeration.
The serial port set up is the same with Zoom1.
Baud rate 115200, 8 bit data, no parity, 1 stop bit, no flow.
The kernel bootargs are
console=ttyS3,115200n8
Signed-off-by: Tom Rix
---
board/omap3/zoom2/Makefile |3 +-
board/omap3/zoom2/zoom2.c| 35 ++
board/omap3/zoom2/zoom2_serial.c | 130 ++
board/omap3/zoom2/zoom2_serial.h | 75 ++
common/serial.c |2 +
drivers/serial/ns16550.c |4 +-
include/configs/omap3_zoom2.h| 26
include/serial.h |7 ++
8 files changed, 266 insertions(+), 16 deletions(-)
create mode 100644 board/omap3/zoom2/zoom2_serial.c
create mode 100644 board/omap3/zoom2/zoom2_serial.h
diff --git a/board/omap3/zoom2/Makefile b/board/omap3/zoom2/Makefile
index b8fa5a7..d27990c 100644
--- a/board/omap3/zoom2/Makefile
+++ b/board/omap3/zoom2/Makefile
@@ -26,7 +26,8 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
COBJS := zoom2.o \
- debug_board.o
+ debug_board.o \
+ zoom2_serial.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c
index 0700c56..dd0086c 100644
--- a/board/omap3/zoom2/zoom2.c
+++ b/board/omap3/zoom2/zoom2.c
@@ -30,10 +30,29 @@
*/
#include
#include
+#include
#include
#include
#include
#include "zoom2.h"
+#include "zoom2_serial.h"
+
+/*
+ * This the the zoom2, board specific, gpmc configuration for the
+ * quad uart on the debug board. The more general gpmc configurations
+ * are setup at the cpu level in cpu/arm_cortexa8/omap3/mem.c
+ */
+extern void enable_gpmc_config(u32 *gpmc_config, gpmc_csx_t *gpmc_cs_base,
+ u32 base, u32 size);
+
+static u32 gpmc_serial_TL16CP754C[GPMC_MAX_REG] = {
+ 0x00011000,
+ 0x001F1F01,
+ 0x00080803,
+ 0x1D091D09,
+ 0x041D1F1F,
+ 0x1D0904C4, 0
+};
/*
* Routine: board_init
@@ -42,13 +61,29 @@
int board_init (void)
{
DECLARE_GLOBAL_DATA_PTR;
+ gpmc_csx_t *serial_cs_base;
+ u32 *gpmc_config;
gpmc_init (); /* in SRAM or SDRAM, finish GPMC */
+
+ /* Configure console support on zoom2 */
+ gpmc_config = gpmc_serial_TL16CP754C;
+ serial_cs_base = (gpmc_csx_t *) (GPMC_CONFIG_CS0_BASE +
+(3 * GPMC_CONFIG_WIDTH));
+ enable_gpmc_config(gpmc_config,
+ serial_cs_base,
+ SERIAL_TL16CP754C_BASE,
+ GPMC_SIZE_16M);
+
/* board id for Linux */
gd->bd->bi_arch_number = MACH_TYPE_OMAP_ZOOM2;
/* boot param addr */
gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+ status_led_set (STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/omap3/zoom2/zoom2_serial.c b/board/omap3/zoom2/zoom2_serial.c
new file mode 100644
index 000..a3d777d
--- /dev/null
+++ b/board/omap3/zoom2/zoom2_serial.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (c) 2009 Wind River Systems, Inc.
+ * Tom Rix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This file was adapted from cpu/mpc5xxx/serial.c
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "zoom2_serial.h"
+
+int quad_init_dev (unsigned long base)
+{
+ /*
+* The Quad UART is on the debug board.
+* Check if the debug board is attached before using the UART
+*/
+ if (zoom2_debug_board_connected ()) {
+ NS16550_t com_port = (NS16550_t) base;
+ int baud_divisor = CONFIG_SYS_NS16550_CLK / 16 /
+ CONFIG_BAUDRATE;
+
+ /*
+* Zoom2 has a board specific initialization of its UART.
+* This generic initialization has been copied from
+* drivers/serial/ns16550.c. The macros have been expanded.
+*
[U-Boot] [PATCH 6/6] ZOOM2 Add led support.
This patch controls the large LED on the top left of the zoom2.
Signed-off-by: Tom Rix
---
board/omap3/zoom2/Makefile|8 ++-
board/omap3/zoom2/led.c | 129 +
board/omap3/zoom2/zoom2.c |4 +-
include/configs/omap3_zoom2.h | 16 +
4 files changed, 153 insertions(+), 4 deletions(-)
create mode 100644 board/omap3/zoom2/led.c
diff --git a/board/omap3/zoom2/Makefile b/board/omap3/zoom2/Makefile
index d27990c..2feafbe 100644
--- a/board/omap3/zoom2/Makefile
+++ b/board/omap3/zoom2/Makefile
@@ -25,10 +25,12 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := zoom2.o \
- debug_board.o \
- zoom2_serial.o
+COBJS-y := $(BOARD).o
+COBJS-y += debug_board.o
+COBJS-y += zoom2_serial.o
+COBJS-$(CONFIG_STATUS_LED) += led.o
+COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/omap3/zoom2/led.c b/board/omap3/zoom2/led.c
new file mode 100644
index 000..4e14c58
--- /dev/null
+++ b/board/omap3/zoom2/led.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright (c) 2009 Wind River Systems, Inc.
+ * Tom Rix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+static unsigned int saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
+
+/*
+ * GPIO LEDs
+ * 173 red
+ * 154 blue
+ * 61 blue2
+ */
+#define ZOOM2_LED_RED 173
+#define ZOOM2_LED_BLUE 154
+#define ZOOM2_LED_BLUE261
+
+void red_LED_off (void)
+{
+ /* red */
+ if (!omap_request_gpio(ZOOM2_LED_RED)) {
+ omap_set_gpio_direction(ZOOM2_LED_RED, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_RED, 0);
+ }
+ saved_state[STATUS_LED_RED] = STATUS_LED_OFF;
+}
+
+void blue_LED_off (void)
+{
+ /* blue */
+ if (!omap_request_gpio(ZOOM2_LED_BLUE)) {
+ omap_set_gpio_direction(ZOOM2_LED_BLUE, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_BLUE, 0);
+ }
+
+ /* blue 2 */
+ if (!omap_request_gpio(ZOOM2_LED_BLUE2)) {
+ omap_set_gpio_direction(ZOOM2_LED_BLUE2, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_BLUE2, 0);
+ }
+ saved_state[STATUS_LED_BLUE] = STATUS_LED_OFF;
+}
+
+void red_LED_on (void)
+{
+ blue_LED_off ();
+
+ /* red */
+ if (!omap_request_gpio(ZOOM2_LED_RED)) {
+ omap_set_gpio_direction(ZOOM2_LED_RED, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_RED, 1);
+ }
+ saved_state[STATUS_LED_RED] = STATUS_LED_ON;
+}
+
+void blue_LED_on (void)
+{
+ red_LED_off ();
+
+ /* blue */
+ if (!omap_request_gpio(ZOOM2_LED_BLUE)) {
+ omap_set_gpio_direction(ZOOM2_LED_BLUE, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_BLUE, 1);
+ }
+
+ /* blue 2 */
+ if (!omap_request_gpio(ZOOM2_LED_BLUE2)) {
+ omap_set_gpio_direction(ZOOM2_LED_BLUE2, 0);
+ omap_set_gpio_dataout(ZOOM2_LED_BLUE2, 1);
+ }
+
+ saved_state[STATUS_LED_BLUE] = STATUS_LED_ON;
+}
+
+void __led_init (led_id_t mask, int state)
+{
+ __led_set (mask, state);
+}
+
+void __led_toggle (led_id_t mask)
+{
+ if (STATUS_LED_BLUE == mask) {
+ if (STATUS_LED_ON == saved_state[STATUS_LED_BLUE])
+ blue_LED_off ();
+ else
+ blue_LED_on ();
+ } else if (STATUS_LED_RED == mask) {
+ if (STATUS_LED_ON == saved_state[STATUS_LED_RED])
+ red_LED_off ();
+ else
+ red_LED_on ();
+ }
+}
+
+void __led_set (led_id_t mask, int state)
+{
+ if (STATUS_LED_BLUE == mask) {
+ if (STATUS_LED_ON == state)
+ blue_LED_on ();
+ else
+ blue_LED_off ();
+ } else if (STATUS_LED_RED == mask) {
+ if (STATUS_LED_ON == state)
+ red_LED_on ();
+ else
+ red_LED_off ();
+ }
+}
diff --git a/board/omap3/zoom2/zoom2.c b/board/omap3/zoom2/zoom2.c
index dd0086c..f4ec38d 100644
--- a/board/omap3/zoom2/zoom2.c
+++ b/board/omap3/zoom2/zoom2.c
@@ -29,6 +29,9 @@
* MA 02111-1307 USA
*/
#include
+#ifdef
Re: [U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.
On Thu, May 07, 2009 at 03:13:40PM -0500, Andy Fleming wrote: > On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy wrote: > > Cards which are not compatible with SD 2.0 standard, cat return response > > for CMD8 command, but it will be invalid in terms of SD 2.0. We should > > accept this case as admissible. > > > > Signed-off-by: Yauhen Kharuzhy > > > You've got a typo in the description on a key word, "cat". Is it can't? can? I am sorry, yes, it is 'can'. > > I'm not convinced that this patch is valid. My understanding is that > if a card receives a command it does not understand, it should not > respond. Thus, if it responds with an error, it's an actual error. > Are you saying that some cards respond to cmd 8 that don't implement > 2.0? Because that would not totally surprise me, but would violate > not just 2.0, but 1.x, as CMD8 is reserved. MMC cards should also not > respond to CMD8 at this stage in initialization, as they are in the > wrong state... I just to try all my cards with my device, and every card responds to CMD8. Probably, this is bug in the implementation of the my MMC host driver (for Ingenic JZ4740 SoC). I compared card initialization procedure with Linux kernel's one and found that any error is ignored in it and means that the card is not SD 2.0 compatible. I will re-check the host controller driver for timeout handling, but it seems clear. -- Yauhen Kharuzhy jekhor _at_ gmail.com JID: j...@jabber.ru A: No Q: Should I quote below my post? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Fix decoding of SCR & function switch data on little-endian machines
On May 6, 2009, at 4:43 PM, Yauhen Kharuzhy wrote:
> SCR & switch data are read from card as big-endian words and should be
> converted to CPU byte order.
>
> Signed-off-by: Yauhen Kharuzhy
> ---
>
> - if ((switch_status[4] & 0x0f00) == 0x0100)
> + if ((__be32_to_cpu(switch_status[4]) & 0x0f00) == 0x0100) {
> mmc->card_caps |= MMC_MODE_HS;
> + printf("Switched to HS mode\n");
> + }
You left some debug output there.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On Thu, May 07, 2009 at 11:02:34PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: > > Can you please run a "git show 24e37645" again? > > > > To me it seems that this commit > > > > - removed the usage of UP2OCR from board/delta/delta.c > > but also > > - added the usage of UP2OCR to the new file cpu/pxa/usb.c > > without defining it. > > > > > > So the comment seems absolutely correct to me. Maybe I'm missing > > something? > It's me I mix the commit > this commit 3ccbfb25f48a:Support for PXA27X UDC. > brake the pxa support > by removing the UP2OCR I was just running 'git blame' on the file that broke the build and pointed out the commit that added the line that made the trouble. I don't see what shouldn't be correct about that? Anyway, feel free to change the commit log if you like, I don't care. Most important thing is that things get fixed. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] mxc-mmc: sdhc host driver for MX2 and MX3 proccessor
HI Ilya, > This is a port of Linux driver for SDHC host controller hardware > found on Freescale's MX2 and MX3 processors. Uses new generic MMC > framework (CONFIG_GENERIC_MMC) and it looks like there are some > problems with a framework (at least on LE cpus). Some of these > problems are addressed in the following patches. Would your patch work for the MX31 pdk. Or it will not work as-is is because the IOMUX setup might be different between MX27 and 31. Al though i have verified that the register set for the HController is the same. Can this be used as a base though? Thanks. Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add Sequoia RAM-booting target
Hi Wolfgang, On Thursday 07 May 2009, Wolfgang Denk wrote: > > Perhaps it's quite new to the Linux kernel. I just spotted it the first > > time a few weeks ago and thought: "What a nice way to remove some of the > > ugly #ifdef's in U-Boot!". :) > > My understanding was that this is (only?) intended for function > declarations to silence warnings about unused function arguments > (which may be necessary anyway for compatible call interface with > other functions that actually need this arg). No. This is not the case. Just take a look at the usage in drivers/net for example. You will see this construct is used here exactly to prevent those #ifdef's in the variable declaration in many cases: drivers/net/bnx2.c: int hw_vlan __maybe_unused = 0; ... #ifdef BCM_VLAN if (bp->vlgrp) hw_vlan = 1; else #endif But ok, if nobody else other than me prefers this version then I'll change to those #ifdef's again. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
Hi Stefan,
Stefan Roese wrote:
> Hi Daniel,
>
> On Wednesday 06 May 2009, Daniel Gorsulowski wrote:
>> This patch allows any at91 board, implementing the GPIO LED API,
>> to control the LEDs from the console.
>>
>> led [ 1 | 2 | 3 | all ] [ on | off ]
>
> Why limit this to a max of 3 LED's? If this is a generic command (which I
> like
> btw) then we should support a user/board defined number of LED's. In your
> case
> it's 3, but the infrastructure should support any number.
>
> More comments below.
>
>
>
...
>
> I suggest to use something like this here:
>
> led_nr = simple_strtoul(argv[1], NULL, 10);
> if (led_nr > CONFIG_LED_MAX) {
> printf ("Usage:\n%s\n", cmdtp->usage);
> return 1;
> }
>
> if (strcmp(argv[2], "off") == 0) {
> on = 1;
> } else if (strcmp(argv[2], "on") == 0) {
> on = 0;
> } else {
> printf ("Usage:\n%s\n", cmdtp->usage);
> return 1;
> }
>
> user_led(led_nr, on);
>
> No ugly #ifdef's in this case. What do you think?
>
> Best regards,
> Stefan
>
I agree with you.
Please give me some days, to implement your basic approaches.
I've many other things to do and it's not that easy (for me)
to create a tidy patch.
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
Wolfgang Denk schrieb: > Dear Daniel Gorsulowski, > > In message <4a02792b.8060...@esd.eu> you wrote: >>> Ummm... common is for, well, for >>common<< stuff. If this code is >>> specific to AT91 only, it should not go into common. >>> >> IMHO this code is not specific to AT91 only. Well, other architectures does >> not >> support the CONFIG_CMD_LED yet, but they could be implemented later. > > This is not quite correct. Actually several boards already support > this, or very similar functions: > > board/amcc/taihu/taihu.c:static int do_led_ctl(cmd_tbl_t* cmd_tp, int flags, > int argc, char *argv[]) > board/amcc/taishan/lcd.c:static int do_led_test_off(cmd_tbl_t * cmdtp, int > flag, int argc, char *argv[]) > board/amcc/taishan/lcd.c:static int do_led_test_on(cmd_tbl_t * cmdtp, int > flag, int argc, char *argv[]) > board/cm5200/cmd_cm5200.c:int do_led(char *argv[]) > board/pcs440ep/pcs440ep.c:int do_led (cmd_tbl_t *cmdtp, int flag, int argc, > char *argv[]) > board/pn62/cmd_pn62.c:int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char > *argv[]) > board/tqc/tqm5200/cmd_stk52xx.c:int do_led(char *argv[]) > board/trab/trab_fkt.c:int do_led (char **); > board/trab/trab_fkt.c:int do_led (char **argv) > Can you tell me a better place for at91 specific code? I think lib_arm is not the proper place for it. I meant to place it in arm926ejs/at91, what do you mean? > ... > > Best regards, > > Wolfgang Denk > Best regards, Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Unable to debug UBOOT
Hello guys I am newbie in bootloader. I am trying to port latest uboot on omap2430(poseidon board). Currently support for omap2430 is not present in uboot; so I made changes accordingly. I am putting it in RAM using Trace 32 debugger. But unable to get prompt. Code hangs but giving message *"DRAM: 64MB" ...* Please suggest me different ways of debugging uboot. I tried using Trace 32(LAUTERBACH JTAG debugger). Loaded uboot elf file(u-boot) into RAM. I am getting symbols and function names. But unable to put breakpoints. Also C code is not visible even after changing mode. Please suggest me ways to debug uboot. -- Cheers Vivek Dalal === He who angers you conquers you === ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to debug UBOOT
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Vivek DALAL > Sent: Friday, May 08, 2009 11:43 AM > To: U-Boot@lists.denx.de > Subject: [U-Boot] Unable to debug UBOOT > > Hello guys > > I am newbie in bootloader. > I am trying to port latest uboot on omap2430(poseidon board). > Currently support for omap2430 is not present in uboot; so I > made changes accordingly. > > I am putting it in RAM using Trace 32 debugger. But unable to > get prompt. > Code hangs but giving message *"DRAM: 64MB" ...* Please Looks like you are reinitializing the DDR , when u are already executing from it, you may want to comment out that code, which initializes DDR. > suggest me different ways of debugging uboot. > I tried using Trace 32(LAUTERBACH JTAG debugger). Loaded uboot elf > file(u-boot) into RAM. I am getting symbols and function > names. But unable to put breakpoints. Also C code is not > visible even after changing mode. > > Please suggest me ways to debug uboot. > > -- > Cheers > > Vivek Dalal > === He who angers you conquers you === > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
Hi Daniel,
On Friday 08 May 2009, Daniel Gorsulowski wrote:
> > I suggest to use something like this here:
> >
> > led_nr = simple_strtoul(argv[1], NULL, 10);
> > if (led_nr > CONFIG_LED_MAX) {
> > printf ("Usage:\n%s\n", cmdtp->usage);
> > return 1;
> > }
> >
> > if (strcmp(argv[2], "off") == 0) {
> > on = 1;
> > } else if (strcmp(argv[2], "on") == 0) {
> > on = 0;
> > } else {
> > printf ("Usage:\n%s\n", cmdtp->usage);
> > return 1;
> > }
> >
> > user_led(led_nr, on);
> >
> > No ugly #ifdef's in this case. What do you think?
> >
> > Best regards,
> > Stefan
>
> I agree with you.
Good. :)
> Please give me some days, to implement your basic approaches.
> I've many other things to do and it's not that easy (for me)
> to create a tidy patch.
Sure. Take your time.
Thanks.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
