[U-Boot] bug when using environment in an i2c eeprom and SPI is enabled?
Hello Wolfgang, I actually try to use Environment on an I2C EEprom with SPI enabled, and found in include/common.h the following defines @line 326ff: /* * Set this up regardless of board * type, to prevent errors. */ #if defined(CONFIG_SPI) || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) # define CONFIG_SYS_DEF_EEPROM_ADDR 0 #else # define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR #endif /* CONFIG_SPI || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) */ So, it seems to me, that, if SPI is enabled, it is not possible to use an I2C EEprom with an address != 0, because in common/env_eeprom.c @line79 in env_init(): /* read old CRC */a eeprom_read (CONFIG_SYS_DEF_EEPROM_ADDR, CONFIG_ENV_OFFSET+offsetof(env_t,crc), (uchar *)crc, sizeof(ulong)); CONFIG_SYS_DEF_EEPROM_ADDR is fix used ... I tried to use git blame to find out where this comes from, but this is in code since the initial revision ... so I ask here on the mailinglist, if somebody knows, if this is a feature or a bug? BTW, I think it should be: diff --git a/include/common.h b/include/common.h index 9e4b859..411563b 100644 --- a/include/common.h +++ b/include/common.h @@ -327,7 +327,7 @@ extern void pic_write (uchar reg, uchar val); * Set this up regardless of board * type, to prevent errors. */ -#if defined(CONFIG_SPI) || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) +#if defined(CONFIG_SPI) !defined(CONFIG_SYS_I2C_EEPROM_ADDR) # define CONFIG_SYS_DEF_EEPROM_ADDR 0 #else # define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR What do you think? thanks Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] Add Eukrea CPUIMX27 support
Hi Eric, On Wed, Jul 15, 2009 at 05:18:39PM +0200, Eric Benard wrote: CPUIMX27 is built around Freescale's i.MX27 and has up to 64MB of NOR Flash, up to 512MB of NAND Flash and up to 256MB of mDDR, it includes an ethernet PHY in MII mode, an I2C RTC and a ST16554 QuadUART on nCS3. Looks good. Applied, thanks. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, kirkwood: added kw_gpio_set_valid() in gpio.h
Signed-off-by: Heiko Schocher h...@denx.de --- This patch needs the patch from: http://lists.denx.de/pipermail/u-boot/2009-July/055854.html first applied. include/asm-arm/arch-kirkwood/gpio.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-kirkwood/gpio.h b/include/asm-arm/arch-kirkwood/gpio.h index cac58f4..aa880c0 100644 --- a/include/asm-arm/arch-kirkwood/gpio.h +++ b/include/asm-arm/arch-kirkwood/gpio.h @@ -37,6 +37,8 @@ /* * Kirkwood-specific GPIO API */ + +void kw_gpio_set_valid(unsigned pin, int mode); int kw_gpio_is_valid(unsigned pin, int mode); int kw_gpio_direction_input(unsigned pin); int kw_gpio_direction_output(unsigned pin, int value); -- 1.6.0.6 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, kirkwood: added KW_TWSI_BASE in kirkwood.h
Signed-off-by: Heiko Schocher h...@denx.de --- include/asm-arm/arch-kirkwood/kirkwood.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-kirkwood/kirkwood.h b/include/asm-arm/arch-kirkwood/kirkwood.h index 47679dd..2470efb 100644 --- a/include/asm-arm/arch-kirkwood/kirkwood.h +++ b/include/asm-arm/arch-kirkwood/kirkwood.h @@ -44,6 +44,7 @@ #define KW_REG_UNDOC_0x1470(KW_REGISTER(0x1470)) #define KW_REG_UNDOC_0x1478(KW_REGISTER(0x1478)) +#define KW_TWSI_BASE (KW_REGISTER(0x11000)) #define KW_UART0_BASE (KW_REGISTER(0x12000)) #define KW_UART1_BASE (KW_REGISTER(0x12100)) #define KW_MPP_BASE(KW_REGISTER(0x1)) -- 1.6.0.6 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, i2c: added support for the TWSI I2C Interface
added support for the Hardware I2C TWSI Interface on
kirkwood SOCs, based on the Linux driver, without IRQ
support.
Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131
SOC Family: KIRKWOOD, KW88F6281) based suen3 board
Signed-off-by: Heiko Schocher h...@denx.de
---
drivers/i2c/Makefile |1 +
drivers/i2c/mv64xxx-i2c.c | 452 +
2 files changed, 453 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/mv64xxx-i2c.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index ef32f13..ce30111 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o
COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o
+COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o
COBJS-$(CONFIG_S3C44B0_I2C) += s3c44b0_i2c.o
COBJS-$(CONFIG_SOFT_I2C) += soft_i2c.o
COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
diff --git a/drivers/i2c/mv64xxx-i2c.c b/drivers/i2c/mv64xxx-i2c.c
new file mode 100644
index 000..6ba2782
--- /dev/null
+++ b/drivers/i2c/mv64xxx-i2c.c
@@ -0,0 +1,452 @@
+/*
+ * Driver for the i2c controller on the Marvell line of host bridges
+ * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, and Orion SoC family).
+ *
+ * Based on:
+ * Author: Mark A. Greer mgr...@mvista.com
+ *
+ * 2005 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ *
+ * ported from Linux to u-boot
+ * (C) Copyright 2009
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ */
+#include common.h
+#include i2c.h
+#include asm/arch/kirkwood.h
+#include asm/errno.h
+#include asm/io.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static unsigned int i2c_bus_num __attribute__ ((section (.data))) = 0;
+#if defined(CONFIG_I2C_MUX)
+static unsigned int i2c_bus_num_mux __attribute__ ((section (data))) = 0;
+#endif
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR 0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS 0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR 0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET 0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START 0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN 0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN 0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR 0x00
+#defineMV64XXX_I2C_STATUS_MAST_START 0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK 0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK 0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK 0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK 0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+
+/* Driver states */
+enum {
+ MV64XXX_I2C_STATE_INVALID,
+ MV64XXX_I2C_STATE_IDLE,
+ MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
+ MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA,
+};
+
+/* Driver actions */
+enum {
+ MV64XXX_I2C_ACTION_INVALID,
+ MV64XXX_I2C_ACTION_CONTINUE,
+ MV64XXX_I2C_ACTION_SEND_START,
+ MV64XXX_I2C_ACTION_SEND_ADDR_1,
+ MV64XXX_I2C_ACTION_SEND_ADDR_2,
+ MV64XXX_I2C_ACTION_SEND_DATA,
+ MV64XXX_I2C_ACTION_RCV_DATA,
+ MV64XXX_I2C_ACTION_RCV_DATA_STOP,
+ MV64XXX_I2C_ACTION_SEND_STOP,
+};
Re: [U-Boot] CONFIG_API, EABI and raise()
On 2009-07-15, at 18:09, Mike Frysinger wrote: On Wednesday 15 July 2009 11:15:46 Rafal Jaworowski wrote: On 2009-07-15, at 16:58, Mike Frysinger wrote: On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: While working on U-Boot for our board we have found problem related to CONFIG_API option. In general, enabling it causes build failure. Our tests showed that problem exists also on other ARM U-Boot targets (for example davinci_dvevm). Do you think that this problem may be caused by your libgcc-related cleanups ? If so, do you have any idea how to fix it ? sounds more like it's always been a bug, but Jean's cleanup will fix it eventually CONFIG_API worked fine for ARM builds some time ago, and this breakage seems like a recent development. or, it still works fine if your toolchain doesnt suck and isnt broken The toolchain is ELDK 4.2 and has worked fine for longer time. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_API, EABI and raise()
Hi Rafal, On Thursday 16 July 2009 10:37:34 Rafal Jaworowski wrote: On 2009-07-15, at 18:09, Mike Frysinger wrote: On Wednesday 15 July 2009 11:15:46 Rafal Jaworowski wrote: On 2009-07-15, at 16:58, Mike Frysinger wrote: On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: While working on U-Boot for our board we have found problem related to CONFIG_API option. In general, enabling it causes build failure. Our tests showed that problem exists also on other ARM U-Boot targets (for example davinci_dvevm). Do you think that this problem may be caused by your libgcc-related cleanups ? If so, do you have any idea how to fix it ? sounds more like it's always been a bug, but Jean's cleanup will fix it eventually CONFIG_API worked fine for ARM builds some time ago, and this breakage seems like a recent development. or, it still works fine if your toolchain doesnt suck and isnt broken The toolchain is ELDK 4.2 and has worked fine for longer time. Just to make it clear: The libgcc removal patches for ARM from Jean-Christophe are not added yet. So if you see a problem with EABI etc, some other patches have to be the reason for this. And very likely Jean-Christophe's patches could fix the problems. 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] arm, i2c: added support for the TWSI I2C Interface
-Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order COBJS-$(CONFIG_S3C44B0_I2C) += s3c44b0_i2c.o COBJS-$(CONFIG_SOFT_I2C) += soft_i2c.o COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o diff --git a/drivers/i2c/mv64xxx-i2c.c b/drivers/i2c/mv64xxx-i2c.c new file mode 100644 index 000..6ba2782 --- /dev/null +++ b/drivers/i2c/mv64xxx-i2c.c @@ -0,0 +1,452 @@ +/* + * Driver for the i2c controller on the Marvell line of host bridges + * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, and Orion SoC family). Pls add kirkwood too.. + * + * Based on: + * Author: Mark A. Greer mgr...@mvista.com + * + * 2005 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed as is without any warranty of any kind, whether express + * or implied. + * + * ported from Linux to u-boot + * (C) Copyright 2009 + * Heiko Schocher, DENX Software Engineering, h...@denx.de. + * + */ +#include common.h +#include i2c.h +#include asm/arch/kirkwood.h +#include asm/errno.h +#include asm/io.h + +DECLARE_GLOBAL_DATA_PTR; + +static unsigned int i2c_bus_num __attribute__ ((section (.data))) = 0; +#if defined(CONFIG_I2C_MUX) +static unsigned int i2c_bus_num_mux __attribute__ ((section (data))) = 0; +#endif + +/* Register defines */ +#define MV64XXX_I2C_REG_SLAVE_ADDR 0x00 +#define MV64XXX_I2C_REG_DATA0x04 MV64XX does not sound generic supported SoCs, Can you choose better name? like TWSI. I will go through in details latter on Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100 Ethernet PHY in RMII mode. Signed-off-by: Eric Benard e...@eukrea.com --- MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/eukrea/cpu9260/Makefile | 59 +++ board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 209 +++ board/eukrea/cpu9260/cpu9260_led.c | 46 + cpu/arm926ejs/at91/lowlevel_init.S |2 +- include/configs/cpu9260.h | 326 9 files changed, 650 insertions(+), 1 deletions(-) create mode 100644 board/eukrea/cpu9260/Makefile create mode 100644 board/eukrea/cpu9260/config.mk create mode 100644 board/eukrea/cpu9260/cpu9260.c create mode 100644 board/eukrea/cpu9260/cpu9260_led.c create mode 100644 include/configs/cpu9260.h diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..b8d701a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -515,6 +515,10 @@ Dirk Behme dirk.be...@gmail.com omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) +Eric Benard e...@eukrea.com + + cpu9260 ARM926EJS (AT91SAM9260 SoC) + Rishi Bhattacharya ri...@ti.com omap5912osk ARM926EJS diff --git a/MAKEALL b/MAKEALL index 020ff73..bdc80fa 100755 --- a/MAKEALL +++ b/MAKEALL @@ -592,6 +592,7 @@ LIST_at91= \ at91sam9m10g45ek\ at91sam9rlek\ cmc_pu2 \ + cpu9260 \ csb637 \ kb9202 \ meesc \ diff --git a/Makefile b/Makefile index 090e645..3b7f427 100644 --- a/Makefile +++ b/Makefile @@ -2813,6 +2813,9 @@ at91sam9rlek_config : unconfig fi; @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91 +cpu9260_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs cpu9260 eukrea at91 + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile new file mode 100644 index 000..5b1acdc --- /dev/null +++ b/board/eukrea/cpu9260/Makefile @@ -0,0 +1,59 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# Ilko Iliev www.ronetix.at +# +# (C) Copyright 2009 +# Eric Benard e...@eukrea.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y += $(BOARD).o +COBJS-y += $(BOARD)_led.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk new file mode 100644 index 000..9ce161e --- /dev/null +++ b/board/eukrea/cpu9260/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x21f0 diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c new file mode 100644 index 000..22c6ab6 --- /dev/null +++ b/board/eukrea/cpu9260/cpu9260.c @@ -0,0 +1,209 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop stelian@leadtechdesign.com + * Lead Tech Design www.leadtechdesign.com + * Ilko Iliev www.ronetix.at + * + * (C) Copyright 2009 + * Eric Benard e...@eukrea.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
Re: [U-Boot] CONFIG_API, EABI and raise()
Hi Stefan, On 2009-07-16, at 10:46, Stefan Roese wrote: On Thursday 16 July 2009 10:37:34 Rafal Jaworowski wrote: On 2009-07-15, at 18:09, Mike Frysinger wrote: On Wednesday 15 July 2009 11:15:46 Rafal Jaworowski wrote: On 2009-07-15, at 16:58, Mike Frysinger wrote: On Tuesday 14 July 2009 09:47:26 Piotr Zięcik wrote: While working on U-Boot for our board we have found problem related to CONFIG_API option. In general, enabling it causes build failure. Our tests showed that problem exists also on other ARM U-Boot targets (for example davinci_dvevm). Do you think that this problem may be caused by your libgcc- related cleanups ? If so, do you have any idea how to fix it ? sounds more like it's always been a bug, but Jean's cleanup will fix it eventually CONFIG_API worked fine for ARM builds some time ago, and this breakage seems like a recent development. or, it still works fine if your toolchain doesnt suck and isnt broken The toolchain is ELDK 4.2 and has worked fine for longer time. Just to make it clear: The libgcc removal patches for ARM from Jean- Christophe are not added yet. So if you see a problem with EABI etc, some other patches have to be the reason for this. And very likely Jean-Christophe's patches could fix the problems. Thanks for pointing this out, we'll look into it some more (I'm all for removing libgcc dependency, but was under the impression that parts of this rework was already included in main line, and thought there might be some loose ends or so). Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
Wednesday 15 July 2009 17:05:44 Mike Frysinger napisał(a): On Tuesday 14 July 2009 04:08:35 Piotr Ziecik wrote: When packets arrive on the interface that are larger than the buffer being passed to U-Boot from a standalone application, then the eth_receive() returns -1 and leaves the packet saved. The next call to eth_receive() will find that same packet and can fail for the exact same reason. A typical scenario is the loader doing ARP with a buffer of 66 bytes. The end result is that the ARP will fail and the loader panics. This patch fixes above problem by allowing partial packet read. seems like it could easily introduce incorrect behavior in existing applications. the code also sounds a bit risky ... your change would mean people could read the leading part, but the rest is lost ? Yes. The patch allows read only first n bytes from packet. The rest is discaded, if buffer is too small. This behaviour is similar to Linux recv() function. I do not see why we have to force application to prepare 1,5kB buffer for received packets when for example it waits for ARP reply. probably better to add a new function with explicit semantics -- eth_receive_partial() or something. API uses simple open, read/write, close model. The eth_receive() function is used by API read() call on network device. I do not see space here another function. -- Best regards, Piotr Ziecik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? Of course, what name do you prefer? + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order What do you mean? COBJS-$(CONFIG_S3C44B0_I2C) += s3c44b0_i2c.o COBJS-$(CONFIG_SOFT_I2C) += soft_i2c.o COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o diff --git a/drivers/i2c/mv64xxx-i2c.c b/drivers/i2c/mv64xxx-i2c.c new file mode 100644 index 000..6ba2782 --- /dev/null +++ b/drivers/i2c/mv64xxx-i2c.c @@ -0,0 +1,452 @@ +/* + * Driver for the i2c controller on the Marvell line of host bridges + * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, and Orion SoC family). Pls add kirkwood too.. OK. + * + * Based on: + * Author: Mark A. Greer mgr...@mvista.com + * + * 2005 (c) MontaVista, Software, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed as is without any warranty of any kind, whether express + * or implied. + * + * ported from Linux to u-boot + * (C) Copyright 2009 + * Heiko Schocher, DENX Software Engineering, h...@denx.de. + * + */ +#include common.h +#include i2c.h +#include asm/arch/kirkwood.h +#include asm/errno.h +#include asm/io.h + +DECLARE_GLOBAL_DATA_PTR; + +static unsigned int i2c_bus_num __attribute__ ((section (.data))) = 0; +#if defined(CONFIG_I2C_MUX) +static unsigned int i2c_bus_num_mux __attribute__ ((section (data))) = 0; +#endif + +/* Register defines */ +#define MV64XXX_I2C_REG_SLAVE_ADDR 0x00 +#define MV64XXX_I2C_REG_DATA0x04 MV64XX does not sound generic supported SoCs, Can you choose better name? like TWSI. Ah, OK. Used the names from the Linux driver. So I think above define for selecting this drivers should be something like that: CONFIG_DRIVER_I2C_TWSI ... (I vote for using CONFIG_DRIVER_I2C_ for new drivers and maybe I find some time renaming the existing drivers to this format...) and replace MV64xxx with TWSI ... right? I will go through in details latter on OK, thanks in advance. bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ppc4xx: Add 405EP based PMC405DE board
Hi Wolfgang,
On Wednesday 15 July 2009 17:08, Wolfgang Denk wrote:
Dear Matthias Fuchs,
In message 200907151251.25985.matthias.fu...@esd.eu you wrote:
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
...
diff --git a/board/esd/pmc405de/pmc405de.c b/board/esd/pmc405de/pmc405de.c
new file mode 100644
index 000..ca26d5c
--- /dev/null
+++ b/board/esd/pmc405de/pmc405de.c
...
+ if ((pllmr0 PLLMR0_CPU_TO_PLB_MASK) == PLLMR0_CPU_PLB_DIV_3) {
+ /* fCPU=333MHz, fPLB=111MHz */
+ if (pci_is_66mhz()) {
+ if ((pllmr0 PLLMR0_PCI_TO_PLB_MASK) !=
+ PLLMR0_PCI_PLB_DIV_1) {
+ pll_write((pllmr0 ~PLLMR0_PCI_TO_PLB_MASK) |
+ PLLMR0_PCI_PLB_DIV_1, pllmr1);
+ }
+ } else {
+ if ((pllmr0 PLLMR0_PCI_TO_PLB_MASK) !=
+ PLLMR0_PCI_PLB_DIV_2) {
+ pll_write((pllmr0 ~PLLMR0_PCI_TO_PLB_MASK) |
+ PLLMR0_PCI_PLB_DIV_2, pllmr1);
+ }
+ }
+ } else {
+ /* fCPU=133|266MHz, fPLB=133MHz */
+ if (pci_is_66mhz()) {
+ if ((pllmr0 PLLMR0_PCI_TO_PLB_MASK) !=
+ PLLMR0_PCI_PLB_DIV_2) {
+ pll_write((pllmr0 ~PLLMR0_PCI_TO_PLB_MASK) |
+ PLLMR0_PCI_PLB_DIV_2, pllmr1);
+ }
+ } else {
+ if ((pllmr0 PLLMR0_PCI_TO_PLB_MASK) !=
+ PLLMR0_PCI_PLB_DIV_3) {
+ pll_write((pllmr0 ~PLLMR0_PCI_TO_PLB_MASK) |
+ PLLMR0_PCI_PLB_DIV_3, pllmr1);
+ }
+ }
+ }
Please try to factor out repeated code like here.
Ack.
+static int is_monarch(void)
+{
+ if (in_be32((void*)GPIO0_IR) CONFIG_SYS_GPIO_MONARCH_N)
+ return 0;
+ return 1;
or:
return (in_be32((void*)GPIO0_IR) CONFIG_SYS_GPIO_MONARCH_N) == 0;
Ack.
Umm... and why do we need a cast here? This should be fixed.
The in/out_be16/32 functions expect a pointer. When you grep over the
U-Boot sources you will find tons of places with this cast.
So I will and cannot fix this with my patch.
We could put the cast into the GPIO_IR (and friends) definitions.
Do you want me to remove the cast and life with a compiler warning until
this has been globally fixed?
Because this is not a particular problem with this patch it should be
addressed in a separate discussion. But you are rigth - this cast is
a little bit nerving :-)
+}
+
+static int pci_is_66mhz(void)
+{
+ if (in_be32((void*)GPIO0_IR) CONFIG_SYS_GPIO_M66EN)
+ return 1;
+ return 0;
Ditto.
+}
+
+static int board_revision(void)
+{
+ return ((in_be32((void*)GPIO0_IR) CONFIG_SYS_GPIO_HWREV_MASK)
+ CONFIG_SYS_GPIO_HWREV_SHIFT);
+}
and again.
+static int cpld_revision(void)
+{
+ return ((in_8((void*)CPLD_VERSION) CPLD_VERSION_MASK));
+}
and again.
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface
-Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:34 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? Of course, what name do you prefer? I will prefer a name kirkwood_i2c.c + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order What do you mean? Arrange them in alphabetical order, insert this line between l m Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:34 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? Of course, what name do you prefer? I will prefer a name kirkwood_i2c.c Hmm.. I thought twsi_i2c.c ... + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order What do you mean? Arrange them in alphabetical order, insert this line between l m I think the alphabetical order is for the CONFIG_ defines ... so I used the right place for it ... but, if I rename this define in CONFIG_DRIVER_I2C_TWSI, it gets another place (between COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o +COBJS-$(CONFIG_DRIVER_I2C_TWSI) += twsi_i2c.o COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o) bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface
-Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:47 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:34 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? Of course, what name do you prefer? I will prefer a name kirkwood_i2c.c Hmm.. I thought twsi_i2c.c ... #include asm/arch/Kirkwood.h in your file indicate it is kirkwood low level driver If you wish twsi_i2c.c is more generic name, but in that case you need to abstract arch specific support well. + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order What do you mean? Arrange them in alphabetical order, insert this line between l m I think the alphabetical order is for the CONFIG_ defines ... so I used the right place for it ... but, if I rename this define in CONFIG_DRIVER_I2C_TWSI, it gets another place (between COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o +COBJS-$(CONFIG_DRIVER_I2C_TWSI) += twsi_i2c.o Also this could be CONFIG_I2C_KIRKWOOD or CONFIG_I2C_TWSI or CONFIG_TWSI_I2C Regards.. Prafulla . . COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o) bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] include/config_cmd_default.h cleanup
arranged configurations in alphabetical order CONFIG_CMD_FLASH moved under ifndef CONFIG_SYS_NO_FLASH Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- include/config_cmd_default.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/config_cmd_default.h b/include/config_cmd_default.h index 0376e44..a5d87a6 100644 --- a/include/config_cmd_default.h +++ b/include/config_cmd_default.h @@ -20,14 +20,13 @@ #define CONFIG_CMD_BOOTD /* bootd*/ #define CONFIG_CMD_CONSOLE /* coninfo */ #define CONFIG_CMD_ECHO/* echo arguments */ -#define CONFIG_CMD_SAVEENV /* saveenv */ -#define CONFIG_CMD_FLASH /* flinfo, erase, protect */ #define CONFIG_CMD_FPGA/* FPGA configuration Support */ #define CONFIG_CMD_IMI /* iminfo */ +#define CONFIG_CMD_ITEST /* Integer (and string) test*/ #ifndef CONFIG_SYS_NO_FLASH +#define CONFIG_CMD_FLASH /* flinfo, erase, protect */ #define CONFIG_CMD_IMLS/* List all found images*/ #endif -#define CONFIG_CMD_ITEST /* Integer (and string) test*/ #define CONFIG_CMD_LOADB /* loadb*/ #define CONFIG_CMD_LOADS /* loads*/ #define CONFIG_CMD_MEMORY /* md mm nm mw cp cmp crc base loop mtest */ @@ -35,6 +34,7 @@ #define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/ #define CONFIG_CMD_NFS /* NFS support */ #define CONFIG_CMD_RUN /* run command in env variable */ +#define CONFIG_CMD_SAVEENV /* saveenv */ #define CONFIG_CMD_SETGETDCR /* DCR support on 4xx */ #define CONFIG_CMD_SOURCE /* source command support */ #define CONFIG_CMD_XIMG/* Load part of Multi Image */ -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 2/6] Marvell Sheevaplug Board support
Reference: http://plugcomputer.org/ http://openplug.org/plugwiki/index.php/Das_U-boot_plug_support This patch is tested for- 1. Boot from DRAM/NAND flash 2. File transfer using tftp 3. NAND flash read/write/erase 4. Linux kernel and RFS Boot from NAND 5. Enabled USB PHY init for kernel need 6. Boot from USB supported Note: to boot Kirkwood kernel with USB support, you should add usb start in the boot sequence Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: updated as per feedback for v1 v3: updated as per feedback for v2 v4: removed PHY driver dependency, coded in sheevaplug.c v5: USB support added v6: config_cmd_default.h used in board config v7: sheevaplug.h alligned as per cleanup in config_cmd_default.h MAINTAINERS |4 + MAKEALL |1 + Makefile |4 +- board/Marvell/sheevaplug/Makefile | 51 + board/Marvell/sheevaplug/config.mk| 25 board/Marvell/sheevaplug/sheevaplug.c | 155 ++ board/Marvell/sheevaplug/sheevaplug.h | 41 +++ include/configs/sheevaplug.h | 195 + 8 files changed, 475 insertions(+), 1 deletions(-) create mode 100644 board/Marvell/sheevaplug/Makefile create mode 100644 board/Marvell/sheevaplug/config.mk create mode 100644 board/Marvell/sheevaplug/sheevaplug.c create mode 100644 board/Marvell/sheevaplug/sheevaplug.h create mode 100644 include/configs/sheevaplug.h diff --git a/MAINTAINERS b/MAINTAINERS index 705bac5..2f3b63c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -673,6 +673,10 @@ Hugo Villeneuve hugo.villene...@lyrtech.com SFFSDR ARM926EJS +Prafulla Wadaskar prafu...@marvell.com + + sheevaplug ARM926EJS (Kirkwood SoC) + Richard Woodruff r-woodru...@ti.com omap2420h4 ARM1136EJS diff --git a/MAKEALL b/MAKEALL index 41f1445..e987d4a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -522,6 +522,7 @@ LIST_ARM9= \ omap730p2 \ sbc2410x\ scb9328 \ + sheevaplug \ smdk2400\ smdk2410\ trab\ diff --git a/Makefile b/Makefile index d427760..a66c4c7 100644 --- a/Makefile +++ b/Makefile @@ -2924,6 +2924,9 @@ sbc2410x_config: unconfig scb9328_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx +sheevaplug_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + smdk2400_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t smdk2400 samsung s3c24x0 @@ -3168,7 +3171,6 @@ omap2420h4_config : unconfig qong_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 qong davedenx mx31 - # ## ARM1176 Systems # diff --git a/board/Marvell/sheevaplug/Makefile b/board/Marvell/sheevaplug/Makefile new file mode 100644 index 000..e378b5b --- /dev/null +++ b/board/Marvell/sheevaplug/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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 := sheevaplug.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/sheevaplug/config.mk b/board/Marvell/sheevaplug/config.mk new file mode 100644 index 000..a4ea769 ---
[U-Boot] [PATCH v13 3/6] Marvell MV88F6281GTW_GE Board support
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 5. Boot from USB supported 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 v8: u-boot.lds removed finetuned for cosmetic and switch related changes v9: new mpp configuration used CONFIG_ARCH_LOWLEVEL_INIT defination removed v10: CONFIG_ENV_SIZE set to 4kb CONFIG_SYS_MALLOC_LEN set to 128kb v11: updated as per feedback for v10 copyright statement corrected mtdparts definition corrected all code lines checked for max len 80 chars v12: config_cmd_default.h used in board config entry in MAINTAINERS list added v13: mv88f6281gtw_ge.h allgined as per cleanup in config_cmd_default.h MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/Marvell/mv88f6281gtw_ge/Makefile | 51 ++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 141 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 36 include/configs/mv88f6281gtw_ge.h | 200 +++ 8 files changed, 458 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 include/configs/mv88f6281gtw_ge.h diff --git a/MAINTAINERS b/MAINTAINERS index 2f3b63c..76268b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -675,6 +675,7 @@ Hugo Villeneuve hugo.villene...@lyrtech.com Prafulla Wadaskar prafu...@marvell.com + mv88f6281gtw_ge ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) Richard Woodruff r-woodru...@ti.com diff --git a/MAKEALL b/MAKEALL index e987d4a..4e1f431 100755 --- a/MAKEALL +++ b/MAKEALL @@ -510,6 +510,7 @@ LIST_ARM9= \ cp946es \ cp966 \ lpd7a400\ + mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ netstar \ diff --git a/Makefile b/Makefile index a66c4c7..b4d8c80 100644 --- a/Makefile +++ b/Makefile @@ -2853,6 +2853,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..92d0b47 --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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) +
[U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support
With these fixes, this driver works properly for multi chip
addressging mode
Bugfixes:
1. Build error fixed for function mv88e61xx_busychk_multic-fixed
2. PHY dev address error detection- fixed
3. wrong busy bit was refered in function mv88e61xx_busychk -fixed
4. invalid data read ptr was refered for RD_PHY in case of
multichip addressing mode -fixed
The Multichip Address mode is tested with RD6281A board having
MV88E6165 switch on it
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/net/phy/mv88e61xx.c | 18 +-
drivers/net/phy/mv88e61xx.h |2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index ec47286..29630f5 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -36,7 +36,7 @@
* By default single chip mode is configured
* multichip mode operation can be configured in board header
*/
-static int mv88e61xx_busychk_multic(u32 devaddr)
+static int mv88e61xx_busychk_multic(char *name, u32 devaddr)
{
u32 reg = 0;
u32 timeout = MV88E61XX_PHY_TIMEOUT;
@@ -58,11 +58,11 @@ static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32
reg_ofs, u16 data)
u32 mii_dev_addr;
/* command to read PHY dev address */
- if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ if (miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
printf(Error..could not read PHY dev address\n);
return;
}
- mv88e61xx_busychk_multic(mii_dev_addr);
+ mv88e61xx_busychk_multic(name, mii_dev_addr);
/* Write data to Switch indirect data register */
miiphy_write(name, mii_dev_addr, 0x1, data);
/* Write command to Switch indirect command register (write) */
@@ -77,18 +77,18 @@ static void mv88e61xx_rd_phy(char *name, u32 phy_adr, u32
reg_ofs, u16 * data)
u32 mii_dev_addr;
/* command to read PHY dev address */
- if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ if (miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
printf(Error..could not read PHY dev address\n);
return;
}
- mv88e61xx_busychk_multic(mii_dev_addr);
+ mv88e61xx_busychk_multic(name, mii_dev_addr);
/* Write command to Switch indirect command register (read) */
miiphy_write(name, mii_dev_addr, 0x0,
-reg_ofs | (phy_adr 5) | (1 10) | (1 12) | (1
+reg_ofs | (phy_adr 5) | (1 11) | (1 12) | (1
15));
- mv88e61xx_busychk_multic(mii_dev_addr);
+ mv88e61xx_busychk_multic(name, mii_dev_addr);
/* Read data from Switch indirect data register */
- miiphy_read(name, mii_dev_addr, 0x1, (u16 *) data);
+ miiphy_read(name, mii_dev_addr, 0x1, data);
}
#endif /* CONFIG_MV88E61XX_MULTICHIP_ADRMODE */
@@ -212,7 +212,7 @@ static int mv88e61xx_busychk(char *name)
printf(SMI busy timeout\n);
return -1;
}
- } while (reg 1 28);/* busy mask */
+ } while (reg 1 15);/* busy mask */
return 0;
}
diff --git a/drivers/net/phy/mv88e61xx.h b/drivers/net/phy/mv88e61xx.h
index 4279464..57762b6 100644
--- a/drivers/net/phy/mv88e61xx.h
+++ b/drivers/net/phy/mv88e61xx.h
@@ -49,7 +49,7 @@
#define MV88E61XX_ADDR_OFST5
#ifdef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
-static int mv88e61xx_busychk_multic(u32 devaddr);
+static int mv88e61xx_busychk_multic(char *name, u32 devaddr);
static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 data);
static void mv88e61xx_rd_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 * data);
#define WR_PHY mv88e61xx_wr_phy
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support
By default Auto Negotiation is enabled for interface speed but on some platforms like RD6281A it does not work. If you want to forced program it to desired speed, this patch helps- Through this patch Auto negotiation can be disabled and desired interface speed can be configured This patch is tested on RD6281A Kirkwood board Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- drivers/net/kirkwood_egiga.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c index 3c5db19..1dfd567 100644 --- a/drivers/net/kirkwood_egiga.c +++ b/drivers/net/kirkwood_egiga.c @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev) /* Assign port configuration and command. */ KWGBEREG_WR(regs-pxc, PRT_CFG_VAL); KWGBEREG_WR(regs-pxcx, PORT_CFG_EXTEND_VALUE); + /* +* Forced 10/100/1000BASE-T interface speed configuration +* By default Auto Negotiation of interface speed is enabled +* This can be forced disabled and desired speed can be configured +*/ +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII +#if (!defined (CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET)) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_1000); +#elif (CONFIG_PHY_SPEED == _100BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_100); +#elif (CONFIG_PHY_SPEED == _10BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_10); +#endif /* CONFIG_PHY_SPEED == _10BASET */ +#else KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE); +#endif /* CONFIG_DIS_AUTO_NEG_SPEED_GMII */ + /* Disable port initially */ KWGBEREG_BITS_SET(regs-psc0, KWGBE_SERIAL_PORT_EN); -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] Marvell RD6281A Board support
This is Marvell's 88F6281_A0 based reference design board This patch is tested for- 1. Boot from DRAM/NAND flash/NFS 2. File transfer using tftp and loadb 3. NAND flash read/write/erase Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/Marvell/rd6281a/Makefile | 51 ++ board/Marvell/rd6281a/config.mk | 25 + board/Marvell/rd6281a/rd6281a.c | 179 + board/Marvell/rd6281a/rd6281a.h | 41 include/configs/rd6281a.h | 209 +++ 8 files changed, 510 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/rd6281a/Makefile create mode 100644 board/Marvell/rd6281a/config.mk create mode 100644 board/Marvell/rd6281a/rd6281a.c create mode 100644 board/Marvell/rd6281a/rd6281a.h create mode 100644 include/configs/rd6281a.h diff --git a/MAINTAINERS b/MAINTAINERS index 76268b4..ff587e1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -676,6 +676,7 @@ Hugo Villeneuve hugo.villene...@lyrtech.com Prafulla Wadaskar prafu...@marvell.com mv88f6281gtw_ge ARM926EJS (Kirkwood SoC) + rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) Richard Woodruff r-woodru...@ti.com diff --git a/MAKEALL b/MAKEALL index 4e1f431..3d7e4da 100755 --- a/MAKEALL +++ b/MAKEALL @@ -521,6 +521,7 @@ LIST_ARM9= \ omap1610inn \ omap5912osk \ omap730p2 \ + rd6281a \ sbc2410x\ scb9328 \ sheevaplug \ diff --git a/Makefile b/Makefile index b4d8c80..3a011c8 100644 --- a/Makefile +++ b/Makefile @@ -2921,6 +2921,9 @@ omap730p2_cs3boot_config :unconfig fi; @$(MKCONFIG) -a $(call xtract_omap730p2,$@) arm arm926ejs omap730p2 NULL omap +rd6281a_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 diff --git a/board/Marvell/rd6281a/Makefile b/board/Marvell/rd6281a/Makefile new file mode 100644 index 000..907dd7d --- /dev/null +++ b/board/Marvell/rd6281a/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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 := rd6281a.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/rd6281a/config.mk b/board/Marvell/rd6281a/config.mk new file mode 100644 index 000..a4ea769 --- /dev/null +++ b/board/Marvell/rd6281a/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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
[U-Boot] [PATCH 6/6][repost] Marvell RD6281A Board support
This is Marvell's 88F6281_A0 based reference design board This patch is tested for- 1. Boot from DRAM/NAND flash/NFS 2. File transfer using tftp and loadb 3. NAND flash read/write/erase Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: Sorry.. One commit was missing... MAINTAINERS |1 + MAKEALL |1 + Makefile|3 + board/Marvell/rd6281a/Makefile | 51 ++ board/Marvell/rd6281a/config.mk | 25 + board/Marvell/rd6281a/rd6281a.c | 179 +++ board/Marvell/rd6281a/rd6281a.h | 41 include/configs/rd6281a.h | 198 +++ 8 files changed, 499 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/rd6281a/Makefile create mode 100644 board/Marvell/rd6281a/config.mk create mode 100644 board/Marvell/rd6281a/rd6281a.c create mode 100644 board/Marvell/rd6281a/rd6281a.h create mode 100644 include/configs/rd6281a.h diff --git a/MAINTAINERS b/MAINTAINERS index 76268b4..ff587e1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -676,6 +676,7 @@ Hugo Villeneuve hugo.villene...@lyrtech.com Prafulla Wadaskar prafu...@marvell.com mv88f6281gtw_ge ARM926EJS (Kirkwood SoC) + rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) Richard Woodruff r-woodru...@ti.com diff --git a/MAKEALL b/MAKEALL index 4e1f431..3d7e4da 100755 --- a/MAKEALL +++ b/MAKEALL @@ -521,6 +521,7 @@ LIST_ARM9= \ omap1610inn \ omap5912osk \ omap730p2 \ + rd6281a \ sbc2410x\ scb9328 \ sheevaplug \ diff --git a/Makefile b/Makefile index b4d8c80..3a011c8 100644 --- a/Makefile +++ b/Makefile @@ -2921,6 +2921,9 @@ omap730p2_cs3boot_config :unconfig fi; @$(MKCONFIG) -a $(call xtract_omap730p2,$@) arm arm926ejs omap730p2 NULL omap +rd6281a_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 diff --git a/board/Marvell/rd6281a/Makefile b/board/Marvell/rd6281a/Makefile new file mode 100644 index 000..907dd7d --- /dev/null +++ b/board/Marvell/rd6281a/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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 := rd6281a.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/rd6281a/config.mk b/board/Marvell/rd6281a/config.mk new file mode 100644 index 000..a4ea769 --- /dev/null +++ b/board/Marvell/rd6281a/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: 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 +#
Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:47 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 3:34 PM To: Prafulla Wadaskar Cc: Jean-Christophe PLAGNIOL-VILLARD; U-Boot user list Subject: Re: arm, i2c: added support for the TWSI I2C Interface Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 16, 2009 1:31 PM To: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar Cc: U-Boot user list Subject: arm, i2c: added support for the TWSI I2C Interface added support for the Hardware I2C TWSI Interface on kirkwood SOCs, based on the Linux driver, without IRQ support. Tested on a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family: KIRKWOOD, KW88F6281) based suen3 board Signed-off-by: Heiko Schocher h...@denx.de --- drivers/i2c/Makefile |1 + drivers/i2c/mv64xxx-i2c.c | 452 Can you rename this? Of course, what name do you prefer? I will prefer a name kirkwood_i2c.c Hmm.. I thought twsi_i2c.c ... #include asm/arch/Kirkwood.h in your file indicate it is kirkwood low level driver If you wish twsi_i2c.c is more generic name, but in that case you need to abstract arch specific support well. I have no idea, how generic this driver is, so I vote for naming it in the first step as kirkwood_i2c.c as you suggested. (Because I could not test it on another plattform) If someone use it on another plattforms, we can do this step later. + 2 files changed, 453 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mv64xxx-i2c.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index ef32f13..ce30111 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -33,6 +33,7 @@ COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o +COBJS-$(CONFIG_I2C_MV64xxx) += mv64xxx-i2c.o Put this in order What do you mean? Arrange them in alphabetical order, insert this line between l m I think the alphabetical order is for the CONFIG_ defines ... so I used the right place for it ... but, if I rename this define in CONFIG_DRIVER_I2C_TWSI, it gets another place (between COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o +COBJS-$(CONFIG_DRIVER_I2C_TWSI) += twsi_i2c.o Also this could be CONFIG_I2C_KIRKWOOD or CONFIG_I2C_TWSI or CONFIG_TWSI_I2C Yep KIRKWOOD is what I prefer actual. thanks bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Scott Wood, In message 20090715221820.ga16...@b07421-ec1.am.freescale.net you wrote: On Mon, Jul 13, 2009 at 05:25:35AM -0400, Mike Frysinger wrote: ... basically, that is correct. arm's libgcc is just that whacky because of all the different ABIs that exist. although citing the Linux kernel here may not be appropriate because they specifically avoid libgcc -- because it's so screwed up. I'm continually amazed to see again and again many otherwise clever software developers investing efforts to solve the same problems again and again locally in separate projects, instead of fixing them once at the central point where the problem actually lies. So instead of fixing the screwed up libgcc code for ARM such thatit can be used for applications _and_ Linux kernel _and_ U-Boot and other projects, we re-invent and copy and improve the code locally in each project (and I cannot tell what would surprise me more - to hear that the libgcc maintainers are not involved, or that they are). Instead of adding a new feature to make once, Linux and several other projects add complicated Makefile rules to produce hort output like CC fs/inode.o CALLarch/powerpc/kernel/prom_init_check.sh AS arch/powerpc/kernel/head_32.o LDS arch/powerpc/kernel/vmlinux.lds I always though softwre engineering was about _not_ re-inventing the wheel again and again and again... :-( Isn't that what multilib is for? hm... wrong forum to ask, I guess... On a related note, I wish GCC had a no-float option that could be used in place of soft-float. It would be ABI-compatible with either soft or hard float, because it doesn't use float at all (GCC would raise an error if you try). You should ask this on a GCC related list, or submit a proposal to the GCC stearing committee. It seems pretty reasonable for U-Boot to provide functions like raise()/abort() that take the place of a hardware exception, and display an error message. This does not sound reasonable to me. 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 In any group of employed individuals the only naturally early riser is _always_ the office manager, who will _always_ leave reproachful little notes ... on the desks of their subordinates. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] Added support for splash screen positioning
Matthias Weisser wrote: This patch adds support splash image positioning by adding an additional variable splashpos to the environment. Please see README for details. Signed-off-by: Matthias Weisser matthias.weis...@graf-syteco.de --- README | 19 +++ common/lcd.c| 39 +-- drivers/video/cfb_console.c | 36 +++- 3 files changed, 91 insertions(+), 3 deletions(-) Applied to u-boot-video. Thanks! Note that I slightly modified the description in README, hope this is okay. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202ddf26...@sc-vexch1.marvell.com you wrote: The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.). During restructuring activity for this utility, I found that most of the code and algorithm is common between mkimage and kwimage (old name doimage). I'm not really surprised. I have studied mkimage code. kwimage requirements can be well supported by adding one more type support to the mkimage (i.e. bootrom). bootrom is a way to generic name. You have a specific data format in mind, so please use a more specific name. The bootrom image file generation generic abstraction can be provided with new file ./common/bootrom.c internally supported by Arch specific macros/code. Hm... I guess this would make it even more complicated to separate the mkimage tool from the rest of the U-Boot code. There have been repeated requests to make it more independent or even integrate in into the Linux kernel code tree. We should keep this in mind. Note that this is not an argument against your proposal - just a note that we should keep this aspect in mind when implementing and reviewing the new code. With this- 1. mkimage can be reused for kwimage generation. Sounds good to me. 2. Kwimage generation can be supported in a generic way under bootrom image type This doesn't sound such a good idea to me. As mentioned above, bootrom is a very generic name which can be anything - but if you assign this name to a specific format, it should be exactly _one_ speific format. 3. In future the same interface can be used by other Marvell and non Marvell socs for similar kind of requirements. Shall I go ahead with this approach? or I should not disturb mkimage at all? What is your opinion? I think this is a pretty good plan. Please go ahead. 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 After a heated argument on some trivial matter Nancy [Astor] . . . shouted, ``If I were your wife I would put poison in your coffee!'' Whereupon Winston Churchill with equal heat and sincerity answered, ``And if I were your husband I would drink it.'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
Le Wed, 15 Jul 2009 09:51:27 -0500, Peter Tyser pty...@xes-inc.com a écrit : You can get rid of the line above. It is nearly identical to the patch subject and doesn't add any useful info. Ok. MAKEALL |1 Makefile |3 You should add an entry to MAINTAINERS Done. +/* LED */ +#define CONFIG_AT91_LED +#defineCONFIG_RED_LED AT91_PIN_PB7/* this is the power led */ +#define CONFIG_GREEN_LEDAT91_PIN_PB8/* this is the user1 led */ +#define CONFIG_YELLOW_LED AT91_PIN_PC29 /* this is the user2 led */ Funky indentation. Fixed. +#define ROUND(A, B)(((A) + (B)) ~((B) - 1)) I'd try and use the round functions already in include/common.h if possible. Maybe its not possible if this file is included prior to common.h though, I'm not sure. Not sure about this one. All at91 boards do it this way, so if a fix needs to be done, I'd suggest to make it separatly. Is this ok ? Below is an updated version of the patch. Not sure it's the right way to resend it, though. Thanks for the review! Thomas The Calao USB A9263 board is a board manufactured and sold by Calao Systems http://www.calao-systems.com. Its components are very similar to the AT91SAM9263EK board, so its configuration is based on the configuration of this board. There are however some differences: different clocks, no LCD, etc. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com MAINTAINERS |4 MAKEALL |1 Makefile |3 board/calao/usb-a9263/Makefile| 56 board/calao/usb-a9263/config.mk |1 board/calao/usb-a9263/led.c | 44 ++ board/calao/usb-a9263/partition.c | 37 + board/calao/usb-a9263/usb-a9263.c | 193 include/configs/usb-a9263.h | 186 ++ 9 files changed, 525 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..5c37647 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -624,6 +624,10 @@ Peter Pearse peter.pea...@arm.com versatile ARM926EJ-S versatile ARM926EJ-S +Thomas Petazzoni thomas.petazz...@free-electrons.com + + usb-a9263 ARM926EJS (AT91SAM9263 SoC) + Dave Peverley dpever...@mpc-data.co.uk omap730p2 ARM926EJS diff --git a/MAKEALL b/MAKEALL index 020ff73..452d09a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -599,6 +599,7 @@ LIST_at91= \ m501sk \ pm9261 \ pm9263 \ + usb9263 \ # diff --git a/Makefile b/Makefile index 090e645..244b8b1 100644 --- a/Makefile +++ b/Makefile @@ -2847,6 +2847,9 @@ at91sam9g45ekes_config: unconfig pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +usb_a9263_config : unconfig + $(MKCONFIG) -a usb-a9263 arm arm926ejs usb-a9263 calao at91 + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ diff --git a/board/calao/usb-a9263/Makefile b/board/calao/usb-a9263/Makefile new file mode 100644 index 000..18325e0 --- /dev/null +++ b/board/calao/usb-a9263/Makefile @@ -0,0 +1,56 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y += usb-a9263.o +COBJS-y += led.o +COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +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 $(obj).depend +
[U-Boot] [PATCH V3] ppc4xx: Add 405EP based PMC405DE board
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/esd/pmc405de/Makefile | 51 board/esd/pmc405de/config.mk | 23 ++ board/esd/pmc405de/pmc405de.c | 575 + board/esd/pmc405de/u-boot.lds | 133 ++ include/configs/PMC405DE.h| 373 ++ 8 files changed, 1160 insertions(+), 0 deletions(-) create mode 100644 board/esd/pmc405de/Makefile create mode 100644 board/esd/pmc405de/config.mk create mode 100644 board/esd/pmc405de/pmc405de.c create mode 100644 board/esd/pmc405de/u-boot.lds create mode 100644 include/configs/PMC405DE.h diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..484040c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -171,6 +171,7 @@ Matthias Fuchs matthias.fu...@esd-electronics.com PCI405 PPC405GP PLU405 PPC405EP PMC405 PPC405GP + PMC405DEPPC405EP PMC440 PPC440EPx VOH405 PPC405EP VOM405 PPC405EP diff --git a/MAKEALL b/MAKEALL index 020ff73..f36a5fd 100755 --- a/MAKEALL +++ b/MAKEALL @@ -237,6 +237,7 @@ LIST_4xx= \ PIP405 \ PLU405 \ PMC405 \ + PMC405DE\ PMC440 \ PPChameleonEVB \ quad100hd \ diff --git a/Makefile b/Makefile index 090e645..a5d397b 100644 --- a/Makefile +++ b/Makefile @@ -1492,6 +1492,9 @@ PLU405_config:unconfig PMC405_config: unconfig @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405 esd +PMC405DE_config: unconfig + @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405de esd + PMC440_config: unconfig @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc440 esd diff --git a/board/esd/pmc405de/Makefile b/board/esd/pmc405de/Makefile new file mode 100644 index 000..cec88f1 --- /dev/null +++ b/board/esd/pmc405de/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS = $(BOARD).o +COBJS += ../common/cmd_loadpci.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/esd/pmc405de/config.mk b/board/esd/pmc405de/config.mk new file mode 100644 index 000..ae855dc --- /dev/null +++ b/board/esd/pmc405de/config.mk @@ -0,0 +1,23 @@ +# +# (C) Copyright 2000 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# +TEXT_BASE = 0xFFFC diff --git a/board/esd/pmc405de/pmc405de.c b/board/esd/pmc405de/pmc405de.c new file mode 100644 index 000..9c1a119 --- /dev/null +++ b/board/esd/pmc405de/pmc405de.c @@ -0,0 +1,575 @@ +/* + * (C) Copyright 2009 + * Matthias Fuchs, esd gmbh germany, matthias.fu...@esd.eu + * + * See file CREDITS
Re: [U-Boot] bug when using environment in an i2c eeprom and SPI is enabled?
Dear Heiko Schocher, In message 4a5ed846.90...@denx.de you wrote: I actually try to use Environment on an I2C EEprom with SPI enabled, and found in include/common.h the following defines @line 326ff: I'm not surprised... So, it seems to me, that, if SPI is enabled, it is not possible to use an I2C EEprom with an address != 0, because in common/env_eeprom.c @line79 in env_init(): Actually you are most probably not supposed to use any I2C EEPROM at all. I tried to use git blame to find out where this comes from, but this is in code since the initial revision ... so I ask here on the mailinglist, if somebody knows, if this is a feature or a bug? I think this is a deficiency of the original implementation which assumed that if there was an EEPROM, it was either attached to the I2C or to the SPI bus, and that SPI would never be used in U-Boot for anything else than reading an EEPROM. Please consider it a bug... 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 An armed society is a polite society. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_API, EABI and raise()
Dear Stefan Roese, In message 200907161046.32385...@denx.de you wrote: Just to make it clear: The libgcc removal patches for ARM from Jean-Christophe are not added yet. ... Just to make it clear: The libgcc removal patches for ARM will never be added - at least not in their current form. ... So if you see a problem with EABI etc, some other patches have to be the reason for this. And very likely Jean-Christophe's patches could fix the problems. Instead af waiting for some potetnial fix that mauy or may not accepted at an unknown (but later) time, we should focus on identifying the patches that caused the problem, and resolve the problem there. It makes no sense to introduce breakage not fix it but blame libgcc for it and wait for a completely unrelated, bigger change to happen. 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 Few people do business well who do nothing else. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
Dear Eric Benard,
In message 1247735589-15527-1-git-send-email-e...@eukrea.com you wrote:
CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.
...
+int dram_init(void)
+{
+ gd-bd-bi_dram[0].start = PHYS_SDRAM;
+ gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
+ return 0;
+}
How about using get_ram_size() for auto-sizing and testing?
diff --git a/cpu/arm926ejs/at91/lowlevel_init.S
b/cpu/arm926ejs/at91/lowlevel_init.S
index 5ed518c..538d3e6 100644
--- a/cpu/arm926ejs/at91/lowlevel_init.S
+++ b/cpu/arm926ejs/at91/lowlevel_init.S
@@ -194,7 +194,7 @@ SMRDATA:
.word CONFIG_SYS_PIOD_PPUDR_VAL
.word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
.word CONFIG_SYS_PIOD_PPUDR_VAL
-#elif defined(CONFIG_AT91SAM9261)
+#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9260)
Please swap to keep sorted:
#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
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
Common sense and a sense of humor are the same thing, moving at
different speeds. A sense of humor is just common sense, dancing.
- Clive James
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
Dear Piotr =?iso-8859-2?q?Zi=EAcik?=, In message 200907161151.59353.ko...@semihalf.com you wrote: This patch fixes above problem by allowing partial packet read. seems like it could easily introduce incorrect behavior in existing applications. the code also sounds a bit risky ... your change would mean people could read the leading part, but the rest is lost ? discaded, if buffer is too small. This behaviour is similar to Linux recv() But recv() is on another level. Here we are dealing with receiving raw ethernet frames. function. I do not see why we have to force application to prepare 1,5kB buffer for received packets when for example it waits for ARP reply. Come on - what exactly is the extra effort you have to spend to prepare a bigger buffer? 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 Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
Dear Wolfgang Denk,
Wolfgang Denk a écrit :
In message 1247735589-15527-1-git-send-email-e...@eukrea.com you wrote:
CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.
...
+int dram_init(void)
+{
+gd-bd-bi_dram[0].start = PHYS_SDRAM;
+gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
+return 0;
+}
How about using get_ram_size() for auto-sizing and testing?
the RAM needs to be properly initialized in low level before being able
to test it so its geometry (rom/columns) and timings must be known
before being able to detect its size using get_ram_size.
I'm not sure it's possible to use a generic geometry/timings there else
u-boot may never relocate.
How would you do this ?
diff --git a/cpu/arm926ejs/at91/lowlevel_init.S
b/cpu/arm926ejs/at91/lowlevel_init.S
index 5ed518c..538d3e6 100644
--- a/cpu/arm926ejs/at91/lowlevel_init.S
+++ b/cpu/arm926ejs/at91/lowlevel_init.S
@@ -194,7 +194,7 @@ SMRDATA:
.word CONFIG_SYS_PIOD_PPUDR_VAL
.word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
.word CONFIG_SYS_PIOD_PPUDR_VAL
-#elif defined(CONFIG_AT91SAM9261)
+#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9260)
Please swap to keep sorted:
#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
OK will do.
Thanks
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory
Signed-off-by: Stefan Roese s...@denx.de
Cc: Scott Wood scottw...@freescale.com
---
cpu/ppc4xx/Makefile |1 -
drivers/mtd/nand/Makefile|1 +
{cpu/ppc4xx = drivers/mtd/nand}/ndfc.c |0
nand_spl/board/amcc/acadia/Makefile |2 +-
nand_spl/board/amcc/bamboo/Makefile |2 +-
nand_spl/board/amcc/canyonlands/Makefile |2 +-
nand_spl/board/amcc/kilauea/Makefile |2 +-
nand_spl/board/amcc/sequoia/Makefile |2 +-
8 files changed, 6 insertions(+), 6 deletions(-)
rename {cpu/ppc4xx = drivers/mtd/nand}/ndfc.c (100%)
diff --git a/cpu/ppc4xx/Makefile b/cpu/ppc4xx/Makefile
index 96ab5c6..6f52dfd 100644
--- a/cpu/ppc4xx/Makefile
+++ b/cpu/ppc4xx/Makefile
@@ -51,7 +51,6 @@ COBJS += fdt.o
COBJS += i2c.o
COBJS += interrupts.o
COBJS += iop480_uart.o
-COBJS += ndfc.o
COBJS += sdram.o
COBJS += speed.o
COBJS += tlb.o
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index a5680e8..945a954 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
COBJS-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
+COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
diff --git a/cpu/ppc4xx/ndfc.c b/drivers/mtd/nand/ndfc.c
similarity index 100%
rename from cpu/ppc4xx/ndfc.c
rename to drivers/mtd/nand/ndfc.c
diff --git a/nand_spl/board/amcc/acadia/Makefile
b/nand_spl/board/amcc/acadia/Makefile
index 931f04b..822f82f 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -73,7 +73,7 @@ $(obj)gpio.c:
$(obj)ndfc.c:
@rm -f $(obj)ndfc.c
- ln -s $(SRCTREE)/cpu/ppc4xx/ndfc.c $(obj)ndfc.c
+ ln -s $(SRCTREE)/drivers/mtd/nand/ndfc.c $(obj)ndfc.c
$(obj)resetvec.S:
@rm -f $(obj)resetvec.S
diff --git a/nand_spl/board/amcc/bamboo/Makefile
b/nand_spl/board/amcc/bamboo/Makefile
index e1c1467..2932927 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -59,7 +59,7 @@ $(nandobj)u-boot-spl: $(OBJS)
# from cpu directory
$(obj)ndfc.c:
@rm -f $(obj)ndfc.c
- ln -s $(SRCTREE)/cpu/ppc4xx/ndfc.c $(obj)ndfc.c
+ ln -s $(SRCTREE)/drivers/mtd/nand/ndfc.c $(obj)ndfc.c
$(obj)resetvec.S:
@rm -f $(obj)resetvec.S
diff --git a/nand_spl/board/amcc/canyonlands/Makefile
b/nand_spl/board/amcc/canyonlands/Makefile
index fb86752..84b1454 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -64,7 +64,7 @@ $(nandobj)u-boot-spl: $(OBJS)
# from cpu directory
$(obj)ndfc.c:
@rm -f $(obj)ndfc.c
- ln -s $(SRCTREE)/cpu/ppc4xx/ndfc.c $(obj)ndfc.c
+ ln -s $(SRCTREE)/drivers/mtd/nand/ndfc.c $(obj)ndfc.c
$(obj)resetvec.S:
@rm -f $(obj)resetvec.S
diff --git a/nand_spl/board/amcc/kilauea/Makefile
b/nand_spl/board/amcc/kilauea/Makefile
index cedc8e0..8a062fe 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -71,7 +71,7 @@ $(obj)ecc.h:
$(obj)ndfc.c:
@rm -f $(obj)ndfc.c
- ln -s $(SRCTREE)/cpu/ppc4xx/ndfc.c $(obj)ndfc.c
+ ln -s $(SRCTREE)/drivers/mtd/nand/ndfc.c $(obj)ndfc.c
$(obj)resetvec.S:
@rm -f $(obj)resetvec.S
diff --git a/nand_spl/board/amcc/sequoia/Makefile
b/nand_spl/board/amcc/sequoia/Makefile
index fba0322..462005f 100644
--- a/nand_spl/board/amcc/sequoia/Makefile
+++ b/nand_spl/board/amcc/sequoia/Makefile
@@ -63,7 +63,7 @@ $(obj)denali_data_eye.c:
$(obj)ndfc.c:
@rm -f $(obj)ndfc.c
- ln -s $(SRCTREE)/cpu/ppc4xx/ndfc.c $(obj)ndfc.c
+ ln -s $(SRCTREE)/drivers/mtd/nand/ndfc.c $(obj)ndfc.c
$(obj)resetvec.S:
@rm -f $(obj)resetvec.S
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] nand: ndfc: Remove unnecessary #ifdef's
Now that the 4xx NAND driver ndfc is moved to the common NAND driver directory we don't need this #ifdef's anymore. Signed-off-by: Stefan Roese s...@denx.de Cc: Scott Wood scottw...@freescale.com --- drivers/mtd/nand/ndfc.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 971e2ae..528b22b 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -30,10 +30,6 @@ */ #include common.h - -#if defined(CONFIG_CMD_NAND) !defined(CONFIG_NAND_LEGACY) \ -defined(CONFIG_NAND_NDFC) - #include nand.h #include linux/mtd/ndfc.h #include linux/mtd/nand_ecc.h @@ -219,5 +215,3 @@ int board_nand_init(struct nand_chip *nand) return 0; } - -#endif -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
Hi Dirk, On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote: On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote: This adds a generic command for programming I2C bootstrap eeproms. Implementation for Canyonlands board is included. bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? Any other good ideas about this naming welcome. :) Other than this, patch looks good. 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
[U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC
CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII mode. Signed-off-by: Eric Benard e...@eukrea.com --- MAINTAINERS |6 +- MAKEALL |3 +- Makefile| 16 +++ board/eukrea/cpuat91/Makefile | 50 board/eukrea/cpuat91/config.mk |1 + board/eukrea/cpuat91/cpuat91.c | 85 ++ cpu/arm920t/at91rm9200/Makefile |5 +- cpu/arm920t/at91rm9200/ks8721.c | 244 +++ include/configs/cpuat91.h | 231 include/ks8721.h| 78 + 10 files changed, 715 insertions(+), 4 deletions(-) create mode 100644 board/eukrea/cpuat91/Makefile create mode 100644 board/eukrea/cpuat91/config.mk create mode 100644 board/eukrea/cpuat91/cpuat91.c create mode 100644 cpu/arm920t/at91rm9200/ks8721.c create mode 100644 include/configs/cpuat91.h create mode 100644 include/ks8721.h diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..da64571 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,4 +1,4 @@ -# +9# # # # Regular Maintainers for U-Boot board support: # # # @@ -515,6 +515,10 @@ Dirk Behme dirk.be...@gmail.com omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) +Eric Benard e...@eukrea.com + + cpcuat91ARM920T + Rishi Bhattacharya ri...@ti.com omap5912osk ARM926EJS diff --git a/MAKEALL b/MAKEALL index 020ff73..0e0b657 100755 --- a/MAKEALL +++ b/MAKEALL @@ -587,11 +587,12 @@ LIST_at91= \ at91sam9260ek \ at91sam9261ek \ at91sam9263ek \ - at91sam9g10ek \ + at91sam9g10ek \ at91sam9g20ek \ at91sam9m10g45ek\ at91sam9rlek\ cmc_pu2 \ + cpuat91 \ csb637 \ kb9202 \ meesc \ diff --git a/Makefile b/Makefile index 090e645..02efe1b 100644 --- a/Makefile +++ b/Makefile @@ -2683,6 +2683,22 @@ at91rm9200ek_config : unconfig cmc_pu2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200 +xtract_cpuat91 = $(subst _ram,, $(subst _config,,$1)) + +cpuat91_ram_config \ +cpuat91_config : unconfig + @if [ $(findstring _ram_,$@) ] ; then \ + echo #define CONFIG_CPUAT91_RAM 1 ./include/config.h ; \ + fi; + @$(MKCONFIG) -a $(call xtract_cpuat91,$@) arm arm920t cpuat91 eukrea at91rm9200 + @if [ $(findstring _ram_,$@) ] ; then \ + echo #define CONFIG_CPUAT91_RAM 1 ./include/config.h ; \ + echo ... CPUAT91 configured for RAM ! ; \ + else \ + echo #define CONFIG_BOOTDELAY 1 ./include/config.h ;\ + echo ... CPUAT91 configure for Flash ! ;\ + fi; + csb637_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t csb637 NULL at91rm9200 diff --git a/board/eukrea/cpuat91/Makefile b/board/eukrea/cpuat91/Makefile new file mode 100644 index 000..08a90dc --- /dev/null +++ b/board/eukrea/cpuat91/Makefile @@ -0,0 +1,50 @@ +# +# (C) Copyright 2003-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := cpuat91.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 + +# + +#
Re: [U-Boot] [PATCH] mtd: cfi - if defined, use MAX_FLASH_BANKS_DETECT for static declarations
On Tuesday 14 July 2009 23:00:24 Kim Phillips wrote: a.k.a cfi_mtd.c does as cfi_flash.c does. This also prevents the TQM834x build from doing a: cfi_mtd.c:36: error: variably modified 'cfi_mtd_info' at file scope cfi_mtd.c:37: error: variably modified 'cfi_mtd_names' at file scope using gcc 4.4. Signed-off-by: Kim Phillips kim.phill...@freescale.com Applied to cfi-flash. 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
[U-Boot] Please pull u-boot-cfi-flash
The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1: Wolfgang Denk (1): mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master Kim Phillips (1): mtd: cfi - if defined, use MAX_FLASH_BANKS_DETECT for static declarations drivers/mtd/cfi_mtd.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
Thursday 16 July 2009 14:39:59 Wolfgang Denk napisał(a): But recv() is on another level. Here we are dealing with receiving raw ethernet frames. I think that there is an analogy. Both function could be used for receiving _frames_. eth_receive() for ethernet frames and Linux recv() for UDP frames. function. I do not see why we have to force application to prepare 1,5kB buffer for received packets when for example it waits for ARP reply. Come on - what exactly is the extra effort you have to spend to prepare a bigger buffer? Maybe I have used bad example. When application prepares a buffer and chooses it's size to be less than interface MTU it means that application is not able to process larger packets. U-Boot should not expect that simple application using API is able to handle every possible case (for example 9k packets on gigabyte ethernet). -- Pozdrawiam. Piotr Zięcik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 15:21, Stefan Roese wrote: Hi Dirk, On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote: On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote: This adds a generic command for programming I2C bootstrap eeproms. Implementation for Canyonlands board is included. bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? To long for my taste. Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. But it works a little mit different that the bootstrap command. Other than this, patch looks good. Thanks. Matthias Best regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
Please see my comments below.
On Wednesday 15 July 2009 15:48, Dirk Eibach wrote:
...
diff --git a/common/cmd_bootstrap.c b/common/cmd_bootstrap.c
new file mode 100644
index 000..6fceb23
--- /dev/null
+++ b/common/cmd_bootstrap.c
@@ -0,0 +1,75 @@
+/*
+ * (C) Copyright 2009
+ * Dirk Eibach, Guntermann Drunck GmbH, eib...@gdsys.de
+ *
+ * based on code (C) Copyright 2008
+ * Stefan Roese, DENX Software Engineering, s...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include bootstrap.h
+#include common.h
+#include command.h
+#include i2c.h
+#include asm/io.h
+
+static int do_bootstrap(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ int x, nbytes, selcfg;
+ extern char console_buffer[];
+
+ printf(Available configurations: \n\n);
+
+ for (x = 0; bootstrap_config_labels[x][0] != 0; x++)
+ printf( %d - %s\n, (x+1), bootstrap_config_labels[x]);
+
+ do {
+ nbytes = readline( Selection [1-x / quit]: );
+
+ if (nbytes) {
+ if (strcmp(console_buffer, quit) == 0)
+ return 0;
+ selcfg = simple_strtol(console_buffer, NULL, 10);
+ if ((selcfg 1) || (selcfg x))
+ nbytes = 0;
+ }
+ } while (nbytes == 0);
Do we really need to have this interactive? At least it would be fine
to use bootstrap 4 to get the fourth configuration.
So when an additional parameter ist passed to bootstrap you could bypass
alle the printf stuff and directly update the EEPROM.
+
+
+ x = (selcfg - 1);
+
+ if (i2c_write(CONFIG_BOOTSTRAP_I2C_EEPROM_ADDR, 0, 1,
+ bootstrap_configs[x], CONFIG_BOOTSTRAP_BLOCKSIZE) != 0)
+ printf(Error writing to EEPROM at address 0x%x\n,
+ CONFIG_BOOTSTRAP_I2C_EEPROM_ADDR);
+ udelay(CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS * 1000);
+
+ printf(Done\n);
Can't we life without this 'Done' message?
+ printf(Please power-cycle the board for the changes to take effect\n);
At least for 440EPx and 405EP calling 'reset' is enough and much easier for
scripting :-)
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 15:47:17 Matthias Fuchs wrote: bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? To long for my taste. Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. If you already forgot what it's supposed to mean, then it definitely is not a good name. Better a bit longer and more descriptive. But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. Does you command support more features? What's the main difference? 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] [PATCH] Add bootstrap command
Hi, Stefan Roese wrote: On Thursday 16 July 2009 15:47:17 Matthias Fuchs wrote: bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? To long for my taste. Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. If you already forgot what it's supposed to mean, then it definitely is not a good name. Better a bit longer and more descriptive. But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. Does you command support more features? What's the main difference? BTW, there's also pllalter command for kilauea, that provides similar functionality. Felix. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
Dear =?ISO-8859-1?Q?Eric_B=E9nard?=, In message 4a5f20db.2000...@eukrea.com you wrote: How about using get_ram_size() for auto-sizing and testing? the RAM needs to be properly initialized in low level before being able to test it so its geometry (rom/columns) and timings must be known before being able to detect its size using get_ram_size. Indeed. That's the same on all board - including the many that successfully use get_ram_size() I'm not sure it's possible to use a generic geometry/timings there else u-boot may never relocate. How would you do this ? Well, normally you have 2 or 3 row/col combinations that have to be considered; you try these in turn until you find one where get_ram_size() returns a non-zero size; if several work, you use that which returns the biggest size. See for example board/tqc/tqm8xx/tqm8xx.c - it tries 8, 9 and 10 column mode... 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 Lady Nancy Astor: Winston, if you were my husband, I'd put poison in your coffee. Winston Churchill: Nancy, if you were my wife, I'd drink it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Piyush Learn more: https://www.linkedin.com/e/isd/651882543/XZ5JfEAP/ -- (c) 2009, LinkedIn Corporation ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support
Hi Prafulla, hi Marvell engineers, By default Auto Negotiation is enabled for interface speed but on some platforms like RD6281A it does not work. If you want to forced program it to desired speed, this patch helps- do you have some information why auto negotiation doesn't work on RD6281A? I'm working on custom hardware and don't want to do the same mistake :) Many thanks, Dieter Through this patch Auto negotiation can be disabled and desired interface speed can be configured This patch is tested on RD6281A Kirkwood board Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- drivers/net/kirkwood_egiga.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c index 3c5db19..1dfd567 100644 --- a/drivers/net/kirkwood_egiga.c +++ b/drivers/net/kirkwood_egiga.c @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev) /* Assign port configuration and command. */ KWGBEREG_WR(regs-pxc, PRT_CFG_VAL); KWGBEREG_WR(regs-pxcx, PORT_CFG_EXTEND_VALUE); + /* + * Forced 10/100/1000BASE-T interface speed configuration + * By default Auto Negotiation of interface speed is enabled + * This can be forced disabled and desired speed can be configured + */ +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII +#if (!defined (CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET)) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_1000); +#elif (CONFIG_PHY_SPEED == _100BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_100); +#elif (CONFIG_PHY_SPEED == _10BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_10); +#endif /* CONFIG_PHY_SPEED == _10BASET */ +#else KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE); +#endif /* CONFIG_DIS_AUTO_NEG_SPEED_GMII */ + /* Disable port initially */ KWGBEREG_BITS_SET(regs-psc0, KWGBE_SERIAL_PORT_EN); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
Hi Thomas, +#define ROUND(A, B) (((A) + (B)) ~((B) - 1)) I'd try and use the round functions already in include/common.h if possible. Maybe its not possible if this file is included prior to common.h though, I'm not sure. Not sure about this one. All at91 boards do it this way, so if a fix needs to be done, I'd suggest to make it separatly. Is this ok ? I don't have the final say here, I'm just giving my opinion. If it was possible to clean up, the best way in my would be to fix your board (ie this patch), then send a separate follow-up patch fixing other boards. I don't think its too big of a deal either way. Below is an updated version of the patch. Not sure it's the right way to resend it, though. Not quite the right way. As is, all your comments above would go into U-Boot's changelog, which you don't want. You should either send your patch and comments in separate emails, or put any comments you don't want in the changelog below the --- mentioned below. The Calao USB A9263 board is a board manufactured and sold by Calao Systems http://www.calao-systems.com. Its components are very similar to the AT91SAM9263EK board, so its configuration is based on the configuration of this board. There are however some differences: different clocks, no LCD, etc. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com You need to add a '---' line here. Anything from the --- to the first diff below are only comments and will be discarded when your patch is applied. MAINTAINERS |4 MAKEALL |1 Makefile |3 board/calao/usb-a9263/Makefile| 56 board/calao/usb-a9263/config.mk |1 board/calao/usb-a9263/led.c | 44 ++ board/calao/usb-a9263/partition.c | 37 + board/calao/usb-a9263/usb-a9263.c | 193 include/configs/usb-a9263.h | 186 ++ 9 files changed, 525 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..5c37647 100644 --- a/MAINTAINERS snip +# diff --git a/board/calao/usb-a9263/config.mk b/board/calao/usb-a9263/config.mk new file mode 100644 index 000..ff2cfd1 --- /dev/null +++ b/board/calao/usb-a9263/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x23f0 You should add a copyright header of some sort to config.mk. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 16:06, Stefan Roese wrote: On Thursday 16 July 2009 15:47:17 Matthias Fuchs wrote: bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? To long for my taste. Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. If you already forgot what it's supposed to mean, then it definitely is not a good name. Better a bit longer and more descriptive. I like 'sbe' - it short and I even gave it a meaning :-) But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. I was a little inspired by the sequoia code that also comes with a bootstrap command. So please don't ask me to merge it into common code. But your finger on your own nose. Does you command support more features? What's the main difference? Much simpler. Just call sbe with a descriptive argument like a CPU frequency or something like '667-66' on a 440EPx target with 66Mhz PCI clock or 'sr-test-only' for something you will remove later :-). This has two advantages over just using numbers: You can remove configurations without making the following configs in the table moving to the front and its a little more secure meaning you have to type a couple of valid character to reconfigure the clocking. Just using bootstrap 5 is error-prone. Well, I like my syntax and behavior, but I do not want to totally dismiss Dirk's idea as long as I can keep my sbe command :-) 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Mike Frysinger wrote: i think calling raise/abort is already unreasonable for bare metal applications. So how do you propose that illegal divide operations be reported to the application? What is so unreasonable about having a function to print a message and dump registers? You could even make it a weak symbol that stays at NULL, so any attempt to call it will trap that way (assuming NULL pointers are trapped in U-Boot on that architecture...). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
Dear Marcel Moolenaar, In message cac78579-738b-4d03-8ef0-14fa1141f...@mac.com you wrote: This is also the crux of the problem. The application waits for a specific response, but there's no guarantee (due to broadcast or multicast packets on the LAN) that the next packet to arrive on the interface is the one that we're waiting for. Right. Now, one approach would be to ignore packets that don't fit the buffer. This seems unflexible, because it makes it impossible to employ flexible buffer allocation in the application. What's left? The only thing left is that flexible buffer allocation? May I ask what sort of applications you have in mind? We're talking about applications running in the context of a boot loader, right? For anything fancy you should probably rather use an operating system. you return whatever arrived on the interface truncated to the buffer size. That way the application can discard and call read again if headers don't match, or it can allocate a bigger buffer and retry. Allocate a bigger buffer? What for? The packet has been dropped already and is not recoverable. The problem with this approach is that theoretically an application needs to use a buffer that is as large as the maximum size of a packet that can appear on the interface. For example, with jumbo frames this means that any application, module or function that wants to receive even the smallest amount of data (say an ARP response) needs to allocate a 9K buffer. Right. The question is not of effort -- there's virtually none. The question is whether this is good engineering. Worst case buffer allocation doesn't strike me as portable nor reasonable. Not portable? In which way do you see any porting issues here? Not reasonable? How many such buffers do you need, then? All it takes is a different size in simple call to malloc(), or am I missing something? Please let's keep in mind: this is a boot loader, and a very minimal network stack. It is not an OS, and we don't claim to implement a TCP/IP stack. 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 shall reach greater and greater platitudes of achievement. - Richard J. Daley ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dear Scott Wood, In message 4a5f4913.5030...@freescale.com you wrote: So how do you propose that illegal divide operations be reported to the application? In the same way as Linux is doing it (i. e. usually nothing at all) ? What is so unreasonable about having a function to print a message and dump registers? We didn't need one for the so far. What exactly do we need it for now? You could even make it a weak symbol that stays at NULL, so any attempt to call it will trap that way (assuming NULL pointers are trapped in U-Boot on that architecture...). As you know, they are not. 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 shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot doesn't compile for M54455EVB_intel_config
Matt, In asm-m68k/io.h, please add #ifndef _IO_BASE #define _IO_BASE 0 #endif Regards, TsiChung On Wed, Jul 15, 2009 at 9:43 AM, Matthew Learm...@bubblegen.co.uk wrote: Hi TsiChung / Wolfgang, I just pulled u-boot.git to re-sync and tried to configure and build it for M54455EVB_intel_config but the compilation failed. I tried a fresh clone just to be sure and it was the same. [snip] m68k-linux-gnu-gcc -g -Os -ffixed-d7 -msep-data -D__KERNEL__ -DTEXT_BASE=0x -I/home/matt/nht/git-uboot-master/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.2.35-eglibc-2.5.35/m68k-linux/lib/gcc/m68k-linux-gnu/4.2.0/include -pipe -DCONFIG_M68K -D__M68K__ -mcpu=54455 -fPIC -DTEXT_BASE=0x -Wall -Wstrict-prototypes -fno-stack-protector -o cmd_ide.o cmd_ide.c -c cmd_ide.c: In function '__ide_outb': cmd_ide.c:529: error: '_IO_BASE' undeclared (first use in this function) cmd_ide.c:529: error: (Each undeclared identifier is reported only once cmd_ide.c:529: error: for each function it appears in.) cmd_ide.c: In function '__ide_inb': cmd_ide.c:538: error: '_IO_BASE' undeclared (first use in this function) cmd_ide.c: In function 'output_data': cmd_ide.c:942: error: '_IO_BASE' undeclared (first use in this function) cmd_ide.c: In function 'input_data': cmd_ide.c:1000: error: '_IO_BASE' undeclared (first use in this function) cmd_ide.c: In function 'output_data_shorts': cmd_ide.c:1705: error: '_IO_BASE' undeclared (first use in this function) cmd_ide.c: In function 'input_data_shorts': cmd_ide.c:1711: error: '_IO_BASE' undeclared (first use in this function) make[1]: *** [cmd_ide.o] Error 1 make[1]: Leaving directory `/home/matt/nht/git-uboot-master/u-boot/common' make: *** [common/libcommon.a] Error 2 Is this expected at the current time? Rgds, -- Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 16, 2009 8:15 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Manas Saksena; Ronen Shitrit; Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek Subject: Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support Hi Prafulla, hi Marvell engineers, By default Auto Negotiation is enabled for interface speed but on some platforms like RD6281A it does not work. If you want to forced program it to desired speed, this patch helps- do you have some information why auto negotiation doesn't work on RD6281A? Hi Dieter I do not have good answer for this with me :-( On RD6281A I thought Auto negotiation should work, but it did not. During my debugging, I performed several trial and error methods and forcing PHY interface speed to 1000BPs worked for me. So I exposed this configuration through this patch. I will certainly look for better answer for you Regards.. Prafulla . . I'm working on custom hardware and don't want to do the same mistake :) Many thanks, Dieter Through this patch Auto negotiation can be disabled and desired interface speed can be configured This patch is tested on RD6281A Kirkwood board Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- drivers/net/kirkwood_egiga.c | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c index 3c5db19..1dfd567 100644 --- a/drivers/net/kirkwood_egiga.c +++ b/drivers/net/kirkwood_egiga.c @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev) /* Assign port configuration and command. */ KWGBEREG_WR(regs-pxc, PRT_CFG_VAL); KWGBEREG_WR(regs-pxcx, PORT_CFG_EXTEND_VALUE); + /* +* Forced 10/100/1000BASE-T interface speed configuration +* By default Auto Negotiation of interface speed is enabled +* This can be forced disabled and desired speed can be configured +*/ +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII #if (!defined +(CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET)) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_1000); +#elif (CONFIG_PHY_SPEED == _100BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_100); +#elif (CONFIG_PHY_SPEED == _10BASET) + KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE + | KWGBE_DIS_AUTO_NEG_SPEED_GMII + | KWGBE_SET_GMII_SPEED_TO_10_100 + | KWGBE_SET_MII_SPEED_TO_10); +#endif /* CONFIG_PHY_SPEED == _10BASET */ #else KWGBEREG_WR(regs-psc0, PORT_SERIAL_CONTROL_VALUE); +#endif /* CONFIG_DIS_AUTO_NEG_SPEED_GMII */ + /* Disable port initially */ KWGBEREG_BITS_SET(regs-psc0, KWGBE_SERIAL_PORT_EN); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
On Thu, Jul 16, 2009 at 05:42:27PM +0200, Wolfgang Denk wrote: Dear Scott Wood, In message 4a5f4913.5030...@freescale.com you wrote: So how do you propose that illegal divide operations be reported to the application? In the same way as Linux is doing it (i. e. usually nothing at all) ? Yay bugs. What is so unreasonable about having a function to print a message and dump registers? We didn't need one for the so far. What exactly do we need it for now? For the same reason we have cpu/*/traps.c. You could even make it a weak symbol that stays at NULL, so any attempt to call it will trap that way (assuming NULL pointers are trapped in U-Boot on that architecture...). As you know, they are not. If you're happy with not making it debuggable, then there's no need to trap on the NULL -- just make sure it never happens. :-) I'd much rather spend the handful of bytes on at least a __builtin_trap(), though. Or do compiler implementation specific things such as reimplementing libgcc functions or carefully avoiding generating calls to them, if you prefer. Whatever. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
Dear Wolfgang, Wolfgang Denk a écrit : I'm not sure it's possible to use a generic geometry/timings there else u-boot may never relocate. How would you do this ? Well, normally you have 2 or 3 row/col combinations that have to be considered; you try these in turn until you find one where get_ram_size() returns a non-zero size; if several work, you use that which returns the biggest size. See for example board/tqc/tqm8xx/tqm8xx.c - it tries 8, 9 and 10 column mode... I've tried something very close to what is done in tqm8xx but I don't manage to get something reliable : either it hangs or I get data abort. After checking the datasheet, I don't understand how we can change the geometry of this SDRAM controler while running from SDRAM : each time we increase the colum number, the address are modified thus we can't execute any more u-boot's code as it's no more where we are expecting it. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
On Jul 16, 2009, at 5:39 AM, Wolfgang Denk wrote: Dear Piotr =?iso-8859-2?q?Zi=EAcik?=, In message 200907161151.59353.ko...@semihalf.com you wrote: This patch fixes above problem by allowing partial packet read. seems like it could easily introduce incorrect behavior in existing applications. the code also sounds a bit risky ... your change would mean people could read the leading part, but the rest is lost ? discaded, if buffer is too small. This behaviour is similar to Linux recv() But recv() is on another level. Here we are dealing with receiving raw ethernet frames. Yes. As such truncation and other protocol errors need to be checked for. Including the reception of packets you're not waiting for. If an application prepares a 100-byte buffer, then it does so under the assumption that what it's waiting for is not larger than 100 bytes. This is a fair assumption, because applications wait for specific packets. In the trigger case: an ARP response. This is also the crux of the problem. The application waits for a specific response, but there's no guarantee (due to broadcast or multicast packets on the LAN) that the next packet to arrive on the interface is the one that we're waiting for. Now, one approach would be to ignore packets that don't fit the buffer. This seems unflexible, because it makes it impossible to employ flexible buffer allocation in the application. What's left? The only thing left is that you return whatever arrived on the interface truncated to the buffer size. That way the application can discard and call read again if headers don't match, or it can allocate a bigger buffer and retry. function. I do not see why we have to force application to prepare 1,5kB buffer for received packets when for example it waits for ARP reply. Come on - what exactly is the extra effort you have to spend to prepare a bigger buffer? The problem with this approach is that theoretically an application needs to use a buffer that is as large as the maximum size of a packet that can appear on the interface. For example, with jumbo frames this means that any application, module or function that wants to receive even the smallest amount of data (say an ARP response) needs to allocate a 9K buffer. The question is not of effort -- there's virtually none. The question is whether this is good engineering. Worst case buffer allocation doesn't strike me as portable nor reasonable. My $0.02. -- Marcel Moolenaar xcl...@mac.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support)
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, July 16, 2009 4:55 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH][repost] mkimage support ( bin_dep.sh Support) Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202ddf26...@sc-vexch1.marvell. com you wrote: The code really needs to be rewritten in a clean fashion using common programming metaphors, style and library functions (i.e. use getopt(3), etc.). During restructuring activity for this utility, I found that most of the code and algorithm is common between mkimage and kwimage (old name doimage). I'm not really surprised. I have studied mkimage code. kwimage requirements can be well supported by adding one more type support to the mkimage (i.e. bootrom). bootrom is a way to generic name. You have a specific data format in mind, so please use a more specific name. Kirkwood Specs call it as boot image which is a post processed binary bundled with BootRom header and optional header extension so that Kirkwood's internal bootRom loads it from specific media to DRAM and starts execution. Ref: (Section 24.2.4) http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf So I will name this as kwbimage and target will be u-boot.kwb Further boot image could be different for boot from SF/NANDF/UART/SATA etc... This information will be abstracted form board specific config.mk. The bootrom image file generation generic abstraction can be provided with new file ./common/bootrom.c internally supported by Arch specific macros/code. Hm... I guess this would make it even more complicated to separate the mkimage tool from the rest of the U-Boot code. There have been repeated requests to make it more independent or even integrate in into the Linux kernel code tree. We should keep this in mind. So I will limit my self not to disturb current mkimage architecture. I will add additional kwbimage type support the related code will be abstracted to ./tools/kwbimage.c Note that this is not an argument against your proposal - just a note that we should keep this aspect in mind when implementing and reviewing the new code. Thanks...If this find useful for others we can think of expanding it latter. For ex. Type = SOCbimage and abstraction in SOCbimage.c/h With this- 1. mkimage can be reused for kwimage generation. Sounds good to me. 2. Kwimage generation can be supported in a generic way under bootrom image type This doesn't sound such a good idea to me. As mentioned above, bootrom is a very generic name which can be anything - but if you assign this name to a specific format, it should be exactly _one_ speific format. Cool. In sync... Type renamed kwbimage, abstraction in ./tools/kwbimage.c/h 3. In future the same interface can be used by other Marvell and non Marvell socs for similar kind of requirements. Shall I go ahead with this approach? or I should not disturb mkimage at all? What is your opinion? I think this is a pretty good plan. Please go ahead. Thanks a lot :-D Regards.. Prafulla . . 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 After a heated argument on some trivial matter Nancy [Astor] . . . shouted, ``If I were your wife I would put poison in your coffee!'' Whereupon Winston Churchill with equal heat and sincerity answered, ``And if I were your husband I would drink it.'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
I've tried something very close to what is done in tqm8xx but I don't manage to get something reliable : either it hangs or I get data abort. After checking the datasheet, I don't understand how we can change the geometry of this SDRAM controler while running from SDRAM No, you can't. That part must be done while you run from flash. Actually, this is done in cpu/arm926ejs/at91/lowlevel_init.S, in the table SMRDATA1. So, with the current code base, you can't autodetect ram size on the atmel 926x. I have the same problem, as I have boards that ship as either 64M or 128M. I'd configure for 128M and look for aliases, reconfiguring for 64M if needed. This can be done in lowlevel_init.S or by setting up a temporary C environment with sp in static RAM and doing it in C. In both cases, this doesn't fit the current code base and some refactoring would be needed to go mainline. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
On Jul 16, 2009, at 8:39 AM, Wolfgang Denk wrote: Now, one approach would be to ignore packets that don't fit the buffer. This seems unflexible, because it makes it impossible to employ flexible buffer allocation in the application. What's left? The only thing left is that flexible buffer allocation? May I ask what sort of applications you have in mind? We're talking about applications running in the context of a boot loader, right? For anything fancy you should probably rather use an operating system. Nothing particular. It was just a random thought that popped in my head while I was typing. I very much doubt that anything will be implemented, but it does illustrate (at least to me :-) how one approach makes assumptions and thereby eliminating a class of implementations (this being the ignore packet behaviour) while the other does not, allows that same class of applications, but does so at the cost of having applications check more. Since we are talking about raw packets, the application (in this case a boot loader) must check anyway, so the cost is nihil. you return whatever arrived on the interface truncated to the buffer size. That way the application can discard and call read again if headers don't match, or it can allocate a bigger buffer and retry. Allocate a bigger buffer? What for? The packet has been dropped already and is not recoverable. The scenario in question is when the truncated packet is passed to the application. There's no dropping. Depending on the application it surely can wait for the retransmit or it can ask for one. Both cases (wait or ask) can be considered retries... The question is not of effort -- there's virtually none. The question is whether this is good engineering. Worst case buffer allocation doesn't strike me as portable nor reasonable. Not portable? In which way do you see any porting issues here? Not reasonable? How many such buffers do you need, then? All it takes is a different size in simple call to malloc(), or am I missing something? Wolfgang, It seems to me that these questions stem from an assumption about how applications are written. That is, I always interpret these questions as an inquiry into the use of an API so as to argue about how an API is used, rather than how the API should behave. Personally, I don't think this is the right approach when discussing an API, because it the API comes with an assumed use case. Anyway: I'll answer your question given above beneath the following... Please let's keep in mind: this is a boot loader, and a very minimal network stack. It is not an OS, and we don't claim to implement a TCP/IP stack. The application in question is a boot loader. One that does not implement a TCP/IP stack either. I would argue that it's exactly the application one would expect to run under U-Boot. As to the porting issues you were asking about: the FreeBSD boot loader runs in many environments: PC BIOS, EFI, Open Firmware, U-Boot, ARC (obsolete), etc. If The U-Boot APIs requires the FreeBSD loader to allocate 9K buffers just so that it can receive a tiny ARP response, then it's the only environment to do so. Changing the FreeBSD loader to work with U-Boot affects the loader in the other environments as well. This by itself shows that there's a portability issue. As for the number of buffers: we need 1 for ARP. A small one I might add. However, BOOTP/DHCP also needs a buffer. That's one more. TFTP needs a buffer. etc, etc... The question as to how many buffers we need cannot really be answered without digressing in why don't you restructure your code so that you only need 1. It all depends on how code is organized, designed, modularized or combined. In the case of the FreeBSD loader we a few places to change. This does not include all the non-open features that people have added to the loader. Let me try to spin it differently: The U-Boot APIs were intended and designed to work with any application. More to the point: they we designed, implemented and added to U-Boot *because* of the need arising from wanting to use the FreeBSD loader under U-Boot. A such, the APIs were designed with the loader in mind and they were tested with the FreeBSD loader. Besides adding a U-Boot interface layer to the loader, no loader changes were made. Ok, there's bug. Or at least a scenario that wasn't really thought about or considered. The pivotal application, key in designing and implementing the APIs, shows that the API in U-Boot can hang. [The hang being caused by the reception of a packet that is larger than the buffer the application provides]. There are 2 simple fixed that would fix the API: 1) just drop the packet. 2) return a truncated packet. However, I'm currently in a discussion that suggests that the application should use bigger buffers. That strikes me as odd, because by intend and design the API was to support the application without requiring it to use bigger buffers. Put differently:
Re: [U-Boot] [PATCH] - save the server's mac address...
Mike Frysinger wrote: On Monday 13 July 2009 16:19:51 Robin Getz wrote: +CONFIG_KEEP_SERVERADDR + +Keeps the server's MAC address, in the env 'serveraddr' +for passing to bootargs (like Linux's netconsole option) is a config option really necessary ? i'd say just add it for everyone -mike ACK ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.
Mike Frysinger wrote: On Tuesday 14 July 2009 04:08:35 Piotr Ziecik wrote: When packets arrive on the interface that are larger than the buffer being passed to U-Boot from a standalone application, then the eth_receive() returns -1 and leaves the packet saved. The next call to eth_receive() will find that same packet and can fail for the exact same reason. A typical scenario is the loader doing ARP with a buffer of 66 bytes. The end result is that the ARP will fail and the loader panics. This patch fixes above problem by allowing partial packet read. seems like it could easily introduce incorrect behavior in existing applications. the code also sounds a bit risky ... your change would mean people could read the leading part, but the rest is lost ? probably better to add a new function with explicit semantics -- eth_receive_partial() or something. -mike I've read this whole thread, but this seems the most appropriate place to respond. I don't like changing the behavior of an existing call to truncation from an error, since who knows what will break. Adding another call with different, documented behavior seems more appropriate. I agree with Wolfgang that this really needs to be simple and personally don't see the burdens involved in allocating full MTU-sized buffers, but obviously can't envision all usage scenarios. The talk of jumbo frames is currently moot, as the buffer size is fixed in U-boot @ 1518 (#define PKTSIZE 1518). This should probably be configurable, but that's another matter. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] eth/net driver documentation
Hi Mike, Mike Frysinger wrote: is there any documentation that covers the NET_MULTI driver stack ? i.e. if i was a network chip vendor and wanted to write a u-boot driver for my part, where would i look ? or is it a matter of the code is the documentation ? i can start a small doc that covers the existing stack if that is the case ... more to keep my sanity so i dont have to keep going through the ethernet stack to remind myself of how things fit together ;). -mike Isn't the code nicely self-documenting? :) I think yours is a great idea. It's a pretty simple interface, but not necessarily intuitive. I'll be glad to help if needed. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/30] lan91c96/smc91111/smc911x: get mac address from environment
Hi Mike, Mike Frysinger wrote: snip not specific to either of these drivers, so if we did choose to make this behavior optional via some define, it would make more sense to do it in the common eth code rather than copying pasting it everywhere. Agreed. Do you think you have time and resources to craft such a patch? net/eth.c:eth_initialize() already has the logic to handle this, but that only applies to NET_MULTI drivers. and most do not take advantage of it. i think the documentation should be updated like so: in the driver function that calls eth_register(), the driver should initialize dev-enetaddr to the MAC found in the hardware (if possible) and then applicable drivers should be fixed. if we agree on this route, i can do a quick scan of the net drivers and post relevant patches. That'd be great. You've done good work bringing consistency to the code. in the case of a mismatch, we would see from the common eth code: Warning: Blackfin EMAC MAC addresses don't match: Address in SROM is 0a:0a:0a:0a:0a:0a Address in environment is 00:e0:22:fe:44:ec the smsc drivers however are not in the NET_MULTI category -- they dont use any of the common ethernet stack. so once they are converted to NET_MULTI, they'll get this functionality for free (when exactly were we adding #warning about non-NET_MULTI usage ?). so rather than expend effort on restoring duplicate code, how about interested parties convert the driver ;). -mike The #warning patch is done but not submitted. Pretty lame, I know, but it's been a crazy summer. I have the SMSC driver mostly ported but don't have any hardware to test on. I guess there are 3 days left in this merge window to get the ball rolling... If anybody else has already done this, please submit. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible bug in NAND driver
On Mon, Jul 13, 2009 at 02:34:42PM -0500, Paulraj, Sandeep wrote: I see that changing if (rval != 0) to if (rval != 0 rval != -EUCLEAN ) solves the problem. I can submit a patch if required. Yes, please submit a patch. Thanks! -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 16:16:36 Felix Radensky wrote: But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. Does you command support more features? What's the main difference? BTW, there's also pllalter command for kilauea, that provides similar functionality. Correct. Thanks for reminding me. I'll do some Kilauea work in the next days and so I'll probably change this command to the new 4xx-common bootstrap command (whatever this will be). 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] [PATCH v2 1/1] Add support for Eukrea CPU9260 SBC
CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100 Ethernet PHY in RMII mode. Signed-off-by: Eric Benard e...@eukrea.com --- MAINTAINERS|4 + MAKEALL|1 + Makefile | 13 ++ board/eukrea/cpu9260/Makefile | 59 +++ board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 211 ++ board/eukrea/cpu9260/cpu9260_led.c | 46 + cpu/arm926ejs/at91/lowlevel_init.S |2 +- include/configs/cpu9260.h | 339 9 files changed, 675 insertions(+), 1 deletions(-) create mode 100644 board/eukrea/cpu9260/Makefile create mode 100644 board/eukrea/cpu9260/config.mk create mode 100644 board/eukrea/cpu9260/cpu9260.c create mode 100644 board/eukrea/cpu9260/cpu9260_led.c create mode 100644 include/configs/cpu9260.h diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..b8d701a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -515,6 +515,10 @@ Dirk Behme dirk.be...@gmail.com omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) +Eric Benard e...@eukrea.com + + cpu9260 ARM926EJS (AT91SAM9260 SoC) + Rishi Bhattacharya ri...@ti.com omap5912osk ARM926EJS diff --git a/MAKEALL b/MAKEALL index 020ff73..bdc80fa 100755 --- a/MAKEALL +++ b/MAKEALL @@ -592,6 +592,7 @@ LIST_at91= \ at91sam9m10g45ek\ at91sam9rlek\ cmc_pu2 \ + cpu9260 \ csb637 \ kb9202 \ meesc \ diff --git a/Makefile b/Makefile index 090e645..7ae2bfe 100644 --- a/Makefile +++ b/Makefile @@ -2813,6 +2813,19 @@ at91sam9rlek_config : unconfig fi; @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91 +cpu9260_64m_config \ +cpu9260_config : unconfig + @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91 + @if [ $(findstring _64m,$@) ] ; then \ + echo #define CONFIG_SYS_SDRC_CR_VAL CONFIG_SYS_SDRC_CR_VAL_64MB \ + $(obj)include/config.h ; \ + $(XECHO) ... with 64MB SDRAM ; \ + else \ + echo #define CONFIG_SYS_SDRC_CR_VAL CONFIG_SYS_SDRC_CR_VAL_128MB \ + $(obj)include/config.h ; \ + $(XECHO) ... with 128MB SDRAM ; \ + fi; + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile new file mode 100644 index 000..5b1acdc --- /dev/null +++ b/board/eukrea/cpu9260/Makefile @@ -0,0 +1,59 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# Ilko Iliev www.ronetix.at +# +# (C) Copyright 2009 +# Eric Benard e...@eukrea.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y += $(BOARD).o +COBJS-y += $(BOARD)_led.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk new file mode 100644 index 000..9ce161e --- /dev/null +++ b/board/eukrea/cpu9260/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x21f0 diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c new file mode 100644 index 000..1d95f96 --- /dev/null +++ b/board/eukrea/cpu9260/cpu9260.c @@ -0,0 +1,211
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPU9260 SBC
Hi Alessandro, Alessandro Rubini a écrit : So, with the current code base, you can't autodetect ram size on the atmel 926x. I have the same problem, as I have boards that ship as either 64M or 128M. I'd configure for 128M and look for aliases, reconfiguring for 64M if needed. This can be done in lowlevel_init.S or by setting up a temporary C environment with sp in static RAM and doing it in C. In both cases, this doesn't fit the current code base and some refactoring would be needed to go mainline. OK, in our case auto detection is not required so my updated patch gives the choice between both configurations through the Makefile. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 17:00:00 Matthias Fuchs wrote: Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. If you already forgot what it's supposed to mean, then it definitely is not a good name. Better a bit longer and more descriptive. I like 'sbe' - it short and I even gave it a meaning :-) But unfortunately not specific enough for a common command. But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. I was a little inspired by the sequoia code that also comes with a bootstrap command. So please don't ask me to merge it into common code. But your finger on your own nose. OK. But if your sbe command is better than the current bootstrap one, then let's see if it makes sense to use your command as the common one. Does you command support more features? What's the main difference? Much simpler. Just call sbe with a descriptive argument like a CPU frequency or something like '667-66' on a 440EPx target with 66Mhz PCI clock or 'sr-test-only' for something you will remove later :-). This has two advantages over just using numbers: You can remove configurations without making the following configs in the table moving to the front and its a little more secure meaning you have to type a couple of valid character to reconfigure the clocking. Just using bootstrap 5 is error-prone. Ack. Well, I like my syntax and behavior, but I do not want to totally dismiss Dirk's idea as long as I can keep my sbe command :-) Seems that your command is not so bad. ;) I'll take a look at it tomorrow. Perhaps we can use some of your ideas in such a new common (PPC4xx) implementation. :) 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] [PATCH 17/30] lan91c96/smc91111/smc911x: get mac address from environment
On Thursday 16 July 2009 13:41:30 Ben Warren wrote: Mike Frysinger wrote: the smsc drivers however are not in the NET_MULTI category -- they dont use any of the common ethernet stack. so once they are converted to NET_MULTI, they'll get this functionality for free (when exactly were we adding #warning about non-NET_MULTI usage ?). so rather than expend effort on restoring duplicate code, how about interested parties convert the driver ;). -mike The #warning patch is done but not submitted. Pretty lame, I know, but it's been a crazy summer. I have the SMSC driver mostly ported but don't have any hardware to test on. I guess there are 3 days left in this merge window to get the ball rolling... If anybody else has already done this, please submit. i can test SMC911X and SMC9 with real hardware -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v5] KB9202: Add NAND support
On Sun, Jul 12, 2009 at 09:57:13PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:51 Wed 24 Jun , Scott Wood wrote: On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote: Add NAND support for the KwikByte KB9202 Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit: I get conflicts in kb9202.h. Is this against an arch tree, or does it need to be respun? The previous patches were against v2009-03, as i had problems building the current git head for the kb9202 when i started working on the patch. Did you apply the first patch of this series when you got the conflict? This patch is based on the current HEAD. No - if it depends on other patches that go through an arch tree, then this patch should go through that tree as well. Acked-by: Scott Wood scottw...@freescale.com Scott I've not follow this patch but for the arm part it's looks fine so I'll let you handle It still does not apply to the current tree, so I cannot accept it as is. The NAND tree is not an appropriate route for unrelated changes to a board config file (such as CONFIG_BOOTARGS/CONFIG_BOOTCOMMAND) to go -- and even if it were, I don't have an easily applyable version of patch 1/2 (the mailing list archives mangle things). Matthias, can you resend a patch that just adds the NAND driver (for me), and a separate patch that just touches the board config (for the arch tree)? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Initial environment variables
When I submitted patches for my new board SIMPC8313 I recall being told that I had inappropriately initialized some of my environment variables. Most specifically I am interested in having default serverip, ipaddr, and ethaddr environment variables. Is this most appropriately done with a specific #define (such as #define CONFIG_SERVERIP) or within #define CONFIG_EXTRA_ENV_SETTINGS? Thanks for the help. Ron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Initial environment variables
On Thursday 16 July 2009 14:57:10 Ron Madrid wrote: When I submitted patches for my new board SIMPC8313 I recall being told that I had inappropriately initialized some of my environment variables. Most specifically I am interested in having default serverip, ipaddr, and ethaddr environment variables. Is this most appropriately done with a specific #define (such as #define CONFIG_SERVERIP) or within #define CONFIG_EXTRA_ENV_SETTINGS? not CONFIG_EXTRA_ENV_SETTINGS look at common/env_common.c to see what defines are available to you -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: OneNAND: Increase the environment size to 4KiB
On Sat, Jul 11, 2009 at 04:49:55PM +0900, Kyungmin Park wrote: Also use mtd operatoin instead of onenand functions Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Applied (with non-subject changelog typo fixed) to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v6] KB9202: Add NAND support
Add KB9202 NAND driver
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
El Thu, Jul 16, 2009 at 01:45:57PM -0500 Scott Wood ha dit:
On Sun, Jul 12, 2009 at 09:57:13PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 15:51 Wed 24 Jun , Scott Wood wrote:
On Wed, Jun 24, 2009 at 05:23:05PM +0200, Matthias Kaehlcke wrote:
Add NAND support for the KwikByte KB9202
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
El Tue, Jun 23, 2009 at 04:19:40PM -0500 Scott Wood ha dit:
I get conflicts in kb9202.h. Is this against an arch tree, or does it
need to be respun?
The previous patches were against v2009-03, as i had problems
building the current git head for the kb9202 when i started working on
the patch. Did you apply the first patch of this series when you got
the conflict? This patch is based on the current HEAD.
No - if it depends on other patches that go through an arch tree, then
this
patch should go through that tree as well.
Acked-by: Scott Wood scottw...@freescale.com
Scott I've not follow this patch but for the arm part it's looks fine so
I'll
let you handle
It still does not apply to the current tree, so I cannot accept it as is.
The NAND tree is not an appropriate route for unrelated changes to a
board config file (such as CONFIG_BOOTARGS/CONFIG_BOOTCOMMAND) to go --
and even if it were, I don't have an easily applyable version of patch
1/2 (the mailing list archives mangle things).
Matthias, can you resend a patch that just adds the NAND driver (for me),
and a separate patch that just touches the board config (for the arch
tree)?
ok, here is a patch that only adds the NAND driver. i'll prepare a
board config patch after my first patch has hit mainline to avoid
further confusion :)
changes regarding v5:
* only add the NAND driver, without touching the board configuration
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/kb9202_nand.c | 150
2 files changed, 151 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/kb9202_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index a5680e8..aab3b70 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
COBJS-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
COBJS-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
+COBJS-$(CONFIG_NAND_KB9202) += kb9202_nand.o
COBJS-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
COBJS-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
diff --git a/drivers/mtd/nand/kb9202_nand.c b/drivers/mtd/nand/kb9202_nand.c
new file mode 100644
index 000..b8f46fa
--- /dev/null
+++ b/drivers/mtd/nand/kb9202_nand.c
@@ -0,0 +1,150 @@
+/*
+ * (C) Copyright 2006
+ * KwikByte kb9200_...@kwikbyte.com
+ *
+ * (C) Copyright 2009
+ * Matthias Kaehlcke matth...@kaehlcke.net
+ *
+ * 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 asm/io.h
+#include asm/arch/AT91RM9200.h
+#include asm/arch/hardware.h
+
+#include nand.h
+
+/*
+ * hardware specific access to control-lines
+ */
+
+#define MASK_ALE(1 22) /* our ALE is A22 */
+#define MASK_CLE(1 21) /* our CLE is A21 */
+
+#define KB9202_NAND_NCE (1 28) /* EN* on D28 */
+#define KB9202_NAND_BUSY (1 29) /* RB* on D29 */
+
+#define KB9202_SMC2_NWS (1 2)
+#define KB9202_SMC2_TDF (1 8)
+#define KB9202_SMC2_RWSETUP (1 24)
+#define KB9202_SMC2_RWHOLD (1 29)
+
+/*
+ * Board-specific function to access device control signals
+ */
+static void kb9202_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+
+ if (ctrl NAND_CTRL_CHANGE) {
+ ulong IO_ADDR_W = (ulong) this-IO_ADDR_W;
+
+ /* clear ALE and CLE bits */
+ IO_ADDR_W = ~(MASK_ALE | MASK_CLE);
+
+ if (ctrl NAND_CLE)
+ IO_ADDR_W |= MASK_CLE;
+
+ if (ctrl NAND_ALE)
+ IO_ADDR_W |=
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
On Mon, Jul 13, 2009 at 09:48:30AM +0900, Kyungmin Park wrote: Basically I agree your opinion, however do see the other arch OneNAND usage? I mean I can't see the other arch patches. There was nothing but powerpc in nand_spl at first, but I don't think ARM developers would have appreciated finding hardcoded powerpc assumptions when they tried to add their boards. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Apollon board use common OneNAND IPL linker
On Sun, Jul 12, 2009 at 02:59:26PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:11 Sat 11 Jul , Kyungmin Park wrote: Use common OneNAND IPL linker script. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com please number the patch to known the apply order Numbering won't help here -- they have to go in the same patch atomically, or else bisect will break. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 3/3] 83xx, kmeter1: added NAND support
On Mon, Jul 13, 2009 at 12:15:12PM +0200, Heiko Schocher wrote:
+#define read_mode() in_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_MODE_REG)
+#define write_mode(val) out_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_MODE_REG, val)
+#define read_data() in_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_DATA_REG)
+#define write_data(val) out_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_DATA_REG, val)
No need for volatile when using accessors. If you kept a pointer around
instead of casting here, you could reasonably use the accessors directly
without needing wrappers...
If this is purely for U-Boot and not shared with Linux we can drop the
__iomem.
+static void kpn_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ u8 reg_val = read_mode();
No tab after u8.
+ if (ctrl NAND_CTRL_CHANGE) {
+ if ( ctrl NAND_NCE)
No space after (.
+ reg_val = reg_val ~KPN_CE1N;
+ else
+ reg_val = reg_val | KPN_CE1N;
+ write_mode(reg_val);
+ }
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ reg_val = reg_val ~(KPN_ALE + KPN_CLE);
+ if (ctrl NAND_CLE)
+ reg_val = reg_val | KPN_CLE;
+ if (ctrl NAND_ALE)
+ reg_val = reg_val | KPN_ALE;
If ALE/CLE is sticky in the hardware mode register, you could probably
move this under NAND_CTRL_CHANGE and simplify things a little.
diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
index 811ba88..4de0dfc 100644
--- a/include/configs/kmeter1.h
+++ b/include/configs/kmeter1.h
@@ -324,6 +324,12 @@
#define CONFIG_SYS_DTT_HYSTERESIS3
#define CONFIG_SYS_DTT_BUS_NUM (CONFIG_SYS_MAX_I2C_BUS)
+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_KMETER1
No tab after #define.
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE CONFIG_SYS_PIGGY_BASE
+#endif
+
#if defined(CONFIG_PCI)
#define CONFIG_CMD_PCI
#endif
This file looks a little different in the current tree (2 rather than
CONFIG_SYS_MAX_I2C_BUS), so it wouldn't apply cleanly.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
Dear Matthias Fuchs, In message 200907161547.17433.matthias.fu...@esd.eu you wrote: Hi Dirk, On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote: On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote: This adds a generic command for programming I2C bootstrap eeproms. Implementation for Canyonlands board is included. bootstrap is pretty generic. can you pick something a little more descriptive/specific ? I agree with Mike. Please change the command name and the files to something more specific. How about 4xxbootstrap? Or 4xxstrap? To long for my taste. Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. But it works Indeed. sbe is not an acceptable name as nobody will know what it's suppost to mean. a little mit different that the bootstrap command. Actually the name bootstrap command itself is something that I really dislike. Please find a better description (avoiding bootstrap), and then chose a descriptive name. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A well-written program is its own heaven; a poorly-written program is its own hell. -- Geoffrey James, The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Improve U-Boot Porting Guide in the README
Dear Jerry Van Baren, In message 20090716004258.ga16...@cideas.com you wrote: Update for... * BDI2000 - BDI3000 (BDI2000 is obsolete). * Add a line to read the doc/README.* files * Fix coding standard violations Signed-off-by: Gerald Van Baren vanba...@cideas.com --- Dear Wolfgang, I was looking at the Porting Guide and realized it needed some updating. Thanks, gvb README | 60 1 files changed, 36 insertions(+), 24 deletions(-) Applied, thanks :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God made machine language; all the rest is the work of man. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.
On Mon, Jul 13, 2009 at 04:29:04PM -0700, David Brownell wrote: On Tuesday 07 July 2009, Scott Wood wrote: I fixed the obvious merge conflict (missing #endif) in davinci_nand: cleanup I (minor), but I'm a little confused since the symbol it refers to (CONFIG_SOC_DM6446) doesn't seem to be defined anywhere. At first I thought it had been replaced with CONFIG_SOC_DM644X, but that doesn't seem to be the case -- AFAICT, there never was a definition of CONFIG_SOC_DM6446 in the tree. There is one other place in the tree that ifdefs based on it, though (cpu/arm926ejs/davinci/cpu.c). David, any thoughts? If this is in error, could you send a followup patch? That should have been CONFIG_SOC_DM644X in the first place, yes. == CUT HERE From: David Brownell dbrown...@users.sourceforge.net Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Applied to u-boot-nand-flash. Wolfgang, I used Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646. as the first line of the commit message, which differs from the Pull request: nand flash subject of the outer message that will show up on the archive list. Do you want me to resend the patch to the list as an e-mail with that subject (and if I do, can I then fix the DM646 typo and clarify which code the fix is for?), or is the updated subject line in this e-mail enough? David, the usage in cpu/arm926ejs/davinci/cpu.c should probably be fixed as well. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull asm-generic
Dear Michal Simek, In message 4a55cdcb.7040...@monstr.eu you wrote: Hi Wolfgang, Please pull my asm-generic branch. There is only one patch which create asm-generic folder with errno.h. I have got ack from ppc40x, blackfin, arm, coldfire and avr custodians. Thanks, Michal The following changes since commit 59869ca72df8bc4e4ffa9dd17cb6673bbe010272: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-video are available in the git repository at: git://git.denx.de/u-boot-microblaze.git asm-generic Michal Simek (1): asm-generic: Consolidate errno.h to asm-generic/errno.h board/Marvell/db64360/mv_eth.h |3 +- board/Marvell/db64460/mv_eth.h |2 +- board/prodrive/p3mx/mv_eth.h |2 +- include/asm-arm/errno.h| 139 +- include/asm-avr32/errno.h | 133 + include/asm-blackfin/errno.h | 157 +--- .../ppc_error_no.h = include/asm-generic/errno.h | 47 +++ include/asm-m68k/errno.h | 139 +- include/asm-microblaze/errno.h |1 + include/asm-ppc/errno.h| 139 +- include/asm-sh/errno.h | 157 +--- include/asm-sparc/errno.h | 163 +--- 12 files changed, 30 insertions(+), 1052 deletions(-) rename board/Marvell/common/ppc_error_no.h = include/asm-generic/errno.h (87%) create mode 100644 include/asm-microblaze/errno.h Thanks, applied. 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 C++ was an interesting and valuable experiment, but we've learned its lessons and it's time to move on. - Peter Curran in dcqm4z@isgtec.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Initial environment variables
Ron, Ron Madrid wrote: When I submitted patches for my new board SIMPC8313 I recall being told that I had inappropriately initialized some of my environment variables. Most specifically I am interested in having default serverip, ipaddr, and ethaddr environment variables. Is this most appropriately done with a specific #define (such as #define CONFIG_SERVERIP) or within #define CONFIG_EXTRA_ENV_SETTINGS? You can set CONFIGs for all of these things in your own private build and they'll work, but they're inappropriate for main-line U-boot. I hope the reasoning is obvious. Thanks for the help. Ron regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Fix 2k page size NAND for iMX27
On Wed, Jul 15, 2009 at 05:18:40PM +0200, Eric Benard wrote:
static int __init imxnd_probe(struct device_d *dev)
{
struct nand_chip *this;
@@ -969,7 +978,7 @@ static int __init imxnd_probe(struct device_d *dev)
struct imx_nand_host *host;
u16 tmp;
int err = 0;
-#ifdef CONFIG_ARCH_MX27
+#ifdef CONFIG_ARCH_IMX27
PCCR1 |= PCCR1_NFC_BAUDEN;
#endif
/* Allocate memory for MTD device structure and private data */
@@ -1050,7 +1059,12 @@ static int __init imxnd_probe(struct device_d *dev)
this-ecc.layout = nand_hw_eccoob_16;
}
- host-pagesize_2k = 0;
+ if (pdata-is2k) {
+ host-pagesize_2k = 1;
+ NFMS |= (1 NFMS_BIT);
+ this-badblock_pattern = smallpage_memorybased;
Why are you using the small-page badblock pattern with large pages?
+ } else
+ host-pagesize_2k = 0;
If you use braces on one side of if/else, use them on the other.
diff --git a/include/asm-arm/arch-imx/imx-nand.h
b/include/asm-arm/arch-imx/imx-nand.h
index 5ebe0be..500bb1a 100644
--- a/include/asm-arm/arch-imx/imx-nand.h
+++ b/include/asm-arm/arch-imx/imx-nand.h
@@ -8,6 +8,7 @@ void imx_nand_load_image(void *dest, int size, int pagesize,
int blocksize);
struct imx_nand_platform_data {
int width;
int hw_ecc;
-};
+ int is2k;
+ };
That last brace should not be indented.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-coldfire
Dear TC Liew, In message a90206390907140812tc125739u7874a6d04b044...@mail.gmail.com you wrote: Hi Wolfgang, Please pull this change for u-boot-coldfire/next into your branch: The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1: Wolfgang Denk (1): mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map are available in the git repository at: git://www.denx.de/git/u-boot-coldfire.git next TsiChung Liew (9): ColdFire: Update configuration file to use flash buffer write ColdFire: Update for M54451EVB ColdFire: Add M5208EVB and MCF520x CPU support ColdFire: Fix M53017EVB flash size ColdFire: Remove compiler warning messages Coldfire: Consolidate DSPI driver ColdFire: Add DSPI support for MCF5227x and MCF5445x Command for accessing serial flash update ColdFire: Update bootargs MAKEALL |1 + Makefile | 12 +- board/freescale/m5208evbe/Makefile| 44 board/freescale/m5208evbe/config.mk | 25 +++ board/freescale/m5208evbe/m5208evbe.c | 94 + board/freescale/m5208evbe/u-boot.lds | 142 + board/freescale/m54451evb/u-boot.spa |9 +- common/cmd_sf.c |2 +- cpu/mcf5227x/Makefile |2 +- cpu/mcf5227x/cpu_init.c | 53 + cpu/mcf5227x/dspi.c | 261 cpu/mcf52x2/config.mk |4 + cpu/mcf52x2/cpu.c | 66 ++ cpu/mcf52x2/cpu_init.c| 89 cpu/mcf52x2/interrupts.c |8 +- cpu/mcf52x2/speed.c | 13 +- cpu/mcf52x2/start.S | 33 +++- cpu/mcf5445x/Makefile |2 +- cpu/mcf5445x/cpu_init.c | 66 ++ cpu/mcf5445x/dspi.c | 239 -- cpu/mcf5445x/start.S | 81 +--- drivers/spi/Makefile |1 + drivers/spi/cf_spi.c | 357 include/asm-m68k/coldfire/dspi.h | 229 ++--- include/asm-m68k/immap.h | 29 +++ include/asm-m68k/immap_520x.h | 212 +++ include/asm-m68k/m520x.h | 358 + include/configs/M5208EVBE.h | 223 include/configs/M52277EVB.h | 26 +-- include/configs/M53017EVB.h |7 +- include/configs/M54451EVB.h | 73 +++ include/configs/M54455EVB.h | 27 +-- lib_m68k/board.c |2 +- 33 files changed, 2039 insertions(+), 751 deletions(-) create mode 100644 board/freescale/m5208evbe/Makefile create mode 100644 board/freescale/m5208evbe/config.mk create mode 100644 board/freescale/m5208evbe/m5208evbe.c create mode 100644 board/freescale/m5208evbe/u-boot.lds delete mode 100644 cpu/mcf5227x/dspi.c delete mode 100644 cpu/mcf5445x/dspi.c create mode 100644 drivers/spi/cf_spi.c create mode 100644 include/asm-m68k/immap_520x.h create mode 100644 include/asm-m68k/m520x.h create mode 100644 include/configs/M5208EVBE.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't tell me how hard you work. Tell me how much you get done. - James J. Ling ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory
On Thu, Jul 16, 2009 at 03:12:48PM +0200, Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Cc: Scott Wood scottw...@freescale.com --- Applied patches 1-2 to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On Thursday 16 July 2009 17:00:00 Matthias Fuchs wrote: Any other good ideas about this naming welcome. :) We called this command sbe on our PMC440 (440EPx) and upcoming PMC405DE (405EP) board. I must admit that I forget its meaning. Probably something like 'setup bootstrap eeprom'. If you already forgot what it's supposed to mean, then it definitely is not a good name. Better a bit longer and more descriptive. I like 'sbe' - it short and I even gave it a meaning :-) But unfortunately not specific enough for a common command. I think we are talking about a generic 4xx command to write data into the EEPROM that is read by the bootstrap controller. But I do not care about the name ;-) But it works a little mit different that the bootstrap command. It would be great if you could merge/consolidate such 4xx custom commands into this common one. I was a little inspired by the sequoia code that also comes with a bootstrap command. So please don't ask me to merge it into common code. But your finger on your own nose. OK. But if your sbe command is better than the current bootstrap one, then let's see if it makes sense to use your command as the common one. Dirk's approach is very generic. Putting nothing but the EEPROM data and a descriptive table into the board file is what we need. I only suggest to add an additional label to each entry that is used instead of using numbers and I'd to pass this label as argument instead of the a number. One could use the numbers as labels also :-) When you do no pass the argument we could either print the descriptive texts as menu (as DIrk did so far) and wait for input or just print the texts as kind of help and the must supply an argument if he want to change something (I prefer the latter). Does you command support more features? What's the main difference? Much simpler. Just call sbe with a descriptive argument like a CPU frequency or something like '667-66' on a 440EPx target with 66Mhz PCI clock or 'sr-test-only' for something you will remove later :-). This has two advantages over just using numbers: You can remove configurations without making the following configs in the table moving to the front and its a little more secure meaning you have to type a couple of valid character to reconfigure the clocking. Just using bootstrap 5 is error-prone. Ack. Well, I like my syntax and behavior, but I do not want to totally dismiss Dirk's idea as long as I can keep my sbe command :-) Seems that your command is not so bad. ;) I'll take a look at it tomorrow. Perhaps we can use some of your ideas in such a new common (PPC4xx) implementation. :) My implementation is nothing but ar if-!strcmp-else-if-!strcmp implementation. But putting things together is a good idea. Matthias Thanks. Best regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx.git
Dear Kim Phillips, In message 20090714171545.161c6ff8.kim.phill...@freescale.com you wrote: Wolfgang, please pull some ITX board USB config tweaking, and some regular maintenance fixes for 83xx: The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1: Wolfgang Denk (1): mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Kim Phillips (2): mpc83xx: set 64BIT_VSPRINTF for boards using nand_util mpc83xx: increase MONITOR_LEN to offset growing pains Valeriy Glushkov (2): usb: mpc834x: added support of the MPH USB controller in addition to the DR one usb: mpx8349itx: added support of loading images from USB storage (MPH/DR) cpu/mpc83xx/cpu_init.c|2 ++ include/asm-ppc/immap_83xx.h | 11 ++- include/configs/MPC8313ERDB.h |3 ++- include/configs/MPC8315ERDB.h |1 + include/configs/MPC8323ERDB.h |2 +- include/configs/MPC832XEMDS.h |2 +- include/configs/MPC8349EMDS.h |2 +- include/configs/MPC8349ITX.h | 33 ++--- include/configs/MPC8360EMDS.h |2 +- include/configs/MPC8360ERDK.h |1 + include/configs/MPC837XERDB.h |2 +- include/configs/SIMPC8313.h |1 + include/configs/kmeter1.h |2 +- 13 files changed, 53 insertions(+), 11 deletions(-) Applied, thanks. p.s. I cannot reply applied to my own patch postings because I don't get them any more (even though in mailman, I have Receive your own posts to the list? set to 'yes'). We had this discussion sevral times before, and I cannot see any problems on the mailing list server. The messages seem to go out normally. There has been speculation that some receiving MTAs automatically and without notice drop messages for which they have already seen the message ID - do you have a chance to check your local server logs? 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 Were there fewer fools, knaves would starve. - Anonymous ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Cleanup PLU405 board code
Some Coding style cleanup (braces, whitespaces, long lines)
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
board/esd/plu405/plu405.c | 118 +++-
1 files changed, 62 insertions(+), 56 deletions(-)
diff --git a/board/esd/plu405/plu405.c b/board/esd/plu405/plu405.c
index fdacbf6..e41545a 100644
--- a/board/esd/plu405/plu405.c
+++ b/board/esd/plu405/plu405.c
@@ -27,10 +27,7 @@
#include command.h
#include malloc.h
-
-#if 0
-#define FPGA_DEBUG
-#endif
+#undef FPGA_DEBUG
DECLARE_GLOBAL_DATA_PTR;
@@ -48,7 +45,6 @@ const unsigned char fpgadata[] =
*/
#include ../common/fpga.c
-
/*
* include common auto-update code (for esd boards)
*/
@@ -68,7 +64,7 @@ int N_AU_IMAGES = (sizeof(au_image) / sizeof(au_image[0]));
/* Prototypes */
int gunzip(void *, int, unsigned char *, unsigned long *);
-int board_early_init_f (void)
+int board_early_init_f(void)
{
/*
* IRQ 0-15 405GP internally generated; active high; level sensitive
@@ -94,15 +90,13 @@ int board_early_init_f (void)
* EBC Configuration Register: set ready timeout to
* 512 ebc-clks - ca. 15 us
*/
- mtebc (epcr, 0xa840); /* ebc always driven */
+ mtebc(epcr, 0xa840); /* ebc always driven */
return 0;
}
-int misc_init_r (void)
+int misc_init_r(void)
{
- unsigned char *duart0_mcr = (unsigned char *)((ulong)DUART0_BA + 4);
- unsigned char *duart1_mcr = (unsigned char *)((ulong)DUART1_BA + 4);
unsigned char *dst;
unsigned char fctr;
ulong len = sizeof(fpgadata);
@@ -115,9 +109,10 @@ int misc_init_r (void)
gd-bd-bi_flashoffset = 0;
dst = malloc(CONFIG_SYS_FPGA_MAX_SIZE);
- if (gunzip (dst, CONFIG_SYS_FPGA_MAX_SIZE, (uchar *)fpgadata, len) !=
0) {
- printf (GUNZIP ERROR - must RESET board to recover\n);
- do_reset (NULL, 0, 0, NULL);
+ if (gunzip(dst, CONFIG_SYS_FPGA_MAX_SIZE,
+ (uchar *)fpgadata, len) != 0) {
+ printf(GUNZIP ERROR - must RESET board to recover\n);
+ do_reset(NULL, 0, 0, NULL);
}
status = fpga_boot(dst, len);
@@ -152,7 +147,7 @@ int misc_init_r (void)
for (index=0;index1000;index++)
udelay(1000);
}
- putc ('\n');
+ putc('\n');
do_reset(NULL, 0, 0, NULL);
}
@@ -165,7 +160,7 @@ int misc_init_r (void)
printf(%s , (dst[index+1]));
index += len+3;
}
- putc ('\n');
+ putc('\n');
free(dst);
@@ -180,29 +175,35 @@ int misc_init_r (void)
/*
* Reset external DUARTs
*/
- out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) |
CONFIG_SYS_DUART_RST);
+ out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_DUART_RST);
udelay(10);
- out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR)
~CONFIG_SYS_DUART_RST);
+ out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) ~CONFIG_SYS_DUART_RST);
udelay(1000);
/*
* Set NAND-FLASH GPIO signals to default
*/
out_be32((void*)GPIO0_OR,
-in_be32((void*)GPIO0_OR) ~(CONFIG_SYS_NAND_CLE |
CONFIG_SYS_NAND_ALE));
- out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) |
CONFIG_SYS_NAND_CE);
+in_be32((void*)GPIO0_OR)
+~(CONFIG_SYS_NAND_CLE | CONFIG_SYS_NAND_ALE));
+ out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_NAND_CE);
/*
* Setup EEPROM write protection
*/
- out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) |
CONFIG_SYS_EEPROM_WP);
- out_be32((void*)GPIO0_TCR, in_be32((void*)GPIO0_TCR) |
CONFIG_SYS_EEPROM_WP);
+ out_be32((void*)GPIO0_OR,
+in_be32((void*)GPIO0_OR) | CONFIG_SYS_EEPROM_WP);
+ out_be32((void*)GPIO0_TCR,
+in_be32((void*)GPIO0_TCR) | CONFIG_SYS_EEPROM_WP);
/*
* Enable interrupts in exar duart mcr[3]
*/
- out_8(duart0_mcr, 0x08);
- out_8(duart1_mcr, 0x08);
+ out_8((void *)DUART0_BA + 4, 0x08);
+ out_8((void *)DUART1_BA + 4, 0x08);
/*
* Enable auto RS485 mode in 2nd external uart
@@ -213,26 +214,25 @@ int misc_init_r (void)
out_8((void *)DUART1_BA + 1, fctr); /* write FCTR */
out_8((void *)DUART1_BA + 3, 0);/* write LCR */
- return (0);
+ return 0;
}
/*
* Check Board Identity:
*/
-int checkboard (void)
+int checkboard(void)
{
char str[64];
- int i = getenv_r (serial#, str, sizeof(str));
+ int i = getenv_r(serial#, str, sizeof(str));
- puts (Board: );
+ puts(Board: );
- if (i == -1) {
- puts (### No HW ID - assuming PLU405);
- } else {
+ if
Re: [U-Boot] Please pull u-boot-cfi-flash
Dear Stefan Roese, In message 200907161530.12024...@denx.de you wrote: The following changes since commit 7d4450a9773673052fcd7fdf0a4a88c089126ac1: Wolfgang Denk (1): mpc5121ads: add JFFS2 and MTDPARTS support; adjust flash map are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master Kim Phillips (1): mtd: cfi - if defined, use MAX_FLASH_BANKS_DETECT for static declarations drivers/mtd/cfi_mtd.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Applying computer technology is simply finding the right wrench to pound in the correct screw. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootstrap command
On 7/16/2009 2:36 PM, Wolfgang Denk wrote: Dear Matthias Fuchs, In message200907161547.17433.matthias.fu...@esd.eu you wrote: Hi Dirk, On Wednesday 15 July 2009 16:46:12 Mike Frysinger wrote: On Wednesday 15 July 2009 09:48:00 Dirk Eibach wrote: This adds a generic command for programming I2C bootstrap eeproms. Implementation for Canyonlands board is included. bootstrap is pretty generic. can you pick something a little more descriptive/specific ? a little mit different that the bootstrap command. Actually the name bootstrap command itself is something that I really dislike. Please find a better description (avoiding bootstrap), and then chose a descriptive name. Keep in mind the processor UM documentation section that covers these boot methods is labeled Bootstrap Operations. It refers the registers that the EEPROM values populate as bootstrap registers, etc. There is some logic in tying the section of the processor manual to the command. Whatever the command ends up being labeled, it would be nice if its purpose was clear to those who actually work in 4xx space. Not to mention there is documentation referencing the current commands used by the evaluation platforms. Regards, -DM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] Add simple hwconfig infrastructure
Dear Anton Vorontsov, In message 20090609202527.ga20...@oksana.dev.rtsoft.ru you wrote: This patch implements simple hwconfig infrastructure: an interface for software knobs to control a hardware. This is very simple implementation, i.e. it is implemented via `hwconfig' environment variable. Later we could write some hwconfig enable|disable|list commands, ncurses interface for Award BIOS-like interface, and frame-buffer interface for AMI GUI[1] BIOS-like interface with mouse support[2]. Current implementation details/limitations: 1. Doesn't support options dependencies and mutual exclusion. We can implement this by integrating apt-get[3] into the u-boot. But I didn't bother yet. 2. Since we don't implement hwconfig command, i.e. we're working with the environement directly, there is no way to tell that toggling a particular option will need a reboot to take an effect. So, for now it's advised to always reboot the target after modifying hwconfig variable. 3. We support hwconfig options with arguments. For example, set hwconfig dr_usb:mode=peripheral,phy_type=ulpi That means: - dr_usb - enable Dual-Role USB controller; - dr_usb:mode=peripheral - USB in Function mode; - dr_usb:phy_type=ulpi - USB should work with ULPI PHYs; The purpose of this simple implementation is to define some internal API and then we can continue improving user experience by adding more mature interface, like hwconfig command with bells and whistles. Or not adding, if we feel that current interface fits its needs. [1] http://en.wikipedia.org/wiki/American_Megatrends [2] Regarding ncurses and GUI with mouse support -- I'm just kidding. [3] The comment regarding apt-get is also a joke, meaning that dependency tracking could be non-trivial. For example, for enabling HW feature X we may need to disable Y, and turn Z into reduced mode (like RMII-only interface for ethernet, no MII). It's quite trivial to implement simple cases though. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- common/Makefile|1 + common/hwconfig.c | 210 include/hwconfig.h | 69 + 3 files changed, 280 insertions(+), 0 deletions(-) create mode 100644 common/hwconfig.c create mode 100644 include/hwconfig.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The games have always strengthened us. Death becomes a familiar pattern. We don't fear it as you do. -- Proconsul Marcus Claudius, Bread and Circuses, stardate 4041.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] fsl_esdhc: Add device tree fixups
Dear Anton Vorontsov, In message 20090609202529.gb20...@oksana.dev.rtsoft.ru you wrote: This patch implements fdt_fixup_esdhc() function that is used to fixup the device tree. The function adds status = disabled propery if esdhc pins muxed away, otherwise it fixups clock-frequency for esdhc nodes. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/mmc/fsl_esdhc.c | 19 +++ include/fsl_esdhc.h |8 2 files changed, 27 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When dreams become more important than reality, you give up travel, building, creating; you even forget how to repair the machines left behind by your ancestors. You just sit living and reliving other lives left behind in the thought records. -- Vina, The Menagerie (The Cage), stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] mpc83xx: MPC837XERDB: Add support for FSL eSDHC
Dear Anton Vorontsov, In message 20090609202530.gc20...@oksana.dev.rtsoft.ru you wrote: This patch adds support for eSDHC on MPC837XERDB boards. The WP switch doesn't seem to work on RDB boards though, the WP pin is always asserted (can see the pin state when it's in GPIO mode). FSL DR USB and FSL eSDHC are mutually exclusive because of pins multiplexing, so user should specify 'esdhc' or 'dr_usb' options in the hwconfig environment variable to choose between the devices. p.s. Now we're very close to a monitor len limit (196 bytes left using gcc-4.2.0), so also increase the monitor len by one sector (64 KB). Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- board/freescale/mpc837xerdb/mpc837xerdb.c | 18 ++ include/configs/MPC837XERDB.h | 18 +- 2 files changed, 35 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I didn't know it was impossible when I did it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] mpc83xx: MPC837XEMDS: Fixup eSDHC nodes in device tree
Dear Anton Vorontsov, In message 20090609202531.gd20...@oksana.dev.rtsoft.ru you wrote: fdt_fixup_esdhc() will either disable or enable eSDHC nodes, and also will fixup clock-frequency property. Plus, since DR USB and eSDHC are mutually exclusive, we should only configure the eSDHC if asked through hwconfig. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- board/freescale/mpc837xemds/mpc837xemds.c | 37 ++-- include/configs/MPC837XEMDS.h |1 + 2 files changed, 25 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find ... - Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] nand: Change NAND_MAX_OOBSIZE to 218 as needed for some 4k page devices
On Thu, Jun 04, 2009 at 04:40:36PM +0200, Stefan Roese wrote: This is needed for the MPC512x NAND driver (fsl_nfc_nand.c) which already defines such a 4k plus 218 bytes ECC layout. Signed-off-by: Stefan Roese s...@denx.de Cc: Scott Wood scottw...@freescale.com --- Applied to u-boot-nand-flash. Sorry for the delay, it got lost in a pile of old e-mail. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg
Dear Anton Vorontsov, In message 20090609202532.ge20...@oksana.dev.rtsoft.ru you wrote: In subsequent patches we'll use FSL-specific functions in fdt_fixup_dr_usb(), so let's move the routine to a more appropriate place. So far fsl_dr_usb.c isn't actually an USB driver, but eventually it will turn into one, let's hope. ;-) Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be consistent with other USB drivers. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Makefile |1 + board/freescale/mpc8315erdb/mpc8315erdb.c |1 + board/freescale/mpc837xemds/mpc837xemds.c |1 + board/freescale/mpc837xerdb/mpc837xerdb.c |1 + common/fdt_support.c | 41 -- drivers/usb/otg/Makefile | 46 + drivers/usb/otg/fsl_dr_usb.c | 52 + include/configs/MPC8315ERDB.h |2 +- include/configs/MPC837XEMDS.h |2 +- include/configs/MPC837XERDB.h |2 +- include/fdt_support.h |6 --- include/fsl_dr_usb.h | 21 +++ 12 files changed, 126 insertions(+), 50 deletions(-) create mode 100644 drivers/usb/otg/Makefile create mode 100644 drivers/usb/otg/fsl_dr_usb.c create mode 100644 include/fsl_dr_usb.h Sorry, this patch doesn't apply: Applying: fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg error: patch failed: common/fdt_support.c:454 error: common/fdt_support.c: patch does not apply error: patch failed: include/configs/MPC8315ERDB.h:344 error: include/configs/MPC8315ERDB.h: patch does not apply error: patch failed: include/fdt_support.h:53 error: include/fdt_support.h: patch does not apply fatal: sha1 information is lacking or useless (board/freescale/mpc837xemds/mpc837xemds.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0005. Please rebase and resubmit. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If it has syntax, it isn't user friendly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] fdt_support, usb: Move fdt_fixup_dr_usb routine to drivers/usb/otg
Dear Anton Vorontsov, In message 20090609202532.ge20...@oksana.dev.rtsoft.ru you wrote: In subsequent patches we'll use FSL-specific functions in fdt_fixup_dr_usb(), so let's move the routine to a more appropriate place. So far fsl_dr_usb.c isn't actually an USB driver, but eventually it will turn into one, let's hope. ;-) Also rename CONFIG_HAS_FSL_DR_USB to CONFIG_USB_FSL_DR to be consistent with other USB drivers. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Makefile |1 + board/freescale/mpc8315erdb/mpc8315erdb.c |1 + board/freescale/mpc837xemds/mpc837xemds.c |1 + board/freescale/mpc837xerdb/mpc837xerdb.c |1 + common/fdt_support.c | 41 -- drivers/usb/otg/Makefile | 46 + drivers/usb/otg/fsl_dr_usb.c | 52 + include/configs/MPC8315ERDB.h |2 +- include/configs/MPC837XEMDS.h |2 +- include/configs/MPC837XERDB.h |2 +- include/fdt_support.h |6 --- include/fsl_dr_usb.h | 21 +++ 12 files changed, 126 insertions(+), 50 deletions(-) create mode 100644 drivers/usb/otg/Makefile create mode 100644 drivers/usb/otg/fsl_dr_usb.c create mode 100644 include/fsl_dr_usb.h Sorry, doesn't apply: Applying: fsl_dr_usb: Fixup disabled USB controllers nodes in device tree error: drivers/usb/otg/fsl_dr_usb.c: does not exist in index fatal: sha1 information is lacking or useless (drivers/usb/otg/fsl_dr_usb.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0006. Please rebase and resubmit. 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 two most common things in the universe are hydrogen and stupi- dity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Initial environment variables
Ron Madrid wrote: When I submitted patches for my new board SIMPC8313 I recall being told that I had inappropriately initialized some of my environment variables. Most specifically I am interested in having default serverip, ipaddr, and ethaddr environment variables. Is this most appropriately done with a specific #define (such as #define CONFIG_SERVERIP) or within #define CONFIG_EXTRA_ENV_SETTINGS? You can set CONFIGs for all of these things in your own private build and they'll work, but they're inappropriate for main-line U-boot. I hope the reasoning is obvious. I'm do not understand why and I see in several include/configs/*.h files that these environment variable are being set as default. I'm guessing that there's something that I'm missing. Ron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
