Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
Dear Wolfgang Denk, Wolfgang Denk wrote: Dear Daniel Gorsulowski, In message 1241619669338-git-send-email-daniel.gorsulow...@esd.eu you 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 ] Adding configuration items CONFIG_AT91_LED and CONFIG_CMD_LED enables the command. Moreover the GPIO Pins have to be defined by CONFIG_USER1_LED ... CONFIG_USER3_LED. Signed-off-by: line missing. Sorry, I'll fix that by the next patch. --- common/Makefile |1 + common/cmd_led.c| 86 +++ cpu/arm926ejs/at91/led.c| 79 +++ include/asm-arm/arch-at91/led.h | 52 +++ 4 files changed, 218 insertions(+), 0 deletions(-) create mode 100644 common/cmd_led.c create mode 100644 include/asm-arm/arch-at91/led.h diff --git a/common/Makefile b/common/Makefile index b9f4ca7..e0f571c 100644 --- a/common/Makefile +++ b/common/Makefile @@ -103,6 +103,7 @@ COBJS-$(CONFIG_CMD_IMMAP) += cmd_immap.o COBJS-$(CONFIG_CMD_IRQ) += cmd_irq.o COBJS-$(CONFIG_CMD_ITEST) += cmd_itest.o COBJS-$(CONFIG_CMD_JFFS2) += cmd_jffs2.o +COBJS-$(CONFIG_CMD_LED) += cmd_led.o COBJS-$(CONFIG_CMD_LICENSE) += cmd_license.o COBJS-y += cmd_load.o COBJS-$(CONFIG_LOGBUFFER) += cmd_log.o diff --git a/common/cmd_led.c b/common/cmd_led.c 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. ... +U_BOOT_CMD( +led, 3, 1, do_led, +[1|2|3|all] [on|off], +[1|2|3|all] [on|off] sets/clears led 1,2,3 Do you really say I set a LED? I clear a LED? I don't think so. Ok, I'll write turns led 1,2,3 on/off. diff --git a/include/asm-arm/arch-at91/led.h b/include/asm-arm/arch-at91/led.h new file mode 100644 index 000..878b2cf --- /dev/null +++ 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. 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
Re: [U-Boot] [PATCH 1/1] at91: Add command to control up to 3 GPIO LEDs from the console
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.
snip
diff --git a/common/cmd_led.c b/common/cmd_led.c
new file mode 100644
index 000..f914d2d
--- /dev/null
+++ b/common/cmd_led.c
@@ -0,0 +1,86 @@
+/*
+ * (C) Copyright 2008
+ * Ulf Samuelsson ulf.samuelsson at atmel.com
+ *
+ * (C) Copyright 2009
+ * Daniel Gorsulowski daniel.gorsulow...@esd.eu
+ * esd electronic system design gmbh www.esd.eu
+ *
+ * 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 common.h
+#include config.h
+#include command.h
+#include asm/arch/led.h
+
+int do_led(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ int led;
+
+ /* Validate arguments */
+ if ((argc != 3)) {
+ printf(Usage:\n%s\n, cmdtp-usage);
+ return 1;
+ }
+ if (strcmp(argv[1], 1) == 0) {
+ led = (1 0);
+ } else if (strcmp(argv[1], 2) == 0) {
+ led = (1 1);
+ } else if (strcmp(argv[1], 3) == 0) {
+ led = (1 2);
+ } else if (strcmp(argv[1], all) == 0) {
+ led = 31;
+ } else {
+ printf (Usage:\n%s\n, cmdtp-usage);
+ return 1;
+ }
Here we have the problem with max of 3 again. Why not just scan the 2nd
parameter as an int and use it as parameter for the following function calls
(see below)?
+
+ if (strcmp(argv[2], off) == 0) {
+#ifdef CONFIG_USER1_LED
+ if(led 1) user1_led_off();
+#endif
+#ifdef CONFIG_USER2_LED
+ if(led 2) user2_led_off();
+#endif
+#ifdef CONFIG_USER3_LED
+ if(led 4) user3_led_off();
+#endif
+ } else if (strcmp(argv[2], on) == 0) {
+#ifdef CONFIG_USER1_LED
+ if(led 1) user1_led_on();
+#endif
+#ifdef CONFIG_USER2_LED
+ if(led 2) user2_led_on();
+#endif
+#ifdef CONFIG_USER3_LED
+ if(led 4) user3_led_on();
+#endif
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] Marvell MV88F6281GTW_GE Board support
From: prafulla_wadaskar prafu...@marvell.com This is Marvell's 88F6281_A0 based custom board developed for wireless access point product This patch is tested for- 1. Boot from DRAM/SPI flash/NFS 2. File transfer using tftp and loadb 3. SPI flash read/write/erase 4. Booting Linux kernel and RFS from SPI flash Reviewed-by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log v2: updated as per first review comments debug_prints updated to debug v3: updaed as per review comments for v2 added mv88f6281gtw_ge.h file removed BITxx macros v4: updated as per review comments for v3 arch_misc_init support is added and used from kirkwood v5: updated as per review comments for v4 CONFIG_MACH_MV88F6281GTW_GE added more comments added and serial configuration removed from mv88f6281gtw_ge.c V6: clean switch configuration using netdev.h v7: Marvell copyright removed from u-boot.lds Maintainer added for this board MAKEALL |1 + Makefile|3 + board/Marvell/mv88f6281gtw_ge/Makefile | 51 +++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 89 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 51 +++ board/Marvell/mv88f6281gtw_ge/u-boot.lds| 51 +++ include/configs/mv88f6281gtw_ge.h | 180 +++ 8 files changed, 451 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h create mode 100644 board/Marvell/mv88f6281gtw_ge/u-boot.lds create mode 100644 include/configs/mv88f6281gtw_ge.h diff --git a/MAKEALL b/MAKEALL index f13c81a..a7545c9 100755 --- a/MAKEALL +++ b/MAKEALL @@ -504,6 +504,7 @@ LIST_ARM9= \ cp946es \ cp966 \ lpd7a400\ + mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ netstar \ diff --git a/Makefile b/Makefile index 137c88f..5ff750c 100644 --- a/Makefile +++ b/Makefile @@ -2794,6 +2794,9 @@ lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x +mv88f6281gtw_ge_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + mx1ads_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t mx1ads NULL imx diff --git a/board/Marvell/mv88f6281gtw_ge/Makefile b/board/Marvell/mv88f6281gtw_ge/Makefile new file mode 100644 index 000..8c49a3e --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := mv88f6281gtw_ge.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk b/board/Marvell/mv88f6281gtw_ge/config.mk new file mode 100644 index 000..fb29a1b --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under
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 mlud...@ultratronik.de
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 mlud...@ultratronik.de
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] How to change the entry point for standalone Applications same as the text section base address
Dear ffmm rrcc,
In message dbab92f10905062254s3bea0882y7d4ec546c4ddb...@mail.gmail.com 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 jek...@gmail.com --- 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 d...@denx.de Cc: Sascha Hauer s.ha...@pengutronix.de --- 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 jonsm...@gmail.com 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 elffile
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:
440EPXload 0x100 /tftpboot/sequoia/u-boot.bin
440EPXgo 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 s...@denx.de
---
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 fe...@embedded-sol.com 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 gerald.vanba...@ge.com 05/07/2009 07:10 PM To Deepak Gopalakrishnan deepak.gopalakrish...@lntemsys.com 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 gerald.vanba...@ge.com 05/07/2009 07:10 PM To Deepak Gopalakrishnan deepak.gopalakrish...@lntemsys.com 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 jek...@gmail.com 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 jek...@gmail.com 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/arch/soc for the davinci it's already start to move to it Best Regards, J. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- 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] [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 tom@windriver.com
---
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, g...@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
- */
-
-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, g...@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
- */
-
-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] [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 tom@windriver.com
---
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 tom@windriver.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * 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ä juha.yrj...@nokia.com
+ *
+ * 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 common.h
+#include asm/arch/gpio.h
+#include asm/io.h
+#include asm/errno.h
+
+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;
+ }
+
[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 tom@windriver.com
---
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 tom@windriver.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include common.h
+#include asm/arch/cpu.h
+#include asm/io.h
+#include asm/arch/mux.h
+#include asm/arch/gpio.h
+
+#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 tom@windriver.com
---
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 common.h
#include asm/io.h
+#include asm/arch/mem.h
#include asm/arch/mux.h
#include asm/arch/sys_proto.h
#include asm/mach-types.h
#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 tom@windriver.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This file was adapted from cpu/mpc5xxx/serial.c
+ *
+ */
+
+#include common.h
+#include serial.h
+#include ns16550.h
+#include asm/arch/cpu.h
+#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.
+
[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 tom@windriver.com
---
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 tom@windriver.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include status_led.h
+#include asm/arch/cpu.h
+#include asm/io.h
+#include asm/arch/sys_proto.h
+#include asm/arch/gpio.h
+
+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
---
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 jek...@gmail.com 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 jek...@gmail.com 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 jek...@gmail.com
---
- 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.
snip
...
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
